I'm forwarding this to monodevelop-*devel* list. + +laas, take a look at the code in this file: + +trunk/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui.Search/WholeCombineDocumentIterator.cs + +I bet it will give you some clues ;) + + Andrés + + +laas wrote: +> Hi Mike, +> I've never used the collection Project.Files. Does it contains all the +> solution document ? Also documents (cs, xml and so on) in project +> subfolder ? +> +> Best regards, +> LAAS +> +> On Thu, Aug 28, 2008 at 4:27 PM, Mike Kestner <mkestner at gmail.com +> <mailto:mkestner at gmail.com>> wrote: +> +> On Thu, 2008-08-28 at 11:39 +0200, laas wrote: +> > Hi all, +> > developing for Monodevelop, I'm using the following collection: +> > +> > IdeApp.Workbench.Documents +> > +> > in order to loop through all the documents that are currently open. +> > Is there a collection that can be used to loop through ALL the +> project (or solution) documents (open and closed) ? +> +> Maybe I'm not understanding what you mean by documents, but there's +> Project.Files. +> +> Mike ++ + +
Starting: Thu Aug 28 11:18:37 EDT 2008
+ Ending: Thu Aug 28 11:18:37 EDT 2008
+ Messages: 1
+
+ Last message date:
+ Thu Aug 28 11:18:37 EDT 2008
+ Archived on: Thu Aug 28 11:19:10 EDT 2008
+
+
+
Starting: Thu Aug 28 11:18:37 EDT 2008
+ Ending: Thu Aug 28 11:18:37 EDT 2008
+ Messages: 1
+
+ Last message date:
+ Thu Aug 28 11:18:37 EDT 2008
+ Archived on: Thu Aug 28 11:19:10 EDT 2008
+
+
+
Starting: Thu Aug 28 11:18:37 EDT 2008
+ Ending: Thu Aug 28 11:18:37 EDT 2008
+ Messages: 1
+
+ Last message date:
+ Thu Aug 28 11:18:37 EDT 2008
+ Archived on: Thu Aug 28 11:19:10 EDT 2008
+
+
+
Starting: Thu Aug 28 11:18:37 EDT 2008
+ Ending: Thu Aug 28 11:18:37 EDT 2008
+ Messages: 1
+
+ Last message date:
+ Thu Aug 28 11:18:37 EDT 2008
+ Archived on: Thu Aug 28 11:19:10 EDT 2008
+
+
+
Starting: Thu Aug 28 11:18:37 EDT 2008
+ Ending: Thu Aug 28 11:18:37 EDT 2008
+ Messages: 1
+
+ Last message date:
+ Thu Aug 28 11:18:37 EDT 2008
+ Archived on: Thu Aug 28 11:19:10 EDT 2008
+
+
+
I created this page where I'll be updating the roadmap for MD: + +http://www.monodevelop.com/Development_Roadmap + +I'll update it with more specific dates when approaching a release. + +Lluis. + ++ + + +
The attached patch fixes some errors received when compiling MD with +csc. This is bug #421838 filed against mcs. + +Jonathan +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: mdpatch1.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081217/3a464dd7/attachment.pl ++ + + +
Fixed. Thanks!
+
+El dc 17 de 12 de 2008 a les 17:24 -0600, en/na Jonathan Pobst va
+escriure:
+> The attached patch fixes some errors received when compiling MD with
+> csc. This is bug #421838 filed against mcs.
+>
+> Jonathan
+> fitxer adjunt document de text pla (mdpatch1.patch)
+> Index: addins/Mono.Texteditor/Mono.TextEditor/DocumentLocation.cs
+> ===================================================================
+> --- addins/Mono.Texteditor/Mono.TextEditor/DocumentLocation.cs (revision 121639)
+> +++ addins/Mono.Texteditor/Mono.TextEditor/DocumentLocation.cs (working copy)
+> @@ -42,7 +42,7 @@
+> }
+> }
+>
+> - public DocumentLocation (int line, int column)
+> + public DocumentLocation (int line, int column) : this ()
+> {
+> this.Line = line;
+> this.Column = column;
+> Index: core/MonoDevelop.Projects/MonoDevelop.Projects.Dom/DomLocation.cs
+> ===================================================================
+> --- core/MonoDevelop.Projects/MonoDevelop.Projects.Dom/DomLocation.cs (revision 121639)
+> +++ core/MonoDevelop.Projects/MonoDevelop.Projects.Dom/DomLocation.cs (working copy)
+> @@ -55,7 +55,7 @@
+> }
+> }
+>
+> - public DomLocation (int line, int column)
+> + public DomLocation (int line, int column) : this ()
+> {
+> this.Line = line;
+> this.Column = column;
+> Index: core/MonoDevelop.Projects/MonoDevelop.Projects.Dom/DomRegion.cs
+> ===================================================================
+> --- core/MonoDevelop.Projects/MonoDevelop.Projects.Dom/DomRegion.cs (revision 121639)
+> +++ core/MonoDevelop.Projects/MonoDevelop.Projects.Dom/DomRegion.cs (working copy)
+> @@ -55,7 +55,7 @@
+> {
+> }
+>
+> - public DomRegion (int startLine, int startColumn, int endLine, int endColumn)
+> + public DomRegion (int startLine, int startColumn, int endLine, int endColumn) : this ()
+> {
+> this.Start = new DomLocation (startLine, startColumn);
+> this.End = new DomLocation (endLine, endColumn);
+> _______________________________________________
+> Monodevelop-devel-list mailing list
+> Monodevelop-devel-list at lists.ximian.com
+> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+
+
+
+
+
+ The attached patch fixes some errors received while compiling MD with +csc. This is bug #370414 filed against mcs. You may want to name the +variables something different than what I chose, however the existing +ones conflict. + +Jonathan +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: mdpatch2.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081218/601259eb/attachment.pl ++ + + +
Hey guys, + +Marc and I would like to start working on a Makefile target to create a +app directory for MonoDevelop (for Mac OSX). +Currently, building the app dir for OSX isn't streamlined and takes some +additional time on our part. If no one is already +working on this, I'd like to put a bit of time into it. I have the MD +source but am not too familiar with it. I was thinking about +doing most of the work in monodevelop/main/build/Makefile.am since that +dir seems to have the built binaries. + +If anyone has suggestions or tips, that would be great. + +Rusty ++ + + +
El dj 18 de 12 de 2008 a les 13:35 -0700, en/na Rusty Howell va +escriure: +> Hey guys, +> +> Marc and I would like to start working on a Makefile target to create a +> app directory for MonoDevelop (for Mac OSX). + +That's great news :) + +> Currently, building the app dir for OSX isn't streamlined and takes some +> additional time on our part. If no one is already +> working on this, I'd like to put a bit of time into it. I have the MD +> source but am not too familiar with it. I was thinking about +> doing most of the work in monodevelop/main/build/Makefile.am since that +> dir seems to have the built binaries. + +A better place would be monodevelop/main/Makefile.am, since that's the +main MD makefile. + +Lluis. + + ++ + +
Starting: Fri Dec 12 13:11:49 EST 2008
+ Ending: Fri Dec 19 13:09:52 EST 2008
+ Messages: 6
+
+ Last message date:
+ Fri Dec 19 13:09:52 EST 2008
+ Archived on: Fri Dec 19 13:10:10 EST 2008
+
+
+
Starting: Fri Dec 12 13:11:49 EST 2008
+ Ending: Fri Dec 19 13:09:52 EST 2008
+ Messages: 6
+
+ Last message date:
+ Fri Dec 19 13:09:52 EST 2008
+ Archived on: Fri Dec 19 13:10:10 EST 2008
+
+
+
Starting: Fri Dec 12 13:11:49 EST 2008
+ Ending: Fri Dec 19 13:09:52 EST 2008
+ Messages: 6
+
+ Last message date:
+ Fri Dec 19 13:09:52 EST 2008
+ Archived on: Fri Dec 19 13:10:10 EST 2008
+
+
+
Starting: Fri Dec 12 13:11:49 EST 2008
+ Ending: Fri Dec 19 13:09:52 EST 2008
+ Messages: 6
+
+ Last message date:
+ Fri Dec 19 13:09:52 EST 2008
+ Archived on: Fri Dec 19 13:10:10 EST 2008
+
+
+
Starting: Fri Dec 12 13:11:49 EST 2008
+ Ending: Fri Dec 19 13:09:52 EST 2008
+ Messages: 6
+
+ Last message date:
+ Fri Dec 19 13:09:52 EST 2008
+ Archived on: Fri Dec 19 13:10:10 EST 2008
+
+
+
Hi, + +is it possible, that the new build system does not stop if a requirement +of a selected package is not met? Or do the packages not check for all +requirements? + +Because today, I ran into a couple of missing missing libraries when +compiling but autogen.sh didn't tell me that they were missing in the +first place. (e.g. monodoc which is used by the documentation plugin). + +Kind Regards, +Valentin +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: This is a digitally signed message part +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080712/25b66d36/attachment.bin ++ + + + +
Hi, + +I noticed, that the current ASP.NET templates are outdated and can not +be used out of the box anymore. (e.g. the CodeBehind attribute is +obsolete and the CodeFile is not present, this stops the application +from compiling). Attached is a patch containing the updated templates to +fix this. + +Kind Regards, +Valentin +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: updatedTemplates.diff +Type: text/x-patch +Size: 10900 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080712/d1a9a35d/attachment.bin +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: This is a digitally signed message part +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080712/d1a9a35d/attachment-0001.bin ++ + + + + + +
On Sat, Jul 12, 2008 at 12:05 PM, Valentin Sawadski +<valentin.sawadski at googlemail.com> wrote: +> Hi, +> +> I noticed, that the current ASP.NET templates are outdated and can not +> be used out of the box anymore. (e.g. the CodeBehind attribute is +> obsolete and the CodeFile is not present, this stops the application +> from compiling). Attached is a patch containing the updated templates to +> fix this. + +Actually, the CodeFile attribute is only needed when the codebehind +files are intended to be compiled on the server (as VS Express < +2008sp1) does it. The full VS (and VS Express 2008sp2) supports Web +Projects, where the CodeBehind is compiled beforehand. MonoDevelop +uses the latter model. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + +
On Mon, 2008-07-14 at 09:41 -0400, Michael Hutchinson wrote: +> On Sat, Jul 12, 2008 at 12:05 PM, Valentin Sawadski +> <valentin.sawadski at googlemail.com> wrote: +> > Hi, +> > +> > I noticed, that the current ASP.NET templates are outdated and can not +> > be used out of the box anymore. (e.g. the CodeBehind attribute is +> > obsolete and the CodeFile is not present, this stops the application +> > from compiling). Attached is a patch containing the updated templates to +> > fix this. +> +> Actually, the CodeFile attribute is only needed when the codebehind +> files are intended to be compiled on the server (as VS Express < +> 2008sp1) does it. The full VS (and VS Express 2008sp2) supports Web +> Projects, where the CodeBehind is compiled beforehand. MonoDevelop +> uses the latter model. +> +Thats odd, because MSDN +(http://msdn.microsoft.com/en-us/library/ydy4x04a(VS.80).aspx) does not +mention this. It only states that: + + "This attribute is included for compatibility with previous + versions of ASP.NET, to implement the code-behind feature. In + ASP.NET version 2.0, you should instead use the CodeFile + attribute to specify the name of the source file, along with the + Inherits attribute to specify the fully qualified name of the + class." + +Anyways, this does not change the fact that the current Templates do not +work with xsp and xsp2 out of the box. Adding CodeFile to them fixes +this. + +Kind Regards, +Valentin +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: This is a digitally signed message part +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080714/398d41fb/attachment-0001.bin ++ + + + + + +
On Mon, Jul 14, 2008 at 12:36 PM, Valentin Sawadski +<valentin.sawadski at googlemail.com> wrote: +>> Actually, the CodeFile attribute is only needed when the codebehind +>> files are intended to be compiled on the server (as VS Express < +>> 2008sp1) does it. The full VS (and VS Express 2008sp2) supports Web +>> Projects, where the CodeBehind is compiled beforehand. MonoDevelop +>> uses the latter model. +>> +> Thats odd, because MSDN +> (http://msdn.microsoft.com/en-us/library/ydy4x04a(VS.80).aspx) does not +> mention this. It only states that: +> +> "This attribute is included for compatibility with previous +> versions of ASP.NET, to implement the code-behind feature. In +> ASP.NET version 2.0, you should instead use the CodeFile +> attribute to specify the name of the source file, along with the +> Inherits attribute to specify the fully qualified name of the +> class." + +The CodeBehind attribute is only used by Visual Studio 2002/2003. All +versions of ASP.NET are aware of it, and totally ignore it. It can be +omitted, and won't affect anything. + +The CodeFile attribute is used by ASP.NET 2.0 for the "2005" model, +where the CodeBehind class is compiled on the server. It specifies the +CodeBehind file that should be compiled when the page is compiled. In +this model, a partial class is generated and compiled together with +the CodeBehind class that's defined in the CodeFile. + +The Inherits attribute is used in ALL compilation models to specify +the class from which the compiled page should inherit. It can be +System.Web.UI.Page or ANY class that derives from this, in ANY of the +referenced assemblies. If you have the CodeFile attribute, it can be +defined in a file compiled on the fly. Having these classes "grouped" +in the IDE (Default.aspx.cs etc) with the corresponding is simply a +convenience that MonoDevelop and Visual Studio provide. Ultimately +they all get compiled down into on application dll from which the aspx +compiler can reference them. + +Note that although the CodeFile ("Web Site") model was introduced with +ASP.NET 2.0 and VS 2005, many developers considered it to be inferior +for serious applications, and hence Microsoft introduced an addin for +2005 that added support for the old-style "Web Projects", and included +it with 2008 by default. They've even added it to VS Express in +2008sp1, since the "web projecy" model is required for the upcoming +MVC style of development. + +> Anyways, this does not change the fact that the current Templates do not +> work with xsp and xsp2 out of the box. Adding CodeFile to them fixes +> this. + +They work just fine, as long as you compile the project first. MD +doesn't yet explicitly support the "web site" model. I plan to support +it to some extent (but maybe only as an importer -- I have a limited +amount of time, and MVC is likely to become the most important +development style anyway). + +When designing the initial ASP.NET support for MD back in 2006, I +investigated the ASP.NET compilation models very thoroughly, and I'm +glad the one I chose seems to have become the preferred choice for +future development. The "web site" model is cute but it's not really +suited to serious development (VCS, deployment, etc). It was basically +an attempt to make ASP.NET more like PHP ;-) + +I'd be happy to add your templates as an alternate set but they won't +replace the existing ones. I'm not sure how to prevent confusion +between the two kinds though :-/ + +Thanks, + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + +
This seems to be a bug in Stetic right? It should parse anything with +the InvariantCulture. + +Regards, + + Andrés + +-- + +-------------- next part -------------- +An embedded message was scrubbed... +From: lordphoenix <lordphoenix at tuxfamily.org> +Subject: Monodevevelop 1.9 Error when opening old Gtk# Project +Date: Thu, 17 Jul 2008 15:21:04 +0200 +Size: 5688 +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080717/1700c705/attachment.eml ++ + + + + + +
On Sat, Jul 12, 2008 at 10:43 AM, Valentin Sawadski +<valentin.sawadski at googlemail.com> wrote: +> Hi, +> +> is it possible, that the new build system does not stop if a requirement +> of a selected package is not met? Or do the packages not check for all +> requirements? + +The top-level configure will fail in any of the packages fail to +configure. However, it's possible that some packages may not check for +everything they need in their configure scripts. + +> Because today, I ran into a couple of missing missing libraries when +> compiling but autogen.sh didn't tell me that they were missing in the +> first place. (e.g. monodoc which is used by the documentation plugin). + +Do you have a list of the missing checks handy? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Fri, 2008-07-18 at 18:16 -0400, Michael Hutchinson wrote: +> On Sat, Jul 12, 2008 at 10:43 AM, Valentin Sawadski +> <valentin.sawadski at googlemail.com> wrote: +> > Hi, +> > +> > is it possible, that the new build system does not stop if a requirement +> > of a selected package is not met? Or do the packages not check for all +> > requirements? +> +> The top-level configure will fail in any of the packages fail to +> configure. However, it's possible that some packages may not check for +> everything they need in their configure scripts. +> +> > Because today, I ran into a couple of missing missing libraries when +> > compiling but autogen.sh didn't tell me that they were missing in the +> > first place. (e.g. monodoc which is used by the documentation plugin). +> +> Do you have a list of the missing checks handy? +> +The only thing I can remember right now is gecko-sharp. I think the +aspnet-addin uses it but does not check for it. Because MD crashes due +to some Missing-Dll-Exception whenever I click the designer button of +aspx-Files. + +But I will check for more dependencies later. + +Kind Regards, +Valentin +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: This is a digitally signed message part +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080719/d82888b8/attachment.bin ++ + + +
On Sat, Jul 19, 2008 at 5:46 AM, Valentin Sawadski +<valentin.sawadski at googlemail.com> wrote: +>> > Because today, I ran into a couple of missing missing libraries when +>> > compiling but autogen.sh didn't tell me that they were missing in the +>> > first place. (e.g. monodoc which is used by the documentation plugin). +>> +>> Do you have a list of the missing checks handy? +>> +> The only thing I can remember right now is gecko-sharp. I think the +> aspnet-addin uses it but does not check for it. Because MD crashes due +> to some Missing-Dll-Exception whenever I click the designer button of +> aspx-Files. + +AspNetEdit requires it, but it looks like it's checking: +http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/extras/AspNetEdit/configure?view=markup. +It looks like the main configure checks for MonoDoc too: +http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/main/configure.in?view=markup + +Maybe the assemblies are in your pkg-config path but not the GAC? Did +you install MonoDoc and Gecko# from source? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Hey folks, + +When I was in MA in January, mhutch and I talked about converging the +codebases of prebuild and monodevelop. It seems that monodevelop will +be using 'xbuild,' which is the Mono version of msbuild. On IRC +today, mhutch, sontek an I talked about making things a bit more +concrete. + +It seems a wise move to me to alter prebuild to depend on xbuild and +hand all of the heavy lifting off to it, providing only the same +command line interface. + +Perhaps during a deprecation phase, a warning could be printed and the +old back-end could be used. This will allow folks to alter their code +while still picking up the latest version of ours. + +Thoughts? ankit, lluis, I hear you're a couple of folks we should get +feedback from. + +Cheers, + +C.J. +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 189 bytes +Desc: Digital signature +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080727/32fdb979/attachment.bin ++ + + +
Marek Safar wrote: +> Hello, +>> Arghh, same issue with gmcs from SVN. Marek, are you already aware of +>> this issue or do you want me to file a bug..? +>> +> No, please fill a bug report. + +Thanks for your reply Marek!: +https://bugzilla.novell.com/show_bug.cgi?id=412595 + +I'll try to cook a smaller testcase if I have enough time. + +FYI: checkout monodevelop rev 108914 as a workaround to this problem. + +Regards, + + Andrés + +-- ++ + + +
On Sun, Jul 27, 2008 at 6:51 AM, Mike Krüger <mkrueger at novell.com> wrote: +> Hi +> +> Today I've submitted my latest dom changes. Do not use the current SVN +> version for daily use. I've tested the changes and work with the +> version. +> +> We'll add nice features like C#3 support, instant code completion and a +> new code completion database backend based on sqlite. (Also the new code +> completion should be faster on large files - but I need to test it) +> Currently all refactoring support is broken. I think I've fixed it next +> week. The next weeks I'll work on stabilizing the new changes and adding +> c#3 support. + +The DOM changes have resulted in severe regressions in the ASP.NET +binding, among many other things (including C# completion, +refactoring, stetic, etc). The CodeBehind member generation is +completely broken, and will have to be ported to use the new DOM, as +will the BindingService and CodeRefactorer that it uses. + +More importantly, the Parser infrastructure and the type/member lookup +used by the ASP.NET code completion is totally non-operational. As I'm +working on the ASP.NET code completion, this makes things difficult +for me. I can work around it for now, but I need this stuff to be +operational soon. + +How soon are these likely to be fixed? Could we have a summary of the +changes that need to be made to existing code to port it to the new +parser infrastructure and DOM? + +If these won't be fixed soon, I suggest that we move the changes into +a svn branch, and revert the changes on trunk. We could then remove +the old DOM and parser infrastructure in order to track down *ALL* the +places that need to be fixed, before merging back to trunk. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Hi, + +This discussion should have been done before committing anything to +trunk, but here it is anyway. + +Migrating to SQLite only makes sense if it provides noticeable +improvements in performance and memory use. Guessing that it will be +better is not enough. We need real numbers before taking the decision to +switch, and only do it if the numbers are so much better that pay off +the burden of having a dependency on SQLite. + +I might be wrong, but I don't believe that SQLite will be better than +the ad-hoc database we are using in MD 1.0. I spent a lot of time tuning +up the parser database, and I'm quite happy about how is it performing. + +The old .pidb files are split in two sections. The first section is an +index of the database contents. It has the names of all types in the +project/assembly, sub-class relations, the hierarchy of namespaces, the +source code files, and all the relations between them. This index is +fully loaded in memory and has enough information for the most common +queries: type lookup, getting types in a namespace or file, querying +subclasses, etc. + +The second section contains the full information for every class. This +section is never fully loaded in memory. Every class entry in the index +contains the file offset of the full information of the class in the +second section. When needed, that class information is loaded using an +ad-hoc binary serializer, which is as fast as it can be. The number of +classes which are fully loaded in memory is limited to 100. Only the +most 100 recently used classes are fully kept in memory. This limit +prevents the parser database from using too much memory and still keep a +good performance. + +However, all this infrastructure is transparent to the database user. +For example, the method GetSubclasses will return a list of IClass +objects, but those IClass objects are not fully loaded, they are just +'proxies'. They only contain information from the index, that is, the +class name, namespace and visibility flags. This is all the information +needed to fill the code completion window for the 'new' keyword, for +example. If more information is requested, such as the class +documentation or the list of members, all that information is lazily +loaded from the database. + +The result is that queries on the database are fast (because in many +cases the required information is already in memory), and have a good +memory use (because the biggest section of the database is never fully +loaded). Could it be better? maybe, but I think it is good enough +(especially regarding memory use, it is much better than Visual Studio +and #develop). + +Lluis. + + ++ + + + +
Hi + +> This discussion should have been done before committing anything to +> trunk, but here it is anyway. +> +> Migrating to SQLite only makes sense if it provides noticeable +> improvements in performance and memory use. Guessing that it will be +> better is not enough. We need real numbers before taking the decision +> to +> switch, and only do it if the numbers are so much better that pay off +> the burden of having a dependency on SQLite. +> +> I might be wrong, but I don't believe that SQLite will be better than +> the ad-hoc database we are using in MD 1.0. I spent a lot of time +> tuning +> up the parser database, and I'm quite happy about how is it +> performing. +> + +Some more benefits for using a real database over an own implementation: + +- It's reliable. Atomic transactions, threading - all solved. +- It's easy to look into the data using a command line client and SQL +statements + +Its not just pure performance. Using a database will allow us for +example to switch the database software to a new implementation. And +databases and SQL are very easy to understood and to change. + +I had to think about it too (I implemented the #develop database some +years ago which monodevelop inherited (but optimized I admit ^^)) - +after thinking about it the decision was easy - A database makes it +easier to change the model and to make complicated querys more +efficient. + +There are many more reasons using database software instead of own data +storage solutions - otherwise the whole database software would be +obsolete. + +Regards +Mike + ++ + + + + +
Hi, + +On Mon, Jul 28, 2008 at 2:44 PM, Mike Krüger <mkrueger at novell.com> wrote: +> Hi +> +>> This discussion should have been done before committing anything to +>> trunk, but here it is anyway. +>> +>> Migrating to SQLite only makes sense if it provides noticeable +>> improvements in performance and memory use. Guessing that it will be +>> better is not enough. We need real numbers before taking the decision +>> to +>> switch, and only do it if the numbers are so much better that pay off +>> the burden of having a dependency on SQLite. +>> +>> I might be wrong, but I don't believe that SQLite will be better than +>> the ad-hoc database we are using in MD 1.0. I spent a lot of time +>> tuning +>> up the parser database, and I'm quite happy about how is it +>> performing. +>> +> +> Some more benefits for using a real database over an own implementation: +> +> - It's reliable. Atomic transactions, threading - all solved. + +While I'm happy with either solution, lets keep in mind that sqlite is +not thread-safe by default (requires SQLITE_THREADSAFE=1 at compile +time). So we will need to queue queries via a single-thread unless we +can guarantee our sqlite version. + +Perhaps the sqlite wrappers take care of that now, I really haven't checked. + +> - It's easy to look into the data using a command line client and SQL +> statements +> +> Its not just pure performance. Using a database will allow us for +> example to switch the database software to a new implementation. And +> databases and SQL are very easy to understood and to change. +> +> I had to think about it too (I implemented the #develop database some +> years ago which monodevelop inherited (but optimized I admit ^^)) - +> after thinking about it the decision was easy - A database makes it +> easier to change the model and to make complicated querys more +> efficient. +> +> There are many more reasons using database software instead of own data +> storage solutions - otherwise the whole database software would be +> obsolete. +> +> Regards +> Mike +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> ++ + + + + + +
Il giorno lun, 28/07/2008 alle 23.44 +0200, Mike Krüger ha scritto: +> I had to think about it too (I implemented the #develop database some +> years ago which monodevelop inherited (but optimized I admit ^^)) - +> after thinking about it the decision was easy - A database makes it +> easier to change the model and to make complicated querys more +> efficient. + +Actually a standard query language allow to make complicated queries +easier to understand but almost never more efficient. We use SQL because +it has a very stable and well-know mathematical foundation and very good +implementations but a specialized storage format is almost always +faster. + +> There are many more reasons using database software instead of own data +> storage solutions - otherwise the whole database software would be +> obsolete. + +In fact we use specialized storage formats for a lot of application +domains where standard SQL would be too slow. The fact that most of the +problems can be solved by SQL doesn't mean that SQL is good for +anything. + +Said that, probably SQLite would be fast enough. + +-- +Federico Di Gregorio http://people.initd.org/fog +Debian GNU/Linux Developer fog at debian.org +INIT.D Developer fog at initd.org + E tu usa il prefisso corretto Re: non R:, questa è una ML seria. + -- cosmos, su debian-italian +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio + firmata digitalmente +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080729/2cdd9ed7/attachment.bin ++ + + +
Hi
+
+Ok. I tried to make it easy to convert old dom code over to new dom
+code.
+
+
+Basically it's:
+
+not longer:
+using MonoDevelop.Projects.Parser;
+
+instead:
+using MonoDevelop.Projects.Dom;
+
+not longer: IClass instead: IType
+
+Parser registration (with the addin tree):
+
+<Extension path = "/MonoDevelop/Ide/DomParser">
+ <Class class = "MonoDevelop.CSharpBinding.DomParser" />
+</Extension>
+
+The parser must extend the MonoDevelop.Projects.Dom.Parser.IParser
+interface. I recommend inheriting from
+MonoDevelop.Projects.Dom.Parser.AbstractParser which makes changes in
+the interface more easy.
+
+Generally I tried to move functions from some services to the objects
+directly. For example - monodoc documentation could be now accessed by
+System.Xml.XmlNode GetMonodocDocumentation (); instead of the
+documentation service. Or the icon could be get by
+string StockIcon { get; } instead of using the IconService. I'll add
+more functions to the dom. The goal is to make it easier to find
+functions and bring back some responsibility to the objects.
+
+
+GETTING PARSE INFOS:
+
+MonoDevelop.Ide.Gui.Document
+
+now contains:
+public ICompilationUnit CompilationUnit {
+ get;
+}
+In former versions the document contained only the text contents, now it
+contains the most recent parse information too.
+
+
+For the rest - look at:
+MonoDevelop.Projects.Dom.Parser.ProjectDomService
+
+There you have functions like:
+IParser GetParserByMime (string mimeType);
+IParser GetParserByFileName (string fileName);
+
+ICompilationUnit Parse (Project project,
+ string fileName,
+ string mimeType)
+
+
+For projects:
+ProjectDom GetDatabaseProjectDom (Project project);
+The ProjectDom contains the project parser info (was ParserContext in
+former versions)
+
+The Projects will contain the ProjectDom as property, but currently I
+had already too many name clashes. After removing the old infrastructure
+I'll do some refactorings to make the access easier. (I could need some
+input here - maybe someone has new ideas what's missing. Like
+the CompilationUnit inside the Document).
+
+The project dom contains some functions old dom users will find very
+familiar (like GetNamespaceContents, SearchType).
+
+
+I've converted much old code - most is done with renaming and switch
+over the usings. If you've more questions feel free to ask.
+
+Regards
+Mike
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Mike, can you give the estimated number of days it will take you to fix +all this? + +El dl 28 de 07 de 2008 a les 14:30 -0400, en/na Michael Hutchinson va +escriure: +> On Sun, Jul 27, 2008 at 6:51 AM, Mike Krüger <mkrueger at novell.com> wrote: +> > Hi +> > +> > Today I've submitted my latest dom changes. Do not use the current SVN +> > version for daily use. I've tested the changes and work with the +> > version. +> > +> > We'll add nice features like C#3 support, instant code completion and a +> > new code completion database backend based on sqlite. (Also the new code +> > completion should be faster on large files - but I need to test it) +> > Currently all refactoring support is broken. I think I've fixed it next +> > week. The next weeks I'll work on stabilizing the new changes and adding +> > c#3 support. +> +> The DOM changes have resulted in severe regressions in the ASP.NET +> binding, among many other things (including C# completion, +> refactoring, stetic, etc). The CodeBehind member generation is +> completely broken, and will have to be ported to use the new DOM, as +> will the BindingService and CodeRefactorer that it uses. +> +> More importantly, the Parser infrastructure and the type/member lookup +> used by the ASP.NET code completion is totally non-operational. As I'm +> working on the ASP.NET code completion, this makes things difficult +> for me. I can work around it for now, but I need this stuff to be +> operational soon. +> +> How soon are these likely to be fixed? Could we have a summary of the +> changes that need to be made to existing code to port it to the new +> parser infrastructure and DOM? +> +> If these won't be fixed soon, I suggest that we move the changes into +> a svn branch, and revert the changes on trunk. We could then remove +> the old DOM and parser infrastructure in order to track down *ALL* the +> places that need to be fixed, before merging back to trunk. +> + ++ + +
Hi!
+
+Let's explicitly set the rule (although I think it is obvious): if
+somebody does a big change or refactoring in the MD core, he is
+responsible for ensuring that *all* projects in MD (including everything
+in extras) can be properly built and work as expected (modulo bugs to be
+fixed as soon as possible when arise). You should take into account that
+you are not working alone in the project, and that other people have
+better thing to do than tracking api breakages.
+
+For a big change such as the project dom change, the correct process
+would be this:
+
+ * Create a branch.
+ * Do all changes in the branch, removing old code and adding the
+ new one.
+ * While doing the changes, merge back to the branch the commits
+ done by other people in trunk ('svn merge' is very helpful for
+ this).
+ * Fix all projects using the old code, change them to use the new
+ api.
+ * Do the basic tests to ensure that everything is working fine.
+ * Announce the availability of the new branch, and open the branch
+ for testing, so that other developers can ensure that there are
+ no issues with their own projects.
+ * Dogfooding: install and use the new MD for at least a couple of
+ weeks.
+ * At least one day before the merge to trunk, announce the
+ upcoming massive change, so people have time to commit pending
+ changes.
+ * Resolve the final conflicts caused by last minute commits.
+ * Do the merge and announce it.
+
+Lluis.
+
+El dt 29 de 07 de 2008 a les 00:23 +0200, en/na Mike Krüger va escriure:
+> Hi
+>
+> Ok. I tried to make it easy to convert old dom code over to new dom
+> code.
+>
+>
+> Basically it's:
+>
+> not longer:
+> using MonoDevelop.Projects.Parser;
+>
+> instead:
+> using MonoDevelop.Projects.Dom;
+>
+> not longer: IClass instead: IType
+>
+> Parser registration (with the addin tree):
+>
+> <Extension path = "/MonoDevelop/Ide/DomParser">
+> <Class class = "MonoDevelop.CSharpBinding.DomParser" />
+> </Extension>
+>
+> The parser must extend the MonoDevelop.Projects.Dom.Parser.IParser
+> interface. I recommend inheriting from
+> MonoDevelop.Projects.Dom.Parser.AbstractParser which makes changes in
+> the interface more easy.
+>
+> Generally I tried to move functions from some services to the objects
+> directly. For example - monodoc documentation could be now accessed by
+> System.Xml.XmlNode GetMonodocDocumentation (); instead of the
+> documentation service. Or the icon could be get by
+> string StockIcon { get; } instead of using the IconService. I'll add
+> more functions to the dom. The goal is to make it easier to find
+> functions and bring back some responsibility to the objects.
+>
+>
+> GETTING PARSE INFOS:
+>
+> MonoDevelop.Ide.Gui.Document
+>
+> now contains:
+> public ICompilationUnit CompilationUnit {
+> get;
+> }
+> In former versions the document contained only the text contents, now it
+> contains the most recent parse information too.
+>
+>
+> For the rest - look at:
+> MonoDevelop.Projects.Dom.Parser.ProjectDomService
+>
+> There you have functions like:
+> IParser GetParserByMime (string mimeType);
+> IParser GetParserByFileName (string fileName);
+>
+> ICompilationUnit Parse (Project project,
+> string fileName,
+> string mimeType)
+>
+>
+> For projects:
+> ProjectDom GetDatabaseProjectDom (Project project);
+> The ProjectDom contains the project parser info (was ParserContext in
+> former versions)
+>
+> The Projects will contain the ProjectDom as property, but currently I
+> had already too many name clashes. After removing the old infrastructure
+> I'll do some refactorings to make the access easier. (I could need some
+> input here - maybe someone has new ideas what's missing. Like
+> the CompilationUnit inside the Document).
+>
+> The project dom contains some functions old dom users will find very
+> familiar (like GetNamespaceContents, SearchType).
+>
+>
+> I've converted much old code - most is done with renaming and switch
+> over the usings. If you've more questions feel free to ask.
+>
+> Regards
+> Mike
+>
+>
+>
+>
+>
+>
+>
+>
+>
+>
+>
+>
+>
+>
+> _______________________________________________
+> Monodevelop-devel-list mailing list
+> Monodevelop-devel-list at lists.ximian.com
+> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+
+
+
+
+
+
+
+
+
+
+ El dl 28 de 07 de 2008 a les 23:44 +0200, en/na Mike Krüger va escriure: +> Hi +> +> > This discussion should have been done before committing anything to +> > trunk, but here it is anyway. +> > +> > Migrating to SQLite only makes sense if it provides noticeable +> > improvements in performance and memory use. Guessing that it will be +> > better is not enough. We need real numbers before taking the decision +> > to +> > switch, and only do it if the numbers are so much better that pay off +> > the burden of having a dependency on SQLite. +> > +> > I might be wrong, but I don't believe that SQLite will be better than +> > the ad-hoc database we are using in MD 1.0. I spent a lot of time +> > tuning +> > up the parser database, and I'm quite happy about how is it +> > performing. +> > +> +> Some more benefits for using a real database over an own implementation: +> +> - It's reliable. Atomic transactions, threading - all solved. + +Transactions and threading are not a problem for the parser database, so +that's not a real benefit. + +> - It's easy to look into the data using a command line client and SQL +> statements + +This is cool, but it has never been a requirement. + +> +> Its not just pure performance. Using a database will allow us for +> example to switch the database software to a new implementation. And +> databases and SQL are very easy to understood and to change. +> +> I had to think about it too (I implemented the #develop database some +> years ago which monodevelop inherited (but optimized I admit ^^)) - + +That's not correct, MD's parser database was written from scratch. The +inherited implementation would load everything in memory and would +collapse the system trying to open the MD solution. + +> after thinking about it the decision was easy - A database makes it +> easier to change the model and to make complicated querys more +> efficient. + +But curiously they are especially bad at querying hierarchies of objects +(such as namespace hierarchies or subclass hierarchies), unless you +denormalize the tables. + +Yes, databases are powerful. They can do amazing things with little +effort. But generic databases don't fit everywhere. A well designed +ad-hoc database may be better than a generic RDBMS, even if less +powerful. Everything depends on the requirements and constraints of the +application. For the specific case of the parser database, here are some +requirements: + + * Type and namespace lookup must be lightning fast. Type and + namespace queries are used by the parser when resolving types, + and by code completion when showing completion entries. I don't + think we can afford hitting the disk for that kind of queries. + * Most of operations are read operations, so the database must be + optimized for reading. Write operations are much less common + than reads. + * The data is the database is discardable. It is always possible + to regenerate a database by re-parsing a project or an assembly. + * Memory usage must be contained. Project and assembly databases + may contain a huge amount of information. + * The set of queries that it has to support is known and limited. + Those are basically: + * Get all types. + * Get all types implemented in a file, given the file + name. + * Get all subclasses of a class, given class name. + * Get a type, given the type name. + * Get all types and sub-namespaces of a namespace. + * Get all sub-namespaces of a namespace. + +A designer has to find the solution that better fulfills the constraints +and requirements of an application. In the parser case, given the +constraints we have, I think an ad-hoc database may perform better. Of +course I might be wrong, since I haven't done any tests with SQLite, but +I yet have to see a proof of the contrary. + +> +> There are many more reasons using database software instead of own data +> storage solutions - otherwise the whole database software would be +> obsolete. + +There are also many more reasons for not using databases, otherwise all +applications would be using them. + +Lluis. + + ++ + + +
On Mon, Jul 28, 2008 at 9:36 PM, Lluis Sanchez Gual <lluis at novell.com> wrote: +> El dl 28 de 07 de 2008 a les 23:44 +0200, en/na Mike Krüger va escriure: +>> Hi +>> +>> > This discussion should have been done before committing anything to +>> > trunk, but here it is anyway. +>> > +>> > Migrating to SQLite only makes sense if it provides noticeable +>> > improvements in performance and memory use. Guessing that it will be +>> > better is not enough. We need real numbers before taking the decision +>> > to +>> > switch, and only do it if the numbers are so much better that pay off +>> > the burden of having a dependency on SQLite. +>> > +>> > I might be wrong, but I don't believe that SQLite will be better than +>> > the ad-hoc database we are using in MD 1.0. I spent a lot of time +>> > tuning +>> > up the parser database, and I'm quite happy about how is it +>> > performing. +>> > +>> +>> Some more benefits for using a real database over an own implementation: +>> +>> - It's reliable. Atomic transactions, threading - all solved. +> +> Transactions and threading are not a problem for the parser database, so +> that's not a real benefit. + +Multithreaded *writes* could be useful if we're parsing on multiple +cores, but those aren't going to happen with SQLite just yet anyway... + +>> - It's easy to look into the data using a command line client and SQL +>> statements +> +> This is cool, but it has never been a requirement. + +I found this appealing :-) + +>> Its not just pure performance. Using a database will allow us for +>> example to switch the database software to a new implementation. And +>> databases and SQL are very easy to understood and to change. +>> +>> I had to think about it too (I implemented the #develop database some +>> years ago which monodevelop inherited (but optimized I admit ^^)) - +> +> That's not correct, MD's parser database was written from scratch. The +> inherited implementation would load everything in memory and would +> collapse the system trying to open the MD solution. +> +>> after thinking about it the decision was easy - A database makes it +>> easier to change the model and to make complicated querys more +>> efficient. +> +> But curiously they are especially bad at querying hierarchies of objects +> (such as namespace hierarchies or subclass hierarchies), unless you +> denormalize the tables. + +Isn't that true of an ad-hoc DB too? + +> Yes, databases are powerful. They can do amazing things with little +> effort. But generic databases don't fit everywhere. A well designed +> ad-hoc database may be better than a generic RDBMS, even if less +> powerful. Everything depends on the requirements and constraints of the +> application. For the specific case of the parser database, here are some +> requirements: +> +> * Type and namespace lookup must be lightning fast. Type and +> namespace queries are used by the parser when resolving types, +> and by code completion when showing completion entries. I don't +> think we can afford hitting the disk for that kind of queries. + +AFAIK, SQLite maintains an in-memory cache of configurable size, so as +long as the databases are properly indexed, this shouldn't be an +issue. + +> * Most of operations are read operations, so the database must be +> optimized for reading. Write operations are much less common +> than reads. + +This is true of SQLite. + +> * The data is the database is discardable. It is always possible +> to regenerate a database by re-parsing a project or an assembly. +> * Memory usage must be contained. Project and assembly databases +> may contain a huge amount of information. +> * The set of queries that it has to support is known and limited. +> Those are basically: +> * Get all types. +> * Get all types implemented in a file, given the file +> name. +> * Get all subclasses of a class, given class name. +> * Get a type, given the type name. +> * Get all types and sub-namespaces of a namespace. +> * Get all sub-namespaces of a namespace. + +I would also like to be able to extend the parser DB to store the +C/C++ symbols. This should be relatively easy with SQLite. + +It would also be nice to store the amount of times a particular item +has been selected from the code completion list, so that if there are +a number of completion entries that match the currently typed prefix, +the completion window can select the most likely one. Visual Studio +does this and it's *very* useful. Things like this would be pretty +easy to implement with SQLite. We could also maintain various other +tables and indices to accelerate things like "find references", which +would help with speeding up renaming and other such refactorings. + +> A designer has to find the solution that better fulfills the constraints +> and requirements of an application. In the parser case, given the +> constraints we have, I think an ad-hoc database may perform better. Of +> course I might be wrong, since I haven't done any tests with SQLite, but +> I yet have to see a proof of the contrary. + +This is a fair point, and we should definitely perform benchmarks +before coming to a conclusion. + +>> There are many more reasons using database software instead of own data +>> storage solutions - otherwise the whole database software would be +>> obsolete. +> +> There are also many more reasons for not using databases, otherwise all +> applications would be using them. + +The main reason I prefer SQLite would be maintainability; I found the +old parser database to be somewhat hard to understand when I was +trying to fix problems. + +However, I fully agree that if the performance tests show that the +ad-hoc database is significantly faster and/or less memory hungry, +it's probably worth the effort of maintaining it. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Hi. Just my 2 cents on this. + +Mike Krüger wrote: +> Hi +> +> +>> This discussion should have been done before committing anything to +>> trunk, but here it is anyway. +>> +>> Migrating to SQLite only makes sense if it provides noticeable +>> improvements in performance and memory use. Guessing that it will be +>> better is not enough. We need real numbers before taking the decision +>> to +>> switch, and only do it if the numbers are so much better that pay off +>> the burden of having a dependency on SQLite. +>> +>> I might be wrong, but I don't believe that SQLite will be better than +>> the ad-hoc database we are using in MD 1.0. I spent a lot of time +>> tuning +>> up the parser database, and I'm quite happy about how is it +>> performing. +>> +>> +> +> Some more benefits for using a real database over an own implementation: +> +> - It's reliable. Atomic transactions, threading - all solved. +> - It's easy to look into the data using a command line client and SQL +> statements +> +> Its not just pure performance. Using a database will allow us for +> example to switch the database software to a new implementation. And +> databases and SQL are very easy to understood and to change. +> +> I had to think about it too (I implemented the #develop database some +> years ago which monodevelop inherited (but optimized I admit ^^)) - +> after thinking about it the decision was easy - A database makes it +> easier to change the model and to make complicated querys more +> efficient. +> +> There are many more reasons using database software instead of own data +> storage solutions - otherwise the whole database software would be +> obsolete. +> + +There are a lot of reasons too why programs don't use SQL database +software. Maintainability gets hurt also by adopting such a solution in +a OOP world; I guess you have heard about the Impedance mismatch [1], +hence the existance of complicated ORM [2] frameworks or OOP databases +like DB4O [3] (which in particular could be a better bet, but I guess +the license is not adequate for MD). + +I'm also worried about the fact that your opinion about SQLite may be +biased because I guess you only used Win32 OS when you were working in +SharpDevelop, right? There has been huge performance problems (locking +problems) with SQLite in Linux, which recently caused a lot of +discussions due to its usage in Firefox (which BTW is performing for me +a lot worse than other browsers in Linux). I can't give you the exact +reference of where I read (but I can give you some first google hits +like [4] and [5]) it but AFAIK this is yet a problem to be solved +upstream (don't remember if it's in the kernel or in the extX filesystem). + +Regards, + + Andrés + +[1] http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch +[2] http://en.wikipedia.org/wiki/Object-relational_mapping +[3] http://www.db4o.com/ +[4] +http://digg.com/linux_unix/Firefox_3_has_system_killing_performance_problem_for_Linux +[5] +http://news.softpedia.com/news/Who-Freezes-The-System-Firefox-or-ext3-86242.shtml +-- + ++ + + + +
On Tue, Jul 29, 2008 at 1:09 AM, "Andrés G. Aragoneses" +<aaragoneses at novell.com> wrote: +> Hi. Just my 2 cents on this. +> +> Mike Krüger wrote: +>> Hi +>> +>> +>>> This discussion should have been done before committing anything to +>>> trunk, but here it is anyway. +>>> +>>> Migrating to SQLite only makes sense if it provides noticeable +>>> improvements in performance and memory use. Guessing that it will be +>>> better is not enough. We need real numbers before taking the decision +>>> to +>>> switch, and only do it if the numbers are so much better that pay off +>>> the burden of having a dependency on SQLite. +>>> +>>> I might be wrong, but I don't believe that SQLite will be better than +>>> the ad-hoc database we are using in MD 1.0. I spent a lot of time +>>> tuning +>>> up the parser database, and I'm quite happy about how is it +>>> performing. +>>> +>>> +>> +>> Some more benefits for using a real database over an own implementation: +>> +>> - It's reliable. Atomic transactions, threading - all solved. +>> - It's easy to look into the data using a command line client and SQL +>> statements +>> +>> Its not just pure performance. Using a database will allow us for +>> example to switch the database software to a new implementation. And +>> databases and SQL are very easy to understood and to change. +>> +>> I had to think about it too (I implemented the #develop database some +>> years ago which monodevelop inherited (but optimized I admit ^^)) - +>> after thinking about it the decision was easy - A database makes it +>> easier to change the model and to make complicated querys more +>> efficient. +>> +>> There are many more reasons using database software instead of own data +>> storage solutions - otherwise the whole database software would be +>> obsolete. +>> +> +> There are a lot of reasons too why programs don't use SQL database +> software. Maintainability gets hurt also by adopting such a solution in +> a OOP world; I guess you have heard about the Impedance mismatch [1], +> hence the existance of complicated ORM [2] frameworks or OOP databases +> like DB4O [3] (which in particular could be a better bet, but I guess +> the license is not adequate for MD). +> +> I'm also worried about the fact that your opinion about SQLite may be +> biased because I guess you only used Win32 OS when you were working in +> SharpDevelop, right? There has been huge performance problems (locking +> problems) with SQLite in Linux, which recently caused a lot of +> discussions due to its usage in Firefox (which BTW is performing for me +> a lot worse than other browsers in Linux). I can't give you the exact +> reference of where I read (but I can give you some first google hits +> like [4] and [5]) it but AFAIK this is yet a problem to be solved +> upstream (don't remember if it's in the kernel or in the extX filesystem). + +Again, I'm completely non-biased to our outcome. I do like the +completion prediction idea however. Not that its necessarily tied to +Sqlite though. + +However, note that Sqlite queries would most likely be delegated to a +single thread for thread-safety (hopefully not the gui thread), the +fsync() issue you notice in firefox would be a non-issue. It would +just mean some async callbacks from the sqlite query would take a +little longer if that level of atomic commit support is desired (which +i doubt is the case). Sqlite prides itself on being able to safely +abort a transaction at any cpu-cycle up to the last block write (which +is atomic on all the platforms it runs on). + +> Regards, +> +> Andrés +> +> [1] http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch +> [2] http://en.wikipedia.org/wiki/Object-relational_mapping +> [3] http://www.db4o.com/ +> [4] +> http://digg.com/linux_unix/Firefox_3_has_system_killing_performance_problem_for_Linux +> [5] +> http://news.softpedia.com/news/Who-Freezes-The-System-Firefox-or-ext3-86242.shtml +> -- +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + +-- Christian ++ + + + +
El dl 28 de 07 de 2008 a les 23:40 -0400, en/na Michael Hutchinson va escriure: +> On Mon, Jul 28, 2008 at 9:36 PM, Lluis Sanchez Gual <lluis at novell.com> wrote: +> > El dl 28 de 07 de 2008 a les 23:44 +0200, en/na Mike Krüger va escriure: +> >> Hi +> >> +> >> > This discussion should have been done before committing anything to +> >> > trunk, but here it is anyway. +> >> > +> >> > Migrating to SQLite only makes sense if it provides noticeable +> >> > improvements in performance and memory use. Guessing that it will be +> >> > better is not enough. We need real numbers before taking the decision +> >> > to +> >> > switch, and only do it if the numbers are so much better that pay off +> >> > the burden of having a dependency on SQLite. +> >> > +> >> > I might be wrong, but I don't believe that SQLite will be better than +> >> > the ad-hoc database we are using in MD 1.0. I spent a lot of time +> >> > tuning +> >> > up the parser database, and I'm quite happy about how is it +> >> > performing. +> >> > +> >> +> >> Some more benefits for using a real database over an own implementation: +> >> +> >> - It's reliable. Atomic transactions, threading - all solved. +> > +> > Transactions and threading are not a problem for the parser database, so +> > that's not a real benefit. +> +> Multithreaded *writes* could be useful if we're parsing on multiple +> cores, but those aren't going to happen with SQLite just yet anyway... + +It isn't a real benefit, given the low rate of writes we require. + +> +> >> - It's easy to look into the data using a command line client and SQL +> >> statements +> > +> > This is cool, but it has never been a requirement. +> +> I found this appealing :-) + +Me too, but software design can't be driven by appealingness. + +> +> >> Its not just pure performance. Using a database will allow us for +> >> example to switch the database software to a new implementation. And +> >> databases and SQL are very easy to understood and to change. +> >> +> >> I had to think about it too (I implemented the #develop database some +> >> years ago which monodevelop inherited (but optimized I admit ^^)) - +> > +> > That's not correct, MD's parser database was written from scratch. The +> > inherited implementation would load everything in memory and would +> > collapse the system trying to open the MD solution. +> > +> >> after thinking about it the decision was easy - A database makes it +> >> easier to change the model and to make complicated querys more +> >> efficient. +> > +> > But curiously they are especially bad at querying hierarchies of objects +> > (such as namespace hierarchies or subclass hierarchies), unless you +> > denormalize the tables. +> +> Isn't that true of an ad-hoc DB too? + +Not always. A hierarchy of objects can be efficiently scanned in memory +without 'denormalizing' it. + +> +> > Yes, databases are powerful. They can do amazing things with little +> > effort. But generic databases don't fit everywhere. A well designed +> > ad-hoc database may be better than a generic RDBMS, even if less +> > powerful. Everything depends on the requirements and constraints of the +> > application. For the specific case of the parser database, here are some +> > requirements: +> > +> > * Type and namespace lookup must be lightning fast. Type and +> > namespace queries are used by the parser when resolving types, +> > and by code completion when showing completion entries. I don't +> > think we can afford hitting the disk for that kind of queries. +> +> AFAIK, SQLite maintains an in-memory cache of configurable size, so as +> long as the databases are properly indexed, this shouldn't be an +> issue. + +Shouldn't, but we don't know. + +> +> > * Most of operations are read operations, so the database must be +> > optimized for reading. Write operations are much less common +> > than reads. +> +> This is true of SQLite. + +This is a design constraint to take into account to choose the right +solution. I'm not saying that this is a problem in SQLite. + +> +> > * The data is the database is discardable. It is always possible +> > to regenerate a database by re-parsing a project or an assembly. +> > * Memory usage must be contained. Project and assembly databases +> > may contain a huge amount of information. +> > * The set of queries that it has to support is known and limited. +> > Those are basically: +> > * Get all types. +> > * Get all types implemented in a file, given the file +> > name. +> > * Get all subclasses of a class, given class name. +> > * Get a type, given the type name. +> > * Get all types and sub-namespaces of a namespace. +> > * Get all sub-namespaces of a namespace. +> +> I would also like to be able to extend the parser DB to store the +> C/C++ symbols. This should be relatively easy with SQLite. +> +> It would also be nice to store the amount of times a particular item +> has been selected from the code completion list, so that if there are +> a number of completion entries that match the currently typed prefix, +> the completion window can select the most likely one. Visual Studio +> does this and it's *very* useful. Things like this would be pretty +> easy to implement with SQLite. + +And with an ad-hoc database even easier. I don't think VS needs a +relational database to implement this. + +> We could also maintain various other +> tables and indices to accelerate things like "find references", which +> would help with speeding up renaming and other such refactorings. + +Again, you don't have to convince me about how cool having all that info +in a database is. I already know it. + +> +> > A designer has to find the solution that better fulfills the constraints +> > and requirements of an application. In the parser case, given the +> > constraints we have, I think an ad-hoc database may perform better. Of +> > course I might be wrong, since I haven't done any tests with SQLite, but +> > I yet have to see a proof of the contrary. +> +> This is a fair point, and we should definitely perform benchmarks +> before coming to a conclusion. +> +> >> There are many more reasons using database software instead of own data +> >> storage solutions - otherwise the whole database software would be +> >> obsolete. +> > +> > There are also many more reasons for not using databases, otherwise all +> > applications would be using them. +> +> The main reason I prefer SQLite would be maintainability; I found the +> old parser database to be somewhat hard to understand when I was +> trying to fix problems. + +Yes, it is hard to understand because it is complex, and it is complex +because it is solving a complex problem. We should refrain the urge of +rewriting all complex software we find, since there may be a good reason +for it being complex. + +> +> However, I fully agree that if the performance tests show that the +> ad-hoc database is significantly faster and/or less memory hungry, +> it's probably worth the effort of maintaining it. + +And if tests show that SQLite is better than the ad-hoc database, I also +agree on using it. + +Lluis. + + + ++ + +
On Tue, Jul 29, 2008 at 4:09 AM, "Andrés G. Aragoneses" +<aaragoneses at novell.com> wrote: +> I'm also worried about the fact that your opinion about SQLite may be +> biased because I guess you only used Win32 OS when you were working in +> SharpDevelop, right? There has been huge performance problems (locking +> problems) with SQLite in Linux, which recently caused a lot of +> discussions due to its usage in Firefox (which BTW is performing for me +> a lot worse than other browsers in Linux). I can't give you the exact +> reference of where I read (but I can give you some first google hits +> like [4] and [5]) it but AFAIK this is yet a problem to be solved +> upstream (don't remember if it's in the kernel or in the extX filesystem). + +That's because Firefox uses SQLite in synchronous mode, which flushes +to disk (and ext3 causes ALL files on the disk to be flushed). We +wouldn't need that mode. Firefix also seems to write a huge amount of +daya to disk compared to what it needs, probably for the same reason +(excessive flushing of indices, etc) + +It'd be fairer to compare Banshee, which opens its database with: +Execute ("PRAGMA cache_size = ?", cache_size); +Execute ("PRAGMA synchronous = OFF"); +Execute ("PRAGMA temp_store = MEMORY"); +Execute ("PRAGMA count_changes = OFF"); + +(see banshee/src/Core/Banshee.Services/Banshee.Database/BansheeDbConnection.cs) + +Banshee's database has not caused any substantial problems. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Sat Jul 12 10:43:11 EDT 2008
+ Ending: Tue Jul 29 11:02:29 EDT 2008
+ Messages: 25
+
+ Last message date:
+ Tue Jul 29 11:02:29 EDT 2008
+ Archived on: Tue Jul 29 11:02:33 EDT 2008
+
+
+
Starting: Sat Jul 12 10:43:11 EDT 2008
+ Ending: Tue Jul 29 11:02:29 EDT 2008
+ Messages: 25
+
+ Last message date:
+ Tue Jul 29 11:02:29 EDT 2008
+ Archived on: Tue Jul 29 11:02:33 EDT 2008
+
+
+
Starting: Sat Jul 12 10:43:11 EDT 2008
+ Ending: Tue Jul 29 11:02:29 EDT 2008
+ Messages: 25
+
+ Last message date:
+ Tue Jul 29 11:02:29 EDT 2008
+ Archived on: Tue Jul 29 11:02:33 EDT 2008
+
+
+
Starting: Sat Jul 12 10:43:11 EDT 2008
+ Ending: Tue Jul 29 11:02:29 EDT 2008
+ Messages: 25
+
+ Last message date:
+ Tue Jul 29 11:02:29 EDT 2008
+ Archived on: Tue Jul 29 11:02:33 EDT 2008
+
+
+
Starting: Sat Jul 12 10:43:11 EDT 2008
+ Ending: Tue Jul 29 11:02:29 EDT 2008
+ Messages: 25
+
+ Last message date:
+ Tue Jul 29 11:02:29 EDT 2008
+ Archived on: Tue Jul 29 11:02:33 EDT 2008
+
+
+
Hi! + +A new mailing list for the MonoDevelop project has been created: + +http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + +This list will be used to discuss about the development of MonoDevelop, +so if you are a project contributor you should subscribe it. Questions +about the internals of MonoDevelop or development of add-ins should be +directed to that list. + +The old monodevelop list will be used from now on only for general +discussion about using MonoDevelop. + +Enjoy! +Lluis. + ++ + + +
I committed a patch to trunk, provided in +https://bugzilla.novell.com/show_bug.cgi?id=398789 . Shall I backport +the fix to the 1.9 branch? + +Regards, + + Andrés + +-- + ++ + +
Starting: Mon Jun 16 16:58:18 EDT 2008
+ Ending: Sat Jun 21 07:32:16 EDT 2008
+ Messages: 2
+
+ Last message date:
+ Sat Jun 21 07:32:16 EDT 2008
+ Archived on: Sat Jun 21 07:30:14 EDT 2008
+
+
+
Starting: Mon Jun 16 16:58:18 EDT 2008
+ Ending: Sat Jun 21 07:32:16 EDT 2008
+ Messages: 2
+
+ Last message date:
+ Sat Jun 21 07:32:16 EDT 2008
+ Archived on: Sat Jun 21 07:30:14 EDT 2008
+
+
+
Starting: Mon Jun 16 16:58:18 EDT 2008
+ Ending: Sat Jun 21 07:32:16 EDT 2008
+ Messages: 2
+
+ Last message date:
+ Sat Jun 21 07:32:16 EDT 2008
+ Archived on: Sat Jun 21 07:30:14 EDT 2008
+
+
+
Starting: Mon Jun 16 16:58:18 EDT 2008
+ Ending: Sat Jun 21 07:32:16 EDT 2008
+ Messages: 2
+
+ Last message date:
+ Sat Jun 21 07:32:16 EDT 2008
+ Archived on: Sat Jun 21 07:30:14 EDT 2008
+
+
+
Starting: Mon Jun 16 16:58:18 EDT 2008
+ Ending: Sat Jun 21 07:32:16 EDT 2008
+ Messages: 2
+
+ Last message date:
+ Sat Jun 21 07:32:16 EDT 2008
+ Archived on: Sat Jun 21 07:30:14 EDT 2008
+
+
+
Hi + +After the next release I want to improve refactoring. +Currently we only have rename as refactoring operation. Generally I want +to do refactoring a bit different than it is now. + +I want a refactoring infrastructure that allows the user to preview all +changes that are done in the refactoring step (see eclipse for an +example). + +I'll need to extend/change the current refactoring infrastructure for +this. And one of the goals for the new one is: unit test support. The +new code completion infrastructure is tested with unit tests and I think +that this has improved the code completion correctness greatly. + +Any thoughts/inputs here ? + +Regards +Mike + + ++ + + +
+1. Test-driven design is the way to go with such a complex subsystem. + +I foresee some hard spots: +1) UI-decoupling on preview/user-decision +2) Memory-consumption to keep track of all pending changes, and before/after +scenarios +3) Undoability + +Also it should be decided if all would be affected files should be loaded in +editor windows, or changes could occur behind-the-scener after user +previewing/deciding, this may bring in some synchronization issues with +other subsystems/addins like the version control one. + +About version control integration, it is not common on open source projects, +but where I work currently SVN is configured to demand locking files to be +able to commit changes on them, meaning that eclipse/vs.net keep asking me +if I want to overwrite the locally marked-as-readonly files in the middle of +refactorings, as I never try to guess and lock files prior to working on +them, and I think we should support that too. + +Just some thoughts + +Regards, + +On Wed, Nov 5, 2008 at 7:11 AM, Mike Krüger <mkrueger at novell.com> wrote: + +> Hi +> +> After the next release I want to improve refactoring. +> Currently we only have rename as refactoring operation. Generally I want +> to do refactoring a bit different than it is now. +> +> I want a refactoring infrastructure that allows the user to preview all +> changes that are done in the refactoring step (see eclipse for an +> example). +> +> I'll need to extend/change the current refactoring infrastructure for +> this. And one of the goals for the new one is: unit test support. The +> new code completion infrastructure is tested with unit tests and I think +> that this has improved the code completion correctness greatly. +> +> Any thoughts/inputs here ? +> +> Regards +> Mike +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Rafael "Monoman" Teixeira +--------------------------------------- +"I myself am made entirely of flaws, stitched together with good +intentions." +Augusten Burroughs +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081105/879d79a1/attachment.html ++ + + + +
Mike Krüger wrote: +> Hi +> +> After the next release I want to improve refactoring. +> Currently we only have rename as refactoring operation. Generally I want +> to do refactoring a bit different than it is now. +> +> I want a refactoring infrastructure that allows the user to preview all +> changes that are done in the refactoring step (see eclipse for an +> example). +> +> I'll need to extend/change the current refactoring infrastructure for +> this. And one of the goals for the new one is: unit test support. The +> new code completion infrastructure is tested with unit tests and I think +> that this has improved the code completion correctness greatly. +> +> Any thoughts/inputs here ? +> + +When you say next release, are talking about a 2.0 Alpha or 2.0 final? +If you mean final, perfect. If not, IMHO I would dedicate more time to +fix more basic use cases for refactoring features. I don't know if there +are still bugs open on bugzilla, but with a brief look I see many +regressions: go to declaration not shown in many cases, looking for +references takes a lot of time, etc.. +I will see if I can report some of those, although it's difficult to +isolate them. + + Andrés + +-- + + ++ + + + + +
On Wed, Nov 5, 2008 at 5:11 AM, Mike Krüger <mkrueger at novell.com> wrote: +> Hi +> +> After the next release I want to improve refactoring. +> Currently we only have rename as refactoring operation. Generally I want +> to do refactoring a bit different than it is now. +> +> I want a refactoring infrastructure that allows the user to preview all +> changes that are done in the refactoring step (see eclipse for an +> example). + +DevExpress Refactor Pro has some nice previews within the editor, with +arrows and highlighting and stuff. + +> I'll need to extend/change the current refactoring infrastructure for +> this. And one of the goals for the new one is: unit test support. The +> new code completion infrastructure is tested with unit tests and I think +> that this has improved the code completion correctness greatly. +> +> Any thoughts/inputs here ? + +I'm interested in a few different things: + +* Cross-project/language aspects of refactoring. For example, if an +identifier is renamed in a C# project, it may need to be renamed in a +dependent VB project or in ASP.NET or XAML files. Unit testing of +these will be an interesting challenge... + +* Non-.NET refactoring hooks -- it should be possible to use some of +the infrastructure (at least) for C/C++ or Python refactoring, for +example. + +* Extensibility -- how easy will it be to build more "complex" +refactorings? It would be interesting to catalogue all the +refactorings provided by popular IDEs and Addins (VS, Eclipse, +Resharper, DevExpress Refactor Pro etc) and try to break them up into +more primitive operations, so that languages can get the high-level +operations for free by implementing only the low-level operations. I +know we have something like this already, but I think it'd be good to +re-evaluate the primitives in light of all of the high-level +operations we might want to implement. + +* Indexing -- for renaming operations (and "find all references") our +performance is currently dire. It might be worth having an index to +make these faster. + +I don't have any ideas right now on how these should be done, but I +think it's important to take them into consideration :-) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + +
On Sun, Oct 26, 2008 at 8:00 PM, Justin Weber <embed68k at dejazzd.com> wrote: +> +> I've been trying like hell to get GTK# 2.0 to show under the C# heading under +> new solution. I downloaded and installed Xcode from apple.com. I go into the +> add-in manager in monodevelop and it complains about not being able to find +> gtkcore 1.9.0 in the go-mono repository. I've tried every thing I could +> think of and searched forever to do this, but still I can't succeed. I've +> also tried getting a c# heading to appear in Xcode and followed the +> tutorials for moving the csharp plugin file, that doesn't work either. This +> is apple, it's not supposed to be this hard. Is it?? + +The GTK# addin isn't included in the Mac builds, because drag-n-drop +issues in the Mac GTK prevent our GTK# designer from working on Mac. +Unfortunately the GTK# templates are in the same addin as the +designer. However, handwritten GTK# code should still work -- MD +itself uses GTK#. + +BTW, monodevelop-devel-list is for discussing the code/development of +MonoDevelop. For other discussions, including bugs and support, please +use monodevelop-list. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + + + + + + + +
Hi all, + +Background: Until a few days ago, the ASP.NET project type in MD +assumed that ASP.NET projects always had a CompileTarget value of +"Library". This has led to all ASP.NET projects files being created +with the default "Executable" target, since MD essentially ignored +this properly, so I did not think to set it correctly. Unfortunately +Visual Studio (MSBuild) *does* respect this properly from the project +file, even though it gives the user no UI with which to change it. +Building MD projects with VS (or MSBuild) hence hits a compile error +when it can't find the Main entry point method. If this method's +added, the build succeeds, but the project doesn't fun, since ASP.NET +apparently ignores exe files. + +Here's the dilemma: MD needs to fix the incorrect value it's been +using in order to make existing projects compatible with VS and +MSBuild. However, I'm not comfortable doing automagic, unavoidable and +potentially unwanted changes (even if right now I can't think of any +ready why anyone would want to build an exe). Which of the following +should I do? + +1) Make the change automatically +2) Ask the user if they want to make the change (if they don't, it'll +ask every time they open the project) +3) Add a warning to the build process, and + a) Don't do anything, let users fix it themselves in the project file + b) Re-enable the CompileTarget-changing UI when the CompileTarget +is incorrect + +My preference is 3b. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + + + + + + + +
On Wed, Nov 5, 2008 at 8:20 PM, Michael Hutchinson <m.j.hutchinson at gmail.com +> wrote: + +> +> 1) Make the change automatically +> 2) Ask the user if they want to make the change (if they don't, it'll +> ask every time they open the project) +> 3) Add a warning to the build process, and +> a) Don't do anything, let users fix it themselves in the project file +> b) Re-enable the CompileTarget-changing UI when the CompileTarget +> is incorrect + + +Or + +4) Don't worry about it. + +I think #1 is probably right. Since there's no point in building an +asp.netexe with a Main method, just do the update. + +I suppose you could refine the logic and only update if its an exe AND a +Main has not been specified. That's the only other defensible +configuration, right, even though it sounds like it's an exercise in +silliness from an asp.net standpoint. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081105/2b60d686/attachment.html ++ + + + + + + + + + + + +
Hi + +> When you say next release, are talking about a 2.0 Alpha or 2.0 final? + +We're not going to integrate something brand new before 2.0 final - only +bugfixes and "minor" enhancements. I have even delayed some small +features (like auto saving) for after 2.0 release. + +I've broken enough during the 1.0 -> 2.0 development :) + +Regards +Mike + ++ + + +
Hi + +> * Cross-project/language aspects of refactoring. For example, if an +> identifier is renamed in a C# project, it may need to be renamed in a +> dependent VB project or in ASP.NET or XAML files. Unit testing of +> these will be an interesting challenge... +> + +Simple solution: If the project has no parser for all files in a project +either warn the user or don't allow it. Currently we destroy code - +that's not a good solution. Btw. for this I wan't previews - then the +developer can have a clear picture on what's going on with the source +code. + +> * Extensibility -- how easy will it be to build more "complex" +> refactorings? It would be interesting to catalogue all the +> refactorings provided by popular IDEs and Addins (VS, Eclipse, +> Resharper, DevExpress Refactor Pro etc) and try to break them up into +> more primitive operations, so that languages can get the high-level +> operations for free by implementing only the low-level operations. I +> know we have something like this already, but I think it'd be good to +> re-evaluate the primitives in light of all of the high-level +> operations we might want to implement. + +Just get a copy of "Refactoring: Improving the Design of Existing Code" +from Martin Fowler :). I'm still sleeping with it under my pillow. + +> * Indexing -- for renaming operations (and "find all references") our +> performance is currently dire. It might be worth having an index to +> make these faster. +> + +Yes the performance is worse, but currently it's mostly because of +something I would call "issue with the infrastructure" - we can do it +much more faster. But currently I don't want extensive changes here. + +> I don't have any ideas right now on how these should be done, but I +> think it's important to take them into consideration :-) +> +I'm pretty sure I would've missed Cross project/language aspects :-). + + +Regards +Mike + ++ + + + +
Hi + +> 1) UI-decoupling on preview/user-decision + +Modal dialog for refactorings ? + +> 2) Memory-consumption to keep track of all pending changes, and +> before/after scenarios + +If we only keep the deltas I don't see a problem. When we keep the parse +tree of the whole solution we may have one. (At least we would waste +some memory) + +> 3) Undoability +> +Ok. This one is really hard especially the undo handling is not done ide +wide instead it's coupled with the views to handle undo/redo. We may +need to change if we want undoable refactorings. + +> Also it should be decided if all would be affected files should be +> loaded in editor windows, or changes could occur behind-the-scener +> after user previewing/deciding, this may bring in some synchronization +> issues with other subsystems/addins like the version control one. +> +No I don't want editor windows there. I want a refactoring dialog that +shows the refactorings in an understandable way - but I wan't to use an +"editor window" to show the refactoring changes. + +> About version control integration, it is not common on open source +> projects, but where I work currently SVN is configured to demand +> locking files to be able to commit changes on them, meaning that +> eclipse/vs.net keep asking me if I want to overwrite the locally +> marked-as-readonly files in the middle of refactorings, as I never try +> to guess and lock files prior to working on them, and I think we +> should support that too. + +That's a good feature. I noted it. + +Thanks +Mike + ++ + +
El dc 05 de 11 de 2008 a les 21:11 -0600, en/na Mike Kestner va +escriure: +> +> On Wed, Nov 5, 2008 at 8:20 PM, Michael Hutchinson +> <m.j.hutchinson at gmail.com> wrote: +> +> 1) Make the change automatically +> 2) Ask the user if they want to make the change (if they +> don't, it'll +> ask every time they open the project) +> 3) Add a warning to the build process, and +> a) Don't do anything, let users fix it themselves in the +> project file +> b) Re-enable the CompileTarget-changing UI when the +> CompileTarget +> is incorrect +> +> Or +> +> 4) Don't worry about it. +> +> I think #1 is probably right. Since there's no point in building an +> asp.net exe with a Main method, just do the update. +> +> I suppose you could refine the logic and only update if its an exe AND +> a Main has not been specified. That's the only other defensible +> configuration, right, even though it sounds like it's an exercise in +> silliness from an asp.net standpoint. + +I pretty much agree. I think #1 is ok. + +Lluis. + +> + ++ + + + + + + + + +
El dc 05 de 11 de 2008 a les 11:11 +0100, en/na Mike Krüger va escriure: +> Hi +> +> After the next release I want to improve refactoring. +> Currently we only have rename as refactoring operation. Generally I want +> to do refactoring a bit different than it is now. +> +> I want a refactoring infrastructure that allows the user to preview all +> changes that are done in the refactoring step (see eclipse for an +> example). + +Notice that change previewing for the rename operation can be done with +the current infrastructure. It's a matter of finding the references, +displaying them and do the replace when the user clicks on OK. The API +supports that, although we haven't implemented the GUI. + +> +> I'll need to extend/change the current refactoring infrastructure for +> this. And one of the goals for the new one is: unit test support. The +> new code completion infrastructure is tested with unit tests and I think +> that this has improved the code completion correctness greatly. +> +> Any thoughts/inputs here ? + +I'd like to see a high level design of the API to get an idea of how you +plan to improve the refactoring infrastructure. + +Thanks! +Lluis. + + ++ + + +
Hi + +> Notice that change previewing for the rename operation can be done with +> the current infrastructure. It's a matter of finding the references, +> displaying them and do the replace when the user clicks on OK. The API +> supports that, although we haven't implemented the GUI. +> + +No not really. It's a hack. There is an operation called: + +IMember RenameMember (RefactorerContext ctx, + IType cls, + IMember member, + string newName); + +And that's it. Ok you've: +MemberReferenceCollection FindMemberReferences (RefactorerContext ctx, +string fileName, IType cls, IMember member); + +> > +> > I'll need to extend/change the current refactoring infrastructure for +> > this. And one of the goals for the new one is: unit test support. The +> > new code completion infrastructure is tested with unit tests and I think +> > that this has improved the code completion correctness greatly. +> > +> > Any thoughts/inputs here ? +> +> I'd like to see a high level design of the API to get an idea of how you +> plan to improve the refactoring infrastructure. +> +> Thanks! +> Lluis. +> +> + ++ + + +
Hi
+
+> Notice that change previewing for the rename operation can be done
+with
+> the current infrastructure. It's a matter of finding the references,
+> displaying them and do the replace when the user clicks on OK. The API
+> supports that, although we haven't implemented the GUI.
+>
+
+No not really. It's a hack. There is an operation called:
+
+IMember RenameMember (RefactorerContext ctx,
+ IType cls,
+ IMember member,
+ string newName);
+
+And that's it. Ok you've:
+
+MemberReferenceCollection FindMemberReferences (RefactorerContext ctx,
+string fileName,
+IType cls,
+IMember member);
+MemberReferenceCollection FindVariableReferences (RefactorerContext ctx,
+string fileName, LocalVariable var);
+MemberReferenceCollection FindParameterReferences (RefactorerContext
+ctx, string fileName, IParameter param);
+
+And with these three methods you can hack something together for this
+one refactoring case - but that's it. Thisis not really what I've in
+mind to do.
+
+> >
+> > I'll need to extend/change the current refactoring infrastructure
+for
+> > this. And one of the goals for the new one is: unit test support.
+The
+> > new code completion infrastructure is tested with unit tests and I
+think
+> > that this has improved the code completion correctness greatly.
+> >
+> > Any thoughts/inputs here ?
+>
+> I'd like to see a high level design of the API to get an idea of how
+you
+> plan to improve the refactoring infrastructure.
+>
+
+Currently:
+
+Anything seems to be called "refactorer" (Even classes that don't
+implement IRefactorer) to make it more stangely we've a refactorer
+called CodeGenerator (inheriting from BaseRefactorer). It looks like
+thats currently anything is hacked together.
+It starts with clicking on something in the editor window there is a
+class that builds the context menu and this class controls which
+operations are valid.
+
+I want:
+
+Split up refactoring a bit to make it clear what each class does.
+
+I intend to split up the "refactoring" feature. Each refactoring
+operation should be an own class that knows it's responsibilities (based
+on the resolve result) it knows when it's valid to display in the
+refactoring context menu.
+
+Then we would've classes like:
+
+Rename
+ImplicitImplementInterface
+ExplicitImplementInterface
+ExtractMethod
+
+etc.
+
+These refactorings should be placed in the addin tree.
+
+We've a RefactorerContext - that's good these context should be
+containing the find functions and some helper functions that are
+currently splitted up between IRefactorer and CodeRefactorer).
+
+Then we need a CodeGenerator - this is a class that actually builds
+code. Not by changing it, it should produce "diffs".
+
+Then we need something like a result of the refactoring operations.
+That'll give us a list of files with diffs as well as a list of the
+class tree with changes. I intend to have a dialog that looks like:
+
+-----------------
+
+ Positions
+
+
+-----------------
+
+
+Diffs
+
+
+-----------------
+
+That's what I intend to:
+
+class RefactoringResult {
+ List<Change> Changes;
+}
+
+class Change {
+ string fileName;
+ IMember memberLocation;
+
+ DomLocation position;
+
+ string old;
+ string new;
+}
+
+
+Something like this an 'positions' should be switchable between class
+view and file view (like the pads).
+
+The Refactoring should something look like:
+
+IRefactoring {
+ bool IsSupported (ResolveResult result);
+ string GetDisplaySting (ResolveResult result);
+
+ void Run ();
+}
+
+IResultRefactoring : IRefactoring {
+ RefactoringResult DoOperation (RefactorerContext, ResolveResult
+result);
+}
+
+I want to support maybe more than one type of refactoring, therefore
+just the "run" method. And there are more types than just the diff
+refactoring - implement/override members for example therefore not all
+refactorings require the position/diff dialogs.
+Another example could be renaming a local variable or parameter which
+could be displayed inline in the text editor instead of having pop up
+dialogs. (Ok I admit I've worked a bit with eclipse this week :) )
+
+To decide: On which infrastructure we'll build. Currently it's a bit
+mixed up between CodeDOM and NRefactory. I would've chosen NRefactory
+because we're already building on this and an own AST gives more control
+than a pre defined one.
+
+Regards
+Mike
+
+
+
+
+
+ El dv 07 de 11 de 2008 a les 09:31 +0100, en/na Mike Krüger va escriure:
+> Hi
+>
+> > Notice that change previewing for the rename operation can be done
+> with
+> > the current infrastructure. It's a matter of finding the references,
+> > displaying them and do the replace when the user clicks on OK. The API
+> > supports that, although we haven't implemented the GUI.
+> >
+>
+> No not really. It's a hack. There is an operation called:
+>
+> IMember RenameMember (RefactorerContext ctx,
+> IType cls,
+> IMember member,
+> string newName);
+>
+> And that's it. Ok you've:
+>
+> MemberReferenceCollection FindMemberReferences (RefactorerContext ctx,
+> string fileName,
+> IType cls,
+> IMember member);
+> MemberReferenceCollection FindVariableReferences (RefactorerContext ctx,
+> string fileName, LocalVariable var);
+> MemberReferenceCollection FindParameterReferences (RefactorerContext
+> ctx, string fileName, IParameter param);
+>
+> And with these three methods you can hack something together for this
+> one refactoring case - but that's it. Thisis not really what I've in
+> mind to do.
+>
+> > >
+> > > I'll need to extend/change the current refactoring infrastructure
+> for
+> > > this. And one of the goals for the new one is: unit test support.
+> The
+> > > new code completion infrastructure is tested with unit tests and I
+> think
+> > > that this has improved the code completion correctness greatly.
+> > >
+> > > Any thoughts/inputs here ?
+> >
+> > I'd like to see a high level design of the API to get an idea of how
+> you
+> > plan to improve the refactoring infrastructure.
+> >
+>
+> Currently:
+>
+> Anything seems to be called "refactorer" (Even classes that don't
+> implement IRefactorer) to make it more stangely we've a refactorer
+> called CodeGenerator (inheriting from BaseRefactorer). It looks like
+> thats currently anything is hacked together.
+
+Before trying to rewrite any piece of code you should at least study the
+current code and try to understand how it works, what are the
+responsibilities of each class, and why it was designed in that way.
+Only then you'll be qualified to say what's wrong and propose a better
+solution. The use of words like "strangely", "hack" and "looks like"
+clearly show that you didn't follow this step.
+
+I'm not saying that the current refactoring infrastructure is perfect.
+It is not. Much of it will probably have to be changed if we want to
+support more advanced refactoring operations. But you can't arbitrarily
+drop all current code, ignoring what has been done. We already had some
+bad experiences in MD because of this.
+
+> It starts with clicking on something in the editor window there is a
+> class that builds the context menu and this class controls which
+> operations are valid.
+>
+> I want:
+>
+> Split up refactoring a bit to make it clear what each class does.
+>
+> I intend to split up the "refactoring" feature. Each refactoring
+> operation should be an own class that knows it's responsibilities (based
+> on the resolve result) it knows when it's valid to display in the
+> refactoring context menu.
+>
+> Then we would've classes like:
+>
+> Rename
+> ImplicitImplementInterface
+> ExplicitImplementInterface
+> ExtractMethod
+>
+> etc.
+>
+> These refactorings should be placed in the addin tree.
+
+Will those refactoring classes be language-specific?
+For example, the Rename class, there will be a RenameCSharp and a
+RenameVisualBasic? if that's the case, will they share some code?
+
+>
+> We've a RefactorerContext - that's good these context should be
+> containing the find functions and some helper functions that are
+> currently splitted up between IRefactorer and CodeRefactorer).
+>
+> Then we need a CodeGenerator - this is a class that actually builds
+> code. Not by changing it, it should produce "diffs".
+
+Some add-ins need to perform basic code manipulation operation such as
+inserting a new method to a class or adding custom attributes to class
+declarations. Which class would provide those operations?
+
+I'd like to see how the high level API will look like. That is, the API
+that will allow starting refactoring operations or manipulate code.
+
+>
+> Then we need something like a result of the refactoring operations.
+> That'll give us a list of files with diffs as well as a list of the
+> class tree with changes. I intend to have a dialog that looks like:
+>
+> -----------------
+>
+> Positions
+>
+>
+> -----------------
+>
+>
+> Diffs
+>
+>
+> -----------------
+>
+> That's what I intend to:
+>
+> class RefactoringResult {
+> List<Change> Changes;
+> }
+>
+> class Change {
+> string fileName;
+> IMember memberLocation;
+>
+> DomLocation position;
+>
+> string old;
+> string new;
+> }
+>
+>
+> Something like this an 'positions' should be switchable between class
+> view and file view (like the pads).
+>
+> The Refactoring should something look like:
+>
+> IRefactoring {
+> bool IsSupported (ResolveResult result);
+> string GetDisplaySting (ResolveResult result);
+>
+> void Run ();
+> }
+>
+> IResultRefactoring : IRefactoring {
+> RefactoringResult DoOperation (RefactorerContext, ResolveResult
+> result);
+> }
+>
+> I want to support maybe more than one type of refactoring, therefore
+> just the "run" method. And there are more types than just the diff
+> refactoring - implement/override members for example therefore not all
+> refactorings require the position/diff dialogs.
+
+Can you provide a list of all refactorings you plan to implement and
+what are the requirements of each of them?
+
+> Another example could be renaming a local variable or parameter which
+> could be displayed inline in the text editor instead of having pop up
+> dialogs. (Ok I admit I've worked a bit with eclipse this week :) )
+>
+> To decide: On which infrastructure we'll build. Currently it's a bit
+> mixed up between CodeDOM and NRefactory. I would've chosen NRefactory
+> because we're already building on this and an own AST gives more control
+> than a pre defined one.
+>
+> Regards
+> Mike
+>
+
+
+
+
+
+ Hi + +> I'm not saying that the current refactoring infrastructure is perfect. +> It is not. Much of it will probably have to be changed if we want to +> support more advanced refactoring operations. But you can't arbitrarily +> drop all current code, ignoring what has been done. We already had some +> bad experiences in MD because of this. +> + +I don't want to drop code. In fact the current one is a good starting +point. There is no need to 'drop' code - I only drop code when there is +no other option. We can use refactoring methods move/rename some stuff - +that's it. I would only drop code if it's GPL or really very different +to refactor the code. +The code we currently have is something I can work with. + +Something different: But over time we must rewrite ALL GPL code. I think +that's still on our todo list isn't it ? +Refactoring is about improving the design of existing code, not to +rewrite it. In this way it's possible to keep all "information" in the +existing code. With a rewrite you'll loose all knowledge that lead to +the existing code. If possible refactoring is always better. +(But keep in mind that all GPL parts need to be rewritten, except we +change our position here) + +> > It starts with clicking on something in the editor window there is a +> > class that builds the context menu and this class controls which +> > operations are valid. +> > +> > I want: +> > +> > Split up refactoring a bit to make it clear what each class does. +> > +> > I intend to split up the "refactoring" feature. Each refactoring +> > operation should be an own class that knows it's responsibilities (based +> > on the resolve result) it knows when it's valid to display in the +> > refactoring context menu. +> > +> > Then we would've classes like: +> > +> > Rename +> > ImplicitImplementInterface +> > ExplicitImplementInterface +> > ExtractMethod +> > +> > etc. +> > +> > These refactorings should be placed in the addin tree. +> +> Will those refactoring classes be language-specific? +> For example, the Rename class, there will be a RenameCSharp and a +> RenameVisualBasic? if that's the case, will they share some code? +> + +Thats in the responsibility of the classes they can support csharp and +visualbasic, but I don't think that I'll support more than these two, I +think I personally will stick to C#. Like with the code completion +infrastructure in the csharp binding. It would be possible to use it for +VB.NET and any other language that can produce NRefactory DOM. + +When I'm really satisfied with refactoring and the capabilities of +monodevelop (especially text editor and search features) I'll maybe +improve visual basic support or bring any other language backend up to +the C# level. But I don't know if we'll ever reach this point - there is +always more stuff to do and I'm a C# fan :). + +Cross language functionality for refactorings is something we need to +factor in but my current 'plan' would be to disallow cross language +refactorings until all refactoring commands are availble for any +languages in the solution - not to allow partial refactorings. + +Regards +Mike + ++ + + +
El dl 10 de 11 de 2008 a les 08:53 +0100, en/na Mike Krüger va escriure: +> Hi +> +> > I'm not saying that the current refactoring infrastructure is perfect. +> > It is not. Much of it will probably have to be changed if we want to +> > support more advanced refactoring operations. But you can't arbitrarily +> > drop all current code, ignoring what has been done. We already had some +> > bad experiences in MD because of this. +> > +> +> I don't want to drop code. In fact the current one is a good starting +> point. There is no need to 'drop' code - I only drop code when there is +> no other option. We can use refactoring methods move/rename some stuff - +> that's it. I would only drop code if it's GPL or really very different +> to refactor the code. +> The code we currently have is something I can work with. +> +> Something different: But over time we must rewrite ALL GPL code. I think +> that's still on our todo list isn't it ? + +Yes, but it is not a priority right now. + +> Refactoring is about improving the design of existing code, not to +> rewrite it. In this way it's possible to keep all "information" in the +> existing code. With a rewrite you'll loose all knowledge that lead to +> the existing code. If possible refactoring is always better. +> (But keep in mind that all GPL parts need to be rewritten, except we +> change our position here) +> +> > > It starts with clicking on something in the editor window there is a +> > > class that builds the context menu and this class controls which +> > > operations are valid. +> > > +> > > I want: +> > > +> > > Split up refactoring a bit to make it clear what each class does. +> > > +> > > I intend to split up the "refactoring" feature. Each refactoring +> > > operation should be an own class that knows it's responsibilities (based +> > > on the resolve result) it knows when it's valid to display in the +> > > refactoring context menu. +> > > +> > > Then we would've classes like: +> > > +> > > Rename +> > > ImplicitImplementInterface +> > > ExplicitImplementInterface +> > > ExtractMethod +> > > +> > > etc. +> > > +> > > These refactorings should be placed in the addin tree. +> > +> > Will those refactoring classes be language-specific? +> > For example, the Rename class, there will be a RenameCSharp and a +> > RenameVisualBasic? if that's the case, will they share some code? +> > +> +> Thats in the responsibility of the classes they can support csharp and +> visualbasic, but I don't think that I'll support more than these two, I +> think I personally will stick to C#. Like with the code completion +> infrastructure in the csharp binding. It would be possible to use it for +> VB.NET and any other language that can produce NRefactory DOM. + +Maybe the core MD team won't be able to provide support for languages +other than C#, but maybe somebody else wants to contribute it. + +> +> When I'm really satisfied with refactoring and the capabilities of +> monodevelop (especially text editor and search features) I'll maybe +> improve visual basic support or bring any other language backend up to +> the C# level. But I don't know if we'll ever reach this point - there is +> always more stuff to do and I'm a C# fan :). +> +> Cross language functionality for refactorings is something we need to +> factor in but my current 'plan' would be to disallow cross language +> refactorings until all refactoring commands are availble for any +> languages in the solution - not to allow partial refactorings. + +In some cases, a warning will be enough. For example, the user should be +able to run Find References, but the results list could include a +warning saying that project XXX could not be searched. + +Even Rename Member should be allowed IMO. In the preview window it would +show a warning about a projects whose languages does not support +renaming, but it should allow renaming in those that support it. + +Lluis. + + ++ + +
Hello everybody, +I'm trying to compile MD from trunk under Debian and got next trouble: + +$ cd monodevelop +$ ./configure --prefix=/usr/local +checking for MONO_ADDINS... configure: error: Package requirements +(mono-addins >= 0.3) were not met: +No package 'mono-addins' found + +$ svn co svn://anonsvn.mono-project.com/source/trunk/mono-addins +$ cd mono-addins +$ ./autogen.sh --prefix=/usr/ +checking for GTK_SHARP_20... configure: error: Package requirements +(gtk-sharp-2.0) were not met: +No package 'gtk-sharp-2.0' found + +$ svn co svn://anonsvn.mono-project.com/source/trunk/gtk-sharp +$ cd gtk-sharp +$ ./autogen.sh --prefix=/usr/ +**Error**: autogen.sh has been replaced by bootstrap for the 2.5.x release. +To bootstrap a 1.9.x build run bootstrap-2.4. +$ ./bootstrap-2.12 +checking for PANGO... configure: error: Package requirements (pango) were +not met: +No package 'pango' found + +Here is my trouble! Whare can I take the pango package? +$ sudo apt-get install pango +E: Couldn't find package pango + +I have installed libpango1.0.-0 and libpango1.0-common but it doesn't helps. +What I have to install more? Maybe libpango1.0-dev? +Assist me please! + +=== +Best regards, +Alexander M. Batishchev + + + ++ + + +
El dl 17 de 11 de 2008 a les 17:50 +0300, en/na Alexander M. Batishchev +va escriure: +> Hello everybody, +> I'm trying to compile MD from trunk under Debian and got next trouble: +> +> $ cd monodevelop +> $ ./configure --prefix=/usr/local +> checking for MONO_ADDINS... configure: error: Package requirements +> (mono-addins >= 0.3) were not met: +> No package 'mono-addins' found +> +> $ svn co svn://anonsvn.mono-project.com/source/trunk/mono-addins +> $ cd mono-addins +> $ ./autogen.sh --prefix=/usr/ +> checking for GTK_SHARP_20... configure: error: Package requirements +> (gtk-sharp-2.0) were not met: +> No package 'gtk-sharp-2.0' found +> +> $ svn co svn://anonsvn.mono-project.com/source/trunk/gtk-sharp +> $ cd gtk-sharp +> $ ./autogen.sh --prefix=/usr/ +> **Error**: autogen.sh has been replaced by bootstrap for the 2.5.x release. +> To bootstrap a 1.9.x build run bootstrap-2.4. +> $ ./bootstrap-2.12 +> checking for PANGO... configure: error: Package requirements (pango) were +> not met: +> No package 'pango' found +> +> Here is my trouble! Whare can I take the pango package? +> $ sudo apt-get install pango +> E: Couldn't find package pango +> +> I have installed libpango1.0.-0 and libpango1.0-common but it doesn't helps. +> What I have to install more? Maybe libpango1.0-dev? + +Yes, libpango1.0-dev. + +> Assist me please! +> +> === +> Best regards, +> Alexander M. Batishchev +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + +
Hi Lluis, thanks for answer your answer! Could you please me assist me a little bit more? +MonoDevelop also requires glade-sharp witch compilation occurs an error: +checking for GLADEUI... configure: error: Package requirements (libgladeui-1.0 >= 2.90.0) were not met: +No package 'libgladeui-1.0' found +My Debian package manager has only libgladeui-1.7 and libgladeui-1-dev (version 3.4.5-3 both). Both are installed. +Why does it not met requirements? + +-----Original Message----- +From: Lluis Sanchez Gual [mailto:lluis at novell.com] +Sent: Monday, November 17, 2008 6:14 PM +To: Alexander M. Batishchev +Cc: monodevelop-devel-list at lists.ximian.com +Subject: Re: [Monodevelop-devel] Comipiling Monodevelop under Debian from trunk + +El dl 17 de 11 de 2008 a les 17:50 +0300, en/na Alexander M. Batishchev +va escriure: +> Hello everybody, +> I'm trying to compile MD from trunk under Debian and got next trouble: +> +> $ cd monodevelop +> $ ./configure --prefix=/usr/local +> checking for MONO_ADDINS... configure: error: Package requirements +> (mono-addins >= 0.3) were not met: +> No package 'mono-addins' found +> +> $ svn co svn://anonsvn.mono-project.com/source/trunk/mono-addins +> $ cd mono-addins +> $ ./autogen.sh --prefix=/usr/ +> checking for GTK_SHARP_20... configure: error: Package requirements +> (gtk-sharp-2.0) were not met: +> No package 'gtk-sharp-2.0' found +> +> $ svn co svn://anonsvn.mono-project.com/source/trunk/gtk-sharp +> $ cd gtk-sharp +> $ ./autogen.sh --prefix=/usr/ +> **Error**: autogen.sh has been replaced by bootstrap for the 2.5.x release. +> To bootstrap a 1.9.x build run bootstrap-2.4. +> $ ./bootstrap-2.12 +> checking for PANGO... configure: error: Package requirements (pango) were +> not met: +> No package 'pango' found +> +> Here is my trouble! Whare can I take the pango package? +> $ sudo apt-get install pango +> E: Couldn't find package pango +> +> I have installed libpango1.0.-0 and libpango1.0-common but it doesn't helps. +> What I have to install more? Maybe libpango1.0-dev? + +Yes, libpango1.0-dev. + +> Assist me please! +> +> === +> Best regards, +> Alexander M. Batishchev +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + + ++ + + +
Hi! + +I've discussed with Mike (Kestner) a couple of times about the need for +proper dependency checks between the MD makefiles. That is, a change in +one of the MD projects would cause all dependent projects to be +rebuilt. + +I'm reluctant to do this change because any small change (even if not +breaking change) in one of the core MD assemblies would cause the +rebuild of all the 50 assemblies of MD, and that would be really +annoying for those who work daily on those assemblies. + +However Mike is right in that with proper dependency checking the +makefiles would be more correct and would avoid weird build errors when +there are changes in the api. + +So I'd like to know what you think about this. I suggested making this +project dependency optional, although I don't know how hard it would be. + +Thoughts? +Lluis. + + ++ + + +
On Mon, Nov 17, 2008 at 6:30 PM, Lluis Sanchez Gual <lluis at novell.com> wrote: +> Hi! +> +> I've discussed with Mike (Kestner) a couple of times about the need for +> proper dependency checks between the MD makefiles. That is, a change in +> one of the MD projects would cause all dependent projects to be +> rebuilt. +> +> I'm reluctant to do this change because any small change (even if not +> breaking change) in one of the core MD assemblies would cause the +> rebuild of all the 50 assemblies of MD, and that would be really +> annoying for those who work daily on those assemblies. + +Actually, a full build is surprisingly fast these days. Also, you can +work around this problem by cd'ing into the directory of the changed +addin before issuing the "make" command. + +> However Mike is right in that with proper dependency checking the +> makefiles would be more correct and would avoid weird build errors when +> there are changes in the api. + +I think this would be a really good idea, as we've had a number of +breakages resulting from the lack of proper dependencies. I've +actually added dependencies to a couple of addins already. + +> So I'd like to know what you think about this. I suggested making this +> project dependency optional, although I don't know how hard it would be. + +I don't think it's necessary. Maybe we could make it more convenient +by having make targets corresponding to the core areas e.g. make +md-project-gui would execute make in +main/src/core/MonoDevelop.Project.Gui. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Mon, 2008-11-17 at 20:19 -0500, Michael Hutchinson wrote: + +> > However Mike is right in that with proper dependency checking the +> > makefiles would be more correct and would avoid weird build errors when +> > there are changes in the api. +> +> I think this would be a really good idea, as we've had a number of +> breakages resulting from the lack of proper dependencies. I've +> actually added dependencies to a couple of addins already. + +There's potentially a larger issue, in that the MD makefiles are +synchronized by MD itself, so the functionality which does this sync +apparently does not currently support robust dependency checking for its +output. Regardless of whether the MD project wants to have robust +dependency checking for project references, I suspect many of our users +will want it. + +> > So I'd like to know what you think about this. I suggested making this +> > project dependency optional, although I don't know how hard it would be. +> +> I don't think it's necessary. Maybe we could make it more convenient +> by having make targets corresponding to the core areas e.g. make +> md-project-gui would execute make in +> main/src/core/MonoDevelop.Project.Gui. + +If the feature is optional, I think it should probably be on by default, +because most people will expect a change in a project to rebuild +projects which depend on it. + +-- +Mike Kestner <mkestner at gmail.com> + ++ + + + +
> I've discussed with Mike (Kestner) a couple of times about the need for +> proper dependency checks between the MD makefiles. That is, a change in +> one of the MD projects would cause all dependent projects to be +> rebuilt. + +This would be a Good Thing. + +> I'm reluctant to do this change because any small change (even if not +> breaking change) in one of the core MD assemblies would cause the +> rebuild of all the 50 assemblies of MD, and that would be really +> annoying for those who work daily on those assemblies. + +I agree with Michael H. that this isn't really a big deal. + + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + + + + +
El dl 17 de 11 de 2008 a les 20:37 -0600, en/na Mike Kestner va +escriure: +> On Mon, 2008-11-17 at 20:19 -0500, Michael Hutchinson wrote: +> +> > > However Mike is right in that with proper dependency checking the +> > > makefiles would be more correct and would avoid weird build errors when +> > > there are changes in the api. +> > +> > I think this would be a really good idea, as we've had a number of +> > breakages resulting from the lack of proper dependencies. I've +> > actually added dependencies to a couple of addins already. +> +> There's potentially a larger issue, in that the MD makefiles are +> synchronized by MD itself, so the functionality which does this sync +> apparently does not currently support robust dependency checking for its +> output. Regardless of whether the MD project wants to have robust +> dependency checking for project references, I suspect many of our users +> will want it. + +No, that's unrelated. Makefile synchronization just keeps in sync lists +of files and references, but it does not decide what to do with those. +That's up to the makefile. + +> +> > > So I'd like to know what you think about this. I suggested making this +> > > project dependency optional, although I don't know how hard it would be. +> > +> > I don't think it's necessary. Maybe we could make it more convenient +> > by having make targets corresponding to the core areas e.g. make +> > md-project-gui would execute make in +> > main/src/core/MonoDevelop.Project.Gui. +> +> If the feature is optional, I think it should probably be on by default, +> because most people will expect a change in a project to rebuild +> projects which depend on it. + +That's ok to me, go ahead. + +Lluis. + + ++ + + +
On Tue, 2008-11-18 at 09:54 -0500, Lluis Sanchez Gual wrote: +> +> > There's potentially a larger issue, in that the MD makefiles are +> > synchronized by MD itself, so the functionality which does this sync +> > apparently does not currently support robust dependency checking for its +> > output. Regardless of whether the MD project wants to have robust +> > dependency checking for project references, I suspect many of our users +> > will want it. +> +> No, that's unrelated. Makefile synchronization just keeps in sync lists +> of files and references, but it does not decide what to do with those. +> That's up to the makefile. + +So the sync code doesn't create make targets for project assemblies? +And it doesn't update those targets at all after they are created? +That's surprising to me. I thought we could create a valid Makefile for +a project from scratch. I also thought we created distribution tarballs +which had automake based build systems. All of the above scenarios +would require make target dependency handling for project references. + +-- +Mike Kestner <mkestner at gmail.com> + ++ + + +
El dt 18 de 11 de 2008 a les 09:18 -0600, en/na Mike Kestner va +escriure: +> On Tue, 2008-11-18 at 09:54 -0500, Lluis Sanchez Gual wrote: +> > +> > > There's potentially a larger issue, in that the MD makefiles are +> > > synchronized by MD itself, so the functionality which does this sync +> > > apparently does not currently support robust dependency checking for its +> > > output. Regardless of whether the MD project wants to have robust +> > > dependency checking for project references, I suspect many of our users +> > > will want it. +> > +> > No, that's unrelated. Makefile synchronization just keeps in sync lists +> > of files and references, but it does not decide what to do with those. +> > That's up to the makefile. +> +> So the sync code doesn't create make targets for project assemblies? +> And it doesn't update those targets at all after they are created? + +Nope. + +> That's surprising to me. I thought we could create a valid Makefile for +> a project from scratch. I also thought we created distribution tarballs +> which had automake based build systems. All of the above scenarios +> would require make target dependency handling for project references. +> + +We do support that, but it is a different feature. + +On one hand, we have a Makefile Generator. This generator takes a +solution and generates a set of makefiles and configuration files that +can be used to build the project. The generated build system can +optionally be based on Autotools. Notice that every time the makefiles +are generated, the previous ones are overwritten. The makefiles it +generates are good enough for the projects you can create with MD, but +they can fall short for complex projects with more complex build system +needs (but still, the generated makefiles can be a good starting point +for those projects). The makefile generator is also used by the +packaging add-in, when you create a Tarball package. + +In MD, we have used the generator in the past to generate some of the +makefiles in 'extras', which have later been modified and improved. We +can certainly improve the generator to support project dependencies. + +On the other hand there is the Makefile Synchronization feature. Using +this feature, you can sync the file and references list of a project +with a makefile. But it is just a matter of updating lists. What the +makefile does with those lists is up to the makefile, and the +synchronizer just doesn't care. So you can have arbitrarily complex +makefiles, but still keep them synchronized with MD projects. You can of +course generate makefiles with the Generator, and then enable +synchronization. + +In MD, we are using the makefile synchronizer to keep the makefiles up +to date. However, if we want to support project dependencies we have to +fix the makefiles, not the synchronizer. + +I hope this clarifies things a bit. +Lluis. + ++ + +
Hi. + +I put some patches to Vi mode in bugzilla, and will probably have some +more in following days. + +So I have a question - I have choosen the text editor component, so they +are assigned to Mike Krueger, but afaik he is not responsible for vimode +at all. +Should I assign new patches to someone? +Or maybe leave general monodevelop-bugs@? + + +-- +silk + ++ + + +
On Wed, Nov 26, 2008 at 8:43 AM, Grzegorz Sobanski +<grzegorz.sobanski at cs.put.poznan.pl> wrote: +> Hi. +> +> I put some patches to Vi mode in bugzilla, and will probably have some +> more in following days. +> +> So I have a question - I have choosen the text editor component, so they +> are assigned to Mike Krueger, but afaik he is not responsible for vimode +> at all. +> Should I assign new patches to someone? +> Or maybe leave general monodevelop-bugs@? + +Please assign them to me, mhutchinson at novell. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
+HI All: + I was talking to Michael and i will try to start the MonoDevelop Gendarme addin. + I have some affirmations/questions, Based on Michael post [*], that i need to clarify, any help will be helpfull. + +1) I use Gendarme with System.Diagnostic.Process to not depend on it. +2) I have to make a widget/dialog to setup Rules.xml file with all the futures: Rules sets, ignore rules, Severity levels, etc. +3) User must jump to the offending code line/file and an explanation of the fault: This is the hard part, i will try to save log file, an parse it, any other way? (Parse html could be another way, but i think is harder than log file). I didn't see the log file, i didn't know if my approach is correct. +4) I will use One rules.xml file per solution/target (Solution & Debug/Release/Test/etc) +5) Allow to check the rules before checking to VCS. +6) Use the MD Code DOM to find things not listed in MDB files. What is this? +7) Add the Gendarme configuration file to the project. +8) Warning message of gendarme result could it be shown in Construction Pad, as "Wanings". + + +Thanks +Lucian0 + +My english isn't my best skill :) So, sorry if i've some errors. + +[*] http://groups.google.com/group/gendarme/browse_thread/thread/eba0f7b881926ab0/158fdf10b9d58998 + + +_________________________________________________________________ +Stay up to date on your PC, the Web, and your mobile phone with Windows Live +http://clk.atdmt.com/MRT/go/119462413/direct/01/ +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081126/9427f746/attachment.html ++ + + +
On Wed, Nov 26, 2008 at 4:02 PM, Luciano _ <lnc19 at hotmail.com> wrote: +> HI All: +> I was talking to Michael and i will try to start the MonoDevelop Gendarme +> addin. +> I have some affirmations/questions, Based on Michael post [*], that i need +> to clarify, any help will be helpfull. +> +> 1) I use Gendarme with System.Diagnostic.Process to not depend on it. + +Yup, it'll need to run gendarme to produce an xml file in the output +directory, then read in the XML. The Smokey code analysis addin +already does this, so that code might be a good starting point. + +This is the main priority IMO. + +> 2) I have to make a widget/dialog to setup Rules.xml file with all the +> futures: Rules sets, ignore rules, Severity levels, etc. + +See #4. + +> 3) User must jump to the offending code line/file and an explanation of the +> fault: This is the hard part, i will try to save log file, an parse it, any +> other way? (Parse html could be another way, but i think is harder than log +> file). I didn't see the log file, i didn't know if my approach is correct. + +There's the XML file, which should be very easy to load. The smokey +addin does this. + +> 4) I will use One rules.xml file per solution/target (Solution & +> Debug/Release/Test/etc) + +I'm not sure how rule sets should apply to +project/solutions/configurations, but this seems like a good model: +http://blogs.msdn.com/fxcop/archive/2008/11/12/fun-with-code-analysis-rulesets.aspx + +> 5) Allow to check the rules before checking to VCS. +> 6) Use the MD Code DOM to find things not listed in MDB files. What is this? + +Some analyses might report an error in a member, without having a +location. MD has an internal type database with lots of line/col/file +information so this could be a good fallback. Very low priority +anyway, so don't worry about it :) + +> 7) Add the Gendarme configuration file to the project. +> 8) Warning message of gendarme result could it be shown in Construction Pad, +> as "Wanings". + +It's debatable exactly how gendarme severity should map to +error/warnings in the errors pad. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Hello Luciano, + +If you're not already I suggest you subscribe to +gendarme at googlegroups.com + +On Wed, 2008-11-26 at 18:17 -0500, Michael Hutchinson wrote: +> On Wed, Nov 26, 2008 at 4:02 PM, Luciano _ <lnc19 at hotmail.com> wrote: +> > HI All: +> > I was talking to Michael and i will try to start the MonoDevelop Gendarme +> > addin. +> > I have some affirmations/questions, Based on Michael post [*], that i need +> > to clarify, any help will be helpfull. +> > +> > 1) I use Gendarme with System.Diagnostic.Process to not depend on it. +> +> Yup, it'll need to run gendarme to produce an xml file in the output +> directory, then read in the XML. The Smokey code analysis addin +> already does this, so that code might be a good starting point. + +Basically you can have: +* one input XML file (optional, but it's how to configure everything); +* a few parameters, like the assemblies being analyzed; +* an ignore-list file (optional, but so useful); and +* one output XML file. + +> This is the main priority IMO. +> +> > 2) I have to make a widget/dialog to setup + +Before setting up you'll need to know what to setup. This means you must +be able to discover what is available (rules as a minimum, potentially +configurable options later) to present them to the user. + +Today different runners have different strategy. E.g. the console runner +base itself on a file (the rules.xml file shipped w/Gendarme) while the +wizard GUI runner inspects the rules assemblies to find the rules +available. The addin needs is kind of in-between. In any case there's no +need to link with the Gendarme binaries to get the information. + +The other important feature IMO is to handle the "ignore-list", i.e. +stuff you don't want to be warned about the next time you ask for your +code to be analyzed. There should be a way to add to this list and a way +to remove ignored stuff from it. + +> Rules.xml file with all the +> > futures: Rules sets, ignore rules, Severity levels, etc. + +Using an XML file you can* + +(a) specify which rules are used (or not) during analysis; + +(b) define different rule sets (inside the same XML file); + +(c) set options on rules [1]; + +(d) set the applicability of each rule on: + everything (the default on the console runner); + code visible outside the assembly; + code only visible inside the assembly; + + * but you don't need to support all possible options in order to + have a useful addin ;-) + +What you cannot set in the XML file are filters on Severity and +Confidence (i.e. filters on the defects) but you can specify them on the +command-line (since Gendarme 2.2). + +However it may be easier to filter defects later, i.e. not at analysis +time, when you load the XML results (and that would work on Gendarme 2.0 +too). This would let users change filtering without re-analyzing the +solution (or projects) which would be faster (since you would need to +reload the results anyway). + +> See #4. +> +> > 3) User must jump to the offending code line/file and an explanation of the +> > fault: This is the hard part, i will try to save log file, an parse it, any +> > other way? (Parse html could be another way, but i think is harder than log +> > file). I didn't see the log file, i didn't know if my approach is correct. +> +> There's the XML file, which should be very easy to load. The smokey +> addin does this. + +You can use "--xml results.xml" to get the defects inside an XML file. +The text and HTML formats would not only be harder to parse but also +more likely to change too in future releases. + +> > 4) I will use One rules.xml file per solution/target (Solution & +> > Debug/Release/Test/etc) +> +> I'm not sure how rule sets should apply to +> project/solutions/configurations, but this seems like a good model: +> http://blogs.msdn.com/fxcop/archive/2008/11/12/fun-with-code-analysis-rulesets.aspx + +In VS.NET people generally defines a target for code analysis - i.e. +where CODE_ANALYSIS is defined (you can see it inside the above link). +This lets attributes, like [SuppressMessage], be compiled into the +assemblies [2]. In the future it's likely people will want contracts to +be part of the analysis (since it gives more clues about the code and +rules are always hungry for clues). + +I think people expects to be able to run analysis on both the solution +and on specific projects. It's important to note that running the +analysis on each projects will be a bit different (result wise) than +running it on the solution. This is because some rules works on the set +of assemblies being analyzed (so more assemblies, more complete the +analysis can be and more potential defects can be found). IMO both +options are valid (even if the solution-level analysis is more +complete). + +> > 5) Allow to check the rules before checking to VCS. + +That's (quite) an advanced option - but something that you should keep +in mind. + +> > 6) Use the MD Code DOM to find things not listed in MDB files. What is this? +> +> Some analyses might report an error in a member, without having a +> location. MD has an internal type database with lots of line/col/file +> information so this could be a good fallback. Very low priority +> anyway, so don't worry about it :) + +Yes, MDB has some limitations (e.g. fields, attributes) where no line +information is available. Having a fallback, eventually, would be a nice +addition. + +> > 7) Add the Gendarme configuration file to the project. +> > 8) Warning message of gendarme result could it be shown in Construction Pad, +> > as "Wanings". +> +> It's debatable exactly how gendarme severity should map to +> error/warnings in the errors pad. + +It's unlikely that people will want all of them mixed with compiler +errors and warnings. You would be best to start with a separate view +where filtering and sorting is possible. + +Later you might want to give the options, for each rule, to act as an +error, a warning or simply be shown in the code analysis view. That +could be a great place to ask if some defects are "commit +breakers" (point #5). + +Don't hesitate to ask any questions (by email or on IRC). +Sebastien + + +[1] Right now the console runner use reflection to set options. Future +versionS of Gendarme (planned for 2.4) will start using System.Component +attributes to advertise rules options in a way that makes it easy to +build an UI on top of it. + +[2] The [SuppressMessage] attribute is not supported in current version +of Gendarme - but the infrastructure is already in place (i.e. matching +Gendarme and FxCop rules) to make this possible in the future. + + ++ + +
Starting: Wed Nov 5 05:11:08 EST 2008
+ Ending: Wed Nov 26 21:02:33 EST 2008
+ Messages: 32
+
+ Last message date:
+ Wed Nov 26 21:02:33 EST 2008
+ Archived on: Wed Nov 26 21:11:34 EST 2008
+
+
+
Starting: Wed Nov 5 05:11:08 EST 2008
+ Ending: Wed Nov 26 21:02:33 EST 2008
+ Messages: 32
+
+ Last message date:
+ Wed Nov 26 21:02:33 EST 2008
+ Archived on: Wed Nov 26 21:11:34 EST 2008
+
+
+
Starting: Wed Nov 5 05:11:08 EST 2008
+ Ending: Wed Nov 26 21:02:33 EST 2008
+ Messages: 32
+
+ Last message date:
+ Wed Nov 26 21:02:33 EST 2008
+ Archived on: Wed Nov 26 21:11:34 EST 2008
+
+
+
Starting: Wed Nov 5 05:11:08 EST 2008
+ Ending: Wed Nov 26 21:02:33 EST 2008
+ Messages: 32
+
+ Last message date:
+ Wed Nov 26 21:02:33 EST 2008
+ Archived on: Wed Nov 26 21:11:34 EST 2008
+
+
+
Starting: Wed Nov 5 05:11:08 EST 2008
+ Ending: Wed Nov 26 21:02:33 EST 2008
+ Messages: 32
+
+ Last message date:
+ Wed Nov 26 21:02:33 EST 2008
+ Archived on: Wed Nov 26 21:11:34 EST 2008
+
+
+
With your help, I was able to get this moving somewhat. + +As an addin, this needs a lot of work. But it currently supports: + + - Python project type + - Project and file template + - Pluggable python runtimes (cPython2.5 only currently. this will change + after i get the ui components added) + - Precompiling of python modules (either .pyc or .pyo for optimized) + - Code folding for functions/comments/classes + - Really basic completion that I will be adding to over the next few + nights (basically until its usable for myself daily) + - Parsing of python code is done via a subprocess to a long running + python process. This allows for building a real AST using the "compiler" + module. + +and the obligatory screenshot + + http://audidude.com/dropbox/monodevelop-python.png + +Cheers! + +-- Christian + +On Tue, Sep 30, 2008 at 11:59 AM, Christian Hergert < +christian.hergert at gmail.com> wrote: + +> While I think its a worthy idea to remove the tight coupling to .NET logic, +> I'm not going to volunteer to do it. I'll work around it for the time being +> and it seems like a notable post-2.0 feature. +> +> -- Christian +> +> +> On Mon, Sep 29, 2008 at 9:59 PM, Michael Hutchinson < +> m.j.hutchinson at gmail.com> wrote: +> +>> Hi, +>> +>> > On Mon, Sep 29, 2008 at 3:38 PM, Christian Hergert +>> > <christian.hergert at gmail.com> wrote: +>> >> +>> >> I have a class that extends ParsedDocument. Do references inside that +>> >> class get persisted to the parser database? Or is this perhaps +>> something +>> >> that i should have encapsulated in an ICompilationUnit. +>> +>> I /think/ any fields of objects that are [Serializable] will get +>> persisted, which includes all the collections that the base +>> ParsedDocument has. +>> +>> On Mon, Sep 29, 2008 at 7:29 PM, Christian Hergert +>> <christian.hergert at gmail.com> wrote: +>> > Ok, so after some further exploration, I think I understand the +>> > ICompilationUnit stuff. I was really hoping that the interface would +>> expose +>> > information via IEnumerable's so that I could maintain data in my own +>> format +>> > and yield requested data at will. It also seems that the +>> ICompilationUnit +>> > is very much geared towards c#/.net. I'll just map things the best I +>> can. +>> +>> ParsedDocument is designed to be language-agnostic. ICompilationUnit +>> is very much .NET-specific, so if you don't want to use it, you don't +>> have to. Have the field here is not ideal IMO, but my suggestion for a +>> .NET parse unit interface was not taken up. There's a thread of +>> discussion about this that you might be able to contribute to. +>> +>> The design so far has been pretty much driven by C#, so if you have +>> any suggestions to improve it, now would be the time to voice them, +>> before we start heading into the 2.0 betas. +>> +>> >> +>> >> As an example .. +>> >> +>> >> PythonParsedDocument : ParsedDocument { +>> >> PythonModule module; // hoping this gets persisted +>> +>> If what I suspect is correct, PythonModule would have to be +>> serializable. However, the DB is optimised/indexed for type lookup and +>> stuff, and this would obviously not work easily with custom +>> serializable classes. This may be something that we could improve. +>> +>> -- +>> Michael Hutchinson +>> http://mjhutchinson.com +>> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081001/93151f73/attachment-0001.html ++ + + +
I've added error highlighting as well. + +http://audidude.com/dropbox/monodevelop-python-errors.png + +-- Christian + +On Wed, Oct 1, 2008 at 12:18 AM, Christian Hergert < +christian.hergert at gmail.com> wrote: + +> With your help, I was able to get this moving somewhat. +> +> As an addin, this needs a lot of work. But it currently supports: +> +> - Python project type +> - Project and file template +> - Pluggable python runtimes (cPython2.5 only currently. this will +> change after i get the ui components added) +> - Precompiling of python modules (either .pyc or .pyo for optimized) +> - Code folding for functions/comments/classes +> - Really basic completion that I will be adding to over the next few +> nights (basically until its usable for myself daily) +> - Parsing of python code is done via a subprocess to a long running +> python process. This allows for building a real AST using the "compiler" +> module. +> +> and the obligatory screenshot +> +> http://audidude.com/dropbox/monodevelop-python.png +> +> Cheers! +> +> -- Christian +> +> +> On Tue, Sep 30, 2008 at 11:59 AM, Christian Hergert < +> christian.hergert at gmail.com> wrote: +> +>> While I think its a worthy idea to remove the tight coupling to .NET +>> logic, I'm not going to volunteer to do it. I'll work around it for the +>> time being and it seems like a notable post-2.0 feature. +>> +>> -- Christian +>> +>> +>> On Mon, Sep 29, 2008 at 9:59 PM, Michael Hutchinson < +>> m.j.hutchinson at gmail.com> wrote: +>> +>>> Hi, +>>> +>>> > On Mon, Sep 29, 2008 at 3:38 PM, Christian Hergert +>>> > <christian.hergert at gmail.com> wrote: +>>> >> +>>> >> I have a class that extends ParsedDocument. Do references inside that +>>> >> class get persisted to the parser database? Or is this perhaps +>>> something +>>> >> that i should have encapsulated in an ICompilationUnit. +>>> +>>> I /think/ any fields of objects that are [Serializable] will get +>>> persisted, which includes all the collections that the base +>>> ParsedDocument has. +>>> +>>> On Mon, Sep 29, 2008 at 7:29 PM, Christian Hergert +>>> <christian.hergert at gmail.com> wrote: +>>> > Ok, so after some further exploration, I think I understand the +>>> > ICompilationUnit stuff. I was really hoping that the interface would +>>> expose +>>> > information via IEnumerable's so that I could maintain data in my own +>>> format +>>> > and yield requested data at will. It also seems that the +>>> ICompilationUnit +>>> > is very much geared towards c#/.net. I'll just map things the best I +>>> can. +>>> +>>> ParsedDocument is designed to be language-agnostic. ICompilationUnit +>>> is very much .NET-specific, so if you don't want to use it, you don't +>>> have to. Have the field here is not ideal IMO, but my suggestion for a +>>> .NET parse unit interface was not taken up. There's a thread of +>>> discussion about this that you might be able to contribute to. +>>> +>>> The design so far has been pretty much driven by C#, so if you have +>>> any suggestions to improve it, now would be the time to voice them, +>>> before we start heading into the 2.0 betas. +>>> +>>> >> +>>> >> As an example .. +>>> >> +>>> >> PythonParsedDocument : ParsedDocument { +>>> >> PythonModule module; // hoping this gets persisted +>>> +>>> If what I suspect is correct, PythonModule would have to be +>>> serializable. However, the DB is optimised/indexed for type lookup and +>>> stuff, and this would obviously not work easily with custom +>>> serializable classes. This may be something that we could improve. +>>> +>>> -- +>>> Michael Hutchinson +>>> http://mjhutchinson.com +>>> +>> +>> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081001/a207c424/attachment.html ++ + + +
On Wed, Oct 1, 2008 at 4:57 AM, Christian Hergert +<christian.hergert at gmail.com> wrote: +> I've added error highlighting as well. +> +> http://audidude.com/dropbox/monodevelop-python-errors.png +> +> -- Christian +> +> On Wed, Oct 1, 2008 at 12:18 AM, Christian Hergert +> <christian.hergert at gmail.com> wrote: +>> +>> With your help, I was able to get this moving somewhat. +>> +>> As an addin, this needs a lot of work. But it currently supports: +>> +>> Python project type +>> Project and file template +>> Pluggable python runtimes (cPython2.5 only currently. this will change +>> after i get the ui components added) +>> Precompiling of python modules (either .pyc or .pyo for optimized) +>> Code folding for functions/comments/classes +>> Really basic completion that I will be adding to over the next few nights +>> (basically until its usable for myself daily) +>> Parsing of python code is done via a subprocess to a long running python +>> process. This allows for building a real AST using the "compiler" module. +>> +>> and the obligatory screenshot +>> +>> http://audidude.com/dropbox/monodevelop-python.png + +Nice work! + +Would you like to add this to extras? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
I would love to! + +The code can currently be found at: + +git://git.dronelabs.com/git/users/chris/monodevelop-pybinding.git +If you place that folder as a sibling to monodevelop/, you can run +"./tester-tool" which will copy the lib over and run "make run" for you. + +-- Christian + +On Wed, Oct 1, 2008 at 8:47 AM, Michael Hutchinson <m.j.hutchinson at gmail.com +> wrote: + +> On Wed, Oct 1, 2008 at 4:57 AM, Christian Hergert +> <christian.hergert at gmail.com> wrote: +> > I've added error highlighting as well. +> > +> > http://audidude.com/dropbox/monodevelop-python-errors.png +> > +> > -- Christian +> > +> > On Wed, Oct 1, 2008 at 12:18 AM, Christian Hergert +> > <christian.hergert at gmail.com> wrote: +> >> +> >> With your help, I was able to get this moving somewhat. +> >> +> >> As an addin, this needs a lot of work. But it currently supports: +> >> +> >> Python project type +> >> Project and file template +> >> Pluggable python runtimes (cPython2.5 only currently. this will change +> >> after i get the ui components added) +> >> Precompiling of python modules (either .pyc or .pyo for optimized) +> >> Code folding for functions/comments/classes +> >> Really basic completion that I will be adding to over the next few +> nights +> >> (basically until its usable for myself daily) +> >> Parsing of python code is done via a subprocess to a long running python +> >> process. This allows for building a real AST using the "compiler" +> module. +> >> +> >> and the obligatory screenshot +> >> +> >> http://audidude.com/dropbox/monodevelop-python.png +> +> Nice work! +> +> Would you like to add this to extras? +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081001/555a9331/attachment.html ++ + + +
Currently, errors matching ErrorType.Warning are highlighted in red along +with ErrorType.Error. Does it make sense to change this to a yellow'ish +color? Do we want that configurable per text editor scheme? + +I just added pyflakes support to the python parser to catch warnings. I +would like these to not turn up red :-) + +-- Christian / vwduder +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081001/4d708c01/attachment.html ++ + + +
On Thu, Oct 2, 2008 at 2:07 AM, Christian Hergert +<christian.hergert at gmail.com> wrote: +> Currently, errors matching ErrorType.Warning are highlighted in red along +> with ErrorType.Error. Does it make sense to change this to a yellow'ish +> color? Do we want that configurable per text editor scheme? +> +> I just added pyflakes support to the python parser to catch warnings. I +> would like these to not turn up red :-) + +I think we could maybe have as many as 5 underline colours: +ParserError, ParserWarning, CompilerError, CompilerWarning, Spelling. +Perhaps the Compiler/Parser distinction isn't necessary, though there +are differences in their dynamicity that might warrant it, so we +probably need to think this over. + +These should of course be defined in the colour scheme so that they +fit in with the other highlighting colours. The named colours should +have fallbacks in case the schemes don't define all the colours. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
I think for the moment we should add a check in SourceEditorWidget.cs +for warnings. + +if (info.ErrorType == ErrorType.Warning) + (marker as UnderlineMarker).Color = new Gdk.Color (232, 192, 52); + +But you are right, abstracting this is a good idea. + +-- Christian + +On 10/2/08, Michael Hutchinson <m.j.hutchinson at gmail.com> wrote: +> On Thu, Oct 2, 2008 at 2:07 AM, Christian Hergert +> <christian.hergert at gmail.com> wrote: +>> Currently, errors matching ErrorType.Warning are highlighted in red along +>> with ErrorType.Error. Does it make sense to change this to a yellow'ish +>> color? Do we want that configurable per text editor scheme? +>> +>> I just added pyflakes support to the python parser to catch warnings. I +>> would like these to not turn up red :-) +> +> I think we could maybe have as many as 5 underline colours: +> ParserError, ParserWarning, CompilerError, CompilerWarning, Spelling. +> Perhaps the Compiler/Parser distinction isn't necessary, though there +> are differences in their dynamicity that might warrant it, so we +> probably need to think this over. +> +> These should of course be defined in the colour scheme so that they +> fit in with the other highlighting colours. The named colours should +> have fallbacks in case the schemes don't define all the colours. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> ++ + + +
Are attached, ok to commit? + +-- Christian +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: syntax-updates.patch +Type: text/x-patch +Size: 1027 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081010/1e5209a2/attachment.bin ++ + + +
On Fri, Oct 10, 2008 at 3:25 AM, Christian Hergert +<christian.hergert at gmail.com> wrote: +> Are attached, ok to commit? + +Looks good. Thanks! + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
+I've been trying like hell to get GTK# 2.0 to show under the C# heading under +new solution. I downloaded and installed Xcode from apple.com. I go into the +add-in manager in monodevelop and it complains about not being able to find +gtkcore 1.9.0 in the go-mono repository. I've tried every thing I could +think of and searched forever to do this, but still I can't succeed. I've +also tried getting a c# heading to appear in Xcode and followed the +tutorials for moving the csharp plugin file, that doesn't work either. This +is apple, it's not supposed to be this hard. Is it?? +-- +View this message in context: http://n2.nabble.com/Can%27t-get-monodevelop-to-show-GTK--2.00-under-C--heading-tp1380670p1380670.html +Sent from the Mono - MonoDevelop - Dev mailing list archive at Nabble.com. + ++ + +
Starting: Wed Oct 1 03:18:47 EDT 2008
+ Ending: Sun Oct 26 21:00:18 EDT 2008
+ Messages: 10
+
+ Last message date:
+ Sun Oct 26 21:00:18 EDT 2008
+ Archived on: Mon Oct 27 10:08:34 EDT 2008
+
+
+
Starting: Wed Oct 1 03:18:47 EDT 2008
+ Ending: Sun Oct 26 21:00:18 EDT 2008
+ Messages: 10
+
+ Last message date:
+ Sun Oct 26 21:00:18 EDT 2008
+ Archived on: Mon Oct 27 10:08:34 EDT 2008
+
+
+
Starting: Wed Oct 1 03:18:47 EDT 2008
+ Ending: Sun Oct 26 21:00:18 EDT 2008
+ Messages: 10
+
+ Last message date:
+ Sun Oct 26 21:00:18 EDT 2008
+ Archived on: Mon Oct 27 10:08:34 EDT 2008
+
+
+
Starting: Wed Oct 1 03:18:47 EDT 2008
+ Ending: Sun Oct 26 21:00:18 EDT 2008
+ Messages: 10
+
+ Last message date:
+ Sun Oct 26 21:00:18 EDT 2008
+ Archived on: Mon Oct 27 10:08:34 EDT 2008
+
+
+
Starting: Wed Oct 1 03:18:47 EDT 2008
+ Ending: Sun Oct 26 21:00:18 EDT 2008
+ Messages: 10
+
+ Last message date:
+ Sun Oct 26 21:00:18 EDT 2008
+ Archived on: Mon Oct 27 10:08:34 EDT 2008
+
+
+
Hi all,
+
+I'm confused about the purpose of the IDocumentMetaInformation. I
+think it exists because I once complained that I had to implement a
+LanguageBinding simply to add code folding and error underlining. My
+exact complaint was that I had to use an ICompilationUnit to mark
+folding region and errors, and that it contained a lot of
+.NET-specific information which my parser didn't need to populate.
+However, I did implement the language binding for ASP.NET and it works
+fine, and adding a parser is easier in the C# 3 branch...
+
+The IDocumentMetaInformation is confusing; it does not fix the
+original problem at all. It's worse -- it requires a second parse and
+isn't stored is a publicly shared location, so has to be reparsed by
+e.g. the document outline provider, which requires the #region
+locations. Also, the source editor only parses an
+IDocumentMetaInformation when a CompilationUnit appears, so a
+CompilationUnit still has to be generated by the parser in order for
+the IDocumentMetaInformation to be used!
+
+I have some suggestions for a solution, which will also solve a few of
+the issue the C/C++ addin had when implementing a parser
+scheduler/notofication system. It will hopefully make it easier to add
+other parses in the future.
+
+I suggest we have the IParser instead return an IParsedDocument, which
+would be very generic, with the basic info used by the text editor:
+
+IParsedDocument
+{
+ string FileName;
+ DateTime ParseTime { get; }
+ IEnumerable<Fold> GetFoldLocations (); // expected to iterate over
+types, comments etc and generate folds
+ ICollection<Error> Errors { get; } // also warnings
+ bool HasErrors { get; }
+}
+
+There would then be an ICompilationUnit derived interface, with
+generic info for things like the quick finder and document outline.
+
+ICompilationUnit : IParsedDocument
+{
+ ICollection<IDisplayType> Types { get; }
+ ICollection<IDisplayMember> GlobalMembers { get; }
+ IEnumerable<Comment> Comments { get; }
+}
+
+The .NET info would be in the derived ICompilationUnit, and would be
+returned by .NET parsers:
+
+IDotNetCompilationUnit : ICompilationUnit
+{
+ ICollection<IUsing> Usings { get; }
+ ICollection<IAttribute> Attributes { get; }
+ ICollection<IType> Classes { get; } // foreach (IBaseType t in
+Types) yield return (IType) t;
+ ICollection<Coderegion> CodeRegions { get; } //#regions
+}
+
+I could implement an AspNetDocument : IParsedDocument. The C/C++
+parser could return a CCompilationUnit : ICompilationUnit.
+
+Even better, this moves some generic logic out of the SourceEditor2,
+so that the compilationunit / parseddocument could control the fold
+locations, i.e. GetFoldLocations () would generate regions by
+iterating over the members, classes, comments, C #regions, etc. Other
+such things should be implemented in a similar manner rather than
+being in SourceEditor2, so that it's easier to implement other
+editors. This is also, perhaps, a step being able to store and query
+C/C++ (ad other non-.NET languages) type information effectively in
+the pidb system.
+
+Does this sound like a good plan? Should I implement it? Any suggested
+changes to the above interfaces, in order to work better with other
+languages?
+
+--
+Michael Hutchinson
+http://mjhutchinson.com
+
+
+
+
+ Hi
+
+> Hi,
+>
+> I'm confused about the purpose of the IDocumentMetaInformation:
+>
+> <mkrueger> @mhutch: you one complained that it was in the parser :)
+> <mkrueger> therefore I put it into another part
+>
+> My exact complaint was that I had to use an ICompilationUnit to mark
+> folding region and errors, and that it contained a lot of
+> .NET-specific information which i didn't need. However, I did
+> implement that for ASP.NET and it works fine... The
+> IDocumentMetaInformation does not fix this at all.
+>
+
+It does fix it that way that .NET specific information is not
+in IDocumentMetaInformation.
+
+> Worse, it requires a second parse and isn't stored is a publicly
+> shared location, so has to be reparsed by e.g. the document outline
+> provider, which requires the #region locations. Also, text editor only
+> parses an IDocumentMetaInformation when a CompilationUnit appears, so
+> a CompilationUnit has to be generated anyway!
+>
+
+Thats because of the mcs stuff. It requires a second parse of the file,
+because it doesn't give me information about regions, comments etc.
+
+My long term vision for that was that a delta parser should take care of
+teh document meta information. The meta information should consists only
+on stuff that are regular expressions.
+
+> I have some suggestions for a solution.
+>
+> I suggest we have the IParser instead return an IParsedDocument, which
+> would be very generic, with the basic info used by the text editor:
+>
+
+> IParsedDocument
+> {
+> string FileName;
+> DateTime ParseTime { get; }
+> IEnumerable<Fold> GetFoldLocations (); //expected to iterate
+> over types, comments etc and generate folds
+> ICollection<Error> Errors { get; } //also warnings
+> bool HasErrors { get; }
+> }
+>
+> There would then be an ICompilationUnit derived interface, with
+> generic info for things like the quick finder and document outline.
+>
+
+> ICompilationUnit : IParsedDocument
+> {
+> ICollection<IBaseType> Types { get; }
+> ICollection<IBaseMember> GlobalMembers { get; }
+>
+> IEnumerable<Comment> Comments { get; }
+> }
+>
+> The .NET info would be in the derived ICompilationUnit, and would be
+> returned by .NET parsers:
+>
+
+> IDotNetCompilationUnit : ICompilationUnit
+> {
+> ICollection<IUsing> Usings { get; }
+> ICollection<IAttribute> Attributes { get; }
+> ICollection<IType> Classes { get; } // foreach (IBaseType t in
+> Types) yield return (IType) t;
+> ICollection<Coderegion> CodeRegions { get; } //#regions
+> }
+>
+> Even better, this moves some generic logic out of the SourceEditor2,
+> so that the compilationunit / parseddocument could control the fold
+> locations, i.e. GetFoldLocations () would generate regions by
+> iterating over the members, classes, comments, C #regions, etc.
+>
+> I could implement an AspNetDocument : IParsedDocument. The C/C++
+> parser could return a CCompilationUnit : ICompilationUnit
+>
+> Does this sound like a good plan? Should I implement it?
+>
+
+Hm, I think that'll produce too many upcasts only for different levels
+of information.
+
+Something like this should work better:
+
+IParsedDocument
+{
+ string FileName;
+
+ DateTime ParseTime { get; }
+
+ IEnumerable<Fold> FoldLocations { get }; // expected to iterate
+over types, comments etc and generate folds
+
+ ICollection<Error> Errors { get; } // also warnings
+ bool HasErrors { get; }
+
+ IEnumerable<Comment> Comments { get; }
+
+ ICollection<Coderegion> CodeRegions { get; } //#regions
+
+ ICompilationUnit CompilationUnit { get; }
+}
+
+ICompilationUnit
+{
+ ICollection<IUsing> Usings { get; }
+ ICollection<IAttribute> Attributes { get; }
+ ICollection<IType> Classes { get; } // foreach (IBaseType t in
+Types) yield return (IType) t;
+}
+
+Then'll don't need to upcast every time.
+
+Regards
+Mike
+
+
+
+
+
+ On Wed, Sep 10, 2008 at 6:10 AM, Mike Krüger <mkrueger at novell.com> wrote: +> Hi +> +>> Hi, +>> +>> I'm confused about the purpose of the IDocumentMetaInformation: +>> +>> <mkrueger> @mhutch: you one complained that it was in the parser :) +>> <mkrueger> therefore I put it into another part +>> +>> My exact complaint was that I had to use an ICompilationUnit to mark +>> folding region and errors, and that it contained a lot of +>> .NET-specific information which i didn't need. However, I did +>> implement that for ASP.NET and it works fine... The +>> IDocumentMetaInformation does not fix this at all. +>> +> +> It does fix it that way that .NET specific information is not +> in IDocumentMetaInformation. + +True, but it wasn't possible to use the IDocumentMetaInformation +without an ICompilationUnit too. Also, the IDocumentMetaInformation +was missing some functionality (in particular, errors), and folding +regions were duplicated across both. + +>> Worse, it requires a second parse and isn't stored is a publicly +>> shared location, so has to be reparsed by e.g. the document outline +>> provider, which requires the #region locations. Also, text editor only +>> parses an IDocumentMetaInformation when a CompilationUnit appears, so +>> a CompilationUnit has to be generated anyway! +>> +> +> Thats because of the mcs stuff. It requires a second parse of the file, +> because it doesn't give me information about regions, comments etc. + +That's an implementation detail specific to the mcs-based parser, so +should not affect core interfaces if we can avoid it. + +> My long term vision for that was that a delta parser should take care of +> teh document meta information. The meta information should consists only +> on stuff that are regular expressions. + +Couldn't an incremental/delta parser be used to /update/ the +CompilationUnit? At this point we don't even know if/how an +incremental parser could be implemented, so it seems premature to +design around it. This also seems rather mcs-specific. + +>> I have some suggestions for a solution. +>> +>> I suggest we have the IParser instead return an IParsedDocument, which +>> would be very generic, with the basic info used by the text editor: +>> +> +>> IParsedDocument +>> { +>> string FileName; +>> DateTime ParseTime { get; } +>> IEnumerable<Fold> GetFoldLocations (); //expected to iterate +>> over types, comments etc and generate folds +>> ICollection<Error> Errors { get; } //also warnings +>> bool HasErrors { get; } +>> } +>> +>> There would then be an ICompilationUnit derived interface, with +>> generic info for things like the quick finder and document outline. +>> +> +>> ICompilationUnit : IParsedDocument +>> { +>> ICollection<IBaseType> Types { get; } +>> ICollection<IBaseMember> GlobalMembers { get; } +>> +>> IEnumerable<Comment> Comments { get; } +>> } +>> +>> The .NET info would be in the derived ICompilationUnit, and would be +>> returned by .NET parsers: +>> +> +>> IDotNetCompilationUnit : ICompilationUnit +>> { +>> ICollection<IUsing> Usings { get; } +>> ICollection<IAttribute> Attributes { get; } +>> ICollection<IType> Classes { get; } // foreach (IBaseType t in +>> Types) yield return (IType) t; +>> ICollection<Coderegion> CodeRegions { get; } //#regions +>> } +>> +>> Even better, this moves some generic logic out of the SourceEditor2, +>> so that the compilationunit / parseddocument could control the fold +>> locations, i.e. GetFoldLocations () would generate regions by +>> iterating over the members, classes, comments, C #regions, etc. + +This is one of the important points in my proposal, since IMO we have +been hardcoding too much .NET-specific functionality into +SourceEditor2 is a way that is not extensible/overridable. + +>> I could implement an AspNetDocument : IParsedDocument. The C/C++ +>> parser could return a CCompilationUnit : ICompilationUnit +>> +>> Does this sound like a good plan? Should I implement it? +>> +> +> Hm, I think that'll produce too many upcasts only for different levels +> of information. + +Why are the upcasts a problem? They are all designed/intended to be +used in different ways. + +> Something like this should work better: +> +> IParsedDocument +> { +> string FileName; +> +> DateTime ParseTime { get; } +> +> IEnumerable<Fold> FoldLocations { get }; // expected to iterate +> over types, comments etc and generate folds +> +> ICollection<Error> Errors { get; } // also warnings +> bool HasErrors { get; } +> +> IEnumerable<Comment> Comments { get; } +> +> ICollection<Coderegion> CodeRegions { get; } //#regions +> +> ICompilationUnit CompilationUnit { get; } +> } +> +> ICompilationUnit +> { +> ICollection<IUsing> Usings { get; } +> ICollection<IAttribute> Attributes { get; } +> ICollection<IType> Classes { get; } // foreach (IBaseType t in +> Types) yield return (IType) t; +> } +> +> Then'll don't need to upcast every time. +> +> Regards +> Mike +> +> + +I've looked at your changes in SVN, and I'm not totally happy; it +would have been nice to finish the discussion first. At least it's a +step in the right direction. + +My concerns are: +* Still not generic enough -- .NET-centric: ConditionalRegion, +PreProcessorDefine, ICompilationUnit will not be needed for many +languages, and are not things that the text editor will use. +* Not designed around use cases -- for example, things like the quick +finder and document outline will still be tied to .NET. IMO the +ParseDocument should be "decomposable" into different interfaces for +different purposes, i.e. text editor's errors&folding, quick +finder/outline showing structure, .NET completion DB information, etc. +Only a single upcast would be required for any one purpose. +* Still leaves ICompilationUnit->folds mapping code in the +SourceEditor2. I'd like the ParseDocument to be able to perform this +mapping so that it can be overridden. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Hi
+
+> > My long term vision for that was that a delta parser should take care of
+> > teh document meta information. The meta information should consists only
+> > on stuff that are regular expressions.
+>
+> Couldn't an incremental/delta parser be used to /update/ the
+> CompilationUnit? At this point we don't even know if/how an
+> incremental parser could be implemented, so it seems premature to
+> design around it. This also seems rather mcs-specific.
+>
+
+An delta parser for a regular grammar is much more easy to do than for
+an context sensitive grammar (programming languages are that type). But
+I think a delta parser isn't worth it, because we may have to re-parse
+the whole file. But we could optimize it a bit more, it's not
+neccessarry for every case to re-parse all and then the delta parser for
+the other information'll make sense too.
+(In fact every time where a body is changed a re-parse is unneccessary,
+just the region information of the member should be updated)
+
+>
+> >> I have some suggestions for a solution.
+> >>
+> >> I suggest we have the IParser instead return an IParsedDocument,
+> which
+> >> would be very generic, with the basic info used by the text editor:
+> >>
+> >
+> >> IParsedDocument
+> >> {
+> >> string FileName;
+> >> DateTime ParseTime { get; }
+> >> IEnumerable<Fold> GetFoldLocations (); //expected to iterate
+> >> over types, comments etc and generate folds
+> >> ICollection<Error> Errors { get; } //also warnings
+> >> bool HasErrors { get; }
+> >> }
+> >>
+> >> There would then be an ICompilationUnit derived interface, with
+> >> generic info for things like the quick finder and document outline.
+> >>
+> >
+> >> ICompilationUnit : IParsedDocument
+> >> {
+> >> ICollection<IBaseType> Types { get; }
+> >> ICollection<IBaseMember> GlobalMembers { get; }
+> >>
+> >> IEnumerable<Comment> Comments { get; }
+> >> }
+> >>
+> >> The .NET info would be in the derived ICompilationUnit, and would
+> be
+> >> returned by .NET parsers:
+> >>
+> >
+> >> IDotNetCompilationUnit : ICompilationUnit
+> >> {
+> >> ICollection<IUsing> Usings { get; }
+> >> ICollection<IAttribute> Attributes { get; }
+> >> ICollection<IType> Classes { get; } // foreach (IBaseType t in
+> >> Types) yield return (IType) t;
+> >> ICollection<Coderegion> CodeRegions { get; } //#regions
+> >> }
+> >>
+> >> Even better, this moves some generic logic out of the
+> SourceEditor2,
+> >> so that the compilationunit / parseddocument could control the fold
+> >> locations, i.e. GetFoldLocations () would generate regions by
+> >> iterating over the members, classes, comments, C #regions, etc.
+>
+> This is one of the important points in my proposal, since IMO we have
+> been hardcoding too much .NET-specific functionality into
+> SourceEditor2 is a way that is not extensible/overridable.
+>
+
+Can you give some examples ? Take the quick class combo - it only makes
+sense when you've classes/members and regions. It's not really designed
+for non object oriented functional languages - I admit. But that's not
+really troublesome I think. For these languages we should not display
+the quick class combo.
+I think that's the case for other .NET specific features the same case.
+Your language don't have '.NET' attributes or Properties ? No problem,
+leave these collections empty in the compilation unit.
+MonoDevelop provides the superset (which is in fact very .NET specific,
+because it's designed around .NET features). But .NET is a good
+superset, because .NET was designed to match many languages.
+
+> >> I could implement an AspNetDocument : IParsedDocument. The C/C++
+> >> parser could return a CCompilationUnit : ICompilationUnit
+> >>
+> >> Does this sound like a good plan? Should I implement it?
+> >>
+> >
+> > Hm, I think that'll produce too many upcasts only for different levels
+> > of information.
+>
+> Why are the upcasts a problem? They are all designed/intended to be
+> used in different ways.
+>
+
+Not different ways, different levels of information.
+* It makes no sense to use object orientation this way, you're just
+creating a complicated class hierarchy and in the end it's casted to
+(IDotNetCompilationUnit) where all informations can be accessed. Even
+the source editor will do it this way. Your three interfaces could be
+separated, they shouldn't need to inherit from each other.
+
+* Having a 3-tier hierarchy like this one duplicates the entries
+(ICollection<IBaseType> Types { get; } and ICollection<IType> Classes
+{ get; }).
+
+* You're still mixing .NET and non .NET stuff
+in IDotNetCompilationUnit. And this is your main concern (Usings may be
+in .NET languages like c++, but not attributes).
+
+> I've looked at your changes in SVN, and I'm not totally happy; it
+> would have been nice to finish the discussion first. At least it's a
+> step in the right direction.
+>
+
+It's a proposal. I prefer to communicate over source code :).
+
+> My concerns are:
+> * Still not generic enough -- .NET-centric: ConditionalRegion,
+> PreProcessorDefine, ICompilationUnit will not be needed for many
+> languages, and are not things that the text editor will use.
+
+Yes that's true, for many 'languages' the CompilationUnit will be null.
+PreProcessorDefine will only be used for defines ... that's true that
+most langugages don't have something like this, but c, c++ share this
+with c# as well as the conditional regions (that are the #if DEFINED ...
+#else ... #endif) stuff.
+
+Think of the user side:
+Somewhere deep in future highlighting code:
+
+
+IParsedDocument doc = GetDoc ();
+
+// highlight errors red
+
+INetCentricParsedDocument netDoc = doc as INetCentricParsedDocument;
+if (netDoc != null) {
+ foreach(ConditionalRegion r in netDoc.ConditionalRegion) {
+ if (!netDoc.IsDefined (r.Condition)) {
+ // make gray
+ }
+ }
+}
+
+You would have just:
+
+
+IParsedDocument doc = GetDoc ();
+
+// highlight errors red
+
+foreach(ConditionalRegion r in doc.ConditionalRegion) {
+ if (!doc.IsDefined (r.Condition)) {
+ // make gray
+ }
+}
+
+Your code is still .NET centric because it does the same thing but you just cast more.
+
+> * Not designed around use cases -- for example, things like the quick
+> finder and document outline will still be tied to .NET. IMO the
+> ParseDocument should be "decomposable" into different interfaces for
+> different purposes, i.e. text editor's errors&folding, quick
+> finder/outline showing structure, .NET completion DB information, etc.
+> Only a single upcast would be required for any one purpose.
+
+See the example above, the code will still be .NET centric, but does the
+upcast. If we've very domain specific information it'll make sense to
+hide them, but pre processor stuff, regions, usings are shared accross
+some languages. And I don't see that it hurts other languages, because
+you just re-use the ParsedDocument that's available and fill in the
+stuff that your language provides. From the user point of view I think
+that's easier than to get comfortable with a class hierarchy. (But I may
+be wrong - comments ?)
+
+> * Still leaves ICompilationUnit->folds mapping code in the
+> SourceEditor2. I'd like the ParseDocument to be able to perform this
+> mapping so that it can be overridden.
+>
+
+That can be done, is a different aspect than the inheritance stuff.
+
+Regards
+Mike
+
+
+
+
+
+
+ Hi. + +I've been using MonoDevelop.Components.DockToolbars in a personal +project and I get random errors when closing my application ( just +after calling Gtk.Application.Quit() ): + +Exception in Gtk# callback delegate + Note: Applications can use GLib.ExceptionManager.UnhandledException +to handle the exception. +System.InvalidOperationException: List has changed. + at System.Collections.ArrayList+SimpleEnumerator.MoveNext () [0x00000] + at MonoDevelop.Components.DockToolbars.FixedPanel.ForAll (Boolean +include_internals, Gtk.Callback callback) [0x0001d] in +/home/kraptor/Documentos/proyectos/MediaWalk/Shield.Interface/deps/MonoDevelop.Components.DockToolbars/FixedPanel.cs:256 + at Gtk.Container.Forall_cb (IntPtr container, Boolean +include_internals, IntPtr cb, IntPtr data) [0x00000] + at GLib.ExceptionManager.RaiseUnhandledException(System.Exception +e, Boolean is_terminal) + at Gtk.Container.Forall_cb(IntPtr container, Boolean +include_internals, IntPtr cb, IntPtr data) + at Gtk.Container.Forall_cb(IntPtr , Boolean , IntPtr , IntPtr ) + at Gtk.Application.gtk_main() + at Gtk.Application.gtk_main() + at Gtk.Application.Run() + +Seems that a callback in the ForAll method modifies the "widgets" +ArrayList. To prevent this, I've used the attached patch, that creates +an in-memory copy of the ArrayList so it can be iterated safely. + +Do not know if is correct or not, but I have no crashes anymore and +all works as expected. + +Any ideas why this happens? + +Thanks. +David. + +-- +David "kraptor" Anes Alcolea +http://www.kraptor.com +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: forall.fixedpanel.diff +Type: text/x-diff +Size: 449 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080916/88ccadc0/attachment.bin ++ + + + +
On Tue, 2008-09-16 at 18:11 +0200, David Anes wrote: + +> Seems that a callback in the ForAll method modifies the "widgets" +> ArrayList. To prevent this, I've used the attached patch, that creates +> an in-memory copy of the ArrayList so it can be iterated safely. +> +> Do not know if is correct or not, but I have no crashes anymore and +> all works as expected. +> +> Any ideas why this happens? + +Thanks for the patch. I committed a fix based on your idea on r113192. +The problem is most likely that a Remove is being done in a Forall loop +during cleanup which is invalidating the arraylist underneath it. + +The iteration definitely needs to be robust enough to continue across +such operations, so a clone of the list was needed. + +Thanks again, +Mike + ++ + + + +
On Thu, Sep 11, 2008 at 4:45 AM, Mike Krüger <mkrueger at novell.com> wrote: +> Hi +> +>> > My long term vision for that was that a delta parser should take care of +>> > teh document meta information. The meta information should consists only +>> > on stuff that are regular expressions. +>> +>> Couldn't an incremental/delta parser be used to /update/ the +>> CompilationUnit? At this point we don't even know if/how an +>> incremental parser could be implemented, so it seems premature to +>> design around it. This also seems rather mcs-specific. +>> +> +> An delta parser for a regular grammar is much more easy to do than for +> an context sensitive grammar (programming languages are that type). But +> I think a delta parser isn't worth it, because we may have to re-parse +> the whole file. But we could optimize it a bit more, it's not +> neccessarry for every case to re-parse all and then the delta parser for +> the other information'll make sense too. +> (In fact every time where a body is changed a re-parse is unneccessary, +> just the region information of the member should be updated) + +That would be really nice to have. + +> Can you give some examples ? Take the quick class combo - it only makes +> sense when you've classes/members and regions. It's not really designed +> for non object oriented functional languages - I admit. But that's not +> really troublesome I think. For these languages we should not display +> the quick class combo. + +It could apply to C++, and other non-.NET (but OO) langauges.... + +> I think that's the case for other .NET specific features the same case. +> Your language don't have '.NET' attributes or Properties ? No problem, +> leave these collections empty in the compilation unit. +> MonoDevelop provides the superset (which is in fact very .NET specific, +> because it's designed around .NET features). But .NET is a good +> superset, because .NET was designed to match many languages. + +I guess that can be made to work, but it's less than ideal from the +point of view of the code completion DB. Anyway, I guess we can solve +that problem when we have a concrete example. + + +>> > Hm, I think that'll produce too many upcasts only for different levels +>> > of information. +>> +>> Why are the upcasts a problem? They are all designed/intended to be +>> used in different ways. +>> +> +> Not different ways, different levels of information. +> * It makes no sense to use object orientation this way, you're just +> creating a complicated class hierarchy and in the end it's casted to +> (IDotNetCompilationUnit) where all informations can be accessed. Even +> the source editor will do it this way. Your three interfaces could be +> separated, they shouldn't need to inherit from each other. +> +> * Having a 3-tier hierarchy like this one duplicates the entries +> (ICollection<IBaseType> Types { get; } and ICollection<IType> Classes +> { get; }). +> +> * You're still mixing .NET and non .NET stuff +> in IDotNetCompilationUnit. And this is your main concern (Usings may be +> in .NET languages like c++, but not attributes). +> +>> I've looked at your changes in SVN, and I'm not totally happy; it +>> would have been nice to finish the discussion first. At least it's a +>> step in the right direction. +>> +> +> It's a proposal. I prefer to communicate over source code :). +> +>> My concerns are: +>> * Still not generic enough -- .NET-centric: ConditionalRegion, +>> PreProcessorDefine, ICompilationUnit will not be needed for many +>> languages, and are not things that the text editor will use. +> +> Yes that's true, for many 'languages' the CompilationUnit will be null. +> PreProcessorDefine will only be used for defines ... that's true that +> most langugages don't have something like this, but c, c++ share this +> with c# as well as the conditional regions (that are the #if DEFINED ... +> #else ... #endif) stuff. +> +> Think of the user side: +> Somewhere deep in future highlighting code: +> +> +> IParsedDocument doc = GetDoc (); +> +> // highlight errors red +> +> INetCentricParsedDocument netDoc = doc as INetCentricParsedDocument; +> if (netDoc != null) { +> foreach(ConditionalRegion r in netDoc.ConditionalRegion) { +> if (!netDoc.IsDefined (r.Condition)) { +> // make gray +> } +> } +> } +> +> You would have just: +> +> +> IParsedDocument doc = GetDoc (); +> +> // highlight errors red +> +> foreach(ConditionalRegion r in doc.ConditionalRegion) { +> if (!doc.IsDefined (r.Condition)) { +> // make gray +> } +> } +> +> Your code is still .NET centric because it does the same thing but you just cast more. + +Well, now that you pointed out how conditional regions can be used in +the text editor I'd move them to a non-.NET interface... + +>> * Not designed around use cases -- for example, things like the quick +>> finder and document outline will still be tied to .NET. IMO the +>> ParseDocument should be "decomposable" into different interfaces for +>> different purposes, i.e. text editor's errors&folding, quick +>> finder/outline showing structure, .NET completion DB information, etc. +>> Only a single upcast would be required for any one purpose. +> +> See the example above, the code will still be .NET centric, but does the +> upcast. If we've very domain specific information it'll make sense to +> hide them, but pre processor stuff, regions, usings are shared accross +> some languages. And I don't see that it hurts other languages, because +> you just re-use the ParsedDocument that's available and fill in the +> stuff that your language provides. From the user point of view I think +> that's easier than to get comfortable with a class hierarchy. (But I may +> be wrong - comments ?) +> +>> * Still leaves ICompilationUnit->folds mapping code in the +>> SourceEditor2. I'd like the ParseDocument to be able to perform this +>> mapping so that it can be overridden. +>> +> +> That can be done, is a different aspect than the inheritance stuff. + +Hey, I noticed you did that already :-) + +I've refactored it into interators/extension methods along with some +other changes (FoldingRegion -> Fold / UserRegion). I'd also be +tempted to make it on-demand too so that folds are only calculated for +visible files. I'll take a look at moving the remaining C#-specific +stuff (#if etc) into the C# binding, and removing the need for a +CompilationUnit. + +I'm not sure how to move the comments stuff out of the source editor, +since it depends on editor settings. + +On the whole I'm just going to let it evolve, since forward planing is +hard to do without concrete examples. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Does anyone have a short overview of how the parser system works now? +The optimal interactions between the parser, resolvers, and completion +system seems a bit tough to grasp which is compounded by the lack of +interface documentation. + +I'm trying to put together code completion for my cPython addin, but I'm +unsure which project I should look at for an ideal example. Things +appear to be in a sort of flux. + +Of particular interest is how the parser should interact with parsed +documents, what Tag's are, and how the gui completion should interact +with that. + +Thanks! + +-- Christian + ++ + + +
Hi + +I think it works almost the same way than before. The language bindings +should provide the parser for class browser/quick navigation. And they +should do the code completion (there is a class completiontexteditor +extension which makes at a bit easier to handle different completion +cases). But basically the language bindings extend the text editor with +completion. + +See the CSharpLanguageBinding for details. Tags are just a special type +of comments. I'm not really happy with the name. (Tag comments are +'TODO', 'HACK' etc.) + +The thing that's really interresting for code completion is the +ICompilationUnit inside the ParsedDocument. This contains all +information. + +Regards +Mike + + +> Does anyone have a short overview of how the parser system works now? +> The optimal interactions between the parser, resolvers, and completion +> system seems a bit tough to grasp which is compounded by the lack of +> interface documentation. +> +> I'm trying to put together code completion for my cPython addin, but I'm +> unsure which project I should look at for an ideal example. Things +> appear to be in a sort of flux. +> +> Of particular interest is how the parser should interact with parsed +> documents, what Tag's are, and how the gui completion should interact +> with that. +> +> Thanks! +> +> -- Christian +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + + +
Hi everyone, + +Here are my current thoughts concerning per-project styles and +policies, so that we can discuss it before I go ahead and implement +it. I also have an number of questions that are interspersed +throughout this email. + +Rationale +======= +There are a number of settings and preferences in MD that should be +customisable for different solutions/projects. Basically, anything +that affects the style of the code you write should be able to be set +for a particular project, since different projects have different +styles and policies. I've lumped "Styles and Policies" together into +one heading since I believe they are related. + +Text Editor Settings +============== +These are the ones that most people care about -- per-mimetype +settings for the general text editor behaviour such as tabs-to-spaces, +editor width, tab width, standard headers. Some languages may add to +this, e.g. C# indenter behaviour, and in future things like +auto-formatting. There should also be a "default" style, and the +per-mimetype settings should override this. + +* Should we allow users to add custom mimetypes for their own file +formats, or just support the "major" text/code mimetypes registered in +MD? +* Should we list only the mimetypes used in the project? +* For each mimetype, should there be a checkbox to override the +"default" text style? Or should there be a UI for adding/removing text +styles to the tree? + +Policies +====== +There are a number of other per-project settings that aren't quite +styles, but also aren't really build options or project properties. +I'm calling these "policies" for now. The only existing one is +changelog policies; in future, we could add settings such as "pass +tests before checkin", "check style before checkin", "must include +changelog entry", etc. + +Settings Infrastructure +================ +Many of these settings may need to be overridable for individual +projects within a solution, because a solution's projects may have +been imported from elsewhere with different coding style. For this +reason, we need an infrastructure that can be used to get the setting +for a project, and if the setting has not been overridden, will grab +the setting from the parent solution. + +* How important is this feature? +* How many of the settings really need to be overridable at project level? +* Should settings be overridable at "solution folder" level too, hence +allowing a cascade of settings? +* Should settings or group of settings be individually overridable? Or +should it just allow a project to override *all* settings? Does this +really need any granularity? +* Where should settings be stored? The solution file and the project +files? I feel this is better than a .userprefs-like file, since it +makes sure the settings stay with the project/solution. +* Should setting be duplicated in the project in case it's opened +without the solution? Or should the project have a flag to say that it +expects settings to be stored in a solution, so MD can warn when the +solution isn't present? +* What settings do we default to when opening projects that don't +contain settings Do we automatically add default settings to the +solution files? Or fall back to a set of user preferences? + +GUI Infrastructure +============= +It's difficult to present all of these options in the GUI in a +scalable way, particularly the per-mimetype editor settings +* Should the settings be in the main "Project options" dialog or a +separate "Styles and policies" dialog? The separate dialog has the +advantage that the same dialog can be used to edit the user's named +styles and default style. It would also help to not overload the +setting treeview in the existing project options dialog. +* Should each panel have "use parent solution's style", "load/save +named style" etc options? Or should these apply to all styles? +* VS has a setting panel that can be used to add "file types" and set +the editing experience that's used for them. maybe we could do +something similar with per-mimetype styles -- the top-level panel for +editor setting would contain this list, and adding a file type would +cause it and its options to appear in the tree. Files not handled this +way would fall back to the "Other files" style (VS has an "All files" +option which aggregates the common settings from all files, with +tri-state checkboxes etc, but I feel this is overcomplex). + +Named Styles +========== +It should be possible to save a project's style, and apply this style +to other solutions/projects. However, I don't think it's viable or +desirable to synchronise these in any way. Once a project is created, +its settings should remain constant unless they are explicitly +changed. + +I also have a number of mockups on my whiteboard which aren't so easy +to express in email :-) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + + +
I have a class that extends ParsedDocument. Do references inside that class
+get persisted to the parser database? Or is this perhaps something that i
+should have encapsulated in an ICompilationUnit.
+
+As an example ..
+
+PythonParsedDocument : ParsedDocument {
+ PythonModule module; // hoping this gets persisted
+}
+
+-- Christian
+
+On Mon, Sep 29, 2008 at 4:52 AM, Mike Krüger <mkrueger at novell.com> wrote:
+
+> Hi
+>
+> I think it works almost the same way than before. The language bindings
+> should provide the parser for class browser/quick navigation. And they
+> should do the code completion (there is a class completiontexteditor
+> extension which makes at a bit easier to handle different completion
+> cases). But basically the language bindings extend the text editor with
+> completion.
+>
+> See the CSharpLanguageBinding for details. Tags are just a special type
+> of comments. I'm not really happy with the name. (Tag comments are
+> 'TODO', 'HACK' etc.)
+>
+> The thing that's really interresting for code completion is the
+> ICompilationUnit inside the ParsedDocument. This contains all
+> information.
+>
+> Regards
+> Mike
+>
+>
+> > Does anyone have a short overview of how the parser system works now?
+> > The optimal interactions between the parser, resolvers, and completion
+> > system seems a bit tough to grasp which is compounded by the lack of
+> > interface documentation.
+> >
+> > I'm trying to put together code completion for my cPython addin, but I'm
+> > unsure which project I should look at for an ideal example. Things
+> > appear to be in a sort of flux.
+> >
+> > Of particular interest is how the parser should interact with parsed
+> > documents, what Tag's are, and how the gui completion should interact
+> > with that.
+> >
+> > Thanks!
+> >
+> > -- Christian
+> >
+> > _______________________________________________
+> > Monodevelop-devel-list mailing list
+> > Monodevelop-devel-list at lists.ximian.com
+> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+>
+> _______________________________________________
+> Monodevelop-devel-list mailing list
+> Monodevelop-devel-list at lists.ximian.com
+> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080929/c6ac3ebe/attachment.html
+
+
+
+
+ Ok, so after some further exploration, I think I understand the +ICompilationUnit stuff. I was really hoping that the interface would expose +information via IEnumerable's so that I could maintain data in my own format +and yield requested data at will. It also seems that the ICompilationUnit +is very much geared towards c#/.net. I'll just map things the best I can. + +Thanks for the info! + +-- Christian + +On Mon, Sep 29, 2008 at 3:38 PM, Christian Hergert < +christian.hergert at gmail.com> wrote: + +> I have a class that extends ParsedDocument. Do references inside that +> class get persisted to the parser database? Or is this perhaps something +> that i should have encapsulated in an ICompilationUnit. +> +> As an example .. +> +> PythonParsedDocument : ParsedDocument { +> PythonModule module; // hoping this gets persisted +> } +> +> -- Christian +> +> +> On Mon, Sep 29, 2008 at 4:52 AM, Mike Krüger <mkrueger at novell.com> wrote: +> +>> Hi +>> +>> I think it works almost the same way than before. The language bindings +>> should provide the parser for class browser/quick navigation. And they +>> should do the code completion (there is a class completiontexteditor +>> extension which makes at a bit easier to handle different completion +>> cases). But basically the language bindings extend the text editor with +>> completion. +>> +>> See the CSharpLanguageBinding for details. Tags are just a special type +>> of comments. I'm not really happy with the name. (Tag comments are +>> 'TODO', 'HACK' etc.) +>> +>> The thing that's really interresting for code completion is the +>> ICompilationUnit inside the ParsedDocument. This contains all +>> information. +>> +>> Regards +>> Mike +>> +>> +>> > Does anyone have a short overview of how the parser system works now? +>> > The optimal interactions between the parser, resolvers, and completion +>> > system seems a bit tough to grasp which is compounded by the lack of +>> > interface documentation. +>> > +>> > I'm trying to put together code completion for my cPython addin, but I'm +>> > unsure which project I should look at for an ideal example. Things +>> > appear to be in a sort of flux. +>> > +>> > Of particular interest is how the parser should interact with parsed +>> > documents, what Tag's are, and how the gui completion should interact +>> > with that. +>> > +>> > Thanks! +>> > +>> > -- Christian +>> > +>> > _______________________________________________ +>> > Monodevelop-devel-list mailing list +>> > Monodevelop-devel-list at lists.ximian.com +>> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080929/eb83afa1/attachment.html ++ + + +
Hi, + +> On Mon, Sep 29, 2008 at 3:38 PM, Christian Hergert +> <christian.hergert at gmail.com> wrote: +>> +>> I have a class that extends ParsedDocument. Do references inside that +>> class get persisted to the parser database? Or is this perhaps something +>> that i should have encapsulated in an ICompilationUnit. + +I /think/ any fields of objects that are [Serializable] will get +persisted, which includes all the collections that the base +ParsedDocument has. + +On Mon, Sep 29, 2008 at 7:29 PM, Christian Hergert +<christian.hergert at gmail.com> wrote: +> Ok, so after some further exploration, I think I understand the +> ICompilationUnit stuff. I was really hoping that the interface would expose +> information via IEnumerable's so that I could maintain data in my own format +> and yield requested data at will. It also seems that the ICompilationUnit +> is very much geared towards c#/.net. I'll just map things the best I can. + +ParsedDocument is designed to be language-agnostic. ICompilationUnit +is very much .NET-specific, so if you don't want to use it, you don't +have to. Have the field here is not ideal IMO, but my suggestion for a +.NET parse unit interface was not taken up. There's a thread of +discussion about this that you might be able to contribute to. + +The design so far has been pretty much driven by C#, so if you have +any suggestions to improve it, now would be the time to voice them, +before we start heading into the 2.0 betas. + +>> +>> As an example .. +>> +>> PythonParsedDocument : ParsedDocument { +>> PythonModule module; // hoping this gets persisted + +If what I suspect is correct, PythonModule would have to be +serializable. However, the DB is optimised/indexed for type lookup and +stuff, and this would obviously not work easily with custom +serializable classes. This may be something that we could improve. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
El dl 29 de 09 de 2008 a les 16:51 -0400, en/na Michael Hutchinson va +escriure: +> Hi everyone, +> +> Here are my current thoughts concerning per-project styles and +> policies, so that we can discuss it before I go ahead and implement +> it. I also have an number of questions that are interspersed +> throughout this email. +> +> Rationale +> ======= +> There are a number of settings and preferences in MD that should be +> customisable for different solutions/projects. Basically, anything +> that affects the style of the code you write should be able to be set +> for a particular project, since different projects have different +> styles and policies. I've lumped "Styles and Policies" together into +> one heading since I believe they are related. + +Regarding styles, I want to stress that they are "anything that affects +the style of the code you write", which means that settings such as +indent mode (auto, smart) are not styles. + +> +> Text Editor Settings +> ============== +> These are the ones that most people care about -- per-mimetype +> settings for the general text editor behaviour such as tabs-to-spaces, +> editor width, tab width, standard headers. Some languages may add to +> this, e.g. C# indenter behaviour, and in future things like +> auto-formatting. + +Indenter behavior and auto-formatting are not styles, and should not be +added to project preferences. On the other hand, formatting rules are +styles. + +About storing styles per-mimetype, I'm not sure this is needed. It makes +more sense to present styles to the user organized by file type, but at +a higher level than mime type. For example we could present settings for +C#, ASP.NET, XML. Those file types could be sub-divided in mime types if +we really need that level of detail. + +> There should also be a "default" style, and the +> per-mimetype settings should override this. +> +> * Should we allow users to add custom mimetypes for their own file +> formats, or just support the "major" text/code mimetypes registered in +> MD? + +I think we should allow binding mime types to file type categories +(e.g. .addin files to XML category). + +> * Should we list only the mimetypes used in the project? + +We should somehow filter out file types which don't make sense in a +given project. For example, ASP.NET styles should not be shown in a GTK# +project (although makes sense to show XML settings in all kind of +projects). + +> * For each mimetype, should there be a checkbox to override the +> "default" text style? Or should there be a UI for adding/removing text +> styles to the tree? + +I don't know how you plan to implement the GUI. IMO, style settings +could be implemented just like other project settings, using option +panels. By changing a setting you would be overriding it. There could be +a button for restoring default settings. + +> +> Policies +> ====== +> There are a number of other per-project settings that aren't quite +> styles, but also aren't really build options or project properties. +> I'm calling these "policies" for now. The only existing one is +> changelog policies; in future, we could add settings such as "pass +> tests before checkin", "check style before checkin", "must include +> changelog entry", etc. + +Sounds good. + +> +> Settings Infrastructure +> ================ +> Many of these settings may need to be overridable for individual +> projects within a solution, because a solution's projects may have +> been imported from elsewhere with different coding style. For this +> reason, we need an infrastructure that can be used to get the setting +> for a project, and if the setting has not been overridden, will grab +> the setting from the parent solution. +> +> * How important is this feature? + +I don't think it is important. + +> * How many of the settings really need to be overridable at project level? + +I don't see why there should be a restriction on that. + +> * Should settings be overridable at "solution folder" level too, hence +> allowing a cascade of settings? + +We could do it (although it is not so important). + +> * Should settings or group of settings be individually overridable? Or +> should it just allow a project to override *all* settings? Does this +> really need any granularity? + +Allow overriding at file type level is probably enough. + +> * Where should settings be stored? The solution file and the project +> files? I feel this is better than a .userprefs-like file, since it +> makes sure the settings stay with the project/solution. + +It has to be stored in the project file, since the idea is to share all +those settings with all developers, and that would not be possible if +you store it in userprefs. + +> * Should setting be duplicated in the project in case it's opened +> without the solution? Or should the project have a flag to say that it +> expects settings to be stored in a solution, so MD can warn when the +> solution isn't present? + +Since this is an uncommon case, I would just use the default settings. + +> * What settings do we default to when opening projects that don't +> contain settings Do we automatically add default settings to the +> solution files? Or fall back to a set of user preferences? + +All style and policy settings should be available as user preferences. +Those would be the settings to use when creating a new solution. + +> +> GUI Infrastructure +> ============= +> It's difficult to present all of these options in the GUI in a +> scalable way, particularly the per-mimetype editor settings +> * Should the settings be in the main "Project options" dialog or a +> separate "Styles and policies" dialog? The separate dialog has the +> advantage that the same dialog can be used to edit the user's named +> styles and default style. It would also help to not overload the +> setting treeview in the existing project options dialog. + +I think they should go in the project options dialog. We can have a +"Coding Style" category and add a subcategory for each file type. + +> * Should each panel have "use parent solution's style", "load/save +> named style" etc options? Or should these apply to all styles? + +Load/save can be done at project level. Overriding at file type level. + +> * VS has a setting panel that can be used to add "file types" and set +> the editing experience that's used for them. maybe we could do +> something similar with per-mimetype styles -- the top-level panel for +> editor setting would contain this list, and adding a file type would +> cause it and its options to appear in the tree. Files not handled this +> way would fall back to the "Other files" style (VS has an "All files" +> option which aggregates the common settings from all files, with +> tri-state checkboxes etc, but I feel this is overcomplex). + +In general, editing experience settings are not styles, they are about +editor behavior. However it makes sense to allow binding a mime type to +a known file type for which behavior and style settings can be set. + +> +> Named Styles +> ========== +> It should be possible to save a project's style, and apply this style +> to other solutions/projects. However, I don't think it's viable or +> desirable to synchronise these in any way. Once a project is created, +> its settings should remain constant unless they are explicitly +> changed. + +Agreed. + +> +> I also have a number of mockups on my whiteboard which aren't so easy +> to express in email :-) +> + +Cool, feel free to post. + +Lluis. + + ++ + + + + +
> * Should we allow users to add custom mimetypes for their own file +> formats, or just support the "major" text/code mimetypes registered in +> MD? +> * Should we list only the mimetypes used in the project? + +If the answer to the latter is yes, then the answer to the former +should also be yes. + +> * For each mimetype, should there be a checkbox to override the +> "default" text style? Or should there be a UI for adding/removing text +> styles to the tree? + +Probably it would be a good idea to have a store of different styles +created by the user. + +> Settings Infrastructure +> ================ +> Many of these settings may need to be overridable for individual +> projects within a solution, because a solution's projects may have +> been imported from elsewhere with different coding style. For this +> reason, we need an infrastructure that can be used to get the setting +> for a project, and if the setting has not been overridden, will grab +> the setting from the parent solution. +> +> * How important is this feature? + +IMO it's as important to have per-project settings as it is to have +per-solution settings. +As an example, I have a solution with some C# projects and a C +project. For external reasons, the coding standard for the C project +is different than for the C# project. I suspect that, as MD becomes +more mature and well-known as a solid, general-purpose IDE, there will +be more and more mixed-language solutions that will lend themselves to +different styles per project. + +> * How many of the settings really need to be overridable at project level? + +All of the ones that are overridable at the solution level. + +> * Where should settings be stored? The solution file and the project +> files? I feel this is better than a .userprefs-like file, since it +> makes sure the settings stay with the project/solution. + +Is there some way to do this such that the settings will be ignored +and won't be stripped if the project/solution is opened in another +IDE? + +> * Should setting be duplicated in the project in case it's opened +> without the solution? Or should the project have a flag to say that it +> expects settings to be stored in a solution, so MD can warn when the +> solution isn't present? + +I would think it makes sense to store the settings at the tree level +at which they're set. (Solutionwide => solution settings, +Project-specific=> project settings) + +> It should be possible to save a project's style, and apply this style +> to other solutions/projects. However, I don't think it's viable or +> desirable to synchronise these in any way. Once a project is created, +> its settings should remain constant unless they are explicitly +> changed. + +Agreed. + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + + + + +
On Tue, Sep 30, 2008 at 8:30 AM, Lluis Sanchez Gual <lluis at novell.com> wrote: +> El dl 29 de 09 de 2008 a les 16:51 -0400, en/na Michael Hutchinson va +> escriure: +>> Hi everyone, +>> +>> Here are my current thoughts concerning per-project styles and +>> policies, so that we can discuss it before I go ahead and implement +>> it. I also have an number of questions that are interspersed +>> throughout this email. +>> +>> Rationale +>> ======= +>> There are a number of settings and preferences in MD that should be +>> customisable for different solutions/projects. Basically, anything +>> that affects the style of the code you write should be able to be set +>> for a particular project, since different projects have different +>> styles and policies. I've lumped "Styles and Policies" together into +>> one heading since I believe they are related. +> +> Regarding styles, I want to stress that they are "anything that affects +> the style of the code you write", which means that settings such as +> indent mode (auto, smart) are not styles. + +Exactly, I should have been clearer. Another example: +* the presence of the column ruler is a user preference +* the /width/ of the column ruler is a per-project setting + +>> Text Editor Settings +>> ============== +>> These are the ones that most people care about -- per-mimetype +>> settings for the general text editor behaviour such as tabs-to-spaces, +>> editor width, tab width, standard headers. Some languages may add to +>> this, e.g. C# indenter behaviour, and in future things like +>> auto-formatting. +> +> Indenter behavior and auto-formatting are not styles, and should not be +> added to project preferences. On the other hand, formatting rules are +> styles. + +Yes, sorry for any ambiguity here. I meant the formatting behaviour of +the indenter/auto-formatter. + +> About storing styles per-mimetype, I'm not sure this is needed. It makes +> more sense to present styles to the user organized by file type, but at +> a higher level than mime type. For example we could present settings for +> C#, ASP.NET, XML. Those file types could be sub-divided in mime types if +> we really need that level of detail. +> +>> There should also be a "default" style, and the +>> per-mimetype settings should override this. +>> +>> * Should we allow users to add custom mimetypes for their own file +>> formats, or just support the "major" text/code mimetypes registered in +>> MD? +> +> I think we should allow binding mime types to file type categories +> (e.g. .addin files to XML category). + +Well, that what VS does, kinda -- it lets you bind arbitrary file +extensions to editors, e.g. the C#, XML, XAML editors... + +However, if we have a panel to do something like that, it's almost +trivial to allow each kind to have its own style. + +>> * Should we list only the mimetypes used in the project? +> +> We should somehow filter out file types which don't make sense in a +> given project. For example, ASP.NET styles should not be shown in a GTK# +> project (although makes sense to show XML settings in all kind of +> projects). + +It won't be very easy. Since styles will mostly be edited at the +solution level, the solution's dialog is going to have to scan all +child projects for file types. + +>> * For each mimetype, should there be a checkbox to override the +>> "default" text style? Or should there be a UI for adding/removing text +>> styles to the tree? +> +> I don't know how you plan to implement the GUI. IMO, style settings +> could be implemented just like other project settings, using option +> panels. By changing a setting you would be overriding it. There could be +> a button for restoring default settings. + +Unfortunately that doesn't make the settings cascade behaviour +obvious. I'd prefer to have the user explicitly override the parent +solution's settings. + +>> Policies +>> ====== +>> There are a number of other per-project settings that aren't quite +>> styles, but also aren't really build options or project properties. +>> I'm calling these "policies" for now. The only existing one is +>> changelog policies; in future, we could add settings such as "pass +>> tests before checkin", "check style before checkin", "must include +>> changelog entry", etc. +> +> Sounds good. +> +>> +>> Settings Infrastructure +>> ================ +>> Many of these settings may need to be overridable for individual +>> projects within a solution, because a solution's projects may have +>> been imported from elsewhere with different coding style. For this +>> reason, we need an infrastructure that can be used to get the setting +>> for a project, and if the setting has not been overridden, will grab +>> the setting from the parent solution. +>> +>> * How important is this feature? +> +> I don't think it is important. + +You don't think it's important for project to be able to override +solution-level settings? I've spoken with a few people who disagree -- +the main use case seems to have been importe + +>> * How many of the settings really need to be overridable at project level? +> +> I don't see why there should be a restriction on that. + +Well, if there are settings that nobody ever wants to override, then +making them overridable will add unnecessary UI. + +>> * Should settings be overridable at "solution folder" level too, hence +>> allowing a cascade of settings? +> +> We could do it (although it is not so important). + +Yes, I don't think it so important, though it's probably not hard. So, +is it worth the effort (and UI clutter)? + +>> * Should settings or group of settings be individually overridable? Or +>> should it just allow a project to override *all* settings? Does this +>> really need any granularity? +> +> Allow overriding at file type level is probably enough. +> +>> * Where should settings be stored? The solution file and the project +>> files? I feel this is better than a .userprefs-like file, since it +>> makes sure the settings stay with the project/solution. +> +> It has to be stored in the project file, since the idea is to share all +> those settings with all developers, and that would not be possible if +> you store it in userprefs. + +The actual .userprefs files is right out, of course, since it should +never be shared. I meant some kind of userprefs-like file, e.g. +solutionname.style, to avoid cluttering the build files. However, +having it in the project file so that it's impossible NOT to share it +:-) + +>> * Should setting be duplicated in the project in case it's opened +>> without the solution? Or should the project have a flag to say that it +>> expects settings to be stored in a solution, so MD can warn when the +>> solution isn't present? +> +> Since this is an uncommon case, I would just use the default settings. +> +>> * What settings do we default to when opening projects that don't +>> contain settings Do we automatically add default settings to the +>> solution files? Or fall back to a set of user preferences? +> +> All style and policy settings should be available as user preferences. +> Those would be the settings to use when creating a new solution. + +Well, yes, that's a given; the user must be able to have a default +style for new projects. The question is whether we should write the +settings to the files automatically in the case where there are none +-- all MD-created projects should have style settings baked in upon +creation, but files from other sources would not. + +It would also be nice to have a "smart default" mode that would infer +some settings (tabs/spaces) from the files. + +> +>> +>> GUI Infrastructure +>> ============= +>> It's difficult to present all of these options in the GUI in a +>> scalable way, particularly the per-mimetype editor settings +>> * Should the settings be in the main "Project options" dialog or a +>> separate "Styles and policies" dialog? The separate dialog has the +>> advantage that the same dialog can be used to edit the user's named +>> styles and default style. It would also help to not overload the +>> setting treeview in the existing project options dialog. +> +> I think they should go in the project options dialog. We can have a +> "Coding Style" category and add a subcategory for each file type. + +Don't forget that each file type will have sub-options, so the tree +will be at least three deep. + +I would like the main panel for the "Coding Style" category to be used +to add / override / load / save file types, and dynamically insert the +corresponding subcategories into the tree. + +I'm still not sure how this would work for allowing the user to manage +styles outside of projects. + +>> * Should each panel have "use parent solution's style", "load/save +>> named style" etc options? Or should these apply to all styles? +> +> Load/save can be done at project level. Overriding at file type level. + +So it won't be possible to save just (e.g.) a C# style; you'd have to +save everything? + +>> * VS has a setting panel that can be used to add "file types" and set +>> the editing experience that's used for them. maybe we could do +>> something similar with per-mimetype styles -- the top-level panel for +>> editor setting would contain this list, and adding a file type would +>> cause it and its options to appear in the tree. Files not handled this +>> way would fall back to the "Other files" style (VS has an "All files" +>> option which aggregates the common settings from all files, with +>> tri-state checkboxes etc, but I feel this is overcomplex). +> +> In general, editing experience settings are not styles, they are about +> editor behavior. However it makes sense to allow binding a mime type to +> a known file type for which behavior and style settings can be set. + +Yes, I meant use a similar UI but for styles, not editor experiences. + +>> Named Styles +>> ========== +>> It should be possible to save a project's style, and apply this style +>> to other solutions/projects. However, I don't think it's viable or +>> desirable to synchronise these in any way. Once a project is created, +>> its settings should remain constant unless they are explicitly +>> changed. +> +> Agreed. +> +>> +>> I also have a number of mockups on my whiteboard which aren't so easy +>> to express in email :-) +>> +> +> Cool, feel free to post. + +It'll probably be better when I have some actual stetic mockups or code. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
On Tue, Sep 30, 2008 at 8:47 AM, Levi Bard +<taktaktaktaktaktaktaktaktaktak at gmail.com> wrote: +>> * Should we allow users to add custom mimetypes for their own file +>> formats, or just support the "major" text/code mimetypes registered in +>> MD? +>> * Should we list only the mimetypes used in the project? +> +> If the answer to the latter is yes, then the answer to the former +> should also be yes. +> +>> * For each mimetype, should there be a checkbox to override the +>> "default" text style? Or should there be a UI for adding/removing text +>> styles to the tree? +> +> Probably it would be a good idea to have a store of different styles +> created by the user. + +See "named styles" :) + +>> Settings Infrastructure +>> ================ +>> Many of these settings may need to be overridable for individual +>> projects within a solution, because a solution's projects may have +>> been imported from elsewhere with different coding style. For this +>> reason, we need an infrastructure that can be used to get the setting +>> for a project, and if the setting has not been overridden, will grab +>> the setting from the parent solution. +>> +>> * How important is this feature? +> +> IMO it's as important to have per-project settings as it is to have +> per-solution settings. +> As an example, I have a solution with some C# projects and a C +> project. For external reasons, the coding standard for the C project +> is different than for the C# project. I suspect that, as MD becomes +> more mature and well-known as a solid, general-purpose IDE, there will +> be more and more mixed-language solutions that will lend themselves to +> different styles per project. + +Mixed-language solutions does NOT mean you need to override things at +the project level. I think the only real case for project-level +overriding is when different project use the same language but +different styles. + +>> * How many of the settings really need to be overridable at project level? +> +> All of the ones that are overridable at the solution level. + +Including things like commit policies? + +My question was really meant as, should we make everything +overridable, or evaluate it on a per-case basis? Allowing the user to +override things adds UI, which just clutters things when it's not +necessary. + +>> * Where should settings be stored? The solution file and the project +>> files? I feel this is better than a .userprefs-like file, since it +>> makes sure the settings stay with the project/solution. +> +> Is there some way to do this such that the settings will be ignored +> and won't be stripped if the project/solution is opened in another +> IDE? + +We can write settings into MSBuild files so that VS won't touch them. + +>> * Should setting be duplicated in the project in case it's opened +>> without the solution? Or should the project have a flag to say that it +>> expects settings to be stored in a solution, so MD can warn when the +>> solution isn't present? +> +> I would think it makes sense to store the settings at the tree level +> at which they're set. (Solutionwide => solution settings, +> Project-specific=> project settings) + +In terms of storage, that makes perfect sense. The potential problem +is when a project is opened independently of the solution. + +>> It should be possible to save a project's style, and apply this style +>> to other solutions/projects. However, I don't think it's viable or +>> desirable to synchronise these in any way. Once a project is created, +>> its settings should remain constant unless they are explicitly +>> changed. +> +> Agreed. +> +> -- +> http://homes.eff.org/~barlow/EconomyOfIdeas.html +> http://www.dreamsongs.com/MobSoftware.html +> http://www.gnu.org/philosophy/shouldbefree.html +> + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
While I think its a worthy idea to remove the tight coupling to .NET logic, +I'm not going to volunteer to do it. I'll work around it for the time being +and it seems like a notable post-2.0 feature. + +-- Christian + +On Mon, Sep 29, 2008 at 9:59 PM, Michael Hutchinson < +m.j.hutchinson at gmail.com> wrote: + +> Hi, +> +> > On Mon, Sep 29, 2008 at 3:38 PM, Christian Hergert +> > <christian.hergert at gmail.com> wrote: +> >> +> >> I have a class that extends ParsedDocument. Do references inside that +> >> class get persisted to the parser database? Or is this perhaps +> something +> >> that i should have encapsulated in an ICompilationUnit. +> +> I /think/ any fields of objects that are [Serializable] will get +> persisted, which includes all the collections that the base +> ParsedDocument has. +> +> On Mon, Sep 29, 2008 at 7:29 PM, Christian Hergert +> <christian.hergert at gmail.com> wrote: +> > Ok, so after some further exploration, I think I understand the +> > ICompilationUnit stuff. I was really hoping that the interface would +> expose +> > information via IEnumerable's so that I could maintain data in my own +> format +> > and yield requested data at will. It also seems that the +> ICompilationUnit +> > is very much geared towards c#/.net. I'll just map things the best I +> can. +> +> ParsedDocument is designed to be language-agnostic. ICompilationUnit +> is very much .NET-specific, so if you don't want to use it, you don't +> have to. Have the field here is not ideal IMO, but my suggestion for a +> .NET parse unit interface was not taken up. There's a thread of +> discussion about this that you might be able to contribute to. +> +> The design so far has been pretty much driven by C#, so if you have +> any suggestions to improve it, now would be the time to voice them, +> before we start heading into the 2.0 betas. +> +> >> +> >> As an example .. +> >> +> >> PythonParsedDocument : ParsedDocument { +> >> PythonModule module; // hoping this gets persisted +> +> If what I suspect is correct, PythonModule would have to be +> serializable. However, the DB is optimised/indexed for type lookup and +> stuff, and this would obviously not work easily with custom +> serializable classes. This may be something that we could improve. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20080930/588771dd/attachment.html ++ + +
El dt 30 de 09 de 2008 a les 14:18 -0400, en/na Michael Hutchinson va +escriure: +> On Tue, Sep 30, 2008 at 8:30 AM, Lluis Sanchez Gual <lluis at novell.com> wrote: +> > El dl 29 de 09 de 2008 a les 16:51 -0400, en/na Michael Hutchinson va +> > escriure: +> >> Hi everyone, +> >> +> >> Here are my current thoughts concerning per-project styles and +> >> policies, so that we can discuss it before I go ahead and implement +> >> it. I also have an number of questions that are interspersed +> >> throughout this email. +> >> +> >> Rationale +> >> ======= +> >> There are a number of settings and preferences in MD that should be +> >> customisable for different solutions/projects. Basically, anything +> >> that affects the style of the code you write should be able to be set +> >> for a particular project, since different projects have different +> >> styles and policies. I've lumped "Styles and Policies" together into +> >> one heading since I believe they are related. +> > +> > Regarding styles, I want to stress that they are "anything that affects +> > the style of the code you write", which means that settings such as +> > indent mode (auto, smart) are not styles. +> +> Exactly, I should have been clearer. Another example: +> * the presence of the column ruler is a user preference +> * the /width/ of the column ruler is a per-project setting +> +> >> Text Editor Settings +> >> ============== +> >> These are the ones that most people care about -- per-mimetype +> >> settings for the general text editor behaviour such as tabs-to-spaces, +> >> editor width, tab width, standard headers. Some languages may add to +> >> this, e.g. C# indenter behaviour, and in future things like +> >> auto-formatting. +> > +> > Indenter behavior and auto-formatting are not styles, and should not be +> > added to project preferences. On the other hand, formatting rules are +> > styles. +> +> Yes, sorry for any ambiguity here. I meant the formatting behaviour of +> the indenter/auto-formatter. +> +> > About storing styles per-mimetype, I'm not sure this is needed. It makes +> > more sense to present styles to the user organized by file type, but at +> > a higher level than mime type. For example we could present settings for +> > C#, ASP.NET, XML. Those file types could be sub-divided in mime types if +> > we really need that level of detail. +> > +> >> There should also be a "default" style, and the +> >> per-mimetype settings should override this. +> >> +> >> * Should we allow users to add custom mimetypes for their own file +> >> formats, or just support the "major" text/code mimetypes registered in +> >> MD? +> > +> > I think we should allow binding mime types to file type categories +> > (e.g. .addin files to XML category). +> +> Well, that what VS does, kinda -- it lets you bind arbitrary file +> extensions to editors, e.g. the C#, XML, XAML editors... +> +> However, if we have a panel to do something like that, it's almost +> trivial to allow each kind to have its own style. +> +> >> * Should we list only the mimetypes used in the project? +> > +> > We should somehow filter out file types which don't make sense in a +> > given project. For example, ASP.NET styles should not be shown in a GTK# +> > project (although makes sense to show XML settings in all kind of +> > projects). +> +> It won't be very easy. Since styles will mostly be edited at the +> solution level, the solution's dialog is going to have to scan all +> child projects for file types. + +Doesn't sound that hard ;) + +> +> >> * For each mimetype, should there be a checkbox to override the +> >> "default" text style? Or should there be a UI for adding/removing text +> >> styles to the tree? +> > +> > I don't know how you plan to implement the GUI. IMO, style settings +> > could be implemented just like other project settings, using option +> > panels. By changing a setting you would be overriding it. There could be +> > a button for restoring default settings. +> +> Unfortunately that doesn't make the settings cascade behaviour +> obvious. I'd prefer to have the user explicitly override the parent +> solution's settings. + +I would need to see a gui mockup to understand what you have in mind. + +> +> >> Policies +> >> ====== +> >> There are a number of other per-project settings that aren't quite +> >> styles, but also aren't really build options or project properties. +> >> I'm calling these "policies" for now. The only existing one is +> >> changelog policies; in future, we could add settings such as "pass +> >> tests before checkin", "check style before checkin", "must include +> >> changelog entry", etc. +> > +> > Sounds good. +> > +> >> +> >> Settings Infrastructure +> >> ================ +> >> Many of these settings may need to be overridable for individual +> >> projects within a solution, because a solution's projects may have +> >> been imported from elsewhere with different coding style. For this +> >> reason, we need an infrastructure that can be used to get the setting +> >> for a project, and if the setting has not been overridden, will grab +> >> the setting from the parent solution. +> >> +> >> * How important is this feature? +> > +> > I don't think it is important. +> +> You don't think it's important for project to be able to override +> solution-level settings? I've spoken with a few people who disagree -- +> the main use case seems to have been importe + +I misread that paragraph. I agree it's important to have settings in the +solution and be able to override them in projects. I was thinking about +whether the full settings should be stored in the project or not, but +that's a different issue. + +> +> >> * How many of the settings really need to be overridable at project level? +> > +> > I don't see why there should be a restriction on that. +> +> Well, if there are settings that nobody ever wants to override, then +> making them overridable will add unnecessary UI. + +In the idea of implementation I have, you would use the same gui for +setting and for overriding properties, so that would not be a problem. + +> +> >> * Should settings be overridable at "solution folder" level too, hence +> >> allowing a cascade of settings? +> > +> > We could do it (although it is not so important). +> +> Yes, I don't think it so important, though it's probably not hard. So, +> is it worth the effort (and UI clutter)? +> +> >> * Should settings or group of settings be individually overridable? Or +> >> should it just allow a project to override *all* settings? Does this +> >> really need any granularity? +> > +> > Allow overriding at file type level is probably enough. +> > +> >> * Where should settings be stored? The solution file and the project +> >> files? I feel this is better than a .userprefs-like file, since it +> >> makes sure the settings stay with the project/solution. +> > +> > It has to be stored in the project file, since the idea is to share all +> > those settings with all developers, and that would not be possible if +> > you store it in userprefs. +> +> The actual .userprefs files is right out, of course, since it should +> never be shared. I meant some kind of userprefs-like file, e.g. +> solutionname.style, to avoid cluttering the build files. However, +> having it in the project file so that it's impossible NOT to share it +> :-) +> +> >> * Should setting be duplicated in the project in case it's opened +> >> without the solution? Or should the project have a flag to say that it +> >> expects settings to be stored in a solution, so MD can warn when the +> >> solution isn't present? +> > +> > Since this is an uncommon case, I would just use the default settings. +> > +> >> * What settings do we default to when opening projects that don't +> >> contain settings Do we automatically add default settings to the +> >> solution files? Or fall back to a set of user preferences? +> > +> > All style and policy settings should be available as user preferences. +> > Those would be the settings to use when creating a new solution. +> +> Well, yes, that's a given; the user must be able to have a default +> style for new projects. The question is whether we should write the +> settings to the files automatically in the case where there are none +> -- all MD-created projects should have style settings baked in upon +> creation, but files from other sources would not. +> +> It would also be nice to have a "smart default" mode that would infer +> some settings (tabs/spaces) from the files. +> +> > +> >> +> >> GUI Infrastructure +> >> ============= +> >> It's difficult to present all of these options in the GUI in a +> >> scalable way, particularly the per-mimetype editor settings +> >> * Should the settings be in the main "Project options" dialog or a +> >> separate "Styles and policies" dialog? The separate dialog has the +> >> advantage that the same dialog can be used to edit the user's named +> >> styles and default style. It would also help to not overload the +> >> setting treeview in the existing project options dialog. +> > +> > I think they should go in the project options dialog. We can have a +> > "Coding Style" category and add a subcategory for each file type. +> +> Don't forget that each file type will have sub-options, so the tree +> will be at least three deep. +> +> I would like the main panel for the "Coding Style" category to be used +> to add / override / load / save file types, and dynamically insert the +> corresponding subcategories into the tree. +> +> I'm still not sure how this would work for allowing the user to manage +> styles outside of projects. +> +> >> * Should each panel have "use parent solution's style", "load/save +> >> named style" etc options? Or should these apply to all styles? +> > +> > Load/save can be done at project level. Overriding at file type level. +> +> So it won't be possible to save just (e.g.) a C# style; you'd have to +> save everything? +> +> >> * VS has a setting panel that can be used to add "file types" and set +> >> the editing experience that's used for them. maybe we could do +> >> something similar with per-mimetype styles -- the top-level panel for +> >> editor setting would contain this list, and adding a file type would +> >> cause it and its options to appear in the tree. Files not handled this +> >> way would fall back to the "Other files" style (VS has an "All files" +> >> option which aggregates the common settings from all files, with +> >> tri-state checkboxes etc, but I feel this is overcomplex). +> > +> > In general, editing experience settings are not styles, they are about +> > editor behavior. However it makes sense to allow binding a mime type to +> > a known file type for which behavior and style settings can be set. +> +> Yes, I meant use a similar UI but for styles, not editor experiences. +> +> >> Named Styles +> >> ========== +> >> It should be possible to save a project's style, and apply this style +> >> to other solutions/projects. However, I don't think it's viable or +> >> desirable to synchronise these in any way. Once a project is created, +> >> its settings should remain constant unless they are explicitly +> >> changed. +> > +> > Agreed. +> > +> >> +> >> I also have a number of mockups on my whiteboard which aren't so easy +> >> to express in email :-) +> >> +> > +> > Cool, feel free to post. +> +> It'll probably be better when I have some actual stetic mockups or code. +> + +Let's discuss all this when I come back from holidays. + +Lluis. + + ++ + +
Starting: Wed Sep 10 00:24:27 EDT 2008
+ Ending: Tue Sep 30 17:20:41 EDT 2008
+ Messages: 19
+
+ Last message date:
+ Tue Sep 30 17:20:41 EDT 2008
+ Archived on: Tue Sep 30 17:20:58 EDT 2008
+
+
+
Starting: Wed Sep 10 00:24:27 EDT 2008
+ Ending: Tue Sep 30 17:20:41 EDT 2008
+ Messages: 19
+
+ Last message date:
+ Tue Sep 30 17:20:41 EDT 2008
+ Archived on: Tue Sep 30 17:20:58 EDT 2008
+
+
+
Starting: Wed Sep 10 00:24:27 EDT 2008
+ Ending: Tue Sep 30 17:20:41 EDT 2008
+ Messages: 19
+
+ Last message date:
+ Tue Sep 30 17:20:41 EDT 2008
+ Archived on: Tue Sep 30 17:20:58 EDT 2008
+
+
+
Starting: Wed Sep 10 00:24:27 EDT 2008
+ Ending: Tue Sep 30 17:20:41 EDT 2008
+ Messages: 19
+
+ Last message date:
+ Tue Sep 30 17:20:41 EDT 2008
+ Archived on: Tue Sep 30 17:20:58 EDT 2008
+
+
+
Starting: Wed Sep 10 00:24:27 EDT 2008
+ Ending: Tue Sep 30 17:20:41 EDT 2008
+ Messages: 19
+
+ Last message date:
+ Tue Sep 30 17:20:41 EDT 2008
+ Archived on: Tue Sep 30 17:20:58 EDT 2008
+
+
+
+Hi: + Attached is a patch to add Sql Syntax Highlighing support for MonoDevelop.Database Addin. + +Please, could someone review/commit it? + +Lucian0 + +_________________________________________________________________ +Get 5 GB of storage with Windows Live Hotmail. +http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090402/177e40cb/attachment-0001.html +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: MonoDevelop.Database.Components.patch +Type: text/x-patch +Size: 12500 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090402/177e40cb/attachment-0001.bin ++ + + +
2009/4/2 Luciano _ <lnc19 at hotmail.com>: +> Hi: +> Attached is a patch to add Sql Syntax Highlighing support for +> MonoDevelop.Database Addin. +> +> Please, could someone review/commit it? + +Patch looks good, though the syntax file's header says +"CSharpSyntaxMode" and the CSProje files seems to have lost a lot of +references. I'll tidy it up and commit tomorrow. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
+Sorry, but I'm sending the patch again to add "non-sensitive" Highlighting support. +Please if someone could review/commit. +I have 2 more related patch to send after this and other that i have pending on bugzilla. + +Bye + + +From: lnc19 at hotmail.com +To: monodevelop-devel-list at lists.ximian.com +Date: Thu, 2 Apr 2009 05:14:42 +0000 +Subject: [Monodevelop-devel] PATCH - Sql Syntax Highlighting support. + + + + + + + + +Hi: + Attached is a patch to add Sql Syntax Highlighing support for MonoDevelop.Database Addin. + +Please, could someone review/commit it? + +Lucian0 + +Get 5 GB of storage with Windows Live Hotmail. Sign up today. +_________________________________________________________________ +Get 5 GB of storage with Windows Live Hotmail. +http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090403/31d7735f/attachment.html +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: MonoDevelop.Database.Components.patch +Type: text/x-patch +Size: 14688 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090403/31d7735f/attachment.bin ++ + + + + + + +
+I sen't other patch a couple of hours ago, this is the correct one, beacause the previous patch isn't case-sensitive. + +Please apply the second patch, and if you need i could try to correct your suggestions. + + +Thanks. + + + + +> Date: Thu, 2 Apr 2009 20:34:18 -0400 +> Subject: Re: [Monodevelop-devel] PATCH - Sql Syntax Highlighting support. +> From: m.j.hutchinson at gmail.com +> To: lnc19 at hotmail.com +> CC: monodevelop-devel-list at lists.ximian.com +> +> 2009/4/2 Luciano _ <lnc19 at hotmail.com>: +> > Hi: +> > Attached is a patch to add Sql Syntax Highlighing support for +> > MonoDevelop.Database Addin. +> > +> > Please, could someone review/commit it? +> +> Patch looks good, though the syntax file's header says +> "CSharpSyntaxMode" and the CSProje files seems to have lost a lot of +> references. I'll tidy it up and commit tomorrow. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com + +_________________________________________________________________ +Stay up to date on your PC, the Web, and your mobile phone with Windows Live +http://clk.atdmt.com/MRT/go/119462413/direct/01/ +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090403/68aec2db/attachment-0001.html ++ + + +
+Hi Michael: + I can send you a new patch with your suggestion but i will attach a couple of lines modified, because i keep improving some other stuff and i modified some other files on the same project. What do you prefer? I send another patch with this changes to? +Other question: i modified 4 projects within the same "sort of change", i mean, in order to make "Create Table" to work on MD i modified 4 diferents projects (All are Mono.Database Sub-projects, but it is a big change) Do i send one patch file? or diferent files? + +Thanks! + +From: lnc19 at hotmail.com +To: m.j.hutchinson at gmail.com +Date: Fri, 3 Apr 2009 01:52:37 +0000 +CC: monodevelop-devel-list at lists.ximian.com +Subject: Re: [Monodevelop-devel] PATCH - Sql Syntax Highlighting support. + + + + + + + + +I sen't other patch a couple of hours ago, this is the correct one, beacause the previous patch isn't case-sensitive. + +Please apply the second patch, and if you need i could try to correct your suggestions. + + +Thanks. + + + + +> Date: Thu, 2 Apr 2009 20:34:18 -0400 +> Subject: Re: [Monodevelop-devel] PATCH - Sql Syntax Highlighting support. +> From: m.j.hutchinson at gmail.com +> To: lnc19 at hotmail.com +> CC: monodevelop-devel-list at lists.ximian.com +> +> 2009/4/2 Luciano _ <lnc19 at hotmail.com>: +> > Hi: +> > Attached is a patch to add Sql Syntax Highlighing support for +> > MonoDevelop.Database Addin. +> > +> > Please, could someone review/commit it? +> +> Patch looks good, though the syntax file's header says +> "CSharpSyntaxMode" and the CSProje files seems to have lost a lot of +> references. I'll tidy it up and commit tomorrow. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com + + Stay up to date on your PC, the Web, and your mobile phone with Windows Live +_________________________________________________________________ +Get 5 GB of storage with Windows Live Hotmail. +http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090406/f81b1d11/attachment.html ++ + + +
On Sun, Apr 5, 2009 at 9:46 PM, Luciano _ <lnc19 at hotmail.com> wrote: +> +> I can send you a new patch with your suggestion but i +> will attach a couple of lines modified, because i keep improving some other +> stuff and i modified some other files on the same project. What do you +> prefer? I send another patch with this changes to? +> Other question: i modified 4 projects within the same "sort of change", i +> mean, in order to make "Create Table" to work on MD i modified 4 diferents +> projects (All are Mono.Database Sub-projects, but it is a big change) Do i +> send one patch file? or diferent files? + +Reviewed and committed the updated patch, thanks! + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Hi. + +With the website redesign old uri: +http://www.monodevelop.com/Inotify_Watches_Limit +no longer works. www prefix must be omited now. + +Attached is a patch ;-) + + +greets +silk +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: md-inotify-url.patch +Type: text/x-diff +Size: 850 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090416/45f15c94/attachment.bin ++ + + + + +
2009/4/16 Grzegorz Sobanski <silk at boktor.net>: +> Hi. +> +> With the website redesign old uri: +> http://www.monodevelop.com/Inotify_Watches_Limit +> no longer works. www prefix must be omited now. +> +> Attached is a patch ;-) + +Committed, thanks! + +I also fixed the server's redirect directive, so it's including the +URL's path. It was meant to since the switch, but there was a missing +capture... + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + +
Hi, + +I am trying to fix assembly references in Moonlight [app/lib] projects, +which are regarded as pointing to missing ones. I guessed that they +are expected as wrong versions and hence added assembly versions +(like there is in asp.net addin), as the attached patch, but it does +*not* seem to fix the issue. +So I wonder if references to 2.1 assemblies are resolved successfully +in MD now. Any idea how to fix this issue? + +Or even better, it would be nicer if we can simply load Silverlight +projects in moonlight, either as a moonlight project or new different +one to replace (or coexist?) current ones. + +Atsushi Eno +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: moonlight-project-reference-fix.patch +Type: text/x-patch +Size: 4041 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090410/ef330d64/attachment-0001.bin ++ + + +
2009/4/10 Atsushi Eno <atsushieno at veritas-vos-liberabit.com>: +> +> I am trying to fix assembly references in Moonlight [app/lib] projects, +> which are regarded as pointing to missing ones. I guessed that they +> are expected as wrong versions and hence added assembly versions +> (like there is in asp.net addin), as the attached patch, but it does +> *not* seem to fix the issue. +> So I wonder if references to 2.1 assemblies are resolved successfully +> in MD now. Any idea how to fix this issue? + +In MD trunk it works for me. + +Do you have the Moonlight assemblies installed to ~/lib/mono/2.1/? + +> Or even better, it would be nicer if we can simply load Silverlight +> projects in moonlight, either as a moonlight project or new different +> one to replace (or coexist?) current ones. + +You can already. I just tested opening a VS-created Silverlight +project and it still works. + +Building xaps doesn't work yet, but MD can create/load Silverlight +projects and compile Silverlight library projects. Also, code +completion (including simple XAML code completion) uses the 2.1 +assemblies. And there's even a xamlg-based parser that injects +codebehind partial classes into MD's code completion DOM. + +The missing parts of Moonlight/Silverlight support are: +* xamlg invocation +* respack invocation +* xap manifest generation +* xap zipping +* generating host HTML page for previewing the xap + +The xamlg invocation is the blocker, since it requires modifying MD +core, so that the compilation pipeline supports building files that +aren't part of the project + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Just for the fun of it i have implemented a few refactorings in monodevelop +last weekend (I have blogged about the implementation of one of the +simplest: +http://intellect.dk/post/Implementing-Generate-Constructor-refactoring-in-MonoDevelop.aspx). +Today i fired up this list and found a discussion from november about +Mike Krüger starting to refactor the refactorings: + +http://lists.ximian.com/pipermail/monodevelop-devel-list/2008-November/000057.html + +What are progress on this, i don't see anything in trunk or in any branches +i could think of (mkrueger and monodevelop)? + +And another question: The TODO list on +http://monodevelop.com/Developers/TODO seems out of date, if we take the +refactoring for example rename and encapsulate field are already +implemented. Who maintains this list? + +And is it correct that this is the development list, there seems to be a lot +of development related questions on the monodevelop-list as well? + + +-- +Jakob Andersen +http://intellect.dk/ +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090430/f0cd7c34/attachment.html ++ + + +
2009/4/29 Jakob Tikjøb Andersen <jta at miracleas.dk>: +> Just for the fun of it i have implemented a few refactorings in monodevelop +> last weekend (I have blogged about the implementation of one of the +> simplest: +> http://intellect.dk/post/Implementing-Generate-Constructor-refactoring-in-MonoDevelop.aspx + +Hey, that's a very cool article and addin! + +We should have a place on the MonoDvelop website to link to things like this. + +> ). Today i fired up this list and found a discussion from november about +> Mike Krüger starting to refactor the refactorings: +> +> http://lists.ximian.com/pipermail/monodevelop-devel-list/2008-November/000057.html +> +> What are progress on this, i don't see anything in trunk or in any branches +> i could think of (mkrueger and monodevelop)? + +Not much has happened in that area, unfortunately, apart from a few +stubs in MonoDevelop.Projects.Dom.Refactoring. + +We (the core MD team) was working on stabilising MonoDevelop 2.0 until +mid-March, and since then we've been busy on other areas of MD, in +particular the Mac and Windows ports. + +Interestingly, refactoring seems to be the most popular area for +contributing to MD 2.0. There's one other refactoring addin I'm aware +of (http://twitter.com/agileguy/statuses/1607907629), and lengthy +planning/discussions about a resharper-like addin, so it seems to me +that it would be good to get some of the core infrastructure done +soon. + +> And another question: The TODO list on +> http://monodevelop.com/Developers/TODO seems out of date, if we take the +> refactoring for example rename and encapsulate field are already +> implemented. Who maintains this list? + +That list hasn't had a maintainer for a while, unfortunately. It's at +least 18 months out of date (both those features were in MD 1.0). + +> And is it correct that this is the development list, there seems to be a lot +> of development related questions on the monodevelop-list as well? + +Yes, this is the correct list for discussion about developing addins +and MD itself :) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Thu, Apr 30, 2009 at 3:55 AM, Michael Hutchinson < +m.j.hutchinson at gmail.com> wrote: + +> 2009/4/29 Jakob Tikjøb Andersen <jta at miracleas.dk>: +> Hey, that's a very cool article and addin! +> + +Thanks a lot, i have a few other already implemented for extracting method +etc. i will try to make them patch ready (translation of UI and a few other +things) and submit them. + + + +> Not much has happened in that area, unfortunately, apart from a few +> stubs in MonoDevelop.Projects.Dom.Refactoring. + + +Okay, I will check it out to see if it reveals intentions for the future, if +not i might ask here or come with a suggestion for a structure. + + +> Interestingly, refactoring seems to be the most popular area for +> contributing to MD 2.0. There's one other refactoring addin I'm aware +> of (http://twitter.com/agileguy/statuses/1607907629), and lengthy +> planning/discussions about a resharper-like addin, so it seems to me +> that it would be good to get some of the core infrastructure done +> soon. + + +The reason im interreseted in refactorings is that it on my end is the one +thing i miss before i can use MonoDevelop effectively in my daily work. I do +TDD/BDD and really have getting used to refactoring tools generating most of +the basic code constructs for me while i run my tests, and it is pretty +killing for my productivity to not have these. + +But when they are in place i might find a new aray i thing needs improvement +for instance integration with specification framework etc. I think most +people have it this way, they wan't to help out but prefer to do it on +features they miss themselves :-) + +-- +Jakob Tikjøb Andersen ++45 25 277 105 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090430/30932a1f/attachment.html ++ + +
Starting: Thu Apr 2 01:14:42 EDT 2009
+ Ending: Thu Apr 30 08:31:20 EDT 2009
+ Messages: 13
+
+ Last message date:
+ Thu Apr 30 08:31:20 EDT 2009
+ Archived on: Thu Apr 30 08:31:32 EDT 2009
+
+
+
Starting: Thu Apr 2 01:14:42 EDT 2009
+ Ending: Thu Apr 30 08:31:20 EDT 2009
+ Messages: 13
+
+ Last message date:
+ Thu Apr 30 08:31:20 EDT 2009
+ Archived on: Thu Apr 30 08:31:32 EDT 2009
+
+
+
Starting: Thu Apr 2 01:14:42 EDT 2009
+ Ending: Thu Apr 30 08:31:20 EDT 2009
+ Messages: 13
+
+ Last message date:
+ Thu Apr 30 08:31:20 EDT 2009
+ Archived on: Thu Apr 30 08:31:32 EDT 2009
+
+
+
Starting: Thu Apr 2 01:14:42 EDT 2009
+ Ending: Thu Apr 30 08:31:20 EDT 2009
+ Messages: 13
+
+ Last message date:
+ Thu Apr 30 08:31:20 EDT 2009
+ Archived on: Thu Apr 30 08:31:32 EDT 2009
+
+
+
Starting: Thu Apr 2 01:14:42 EDT 2009
+ Ending: Thu Apr 30 08:31:20 EDT 2009
+ Messages: 13
+
+ Last message date:
+ Thu Apr 30 08:31:20 EDT 2009
+ Archived on: Thu Apr 30 08:31:32 EDT 2009
+
+
+
Same process as usual. + +-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: iworkbench_iworkbenchlayout_rewrite.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090804/f66400f6/attachment.pl ++ + + +
same process as usual. +-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: tipoftheday_tipofthedaystarthandler.diff +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090804/dac87d1d/attachment-0001.pl ++ + + + +
Hello all. I have wanted to contribute to Mono-Develop for sometime now; and +have been dabbling and learning the ropes. Since I now have free time, I +figured that I would start small. Mainly pick a few of the 'small task' todo +action items. I have create a New Class Wizard; but I am unsure of where to +put it. Should I merge it the main Monodevelop.IDE project or should I keep +it as an Add-In (this is what it is now)? Also; if someone would want to +take me under their wing, so I don't spam the mailing list - I would greatly +appreciate it. + +-- +Christopher Houdeshell +-- +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090805/ce2861ee/attachment.html ++ + + + + +
+-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: interfaces.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090806/0db686c1/attachment-0001.pl ++ + + + + + +
Same method as usual. We went through and compared to the original, it +*should* be good, but we couldn't test the subview support (we develop +on windows). + +-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: SdiWorkspaceWindow.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090806/5a1b52a6/attachment-0001.pl ++ + + + + + + +
same as usual +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: IDotNetLanguageBinding.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090806/bb3773dd/attachment.pl ++ + + + + + + +
same as always. +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: Abstract classes.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090806/710e8e31/attachment-0001.pl ++ + + + + + + +
Hi Christopher, + +I'm happy to see you're interested in contributing. If you already have +the class wizard as an add-in, keep it like this for now. Maybe when it +is completed and polished we can add it to the main project. + +Feel free to send your questions and patches to the monodevelop-devel +list. That's what the list is for. + +Thanks! +Lluis. + +El dc 05 de 08 de 2009 a les 20:02 -0400, en/na Christopher Houdeshell +va escriure: +> Hello all. I have wanted to contribute to Mono-Develop for sometime +> now; and have been dabbling and learning the ropes. Since I now have +> free time, I figured that I would start small. Mainly pick a few of +> the 'small task' todo action items. I have create a New Class Wizard; +> but I am unsure of where to put it. Should I merge it the main +> Monodevelop.IDE project or should I keep it as an Add-In (this is what +> it is now)? Also; if someone would want to take me under their wing, +> so I don't spam the mailing list - I would greatly appreciate it. +> +> -- +> Christopher Houdeshell +> -- +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + +
+-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: AbstractProjectConfiguration.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090807/83066e09/attachment.pl ++ + + + + + +
Committed with some fixes. Thanks! + +El dt 04 de 08 de 2009 a les 17:51 +0200, en/na Carlo Kok va escriure: +> same process as usual. +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + +
Committed. Thanks! + +El dj 06 de 08 de 2009 a les 09:58 +0200, en/na Carlo Kok va escriure: +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + +
* MonoDevelop.Ide.Gui.Dialogs/SharpDevelopAboutPanels.cs: removed +* MonoDevelop.Ide.Gui.Dialogs/AboutMonoDevelopTabPage.cs: +* MonoDevelop.Ide.Templates/VersionInformationTabPage.cs: Rewritten from +scratch + to make it non-GPL. + +-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: PAtch.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090807/2370afc2/attachment-0001.pl ++ + + + +
kept the code that was rewritten. + +-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: GacReferencePanel.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090807/7b71307c/attachment.pl ++ + + + +
Should there be a XSP/XSP2 path preference in MonoDevelop.AspNet.Gui. +XspOptionsPanelWidget so that we can Window users can figure the path to +XSP/XSP2 without setting this up in their $PATH? + +-- +Christopher Houdeshell +(814) 441-3863 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090808/0d56a03f/attachment.html ++ + + + +
2009/8/8 Christopher Houdeshell <christopher.houdeshell at gmail.com>: +> Should there be a XSP/XSP2 path preference in MonoDevelop.AspNet.Gui. +> XspOptionsPanelWidget so that we can Window users can figure the path to +> XSP/XSP2 without setting this up in their $PATH? + +It would be better to make the tools path for the TargetRuntime configurable. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
we've only rewritten the functions that were in the original split +(compared everything to the latest version) +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: NewProjectDialog.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090810/6ba9106a/attachment-0001.pl ++ + + + +
I kept the original #D code since it was relicensed to LGPL in #D 2.0. + +El dj 06 de 08 de 2009 a les 13:15 +0200, en/na Carlo Kok va escriure: +> Same method as usual. We went through and compared to the original, it +> *should* be good, but we couldn't test the subview support (we develop +> on windows). +> +> fitxer adjunt document de text pla (SdiWorkspaceWindow.patch) +> Index: main/src/core/MonoDevelop.Ide/ChangeLog +> =================================================================== +> --- main/src/core/MonoDevelop.Ide/ChangeLog (revision 139397) +> +++ main/src/core/MonoDevelop.Ide/ChangeLog (working copy) +> @@ -1,3 +1,8 @@ +> +2009-07-02 Viktoria Dudka <viktoriad at remobjects.com> +> + +> + * MonoDevelop.Ide.Gui/SdiWorkspaceWindow.cs: Rewritten from scratch +> + to make it non-GPL. +> + +> 2009-08-05 Lluis Sanchez Gual <lluis at novell.com> +> +> * MonoDevelop.Ide.FindInFiles/SearchResultWidget.cs: Don't +> Index: main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/SdiWorkspaceWindow.cs +> =================================================================== +> --- main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/SdiWorkspaceWindow.cs (revision 139397) +> +++ main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/SdiWorkspaceWindow.cs (working copy) +> @@ -1,634 +1,637 @@ +> -// SdiWorkspaceWindow.cs +> -// +> -// This file was derived from a file from #Develop. +> -// +> -// Copyright (C) 2001-2007 Mike Krüger <mkrueger at novell.com> +> -// +> -// This program is free software; you can redistribute it and/or modify +> -// it under the terms of the GNU General Public License as published by +> -// the Free Software Foundation; either version 2 of the License, or +> -// (at your option) any later version. +> -// +> -// This program is distributed in the hope that it will be useful, +> -// but WITHOUT ANY WARRANTY; without even the implied warranty of +> -// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +> -// GNU General Public License for more details. +> -// +> -// You should have received a copy of the GNU General Public License +> -// along with this program; if not, write to the Free Software +> -// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +> - +> -using System; +> -using System.Collections; +> -using System.IO; +> -using Gtk; +> - +> -using MonoDevelop.Core; +> -using MonoDevelop.Core.Gui; +> -using MonoDevelop.Components; +> -using MonoDevelop.Ide.Commands; +> -using MonoDevelop.Components.Commands; +> - +> -namespace MonoDevelop.Ide.Gui +> -{ +> - internal class SdiWorkspaceWindow : Frame, IWorkbenchWindow, ICommandDelegatorRouter +> - { +> - IWorkbench workbench; +> - IViewContent content; +> - +> - ArrayList subViewContents = null; +> - Notebook subViewNotebook = null; +> - Toolbar subViewToolbar = null; +> - HBox pathBox = null; +> - HBox toolbarBox = null; +> - +> - VBox box; +> - TabLabel tabLabel; +> - Widget tabPage; +> - Notebook tabControl; +> - SeparatorToolItem separatorItem; +> - +> - string myUntitledTitle = null; +> - string _titleHolder = ""; +> - +> - string documentType; +> - MonoDevelop.Ide.Gui.Content.IPathedDocument pathDoc; +> - +> - bool show_notification = false; +> - +> - ViewCommandHandlers commandHandler; +> - +> - public SdiWorkspaceWindow (IWorkbench workbench, IViewContent content, Notebook tabControl, TabLabel tabLabel) : base () +> - { +> - this.workbench = workbench; +> - this.tabControl = tabControl; +> - this.content = content; +> - this.tabLabel = tabLabel; +> - this.tabPage = content.Control; +> - +> - content.WorkbenchWindow = this; +> - +> - content.ContentNameChanged += new EventHandler(SetTitleEvent); +> - content.DirtyChanged += new EventHandler(SetTitleEvent); +> - content.BeforeSave += new EventHandler(BeforeSave); +> - content.ContentChanged += new EventHandler (OnContentChanged); +> - +> - ShadowType = ShadowType.None; +> - box = new VBox (); +> - box.Add (content.Control); +> - Add (box); +> - +> - Show (); +> - box.Show (); +> - content.Control.Show (); +> - SetTitleEvent(null, null); +> - +> - commandHandler = new ViewCommandHandlers (this); +> - } +> - +> - protected SdiWorkspaceWindow (IntPtr p): base (p) +> - { +> - } +> - +> - public Widget TabPage { +> - get { +> - return tabPage; +> - } +> - set { +> - tabPage = value; +> - } +> - } +> - +> - internal TabLabel TabLabel { +> - get { return tabLabel; } +> - } +> - +> - public Document Document { +> - get; +> - set; +> - } +> - +> - public bool ShowNotification { +> - get { +> - return show_notification; +> - } +> - set { +> - if (show_notification != value) { +> - show_notification = value; +> - OnTitleChanged (null); +> - } +> - } +> - } +> - +> - public string Title { +> - get { +> - //FIXME: This breaks, Why? --Todd +> - //_titleHolder = tabControl.GetTabLabelText (tabPage); +> - return _titleHolder; +> - } +> - set { +> - _titleHolder = value; +> - string fileName = content.ContentName; +> - if (fileName == null) { +> - fileName = content.UntitledName; +> - } +> - +> - OnTitleChanged(null); +> - } +> - } +> - +> - public ArrayList SubViewContents { +> - get { +> - return subViewContents; +> - } +> - } +> - +> - // caution use activeView with care !! +> - IBaseViewContent activeView = null; +> - public IBaseViewContent ActiveViewContent { +> - get { +> - if (activeView != null) +> - return activeView; +> - if (subViewNotebook != null && subViewNotebook.CurrentPage > 0) { +> - return (IBaseViewContent)subViewContents[subViewNotebook.CurrentPage - 1]; +> - } +> - return content; +> - } +> - set { +> - this.activeView = value; +> - this.OnActiveViewContentChanged (new ActiveViewContentEventArgs (value)); +> - } +> - } +> - +> - public void SwitchView (int viewNumber) +> - { +> - if (subViewNotebook != null) +> - ShowPage (viewNumber); +> - } +> - +> - public void SelectWindow() +> - { +> - if (this.Parent == null) +> - return; +> - int toSelect = tabControl.PageNum (this); +> - tabControl.CurrentPage = toSelect; +> - } +> - +> - +> - void BeforeSave(object sender, EventArgs e) +> - { +> - IAttachableViewContent secondaryViewContent = ActiveViewContent as IAttachableViewContent; +> - if (secondaryViewContent != null) { +> - secondaryViewContent.BeforeSave (); +> - } +> - } +> - +> - public IViewContent ViewContent { +> - get { +> - return content; +> - } +> - set { +> - content = value; +> - } +> - } +> - +> - public MonoDevelop.Ide.Gui.ViewCommandHandlers CommandHandler { +> - get { +> - return commandHandler; +> - } +> - } +> - +> - public string DocumentType { +> - get { +> - return documentType; +> - } +> - set { +> - documentType = value; +> - } +> - } +> - +> - public void SetTitleEvent(object sender, EventArgs e) +> - { +> - if (content == null) { +> - return; +> - } +> - +> - string newTitle = ""; +> - if (content.ContentName == null) { +> - if (myUntitledTitle == null) { +> - string baseName = System.IO.Path.GetFileNameWithoutExtension(content.UntitledName); +> - int number = 1; +> - bool found = true; +> - myUntitledTitle = baseName + System.IO.Path.GetExtension (content.UntitledName); +> - while (found) { +> - found = false; +> - foreach (IViewContent windowContent in workbench.ViewContentCollection) { +> - string title = windowContent.WorkbenchWindow.Title; +> - if (title.EndsWith("*") || title.EndsWith("+")) { +> - title = title.Substring(0, title.Length - 1); +> - } +> - if (title == myUntitledTitle) { +> - myUntitledTitle = baseName + number + System.IO.Path.GetExtension (content.UntitledName); +> - found = true; +> - ++number; +> - break; +> - } +> - } +> - } +> - } +> - newTitle = myUntitledTitle; +> - } else { +> - newTitle = System.IO.Path.GetFileName(content.ContentName); +> - } +> - +> - if (content.IsDirty) { +> - newTitle += "*"; +> - IdeApp.ProjectOperations.MarkFileDirty (content.ContentName); +> - } else if (content.IsReadOnly) { +> - newTitle += "+"; +> - } +> - +> - if (newTitle != Title) { +> - Title = newTitle; +> - } +> - } +> - +> - public void OnContentChanged (object o, EventArgs e) +> - { +> - if (subViewContents != null) { +> - foreach (IAttachableViewContent subContent in subViewContents) +> - { +> - subContent.BaseContentChanged (); +> - } +> - } +> - } +> - +> - public bool CloseWindow (bool force, bool fromMenu, int pageNum) +> - { +> - bool wasActive = workbench.WorkbenchLayout.ActiveWorkbenchwindow == this; +> - WorkbenchWindowEventArgs args = new WorkbenchWindowEventArgs (force, wasActive); +> - args.Cancel = false; +> - OnClosing (args); +> - if (args.Cancel) +> - return false; +> - if (fromMenu == true) { +> - workbench.WorkbenchLayout.RemoveTab (tabControl.PageNum(this)); +> - } else { +> - workbench.WorkbenchLayout.RemoveTab (pageNum); +> - } +> - +> - content.ContentNameChanged -= new EventHandler(SetTitleEvent); +> - content.DirtyChanged -= new EventHandler(SetTitleEvent); +> - content.BeforeSave -= new EventHandler(BeforeSave); +> - content.ContentChanged -= new EventHandler (OnContentChanged); +> - content.WorkbenchWindow = null; +> - +> - if (subViewContents != null) { +> - foreach (IAttachableViewContent sv in subViewContents) { +> - subViewNotebook.Remove (sv.Control); +> - sv.Dispose (); +> - } +> - this.subViewContents = null; +> - subViewNotebook.Remove (content.Control); +> - } else { +> - box.Remove (content.Control); +> - } +> - content.Dispose (); +> - tabLabel.Dispose (); +> - +> - this.subViewToolbar = null; +> - this.separatorItem = null; +> - DetachFromPathedDocument (); +> - +> - OnClosed (args); +> - +> - this.content = null; +> - this.subViewNotebook = null; +> - this.tabControl = null; +> - this.tabLabel = null; +> - this.tabPage = null; +> - Destroy (); +> - return true; +> - } +> - +> - #region lazy UI element creation +> - +> - void CheckCreateSubViewToolbar () +> - { +> - if (subViewToolbar != null) +> - return; +> - +> - subViewToolbar = new Toolbar (); +> - subViewToolbar.IconSize = IconSize.SmallToolbar; +> - subViewToolbar.ToolbarStyle = ToolbarStyle.BothHoriz; +> - subViewToolbar.ShowArrow = false; +> - subViewToolbar.Show (); +> - +> - CheckCreateToolbarBox (); +> - toolbarBox.PackStart (subViewToolbar, false, false, 0); +> - } +> - +> - void EnsureToolbarBoxSeparator () +> - { +> - if (toolbarBox == null || subViewToolbar == null) +> - return; +> - +> - if (separatorItem != null && pathBox == null) { +> - subViewToolbar.Remove (separatorItem); +> - separatorItem = null; +> - } else if (separatorItem == null && pathBox != null) { +> - separatorItem = new SeparatorToolItem (); +> - subViewToolbar.Insert (separatorItem, -1); +> - } else if (separatorItem != null && pathBox != null) { +> - if (subViewToolbar.GetItemIndex(separatorItem) != subViewToolbar.NumChildren - 1) { +> - subViewToolbar.Remove (separatorItem); +> - subViewToolbar.Insert (separatorItem, -1); +> - } +> - } +> - } +> - +> - void CheckCreateToolbarBox () +> - { +> - if (toolbarBox != null) +> - return; +> - toolbarBox = new HBox (false, 6); +> - toolbarBox.Show (); +> - box.PackEnd (toolbarBox, false, false, 3); +> - } +> - +> - void CheckCreateSubViewContents () +> - { +> - if (subViewContents != null) +> - return; +> - +> - subViewContents = new ArrayList (); +> - +> - box.Remove (this.ViewContent.Control); +> - +> - subViewNotebook = new Notebook (); +> - subViewNotebook.TabPos = PositionType.Bottom; +> - subViewNotebook.ShowTabs = false; +> - subViewNotebook.ShowBorder = false; +> - subViewNotebook.Show (); +> - subViewNotebook.SwitchPage += subViewNotebookIndexChanged; +> - +> - //add existing ViewContent +> - AddButton (this.ViewContent.TabPageLabel, this.ViewContent.Control).Active = true; +> - +> - //pack them in a box +> - box.PackStart (subViewNotebook, true, true, 0); +> - box.ShowAll (); +> - } +> - +> - #endregion +> - +> - +> - public void AttachViewContent (IAttachableViewContent subViewContent) +> - { +> - // need to create child Notebook when first IAttachableViewContent is added +> - CheckCreateSubViewContents (); +> - +> - subViewContents.Add (subViewContent); +> - subViewContent.WorkbenchWindow = this; +> - AddButton (subViewContent.TabPageLabel, subViewContent.Control); +> - +> - OnContentChanged (null, null); +> - } +> - +> - bool updating = false; +> - protected ToggleToolButton AddButton (string label, Gtk.Widget page) +> - { +> - CheckCreateSubViewToolbar (); +> - updating = true; +> - ToggleToolButton button = new ToggleToolButton (); +> - button.Label = label; +> - button.IsImportant = true; +> - button.Clicked += new EventHandler (OnButtonToggled); +> - button.ShowAll (); +> - subViewToolbar.Insert (button, -1); +> - subViewNotebook.AppendPage (page, new Gtk.Label ()); +> - page.ShowAll (); +> - EnsureToolbarBoxSeparator (); +> - updating = false; +> - return button; +> - } +> - +> - #region Track and display document's "path" +> - +> - internal void AttachToPathedDocument (MonoDevelop.Ide.Gui.Content.IPathedDocument pathDoc) +> - { +> - if (this.pathDoc != pathDoc) +> - DetachFromPathedDocument (); +> - if (pathDoc == null) +> - return; +> - PathWidgetEnabled = true; +> - pathDoc.PathChanged += HandlePathChange; +> - this.pathDoc = pathDoc; +> - } +> - +> - internal void DetachFromPathedDocument () +> - { +> - if (pathDoc == null) +> - return; +> - PathWidgetEnabled = false; +> - pathDoc.PathChanged -= HandlePathChange; +> - pathDoc = null; +> - } +> - +> - void HandlePathChange (object sender, MonoDevelop.Ide.Gui.Content.DocumentPathChangedEventArgs args) +> - { +> - MonoDevelop.Ide.Gui.Content.IPathedDocument pathDoc = (MonoDevelop.Ide.Gui.Content.IPathedDocument) sender; +> - +> - while (pathBox.Children.Length > 0) +> - pathBox.Remove (pathBox.Children[0]); +> - +> - if (pathDoc.CurrentPath == null || pathDoc.CurrentPath.Length == 0) +> - return; +> - +> - for (int i = 0; i < pathDoc.CurrentPath.Length; i++) { +> - PathMenuButton button = new PathMenuButton (pathDoc, i); +> - button.ArrowType = (i + 1 < pathDoc.CurrentPath.Length)? ArrowType.Right : (ArrowType?) null; +> - +> - if (i == pathDoc.SelectedIndex) { +> - string escaped = GLib.Markup.EscapeText (pathDoc.CurrentPath[i]); +> - button.Markup = string.Concat ("<b>", escaped ,"</b>"); +> - } else { +> - button.Label = pathDoc.CurrentPath[i]; +> - } +> - pathBox.PackStart (button, false, false, 0); +> - } +> - pathBox.PackEnd (new Label (string.Empty), true, true, 0); +> - pathBox.ShowAll (); +> - } +> - +> - bool PathWidgetEnabled { +> - get { return (pathBox != null); } +> - set { +> - if (PathWidgetEnabled == value) +> - return; +> - if (value) { +> - CheckCreateToolbarBox (); +> - +> - pathBox = new HBox (); +> - pathBox.Spacing = 0; +> - +> - toolbarBox.PackEnd (pathBox, true, true, 0); +> - toolbarBox.ShowAll (); +> - } else { +> - toolbarBox.Remove (pathBox); +> - toolbarBox.Destroy (); +> - } +> - EnsureToolbarBoxSeparator (); +> - } +> - } +> - +> - private class PathMenuButton : MenuButton +> - { +> - MonoDevelop.Ide.Gui.Content.IPathedDocument pathDoc; +> - int index; +> - +> - public PathMenuButton (MonoDevelop.Ide.Gui.Content.IPathedDocument pathDoc, int index) +> - { +> - this.pathDoc = pathDoc; +> - this.index = index; +> - this.MenuCreator = PathMenuCreator; +> - this.Relief = Gtk.ReliefStyle.None; +> - } +> - +> - Menu PathMenuCreator (MenuButton button) +> - { +> - Menu menu = new Menu (); +> - MenuItem mi = new MenuItem (GettextCatalog.GetString ("Select")); +> - mi.Activated += delegate { +> - pathDoc.SelectPath (index); +> - }; +> - menu.Add (mi); +> - mi = new MenuItem (GettextCatalog.GetString ("Select contents")); +> - mi.Activated += delegate { +> - pathDoc.SelectPathContents (index); +> - }; +> - menu.Add (mi); +> - menu.ShowAll (); +> - return menu; +> - } +> - } +> - +> - #endregion +> - +> - protected void ShowPage (int npage) +> - { +> - if (updating) return; +> - updating = true; +> - +> - subViewNotebook.CurrentPage = npage; +> - Gtk.Widget[] buttons = subViewToolbar.Children; +> - for (int n=0; n<buttons.Length; n++) { +> - if (buttons [n] is ToggleToolButton) { +> - ToggleToolButton b = (ToggleToolButton) buttons [n]; +> - b.Active = (n == npage); +> - } +> - } +> - +> - updating = false; +> - } +> - +> - void OnButtonToggled (object s, EventArgs args) +> - { +> - int i = Array.IndexOf (subViewToolbar.Children, s); +> - if (i != -1) +> - ShowPage (i); +> - } +> - +> - int oldIndex = -1; +> - protected void subViewNotebookIndexChanged(object sender, SwitchPageArgs e) +> - { +> - if (oldIndex > 0) { +> - IAttachableViewContent secondaryViewContent = subViewContents[oldIndex - 1] as IAttachableViewContent; +> - if (secondaryViewContent != null) { +> - secondaryViewContent.Deselected(); +> - } +> - } +> - +> - if (subViewNotebook.CurrentPage > 0) { +> - IAttachableViewContent secondaryViewContent = subViewContents[subViewNotebook.CurrentPage - 1] as IAttachableViewContent; +> - if (secondaryViewContent != null) { +> - secondaryViewContent.Selected(); +> - } +> - } +> - oldIndex = subViewNotebook.CurrentPage; +> - +> - OnActiveViewContentChanged (new ActiveViewContentEventArgs (this.ActiveViewContent)); +> - } +> - +> - object ICommandDelegatorRouter.GetNextCommandTarget () +> - { +> - return Parent; +> - } +> - +> - object ICommandDelegatorRouter.GetDelegatedCommandTarget () +> - { +> - Gtk.Widget w = content as Gtk.Widget; +> - if (w != this.tabPage) { +> - // Route commands to the view +> - return content; +> - } else +> - return null; +> - } +> - +> - protected virtual void OnTitleChanged(EventArgs e) +> - { +> - if (show_notification) { +> - tabLabel.Label.Markup = "<span foreground=\"blue\">" + Title + "</span>"; +> - tabLabel.Label.UseMarkup = true; +> - } else { +> - tabLabel.Label.Text = Title; +> - tabLabel.Label.UseMarkup = false; +> - } +> - +> - if (content.ContentName != null && content.ContentName != "") { +> - tabLabel.SetTooltip (content.ContentName, content.ContentName); +> - } +> - +> - try { +> - if (content.StockIconId != null ) { +> - tabLabel.Icon = new Gtk.Image ( content.StockIconId, IconSize.Menu ); +> - } +> - else if (content.ContentName != null && content.ContentName.IndexOfAny (new char[] { '*', '+'}) == -1) { +> - tabLabel.Icon.Pixbuf = DesktopService.GetPixbufForFile (content.ContentName, Gtk.IconSize.Menu); +> - } +> - } catch (Exception ex) { +> - LoggingService.LogError (ex.ToString ()); +> - tabLabel.Icon.Pixbuf = DesktopService.GetPixbufForType ("gnome-fs-regular", Gtk.IconSize.Menu); +> - } +> - +> - if (TitleChanged != null) { +> - TitleChanged(this, e); +> - } +> - } +> - +> - protected virtual void OnClosing (WorkbenchWindowEventArgs e) +> - { +> - if (Closing != null) { +> - Closing (this, e); +> - } +> - } +> - +> - protected virtual void OnClosed (WorkbenchWindowEventArgs e) +> - { +> - if (Closed != null) { +> - Closed (this, e); +> - } +> - } +> - +> - protected virtual void OnActiveViewContentChanged (ActiveViewContentEventArgs e) +> - { +> - if (ActiveViewContentChanged != null) +> - ActiveViewContentChanged (this, e); +> - } +> - +> - public event EventHandler TitleChanged; +> - public event WorkbenchWindowEventHandler Closed; +> - public event WorkbenchWindowEventHandler Closing; +> - public event ActiveViewContentEventHandler ActiveViewContentChanged; +> - } +> -} +> +// SdiWorkspaceWindow.cs +> +// +> +// Author: +> +// Viktoria Dudka (viktoriad at remobjects.com) +> +// +> +// Copyright (c) 2009 RemObjects Software +> +// +> +// Permission is hereby granted, free of charge, to any person obtaining a copy +> +// of this software and associated documentation files (the "Software"), to deal +> +// in the Software without restriction, including without limitation the rights +> +// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +> +// copies of the Software, and to permit persons to whom the Software is +> +// furnished to do so, subject to the following conditions: +> +// +> +// The above copyright notice and this permission notice shall be included in +> +// all copies or substantial portions of the Software. +> +// +> +// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +> +// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +> +// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +> +// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +> +// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +> +// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +> +// THE SOFTWARE. +> +// +> +// +> + +> +using System; +> +using System.Collections.Generic; +> +using System.Linq; +> +using System.Text; +> +using Gtk; +> +using MonoDevelop.Components.Commands; +> +using MonoDevelop.Components; +> +using System.Collections; +> +using MonoDevelop.Core.Gui; +> +using MonoDevelop.Core; +> +using MonoDevelop.Ide.Gui.Content; +> + +> +namespace MonoDevelop.Ide.Gui +> +{ +> + class SdiWorkspaceWindow : Frame, IWorkbenchWindow, ICommandDelegatorRouter +> + { +> + private VBox vBox = null; +> + private IWorkbench workbench = null; +> + private IViewContent content = null; +> + private Notebook tabControl = null; +> + +> + private ViewCommandHandlers viewCommandHandlers = null; +> + +> + private Notebook subViewNotebook = null; +> + +> + private bool updating = false; +> + +> + private Toolbar subViewToolbar = null; +> + +> + private TabLabel tabLabel = null; +> + public TabLabel TabLabel +> + { +> + get { return tabLabel; } +> + } +> + +> + private ViewCommandHandlers commandHandler = null; +> + public ViewCommandHandlers CommandHandler +> + { +> + get { return commandHandler; } +> + } +> + +> + +> + public SdiWorkspaceWindow (IWorkbench workbench, IViewContent content, Notebook tabControl, TabLabel tabLabel): base() +> + { +> + vBox = new VBox(); +> + vBox.Add (content.Control); +> + this.Add (vBox); +> + Show (); +> + vBox.Show (); +> + content.Control.Show (); +> + +> + this.workbench = workbench; +> + this.content = content; +> + this.tabControl = tabControl; +> + this.tabLabel = tabLabel; +> + +> + +> + SetTitleEvent (null, null); +> + +> + content.WorkbenchWindow = this; +> + +> + content.ContentChanged += new EventHandler (OnContentChanged); +> + content.BeforeSave += new EventHandler (OnBeforeSave); +> + content.ContentNameChanged += new EventHandler (SetTitleEvent); +> + content.DirtyChanged += new EventHandler (SetTitleEvent); +> + +> + viewCommandHandlers = new ViewCommandHandlers (this); +> + } +> + +> + protected SdiWorkspaceWindow (IntPtr intPtr): base (intPtr) +> + { +> + } +> + +> + #region ICommandDelegatorRouter Members +> + +> + public object GetNextCommandTarget () +> + { +> + return Parent; +> + } +> + +> + public object GetDelegatedCommandTarget () +> + { +> + return content != content.Control ? content : null; +> + } +> + +> + #endregion +> + +> + +> + #region IWorkbenchWindow Members +> + +> + private string title = ""; +> + public string Title +> + { +> + get +> + { +> + return title; +> + } +> + set +> + { +> + title = value; +> + OnTitleChanged (EventArgs.Empty); +> + } +> + } +> + +> + private string documentType = null; +> + public string DocumentType +> + { +> + get +> + { +> + return documentType; +> + } +> + set +> + { +> + documentType = value; +> + } +> + } +> + +> + private bool showNotification = false; +> + public bool ShowNotification +> + { +> + get +> + { +> + return showNotification; +> + } +> + set +> + { +> + if (showNotification != value) { +> + showNotification = value; +> + } +> + +> + OnTitleChanged (EventArgs.Empty); +> + } +> + } +> + +> + public IViewContent ViewContent +> + { +> + get { return content; } //maybe we need setter +> + set { content = value; } +> + } +> + +> + private ArrayList subViewContents = null; +> + public ArrayList SubViewContents +> + { +> + get { return subViewContents; } +> + } +> + +> + private IBaseViewContent activeViewContent = null; +> + public IBaseViewContent ActiveViewContent +> + { +> + get +> + { +> + if (activeViewContent != null) +> + return activeViewContent; +> + +> + if ((subViewNotebook != null) && (subViewNotebook.CurrentPage > 0)) +> + return (IBaseViewContent)subViewContents[subViewNotebook.CurrentPage - 1]; +> + else +> + return content; +> + +> + } +> + set +> + { +> + activeViewContent = value; +> + OnActiveViewContentChanged(new ActiveViewContentEventArgs(value)); +> + } +> + } +> + +> + private Document document = null; +> + public Document Document +> + { +> + get +> + { +> + return document; +> + } +> + set +> + { +> + document = value; +> + } +> + } +> + +> + public bool CloseWindow (bool force, bool fromMenu, int pageNum) +> + { +> + WorkbenchWindowEventArgs workbenchWindowEventArgs = new WorkbenchWindowEventArgs (force, (workbench.WorkbenchLayout.ActiveWorkbenchwindow == this)); +> + OnClosing (workbenchWindowEventArgs); +> + if (workbenchWindowEventArgs.Cancel) +> + return false; +> + +> + content.ContentChanged -= new EventHandler (OnContentChanged); +> + content.BeforeSave -= new EventHandler (OnBeforeSave); +> + content.ContentNameChanged -= new EventHandler (SetTitleEvent); +> + content.DirtyChanged -= new EventHandler (SetTitleEvent); +> + +> + content.WorkbenchWindow = null; +> + +> + if (subViewContents != null) { +> + subViewNotebook.Remove (content.Control); +> + foreach (IAttachableViewContent subViewContent in subViewContents) +> + { +> + subViewContent.Dispose (); +> + subViewNotebook.Remove (subViewContent.Control); +> + } +> + } +> + else { +> + vBox.Remove (content.Control); +> + } +> + +> + content.Dispose (); +> + tabLabel.Dispose (); +> + +> + DetachFromPathedDocument (); +> + OnClosed (workbenchWindowEventArgs); +> + Destroy (); +> + +> + content = null; +> + +> + return true; +> + } +> + +> + public void SelectWindow () +> + { +> + if (this.Parent == null) +> + return; +> + tabControl.CurrentPage = tabControl.PageNum (this); +> + } +> + +> + public void SwitchView (int viewNumber) +> + { +> + if (subViewNotebook == null) +> + return; +> + +> + if (updating) +> + return; +> + +> + updating = true; +> + subViewNotebook.CurrentPage = viewNumber; +> + +> + int i = 0; +> + foreach (Widget widget in subViewToolbar.Children) { +> + ToggleToolButton btn = widget as ToggleToolButton; +> + if (btn != null) { +> + btn.Active = (i == viewNumber); +> + } +> + i++; +> + } +> + +> + updating = false; +> + } +> + +> + public void AttachViewContent (IAttachableViewContent subViewContent) +> + { +> + if (subViewContents == null) { +> + subViewContents = new ArrayList (); +> + vBox.Remove (ViewContent.Control); +> + +> + subViewNotebook = new Notebook (); +> + subViewNotebook.ShowBorder = false; +> + subViewNotebook.ShowTabs = false; +> + subViewNotebook.TabPos = PositionType.Bottom; +> + subViewNotebook.SwitchPage += subViewNotebookIndexChanged; +> + subViewNotebook.Show (); +> + +> + ToggleToolButton toggleToolButton = AddButton (ViewContent.TabPageLabel, ViewContent.Control); +> + toggleToolButton.Active = true; +> + +> + vBox.PackStart (subViewNotebook, true, true, 0); +> + vBox.ShowAll (); +> + } +> + +> + subViewContent.WorkbenchWindow = this; +> + subViewContents.Add (subViewContent); +> + +> + AddButton (subViewContent.TabPageLabel, subViewContent.Control); +> + +> + OnContentChanged (null, null); +> + } +> + +> + public event EventHandler TitleChanged; +> + +> + public event WorkbenchWindowEventHandler Closing; +> + +> + public event WorkbenchWindowEventHandler Closed; +> + +> + public event ActiveViewContentEventHandler ActiveViewContentChanged; +> + +> + #endregion +> + +> + private void OnTitleChanged (EventArgs e) +> + { +> + tabLabel.Label.UseMarkup = showNotification; +> + if (showNotification) +> + tabLabel.Label.Markup = String.Format ("<span foreground=\"blue\">{0}</span>", Title); +> + else +> + tabLabel.Label.Text = Title; +> + +> + if (!String.IsNullOrEmpty (content.ContentName)) +> + tabLabel.SetTooltip (content.ContentName, content.ContentName); +> + +> + try { +> + if (!String.IsNullOrEmpty (content.StockIconId)) { +> + tabLabel.Icon = new Gtk.Image (content.StockIconId, IconSize.Menu); +> + } +> + else if (!String.IsNullOrEmpty (content.ContentName) && !(content.ContentName.Contains ("+") && content.ContentName.Contains ("*"))) { +> + tabLabel.Icon.Pixbuf = DesktopService.GetPixbufForFile (content.ContentName, IconSize.Menu); +> + } +> + } +> + catch (Exception ex) { +> + LoggingService.LogError (ex.ToString ()); +> + tabLabel.Icon.Pixbuf = DesktopService.GetPixbufForType ("gnome-fs-regular", IconSize.Menu); +> + } +> + +> + if (TitleChanged != null) +> + TitleChanged(this, e); +> + } +> + +> + protected virtual void OnActiveViewContentChanged (ActiveViewContentEventArgs e) +> + { +> + if (ActiveViewContentChanged != null) +> + ActiveViewContentChanged (this, e); +> + } +> + +> + protected virtual void OnClosing (WorkbenchWindowEventArgs e) +> + { +> + if (Closing != null) +> + Closing (this, e); +> + } +> + +> + protected virtual void OnClosed (WorkbenchWindowEventArgs e) +> + { +> + if (Closed != null) +> + Closed (this, e); +> + } +> + +> + public void OnContentChanged (System.Object o, EventArgs e) +> + { +> + if (subViewContents != null) { +> + foreach (IAttachableViewContent subViewContent in subViewContents) +> + subViewContent.BaseContentChanged (); +> + +> + } +> + } +> + +> + private void OnBeforeSave (System.Object o, EventArgs e) +> + { +> + if (ActiveViewContent is IAttachableViewContent) +> + ((IAttachableViewContent)ActiveViewContent).BeforeSave (); +> + +> + } +> + +> + private string untitledName; +> + public void SetTitleEvent (System.Object o, EventArgs e) +> + { +> + if (content == null) +> + return; +> + +> + string title = ""; +> + if (!String.IsNullOrEmpty (content.ContentName)) { +> + title = System.IO.Path.GetFileName (content.ContentName); +> + untitledName = null; +> + } +> + else { +> + string baseName = System.IO.Path.GetFileNameWithoutExtension (content.UntitledName); +> + untitledName = baseName + System.IO.Path.GetExtension (content.UntitledName); +> + +> + if (!TitleExists (untitledName)) { +> + int i = 1; +> + while (true) { +> + untitledName = baseName + i + System.IO.Path.GetExtension (content.UntitledName); +> + if ( TitleExists(untitledName)) break; +> + i++; +> + } +> + } +> + else +> + title = untitledName; +> + } +> + +> + if (content.IsDirty) { +> + title = title + "*"; +> + IdeApp.ProjectOperations.MarkFileDirty (content.ContentName); +> + } +> + else if (content.IsReadOnly) { +> + title = title + "*"; +> + } +> + +> + Title = title; +> + } +> + +> + private bool TitleExists (string titleFound) +> + { +> + foreach (IViewContent viewContent in workbench.ViewContentCollection) { +> + string name = viewContent.WorkbenchWindow.Title; +> + if (name.EndsWith ("*") || name.EndsWith ("+")) +> + name.Remove (name.Length, 1); +> + +> + if (name == titleFound) +> + return true; +> + } +> + +> + return false; +> + +> + } +> + +> + private int prevIndex = -1; +> + protected void subViewNotebookIndexChanged (System.Object o, SwitchPageArgs e) +> + { +> + if (prevIndex != -1) { +> + if (subViewContents[prevIndex - 1] is IAttachableViewContent) { +> + ((IAttachableViewContent)subViewContents[prevIndex - 1]).Deselected (); +> + } +> + } +> + +> + prevIndex = subViewNotebook.CurrentPage; +> + +> + if (prevIndex > 0) { +> + if (subViewContents[prevIndex - 1] is IAttachableViewContent) { +> + ((IAttachableViewContent)subViewContents[prevIndex - 1]).Selected (); +> + } +> + } +> + +> + OnActiveViewContentChanged (new ActiveViewContentEventArgs (ActiveViewContent)); +> + } +> + +> + private HBox toolbarBox = null; +> + protected ToggleToolButton AddButton (String label, Widget page) +> + { +> + if (subViewToolbar == null) { +> + subViewToolbar = new Toolbar (); +> + subViewToolbar.ShowArrow = false; +> + subViewToolbar.ToolbarStyle = ToolbarStyle.BothHoriz; +> + subViewToolbar.IconSize = IconSize.SmallToolbar; +> + +> + subViewToolbar.Show (); +> + CheckCreateToolbarBox (); +> + toolbarBox.PackStart (subViewToolbar, false, false, 0); +> + } +> + +> + this.updating = true; +> + +> + ToggleToolButton buttonResult = new ToggleToolButton (); +> + buttonResult.Label = label; +> + buttonResult.IsImportant = true; +> + buttonResult.Clicked += new EventHandler (OnButtonToggled); +> + buttonResult.ShowAll (); +> + +> + subViewToolbar.Insert (buttonResult, -1); +> + subViewNotebook.AppendPage (page, new Gtk.Label ()); +> + page.ShowAll (); +> + EnsureToolbarBoxSeparator (); +> + +> + this.updating = false; +> + +> + return buttonResult; +> + } +> + +> + private void OnButtonToggled (System.Object o, EventArgs e) +> + { +> + int index = 0; +> + foreach (Widget w in subViewToolbar.Children) { +> + if (w == (Widget)o) { +> + SwitchView (index); +> + return; +> + } +> + index++; +> + } +> + } +> + +> + private void CheckCreateToolbarBox () +> + { +> + if (toolbarBox == null ) { +> + toolbarBox = new HBox(false, 6); +> + toolbarBox.Show (); +> + vBox.PackEnd (toolbarBox, false, false, 3); +> + +> + } +> + } +> + +> + private HBox pathBox = null; +> + private SeparatorToolItem separatorItem = null; +> + private void EnsureToolbarBoxSeparator() { +> + if ( (subViewToolbar != null) && (toolbarBox != null)) { +> + +> + if (pathBox == null && separatorItem != null) { +> + subViewToolbar.Remove (separatorItem); +> + separatorItem = null; +> + } +> + +> + if ( (separatorItem != null) && (pathBox != null) && (subViewToolbar.GetItemIndex (separatorItem) != subViewToolbar.NumChildren - 1)) { +> + subViewToolbar.Remove (separatorItem); +> + subViewToolbar.Insert (separatorItem, -1); +> + } +> + else if ( (pathBox != null) && (separatorItem == null)) { +> + separatorItem = new SeparatorToolItem(); +> + subViewToolbar.Insert (separatorItem, -1); +> + } +> + } +> + } +> + +> + public bool PathWidgetEnabled +> + { +> + get +> + { +> + return (pathBox != null); +> + } +> + +> + set +> + { +> + if ((pathBox != null) == value) +> + return; +> + +> + if (value) { +> + CheckCreateToolbarBox (); +> + +> + pathBox = new HBox (); +> + pathBox.Spacing = 0; +> + +> + toolbarBox.PackEnd (pathBox, true, true, 0); +> + toolbarBox.ShowAll (); +> + } +> + else { +> + toolbarBox.Remove (pathBox); +> + toolbarBox.Destroy (); +> + } +> + +> + EnsureToolbarBoxSeparator (); +> + } +> + } +> + +> + void HandlePathChange (System.Object o, EventArgs e) +> + { +> + for (int i = pathBox.Children.Length - 1; i >= 0; i--) { +> + pathBox.Remove (pathBox.Children[i]); +> + } +> + +> + IPathedDocument pathedDocument = o as IPathedDocument; +> + for (int i = 0; i < pathedDocument.CurrentPath.Length; i++) { +> + PathMenuButton menuButton = new PathMenuButton (pathedDocument, i); +> + +> + if (i == pathedDocument.CurrentPath.Length - 1) +> + menuButton.ArrowType = ArrowType.Right; +> + else +> + menuButton.ArrowType = null; +> + +> + if (pathDoc.SelectedIndex == i) +> + menuButton.Markup = String.Format ("<b>{0}</b>", GLib.Markup.EscapeText (pathedDocument.CurrentPath[i])); +> + else +> + menuButton.Label = pathDoc.CurrentPath[i]; +> + +> + pathBox.PackStart (menuButton, false, false, 0); +> + +> + } +> + +> + pathBox.PackEnd (new Label (string.Empty), true, true, 0); +> + pathBox.ShowAll (); +> + } +> + +> + private IPathedDocument pathDoc = null; +> + public void AttachToPathedDocument (IPathedDocument pathedDocument) +> + { +> + if (this.pathDoc != pathedDocument) { +> + DetachFromPathedDocument (); +> + } +> + +> + if (pathedDocument != null) { +> + PathWidgetEnabled = true; +> + pathedDocument.PathChanged += HandlePathChange; +> + this.pathDoc = pathedDocument; +> + } +> + } +> + +> + public void DetachFromPathedDocument () +> + { +> + if (pathDoc != null) { +> + PathWidgetEnabled = false; +> + pathDoc.PathChanged -= HandlePathChange; +> + this.pathDoc = null; +> + } +> + } +> + +> + internal class PathMenuButton : MenuButton { +> + private IPathedDocument pathedDocument = null; +> + private int index; +> + +> + public PathMenuButton (IPathedDocument pathedDocument, int index) +> + { +> + this.Relief = ReliefStyle.None; +> + +> + this.pathedDocument = pathedDocument; +> + this.index = index; +> + +> + this.MenuCreator = (delegate (MenuButton menuButton) +> + { +> + Menu menu = new Menu(); +> + MenuItem menuItem = new MenuItem(GettextCatalog.GetString("Select")); +> + menuItem.Activated += delegate { pathedDocument.SelectPath (index); }; +> + menu.Add (menuItem); +> + +> + MenuItem menuItemContent = new MenuItem (GettextCatalog.GetString ("Select contents")); +> + menuItemContent.Activated += delegate { pathedDocument.SelectPathContents (index); }; +> + menu.Add (menuItemContent); +> + +> + menu.ShowAll (); +> + +> + return menu; +> + }); +> + } +> + } +> + +> + } +> + +> + +> +} +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + +
same as the others. +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: FileList.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090810/ff2103ae/attachment.pl ++ + + +
+-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: NewFileDialog.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090810/913a06d4/attachment-0001.pl ++ + + +
Same process as usual. We did copy over the methods that were rewritten +since. +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: ProjectFile.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090811/dcd9f312/attachment.pl ++ + + +
same as all the others +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: Project.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090811/b61ec0aa/attachment-0001.pl ++ + + +
kept most of the code since it was rewritten +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: CommonAboutDialog.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090811/832671b1/attachment.pl ++ + + +
+-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: DotNetProject.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090811/2eb68f0f/attachment-0001.pl ++ + + +
Hi! + +I updated the roadmap for MonoDevelop 2.2. You can see it here: + +http://monodevelop.com/Developers/Development_Roadmap + +As you can see, we plan to branch for the first beta next week, so we +should be focusing on the most important bugs. + +Lluis. + ++ + + +
Hi Lluis, + +A little correction. It still says v2.0 in the top text. + +And when you say "most important bugs" is it P3 and higher severity? +-- +Best Regards, +Jakob Tikjøb Andersen + + + +On Tue, Aug 18, 2009 at 10:31 AM, Lluis Sanchez Gual <slluis at gmail.com>wrote: + +> Hi! +> +> I updated the roadmap for MonoDevelop 2.2. You can see it here: +> +> http://monodevelop.com/Developers/Development_Roadmap +> +> As you can see, we plan to branch for the first beta next week, so we +> should be focusing on the most important bugs. +> +> Lluis. +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090818/39dcd92b/attachment.html ++ + + +
I've been wondering whether we should re-evaluate our policy regarding +XML doc comments in MonoDevelop source. I would argue that we should +use doc comments in MD for a number of reasons. MD is a very different +case to the Mono classlibs -- the MD APIs are often only well +understood by the person who writes them, there are no alternative +sources of documentation, and the API is less stable. + +For these reason, I think it is important to lower the barrier as much +as possible for getting docs from the people who are creating and +changing the APIs, so that we can improve the sorry state of our +documentation with minimal effort. + +Mono policy has always been to use MonoDoc for doc comments. However, +although MD has some MonoDoc docs set up in the makefiles, these docs +are not maintained because it is *extremely* awkward to update them +when the APIs change. This is not set up -- nor is it easy to set up +-- for addins that are not in main. Nor can these docs easily be +edited alongside the code. In addition, MonoDoc docs show up in +tooltips for the current installed MD, not the MD codebase that is +being edited. These problems could be solved with a few weeks' work on +a MonoDoc generating/editing addin for MD and some hacking on MonoDoc +to allow it to include non-installed sources, but I don't think we can +easily justify that right now. + +There are also other benefits: +* Tooltips would show live documentation for the current codebase +* MonoDevelop has code completion for creating XML doc comments +* Doc writing and editing would easily be accessible from the IDE on +all platforms - there is no MonoDoc editor on Mac & Windows +* Doc tooltips would work in VS +* Contributions often include doc comments, which we currently discard + +It would be pretty easy to migrate the doc comments automatically back +out of MD source into MonoDoc if/when we have a decent MonoDoc addin. + +I would however suggest that we have a policy to avoid clogging up the +codebase with doc comments for private/internal API and +trivial/obvious/useless documentation such as <param name="count">The +number of items</param>. I still think doc comments are ugly, I just +think that their advantages for us outweigh the disadvantages :-) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Tue, Aug 18, 2009 at 10:08 AM, Michael +Hutchinson<m.j.hutchinson at gmail.com> wrote: +> I've been wondering whether we should re-evaluate our policy regarding +> XML doc comments in MonoDevelop source. I would argue that we should +> use doc comments in MD for a number of reasons. MD is a very different +> case to the Mono classlibs -- the MD APIs are often only well +> understood by the person who writes them, there are no alternative +> sources of documentation, and the API is less stable. +> +> For these reason, I think it is important to lower the barrier as much +> as possible for getting docs from the people who are creating and +> changing the APIs, so that we can improve the sorry state of our +> documentation with minimal effort. + +I agree completely. +In addition, those that find the doc comment blocks ugly can make use +of the "Fold comments by default" preference in the text editor +settings (in fact, I believe that setting is enabled by default). + + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + +
Hi everyone, + +Sorry for the cross-post but this could affect quite a few people. + +I'd like to propose that we bump MonoDevelop's minimum GTK# version +requirement to 2.12.9 and the Mono version to 2.4.2. Although these +are fairly recent, they are by no means cutting edge, and they are the +most stable versions currently available. These requirements would +affect the upcoming MonoDevelop 2.2. release, which is currently +scheduled for the end of October: +http://monodevelop.com/Developers/Development_Roadmap + +Rationale for requiring Mono 2.4.2: + +* 2.4.x is a long-term stable Mono branch +* The Mono debugger is *much* more usable in 2.4.x +* MonoDevelop 2.0 required Mono 2.0, but trunk already requires Mono +2.2 because we use some functionality that doesn't work/compile on +2.0. Continuing to support 2.0/2.2 has a nontrivial maintenance cost. +* There are some runtime issues in 2.2 that cause startup hangs. These +are improved in 2.4, and the complete fix is expected to be backported +from Mono 2.6 to the 2.4 branch. +* MonoDevelop 2.2 will have the ability to target parallel runtimes, +so developers wishing to develop against older releases can use +parallel Mono installations. + +Rationale for requiring GTK# 2.12.9: + +* GTK+ 2.12 is now two years old, and very widely available. +* We were primarily supporting GTK+ 2.8 in order to run on SLED10, and +SLED 11 has now been available for a while. +* Switching to 2.12 would enable us to tidy up a lot of hacks and +workarounds, and move to some nicer APIs (e.g. tooltips), thus +lowering our maintenance burden. +* Requiring the 2.12.9 bugfix point release would fix quite a few GTK# +issues, and would improve stability, particularly in Stetic. +* MD can still be used to target older GTK versions, so this is only a +requirement for developers using MD, not *their* users. + +In summary, upgrading dependencies will help us to ensure that +developers using MonoDevelop get the most stable experience possible, +while also reducing the maintenance burden. MonoDevelop 2.0 will of +course continue to be available for people who can't meet these +requirements. + +If you have good counter-arguments please put them forward ASAP. + +Thanks! + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +Fine by me, we have those in Karmic (which will be released shortly +before 2.2) so it's still open to backports + +And in Squeeze too, which will release at some point this millennium +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.9 (MingW32) +Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ + +iQEcBAEBAgAGBQJKixEoAAoJEMkPnLkOH60MjlYIAIGgij6CUpS+38gPbHCCLGl5 +T21oM3iB11INEQmMXOxe8LkFD6jRUF/jtv5c6PQ4f/CgGeoeX3xhkGC7L6zCRn0W +4/5VOf6YKCSRTHdQwnrhXBAgPIkAt44b2xBKYKdjXh+JEzsTThj1F6Puk4KMWSIW +vPMRuV07LX5O+LlCV1Tqwr5LZBIPpN8VmD9x6GqPopu/dLXj1LM6SV5r5PLYNRkg +rQGJYwWF3vNLvpM3Lc5bwCiGIUxwruTWwpcO8rlSO3UzCSZIHsKBOBJS7Am6p6wf +GsVzBQbtZn6r5rXpeYrK3w2XlsO2tjrXDFHg5CjLr/Tfc7oWBMqujtimFamyOqU= +=GkeG +-----END PGP SIGNATURE----- + ++ + + +
While trying to figure out how to add a default style for python I +came across a couple things. It seems like the mime-types that are +globally configurable are hard coded (See +MonoDevelop.Projects.Gui.Dialogs.OptionPanels/CodeFormattingPanel.cs +or patch below). And beyond that, I can't seem to find a way to set +the default settings for a mime-type. Am I correct in that all the +default global formats inherit from the plain-text style? + +For python specifically, almost nobody does anything other than +PEP8[1] (4 space tabs, etc). So having that as the default for +text/x-python makes a lot of sense. + +Thoughts? Should we consider getting this in quick for the 2.2 branch? + +-- Christian + +[1] http://www.python.org/dev/peps/pep-0008/ + +Index: main/src/core/MonoDevelop.Projects.Gui/MonoDevelop.Projects.Gui.Dialogs.OptionPanels/CodeFormattingPanel.cs +=================================================================== +--- main/src/core/MonoDevelop.Projects.Gui/MonoDevelop.Projects.Gui.Dialogs.OptionPanels/CodeFormattingPanel.cs (revision +140589) ++++ main/src/core/MonoDevelop.Projects.Gui/MonoDevelop.Projects.Gui.Dialogs.OptionPanels/CodeFormattingPanel.cs (working +copy) +@@ -135,7 +135,7 @@ + else if (DataObject is SolutionItem) + GetItemMimeTypes (types, (SolutionItem)DataObject); + else +- return new string[] { "text/plain", "application/xml", "text/x-csharp" }; ++ return new string[] { "text/plain", "application/xml", +"text/x-csharp", "text/x-python" }; + return types; + } ++ + + + +
same process as usual + +that leaves: +Parser/DomParser.cs: This one was written for MonoDevelop. +Project/VBCompilerParameters.cs: THis one looks rewritten (compared it +with the root of the history) +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: VBLanguageBinding.cs +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090825/7da8f51f/attachment-0003.pl +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: VB.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090825/7da8f51f/attachment-0004.pl +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: VBBindingCompilerServices.cs +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090825/7da8f51f/attachment-0005.pl ++ + + + + +
El dt 25 de 08 de 2009 a les 01:31 -0700, en/na Christian Hergert va +escriure: +> While trying to figure out how to add a default style for python I +> came across a couple things. It seems like the mime-types that are +> globally configurable are hard coded (See +> MonoDevelop.Projects.Gui.Dialogs.OptionPanels/CodeFormattingPanel.cs +> or patch below). + +This is now fixed. MD will show mime types for which there is a custom +options panel defined, and users can also manually register them. + +> And beyond that, I can't seem to find a way to set +> the default settings for a mime-type. Am I correct in that all the +> default global formats inherit from the plain-text style? + +Yes. Right now there is no way of setting the default settings for a +specific mime type. + +> +> For python specifically, almost nobody does anything other than +> PEP8[1] (4 space tabs, etc). So having that as the default for +> text/x-python makes a lot of sense. + +You should define those settings as a policy set. I've seen you added +them to the Mono policy set, but you should create a PEP8 policy set. +Unfortunately, there is no way of setting the default policy set. + +Lluis. + + ++ + + +
Lluis Sanchez Gual wrote: +> El dt 25 de 08 de 2009 a les 01:31 -0700, en/na Christian Hergert va +> escriure: +>> While trying to figure out how to add a default style for python I +>> came across a couple things. It seems like the mime-types that are +>> globally configurable are hard coded (See +>> MonoDevelop.Projects.Gui.Dialogs.OptionPanels/CodeFormattingPanel.cs +>> or patch below). +> +> This is now fixed. MD will show mime types for which there is a custom +> options panel defined, and users can also manually register them. + +Great! + +>> And beyond that, I can't seem to find a way to set +>> the default settings for a mime-type. Am I correct in that all the +>> default global formats inherit from the plain-text style? +> +> Yes. Right now there is no way of setting the default settings for a +> specific mime type. + +This might be a good candidate to add before the 2.2 release. I'm sure +some of users wont even think to change the default settings. I'll +volunteer if its desired and those intimate with the feature are busy. + +>> For python specifically, almost nobody does anything other than +>> PEP8[1] (4 space tabs, etc). So having that as the default for +>> text/x-python makes a lot of sense. +> +> You should define those settings as a policy set. I've seen you added +> them to the Mono policy set, but you should create a PEP8 policy set. +> Unfortunately, there is no way of setting the default policy set. + +I added the python style to the Mono policy set thinking that it might +be useful for IronPython. Migrating to PEP8 sounds fine with me. + +Thanks! + +-- Christian ++ + +
Hi + +We should make monodevelop easier understandable & extendable. + +I think we should do some brain storming about stuff that we encounter +during our daily work with the source code. I begin with the +view/pad/workbench/language binding system. + +* The way it's used it's not build for. + +- For example the workspace window should wrap the gui the view content +is displayed in (for example tab page or window) - therefore it should +be a DockItem directly. It should contain a collection of view contents +(for example text editor/forms designer) - but stetic doesn't use this, +it does it's own. I don't know if the subviews are currently used. + +- The Layout abstraction was for enabling other layout managers. +SharpDevelop had a floating layout (think of gimp layout) and a tabbed +layout (called sdi) - later I got rid of the floating layout, because +maintaining layouts is error prone. Now we don't need the abstraction +anymore. + +* Workbench: We've IWorkbench, Workbench (not implementing IWorkbench +or inheriting DefaultWorkbench), DefaultWorkbench (not inheriting from +Workbench). Easy to explain ? + +* Language bindings: + +- They provide parsers/refactories - but no ambiences ? +- They provide comment tags, but we get comment tags from the syntax +modes. +- They bind to a 'language' and can ask if a file is a source code file +ore not - they're not using our newer mime type system (inconsistent!) +- Maybe they should be attached to a ProjectDom or ViewContent to allow +easier access. + +When 2.2 is released we should put some effort on building a better +framework people can work with. I would like that everybody looks out +for possible code issues. At first not finding solutions, only +collecting possible issues. When we've time and collected enough we can +go over to design work. + +We can need some input from anyone who implemented an addin for +monodevelop. The core team works too long with the code base. Therefore +we're used to it and don't see most possible issues. + +Regards +Mike + ++ + + +
On Mon, Aug 31, 2009 at 7:19 AM, Mike Krüger<mkrueger at novell.com> wrote: +> Hi +> +> We should make monodevelop easier understandable & extendable. +> +> I think we should do some brain storming about stuff that we encounter +> during our daily work with the source code. I begin with the +> view/pad/workbench/language binding system. +> +> * The way it's used it's not build for. +> +> - For example the workspace window should wrap the gui the view content +> is displayed in (for example tab page or window) - therefore it should +> be a DockItem directly. It should contain a collection of view contents +> (for example text editor/forms designer) - but stetic doesn't use this, +> it does it's own. I don't know if the subviews are currently used. + +The ASP.NET designer uses a subview. There used to be an subview for +previews of HTML docs in MD.IDE, but AFAIK it was removed during +deGPLification. + +> - The Layout abstraction was for enabling other layout managers. +> SharpDevelop had a floating layout (think of gimp layout) and a tabbed +> layout (called sdi) - later I got rid of the floating layout, because +> maintaining layouts is error prone. Now we don't need the abstraction +> anymore. + +Well, a floating layout would be useful for the Mac, if anyone cares +to implement it. + +> * Workbench: We've IWorkbench, Workbench (not implementing IWorkbench +> or inheriting DefaultWorkbench), DefaultWorkbench (not inheriting from +> Workbench). Easy to explain ? + +Nop, eit's a mess. + +> * Language bindings: +> +> - They provide parsers/refactories - but no ambiences ? +> - They provide comment tags, but we get comment tags from the syntax +> modes. +> - They bind to a 'language' and can ask if a file is a source code file +> ore not - they're not using our newer mime type system (inconsistent!) + +Agreed. + +> - Maybe they should be attached to a ProjectDom or ViewContent to allow +> easier access. +> +> When 2.2 is released we should put some effort on building a better +> framework people can work with. I would like that everybody looks out +> for possible code issues. At first not finding solutions, only +> collecting possible issues. When we've time and collected enough we can +> go over to design work. +> +> We can need some input from anyone who implemented an addin for +> monodevelop. The core team works too long with the code base. Therefore +> we're used to it and don't see most possible issues. + +True. I think that in particular people implementing non-.NET language +bindings are having problems with some of our .NET-centric APIs. Maybe +we should solicit opinions from them. + +There are some areas that I would like to overhaul too: + +* file/project templating system: I've really been stressing it, +particularly with ASP.NET / ASP.NET MVC templates, and it makes a lot +of things difficult. + +* new file/project dialog: these have poor usability and organization. + +* code templates. I'd like to have APIs for addins to add code templates.\ + +* There are many places in the project system where a "configuration" +string is passed around and it's unclear whether it's a project +configuration (and should be looked up with GetConfiguration) or a +solution configuration (and the project configuration should be looked +up with GetActiveConfiguration).. This API really needs usability +improvements. + +I would also really like to do a full gendarme run against MD and +review the results. Maybe this will catch some bugs or API issues. Of +course, it would help if the CodeAnalysis addin were complete... + +It would also be very useful to improve the MD docs. I think there's a +good case to be made for using XML documentation -- see my previous +email on the topic. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
El dl 31 de 08 de 2009 a les 13:19 +0200, en/na Mike Krüger va escriure: +> Hi +> +> We should make monodevelop easier understandable & extendable. +> +> I think we should do some brain storming about stuff that we encounter +> during our daily work with the source code. I begin with the +> view/pad/workbench/language binding system. +> +> * The way it's used it's not build for. +> +> - For example the workspace window should wrap the gui the view content +> is displayed in (for example tab page or window) - therefore it should +> be a DockItem directly. It should contain a collection of view contents +> (for example text editor/forms designer) - but stetic doesn't use this, +> it does it's own. I don't know if the subviews are currently used. + +Yes, I agree on that this code can be improved. There is some leftover +code from #D that we are not really using. Some functionality currently +implemented in MD.Ide could be directly handled by our docking system. + +> +> - The Layout abstraction was for enabling other layout managers. +> SharpDevelop had a floating layout (think of gimp layout) and a tabbed +> layout (called sdi) - later I got rid of the floating layout, because +> maintaining layouts is error prone. Now we don't need the abstraction +> anymore. +> +> * Workbench: We've IWorkbench, Workbench (not implementing IWorkbench +> or inheriting DefaultWorkbench), DefaultWorkbench (not inheriting from +> Workbench). Easy to explain ? + +IWorkbench and DefaultWorkbench (the layout abstraction) are #D +leftovers. They are internal, so they are not relevant to add-in +developers. + +Workbench is the only public class. + +> +> * Language bindings: +> +> - They provide parsers/refactories - but no ambiences ? + +Ambiences have their own extension points. Maybe we should do the same +for parsers and refactory providers? I don't know if it makes sense. + +We should review the api and see how language bindings are currently +used. So for example, if we move the comment tag properties to syntax +modes, and parser/refactorer have their own extension points, there +isn't much left in ILanguageBinding. This code has evolved a lot since +it was designed, so maybe it can go away or it can be replaced by +something else. + +> - They provide comment tags, but we get comment tags from the syntax +> modes. + +I think we should get rid of those comment tag properties from +ILanguageBinding, and use only the info from syntax modes. However, they +are still being used when creating a new file to insert the license +header. We have to find a way of querying information from syntax modes +without having and instance of an editor. + +> - They bind to a 'language' and can ask if a file is a source code file +> ore not - they're not using our newer mime type system (inconsistent!) + +The mime-type system doesn't have information about which types are +source code files. We have per-mime-type formatting policies, but this +is unrelated. + +> - Maybe they should be attached to a ProjectDom or ViewContent to allow +> easier access. + +I don't think that's necessary. You can already get a language binding +from Project, and you can get a project from ProjectDom and ViewContent. + +> +> When 2.2 is released we should put some effort on building a better +> framework people can work with. I would like that everybody looks out +> for possible code issues. At first not finding solutions, only +> collecting possible issues. When we've time and collected enough we can +> go over to design work. + +Our resources are limited, so we have to be careful about where we put +our development effort. We should focus on fixing, improving or +implementing features that users really need. Improving the API is part +of the work, but we have to find the right effort/benefit balance. + +Lluis. + + ++ + + +
First and foremost, I'd like to see all the legacy code that is somewhat +broken or need work to be useful to be moved somewhere like "attic". + +I think making a list of common extension topics we can create a clear +picture of what the API should look like. It's pretty obvious where the +pain points are when you try to follow a howto on adding a feature (even +if a quick ad-hoc one). + +I'd really like to be able to script a lot of my daily tasks in the IDE +without writing an Addin (JavaScript or similar). We could provide a +small scripting environment with a simpler API that tries to cover the +80% in a friendly way. + +-- Christian + +Lluis Sanchez Gual wrote: +> El dl 31 de 08 de 2009 a les 13:19 +0200, en/na Mike Krüger va escriure: +>> Hi +>> +>> We should make monodevelop easier understandable& extendable. +>> +>> I think we should do some brain storming about stuff that we encounter +>> during our daily work with the source code. I begin with the +>> view/pad/workbench/language binding system. +>> +>> * The way it's used it's not build for. +>> +>> - For example the workspace window should wrap the gui the view content +>> is displayed in (for example tab page or window) - therefore it should +>> be a DockItem directly. It should contain a collection of view contents +>> (for example text editor/forms designer) - but stetic doesn't use this, +>> it does it's own. I don't know if the subviews are currently used. +> +> Yes, I agree on that this code can be improved. There is some leftover +> code from #D that we are not really using. Some functionality currently +> implemented in MD.Ide could be directly handled by our docking system. +> +>> - The Layout abstraction was for enabling other layout managers. +>> SharpDevelop had a floating layout (think of gimp layout) and a tabbed +>> layout (called sdi) - later I got rid of the floating layout, because +>> maintaining layouts is error prone. Now we don't need the abstraction +>> anymore. +>> +>> * Workbench: We've IWorkbench, Workbench (not implementing IWorkbench +>> or inheriting DefaultWorkbench), DefaultWorkbench (not inheriting from +>> Workbench). Easy to explain ? +> +> IWorkbench and DefaultWorkbench (the layout abstraction) are #D +> leftovers. They are internal, so they are not relevant to add-in +> developers. +> +> Workbench is the only public class. +> +>> * Language bindings: +>> +>> - They provide parsers/refactories - but no ambiences ? +> +> Ambiences have their own extension points. Maybe we should do the same +> for parsers and refactory providers? I don't know if it makes sense. +> +> We should review the api and see how language bindings are currently +> used. So for example, if we move the comment tag properties to syntax +> modes, and parser/refactorer have their own extension points, there +> isn't much left in ILanguageBinding. This code has evolved a lot since +> it was designed, so maybe it can go away or it can be replaced by +> something else. +> +>> - They provide comment tags, but we get comment tags from the syntax +>> modes. +> +> I think we should get rid of those comment tag properties from +> ILanguageBinding, and use only the info from syntax modes. However, they +> are still being used when creating a new file to insert the license +> header. We have to find a way of querying information from syntax modes +> without having and instance of an editor. +> +>> - They bind to a 'language' and can ask if a file is a source code file +>> ore not - they're not using our newer mime type system (inconsistent!) +> +> The mime-type system doesn't have information about which types are +> source code files. We have per-mime-type formatting policies, but this +> is unrelated. +> +>> - Maybe they should be attached to a ProjectDom or ViewContent to allow +>> easier access. +> +> I don't think that's necessary. You can already get a language binding +> from Project, and you can get a project from ProjectDom and ViewContent. +> +>> When 2.2 is released we should put some effort on building a better +>> framework people can work with. I would like that everybody looks out +>> for possible code issues. At first not finding solutions, only +>> collecting possible issues. When we've time and collected enough we can +>> go over to design work. +> +> Our resources are limited, so we have to be careful about where we put +> our development effort. We should focus on fixing, improving or +> implementing features that users really need. Improving the API is part +> of the work, but we have to find the right effort/benefit balance. +> +> Lluis. +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list ++ + +
Starting: Tue Aug 4 11:30:00 EDT 2009
+ Ending: Mon Aug 31 19:17:03 EDT 2009
+ Messages: 37
+
+ Last message date:
+ Mon Aug 31 19:17:03 EDT 2009
+ Archived on: Mon Aug 31 19:15:36 EDT 2009
+
+
+
Starting: Tue Aug 4 11:30:00 EDT 2009
+ Ending: Mon Aug 31 19:17:03 EDT 2009
+ Messages: 37
+
+ Last message date:
+ Mon Aug 31 19:17:03 EDT 2009
+ Archived on: Mon Aug 31 19:15:36 EDT 2009
+
+
+
Starting: Tue Aug 4 11:30:00 EDT 2009
+ Ending: Mon Aug 31 19:17:03 EDT 2009
+ Messages: 37
+
+ Last message date:
+ Mon Aug 31 19:17:03 EDT 2009
+ Archived on: Mon Aug 31 19:15:36 EDT 2009
+
+
+
Starting: Tue Aug 4 11:30:00 EDT 2009
+ Ending: Mon Aug 31 19:17:03 EDT 2009
+ Messages: 37
+
+ Last message date:
+ Mon Aug 31 19:17:03 EDT 2009
+ Archived on: Mon Aug 31 19:15:36 EDT 2009
+
+
+
Starting: Tue Aug 4 11:30:00 EDT 2009
+ Ending: Mon Aug 31 19:17:03 EDT 2009
+ Messages: 37
+
+ Last message date:
+ Mon Aug 31 19:17:03 EDT 2009
+ Archived on: Mon Aug 31 19:15:36 EDT 2009
+
+
+
Hi everyone, + +One of my work items for MonoDevelop 2.4 is to rework the file/project +dialogs, which necessitates working on the templating system too. This +will +* Drastically improve usability of the new file/project dialogs +* Make it much easier for people to create and manage their own templates + +As secondary objective, I'd also like to +* Rework the unmaintainable mess the templating system has become, and +break the tight coupling between the template dialog and the template +system +* Support templates with options - toggles/combos, class pickers, +entries - and declarative validation +* Merge the ASP.NET MVC T4 template system into the main templating system +* Allow per-solution templates that can override built-ins, like in ASP.NET MVC +* Kill the C#->codedom converter and ASP.NET substitution templates. +They're not very reliable. + +The two items are on the wiki at +http://monodevelop.com/Developers/Tasks/General/Workspace_Usability_Overhaul#_task_a_General.Wb.NewProjectDialog + +I'm seeking input and ideas so we can make the user experience as good +as possible + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
This will break something in trunk revision of MD during this work ? +What about the gnome-osc plugging VS MonoOBSFramework ? + +2009/12/21 Michael Hutchinson <m.j.hutchinson at gmail.com>: +> Hi everyone, +> +> One of my work items for MonoDevelop 2.4 is to rework the file/project +> dialogs, which necessitates working on the templating system too. This +> will +> * Drastically improve usability of the new file/project dialogs +> * Make it much easier for people to create and manage their own templates +> +> As secondary objective, I'd also like to +> * Rework the unmaintainable mess the templating system has become, and +> break the tight coupling between the template dialog and the template +> system +> * Support templates with options - toggles/combos, class pickers, +> entries - and declarative validation +> * Merge the ASP.NET MVC T4 template system into the main templating system +> * Allow per-solution templates that can override built-ins, like in ASP.NET MVC +> * Kill the C#->codedom converter and ASP.NET substitution templates. +> They're not very reliable. +> +> The two items are on the wiki at +> http://monodevelop.com/Developers/Tasks/General/Workspace_Usability_Overhaul#_task_a_General.Wb.NewProjectDialog +> +> I'm seeking input and ideas so we can make the user experience as good +> as possible +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- + Cordially. + +Deploy your softwares for all platforms and finally update them in 3 clicks. +Try now the OpenSource MonoOSC tool +http://monoosc.sourceforge.net/ +http://download.opensuse.org/repositories/home:/surfzoid/ +http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/ +http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu:/Mono/ + + Small Eric Quotations of the days: + --------------------------------------------------------------------------- + I have no special talents. I am only passionately curious ++ + + +
A nice stuff should be a template for Monodevelop Addin, still already exist ? + +2009/12/22 Petit Eric <surfzoid at gmail.com>: +> This will break something in trunk revision of MD during this work ? +> What about the gnome-osc plugging VS MonoOBSFramework ? +> +> 2009/12/21 Michael Hutchinson <m.j.hutchinson at gmail.com>: +>> Hi everyone, +>> +>> One of my work items for MonoDevelop 2.4 is to rework the file/project +>> dialogs, which necessitates working on the templating system too. This +>> will +>> * Drastically improve usability of the new file/project dialogs +>> * Make it much easier for people to create and manage their own templates +>> +>> As secondary objective, I'd also like to +>> * Rework the unmaintainable mess the templating system has become, and +>> break the tight coupling between the template dialog and the template +>> system +>> * Support templates with options - toggles/combos, class pickers, +>> entries - and declarative validation +>> * Merge the ASP.NET MVC T4 template system into the main templating system +>> * Allow per-solution templates that can override built-ins, like in ASP.NET MVC +>> * Kill the C#->codedom converter and ASP.NET substitution templates. +>> They're not very reliable. +>> +>> The two items are on the wiki at +>> http://monodevelop.com/Developers/Tasks/General/Workspace_Usability_Overhaul#_task_a_General.Wb.NewProjectDialog +>> +>> I'm seeking input and ideas so we can make the user experience as good +>> as possible +>> +>> -- +>> Michael Hutchinson +>> http://mjhutchinson.com +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +> +> +> +> -- +> Cordially. +> +> Deploy your softwares for all platforms and finally update them in 3 clicks. +> Try now the OpenSource MonoOSC tool +> http://monoosc.sourceforge.net/ +> http://download.opensuse.org/repositories/home:/surfzoid/ +> http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/ +> http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu:/Mono/ +> +> Small Eric Quotations of the days: +> --------------------------------------------------------------------------- +> I have no special talents. I am only passionately curious +> + + + +-- + Cordially. + +Deploy your softwares for all platforms and finally update them in 3 clicks. +Try now the OpenSource MonoOSC tool +http://monoosc.sourceforge.net/ +http://download.opensuse.org/repositories/home:/surfzoid/ +http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/ +http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu:/Mono/ + + Small Eric Quotations of the days: + --------------------------------------------------------------------------- + I have no special talents. I am only passionately curious ++ + + + +
On Tue, Dec 22, 2009 at 3:37 AM, Petit Eric <surfzoid at gmail.com> wrote: +> This will break something in trunk revision of MD during this work ? + +Nope, it won't be enabled until it's working. + +> What about the gnome-osc plugging VS MonoOBSFramework ? + +Hm, I'm afraid I'm really busy with the 2.4 targets, so I can't really +do any more for obs/osc than to give advice. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
On Mon, Dec 21, 2009 at 3:10 PM, Michael Hutchinson +<m.j.hutchinson at gmail.com> wrote: +> One of my work items for MonoDevelop 2.4 is to rework the file/project +> dialogs, which necessitates working on the templating system too. This +... +> I'm seeking input and ideas so we can make the user experience as good +> as possible + +I've shared my planning document at +http://docs.google.com/Doc?docid=0AQR9fLn9hEwTZGdxY3c2NWtfMzVjbWt2bXFjaA&hl=en_GB + +I'm still looking for feedback on what users want from a templating +system - both from people writing addins, and people writing templates +for their own use. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Tue, Dec 22, 2009 at 4:44 AM, Petit Eric <surfzoid at gmail.com> wrote: +> A nice stuff should be a template for Monodevelop Addin, still already exist ? + +That;s the domain of the MonoDevelop.AddinAuthoring addin, which isn't +functional yet, but Lluis is working on it from time to time. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Mon Dec 21 15:10:29 EST 2009
+ Ending: Wed Dec 30 16:23:27 EST 2009
+ Messages: 6
+
+ Last message date:
+ Wed Dec 30 16:23:27 EST 2009
+ Archived on: Wed Dec 30 16:26:17 EST 2009
+
+
+
Starting: Mon Dec 21 15:10:29 EST 2009
+ Ending: Wed Dec 30 16:23:27 EST 2009
+ Messages: 6
+
+ Last message date:
+ Wed Dec 30 16:23:27 EST 2009
+ Archived on: Wed Dec 30 16:26:17 EST 2009
+
+
+
Starting: Mon Dec 21 15:10:29 EST 2009
+ Ending: Wed Dec 30 16:23:27 EST 2009
+ Messages: 6
+
+ Last message date:
+ Wed Dec 30 16:23:27 EST 2009
+ Archived on: Wed Dec 30 16:26:17 EST 2009
+
+
+
Starting: Mon Dec 21 15:10:29 EST 2009
+ Ending: Wed Dec 30 16:23:27 EST 2009
+ Messages: 6
+
+ Last message date:
+ Wed Dec 30 16:23:27 EST 2009
+ Archived on: Wed Dec 30 16:26:17 EST 2009
+
+
+
Starting: Mon Dec 21 15:10:29 EST 2009
+ Ending: Wed Dec 30 16:23:27 EST 2009
+ Messages: 6
+
+ Last message date:
+ Wed Dec 30 16:23:27 EST 2009
+ Archived on: Wed Dec 30 16:26:17 EST 2009
+
+
+
I've tried running MD on .NET my combining the dependencies (MonoDoc +in particular was helpful) from Jonathan Pobst's MD zip with dlls +extracted from my trunk RPMs. + +I've successfully run MD on .NET 3.5SP1 on XP32 and Vista64 without +any actual crashes, but a lot of things don't work. + +There are a few caveats to getting it running: + +a) On 64-bits, the MD binary has to be flagged as a 32-bit binary +using Corflags.exe +b) The WindowsPlatformService has to be build against the MD binaries +c) The path in the MonoDevelop.exe.addins has to be altered to use \ +directory separators. +d) Mono.Posix.dll 1.0 has to be installed to the GAC, because MD needs +both 2.0 and 1.0. 2.0 and PosixHelper (as per jpobsts' zip) can go +alongside MD. +e) The GnomePlatformService has to be removed + +I've catalogued the errors I came across so far: + + +1) At startup, and when trying to load projects: + +ERROR [2009-02-06 03:06:42Z]: Add-in error (MonoDevelop.Projects): +System.InvalidOperationException: Duplicate property 'name' in class 'MonoDevelo +p.Projects.UnknownSolutionItem + at MonoDevelop.Core.Serialization.ClassDataType.AddProperty(ItemProperty +prop, String insertBefore) + at MonoDevelop.Core.Serialization.ClassDataType.AddProperty(Object +member, String name, Type memberType) + at MonoDevelop.Core.Serialization.ClassDataType.Initialize() + at MonoDevelop.Core.Serialization.DataContext.GetConfigurationDataType(Type +type) + at MonoDevelop.Core.Serialization.ClassDataType.Initialize() + at MonoDevelop.Core.Serialization.DataContext.GetConfigurationDataType(Type +type) + at MonoDevelop.Core.Serialization.DataContext.IncludeType(Type type) + at MonoDevelop.Projects.ProjectService.OnSerializableExtensionChanged(Objects, +ExtensionNodeEventArgs args) + at Mono.Addins.ExtensionNode.add_ExtensionNodeChanged(ExtensionNodeEventHandler +value) +System.TypeLoadException: Could not load type 'Gdk.ExtensionMode,gdk-sharp' + at Stetic.Registry.GetType(String typeName, Boolean throwOnError) + at Stetic.EnumDescriptor..ctor(XmlElement elem) + at Stetic.WidgetLibrary.Load(XmlDocument objects) + at Stetic.AssemblyWidgetLibrary.Load() + at Stetic.Registry.RegisterWidgetLibrary(WidgetLibrary library) +System.TypeLoadException: Could not load type 'Gdk.ExtensionMode,gdk-sharp' + at Stetic.Registry.GetType(String typeName, Boolean throwOnError) + at Stetic.EnumDescriptor..ctor(XmlElement elem) + at Stetic.WidgetLibrary.Load(XmlDocument objects) + at Stetic.AssemblyWidgetLibrary.Load() + at Stetic.Registry.RegisterWidgetLibrary(WidgetLibrary library) +Marshaling delete_event signal + +2) When closing MD, with no documents open. Prevents cleanly closing MD: + +ERROR [2009-02-06 03:12:41Z]: Unhandled exception in GLib event handler. +System.Reflection.TargetInvocationException: Exception has been thrown by the ta +rget of an invocation. ---> System.TypeLoadException: Could not load type 'Gdk.E +xtensionMode,gdk-sharp' + at Stetic.Registry.GetType(String typeName, Boolean throwOnError) + at Stetic.EnumDescriptor..ctor(XmlElement elem) + at Stetic.WidgetLibrary.Load(XmlDocument objects) + at Stetic.AssemblyWidgetLibrary.Load() + at Stetic.Registry.RegisterWidgetLibrary(WidgetLibrary library) + at Stetic.Registry.Initialize(WidgetLibrary coreLibrary) + at Stetic.ApplicationBackend..ctor(Application app) + at Stetic.LocalApplication..ctor() + at Stetic.ApplicationFactory.CreateApplication(IsolationMode mode) + at MonoDevelop.GtkCore.GuiBuilder.GuiBuilderService.get_SteticApp() + at MonoDevelop.GtkCore.GuiBuilder.GuiBuilderService.OnActiveDocumentChanged(Object +s, EventArgs args) + at System.EventHandler.Invoke(Object sender, EventArgs e) + at MonoDevelop.Ide.Gui.Workbench.OnDocumentChanged(Object s, EventArgs a) + at MonoDevelop.Ide.Gui.DefaultWorkbench.OnActiveWindowChanged(Object +sender,EventArgs e) + at MonoDevelop.Ide.Gui.DefaultWorkbench.CloseAllViews() + at MonoDevelop.Ide.Gui.DefaultWorkbench.Close() + at MonoDevelop.Ide.Gui.DefaultWorkbench.OnClosing(Object o, +DeleteEventArgs e) + --- End of inner exception stack trace --- + at System.RuntimeMethodHandle._InvokeMethodFast(Object target, +Object[] arguments, SignatureStruct& sig, MethodAttributes +methodAttributes, RuntimeTypeHandle typeOwner) + at System.RuntimeMethodHandle.InvokeMethodFast(Object target, +Object[] arguments, Signature sig, MethodAttributes methodAttributes, +RuntimeTypeHandle typeOwner) + at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, +BindingFlags invokeAttr, Binder binder, Object[] parameters, +CultureInfo culture, Boolean skipVisibilityChecks) + at System.Delegate.DynamicInvokeImpl(Object[] args) + at GLib.Signal.ClosureInvokedCB(Object o, ClosureInvokedArgs args) + at GLib.SignalClosure.Invoke(ClosureInvokedArgs args) + at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr +return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr +invocation_hint, IntPtr marshal +_data) + + +3) Dragging pads around: + +WARNING [2009-02-06 03:12:41Z]: Gtk-Warning: GtkContainerClass::remove not imple +mented for `__gtksharp_22_MonoDevelop_Components_Docking_DockContainer' +Stack trace: + at Gtk.Container.CallbackInvoker.Invoke(Widget w) + at MonoDevelop.Components.Docking.DockContainer.ForAll(Boolean +include_internals, Callback callback) + at Gtk.Container.Forall_cb(IntPtr container, Boolean +include_internals, IntPtr cb, IntPtr data) + at Gtk.Container.gtksharp_container_base_forall(IntPtr handle, +Boolean include_internals, IntPtr cb, IntPtr data) + at Gtk.Container.ForAll(Boolean include_internals, Callback callback) + at MonoDevelop.Components.Docking.DockFrame.ForAll(Boolean +include_internals, Callback callback) + at Gtk.Container.Forall_cb(IntPtr container, Boolean +include_internals, IntPtr cb, IntPtr data) + at Gtk.Application.gtk_main() + at Gtk.Application.Run() + at MonoDevelop.Ide.Gui.IdeStartup.Run(String[] args) + at MonoDevelop.Startup.SharpDevelopMain.Main(String[] args) + + +4) A message box warning of of an "Invalid path" when saving +preference of default path for new projects. + + +5) MD shows nonexistent language * if "New file" dialog when no .NET +language addins are present. + + +6) "Illegal Project Name" when creating a solution, presumably due to C:\ etc + + +7) GTK# error prevents opening the text editor: + + +System.AccessViolationException: Attempted to read or write protected +memory. This is often an indication that other memory is corrupt. at +Gtk.TargetList.gtksharp_target_list_to_entry_array(IntPtr list, +TargetEntry[] entries) at Gtk.TargetList.op_Explicit(TargetList +list) at Mono.TextEditor.TextEditor..ctor(Document doc, +ITextEditorOptions options, EditMode initialMode) at +Mono.TextEditor.TextEditor..ctor() at +MonoDevelop.SourceEditor.ExtensibleTextEditor..ctor(SourceEditorView +view) at +MonoDevelop.SourceEditor.SourceEditorWidget..ctor(SourceEditorView +view) at MonoDevelop.SourceEditor.SourceEditorView..ctor() at +MonoDevelop.SourceEditor.SourceEditorDisplayBinding.MonoDevelop.Ide.Codons.IDisplayBinding.CreateContentForMimeType(String +mimeType, Stream content) at +MonoDevelop.Ide.Gui.Workbench.NewDocument(String defaultName, String +mimeType, Stream content) at +MonoDevelop.Ide.Templates.FileTemplate.CreateFile(FileDescriptionTemplate +newfile, +SolutionItem policyParent, Project project, String directory, String +language, String name) at +MonoDevelop.Ide.Templates.FileTemplate.Create(SolutionItem +policyParent, Project project, +String directory, String language, String name) at +MonoDevelop.Ide.Gui.Dialogs.NewFileDialog.OpenEvent(Object sender, +EventArgs e) + +(I only have this on vista64/.net32 the editors open fine on my XP32 machine). + + +8) Addin error at startup: + + +ERROR [2009-02-06 03:30:26Z]: Add-in error (MonoDevelop.NUnit): +System.InvalidOperationException: Type +'MonoDevelop.NUnit.NUnitAssemblyGroupFileFormat, MonoDevelop.NUnit' +not found in add-in 'MonoDevelop.NUnit,1.9.2' + at Mono.Addins.RuntimeAddin.GetType(String typeName, Boolean throwIfNotFound) + + at Mono.Addins.TypeExtensionNode.get_Type() + at Mono.Addins.TypeExtensionNode.CreateInstance() + at Mono.Addins.InstanceExtensionNode.GetInstance() + at Mono.Addins.ExtensionNodeEventArgs.get_ExtensionObject() + at MonoDevelop.Projects.ProjectService.OnFormatExtensionChanged(Object +s, ExtensionNodeEventArgs args) + at Mono.Addins.ExtensionNode.add_ExtensionNodeChanged(ExtensionNodeEventHandler +value) + + +9) Failed GTK+ assertions in the open file dialog: + +ERROR [2009-02-06 03:35:13Z]: GLib-Critical: g_convert: assertion `str != NULL' +failed +Stack trace: + at Gtk.FileChooserDialog.get_Filename() + at MonoDevelop.Ide.Gui.Dialogs.FileSelectorDialog.FillViewers() + at MonoDevelop.Ide.Gui.Dialogs.FileSelectorDialog.OnSelectionChanged() + at Gtk.FileChooserDialog.selectionchanged_cb(IntPtr chooser) + at Gtk.Dialog.gtk_dialog_run(IntPtr raw) + at Gtk.Dialog.Run() + at MonoDevelop.Ide.Commands.OpenFileHandler.Run() + at MonoDevelop.Components.Commands.CommandHandler.Run(Object dataItem) + at MonoDevelop.Components.Commands.ActionCommand.DispatchCommand(Object dataI +tem) + at MonoDevelop.Components.Commands.CommandManager.DispatchCommand(Object comm +andId, Object dataItem, Object initialTarget) + at MonoDevelop.Components.Commands.CommandToolButton.OnClicked() + at Gtk.ToolButton.clicked_cb(IntPtr tool_item) + at Gtk.Application.gtk_main() + at Gtk.Application.Run() + at MonoDevelop.Ide.Gui.IdeStartup.Run(String[] args) + at MonoDevelop.Startup.SharpDevelopMain.Main(String[] args) + + +10) Tabs on bottom of docks are painted upside-down. + + +11) Theme changes of base colour propagate to the children of the +dacks, but not the base areas that the docks draw. + + +12) MD doesn't use native widget styles unless the windows theme is +changed while MD is running. + + +13) I don't have the traces right now, and I can't repro in vista64 +because of (7) but the .NET VM was complaining about violated type +constraints in the history service. I wonder if gmcs is generating +invalid IL? + + +14) Also can't repro right now due to (7), but the text editor was +behaving very strangely, deleting random text, with some generics +errors about the Delete Action<T>. + + +15) At startup, an error scanning an unmanaged dll: +ERROR: There was an error while scanning assembly: +C:\Users\Michael\Desktop\MonoDevelop\bin\MonoPosixHelper.dll (The +module was expected to contain an assembly manifest. (Exception from +HRESULT: 0x80131018)) + + +15) Querying the assembly code completion DB causes everything to fall +apart horribly (offset errors on pidbs, remoting failed to start, +MonoDoc panicking etc), so C# and ASP.NET completion are out of the +question right now. However, I did get HTML completion working despite +(14). + + +16) Addin error: +ERROR [2009-02-06 04:01:50Z]: Add-in error (MonoDevelop.NUnit): +System.InvalidOperationException: Type +'MonoDevelop.NUnit.NUnitAssemblyGroupFileFormat, MonoDevelop.NUnit' +not found in add-in 'MonoDevelop.NUnit,1.9.2' + at Mono.Addins.RuntimeAddin.GetType(String typeName, Boolean throwIfNotFound) + at Mono.Addins.TypeExtensionNode.get_Type() + at Mono.Addins.TypeExtensionNode.CreateInstance() + at Mono.Addins.InstanceExtensionNode.GetInstance() + at Mono.Addins.ExtensionNodeEventArgs.get_ExtensionObject() + at MonoDevelop.Projects.ProjectService.OnFormatExtensionChanged(Object +s, ExtensionNodeEventArgs args) + at Mono.Addins.ExtensionNode.add_ExtensionNodeChanged(ExtensionNodeEventHandler +value) + + +17) Closing default policies window after changing settings: + +ERROR [2009-02-06 04:04:04Z]: Error writing default policies file +'C:\Users\Michael\AppData\Roaming\MonoDevelop\.#DefaultPolicies.xml' +System.NullReferenceException: Object reference not set to an instance +of an object. + at MonoDevelop.Projects.Policies.PolicySet.SaveToFile(StreamWriter writer) + at MonoDevelop.Projects.Policies.PolicyService.<SaveDefaultPolicies>m__11(StreamWriter +writer) + at MonoDevelop.Projects.Policies.PolicyService.ParanoidSave(String +fileName,String friendlyName, Action`1 write) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Fri, Feb 6, 2009 at 4:29 AM, Michael Hutchinson +<m.j.hutchinson at gmail.com> wrote: +> I've tried running MD on .NET my combining the dependencies (MonoDoc +> in particular was helpful) from Jonathan Pobst's MD zip with dlls +> extracted from my trunk RPMs. +> +> I've successfully run MD on .NET 3.5SP1 on XP32 and Vista64 without +> any actual crashes, but a lot of things don't work. + +Screenshot @ http://mjhutchinson.com/files/images/MonoScreenshots/PreliminaryMonoDevelopOnVista64.png + +> 13) I don't have the traces right now, and I can't repro in vista64 +> because of (7) but the .NET VM was complaining about violated type +> constraints in the history service. I wonder if gmcs is generating +> invalid IL? + +OK, found this one: + +System.Reflection.TargetInvocationException: Exception has been thrown +by the target of an invocation. ---> System.TypeLoadException: +GenericArguments[0], 'T', on 'MonoDevelop.Ide.Gui.HistoryList`1[T]' +violates the constraint of type parameter 'T'. + at MonoDevelop.Ide.Gui.HistoryList`1.<>c__Iterator6.System.Collections.Generic.IEnumerable<T>.GetEnumerator() + at MonoDevelop.Ide.Gui.HistoryList`1.get_Item(Int32 index) + at MonoDevelop.Ide.Gui.NavigationHistoryService.LogActiveDocument(Boolean +transient) + at MonoDevelop.Ide.Gui.NavigationHistoryService.ActiveDocChanged(Object +sender, EventArgs args) + at System.EventHandler.Invoke(Object sender, EventArgs e) + at MonoDevelop.Ide.Gui.Workbench.OnDocumentChanged(Object s, EventArgs a) + at MonoDevelop.Ide.Gui.DefaultWorkbench.OnActiveWindowChanged(Object +sender, EventArgs e) + at MonoDevelop.Ide.Gui.SdiWorkbenchLayout.ActiveMdiChanged(Object +sender, SwitchPageArgs e) + at MonoDevelop.Ide.Gui.SdiWorkbenchLayout.RemoveTab(Int32 pageNum) + at MonoDevelop.Ide.Gui.SdiWorkspaceWindow.CloseWindow(Boolean +force, Boolean fromMenu, Int32 pageNum) + at MonoDevelop.Ide.Gui.SdiWorkbenchLayout.closeClicked(Object o, EventArgs e) + at MonoDevelop.Components.TabLabel.ButtonClicked(Object o, +EventArgs eventArgs) + --- End of inner exception stack trace --- + at System.RuntimeMethodHandle._InvokeMethodFast(Object target, +Object[] arguments, SignatureStruct& sig, MethodAttributes +methodAttributes, RuntimeTypeHandle typeOwner) + at System.RuntimeMethodHandle.InvokeMethodFast(Object target, +Object[] arguments, Signature sig, MethodAttributes methodAttributes, +RuntimeTypeHandle typeOwner) + at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, +BindingFlags invokeAttr, Binder binder, Object[] parameters, +CultureInfo culture, Boolean skipVisibilityChecks) + at System.Delegate.DynamicInvokeImpl(Object[] args) + at GLib.Signal.ClosureInvokedCB(Object o, ClosureInvokedArgs args) + at GLib.SignalClosure.Invoke(ClosureInvokedArgs args) + at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr +return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr +invocation_hint, IntPtr marshal_data) + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On 02/06/2009 01:29 AM, Michael Hutchinson wrote: +> d) Mono.Posix.dll 1.0 has to be installed to the GAC, because MD needs +> both 2.0 and 1.0. 2.0 and PosixHelper (as per jpobsts' zip) can go +> alongside MD. + +Hmm, you could probably fix this with some dll.config magic and a subdir +for each. + +> 15) At startup, an error scanning an unmanaged dll: +> ERROR: There was an error while scanning assembly: +> C:\Users\Michael\Desktop\MonoDevelop\bin\MonoPosixHelper.dll (The +> module was expected to contain an assembly manifest. (Exception from +> HRESULT: 0x80131018)) + +Pretty sure this is just Mono.Addins scanning every assembly in that +directory, for obvious reasons. + +Exciting stuff! + +Sandy ++ + + +
> 1) At startup, and when trying to load projects: +> +> ERROR [2009-02-06 03:06:42Z]: Add-in error (MonoDevelop.Projects): +> System.InvalidOperationException: Duplicate property 'name' in class 'MonoDevelo +> p.Projects.UnknownSolutionItem +> at MonoDevelop.Core.Serialization.ClassDataType.AddProperty(ItemProperty +> prop, String insertBefore) +> at MonoDevelop.Core.Serialization.ClassDataType.AddProperty(Object +> member, String name, Type memberType) +> at MonoDevelop.Core.Serialization.ClassDataType.Initialize() +> at MonoDevelop.Core.Serialization.DataContext.GetConfigurationDataType(Type +> type) +> at MonoDevelop.Core.Serialization.ClassDataType.Initialize() +> at MonoDevelop.Core.Serialization.DataContext.GetConfigurationDataType(Type +> type) +> at MonoDevelop.Core.Serialization.DataContext.IncludeType(Type type) +> at MonoDevelop.Projects.ProjectService.OnSerializableExtensionChanged(Objects, +> ExtensionNodeEventArgs args) +> at Mono.Addins.ExtensionNode.add_ExtensionNodeChanged(ExtensionNodeEventHandler +> value) +> System.TypeLoadException: Could not load type 'Gdk.ExtensionMode,gdk-sharp' +> at Stetic.Registry.GetType(String typeName, Boolean throwOnError) +> at Stetic.EnumDescriptor..ctor(XmlElement elem) +> at Stetic.WidgetLibrary.Load(XmlDocument objects) +> at Stetic.AssemblyWidgetLibrary.Load() +> at Stetic.Registry.RegisterWidgetLibrary(WidgetLibrary library) +> System.TypeLoadException: Could not load type 'Gdk.ExtensionMode,gdk-sharp' +> at Stetic.Registry.GetType(String typeName, Boolean throwOnError) +> at Stetic.EnumDescriptor..ctor(XmlElement elem) +> at Stetic.WidgetLibrary.Load(XmlDocument objects) +> at Stetic.AssemblyWidgetLibrary.Load() +> at Stetic.Registry.RegisterWidgetLibrary(WidgetLibrary library) +> Marshaling delete_event signal +> + +I have filed the cause of this as bug 469848. When this is fixed, it +should break on Mono as well. Basically there is a hierarchy like: + +abstract Item -> SolutionItem -> UnknownSolutionItem + +SolutionItem and UnknownSolutionItem have a serialize attribute of +"name" on them. On Mono, GetCustomAttributes only returns the one on +UnknownSolutionItem, not both of them like on .Net. + +> +> 4) A message box warning of of an "Invalid path" when saving +> preference of default path for new projects. +> 6) "Illegal Project Name" when creating a solution, presumably due to C:\ etc +> + +#6 needs the ":" removed from IsValidPath in FileService.cs. #4 might +be the same as well. + +> +> 7) GTK# error prevents opening the text editor: +> +> +> System.AccessViolationException: Attempted to read or write protected +> memory. This is often an indication that other memory is corrupt. at +> Gtk.TargetList.gtksharp_target_list_to_entry_array(IntPtr list, +> TargetEntry[] entries) at Gtk.TargetList.op_Explicit(TargetList +> list) at Mono.TextEditor.TextEditor..ctor(Document doc, +> ITextEditorOptions options, EditMode initialMode) at +> Mono.TextEditor.TextEditor..ctor() at +> MonoDevelop.SourceEditor.ExtensibleTextEditor..ctor(SourceEditorView +> view) at +> MonoDevelop.SourceEditor.SourceEditorWidget..ctor(SourceEditorView +> view) at MonoDevelop.SourceEditor.SourceEditorView..ctor() at +> MonoDevelop.SourceEditor.SourceEditorDisplayBinding.MonoDevelop.Ide.Codons.IDisplayBinding.CreateContentForMimeType(String +> mimeType, Stream content) at +> MonoDevelop.Ide.Gui.Workbench.NewDocument(String defaultName, String +> mimeType, Stream content) at +> MonoDevelop.Ide.Templates.FileTemplate.CreateFile(FileDescriptionTemplate +> newfile, +> SolutionItem policyParent, Project project, String directory, String +> language, String name) at +> MonoDevelop.Ide.Templates.FileTemplate.Create(SolutionItem +> policyParent, Project project, +> String directory, String language, String name) at +> MonoDevelop.Ide.Gui.Dialogs.NewFileDialog.OpenEvent(Object sender, +> EventArgs e) +> +> (I only have this on vista64/.net32 the editors open fine on my XP32 machine). +> +> + +This is bug #459974. + +> 10) Tabs on bottom of docks are painted upside-down. + +My understanding is this is a limitation of the Gtk+ Wimp theme. + +Jonathan ++ + + +
Hi all, + +Over the weekend I brought the MD project files to a state where MD +main can be built and debugged in VS from a clean SVN checkout. It's +still pretty rough, but here are my (also rough) notes from the +problems and potential problems that I found. + +Note that same of these changes make a "make-less" build of MD possible too. + + +* MD writes "." values for icons elements in some csproj files. Breaks +build. [RESOLVED] + Removed offending elements. Not sure if I should file a bug against MD. + +* WarnAsError breaks build since CSC has more warnings [RESOLVED] + Disabled WarnAsError for now. + +* Some pointless csc variable scope errors [RESOLVED] + Renamed variables where necessary. + +* Very picky about implicit references [RESOLVED] + MD local copies a lot of files during the build to keep mcs happy, +then deletes then afterwards. VS just seems to require explicit +references to everything. + +* Autotools-generated files : BuildVariables.cs and +MonoDevelop.projects.dll.config [RESOLVED] + Committed these to SVN, so autotools is no longer necessary before +first compiling MD. Autotools will still update BuildVariables when +version numbers in configure.in change. The .config file is now +platform-independent. + +* The make-based build of Cecil doesn't work, and this affects a lot +of projects [RESOLVED] + Added working project files for Cecil. + +* WindowsPlatform not built [RESOLVED] + I added DebugWindows and DebugMac solution-level configurations that +build only the appropriate addins. + +* Need Nunit 2.2 + UnitTests specifies nunit 2.2 locked version + +* Need GTK# 2.8 dlls for build, since we've locked referenced GTK# version + +* Some projects ref GTK# > 2.8 [RESOLVED] + Fixed refs. + +* Unwanted local copy of referenced projects in many places [RESOLVED] + Marked not to local copy. + +* Unwanted local copy of GTK#, nunit, mono.cairo, mono.posix etc + Do we have to put these in the GAC to stop VS local copying them? + +* string mainRep = "http://go-mono.com/md/" + +AddinManager.CurrentAddin.Version + "/main.mrep"; fails if Mono.Addins +has already loaded another local-copied version of the IDE assembly +and the hashes do not match in the Mono.Addins internal assembly list + Maybe the hash should be on the assembly name and not the location. +Is this a Mono/>NET difference? + +* Local copy of autotools, aspnet, moonlight template files isn't +where the addin expects [RESOLVED] + Changed deployment paths to match what local copy does. + +* IDE data files (build/data) are not copied by build process + The files in build/data aren't copied during the buiold. + +* mdrun & mdtool build to a directory too far up [RESOLVED] + Fixed output location. + +* startup project not stored in .sln [NOT POSSIBLE] + AFAICT the startup project isn't stored with the sln. + +* Need x86 target for MonoDevelop.Startup to be able to debug on +x86_64 [RESOLVED] + Added Debug|x86 configurations for Mono.Startup, mdrun and mdhost, +added platform=x86 flags, map these to DebugWin32 solution config. + +* XmlTextWriter.Settings is null by default on .NET, so calling +writer.Indent causes NRE. + Should use XmlWriter factory instead. File a Mono bug? + +* Mono.posix move call fails silently, so "safe writes" of text files +in various places do not work. + Maybe this needs to be handled by the platform service. + +* Mono.Addins' remote reflection process runs as .NET 1.1, can't read +2.0 assemblies? + Had to build local M.A. with .NET 2 to fix. Not 100% sure what was +going on here. + +* Mono.Addins: [MethodImpl(MethodImplOptions.NoInlining)] should be +added on methods that contain Assembly.GetCallingAssembly (); calls +[PATCHED IN LOCAL MONO.ADDINS] + Don't know if lack of this actually breaks anything but it might be +good to do just in case. + +* Mono.Addins: Runtime dependencies' paths / are not mapped to Windows +paths \, breaks Autotools, xml, aspnet, moonlight [PATCHED IN LOCAL +MONO.ADDINS] + Breaks addins that have file dependencies + +* SdiWorkbenchLayout has hardcoded / + +* ProcessHostController invokes Mono [PATCHED LOCALLY] + Should just be able to invoke the mdhost exe directly, except that +it's passing --debug to Mono if MD's in debug mode. My patch invokes +the exe directly unless MD's running on Mono *and* is in debug mode. + +* Remoting using TCIP-IP is blocked by the firewall + Should we use use the .NET 2.0 IPC channel instead of "unix"? IIRC +on Linux the IPC channel is Unix sockets anyway. + +* VS upgrades ProductType minor version number (SP1?) + Maybe we should update. + +* VS adds <SubType>Component</SubType> to a few files in project files + Not sure why. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On 02/08/2009 07:06 PM, Michael Hutchinson wrote: +> * MD writes "." values for icons elements in some csproj files. Breaks +> build. [RESOLVED] +> Removed offending elements. Not sure if I should file a bug against MD. + +I've noticed that. It's been a problem for me when trying to build +Mono.Addins using Visual Studio. + +Sandy ++ + + +
Hi All, +Good Day, +I am trying to write an add-in which can parse the C# code and spit out information like Method Name and Signature , Method Body, Method Call information. + +Can I extend MonoDevleop.Projects and use MonoDevelop.Projects.Dom and MonoDevelop.Projects.Dom.Parser. Can any body throw some light on the same. + + +Please note my experience with C# is minimal. + +Regards, +Allahbaksh +Allahbaksh Mohammedali Asadullah, +Software Engineering & Technology Labs, +Infosys Technolgies Limited, Electronics City, +Hosur Road, Bangalore 560 100, India. +*Board: +91-80-28520261 | Extn: 53915 | Direct: 41173915. +Fax: +91-80-28520362 | Mobile: +91-9845505322. +http://setlabs/slim/ +http://allahbaksh.blogspot.com<http://allahbaksh.blogspot.com/> + + + + + +**************** CAUTION - Disclaimer ***************** +This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely +for the use of the addressee(s). If you are not the intended recipient, please +notify the sender by e-mail and delete the original message. Further, you are not +to copy, disclose, or distribute this e-mail or its contents to any other person and +any such actions are unlawful. This e-mail may contain viruses. Infosys has taken +every reasonable precaution to minimize this risk, but is not liable for any damage +you may sustain as a result of any virus in this e-mail. You should carry out your +own virus checks before opening the e-mail or attachment. Infosys reserves the +right to monitor and review the content of all messages sent to or from this e-mail +address. Messages sent to or from this e-mail address may be stored on the +Infosys e-mail system. +***INFOSYS******** End of Disclaimer ********INFOSYS*** +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090217/1ea1915b/attachment.html ++ + + +
Hi. + +I am using a latest trunk. Few days ago Lluis you commited +changes that allow to running unit tests in different modes - +eg. debugging. I think this is (or would be ;) ) a great feature - +I was missing it a lot. + +Unfortunatley it killed for me an ability to launch unittests. +And some other side effects appeard at the same time, although they +may not be related. I am curious if I'm the only one experiencing it ;) + +First - the side effects, not clearly reproducible, happening randomly: +- make run - hangs sometimes, (sth like one in three runs) + cd main && make run + make[1]: Entering directory `/home/silk/devel/monodevelop/main' + MONODEVELOP_LOCALE_PATH=./build/locale MONO_ADDINS_REGISTRY=./build/bin + MOZILLA_FIVE_HOME= LD_LIBRARY_PATH=`echo "/opt/mono-2.2/lib::" | sed + 's/^://g'`d exec -a "monodevelop" /opt/mono-2.2/bin/mono --debug + ./build/bin/MonoDevelop.exe + + ** (./build/bin/MonoDevelop.exe:2908): WARNING **: Symbol file + /usr/local/lib/mono/gac/Mono.Addins.Setup/0.4.0.0__0738eb9f132ed756/Mono.Addins.Setup.dll.mdb + has incorrect version (expected 50.0, got 39) + + ** (./build/bin/MonoDevelop.exe:2908): WARNING **: Symbol file + /usr/local/lib/mono/gac/Mono.Addins/0.4.0.0__0738eb9f132ed756/Mono.Addins.dll.mdb + has incorrect version (expected 50.0, got 39) +(it stops here, no gui is shown - few minutes waiting) +^C + make[1]: *** [runmd] Interrupt + make: *** [run] Interrupt + +- action of openning solution, building sometimes "do not finish" - + statusbar shows "Opening solution xxx ...", options in menus are + grayed out, etc. Switching tabs in editor makes the action finish. + For example: I "Run" project. It compiles fines, but MD thinks the + compilation process is still running. Switch tabs in editor, and MD + accepts the compilation finished, and runs the exe. + This one was happening very often on 18.02, now it is very very rare, + but I see it sometimes. + +And the problem with unit test - reproduced with all configs deleted and +clean build. +Running or debugging unit tests does not work. I push "run test" on +test, and get in console: + +# DebuggerServer started +Module mdhost, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null +loaded. +>> OnInitialized +<< OnInitialized +Module System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, +PublicKeyToken=b77a5c561934e089 loaded. +Module MonoDevelop.Core, Version=1.9.2.0, Culture=neutral, +PublicKeyToken=null loaded. +Module Mono.Posix, Version=2.0.0.0, Culture=neutral, +PublicKeyToken=0738eb9f132ed756 loaded. + +System.Runtime.Serialization.SerializationException: serializationStream +supports seeking, but its length is 0 + at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00094] in /home/silk/devel/mono-2.2/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/BinaryFormatter.cs:181 + at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream) [0x00000] in /home/silk/devel/mono-2.2/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/BinaryFormatter.cs:134 + at MonoDevelopProcessHost.Main (System.String[] args) [0x000ca] in /home/silk/devel/monodevelop/main/src/tools/mdhost/src/mdhost.cs:74 + +And in test result pad: +http://boktor.net/pliki/screenshots/unittest-ss-bug.png +(unfortunatle there is no possibility to copy the text, hence +the screenshot). + + +Mono 2.2 +MD tracking trunk +Ubuntu, 32b + +Anyone is experiencing something similar? +I can try to debug this more, but don't really know where to start. + +silk ++ + + +
> Anyone is experiencing something similar? +> I can try to debug this more, but don't really know where to start. + +I experience similar behavior with the unit test interface. + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + +
I'll take a look. + +El dv 20 de 02 de 2009 a les 13:05 +0100, en/na Grzegorz Sobanski va +escriure: +> Hi. +> +> I am using a latest trunk. Few days ago Lluis you commited +> changes that allow to running unit tests in different modes - +> eg. debugging. I think this is (or would be ;) ) a great feature - +> I was missing it a lot. +> +> Unfortunatley it killed for me an ability to launch unittests. +> And some other side effects appeard at the same time, although they +> may not be related. I am curious if I'm the only one experiencing it ;) +> +> First - the side effects, not clearly reproducible, happening randomly: +> - make run - hangs sometimes, (sth like one in three runs) +> cd main && make run +> make[1]: Entering directory `/home/silk/devel/monodevelop/main' +> MONODEVELOP_LOCALE_PATH=./build/locale MONO_ADDINS_REGISTRY=./build/bin +> MOZILLA_FIVE_HOME= LD_LIBRARY_PATH=`echo "/opt/mono-2.2/lib::" | sed +> 's/^://g'`d exec -a "monodevelop" /opt/mono-2.2/bin/mono --debug +> ./build/bin/MonoDevelop.exe +> +> ** (./build/bin/MonoDevelop.exe:2908): WARNING **: Symbol file +> /usr/local/lib/mono/gac/Mono.Addins.Setup/0.4.0.0__0738eb9f132ed756/Mono.Addins.Setup.dll.mdb +> has incorrect version (expected 50.0, got 39) +> +> ** (./build/bin/MonoDevelop.exe:2908): WARNING **: Symbol file +> /usr/local/lib/mono/gac/Mono.Addins/0.4.0.0__0738eb9f132ed756/Mono.Addins.dll.mdb +> has incorrect version (expected 50.0, got 39) +> (it stops here, no gui is shown - few minutes waiting) +> ^C +> make[1]: *** [runmd] Interrupt +> make: *** [run] Interrupt +> +> - action of openning solution, building sometimes "do not finish" - +> statusbar shows "Opening solution xxx ...", options in menus are +> grayed out, etc. Switching tabs in editor makes the action finish. +> For example: I "Run" project. It compiles fines, but MD thinks the +> compilation process is still running. Switch tabs in editor, and MD +> accepts the compilation finished, and runs the exe. +> This one was happening very often on 18.02, now it is very very rare, +> but I see it sometimes. +> +> And the problem with unit test - reproduced with all configs deleted and +> clean build. +> Running or debugging unit tests does not work. I push "run test" on +> test, and get in console: +> +> # DebuggerServer started +> Module mdhost, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null +> loaded. +> >> OnInitialized +> << OnInitialized +> Module System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, +> PublicKeyToken=b77a5c561934e089 loaded. +> Module MonoDevelop.Core, Version=1.9.2.0, Culture=neutral, +> PublicKeyToken=null loaded. +> Module Mono.Posix, Version=2.0.0.0, Culture=neutral, +> PublicKeyToken=0738eb9f132ed756 loaded. +> +> System.Runtime.Serialization.SerializationException: serializationStream +> supports seeking, but its length is 0 +> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00094] in /home/silk/devel/mono-2.2/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/BinaryFormatter.cs:181 +> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream) [0x00000] in /home/silk/devel/mono-2.2/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/BinaryFormatter.cs:134 +> at MonoDevelopProcessHost.Main (System.String[] args) [0x000ca] in /home/silk/devel/monodevelop/main/src/tools/mdhost/src/mdhost.cs:74 +> +> And in test result pad: +> http://boktor.net/pliki/screenshots/unittest-ss-bug.png +> (unfortunatle there is no possibility to copy the text, hence +> the screenshot). +> +> +> Mono 2.2 +> MD tracking trunk +> Ubuntu, 32b +> +> Anyone is experiencing something similar? +> I can try to debug this more, but don't really know where to start. +> +> silk +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + +
Hi everyone, + +I've been fixing up the Mac MD in the last few days, trying to +identify what needs to be resolved to polish it up. + +I've set up a minimal bit of dock and menu integration (click on dock +to unminimise, fix the dock quit command, that sort of thing), fixed +the pkgconfig lookup (so all the Mono packages, including GTK# show +up), and tidied up the configure scripts. On the build side, I set up +the makefiles so that I can easily generate a MonoDevelop.app.zip file +on Linux, which can be downloaded and run directly. I also made sure +it's easy to build and run MD from SVN from within MD on the Mac (open +& hit "run"). + +Encouraging progress, maybe, but there's still much to be done. The MD +team isn't going to work on this for the upcoming 2.0 release, since +we're focusing on Linux stability. The 2.0 release for OS X will still +be a preview. After 2.0 we will be able to focus more on improving the +usability and stability of MonoDevelop on the Mac and Windows. + +A lot of this, especially key binding stuff, cannot easily be done by +those of us who are not Mac users, as we just don't know how typical +Mac keybindings are expected to *feel*. Help and advice from Mac +developers would be much appreciated. Even if you fix just one of +these things, that means together we get more of it sorted out, +faster. I'd be happy to advise anyone on how to get started. + +Here's my summary of the current state of things I'm aware of that +need to be fixed. + +Redraw issues: +* File chooser's file list + - GTK+ bug: http://bugzilla.gnome.org/show_bug.cgi?id=550939 +* Tree view's selection and expander arrow + - GTK+ bug +* MD text editor's text + - This may be fixable in MD itself, or might be a GTK+ bug + +Key binding issues +* Good default Mac keybinding scheme +* Ability to bind Command + - It seems to show up as Alt right now +* Reliable capture of keys for keybindings + - Can't capture F keys - OS is grabbing them? + - Widget mnemonics seem to override key capture - GTK+ issue? +* Display keybindings using Mac-style symbols + - In key binding manager and menus +* Key bindings for GTK+ built-in widgets + - GTK+ bug & patch: http://bugzilla.gnome.org/show_bug.cgi?id=530351 +* Review all places that MD code uses key modifiers, e.g. completion +window, expanding text selection, etc. and make sure they can be made +Mac-like + +Global menu integration +* IGE menu integration library is very limited, so currently disabled + - Can't display menu items with embedded labels, which we use for +displaying our accelerators, since we don't use GTK accelerator +infrastructure + - Doesn't display radio or check items + - Doesn't display icons + - Doesn't update sensitivity + - Reported to be very broken with menus that are dynamically updated +* Proposed solution: Write a CarbonMenu# binding (P/Invoke, should be +pretty easy) and use it to turn a CommandEntrySet into a Carbon menu +directly + +Misc +* Right-click emulation with Control-click + - GTK+ bug & patch: http://bugzilla.gnome.org/show_bug.cgi?id=346609 +* Modal dialogs don't stay on top +* Text position shifts while it's selected, even with Monospaced fonts. + - Mostly a MD kerning bug, but monospace issues may be +http://bugzilla.gnome.org/show_bug.cgi?id=569146 +* Dock integration + - Some basics done, but would be useful to be able to add commands to the menu +* File handlers integration + - Ffetch list of handlers for given mime types, for "open with" context menu +* Recent files list integration + - Currently use the FreeDesktop ~/.recently-used file, which still +works for MD + +Drag-n-drop +* Buggy, with a lot of unimplemented features needed by the GTK# designer +* http://bugzilla.gnome.org/show_bug.cgi?id=559904 +* http://bugzilla.gnome.org/show_bug.cgi?id=501588 +* Shift-drag: http://bugzilla.gnome.org/show_bug.cgi?id=569145 + +Misc. disabled addins +* Gettext addin - not sure why +* SVN addin - needs testing, svn binding reportedly very unstable on Mac +* GtkCore designer - missing drag-n-drop in GTK+, no dllmaps, probably more +* Database addin - should work now it no longer uses GtkSourceView, but untested +* Boo binding - boo console uses GtkSourceView. Port or disable this feature. +* Moonlight/Silverlight - developer libraries not present (also a +problem on Linux) +* Python, Vala, Java - totally untested + +Open GTK+ Quartz bugs can be seen here: +http://bugzilla.gnome.org/buglist.cgi?query=component:quartz+product:gtk%2B+ + +It would be useful to isolate the GTK/GDK issues and file bugs against +GTK. We can fairly easily apply patches to the GTK+ that Mono ships, +making things better for all GTK# apps. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Hi, + +When i try to build the latest mono develop from trunk i get an +error You need to install update-mime-database. + +I read in the archives that i should provide --disable-update-mimedb +but this parameter seems to get rejected from ./configure as an +illegal option. + +What should i be passing to the configure to make mono develop compile? + +Joachim Ante ++ + + + +
> Hi, +> +> When i try to build the latest mono develop from trunk i get an +> error You need to install update-mime-database. +> +> I read in the archives that i should provide --disable-update- +> mimedb but this parameter seems to get rejected from ./configure as +> an illegal option. +> +> What should i be passing to the configure to make mono develop +> compile? +> +> Joachim Ante + + +using ./configure --profile=mac works better :) + +But now i am getting this: + +./configure: line 2688: syntax error near unexpected token +`UNMANAGED_DEPENDENCIES_MONO,mono' +./configure: line 2688: `PKG_CHECK_MODULES +(UNMANAGED_DEPENDENCIES_MONO,mono >= $MONO_REQUIRED_VERSION, +has_mono=true, has_mono=false)' + +I have mono 2.4 preview 3 installed. + +Joachim Ante +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090221/59f49398/attachment.html ++ + + + +
On Sat, Feb 21, 2009 at 2:18 PM, Joachim Ante <joe at unity3d.com> wrote: +> Hi, +> When i try to build the latest mono develop from trunk i get an error You +> need to install update-mime-database. +> I read in the archives that i should provide --disable-update-mimedb but +> this parameter seems to get rejected from ./configure as an illegal option. +> What should i be passing to the configure to make mono develop compile? +> Joachim Ante +> +> using ./configure --profile=mac works better :) +> But now i am getting this: +> ./configure: line 2688: syntax error near unexpected token +> `UNMANAGED_DEPENDENCIES_MONO,mono' +> ./configure: line 2688: `PKG_CHECK_MODULES(UNMANAGED_DEPENDENCIES_MONO,mono +>>= $MONO_REQUIRED_VERSION, has_mono=true, has_mono=false)' +> I have mono 2.4 preview 3 installed. + +Set PKG_CONFIG_PATH to the Mono framework's pkgconfig directory. IIRC +it's something like +export PKG_CONFIG_PATH=/Libraries/Frameworks/Mono.framework/Version/Current/lib/pkgconfig + +I've never actually built it on Mac using make. Instead, I loaded the +solution using MonoDevelop.app, switched the active configuration to +"DebugMac", and it built and run from within MonoDevelop without any +problems or use of the command line. + +You'd probably need a very recent MonoDveelop.app to do this, though. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
+Hi all:
+ Attached is a patch for MonoDevelop.Database addin (MySql).
+This patch fix some bugs and incorrect behaviors (more info on the ChangeLog):
+* BugFix when showing the list of procedure and one of the procedure is a Function ("SHOW CREATE PROCEDURE myFunc" is invalid)
+* BugFix ArgumentNullException when editing a procedure.
+* "Alter Procedure" Implementation for MySql Provider. (Based on the current)
+
+Could someone review it and commit it?
+
+Lucian0
+
+_________________________________________________________________
+Get 5 GB of storage with Windows Live Hotmail.
+http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090222/9fdae5cb/attachment-0001.html
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: MonoDevelop.Database.patch
+Type: text/x-patch
+Size: 5366 bytes
+Desc: not available
+Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090222/9fdae5cb/attachment-0001.bin
+
+
+
+
+
+
+ Dear Translators and Committers, + +MonoDevelop is now string-frozen for release. No changes should be +made to the translatable strings without careful review and extremely +good reasons. This freeze applies to trunk until 2.0 is branched, and +will apply to the 2.0 branch indefinitely. + +This means its time to start translating MonoDevelop for the 2.0 release! + +Procedure is the same as before, but I'll run through it for +newcomers. before beginning a translation, please reply to the list +with your intentions, so we don't have duplicated efforts. + +I've committed up-to-date version of all the .po files to MonoDevelop +main in SVN. Either use an up-to-date SVN checkout, or grab the +appropriate .po file from +http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/po. +* To edit the .po file, you can open the MonoDevelop solution in +MonoDevelop, find the "po" project, and edit the translation using our +editor. Alternatively you can use any po editor or text editor to edit +the po file. +* To add a new translation from within MonoDevelop, use the context +menu on the "po" project. If you are doing this manually, make a copy +of messages.po, rename it to match your language code, and add it to +the lists in the Makefile.am and the po.mdproj file. + * To test the translation, build MonoDevelop (using either +MonoDevelop itself or "make"), ensure that you have set the +appropriate LANGUAGE/LANG environment variable, and run MonoDevelop +using the Run button or "make run". + +Several of the addins in extras/ have been set up with po files. +Procedure for these is similar, though I have not finished updating +them yet. + +When you are done, please commit your translation if you have SVN +commit access, or email your translation directly to me, or attach it +to a bug report at http://bugzilla.novell.com. + +Thank you for you contributions! + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + +
+Hi Again: +Sorry to reply to myself: +I submit a bug report with the explanation and the patch: #479343. +If someone could review it and/or commit it now it will be great :) + +Bye. +Lucian0 + +From: lnc19 at hotmail.com +To: monodevelop-devel-list at lists.ximian.com +Date: Sun, 22 Feb 2009 22:08:59 +0000 +Subject: [Monodevelop-devel] Database Addin patch - MySql Provider + + + + + + + + +Hi all: + Attached is a patch for MonoDevelop.Database addin (MySql). +This patch fix some bugs and incorrect behaviors (more info on the ChangeLog): +* BugFix when showing the list of procedure and one of the procedure is a Function ("SHOW CREATE PROCEDURE myFunc" is invalid) +* BugFix ArgumentNullException when editing a procedure. +* "Alter Procedure" Implementation for MySql Provider. (Based on the current) + +Could someone review it and commit it? + +Lucian0 + +Get 5 GB of storage with Windows Live Hotmail. Sign up today. +_________________________________________________________________ +Windows Live Hotmail now works up to 70% faster. +http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090225/a8f0e4dc/attachment.html ++ + + +
Hi + +I need some opinions from developers. I got a bug report (cut&paste:) + +------------------------------------------------------------------------ +Description of Problem: +In some cases when I am writing a line of code, intellisense is blocking the +left and right arrow, so that I can't properly navigate my line of code, even +though I have not even actively engaged intellisense by selecting any of the +options it present. + +Steps to reproduce the problem: +1. Write the line: if () +2. Place the cursor between the parenthesis +3. Write (between the paranthesis): "" == null +4. The cursor should now be after "null" and before ")". +5. Press the right arrow key to get out of the parenthesis - but nothing +happens. (Intellisense popped up when writing "null" and is now blocking the +right arrow key.) + + +Actual Results: +Left and right arrow keys are blocked (do nothing) in above case. + +Expected Results: +Left and right arrow keys always move the cursor left and right, respectively. + +How often does this happen? +Always + +Additional Information: +------------------------------------------------------------------------ + +One suggested solution: +Pass though left and right arrow keys to the editor when the selected +item has no overloads. + +My opinion is that passing through when there aren't overloads and not +when they are are not a good solution from user point of view. + +I'm unsure how to solve this. A solution MUST be consistent. + +I see two options: +A) Letting the user interface how it is now - changing nothing. (easy +solution) +B) Always pass left/right to the editor - not navigating through +overloads. + +When a method has overloads we could show in the tooltip: +--------- +MethodWithOverloads () (+18 Overloads) +Description +--------- + +I would favor the option A) because I find it sometimes useful to view +each overload and I don't have a problem with the behavior. But maybe I +just get to used to the monodevelop way of handling things. + +Option B) is how Visual Studio handles the problem. Theoretically we +could add an option for switching between A) and B). But I don't know if +this is worth an option (I think not). + +Before I destroy the user experience I want some opinions about the +issue. + +What do you think ? + +Regards +Mike + + ++ + + + + +
> A) Letting the user interface how it is now - changing nothing. (easy +> solution) +> B) Always pass left/right to the editor - not navigating through +> overloads. +> [...] +> Before I destroy the user experience I want some opinions about the +> issue. + +What about changing the overload navigation keys? +PgUp/PgDn? Home/End? + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + + + +
Hi, + +MD 2.0 has been branched. We plan to release a Beta 2 next week out of +this branch and use the same branch for the final release. Important +fixes can be backported to the branch, although we have to be careful +about this since we have to keep the branch stable. + +Thanks, +Lluis. + ++ + + + +
On Sat, Feb 21, 2009 at 3:21 AM, Michael Hutchinson +<m.j.hutchinson at gmail.com> wrote: +> Hi everyone, +> +> I've been fixing up the Mac MD in the last few days, trying to +> identify what needs to be resolved to polish it up. + +I can't help you much with the key bindings. I find my mac to be +infuriatingly inconsistent when it comes to key bindings across +applications, so I don't know what the "correct" bindings are really +supposed to be anyway. Windows is far more consistent. + +That being said, your list looks very good. There are a few things +I've noticed that bother me: + +* Window drawing/refresh issues (as you mentioned, but they are very +bad right now) + +* In tree views and menus, your current item doesn't always highlight +(probably related to the window refresh issue) + +* Dialog boxes open in the upper left corner of the screen. This is +annoying because I have my dock on the left and the dialogs always +appear under the dock. + +* I had to delete my ~/.config/MonoDevelop folder to get this build to +load. Before I did that, I was getting the following error on +startup: LSOpenFromURLSpec() failed with error -10810 + +I only downloaded the newest build last night. I haven't looked at +MonoDevelop on mac in months so I'll post more as I re-familiarize +myself with it and use it. + +Bryan ++ + +
I'm updating French Translation... should be ready pretty soon + +Michael Hutchinson a écrit : +> Dear Translators and Committers, +> +> MonoDevelop is now string-frozen for release. No changes should be +> made to the translatable strings without careful review and extremely +> good reasons. This freeze applies to trunk until 2.0 is branched, and +> will apply to the 2.0 branch indefinitely. +> +> This means its time to start translating MonoDevelop for the 2.0 release! +> +> Procedure is the same as before, but I'll run through it for +> newcomers. before beginning a translation, please reply to the list +> with your intentions, so we don't have duplicated efforts. +> +> I've committed up-to-date version of all the .po files to MonoDevelop +> main in SVN. Either use an up-to-date SVN checkout, or grab the +> appropriate .po file from +> http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/po. +> * To edit the .po file, you can open the MonoDevelop solution in +> MonoDevelop, find the "po" project, and edit the translation using our +> editor. Alternatively you can use any po editor or text editor to edit +> the po file. +> * To add a new translation from within MonoDevelop, use the context +> menu on the "po" project. If you are doing this manually, make a copy +> of messages.po, rename it to match your language code, and add it to +> the lists in the Makefile.am and the po.mdproj file. +> * To test the translation, build MonoDevelop (using either +> MonoDevelop itself or "make"), ensure that you have set the +> appropriate LANGUAGE/LANG environment variable, and run MonoDevelop +> using the Run button or "make run". +> +> Several of the addins in extras/ have been set up with po files. +> Procedure for these is similar, though I have not finished updating +> them yet. +> +> When you are done, please commit your translation if you have SVN +> commit access, or email your translation directly to me, or attach it +> to a bug report at http://bugzilla.novell.com. +> +> Thank you for you contributions! +> +> + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: vdaron.vcf +Type: text/x-vcard +Size: 168 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090225/98fe5cfe/attachment-0001.vcf ++ + +
Starting: Fri Feb 6 04:29:00 EST 2009
+ Ending: Fri Feb 27 06:15:08 EST 2009
+ Messages: 22
+
+ Last message date:
+ Fri Feb 27 06:15:08 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Fri Feb 6 04:29:00 EST 2009
+ Ending: Fri Feb 27 06:15:08 EST 2009
+ Messages: 22
+
+ Last message date:
+ Fri Feb 27 06:15:08 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Fri Feb 6 04:29:00 EST 2009
+ Ending: Fri Feb 27 06:15:08 EST 2009
+ Messages: 22
+
+ Last message date:
+ Fri Feb 27 06:15:08 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Fri Feb 6 04:29:00 EST 2009
+ Ending: Fri Feb 27 06:15:08 EST 2009
+ Messages: 22
+
+ Last message date:
+ Fri Feb 27 06:15:08 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Fri Feb 6 04:29:00 EST 2009
+ Ending: Fri Feb 27 06:15:08 EST 2009
+ Messages: 22
+
+ Last message date:
+ Fri Feb 27 06:15:08 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Hey guys, + +I converted some of the MD .mdp's to be .csproj's so I can successfully +build MD in Visual Studio. I talked to Hutch about what to do with +them, and we decided that it would suck to maintain Makefile/mdp/csproj. + +He said at some point, MD probably needs to switch to using .csproj's +instead of .mdp's, and that Banshee had already done this migration. + +Is this migration something that is planned in the near-term, or at all? + If not, could we consider it? + +Thanks! +Jonathan ++ + + +
El lun, 05-01-2009 a las 13:23 -0600, Jonathan Pobst escribió: +> Hey guys, +> +> I converted some of the MD .mdp's to be .csproj's so I can successfully +> build MD in Visual Studio. I talked to Hutch about what to do with +> them, and we decided that it would suck to maintain Makefile/mdp/csproj. +> +> He said at some point, MD probably needs to switch to using .csproj's +> instead of .mdp's, and that Banshee had already done this migration. +> +> Is this migration something that is planned in the near-term, or at all? +> If not, could we consider it? + +Yes, it makes sense to do the switch. Maybe your csproj's are a good +starting point? + +Lluis. + + ++ + + + +
I recently implemented "Go to definition" and "Find references" +commands as top-level items in the text editor context menu. This +allows them to be bound to keyboard shortcuts, F12 and Shift-F12. +However, I haven't committed them yet as I have a few concerns about +how it relates to the existing refactoring/navigation context menus. + +Currently, MD dynamically generates submenus for the symbol under the +cursor, and its enclosing/parent items, i.e. the enclosing member, the +enclosing class, and (if it's a variable) the type. Each of these +menus allows refactoring and navigation operations on the associated +item. + +There are a few problems with this. Since the submenus are dynamically +generated, user extensions cannot add new refactoring operations to +the menu, nor can extensions override the handling of these commands. +Also, the commands cannot be keybound -- and even if they could, it +would not be obvious which commands the shortcuts would apply to, +since the menus contain identical commands. + +So, my question is: are all of the submenus really necessary? How +useful is it to be able to implement members on a class from the +context menu on a field within it? What I'd like to do is replace all +these menus with a simple refactor/navigate menu that would apply only +to the item under the cursor, as this would be keybindable and +extensible. However, would it be noticeably less usable or functional? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Having used Resharper on a previous job, I like that they have it all on the +first-level context menu, but vary the list according to where you are in +the source structure. Taking your example, if you are in a field you can +rename it but not the class it is contained, but you can do some actions on +the class like moving it to another namespace or source-file, I think the +key word is to have commands that are "unequivocally" associated with the +current context OR (exclusive) its containers. If I want to rename a class, +I should position the cursor on its name or, maybe, in first-level +whitespace in it: a blank line inside the class definition block, but not +inside a member's definition block. + +Just my 2 cents, + +On Thu, Jan 8, 2009 at 5:34 AM, Michael Hutchinson <m.j.hutchinson at gmail.com +> wrote: + +> I recently implemented "Go to definition" and "Find references" +> commands as top-level items in the text editor context menu. This +> allows them to be bound to keyboard shortcuts, F12 and Shift-F12. +> However, I haven't committed them yet as I have a few concerns about +> how it relates to the existing refactoring/navigation context menus. +> +> Currently, MD dynamically generates submenus for the symbol under the +> cursor, and its enclosing/parent items, i.e. the enclosing member, the +> enclosing class, and (if it's a variable) the type. Each of these +> menus allows refactoring and navigation operations on the associated +> item. +> +> There are a few problems with this. Since the submenus are dynamically +> generated, user extensions cannot add new refactoring operations to +> the menu, nor can extensions override the handling of these commands. +> Also, the commands cannot be keybound -- and even if they could, it +> would not be obvious which commands the shortcuts would apply to, +> since the menus contain identical commands. +> +> So, my question is: are all of the submenus really necessary? How +> useful is it to be able to implement members on a class from the +> context menu on a field within it? What I'd like to do is replace all +> these menus with a simple refactor/navigate menu that would apply only +> to the item under the cursor, as this would be keybindable and +> extensible. However, would it be noticeably less usable or functional? +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Rafael "Monoman" Teixeira +--------------------------------------- +"I myself am made entirely of flaws, stitched together with good +intentions." +Augusten Burroughs +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090108/391f85a5/attachment.html ++ + + + +
El jue, 08-01-2009 a las 02:34 -0500, Michael Hutchinson escribió: +> I recently implemented "Go to definition" and "Find references" +> commands as top-level items in the text editor context menu. This +> allows them to be bound to keyboard shortcuts, F12 and Shift-F12. +> However, I haven't committed them yet as I have a few concerns about +> how it relates to the existing refactoring/navigation context menus. +> +> Currently, MD dynamically generates submenus for the symbol under the +> cursor, and its enclosing/parent items, i.e. the enclosing member, the +> enclosing class, and (if it's a variable) the type. Each of these +> menus allows refactoring and navigation operations on the associated +> item. +> +> There are a few problems with this. Since the submenus are dynamically +> generated, user extensions cannot add new refactoring operations to +> the menu, nor can extensions override the handling of these commands. +> Also, the commands cannot be keybound -- and even if they could, it +> would not be obvious which commands the shortcuts would apply to, +> since the menus contain identical commands. +> +> So, my question is: are all of the submenus really necessary? How +> useful is it to be able to implement members on a class from the +> context menu on a field within it? What I'd like to do is replace all +> these menus with a simple refactor/navigate menu that would apply only +> to the item under the cursor, as this would be keybindable and +> extensible. However, would it be noticeably less usable or functional? +> + +I think we should check how those refactoring commands are presented in +other IDEs and tools. In any case, I don't think the submenus add much +value. The editor context menu could have a "Go to declaration" command +at the top, maybe a "Go to declaring type" (for type members), and a +"Refactoring" menu with all other refactoring commands. + +Lluis. + + ++ + + + +
On Thu, Jan 8, 2009 at 12:39 PM, Lluis Sanchez Gual <lluis at novell.com> wrote: +> I think we should check how those refactoring commands are presented in +> other IDEs and tools. In any case, I don't think the submenus add much +> value. The editor context menu could have a "Go to declaration" command +> at the top, maybe a "Go to declaring type" (for type members), and a +> "Refactoring" menu with all other refactoring commands. + +Yes, I'll take a look at how some other IDEs present these commands +and post a summary later. + +My other concern with the current approach we have is that it's +possible to do things that don't make much sense in the current +"scope", e.g. from the context menu on a parameter, you can rename the +class of the type of the parameter, even though it's in a different +file or project. IMO refactoring operations should only affect the +current file and files that depend on it, else the scope of the +changes becomes confusing. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
On Thu, Jan 8, 2009 at 2:13 PM, Michael Hutchinson +<m.j.hutchinson at gmail.com> wrote: +> On Thu, Jan 8, 2009 at 12:39 PM, Lluis Sanchez Gual <lluis at novell.com> wrote: +>> I think we should check how those refactoring commands are presented in +>> other IDEs and tools. In any case, I don't think the submenus add much +>> value. The editor context menu could have a "Go to declaration" command +>> at the top, maybe a "Go to declaring type" (for type members), and a +>> "Refactoring" menu with all other refactoring commands. +> +> Yes, I'll take a look at how some other IDEs present these commands +> and post a summary later. + +VS Express +========= +Pretty simple, context menu is as follows: + +Refactor > + Rename... + Extract Method... +Organise Usings > (submenu operating on the file's usings) +--- +Insert Snippet... +Surround With... +-- +Go to Definition +Find All References + +None of these commands are contextualised; running them when not over +a valid symbol causes an error. Some commands show up via contexual +smart tags. The Refactor menu is also a main menu, and the other +commands can be found in Edit > IntelliSense + +Eclipse +===== +Ctrl-1 brings up a list of "Quick assists" +HUGE context menu with submenus "Refactor" and "Source" each +containing a ton of refactoring commands. They do not seem to be +contextually enabled, and hence many can error when you try to run +them. These commands (and more) are in a "Refactor" main menu, which +is similarly non-contextualised. +Very few navigation commands are in the context menu (only "open +declaration"); they seem mostly to be in the "Navigation" main menu, +and again are not contextually enabled. Instead they have context menu +commands for jumping to the class pad, breadcrumb bar, etc. And, once +again, the commands are not contextualised; even "open declaration" +can error out (with a message in the status bar). + +Netbeans +======= +Context menu has "Navigate" and "Refactor" submenus, +non-contextualised. They also have main menus with the same names and +commands, but with additional commands. "Find usages", "Call +Hierarchy", "Insert Code" and "Fix Imports" are the only top-level +navigation/refactoring commands in the context menu. + +Visual Assist X +=========== +AFAICT from docs, it adds a "refactor" menu invoked by a special key, +which shown contextual refactoring commands and "find references". Go +to definition is invoked by another shortcut. It appears they don't +want to hook into the IDE's usual context menu. + +Refactor! Pro / CodeRush +=================== +AFAICT from docs, Refactor! uses smart tags and a contextual +"refactor" menu with a keyboard shortcut. CodeRush adds a "jump to" +menu to the VS context menu. + +ReSharper +======== +Adds "Refactor" and "navigation" contextual menus accessible via +keyboard shortcuts. + +Later I'll post thoughts on this and how I think we should proceed. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Here's the .csproj's I used to build MD in VS2k8. + +These may or may not be useful. :) + +Jonathan + + +Lluis Sanchez Gual wrote: +> El lun, 05-01-2009 a las 13:23 -0600, Jonathan Pobst escribió: +>> Hey guys, +>> +>> I converted some of the MD .mdp's to be .csproj's so I can successfully +>> build MD in Visual Studio. I talked to Hutch about what to do with +>> them, and we decided that it would suck to maintain Makefile/mdp/csproj. +>> +>> He said at some point, MD probably needs to switch to using .csproj's +>> instead of .mdp's, and that Banshee had already done this migration. +>> +>> Is this migration something that is planned in the near-term, or at all? +>> If not, could we consider it? +> +> Yes, it makes sense to do the switch. Maybe your csproj's are a good +> starting point? +> +> Lluis. +> +> +> +> + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: mdsln.zip +Type: application/x-zip-compressed +Size: 36955 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090121/398d4ba5/attachment-0001.bin ++ + +
+Hi, + +Could someone give me statement about xbuild regarding the compatibility +with msbuild? I'd like use xbuild to build Silverlight 2.0 project. I'm +looking for all information about xbuild. But I found very few. + +Looking for your reply + +Best regards +Yves YANG +-- +View this message in context: http://n2.nabble.com/compability-of-xbuild-with-msbuild-tp2221558p2221558.html +Sent from the Mono - MonoDevelop - Dev mailing list archive at Nabble.com. + ++ + +
Starting: Mon Jan 5 14:23:42 EST 2009
+ Ending: Mon Jan 26 19:13:35 EST 2009
+ Messages: 9
+
+ Last message date:
+ Mon Jan 26 19:13:35 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Mon Jan 5 14:23:42 EST 2009
+ Ending: Mon Jan 26 19:13:35 EST 2009
+ Messages: 9
+
+ Last message date:
+ Mon Jan 26 19:13:35 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Mon Jan 5 14:23:42 EST 2009
+ Ending: Mon Jan 26 19:13:35 EST 2009
+ Messages: 9
+
+ Last message date:
+ Mon Jan 26 19:13:35 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Mon Jan 5 14:23:42 EST 2009
+ Ending: Mon Jan 26 19:13:35 EST 2009
+ Messages: 9
+
+ Last message date:
+ Mon Jan 26 19:13:35 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
Starting: Mon Jan 5 14:23:42 EST 2009
+ Ending: Mon Jan 26 19:13:35 EST 2009
+ Messages: 9
+
+ Last message date:
+ Mon Jan 26 19:13:35 EST 2009
+ Archived on: Wed Apr 29 10:39:01 EDT 2009
+
+
+
---
+ .../Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs | 1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+diff --git a/main/src/core/Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs b/main/src/core/Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs
+index cd4bea6..b5eeda0 100644
+--- a/main/src/core/Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs
++++ b/main/src/core/Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs
+@@ -432,6 +432,7 @@ namespace Mono.TextEditor.Vi
+ if (action != null) {
+ RunActions (action, ClipboardActions.Cut);
+ Reset ("-- INSERT --");
++ Caret.Mode = CaretMode.Insert;
+ state = State.Insert;
+ } else {
+ Reset ("Unrecognised motion");
+--
+1.6.3.3.467.g98a79
+
+
+
+
+
+ > .../Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs | 1 + +> 1 files changed, 1 insertions(+), 0 deletions(-) + +Looks ok to me. ++ + + +
On Fri, Jul 10, 2009 at 9:49 AM, Levi +Bard<taktaktaktaktaktaktaktaktaktak at gmail.com> wrote: +>> .../Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs | 1 + +>> 1 files changed, 1 insertions(+), 0 deletions(-) +> +> Looks ok to me. + +Looks good, please commit. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Some of the code formatting has made writing python impossible. +Whenever I try to add a python doc block (three quotations """) it +adds a fourth and sometimes fifth quote. When backspacing it removes +multiple as well so I can never get it just right. Pasting also +automatically formats. + +Any way we can have this disabled for certain mime-types? + +-- Christian ++ + + +
On Mon, Jul 27, 2009 at 5:26 AM, Christian +Hergert<christian.hergert at gmail.com> wrote: +> Some of the code formatting has made writing python impossible. +> Whenever I try to add a python doc block (three quotations """) it +> adds a fourth and sometimes fifth quote. When backspacing it removes +> multiple as well so I can never get it just right. Pasting also +> automatically formats. +> +> Any way we can have this disabled for certain mime-types? + +IMO it sounds like this should be opt-in for mimetypes, not opt-out. + +You should probably file a bug against the text editor. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
>> Any way we can have this disabled for certain mime-types? +> +> IMO it sounds like this should be opt-in for mimetypes, not opt-out. + +Maybe these options (insert matching, OTF formatting) should be pushed +into the project-level policies? ++ + + +
On Mon, Jul 27, 2009 at 9:33 AM, Levi +Bard<taktaktaktaktaktaktaktaktaktak at gmail.com> wrote: +>>> Any way we can have this disabled for certain mime-types? +>> +>> IMO it sounds like this should be opt-in for mimetypes, not opt-out. +> +> Maybe these options (insert matching, OTF formatting) should be pushed +> into the project-level policies? + +Ouch, no. Insert matching in particular fundamentally changes the way +you use the text editor - it's definitely a personal preference. I'd +argue that this is the case for OTF formatting too. + +I've haven't yet worked out a concise definition for how I intended +policies to be used, but broadly speaking, they should be used to +control *what* the output of MD is, not *how* it is produced. People +have their own preferences for how they like to work, and as long as +these do not affect the code that they save/commit, MD shouldn't +interfere. I can explain all the existing policies in these terms. + +For example, for enforcing coding style, I'd be more in favour of +auto-format on save or commit. + +Feel free to make the case against me though :) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
>> Maybe these options (insert matching, OTF formatting) should be pushed +>> into the project-level policies? +> +> Ouch, no. Insert matching in particular fundamentally changes the way +> you use the text editor - it's definitely a personal preference. I'd +> argue that this is the case for OTF formatting too. + +I was thinking of the user-specific, project-level policies, similar +to author information. ++ + + +
On Mon, Jul 27, 2009 at 10:45 AM, Levi +Bard<taktaktaktaktaktaktaktaktaktak at gmail.com> wrote: +>>> Maybe these options (insert matching, OTF formatting) should be pushed +>>> into the project-level policies? +>> +>> Ouch, no. Insert matching in particular fundamentally changes the way +>> you use the text editor - it's definitely a personal preference. I'd +>> argue that this is the case for OTF formatting too. +> +> I was thinking of the user-specific, project-level policies, similar +> to author information. + +Yes, that would make sense. However, we don't have any +per-user-per-project policies infrastructure yet, and IMO it would be +extremely hard to make the GUI for such a thing usable. + +Author info is completely special-cased right now. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
> Author info is completely special-cased right now. + +Ah, I'd thought it was leveraging a similar mechanism to the other policies. ++ + +
Starting: Fri Jul 10 05:26:49 EDT 2009
+ Ending: Mon Jul 27 11:07:27 EDT 2009
+ Messages: 10
+
+ Last message date:
+ Mon Jul 27 11:07:27 EDT 2009
+ Archived on: Mon Jul 27 11:07:33 EDT 2009
+
+
+
Starting: Fri Jul 10 05:26:49 EDT 2009
+ Ending: Mon Jul 27 11:07:27 EDT 2009
+ Messages: 10
+
+ Last message date:
+ Mon Jul 27 11:07:27 EDT 2009
+ Archived on: Mon Jul 27 11:07:33 EDT 2009
+
+
+
Starting: Fri Jul 10 05:26:49 EDT 2009
+ Ending: Mon Jul 27 11:07:27 EDT 2009
+ Messages: 10
+
+ Last message date:
+ Mon Jul 27 11:07:27 EDT 2009
+ Archived on: Mon Jul 27 11:07:33 EDT 2009
+
+
+
Starting: Fri Jul 10 05:26:49 EDT 2009
+ Ending: Mon Jul 27 11:07:27 EDT 2009
+ Messages: 10
+
+ Last message date:
+ Mon Jul 27 11:07:27 EDT 2009
+ Archived on: Mon Jul 27 11:07:33 EDT 2009
+
+
+
Starting: Fri Jul 10 05:26:49 EDT 2009
+ Ending: Mon Jul 27 11:07:27 EDT 2009
+ Messages: 10
+
+ Last message date:
+ Mon Jul 27 11:07:27 EDT 2009
+ Archived on: Mon Jul 27 11:07:33 EDT 2009
+
+
+
Hi + +> What about changing the overload navigation keys? +> PgUp/PgDn? Home/End? + +Then you're moving the left/right "problem" to other keys. + +Regards +Mike + ++ + + +
El dj 26 de 02 de 2009 a les 07:18 +0100, en/na Mike Krüger va escriure: +> Hi +> +> I need some opinions from developers. I got a bug report (cut&paste:) +> +> ------------------------------------------------------------------------ +> Description of Problem: +> In some cases when I am writing a line of code, intellisense is blocking the +> left and right arrow, so that I can't properly navigate my line of code, even +> though I have not even actively engaged intellisense by selecting any of the +> options it present. +> +> Steps to reproduce the problem: +> 1. Write the line: if () +> 2. Place the cursor between the parenthesis +> 3. Write (between the paranthesis): "" == null +> 4. The cursor should now be after "null" and before ")". +> 5. Press the right arrow key to get out of the parenthesis - but nothing +> happens. (Intellisense popped up when writing "null" and is now blocking the +> right arrow key.) +> +> +> Actual Results: +> Left and right arrow keys are blocked (do nothing) in above case. +> +> Expected Results: +> Left and right arrow keys always move the cursor left and right, respectively. +> +> How often does this happen? +> Always +> +> Additional Information: +> ------------------------------------------------------------------------ +> +> One suggested solution: +> Pass though left and right arrow keys to the editor when the selected +> item has no overloads. +> +> My opinion is that passing through when there aren't overloads and not +> when they are are not a good solution from user point of view. +> +> I'm unsure how to solve this. A solution MUST be consistent. +> +> I see two options: +> A) Letting the user interface how it is now - changing nothing. (easy +> solution) +> B) Always pass left/right to the editor - not navigating through +> overloads. +> +> When a method has overloads we could show in the tooltip: +> --------- +> MethodWithOverloads () (+18 Overloads) +> Description +> --------- +> +> I would favor the option A) because I find it sometimes useful to view +> each overload and I don't have a problem with the behavior. But maybe I +> just get to used to the monodevelop way of handling things. +> +> Option B) is how Visual Studio handles the problem. Theoretically we +> could add an option for switching between A) and B). But I don't know if +> this is worth an option (I think not). +> +> Before I destroy the user experience I want some opinions about the +> issue. +> +> What do you think ? + +I like the option of passing through when there are no overloads. I +don't think consistency is a problem here. + +> +> Regards +> Mike +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + +
Lluis Sanchez Gual wrote:
+> El dj 26 de 02 de 2009 a les 07:18 +0100, en/na Mike Krüger va escriure:
+>> Hi
+>>
+>> I need some opinions from developers. I got a bug report (cut&paste:)
+>>
+>> ------------------------------------------------------------------------
+>> Description of Problem:
+>> In some cases when I am writing a line of code, intellisense is blocking the
+>> left and right arrow, so that I can't properly navigate my line of code, even
+>> though I have not even actively engaged intellisense by selecting any of the
+>> options it present.
+>>
+>> Steps to reproduce the problem:
+>> 1. Write the line: if ()
+>> 2. Place the cursor between the parenthesis
+>> 3. Write (between the paranthesis): "" == null
+>> 4. The cursor should now be after "null" and before ")".
+>> 5. Press the right arrow key to get out of the parenthesis - but nothing
+>> happens. (Intellisense popped up when writing "null" and is now blocking the
+>> right arrow key.)
+>>
+>>
+>> Actual Results:
+>> Left and right arrow keys are blocked (do nothing) in above case.
+>>
+>> Expected Results:
+>> Left and right arrow keys always move the cursor left and right, respectively.
+>>
+>> How often does this happen?
+>> Always
+>>
+>> Additional Information:
+>> ------------------------------------------------------------------------
+>>
+>> One suggested solution:
+>> Pass though left and right arrow keys to the editor when the selected
+>> item has no overloads.
+>>
+>> My opinion is that passing through when there aren't overloads and not
+>> when they are are not a good solution from user point of view.
+>>
+>> I'm unsure how to solve this. A solution MUST be consistent.
+>>
+>> I see two options:
+>> A) Letting the user interface how it is now - changing nothing. (easy
+>> solution)
+>> B) Always pass left/right to the editor - not navigating through
+>> overloads.
+>>
+>> When a method has overloads we could show in the tooltip:
+>> ---------
+>> MethodWithOverloads () (+18 Overloads)
+>> Description
+>> ---------
+>>
+>> I would favor the option A) because I find it sometimes useful to view
+>> each overload and I don't have a problem with the behavior. But maybe I
+>> just get to used to the monodevelop way of handling things.
+>>
+>> Option B) is how Visual Studio handles the problem. Theoretically we
+>> could add an option for switching between A) and B). But I don't know if
+>> this is worth an option (I think not).
+>>
+>> Before I destroy the user experience I want some opinions about the
+>> issue.
+>>
+>> What do you think ?
+>
+> I like the option of passing through when there are no overloads. I
+> don't think consistency is a problem here.
+
+FYI: I've tested this on VS.NET 2008, and the arrows are always
+*respected*. Furthermore, the overloads are never present in this
+context, but after the user has written the "(" to indicate that a new
+function call is being done.
+
+
+--
+
+Andrés G. Aragoneses
+Software Engineer
+aaragoneses at novell.com
+
+Novell, Inc.
+http://www.novell.com/
+Software for the open enterprise
+
+
+
+
+
+ VS is able to respect the arrows because it doesn't +allow browsing overloads in this way. I find the current feature in MD +feature very useful - IMO we shouldn't copy VS if we can do better. + +On Mar 5, 2009 8:51 PM, Andrés G. Aragoneses <aaragoneses at novell.com> wrote: + +Lluis Sanchez Gual wrote: > El dj 26 de 02 de 2009 a les 07:18 +0100, en/na +Mike Krüger va escriure:... +FYI: I've tested this on VS.NET 2008, and the arrows are always +*respected*. Furthermore, the overloads are never present in this +context, but after the user has written the "(" to indicate that a new +function call is being done. + + +-- + +Andrés G. Aragoneses +Software Engineer +aaragoneses at novell.com + +Novell, Inc. +http://www.novell.com/ +Software for the open enterprise + +_______________________________________________ Monodevelop-devel-list +mailing list Monodevelop-dev... +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090305/7590c92a/attachment.html ++ + + +
An issue that has recently gained prominence is reliability of file +writes on Ext4: +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54 +http://mjg59.livejournal.com/108257.html?view=1320929 +After writing a changed file to disk and the system crashes before the +changes are flushed from the OS or disk buffers, files can be left in +a corrupted state. + +The MonoDevelop.Projects TextFile API, in addition to (partially) +handling file encoding detection, has a file save API that attempts to +solve this problem by writing the new file contents to a temp file and +then using a POSIX call to rename the changed file over the old one. +Unfortunately, I often see code in MD that doesn't use this API. +Indeed, it's impossible to use it from MonoDevelop.Core, so I had to +replicate the functionality there some time ago. + +Worse, as described in the posts linked above, this sequence of +operations isn't guaranteed to be safe on POSIX. + +I think we should add an FileStream-based API to MonoDevelop.Core for +handling this, with several other features: +* Levels of reliability: fsync, renaming, unsafe +* Option to create backup files, with automatic fallbacks to backups +when loading damaged settings files +* Autosave to temp files, and prompting the user for recovery of +autosaved or damaged files after a crash + +Another advantage of having this code in a centralised location is +that it would be easy to use alternatives as they become available, +e.g. transactional NTFS on Windows Vista +(http://code.msdn.microsoft.com/txfmanaged). + +Thoughts? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
> An issue that has recently gained prominence is reliability of file +> writes on Ext4: +> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54 +> http://mjg59.livejournal.com/108257.html?view=1320929 +> After writing a changed file to disk and the system crashes before the +> changes are flushed from the OS or disk buffers, files can be left in +> a corrupted state. + +I largely agree with Matthew Garrett's POV on these matters. + +> The MonoDevelop.Projects TextFile API, in addition to (partially) +> handling file encoding detection, has a file save API that attempts to +> solve this problem by writing the new file contents to a temp file and +> then using a POSIX call to rename the changed file over the old one. +> Unfortunately, I often see code in MD that doesn't use this API. +> Indeed, it's impossible to use it from MonoDevelop.Core, so I had to +> replicate the functionality there some time ago. +> +> Worse, as described in the posts linked above, this sequence of +> operations isn't guaranteed to be safe on POSIX. + +Fortunately, it looks like at least the fsync() requirement has +already been removed for ext4 ( +http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8 +). + +> I think we should add an FileStream-based API to MonoDevelop.Core for +> handling this, with several other features: +> * Levels of reliability: fsync, renaming, unsafe +> * Option to create backup files, with automatic fallbacks to backups +> when loading damaged settings files +> * Autosave to temp files, and prompting the user for recovery of +> autosaved or damaged files after a crash + +Would anyone ever explicitly choose less than the most-reliable option? +The backup from temp files is nice. + +> Another advantage of having this code in a centralised location is +> that it would be easy to use alternatives as they become available, +> e.g. transactional NTFS on Windows Vista +> (http://code.msdn.microsoft.com/txfmanaged). +> +> Thoughts? + +Shouldn't some of this be pushed down into the mono framework? +Obviously, stuff like restoring from backups is out-of-spec and must +be external, but shouldn't POSIX minutiae be handled by the System.IO +implementation? + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + + +
El dg 15 de 03 de 2009 a les 15:19 -0400, en/na Michael Hutchinson va +escriure: +> An issue that has recently gained prominence is reliability of file +> writes on Ext4: +> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54 +> http://mjg59.livejournal.com/108257.html?view=1320929 +> After writing a changed file to disk and the system crashes before the +> changes are flushed from the OS or disk buffers, files can be left in +> a corrupted state. +> +> The MonoDevelop.Projects TextFile API, in addition to (partially) +> handling file encoding detection, has a file save API that attempts to +> solve this problem by writing the new file contents to a temp file and +> then using a POSIX call to rename the changed file over the old one. +> Unfortunately, I often see code in MD that doesn't use this API. +> Indeed, it's impossible to use it from MonoDevelop.Core, so I had to +> replicate the functionality there some time ago. +> +> Worse, as described in the posts linked above, this sequence of +> operations isn't guaranteed to be safe on POSIX. +> +> I think we should add an FileStream-based API to MonoDevelop.Core for +> handling this, with several other features: +> * Levels of reliability: fsync, renaming, unsafe +> * Option to create backup files, with automatic fallbacks to backups +> when loading damaged settings files +> * Autosave to temp files, and prompting the user for recovery of +> autosaved or damaged files after a crash + +It sounds ok to me. + +Lluis. + + ++ + + + + + + +
On Mon, Mar 16, 2009 at 8:52 AM, Levi Bard +<taktaktaktaktaktaktaktaktaktak at gmail.com> wrote: +>> An issue that has recently gained prominence is reliability of file +>> writes on Ext4: +>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54 +>> http://mjg59.livejournal.com/108257.html?view=1320929 +>> After writing a changed file to disk and the system crashes before the +>> changes are flushed from the OS or disk buffers, files can be left in +>> a corrupted state. +> +> I largely agree with Matthew Garrett's POV on these matters. + +Me too, but that doesn't change the fact that these problems are +permitted by POSIX, so even if heuristics are added for fixed for ex4 +and btrfs, which should still do the right thing in case other +filesystems are used. + +[...] +>> I think we should add an FileStream-based API to MonoDevelop.Core for +>> handling this, with several other features: +>> * Levels of reliability: fsync, renaming, unsafe +>> * Option to create backup files, with automatic fallbacks to backups +>> when loading damaged settings files +>> * Autosave to temp files, and prompting the user for recovery of +>> autosaved or damaged files after a crash +> +> Would anyone ever explicitly choose less than the most-reliable option? + +Because it has a cost. An fsync can be very expensive. Presumably the +heuristics employed by ext4 have some associated cost too. + +> The backup from temp files is nice. +> +>> Another advantage of having this code in a centralised location is +>> that it would be easy to use alternatives as they become available, +>> e.g. transactional NTFS on Windows Vista +>> (http://code.msdn.microsoft.com/txfmanaged). +>> +>> Thoughts? +> +> Shouldn't some of this be pushed down into the mono framework? +> Obviously, stuff like restoring from backups is out-of-spec and must +> be external, but shouldn't POSIX minutiae be handled by the System.IO +> implementation? + +How could it be fixed? AFAIK the truncate-on-overwrite exists on +Windows (though not the need for fsync), which is one reason why +Transactional NTFS was added. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
>> Shouldn't some of this be pushed down into the mono framework? +>> Obviously, stuff like restoring from backups is out-of-spec and must +>> be external, but shouldn't POSIX minutiae be handled by the System.IO +>> implementation? +> +> How could it be fixed? AFAIK the truncate-on-overwrite exists on +> Windows (though not the need for fsync), which is one reason why +> Transactional NTFS was added. + +Perhaps internally, a write-mode FileStream writes to a temp file, +then renames on close/dispose (maybe fsync on Flush() where +necessary/supported). + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + +
It can be done on a additional layer, but not in the framework as that +changes the contract (or perhaps the better term is semantics) of that API +and so it would not have the same results in .NET and in Mono. + +Just my two cents, + +On Mon, Mar 16, 2009 at 3:46 PM, Levi Bard < +taktaktaktaktaktaktaktaktaktak at gmail.com> wrote: + +> >> Shouldn't some of this be pushed down into the mono framework? +> >> Obviously, stuff like restoring from backups is out-of-spec and must +> >> be external, but shouldn't POSIX minutiae be handled by the System.IO +> >> implementation? +> > +> > How could it be fixed? AFAIK the truncate-on-overwrite exists on +> > Windows (though not the need for fsync), which is one reason why +> > Transactional NTFS was added. +> +> Perhaps internally, a write-mode FileStream writes to a temp file, +> then renames on close/dispose (maybe fsync on Flush() where +> necessary/supported). +> +> -- +> http://homes.eff.org/~barlow/EconomyOfIdeas.html<http://homes.eff.org/%7Ebarlow/EconomyOfIdeas.html> +> http://www.dreamsongs.com/MobSoftware.html +> http://www.gnu.org/philosophy/shouldbefree.html +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Rafael "Monoman" Teixeira +--------------------------------------- +"I myself am made entirely of flaws, stitched together with good +intentions." +Augusten Burroughs +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090316/d43680db/attachment-0001.html ++ + + +
On Mon, Mar 16, 2009 at 2:53 PM, Rafael Teixeira <monoman at gmail.com> wrote: +> It can be done on a additional layer, but not in the framework as that +> changes the contract (or perhaps the better term is semantics) of that API +> and so it would not have the same results in .NET and in Mono. + +Yup, that was my point. Thanks for clarifying :) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
On Tue, Feb 17, 2009 at 8:53 AM, Allahbaksh Mohammedali Asadullah +<Allahbaksh_Asadullah at infosys.com> wrote: +> I am trying to write an add-in which can parse the C# code and spit out +> information like Method Name and Signature , Method Body, Method Call +> information. +> +> Can I extend MonoDevleop.Projects and use MonoDevelop.Projects.Dom and +> MonoDevelop.Projects.Dom.Parser. Can any body throw some light on the same. + +What kind of information are you trying to get? It's possible that the +DOM has the information you require already. If not, there's the +lower-level NRefactory parser, which has a full C# parser -- it's used +to build the DOM in the first place. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
+I just installed Monodevelop 1.9.3. I also tried 1.9.2 but Codecompletion and +Monodoc are not working. The program opens my source created with VBExpress +2008 fine, but when I try to change the code I only get syntax highlighting +and nothing else. + +Regards + +Hans +-- +View this message in context: http://n2.nabble.com/VB-Code-Completion-and-monodoc-tp2499745p2499745.html +Sent from the Mono - MonoDevelop - Dev mailing list archive at Nabble.com. + ++ + + +
+P.S. I could only compile monodoc 1.1.9. Monodoc 2.0 compiled with Error. I +used monoAddins 0.4. +-- +View this message in context: http://n2.nabble.com/VB-Code-Completion-and-monodoc-tp2499745p2503314.html +Sent from the Mono - MonoDevelop - Dev mailing list archive at Nabble.com. + ++ + + +
+Hi: + Is the MonoDevelop.Database Addin still have a Maintainer? I have a pending bug [*] with a patch and no one review it, i think that maybe no one could see it. + + I need to have a review/commit in order to send another patch. I'm heavily using it with mysql as a backend and i have a couple of errors that i could try to fix it beacause is really usefull addin. + + + +Thanks. +Lucian0 + + + +[*] 479343 + + + +_________________________________________________________________ +Get 5 GB of storage with Windows Live Hotmail. +http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090323/f1239ba0/attachment.html ++ + + +
I wrote the original MonoQuery addin, so if the author of the "new" +database addin does not speak up I could probably review it. From what +I remember it was a SoC project so he may not be active anymore. + +-- Christian + +On Mon, 2009-03-23 at 13:36 +0000, Luciano _ wrote: +> Hi: +> Is the MonoDevelop.Database Addin still have a Maintainer? I have +> a pending bug [*] with a patch and no one review it, i think that +> maybe no one could see it. +> I need to have a review/commit in order to send another patch. I'm +> heavily using it with mysql as a backend and i have a couple of errors +> that i could try to fix it beacause is really usefull addin. +> +> Thanks. +> Lucian0 +> +> [*] 479343 +> +> +> +> ______________________________________________________________________ +> Get 5 GB of storage with Windows Live Hotmail. Sign up today. +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + +
Starting: Mon Mar 2 02:29:01 EST 2009
+ Ending: Mon Mar 23 15:48:21 EDT 2009
+ Messages: 16
+
+ Last message date:
+ Mon Mar 23 15:48:21 EDT 2009
+ Archived on: Mon Mar 23 15:48:27 EDT 2009
+
+
+
Starting: Mon Mar 2 02:29:01 EST 2009
+ Ending: Mon Mar 23 15:48:21 EDT 2009
+ Messages: 16
+
+ Last message date:
+ Mon Mar 23 15:48:21 EDT 2009
+ Archived on: Mon Mar 23 15:48:27 EDT 2009
+
+
+
Starting: Mon Mar 2 02:29:01 EST 2009
+ Ending: Mon Mar 23 15:48:21 EDT 2009
+ Messages: 16
+
+ Last message date:
+ Mon Mar 23 15:48:21 EDT 2009
+ Archived on: Mon Mar 23 15:48:27 EDT 2009
+
+
+
Starting: Mon Mar 2 02:29:01 EST 2009
+ Ending: Mon Mar 23 15:48:21 EDT 2009
+ Messages: 16
+
+ Last message date:
+ Mon Mar 23 15:48:21 EDT 2009
+ Archived on: Mon Mar 23 15:48:27 EDT 2009
+
+
+
Starting: Mon Mar 2 02:29:01 EST 2009
+ Ending: Mon Mar 23 15:48:21 EDT 2009
+ Messages: 16
+
+ Last message date:
+ Mon Mar 23 15:48:21 EDT 2009
+ Archived on: Mon Mar 23 15:48:27 EDT 2009
+
+
+
For some reason on Windows the File|Open dialog is throwing exceptions +constantly, usability low for that reason. I saw this issue mentioned +in other posts but no bug report. I modified it to check the +Filenames property rather that Filename and that has improved it +considerably without sacrificing any functionality as far as I can +tell. + +In the event this will help I've attached the diff. + +Thanks +Dave Joyner +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: FileSelectorDialog.patch +Type: application/octet-stream +Size: 2054 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090512/5c0e8d06/attachment.obj ++ + + + +
Hi! + +I'm currently working on a debugger backend for MS.NET, and one of the +problems I've found is due to the fact that the file system is case +insensitive. The debugger returns file names with a lowercase drive +letter while framework always returns it with uppercase. The result is +that files may be opened in the IDE twice, once for each casing. + +This specific issue can easily fixed by uppercasing the initial letter, +but it left me wondering if this should be fixed in a more global way. +We do path comparisons in many places in MD. Many of those are comparing +file names retrieved using the framework, so they should not be a +problem. However, other comparisons may involve paths entered by the +user or read from files. + +One solution I'm pondering the creation of a new FilePath struct to be +used instead of string for all file paths. This struct would only +contain one string and would override all comparison methods which would +be case insensitive only on Windows. With conversion operators in place, +using this struct instead of string should be straightforward. + +However, this is a big change in the api, so I'd like to get some +feedback about it. Other than the debugger issue, everything else seems +to work fine, so I'm not sure it is worth the effort. What do you think? + +Lluis. + ++ + + + +
On Fri, May 15, 2009 at 5:26 PM, Lluis Sanchez Gual <lluis at novell.com> wrote: +> One solution I'm pondering the creation of a new FilePath struct to be +> used instead of string for all file paths. This struct would only +> contain one string and would override all comparison methods which would +> be case insensitive only on Windows. With conversion operators in place, +> using this struct instead of string should be straightforward. +> +> However, this is a big change in the api, so I'd like to get some +> feedback about it. Other than the debugger issue, everything else seems +> to work fine, so I'm not sure it is worth the effort. What do you think? + +I think it's useful to have stronger "typing" for strings, and changes +like this would be better to make sooner rather than later. The struct +could also store whether it's a relative path, and have utility +methods (Combine, GetRoot, GetExtension, etc). + +I was thinking about a similar "typing" trick for solution +configurations vs. project configurations, since I'm pretty sure +they're used interchangeably in many places when they shouldn't be. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
2009/5/12 David Joyner <d4ljoyn at gmail.com>: +> For some reason on Windows the File|Open dialog is throwing exceptions +> constantly, usability low for that reason. I saw this issue mentioned +> in other posts but no bug report. I modified it to check the +> Filenames property rather that Filename and that has improved it +> considerably without sacrificing any functionality as far as I can +> tell. +> +> In the event this will help I've attached the diff. + +Thanks, I'm not using Windows so I can't test this, but it looks like +Lluis committed a partial version: +http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui.Dialogs/FileSelectorDialog.cs?r1=104769&r2=135028 + +Does that fix the problem for you? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Tue May 12 12:15:34 EDT 2009
+ Ending: Sun May 31 22:39:26 EDT 2009
+ Messages: 4
+
+ Last message date:
+ Sun May 31 22:39:26 EDT 2009
+ Archived on: Sun May 31 22:39:35 EDT 2009
+
+
+
Starting: Tue May 12 12:15:34 EDT 2009
+ Ending: Sun May 31 22:39:26 EDT 2009
+ Messages: 4
+
+ Last message date:
+ Sun May 31 22:39:26 EDT 2009
+ Archived on: Sun May 31 22:39:35 EDT 2009
+
+
+
Starting: Tue May 12 12:15:34 EDT 2009
+ Ending: Sun May 31 22:39:26 EDT 2009
+ Messages: 4
+
+ Last message date:
+ Sun May 31 22:39:26 EDT 2009
+ Archived on: Sun May 31 22:39:35 EDT 2009
+
+
+
Starting: Tue May 12 12:15:34 EDT 2009
+ Ending: Sun May 31 22:39:26 EDT 2009
+ Messages: 4
+
+ Last message date:
+ Sun May 31 22:39:26 EDT 2009
+ Archived on: Sun May 31 22:39:35 EDT 2009
+
+
+
Starting: Tue May 12 12:15:34 EDT 2009
+ Ending: Sun May 31 22:39:26 EDT 2009
+ Messages: 4
+
+ Last message date:
+ Sun May 31 22:39:26 EDT 2009
+ Archived on: Sun May 31 22:39:35 EDT 2009
+
+
+
Hi! + +I plan to do the final branch for MD 2.2 today. If there is any +showstopper bug you think that needs to be fixed for 2.2, please let me +know ASAP. + +Thanks! +Lluis. + ++ + + +
Hi, + +I have just created a branch for MD 2.2. This is the branch from which +we'll release the final 2.2. After going through QA, we'll release this +branch as RC, and if there isn't any showstopper, that will be 2.2. + +>From now on, only critical fixes can be backported to the 2.2 branch. In +case of doubt, ask here or in irc. + +Lluis. + ++ + +
Starting: Thu Nov 5 05:24:11 EST 2009
+ Ending: Thu Nov 5 12:53:49 EST 2009
+ Messages: 2
+
+ Last message date:
+ Thu Nov 5 12:53:49 EST 2009
+ Archived on: Thu Nov 5 12:56:23 EST 2009
+
+
+
Starting: Thu Nov 5 05:24:11 EST 2009
+ Ending: Thu Nov 5 12:53:49 EST 2009
+ Messages: 2
+
+ Last message date:
+ Thu Nov 5 12:53:49 EST 2009
+ Archived on: Thu Nov 5 12:56:23 EST 2009
+
+
+
Starting: Thu Nov 5 05:24:11 EST 2009
+ Ending: Thu Nov 5 12:53:49 EST 2009
+ Messages: 2
+
+ Last message date:
+ Thu Nov 5 12:53:49 EST 2009
+ Archived on: Thu Nov 5 12:56:23 EST 2009
+
+
+
Starting: Thu Nov 5 05:24:11 EST 2009
+ Ending: Thu Nov 5 12:53:49 EST 2009
+ Messages: 2
+
+ Last message date:
+ Thu Nov 5 12:53:49 EST 2009
+ Archived on: Thu Nov 5 12:56:23 EST 2009
+
+
+
Starting: Thu Nov 5 05:24:11 EST 2009
+ Ending: Thu Nov 5 12:53:49 EST 2009
+ Messages: 2
+
+ Last message date:
+ Thu Nov 5 12:53:49 EST 2009
+ Archived on: Thu Nov 5 12:56:23 EST 2009
+
+
+
Hi, + +Visual Studio 2010 and SharpDevelop are now creating new projects +targeting 32bit platforms by default. See [1] for a good explanation of +why. This doesn't have any effect when running on Mono, but it does +in .NET/Windows (we already have bug reports about this, such has [2]). + +Does anybody have anything against doing this change in MD? + +Lluis. + +[1] http://laputa.sharpdevelop.net/SharpDevelopNowCreatesProjectsAs32bitByDefault.aspx +[2] https://bugzilla.novell.com/show_bug.cgi?id=514759 + ++ + + +
I just changed the default to x86 platform. There is a more in-depth +explanation of that change in VS 2010 here: + +http://blogs.msdn.com/rmbyers/archive/2009/06/08/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx + +In any case, if we find that's not convenient for MD it's easy to +revert. + +El dl 05 de 10 de 2009 a les 18:26 +0200, en/na Lluis Sanchez Gual va +escriure: +> Hi, +> +> Visual Studio 2010 and SharpDevelop are now creating new projects +> targeting 32bit platforms by default. See [1] for a good explanation of +> why. This doesn't have any effect when running on Mono, but it does +> in .NET/Windows (we already have bug reports about this, such has [2]). +> +> Does anybody have anything against doing this change in MD? +> +> Lluis. +> +> [1] http://laputa.sharpdevelop.net/SharpDevelopNowCreatesProjectsAs32bitByDefault.aspx +> [2] https://bugzilla.novell.com/show_bug.cgi?id=514759 +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + +
+Hi: + Attached is a patch to fix an ExtensibleTreeView bug. When "Context Menu Key" is pressed and no item is selected in tbe treeview a NullReferenceException Exception is raise. This patch fix this bug. + +Could i commit? + +Thanks +Lucian0 + +_________________________________________________________________ + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20091022/e846cd90/attachment-0001.html ++ + + +
+Ups i forgot the file :) + +From: lnc19 at hotmail.com +To: monodevelop-devel-list at lists.ximian.com +Date: Thu, 22 Oct 2009 03:26:53 +0000 +Subject: [Monodevelop-devel] ExtensibleTreeView patch + + + + + + + + +Hi: + Attached is a patch to fix an ExtensibleTreeView bug. When "Context Menu Key" is pressed and no item is selected in tbe treeview a NullReferenceException Exception is raise. This patch fix this bug. + +Could i commit? + +Thanks +Lucian0 + + +_________________________________________________________________ + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20091022/75a8bada/attachment.html +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: MonoDevelop.Ide.Gui.Components.patch +Type: text/x-patch +Size: 1102 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20091022/75a8bada/attachment.bin ++ + + +
Please commit. Thanks! + +El dj 22 de 10 de 2009 a les 03:28 +0000, en/na Luciano _ va escriure: +> Ups i forgot the file :) +> +> +> ______________________________________________________________________ +> From: lnc19 at hotmail.com +> To: monodevelop-devel-list at lists.ximian.com +> Date: Thu, 22 Oct 2009 03:26:53 +0000 +> Subject: [Monodevelop-devel] ExtensibleTreeView patch +> +> Hi: +> Attached is a patch to fix an ExtensibleTreeView bug. When +> "Context Menu Key" is pressed and no item is selected in tbe treeview +> a NullReferenceException Exception is raise. This patch fix this bug. +> +> Could i commit? +> +> Thanks +> Lucian0 +> +> +> ______________________________________________________________________ +> +> +> ______________________________________________________________________ +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + +
Hi + +I've created this small patch to make the development of a XNA addin +for MD easier. MS XNA projects all have a nested content project ie. a +dot net child project containing the game content. These content +projects are not referenced like a normal project in the Projects +section of the sln file. They are only represented in the +ProjectConfigurationPlatforms global section by only an ActiveCfg +configuration and no Build.0. + +I managed to get things "working" without modifying the MD source, but +things got a bit messy and I had to duplicate working MD code. The +changes i've done to the MD source has removed several of these issues + by allowing the content project to registered with the solution +without being "visible". The modifications shouldn't affect any +existing code. + +The changes are: +- added property to SolutionItem called Visible +- added check to SolutionConfiguration set the Build property to null +if not Visible +- added check to SolutionNodeBuilder to not add non Visible solution +items to the project pad +- added check to SlnFileFormat to not serialize non Visible items + +The problem remaining now since the project isn't referenced directly +in the sln file is that I get a warning when the solution is loaded +and my nested content project has to be manually loaded later and then +added to the solution over again. I've been thinking about a fix for +this which would involve allowing SolutionItem subclasses to have +nested SolutionItems which would be loaded along (directly after) by +the solution loader. + +Hope this information provides adequate insight of what I'm doing and +why I'm doing it. I'm looking forward to you feedback... + +-lavima +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: lavima.patch +Type: text/x-patch +Size: 3241 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20091029/d3cab946/attachment.bin ++ + +
Starting: Mon Oct 5 12:26:30 EDT 2009
+ Ending: Thu Oct 29 08:18:08 EDT 2009
+ Messages: 6
+
+ Last message date:
+ Thu Oct 29 08:18:08 EDT 2009
+ Archived on: Thu Oct 29 08:38:09 EDT 2009
+
+
+
Starting: Mon Oct 5 12:26:30 EDT 2009
+ Ending: Thu Oct 29 08:18:08 EDT 2009
+ Messages: 6
+
+ Last message date:
+ Thu Oct 29 08:18:08 EDT 2009
+ Archived on: Thu Oct 29 08:38:09 EDT 2009
+
+
+
Starting: Mon Oct 5 12:26:30 EDT 2009
+ Ending: Thu Oct 29 08:18:08 EDT 2009
+ Messages: 6
+
+ Last message date:
+ Thu Oct 29 08:18:08 EDT 2009
+ Archived on: Thu Oct 29 08:38:09 EDT 2009
+
+
+
Starting: Mon Oct 5 12:26:30 EDT 2009
+ Ending: Thu Oct 29 08:18:08 EDT 2009
+ Messages: 6
+
+ Last message date:
+ Thu Oct 29 08:18:08 EDT 2009
+ Archived on: Thu Oct 29 08:38:09 EDT 2009
+
+
+
Starting: Mon Oct 5 12:26:30 EDT 2009
+ Ending: Thu Oct 29 08:18:08 EDT 2009
+ Messages: 6
+
+ Last message date:
+ Thu Oct 29 08:18:08 EDT 2009
+ Archived on: Thu Oct 29 08:38:09 EDT 2009
+
+
+
Hi + +> We should review the api and see how language bindings are currently +> used. So for example, if we move the comment tag properties to syntax +> modes, and parser/refactorer have their own extension points, there +> isn't much left in ILanguageBinding. This code has evolved a lot since +> it was designed, so maybe it can go away or it can be replaced by +> something else. +> + +Ok my suggestion would be removing the language binding and replacing it +with an ICompiler interface (that is the only functionality that is +really used). We then can have the IParser, ICompiler, IResolver +interfaces directly in the addin tree. There is no need that each +language binding provides a wrapper class there. + +> > - They provide comment tags, but we get comment tags from the syntax +> > modes. +> +> I think we should get rid of those comment tag properties from +> ILanguageBinding, and use only the info from syntax modes. However, +> they +> are still being used when creating a new file to insert the license +> header. We have to find a way of querying information from syntax +> modes +> without having and instance of an editor. +> + +Instance of an editor isn't required for accessing the syntax modes. The +syntax mode service is static. + +> > - They bind to a 'language' and can ask if a file is a source code +> file +> > ore not - they're not using our newer mime type system +> (inconsistent!) +> +> The mime-type system doesn't have information about which types are +> source code files. We have per-mime-type formatting policies, but this +> is unrelated. +> + +The language system doesn't have good information too, the language +binding system with the 'language' property was an idea to mimic the +mime type system. Unfortunately binding this to a IProject doesn't work +for example a parser or refactorer for a "C#" language needs to be +different, because the project can contain C# files an ASP.NET files. +It makes sense to bind a compiler to a project (The ICompiler for +example). This can be done with a project id, but we're using guids for +them the language name is a leftover from old #d days and hasn't any +real meaning. + +> > - Maybe they should be attached to a ProjectDom or ViewContent to allow +> > easier access. +> +> I don't think that's necessary. You can already get a language binding +> from Project, and you can get a project from ProjectDom and ViewContent. +> +A project can contain different languages (ASP.NET project for example) +therefore binding some functions to the mime type makes more sense. I +think the view content (or 'Document') would be a good point to place +this. For example accessing the 'comment' tags could be handled on the +'Document' level. I think it makes sense to have a ICompiler on the +project level and most of the rest on the mime type/per document level. + + +> Our resources are limited, so we have to be careful about where we put +> our development effort. We should focus on fixing, improving or +> implementing features that users really need. Improving the API is part +> of the work, but we have to find the right effort/benefit balance. +> + +Improving the API helps us. + +Regards +Mike + ++ + + +
Hi + +> > * The way it's used it's not build for. +> > +> > - For example the workspace window should wrap the gui the view content +> > is displayed in (for example tab page or window) - therefore it should +> > be a DockItem directly. It should contain a collection of view contents +> > (for example text editor/forms designer) - but stetic doesn't use this, +> > it does it's own. I don't know if the subviews are currently used. +> +> The ASP.NET designer uses a subview. There used to be an subview for +> previews of HTML docs in MD.IDE, but AFAIK it was removed during +> deGPLification. +> + +But no core addin should re-create the 'attached view content' subsystem +itself. And thats what stetic did. If the subsystem isn't good enough it +should be extended. + +> > - The Layout abstraction was for enabling other layout managers. +> > SharpDevelop had a floating layout (think of gimp layout) and a tabbed +> > layout (called sdi) - later I got rid of the floating layout, because +> > maintaining layouts is error prone. Now we don't need the abstraction +> > anymore. +> +> Well, a floating layout would be useful for the Mac, if anyone cares +> to implement it. +> + +It's a nightmare to maintain. But if someone does it for mac - why not. + +> * file/project templating system: I've really been stressing it, +> particularly with ASP.NET / ASP.NET MVC templates, and it makes a lot +> of things difficult. +> +> * new file/project dialog: these have poor usability and organization. +> + +Yes templates should be on the redo list. + +> * code templates. I'd like to have APIs for addins to add code +> templates.\ +> +I think it's easy to do this. + +> * There are many places in the project system where a "configuration" +> string is passed around and it's unclear whether it's a project +> configuration (and should be looked up with GetConfiguration) or a +> solution configuration (and the project configuration should be looked +> up with GetActiveConfiguration).. This API really needs usability +> improvements. +> + +I had problems with this too :) + +> It would also be very useful to improve the MD docs. I think there's a +> good case to be made for using XML documentation -- see my previous +> email on the topic. +> + +MD docs are a good thing. But I would prefer good APIs in the first +place. + +Regards +Mike + ++ + + +
I kept a few notes while implementing portions of the PyBinding. These +are in their raw form but I figured I'd attach them for the sake of +having the information somewhere. + +Some things also may have been fixed since I wrote these. Please do not +take any offense to any of the wording if my comments are on code you've +written, all in all it was a quite pleasant experience :-) + +-- Christian + + +Reusable REPL +============= + +We need a reusable REPL that languages can extend. Perhaps the guts +from the "csharp>" REPL can be extracted and re-used. Bonus points if +it can render using a modified Mono.TextEditor for highlighting. + +Language Bindings +================= + +I'm not convinced that the language binding class is even needed. All +it seems to do is aggregate different pieces together. It also doesn't +provide a compeling way for multiple language bindings to implement the +same feature. This may become an issue for an IronPython versus CPython +addin. + +Workspace +========= + +Michael mentioned that having the "Gimp" style interface would be nice +on OS X. I agree. I also think it would be nice on Linux. I much +prefer the layout as long as the toolbars are "sticky" to the top of my +screen. + +Docking Panels +============== + +This are *very* buggy in their current state. We need a bug love day +focused on these since they are so critical to daily use. + +Refactoring +=========== + +XXX: Add information + +Editor Extensions +================= + +Custom extensions for indentation control don't seem to have a well +defined model for implementation. This may simply be a documentation +problem. + +Code Completion +=============== + +ProjectDom is highly .NET centric. PyBinding conforms to this for in +file parsing since it gives us persistence "for free". But this is not +suitable for indexing the system packages. I would like this to be +easily re-usable for writing other add-ins such as JavaScript, Ruby, or +even SQL. + +Currently, it is very tough to map python language concepts to things +like IType, IMember, and such. Even when conforming to that, features +like tooltips are bound to using words like "Namespace" rather than +"Module" or "Package". + +I'd really like to be able to re-use the parser database rather than +managing my own with sqlite. + +It might be nice to use compression within the database by default. All +the information on the subject I've seen recently shows faster query +times due to reduced I/O. However, I haven't looked to seef if this is +done already. + +Mime Type's and Settings +======================== + +I need a way of specifying the default settings for a mime-type. I'm +sure pretty much all non-c# languages need this. + +Appearance +========== + +Far too much of the UI window is wasted for non-coding. The +double-click tab feature is nice, but tabs themself are quite large. +I'm quite aware this is caused by common gtk+ widget themes and icons +included in buttons. + +However, I think it is a worthwhile effort to see how we can work around +it. A solid default pixmap theme could make things quite attactive. +For example, QtCreator[1] is quite attactive on various platforms. + +Documentation +============= + +MonoDoc is possibly the worst documentation system I've ever used. I +suggest we abandon it as an external dependency and build something in +process. It should support: + + * .NET and non-.NET languages. + * Indexing and Full-text like MonoDoc does. + * Cross-referencing of documentation between languages so GtkWidget in + C documentation can link to gtk.Widget python docs and Gtk.Widget + .NET documentation. + * Generated HTML documentation for viewing and ability to export to + static files. + * Add comments or update documentation. This could be pushed to a + collaborative system that mono/monodevelop could host for comments. + That way, we continue to get the benefit of crowd-sourcing. + +Collaboration +============= + +We need a bugzilla add-in that can hook with version control system. +When I include a commit message that says "Fixes #123123" I expect it to +send the patch to bugzilla and close the bug. + +Build System +============ + +I find the build system to be a PITA to work with. I personally build +from command line most of the time. I don't understand why we need +configure scripts for various individual projects and such. I certainly +don't mind the change to xbuild; it just needs to work. + +We have svn, do we really need ChangeLog's anymore? They waste space +and add one more layer of duplication of content. We should simply +generate a master ChangeLog during "make dist" or similar. + +MonoDevelop Shell +================= + +In Visual Studio and Eclipse fashion, it's time that the shell itself +become re-usable and re-distributable. It would be nice if I was able +to build a self contained PyBinding application that included only what +it needed from MonoDevelop. + +[1] http://qt.nokia.com/products/developer-tools/developer-tools ++ + + +
Hi + +> Code Completion +> =============== +> +> ProjectDom is highly .NET centric. PyBinding conforms to this for in +> file parsing since it gives us persistence "for free". But this is +> not +> suitable for indexing the system packages. I would like this to be +> easily re-usable for writing other add-ins such as JavaScript, Ruby, +> or +> even SQL. +> + +Why it is .NET centric ? It's usable for defining a class model. It's +not suited for defining a language that doesn't contain classes (like +SQL). And for non oo languages it can be simulated (just put all members +in a generated container class). + + +> Currently, it is very tough to map python language concepts to things +> like IType, IMember, and such. Even when conforming to that, features +> like tooltips are bound to using words like "Namespace" rather than +> "Module" or "Package". +> + +This should be changeable by using another ambience. Currently they +don't contain these strings, but thats somethin we should put into them. + +> I'd really like to be able to re-use the parser database rather than +> managing my own with sqlite. +> +> It might be nice to use compression within the database by default. All +> the information on the subject I've seen recently shows faster query +> times due to reduced I/O. However, I haven't looked to seef if this is +> done already. +> + +I've always thought that we should use a 'real' database there. I've too +often code completion file errors. I'm the only one with this problem ? + +Regards +Mike + ++ + + +
>> ProjectDom is highly .NET centric. PyBinding conforms to this for in +>> file parsing since it gives us persistence "for free". But this is +>> not +>> suitable for indexing the system packages. I would like this to be +>> easily re-usable for writing other add-ins such as JavaScript, Ruby, +>> or +>> even SQL. +>> +> +> Why it is .NET centric ? It's usable for defining a class model. It's +> not suited for defining a language that doesn't contain classes (like +> SQL). And for non oo languages it can be simulated (just put all members +> in a generated container class). +> +> +>> Currently, it is very tough to map python language concepts to things +>> like IType, IMember, and such. Even when conforming to that, features +>> like tooltips are bound to using words like "Namespace" rather than +>> "Module" or "Package". +>> +> +> This should be changeable by using another ambience. Currently they +> don't contain these strings, but thats somethin we should put into them. + +It's not just a difference in terminology - different languages often +have slightly (or drastically) different OO models, due to different +language features, designer mindsets, what have you. For example, a +Ruby module is kind of a mixture, from a c# perspective, of a +namespace, a static class, and an interface. Or in Vala, one can have +static methods that belong directly to a namespace. + +So, it would be nice to have a more generic builtin dom. + +I'm in favor of removing the language binding, as long as the +information in the syntax modes is sanely exposed. + +A generic REPL using Mono.TextEditor would be fantastic. +I'd love to see M.TE reworked a little so that it would be easy for +extenders and aggregators to pick/choose/add/remove/rearrange things +like the margins. + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + +
Hi + +Currently we've two DOMs: + +MonoDevelop DOM +Language specific DOM + +The idea of the monodevelop dom is that most parts of the IDE only use +the upper level (namespaces/types/members etc.) of the .NET doms for +some parts (class browser, quick method navigation etc.). This DOM +reflects the capabilities of .NET reflection. + +Now some people have the opinion that this limits monodevelop when +supporting non .NET languages and I think they're right. +I see that currently the main problem is that monodevelop uses the +type->member model. +I would rather suggest working with a tree model instead, adding some +new 'types' to be able to do have a file->member structure. + +I would: + ++ Replace IDomVisitable with a tree node - each tree node knows it's +parent, children and siblings. + ++ Remove compilation unit, replace it with IFile. + +Then it's possible to have file->methods/fields as well as +file->type->methods/members and the class browser/code navigator can +show the new 'model' as well. I don't expect huge changes in the current +code base. The parser database needs to change a bit, but shouldn't +change much. + +And I would like to replace the DomLocation with DocumentLocation from +the text editor (or offset based from the text editor) - currently we've +too many ways of representing a location in a file. + +Any opinions on that ? + +Regards +Mike + ++ + + +
I vote +1, this would make the python dom code much more readable. +-- Christian + +On Tue, Sep 22, 2009 at 5:08 AM, Mike Krüger <mkrueger at novell.com> wrote: + +> Hi +> +> Currently we've two DOMs: +> +> MonoDevelop DOM +> Language specific DOM +> +> The idea of the monodevelop dom is that most parts of the IDE only use +> the upper level (namespaces/types/members etc.) of the .NET doms for +> some parts (class browser, quick method navigation etc.). This DOM +> reflects the capabilities of .NET reflection. +> +> Now some people have the opinion that this limits monodevelop when +> supporting non .NET languages and I think they're right. +> I see that currently the main problem is that monodevelop uses the +> type->member model. +> I would rather suggest working with a tree model instead, adding some +> new 'types' to be able to do have a file->member structure. +> +> I would: +> +> + Replace IDomVisitable with a tree node - each tree node knows it's +> parent, children and siblings. +> +> + Remove compilation unit, replace it with IFile. +> +> Then it's possible to have file->methods/fields as well as +> file->type->methods/members and the class browser/code navigator can +> show the new 'model' as well. I don't expect huge changes in the current +> code base. The parser database needs to change a bit, but shouldn't +> change much. +> +> And I would like to replace the DomLocation with DocumentLocation from +> the text editor (or offset based from the text editor) - currently we've +> too many ways of representing a location in a file. +> +> Any opinions on that ? +> +> Regards +> Mike +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090922/fd591acc/attachment-0001.html ++ + + +
On Tue, Sep 22, 2009 at 8:08 AM, Mike Krüger <mkrueger at novell.com> wrote: +... +> Now some people have the opinion that this limits monodevelop when +> supporting non .NET languages and I think they're right. +> I see that currently the main problem is that monodevelop uses the +> type->member model. +... +> Any opinions on that ? + +Sounds good. + +It would be good to drive it with practical cases though. Maybe it +would be best to start by looking at the problems that the +C/C++/Vala/Python addins have. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
> + Replace IDomVisitable with a tree node - each tree node knows it's +> parent, children and siblings. + +I'm fine with that. + +> + Remove compilation unit, replace it with IFile. + +I'm not sure what's the best way to approach this. +For a lot of languages, file-level separation doesn't make sense: it +may require the contents of multiple files (whose relationship is not +explicitly specified at the source level) to build a coherent model +for any one file (Vala); nodes may be declared and/or defined across +multiple files (C, C#, Ruby, Python); etc. These issues can be worked +out / worked around while retaining the IFile model, but IMO they +/should/ be worked out before any code gets changed. + +> Then it's possible to have file->methods/fields as well as +> file->type->methods/members and the class browser/code navigator can +> show the new 'model' as well. I don't expect huge changes in the current +> code base. The parser database needs to change a bit, but shouldn't +> change much. + +It would be nice to have a more "global" (per-solution? per-project?) +builtin parse db that's a sink for any/all parse operations, and _the_ +source for completion, quickfinder, folding, class browser, +refactoring, etc. + +> And I would like to replace the DomLocation with DocumentLocation from +> the text editor (or offset based from the text editor) - currently we've +> too many ways of representing a location in a file. + +Works for me - I keep having to manually offset my DomLocation values +in order for folds and things to show up at the right spots. + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + +
Hi + +> > + Remove compilation unit, replace it with IFile. +> +> I'm not sure what's the best way to approach this. +> For a lot of languages, file-level separation doesn't make sense: it +> may require the contents of multiple files (whose relationship is not +> explicitly specified at the source level) to build a coherent model +> for any one file (Vala); nodes may be declared and/or defined across +> multiple files (C, C#, Ruby, Python); etc. These issues can be worked +> out / worked around while retaining the IFile model, but IMO they +> /should/ be worked out before any code gets changed. +> + +Doesn't matter at this level, because it's required to get the file +where the node is declared. That is the main reason for using a IFile +node. To define cross file nodes (like partial types in c#) it's +required to do something like the CompoundType. This doesn't change - in +contrast it makes more sense, because now CompoundType has a compilation +unit attached which is really senseless for this type. + +> > Then it's possible to have file->methods/fields as well as +> > file->type->methods/members and the class browser/code navigator can +> > show the new 'model' as well. I don't expect huge changes in the current +> > code base. The parser database needs to change a bit, but shouldn't +> > change much. +> +> It would be nice to have a more "global" (per-solution? per-project?) +> builtin parse db that's a sink for any/all parse operations, and _the_ +> source for completion, quickfinder, folding, class browser, +> refactoring, etc. +> + +We've a 'builtin' parse db where all parse operations 'should' occur - +this is the source for completion, class browser, folding markers and +quick finder. + +The problem is refactoring and folding. Folding can be partially done +for all languages but refactoring (and the resolving for completion) is +language bound. I've tried to merge at least c#/vb.net in the past but I +doubt that this did really make sense - at least there are always nodes +or properties that are incompatible with language X. This makes the DOM +harder to handle and visitors or analyzers harder to write/maintain. + +But what can be done is dom node sharing - having the language bound dom +using the monodevelop dom structures, wrapping the monodevelop +interfaces (this will safe one tree conversion). But at the end the DOMs +are still distinct. But I would like to have more shared data structures +(for example having always translate the coordinates NRefactor location +<-> DOM location <-> DocumentLocation <-> text offsets can drive me +crazy, as well as IReturnType <-> TypeReference). + +I think that language bindings need to bring their own dom for +refactoring, resolving and code formatting. These things are strictly +bound to the language and can't be abstracted - except for having two +very similiar languages (but even than it has a price). +But the good thing is that much other stuff can be shared - that's what +the monodevlop DOM is for. + +But there should be a central point where the language specific DOM +should be available (I think the Document is the right place). + +Regards +Mike + ++ + + + +
Hello all, + +I've installed MonoDevelop 2.2b1 and the GTK library. I already had .NET +3.5 installed. When I click on the MonoDevelop start menu icon the mouse +cursor goes busy for a few seconds and then nothing happens. I can't +seem to find any logs that might explain what's gone wrong. I'm running +Windows XP SP3. + +What am I doing wrong? + +Regards, + +Jack Hughes +OPENXTRA Ltd. +http://www.openxtra.co.uk ++ + + + + + + + + + + + + + + + + + + + + + + + +
El dt 22 de 09 de 2009 a les 14:08 +0200, en/na Mike Krüger va escriure: +> Hi +> +> Currently we've two DOMs: +> +> MonoDevelop DOM +> Language specific DOM +> +> The idea of the monodevelop dom is that most parts of the IDE only use +> the upper level (namespaces/types/members etc.) of the .NET doms for +> some parts (class browser, quick method navigation etc.). This DOM +> reflects the capabilities of .NET reflection. +> +> Now some people have the opinion that this limits monodevelop when +> supporting non .NET languages and I think they're right. +> I see that currently the main problem is that monodevelop uses the +> type->member model. +> I would rather suggest working with a tree model instead, adding some +> new 'types' to be able to do have a file->member structure. +> +> I would: +> +> + Replace IDomVisitable with a tree node - each tree node knows it's +> parent, children and siblings. +> +> + Remove compilation unit, replace it with IFile. +> +> Then it's possible to have file->methods/fields as well as +> file->type->methods/members and the class browser/code navigator can +> show the new 'model' as well. I don't expect huge changes in the current +> code base. The parser database needs to change a bit, but shouldn't +> change much. + +Right now the DOM we have is very .NET centric. It is not just a matter +of DOM structure (e.g. assembly->namespace->type->member), but also +about the semantics of the DOM (for example, all types are subclasses of +System.Object). .NET semantics are everywhere in the DOM. + +The problem we have is that we are trying to do too many things with a +single DOM. The MD DOM is used basically for three things: + + 1. Fill navigation widgets such as the member/type combos at the + top of the editor, the document outline or the class pad. + 2. Support code completion for .NET languages. It can be used for + example to resolve types across all referenced assemblies of a + project, no matter which language were those assemblies written + on. + 3. A general purpose DOM, used by add-ins to extract information + about classes and members and do something with them (for + example, the Stetic designer uses that to detect classes bound + to a designer). + +The current situation is that if a non .NET language wants to provide +support for 1), we are forcing the use of the MD DOM, even when it +really doesn't fit. And there isn't much gain with that, because that +language won't be really able to leverage 2) and 3). The type resolution +rules of the MD DOM strictly follow the .NET semantics, so it won't be +of much use for non .NET languages. Also, as a general purpose DOM for +the language it won't be really useful because it won't allow expressing +the particularities of the language. + +My ideas for improving the situation are the following: + + * Create a new DOM, which would be very high level, with just the + information required to support 1). It would be a simple DOM, + intended only for displaying information to the user, not for + type resolution or other operations. + * Make it explicit that the current MD DOM is only for .NET + languages. + * Each .NET language would implement its own DOM to support code + completion. + * Generalize a bit the parser service, so we can share some of its + logic. We can keep the parser database as it is right now, but + it would be used only for .NET languages. Non .NET languages + would use its own DOM storage model. Maybe we wouldn't be able + to share much, but at least we could share the thread that + checks for changes and triggers parse operations or something + like that. + +Lluis. + + ++ + + +
El dv 25 de 09 de 2009 a les 11:33 +0100, en/na Jack Hughes va escriure: +> Hello all, +> +> I've installed MonoDevelop 2.2b1 and the GTK library. I already had .NET +> 3.5 installed. When I click on the MonoDevelop start menu icon the mouse +> cursor goes busy for a few seconds and then nothing happens. I can't +> seem to find any logs that might explain what's gone wrong. I'm running +> Windows XP SP3. +> +> What am I doing wrong? + +Try the latest trunk installer from: +http://monodevelop.com/Download/Trunk_Builds + +If MD still doesn't start, look at this log file: +c:\documents and settings\<your user>\Application Data\MonoDevelop\log.txt + +Lluis. + ++ + + + + + + + + + + + + + + + + + + + + + +
> The problem we have is that we are trying to do too many things with a +> single DOM. The MD DOM is used basically for three things: +> +> 1. Fill navigation widgets such as the member/type combos at the +> top of the editor, the document outline or the class pad. +> 2. Support code completion for .NET languages. It can be used for +> example to resolve types across all referenced assemblies of a +> project, no matter which language were those assemblies written +> on. +> 3. A general purpose DOM, used by add-ins to extract information +> about classes and members and do something with them (for +> example, the Stetic designer uses that to detect classes bound +> to a designer). +> +> The current situation is that if a non .NET language wants to provide +> support for 1), we are forcing the use of the MD DOM, even when it +> really doesn't fit. And there isn't much gain with that, because that +> language won't be really able to leverage 2) and 3). The type resolution +> rules of the MD DOM strictly follow the .NET semantics, so it won't be +> of much use for non .NET languages. Also, as a general purpose DOM for +> the language it won't be really useful because it won't allow expressing +> the particularities of the language. +> +> My ideas for improving the situation are the following: +> +> * Create a new DOM, which would be very high level, with just the +> information required to support 1). It would be a simple DOM, +> intended only for displaying information to the user, not for +> type resolution or other operations. +> * Make it explicit that the current MD DOM is only for .NET +> languages. +> * Each .NET language would implement its own DOM to support code +> completion. +> * Generalize a bit the parser service, so we can share some of its +> logic. We can keep the parser database as it is right now, but +> it would be used only for .NET languages. Non .NET languages +> would use its own DOM storage model. Maybe we wouldn't be able +> to share much, but at least we could share the thread that +> checks for changes and triggers parse operations or something +> like that. + +This is more or less what non-.NET languages have to do currently: +Munge some stuff into the DOM for 1), custom implementation for 2), 3) +[which is refactoring also, isn't it?] is basically impossible. + +I'm on board with a unified, high-level DOM for populating +quickfinder, classpad, etc. [Zeroth bullet] +If this part is generalized enough to support native hierarchy +structures for various languages [currently missing], easily updatable +[currently exists], and easily and flexibly queryable from addin code +[currently missing], completion doesn't necessarily require its own +DOM, just some completion hooks similar to the existing ones. Things +like Goto Definition and Find References could operate at this level +as well. +Similarly, there's no reason that the same overall storage mechanism +couldn't be used for .NET and non-.NET parse databases, as long as +hooks are exposed for specializing the storage process for specific +DOM implementations. + +I would LOVE to see enough assumptions neutralized that I could enable +Stetic or hook into existing refactoring operations for a specific, +arbitrary language. + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + + +
Hi
+
+
+> The current situation is that if a non .NET language wants to provide
+> support for 1), we are forcing the use of the MD DOM, even when it
+> really doesn't fit. And there isn't much gain with that, because that
+> language won't be really able to leverage 2) and 3). The type
+> resolution
+> rules of the MD DOM strictly follow the .NET semantics, so it won't be
+> of much use for non .NET languages. Also, as a general purpose DOM for
+> the language it won't be really useful because it won't allow
+> expressing
+> the particularities of the language.
+>
+
+Type resolution isn't done in the MD DOM most resolving is done by the
+backends.
+Our DOM it can be a bit better at genericity than the current one. But
+we won't never get a 'general purpose' dom. It should just describe the
+most basic language structures we likely encounter.
+
+> My ideas for improving the situation are the following:
+>
+> * Create a new DOM, which would be very high level, with just
+> the
+> information required to support 1). It would be a simple DOM,
+> intended only for displaying information to the user, not for
+> type resolution or other operations.
+
+I don't think a new DOM is required the current one represents the .NET
+reflection API and that's a good sharing point across all .NET
+languages. I would change the current one a bit so that it's more mighty
+than the reflection API. Some languages that are a bit different can be
+wrapped to .NET classes by their compiler and it would be nice if we can
+support those languages.
+
+Type resolution is done in the language backends. It does have some
+operations but these are common accross all languages that use .NET
+(like give all types in a namespace). When building a non .NET binding
+there is no need to use these .NET specific features.
+
+My suggestion for making the DOM more general:
+Doing anything with a tree node as base and have some types of tree
+nodes (file/namespace/class/method etc). All tree nodes have:
+
+* Link to their parent
+* Know their childrin
+* Have connections to their siblings
+
+Accessing the children/parents is the same for all these DOM nodes. Some
+operations on the current DOM have become a bit too difficult and they
+would be easier with a general tree as underlying data structure.
+
+It has limits to build a general DOM - I would draw the line
+between .NET/non .NET language. The output done by the ambiences limits
+a bit the flexibility of the DOM. But I think that ambiences are a good
+idea.
+
+Some examples .NET specific things that we use but will clash with
+non .NET languages and there isn't anything we can do about:
+
+* Method paramater modifiers out/ref/params - no 'per name' modifier
+* General modifiers (public/protected etc.) - no c++ 'inline' modifier
+or others
+* Just file -> namespace -> type -> member model - no 'pascal units' or
+declaration/implementation models (#include) or any other form of
+representation
+* Just the .NET constructs (no 'typedef' for example).
+
+.. and maybe more
+
+Things we currently support but .NET doesn't:
+
+* Multiple inheritance
+
+Things we can support with some DOM refactorings but currently we don't:
+
+* file -> member models (would useful for the c# language too)
+* method -> method will be allowed (local methods are supported by some
+languages)
+* Other constructs ('typedef') which can be supported in a language
+specific ambience. This is a strong point theoretical it would be
+possible that a language brings their own tree.
+
+----
+Other operations:
+If we want to have central support for code completion through a code
+completion database the DOM needs support for some operations.
+
+The problem with these operations is now to determine if an operation
+is:
+
+* Language specific
+* .NET centric
+* General.
+
+I don't think that .NET centric operations like IsMemberAcessible or the
+ResolveResults shouldn't be inside the central dom, because it can be re
+used accross some .NET language bindings and if we can make the life
+easier for .NET language bindings - why not. Other languages (if they
+fit in our DOM model) don't need to call/use these features.
+
+> * Each .NET language would implement its own DOM to support code
+> completion.
+
+It's already required, otherwise resolving won't work - there is no way
+around it. But retieving the .NET code completion information should
+work with our general DOM - otherwise it won't give any access to our
+code completion database. (But language bindings can bring their own
+code completion infrastructure if they want)
+
+> * Generalize a bit the parser service, so we can share some of
+> its
+> logic. We can keep the parser database as it is right now, but
+> it would be used only for .NET languages. Non .NET languages
+> would use its own DOM storage model. Maybe we wouldn't be able
+> to share much, but at least we could share the thread that
+> checks for changes and triggers parse operations or something
+> like that.
+>
+
+I wouldn't give access for custom (binary)database plugins, because the
+database exposes a model and other languages that don't fit into the
+model won't share the same logic/models. Our database uses a custom
+binary format and some tables to speed up some operations.
+
+I would just add support for binary serialization of custom DOM nodes.
+
+Bringing other models into our 'database' (which isn't a real database)
+would require that they write their own data storage and logic/models
+and not interfere with the current binary format (depending on what the
+plugins want to do). I think if they don't support our DOM model they
+should bring their own 'database' implementation. Another point is that
+the database is accessible only through DOM models - that'll make it
+even more unlikely that a language can put some plugin into it.
+
+Therefore I don't see a good reason for this (But this will depend on
+the user requests - I think some work can be done by the language
+implementors).
+
+btw. how about switching to SQLite for the parser database ?
+
+Regards
+Mike
+
+
+
+
+
+
+
+
+
+
+
+
+ Hi
+
+> This is more or less what non-.NET languages have to do currently:
+> Munge some stuff into the DOM for 1), custom implementation for 2), 3)
+> [which is refactoring also, isn't it?] is basically impossible.
+>
+> I'm on board with a unified, high-level DOM for populating
+> quickfinder, classpad, etc. [Zeroth bullet]
+> If this part is generalized enough to support native hierarchy
+> structures for various languages [currently missing], easily updatable
+> [currently exists], and easily and flexibly queryable from addin code
+> [currently missing], completion doesn't necessarily require its own
+> DOM, just some completion hooks similar to the existing ones. Things
+> like Goto Definition and Find References could operate at this level
+> as well.
+
+Some questions:
+1) How do you do code completion without an own DOM? I mean you need to
+find out which construct the user wants to complete.
+2) How do you do Find References without an own DOM? Don't you need to
+traverse the language specific DOM for it?
+3) Same for goto definition. (need to find out which construct etc.)
+
+> Similarly, there's no reason that the same overall storage mechanism
+> couldn't be used for .NET and non-.NET parse databases, as long as
+> hooks are exposed for specializing the storage process for specific
+> DOM implementations.
+>
+> I would LOVE to see enough assumptions neutralized that I could enable
+> Stetic or hook into existing refactoring operations for a specific,
+> arbitrary language.
+>
+
+Existing refactoring will move to the c# backend :/. I don't see a way
+to generalize them accross languages that don't share a specific 'down
+to expression level' DOM.
+(Otherwise than having a general refactoring API that would be:
+
+interaface IRefactoring {
+ void ExtractMethod ...
+ void RemoveTemporaryVariable ...
+ void InsertVariable ...
+ void RemoveBackingStore ...
+
+..
+}
+
+I think the general refactoring ends where the 'FindAllReferences'
+function ends :(. But I'm open for ideas here.
+
+Regards
+Mike
+
+
+
+
+
+ See comments inline.
+
+El ds 26 de 09 de 2009 a les 14:57 +0200, en/na Mike Krüger va escriure:
+> Hi
+>
+>
+> > The current situation is that if a non .NET language wants to provide
+> > support for 1), we are forcing the use of the MD DOM, even when it
+> > really doesn't fit. And there isn't much gain with that, because that
+> > language won't be really able to leverage 2) and 3). The type
+> > resolution
+> > rules of the MD DOM strictly follow the .NET semantics, so it won't be
+> > of much use for non .NET languages. Also, as a general purpose DOM for
+> > the language it won't be really useful because it won't allow
+> > expressing
+> > the particularities of the language.
+> >
+>
+> Type resolution isn't done in the MD DOM most resolving is done by the
+> backends.
+
+I know most of the work is done by the backends, but still the parser
+service does .NET specific resolution work which is useless to other
+languages. See ProjectDom.SearchType for example.
+
+> Our DOM it can be a bit better at genericity than the current one. But
+> we won't never get a 'general purpose' dom. It should just describe the
+> most basic language structures we likely encounter.
+>
+> > My ideas for improving the situation are the following:
+> >
+> > * Create a new DOM, which would be very high level, with just
+> > the
+> > information required to support 1). It would be a simple DOM,
+> > intended only for displaying information to the user, not for
+> > type resolution or other operations.
+>
+> I don't think a new DOM is required the current one represents the .NET
+> reflection API and that's a good sharing point across all .NET
+> languages.
+
+That's OK for .NET languages, but we are talking about improving support
+for non-.NET languages.
+
+> I would change the current one a bit so that it's more mighty
+> than the reflection API. Some languages that are a bit different can be
+> wrapped to .NET classes by their compiler and it would be nice if we can
+> support those languages.
+>
+> Type resolution is done in the language backends. It does have some
+> operations but these are common accross all languages that use .NET
+> (like give all types in a namespace). When building a non .NET binding
+> there is no need to use these .NET specific features.
+
+Also, there is no need to be unnecessarily constrained by them. For
+example, to show the current method in the members combo box, the
+following interface would be enough:
+
+interface INewMethod
+{
+ string GetDescription (SomeContext ctx);
+ string Icon { get; }
+ Region BodyRegion { get; }
+}
+
+That would be very easy to implement by a non .net language, and it is
+not constraining the implementation in any way. The current IMethod
+interface constraints the implementation to use a specific set of
+modifiers, implement stuff like TypeParameters which won't be used, and
+force the use of a parameters collection which also have .net specific
+modifiers. And all this for just being able to build a string describing
+a method.
+
+My idea of new DOM is to create a set of interfaces which can be
+implemented by non-.net language DOMs. Those interfaces would provide
+just the enough information that usually has to be shown to the user.
+They would be very generic, and could have a tree-like structure like
+the one you are proposing. But the main idea is that those interfaces
+are not meant to be used as part of any resolution process, or
+refactoring, or any other operation that requires rich information about
+the types. We already have language-specific DOMs to do that. Instead,
+these would be used only for displaying information to the user.
+
+The current DOM would also implement those interfaces, so .NET languages
+(for which the current DOM works great) wouldn't need to implement them.
+
+>
+> My suggestion for making the DOM more general:
+> Doing anything with a tree node as base and have some types of tree
+> nodes (file/namespace/class/method etc). All tree nodes have:
+>
+> * Link to their parent
+> * Know their childrin
+> * Have connections to their siblings
+>
+> Accessing the children/parents is the same for all these DOM nodes. Some
+> operations on the current DOM have become a bit too difficult and they
+> would be easier with a general tree as underlying data structure.
+>
+> It has limits to build a general DOM - I would draw the line
+> between .NET/non .NET language. The output done by the ambiences limits
+> a bit the flexibility of the DOM. But I think that ambiences are a good
+> idea.
+>
+> Some examples .NET specific things that we use but will clash with
+> non .NET languages and there isn't anything we can do about:
+>
+> * Method paramater modifiers out/ref/params - no 'per name' modifier
+> * General modifiers (public/protected etc.) - no c++ 'inline' modifier
+> or others
+> * Just file -> namespace -> type -> member model - no 'pascal units' or
+> declaration/implementation models (#include) or any other form of
+> representation
+> * Just the .NET constructs (no 'typedef' for example).
+>
+> ... and maybe more
+>
+> Things we currently support but .NET doesn't:
+>
+> * Multiple inheritance
+>
+> Things we can support with some DOM refactorings but currently we don't:
+>
+> * file -> member models (would useful for the c# language too)
+> * method -> method will be allowed (local methods are supported by some
+> languages)
+> * Other constructs ('typedef') which can be supported in a language
+> specific ambience. This is a strong point theoretical it would be
+> possible that a language brings their own tree.
+>
+> ----
+> Other operations:
+> If we want to have central support for code completion through a code
+> completion database the DOM needs support for some operations.
+>
+> The problem with these operations is now to determine if an operation
+> is:
+>
+> * Language specific
+> * .NET centric
+> * General.
+>
+> I don't think that .NET centric operations like IsMemberAcessible or the
+> ResolveResults shouldn't be inside the central dom, because it can be re
+> used accross some .NET language bindings and if we can make the life
+> easier for .NET language bindings - why not. Other languages (if they
+> fit in our DOM model) don't need to call/use these features.
+
+If we can generalize a bit the DOM, so some non-.NET languages can reuse
+it, that's OK to me. But reusing the full DOM (with all its features and
+constraints) should be optional.
+
+
+> > * Each .NET language would implement its own DOM to support code
+> > completion.
+>
+> It's already required, otherwise resolving won't work - there is no way
+> around it. But retieving the .NET code completion information should
+> work with our general DOM - otherwise it won't give any access to our
+> code completion database. (But language bindings can bring their own
+> code completion infrastructure if they want)
+
+All that is OK to me.
+
+>
+> > * Generalize a bit the parser service, so we can share some of
+> > its
+> > logic. We can keep the parser database as it is right now, but
+> > it would be used only for .NET languages. Non .NET languages
+> > would use its own DOM storage model. Maybe we wouldn't be able
+> > to share much, but at least we could share the thread that
+> > checks for changes and triggers parse operations or something
+> > like that.
+> >
+>
+> I wouldn't give access for custom (binary)database plugins, because the
+> database exposes a model and other languages that don't fit into the
+> model won't share the same logic/models. Our database uses a custom
+> binary format and some tables to speed up some operations.
+
+That's not what I'm proposing.
+
+>
+> I would just add support for binary serialization of custom DOM nodes.
+>
+> Bringing other models into our 'database' (which isn't a real database)
+> would require that they write their own data storage and logic/models
+> and not interfere with the current binary format (depending on what the
+> plugins want to do). I think if they don't support our DOM model they
+> should bring their own 'database' implementation.
+
+And that's just what I'm proposing. Notice that I talked about
+generalizing the parser *service*, not the parser *database*. The parser
+service is in charge of driving the parse operations of project files
+and referenced assemblies. It can be generalized a bit to allow plugging
+other parsing systems on it, with their own database systems.
+
+> Another point is that
+> the database is accessible only through DOM models - that'll make it
+> even more unlikely that a language can put some plugin into it.
+>
+> Therefore I don't see a good reason for this (But this will depend on
+> the user requests - I think some work can be done by the language
+> implementors).
+>
+> btw. how about switching to SQLite for the parser database ?
+
+If a SQLite based database provides equal or faster access times, with a
+reasonable memory use, we can consider it.
+
+Lluis.
+
+
+
+
+
+
+
+
+
+
+
+
+ Having done a SQLite database for PyBinding, my primary concern is migration +of schemas and upgrading on the fly. It's largely a PITA (however perhaps +the ParserDatabase is as well). + +-- Christian + +On Mon, Sep 28, 2009 at 4:47 AM, Lluis Sanchez Gual <lluis at novell.com>wrote: + +> See comments inline. +> +> El ds 26 de 09 de 2009 a les 14:57 +0200, en/na Mike Krüger va escriure: +> > Hi +> > +> > +> > > The current situation is that if a non .NET language wants to provide +> > > support for 1), we are forcing the use of the MD DOM, even when it +> > > really doesn't fit. And there isn't much gain with that, because that +> > > language won't be really able to leverage 2) and 3). The type +> > > resolution +> > > rules of the MD DOM strictly follow the .NET semantics, so it won't be +> > > of much use for non .NET languages. Also, as a general purpose DOM for +> > > the language it won't be really useful because it won't allow +> > > expressing +> > > the particularities of the language. +> > > +> > +> > Type resolution isn't done in the MD DOM most resolving is done by the +> > backends. +> +> I know most of the work is done by the backends, but still the parser +> service does .NET specific resolution work which is useless to other +> languages. See ProjectDom.SearchType for example. +> +> > Our DOM it can be a bit better at genericity than the current one. But +> > we won't never get a 'general purpose' dom. It should just describe the +> > most basic language structures we likely encounter. +> > +> > > My ideas for improving the situation are the following: +> > > +> > > * Create a new DOM, which would be very high level, with just +> > > the +> > > information required to support 1). It would be a simple DOM, +> > > intended only for displaying information to the user, not for +> > > type resolution or other operations. +> > +> > I don't think a new DOM is required the current one represents the .NET +> > reflection API and that's a good sharing point across all .NET +> > languages. +> +> That's OK for .NET languages, but we are talking about improving support +> for non-.NET languages. +> +> > I would change the current one a bit so that it's more mighty +> > than the reflection API. Some languages that are a bit different can be +> > wrapped to .NET classes by their compiler and it would be nice if we can +> > support those languages. +> > +> > Type resolution is done in the language backends. It does have some +> > operations but these are common accross all languages that use .NET +> > (like give all types in a namespace). When building a non .NET binding +> > there is no need to use these .NET specific features. +> +> Also, there is no need to be unnecessarily constrained by them. For +> example, to show the current method in the members combo box, the +> following interface would be enough: +> +> interface INewMethod +> { +> string GetDescription (SomeContext ctx); +> string Icon { get; } +> Region BodyRegion { get; } +> } +> +> That would be very easy to implement by a non .net language, and it is +> not constraining the implementation in any way. The current IMethod +> interface constraints the implementation to use a specific set of +> modifiers, implement stuff like TypeParameters which won't be used, and +> force the use of a parameters collection which also have .net specific +> modifiers. And all this for just being able to build a string describing +> a method. +> +> My idea of new DOM is to create a set of interfaces which can be +> implemented by non-.net language DOMs. Those interfaces would provide +> just the enough information that usually has to be shown to the user. +> They would be very generic, and could have a tree-like structure like +> the one you are proposing. But the main idea is that those interfaces +> are not meant to be used as part of any resolution process, or +> refactoring, or any other operation that requires rich information about +> the types. We already have language-specific DOMs to do that. Instead, +> these would be used only for displaying information to the user. +> +> The current DOM would also implement those interfaces, so .NET languages +> (for which the current DOM works great) wouldn't need to implement them. +> +> > +> > My suggestion for making the DOM more general: +> > Doing anything with a tree node as base and have some types of tree +> > nodes (file/namespace/class/method etc). All tree nodes have: +> > +> > * Link to their parent +> > * Know their childrin +> > * Have connections to their siblings +> > +> > Accessing the children/parents is the same for all these DOM nodes. Some +> > operations on the current DOM have become a bit too difficult and they +> > would be easier with a general tree as underlying data structure. +> > +> > It has limits to build a general DOM - I would draw the line +> > between .NET/non .NET language. The output done by the ambiences limits +> > a bit the flexibility of the DOM. But I think that ambiences are a good +> > idea. +> > +> > Some examples .NET specific things that we use but will clash with +> > non .NET languages and there isn't anything we can do about: +> > +> > * Method paramater modifiers out/ref/params - no 'per name' modifier +> > * General modifiers (public/protected etc.) - no c++ 'inline' modifier +> > or others +> > * Just file -> namespace -> type -> member model - no 'pascal units' or +> > declaration/implementation models (#include) or any other form of +> > representation +> > * Just the .NET constructs (no 'typedef' for example). +> > +> > ... and maybe more +> > +> > Things we currently support but .NET doesn't: +> > +> > * Multiple inheritance +> > +> > Things we can support with some DOM refactorings but currently we don't: +> > +> > * file -> member models (would useful for the c# language too) +> > * method -> method will be allowed (local methods are supported by some +> > languages) +> > * Other constructs ('typedef') which can be supported in a language +> > specific ambience. This is a strong point theoretical it would be +> > possible that a language brings their own tree. +> > +> > ---- +> > Other operations: +> > If we want to have central support for code completion through a code +> > completion database the DOM needs support for some operations. +> > +> > The problem with these operations is now to determine if an operation +> > is: +> > +> > * Language specific +> > * .NET centric +> > * General. +> > +> > I don't think that .NET centric operations like IsMemberAcessible or the +> > ResolveResults shouldn't be inside the central dom, because it can be re +> > used accross some .NET language bindings and if we can make the life +> > easier for .NET language bindings - why not. Other languages (if they +> > fit in our DOM model) don't need to call/use these features. +> +> If we can generalize a bit the DOM, so some non-.NET languages can reuse +> it, that's OK to me. But reusing the full DOM (with all its features and +> constraints) should be optional. +> +> +> > > * Each .NET language would implement its own DOM to support code +> > > completion. +> > +> > It's already required, otherwise resolving won't work - there is no way +> > around it. But retieving the .NET code completion information should +> > work with our general DOM - otherwise it won't give any access to our +> > code completion database. (But language bindings can bring their own +> > code completion infrastructure if they want) +> +> All that is OK to me. +> +> > +> > > * Generalize a bit the parser service, so we can share some of +> > > its +> > > logic. We can keep the parser database as it is right now, but +> > > it would be used only for .NET languages. Non .NET languages +> > > would use its own DOM storage model. Maybe we wouldn't be able +> > > to share much, but at least we could share the thread that +> > > checks for changes and triggers parse operations or something +> > > like that. +> > > +> > +> > I wouldn't give access for custom (binary)database plugins, because the +> > database exposes a model and other languages that don't fit into the +> > model won't share the same logic/models. Our database uses a custom +> > binary format and some tables to speed up some operations. +> +> That's not what I'm proposing. +> +> > +> > I would just add support for binary serialization of custom DOM nodes. +> > +> > Bringing other models into our 'database' (which isn't a real database) +> > would require that they write their own data storage and logic/models +> > and not interfere with the current binary format (depending on what the +> > plugins want to do). I think if they don't support our DOM model they +> > should bring their own 'database' implementation. +> +> And that's just what I'm proposing. Notice that I talked about +> generalizing the parser *service*, not the parser *database*. The parser +> service is in charge of driving the parse operations of project files +> and referenced assemblies. It can be generalized a bit to allow plugging +> other parsing systems on it, with their own database systems. +> +> > Another point is that +> > the database is accessible only through DOM models - that'll make it +> > even more unlikely that a language can put some plugin into it. +> > +> > Therefore I don't see a good reason for this (But this will depend on +> > the user requests - I think some work can be done by the language +> > implementors). +> > +> > btw. how about switching to SQLite for the parser database ? +> +> If a SQLite based database provides equal or faster access times, with a +> reasonable memory use, we can consider it. +> +> Lluis. +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090928/a2eee449/attachment-0001.html ++ + + + + + + + + +
Hi
+
+> That's OK for .NET languages, but we are talking about improving support
+> for non-.NET languages.
+>
+
+For the DOM - no not really. I don't think that we can support non .NET
+languages at the level we're supporting .NET languages. My goal would be
+to improve .NET languages that don't fit into the C# model (like pascal
+for example) and maybe improving the ability for plugging in non .NET
+languages.
+
+What are the language binding implementors saying on this ?
+
+> Also, there is no need to be unnecessarily constrained by them. For
+> example, to show the current method in the members combo box, the
+> following interface would be enough:
+>
+> interface INewMethod
+> {
+> string GetDescription (SomeContext ctx);
+> string Icon { get; }
+> Region BodyRegion { get; }
+> }
+>
+>
+> That would be very easy to implement by a non .net language, and it is
+> not constraining the implementation in any way. The current IMethod
+> interface constraints the implementation to use a specific set of
+> modifiers, implement stuff like TypeParameters which won't be used, and
+> force the use of a parameters collection which also have .net specific
+> modifiers. And all this for just being able to build a string describing
+> a method.
+>
+
+Ok then each .NET language vb/c#/boo etc. needs an own INewMethod
+implementation (and full monodevelop dom). To make it more worse to
+which tree should we convert the assemblies to ? Then each specific
+language needs to be able to convert cecil to their dom. (otherwise we
+won't get descriptions for the reflection objects). And to make it even
+more worse a solution that contains different .NET languages needs to
+share their DOMs as well. It would be very strange if vb.net syntax
+would pop up in a c# project that uses something from a vb.net project.
+
+> My idea of new DOM is to create a set of interfaces which can be
+> implemented by non-.net language DOMs. Those interfaces would provide
+> just the enough information that usually has to be shown to the user.
+> They would be very generic, and could have a tree-like structure like
+> the one you are proposing. But the main idea is that those interfaces
+> are not meant to be used as part of any resolution process, or
+> refactoring, or any other operation that requires rich information about
+> the types. We already have language-specific DOMs to do that. Instead,
+> these would be used only for displaying information to the user.
+>
+
+The user wants to display modifiers and stuff that is in ambience, some
+languages have: type varName others tend to use varName : type.
+Currently I separated the display from the data (ambiences) therefore
+it's possible to have the language specfic display everywhere (even from
+reflection generated data).
+With the change above we're going a step back, because we make it more
+difficult for .NET languages - for almost no gain. Theoretically each
+component that displays some other sort of a language may need changes,
+if a language is really, really far away of c#. At the end we're going
+to let each language binding bring their own class browser, code
+completion, code completion db, quick navigator etc. only having the
+text editor/project system in common.
+
+Regards
+Mike
+
+
+
+
+
+
+
+
+
+
+
+ > Some questions:
+> 1) How do you do code completion without an own DOM? I mean you need to
+> find out which construct the user wants to complete.
+
+Precisely. However, if we already have all the information to populate
+an entire symbol tree in the classpad,
+why should that be replicated elsewhere for completion?
+
+> 2) How do you do Find References without an own DOM? Don't you need to
+> traverse the language specific DOM for it?
+> 3) Same for goto definition. (need to find out which construct etc.)
+
+Maybe I'm misunderstanding the proposal. In my mind, any given DOM
+schema would be language-specific, but the means of populating,
+storing, and querying it would be schema-apathetic.
+
+> Existing refactoring will move to the c# backend :/. I don't see a way
+> to generalize them accross languages that don't share a specific 'down
+> to expression level' DOM.
+> (Otherwise than having a general refactoring API that would be:
+>
+> interaface IRefactoring {
+> void ExtractMethod ...
+> void RemoveTemporaryVariable ...
+> void InsertVariable ...
+> void RemoveBackingStore ...
+>
+> ..
+> }
+>
+> I think the general refactoring ends where the 'FindAllReferences'
+> function ends :(. But I'm open for ideas here.
+
+Yeah, the "Extract Method" types of refactorings would have to be
+implemented for each language, where appropriate
+And I would love to see an extensible refactoring framework that
+facilitates this.
+
+On the other hand, "Goto Definition" and "Find References" don't
+require any more information than completion.
+
+
+--
+http://homes.eff.org/~barlow/EconomyOfIdeas.html
+http://www.dreamsongs.com/MobSoftware.html
+http://www.gnu.org/philosophy/shouldbefree.html
+
+
+
+
+ > For the DOM - no not really. I don't think that we can support non .NET +> languages at the level we're supporting .NET languages. My goal would be +> to improve .NET languages that don't fit into the C# model (like pascal +> for example) and maybe improving the ability for plugging in non .NET +> languages. +> +> What are the language binding implementors saying on this ? + +Clearly, C# is going to continue to be the best-supported language - +that's fine. +However, with the increasing popularity of MD as an IDE for non-.NET +languages and mixed-language projects, it would be great if those +languages 1) didn't have to reinvent the same functionality over and +over, and 2) could hook into some of the more advanced MD features +that make it such a great environment for C#. + +> At the end we're going +> to let each language binding bring their own class browser, code +> completion, code completion db, quick navigator etc. only having the +> text editor/project system in common. + +That's already the situation for non-.NET languages. + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + + + + + + +
El dl 28 de 09 de 2009 a les 17:43 +0200, en/na Mike Krüger va escriure:
+> Hi
+>
+> > That's OK for .NET languages, but we are talking about improving support
+> > for non-.NET languages.
+> >
+>
+> For the DOM - no not really. I don't think that we can support non .NET
+> languages at the level we're supporting .NET languages.
+> My goal would be
+> to improve .NET languages that don't fit into the C# model (like pascal
+> for example) and maybe improving the ability for plugging in non .NET
+> languages.
+>
+> What are the language binding implementors saying on this ?
+>
+> > Also, there is no need to be unnecessarily constrained by them. For
+> > example, to show the current method in the members combo box, the
+> > following interface would be enough:
+> >
+> > interface INewMethod
+> > {
+> > string GetDescription (SomeContext ctx);
+> > string Icon { get; }
+> > Region BodyRegion { get; }
+> > }
+> >
+> >
+> > That would be very easy to implement by a non .net language, and it is
+> > not constraining the implementation in any way. The current IMethod
+> > interface constraints the implementation to use a specific set of
+> > modifiers, implement stuff like TypeParameters which won't be used, and
+> > force the use of a parameters collection which also have .net specific
+> > modifiers. And all this for just being able to build a string describing
+> > a method.
+> >
+>
+> Ok then each .NET language vb/c#/boo etc. needs an own INewMethod
+> implementation (and full monodevelop dom).
+
+No, you got it wrong. From my previous mail:
+
+"The current DOM would also implement those interfaces, so .NET
+languages (for which the current DOM works great) wouldn't need to
+implement them."
+
+For example (and this is just an incomplete example), DomField could be
+implemented like this:
+
+class DomField: IMember, INewField
+{
+ public string GetDescription (SomeContext ctx)
+ {
+ return ctx.Ambience.GetString (this, someFlags);
+ }
+ ...
+}
+
+C#, VB, boo and all .net languages would keep using the DOM we have
+right now, which would implement INewField, so they don't have to be
+changed.
+
+On the other hand, the C++ binding could have this implementation:
+
+class CppField: SomeBaseClass, INewField
+{
+ public string GetDescription (SomeContext ctx)
+ {
+ return cppModifiers + " " + type + " " + name;
+ }
+ ...
+}
+
+The C++ DOM can be arbitrarily complex and can have its own storage
+system, but by implementing INewField, the IDE would be able to display
+data about it. In this case it is not necessary to separate data from
+display data, because the DOM is specific to C++, so it will always use
+C++ syntax.
+
+The members combo, the document outline, the class pad, the go-to-member
+dialog and the code completion window can all be impemented based on
+INew* interfaces which are more simple and have less implementation
+constraints. .NET bindings would just feed those GUI components using
+the existing DOM, which would implement INew*. Non .NET bindings would
+just provide any DOM implementing INew*.
+
+Lluis.
+
+
+
+
+
+
+
+
+
+
+ Hi
+
+> > Some questions:
+> > 1) How do you do code completion without an own DOM? I mean you need to
+> > find out which construct the user wants to complete.
+>
+> Precisely. However, if we already have all the information to populate
+> an entire symbol tree in the classpad,
+> why should that be replicated elsewhere for completion?
+>
+
+Ok how do you populate
+void MyMethod ()
+{
+ Foo x;
+ x.Bar. <- complete
+}
+
+with the classpad and without a language specific dom.
+
+> On the other hand, "Goto Definition" and "Find References" don't
+> require any more information than completion.
+>
+
+See above, you need something that finds out what text means.
+
+Regards
+Mike
+
+
+
+
+
+ >> > Some questions:
+>> > 1) How do you do code completion without an own DOM? I mean you need to
+>> > find out which construct the user wants to complete.
+>>
+>> Precisely. However, if we already have all the information to populate
+>> an entire symbol tree in the classpad,
+>> why should that be replicated elsewhere for completion?
+>>
+> Ok how do you populate
+> void MyMethod ()
+> {
+> Foo x;
+> x.Bar. <- complete
+> }
+>
+> with the classpad and without a language specific dom.
+
+Right. You need code that says, "Where am I, and what can I see from
+here?" - I'm not arguing that.
+
+--
+http://homes.eff.org/~barlow/EconomyOfIdeas.html
+http://www.dreamsongs.com/MobSoftware.html
+http://www.gnu.org/philosophy/shouldbefree.html
+
+
+
+
+ Hi
+
+> "The current DOM would also implement those interfaces, so .NET
+> languages (for which the current DOM works great) wouldn't need to
+> implement them."
+>
+> For example (and this is just an incomplete example), DomField could be
+> implemented like this:
+>
+> class DomField: IMember, INewField
+> {
+> public string GetDescription (SomeContext ctx)
+> {
+> return ctx.Ambience.GetString (this, someFlags);
+> }
+> ...
+> }
+>
+> C#, VB, boo and all .net languages would keep using the DOM we have
+> right now, which would implement INewField, so they don't have to be
+> changed.
+>
+>
+> On the other hand, the C++ binding could have this implementation:
+>
+> class CppField: SomeBaseClass, INewField
+> {
+> public string GetDescription (SomeContext ctx)
+> {
+> return cppModifiers + " " + type + " " + name;
+> }
+> ...
+> }
+>
+> The C++ DOM can be arbitrarily complex and can have its own storage
+> system, but by implementing INewField, the IDE would be able to display
+> data about it. In this case it is not necessary to separate data from
+> display data, because the DOM is specific to C++, so it will always use
+> C++ syntax.
+>
+> The members combo, the document outline, the class pad, the go-to-member
+> dialog and the code completion window can all be impemented based on
+> INew* interfaces which are more simple and have less implementation
+> constraints. .NET bindings would just feed those GUI components using
+> the existing DOM, which would implement INew*. Non .NET bindings would
+> just provide any DOM implementing INew*.
+>
+
+Ok and in the end we would've a .NET infrastructure that works with .NET
+classes and a 'do it on your own' infrastructure.
+
+If you say that the document outline/class pad/go to member dialog/quick
+member navigation can work with the INewField etc. interfaces it's
+simply wrong, because they're the ones that already define/use a .NET
+specfic system.
+
+Why do you think that there are always types and members, methods,
+fields etc. - in fact every component of monodevelop would need a custom
+entry point where a filler class can fill the contents. Builds
+tree/context menu for the class browser, does add 'columns' to the quick
+navigation pane etc. - at the end almost any component that shows the
+DOM needs to be rewritten/extended to make it work. I don't know if
+anyone will do such a deep integration.
+
+What you're proposing above can already be done now, by adding a c+
+ambience that handles a c++ tree extending the current one.
+
+class CppAmbience : Ambience
+{
+ public override string GetString (IField field, flags)
+ {
+ CppField cppfield = (CppField)field;
+ return cppfield.Modifiers + " " + cppfield.Type + " " + cppfield.Name;
+ }
+}
+(yes this ambience won't work on a non c++ tree, but it would be
+possible to fill for example the code completion window or quick class
+browser with c++ objects and a c++ ambience).
+
+I will think about it a bit more when I look/work at the source code.
+btw. we could need input for people doing a language binding here :)
+
+Mike
+
+
+
+
+
+
+
+
+ El ds 26 de 09 de 2009 a les 15:03 +0200, en/na Mike Krüger va escriure: +> Hi +> +> > This is more or less what non-.NET languages have to do currently: +> > Munge some stuff into the DOM for 1), custom implementation for 2), 3) +> > [which is refactoring also, isn't it?] is basically impossible. +> > +> > I'm on board with a unified, high-level DOM for populating +> > quickfinder, classpad, etc. [Zeroth bullet] +> > If this part is generalized enough to support native hierarchy +> > structures for various languages [currently missing], easily updatable +> > [currently exists], and easily and flexibly queryable from addin code +> > [currently missing], completion doesn't necessarily require its own +> > DOM, just some completion hooks similar to the existing ones. Things +> > like Goto Definition and Find References could operate at this level +> > as well. +> +> Some questions: +> 1) How do you do code completion without an own DOM? I mean you need to +> find out which construct the user wants to complete. +> 2) How do you do Find References without an own DOM? Don't you need to +> traverse the language specific DOM for it? +> 3) Same for goto definition. (need to find out which construct etc.) + +I think you are misunderstanding Levi. I think he means that the code +completion window (the GUI component) doesn't need its (its==code +completion window) own particular DOM, and that a set of completion +hooks should suffice. If I understand it correctly, he is talking about +displaying the information, not about generating it. + +Lluis. + + ++ + + +
> I think you are misunderstanding Levi. I think he means that the code +> completion window (the GUI component) doesn't need its (its==code +> completion window) own particular DOM, and that a set of completion +> hooks should suffice. If I understand it correctly, he is talking about +> displaying the information, not about generating it. + +Yes, Lluis is correct. I apologize for not having communicated this +more clearly. + +-- +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.dreamsongs.com/MobSoftware.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + +
El dl 28 de 09 de 2009 a les 19:27 +0200, en/na Mike Krüger va escriure:
+> Hi
+>
+> > "The current DOM would also implement those interfaces, so .NET
+> > languages (for which the current DOM works great) wouldn't need to
+> > implement them."
+> >
+> > For example (and this is just an incomplete example), DomField could be
+> > implemented like this:
+> >
+> > class DomField: IMember, INewField
+> > {
+> > public string GetDescription (SomeContext ctx)
+> > {
+> > return ctx.Ambience.GetString (this, someFlags);
+> > }
+> > ...
+> > }
+> >
+> > C#, VB, boo and all .net languages would keep using the DOM we have
+> > right now, which would implement INewField, so they don't have to be
+> > changed.
+> >
+> >
+> > On the other hand, the C++ binding could have this implementation:
+> >
+> > class CppField: SomeBaseClass, INewField
+> > {
+> > public string GetDescription (SomeContext ctx)
+> > {
+> > return cppModifiers + " " + type + " " + name;
+> > }
+> > ...
+> > }
+> >
+> > The C++ DOM can be arbitrarily complex and can have its own storage
+> > system, but by implementing INewField, the IDE would be able to display
+> > data about it. In this case it is not necessary to separate data from
+> > display data, because the DOM is specific to C++, so it will always use
+> > C++ syntax.
+> >
+> > The members combo, the document outline, the class pad, the go-to-member
+> > dialog and the code completion window can all be impemented based on
+> > INew* interfaces which are more simple and have less implementation
+> > constraints. .NET bindings would just feed those GUI components using
+> > the existing DOM, which would implement INew*. Non .NET bindings would
+> > just provide any DOM implementing INew*.
+> >
+>
+> Ok and in the end we would've a .NET infrastructure that works with .NET
+> classes and a 'do it on your own' infrastructure.
+
+To some extent, yes. See the PyBinding case. It has its own
+infrastructure for parsing, storing and querying parse information,
+resolving and generating completion data. It doesn't need the .NET
+infrastructure, which doesn't really fit.
+
+>
+> If you say that the document outline/class pad/go to member dialog/quick
+> member navigation can work with the INewField etc. interfaces it's
+> simply wrong, because they're the ones that already define/use a .NET
+> specfic system.
+
+Why is it specific to .NET? I'm missing something here. The document
+outline shows a hierarchy of items. It is so generic that it even works
+for XML documents. The class pad is also just a hierarchy of items (for
+the whole project in this case). The goto type dialog shows a list of
+types in the solution.
+
+The quick member navigation shows types in the first combo, and members
+of the types in the second one. It can easily be redefined to showing
+'first level items of the file' in the first combo, and 'children of the
+active first level item' in the second combo. Or something like that.
+
+I don't see anything .NET specific in all this.
+
+>
+> Why do you think that there are always types and members, methods,
+> fields etc. - in fact every component of monodevelop would need a custom
+> entry point where a filler class can fill the contents. Builds
+> tree/context menu for the class browser, does add 'columns' to the quick
+> navigation pane etc. - at the end almost any component that shows the
+> DOM needs to be rewritten/extended to make it work. I don't know if
+> anyone will do such a deep integration.
+
+That's the point of the INew* set of interfaces. The MD components will
+extract the required information from those interfaces, so no deep
+integration will be required.
+
+>
+> What you're proposing above can already be done now, by adding a c+
+> ambience that handles a c++ tree extending the current one.
+>
+> class CppAmbience : Ambience
+> {
+> public override string GetString (IField field, flags)
+> {
+> CppField cppfield = (CppField)field;
+> return cppfield.Modifiers + " " + cppfield.Type + " " + cppfield.Name;
+> }
+> }
+> (yes this ambience won't work on a non c++ tree, but it would be
+> possible to fill for example the code completion window or quick class
+> browser with c++ objects and a c++ ambience).
+
+Yes, that's currently possible (with some tweaks). But it means that the
+language has to implement all the DOM interfaces: IField, IMethod,
+IType, etc, which are full of .NET specific stuff. Yes, you can just
+throw NotSupportedException of all .NET specific methods and properties,
+but that's just unnecessary bloat. If anything, it would be better to
+have:
+
+class CppAmbience : Ambience
+{
+ public override string GetString (INode field, flags)
+ {
+ CppField cppfield = field as CppField;
+ if (cppfield != null)
+ return cppfield.Modifiers + " " + cppfield.Type + " " + cppfield.Name;
+ ...
+ }
+}
+
+That would work, although I don't see the benefit of separating data
+from display data in non .NET languages, since there will be a 1 to 1
+correspondence between data and display data.
+
+Lluis.
+
+
+
+
+
+
+
+ Hi + +> > I think you are misunderstanding Levi. I think he means that the code +> > completion window (the GUI component) doesn't need its (its==code +> > completion window) own particular DOM, and that a set of completion +> > hooks should suffice. If I understand it correctly, he is talking about +> > displaying the information, not about generating it. +> +> Yes, Lluis is correct. I apologize for not having communicated this +> more clearly. +> + +Sad :/. I hoped that there as a more magically way of doing this :) +Resolving an expression can be quite painful. + +Regards +Mike + ++ + +
Hi
+
+> Why is it specific to .NET? I'm missing something here. The document
+> outline shows a hierarchy of items. It is so generic that it even works
+> for XML documents. The class pad is also just a hierarchy of items (for
+> the whole project in this case). The goto type dialog shows a list of
+> types in the solution.
+>
+> The quick member navigation shows types in the first combo, and members
+> of the types in the second one. It can easily be redefined to showing
+> 'first level items of the file' in the first combo, and 'children of the
+> active first level item' in the second combo. Or something like that.
+>
+> I don't see anything .NET specific in all this.
+>
+
+Ok I've looked a bit at the source code.
+
+Class pad:
+
+ClassNodeBuilder, FieldNodeBuilder, MethodNodeBuilder,
+NamespaceNodeBuilder etc.
+
+But it can be extended using the addin tree - but the things we have are
+very specific. For example: I've took a look at the MethodNodeBuilder -
+it doesn't build child nodes (yes there are languages with methods in
+methods). Taking this example it wouldn't even work if we had a new
+INewMethod interface for such a language to be build with the class pad,
+because the MethodNodeBuilder that takes care of building these objects
+would prevent building child nodes.
+
+Quick Member navigation - it's not so easy to set the rules:
+
+'showing first level items of the file' means:
++ Showing only the namespaces -> no containing types (they're first
+level, and will be part of the DOM as nodes)
++ Don't show inner types (they're second level at best)
+
+'children of the active first level item' means:
++ Show the current inner type (should be in the type selector).
++ Show the current statement, if the DOM is extended and more specific
+than the monodevelop DOM.
+
+Then there are 3 navigators: types/members/regions. That doesn't make
+sense for some cases (think of C, there are no members/regions).
+
+Document outline:
+The document outline that shows the hierarchy requires that
+IOutlinedDocument is implemented. A XML and MD DOM get different
+implementations of this interface. It's very general:
+
+public interface IOutlinedDocument
+{
+ Gtk.Widget GetOutlineWidget ();
+ void ReleaseOutlineWidget ();
+}
+
+I would say that's one of the best components we have for extensibility.
+Because it doesn't 'lock' into a specific model. The downside is that it
+doesn't provide much to re-use. But I think we should have this sort of
+extensibility for all components and let the non-.NET languages a way to
+work around all pre defined structures and replace the components with
+an own way. This ensures that we can't make a mistake.
+
+btw. another thing: All pads/output function currently build on ambience
+flags - but for other languages there may be different sets of flags
+required for displaying the information at that point.
+
+> Yes, that's currently possible (with some tweaks). But it means that the
+> language has to implement all the DOM interfaces: IField, IMethod,
+> IType, etc, which are full of .NET specific stuff. Yes, you can just
+> throw NotSupportedException of all .NET specific methods and properties,
+> but that's just unnecessary bloat. If anything, it would be better to
+> have:
+
+We've classes that implement the interfaces, no .NET specific
+implementation is required. But the other thing is that a new languages
+now would ALWAYS require to implement all DOM interfaces that are full
+of .NET specific stuff. (ok could use the same base class)
+You've still not told how to display a VB output, Boo output and c#
+output of a reflection source when putting the output code inside the
+DOM objects. I think that's not easily possible.
+
+MD side:
+Code Completion DB -> Data (in which DOM format)
+
+Language binding:
+Own Dom info + wants to display code completion data from the code
+completion db
+
+> That would work, although I don't see the benefit of separating data
+> from display data in non .NET languages, since there will be a 1 to 1
+> correspondence between data and display data.
+>
+
+The benefit is that the non .NET languages can communicate with
+MonoDevelop components to produce output. And that the .NET unspecific
+types/members etc. could be implemented today.
+Sometimes the output is altered (adding markup to names etc.) by
+consuming code. Outputting the text from the DOM isn't very easy and
+just a GetString () doesn't cut the edge. We've to display this
+information in various tooltips/lists with different options (short name
+vs. long name). Therefore the GetString () needs to get the same
+parameters as ambiences.
+
+I tend to make the monodevelop DOM stuff .NET dependent in the type
+model, generalize the object model so that other .NET languages can be
+supported that are more far from C#/VB.NET and have a way to do
+something like the IOutlinedDocument for each component. I don't want to
+make the life harder for .NET language implementors when the non .NET
+language implementors get little to no gain (See above - they need to
+implement their own widgets/infrastructure - regardless of what we try,
+more worse they can run into dead ends when trying to re-use the
+monodevelop DOM - see the class output pad method example).
+
+Regards
+Mike
+
+
+
+
+
+ El dt 29 de 09 de 2009 a les 00:09 +0200, en/na Mike Krüger va escriure:
+> Hi
+>
+> > Why is it specific to .NET? I'm missing something here. The document
+> > outline shows a hierarchy of items. It is so generic that it even works
+> > for XML documents. The class pad is also just a hierarchy of items (for
+> > the whole project in this case). The goto type dialog shows a list of
+> > types in the solution.
+> >
+> > The quick member navigation shows types in the first combo, and members
+> > of the types in the second one. It can easily be redefined to showing
+> > 'first level items of the file' in the first combo, and 'children of the
+> > active first level item' in the second combo. Or something like that.
+> >
+> > I don't see anything .NET specific in all this.
+> >
+>
+> Ok I've looked a bit at the source code.
+>
+> Class pad:
+>
+> ClassNodeBuilder, FieldNodeBuilder, MethodNodeBuilder,
+> NamespaceNodeBuilder etc.
+>
+> But it can be extended using the addin tree - but the things we have are
+> very specific. For example: I've took a look at the MethodNodeBuilder -
+> it doesn't build child nodes (yes there are languages with methods in
+> methods). Taking this example it wouldn't even work if we had a new
+> INewMethod interface for such a language to be build with the class pad,
+> because the MethodNodeBuilder that takes care of building these objects
+> would prevent building child nodes.
+
+I feel there is some misunderstanding here. If we introduce a new set of
+INew* interfaces we'll certainly have to track the changes in
+MethodNodeBuilder and all the builders. And those changes will include
+rendering child nodes, since any node can have child nodes.
+
+>
+> Quick Member navigation - it's not so easy to set the rules:
+>
+> 'showing first level items of the file' means:
+> + Showing only the namespaces -> no containing types (they're first
+> level, and will be part of the DOM as nodes)
+> + Don't show inner types (they're second level at best)
+>
+> 'children of the active first level item' means:
+> + Show the current inner type (should be in the type selector).
+> + Show the current statement, if the DOM is extended and more specific
+> than the monodevelop DOM.
+
+This has a very simple solution:
+
+interface IQuickMemberNavigationProvider
+{
+ IEnumerable<INode> GetTypes ();
+ IEnumerable<INode> GetMembers (INode type);
+}
+
+to be implemented by language bindings.
+
+>
+> Then there are 3 navigators: types/members/regions. That doesn't make
+> sense for some cases (think of C, there are no members/regions).
+>
+> Document outline:
+> The document outline that shows the hierarchy requires that
+> IOutlinedDocument is implemented. A XML and MD DOM get different
+> implementations of this interface. It's very general:
+>
+> public interface IOutlinedDocument
+> {
+> Gtk.Widget GetOutlineWidget ();
+> void ReleaseOutlineWidget ();
+> }
+>
+> I would say that's one of the best components we have for extensibility.
+> Because it doesn't 'lock' into a specific model. The downside is that it
+> doesn't provide much to re-use. But I think we should have this sort of
+> extensibility for all components and let the non-.NET languages a way to
+> work around all pre defined structures and replace the components with
+> an own way. This ensures that we can't make a mistake.
+
+But that's not always possible. For example, a solution may contain C#
+and C++ projects, and the class pad has to show all of them in a single
+tree.
+
+It might work in other cases, for example in the quick member navigation
+toolbar.
+
+>
+> btw. another thing: All pads/output function currently build on ambience
+> flags - but for other languages there may be different sets of flags
+> required for displaying the information at that point.
+>
+> > Yes, that's currently possible (with some tweaks). But it means that the
+> > language has to implement all the DOM interfaces: IField, IMethod,
+> > IType, etc, which are full of .NET specific stuff. Yes, you can just
+> > throw NotSupportedException of all .NET specific methods and properties,
+> > but that's just unnecessary bloat. If anything, it would be better to
+> > have:
+>
+> We've classes that implement the interfaces, no .NET specific
+> implementation is required. But the other thing is that a new languages
+> now would ALWAYS require to implement all DOM interfaces that are full
+> of .NET specific stuff. (ok could use the same base class)
+> You've still not told how to display a VB output, Boo output and c#
+> output of a reflection source when putting the output code inside the
+> DOM objects. I think that's not easily possible.
+
+I showed it some posts ago:
+
+class DomField: IMember, INewField
+{
+ public string GetDescription (SomeContext ctx)
+ {
+ return ctx.Ambience.GetString (this, ctx.AmbienceOptions);
+ }
+ ...
+}
+
+>
+> MD side:
+> Code Completion DB -> Data (in which DOM format)
+>
+> Language binding:
+> Own Dom info + wants to display code completion data from the code
+> completion db
+>
+> > That would work, although I don't see the benefit of separating data
+> > from display data in non .NET languages, since there will be a 1 to 1
+> > correspondence between data and display data.
+> >
+>
+> The benefit is that the non .NET languages can communicate with
+> MonoDevelop components to produce output. And that the .NET unspecific
+> types/members etc. could be implemented today.
+> Sometimes the output is altered (adding markup to names etc.) by
+> consuming code. Outputting the text from the DOM isn't very easy and
+> just a GetString () doesn't cut the edge. We've to display this
+> information in various tooltips/lists with different options (short name
+> vs. long name). Therefore the GetString () needs to get the same
+> parameters as ambiences.
+
+I think we have to look at this case by case. For the tooltip case,
+maybe this is enough:
+
+interface ITooltipProvider
+{
+ string GetMarkup (INode node);
+}
+
+to be implemented in every non-.net language binding.
+
+>
+> I tend to make the monodevelop DOM stuff .NET dependent in the type
+> model, generalize the object model so that other .NET languages can be
+> supported that are more far from C#/VB.NET and have a way to do
+> something like the IOutlinedDocument for each component. I don't want to
+> make the life harder for .NET language implementors when the non .NET
+> language implementors get little to no gain (See above - they need to
+> implement their own widgets/infrastructure - regardless of what we try,
+> more worse they can run into dead ends when trying to re-use the
+> monodevelop DOM - see the class output pad method example).
+
+No, what I'm proposing does not involve implementing additional
+widgets/infrastructure. See above.
+
+Lluis.
+
+
+
+
+
+
+ Hi
+
+> I feel there is some misunderstanding here. If we introduce a new set of
+> INew* interfaces we'll certainly have to track the changes in
+> MethodNodeBuilder and all the builders. And those changes will include
+> rendering child nodes, since any node can have child nodes.
+>
+
+Don't solve the case, where the DOM goes deeper than methods. I'm sure
+you're coming up with an interface: IClassBrowserProvider { bool
+IncludeInClassBrowser { get; }} that 'just' needs to be provided for
+every dom.
+The class browser works better when non .NET languages don't re-use our
+DOM, if they use their own one they can add their node builders to the
+class browser and the thing works.
+
+> >
+> > Quick Member navigation - it's not so easy to set the rules:
+> >
+> > 'showing first level items of the file' means:
+> > + Showing only the namespaces -> no containing types (they're first
+> > level, and will be part of the DOM as nodes)
+> > + Don't show inner types (they're second level at best)
+> >
+> > 'children of the active first level item' means:
+> > + Show the current inner type (should be in the type selector).
+> > + Show the current statement, if the DOM is extended and more specific
+> > than the monodevelop DOM.
+>
+> This has a very simple solution:
+>
+> interface IQuickMemberNavigationProvider
+> {
+> IEnumerable<INode> GetTypes ();
+> IEnumerable<INode> GetMembers (INode type);
+> }
+>
+> to be implemented by language bindings.
+>
+
+Doesn't solve the issue with more than one panel or three panels. You
+need something like:
+interface IQuickMemberNavigationProvider
+{
+ IEnumerable<IQuickNavigationPanel> GetPanels ();
+}
+-> then the quick navigation code has nothing to do with any dom.
+
+> >
+> > btw. another thing: All pads/output function currently build on ambience
+> > flags - but for other languages there may be different sets of flags
+> > required for displaying the information at that point.
+> >
+> > > Yes, that's currently possible (with some tweaks). But it means that the
+> > > language has to implement all the DOM interfaces: IField, IMethod,
+> > > IType, etc, which are full of .NET specific stuff. Yes, you can just
+> > > throw NotSupportedException of all .NET specific methods and properties,
+> > > but that's just unnecessary bloat. If anything, it would be better to
+> > > have:
+> >
+> > We've classes that implement the interfaces, no .NET specific
+> > implementation is required. But the other thing is that a new languages
+> > now would ALWAYS require to implement all DOM interfaces that are full
+> > of .NET specific stuff. (ok could use the same base class)
+> > You've still not told how to display a VB output, Boo output and c#
+> > output of a reflection source when putting the output code inside the
+> > DOM objects. I think that's not easily possible.
+>
+> I showed it some posts ago:
+>
+> class DomField: IMember, INewField
+> {
+> public string GetDescription (SomeContext ctx)
+> {
+> return ctx.Ambience.GetString (this, ctx.AmbienceOptions);
+> }
+> ...
+> }
+
+Doesn't solve what I'm describing, because it doesn't solve the problem
+for the reflection source. Or you're saying that we use a same set of
+classes for every .NET language - that is what we currently have.
+
+You're coming up with a design that isn't better than the thing we
+already have, it's just the same. The discussion is about visitors vs.
+member methods - this is pointless.
+
+> I think we have to look at this case by case. For the tooltip case,
+> maybe this is enough:
+>
+> interface ITooltipProvider
+> {
+> string GetMarkup (INode node);
+> }
+>
+> to be implemented in every non-.net language binding.
+>
+
+Just another DOM extender interface - you see the design gets more and
+more complicated this way ? It's generally not possible to handle every
+possible language output/model in a single GetString() - you'll get
+scaling problems. If you try this you basically come up with:
+
+INode {
+ GetDescription (CaseEnum, SomeContext ctx);
+}
+
+CaseEnum { CompletionList, CompletionListTooltip, ParameterTooltip,
+ParameterDescription, ClassBrowser, QuickNavigationList, ... }
+
+SomeContext { ... }
+ClassBrowserContext : SomeContext { ... }
+CompletionContext : SomeContext { ... }
+ParameterListContext : SomeContext { ... }
+..
+
+Is that really an option ? What are the others saying ? (The problem
+will be adding new controls that display DOM stuff - currently we've a
+set of display options where the controls choose from).
+
+> >
+> > I tend to make the monodevelop DOM stuff .NET dependent in the type
+> > model, generalize the object model so that other .NET languages can be
+> > supported that are more far from C#/VB.NET and have a way to do
+> > something like the IOutlinedDocument for each component. I don't want to
+> > make the life harder for .NET language implementors when the non .NET
+> > language implementors get little to no gain (See above - they need to
+> > implement their own widgets/infrastructure - regardless of what we try,
+> > more worse they can run into dead ends when trying to re-use the
+> > monodevelop DOM - see the class output pad method example).
+>
+> No, what I'm proposing does not involve implementing additional
+> widgets/infrastructure. See above.
+>
+
+But to change every widget/infrastructure with an interface that may not
+work for the case the language implementor needs, doesn't add
+functionality and makes the life more difficult implementing standard
+language bindings isn't a solution.
+
+Again what I wanted:
+
+Extend the MD DOM to make it EASIER to implement .NET based languages -
+and MAYBE being able to map non .NET languages to it. I don't intend to
+make anything HARDER to implement for .NET languages.
+
+What I learned from our discussion:
+
+a) Don't provide too much infrastructure for trees you don't yet know
+how they look like.
+b) Make every component of monodevelop extendable without sticking to a
+specific DOM - provide defaults for the .NET based DOM.
+
+Reagds
+Mike
+
+
+
+
+
+ El dt 29 de 09 de 2009 a les 13:19 +0200, en/na Mike Krüger va
+escriure:
+> Hi
+>
+> > I feel there is some misunderstanding here. If we introduce a new set of
+> > INew* interfaces we'll certainly have to track the changes in
+> > MethodNodeBuilder and all the builders. And those changes will include
+> > rendering child nodes, since any node can have child nodes.
+> >
+>
+> Don't solve the case, where the DOM goes deeper than methods.
+
+I don't know why you say that. If an IMethod is an INode, and an INode
+can have child INodes. MethodNodeBuilder can be a subclass of
+INodeBuilder, which by default renders child INodes.
+
+> I'm sure
+> you're coming up with an interface: IClassBrowserProvider { bool
+> IncludeInClassBrowser { get; }} that 'just' needs to be provided for
+> every dom.
+> The class browser works better when non .NET languages don't re-use our
+> DOM, if they use their own one they can add their node builders to the
+> class browser and the thing works.
+
+Agreed, in this case using node builders bound to the particular
+language dom is an easy solution.
+
+>
+> > >
+> > > Quick Member navigation - it's not so easy to set the rules:
+> > >
+> > > 'showing first level items of the file' means:
+> > > + Showing only the namespaces -> no containing types (they're first
+> > > level, and will be part of the DOM as nodes)
+> > > + Don't show inner types (they're second level at best)
+> > >
+> > > 'children of the active first level item' means:
+> > > + Show the current inner type (should be in the type selector).
+> > > + Show the current statement, if the DOM is extended and more specific
+> > > than the monodevelop DOM.
+> >
+> > This has a very simple solution:
+> >
+> > interface IQuickMemberNavigationProvider
+> > {
+> > IEnumerable<INode> GetTypes ();
+> > IEnumerable<INode> GetMembers (INode type);
+> > }
+> >
+> > to be implemented by language bindings.
+> >
+>
+> Doesn't solve the issue with more than one panel or three panels.
+
+It does solve the problems you asked for.
+
+> You
+> need something like:
+> interface IQuickMemberNavigationProvider
+> {
+> IEnumerable<IQuickNavigationPanel> GetPanels ();
+> }
+> -> then the quick navigation code has nothing to do with any dom.
+
+Agreed, that's the most generic solution (well, the most generic would
+be just returning a gtk.widget).
+
+In any case we can have both interfaces. The first interface could be
+used by language bindings which don't want to implement its own custom
+panel. MD would use the default panel in this case, filling the data
+retrieved from the interface. Language bindings with more advanced needs
+could implement the second interface and provide a full custom set of
+panels.
+
+The Properties Pad already works in this way. You can implement
+IPropertyPadProvider, which has a GetActiveComponent() method. When
+using this interface, MD will create a standard PropertyGrid and fill it
+up with the data of the active component (retrieved using the
+System.ComponentModel classes). On the other hand, you can implement
+ICustomPropertyPadProvider, which has a GetCustomPropertyWidget(). When
+finding this interface, MD will just create the custom widget and embed
+it in the properties pad, replacing the default property grid.
+
+>
+> > >
+> > > btw. another thing: All pads/output function currently build on ambience
+> > > flags - but for other languages there may be different sets of flags
+> > > required for displaying the information at that point.
+> > >
+> > > > Yes, that's currently possible (with some tweaks). But it means that the
+> > > > language has to implement all the DOM interfaces: IField, IMethod,
+> > > > IType, etc, which are full of .NET specific stuff. Yes, you can just
+> > > > throw NotSupportedException of all .NET specific methods and properties,
+> > > > but that's just unnecessary bloat. If anything, it would be better to
+> > > > have:
+> > >
+> > > We've classes that implement the interfaces, no .NET specific
+> > > implementation is required. But the other thing is that a new languages
+> > > now would ALWAYS require to implement all DOM interfaces that are full
+> > > of .NET specific stuff. (ok could use the same base class)
+> > > You've still not told how to display a VB output, Boo output and c#
+> > > output of a reflection source when putting the output code inside the
+> > > DOM objects. I think that's not easily possible.
+> >
+> > I showed it some posts ago:
+> >
+> > class DomField: IMember, INewField
+> > {
+> > public string GetDescription (SomeContext ctx)
+> > {
+> > return ctx.Ambience.GetString (this, ctx.AmbienceOptions);
+> > }
+> > ...
+> > }
+>
+> Doesn't solve what I'm describing, because it doesn't solve the problem
+> for the reflection source. Or you're saying that we use a same set of
+> classes for every .NET language - that is what we currently have.
+
+Yes, that's what I've been saying since the beginning. The current DOM
+is OK for .NET languages and I'm not proposing the change it. I just
+proposed creating a higher level set of interfaces (which would not
+replace the ones we have now, only complement them). Those interfaces
+would allow using the current set of navigation/information widgets
+without having to use the .NET specific DOM.
+
+>
+> You're coming up with a design that isn't better than the thing we
+> already have, it's just the same. The discussion is about visitors vs.
+> member methods - this is pointless.
+
+No, this is not the discussion. I hope my previous paragraph clarifies
+it.
+
+>
+> > I think we have to look at this case by case. For the tooltip case,
+> > maybe this is enough:
+> >
+> > interface ITooltipProvider
+> > {
+> > string GetMarkup (INode node);
+> > }
+> >
+> > to be implemented in every non-.net language binding.
+> >
+>
+> Just another DOM extender interface - you see the design gets more and
+> more complicated this way ? It's generally not possible to handle every
+> possible language output/model in a single GetString() - you'll get
+> scaling problems. If you try this you basically come up with:
+>
+> INode {
+> GetDescription (CaseEnum, SomeContext ctx);
+> }
+>
+> CaseEnum { CompletionList, CompletionListTooltip, ParameterTooltip,
+> ParameterDescription, ClassBrowser, QuickNavigationList, ... }
+>
+> SomeContext { ... }
+> ClassBrowserContext : SomeContext { ... }
+> CompletionContext : SomeContext { ... }
+> ParameterListContext : SomeContext { ... }
+> ...
+>
+> Is that really an option ? What are the others saying ? (The problem
+> will be adding new controls that display DOM stuff - currently we've a
+> set of display options where the controls choose from).
+
+The problem is that those display options are .NET specific:
+UseFullName, IncludeBaseTypes, IncludeGenerics, HideArrayBrackets,
+HideExtensionsParameter, UseNETTypeNames, UseFullInnerTypeName.
+
+So, a non-.net language won't make any use of those properties, and it
+will have a hard time figuring out which information to show. On the
+other hand, there is no doubt about how to implement ITooltipProvider:
+it is very clear that the markup is going to be used to show a tooltip
+to the user, so the language can decide what needs to be shown.
+
+I'm not saying however that ITooltipProvider is the best solution, it
+was just an example of high level interface which could be used to avoid
+a DOM dependency.
+
+>
+> > >
+> > > I tend to make the monodevelop DOM stuff .NET dependent in the type
+> > > model, generalize the object model so that other .NET languages can be
+> > > supported that are more far from C#/VB.NET and have a way to do
+> > > something like the IOutlinedDocument for each component. I don't want to
+> > > make the life harder for .NET language implementors when the non .NET
+> > > language implementors get little to no gain (See above - they need to
+> > > implement their own widgets/infrastructure - regardless of what we try,
+> > > more worse they can run into dead ends when trying to re-use the
+> > > monodevelop DOM - see the class output pad method example).
+> >
+> > No, what I'm proposing does not involve implementing additional
+> > widgets/infrastructure. See above.
+> >
+>
+> But to change every widget/infrastructure with an interface that may not
+> work for the case the language implementor needs, doesn't add
+> functionality and makes the life more difficult implementing standard
+> language bindings isn't a solution.
+>
+> Again what I wanted:
+>
+> Extend the MD DOM to make it EASIER to implement .NET based languages -
+> and MAYBE being able to map non .NET languages to it. I don't intend to
+> make anything HARDER to implement for .NET languages.
+
+And I'm OK with that. Now, what I want is to make it EASIER to implement
+non .NET languages, without making it HARDER to implement the .NET
+languages (no changes should be required in the existing .NET language
+bindings). That's the whole point of my proposal.
+
+>
+> What I learned from our discussion:
+>
+> a) Don't provide too much infrastructure for trees you don't yet know
+> how they look like.
+> b) Make every component of monodevelop extendable without sticking to a
+> specific DOM - provide defaults for the .NET based DOM.
+
+Agreed. The document outline component is a good example of this. I
+think however that there must be a middle-ground solution between
+getting the document outline automatically filled from the .NET DOM
+(using the default component), and having to write your custom widget
+from scratch. I'd like to make it easier to support non .net languages
+by providing this kind of middle-ground solution (whatever it is).
+
+Lluis.
+
+
+
+
+
+
+
+ Starting: Tue Sep 1 12:17:21 EDT 2009
+ Ending: Wed Sep 30 18:08:39 EDT 2009
+ Messages: 33
+
+ Last message date:
+ Wed Sep 30 18:08:39 EDT 2009
+ Archived on: Wed Sep 30 18:10:59 EDT 2009
+
+
+
Starting: Tue Sep 1 12:17:21 EDT 2009
+ Ending: Wed Sep 30 18:08:39 EDT 2009
+ Messages: 33
+
+ Last message date:
+ Wed Sep 30 18:08:39 EDT 2009
+ Archived on: Wed Sep 30 18:10:59 EDT 2009
+
+
+
Starting: Tue Sep 1 12:17:21 EDT 2009
+ Ending: Wed Sep 30 18:08:39 EDT 2009
+ Messages: 33
+
+ Last message date:
+ Wed Sep 30 18:08:39 EDT 2009
+ Archived on: Wed Sep 30 18:10:59 EDT 2009
+
+
+
Starting: Tue Sep 1 12:17:21 EDT 2009
+ Ending: Wed Sep 30 18:08:39 EDT 2009
+ Messages: 33
+
+ Last message date:
+ Wed Sep 30 18:08:39 EDT 2009
+ Archived on: Wed Sep 30 18:10:59 EDT 2009
+
+
+
Starting: Tue Sep 1 12:17:21 EDT 2009
+ Ending: Wed Sep 30 18:08:39 EDT 2009
+ Messages: 33
+
+ Last message date:
+ Wed Sep 30 18:08:39 EDT 2009
+ Archived on: Wed Sep 30 18:10:59 EDT 2009
+
+
+
Hi. +Just want to check the status. Have you read my previous message? + +-----Original Message----- +From: Alexander M. Batishchev [mailto:abatishchev at godfather.net.ru] +Sent: Thursday, March 11, 2010 8:44 PM +To: 'Michael Hutchinson' +Cc: 'monodevelop-devel-list at lists.ximian.com' +Subject: RE: [Monodevelop-devel] Integration MonoDevelop into Gnome + +Hi Michael. + +Here is the patch +Is it correct? (this is my first svn patch) + +Have I to open a ticket on Novell Bugzilla? + +What more can I do for this topic? + +Thanks. +Alex + +-----Original Message----- +From: Michael Hutchinson [mailto:m.j.hutchinson at gmail.com] +Sent: Saturday, February 27, 2010 6:42 AM +To: Alexander M. Batishchev +Cc: monodevelop-devel-list +Subject: Re: [Monodevelop-devel] Integration MonoDevelop into Gnome + +On Sun, Jan 17, 2010 at 11:12 AM, Alexander M. Batishchev +<abatishchev at godfather.net.ru> wrote: +> Also, as far as MonoDevelop opens only first file passed as argument +> and ignores others and as provided by Desktop Entry Spec, Exec key +> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.htm +> l +> +> monodevelop.desktop should contain: +> Exec=monodevelop %f +> +> now this key is just: +> Exec=monodevelop +> +> What do you think? + +Makes sense. Can you file a patch in bugzilla? + +(Sorry for late reply, I lost track of my email...) + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: monodevelop.desktop.diff +Type: application/octet-stream +Size: 967 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100404/c10c7c52/attachment.obj ++ + + + +
On Tue, Mar 30, 2010 at 2:10 AM, Ray Wang <rawang at novell.com> wrote: +> Hi all, +> +> It appears Chinese(China) translation for monodevelop was not touched for a +> pretty long time. +> +> Today, I've partially updated it. but I can't find any way to submit/commit +> the translation, neither on mono-project.com, nor on l10n.gnome.org +> +> So should I commit directly(I have write permission to mono svn), or should +> someone review my translation first? Or someone commit for me? + +Please commit directly, thanks! + +The normal procedure is for translator to attach translations to +mailing list message or bug reports so that we can commit them - we +don't have a procedure for reviewing, as we mostly don't have +duplicate translators to do the review. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + +
>>> On 4/5/2010 at 06:15 PM, in message +<r2iaec34c771004050315p7028b45ana93786185f02fb94 at mail.gmail.com>, Michael +Hutchinson <m.j.hutchinson at gmail.com> wrote: +> On Tue, Mar 30, 2010 at 2:10 AM, Ray Wang <rawang at novell.com> wrote: +> > Hi all, +> > +> > It appears Chinese(China) translation for monodevelop was not touched for a +> > pretty long time. +> > +> > Today, I've partially updated it. but I can't find any way to submit/commit +> > the translation, neither on mono-project.com, nor on l10n.gnome.org +> > +> > So should I commit directly(I have write permission to mono svn), or should +> > someone review my translation first? Or someone commit for me? +> +> Please commit directly, thanks! + +Great! Thank you, I'll do it. + +> The normal procedure is for translator to attach translations to +> mailing list message or bug reports so that we can commit them - we +> don't have a procedure for reviewing, as we mostly don't have +> duplicate translators to do the review. + +Since Monodevelop uses GNOME technology, I think it would even better to +make Monodevelop as a GNOME module, so that GNOME could help monodevelop +manage translation or something? It's just my humble option. :) + +Ray + + ++ + + + + +
Hi + +*I want to move the discussion to the developer mailing list* + +> I had a talk with Michael Hutchinson on IRC regarding the new VS 2010 +> text editor features, such as the text markers, tracking spans and the +> ITagger interface. I guess currently book keeping in the text editor, +> like region folding, bookmarks and breakpoints are done using markers. +> In VS 2010, changes in the text are exposed to tracking spans. +> Basically you create a span over some text, and after the text has +> changed, you can query the span for its status. They key difference is +> that, unlike markers that are checked at each text change event, spans +> are checked only when you require their status, ie lazy evaluation. + +Don't believe all of the ms marketing :) + +Monodevelop doesn't update all 'markers' on on text change events ... +Currently the stuff is stored in the line segments and the line segments +are stored in a red-black tree. And on text change only a small part of +the tree changes. The monodevelop text editor is the same in this regard +(I don't know why you think it's not). + +And for any kind of markers a red-black tree could be used as well. I +don't know what's so difficult in 'not updatating all markers' ... this +is more or less 3rd semester computer science stuff what they're +describing. 'Use a tree instead of an array.' I wonder if they stored +their lines as an 'array' as well :). + +(Before you kill me - the region folding isn't stored in a red-black +tree this one is currently stored as a 'folding tree' ... has to do with +the way I get the data from the parser. This is something like a hybrid +tree ... it contains links in the line segment red-black tree - +therefore updating it is faster as the domino update effect the MS +developers are fearing). + +> This is being done by using snapshots of the text editor, which allow +> you to go get the status of the span at each write. The way its being +> done suggests that the underlying data structure is persistent. +> Also of interest is the ITagger interface, which provides metadata for +> text in a buffer. The tagger interface will make writing of spell +> checkers and the quick-fixes part of my proposal very easy. Also as +> the spans are immutable, you could probably use PLINQ on them to do +> some awesome stuff. I would like to point your attention to two +> articles +> +> http://blogs.msdn.com/noahric/archive/2010/01/28/new-extension-spell-checker.aspx +> http://blogs.msdn.com/noahric/archive/2009/06/06/editor-perf-markers-vs-tracking-spans.aspx +> +> Do let me know of your plans with the text editor. + +This one is *much* more interresting - I do want to do it as well :). +Snapshots are the way to go (I've too many 'background' thread problems +and I too think that this is the best solution). + +The snapshot stuff I call 'piece table'. I've started to implement it to +replace the buffer. The idea is that the current buffer state is always +valid - even if the buffer changes. (But for multi threading you need a +copy of the 'snapshot' in the other thread - but it's always valid). I +want the snapshot system for the whole document. +(this will make the undo/redo more easier to implement as well ... but +it's only a side effect). + +It's something like: +[DATA] <- [TABLE] +And [DATA] only grows and [TABLE] contains the information how the +[DATA] is puzzled together as text. [DATA] contains something like 2 +char arrays: one of the original file and one growing change buffer. +Background threads now can use the current valid [TABLE] in their thread +and it's always valid against the [DATA] - even if it changes. + +(Before anybody throws in 'memory hole' I want to throw in 'unlimited +undo') + +Markers/Highlighting: + +And I want to do an own red-black tree for segments (aka. 'markers') for +the highlighting. Currently the highlighting spans are a bit hacky. +Doing this as an own tree would be much easier. And a tree for semantic +highlighting tags as well. I think here something like the ITagger +interface would work. Currently the highlighting is state less more or +less ... the line segments contain the begin span stack. But I want to +get rid of this hack and have an own span red-black tree instead. + +Overall I want to use more red-black trees in the text editor. Maybe +even put all markers into an own one (but for many markers the line +tagging works well and the line segments also aren't updated on each +text change). Currently the piece table has some bugs (but it uses the +same red-black tree than the current line segments, I haven't had the +time/patience to track this yet). + +It's interresting that the vs.net developers and we are doing almost the +same evolution - it's always good to know what the competitors are up +to :) + +If anyone wants to help with the text editor data structures (or maybe +have more proposals on doing things) - all input/help is welcome. + +Regards +Mike + ++ + + + + +
On Tue, Apr 6, 2010 at 11:20 PM, Mike Krüger <mkrueger at novell.com> wrote: +> Hi +> +> *I want to move the discussion to the developer mailing list* +> +>> I had a talk with Michael Hutchinson on IRC regarding the new VS 2010 +>> text editor features, such as the text markers, tracking spans and the +>> ITagger interface. I guess currently book keeping in the text editor, +>> like region folding, bookmarks and breakpoints are done using markers. +>> In VS 2010, changes in the text are exposed to tracking spans. +>> Basically you create a span over some text, and after the text has +>> changed, you can query the span for its status. They key difference is +>> that, unlike markers that are checked at each text change event, spans +>> are checked only when you require their status, ie lazy evaluation. +> +> Don't believe all of the ms marketing :) + +I generally assume they know what they are talking about, but I'll be +careful next time :) + +> Monodevelop doesn't update all 'markers' on on text change events ... +> Currently the stuff is stored in the line segments and the line segments +> are stored in a red-black tree. And on text change only a small part of +> the tree changes. The monodevelop text editor is the same in this regard + +I did know about the line segment data structure, its used to +calculate the LOC in the code metrics. +I just had a vague recollection of it being stored in the RB tree. +Thing is I don't know how to keep a track +of changes in the line segment. Maybe theres a onLineSegmentChange +event, I don't know. The problem is +how do I narrow down to that *part* of the line segment that changed, +ie a word or phrase. + +> (I don't know why you think it's not). + +Ignorance? I'm still new to Mono, and I never claimed to know the text +editor internals :) + +> And for any kind of markers a red-black tree could be used as well. I +> don't know what's so difficult in 'not updatating all markers' ... this +> is more or less 3rd semester computer science stuff what they're +> describing. 'Use a tree instead of an array.' I wonder if they stored +> their lines as an 'array' as well :). + +> (Before you kill me - the region folding isn't stored in a red-black +> tree this one is currently stored as a 'folding tree' ... has to do with +> the way I get the data from the parser. This is something like a hybrid +> tree ... it contains links in the line segment red-black tree - +> therefore updating it is faster as the domino update effect the MS +> developers are fearing). + +So would you suggest I create my own hybrid tree to keep track of text in the +text editor? For example, I wanted to keep track of text that violate +certain rules +so that I could add little squiggly lines under them. I could probably +create a tree +that stores the links to the line segments that I know violate the +rules. Thing is, +is there a way to highlight only that part of the line segment which +has the error? +AFAIK, whenever theres a parse error, the entire line gets highlighted +by a red squiggly. + +>> This is being done by using snapshots of the text editor, which allow +>> you to go get the status of the span at each write. The way its being +>> done suggests that the underlying data structure is persistent. +>> Also of interest is the ITagger interface, which provides metadata for +>> text in a buffer. The tagger interface will make writing of spell +>> checkers and the quick-fixes part of my proposal very easy. Also as +>> the spans are immutable, you could probably use PLINQ on them to do +>> some awesome stuff. I would like to point your attention to two +>> articles +>> +>> http://blogs.msdn.com/noahric/archive/2010/01/28/new-extension-spell-checker.aspx +>> http://blogs.msdn.com/noahric/archive/2009/06/06/editor-perf-markers-vs-tracking-spans.aspx +>> +>> Do let me know of your plans with the text editor. +> +> This one is *much* more interresting - I do want to do it as well :). +> Snapshots are the way to go (I've too many 'background' thread problems +> and I too think that this is the best solution). +> +> The snapshot stuff I call 'piece table'. I've started to implement it to +> replace the buffer. The idea is that the current buffer state is always +> valid - even if the buffer changes. (But for multi threading you need a +> copy of the 'snapshot' in the other thread - but it's always valid). I +> want the snapshot system for the whole document. +> (this will make the undo/redo more easier to implement as well ... but +> it's only a side effect). +> +> It's something like: +> [DATA] <- [TABLE] +> And [DATA] only grows and [TABLE] contains the information how the +> [DATA] is puzzled together as text. [DATA] contains something like 2 +> char arrays: one of the original file and one growing change buffer. +> Background threads now can use the current valid [TABLE] in their thread +> and it's always valid against the [DATA] - even if it changes. +> +> (Before anybody throws in 'memory hole' I want to throw in 'unlimited +> undo') +> +> Markers/Highlighting: +> +> And I want to do an own red-black tree for segments (aka. 'markers') for +> the highlighting. Currently the highlighting spans are a bit hacky. +> Doing this as an own tree would be much easier. And a tree for semantic +> highlighting tags as well. I think here something like the ITagger +> interface would work. Currently the highlighting is state less more or +> less ... the line segments contain the begin span stack. But I want to +> get rid of this hack and have an own span red-black tree instead. + +I guess this answers my questions above? +Btw does this mean an RB Tree within an RB Tree? + +> Overall I want to use more red-black trees in the text editor. Maybe +> even put all markers into an own one (but for many markers the line +> tagging works well and the line segments also aren't updated on each +> text change). Currently the piece table has some bugs (but it uses the +> same red-black tree than the current line segments, I haven't had the +> time/patience to track this yet). +> +> It's interresting that the vs.net developers and we are doing almost the +> same evolution - it's always good to know what the competitors are up +> to :) +> +> If anyone wants to help with the text editor data structures (or maybe +> have more proposals on doing things) - all input/help is welcome. + +Um, make the text editor extensible through scripting? *ducks shoes* + +> Regards +> Mike +> +> +Cheers +Nikhil Sarda ++ + + + + +
On Wed, Apr 7, 2010 at 8:58 AM, nikhil sarda <diff.operator at gmail.com> wrote: +>> (Before you kill me - the region folding isn't stored in a red-black +>> tree this one is currently stored as a 'folding tree' ... has to do with +>> the way I get the data from the parser. This is something like a hybrid +>> tree ... it contains links in the line segment red-black tree - +>> therefore updating it is faster as the domino update effect the MS +>> developers are fearing). +> +> So would you suggest I create my own hybrid tree to keep track of text in the +> text editor? For example, I wanted to keep track of text that violate +> certain rules +> so that I could add little squiggly lines under them. I could probably +> create a tree +> that stores the links to the line segments that I know violate the +> rules. Thing is, +> is there a way to highlight only that part of the line segment which +> has the error? +> AFAIK, whenever theres a parse error, the entire line gets highlighted +> by a red squiggly. + +The text editor's error underlining can underline specific portions of +the line - although the markers track a line rather than a span, the +markers can contain column numbers and just render the squiggle under +those columns. The reason the C# syntax error underlines affect the +whole line is that the parser only outputs a start position for the +error. Some of the XML error underlines are localized to specific +tags. + +Obviously this isn't as good as real span tracking, but it works okay. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + +
Hi + +> > *I want to move the discussion to the developer mailing list* +> > +> >> I had a talk with Michael Hutchinson on IRC regarding the new VS 2010 +> >> text editor features, such as the text markers, tracking spans and the +> >> ITagger interface. I guess currently book keeping in the text editor, +> >> like region folding, bookmarks and breakpoints are done using markers. +> >> In VS 2010, changes in the text are exposed to tracking spans. +> >> Basically you create a span over some text, and after the text has +> >> changed, you can query the span for its status. They key difference is +> >> that, unlike markers that are checked at each text change event, spans +> >> are checked only when you require their status, ie lazy evaluation. +> > +> > Don't believe all of the ms marketing :) +> +> I generally assume they know what they are talking about, but I'll be +> careful next time :) +> + +They know what they're talking about ... using an array for the markers +is a bad idea ... but I for myself are not very surprised about that :) +(I found that out about 10 years ago with my 1st text editor storing the +lines in an ArrayList :)) + +> > Monodevelop doesn't update all 'markers' on on text change events ... +> > Currently the stuff is stored in the line segments and the line segments +> > are stored in a red-black tree. And on text change only a small part of +> > the tree changes. The monodevelop text editor is the same in this regard +> +> I did know about the line segment data structure, its used to +> calculate the LOC in the code metrics. +> I just had a vague recollection of it being stored in the RB tree. +> Thing is I don't know how to keep a track +> of changes in the line segment. Maybe theres a onLineSegmentChange +> event, I don't know. The problem is +> how do I narrow down to that *part* of the line segment that changed, +> ie a word or phrase. +> + +That's more difficult - I recommend storing the segments in a RB tree +and track the change there separately. + +> So would you suggest I create my own hybrid tree to keep track of text in the +> text editor? For example, I wanted to keep track of text that violate +> certain rules +> so that I could add little squiggly lines under them. I could probably +> create a tree +> that stores the links to the line segments that I know violate the +> rules. Thing is, +> is there a way to highlight only that part of the line segment which +> has the error? + +Yes that's the current approach. The part of the line segment is more +difficult. The text marker gets the whole line. With this info you can +get the line layout and inside the pango line layout you have to get the +position of the line part with IndexToXY + +> AFAIK, whenever theres a parse error, the entire line gets highlighted +> by a red squiggly. +> + +I'll improve the red squiggly lines when I get good parser errors. The +current ones are just 'proof of concept' :). NRefactory was never +designed for finding errors. + +> > And I want to do an own red-black tree for segments (aka. 'markers') for +> > the highlighting. Currently the highlighting spans are a bit hacky. +> > Doing this as an own tree would be much easier. And a tree for semantic +> > highlighting tags as well. I think here something like the ITagger +> > interface would work. Currently the highlighting is state less more or +> > less ... the line segments contain the begin span stack. But I want to +> > get rid of this hack and have an own span red-black tree instead. +> +> I guess this answers my questions above? +> Btw does this mean an RB Tree within an RB Tree? +> + +No it means just that each RB tree node (==line segment) has a tag with +the current span stack at this position. + +> > Overall I want to use more red-black trees in the text editor. Maybe +> > even put all markers into an own one (but for many markers the line +> > tagging works well and the line segments also aren't updated on each +> > text change). Currently the piece table has some bugs (but it uses the +> > same red-black tree than the current line segments, I haven't had the +> > time/patience to track this yet). +> > +> > It's interresting that the vs.net developers and we are doing almost the +> > same evolution - it's always good to know what the competitors are up +> > to :) +> > +> > If anyone wants to help with the text editor data structures (or maybe +> > have more proposals on doing things) - all input/help is welcome. +> +> Um, make the text editor extensible through scripting? *ducks shoes* +> + +Scripting for what ? (btw. we choose to be extendable with .NET using +the addin-tree :)) + +Regards +Mike + ++ + + + + +
I thought I'd share some constructive consistency-/polish-related +feedback on MD's evolving UI, from Unity's Nicholas Francis. +(Hopefully my mail client hasn't mangled the graphic insertion too badly.) +===== + +Why does the toolbar on the right (don't know what it's called) use a +smaller widget size and have an underline? + + + + +================================================================== + +I like the less boxed version of the UI, but some details were missed out: + +If there's a theme of grey background behind windows, that needs to be +fairly consistent. This was missed e.g. here: + + + + + +I'd also make sure the dark border is present here: + + + + + +================================================================== + +It looks to me like you want to make it look like the +which-function-am-I-editing-dropdown should take over the entire +window (which is nice and a lot less noisy than the old version). + + + + +However, you've got 5 px at the top (you can see the seperator lines +don't extend all the way). Also, the top of the toolbar doesn't match +color with the outline border giving it a weird wavy 'curve' from the +shading. You also can't click the top 5 px. I'd say you should just +lose them and pull up the toolbar. + +================================================================== +Your bordering of scrollviews is inconsistent: + + + +The one on the left is esp. weird: you have a 2px grey inset between +scrollbars and content, but no hard line. Being a Mac user, I'd just +lose spacing on both sides. Either way, it should probably be +consistent. + +================================================================== + +Why is this right side of the status bar darker grey than the left? + + + +Maybe just make the entire status line a bit darker? We do that in +Unity, and readability is not really a problem (even on 2.2 gamma +monitors) +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: pastedGraphic.png +Type: image/png +Size: 9120 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100416/524d8064/attachment-0006.png +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: pastedGraphic.png +Type: image/png +Size: 27320 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100416/524d8064/attachment-0007.png +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: pastedGraphic.png +Type: image/png +Size: 10751 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100416/524d8064/attachment-0008.png +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: pastedGraphic.png +Type: image/png +Size: 15048 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100416/524d8064/attachment-0009.png +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: pastedGraphic.png +Type: image/png +Size: 5463 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100416/524d8064/attachment-0010.png +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: pastedGraphic.png +Type: image/png +Size: 6912 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100416/524d8064/attachment-0011.png ++ + + + + +
2010/4/16 Levi Bard <taktaktaktaktaktaktaktaktaktak at gmail.com>: +> I thought I'd share some constructive consistency-/polish-related +> feedback on MD's evolving UI, from Unity's Nicholas Francis. +> (Hopefully my mail client hasn't mangled the graphic insertion too badly.) + +It did :/ + +> ===== +> +> Why does the toolbar on the right (don't know what it's called) use a +> smaller widget size and have an underline? + +Not sure why the font size is different. Should probably use the +smaller size in both cases. Please file bug. + +The underline at the bottom is part of the theme. Looks like looks +like a minor vertical positioning inconsistency between the toolbars +is causing the visual inconsistency. Doesn't seem to be reproducible. +Maybe it'll go away when font size it fixed anyway. + +> ================================================================== +> +> I like the less boxed version of the UI, but some details were missed out: +> +> If there's a theme of grey background behind windows, that needs to be +> fairly consistent. This was missed e.g. here: +> +> I'd also make sure the dark border is present here: + +If I understand what you're saying, I think it's an optical illusion, +and the shadow is present, but the adjacent colours make it look +different? + +> ================================================================== +> +> It looks to me like you want to make it look like the +> which-function-am-I-editing-dropdown should take over the entire +> window (which is nice and a lot less noisy than the old version). +> +> However, you've got 5 px at the top (you can see the seperator lines +> don't extend all the way). Also, the top of the toolbar doesn't match +> color with the outline border giving it a weird wavy 'curve' from the +> shading. You also can't click the top 5 px. I'd say you should just +> lose them and pull up the toolbar. + +IIRC the 5px padding is a hardcoded limitations of GtkNotebook, and +will go away when we move to instead use dock frames for the content +area, in MD 2.6. + +> ================================================================== +> Your bordering of scrollviews is inconsistent: +> +> The one on the left is esp. weird: you have a 2px grey inset between +> scrollbars and content, but no hard line. Being a Mac user, I'd just +> lose spacing on both sides. Either way, it should probably be +> consistent. + +The border around the inside of the ScrolledWindow seen on the left is +a GTK issue, IIRC either hardcoded or part of the theme. IMO it's +wasted space, but tricky/impossible to fix in MD itself. + +On the right, we have set the option to add a frame on the inside of +the ScrolledWindow, which wastes *even more* space. We did try +removing it a while ago, but it made the edge of the text editor +surface indistinct in some cases. + +Possibly we need a custom ScrolledWindow to fix these issues properly. + +> ================================================================== +> +> Why is this right side of the status bar darker grey than the left? +> +> Maybe just make the entire status line a bit darker? We do that in +> Unity, and readability is not really a problem (even on 2.2 gamma +> monitors) + +The right side is not part of the status bar. The status bar was +condensed onto the same line as the autohidden pads, saving vertical +space. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + +
On Sat, Apr 17, 2010 at 12:03 AM, Michael Hutchinson +<m.j.hutchinson at gmail.com> wrote: +> 2010/4/16 Levi Bard <taktaktaktaktaktaktaktaktaktak at gmail.com>: +>> Why does the toolbar on the right (don't know what it's called) use a +>> smaller widget size and have an underline? +> +> Not sure why the font size is different. Should probably use the +> smaller size in both cases. Please file bug. + +Fixed in SVN. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + +
Attached is a patch that will let plugins assign their own "Expression +Evaluator" for the debugger. Tested with Delphi Prism (works). + +if oke, I'll check it in. + +-- +Carlo Kok +RemObjects Software +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: custom_expression_evaluator3.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100420/b93b7014/attachment-0001.pl ++ + + + + +
> Attached is a patch that will let plugins assign their own "Expression +> Evaluator" for the debugger. Tested with Delphi Prism (works). + +Should we fallback to the c# evaluator if a better evaluator isn't found? ++ + + + + +
On 4/20/2010 7:39 PM, Levi Bard wrote: +>> Attached is a patch that will let plugins assign their own "Expression +>> Evaluator" for the debugger. Tested with Delphi Prism (works). +> +> Should we fallback to the c# evaluator if a better evaluator isn't found? + + +That's what it does, it uses the NRefactory (C#) parser like it did +before this change when no evaluator can be found. + +-- +Carlo Kok +RemObjects Software ++ + + + + +
>> Should we fallback to the c# evaluator if a better evaluator isn't found? +> +> That's what it does, it uses the NRefactory (C#) parser like it did before +> this change when no evaluator can be found. + +Ah, guess I read it through too quickly. +In that case, I'm on board! ++ + + + + +
Hi, + +Thanks for the patch. It looks good in general, although I have some +comments: + + * Indenting seems to be done with spaces, it should be with tabs. + * Instead of having two handlers in DebuggerSession + (GetExpressionEvaluator and GetAllLocalsHandler), it would be + simpler to just have a single method which returns a + IExpressionEvaluator. + * The evaluators list in DebuggingService should be reset if there + is any change in the evaluators extension point (like what is + done for DebuggerEngines). + +Lluis. + +El dt 20 de 04 de 2010 a les 19:12 +0200, en/na Carlo Kok va escriure: +> Attached is a patch that will let plugins assign their own "Expression +> Evaluator" for the debugger. Tested with Delphi Prism (works). +> +> if oke, I'll check it in. +> +> -- +> Carlo Kok +> RemObjects Software +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + + ++ + + + + +
Hello. +Just a notification. I didn't got any response. + +On Sun, Apr 4, 2010 at 1:13 AM, Alexander M. Batishchev < +abatishchev at godfather.net.ru> wrote: + +> Hi. +> Just want to check the status. Have you read my previous message? +> +> -----Original Message----- +> From: Alexander M. Batishchev [mailto:abatishchev at godfather.net.ru] +> Sent: Thursday, March 11, 2010 8:44 PM +> To: 'Michael Hutchinson' +> Cc: 'monodevelop-devel-list at lists.ximian.com' +> Subject: RE: [Monodevelop-devel] Integration MonoDevelop into Gnome +> +> Hi Michael. +> +> Here is the patch +> Is it correct? (this is my first svn patch) +> +> Have I to open a ticket on Novell Bugzilla? +> +> What more can I do for this topic? +> +> Thanks. +> Alex +> +> -----Original Message----- +> From: Michael Hutchinson [mailto:m.j.hutchinson at gmail.com] +> Sent: Saturday, February 27, 2010 6:42 AM +> To: Alexander M. Batishchev +> Cc: monodevelop-devel-list +> Subject: Re: [Monodevelop-devel] Integration MonoDevelop into Gnome +> +> On Sun, Jan 17, 2010 at 11:12 AM, Alexander M. Batishchev +> <abatishchev at godfather.net.ru> wrote: +> > Also, as far as MonoDevelop opens only first file passed as argument +> > and ignores others and as provided by Desktop Entry Spec, Exec key +> > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.htm +> > l +> > +> > monodevelop.desktop should contain: +> > Exec=monodevelop %f +> > +> > now this key is just: +> > Exec=monodevelop +> > +> > What do you think? +> +> Makes sense. Can you file a patch in bugzilla? +> +> (Sorry for late reply, I lost track of my email...) +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100422/a54774f5/attachment.html ++ + + +
On Thu, Apr 22, 2010 at 8:05 PM, Alexander Batishchev +<abatishchev at godfather.net.ru> wrote: +> Hello. +> Just a notification. I didn't got any response. + +Sorry, I was on vacation till April 19th, and right now I'm still +delayed getting back to the USA because of volcanic ash, and I only +have my Mac laptop with me, so i can't test Gnome stuff till I get +back... + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
On 4/22/2010 6:16 PM, Lluis Sanchez Gual wrote: +> Hi, +> +> Thanks for the patch. It looks good in general, although I have some +> comments: +> +> * Indenting seems to be done with spaces, it should be with tabs. +> * Instead of having two handlers in DebuggerSession +> (GetExpressionEvaluator and GetAllLocalsHandler), it would be +> simpler to just have a single method which returns a +> IExpressionEvaluator. +> * The evaluators list in DebuggingService should be reset if there +> is any change in the evaluators extension point (like what is +> done for DebuggerEngines). +> + +All fixed. New patch attached. + +-- +Carlo Kok +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: custom_expression_evaluator5.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100423/ea5226eb/attachment-0001.pl ++ + + +
Feel free to commit. Thanks! + +El dv 23 de 04 de 2010 a les 09:27 +0200, en/na Carlo Kok va escriure: +> On 4/22/2010 6:16 PM, Lluis Sanchez Gual wrote: +> > Hi, +> > +> > Thanks for the patch. It looks good in general, although I have some +> > comments: +> > +> > * Indenting seems to be done with spaces, it should be with tabs. +> > * Instead of having two handlers in DebuggerSession +> > (GetExpressionEvaluator and GetAllLocalsHandler), it would be +> > simpler to just have a single method which returns a +> > IExpressionEvaluator. +> > * The evaluators list in DebuggingService should be reset if there +> > is any change in the evaluators extension point (like what is +> > done for DebuggerEngines). +> > +> +> All fixed. New patch attached. +> +> -- +> Carlo Kok + + ++ + +
Starting: Sat Apr 3 17:13:44 EDT 2010
+ Ending: Fri Apr 23 05:37:53 EDT 2010
+ Messages: 19
+
+ Last message date:
+ Fri Apr 23 05:37:53 EDT 2010
+ Archived on: Fri Apr 23 05:40:03 EDT 2010
+
+
+
Starting: Sat Apr 3 17:13:44 EDT 2010
+ Ending: Fri Apr 23 05:37:53 EDT 2010
+ Messages: 19
+
+ Last message date:
+ Fri Apr 23 05:37:53 EDT 2010
+ Archived on: Fri Apr 23 05:40:03 EDT 2010
+
+
+
Starting: Sat Apr 3 17:13:44 EDT 2010
+ Ending: Fri Apr 23 05:37:53 EDT 2010
+ Messages: 19
+
+ Last message date:
+ Fri Apr 23 05:37:53 EDT 2010
+ Archived on: Fri Apr 23 05:40:03 EDT 2010
+
+
+
Starting: Sat Apr 3 17:13:44 EDT 2010
+ Ending: Fri Apr 23 05:37:53 EDT 2010
+ Messages: 19
+
+ Last message date:
+ Fri Apr 23 05:37:53 EDT 2010
+ Archived on: Fri Apr 23 05:40:03 EDT 2010
+
+
+
Starting: Sat Apr 3 17:13:44 EDT 2010
+ Ending: Fri Apr 23 05:37:53 EDT 2010
+ Messages: 19
+
+ Last message date:
+ Fri Apr 23 05:37:53 EDT 2010
+ Archived on: Fri Apr 23 05:40:03 EDT 2010
+
+
+
Hi, + +Following the new Mono policy, it is not required to write ChangeLog +entries anymore for commits in MonoDevelop. ChangeLog files will be +generated from the Git history when building the tarballs. + +Also, there are some new policies for writing commit messages and +working on personal work branches. + +Please check the complete guidelines here: + +http://www.mono-project.com/Coding_Guidelines#Git_Workflow_Changes + +Thanks, +Lluis. + ++ + + +
Hi + +Today I finished the coordinate system refactoring. I choose 1 based +coordinates for the text editor. Then the text editor is more compatible +with the coordinates used in monodevelop. + +The main reason I choose the 1 based coordinates for lines/colums is +that I get 1 based coordinates at all inputs and I need to output 1 +based coordinates to the user. Therefore it doesn't make any real sense +to use 0 based coordinates for lines/columns. Most other editors I +looked at seem to use 1 based coordinates too - therefore it's the +'standard' coordinate system. + +All tests are green - but I expect some bugs - I try to cover anything +with unit tests. I'll test it a few days, when I think it's stable I +submit it next week. I mainly did the change because the coordinate +transformation is a cause of hard to find errors and makes the code less +readable. I hope that I can work on the refactoring/code completion +stuff after we finished the version control gui - for refactoring it's a +nightmare to have to transform all the coordinates everytime because +I've to access the parser coordinates and the text editor coordinas +everywhere. + +btw. I've put 2 constants in the document location struct : MinLine and +MinColumn for everyone who doesn't want to check against 1 or 0. + +Regards +Mike ++ + +
Starting: Wed Aug 4 14:43:04 EDT 2010
+ Ending: Fri Aug 20 14:26:35 EDT 2010
+ Messages: 2
+
+ Last message date:
+ Fri Aug 20 14:26:35 EDT 2010
+ Archived on: Fri Aug 20 14:26:44 EDT 2010
+
+
+
Starting: Wed Aug 4 14:43:04 EDT 2010
+ Ending: Fri Aug 20 14:26:35 EDT 2010
+ Messages: 2
+
+ Last message date:
+ Fri Aug 20 14:26:35 EDT 2010
+ Archived on: Fri Aug 20 14:26:44 EDT 2010
+
+
+
Starting: Wed Aug 4 14:43:04 EDT 2010
+ Ending: Fri Aug 20 14:26:35 EDT 2010
+ Messages: 2
+
+ Last message date:
+ Fri Aug 20 14:26:35 EDT 2010
+ Archived on: Fri Aug 20 14:26:44 EDT 2010
+
+
+
Starting: Wed Aug 4 14:43:04 EDT 2010
+ Ending: Fri Aug 20 14:26:35 EDT 2010
+ Messages: 2
+
+ Last message date:
+ Fri Aug 20 14:26:35 EDT 2010
+ Archived on: Fri Aug 20 14:26:44 EDT 2010
+
+
+
Starting: Wed Aug 4 14:43:04 EDT 2010
+ Ending: Fri Aug 20 14:26:35 EDT 2010
+ Messages: 2
+
+ Last message date:
+ Fri Aug 20 14:26:35 EDT 2010
+ Archived on: Fri Aug 20 14:26:44 EDT 2010
+
+
+
Hi, + +Welcome to the list! Any help on the database add-in will be really +welcome. I you fix something in the add-in, feel free to send patches to +this list, and they will be reviewed and applied. + +Thanks! +Lluis. + +El dg 31 de 01 de 2010 a les 23:48 +0100, en/na Juan Francisco Estrada +García va escriure: +> Hi everybody, I just want to introduce myself, my name is +> Juanfra and my nickname is pexi, I'm working as MSSQL DBA +> and SAP Netweaver administrator, I have written some +> applications on asp.net C# that improve my diary job, so I +> like to much the environment monodevelop, and I want help +> to improve the Monodevelop.Database extra, starting by +> SQL Server support because I know it better than another Databases. +> By the way I was reading the code of +> Monodevelop.Database.SQL.SqlServer and I find that it use +> sentences compatible with SQL Server 2000, and does not +> provide 100% compatibility with the new versions (SQL 2005 +> and 2008). +> I don't know what more can I say, only that I want to help +> you in this project, but I don't know how to begin (of +> course reading code, and following the guide +> http://monodevelop.com/Developers) +> +> I think that I could begin updating the sentences for SQL +> Server 2005/2008 and adding the support in the code to +> choose between versions. Other thing that could be improved +> is the support to connect without specifying the port, only +> SERVER\INSTANCE_NAME. +> +> Please let me know if this is a good point to start or not. +> +> P.S.: Sorry about my English. +> +> Best regards +> Pexi. +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + + ++ + + +
+Hi Juan: + Welcome to the list :) I was working on db addin, right now i haven't got time and i stop working on it, but in the next couple of months i will try to get back to work. You are welcome to work on Sql Server Addin, I was having problem testing some couple of fix on this addin beacause i haven't got any full (unlimited) access to Sql Server. The port on sql server connection dialog was introduced by me beacause i was having problems on servers with multiple sql version, i guess (didn't really remember) that it was disabled by default. + + If you have any question don't hesitate to ask me or the list and i will try to help you, i have a pending patch to get "create database" support on Sql Server, i have a lot of TODO's on the project (i could share this TODO), and need some optimizations/fix. I have a pending bug, but i was waiting to have mono DLinQ integration (which is already implemented). + +Bye, Lucian0 + + + + + + + + + + +> From: jfestrada at gmail.com +> To: monodevelop-devel-list at lists.ximian.com +> Date: Sun, 31 Jan 2010 23:48:24 +0100 +> Subject: [Monodevelop-devel] I'm new on the list +> +> Hi everybody, I just want to introduce myself, my name is +> Juanfra and my nickname is pexi, I'm working as MSSQL DBA +> and SAP Netweaver administrator, I have written some +> applications on asp.net C# that improve my diary job, so I +> like to much the environment monodevelop, and I want help +> to improve the Monodevelop.Database extra, starting by +> SQL Server support because I know it better than another Databases. +> By the way I was reading the code of +> Monodevelop.Database.SQL.SqlServer and I find that it use +> sentences compatible with SQL Server 2000, and does not +> provide 100% compatibility with the new versions (SQL 2005 +> and 2008). +> I don't know what more can I say, only that I want to help +> you in this project, but I don't know how to begin (of +> course reading code, and following the guide +> http://monodevelop.com/Developers) +> +> I think that I could begin updating the sentences for SQL +> Server 2005/2008 and adding the support in the code to +> choose between versions. Other thing that could be improved +> is the support to connect without specifying the port, only +> SERVER\INSTANCE_NAME. +> +> Please let me know if this is a good point to start or not. +> +> P.S.: Sorry about my English. +> +> Best regards +> Pexi. +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + +_________________________________________________________________ + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100202/d1f24b7d/attachment-0001.html ++ + + +
Hello all, first, sorry for my bad english, i'm from Brazil. + +So, i'm starting now with MD, and i like to devel an php-gtk front/back-end +in MD. + +Anyone start any project about this? + +Thank you guys! + +- - - +Bruno Pitteli Gonçalves +Desenvolvedor SAP Business One / WEB +scorninpc at gmail.com ++55 018 97958674 + +- - - +ScornInPC - http://blog.scorninpc.com/ +Browse Happy - http://browsehappy.com/ +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100203/e8efefc6/attachment.html ++ + + + +
Please review and submit the patch attached to bug #503462 +<https://bugzilla.novell.com/show_bug.cgi?id=503462>. It fixes the +problem that when opening a .csproj file written by VS, Mono can't find +a reference if it doesn't have a HintPath but it is already in the +output directory. + +Thanks! + Eberhard + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100204/d0ff50fe/attachment.html ++ + + + + + +
Ola Bruno, + +MonoDevelop doesn't currently has any addin to support PHP development directly. +But it does have Addins for non-managed (.NET) languages like Python, +e is conceivable that someone could build one for PHP. + +Welcome, + +Rafael "Monoman" Teixeira +--------------------------------------- +"To be creative means to be in love with life. You can be creative +only if you love life enough that you want to enhance its beauty, you +want to bring a little more music to it, a little more poetry to it, a +little more dance to it." +Osho + + +2010/2/3 Bruno P. Gonçalves <scorninpc at gmail.com>: +> Hello all, first, sorry for my bad english, i'm from Brazil. +> +> So, i'm starting now with MD, and i like to devel an php-gtk front/back-end +> in MD. +> +> Anyone start any project about this? +> +> Thank you guys! +> +> - - - +> Bruno Pitteli Gonçalves +> Desenvolvedor SAP Business One / WEB +> scorninpc at gmail.com +> +55 018 97958674 +> +> - - - +> ScornInPC - http://blog.scorninpc.com/ +> Browse Happy - http://browsehappy.com/ +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> ++ + + +
Ok, nice. + +Can i use Gtk designer in an addin too? + +where i can find documentations about this, i try read monodevelop site, but +very confused, dont have an start, only the manifests files. + +Thanks for replay! + +- - - +Bruno Pitteli Gonçalves +Desenvolvedor SAP Business One / WEB +scorninpc at gmail.com ++55 018 97958674 + +- - - +ScornInPC - http://blog.scorninpc.com/ +Browse Happy - http://browsehappy.com/ + + +2010/2/4 Rafael Teixeira <monoman at gmail.com> + +> Ola Bruno, +> +> MonoDevelop doesn't currently has any addin to support PHP development +> directly. +> But it does have Addins for non-managed (.NET) languages like Python, +> e is conceivable that someone could build one for PHP. +> +> Welcome, +> +> Rafael "Monoman" Teixeira +> --------------------------------------- +> "To be creative means to be in love with life. You can be creative +> only if you love life enough that you want to enhance its beauty, you +> want to bring a little more music to it, a little more poetry to it, a +> little more dance to it." +> Osho +> +> +> 2010/2/3 Bruno P. Gonçalves <scorninpc at gmail.com>: +> > Hello all, first, sorry for my bad english, i'm from Brazil. +> > +> > So, i'm starting now with MD, and i like to devel an php-gtk +> front/back-end +> > in MD. +> > +> > Anyone start any project about this? +> > +> > Thank you guys! +> > +> > - - - +> > Bruno Pitteli Gonçalves +> > Desenvolvedor SAP Business One / WEB +> > scorninpc at gmail.com +> > +55 018 97958674 +> > +> > - - - +> > ScornInPC - http://blog.scorninpc.com/ +> > Browse Happy - http://browsehappy.com/ +> > +> > _______________________________________________ +> > Monodevelop-devel-list mailing list +> > Monodevelop-devel-list at lists.ximian.com +> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> > +> > +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100204/b9ac50b3/attachment.html ++ + + +
The GTK Designer in MonoDevelop is currently tied to C#, and +nevertheless it targets GTK# (the managed bindings of GTK+), so it is +not very useful to generate layouts to use with PHP, unless you're +trying to use Phalanger [1] . + +About using the designer from a new Addin, yes it is possible, as it +is itself an Addin, that exposes it's services to be consumed by other +Addins (the whole IDE is a tree of Addins over the MD Core), You +should study Mono.Addins [2] to better understand MonoDevelop to be +extensible and composable. + +You can also hang around with other Brazilians that like Mono, like +me, at MonoBrasil [3][4]. + +[1] http://php-compiler.net/doku.php?id=core%3aphalanger_for_mono_users +[2] http://www.mono-project.com/Introduction_to_Mono.Addins +[3] http://monobrasil.org/ +[4] monobrasil at googlegroups.com (http://groups.google.com/group/monobrasil) + +Grande abraço, +Have Fun + +Rafael "Monoman" Teixeira +--------------------------------------- +"To be creative means to be in love with life. You can be creative +only if you love life enough that you want to enhance its beauty, you +want to bring a little more music to it, a little more poetry to it, a +little more dance to it." +Osho + +2010/2/4 Bruno P. Gonçalves <scorninpc at gmail.com>: +> Ok, nice. +> +> Can i use Gtk designer in an addin too? +> +> where i can find documentations about this, i try read monodevelop site, but +> very confused, dont have an start, only the manifests files. +> +> Thanks for replay! +> +> - - - +> Bruno Pitteli Gonçalves +> Desenvolvedor SAP Business One / WEB +> scorninpc at gmail.com +> +55 018 97958674 +> +> - - - +> ScornInPC - http://blog.scorninpc.com/ +> Browse Happy - http://browsehappy.com/ +> +> +> 2010/2/4 Rafael Teixeira <monoman at gmail.com> +>> +>> Ola Bruno, +>> +>> MonoDevelop doesn't currently has any addin to support PHP development +>> directly. +>> But it does have Addins for non-managed (.NET) languages like Python, +>> e is conceivable that someone could build one for PHP. +>> +>> Welcome, +>> +>> Rafael "Monoman" Teixeira +>> --------------------------------------- +>> "To be creative means to be in love with life. You can be creative +>> only if you love life enough that you want to enhance its beauty, you +>> want to bring a little more music to it, a little more poetry to it, a +>> little more dance to it." +>> Osho +>> +>> +>> 2010/2/3 Bruno P. Gonçalves <scorninpc at gmail.com>: +>> > Hello all, first, sorry for my bad english, i'm from Brazil. +>> > +>> > So, i'm starting now with MD, and i like to devel an php-gtk +>> > front/back-end +>> > in MD. +>> > +>> > Anyone start any project about this? +>> > +>> > Thank you guys! +>> > +>> > - - - +>> > Bruno Pitteli Gonçalves +>> > Desenvolvedor SAP Business One / WEB +>> > scorninpc at gmail.com +>> > +55 018 97958674 +>> > +>> > - - - +>> > ScornInPC - http://blog.scorninpc.com/ +>> > Browse Happy - http://browsehappy.com/ +>> > +>> > _______________________________________________ +>> > Monodevelop-devel-list mailing list +>> > Monodevelop-devel-list at lists.ximian.com +>> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> > +>> > +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> ++ + +
This patch adds marks (ma; `a) capabilities to the Vi mode of the code +editor. The file +'src/core/Mono.Texteditor/Mono.TextEditor.Vi/ViMode.cs' needs to be +patched. + +I am very new to all this (especially to C#) and suggestions / +comments to improve my code are more than welcome. + +Regards, +Sanjoy Das + +Second Year Undergraduate Student, +Department of Mathematics, +Indian Institute of Technology, Kharagpur. + +http://playingwithpointers.com + +Public Key at http://www.playingwithpointers.com/custom/public_key.txt +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: patchfile +Type: application/octet-stream +Size: 2576 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100216/2dccc0af/attachment-0001.obj ++ + + +
Hi! + +I've been working on adding marks and macros support to the Vi +emulation in MonoDevelop. I posted two (not-so-complete) versions of +what I was working on to the mailing lists yesternight. I've +subsequently discovered some small issues with my code and have +modified it accordingly. + +What I have now is, I think, somewhat complete. I was wondering if +someone could try out the (attached) patch and give me some feedback +(and hopefully get it merged). + +Regards, + +Sanjoy Das + +Second Year Undergraduate Student, +Department of Mathematics, +Indian Institute of Technology, Kharagpur. + +http://playingwithpointers.com + +Public Key at http://playingwithpointers.com/custom/public_key.txt +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: monodevelop.diff +Type: text/x-diff +Size: 9200 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100216/aff26c7f/attachment.bin ++ + + +
> I've been working on adding marks and macros support to the Vi +> emulation in MonoDevelop. I posted two (not-so-complete) versions of +> what I was working on to the mailing lists yesternight. I've +> subsequently discovered some small issues with my code and have +> modified it accordingly. +> +> What I have now is, I think, somewhat complete. I was wondering if +> someone could try out the (attached) patch and give me some feedback +> (and hopefully get it merged). + +Hi Sanjoy, +The macro recording and playback work ok for me; however, the mark +save/load only get me to the recorded line, and not the recorded +position within the line (in vim, if I record a mark in the middle of +the line, it puts me back in the middle of the line). + +With respect to the code, I'd say that ViMark and ViMacro should +probably get their own files in Mono.TextEditor.Vi/. +Finally, the console output should probably come out of the final patch. ;-) + +Other than that, it looks good to me, although I'm sure others +(mhutch) will have more to add. + +Levi (Tak!) + +-- +http://theoatmeal.com/comics/apostrophe +http://homes.eff.org/~barlow/EconomyOfIdeas.html +http://www.gnu.org/philosophy/shouldbefree.html ++ + + +
Hi! + +Thank you for taking out time to review the patch. + +I've attached a new patch containing the mentioned changes. + +Regards, + +Sanjoy Das + +Second Year Undergraduate Student, +Department of Mathematics, +Indian Institute of Technology, Kharagpur. + +http://playingwithpointers.com + +Public Key at http://playingwithpointers.com/custom/public_key.txt +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: monodevelop_2.diff +Type: text/x-diff +Size: 12597 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100216/ecd02bf7/attachment-0001.bin ++ + + +
Hi + +> Several window titles and other dialog elements are not internationalized. +> Shall I just point them out, and someone else will fix them, or is it better if +> I make changes to the source and send patches to the list? +> Or better to the bug tracking system? +> + +This all does work - it's up to you :) +> There are some more places that are not internationalized: +> - the template descriptions (when you select "Insert template") in +> the context menu in the editor + +There was a GetString call missing there (fortunately the descriptions +are translated :)). + +> - the tab titles in "Project Options" -> "Source Code" -> "Source +> Code Formatting" -> "C#" + +Was a missing GetString too. + +> - the tool tips about return types in the editor + +The descriptions are taken from the library documentation - if there is +no library translation installed for the system language we can't do +much about it. + +> - the different file types in the "New File" dialog +> + +Added the missing GetString. + +Regards +Mike + ++ + + +
Hi + +> Is there any non-English documentation for mono? +> On the project website, I couldn't find any. + +No there isn't. I don't know if someone will have the patience to +translate them. + +> +> btw, I did not mean user-defined types, but things like void etc. +> + +I know - these are comments taken from the mono libraries - these +comments need to be translated and these translations need to be +installed. + +Regards +Mike + ++ + + +
Hi + +I've overworked the search result animation a bit. But I bet it could be +made much nicer (I've only limited graphic skills). + +If anybody wants to improve it the code is in: + +src/core/Mono.Texteditor/Mono.TextEditor/TextEditor.cs + +Inside the HighlightSearchResultAnimation ... it should be pretty easy +to understand - with a bit cairo knowledge. + +Regards +Mike + ++ + + +
On Sun, Jan 17, 2010 at 11:12 AM, Alexander M. Batishchev +<abatishchev at godfather.net.ru> wrote: +> Also, as far as MonoDevelop opens only first file passed as argument and +> ignores others +> and as provided by Desktop Entry Spec, Exec key +> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html +> +> monodevelop.desktop should contain: +> Exec=monodevelop %f +> +> now this key is just: +> Exec=monodevelop +> +> What do you think? + +Makes sense. Can you file a patch in bugzilla? + +(Sorry for late reply, I lost track of my email...) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Mon Feb 1 11:43:30 EST 2010
+ Ending: Fri Feb 26 22:42:12 EST 2010
+ Messages: 15
+
+ Last message date:
+ Fri Feb 26 22:42:12 EST 2010
+ Archived on: Fri Feb 26 23:09:16 EST 2010
+
+
+
Starting: Mon Feb 1 11:43:30 EST 2010
+ Ending: Fri Feb 26 22:42:12 EST 2010
+ Messages: 15
+
+ Last message date:
+ Fri Feb 26 22:42:12 EST 2010
+ Archived on: Fri Feb 26 23:09:16 EST 2010
+
+
+
Starting: Mon Feb 1 11:43:30 EST 2010
+ Ending: Fri Feb 26 22:42:12 EST 2010
+ Messages: 15
+
+ Last message date:
+ Fri Feb 26 22:42:12 EST 2010
+ Archived on: Fri Feb 26 23:09:16 EST 2010
+
+
+
Starting: Mon Feb 1 11:43:30 EST 2010
+ Ending: Fri Feb 26 22:42:12 EST 2010
+ Messages: 15
+
+ Last message date:
+ Fri Feb 26 22:42:12 EST 2010
+ Archived on: Fri Feb 26 23:09:16 EST 2010
+
+
+
Starting: Mon Feb 1 11:43:30 EST 2010
+ Ending: Fri Feb 26 22:42:12 EST 2010
+ Messages: 15
+
+ Last message date:
+ Fri Feb 26 22:42:12 EST 2010
+ Archived on: Fri Feb 26 23:09:16 EST 2010
+
+
+
Hello. + +As far as I could find out, MonoDevelop installation script doesn't create a +desktop entry in /usr/share/applications/ +I wish to improve it. + +Were there already done some tasks in this topic? Who does manage this +topic? + +I have read desktop entry spec at +http://standards.freedesktop.org/desktop-entry-spec/latest/ so able to +create one. + +Thanks +Alex + ++ + + +
On Thu, Jan 14, 2010 at 10:26 AM, Alexander M. Batishchev +<abatishchev at godfather.net.ru> wrote: +> Hello. +> +> As far as I could find out, MonoDevelop installation script doesn't create a +> desktop entry in /usr/share/applications/ +> I wish to improve it. +> +> Were there already done some tasks in this topic? Who does manage this +> topic? + +The MD makefile has done this for many years. See the +monodevelop.desktop file in the MD source, and the Makefile.am which +has +desktopdir = $(datadir)/applications +desktop_DATA = monodevelop.desktop + +Perhaps something is wrong with your local install, or you are looking +in the wrong place? For example, if you configure with a prefix of +/usr/local, the .desktop file will be in +/usr/local/share/applications/ + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Hello Michael. + +Thank you for mention /usr/local/share/applications/. Indeed my +monodevelop.desktop is located there. + +Can I suggest to add next mime-types: + +application/x-aspx +application/x-web-config +application/xml or text/xml +application/xhtml+xml +text/html +text/plain + +Thanks. +Alex + +-----Original Message----- +From: Michael Hutchinson [mailto:m.j.hutchinson at gmail.com] +Sent: Sunday, January 17, 2010 9:52 AM +To: Alexander M. Batishchev +Cc: monodevelop-devel-list +Subject: Re: [Monodevelop-devel] Integration MonoDevelop into Gnome + +On Thu, Jan 14, 2010 at 10:26 AM, Alexander M. Batishchev +<abatishchev at godfather.net.ru> wrote: +> Hello. +> +> As far as I could find out, MonoDevelop installation script doesn't create +a +> desktop entry in /usr/share/applications/ +> I wish to improve it. +> +> Were there already done some tasks in this topic? Who does manage this +> topic? + +The MD makefile has done this for many years. See the +monodevelop.desktop file in the MD source, and the Makefile.am which +has +desktopdir = $(datadir)/applications +desktop_DATA = monodevelop.desktop + +Perhaps something is wrong with your local install, or you are looking +in the wrong place? For example, if you configure with a prefix of +/usr/local, the .desktop file will be in +/usr/local/share/applications/ + +-- +Michael Hutchinson +http://mjhutchinson.com + ++ + + +
Also, as far as MonoDevelop opens only first file passed as argument and +ignores others +and as provided by Desktop Entry Spec, Exec key +http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html + +monodevelop.desktop should contain: +Exec=monodevelop %f + +now this key is just: +Exec=monodevelop + +What do you think? + +-----Original Message----- +From: Michael Hutchinson [mailto:m.j.hutchinson at gmail.com] +Sent: Sunday, January 17, 2010 9:52 AM +To: Alexander M. Batishchev +Cc: monodevelop-devel-list +Subject: Re: [Monodevelop-devel] Integration MonoDevelop into Gnome + +On Thu, Jan 14, 2010 at 10:26 AM, Alexander M. Batishchev +<abatishchev at godfather.net.ru> wrote: +> Hello. +> +> As far as I could find out, MonoDevelop installation script doesn't create +a +> desktop entry in /usr/share/applications/ +> I wish to improve it. +> +> Were there already done some tasks in this topic? Who does manage this +> topic? + +The MD makefile has done this for many years. See the +monodevelop.desktop file in the MD source, and the Makefile.am which +has +desktopdir = $(datadir)/applications +desktop_DATA = monodevelop.desktop + +Perhaps something is wrong with your local install, or you are looking +in the wrong place? For example, if you configure with a prefix of +/usr/local, the .desktop file will be in +/usr/local/share/applications/ + +-- +Michael Hutchinson +http://mjhutchinson.com + ++ + + +
Hi all, + +I'm seeking feedback on a proposal to change the locations in which +MonoDevelop stores data. This affects all users, so please have your +say! + +Historically MonoDevelop has stored all data, cache, settings, etc. in +a subdirectory of +Environment.GetFolderPath (Environment.SpecialFolder.ApplicationData). +Typically on Linux/Mac this is /home/$USER/.config/MonoDevelop/ and on +Windows Vista/7 it's C:\Users\$USER\AppData\Roaming\MonoDevelop\. The +path has been accessible via PropertyService.ConfigPath, for addins to +determine where to store their own data. + +There are a few problems here. Firstly, it's not clear to the user +which data need to be backed up and which can be regenerated. It's not +particularly well-structured if one ever needs to look in the +directory and find things. On Windows, all data is in the roaming +profile, which is inefficient with network logins. And on Mac, this +doesn't match the standard ~/Library subdirectories for caches, prefs, +etc. + +I therefore propose that we add more granular locations for different +types of data. Since the migration will be a pain and we will have to +review and set up migrations for all current uses, we may as well get +it *right* first time so it only needs to be done once. + +* UserPreferencesPath: current preferences/settings + Lin: ~/.config/MonoDevelop/Preferences + Mac: ~/Library/Preferences/MonoDevelop/ + Win: ~\AppData\Roaming\MonoDevelop\ Preferences + +* UserDataRoot: Root location for data files created or modifiable by +the user, such as templates, snippets and color schemes. + Lin: ~/.config/MonoDevelop/ + Mac: ~/Library/MonoDevelop/ + Win: ~\AppData\Roaming\MonoDevelop\ + +* UserCachePath: cached data that can be regenerated + Lin: ~/.share/local/MonoDevelop/Cache + Mac: ~/Library/Cache/MonoDevelop/ + Win: ~\AppData\Local\MonoDevelop\Cache + +* UserLogsPath: MD log output and anything similar from addins + Lin: ~/.share/local/MonoDevelop/Logs + Mac: ~/Library/Logs/MonoDevelop/ + Win: ~\AppData\Local\MonoDevelop\Logs + +* UserAddinsPath: addin registry and user-installed addins + Lin: ~/.share/local/MonoDevelop/Addins + Mac: ~/Library/Application Support/MonoDevelop/ + Win: ~\AppData\Local\MonoDevelop\Addins + +In summary, the contents of UserPreferencesPath and UserDataRoot +should be backed up. + +I also intend to add FileService.MigratePath (string +oldRelativeConfigPath, string newFullPath, bool removeEmpty) call that +can be used to migrate files and folders from an old path to a new +path. This can be used to move files and directories to the new +locations. + +There is also the question of whether some of these directories should +be versioned so that multiple MD versions can be used in parallel on +one user profile. I don't think it's worth the maintenance burden; in +general we've only ever supported forward migrations properly. Perhaps +we should have an error message if you try to run MD with too-new +settings/data formats, or alter all the location properties to point +to some dummy temp location so you can run the older version without +corrupting your newer settings. + +You can see the current patch at http://monobin.com/__d215cffd5 if +you're curious. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Just a comment on supportting mutliple versions of MD. + +In Windows it is very common to have many versions of VisualStudio, as +they've made it hard to compile old solutions in a really compatible +way (they are changing the look of things with VS2010 that, as newer +versions of MD, can compile targetting different versions of the +framework), but I still have 4 versions of VisualStudio in my +workstation (2003, 2005, 2008 and 2010 beta) and 3 on our build +servers (no 2010 beta), and they open correctly their respective +solutions/projects and don't interfere with each other (In truth .sln +files are associated with a helper VisualStudio-Version auto-selector +application). + +Said that, I don't think MD needs to support multiple released +versions installed side-by-side, but it would be nice if a development +(or preview/beta release), could be installed to another prefix and +could take it in account to keep per-user data in a separate root: + +For instance a development build installed to \usr\local prefix could +use \usr\local\home\$User\ or perhaps \home\$User\.local\ +in linux. Or perhaps, all your suggested paths would use +MonoDevelopPreview instead of MonoDevelop, for non-release builds. + +That would allow to also concoct tests for configuration migration +between versions of MD and of independently released addins, even +after your proposed wholesale migration. + +Just my thoughts, + +Rafael "Monoman" Teixeira +--------------------------------------- +"To be creative means to be in love with life. You can be creative +only if you love life enough that you want to enhance its beauty, you +want to bring a little more music to it, a little more poetry to it, a +little more dance to it." +Osho + + + +On Fri, Jan 22, 2010 at 3:25 AM, Michael Hutchinson +<m.j.hutchinson at gmail.com> wrote: +> Hi all, +> +> I'm seeking feedback on a proposal to change the locations in which +> MonoDevelop stores data. This affects all users, so please have your +> say! +> +> Historically MonoDevelop has stored all data, cache, settings, etc. in +> a subdirectory of +> Environment.GetFolderPath (Environment.SpecialFolder.ApplicationData). +> Typically on Linux/Mac this is /home/$USER/.config/MonoDevelop/ and on +> Windows Vista/7 it's C:\Users\$USER\AppData\Roaming\MonoDevelop\. The +> path has been accessible via PropertyService.ConfigPath, for addins to +> determine where to store their own data. +> +> There are a few problems here. Firstly, it's not clear to the user +> which data need to be backed up and which can be regenerated. It's not +> particularly well-structured if one ever needs to look in the +> directory and find things. On Windows, all data is in the roaming +> profile, which is inefficient with network logins. And on Mac, this +> doesn't match the standard ~/Library subdirectories for caches, prefs, +> etc. +> +> I therefore propose that we add more granular locations for different +> types of data. Since the migration will be a pain and we will have to +> review and set up migrations for all current uses, we may as well get +> it *right* first time so it only needs to be done once. +> +> * UserPreferencesPath: current preferences/settings +> Lin: ~/.config/MonoDevelop/Preferences +> Mac: ~/Library/Preferences/MonoDevelop/ +> Win: ~\AppData\Roaming\MonoDevelop\ Preferences +> +> * UserDataRoot: Root location for data files created or modifiable by +> the user, such as templates, snippets and color schemes. +> Lin: ~/.config/MonoDevelop/ +> Mac: ~/Library/MonoDevelop/ +> Win: ~\AppData\Roaming\MonoDevelop\ +> +> * UserCachePath: cached data that can be regenerated +> Lin: ~/.share/local/MonoDevelop/Cache +> Mac: ~/Library/Cache/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Cache +> +> * UserLogsPath: MD log output and anything similar from addins +> Lin: ~/.share/local/MonoDevelop/Logs +> Mac: ~/Library/Logs/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Logs +> +> * UserAddinsPath: addin registry and user-installed addins +> Lin: ~/.share/local/MonoDevelop/Addins +> Mac: ~/Library/Application Support/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Addins +> +> In summary, the contents of UserPreferencesPath and UserDataRoot +> should be backed up. +> +> I also intend to add FileService.MigratePath (string +> oldRelativeConfigPath, string newFullPath, bool removeEmpty) call that +> can be used to migrate files and folders from an old path to a new +> path. This can be used to move files and directories to the new +> locations. +> +> There is also the question of whether some of these directories should +> be versioned so that multiple MD versions can be used in parallel on +> one user profile. I don't think it's worth the maintenance burden; in +> general we've only ever supported forward migrations properly. Perhaps +> we should have an error message if you try to run MD with too-new +> settings/data formats, or alter all the location properties to point +> to some dummy temp location so you can run the older version without +> corrupting your newer settings. +> +> You can see the current patch at http://monobin.com/__d215cffd5 if +> you're curious. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> ++ + + +
On 1/22/2010 3:11 PM, Rafael Teixeira wrote: +> Just a comment on supportting mutliple versions of MD. +> +> In Windows it is very common to have many versions of VisualStudio, as +> they've made it hard to compile old solutions in a really compatible +> way (they are changing the look of things with VS2010 that, as newer +> versions of MD, can compile targetting different versions of the +> framework), but I still have 4 versions of VisualStudio in my +> workstation (2003, 2005, 2008 and 2010 beta) and 3 on our build +> servers (no 2010 beta), and they open correctly their respective +> solutions/projects and don't interfere with each other (In truth .sln +> files are associated with a helper VisualStudio-Version auto-selector +> application). +> +> Said that, I don't think MD needs to support multiple released +> versions installed side-by-side, but it would be nice if a development +> (or preview/beta release), could be installed to another prefix and +> could take it in account to keep per-user data in a separate root: +> +> For instance a development build installed to \usr\local prefix could +> use \usr\local\home\$User\ or perhaps \home\$User\.local\ +> in linux. Or perhaps, all your suggested paths would use +> MonoDevelopPreview instead of MonoDevelop, for non-release builds. +> +> That would allow to also concoct tests for configuration migration +> between versions of MD and of independently released addins, even +> after your proposed wholesale migration. +> + +One easy way to do this would be like Firefox and even Visual Studio +does it, is a "profile". You can start it with --profile "profilename" +and it uses a different directory store the settings (and plugin cache). + +-- +Carlo Kok + +RemObjects Software +The Infrastructure Company +http://www.remobjects.com ++ + + + + + +
+Hello everyone, this is my first post and I hope you can help. Sorry for my +English. + +The issue is this: I have problems with the ide monodevelop because I can +not see anywhere the menu bar. Only the icons are shown under it but nothing +from the menu bar. I installed version 2.2 from ppa repositories (https: / / +launchpad.net / ~ directhex / + archive / monoxide). Thanks for the help +-- +View this message in context: http://n2.nabble.com/NO-MENU-BAR-IN-MONODEVELOP-IN-UBUNTU-KARMIC-tp4438873p4438873.html +Sent from the Mono - MonoDevelop - Dev mailing list archive at Nabble.com. ++ + + + + + + +
this is not a suggestion, just an idea that I once read about +what about storing UserPreferences in a single sqlite db file? I heard that +would be better than a lot of text files (if they are a lot) +u don't have to reply to my message, as I said I'm not trying to really +suggest something + +On Fri, Jan 22, 2010 at 7:25 AM, Michael Hutchinson < +m.j.hutchinson at gmail.com> wrote: + +> Hi all, +> +> I'm seeking feedback on a proposal to change the locations in which +> MonoDevelop stores data. This affects all users, so please have your +> say! +> +> Historically MonoDevelop has stored all data, cache, settings, etc. in +> a subdirectory of +> Environment.GetFolderPath (Environment.SpecialFolder.ApplicationData). +> Typically on Linux/Mac this is /home/$USER/.config/MonoDevelop/ and on +> Windows Vista/7 it's C:\Users\$USER\AppData\Roaming\MonoDevelop\. The +> path has been accessible via PropertyService.ConfigPath, for addins to +> determine where to store their own data. +> +> There are a few problems here. Firstly, it's not clear to the user +> which data need to be backed up and which can be regenerated. It's not +> particularly well-structured if one ever needs to look in the +> directory and find things. On Windows, all data is in the roaming +> profile, which is inefficient with network logins. And on Mac, this +> doesn't match the standard ~/Library subdirectories for caches, prefs, +> etc. +> +> I therefore propose that we add more granular locations for different +> types of data. Since the migration will be a pain and we will have to +> review and set up migrations for all current uses, we may as well get +> it *right* first time so it only needs to be done once. +> +> * UserPreferencesPath: current preferences/settings +> Lin: ~/.config/MonoDevelop/Preferences +> Mac: ~/Library/Preferences/MonoDevelop/ +> Win: ~\AppData\Roaming\MonoDevelop\ Preferences +> +> * UserDataRoot: Root location for data files created or modifiable by +> the user, such as templates, snippets and color schemes. +> Lin: ~/.config/MonoDevelop/ +> Mac: ~/Library/MonoDevelop/ +> Win: ~\AppData\Roaming\MonoDevelop\ +> +> * UserCachePath: cached data that can be regenerated +> Lin: ~/.share/local/MonoDevelop/Cache +> Mac: ~/Library/Cache/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Cache +> +> * UserLogsPath: MD log output and anything similar from addins +> Lin: ~/.share/local/MonoDevelop/Logs +> Mac: ~/Library/Logs/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Logs +> +> * UserAddinsPath: addin registry and user-installed addins +> Lin: ~/.share/local/MonoDevelop/Addins +> Mac: ~/Library/Application Support/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Addins +> +> In summary, the contents of UserPreferencesPath and UserDataRoot +> should be backed up. +> +> I also intend to add FileService.MigratePath (string +> oldRelativeConfigPath, string newFullPath, bool removeEmpty) call that +> can be used to migrate files and folders from an old path to a new +> path. This can be used to move files and directories to the new +> locations. +> +> There is also the question of whether some of these directories should +> be versioned so that multiple MD versions can be used in parallel on +> one user profile. I don't think it's worth the maintenance burden; in +> general we've only ever supported forward migrations properly. Perhaps +> we should have an error message if you try to run MD with too-new +> settings/data formats, or alter all the location properties to point +> to some dummy temp location so you can run the older version without +> corrupting your newer settings. +> +> You can see the current patch at http://monobin.com/__d215cffd5 if +> you're curious. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> _______________________________________________ +> Monodevelop-list mailing list +> Monodevelop-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-list +> + + + +-- +A.M. Abdelaziz +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100122/fc1ac217/attachment.html ++ + + + + +
On Fri, Jan 22, 2010 at 9:11 AM, Rafael Teixeira <monoman at gmail.com> wrote: +> Just a comment on supportting mutliple versions of MD. +> +> In Windows it is very common to have many versions of VisualStudio, as +> they've made it hard to compile old solutions in a really compatible +> way (they are changing the look of things with VS2010 that, as newer +> versions of MD, can compile targetting different versions of the +> framework), but I still have 4 versions of VisualStudio in my +> workstation (2003, 2005, 2008 and 2010 beta) and 3 on our build +> servers (no 2010 beta), and they open correctly their respective +> solutions/projects and don't interfere with each other (In truth .sln +> files are associated with a helper VisualStudio-Version auto-selector +> application). +> +> Said that, I don't think MD needs to support multiple released +> versions installed side-by-side, but it would be nice if a development +> (or preview/beta release), could be installed to another prefix and +> could take it in account to keep per-user data in a separate root: +> +> For instance a development build installed to \usr\local prefix could +> use \usr\local\home\$User\ or perhaps \home\$User\.local\ +> in linux. Or perhaps, all your suggested paths would use +> MonoDevelopPreview instead of MonoDevelop, for non-release builds. +> +> That would allow to also concoct tests for configuration migration +> between versions of MD and of independently released addins, even +> after your proposed wholesale migration. + +On Linux you can override the ~/local/share and ~/.config with +environment variables XDG_DATA_HOME and XDG_CONFIG_HOME. +http://go-mono.com/docs/index.aspx?link=T%3aSystem.Environment.SpecialFolder + +And we could easily add another env var to override the location +properties in MD. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Fri, Jan 22, 2010 at 9:40 AM, Carlo Kok <ck at carlo-kok.com> wrote: +> One easy way to do this would be like Firefox and even Visual Studio +> does it, is a "profile". You can start it with --profile "profilename" +> and it uses a different directory store the settings (and plugin cache). + +We could just have --profile take a full path. Then, on all platforms, use +$PROFILE/Data +$PROFILE/Cache +$PROFILE/Preferences +$PROFILE/Logs + +But I'd still like to get the "default" locations correct, because +most users will not want to bother with profiles. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
On Sat, Jan 23, 2010 at 11:58 AM, Martin Olsson <mnemo at minimum.se> wrote: +> I didn't read the original post, but I hope you read and +> considered these: +> +> http://brainstorm.ubuntu.com/idea/6557/ +> http://live.gnome.org/GnomeGoals/XDGConfigFolders + +Yes, I am aware of the XDG specs, as you'd know if you'd read my +proposal. XDG_CONFIG_HOME and XDG_DATA_HOME are the values that Mono +uses for Environment.GetFolderPath +(Environment.SpecialFolder.ApplicationData) and +Environment.GetFolderPath +(Environment.SpecialFolder.LocalAppplicationData) on Linux. + +We should probably use XDG_CACHE_HOME too though, i.e. +* UserCachePath: ~/.cache/MonoDevelop + +I'm not convinced that that we should use XDG_DATA_HOME for MD user +data like templates and key binding schemes though, because its name +implies that it's local data, not roaming data. So I suggest we +continue to use XDG_CONFIG_HOME for these. It doesn't look like I'm +the only one reading it this way either: +http://trac.transmissionbt.com/ticket/684#comment:14 and +http://www.opensubscriber.com/message/xdg@lists.freedesktop.org/9346540.html + +> Also please partition preferences etc so that multi machine +> cloud synchronization becomes easy. + +That was one of my goals, though driven by the Windows Roaming/Local +profile directories. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
I didn't read the original post, but I hope you read and +considered these: + +http://brainstorm.ubuntu.com/idea/6557/ +http://live.gnome.org/GnomeGoals/XDGConfigFolders + +Also please partition preferences etc so that multi machine +cloud synchronization becomes easy. + + + Martin + +Michael Hutchinson wrote: +> Hi all, +> +> I'm seeking feedback on a proposal to change the locations in which +> MonoDevelop stores data. This affects all users, so please have your +> say! +> +> Historically MonoDevelop has stored all data, cache, settings, etc. in +> a subdirectory of +> Environment.GetFolderPath (Environment.SpecialFolder.ApplicationData). +> Typically on Linux/Mac this is /home/$USER/.config/MonoDevelop/ and on +> Windows Vista/7 it's C:\Users\$USER\AppData\Roaming\MonoDevelop\. The +> path has been accessible via PropertyService.ConfigPath, for addins to +> determine where to store their own data. +> +> There are a few problems here. Firstly, it's not clear to the user +> which data need to be backed up and which can be regenerated. It's not +> particularly well-structured if one ever needs to look in the +> directory and find things. On Windows, all data is in the roaming +> profile, which is inefficient with network logins. And on Mac, this +> doesn't match the standard ~/Library subdirectories for caches, prefs, +> etc. +> +> I therefore propose that we add more granular locations for different +> types of data. Since the migration will be a pain and we will have to +> review and set up migrations for all current uses, we may as well get +> it *right* first time so it only needs to be done once. +> +> * UserPreferencesPath: current preferences/settings +> Lin: ~/.config/MonoDevelop/Preferences +> Mac: ~/Library/Preferences/MonoDevelop/ +> Win: ~\AppData\Roaming\MonoDevelop\ Preferences +> +> * UserDataRoot: Root location for data files created or modifiable by +> the user, such as templates, snippets and color schemes. +> Lin: ~/.config/MonoDevelop/ +> Mac: ~/Library/MonoDevelop/ +> Win: ~\AppData\Roaming\MonoDevelop\ +> +> * UserCachePath: cached data that can be regenerated +> Lin: ~/.share/local/MonoDevelop/Cache +> Mac: ~/Library/Cache/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Cache +> +> * UserLogsPath: MD log output and anything similar from addins +> Lin: ~/.share/local/MonoDevelop/Logs +> Mac: ~/Library/Logs/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Logs +> +> * UserAddinsPath: addin registry and user-installed addins +> Lin: ~/.share/local/MonoDevelop/Addins +> Mac: ~/Library/Application Support/MonoDevelop/ +> Win: ~\AppData\Local\MonoDevelop\Addins +> +> In summary, the contents of UserPreferencesPath and UserDataRoot +> should be backed up. +> +> I also intend to add FileService.MigratePath (string +> oldRelativeConfigPath, string newFullPath, bool removeEmpty) call that +> can be used to migrate files and folders from an old path to a new +> path. This can be used to move files and directories to the new +> locations. +> +> There is also the question of whether some of these directories should +> be versioned so that multiple MD versions can be used in parallel on +> one user profile. I don't think it's worth the maintenance burden; in +> general we've only ever supported forward migrations properly. Perhaps +> we should have an error message if you try to run MD with too-new +> settings/data formats, or alter all the location properties to point +> to some dummy temp location so you can run the older version without +> corrupting your newer settings. +> +> You can see the current patch at http://monobin.com/__d215cffd5 if +> you're curious. +> + ++ + +
Hi everybody, I just want to introduce myself, my name is +Juanfra and my nickname is pexi, I'm working as MSSQL DBA +and SAP Netweaver administrator, I have written some +applications on asp.net C# that improve my diary job, so I +like to much the environment monodevelop, and I want help +to improve the Monodevelop.Database extra, starting by +SQL Server support because I know it better than another Databases. +By the way I was reading the code of +Monodevelop.Database.SQL.SqlServer and I find that it use +sentences compatible with SQL Server 2000, and does not +provide 100% compatibility with the new versions (SQL 2005 +and 2008). +I don't know what more can I say, only that I want to help +you in this project, but I don't know how to begin (of +course reading code, and following the guide +http://monodevelop.com/Developers) + +I think that I could begin updating the sentences for SQL +Server 2005/2008 and adding the support in the code to +choose between versions. Other thing that could be improved +is the support to connect without specifying the port, only +SERVER\INSTANCE_NAME. + +Please let me know if this is a good point to start or not. + +P.S.: Sorry about my English. + +Best regards +Pexi. + ++ + +
Starting: Thu Jan 14 10:26:39 EST 2010
+ Ending: Sun Jan 31 17:48:24 EST 2010
+ Messages: 14
+
+ Last message date:
+ Sun Jan 31 17:48:24 EST 2010
+ Archived on: Sun Jan 31 17:53:45 EST 2010
+
+
+
Starting: Thu Jan 14 10:26:39 EST 2010
+ Ending: Sun Jan 31 17:48:24 EST 2010
+ Messages: 14
+
+ Last message date:
+ Sun Jan 31 17:48:24 EST 2010
+ Archived on: Sun Jan 31 17:53:45 EST 2010
+
+
+
Starting: Thu Jan 14 10:26:39 EST 2010
+ Ending: Sun Jan 31 17:48:24 EST 2010
+ Messages: 14
+
+ Last message date:
+ Sun Jan 31 17:48:24 EST 2010
+ Archived on: Sun Jan 31 17:53:45 EST 2010
+
+
+
Starting: Thu Jan 14 10:26:39 EST 2010
+ Ending: Sun Jan 31 17:48:24 EST 2010
+ Messages: 14
+
+ Last message date:
+ Sun Jan 31 17:48:24 EST 2010
+ Archived on: Sun Jan 31 17:53:45 EST 2010
+
+
+
Starting: Thu Jan 14 10:26:39 EST 2010
+ Ending: Sun Jan 31 17:48:24 EST 2010
+ Messages: 14
+
+ Last message date:
+ Sun Jan 31 17:48:24 EST 2010
+ Archived on: Sun Jan 31 17:53:45 EST 2010
+
+
+
Hello,
+
+I noticed that MD 2.4 intellisense doesn't show the members for delegates
+but only the inherited from System.Object. So I compiled MD and decide that
+*CSharpTextEditorCompletion.CreateCompletionData() *would be a good start to
+improve this functionality (I didn't see any open issue or bug regarding
+this in the lists). So far I added something like:
+
+ CSharpAmbience ambience = new CSharpAmbience ();
+ IType type = dom.GetType (resolveResult.ResolvedType);
+
+ string strType = ambience.GetString (type,
+OutputFlags.ReformatDelegates | OutputFlags.IncludeParameterName |
+OutputFlags.IncludeKeywords | OutputFlags.UseFullName);
+ Console.WriteLine("Type is " + strType);
+
+ if (strType.StartsWith("delegate"))
+ {
+ type.BaseType = new
+DomReturnType("System.MulticastDelegate");
+ }
+
+in the mentioned method just to see if that works (and somehow it does). Of
+course is not the solution because:
+
+ - I think that the type should be assigned while the DOM structure is
+ created and not in that method.
+ - It doesn't generate (or simulate) the sealed class with the
+members *BeginInvoke(),
+ EndInvoke()*.
+
+Right now I'm facing the first problem but honestly is a bit difficult to
+work with the code since I don't clearly see how the classes interacts. So
+the question is if you could briefly describe where do you think I should
+make the first change (set the right DomReturnType to the delegates) or what
+are the responsibilities of the classes involved in this functionality:
+CSharpTextEditorCompletion, ProjectDom, Ambience, NRefactoryResolver,
+ResolveResult
+
+Thanks in advance,
+D.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100608/9343345e/attachment.html
+
+
+
+ Starting: Tue Jun 8 08:29:37 EDT 2010
+ Ending: Tue Jun 8 08:29:37 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Tue Jun 8 08:29:37 EDT 2010
+ Archived on: Tue Jun 8 08:29:41 EDT 2010
+
+
+
Starting: Tue Jun 8 08:29:37 EDT 2010
+ Ending: Tue Jun 8 08:29:37 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Tue Jun 8 08:29:37 EDT 2010
+ Archived on: Tue Jun 8 08:29:41 EDT 2010
+
+
+
Starting: Tue Jun 8 08:29:37 EDT 2010
+ Ending: Tue Jun 8 08:29:37 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Tue Jun 8 08:29:37 EDT 2010
+ Archived on: Tue Jun 8 08:29:41 EDT 2010
+
+
+
Starting: Tue Jun 8 08:29:37 EDT 2010
+ Ending: Tue Jun 8 08:29:37 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Tue Jun 8 08:29:37 EDT 2010
+ Archived on: Tue Jun 8 08:29:41 EDT 2010
+
+
+
Starting: Tue Jun 8 08:29:37 EDT 2010
+ Ending: Tue Jun 8 08:29:37 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Tue Jun 8 08:29:37 EDT 2010
+ Archived on: Tue Jun 8 08:29:41 EDT 2010
+
+
+
Hi Michael. + +Sure, I can. Will do this shortly. + +Thanks. +Alex + +-----Original Message----- +From: Michael Hutchinson [mailto:m.j.hutchinson at gmail.com] +Sent: Saturday, February 27, 2010 6:42 AM +To: Alexander M. Batishchev +Cc: monodevelop-devel-list +Subject: Re: [Monodevelop-devel] Integration MonoDevelop into Gnome + +On Sun, Jan 17, 2010 at 11:12 AM, Alexander M. Batishchev +<abatishchev at godfather.net.ru> wrote: +> Also, as far as MonoDevelop opens only first file passed as argument and +> ignores others +> and as provided by Desktop Entry Spec, Exec key +> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html +> +> monodevelop.desktop should contain: +> Exec=monodevelop %f +> +> now this key is just: +> Exec=monodevelop +> +> What do you think? + +Makes sense. Can you file a patch in bugzilla? + +(Sorry for late reply, I lost track of my email...) + +-- +Michael Hutchinson +http://mjhutchinson.com + ++ + + +
Hi, +First an introduction; I am Nikhil Sarda, a 4th yr undergraduate at IIT +Kharagpur majoring in Maths and Computing. I have been wanting to contribute +to the Mono project and MonoDevelop in particular for a very long time and +this is a step towards that direction. I hacked Mike Krueger's original code +and added a bunch of stuff myself such as, depth of inheritance tree, +cyclometric complexity, fan out and so on. I was helped immensely along the +way by Michael Hutchinson and Levi Bard. Here is the code +http://monodevelopcodemetrics.googlecode.com/files/MonoDevelop.CodeMetrics_alpha1.tar.gz +A lot of stuff needs to be added and the code needs to be polished a lot, +but its a start I guess. +Thanks for your time +Nikhil Sarda +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100309/20614bee/attachment.html ++ + + +
Hi Michael. + +Here is the patch +Is it correct? (this is my first svn patch) + +Have I to open a ticket on Novell Bugzilla? + +What more can I do for this topic? + +Thanks. +Alex + +-----Original Message----- +From: Michael Hutchinson [mailto:m.j.hutchinson at gmail.com] +Sent: Saturday, February 27, 2010 6:42 AM +To: Alexander M. Batishchev +Cc: monodevelop-devel-list +Subject: Re: [Monodevelop-devel] Integration MonoDevelop into Gnome + +On Sun, Jan 17, 2010 at 11:12 AM, Alexander M. Batishchev +<abatishchev at godfather.net.ru> wrote: +> Also, as far as MonoDevelop opens only first file passed as argument and +> ignores others +> and as provided by Desktop Entry Spec, Exec key +> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html +> +> monodevelop.desktop should contain: +> Exec=monodevelop %f +> +> now this key is just: +> Exec=monodevelop +> +> What do you think? + +Makes sense. Can you file a patch in bugzilla? + +(Sorry for late reply, I lost track of my email...) + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: monodevelop.desktop.diff +Type: application/octet-stream +Size: 967 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100311/c90803f3/attachment.obj ++ + + +
Hi, + +We are planning a reorganization of the MonoDevelop code which involves +merging some of the assemblies. The goal is to reduce the number of +assemblies that need to be loaded, and to make it easier to link against +the core assemblies. There will be two main core assemblies: + + * New MonoDevelop.Core, which will contain the classes from: + * MonoDevelop.Core + * MonoDevelop.Projects + + * New MonoDevelop.IDE, with the classes from: + * Mono.TextEditor + * MonoDevelop.Components + * MonoDevelop.Dock + * MonoDevelop.Core.Gui + * MonoDevelop.Projects.Gui + * MonoDevelop.Ide + +Other assemblies in Core won't change for now. + +There will be some namespace changes too: + + * The MonoDevelop.Core.Gui will go away. Some classes will be + moved to MonoDevelop.Components and some to + MonoDevelop.Ide.Components. + * Classes MonoDevelop.Projects.Gui.* will be moved to + MonoDevelop.Ide.* + +The idea is to keep the classes in Mono.* and MonoDevelop.Components.* +namespaces independent from the IDE infrastructure (even if they live in +the same assembly), so that they can be reused in other projects. + +I plan to do the changes tomorrow, so if you are doing changes in any of +the core assemblies, make sure they are committed today (or you'll have +to deal with the conflicts). + +Lluis. + + ++ + + + +
Greetings all, + +My name is Eugene Kulabuhov and I am a student, studying IT and +Electronics at Aarhus Technical College in Denmark. +I'm looking forward to join you in this year's Google Summer of Code program. + +I am newbie to open source development and MonoDevelop particularly. +So I've been hacking using the latest version of MonoDevelop for a few +a days now. +And I have few questions: + +1. Now I was thinking about adding some performance gain features, +like the ones found in ReSharper for Visual Studio. But I'm not sure, +if those features are welcome? I've seen your to-do list and it +doesn't say anything about it. So my question is, who should I ask, if +I wanted to work on those features? + +2. I'm investigating few bugs from BugZilla. And I found the code +responsible for that bug, but as code is quite complex, I need to +clarify few things about the code before doing any fixes. Should I +contact the owner of that particular file? Or ask the question in this +list? + +Thank you, +Eugene. ++ + + + +
El dl 15 de 03 de 2010 a les 17:13 +0100, en/na Eugene K va escriure: +> Greetings all, +> +> My name is Eugene Kulabuhov and I am a student, studying IT and +> Electronics at Aarhus Technical College in Denmark. +> I'm looking forward to join you in this year's Google Summer of Code program. +> +> I am newbie to open source development and MonoDevelop particularly. +> So I've been hacking using the latest version of MonoDevelop for a few +> a days now. +> And I have few questions: +> +> 1. Now I was thinking about adding some performance gain features, +> like the ones found in ReSharper for Visual Studio. But I'm not sure, +> if those features are welcome? I've seen your to-do list and it +> doesn't say anything about it. So my question is, who should I ask, if +> I wanted to work on those features? + +Yes, refactoring features are welcome. You can ask in this list if you +have questions about it. + +> +> 2. I'm investigating few bugs from BugZilla. And I found the code +> responsible for that bug, but as code is quite complex, I need to +> clarify few things about the code before doing any fixes. Should I +> contact the owner of that particular file? Or ask the question in this +> list? + +Better ask in this list, since people other than the author may also +help. + +Lluis. + + ++ + + + +
I'm done with the merge. After updating from SVN, you'll have to do a +full rebuild with ./configure && make clean && make. Also, if you +installed MD with 'make install', you'll have to clean the install +directory before installing again. + +Lluis. + + +El dl 15 de 03 de 2010 a les 16:46 +0100, en/na Lluis Sanchez Gual va +escriure: +> Hi, +> +> We are planning a reorganization of the MonoDevelop code which involves +> merging some of the assemblies. The goal is to reduce the number of +> assemblies that need to be loaded, and to make it easier to link against +> the core assemblies. There will be two main core assemblies: +> +> * New MonoDevelop.Core, which will contain the classes from: +> * MonoDevelop.Core +> * MonoDevelop.Projects +> +> * New MonoDevelop.IDE, with the classes from: +> * Mono.TextEditor +> * MonoDevelop.Components +> * MonoDevelop.Dock +> * MonoDevelop.Core.Gui +> * MonoDevelop.Projects.Gui +> * MonoDevelop.Ide +> +> Other assemblies in Core won't change for now. +> +> There will be some namespace changes too: +> +> * The MonoDevelop.Core.Gui will go away. Some classes will be +> moved to MonoDevelop.Components and some to +> MonoDevelop.Ide.Components. +> * Classes MonoDevelop.Projects.Gui.* will be moved to +> MonoDevelop.Ide.* +> +> The idea is to keep the classes in Mono.* and MonoDevelop.Components.* +> namespaces independent from the IDE infrastructure (even if they live in +> the same assembly), so that they can be reused in other projects. +> +> I plan to do the changes tomorrow, so if you are doing changes in any of +> the core assemblies, make sure they are committed today (or you'll have +> to deal with the conflicts). +> +> Lluis. +> +> + + ++ + +
Hello. This patch will fix the tooltip appearing over method names, +adding missing Method tag and overload count. + +Best regards, +Eugene Kulabuhov. +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: change.patch +Type: application/octet-stream +Size: 2869 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100322/19eec732/attachment.obj ++ + + +
Hi + +Patch submitted. + +Thanks +Mike + ++ + + +
It wasn't getting used, it was needlessly referenced and needlessly +imported with using statements. + +But Mono.Data is gone, so this is needed to build against a fresh mono +trunk HEAD +-- +Jay + + +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: monodevelop.removeMono.Data.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100325/26136e91/attachment.pl ++ + + + +
MonoDevelop AddinAuthoring updated for some MD Core namespace renames or +class moves + +-- +Jay + + +-------------- next part -------------- +An embedded and charset-unspecified text was scrubbed... +Name: monodevelop-fix-AddinAuthoring.patch +Url: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100325/5137d67d/attachment-0001.pl ++ + + + + +
+Hi, + +how can i set the correct path to xsp/xsp2 in monodevelop unter windows? I +usw the mono 2.6.3 runtime but every webservice app will not start from +monodevelop 2.2.2. Because the IDE try to start the mono.exe not the xsp.exe +or xsp2.exe :( + +If i use the ms .net runtime for my projects every thing is fine, because +the IDE use the xsp2.exe in the IDE directory. But i want to test/debug my +apps on the mono runtime. + +These are my first experience with mono. So if someone has a solution for my +problem, pls explain them step by step :) + +with kind regards +Taki + +ps. my OS is windows 7 pro 32bit +-- +View this message in context: http://n2.nabble.com/How-to-set-XSP-XSP2-path-in-MonoDevelop-under-Windows-tp4804290p4804290.html +Sent from the Mono - MonoDevelop - Dev mailing list archive at Nabble.com. ++ + + + + +
Committed. Thanks! + +El dj 25 de 03 de 2010 a les 22:49 -0400, en/na Jay R. Wren va escriure: +> It wasn't getting used, it was needlessly referenced and needlessly +> imported with using statements. +> +> But Mono.Data is gone, so this is needed to build against a fresh mono +> trunk HEAD +> -- +> Jay +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + + ++ + +
Committed. Thanks! + +El dj 25 de 03 de 2010 a les 22:50 -0400, en/na Jay R. Wren va escriure: +> MonoDevelop AddinAuthoring updated for some MD Core namespace renames or +> class moves +> +> -- +> Jay +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + + ++ + +
El dv 26 de 03 de 2010 a les 06:44 -0800, en/na Taki va escriure: +> Hi, +> +> how can i set the correct path to xsp/xsp2 in monodevelop unter windows? I +> usw the mono 2.6.3 runtime but every webservice app will not start from +> monodevelop 2.2.2. Because the IDE try to start the mono.exe not the xsp.exe +> or xsp2.exe :( +> +> If i use the ms .net runtime for my projects every thing is fine, because +> the IDE use the xsp2.exe in the IDE directory. But i want to test/debug my +> apps on the mono runtime. +> +> These are my first experience with mono. So if someone has a solution for my +> problem, pls explain them step by step :) + +This looks like a MonoDevelop bug. Can you please file a bug report in: + +http://monodevelop.com/Bugs + +Thanks. + + ++ + + +
Hi all, + +It appears Chinese(China) translation for monodevelop was not touched for a +pretty long time. + +Today, I've partially updated it. but I can't find any way to submit/commit +the translation, neither on mono-project.com, nor on l10n.gnome.org + +So should I commit directly(I have write permission to mono svn), or should +someone review my translation first? Or someone commit for me? + +Thanks a lot + + ++ + +
Starting: Mon Mar 1 17:17:03 EST 2010
+ Ending: Tue Mar 30 02:10:04 EDT 2010
+ Messages: 16
+
+ Last message date:
+ Tue Mar 30 02:10:04 EDT 2010
+ Archived on: Tue Mar 30 02:09:58 EDT 2010
+
+
+
Starting: Mon Mar 1 17:17:03 EST 2010
+ Ending: Tue Mar 30 02:10:04 EDT 2010
+ Messages: 16
+
+ Last message date:
+ Tue Mar 30 02:10:04 EDT 2010
+ Archived on: Tue Mar 30 02:09:58 EDT 2010
+
+
+
Starting: Mon Mar 1 17:17:03 EST 2010
+ Ending: Tue Mar 30 02:10:04 EDT 2010
+ Messages: 16
+
+ Last message date:
+ Tue Mar 30 02:10:04 EDT 2010
+ Archived on: Tue Mar 30 02:09:58 EDT 2010
+
+
+
Starting: Mon Mar 1 17:17:03 EST 2010
+ Ending: Tue Mar 30 02:10:04 EDT 2010
+ Messages: 16
+
+ Last message date:
+ Tue Mar 30 02:10:04 EDT 2010
+ Archived on: Tue Mar 30 02:09:58 EDT 2010
+
+
+
Starting: Mon Mar 1 17:17:03 EST 2010
+ Ending: Tue Mar 30 02:10:04 EDT 2010
+ Messages: 16
+
+ Last message date:
+ Tue Mar 30 02:10:04 EDT 2010
+ Archived on: Tue Mar 30 02:09:58 EDT 2010
+
+
+
Currently PyBinding is hardcoded with " " for indentation. I have written a patch so that the indentation is read from the current TextStylePolicy and applied appropriately. + + Jason +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: PyBinding_Whitespace.patch +Type: text/x-patch +Size: 3269 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20100519/8c31dbce/attachment.bin ++ + +
Starting: Wed May 19 04:22:47 EDT 2010
+ Ending: Wed May 19 04:22:47 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Wed May 19 04:22:47 EDT 2010
+ Archived on: Wed May 19 04:22:54 EDT 2010
+
+
+
Starting: Wed May 19 04:22:47 EDT 2010
+ Ending: Wed May 19 04:22:47 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Wed May 19 04:22:47 EDT 2010
+ Archived on: Wed May 19 04:22:54 EDT 2010
+
+
+
Starting: Wed May 19 04:22:47 EDT 2010
+ Ending: Wed May 19 04:22:47 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Wed May 19 04:22:47 EDT 2010
+ Archived on: Wed May 19 04:22:54 EDT 2010
+
+
+
Starting: Wed May 19 04:22:47 EDT 2010
+ Ending: Wed May 19 04:22:47 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Wed May 19 04:22:47 EDT 2010
+ Archived on: Wed May 19 04:22:54 EDT 2010
+
+
+
Starting: Wed May 19 04:22:47 EDT 2010
+ Ending: Wed May 19 04:22:47 EDT 2010
+ Messages: 1
+
+ Last message date:
+ Wed May 19 04:22:47 EDT 2010
+ Archived on: Wed May 19 04:22:54 EDT 2010
+
+
+
Hi, +I've been working on an F# Language Binding for MonoDevelop and I'm +trying to create a repository, so that people can install it using the +standard tools. There are still some bugs in the Language Binding, but +when I just copy the DLL to the "BackendBindings" directory in +MonoDevelop folder, then it seems to work okay (it requires F# and F# +PowerPack in order to run). My testing repository is here: +http://www.tomasp.net/monodevelop/ + +The installation from the repository seems to work fine on Linux/Mono. +The installation reports some errors with the configuration and some +exception occurs when it loads (I guess), but that looks like my bugs +that I can fix (still, it installs and you can create new projects and +everything) + +However, I'm having more troubles on Windows/.NET (I'm testing it on a +clean Windows 7 machine with Gtk# and MonoDevelop installed using the +instructions from the web). When I go through the addin installation +procedure, it installs the adding and just before showing the final +dialog window (with success message and warnings), it shows an +"Unhandled Exception." dialog with the following: + +System.Reflection.TargetInvocationException: Exception has been thrown +by the target of an invocation. +---> System.AccessViolationException: Attempted to read or write +protected memory. +This is often an indication that other memory is corrupt. + + at Gtk.Dialog.gtk_dialog_run(IntPtr raw) + at Gtk.Dialog.Run() + at Mono.Addins.Gui.AddinManagerDialog.OnInstall(Object sender, EventArgs e) + --- End of inner exception stack trace --- + at System.RuntimeMethodHandle._InvokeMethodFast(Object target, +Object[] arguments, SignatureStruct& sig, MethodAttributes +methodAttributes, RuntimeTypeHandle typeOwner) + at System.RuntimeMethodHandle.InvokeMethodFast(Object target, +Object[] arguments, Signature sig, MethodAttributes methodAttributes, +RuntimeTypeHandle typeOwner) + at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, +BindingFlags invokeAttr, Binder binder, Object[] parameters, +CultureInfo culture, Boolean skipVisibilityChecks) + at System.Delegate.DynamicInvokeImpl(Object[] args) + at GLib.Signal.ClosureInvokedCB(Object o, ClosureInvokedArgs args) + at GLib.SignalClosure.Invoke(ClosureInvokedArgs args) + at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr +return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr +invocation_hint, IntPtr marshal_data) + +I tried attaching to the process from VS debugger and it doesn't seem +to even load my "FSharpBinding.dll" assembly, so I'm wondering if this +could some issue in MonoDevelop itself? I tried creating a trivial +language binding in C# and that worked okay, but I was able to +reproduce the error with the repository above on two different +machines. I can also send you the generated log file from the +installation if you need more information. + +I wasn't quite able to figure out what is going on (I think the +exception actually comes from Mono.Addins and I think I've seen errors +like this when accidentally accessing GUI stuff from a background +thread, but I'm not sure if that could be a problem here). Anyway, +this will be probably quite easy to find out for somebody who has +properly setup environment with debug builds of all relevant +libraries. + +Thanks for your help! +Tomas Petricek + +PS: I think that the Visual Studio projects in monodevelop-2.4 "tag" +(I used that version to make sure my adding works with latest stable +version) incorrectly reference 4.0.0 versions of Mono.Addins etc. (see +for example http://github.com/mono/monodevelop/blob/monodevelop-2.4/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.csproj). +I tried changed that to 5.0.0 on my machine, but it didn't resolve the +issue I was having. + +PS2: I noticed there was a project with the aim to implement F# +support for MonoDevelop at the GSOC this year, but I couldn't find any +outcomes of the project. Is that available somewhere? I tried +contacting the person who worked on that, but with no luck (possibly, +I just got a wrong email). Anyway, I could probably contribute my work +to that project (or the other way round) to avoid duplication of +efforts... ++ + + +
On Wed, Oct 13, 2010 at 1:13 PM, Tomas Petricek +<tomas.petricek at gmail.com> wrote: +> Hi, +> I've been working on an F# Language Binding for MonoDevelop and I'm +> trying to create a repository, so that people can install it using the +> standard tools. There are still some bugs in the Language Binding, but +> when I just copy the DLL to the "BackendBindings" directory in +> MonoDevelop folder, then it seems to work okay (it requires F# and F# +> PowerPack in order to run). My testing repository is here: +> http://www.tomasp.net/monodevelop/ +> +> The installation from the repository seems to work fine on Linux/Mono. +> The installation reports some errors with the configuration and some +> exception occurs when it loads (I guess), but that looks like my bugs +> that I can fix (still, it installs and you can create new projects and +> everything) + +Nice! + +> However, I'm having more troubles on Windows/.NET (I'm testing it on a +> clean Windows 7 machine with Gtk# and MonoDevelop installed using the +> instructions from the web). When I go through the addin installation +> procedure, it installs the adding and just before showing the final +> dialog window (with success message and warnings), it shows an +> "Unhandled Exception." dialog with the following: +> +<snip> +> +> I tried attaching to the process from VS debugger and it doesn't seem +> to even load my "FSharpBinding.dll" assembly, so I'm wondering if this +> could some issue in MonoDevelop itself? I tried creating a trivial +> language binding in C# and that worked okay, but I was able to +> reproduce the error with the repository above on two different +> machines. I can also send you the generated log file from the +> installation if you need more information. +> +> I wasn't quite able to figure out what is going on (I think the +> exception actually comes from Mono.Addins and I think I've seen errors +> like this when accidentally accessing GUI stuff from a background +> thread, but I'm not sure if that could be a problem here). Anyway, +> this will be probably quite easy to find out for somebody who has +> properly setup environment with debug builds of all relevant +> libraries. + +Lluis will need to look at that; it sounds like an issue in +Mono.Addins. I've cc'd him. + +> Thanks for your help! +> Tomas Petricek +> +> PS: I think that the Visual Studio projects in monodevelop-2.4 "tag" +> (I used that version to make sure my adding works with latest stable +> version) incorrectly reference 4.0.0 versions of Mono.Addins etc. (see +> for example http://github.com/mono/monodevelop/blob/monodevelop-2.4/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.csproj). +> I tried changed that to 5.0.0 on my machine, but it didn't resolve the +> issue I was having. + +There should be a GAC policy to make Mono.Addins 0.5 used for 0.4 +references, so it shouldn't be an issue. + +BTW, we have a public addin build server at +http://addins.monodevelop.com/ that can build and publish open-source +addins against specific MonoDevelop versions... + +> PS2: I noticed there was a project with the aim to implement F# +> support for MonoDevelop at the GSOC this year, but I couldn't find any +> outcomes of the project. Is that available somewhere? I tried +> contacting the person who worked on that, but with no luck (possibly, +> I just got a wrong email). Anyway, I could probably contribute my work +> to that project (or the other way round) to avoid duplication of +> efforts... + +You can find it here - +http://code.google.com/p/mono-soc-2010/source/browse/#svn/trunk/FSharpBinding. +The project wasn't completed successfully, and I'm not sure of the +current state of the addin. It was derived from an earlier effort by +Vasili I. Galchin at http://github.com/vasili/FSharpBinding. + +There was also an older addin at +http://code.google.com/p/wildart/wiki/FSharpBinding but we recommended +people not to use it because it was derived from old MD/#D GPL code, +which would not permit use of MS-PL code and libraries. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Hi, thanks for the reply! + +>> Lluis will need to look at that; it sounds +>> like an issue in Mono.Addins. I've cc'd him. + +Lluis - did you have any time to look into the issue, or is there any +other information that I could provide? If you had some idea how to +workaround the problem (for now), that would be very useful. I assume +that most of the people will use it on Linux or Mac, but it would be +nice to make it work on Windows too. Alternatively, I'll probably just +have ZIP download with files that people can copy to "BackendBindings" +directory... + +>> BTW, we have a public addin build server at +>> http://addins.monodevelop.com/ that can build and publish open-source +>> addins against specific MonoDevelop versions... + +This looks like a fantastic project - I'll definitely take a look if +we could host the F# plugin there once I'll have some more stable +version (and a bit of time). One possible problem is that the plugin +is implemented in F#, so we'd probably need F# on your server... (I'm +not quite sure how difficult that would be - I'm not sure if the +Microsoft's implementation of MSBUILD task would work on Mono, because +it wasn't needed for MonoDevelop support that I'm working on so far). +Also, do you have any plans for supporting Mercurial source control in +a near future (that's what I currently use to host the project on +CodePlex, but I could probably switch to TFS with Subversion support). + +Thanks! +Tomas + +On Thu, Oct 14, 2010 at 12:18 AM, Michael Hutchinson +<m.j.hutchinson at gmail.com> wrote: +> On Wed, Oct 13, 2010 at 1:13 PM, Tomas Petricek +> <tomas.petricek at gmail.com> wrote: +>> Hi, +>> I've been working on an F# Language Binding for MonoDevelop and I'm +>> trying to create a repository, so that people can install it using the +>> standard tools. There are still some bugs in the Language Binding, but +>> when I just copy the DLL to the "BackendBindings" directory in +>> MonoDevelop folder, then it seems to work okay (it requires F# and F# +>> PowerPack in order to run). My testing repository is here: +>> http://www.tomasp.net/monodevelop/ +>> +>> The installation from the repository seems to work fine on Linux/Mono. +>> The installation reports some errors with the configuration and some +>> exception occurs when it loads (I guess), but that looks like my bugs +>> that I can fix (still, it installs and you can create new projects and +>> everything) +> +> Nice! +> +>> However, I'm having more troubles on Windows/.NET (I'm testing it on a +>> clean Windows 7 machine with Gtk# and MonoDevelop installed using the +>> instructions from the web). When I go through the addin installation +>> procedure, it installs the adding and just before showing the final +>> dialog window (with success message and warnings), it shows an +>> "Unhandled Exception." dialog with the following: +>> +> <snip> +>> +>> I tried attaching to the process from VS debugger and it doesn't seem +>> to even load my "FSharpBinding.dll" assembly, so I'm wondering if this +>> could some issue in MonoDevelop itself? I tried creating a trivial +>> language binding in C# and that worked okay, but I was able to +>> reproduce the error with the repository above on two different +>> machines. I can also send you the generated log file from the +>> installation if you need more information. +>> +>> I wasn't quite able to figure out what is going on (I think the +>> exception actually comes from Mono.Addins and I think I've seen errors +>> like this when accidentally accessing GUI stuff from a background +>> thread, but I'm not sure if that could be a problem here). Anyway, +>> this will be probably quite easy to find out for somebody who has +>> properly setup environment with debug builds of all relevant +>> libraries. +> +> Lluis will need to look at that; it sounds like an issue in +> Mono.Addins. I've cc'd him. +> +>> Thanks for your help! +>> Tomas Petricek +>> +>> PS: I think that the Visual Studio projects in monodevelop-2.4 "tag" +>> (I used that version to make sure my adding works with latest stable +>> version) incorrectly reference 4.0.0 versions of Mono.Addins etc. (see +>> for example http://github.com/mono/monodevelop/blob/monodevelop-2.4/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.csproj). +>> I tried changed that to 5.0.0 on my machine, but it didn't resolve the +>> issue I was having. +> +> There should be a GAC policy to make Mono.Addins 0.5 used for 0.4 +> references, so it shouldn't be an issue. +> +> BTW, we have a public addin build server at +> http://addins.monodevelop.com/ that can build and publish open-source +> addins against specific MonoDevelop versions... +> +>> PS2: I noticed there was a project with the aim to implement F# +>> support for MonoDevelop at the GSOC this year, but I couldn't find any +>> outcomes of the project. Is that available somewhere? I tried +>> contacting the person who worked on that, but with no luck (possibly, +>> I just got a wrong email). Anyway, I could probably contribute my work +>> to that project (or the other way round) to avoid duplication of +>> efforts... +> +> You can find it here - +> http://code.google.com/p/mono-soc-2010/source/browse/#svn/trunk/FSharpBinding. +> The project wasn't completed successfully, and I'm not sure of the +> current state of the addin. It was derived from an earlier effort by +> Vasili I. Galchin at http://github.com/vasili/FSharpBinding. +> +> There was also an older addin at +> http://code.google.com/p/wildart/wiki/FSharpBinding but we recommended +> people not to use it because it was derived from old MD/#D GPL code, +> which would not permit use of MS-PL code and libraries. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> ++ + + + +
Hi, +I have been working on MonoDevelop language binding for F# and I have +one question regarding colorization (the SyntaxMode class). Creating +XML based syntax mode is quite easy, so I'm using that for now, but +there are a few things that would need to be improved (e.g. F# allows +you to have nested multi-line comments and I'd like to eventually +implement support for #if, etc.) + +The F# compiler exposes a very simple tokenizer that I could use - you +give it a line from the source file and it parses the line returning a +sequence of tokens (with location, color information and other +possibly useful things). I was wondering if I could just implement +SyntaxMode by calling the F# tokenizer, but I don't see any way of +creating SyntaxMode that would just return e.g. a list with starting +and ending colum & color for each line. + +I found some syntax modes that create custom SpanParser which returns +stack of Span objects, but that still marks the start/end of a span +using Regex. Is there a more direct way of providing colorization? + +Thanks! +Tomas Petricek ++ + + + + + + +
Hi + +If you really want to make a complex syntax highlighting you need to +write a highlighter in c#. + +See: +main/src/addins/CSharpBinding/MonoDevelop.CSharp.Highlighting/CSharpSyntaxMode.cs + +btw. you could create a custom chunk parser as well as a custom span parser. + +Regards +Mike +> Hi, +> I have been working on MonoDevelop language binding for F# and I have +> one question regarding colorization (the SyntaxMode class). Creating +> XML based syntax mode is quite easy, so I'm using that for now, but +> there are a few things that would need to be improved (e.g. F# allows +> you to have nested multi-line comments and I'd like to eventually +> implement support for #if, etc.) +> +> The F# compiler exposes a very simple tokenizer that I could use - you +> give it a line from the source file and it parses the line returning a +> sequence of tokens (with location, color information and other +> possibly useful things). I was wondering if I could just implement +> SyntaxMode by calling the F# tokenizer, but I don't see any way of +> creating SyntaxMode that would just return e.g. a list with starting +> and ending colum& color for each line. +> +> I found some syntax modes that create custom SpanParser which returns +> stack of Span objects, but that still marks the start/end of a span +> using Regex. Is there a more direct way of providing colorization? +> +> Thanks! +> Tomas Petricek +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + + + + + +
Hi Mike,
+thanks for the reply. I think that in my scenario, using an existing
+tokenizer would be the easiest option (because it is already there,
+efficient and tested). I was looking at CSharpSyntaxMode.cs briefly,
+but I didn't quite understood how it works. Is there any example with
+some comments or a brief overview article about this?
+
+As far as I can see, the C# example implements a custom "SpanParser"
+and overrides two virtual methods "ScanSpan" and "ScanSpanEnd". These
+methods somehow manipulate "spanStack" (where does that come from?),
+but if I understand it correctly, this provides "Span" objects which
+specify start and end using regular expressions. I'd like to generate
+tokens with locations to mark their start/end and some color
+information, so should I create my own "SpanParser"? You also
+mentioned chunk parser - what is the difference between this one and
+span parser? Sorry for so many questions - I'm new to MonoDevelop and
+I couldn't find any documentation on this part (aside from the
+description of XML format) and the existing C# syntax mode contains
+only a few comments...
+
+Below is the existing F# parsing that I'd like to use - to give you an
+idea of what I'd like to map to the MonoDevelop API.
+
+Thanks!
+Tomas
+
+
+class TokenInformation {
+ public int LeftColumn { get; } // Start location at the current line
+ public int RightColumn { get; } // End location at the current line
+ public TokenColorKind ColorClass { get; } // Color as simple 'enum'
+}
+
+class SourceTokenizer {
+ public SourceTokenizer(string[] defines, string source); // Takes
+list of #define symbols and source
+ LineTokenizer CreateLineTokenizer(string line); // Create parser for
+a line (passed in as a string)
+}
+
+class LineTokenizer {
+ // Read next token on the line (takes current state of parser and
+returns a state after parsing)
+ public Tuple<TokenInformation, State> ScanToken(State state);
+}
+
+
+On Thu, Oct 21, 2010 at 7:00 AM, Mike Krüger <mkrueger at novell.com> wrote:
+> Hi
+>
+> If you really want to make a complex syntax highlighting you need to
+> write a highlighter in c#.
+>
+> See:
+> main/src/addins/CSharpBinding/MonoDevelop.CSharp.Highlighting/CSharpSyntaxMode.cs
+>
+> btw. you could create a custom chunk parser as well as a custom span parser.
+>
+> Regards
+> Mike
+>> Hi,
+>> I have been working on MonoDevelop language binding for F# and I have
+>> one question regarding colorization (the SyntaxMode class). Creating
+>> XML based syntax mode is quite easy, so I'm using that for now, but
+>> there are a few things that would need to be improved (e.g. F# allows
+>> you to have nested multi-line comments and I'd like to eventually
+>> implement support for #if, etc.)
+>>
+>> The F# compiler exposes a very simple tokenizer that I could use - you
+>> give it a line from the source file and it parses the line returning a
+>> sequence of tokens (with location, color information and other
+>> possibly useful things). I was wondering if I could just implement
+>> SyntaxMode by calling the F# tokenizer, but I don't see any way of
+>> creating SyntaxMode that would just return e.g. a list with starting
+>> and ending colum& color for each line.
+>>
+>> I found some syntax modes that create custom SpanParser which returns
+>> stack of Span objects, but that still marks the start/end of a span
+>> using Regex. Is there a more direct way of providing colorization?
+>>
+>> Thanks!
+>> Tomas Petricek
+>> _______________________________________________
+>> Monodevelop-devel-list mailing list
+>> Monodevelop-devel-list at lists.ximian.com
+>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+>
+> _______________________________________________
+> Monodevelop-devel-list mailing list
+> Monodevelop-devel-list at lists.ximian.com
+> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+>
+
+
+
+
+
+
+
+
+ Hi
+
+No - this is may change in the future too. It's basically splitting up a
+text into tokens.
+I've 2 tokenizer runs : spans and chunks. Spans help to reduce the
+amount of re-parses.
+Spans are comments, strings etc. - they just help to set the correct
+color for a chunk. A chunk is the real token.
+It's just a segment (offset/length) that has a color attached to.
+
+The spanstack is the stack that contains the spans - it comes from
+outside (atm it's stored for each line). It's a stack because spans can
+contain each other but aren't allowed to overlap. If you want something
+with a start & end and stuff in between then a span is the thing you're
+looking for and you need to modify the span parser.
+ScanSpan scans for the span beginnings and scanspanend for the endings.
+I would leave it with this model.
+
+I plan to work on the highlighting engine in the future - I've put up
+some code in a private branch, but I don't think I've time to do it in
+the mid-term future. I've only documented the syntax mode xml stuff -
+making own highlightings per code is one of the newer features and a bit
+messy (that's why I want to clean up that stuff).
+
+Regards
+Mike
+> Hi Mike,
+> thanks for the reply. I think that in my scenario, using an existing
+> tokenizer would be the easiest option (because it is already there,
+> efficient and tested). I was looking at CSharpSyntaxMode.cs briefly,
+> but I didn't quite understood how it works. Is there any example with
+> some comments or a brief overview article about this?
+>
+> As far as I can see, the C# example implements a custom "SpanParser"
+> and overrides two virtual methods "ScanSpan" and "ScanSpanEnd". These
+> methods somehow manipulate "spanStack" (where does that come from?),
+> but if I understand it correctly, this provides "Span" objects which
+> specify start and end using regular expressions. I'd like to generate
+> tokens with locations to mark their start/end and some color
+> information, so should I create my own "SpanParser"? You also
+> mentioned chunk parser - what is the difference between this one and
+> span parser? Sorry for so many questions - I'm new to MonoDevelop and
+> I couldn't find any documentation on this part (aside from the
+> description of XML format) and the existing C# syntax mode contains
+> only a few comments...
+>
+> Below is the existing F# parsing that I'd like to use - to give you an
+> idea of what I'd like to map to the MonoDevelop API.
+>
+> Thanks!
+> Tomas
+>
+>
+> class TokenInformation {
+> public int LeftColumn { get; } // Start location at the current line
+> public int RightColumn { get; } // End location at the current line
+> public TokenColorKind ColorClass { get; } // Color as simple 'enum'
+> }
+>
+> class SourceTokenizer {
+> public SourceTokenizer(string[] defines, string source); // Takes
+> list of #define symbols and source
+> LineTokenizer CreateLineTokenizer(string line); // Create parser for
+> a line (passed in as a string)
+> }
+>
+> class LineTokenizer {
+> // Read next token on the line (takes current state of parser and
+> returns a state after parsing)
+> public Tuple<TokenInformation, State> ScanToken(State state);
+> }
+>
+>
+> On Thu, Oct 21, 2010 at 7:00 AM, Mike Krüger<mkrueger at novell.com> wrote:
+>> Hi
+>>
+>> If you really want to make a complex syntax highlighting you need to
+>> write a highlighter in c#.
+>>
+>> See:
+>> main/src/addins/CSharpBinding/MonoDevelop.CSharp.Highlighting/CSharpSyntaxMode.cs
+>>
+>> btw. you could create a custom chunk parser as well as a custom span parser.
+>>
+>> Regards
+>> Mike
+>>> Hi,
+>>> I have been working on MonoDevelop language binding for F# and I have
+>>> one question regarding colorization (the SyntaxMode class). Creating
+>>> XML based syntax mode is quite easy, so I'm using that for now, but
+>>> there are a few things that would need to be improved (e.g. F# allows
+>>> you to have nested multi-line comments and I'd like to eventually
+>>> implement support for #if, etc.)
+>>>
+>>> The F# compiler exposes a very simple tokenizer that I could use - you
+>>> give it a line from the source file and it parses the line returning a
+>>> sequence of tokens (with location, color information and other
+>>> possibly useful things). I was wondering if I could just implement
+>>> SyntaxMode by calling the F# tokenizer, but I don't see any way of
+>>> creating SyntaxMode that would just return e.g. a list with starting
+>>> and ending colum& color for each line.
+>>>
+>>> I found some syntax modes that create custom SpanParser which returns
+>>> stack of Span objects, but that still marks the start/end of a span
+>>> using Regex. Is there a more direct way of providing colorization?
+>>>
+>>> Thanks!
+>>> Tomas Petricek
+>>> _______________________________________________
+>>> Monodevelop-devel-list mailing list
+>>> Monodevelop-devel-list at lists.ximian.com
+>>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+>> _______________________________________________
+>> Monodevelop-devel-list mailing list
+>> Monodevelop-devel-list at lists.ximian.com
+>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+>>
+
+
+
+
+
+
+
+
+
+ El dc 20 de 10 de 2010 a les 13:15 +0100, en/na Tomas Petricek va +escriure: +> Hi, thanks for the reply! +> +> >> Lluis will need to look at that; it sounds +> >> like an issue in Mono.Addins. I've cc'd him. +> +> Lluis - did you have any time to look into the issue, or is there any +> other information that I could provide? If you had some idea how to +> workaround the problem (for now), that would be very useful. I assume +> that most of the people will use it on Linux or Mac, but it would be +> nice to make it work on Windows too. Alternatively, I'll probably just +> have ZIP download with files that people can copy to "BackendBindings" +> directory... +> +> >> BTW, we have a public addin build server at +> >> http://addins.monodevelop.com/ that can build and publish open-source +> >> addins against specific MonoDevelop versions... + +Looks like this repository is not available anymore... + +> +> This looks like a fantastic project - I'll definitely take a look if +> we could host the F# plugin there once I'll have some more stable +> version (and a bit of time). + +It doesn't need to be stable to publish it there. You can set the add-in +as "Alpha" and will only appear in the alpha channel. + +> One possible problem is that the plugin +> is implemented in F#, so we'd probably need F# on your server... (I'm +> not quite sure how difficult that would be - I'm not sure if the +> Microsoft's implementation of MSBUILD task would work on Mono, because +> it wasn't needed for MonoDevelop support that I'm working on so far). + +That's something we can try. + +> Also, do you have any plans for supporting Mercurial source control in +> a near future (that's what I currently use to host the project on +> CodePlex, but I could probably switch to TFS with Subversion support). + +I don't know Mercurial, but I'll take a look. It shouldn't be hard to +add support for it. + +Lluis. + + ++ + + +
> I don't know Mercurial, but I'll take a look. It shouldn't be hard to +> add support for it. + +Should be very similar to the bzr codepath. ++ + + +
Hi, + +>> Looks like this repository is not available anymore... +I moved the repository to another domain (and I forgot I sent a link +to the mailing list). The new URL is: +http://openfsharp.net/monodevelop/ (it still repros on my machine). + +>> (MonoDevelop addins project) +I just tried compiling the F# project using an MSBUILD task that is +shipped with the F# installation and it looks like it should be +possible to use it on Mono. I'm getting an error that seems to be an +instance of this bug: +https://bugzilla.novell.com/show_bug.cgi?id=565847 (the "targets" file +is attached just FYI - it certainly uses "ItemGroup" inside "Target"). +Is this bug going to be fixed in some Mono version soon (it repros on +2.8)? + +I'm not very familiar with MSBUILD, so I'll need to take more look at +that. Do you know about any easy workaround off hand? + +Thanks! +Tomas + + +On Fri, Oct 22, 2010 at 9:17 AM, Lluis Sanchez <lluis at novell.com> wrote: +> El dc 20 de 10 de 2010 a les 13:15 +0100, en/na Tomas Petricek va +> escriure: +>> Hi, thanks for the reply! +>> +>> >> Lluis will need to look at that; it sounds +>> >> like an issue in Mono.Addins. I've cc'd him. +>> +>> Lluis - did you have any time to look into the issue, or is there any +>> other information that I could provide? If you had some idea how to +>> workaround the problem (for now), that would be very useful. I assume +>> that most of the people will use it on Linux or Mac, but it would be +>> nice to make it work on Windows too. Alternatively, I'll probably just +>> have ZIP download with files that people can copy to "BackendBindings" +>> directory... +>> +>> >> BTW, we have a public addin build server at +>> >> http://addins.monodevelop.com/ that can build and publish open-source +>> >> addins against specific MonoDevelop versions... +> +> Looks like this repository is not available anymore... +> +>> +>> This looks like a fantastic project - I'll definitely take a look if +>> we could host the F# plugin there once I'll have some more stable +>> version (and a bit of time). +> +> It doesn't need to be stable to publish it there. You can set the add-in +> as "Alpha" and will only appear in the alpha channel. +> +>> One possible problem is that the plugin +>> is implemented in F#, so we'd probably need F# on your server... (I'm +>> not quite sure how difficult that would be - I'm not sure if the +>> Microsoft's implementation of MSBUILD task would work on Mono, because +>> it wasn't needed for MonoDevelop support that I'm working on so far). +> +> That's something we can try. +> +>> Also, do you have any plans for supporting Mercurial source control in +>> a near future (that's what I currently use to host the project on +>> CodePlex, but I could probably switch to TFS with Subversion support). +> +> I don't know Mercurial, but I'll take a look. It shouldn't be hard to +> add support for it. +> +> Lluis. +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: Microsoft.FSharp.Targets +Type: application/octet-stream +Size: 9011 bytes +Desc: not available +Url : http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20101022/cf569445/attachment.obj ++ + + +
On Fri, Oct 22, 2010 at 6:46 AM, Tomas Petricek +<tomas.petricek at gmail.com> wrote: +> Hi, +> +>>> Looks like this repository is not available anymore... +> I moved the repository to another domain (and I forgot I sent a link +> to the mailing list). The new URL is: +> http://openfsharp.net/monodevelop/ (it still repros on my machine). +> +>>> (MonoDevelop addins project) +> I just tried compiling the F# project using an MSBUILD task that is +> shipped with the F# installation and it looks like it should be +> possible to use it on Mono. I'm getting an error that seems to be an +> instance of this bug: +> https://bugzilla.novell.com/show_bug.cgi?id=565847 (the "targets" file +> is attached just FYI - it certainly uses "ItemGroup" inside "Target"). +> Is this bug going to be fixed in some Mono version soon (it repros on +> 2.8)? +> +> I'm not very familiar with MSBUILD, so I'll need to take more look at +> that. Do you know about any easy workaround off hand? + +Yes, the CreateItem task: http://msdn.microsoft.com/en-us/library/s2y3e43x.aspx + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
+Dear all, + +I am Xiong ZhangLiang from Samsung Electronics (China) RD Center. + +Recently we try to adopt Mono2.8 as embedded S/W platform for Samsung products, +and we wrote an network communication App with Winform UI on it. +The app of LOC is approximately 70K. +Target board is S3C24400(ARM920T-ARMv4t, 400MCPU, 128M Flash, 128M SDRAM, Linux2.4.20, arm- +v4t-le_gcc3.2.1). +We ported XServer for UI. + +We found the app performance on Mono is bad. +Init time is more than 3 min, Memory occupation is more than 80M and UI repsonse time is +more than 8 sec. +And memory cannot be released when user operated until memory is used up. +ARM byte order is middle order, but App on Mono can not execute double calculation correctly +because of the byte order. + +Then we try the AOT to reduce the startup time. +Full AOT can be executed except two Mono files (I18Rare.dll), but it cannot run and print +"undefined instructions". +If compile Mono file with --aot -O=all option, about 10 Mono files cannot be compiled (most +important is System.Windows.Winform.dll), then libGdiplus.so can be found, the app can be +executed with 10% startup time reduce. But that's not enough. + +If we compile System.Windows.Winform.dll with --aot option, it can be compiled. +But with compiled System.Windows.Winform.dll.so, app cannot run and print "libGdiplus.so +unable to be load" because of "error loading libFontconfig.so.1:R_ARM_PC24 relocation out of +range". But to reduce the startup time significantly, I think compile +System.Windows.Winform.dll is the most important. +Could you kindly give us some guidance? + +Thank you very much. +With BR, +Xiong ZhangLiang +-------------------------------------------------- +Samsung Electronics (China) RD Center +Mono project, Project Leader, PhD +Mobile:86-13913925119 +Office:86-25-58748787-3440 +Mail:xdz3701 at hotmail.com +-------------------------------------------------- + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20101024/25d894be/attachment-0001.html ++ + +
Starting: Wed Oct 13 13:13:23 EDT 2010
+ Ending: Sun Oct 24 00:11:46 EDT 2010
+ Messages: 12
+
+ Last message date:
+ Sun Oct 24 00:11:46 EDT 2010
+ Archived on: Mon Jan 10 02:59:39 EST 2011
+
+
+
Starting: Wed Oct 13 13:13:23 EDT 2010
+ Ending: Sun Oct 24 00:11:46 EDT 2010
+ Messages: 12
+
+ Last message date:
+ Sun Oct 24 00:11:46 EDT 2010
+ Archived on: Mon Jan 10 02:59:39 EST 2011
+
+
+
Starting: Wed Oct 13 13:13:23 EDT 2010
+ Ending: Sun Oct 24 00:11:46 EDT 2010
+ Messages: 12
+
+ Last message date:
+ Sun Oct 24 00:11:46 EDT 2010
+ Archived on: Mon Jan 10 02:59:39 EST 2011
+
+
+
Starting: Wed Oct 13 13:13:23 EDT 2010
+ Ending: Sun Oct 24 00:11:46 EDT 2010
+ Messages: 12
+
+ Last message date:
+ Sun Oct 24 00:11:46 EDT 2010
+ Archived on: Mon Jan 10 02:59:39 EST 2011
+
+
+
Starting: Wed Oct 13 13:13:23 EDT 2010
+ Ending: Sun Oct 24 00:11:46 EDT 2010
+ Messages: 12
+
+ Last message date:
+ Sun Oct 24 00:11:46 EDT 2010
+ Archived on: Mon Jan 10 02:59:39 EST 2011
+
+
+
Hi, + +Applications must be made directly to the Google GSoC site, and should +include a project proposal. If you are having trouble finding ideas +for the project, I suggest you approach the Axiom developers on their +mailing list or IRC. + +- Michael + +On Wed, Apr 6, 2011 at 8:23 PM, Shivansh Srivastava +<shivansh.bits at gmail.com> wrote: +> Hi, +> I have been interacting frequently on the monodevelop mailing list, but +> havnt got a chance to discuss any idea regarding "Building/developing apps +> with Axiom engine". +> Also, i am not able to join the "monoxna at googlegroups.com" googlegroup, +> where they could really help me. +> Kindly find attached my application for GSoC 2011. +> I have a sound experience in developing apps/games in C# using XNA Framework +> (3.0, 3.1, 4.0) for Windows & Windows Phone 7. +> I have compiled/built OGRE & am going through its code for better +> understanding. +> I dont have any idea(s) as such, but would really appreciate if any mentor +> would guide me & help me with how I can help in the development. +> I would be glad to help in the development of Axiom Engine. +> +> I really apologise for submitting my Application this late. I had a few +> family problems/commitments that I had to take care of. +> Waiting for a reply. +> With regards, +> Shivansh. +> +> -- +> Shivansh Srivastava | +91-955-243-5407 | shivansh.bits at gmail.com +> 2nd Year Undergraduate | B.E. (Hons.) - Electronics & Instrumentation +> BITS-Pilani. +> _______________________________________________ +> Monodevelop-list mailing list +> Monodevelop-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-list +> +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Tue, Mar 29, 2011 at 5:26 PM, Christopher Houdeshell +<christopher.houdeshell at gmail.com> wrote: +> Hello -- +> Is the main.sln out of sync with Visual Studio 2010/2010 SP1? I haven't +> tried to build on Windows in some time. Opening the solution in VS2010 and +> VS2010 SP1 results in the upgrade solution dialog. Thanks. + +It seems that some of the projects in contrib still have +ToolsVersion="3.5", even though everything else is 4.0. I suspect +that's the reason VS upgrades the solution. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On Sun, Apr 10, 2011 at 3:46 PM, Christopher Houdeshell +<christopher.houdeshell at gmail.com> wrote: +>> It seems that some of the projects in contrib still have +>> ToolsVersion="3.5", even though everything else is 4.0. I suspect +>> that's the reason VS upgrades the solution. +> +> Ah, that makes sense. Should those projects in contrib be upgraded? + +IMO they should be upgraded, but since Lluis owns them I'll let him do +it, in case he had some reason to leave them that way. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Thu Apr 7 14:44:37 EDT 2011
+ Ending: Sun Apr 10 16:06:23 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Sun Apr 10 16:06:23 EDT 2011
+ Archived on: Sun Apr 10 16:06:26 EDT 2011
+
+
+
Starting: Thu Apr 7 14:44:37 EDT 2011
+ Ending: Sun Apr 10 16:06:23 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Sun Apr 10 16:06:23 EDT 2011
+ Archived on: Sun Apr 10 16:06:26 EDT 2011
+
+
+
Starting: Thu Apr 7 14:44:37 EDT 2011
+ Ending: Sun Apr 10 16:06:23 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Sun Apr 10 16:06:23 EDT 2011
+ Archived on: Sun Apr 10 16:06:26 EDT 2011
+
+
+
Starting: Thu Apr 7 14:44:37 EDT 2011
+ Ending: Sun Apr 10 16:06:23 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Sun Apr 10 16:06:23 EDT 2011
+ Archived on: Sun Apr 10 16:06:26 EDT 2011
+
+
+
Starting: Thu Apr 7 14:44:37 EDT 2011
+ Ending: Sun Apr 10 16:06:23 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Sun Apr 10 16:06:23 EDT 2011
+ Archived on: Sun Apr 10 16:06:26 EDT 2011
+
+
+
LinkedIn +------------ + + + + +I'd like to add you to my professional network on LinkedIn. + +- Gianluca + +Gianluca Masone +R&D Software Designer (Microsoft .Net Platform) at Microgame S.p.A. +Naples Area, Italy + +Confirm that you know Gianluca Masone +https://www.linkedin.com/e/gbocpw-gqud133j-30/isd/3725667015/rQxzcirc/ + + + +-- +(c) 2011, LinkedIn Corporation +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110802/de03d133/attachment-0001.html ++ + + +
Hi, + +I created a MonoDevelop AddIn. From the manifest.xml I am extending + + + +/MonoDevelop/Ide/GlobalOptionsDialog + + + +with a custom options property page as well as adding a project template to + + + +/MonoDevelop/Ide/ProjectTemplates + + + +The project template is defined in an xpt.xml file and is mainly a C# +library project with some special assembly references and some C# source +code files. + + + +The custom property page exposes a file chooser where users can setup a +certain directory. The user setting here is stored using the +MonoDevelop.Core.PropertyService. Now I would like to use the path specified +here in my project template, because the user chosen path points to a place +where an assembly referenced by the project template can be found. + + + +My question is: Can this be done without programming? How can I access +settings stored in the MonoDevelop.Core.PropertyService from within the +xpt.xml? + + + +If I need programming: How would I do this. What additional extension points +do I need to hook on? What classes do I need to inherit and what +methods/properties do I need to override? + + + +Thanks a lot in advance, + +Christoph Müller + + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110803/378843ed/attachment.html ++ + +
Starting: Tue Aug 2 00:20:37 EDT 2011
+ Ending: Wed Aug 3 08:38:22 EDT 2011
+ Messages: 2
+
+ Last message date:
+ Wed Aug 3 08:38:22 EDT 2011
+ Archived on: Wed Aug 3 08:38:31 EDT 2011
+
+
+
Starting: Tue Aug 2 00:20:37 EDT 2011
+ Ending: Wed Aug 3 08:38:22 EDT 2011
+ Messages: 2
+
+ Last message date:
+ Wed Aug 3 08:38:22 EDT 2011
+ Archived on: Wed Aug 3 08:38:31 EDT 2011
+
+
+
Starting: Tue Aug 2 00:20:37 EDT 2011
+ Ending: Wed Aug 3 08:38:22 EDT 2011
+ Messages: 2
+
+ Last message date:
+ Wed Aug 3 08:38:22 EDT 2011
+ Archived on: Wed Aug 3 08:38:31 EDT 2011
+
+
+
Starting: Tue Aug 2 00:20:37 EDT 2011
+ Ending: Wed Aug 3 08:38:22 EDT 2011
+ Messages: 2
+
+ Last message date:
+ Wed Aug 3 08:38:22 EDT 2011
+ Archived on: Wed Aug 3 08:38:31 EDT 2011
+
+
+
Starting: Tue Aug 2 00:20:37 EDT 2011
+ Ending: Wed Aug 3 08:38:22 EDT 2011
+ Messages: 2
+
+ Last message date:
+ Wed Aug 3 08:38:22 EDT 2011
+ Archived on: Wed Aug 3 08:38:31 EDT 2011
+
+
+
Hi! + +Monodevelop on windows uses the Mono 2.10.6 Runtime and automatically +generates mdb and pdb files. + +when running the app on the device i get a stackttrace but with +"filename unkown:0" But if i run the exe with mono --debug on windows +i get the filename / numbers. + +I tried to rebuild the mdb with pdb2mdb on linux which worked ok, but +still no line numbers. + +thank you for your help + +Peter + +On the Linux Box its the same (2.10.6) + +Am 30. November 2011 20:28 schrieb Michael Hutchinson +<m.j.hutchinson at gmail.com>: +> On 27 November 2011 16:17, Peter Siegel <siegelpeter2009 at gmail.com> wrote: +>> Hi! +>> +>> Im writing an Addin for Monodevelop which can debug mono Applications +>> on remote Linux hosts based on the Meego Plugin. It seems like the +>> Meego Addin has been discontinued... So i try to resurrect it as a +>> general Linux Remote Debugging Addin.... ;-) +>> +>> I got it up and running, and the Debugger connects successfully, Pause +>> and Continue works, but the Debugger ignores all breakpoints. +>> +>> I think the problem might be with the Assembly path in the MDB files +>> which are transfered to the Linux Host from my Windows PC, because +>> FindLocation in ResolveBreakPoint is null.. and inisideLoadedRange == +>> false +>> +>> Is there a way to change the Path info's in the MDB, so that i can +>> use them on windows and linux devices? +> +> That shouldn't matter, the paths are handled only in the context of +> the host. We did initially have some issue but fixed them so that +> MonoDevelop on Windows could debug Mono for Android apps. +> +> How are you building the apps on Windows? I assume you selected the +> Mono runtime so that your apps are built with mcs and have mdb +> debugging files. If you're using the .NET target runtime, then your +> apps will be built with csc files so will only have pdb files, which +> Mono cannot handle directly. You'd need to use pdb2mdb +> (mcs/tools/pdb2mdb) to convert them. +> +> What version of Mono is running on the target device? Can you verify +> that stack traces on the target device have file/line information that +> corresponds to real files on the Windows host? +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com ++ + + +
On 1 December 2011 05:15, Peter Siegel <siegelpeter2009 at gmail.com> wrote: +> Hi! +> +> Monodevelop on windows uses the Mono 2.10.6 Runtime and automatically +> generates mdb and pdb files. + +That doesn't sound right, I don't think Mono can generate pdb files. + +> when running the app on the device i get a stackttrace but with +> "filename unkown:0" But if i run the exe with mono --debug on windows +> i get the filename / numbers. +> +> I tried to rebuild the mdb with pdb2mdb on linux which worked ok, but +> still no line numbers. + +It's hard to diagnose without debugging, but if you don't have line +numbers in stack traces in if you use mono --debug on the device, that +implies you don't have the correct mdb files beside the assemblies. +AFAIK the stack trace should print the original Windows paths. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Hello, + +I want to help improve the Python (CPython) add-in to make MonoDevelop more +competitive with other free IDEs that support the language. MonoDevelop is +a great environment and I hate having to switch to another tool for Python. + + +After using the current add-in, the most important missing features I +noticed are the debugger (not working) and an integrated console (missing). + + +I haven't found much information about the Python add-in online. If you +know anything about the history of the project I would appreciate hearing +from you. Likewise if you have experience building support for a new +language, have worked on the debugger, have worked on Python integration in +some other IDE, or just want to discuss the project. This is my first +attempt at contributing to MonoDevelop so mentors are welcome. + +Cheers, +Chris +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20111206/c0280d8d/attachment.html ++ + + + + +
Hi Chris, + +I wrote the CPython binding. However, I'm not an active contributor +anymore. Go through the source, there is a lot of low-hanging fruit +that would be good for starting. + +Longer term stuff might include using IronPython for an AST which +would likely make parsing the source for errors much faster. The +current design is sort of clown shoes. + +The parser/indexer for symbols to be used in autocompletion was also +really slow at one time. I don't know if that has been fixed. It was +probably due to a lack of sqlite transactions. + +Anyway, if you have questions, feel free to ask. + +-- Christian + +2011/12/6 Chris Stevens <chris.h.stevens at gmail.com>: +> Hello, +> +> I want to help improve the Python (CPython) add-in to make MonoDevelop more +> competitive with other free IDEs that support the language. MonoDevelop is +> a great environment and I hate having to switch to another tool for Python. +> +> +> After using the current add-in, the most important missing features I +> noticed are the debugger (not working) and an integrated console (missing). +> +> +> I haven't found much information about the Python add-in online. If you +> know anything about the history of the project I would appreciate hearing +> from you. Likewise if you have experience building support for a new +> language, have worked on the debugger, have worked on Python integration in +> some other IDE, or just want to discuss the project. This is my first +> attempt at contributing to MonoDevelop so mentors are welcome. +> +> Cheers, +> Chris +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> ++ + + + + +
> Go through the source, there is a lot of low-hanging fruit +> that would be good for starting. + +A good place to start might be reenabling the breadcrumb bar in the +source editor view. ++ + + + + +
Hi! +I think you are right... It seems like Monodevelop uses the +.netcompiler when compiling for "Softdebugger on Meego Device". I +checkedthe normal debug mode and it uses mono. Now i'm going to check +whymono isn't used for the Meego SDB Debugging. +I can't find anything about the compiler in the Meego Addin code...Any +Idea where i have to search for this? +Today i tested this on Linux (OpenSuSE 12.1) and there +Singlestepdebugging worked (locally but using Meego SDB Debugging. +I couldn't find any recent updates in git... Is Monodevelop +stillactively developed? +Thank you very much for your help +Peter +Am 2. Dezember 2011 06:25 schrieb Michael Hutchinson <m.j.hutchinson at gmail.com>: +> On 1 December 2011 05:15, Peter Siegel <siegelpeter2009 at gmail.com> wrote: +>> Hi! +>> +>> Monodevelop on windows uses the Mono 2.10.6 Runtime and automatically +>> generates mdb and pdb files. +> +> That doesn't sound right, I don't think Mono can generate pdb files. +> +>> when running the app on the device i get a stackttrace but with +>> "filename unkown:0" But if i run the exe with mono --debug on windows +>> i get the filename / numbers. +>> +>> I tried to rebuild the mdb with pdb2mdb on linux which worked ok, but +>> still no line numbers. +> +> It's hard to diagnose without debugging, but if you don't have line +> numbers in stack traces in if you use mono --debug on the device, that +> implies you don't have the correct mdb files beside the assemblies. +> AFAIK the stack trace should print the original Windows paths. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com ++ + + +
On 16 December 2011 07:30, Peter Siegel <siegelpeter2009 at gmail.com> wrote: +> Hi! +> I think you are right... It seems like Monodevelop uses the +> .netcompiler when compiling for "Softdebugger on Meego Device". I +> checkedthe normal debug mode and it uses mono. Now i'm going to check +> whymono isn't used for the Meego SDB Debugging. +> I can't find anything about the compiler in the Meego Addin code...Any +> Idea where i have to search for this? + +This addin doesn't alter the compilation all all, that's left to the core code. + +In order to have mdb files when compiling on Windows for transferring +to the debuggee, you should either: +a) Set MonoDevelop to target the Mono runtime/toolchain, using +Project->Target Runtime, so it will use *mcs when compiling. +-or- +b) Use pdb2mdb to convert the pdb files produced by .NET's csc to mdb files + +Since the choice of target runtime is up to the user, not the addin, I +would suggest supporting pdb2mdb anyway. + +> Today i tested this on Linux (OpenSuSE 12.1) and there +> Singlestepdebugging worked (locally but using Meego SDB Debugging. +> I couldn't find any recent updates in git... Is Monodevelop +> stillactively developed? + +Yes, see https://github.com/mono/monodevelop/commits/master + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Started fresh with... + +$ git clone https://github.com/mono/monodevelop.git +$ cd monodevelop +$ ./configure --prefix=/usr/local + +The build profile 'default' does not exist. A new profile will be created. +Select the packages to include in the build for the profile 'default': + +1. [X] main +2. [ ] extras/JavaBinding +3. [ ] extras/ValaBinding +4. [ ] extras/MonoDevelop.Database +5. [ ] extras/MonoDevelop.Debugger.Gdb +6. [ ] extras/PyBinding +7. [ ] extras/MonoDevelop.MonoMac +8. [ ] extras/MonoDevelop.MeeGo + +Enter the number of an add-in to enable/disable, +(q) quit, (c) clear all, (s) select all, or ENTER to continue: + +Hit ENTER and eventually saw... + +checking for MONO_ADDINS... configure: error: Package requirements +(mono-addins >= 0.6) were not met: + +No package 'mono-addins' found + +So, went back to github... + +$ cd .. +$ git clone https://github.com/mono/mono-addins.git +$ cd mono-addins +$ ./configure --prefix=/usr/local +-bash: ./configure: No such file or directory + +Instructions in README say "./configure", but I see "autogen.sh", so... + +$ autogen.sh --prefix=/usr/local +$ make +$ make install +$ cd ../monodevelop +$ ./configure --prefix=/usr/local --profile=core +... +configure: error: You must enable one of the platform bindings + +OK, would be nice if README were updated with new profiles... + +$ rm profiles/default +$ ./configure --prefix=/usr/local --profile=windows +$ make +$ make install +... +/usr/local/bin/dmcs -debug -codepage:utf8 -warnaserror -debug +-out:../../../build/bin/MonoDevelop.Projects.Formats.MSBuild.exe +-target:winexe -r:/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Engine.dll + -r:/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Framework.dll + -r:/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Utilities.v3.5.dll + -r:System -r:System.Runtime.Remoting ./AssemblyInfo.cs ./Main.cs +./MonoDevelop.Projects.Formats.MSBuild/BuildEngine.cs +./MonoDevelop.Projects.Formats.MSBuild/ConsoleLogger.cs +./MonoDevelop.Projects.Formats.MSBuild/IBuildEngine.cs +./MonoDevelop.Projects.Formats.MSBuild/ILogWriter.cs +./MonoDevelop.Projects.Formats.MSBuild/IProjectBuilder.cs +./MonoDevelop.Projects.Formats.MSBuild/LocalLogger.cs +./MonoDevelop.Projects.Formats.MSBuild/MSBuildResult.cs +./MonoDevelop.Projects.Formats.MSBuild/ProjectBuilder.cs +error CS0006: Metadata file +`/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Engine.dll' +could not be found +error CS0006: Metadata file +`/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Framework.dll' +could not be found +error CS0006: Metadata file +`/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Utilities.v3.5.dll' +could not be found +Compilation failed: 3 error(s), 0 warnings +... + +Now I'm stuck. Help please? ++ + + +
On 21 December 2011 19:23, Dale Schumacher <dale.schumacher at gmail.com> wrote: +> Started fresh with... +> +> $ git clone https://github.com/mono/monodevelop.git +> $ cd monodevelop +> $ ./configure --prefix=/usr/local +> +> The build profile 'default' does not exist. A new profile will be created. +> Select the packages to include in the build for the profile 'default': +> +> 1. [X] main +> 2. [ ] extras/JavaBinding +> 3. [ ] extras/ValaBinding +> 4. [ ] extras/MonoDevelop.Database +> 5. [ ] extras/MonoDevelop.Debugger.Gdb +> 6. [ ] extras/PyBinding +> 7. [ ] extras/MonoDevelop.MonoMac +> 8. [ ] extras/MonoDevelop.MeeGo +> +> Enter the number of an add-in to enable/disable, +> (q) quit, (c) clear all, (s) select all, or ENTER to continue: +> +> Hit ENTER and eventually saw... +> +> checking for MONO_ADDINS... configure: error: Package requirements +> (mono-addins >= 0.6) were not met: +> +> No package 'mono-addins' found +> +> So, went back to github... +> +> $ cd .. +> $ git clone https://github.com/mono/mono-addins.git +> $ cd mono-addins +> $ ./configure --prefix=/usr/local +> -bash: ./configure: No such file or directory +> +> Instructions in README say "./configure", but I see "autogen.sh", so... +> +> $ autogen.sh --prefix=/usr/local +> $ make +> $ make install +> $ cd ../monodevelop +> $ ./configure --prefix=/usr/local --profile=core +> ... +> configure: error: You must enable one of the platform bindings +> +> OK, would be nice if README were updated with new profiles... +> +> $ rm profiles/default +> $ ./configure --prefix=/usr/local --profile=windows +> $ make +> $ make install +> ... +> /usr/local/bin/dmcs -debug -codepage:utf8 -warnaserror -debug +> -out:../../../build/bin/MonoDevelop.Projects.Formats.MSBuild.exe +> -target:winexe -r:/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Engine.dll +> -r:/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Framework.dll +> -r:/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Utilities.v3.5.dll +> -r:System -r:System.Runtime.Remoting ./AssemblyInfo.cs ./Main.cs +> ./MonoDevelop.Projects.Formats.MSBuild/BuildEngine.cs +> ./MonoDevelop.Projects.Formats.MSBuild/ConsoleLogger.cs +> ./MonoDevelop.Projects.Formats.MSBuild/IBuildEngine.cs +> ./MonoDevelop.Projects.Formats.MSBuild/ILogWriter.cs +> ./MonoDevelop.Projects.Formats.MSBuild/IProjectBuilder.cs +> ./MonoDevelop.Projects.Formats.MSBuild/LocalLogger.cs +> ./MonoDevelop.Projects.Formats.MSBuild/MSBuildResult.cs +> ./MonoDevelop.Projects.Formats.MSBuild/ProjectBuilder.cs +> error CS0006: Metadata file +> `/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Engine.dll' +> could not be found +> error CS0006: Metadata file +> `/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Framework.dll' +> could not be found +> error CS0006: Metadata file +> `/usr/local/lib/pkgconfig/../../lib/mono/3.5/Microsoft.Build.Utilities.v3.5.dll' +> could not be found +> Compilation failed: 3 error(s), 0 warnings + +It looks like your Mono installation is broken, you have a pc file +pointing at nonexistent/missing files. + +Is there any specific reason you need to build/run it in cygwin? On +Windows I'd recommend building with .NET since that's what we actively +support: http://monodevelop.com/Developers/Building_MonoDevelop#Windows + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Thu Dec 1 05:15:24 EST 2011
+ Ending: Wed Dec 21 22:49:08 EST 2011
+ Messages: 9
+
+ Last message date:
+ Wed Dec 21 22:49:08 EST 2011
+ Archived on: Wed Dec 21 22:49:12 EST 2011
+
+
+
Starting: Thu Dec 1 05:15:24 EST 2011
+ Ending: Wed Dec 21 22:49:08 EST 2011
+ Messages: 9
+
+ Last message date:
+ Wed Dec 21 22:49:08 EST 2011
+ Archived on: Wed Dec 21 22:49:12 EST 2011
+
+
+
Starting: Thu Dec 1 05:15:24 EST 2011
+ Ending: Wed Dec 21 22:49:08 EST 2011
+ Messages: 9
+
+ Last message date:
+ Wed Dec 21 22:49:08 EST 2011
+ Archived on: Wed Dec 21 22:49:12 EST 2011
+
+
+
Starting: Thu Dec 1 05:15:24 EST 2011
+ Ending: Wed Dec 21 22:49:08 EST 2011
+ Messages: 9
+
+ Last message date:
+ Wed Dec 21 22:49:08 EST 2011
+ Archived on: Wed Dec 21 22:49:12 EST 2011
+
+
+
Starting: Thu Dec 1 05:15:24 EST 2011
+ Ending: Wed Dec 21 22:49:08 EST 2011
+ Messages: 9
+
+ Last message date:
+ Wed Dec 21 22:49:08 EST 2011
+ Archived on: Wed Dec 21 22:49:12 EST 2011
+
+
+
I want to develop a new kind of "add file" template (like "C# Class"). +How ca I do? +I didn't find any article or resource! +Thanks +GM +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110202/8cbc03af/attachment.html ++ + + +
2011/2/2 Gianluca Masone <gianluca.masone at gmail.com>: +> I want to develop a new kind of "add file" template (like "C# Class"). +> How ca I do? +> I didn't find any article or resource! +> Thanks +> GM + +You must create a simple addin to register the .xft.xml file. The +addin doesn't need to have any code, it only needs an .addin.xml +manifest. + +For some information on creating addins, see: +http://monodevelop.com/Developers/Articles/Addin_development_basics + +For an example of an addin that does not have code but only templates, +see the OpenOddiceSamples addin: +https://github.com/mono/monodevelop/tree/master/extras/OpenOfficeSamples + +There are many examples of .xft.xml template files throughout the MD +source tree. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Hi Michael, thanks for the reply. +My problem now is where to place the XML file (I made an XML template file +for c# binding "MyCSharpFile.xft.xml"). + +I'm using Monodevelop on Mac and I have both Binary and Source Tree. + +In the source tree I see a folder + +monodevelop-2.4.2\monodevelop-2.4.2\src\addins\CSharpBinding\templates + +... and I suppose that the XML have to be placed here! + +In the Binary Tree I don't have this folder ... so I'm little bit confused!! +Where I have to put the XML file? + +Regards. +GM + + + + +On Thu, Feb 3, 2011 at 7:33 AM, Michael Hutchinson <m.j.hutchinson at gmail.com +> wrote: + +> 2011/2/2 Gianluca Masone <gianluca.masone at gmail.com>: +> > I want to develop a new kind of "add file" template (like "C# Class"). +> > How ca I do? +> > I didn't find any article or resource! +> > Thanks +> > GM +> +> You must create a simple addin to register the .xft.xml file. The +> addin doesn't need to have any code, it only needs an .addin.xml +> manifest. +> +> For some information on creating addins, see: +> http://monodevelop.com/Developers/Articles/Addin_development_basics +> +> For an example of an addin that does not have code but only templates, +> see the OpenOddiceSamples addin: +> https://github.com/mono/monodevelop/tree/master/extras/OpenOfficeSamples +> +> There are many examples of .xft.xml template files throughout the MD +> source tree. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> + + + +-- +** +Ingegnere Informatico* + +**Citazione: Ciò che dobbiamo imparare a fare, lo impariamo facendo. +(Aristotele)* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110203/e43eb4d7/attachment.html ++ + + +
On Thu, Feb 3, 2011 at 2:47 AM, Gianluca Masone +<gianluca.masone at gmail.com> wrote: +> Hi Michael, thanks for the reply. +> My problem now is where to place the XML file (I made an XML template file +> for c# binding "MyCSharpFile.xft.xml"). +> I'm using Monodevelop on Mac and I have both Binary and Source Tree. +> In the source tree I see a folder +> monodevelop-2.4.2\monodevelop-2.4.2\src\addins\CSharpBinding\templates +> ... and I suppose that the XML have to be placed here! +> In the Binary Tree I don't have this folder ... so I'm little bit confused!! +> Where I have to put the XML file? + +You need to create the .addin.xml file and install it and the xft file +as you would an addin, i.e. into +~/.confg/monoDevelop/addins/{your-addin-name} + +http://monodevelop.com/Developers/Articles/Creating_a_Simple_Add-in + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
We're planning to move the locations that MonoDevelop stores user +data, to make it more idiomatic for each of the major OSes that MD +runs on, to make it clearer what should be backed up and what can be +deleted safely, and to allow roaming profiles to work on Windows. + +I've documented the planned locations at +http://monodevelop.com/Developers/Articles/User_Profiles + +Please let me know if there are locations that would make sense, and +why they would be better. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
> We're planning to move the locations that MonoDevelop stores user +> data, to make it more idiomatic for each of the major OSes that MD +> runs on, to make it clearer what should be backed up and what can be +> deleted safely, and to allow roaming profiles to work on Windows. +> +> I've documented the planned locations at +> http://monodevelop.com/Developers/Articles/User_Profiles +> +> Please let me know if there are locations that would make sense, and +> why they would be better. + +Looks good. It will be a little more painful for windows users to +flush their configurations, but hopefully the new scheme will make it +necessary much less often. ++ + + +
On Mon, Feb 14, 2011 at 9:42 AM, IBBoard <ibboard at gmail.com> wrote: +> On 14/02/11 03:39, Michael Hutchinson wrote: +>> +>> We're planning to move the locations that MonoDevelop stores user +>> data, to make it more idiomatic for each of the major OSes that MD +>> runs on, to make it clearer what should be backed up and what can be +>> deleted safely, and to allow roaming profiles to work on Windows. +>> +>> I've documented the planned locations at +>> http://monodevelop.com/Developers/Articles/User_Profiles +>> +>> Please let me know if there are locations that would make sense, and +>> why they would be better. +>> +> +> It generally looks sensible for the Linux side of things. For my apps then +> I've just used the built-in .Net default paths. + +Yeah, a note on that - when I was looking at that I realized that +ApplicationData and LocalApplicationData have the wrong semantics on +Linux. The former maps to "config" and the latter maps to "data", +instead of the remote/local distinction. Because of that, I avoided +using them, and implemented the XDG spec directly. + +> The only comments/questions I'd have are: +> +> 1) For the sake of tidiness (reducing folders at a given level on a user's +> machine) would it not be better to use "MonoDevelop/version" rather than +> "MonoDevelop-version"? That way the user always gets just one MD folder + +I considered that, but I think my way makes it clearer to the user +that old profiles still exist and can be removed. It also implies that +we have versioned profiles, rather that a profile with versioned data. + +> 2) Would it be possible to include a forced migration, in case the first one +> failed or generally didn't include everything? + +This is a minor use case IMO and probably not worth complicating the +UI. However, by removing MonoDevelopProperties.xml from the target +profile, you can force a migration. + +Something I didn't implement support for is for migrating the user +data of addins that are installed after MD is first run, but this +would be easily fixable by keeping a list of migrated addins in the +properties store and checking loaded addins against it. + +It might be worth thinking about a GUI in preferences for deleting old +profiles and clearing caches. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
I followed the instructions on http://monodevelop.com/Developers/Mac_Support/Building_MonoDevelop_on_OS_X to make a custom build of MonoDevelop.app. While it works fine on my machine (running Mono 2.8.2), developers with versions other than 2.8.2 are unable to run the app (or mdtool), and receive errors to the effect of + + [exec] The assembly mscorlib.dll was not found or could not be loaded. + [exec] It should have been installed in the `/Library/Frameworks/Mono.framework/Versions/2.8.2/lib/mono/2.0/mscorlib.dll' directory. + +Is there a way to build MonoDevelop for OS X such that it will be more tolerant of other versions of Mono? + +— Dave +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110218/3c07bd89/attachment.html ++ + + +
2011/2/18 David Mitchell <dmitchell at logos.com>: +> I followed the instructions +> on http://monodevelop.com/Developers/Mac_Support/Building_MonoDevelop_on_OS_X to +> make a custom build of MonoDevelop.app. While it works fine on my machine +> (running Mono 2.8.2), developers with versions other than 2.8.2 are unable +> to run the app (or mdtool), and receive errors to the effect of +> [exec] The assembly mscorlib.dll was not found or could not be loaded. +> [exec] It should have been installed in the +> `/Library/Frameworks/Mono.framework/Versions/2.8.2/lib/mono/2.0/mscorlib.dll' +> directory. +> Is there a way to build MonoDevelop for OS X such that it will be more +> tolerant of other versions of Mono? + +All the builds we provide on MonoDevelop.com are built this way and +work fine. It sounds like there's a broken Mono installation on the +target machine. Is there any more error information? +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
I dug into this further, and the issue seems to be how the zip file is +created (I neglected to mention that we've been distributing MonoDevelop +in zip form; my apologies). Here is the relevant snippet from the Mac +makefile: + +MonoDevelop.app.zip: MonoDevelop.app + zip -r9uq MonoDevelop.app.zip MonoDevelop.app + + +We zip the file, but we don't pass the -y argument, which would cause +symlinks to be preserved. Since the app bundle symlinks to Mono, this +means that whatever I have in Versions/Current/bin/mono is copied into the +zip file, and if the target machine doesn't have this same version of Mono +installed, then MonoDevelop fails to run. I believe the Makefile should +read + +MonoDevelop.app.zip: MonoDevelop.app + zip -r9uyq MonoDevelop.app.zip MonoDevelop.app + + +I'll be pushing this change to the master and 2.4 branches of our fork and +submitting a pull request shortly. + +‹ Dave + +On 2/20/11 10:36 AM, "Michael Hutchinson" <m.j.hutchinson at gmail.com> wrote: + +>2011/2/18 David Mitchell <dmitchell at logos.com>: +>> I followed the instructions +>> on +>>http://monodevelop.com/Developers/Mac_Support/Building_MonoDevelop_on_OS_ +>>X to +>> make a custom build of MonoDevelop.app. While it works fine on my +>>machine +>> (running Mono 2.8.2), developers with versions other than 2.8.2 are +>>unable +>> to run the app (or mdtool), and receive errors to the effect of +>> [exec] The assembly mscorlib.dll was not found or could not be +>>loaded. +>> [exec] It should have been installed in the +>> +>>`/Library/Frameworks/Mono.framework/Versions/2.8.2/lib/mono/2.0/mscorlib. +>>dll' +>> directory. +>> Is there a way to build MonoDevelop for OS X such that it will be more +>> tolerant of other versions of Mono? +> +>All the builds we provide on MonoDevelop.com are built this way and +>work fine. It sounds like there's a broken Mono installation on the +>target machine. Is there any more error information? +>-- +>Michael Hutchinson +>http://mjhutchinson.com + ++ + + +
On Tue, Feb 22, 2011 at 5:24 PM, David Mitchell <dmitchell at logos.com> wrote: +> I dug into this further, and the issue seems to be how the zip file is +> created (I neglected to mention that we've been distributing MonoDevelop +> in zip form; my apologies). Here is the relevant snippet from the Mac +> makefile: +> +> MonoDevelop.app.zip: MonoDevelop.app +> zip -r9uq MonoDevelop.app.zip MonoDevelop.app +> +> +> We zip the file, but we don't pass the -y argument, which would cause +> symlinks to be preserved. Since the app bundle symlinks to Mono, this +> means that whatever I have in Versions/Current/bin/mono is copied into the +> zip file, and if the target machine doesn't have this same version of Mono +> installed, then MonoDevelop fails to run. I believe the Makefile should +> read +> +> MonoDevelop.app.zip: MonoDevelop.app +> zip -r9uyq MonoDevelop.app.zip MonoDevelop.app +> +> +> I'll be pushing this change to the master and 2.4 branches of our fork and +> submitting a pull request shortly. + +Ah, yeah, I haven't used the zip target since adding the symlink. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Hi + +I needed to disable the AST generation inside the monodevelop dom +parser. I don't think that I broke something with it - since it wasn't +used inside monodevelop at all. I needed to do it to speed up the +loading of really large files. + +Any thoughts on this ? + +Regards +Mike ++ + + +
On Fri, Feb 25, 2011 at 10:51 AM, Mike Krüger <mkrueger at novell.com> wrote: +> I needed to disable the AST generation inside the monodevelop dom +> parser. I don't think that I broke something with it - since it wasn't +> used inside monodevelop at all. I needed to do it to speed up the +> loading of really large files. +> +> Any thoughts on this ? + +Is there at least an API to get it on request? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Wed Feb 2 03:08:54 EST 2011
+ Ending: Fri Feb 25 19:19:37 EST 2011
+ Messages: 13
+
+ Last message date:
+ Fri Feb 25 19:19:37 EST 2011
+ Archived on: Fri Feb 25 19:19:40 EST 2011
+
+
+
Starting: Wed Feb 2 03:08:54 EST 2011
+ Ending: Fri Feb 25 19:19:37 EST 2011
+ Messages: 13
+
+ Last message date:
+ Fri Feb 25 19:19:37 EST 2011
+ Archived on: Fri Feb 25 19:19:40 EST 2011
+
+
+
Starting: Wed Feb 2 03:08:54 EST 2011
+ Ending: Fri Feb 25 19:19:37 EST 2011
+ Messages: 13
+
+ Last message date:
+ Fri Feb 25 19:19:37 EST 2011
+ Archived on: Fri Feb 25 19:19:40 EST 2011
+
+
+
Starting: Wed Feb 2 03:08:54 EST 2011
+ Ending: Fri Feb 25 19:19:37 EST 2011
+ Messages: 13
+
+ Last message date:
+ Fri Feb 25 19:19:37 EST 2011
+ Archived on: Fri Feb 25 19:19:40 EST 2011
+
+
+
Starting: Wed Feb 2 03:08:54 EST 2011
+ Ending: Fri Feb 25 19:19:37 EST 2011
+ Messages: 13
+
+ Last message date:
+ Fri Feb 25 19:19:37 EST 2011
+ Archived on: Fri Feb 25 19:19:40 EST 2011
+
+
+
Hey, + +I found the mono Develop Debugger implementation here. +https://github.com/mono/monodevelop/tree/master/extras/MonoDevelop.Debugger.Mdb + +I am wanting to debug Mono Applications from inside a browser using Cloud9IDE +http://www.cloud9ide.com/ + + +Before i dive in a wrap this to work over http and JSON, is there any +pointers you have. +Any prior implementations of this that you know of? +I believe the stream protocol is actually Java Debugger JDWP ? +For the IPhone i noticed the client has the ability to turn the port +agent on or off on their phone ? + +Regards + +Gerard Webb ++ + +
Starting: Sun Jan 9 15:23:49 EST 2011
+ Ending: Sun Jan 9 15:23:49 EST 2011
+ Messages: 1
+
+ Last message date:
+ Sun Jan 9 15:23:49 EST 2011
+ Archived on: Mon Jan 10 02:59:40 EST 2011
+
+
+
Starting: Sun Jan 9 15:23:49 EST 2011
+ Ending: Sun Jan 9 15:23:49 EST 2011
+ Messages: 1
+
+ Last message date:
+ Sun Jan 9 15:23:49 EST 2011
+ Archived on: Mon Jan 10 02:59:40 EST 2011
+
+
+
Starting: Sun Jan 9 15:23:49 EST 2011
+ Ending: Sun Jan 9 15:23:49 EST 2011
+ Messages: 1
+
+ Last message date:
+ Sun Jan 9 15:23:49 EST 2011
+ Archived on: Mon Jan 10 02:59:40 EST 2011
+
+
+
Starting: Sun Jan 9 15:23:49 EST 2011
+ Ending: Sun Jan 9 15:23:49 EST 2011
+ Messages: 1
+
+ Last message date:
+ Sun Jan 9 15:23:49 EST 2011
+ Archived on: Mon Jan 10 02:59:40 EST 2011
+
+
+
Starting: Sun Jan 9 15:23:49 EST 2011
+ Ending: Sun Jan 9 15:23:49 EST 2011
+ Messages: 1
+
+ Last message date:
+ Sun Jan 9 15:23:49 EST 2011
+ Archived on: Mon Jan 10 02:59:40 EST 2011
+
+
+
There’s a big commercial application that comes with a C++ plugin API which +I am wrapping to allow users to write plugins for that application using C# +or other .Net/Mono languages. Everything works quite well using MS .Net and +Visual Studio: + + + +I have a master C++ plugin that brings up the .Net runtime in which I start +one or more C#/.Net plugins from which I can use and call C# classes and +methods wrapped around the original C++ API. I can debug into the C# code, +set breakpoints – all is quite well. + + + +Now I’d like to use the Mono runtime instead of the .Net runtime in my +master plugin and MonoDevelop to edit and debug C# plugins because the +target application is also available on the Mac. Currently I’m still +developing under Windows 7. I developed a MonoDevelop Add-In that starts the +Soft Debugger. What already works is: + +Starting the Mono runtime (Mono 2.10.2) from my C++ master plugin, loading +managed assemblies and invoking managed code. + +Building assemblies using MonoDevleop (v. 2.6 beta 3). + +The target application comes up, my managed plugins are started, and somehow +the debugger seems to connect. + + + +BUT: + +No breakpoint is ever hit. All breakpoints set in MonoDevelop appear invalid +when MonoDevelop enters debug mode. + + + +I rebuilt mono-2.0.dll and debugged into it from Visual Studio where I can +see that my embedded mono runtime seems to start in debug mode – it tries to +connect to localhost, port 57432 (I took the port number that Unity seems +successfully connect to the soft debugger – but my app is not related to +Unity). So it doesn’t seem to be a basic connection problem. + + + +Since I’m pretty new to all the stuff: Do you have any idea where I could +start searching? I read something about Mono using the mdb debug format, +while mono creates pdb files – Could this be a problem? Or is all the stuff +just too new as I’m using beta versions of Mono and MonoDevelop? Is there a +way to break into the soft debugger from C# code (like breaking into the +Visual Studio debugger with System.Diagnostics.Debugger.Break ()? + + + +Thanks for any hint. + +Christoph + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110711/edca53d2/attachment.html ++ + + +
> No breakpoint is ever hit. All breakpoints set in MonoDevelop appear invalid +> when MonoDevelop enters debug mode. +> +> [...] +> +> Since I’m pretty new to all the stuff: Do you have any idea where I could +> start searching? I read something about Mono using the mdb debug format, +> while mono creates pdb files – Could this be a problem? + +Yes, you need mdbs. Either build the assemblies using Mono, or use +pdb2mdb on your .net-generated pdbs. ++ + + +
>> No breakpoint is ever hit. All breakpoints set in MonoDevelop appear +>> invalid when MonoDevelop enters debug mode. +>> +>> [...] +>> +>> Since I’m pretty new to all the stuff: Do you have any idea where I +>> could start searching? I read something about Mono using the mdb debug +>> format, while mono creates pdb files – Could this be a problem? +> +> Yes, you need mdbs. Either build the assemblies using Mono, or use +> pdb2mdb on your .net-generated pdbs. + +Thx for the hint. Just to clarify: the pdbs were generated by MonoDevelop +(2.6) and not by Visual Studio. Am I wrong thinking they actually ARE built +by Mono? + +I'll give pdb2mdb a try, though. + ++ + + +
> Thx for the hint. Just to clarify: the pdbs were generated by MonoDevelop +> (2.6) and not by Visual Studio. Am I wrong thinking they actually ARE built +> by Mono? + +On windows, MonoDevelop runs on (and builds with) .net by default. ++ + + +
>> (2.6) and not by Visual Studio. Am I wrong thinking they actually ARE +>> built by Mono? +> +>On windows, MonoDevelop runs on (and builds with) .net by default. + +Allright, that explains things. Thank you. Now I managed to build my mdbs +with pdb2mdb as well as setting the .Net runtime to default to Mono-2.10.2 +in MonoDevelop's preferences. Both ways result in an mdb file changing the +behavior in the same way: + +When setting a breakpoint in MonoDevelop on my C# code, my +mono-embedding-application crashes (with MonoDevelop in Debug mode and +showing the breakpoint as "active"). Activating my self-built mono-2.0.dll +and debugging into the native application shows that the mono runtime seems +to crash in mini.c in the function mono_jit_runtime_invoke when calling +"return runtime_invoke(obj, params, exc, info->compiled_method);". This is +called when my embedding application's C++ code invokes a method on some +object. From that the above line is called about 27 times before the crash +occurs on that line on the 28th pass-by. + +When deactivating the breakpoint in MonoDevelop no crash occurs - I can then +set and remove breakpoints in MonoDevelop in debug mode and the breakpoints +appear as active. But hitting a breakpoint will crash. This happens with my +self-built mono-2.0.dll as well as with the one shipped with the 2.10 mono +distribution. + +It seems as if the code injected by a breakpoint has some defect. Any idea +what to try next? Is this due to beta status of Mono 2.10 or MonoDevelop +2.6? + +Thanks for further advice. + ++ + + +
> When setting a breakpoint in MonoDevelop on my C# code, my +> mono-embedding-application crashes (with MonoDevelop in Debug mode and +> showing the breakpoint as "active"). Activating my self-built mono-2.0.dll +> and debugging into the native application shows that the mono runtime seems +> to crash in mini.c in the function mono_jit_runtime_invoke when calling +> "return runtime_invoke(obj, params, exc, info->compiled_method);". This is +> called when my embedding application's C++ code invokes a method on some +> object. From that the above line is called about 27 times before the crash +> occurs on that line on the 28th pass-by. +> +> When deactivating the breakpoint in MonoDevelop no crash occurs - I can then +> set and remove breakpoints in MonoDevelop in debug mode and the breakpoints +> appear as active. But hitting a breakpoint will crash. This happens with my +> self-built mono-2.0.dll as well as with the one shipped with the 2.10 mono +> distribution. +> +> It seems as if the code injected by a breakpoint has some defect. Any idea +> what to try next? Is this due to beta status of Mono 2.10 or MonoDevelop +> 2.6? + +Sdb uses segmentation faults to trigger breakpoints, so a native +debugger will detect them as crashes when they're triggered. +Is your app actually crashing when the (VS) debugger isn't attached? +Also, breakpoints will actually cause (unhandled) crashes on 64bit +windows prior to win7sp1, I don't know what version of vista, and all +known versions of xp. ( http://support.microsoft.com/kb/976038 ) ++ + + +
> Sdb uses segmentation faults to trigger breakpoints, so a native debugger +> will detect them as crashes when they're triggered. Is your app actually +> crashing when the (VS) debugger isn't attached? +> Also, breakpoints will actually cause (unhandled) crashes on 64bit windows +> prior to win7sp1, I don't know what version of vista, and all known +versions of xp. +> (http://support.microsoft.com/kb/976038) + +Thx for your quick reply. I am running on win7sp1 64 bit. Yes, my app also +crashes with the VS debugger not attached, with both, my self-built version +of mono-2.0.dll as well as the one shipped with Mono 2.10. Well, it's not +quite a crash - it's rather some application message box saying that there +was some severe error and the app is going to close now. Maybe there's some +segmentation fault exception handler built into the native app? How do I get +the soft debugger exception handler (don't know if that's the correct +terminology) to handle the breakpoint exception first? + +I'll probably try to recreate the situation with a simple console C++ +application to see if there's a difference to the application I'm currently +using. + +Thanks again + ++ + + + +
Hello: + +I've been developing C#.NET applications for sometime now and have been in the business of developing business applications some 20+ years. About 5 months ago i became interested in iPhone development when i happened upon MonoDevelop. I found a book on Books24x7.com which i've worked through and have an iPhone app underway which i feel pretty good about. + +That said, I've been finding that the more i dive into this development environment the fewer comprehensive references and development support help i find. I'm starting to get into more advanced levels of development, but keep running into "walls" as the learning curve steers me. It seems to me that learning Objective-C is an inevitable reality, and so I am working through learning the language as well. + +But the going is slow, and being accustomed to tons of .NET support and stuff you can find on Google I'm becoming a bit frustrated with my progress. I'm kind of at a lost in deciding if I should stick with MonoDevelop or switch over to Xcode and Objective-C and could use some good advice on which direction I should go. Also, can one build components in Xcode/Objective-C and use them in MonoDevelop? + +Further, I would welcome any information on MonoDevelop support, books, tutorials, samples, forums, online chats, any other kind of MonoDevelop and/or Xcode development resources, etc. In particular I would like to master the art of showing a view that my users can flip the pages with their fingers, like when reading a book. I've seen this kind of thing, but can only find samples on how to do it in Xcode/Objective-C and would really rather do it in MonoDevelop. + + +Best Regards, +Jim + ++ + + + + +
Please contact http://xamarin.com/ . + +I'm quite sure they will try to help you. + +Rafael "Monoman" Teixeira +--------------------------------------- +"The most exciting phrase to hear in science, the one that heralds new +discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" +Isaac Asimov +US science fiction novelist & scholar (1920 - 1992) + + +On Thu, Jul 21, 2011 at 10:35 PM, Jim Taranto <jtaranto at bellsouth.net>wrote: + +> Hello: +> +> I've been developing C#.NET applications for sometime now and have been in +> the business of developing business applications some 20+ years. About 5 +> months ago i became interested in iPhone development when i happened upon +> MonoDevelop. I found a book on Books24x7.com which i've worked through and +> have an iPhone app underway which i feel pretty good about. +> +> That said, I've been finding that the more i dive into this development +> environment the fewer comprehensive references and development support help +> i find. I'm starting to get into more advanced levels of development, but +> keep running into "walls" as the learning curve steers me. It seems to me +> that learning Objective-C is an inevitable reality, and so I am working +> through learning the language as well. +> +> But the going is slow, and being accustomed to tons of .NET support and +> stuff you can find on Google I'm becoming a bit frustrated with my progress. +> I'm kind of at a lost in deciding if I should stick with MonoDevelop or +> switch over to Xcode and Objective-C and could use some good advice on which +> direction I should go. Also, can one build components in Xcode/Objective-C +> and use them in MonoDevelop? +> +> Further, I would welcome any information on MonoDevelop support, books, +> tutorials, samples, forums, online chats, any other kind of MonoDevelop +> and/or Xcode development resources, etc. In particular I would like to +> master the art of showing a view that my users can flip the pages with their +> fingers, like when reading a book. I've seen this kind of thing, but can +> only find samples on how to do it in Xcode/Objective-C and would really +> rather do it in MonoDevelop. +> +> +> Best Regards, +> Jim +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110722/260b04d8/attachment.html ++ + + + +
+>> Sdb uses segmentation faults to trigger breakpoints, so a native +>> debugger will detect them as crashes when they're triggered. Is your +>> app actually crashing when the (VS) debugger isn't attached? +>> Also, breakpoints will actually cause (unhandled) crashes on 64bit +>> windows prior to win7sp1, I don't know what version of vista, and all +known versions of xp. +>> (http://support.microsoft.com/kb/976038) + +>Thx for your quick reply. I am running on win7sp1 64 bit. Yes, my app also +crashes with the +>VS debugger not attached, with both, my self-built version of mono-2.0.dll +as well as the +>one shipped with Mono 2.10. Well, it's not quite a crash - it's rather some +application +>message box saying that there was some severe error and the app is going to +close now. +>Maybe there's some segmentation fault exception handler built into the +native app? +>How do I get the soft debugger exception handler (don't know if that's the +correct +>terminology) to handle the breakpoint exception first? +>I'll probably try to recreate the situation with a simple console C++ +application to +>see if there's a difference to the application I'm currently using. +>Thanks again + +Sorry to annoy you again. I'm still looking for a way to embed mono into a +C++Plugin-API of a commercial product (I don't have the sources) and still +trying to get the monodevelop soft-debugger connected. So I am initializing +mono from some C++ Plugin for that product I have written. I can start the +app from my self-written Monodevelop-Addon and everything runs quite well. +Whenever I set a breakpoint in Monodevelop, the app crashes when hitting the +breakpoint. + +As it seems, the product wraps every call to Plugins into some sort of __try +{} __except block. At least that's the most probable explanation why the +seh_handler set by SetUnhandledExceptionFilter (exceptions-x86.c) is never +reached - the exception (or segmentation fault) generated by a breakpoint is +swallowed by the application and results in an error message from the +application code. + +>From my plugin, I was able to set my own exception block around some code +calling into mono like the following: + +MonoObject *CallPluginStart(MonoMethod *methodStart, void *pluginobject) +{ + MonoObject *result = NULL; + __try + { + // plugin.Start(); + result = mono_runtime_invoke(methodStart, pluginobject, +NULL, NULL); + } + __except(GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ? +EXCEPTION_EXECUTE_HANDLER) : +EXCEPTION_CONTINUE_SEARCH) + { + volatile int i = 42; + } + return result; +} + +And I verified that I get into the exception block when a breakpoint is set +and that the invoke call returns without exception when no breakpoint is +hit. + +So now my question is: Is there a way to bypass the application's exception +handling to enable the seh_handler installed by mono to handle the +segmentation fault (and report the breakpoint hit to the to the connected +debugger)? + +My first idea was to call the seh_handler directly from the code above, but +I had problems with building my mono-2.0-dll and I wanted to know if that's +a promising solution before carrying on. + +The other idea I had was: Why not install the exception handler using +AddVectoredExceptionHandler instead of (or in addition to) +SetUnhandledExceptionFilter. A handler installed that way can be told to be +the first in line, so it would be called before the application gets +signaled. Also trying this approach would mean that I need to build my own +mono-2.0.dll. + +I'd be glad if you could give me some expert opinion what would be the best +way for me to proceed. + +Thanks a lot, +Christoph + + ++ + + +
Update:
+I tried the second approach - to use AddVectoredExceptionHandler(1,
+seh_handler) to inject the mono exception handler first in line into the
+queue of exception handlers along the stack frame (with the unhandled
+exception handler being last and never reached in my scenario).
+
+It worked! I tried it with directly tweaking the mono sources
+(exceptions-x86.c in line 249). To avoid using a tweaked mono I did the
+following: right after embedding mono and setting it up for debugging (after
+calling mono_jit_init) I added this to my own code (the application plugin
+that embeds mono):
+
+ LPTOP_LEVEL_EXCEPTION_FILTER seh_handler =
+SetUnhandledExceptionFilter(NULL);
+ AddVectoredExceptionHandler(1, seh_handler);
+ SetUnhandledExceptionFilter(seh_handler);
+
+So I retrieve the unhandled exception handler set by mono, re-set it as the
+unhandled exception handler and additionally set it as the first-in-line
+exception handler. And this works, too - without changing the mono sources.
+
+Now I don't know what (probably critical) side effects this might cause. In
+general swallowing all exceptions doesn't sound like too a good idea.
+Frankly, I don't understand much of what happens in the seh_handler function
+(exceptions-x86.c in line 174). I could imagine implementing some filter
+function that does not call the original seh_handler on every signal but
+only for those which are raised due to breakpoints. Any hints and comments
+on that would be greatly appreciated.
+
+Thanks a lot,
+Christoph
+
+
+
+
+------------------ old message --------------------------
+
+Sorry to annoy you again. I'm still looking for a way to embed mono into a
+C++Plugin-API of a commercial product (I don't have the sources) and still
+trying to get the monodevelop soft-debugger connected. So I am initializing
+mono from some C++ Plugin for that product I have written. I can start the
+app from my self-written Monodevelop-Addon and everything runs quite well.
+Whenever I set a breakpoint in Monodevelop, the app crashes when hitting the
+breakpoint.
+
+As it seems, the product wraps every call to Plugins into some sort of __try
+{} __except block. At least that's the most probable explanation why the
+seh_handler set by SetUnhandledExceptionFilter (exceptions-x86.c) is never
+reached - the exception (or segmentation fault) generated by a breakpoint is
+swallowed by the application and results in an error message from the
+application code.
+
+>From my plugin, I was able to set my own exception block around some code
+calling into mono like the following:
+
+MonoObject *CallPluginStart(MonoMethod *methodStart, void *pluginobject) {
+ MonoObject *result = NULL;
+ __try
+ {
+ // plugin.Start();
+ result = mono_runtime_invoke(methodStart, pluginobject,
+NULL, NULL);
+ }
+ __except(GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
+EXCEPTION_EXECUTE_HANDLER) :
+EXCEPTION_CONTINUE_SEARCH)
+ {
+ volatile int i = 42;
+ }
+ return result;
+}
+
+And I verified that I get into the exception block when a breakpoint is set
+and that the invoke call returns without exception when no breakpoint is
+hit.
+
+So now my question is: Is there a way to bypass the application's exception
+handling to enable the seh_handler installed by mono to handle the
+segmentation fault (and report the breakpoint hit to the to the connected
+debugger)?
+
+My first idea was to call the seh_handler directly from the code above, but
+I had problems with building my mono-2.0-dll and I wanted to know if that's
+a promising solution before carrying on.
+
+The other idea I had was: Why not install the exception handler using
+AddVectoredExceptionHandler instead of (or in addition to)
+SetUnhandledExceptionFilter. A handler installed that way can be told to be
+the first in line, so it would be called before the application gets
+signaled. Also trying this approach would mean that I need to build my own
+mono-2.0.dll.
+
+I'd be glad if you could give me some expert opinion what would be the best
+way for me to proceed.
+
+Thanks a lot,
+Christoph
+
+
+
+
+
+ Starting: Sun Jul 10 18:36:20 EDT 2011
+ Ending: Tue Jul 26 17:20:13 EDT 2011
+ Messages: 11
+
+ Last message date:
+ Tue Jul 26 17:20:13 EDT 2011
+ Archived on: Tue Jul 26 17:20:18 EDT 2011
+
+
+
Starting: Sun Jul 10 18:36:20 EDT 2011
+ Ending: Tue Jul 26 17:20:13 EDT 2011
+ Messages: 11
+
+ Last message date:
+ Tue Jul 26 17:20:13 EDT 2011
+ Archived on: Tue Jul 26 17:20:18 EDT 2011
+
+
+
Starting: Sun Jul 10 18:36:20 EDT 2011
+ Ending: Tue Jul 26 17:20:13 EDT 2011
+ Messages: 11
+
+ Last message date:
+ Tue Jul 26 17:20:13 EDT 2011
+ Archived on: Tue Jul 26 17:20:18 EDT 2011
+
+
+
Starting: Sun Jul 10 18:36:20 EDT 2011
+ Ending: Tue Jul 26 17:20:13 EDT 2011
+ Messages: 11
+
+ Last message date:
+ Tue Jul 26 17:20:13 EDT 2011
+ Archived on: Tue Jul 26 17:20:18 EDT 2011
+
+
+
Starting: Sun Jul 10 18:36:20 EDT 2011
+ Ending: Tue Jul 26 17:20:13 EDT 2011
+ Messages: 11
+
+ Last message date:
+ Tue Jul 26 17:20:13 EDT 2011
+ Archived on: Tue Jul 26 17:20:18 EDT 2011
+
+
+
Hi + +Monodevelop joins forces with the SharpDevelop team in the area 'how do +we represent source code'. +(Some of you may know that I've good contacts to the #develop team - I +started #develop 2000 and left 2006 - and joined monodevelop 2007). + +This will change the monodevelop source code a bit: + +- The old nrefactory and it's DOM is depreceted and we wont see it +again. (It lived for more than 10 years now) + +It will be replaced with a shiny new Ast + Parser. The parser most of +you know as 'mcs' and the Ast is inside the c# binding - and inside the +new nrefactory on github. + +For consuming code only little issues change (I translated much old +nrefactory code). Most should be 'the same' on user side. With one +exception: you can't 'reparent' ast nodes: + +Doesn't work: + ifStatment.EmbeddedStatment = forStatment.EmbeddedStatment; + +You can do that using the 'Clone' method. + +Works: + ifStatment.EmbeddedStatment = forStatment.EmbeddedStatment.Clone (); + +All ast nodes have links to their parents & siblings - that's why a node +can have only one place in the tree. The tree contains all tokens, +comments etc. and it is able to hold new lines/white spaces or any other +sort of information. +The tree infrastructure is pretty mature (thanks to marek providing the +parser) it contains exact text locations for any c# token inside the ast +- it's pretty nice to write refactorings with that. + +- The DOM changes - in fact it's not called DOM anymore we call it now +'Type system'. I've always had problems explaining the differences +between MD DOM and C# DOM. Now we call it abstract syntax tree on the +language level and give the high level representation the name 'type +system'. + +#Develop once started with a type system like monodevelop has from the +model - I used something like reflection - but didn't really care about +that much. The #develop team made some great effort on that layer. +They've a better representation & resolving strategy than we had. Here +some things change. + +MD Dom: Getting all methods on a type: +GetAllMethods ().... + foreach (var type in dom.GetInheritanceTree (origType)) + foreach (var method in type.Methods) + yield return method; + +NRefactory dom: +GetAllMethods ().... + origType.GetMethods (ctx); + +I think you'll get the point - their type system is more high level than +ours was. It's easier to get the accisibility (finding out if something +is private wasn't really easy with the monodevelop dom since the private +modifier was syntactic). +The type names will sound all familiar - they're the same. Whats mostly +changing is that the 'dom' as object will not be so important anymore - +instead it'll be a parameter of most methods. +Even if the usage is 'mostly' the same the model is very different: +- CompilationUnits (are now called IParsedFile) are now always stored +correctly (this info is never lost). +- The resolving of return types is done at call time. There is no real +way to do it clean without that, but the resolver is lighting fast and +correctness > speed. This resolves some issues we had (like changing +namespaces, makes it possible to use 'external aliases') +- IType and the definition are now 2 classes +IType is that what 'InstantiatedType' was and ITypeDefinition is the +real definition in file. You won't need ITypeDefinition very often - +most stuff is done with IType. + +While consuming code should be easy to translate dom parsers are a bit +harder to translate (but again - mostly the same). Atm we've c# and +cecil as type system source - and I think that nrefactory.vb has a type +system converter + parser + ast for vb.net. Ovearall the new type system +feels a lot more like a 'high level' api, which is a good thing. + +- Resolver changes +The new resolver infrastructure changes internally very much - the old +one basically took an expression and a position in the file. Then it +gave you a resolve result. The new resolver resolves a 'set' of ast +nodes. And then it analyzes the ast with the 'set' (the set should +contain all parents of the node to resolve, all other nodes are +skipped). I intend to hide the resolver internals from the users, so +that they do not need to care about that (In fact I keep the resolver +backend mostly intact - but the ResolveResults change - the new resolver +brings own results, but consuming code is very easy to translate). +What I can say is that the new one + infrastructure is very fast to use :) + +... I don't know when I do the commit, but the ast/type system/resolver +is all in NRefactory - I just translate our infrastructure over. Atm I +broke some things - for ex. the refactoring infrastructure & c# code +completion. But semantic highlighting works and it seems to be usable +now :) - context actions are in place as well. I think that I'll commit +around friday (y, I want to get sure I didn't break anything and I need +to fix some issues that are only working 80% - I commented out some +functions that I didn't find not so important for ex. in the code +metrics or unit tests) + I can't tell how long I need for the code +completion. + +Regards +Mike ++ + + +
> +> Even if the usage is 'mostly' the same the model is very different: +> - CompilationUnits (are now called IParsedFile) are now always stored +> correctly (this info is never lost). +> - The resolving of return types is done at call time. There is no real +> way to do it clean without that, but the resolver is lighting fast and +> correctness > speed. This resolves some issues we had (like changing +> namespaces, makes it possible to use 'external aliases') + +Will this resolution of types be transparent? that is, if I get for example the list of fields of a class and I want to get the type of each field, will I have to make a call to resolve each type or will the type system resolve the type for me when I query it? + +> - IType and the definition are now 2 classes +> IType is that what 'InstantiatedType' was and ITypeDefinition is the +> real definition in file. You won't need ITypeDefinition very often - +> most stuff is done with IType. +> +> While consuming code should be easy to translate dom parsers are a bit +> harder to translate (but again - mostly the same). Atm we've c# and +> cecil as type system source - and I think that nrefactory.vb has a type +> system converter + parser + ast for vb.net. Ovearall the new type system +> feels a lot more like a 'high level' api, which is a good thing. +> +> - Resolver changes +> The new resolver infrastructure changes internally very much - the old +> one basically took an expression and a position in the file. Then it +> gave you a resolve result. The new resolver resolves a 'set' of ast +> nodes. And then it analyzes the ast with the 'set' (the set should +> contain all parents of the node to resolve, all other nodes are +> skipped). I intend to hide the resolver internals from the users, so +> that they do not need to care about that (In fact I keep the resolver +> backend mostly intact - but the ResolveResults change - the new resolver +> brings own results, but consuming code is very easy to translate). +> What I can say is that the new one + infrastructure is very fast to use :) +> +> ... I don't know when I do the commit, but the ast/type system/resolver +> is all in NRefactory - I just translate our infrastructure over. Atm I +> broke some things - for ex. the refactoring infrastructure & c# code +> completion. But semantic highlighting works and it seems to be usable +> now :) - context actions are in place as well. I think that I'll commit +> around friday (y, I want to get sure I didn't break anything and I need +> to fix some issues that are only working 80% - I commented out some +> functions that I didn't find not so important for ex. in the code +> metrics or unit tests) + I can't tell how long I need for the code +> completion. + +Right now, we can't afford de-stabilizing master. You should commit those changes in a branch and make it public. Then we can test it and when everything is ready, we can merge to master. + +Lluis. + ++ + + +
Hi + +>> Even if the usage is 'mostly' the same the model is very different: +>> - CompilationUnits (are now called IParsedFile) are now always stored +>> correctly (this info is never lost). +>> - The resolving of return types is done at call time. There is no real +>> way to do it clean without that, but the resolver is lighting fast and +>> correctness> speed. This resolves some issues we had (like changing +>> namespaces, makes it possible to use 'external aliases') +> Will this resolution of types be transparent? that is, if I get for example the list of fields of a class and I want to get the type of each field, will I have to make a call to resolve each type or will the type system resolve the type for me when I query it? +If you resolve a TypeReference (==IReturnType) you get a IType which is +fully resolved. There is more than one IType 'implementation' that +handles the more complex cases. +InstantiatedType == ParameterizedType for example. For arrays there is +an ArrayType etc. + +A branch is a good idea - but I think that we shouldn't wait too long to +merge it, maybe 1-2 months. I'll make my branch public when code +completion works again. + +Regards +Mike ++ + +
Starting: Tue Jun 14 10:52:03 EDT 2011
+ Ending: Tue Jun 14 13:05:29 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Tue Jun 14 13:05:29 EDT 2011
+ Archived on: Tue Jun 14 13:05:47 EDT 2011
+
+
+
Starting: Tue Jun 14 10:52:03 EDT 2011
+ Ending: Tue Jun 14 13:05:29 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Tue Jun 14 13:05:29 EDT 2011
+ Archived on: Tue Jun 14 13:05:47 EDT 2011
+
+
+
Starting: Tue Jun 14 10:52:03 EDT 2011
+ Ending: Tue Jun 14 13:05:29 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Tue Jun 14 13:05:29 EDT 2011
+ Archived on: Tue Jun 14 13:05:47 EDT 2011
+
+
+
Starting: Tue Jun 14 10:52:03 EDT 2011
+ Ending: Tue Jun 14 13:05:29 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Tue Jun 14 13:05:29 EDT 2011
+ Archived on: Tue Jun 14 13:05:47 EDT 2011
+
+
+
Starting: Tue Jun 14 10:52:03 EDT 2011
+ Ending: Tue Jun 14 13:05:29 EDT 2011
+ Messages: 3
+
+ Last message date:
+ Tue Jun 14 13:05:29 EDT 2011
+ Archived on: Tue Jun 14 13:05:47 EDT 2011
+
+
+
I'm writing an add-in for MonoDevelop, starting from +http://monodevelop.com/Developers/Articles/Creating_a_Simple_Add-in. I +have this working, and would like to add a context menu in the source +code and the xml editors. Unfortunately the page +http://monodevelop.com/Developers/Articles/The_Command_System has only +"TODO" under the context menu section. + +Browsing the latest source from Git I've tried all of the following, +but none of them work: + + <Extension path = "/MonoDevelop/Ide/SourceEditor/ContextMenu/Editor"> + <CommandItem +id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +/> + </Extension> + + <Extension path = "/MonoDevelop/Ide/SourceEditor2/ContextMenu/Editor"> + <CommandItem +id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +/> + </Extension> + + <Extension path = "/MonoDevelop/SourceEditor/ContextMenu/Editor"> + <CommandItem +id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +/> + </Extension> + + <Extension path = "/MonoDevelop/SourceEditor2/ContextMenu/Editor"> + <CommandItem +id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +/> + </Extension> + + +btw I'd be happy to update that page, if appropriate. + +thanks, + +Jools ++ + + +
Hi + +The path "/MonoDevelop/SourceEditor2/ContextMenu/Editor" is the correct +one - you don't need to use "/MonoDevelop/SourceEditor/ContextMenu/Editor". + +Did you add the "SourceEditor2" into the dependencies - something like : + +<Dependencies> +<Addin id="SourceEditor2" version="2.6"/> +</Dependencies> + +Regards +Mike +> I'm writing an add-in for MonoDevelop, starting from +> http://monodevelop.com/Developers/Articles/Creating_a_Simple_Add-in. I +> have this working, and would like to add a context menu in the source +> code and the xml editors. Unfortunately the page +> http://monodevelop.com/Developers/Articles/The_Command_System has only +> "TODO" under the context menu section. +> +> Browsing the latest source from Git I've tried all of the following, +> but none of them work: +> +> <Extension path = "/MonoDevelop/Ide/SourceEditor/ContextMenu/Editor"> +> <CommandItem +> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +> /> +> </Extension> +> +> <Extension path = "/MonoDevelop/Ide/SourceEditor2/ContextMenu/Editor"> +> <CommandItem +> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +> /> +> </Extension> +> +> <Extension path = "/MonoDevelop/SourceEditor/ContextMenu/Editor"> +> <CommandItem +> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +> /> +> </Extension> +> +> <Extension path = "/MonoDevelop/SourceEditor2/ContextMenu/Editor"> +> <CommandItem +> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +> /> +> </Extension> +> +> +> btw I'd be happy to update that page, if appropriate. +> +> thanks, +> +> Jools +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + ++ + + +
Yup, that fixed it. Thanks. (with 2.4 as the version). I hadn't really +understood what the dependencies were for. + +btw Is there a way of debugging that sort of thing? I never saw +anything in the messages window telling me that my path was incorrect. + +Jools + +On 24 March 2011 13:00, Mike Krüger <mkrueger at novell.com> wrote: +> Hi +> +> The path "/MonoDevelop/SourceEditor2/ContextMenu/Editor" is the correct one +> - you don't need to use "/MonoDevelop/SourceEditor/ContextMenu/Editor". +> +> Did you add the "SourceEditor2" into the dependencies - something like : +> +> <Dependencies> +> <Addin id="SourceEditor2" version="2.6"/> +> </Dependencies> +> +> Regards +> Mike +>> +>> I'm writing an add-in for MonoDevelop, starting from +>> http://monodevelop.com/Developers/Articles/Creating_a_Simple_Add-in. I +>> have this working, and would like to add a context menu in the source +>> code and the xml editors. Unfortunately the page +>> http://monodevelop.com/Developers/Articles/The_Command_System has only +>> "TODO" under the context menu section. +>> +>> Browsing the latest source from Git I've tried all of the following, +>> but none of them work: +>> +>> <Extension path = "/MonoDevelop/Ide/SourceEditor/ContextMenu/Editor"> +>> <CommandItem +>> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +>> /> +>> </Extension> +>> +>> <Extension path = "/MonoDevelop/Ide/SourceEditor2/ContextMenu/Editor"> +>> <CommandItem +>> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +>> /> +>> </Extension> +>> +>> <Extension path = "/MonoDevelop/SourceEditor/ContextMenu/Editor"> +>> <CommandItem +>> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +>> /> +>> </Extension> +>> +>> <Extension path = "/MonoDevelop/SourceEditor2/ContextMenu/Editor"> +>> <CommandItem +>> id="MonoDevelop.Samples.DateInserter.DateInserterCommands.InsertDate" +>> /> +>> </Extension> +>> +>> +>> btw I'd be happy to update that page, if appropriate. +>> +>> thanks, +>> +>> Jools +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> ++ + + +
Hello -- + Is the main.sln out of sync with Visual Studio 2010/2010 SP1? I haven't +tried to build on Windows in some time. Opening the solution in VS2010 and +VS2010 SP1 results in the upgrade solution dialog. Thanks. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110329/d4b1dbfa/attachment.html ++ + +
Starting: Thu Mar 24 07:04:15 EDT 2011
+ Ending: Tue Mar 29 17:26:11 EDT 2011
+ Messages: 4
+
+ Last message date:
+ Tue Mar 29 17:26:11 EDT 2011
+ Archived on: Tue Mar 29 17:26:13 EDT 2011
+
+
+
Starting: Thu Mar 24 07:04:15 EDT 2011
+ Ending: Tue Mar 29 17:26:11 EDT 2011
+ Messages: 4
+
+ Last message date:
+ Tue Mar 29 17:26:11 EDT 2011
+ Archived on: Tue Mar 29 17:26:13 EDT 2011
+
+
+
Starting: Thu Mar 24 07:04:15 EDT 2011
+ Ending: Tue Mar 29 17:26:11 EDT 2011
+ Messages: 4
+
+ Last message date:
+ Tue Mar 29 17:26:11 EDT 2011
+ Archived on: Tue Mar 29 17:26:13 EDT 2011
+
+
+
Starting: Thu Mar 24 07:04:15 EDT 2011
+ Ending: Tue Mar 29 17:26:11 EDT 2011
+ Messages: 4
+
+ Last message date:
+ Tue Mar 29 17:26:11 EDT 2011
+ Archived on: Tue Mar 29 17:26:13 EDT 2011
+
+
+
Starting: Thu Mar 24 07:04:15 EDT 2011
+ Ending: Tue Mar 29 17:26:11 EDT 2011
+ Messages: 4
+
+ Last message date:
+ Tue Mar 29 17:26:11 EDT 2011
+ Archived on: Tue Mar 29 17:26:13 EDT 2011
+
+
+
Hi, + +MonoDevelop 2.6 has been branched. Upcoming beta and/or RC releases will +be done from that branch, so development of new features can continue in +master. + +Lluis. + ++ + + +
I'll try and double-check my bug/issue list in the next week or so and +see if they've all been tidied up yet. + +Is there a rough schedule for when release is expected? I know I've +encountered a few points where MD was a bit flakey on some not too niche +areas in recent weeks, so it'd be good to make sure they're all gone +before the release arrives. + + + +On 03/05/11 11:47, Lluis Sanchez Gual wrote: +> Hi, +> +> MonoDevelop 2.6 has been branched. Upcoming beta and/or RC releases will +> be done from that branch, so development of new features can continue in +> master. +> +> Lluis. +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list ++ + + +
Hello, + +I am trying to debug the latest monodevelop from github and whenever I start +the debugger I get the following error message. + +"The debugger's protocol is incompatible with the debuggee (Exception from +HRESULT: 0x8013134B)." + +I am using a Windows 7 64 bit machine. The Main.sln target is +DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying to debug +from within it. + +Thank you for your help. + +-- +Juba +*@jubaborgohain <http://www.twitter.com/jubaborgohain>* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110527/35a8e01b/attachment.html ++ + + +
Hi, + +What kind of project are you debugging? C#? Are you using the +Microsoft runtime or the Mono runtime? + +Regards, +Alex + +2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> Hello, +> +> I am trying to debug the latest monodevelop from github and whenever I start +> the debugger I get the following error message. +> +> "The debugger's protocol is incompatible with the debuggee (Exception from +> HRESULT: 0x8013134B)." +> +> I am using a Windows 7 64 bit machine. The Main.sln target is +> DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying to debug +> from within it. +> +> Thank you for your help. +> +> -- +> Juba +> @jubaborgohain +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> ++ + + +
Hi, + +I am trying to debug monodevelop (pulled from github) from inside of +monodevelop 2.4.2.1. I am using the default runtime that is set, in my case +Microsoft. + +Thanks, +Jubaraj + +On Fri, May 27, 2011 at 9:28 AM, Alex <xtzgzorex at gmail.com> wrote: + +> Hi, +> +> What kind of project are you debugging? C#? Are you using the +> Microsoft runtime or the Mono runtime? +> +> Regards, +> Alex +> +> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> > Hello, +> > +> > I am trying to debug the latest monodevelop from github and whenever I +> start +> > the debugger I get the following error message. +> > +> > "The debugger's protocol is incompatible with the debuggee (Exception +> from +> > HRESULT: 0x8013134B)." +> > +> > I am using a Windows 7 64 bit machine. The Main.sln target is +> > DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying to +> debug +> > from within it. +> > +> > Thank you for your help. +> > +> > -- +> > Juba +> > @jubaborgohain +> > +> > _______________________________________________ +> > Monodevelop-devel-list mailing list +> > Monodevelop-devel-list at lists.ximian.com +> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> > +> > +> + + + +-- +Juba +*@jubaborgohain <http://www.twitter.com/jubaborgohain>* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110527/ed6f7a5c/attachment-0001.html ++ + + +
Hi, + +Did you make sure to tell MD to use the Win32 COR debugger? You can do +so in options somewhere... + +Regards, +Alex + +2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> Hi, +> +> I am trying to debug monodevelop (pulled from github) from inside of +> monodevelop 2.4.2.1. I am using the default runtime that is set, in my case +> Microsoft. +> +> Thanks, +> Jubaraj +> +> On Fri, May 27, 2011 at 9:28 AM, Alex <xtzgzorex at gmail.com> wrote: +>> +>> Hi, +>> +>> What kind of project are you debugging? C#? Are you using the +>> Microsoft runtime or the Mono runtime? +>> +>> Regards, +>> Alex +>> +>> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +>> > Hello, +>> > +>> > I am trying to debug the latest monodevelop from github and whenever I +>> > start +>> > the debugger I get the following error message. +>> > +>> > "The debugger's protocol is incompatible with the debuggee (Exception +>> > from +>> > HRESULT: 0x8013134B)." +>> > +>> > I am using a Windows 7 64 bit machine. The Main.sln target is +>> > DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying to +>> > debug +>> > from within it. +>> > +>> > Thank you for your help. +>> > +>> > -- +>> > Juba +>> > @jubaborgohain +>> > +>> > _______________________________________________ +>> > Monodevelop-devel-list mailing list +>> > Monodevelop-devel-list at lists.ximian.com +>> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> > +>> > +> +> +> +> -- +> Juba +> @jubaborgohain +> ++ + + +
Hi, + +I think it is already using the Win32 COR debugger as I see it in the +exception trace. Correct? + +Here is the trace. + +System.Runtime.InteropServices.COMException (0x8013134B): The debugger's +protocol is incompatible with the debuggee. (Exception from HRESULT: +0x8013134B) + + at +Microsoft.Samples.Debugging.CorDebug.NativeApi.ICorDebug.CreateProcess(String +lpApplicationName, String lpCommandLine, SECURITY_ATTRIBUTES +lpProcessAttributes, SECURITY_ATTRIBUTES lpThreadAttributes, Int32 +bInheritHandles, UInt32 dwCreationFlags, IntPtr lpEnvironment, String +lpCurrentDirectory, STARTUPINFO lpStartupInfo, PROCESS_INFORMATION +lpProcessInformation, CorDebugCreateProcessFlags debuggingFlags, +ICorDebugProcess& ppProcess) + + at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +applicationName, String commandLine, SECURITY_ATTRIBUTES processAttributes, +SECURITY_ATTRIBUTES threadAttributes, Boolean inheritHandles, Int32 +creationFlags, IntPtr environment, String currentDirectory, STARTUPINFO +startupInfo, PROCESS_INFORMATION& processInformation, +CorDebugCreateProcessFlags debuggingFlags) + + at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +applicationName, String commandLine, String currentDirectory, IDictionary`2 +environment, Int32 flags) + + at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +applicationName, String commandLine, String currentDirectory, IDictionary`2 +environment) + + at MonoDevelop.Debugger.Win32.CorDebuggerSession.OnRun(DebuggerStartInfo +startInfo) + + at Mono.Debugging.Client.DebuggerSession.<>c__DisplayClass7.<Run>b__5() + + +Thanks, +Juba + + +On Fri, May 27, 2011 at 9:42 AM, Alex <xtzgzorex at gmail.com> wrote: + +> Hi, +> +> Did you make sure to tell MD to use the Win32 COR debugger? You can do +> so in options somewhere... +> +> Regards, +> Alex +> +> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> > Hi, +> > +> > I am trying to debug monodevelop (pulled from github) from inside of +> > monodevelop 2.4.2.1. I am using the default runtime that is set, in my +> case +> > Microsoft. +> > +> > Thanks, +> > Jubaraj +> > +> > On Fri, May 27, 2011 at 9:28 AM, Alex <xtzgzorex at gmail.com> wrote: +> >> +> >> Hi, +> >> +> >> What kind of project are you debugging? C#? Are you using the +> >> Microsoft runtime or the Mono runtime? +> >> +> >> Regards, +> >> Alex +> >> +> >> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> >> > Hello, +> >> > +> >> > I am trying to debug the latest monodevelop from github and whenever I +> >> > start +> >> > the debugger I get the following error message. +> >> > +> >> > "The debugger's protocol is incompatible with the debuggee (Exception +> >> > from +> >> > HRESULT: 0x8013134B)." +> >> > +> >> > I am using a Windows 7 64 bit machine. The Main.sln target is +> >> > DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying to +> >> > debug +> >> > from within it. +> >> > +> >> > Thank you for your help. +> >> > +> >> > -- +> >> > Juba +> >> > @jubaborgohain +> >> > +> >> > _______________________________________________ +> >> > Monodevelop-devel-list mailing list +> >> > Monodevelop-devel-list at lists.ximian.com +> >> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> >> > +> >> > +> > +> > +> > +> > -- +> > Juba +> > @jubaborgohain +> > +> + + + +-- +Juba +*@jubaborgohain <http://www.twitter.com/jubaborgohain>* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110527/84692f92/attachment.html ++ + + +
My understanding was that the debugger protocol changed in .NET 4.0 and +monodevelop hasn't been updated for that. I ran into a similar issue a while +back and that was the information I was given. +On May 27, 2011 9:01 AM, "Jubaraj Borgohain" <jubarajborgohain at gmail.com> +wrote: +> Hi, +> +> I think it is already using the Win32 COR debugger as I see it in the +> exception trace. Correct? +> +> Here is the trace. +> +> System.Runtime.InteropServices.COMException (0x8013134B): The debugger's +> protocol is incompatible with the debuggee. (Exception from HRESULT: +> 0x8013134B) +> +> at +> +Microsoft.Samples.Debugging.CorDebug.NativeApi.ICorDebug.CreateProcess(String +> lpApplicationName, String lpCommandLine, SECURITY_ATTRIBUTES +> lpProcessAttributes, SECURITY_ATTRIBUTES lpThreadAttributes, Int32 +> bInheritHandles, UInt32 dwCreationFlags, IntPtr lpEnvironment, String +> lpCurrentDirectory, STARTUPINFO lpStartupInfo, PROCESS_INFORMATION +> lpProcessInformation, CorDebugCreateProcessFlags debuggingFlags, +> ICorDebugProcess& ppProcess) +> +> at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +> applicationName, String commandLine, SECURITY_ATTRIBUTES +processAttributes, +> SECURITY_ATTRIBUTES threadAttributes, Boolean inheritHandles, Int32 +> creationFlags, IntPtr environment, String currentDirectory, STARTUPINFO +> startupInfo, PROCESS_INFORMATION& processInformation, +> CorDebugCreateProcessFlags debuggingFlags) +> +> at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +> applicationName, String commandLine, String currentDirectory, +IDictionary`2 +> environment, Int32 flags) +> +> at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +> applicationName, String commandLine, String currentDirectory, +IDictionary`2 +> environment) +> +> at MonoDevelop.Debugger.Win32.CorDebuggerSession.OnRun(DebuggerStartInfo +> startInfo) +> +> at Mono.Debugging.Client.DebuggerSession.<>c__DisplayClass7.<Run>b__5() +> +> +> Thanks, +> Juba +> +> +> On Fri, May 27, 2011 at 9:42 AM, Alex <xtzgzorex at gmail.com> wrote: +> +>> Hi, +>> +>> Did you make sure to tell MD to use the Win32 COR debugger? You can do +>> so in options somewhere... +>> +>> Regards, +>> Alex +>> +>> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +>> > Hi, +>> > +>> > I am trying to debug monodevelop (pulled from github) from inside of +>> > monodevelop 2.4.2.1. I am using the default runtime that is set, in my +>> case +>> > Microsoft. +>> > +>> > Thanks, +>> > Jubaraj +>> > +>> > On Fri, May 27, 2011 at 9:28 AM, Alex <xtzgzorex at gmail.com> wrote: +>> >> +>> >> Hi, +>> >> +>> >> What kind of project are you debugging? C#? Are you using the +>> >> Microsoft runtime or the Mono runtime? +>> >> +>> >> Regards, +>> >> Alex +>> >> +>> >> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +>> >> > Hello, +>> >> > +>> >> > I am trying to debug the latest monodevelop from github and whenever +I +>> >> > start +>> >> > the debugger I get the following error message. +>> >> > +>> >> > "The debugger's protocol is incompatible with the debuggee +(Exception +>> >> > from +>> >> > HRESULT: 0x8013134B)." +>> >> > +>> >> > I am using a Windows 7 64 bit machine. The Main.sln target is +>> >> > DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying +to +>> >> > debug +>> >> > from within it. +>> >> > +>> >> > Thank you for your help. +>> >> > +>> >> > -- +>> >> > Juba +>> >> > @jubaborgohain +>> >> > +>> >> > _______________________________________________ +>> >> > Monodevelop-devel-list mailing list +>> >> > Monodevelop-devel-list at lists.ximian.com +>> >> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> >> > +>> >> > +>> > +>> > +>> > +>> > -- +>> > Juba +>> > @jubaborgohain +>> > +>> +> +> +> +> -- +> Juba +> *@jubaborgohain <http://www.twitter.com/jubaborgohain>* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110527/84aac60c/attachment.html ++ + + +
Thanks for your help. +Is the only way to resolve this is by working on a different platform? + + + +On Fri, May 27, 2011 at 11:51 AM, Slide <slide.o.mix at gmail.com> wrote: + +> My understanding was that the debugger protocol changed in .NET 4.0 and +> monodevelop hasn't been updated for that. I ran into a similar issue a while +> back and that was the information I was given. +> On May 27, 2011 9:01 AM, "Jubaraj Borgohain" <jubarajborgohain at gmail.com> +> wrote: +> > Hi, +> > +> > I think it is already using the Win32 COR debugger as I see it in the +> > exception trace. Correct? +> > +> > Here is the trace. +> > +> > System.Runtime.InteropServices.COMException (0x8013134B): The debugger's +> > protocol is incompatible with the debuggee. (Exception from HRESULT: +> > 0x8013134B) +> > +> > at +> > +> Microsoft.Samples.Debugging.CorDebug.NativeApi.ICorDebug.CreateProcess(String +> > lpApplicationName, String lpCommandLine, SECURITY_ATTRIBUTES +> > lpProcessAttributes, SECURITY_ATTRIBUTES lpThreadAttributes, Int32 +> > bInheritHandles, UInt32 dwCreationFlags, IntPtr lpEnvironment, String +> > lpCurrentDirectory, STARTUPINFO lpStartupInfo, PROCESS_INFORMATION +> > lpProcessInformation, CorDebugCreateProcessFlags debuggingFlags, +> > ICorDebugProcess& ppProcess) +> > +> > at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +> > applicationName, String commandLine, SECURITY_ATTRIBUTES +> processAttributes, +> > SECURITY_ATTRIBUTES threadAttributes, Boolean inheritHandles, Int32 +> > creationFlags, IntPtr environment, String currentDirectory, STARTUPINFO +> > startupInfo, PROCESS_INFORMATION& processInformation, +> > CorDebugCreateProcessFlags debuggingFlags) +> > +> > at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +> > applicationName, String commandLine, String currentDirectory, +> IDictionary`2 +> > environment, Int32 flags) +> > +> > at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +> > applicationName, String commandLine, String currentDirectory, +> IDictionary`2 +> > environment) +> > +> > at MonoDevelop.Debugger.Win32.CorDebuggerSession.OnRun(DebuggerStartInfo +> > startInfo) +> > +> > at Mono.Debugging.Client.DebuggerSession.<>c__DisplayClass7.<Run>b__5() +> > +> > +> > Thanks, +> > Juba +> > +> > +> > On Fri, May 27, 2011 at 9:42 AM, Alex <xtzgzorex at gmail.com> wrote: +> > +> >> Hi, +> >> +> >> Did you make sure to tell MD to use the Win32 COR debugger? You can do +> >> so in options somewhere... +> >> +> >> Regards, +> >> Alex +> >> +> >> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> >> > Hi, +> >> > +> >> > I am trying to debug monodevelop (pulled from github) from inside of +> >> > monodevelop 2.4.2.1. I am using the default runtime that is set, in my +> >> case +> >> > Microsoft. +> >> > +> >> > Thanks, +> >> > Jubaraj +> >> > +> >> > On Fri, May 27, 2011 at 9:28 AM, Alex <xtzgzorex at gmail.com> wrote: +> >> >> +> >> >> Hi, +> >> >> +> >> >> What kind of project are you debugging? C#? Are you using the +> >> >> Microsoft runtime or the Mono runtime? +> >> >> +> >> >> Regards, +> >> >> Alex +> >> >> +> >> >> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> >> >> > Hello, +> >> >> > +> >> >> > I am trying to debug the latest monodevelop from github and +> whenever I +> >> >> > start +> >> >> > the debugger I get the following error message. +> >> >> > +> >> >> > "The debugger's protocol is incompatible with the debuggee +> (Exception +> >> >> > from +> >> >> > HRESULT: 0x8013134B)." +> >> >> > +> >> >> > I am using a Windows 7 64 bit machine. The Main.sln target is +> >> >> > DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying +> to +> >> >> > debug +> >> >> > from within it. +> >> >> > +> >> >> > Thank you for your help. +> >> >> > +> >> >> > -- +> >> >> > Juba +> >> >> > @jubaborgohain +> >> >> > +> >> >> > _______________________________________________ +> >> >> > Monodevelop-devel-list mailing list +> >> >> > Monodevelop-devel-list at lists.ximian.com +> >> >> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> >> >> > +> >> >> > +> >> > +> >> > +> >> > +> >> > -- +> >> > Juba +> >> > @jubaborgohain +> >> > +> >> +> > +> > +> > +> > -- +> > Juba +> > *@jubaborgohain <http://www.twitter.com/jubaborgohain>* +> + + + +-- +Juba +*@jubaborgohain <http://www.twitter.com/jubaborgohain>* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110527/060a857f/attachment-0001.html ++ + + +
Hi, + +Do you really need to use the Win32 debugger? Mono provides a very +well-working soft debugger that you can instruct MD to use. + +Regards, +Alex + +2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> Thanks for your help. +> Is the only way to resolve this is by working on a different platform? +> +> +> +> On Fri, May 27, 2011 at 11:51 AM, Slide <slide.o.mix at gmail.com> wrote: +>> +>> My understanding was that the debugger protocol changed in .NET 4.0 and +>> monodevelop hasn't been updated for that. I ran into a similar issue a while +>> back and that was the information I was given. +>> +>> On May 27, 2011 9:01 AM, "Jubaraj Borgohain" <jubarajborgohain at gmail.com> +>> wrote: +>> > Hi, +>> > +>> > I think it is already using the Win32 COR debugger as I see it in the +>> > exception trace. Correct? +>> > +>> > Here is the trace. +>> > +>> > System.Runtime.InteropServices.COMException (0x8013134B): The debugger's +>> > protocol is incompatible with the debuggee. (Exception from HRESULT: +>> > 0x8013134B) +>> > +>> > at +>> > +>> > Microsoft.Samples.Debugging.CorDebug.NativeApi.ICorDebug.CreateProcess(String +>> > lpApplicationName, String lpCommandLine, SECURITY_ATTRIBUTES +>> > lpProcessAttributes, SECURITY_ATTRIBUTES lpThreadAttributes, Int32 +>> > bInheritHandles, UInt32 dwCreationFlags, IntPtr lpEnvironment, String +>> > lpCurrentDirectory, STARTUPINFO lpStartupInfo, PROCESS_INFORMATION +>> > lpProcessInformation, CorDebugCreateProcessFlags debuggingFlags, +>> > ICorDebugProcess& ppProcess) +>> > +>> > at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +>> > applicationName, String commandLine, SECURITY_ATTRIBUTES +>> > processAttributes, +>> > SECURITY_ATTRIBUTES threadAttributes, Boolean inheritHandles, Int32 +>> > creationFlags, IntPtr environment, String currentDirectory, STARTUPINFO +>> > startupInfo, PROCESS_INFORMATION& processInformation, +>> > CorDebugCreateProcessFlags debuggingFlags) +>> > +>> > at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +>> > applicationName, String commandLine, String currentDirectory, +>> > IDictionary`2 +>> > environment, Int32 flags) +>> > +>> > at Microsoft.Samples.Debugging.CorDebug.CorDebugger.CreateProcess(String +>> > applicationName, String commandLine, String currentDirectory, +>> > IDictionary`2 +>> > environment) +>> > +>> > at MonoDevelop.Debugger.Win32.CorDebuggerSession.OnRun(DebuggerStartInfo +>> > startInfo) +>> > +>> > at Mono.Debugging.Client.DebuggerSession.<>c__DisplayClass7.<Run>b__5() +>> > +>> > +>> > Thanks, +>> > Juba +>> > +>> > +>> > On Fri, May 27, 2011 at 9:42 AM, Alex <xtzgzorex at gmail.com> wrote: +>> > +>> >> Hi, +>> >> +>> >> Did you make sure to tell MD to use the Win32 COR debugger? You can do +>> >> so in options somewhere... +>> >> +>> >> Regards, +>> >> Alex +>> >> +>> >> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +>> >> > Hi, +>> >> > +>> >> > I am trying to debug monodevelop (pulled from github) from inside of +>> >> > monodevelop 2.4.2.1. I am using the default runtime that is set, in +>> >> > my +>> >> case +>> >> > Microsoft. +>> >> > +>> >> > Thanks, +>> >> > Jubaraj +>> >> > +>> >> > On Fri, May 27, 2011 at 9:28 AM, Alex <xtzgzorex at gmail.com> wrote: +>> >> >> +>> >> >> Hi, +>> >> >> +>> >> >> What kind of project are you debugging? C#? Are you using the +>> >> >> Microsoft runtime or the Mono runtime? +>> >> >> +>> >> >> Regards, +>> >> >> Alex +>> >> >> +>> >> >> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +>> >> >> > Hello, +>> >> >> > +>> >> >> > I am trying to debug the latest monodevelop from github and +>> >> >> > whenever I +>> >> >> > start +>> >> >> > the debugger I get the following error message. +>> >> >> > +>> >> >> > "The debugger's protocol is incompatible with the debuggee +>> >> >> > (Exception +>> >> >> > from +>> >> >> > HRESULT: 0x8013134B)." +>> >> >> > +>> >> >> > I am using a Windows 7 64 bit machine. The Main.sln target is +>> >> >> > DebugWin32|x86. I am building using MonoDevelop 2.4.2.1 and trying +>> >> >> > to +>> >> >> > debug +>> >> >> > from within it. +>> >> >> > +>> >> >> > Thank you for your help. +>> >> >> > +>> >> >> > -- +>> >> >> > Juba +>> >> >> > @jubaborgohain +>> >> >> > +>> >> >> > _______________________________________________ +>> >> >> > Monodevelop-devel-list mailing list +>> >> >> > Monodevelop-devel-list at lists.ximian.com +>> >> >> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> >> >> > +>> >> >> > +>> >> > +>> >> > +>> >> > +>> >> > -- +>> >> > Juba +>> >> > @jubaborgohain +>> >> > +>> >> +>> > +>> > +>> > +>> > -- +>> > Juba +>> > *@jubaborgohain <http://www.twitter.com/jubaborgohain>* +> +> +> +> -- +> Juba +> @jubaborgohain +> ++ + + +
2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> Is the only way to resolve this is by working on a different platform? + +Install the Mono runtime on Windows and tell MD to target that using +the Project->Runtime menu. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
The runtime is set to Mono runtime but debugging still doesn't work. + +However, debugging and running it works fine from inside of visual studio +2010. + +On Mon, May 30, 2011 at 8:08 AM, Michael Hutchinson < +m.j.hutchinson at gmail.com> wrote: + +> 2011/5/27 Jubaraj Borgohain <jubarajborgohain at gmail.com>: +> > Is the only way to resolve this is by working on a different platform? +> +> Install the Mono runtime on Windows and tell MD to target that using +> the Project->Runtime menu. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> + + + +-- +Juba +*@jubaborgohain <http://www.twitter.com/jubaborgohain>* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20110531/ea46ad43/attachment.html ++ + +
Starting: Tue May 3 06:47:15 EDT 2011
+ Ending: Tue May 31 10:53:16 EDT 2011
+ Messages: 12
+
+ Last message date:
+ Tue May 31 10:53:16 EDT 2011
+ Archived on: Tue May 31 10:53:19 EDT 2011
+
+
+
Starting: Tue May 3 06:47:15 EDT 2011
+ Ending: Tue May 31 10:53:16 EDT 2011
+ Messages: 12
+
+ Last message date:
+ Tue May 31 10:53:16 EDT 2011
+ Archived on: Tue May 31 10:53:19 EDT 2011
+
+
+
Starting: Tue May 3 06:47:15 EDT 2011
+ Ending: Tue May 31 10:53:16 EDT 2011
+ Messages: 12
+
+ Last message date:
+ Tue May 31 10:53:16 EDT 2011
+ Archived on: Tue May 31 10:53:19 EDT 2011
+
+
+
Starting: Tue May 3 06:47:15 EDT 2011
+ Ending: Tue May 31 10:53:16 EDT 2011
+ Messages: 12
+
+ Last message date:
+ Tue May 31 10:53:16 EDT 2011
+ Archived on: Tue May 31 10:53:19 EDT 2011
+
+
+
Starting: Tue May 3 06:47:15 EDT 2011
+ Ending: Tue May 31 10:53:16 EDT 2011
+ Messages: 12
+
+ Last message date:
+ Tue May 31 10:53:16 EDT 2011
+ Archived on: Tue May 31 10:53:19 EDT 2011
+
+
+
Hi! + +Im writing an Addin for Monodevelop which can debug mono Applications +on remote Linux hosts based on the Meego Plugin. It seems like the +Meego Addin has been discontinued... So i try to resurrect it as a +general Linux Remote Debugging Addin.... ;-) + +I got it up and running, and the Debugger connects successfully, Pause +and Continue works, but the Debugger ignores all breakpoints. + +I think the problem might be with the Assembly path in the MDB files +which are transfered to the Linux Host from my Windows PC, because +FindLocation in ResolveBreakPoint is null.. and inisideLoadedRange == +false + + Is there a way to change the Path info's in the MDB, so that i can +use them on windows and linux devices? + +Peter ++ + + +
On 27 November 2011 16:17, Peter Siegel <siegelpeter2009 at gmail.com> wrote: +> Hi! +> +> Im writing an Addin for Monodevelop which can debug mono Applications +> on remote Linux hosts based on the Meego Plugin. It seems like the +> Meego Addin has been discontinued... So i try to resurrect it as a +> general Linux Remote Debugging Addin.... ;-) +> +> I got it up and running, and the Debugger connects successfully, Pause +> and Continue works, but the Debugger ignores all breakpoints. +> +> I think the problem might be with the Assembly path in the MDB files +> which are transfered to the Linux Host from my Windows PC, because +> FindLocation in ResolveBreakPoint is null.. and inisideLoadedRange == +> false +> +> Is there a way to change the Path info's in the MDB, so that i can +> use them on windows and linux devices? + +That shouldn't matter, the paths are handled only in the context of +the host. We did initially have some issue but fixed them so that +MonoDevelop on Windows could debug Mono for Android apps. + +How are you building the apps on Windows? I assume you selected the +Mono runtime so that your apps are built with mcs and have mdb +debugging files. If you're using the .NET target runtime, then your +apps will be built with csc files so will only have pdb files, which +Mono cannot handle directly. You'd need to use pdb2mdb +(mcs/tools/pdb2mdb) to convert them. + +What version of Mono is running on the target device? Can you verify +that stack traces on the target device have file/line information that +corresponds to real files on the Windows host? + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Sun Nov 27 16:17:05 EST 2011
+ Ending: Wed Nov 30 14:28:22 EST 2011
+ Messages: 2
+
+ Last message date:
+ Wed Nov 30 14:28:22 EST 2011
+ Archived on: Wed Nov 30 14:28:25 EST 2011
+
+
+
Starting: Sun Nov 27 16:17:05 EST 2011
+ Ending: Wed Nov 30 14:28:22 EST 2011
+ Messages: 2
+
+ Last message date:
+ Wed Nov 30 14:28:22 EST 2011
+ Archived on: Wed Nov 30 14:28:25 EST 2011
+
+
+
Starting: Sun Nov 27 16:17:05 EST 2011
+ Ending: Wed Nov 30 14:28:22 EST 2011
+ Messages: 2
+
+ Last message date:
+ Wed Nov 30 14:28:22 EST 2011
+ Archived on: Wed Nov 30 14:28:25 EST 2011
+
+
+
Starting: Sun Nov 27 16:17:05 EST 2011
+ Ending: Wed Nov 30 14:28:22 EST 2011
+ Messages: 2
+
+ Last message date:
+ Wed Nov 30 14:28:22 EST 2011
+ Archived on: Wed Nov 30 14:28:25 EST 2011
+
+
+
Starting: Sun Nov 27 16:17:05 EST 2011
+ Ending: Wed Nov 30 14:28:22 EST 2011
+ Messages: 2
+
+ Last message date:
+ Wed Nov 30 14:28:22 EST 2011
+ Archived on: Wed Nov 30 14:28:25 EST 2011
+
+
+
Hi to all, +As some of you know (or might not) this summer I want to improve F# under +Mono and one of the three features of project is integration F# plugin into +official MD destribution and I want to ask you what needs to be done? I am +looking forward to your suggestions. + +Thank you. + +Regards, Igor. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120402/a08cb08f/attachment.html> ++ + + +
Hello, + +As some of you know (or might not) this summer I want to improve F# under +> Mono and one of the three features of project is integration F# plugin into +> official MD destribution and I want to ask you what needs to be done? I am +> looking forward to your suggestions. +> + +The latest version of the add-in needs to be updated to run with +MonoDevelop from master, and once that is the case, we can get the code +applied to master. + +Miguel +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120402/3b31f43b/attachment.html> ++ + + +
Hello. + +I have an idea of Summer of Code project. +I call it "Smart usings for C#". I'm writing code not only in C#, but +in Java too, and I noticed one difference between C# and Java IDEs: +while most java IDEs can automatically add imports (usings in C#), it +seems that only ReSharper can do it in C#. I think that it will be +nice to have such feature in MonoDevelop. Actually, I'm feeling very +uncomfortable when I have to manually type usings in MonoDevelop after +writing code in Eclipse. But Eclipse does it not the best way too. It +lists possibly everything in auto-completion suggestions. I think a +better way is providing a command like "Convert to unqualified name". +This command must remove all namespace prefixes from class/method +currently under cursor and insert usings at correct location - at the +beginning of the file or at scope start. I think the most appropriate +for such settings is "Formatting policy". Also, if it is possible to +automatically generate using for one identifier, it's not too hard to +do this for entire source file. I think it's best to provide a +separate command for this, and another option in formatting policy. Of +course, old usings will be modified during formatting to conform with +formatting policy. +Could someone be a mentor for this project or have any suggestions? + +Also I looked at proposed ideas page on Mono site and choose two +interesting for me: +a) "Extend SIMD support - Extend SIMD support to existing data types +in MonoGame to assist existing applications that use the MonoGame +matrix and vector types to use SIMD operations instead of limiting +this to the Mono.SIMD namespace". I think I can implement this +project, because I am familiar with XNA and SIMD. But, to be fair, I +don't know much about MonoGame and Mono.SIMD. However, I think that +Mono.SIMD isn't much different from SIMD intrinsics for C/C++. The +only problem is that I don't know how to write a good proposal for +this project - it is hard to add something to project description, and +also timeline will look like a list of MonoGame's math classes. Can +such proposal be accepted? + +b) "Mono.Cecil clone for Dalvik's DEX file format" - I am not familiar +with either Cecil and Dalvik, but I have experience writing, debugging +and fixing code in Java and C#, so I won't only run some automatic +code converter, but also will be able to find and fix bugs appeared +because of automatic code conversion. It seems that this project is +intended to run on Android? If it is, I think that existing automatic +code conversion tools will require much tuning, mostly on type +mapping, or I even will have to write my own tool to achieve a good +result. Could someone describe what is expected way of implementing +this project idea? Is there a potential mentor for this project? ++ + + +
Hi community! +One of my implementation tasks for this summer is to improve debugging F# +projects in MonoDevelop. I have been loking for any info about it so could +you please point me on any articles dedicated to how debugging in +MonoDevelop goes? + +Thank you. + +Igor. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120409/1de0eeae/attachment.html> ++ + + +
Hello folks! + +I'm planning to write and maintain a page listing maintainers of +specific parts of Mono. When you have a patch that you wish to +contribute, it is usually easier to go directly to the maintainer of +the part of the code that you are modifying in order to have it +reviewed, rather than posting to the mailing list or #monodev and +waiting for someone to notice it. However, it is not currently clear +who to go to for the various parts of Mono's source. I'm planning to +improve this situation by creating a Maintainers page on the wiki, +which I am also committing to keeping up to date. + +So, in order to put together an initial list, I'm writing to the +various dev lists. If you are willing to take maintainership of a +particular part of Mono's source base, please reply to this email with +a description of the parts of Mono you wish to take maintainership of +and your IRC nickname (if any). Essentially, doing this just means +that people will be able to go to you when they need patch reviews. + +Thanks! + +Regards, +Alex ++ + + + +
Hi All, + +How do I get MonoDevelop (either 2.4 or 2.8.x) to work on openSUSE 12.1 + +I've used the default repo which is Mono 2.10.6 and MonoDevlop 2.4 and get the following error... + + +The following add-ins could not be started: + +MonoDevelop.GnomePlatform.2 +Full Path: MonoDevelop.GnomePlatform.2.4 + + +And when I re-install the OS, and change the repo to Mono/openSuse12.1 (which for some reason uses Mono 2.10.2 and MonoDevelop 2.8.x) I get a similar error: + +The following add-ins could not be started: + + MonoDevelop.GnomePlatform.2 + Full Path: MonoDevelop.GnomePlatform.2.8.6 + +I've tried the same with Tumbleweed and even compiling Mono and MonoDevelop from source. + +I typically install: +mono-complete +gtk-sharp2-complete +gnome-sharp2-complete +mono-basic +xsp +webkit-sharp +monodevelop +monodevelop-debugger-gdb + +Any ideas? + + +Thanks in advance. + + + +Regards, + +Chris Tottle +----------- +Cardiff University +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120413/813ac5ce/attachment.html> ++ + + + + +
I'm running a build from source on openSUSE 12.1 without any problems +(not the OBS). Given some of the packages on OBS then I'd suspect it +doesn't have its dependencies defined correctly, although I can't +obviously see what is missing. + +Do you get any extra information if you run MD from the console? +Sometimes MonoDevelop prints out extra info to the console compared to +what is in error dialogs. + + + + +On 13/04/12 15:54, Chris Tottle wrote: +> Hi All, +> +> How do I get MonoDevelop (either 2.4 or 2.8.x) to work on openSUSE 12.1 +> +> I've used the default repo which is Mono 2.10.6 and MonoDevlop 2.4 and +> get the following error... +> +> +> The following add-ins could not be started: +> +> MonoDevelop.GnomePlatform.2 +> Full Path: MonoDevelop.GnomePlatform.2.4 +> +> +> And when I re-install the OS, and change the repo to Mono/openSuse12.1 +> (which for some reason uses Mono 2.10.2 and MonoDevelop 2.8.x) I get a +> similar error: +> +> The following add-ins could not be started: +> +> MonoDevelop.GnomePlatform.2 +> Full Path: MonoDevelop.GnomePlatform.2.8.6 +> +> I've tried the same with Tumbleweed and even compiling Mono and +> MonoDevelop from source. +> +> I typically install: +> mono-complete +> gtk-sharp2-complete +> gnome-sharp2-complete +> mono-basic +> xsp +> webkit-sharp +> monodevelop +> monodevelop-debugger-gdb +> +> Any ideas? +> +> +> Thanks in advance. +> +> +> +> Regards, +> +> Chris Tottle +> ----------- +> Cardiff University +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list ++ + + + + +
I don't know if it's the same error Chris reports, but I upgraded my +openSUSE from 11.4 to 12.1 last night and get an error running Monodevelop. +I notice it's version 2.4 as well which a bit old now. Anyway, I cloned the +main git repo and built from that and it runs fine. + +Here's the error I get from the openSUSE packaged version:- + +richard at devlinux:~> monodevelop +WARNING: Cannot find Mozilla directory containing libgtkembedmoz.so. Some +Addins may not be able to function. Please set MOZILLA_FIVE_HOME to your +Mozilla directory. +WARNING: trailing data after Gdk.Key portion of shortcut Control|Alt|Up| +WARNING [2012-04-13 21:11:21Z]: Error creating composed icon +gtk-execute___asm0__debug-overlay-24.png__LargeToolbar at size +LargeToolbar. Icon __asm0__debug-overlay-24.png__LargeToolbar is 24x24, +expected 22x22. +ERROR [2012-04-13 21:11:21Z]: GdkPixbuf-Critical: gdk_pixbuf_composite: +assertion `dest_x >= 0 && dest_x + dest_width <= dest->width' failed +Stack trace: + at Gdk.Pixbuf.Composite(Gdk.Pixbuf dest, Int32 dest_x, Int32 dest_y, +Int32 dest_width, Int32 dest_height, Double offset_x, Double offset_y, +Double scale_x, Double scale_y, InterpType interp_type, Int32 overall_alpha) + at MonoDevelop.Ide.ImageService.MergeIcons(Gdk.Pixbuf icon1, Gdk.Pixbuf +icon2) + at MonoDevelop.Ide.ImageService.GetComposedIcon(System.String[] ids, +IconSize size) + at +MonoDevelop.Ide.ImageService.InternalGetStockId(Mono.Addins.RuntimeAddin +addin, System.String filename, IconSize size) + at +MonoDevelop.Ide.ImageService.LoadStockIcon(MonoDevelop.Ide.Extensions.StockIconCodon +iconCodon) + at +MonoDevelop.Ide.ImageService.<EnsureStockIconIsLoaded>m__130(MonoDevelop.Ide.Extensions.StockIconCodon +i) + at +System.Collections.Generic.List`1[[MonoDevelop.Ide.Extensions.StockIconCodon, +MonoDevelop.Ide, Version=2.4.0.0, Culture=neutral, +PublicKeyToken=null]].ForEach(System.Action`1 action) + at MonoDevelop.Ide.ImageService.EnsureStockIconIsLoaded(System.String +stockId, IconSize size) + at MonoDevelop.Ide.ImageService.<ImageService>m__12E(System.String +stockId) + at MonoDevelop.Core.IconId.get_Name() + at MonoDevelop.Core.IconId.op_Implicit(IconId icon) + at +MonoDevelop.Components.Commands.CommandToolButton.Update(MonoDevelop.Components.Commands.CommandInfo +cmdInfo) + at +MonoDevelop.Components.Commands.CommandToolButton.MonoDevelop.Components.Commands.ICommandUserItem.Update(MonoDevelop.Components.Commands.CommandTargetRoute +targetRoute) + at +MonoDevelop.Components.Commands.CommandToolButton.OnParentSet(Gtk.Widget +parent) + at Gtk.Widget.parentset_cb(IntPtr widget, IntPtr previous_parent) + at Gtk.Container.gtksharp_container_base_add(IntPtr , IntPtr ) + at Gtk.Container.OnAdded(Gtk.Widget widget) + at MonoDevelop.Components.DockToolbars.DockToolbar.OnAdded(Gtk.Widget w) + at Gtk.Container.added_cb(IntPtr container, IntPtr widget) + at Gtk.Container.gtk_container_add(IntPtr , IntPtr ) + at Gtk.Container.Add(Gtk.Widget widget) + at +MonoDevelop.Components.Commands.CommandManager.CreateToolbar(System.String +id, MonoDevelop.Components.Commands.CommandEntrySet entrySet, System.Object +initialTarget) + at +MonoDevelop.Components.Commands.CommandManager.CreateToolbar(System.String +id, MonoDevelop.Components.Commands.CommandEntrySet entrySet) + at +MonoDevelop.Components.Commands.CommandManager.CreateToolbarSet(System.String +addinPath) + at MonoDevelop.Ide.Gui.DefaultWorkbench.InitializeWorkspace() + at MonoDevelop.Ide.Gui.Workbench.Initialize(IProgressMonitor monitor) + at MonoDevelop.Ide.IdeApp.Initialize(IProgressMonitor monitor) + at MonoDevelop.Ide.IdeStartup.Run(System.String[] args) + at MonoDevelop.Startup.MonoDevelopMain.Main(System.String[] args) +ERROR [2012-04-13 21:11:22Z]: Unhandled Exception +System.NullReferenceException: Object reference not set to an instance of +an object + at GLib.Object.NotifyCallback (IntPtr handle, IntPtr pspec, IntPtr gch) +[0x00000] in <filename unknown>:0 +ERROR [2012-04-13 21:11:23Z]: Unhandled +Exception +System.NullReferenceException: Object reference not set to an instance of +an object + at GLib.Object.NotifyCallback (IntPtr handle, IntPtr pspec, IntPtr gch) +[0x00000] in <filename unknown>:0 + + + +On Fri, Apr 13, 2012 at 7:50 PM, IBBoard <ibboard at gmail.com> wrote: + +> I'm running a build from source on openSUSE 12.1 without any problems (not +> the OBS). Given some of the packages on OBS then I'd suspect it doesn't +> have its dependencies defined correctly, although I can't obviously see +> what is missing. +> +> Do you get any extra information if you run MD from the console? Sometimes +> MonoDevelop prints out extra info to the console compared to what is in +> error dialogs. +> +> +> +> +> +> On 13/04/12 15:54, Chris Tottle wrote: +> +>> Hi All, +>> +>> How do I get MonoDevelop (either 2.4 or 2.8.x) to work on openSUSE 12.1 +>> +>> I've used the default repo which is Mono 2.10.6 and MonoDevlop 2.4 and +>> get the following error... +>> +>> +>> The following add-ins could not be started: +>> +>> MonoDevelop.GnomePlatform.2 +>> Full Path: MonoDevelop.GnomePlatform.2.4 +>> +>> +>> And when I re-install the OS, and change the repo to Mono/openSuse12.1 +>> (which for some reason uses Mono 2.10.2 and MonoDevelop 2.8.x) I get a +>> similar error: +>> +>> The following add-ins could not be started: +>> +>> MonoDevelop.GnomePlatform.2 +>> Full Path: MonoDevelop.GnomePlatform.2.8.**6 +>> +>> I've tried the same with Tumbleweed and even compiling Mono and +>> MonoDevelop from source. +>> +>> I typically install: +>> mono-complete +>> gtk-sharp2-complete +>> gnome-sharp2-complete +>> mono-basic +>> xsp +>> webkit-sharp +>> monodevelop +>> monodevelop-debugger-gdb +>> +>> Any ideas? +>> +>> +>> Thanks in advance. +>> +>> +>> +>> Regards, +>> +>> Chris Tottle +>> ----------- +>> Cardiff University +>> +>> +>> ______________________________**_________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.**ximian.com<Monodevelop-devel-list at lists.ximian.com> +>> http://lists.ximian.com/**mailman/listinfo/monodevelop-**devel-list<http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list> +>> +> ______________________________**_________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.**ximian.com<Monodevelop-devel-list at lists.ximian.com> +> http://lists.ximian.com/**mailman/listinfo/monodevelop-**devel-list<http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120413/1930c319/attachment.html> ++ + + + + +
Hi, + +Thanks for both you and Richard for answering my post. + +I've re-installed my laptop last night and full patched it. I'm running openSUSE 12.1 (32 bit). I've add the following repo since it has the newer version of MonoDevelop. + +http://download.opensuse.org/repositories/Mono/openSUSE_12.1/ + +I also installed the version of Mono taken from the Mono repo (which is older than the OSS version) since I would expect them to test the latest version of MonoDevelop against this version. + +I've installed the following packages: + +zypper --non-interactive install --auto-agree-with-licenses --repo Mono mono-complete +zypper --non-interactive install --auto-agree-with-licenses --repo Mono mono-basic +zypper --non-interactive install --auto-agree-with-licenses --repo Mono gtk-sharp2-complete +zypper --non-interactive install --auto-agree-with-licenses --repo repo-oss gnome-sharp2-complete +zypper --non-interactive install --auto-agree-with-licenses --repo repo-oss glade-sharp2 +zypper --non-interactive install --auto-agree-with-licenses --repo Mono webkit-sharp +zypper --non-interactive install --auto-agree-with-licenses --repo repo-oss xsp + +zypper --non-interactive install --auto-agree-with-licenses --repo Mono monodevelop +zypper --non-interactive install --auto-agree-with-licenses --repo Mono monodevelop-debugger-gdb + +As an aside, any ideas why not all Mono packages can be found in the Mono repo? I had to mix and match with OSS. + +And when I run MonoDevelop up I get the following (this was taken from the command line) + + +monodevelop +ERROR [2012-04-14 19:46:36Z]: Add-in error (MonoDevelop.GnomePlatform,2.8.6.3): Error while getting object for node in path '/MonoDevelop/Core/PlatformService'. +System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.DllNotFoundException: libgnomeui-2.so.0 + at (wrapper managed-to-native) Gnome.ThumbnailFactory:gnome_thumbnail_factory_new (int) + at Gnome.ThumbnailFactory..ctor (ThumbnailSize size) [0x0002b] in /home/abuild/rpmbuild/BUILD/gnome-sharp-2.24.2/gnome/generated/ThumbnailFactory.cs:25 + at MonoDevelop.Platform.GnomePlatform..ctor () [0x00000] in <filename unknown>:0 + at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&) + at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0011e] in /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/MonoMethod.cs:526 + --- End of inner exception stack trace --- + at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00131] in /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/MonoMethod.cs:532 + at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/MonoMethod.cs:541 + at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x0000e] in /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/ConstructorInfo.cs:62 + at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x000c7] in /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System/Activator.cs:333 + at System.Activator.CreateInstance (System.Type type) [0x00000] in /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System/Activator.cs:224 + at Mono.Addins.TypeExtensionNode.CreateInstance () [0x00000] in /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/TypeExtensionNode.cs:93 + at Mono.Addins.InstanceExtensionNode.GetInstance () [0x0000b] in /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/InstanceExtensionNode.cs:73 + at Mono.Addins.InstanceExtensionNode.GetInstance (System.Type expectedType) [0x00000] in /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/InstanceExtensionNode.cs:55 + at Mono.Addins.ExtensionNode.GetChildObjectsInternal (System.Type arrayElementType, Boolean reuseCachedInstance) [0x0005e] in /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/ExtensionNode.cs:356 +FATAL ERROR [2012-04-14 19:46:36Z]: A platform service implementation has not been found. + + +Many thanks for your help. + +Regards, + +Chris Tottle +----------- +Cardiff University +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120414/bc8c8562/attachment.html> ++ + + + + +
I just looked that .so file - it is provided by +libgnomeui-2.24.5-3.1.2.x86_64 on my system. + + From a quick look at the dependencies then my guess is that +gnome-sharp2-complete or gnome-sharp2 is badly packaged and should pull +in libgnomeui as a dependency but doesn't define it. Try installing it +and see if that fixes the problem. + + + +On 14/04/12 20:48, Chris Tottle wrote: +> Hi, +> +> Thanks for both you and Richard for answering my post. +> +> I've re-installed my laptop last night and full patched it. I'm running +> openSUSE 12.1 (32 bit). I've add the following repo since it has the +> newer version of MonoDevelop. +> +> http://download.opensuse.org/repositories/Mono/openSUSE_12.1/ +> +> I also installed the version of Mono taken from the Mono repo (which is +> older than the OSS version) since I would expect them to test the latest +> version of MonoDevelop against this version. +> +> I've installed the following packages: +> +> zypper --non-interactive install --auto-agree-with-licenses --repo Mono +> mono-complete +> zypper --non-interactive install --auto-agree-with-licenses --repo Mono +> mono-basic +> zypper --non-interactive install --auto-agree-with-licenses --repo Mono +> gtk-sharp2-complete +> zypper --non-interactive install --auto-agree-with-licenses --repo +> repo-oss gnome-sharp2-complete +> zypper --non-interactive install --auto-agree-with-licenses --repo +> repo-oss glade-sharp2 +> zypper --non-interactive install --auto-agree-with-licenses --repo Mono +> webkit-sharp +> zypper --non-interactive install --auto-agree-with-licenses --repo +> repo-oss xsp +> +> zypper --non-interactive install --auto-agree-with-licenses --repo Mono +> monodevelop +> zypper --non-interactive install --auto-agree-with-licenses --repo Mono +> monodevelop-debugger-gdb +> +> As an aside, any ideas why not all Mono packages can be found in the +> Mono repo? I had to mix and match with OSS. +> +> And when I run MonoDevelop up I get the following (this was taken from +> the command line) +> +> +> monodevelop +> ERROR [2012-04-14 19:46:36Z]: Add-in error +> (MonoDevelop.GnomePlatform,2.8.6.3): Error while getting object for node +> in path '/MonoDevelop/Core/PlatformService'. +> System.Reflection.TargetInvocationException: Exception has been thrown +> by the target of an invocation. ---> System.DllNotFoundException: +> libgnomeui-2.so.0 +> at (wrapper managed-to-native) +> Gnome.ThumbnailFactory:gnome_thumbnail_factory_new (int) +> at Gnome.ThumbnailFactory..ctor (ThumbnailSize size) [0x0002b] in +> /home/abuild/rpmbuild/BUILD/gnome-sharp-2.24.2/gnome/generated/ThumbnailFactory.cs:25 +> +> at MonoDevelop.Platform.GnomePlatform..ctor () [0x00000] in <filename +> unknown>:0 +> at (wrapper managed-to-native) +> System.Reflection.MonoCMethod:InternalInvoke +> (System.Reflection.MonoCMethod,object,object[],System.Exception&) +> at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags +> invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, +> System.Globalization.CultureInfo culture) [0x0011e] in +> /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/MonoMethod.cs:526 +> +> --- End of inner exception stack trace --- +> at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags +> invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, +> System.Globalization.CultureInfo culture) [0x00131] in +> /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/MonoMethod.cs:532 +> +> at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, +> System.Reflection.Binder binder, System.Object[] parameters, +> System.Globalization.CultureInfo culture) [0x00000] in +> /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/MonoMethod.cs:541 +> +> at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) +> [0x0000e] in +> /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System.Reflection/ConstructorInfo.cs:62 +> +> at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) +> [0x000c7] in +> /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System/Activator.cs:333 +> +> at System.Activator.CreateInstance (System.Type type) [0x00000] in +> /home/abuild/rpmbuild/BUILD/mono-2.10.2/mcs/class/corlib/System/Activator.cs:224 +> +> at Mono.Addins.TypeExtensionNode.CreateInstance () [0x00000] in +> /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/TypeExtensionNode.cs:93 +> +> at Mono.Addins.InstanceExtensionNode.GetInstance () [0x0000b] in +> /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/InstanceExtensionNode.cs:73 +> +> at Mono.Addins.InstanceExtensionNode.GetInstance (System.Type +> expectedType) [0x00000] in +> /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/InstanceExtensionNode.cs:55 +> +> at Mono.Addins.ExtensionNode.GetChildObjectsInternal (System.Type +> arrayElementType, Boolean reuseCachedInstance) [0x0005e] in +> /home/abuild/rpmbuild/BUILD/mono-addins-0.6.1/Mono.Addins/Mono.Addins/ExtensionNode.cs:356 +> +> FATAL ERROR [2012-04-14 19:46:36Z]: A platform service implementation +> has not been found. +> +> +> Many thanks for your help. +> +> Regards, +> +> Chris Tottle +> ----------- +> Cardiff University ++ + + + + +
Thank you ever so much :-) + +That fixed the problem for me. Not being able to install MonoDevlop has been driving me nuts these past few weeks. + +I've now added the following to my install script + +zypper --non-interactive install --auto-agree-with-licenses --repo repo-oss libgnomeui + + +Regards, + +Chris Tottle +----------- +Cardiff University +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120414/2fcb8312/attachment.html> ++ + + + +
Hey, + +On Apr 10, 2012, at 11:54 PM, Alex Rønne Petersen wrote: +> So, in order to put together an initial list, I'm writing to the +> various dev lists. If you are willing to take maintainership of a +> particular part of Mono's source base, please reply to this email with +> a description of the parts of Mono you wish to take maintainership of +> and your IRC nickname (if any). Essentially, doing this just means +> that people will be able to go to you when they need patch reviews. + + +mcs/class/Mono.Cecil +mcs/class/Mono.Cecil.Mdb +mcs/class/dlr +mcs/class/System.Core/System.Linq +mcs/class/System.Core/System.Linq.Expressions +mcs/tools/linker +mcs/tools/cil-strip +mcs/tools/pdb2mdb +mcs/tools/tuner + +Jb + ++ + + +
Was this stored in git in a 'MAINTAINERS' file? If not, why not? This +would be the ideal place for it to be located as it'd be simple for +people to find and update it as all maintainers have write access to +there :) + +Alan + +On 16 April 2012 08:57, Jb Evain <jbevain at gmail.com> wrote: +> Hey, +> +> On Apr 10, 2012, at 11:54 PM, Alex Rønne Petersen wrote: +>> So, in order to put together an initial list, I'm writing to the +>> various dev lists. If you are willing to take maintainership of a +>> particular part of Mono's source base, please reply to this email with +>> a description of the parts of Mono you wish to take maintainership of +>> and your IRC nickname (if any). Essentially, doing this just means +>> that people will be able to go to you when they need patch reviews. +> +> +> mcs/class/Mono.Cecil +> mcs/class/Mono.Cecil.Mdb +> mcs/class/dlr +> mcs/class/System.Core/System.Linq +> mcs/class/System.Core/System.Linq.Expressions +> mcs/tools/linker +> mcs/tools/cil-strip +> mcs/tools/pdb2mdb +> mcs/tools/tuner +> +> Jb +> +> _______________________________________________ +> Mono-devel-list mailing list +> Mono-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/mono-devel-list ++ + +
Starting: Mon Apr 2 12:09:50 UTC 2012
+ Ending: Mon Apr 16 10:53:13 UTC 2012
+ Messages: 13
+
+ Last message date:
+ Mon Apr 16 10:53:13 UTC 2012
+ Archived on: Mon Apr 16 13:38:30 UTC 2012
+
+
+
Starting: Mon Apr 2 12:09:50 UTC 2012
+ Ending: Mon Apr 16 10:53:13 UTC 2012
+ Messages: 13
+
+ Last message date:
+ Mon Apr 16 10:53:13 UTC 2012
+ Archived on: Mon Apr 16 13:38:30 UTC 2012
+
+
+
Starting: Mon Apr 2 12:09:50 UTC 2012
+ Ending: Mon Apr 16 10:53:13 UTC 2012
+ Messages: 13
+
+ Last message date:
+ Mon Apr 16 10:53:13 UTC 2012
+ Archived on: Mon Apr 16 13:38:30 UTC 2012
+
+
+
Starting: Mon Apr 2 12:09:50 UTC 2012
+ Ending: Mon Apr 16 10:53:13 UTC 2012
+ Messages: 13
+
+ Last message date:
+ Mon Apr 16 10:53:13 UTC 2012
+ Archived on: Mon Apr 16 13:38:30 UTC 2012
+
+
+
Starting: Mon Apr 2 12:09:50 UTC 2012
+ Ending: Mon Apr 16 10:53:13 UTC 2012
+ Messages: 13
+
+ Last message date:
+ Mon Apr 16 10:53:13 UTC 2012
+ Archived on: Mon Apr 16 13:38:30 UTC 2012
+
+
+
+Hi there, + +I'm trying to compile monodevelop (master) on my Fedora 17 system. I +would like to try out the F# support and from what I can gather, that is +best done with mono/monodevelop 3+ + +I've compiled the entire mono stack locally which consists of: + +mono (master) +fsharp (master) +gtk-sharp (gtk-sharp-2-12-branch) <== not sure this is correct... +gnome-sharp (master) +monodevelop (master) + +Configuring gnome-sharp: + +[jsr at hermes gnome-sharp]$ ./bootstrap-2.24 --prefix=/home/jsr/local ++ sed -e s/@GNOME_SHARP_VERSION@/2.24.2/ -e +s/@GTK_REQUIRED_VERSION@/2.13.0/ -e +s/@GTK_SHARP_REQUIRED_VERSION@/2.12.2/ -e +s/@GNOME_REQUIRED_VERSION@/2.23.0/ -e +s/@GNOMECANVAS_REQUIRED_VERSION@/2.20.0/ -e +'s/@VERSIONCSDEFINES@/-define:GTK_SHARP_2_6 -define:GTK_SHARP_2_8 +-define:GNOME_SHARP_2_16 -define:GNOME_SHARP_2_20 +-define:GNOME_SHARP_2_24/' -e 's/@VERSIONCFLAGS@/-DGTK_SHARP_2_6 +-DGTK_SHARP_2_8 -DGNOME_SHARP_2_16 -DGNOME_SHARP_2_20 +-DGNOME_SHARP_2_24/' -e 's/@POLICY_VERSIONS@/2.4 2.6 2.8 2.16 2.20/' -e +s/@ASSEMBLY_VERSION@/2.24.0.0/ ./configure.in.in +Running libtoolize... +libtoolize: putting auxiliary files in `.'. +libtoolize: copying file `./ltmain.sh' +libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in +and +libtoolize: rerunning libtoolize, to keep the correct libtool macros +in-tree. +libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. +Running aclocal ... +Running autoheader... +Running automake --foreign ... +Running autoconf ... +Running ./configure --enable-maintainer-mode --enable-compile-warnings +--prefix=/home/jsr/local ... +configure: WARNING: unrecognized options: --enable-compile-warnings +checking build system type... x86_64-unknown-linux-gnu +checking host system type... x86_64-unknown-linux-gnu +checking target system type... x86_64-unknown-linux-gnu +checking for a BSD-compatible install... /usr/bin/install -c +checking whether build environment is sane... yes +checking for a thread-safe mkdir -p... /usr/bin/mkdir -p +checking for gawk... gawk +checking whether make sets $(MAKE)... yes +checking whether to enable maintainer-specific portions of Makefiles... +yes +checking for gcc... gcc +checking for gcc... (cached) gcc +checking whether the C compiler works... yes +checking for C compiler default output file name... a.out +checking for suffix of executables... +checking whether we are cross compiling... no +checking for suffix of object files... o +checking whether we are using the GNU C compiler... yes +checking whether gcc accepts -g... yes +checking for gcc option to accept ISO C89... none needed +checking for style of include used by make... GNU +checking dependency style of gcc... gcc3 +checking for gcc... (cached) gcc +checking whether we are using the GNU C compiler... (cached) yes +checking whether gcc accepts -g... (cached) yes +checking for gcc option to accept ISO C89... (cached) none needed +checking dependency style of gcc... (cached) gcc3 +checking how to run the C preprocessor... gcc -E +checking for grep that handles long lines and -e... /usr/bin/grep +checking for egrep... /usr/bin/grep -E +checking for ANSI C header files... yes +checking how to print strings... printf +checking for a sed that does not truncate output... /usr/bin/sed +checking for fgrep... /usr/bin/grep -F +checking for ld used by gcc... /usr/bin/ld +checking if the linker (/usr/bin/ld) is GNU ld... yes +checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B +checking the name lister (/usr/bin/nm -B) interface... BSD nm +checking whether ln -s works... yes +checking the maximum length of command line arguments... 1572864 +checking whether the shell understands some XSI constructs... yes +checking whether the shell understands "+="... yes +checking how to convert x86_64-unknown-linux-gnu file names to +x86_64-unknown-linux-gnu format... func_convert_file_noop +checking how to convert x86_64-unknown-linux-gnu file names to toolchain +format... func_convert_file_noop +checking for /usr/bin/ld option to reload object files... -r +checking for objdump... objdump +checking how to recognize dependent libraries... pass_all +checking for dlltool... dlltool +checking how to associate runtime and link libraries... printf %s\n +checking for ar... ar +checking for archiver @FILE support... @ +checking for strip... strip +checking for ranlib... ranlib +checking command to parse /usr/bin/nm -B output from gcc object... ok +checking for sysroot... no +checking for mt... no +checking if : is a manifest tool... no +checking for sys/types.h... yes +checking for sys/stat.h... yes +checking for stdlib.h... yes +checking for string.h... yes +checking for memory.h... yes +checking for strings.h... yes +checking for inttypes.h... yes +checking for stdint.h... yes +checking for unistd.h... yes +checking for dlfcn.h... yes +checking for objdir... .libs +checking if gcc supports -fno-rtti -fno-exceptions... no +checking for gcc option to produce PIC... -fPIC -DPIC +checking if gcc PIC flag -fPIC -DPIC works... yes +checking if gcc static flag -static works... no +checking if gcc supports -c -o file.o... yes +checking if gcc supports -c -o file.o... (cached) yes +checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports +shared libraries... yes +checking whether -lc should be explicitly linked in... no +checking dynamic linker characteristics... GNU/Linux ld.so +checking how to hardcode library paths into programs... immediate +checking whether stripping libraries is possible... yes +checking if libtool supports shared libraries... yes +checking whether to build shared libraries... yes +checking whether to build static libraries... yes +checking size of void *... 8 +checking for pkg-config... /usr/bin/pkg-config +checking pkg-config is at least version 0.9.0... yes +checking for MONO_DEPENDENCY... yes +checking for gacutil... /home/jsr/local/bin/gacutil +checking for al... /home/jsr/local/bin/al +checking for mono... /home/jsr/local/bin/mono +checking for mcs... /home/jsr/local/bin/mcs +checking for MONO_CAIRO... yes +checking for GTKSHARP... yes +checking for GLADESHARP... yes +checking for GAPI... yes +checking for gapi2-parser... /home/jsr/local/bin/gapi2-parser +checking for gapi2-codegen... /home/jsr/local/bin/gapi2-codegen +checking for gapi2-fixup... /home/jsr/local/bin/gapi2-fixup +checking for LIBART... yes +checking for GNOMEVFS... yes +checking for GNOME... yes +configure: creating ./config.status +config.status: creating AssemblyInfo.cs +config.status: creating Makefile +config.status: creating policy.config +config.status: creating sources/Makefile +config.status: creating art/Makefile +config.status: creating art/art-sharp.dll.config +config.status: creating art/art-sharp-2.0.pc +config.status: creating gnome/Makefile +config.status: creating gnome/gnome-sharp.dll.config +config.status: creating gnome/gnome-sharp-2.0.pc +config.status: creating gnome/glue/Makefile +config.status: creating gnomevfs/Makefile +config.status: creating gnomevfs/gnome-vfs-sharp.dll.config +config.status: creating gnomevfs/gnome-vfs-sharp-2.0.pc +config.status: creating gconf/Makefile +config.status: creating gconf/doc/Makefile +config.status: creating gconf/GConf/Makefile +config.status: creating gconf/GConf/gconf-sharp.dll.config +config.status: creating gconf/GConf/gconf-sharp-2.0.pc +config.status: creating gconf/GConf.PropertyEditors/Makefile +config.status: creating +gconf/GConf.PropertyEditors/gconf-sharp-peditors-2.0.pc +config.status: creating gconf/tools/Makefile +config.status: creating gconf/tools/gconfsharp2-schemagen +config.status: creating sample/Makefile +config.status: creating sample/gconf/Makefile +config.status: creating sample/gnomevfs/Makefile +config.status: creating config.h +config.status: config.h is unchanged +config.status: executing depfiles commands +config.status: executing libtool commands +configure: WARNING: unrecognized options: --enable-compile-warnings +--- +Configuration summary + + * Installation prefix = /home/jsr/local + * C# compiler: /home/jsr/local/bin/mcs -debug -define:GTK_SHARP_2_6 +-define:GTK_SHARP_2_8 -define:GNOME_SHARP_2_16 -define:GNOME_SHARP_2_20 +-define:GNOME_SHARP_2_24 + + Optional assemblies included in the build: + + * art-sharp.dll: yes + * gnomevfs-sharp.dll: yes + * gnome-sharp.dll: yes + + NOTE: if any of the above say 'no' you may install the + corresponding development packages for them, rerun + autogen.sh to include them in the build. + + gnome-sharp.dll requires libgnomecanvas, libgnome, + and libgnomeui. +--- +Now type `make' to compile +[jsr at hermes gnome-sharp]$ + + +My gnome-sharp build fails with the following: + +[jsr at hermes gnome-sharp]$ make +make all-recursive +make[1]: Entering directory `/home/jsr/dev/gnome-sharp' +Making all in sources +make[2]: Entering directory `/home/jsr/dev/gnome-sharp/sources' +make[2]: Nothing to be done for `all'. +make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/sources' +Making all in art +make[2]: Entering directory `/home/jsr/dev/gnome-sharp/art' +make[2]: Nothing to be done for `all'. +make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/art' +Making all in gnomevfs +make[2]: Entering directory `/home/jsr/dev/gnome-sharp/gnomevfs' +Making all in . +make[3]: Entering directory `/home/jsr/dev/gnome-sharp/gnomevfs' +make[3]: Nothing to be done for `all-am'. +make[3]: Leaving directory `/home/jsr/dev/gnome-sharp/gnomevfs' +make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/gnomevfs' +Making all in gnome +make[2]: Entering directory `/home/jsr/dev/gnome-sharp/gnome' +Making all in . +make[3]: Entering directory `/home/jsr/dev/gnome-sharp/gnome' +/home/jsr/local/bin/mcs -debug -define:GTK_SHARP_2_6 +-define:GTK_SHARP_2_8 -define:GNOME_SHARP_2_16 -define:GNOME_SHARP_2_20 +-define:GNOME_SHARP_2_24 -nowarn:0169,0612,0618 -unsafe +-out:gnome-sharp.dll -target:library +-r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/pango-sharp.dll -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gdk-sharp.dll -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glib-sharp.dll /r:../art/art-sharp.dll /r:../gnomevfs/gnome-vfs-sharp.dll -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/2.0/Mono.Cairo.dll generated/*.cs ./BonoboUIVerb.cs ./IconTheme.cs ./Modules.cs AssemblyInfo.cs +AssemblyInfo.cs(6,11): warning CS1699: Use compiler option `keyfile' or +appropriate project settings instead of `AssemblyKeyFile' attribute +generated/App.cs(41,17): warning CS0108: `Gnome.App.Name' hides +inherited member `Gtk.Widget.Name'. Use the new keyword if hiding was +intended +/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll +(Location of the symbol related to previous warning) +generated/ThemeFile.cs(41,26): warning CS0809: Obsolete member +`Gnome.ThemeFile.ToString()' overrides non-obsolete member +`object.ToString()' +/home/jsr/local/lib/mono/4.5/mscorlib.dll (Location of the symbol +related to previous warning) +generated/CanvasShape.cs(200,41): error CS0030: Cannot convert type +`GLib.Value' to `Art.VpathDash' +Compilation failed: 1 error(s), 3 warnings +make[3]: *** [gnome-sharp.dll] Error 1 +make[3]: Leaving directory `/home/jsr/dev/gnome-sharp/gnome' +make[2]: *** [all-recursive] Error 1 +make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/gnome' +make[1]: *** [all-recursive] Error 1 +make[1]: Leaving directory `/home/jsr/dev/gnome-sharp' +make: *** [all] Error 2 +[jsr at hermes gnome-sharp]$ + + +If I've left out any information helpful to resolution of the problem, +I'd be more than happy to provide it. + +Any help appreciated. + +Regards...Jeremy + + + ++ + +
Starting: Mon Dec 31 10:19:33 UTC 2012
+ Ending: Mon Dec 31 10:19:33 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Mon Dec 31 10:19:33 UTC 2012
+ Archived on: Mon Dec 31 10:37:08 UTC 2012
+
+
+
Starting: Mon Dec 31 10:19:33 UTC 2012
+ Ending: Mon Dec 31 10:19:33 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Mon Dec 31 10:19:33 UTC 2012
+ Archived on: Mon Dec 31 10:37:08 UTC 2012
+
+
+
Starting: Mon Dec 31 10:19:33 UTC 2012
+ Ending: Mon Dec 31 10:19:33 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Mon Dec 31 10:19:33 UTC 2012
+ Archived on: Mon Dec 31 10:37:08 UTC 2012
+
+
+
Starting: Mon Dec 31 10:19:33 UTC 2012
+ Ending: Mon Dec 31 10:19:33 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Mon Dec 31 10:19:33 UTC 2012
+ Archived on: Mon Dec 31 10:37:08 UTC 2012
+
+
+
Starting: Mon Dec 31 10:19:33 UTC 2012
+ Ending: Mon Dec 31 10:19:33 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Mon Dec 31 10:19:33 UTC 2012
+ Archived on: Mon Dec 31 10:37:08 UTC 2012
+
+
+
Hi! + +I'm just wondering? Is there who knows about debugging with SDB on +ARM? the Meego Addin should have been able to do this, and the Mono +for the Iphone also uses the SDB to debug so i expected it to work. +I'm willing to investigate this issue on my own, but any help would be +really appreciated. + +thanks + +Peter + +Am 29. Januar 2012 15:18 schrieb Peter Siegel <siegelpeter2009 at gmail.com>: +> Hi! +> +> I tried to do single step debugging using the mono sdb with +> monodevelop remotely on an arm target... +> I modified the Meego addin to be able to debug remotely on any Linux +> System. It's an Linux Remote Debugging addin now :-) +> +> It works very well on the same cpu architecture. Now I can debug my +> Linux Mono Programs from windows, but some debuging features do not +> work if the remote target is an Arm Plattform. +> +> It connects without an exception and the Programm starts, when the +> remote program throws an exception, the exception caught window opens +> with no information at all and instance is "evaluating". On the +> Remote Arm box, the Mono process has stopped +> +> When i insert an breakpoint the Program seems to pauses, but when i +> press continue it crashes: +> +> Loaded assembly: /root/test/testproj.exe +> Resolved pending breakpoint at +> 'C:\Users\PeterS\Documents\testproj\testproj\Main.cs:11' to Void +> testproj.MainClass:Main (String[]) [0x00011]. +> converting method System.OutOfMemoryException:.ctor (string) +> Method System.OutOfMemoryException:.ctor (string) emitted at +> 0xb6ee4b68 to 0xb6ee4c20 (code length 184) [testproj.exe] +> converting method (wrapper runtime-invoke) +> <Module>:runtime_invoke_void__this___object +> (object,intptr,intptr,intptr) +> Method (wrapper runtime-invoke) +> <Module>:runtime_invoke_void__this___object +> (object,intptr,intptr,intptr) emitted at 0xb6ee4c48 to 0xb6ee4f2c +> (code length 740) [testproj.exe] +> converting method System.SystemException:.ctor (string) +> Method System.SystemException:.ctor (string) emitted at 0xb6ee4f30 to +> 0xb6ee4fe8 (code length 184) [testproj.exe] +> converting method System.Exception:.ctor (string) +> Method System.Exception:.ctor (string) emitted at 0xb6ee4ff8 to +> 0xb6ee50d4 (code length 220) [testproj.exe] +> converting method System.Exception:set_HResult (int) +> Method System.Exception:set_HResult (int) emitted at 0xb6ee50d8 to +> 0xb6ee5160 (code length 136) [testproj.exe] +> converting method System.NullReferenceException:.ctor (string) +> Method System.NullReferenceException:.ctor (string) emitted at +> 0xb6ee5160 to 0xb6ee5218 (code length 184) [testproj.exe] +> converting method System.StackOverflowException:.ctor (string) +> Method System.StackOverflowException:.ctor (string) emitted at +> 0xb6ee5218 to 0xb6ee52a0 (code length 136) [testproj.exe] +> converting method testproj.MainClass:Main (string[]) +> Method testproj.MainClass:Main (string[]) emitted at 0xb6ee52b0 to +> 0xb6ee5490 (code length 480) [testproj.exe] +> converting method (wrapper runtime-invoke) +> <Module>:runtime_invoke_void_object (object,intptr,intptr,intptr) +> Method (wrapper runtime-invoke) <Module>:runtime_invoke_void_object +> (object,intptr,intptr,intptr) emitted at 0xb6ee54b8 to 0xb6ee5794 +> (code length 732) [testproj.exe] +> converting method System.Console:WriteLine (string) +> Method System.Console:WriteLine (string) emitted at 0xb6ee5798 to +> 0xb6ee5834 (code length 156) [testproj.exe] +> converting method System.Console:.cctor () +> Method System.Console:.cctor () emitted at 0xb6ee5870 to 0xb6ee6358 +> (code length 2792) [testproj.exe] +> converting method (wrapper runtime-invoke) object:runtime_invoke_void +> (object,intptr,intptr,intptr) +> Method (wrapper runtime-invoke) object:runtime_invoke_void +> (object,intptr,intptr,intptr) emitted at 0xb6ee6440 to 0xb6ee670c +> (code length 716) [testproj.exe] +> converting method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_fast (intptr) +> Method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_fast (intptr) emitted at +> 0xb6ee6718 to 0xb6ee6810 (code length 248) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.Text.Encoding:InternalCodePage (int&) +> Method (wrapper managed-to-native) +> System.Text.Encoding:InternalCodePage (int&) emitted at 0xb6ee6810 to +> 0xb6ee6908 (code length 248) [testproj.exe] +> converting method System.Text.Encoding:.cctor () +> Method System.Text.Encoding:.cctor () emitted at 0xb6ee6920 to +> 0xb6ee7298 (code length 2424) [testproj.exe] +> converting method (wrapper managed-to-native) +> object:__icall_wrapper_mono_array_new_specific (intptr,int) +> Method (wrapper managed-to-native) +> object:__icall_wrapper_mono_array_new_specific (intptr,int) emitted at +> 0xb6ee72a8 to 0xb6ee73a8 (code length 256) [testproj.exe] +> converting method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) +> Method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) emitted at +> 0xb6ee73a8 to 0xb6ee74a0 (code length 248) [testproj.exe] +> converting method (wrapper stelemref) object:virt_stelemref_object +> (intptr,object) +> Method (wrapper stelemref) object:virt_stelemref_object +> (intptr,object) emitted at 0xb6ee74a0 to 0xb6ee7558 (code length 184) +> [testproj.exe] +> converting method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_ptrfree (intptr) +> Method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_ptrfree (intptr) emitted at +> 0xb6ee7558 to 0xb6ee7650 (code length 248) [testproj.exe] +> converting method object:.ctor () +> Method object:.ctor () emitted at 0xb6ee7650 to 0xb6ee76a8 (code +> length 88) [testproj.exe] +> converting method System.Text.Encoding:get_UTF8Unmarked () +> Method System.Text.Encoding:get_UTF8Unmarked () emitted at 0xb6ee76a8 +> to 0xb6ee792c (code length 644) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.Threading.Monitor:Enter (object) +> Method (wrapper managed-to-native) System.Threading.Monitor:Enter +> (object) emitted at 0xb6ee7950 to 0xb6ee7a8c (code length 316) +> [testproj.exe] +> converting method System.Text.UTF8Encoding:.ctor (bool,bool) +> Method System.Text.UTF8Encoding:.ctor (bool,bool) emitted at +> 0xb6ee7a90 to 0xb6ee7d94 (code length 772) [testproj.exe] +> converting method System.Text.Encoding:.ctor (int) +> Method System.Text.Encoding:.ctor (int) emitted at 0xb6ee7de0 to +> 0xb6ee8258 (code length 1144) [testproj.exe] +> converting method System.Text.DecoderFallback:get_StandardSafeFallback () +> converting method System.Text.DecoderFallback:.cctor () +> Method System.Text.DecoderFallback:.cctor () emitted at 0xb6ee8270 to +> 0xb6ee83a0 (code length 304) [testproj.exe] +> converting method System.Text.DecoderExceptionFallback:.ctor () +> Method System.Text.DecoderExceptionFallback:.ctor () emitted at +> 0xb6ee83c8 to 0xb6ee8448 (code length 128) [testproj.exe] +> converting method System.Text.DecoderFallback:.ctor () +> Method System.Text.DecoderFallback:.ctor () emitted at 0xb6ee8458 to +> 0xb6ee84d4 (code length 124) [testproj.exe] +> converting method System.Text.DecoderReplacementFallback:.ctor () +> Method System.Text.DecoderReplacementFallback:.ctor () emitted at +> 0xb6ee84d8 to 0xb6ee8560 (code length 136) [testproj.exe] +> converting method System.Text.DecoderReplacementFallback:.ctor (string) +> Method System.Text.DecoderReplacementFallback:.ctor (string) emitted +> at 0xb6ee8560 to 0xb6ee866c (code length 268) [testproj.exe] +> Method System.Text.DecoderFallback:get_StandardSafeFallback () emitted +> at 0xb6ee8670 to 0xb6ee86ec (code length 124) [testproj.exe] +> converting method System.Text.EncoderFallback:get_StandardSafeFallback () +> converting method System.Text.EncoderFallback:.cctor () +> Method System.Text.EncoderFallback:.cctor () emitted at 0xb6ee86f0 to +> 0xb6ee8820 (code length 304) [testproj.exe] +> converting method System.Text.EncoderExceptionFallback:.ctor () +> Method System.Text.EncoderExceptionFallback:.ctor () emitted at +> 0xb6ee8848 to 0xb6ee88c8 (code length 128) [testproj.exe] +> converting method System.Text.EncoderFallback:.ctor () +> Method System.Text.EncoderFallback:.ctor () emitted at 0xb6ee88d8 to +> 0xb6ee8954 (code length 124) [testproj.exe] +> converting method System.Text.EncoderReplacementFallback:.ctor () +> Method System.Text.EncoderReplacementFallback:.ctor () emitted at +> 0xb6ee8958 to 0xb6ee89e0 (code length 136) [testproj.exe] +> converting method System.Text.EncoderReplacementFallback:.ctor (string) +> Method System.Text.EncoderReplacementFallback:.ctor (string) emitted +> at 0xb6ee89e0 to 0xb6ee8aec (code length 268) [testproj.exe] +> Method System.Text.EncoderFallback:get_StandardSafeFallback () emitted +> at 0xb6ee8af0 to 0xb6ee8b6c (code length 124) [testproj.exe] +> converting method System.Text.Encoding:SetFallbackInternal +> (System.Text.EncoderFallback,System.Text.DecoderFallback) +> Method System.Text.Encoding:SetFallbackInternal +> (System.Text.EncoderFallback,System.Text.DecoderFallback) emitted at +> 0xb6ee8b70 to 0xb6ee8c80 (code length 272) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.Threading.Monitor:Exit (object) +> Method (wrapper managed-to-native) System.Threading.Monitor:Exit +> (object) emitted at 0xb6ee8c80 to 0xb6ee8dbc (code length 316) +> [testproj.exe] +> converting method System.Console:OpenStandardError (int) +> Method System.Console:OpenStandardError (int) emitted at 0xb6ee8dc0 to +> 0xb6ee8e48 (code length 136) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.IO.MonoIO:get_ConsoleError () +> Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleError +> () emitted at 0xb6ee8e60 to 0xb6ee8f50 (code length 240) +> [testproj.exe] +> converting method System.IO.MonoIO:.cctor () +> Method System.IO.MonoIO:.cctor () emitted at 0xb6ee8f50 to 0xb6ee9010 +> (code length 192) [testproj.exe] +> converting method intptr:op_Explicit (long) +> Method intptr:op_Explicit (long) emitted at 0xb6ee9020 to 0xb6ee90c0 +> (code length 160) [testproj.exe] +> converting method intptr:.ctor (long) +> Method intptr:.ctor (long) emitted at 0xb6ee90d0 to 0xb6ee9160 (code +> length 144) [testproj.exe] +> converting method System.Console:Open (intptr,System.IO.FileAccess,int) +> Method System.Console:Open (intptr,System.IO.FileAccess,int) emitted +> at 0xb6ee9160 to 0xb6ee9354 (code length 500) [testproj.exe] +> converting method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_specific (intptr) +> Method (wrapper managed-to-native) +> object:__icall_wrapper_mono_object_new_specific (intptr) emitted at +> 0xb6ee9370 to 0xb6ee9468 (code length 248) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.FileStream:.ctor +> (intptr,System.IO.FileAccess,bool,int,bool,bool) +> Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor +> (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee9468 +> to 0xb6ee9628 (code length 448) [testproj.exe] +> converting method System.IO.FileStream:.cctor () +> Method System.IO.FileStream:.cctor () emitted at 0xb6ee9640 to +> 0xb6ee96d8 (code length 152) [testproj.exe] +> converting method System.IO.FileStream:.ctor +> (intptr,System.IO.FileAccess,bool,int,bool,bool) +> Method System.IO.FileStream:.ctor +> (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee96e8 +> to 0xb6ee9d74 (code length 1676) [testproj.exe] +> converting method System.IO.Stream:.ctor () +> Method System.IO.Stream:.ctor () emitted at 0xb6ee9dc8 to 0xb6ee9e48 +> (code length 128) [testproj.exe] +> converting method System.IO.Stream:.cctor () +> Method System.IO.Stream:.cctor () emitted at 0xb6ee9e58 to 0xb6ee9efc +> (code length 164) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.NullStream:.ctor () +> Method (wrapper remoting-invoke-with-check) System.IO.NullStream:.ctor +> () emitted at 0xb6ee9f00 to 0xb6ee9fd4 (code length 212) +> [testproj.exe] +> converting method System.IO.NullStream:.ctor () +> Method System.IO.NullStream:.ctor () emitted at 0xb6ee9ff0 to +> 0xb6eea070 (code length 128) [testproj.exe] +> converting method System.MarshalByRefObject:.ctor () +> Method System.MarshalByRefObject:.ctor () emitted at 0xb6eea070 to +> 0xb6eea0ec (code length 124) [testproj.exe] +> converting method intptr:op_Equality (intptr,intptr) +> Method intptr:op_Equality (intptr,intptr) emitted at 0xb6eea0f0 to +> 0xb6eea188 (code length 152) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.IO.MonoIO:GetFileType (intptr,System.IO.MonoIOError&) +> Method (wrapper managed-to-native) System.IO.MonoIO:GetFileType +> (intptr,System.IO.MonoIOError&) emitted at 0xb6eea188 to 0xb6eea288 +> (code length 256) [testproj.exe] +> converting method System.IO.FileStream:InitBuffer (int,bool) +> Method System.IO.FileStream:InitBuffer (int,bool) emitted at +> 0xb6eea288 to 0xb6eea72c (code length 1188) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.UnexceptionalStreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding) +> Method (wrapper remoting-invoke-with-check) +> System.IO.UnexceptionalStreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea748 to +> 0xb6eea844 (code length 252) [testproj.exe] +> converting method System.IO.UnexceptionalStreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding) +> Method System.IO.UnexceptionalStreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea860 to +> 0xb6eea8f0 (code length 144) [testproj.exe] +> converting method System.IO.StreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding) +> Method System.IO.StreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea900 to +> 0xb6eea994 (code length 148) [testproj.exe] +> converting method System.IO.StreamWriter:.cctor () +> Method System.IO.StreamWriter:.cctor () emitted at 0xb6eea9a0 to +> 0xb6eeaa74 (code length 212) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.StreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding,int) +> Method (wrapper remoting-invoke-with-check) +> System.IO.StreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaa80 to +> 0xb6eeab98 (code length 280) [testproj.exe] +> converting method System.IO.StreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding,int) +> Method System.IO.StreamWriter:.ctor +> (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaba8 to +> 0xb6eeae54 (code length 684) [testproj.exe] +> converting method System.IO.TextWriter:.ctor () +> Method System.IO.TextWriter:.ctor () emitted at 0xb6eeae70 to +> 0xb6eeaf34 (code length 196) [testproj.exe] +> converting method System.IO.TextWriter:.cctor () +> Method System.IO.TextWriter:.cctor () emitted at 0xb6eeaf50 to +> 0xb6eeaff4 (code length 164) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.TextWriter/NullTextWriter:.ctor () +> Method (wrapper remoting-invoke-with-check) +> System.IO.TextWriter/NullTextWriter:.ctor () emitted at 0xb6eeb000 to +> 0xb6eeb0d4 (code length 212) [testproj.exe] +> converting method System.IO.TextWriter/NullTextWriter:.ctor () +> Method System.IO.TextWriter/NullTextWriter:.ctor () emitted at +> 0xb6eeb0f0 to 0xb6eeb170 (code length 128) [testproj.exe] +> converting method System.Environment:get_NewLine () +> Method System.Environment:get_NewLine () emitted at 0xb6eeb170 to +> 0xb6eeb2a8 (code length 312) [testproj.exe] +> converting method (wrapper managed-to-native) System.Environment:GetNewLine () +> Method (wrapper managed-to-native) System.Environment:GetNewLine () +> emitted at 0xb6eeb2b8 to 0xb6eeb3a8 (code length 240) [testproj.exe] +> converting method string:ToCharArray () +> Method string:ToCharArray () emitted at 0xb6eeb3a8 to 0xb6eeb434 (code +> length 140) [testproj.exe] +> converting method string:.cctor () +> Method string:.cctor () emitted at 0xb6eeb440 to 0xb6eeb554 (code +> length 276) [testproj.exe] +> converting method (wrapper managed-to-native) string:GetLOSLimit () +> Method (wrapper managed-to-native) string:GetLOSLimit () emitted at +> 0xb6eeb570 to 0xb6eeb660 (code length 240) [testproj.exe] +> converting method string:memcpy (byte*,byte*,int) +> Method string:memcpy (byte*,byte*,int) emitted at 0xb6eeb660 to +> 0xb6eebac8 (code length 1128) [testproj.exe] +> converting method string:memcpy4 (byte*,byte*,int) +> Method string:memcpy4 (byte*,byte*,int) emitted at 0xb6eebaf0 to +> 0xb6eebf10 (code length 1056) [testproj.exe] +> converting method string:ToCharArray (int,int) +> Method string:ToCharArray (int,int) emitted at 0xb6eebf10 to +> 0xb6eec32c (code length 1052) [testproj.exe] +> converting method string:CharCopy (char*,char*,int) +> Method string:CharCopy (char*,char*,int) emitted at 0xb6eec338 to +> 0xb6eec5d8 (code length 672) [testproj.exe] +> converting method System.IO.NullStream:get_CanWrite () +> Method System.IO.NullStream:get_CanWrite () emitted at 0xb6eec5d8 to +> 0xb6eec654 (code length 124) [testproj.exe] +> converting method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +> Method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +> emitted at 0xb6eec658 to 0xb6eec8f4 (code length 668) [testproj.exe] +> converting method System.Math:Max (int,int) +> Method System.Math:Max (int,int) emitted at 0xb6eec8f8 to 0xb6eec9dc +> (code length 228) [testproj.exe] +> converting method System.Text.UTF8Encoding:GetMaxByteCount (int) +> Method System.Text.UTF8Encoding:GetMaxByteCount (int) emitted at +> 0xb6eec9e0 to 0xb6eecaec (code length 268) [testproj.exe] +> converting method System.IO.NullStream:get_CanSeek () +> Method System.IO.NullStream:get_CanSeek () emitted at 0xb6eecaf8 to +> 0xb6eecb74 (code length 124) [testproj.exe] +> converting method System.IO.NullStream:get_Position () +> Method System.IO.NullStream:get_Position () emitted at 0xb6eecb78 to +> 0xb6eecbf8 (code length 128) [testproj.exe] +> converting method System.IO.FileStream:get_CanWrite () +> Method System.IO.FileStream:get_CanWrite () emitted at 0xb6eecbf8 to +> 0xb6eeccf0 (code length 248) [testproj.exe] +> converting method System.IO.FileStream:get_CanSeek () +> Method System.IO.FileStream:get_CanSeek () emitted at 0xb6eeccf0 to +> 0xb6eecd70 (code length 128) [testproj.exe] +> converting method System.IO.StreamWriter:set_AutoFlush (bool) +> Method System.IO.StreamWriter:set_AutoFlush (bool) emitted at +> 0xb6eecd70 to 0xb6eece5c (code length 236) [testproj.exe] +> converting method System.IO.UnexceptionalStreamWriter:Flush () +> Method System.IO.UnexceptionalStreamWriter:Flush () emitted at +> 0xb6eece60 to 0xb6eecf4c (code length 236) [testproj.exe] +> converting method System.IO.StreamWriter:Flush () +> Method System.IO.StreamWriter:Flush () emitted at 0xb6eecf58 to +> 0xb6eed0dc (code length 388) [testproj.exe] +> converting method System.IO.StreamWriter:Decode () +> Method System.IO.StreamWriter:Decode () emitted at 0xb6eed0f8 to +> 0xb6eed308 (code length 528) [testproj.exe] +> converting method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +> Method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +> emitted at 0xb6eed320 to 0xb6eed5c0 (code length 672) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +> Method (wrapper remoting-invoke-with-check) +> System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) emitted +> at 0xb6eed5d8 to 0xb6eed6d4 (code length 252) [testproj.exe] +> converting method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +> Method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +> emitted at 0xb6eed6f0 to 0xb6eed7d0 (code length 224) [testproj.exe] +> converting method System.ConsoleDriver:get_IsConsole () +> Method System.ConsoleDriver:get_IsConsole () emitted at 0xb6eed7d0 to +> 0xb6eed9b0 (code length 480) [testproj.exe] +> converting method System.ConsoleDriver:.cctor () +> Method System.ConsoleDriver:.cctor () emitted at 0xb6eed9e0 to +> 0xb6eedc6c (code length 652) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.IO.MonoIO:get_ConsoleOutput () +> Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleOutput +> () emitted at 0xb6eedca8 to 0xb6eedd98 (code length 240) +> [testproj.exe] +> converting method (wrapper managed-to-native) +> System.ConsoleDriver:Isatty (intptr) +> Method (wrapper managed-to-native) System.ConsoleDriver:Isatty +> (intptr) emitted at 0xb6eedd98 to 0xb6eede90 (code length 248) +> [testproj.exe] +> converting method System.ConsoleDriver:CreateNullConsoleDriver () +> Method System.ConsoleDriver:CreateNullConsoleDriver () emitted at +> 0xb6eede90 to 0xb6eedf1c (code length 140) [testproj.exe] +> converting method System.NullConsoleDriver:.ctor () +> Method System.NullConsoleDriver:.ctor () emitted at 0xb6eedf28 to +> 0xb6eedfa4 (code length 124) [testproj.exe] +> converting method System.Console:OpenStandardOutput (int) +> Method System.Console:OpenStandardOutput (int) emitted at 0xb6eedfa8 +> to 0xb6eee030 (code length 136) [testproj.exe] +> converting method System.Console:OpenStandardInput (int) +> Method System.Console:OpenStandardInput (int) emitted at 0xb6eee030 to +> 0xb6eee0b8 (code length 136) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.IO.MonoIO:get_ConsoleInput () +> Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleInput +> () emitted at 0xb6eee0b8 to 0xb6eee1a8 (code length 240) +> [testproj.exe] +> converting method System.IO.UnexceptionalStreamReader:.cctor () +> Method System.IO.UnexceptionalStreamReader:.cctor () emitted at +> 0xb6eee1a8 to 0xb6eee300 (code length 344) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.UnexceptionalStreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding) +> Method (wrapper remoting-invoke-with-check) +> System.IO.UnexceptionalStreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee300 to +> 0xb6eee3fc (code length 252) [testproj.exe] +> converting method System.IO.UnexceptionalStreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding) +> Method System.IO.UnexceptionalStreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee418 to +> 0xb6eee4a8 (code length 144) [testproj.exe] +> converting method System.IO.StreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding) +> Method System.IO.StreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee4b8 to +> 0xb6eee554 (code length 156) [testproj.exe] +> converting method System.IO.StreamReader:.cctor () +> Method System.IO.StreamReader:.cctor () emitted at 0xb6eee560 to +> 0xb6eee648 (code length 232) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.StreamReader/NullStreamReader:.ctor () +> Method (wrapper remoting-invoke-with-check) +> System.IO.StreamReader/NullStreamReader:.ctor () emitted at 0xb6eee658 +> to 0xb6eee72c (code length 212) [testproj.exe] +> converting method System.IO.StreamReader/NullStreamReader:.ctor () +> Method System.IO.StreamReader/NullStreamReader:.ctor () emitted at +> 0xb6eee748 to 0xb6eee7c8 (code length 128) [testproj.exe] +> converting method System.IO.StreamReader:.ctor () +> Method System.IO.StreamReader:.ctor () emitted at 0xb6eee7d8 to +> 0xb6eee858 (code length 128) [testproj.exe] +> converting method System.IO.TextReader:.ctor () +> Method System.IO.TextReader:.ctor () emitted at 0xb6eee868 to +> 0xb6eee8e8 (code length 128) [testproj.exe] +> converting method System.IO.TextReader:.cctor () +> Method System.IO.TextReader:.cctor () emitted at 0xb6eee8e8 to +> 0xb6eee98c (code length 164) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.TextReader/NullTextReader:.ctor () +> Method (wrapper remoting-invoke-with-check) +> System.IO.TextReader/NullTextReader:.ctor () emitted at 0xb6eee998 to +> 0xb6eeea6c (code length 212) [testproj.exe] +> converting method System.IO.TextReader/NullTextReader:.ctor () +> Method System.IO.TextReader/NullTextReader:.ctor () emitted at +> 0xb6eeea88 to 0xb6eeeb08 (code length 128) [testproj.exe] +> converting method System.IO.StreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding,bool,int) +> Method System.IO.StreamReader:.ctor +> (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeeb08 +> to 0xb6eeebd8 (code length 208) [testproj.exe] +> converting method System.IO.StreamReader:Initialize +> (System.IO.Stream,System.Text.Encoding,bool,int) +> Method System.IO.StreamReader:Initialize +> (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeebe8 +> to 0xb6eef5b8 (code length 2512) [testproj.exe] +> converting method System.IO.FileStream:get_CanRead () +> Method System.IO.FileStream:get_CanRead () emitted at 0xb6eef5b8 to +> 0xb6eef6b0 (code length 248) [testproj.exe] +> converting method System.Text.UTF8Encoding:GetMaxCharCount (int) +> Method System.Text.UTF8Encoding:GetMaxCharCount (int) emitted at +> 0xb6eef6b0 to 0xb6eef7b8 (code length 264) [testproj.exe] +> converting method System.Text.UTF8Encoding:GetDecoder () +> Method System.Text.UTF8Encoding:GetDecoder () emitted at 0xb6eef7b8 to +> 0xb6eef858 (code length 160) [testproj.exe] +> converting method System.Text.Encoding:get_DecoderFallback () +> Method System.Text.Encoding:get_DecoderFallback () emitted at +> 0xb6eef870 to 0xb6eef8f0 (code length 128) [testproj.exe] +> converting method System.Text.UTF8Encoding/UTF8Decoder:.ctor +> (System.Text.DecoderFallback) +> Method System.Text.UTF8Encoding/UTF8Decoder:.ctor +> (System.Text.DecoderFallback) emitted at 0xb6eef8f0 to 0xb6eef9f8 +> (code length 264) [testproj.exe] +> converting method System.Text.Decoder:.ctor () +> Method System.Text.Decoder:.ctor () emitted at 0xb6eefa10 to +> 0xb6eefad4 (code length 196) [testproj.exe] +> converting method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +> Method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +> emitted at 0xb6eefad8 to 0xb6eefbe8 (code length 272) [testproj.exe] +> converting method System.Text.UTF8Encoding:GetPreamble () +> Method System.Text.UTF8Encoding:GetPreamble () emitted at 0xb6eefbe8 +> to 0xb6eefd10 (code length 296) [testproj.exe] +> converting method (wrapper stfld) +> object:__stfld_wrapper_0x34ee68_System.Int32 +> (object,intptr,intptr,intptr,int) +> Method (wrapper stfld) object:__stfld_wrapper_0x34ee68_System.Int32 +> (object,intptr,intptr,intptr,int) emitted at 0xb6eefd10 to 0xb6eefe7c +> (code length 364) [testproj.exe] +> converting method (wrapper ldfld) +> object:__ldfld_wrapper_0x34ee68_System.Int32 +> (object,intptr,intptr,intptr) +> Method (wrapper ldfld) object:__ldfld_wrapper_0x34ee68_System.Int32 +> (object,intptr,intptr,intptr) emitted at 0xb6eefe88 to 0xb6eeffd8 +> (code length 336) [testproj.exe] +> converting method System.IO.TextReader:Synchronized (System.IO.TextReader) +> Method System.IO.TextReader:Synchronized (System.IO.TextReader) +> emitted at 0xb6eeffe8 to 0xb6ef0278 (code length 656) [testproj.exe] +> converting method (wrapper remoting-invoke-with-check) +> System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +> Method (wrapper remoting-invoke-with-check) +> System.IO.SynchronizedReader:.ctor (System.IO.TextReader) emitted at +> 0xb6ef0290 to 0xb6ef0378 (code length 232) [testproj.exe] +> converting method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +> Method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +> emitted at 0xb6ef0390 to 0xb6ef0440 (code length 176) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.GC:SuppressFinalize (object) +> Method (wrapper managed-to-native) System.GC:SuppressFinalize (object) +> emitted at 0xb6ef0440 to 0xb6ef057c (code length 316) [testproj.exe] +> converting method System.IO.SynchronizedWriter:WriteLine (string) +> Method System.IO.SynchronizedWriter:WriteLine (string) emitted at +> 0xb6ef0580 to 0xb6ef06ec (code length 364) [testproj.exe] +> converting method System.IO.TextWriter:WriteLine (string) +> Method System.IO.TextWriter:WriteLine (string) emitted at 0xb6ef06f0 +> to 0xb6ef07b8 (code length 200) [testproj.exe] +> converting method System.IO.UnexceptionalStreamWriter:Write (string) +> Method System.IO.UnexceptionalStreamWriter:Write (string) emitted at +> 0xb6ef07b8 to 0xb6ef08ac (code length 244) [testproj.exe] +> converting method System.IO.StreamWriter:Write (string) +> Method System.IO.StreamWriter:Write (string) emitted at 0xb6ef08b8 to +> 0xb6ef0a40 (code length 392) [testproj.exe] +> converting method System.IO.StreamWriter:LowLevelWrite (string) +> Method System.IO.StreamWriter:LowLevelWrite (string) emitted at +> 0xb6ef0a50 to 0xb6ef0e94 (code length 1092) [testproj.exe] +> converting method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +> Method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +> emitted at 0xb6ef0e98 to 0xb6ef1010 (code length 376) [testproj.exe] +> converting method System.Text.Encoding:get_EncoderFallback () +> Method System.Text.Encoding:get_EncoderFallback () emitted at +> 0xb6ef1028 to 0xb6ef10a8 (code length 128) [testproj.exe] +> converting method System.Text.UTF8Encoding:InternalGetBytes +> (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> Method System.Text.UTF8Encoding:InternalGetBytes +> (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> emitted at 0xb6ef10a8 to 0xb6ef1878 (code length 2000) [testproj.exe] +> converting method System.Text.UTF8Encoding:InternalGetBytes +> (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> Method System.Text.UTF8Encoding:InternalGetBytes +> (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> emitted at 0xb645a000 to 0xb645b31c (code length 4892) [testproj.exe] +> converting method System.IO.StreamWriter:FlushBytes () +> Method System.IO.StreamWriter:FlushBytes () emitted at 0xb645b338 to +> 0xb645b558 (code length 544) [testproj.exe] +> converting method System.IO.FileStream:Write (byte[],int,int) +> Method System.IO.FileStream:Write (byte[],int,int) emitted at +> 0xb645b558 to 0xb645b9cc (code length 1140) [testproj.exe] +> converting method System.IO.FileStream:WriteInternal (byte[],int,int) +> Method System.IO.FileStream:WriteInternal (byte[],int,int) emitted at +> 0xb645b9d8 to 0xb645bed0 (code length 1272) [testproj.exe] +> converting method System.IO.FileStream:FlushBuffer () +> Method System.IO.FileStream:FlushBuffer () emitted at 0xb645bf18 to +> 0xb645bf9c (code length 132) [testproj.exe] +> converting method System.IO.FileStream:FlushBuffer (System.IO.Stream) +> Method System.IO.FileStream:FlushBuffer (System.IO.Stream) emitted at +> 0xb645bfa8 to 0xb645c4fc (code length 1364) [testproj.exe] +> converting method (wrapper ldfld) +> object:__ldfld_wrapper_0x350250_System.Int64 +> (object,intptr,intptr,intptr) +> Method (wrapper ldfld) object:__ldfld_wrapper_0x350250_System.Int64 +> (object,intptr,intptr,intptr) emitted at 0xb645c500 to 0xb645c654 +> (code length 340) [testproj.exe] +> coStarted +> nverting method (wrapper stfld) +> object:__stfld_wrapper_0x350250_System.Int64 +> (object,intptr,intptr,intptr,long) +> Method (wrapper stfld) object:__stfld_wrapper_0x350250_System.Int64 +> (object,intptr,intptr,intptr,long) emitted at 0xb645c658 to 0xb645c7e4 +> (code length 396) [testproj.exe] +> converting method (wrapper managed-to-native) System.IO.MonoIO:Write +> (intptr,byte[],int,int,System.IO.MonoIOError&) +> Method (wrapper managed-to-native) System.IO.MonoIO:Write +> (intptr,byte[],int,int,System.IO.MonoIOError&) emitted at 0xb645c7e8 +> to 0xb645c918 (code length 304) [testproj.exe] +> converting method System.IO.FileStream:Flush () +> Method System.IO.FileStream:Flush () emitted at 0xb645c918 to +> 0xb645ca18 (code length 256) [testproj.exe] +> converting method System.IO.TextWriter:WriteLine () +> Method System.IO.TextWriter:WriteLine () emitted at 0xb645ca18 to +> 0xb645caac (code length 148) [testproj.exe] +> converting method System.IO.UnexceptionalStreamWriter:Write (char[]) +> Method System.IO.UnexceptionalStreamWriter:Write (char[]) emitted at +> 0xb645cab0 to 0xb645cba4 (code length 244) [testproj.exe] +> converting method System.IO.StreamWriter:Write (char[]) +> Method System.IO.StreamWriter:Write (char[]) emitted at 0xb645cbb0 to +> 0xb645cd44 (code length 404) [testproj.exe] +> converting method System.IO.StreamWriter:LowLevelWrite (char[],int,int) +> Method System.IO.StreamWriter:LowLevelWrite (char[],int,int) emitted +> at 0xb645cd50 to 0xb645d04c (code length 764) [testproj.exe] +> converting method System.Buffer:BlockCopy +> (System.Array,int,System.Array,int,int) +> Method System.Buffer:BlockCopy (System.Array,int,System.Array,int,int) +> emitted at 0xb645d058 to 0xb645d458 (code length 1024) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.Buffer:BlockCopyInternal +> (System.Array,int,System.Array,int,int) +> Method (wrapper managed-to-native) System.Buffer:BlockCopyInternal +> (System.Array,int,System.Array,int,int) emitted at 0xb645d470 to +> 0xb645d5a0 (code length 304) [testproj.exe] +> converting method System.ExecutionEngineException:.ctor () +> Method System.ExecutionEngineException:.ctor () emitted at 0xb645d5a0 +> to 0xb645d638 (code length 152) [testproj.exe] +> converting method (wrapper runtime-invoke) +> object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) +> Method (wrapper runtime-invoke) object:runtime_invoke_void__this__ +> (object,intptr,intptr,intptr) emitted at 0xb645d638 to 0xb645d90c +> (code length 724) [testproj.exe] +> converting method Locale:GetText (string) +> Method Locale:GetText (string) emitted at 0xb645d910 to 0xb645d98c +> (code length 124) [testproj.exe] +> converting method System.Exception:ToString () +> Method System.Exception:ToString () emitted at 0xb645d990 to +> 0xb645dd04 (code length 884) [testproj.exe] +> converting method (wrapper runtime-invoke) +> <Module>:runtime_invoke_object__this__ (object,intptr,intptr,intptr) +> Method (wrapper runtime-invoke) <Module>:runtime_invoke_object__this__ +> (object,intptr,intptr,intptr) emitted at 0xb645dd28 to 0xb645e004 +> (code length 732) [testproj.exe] +> converting method System.Exception:get_ClassName () +> Method System.Exception:get_ClassName () emitted at 0xb645e008 to +> 0xb645e104 (code length 252) [testproj.exe] +> converting method System.Exception:GetType () +> Method System.Exception:GetType () emitted at 0xb645e110 to 0xb645e194 +> (code length 132) [testproj.exe] +> converting method System.MonoType:ToString () +> Method System.MonoType:ToString () emitted at 0xb645e198 to 0xb645e220 +> (code length 136) [testproj.exe] +> converting method (wrapper managed-to-native) +> System.MonoType:getFullName (System.MonoType,bool,bool) +> Method (wrapper managed-to-native) System.MonoType:getFullName +> (System.MonoType,bool,bool) emitted at 0xb645e230 to 0xb645e394 (code +> length 356) [testproj.exe] +> converting method System.Text.StringBuilder:.ctor (string) +> Method System.Text.StringBuilder:.ctor (string) emitted at 0xb645e398 +> to 0xb645e520 (code length 392) [testproj.exe] +> converting method System.Text.StringBuilder:Append (string) +> Method System.Text.StringBuilder:Append (string) emitted at 0xb645e520 +> to 0xb645e8c4 (code length 932) [testproj.exe] +> converting method +> Unhandled Exception: System.ExecutionEngineException: SIGILL +> [ERROR] FATAL UNHANDLED EXCEPTION: System.ExecutionEngineException: SIGILL +> +> +> What can i do? +> +> +> thanks Peter ++ + + +
Hi Peter, + +Looks like you are running out of memory for some reason. Beyond that, I +have no idea. + +Jeff + +On Tue, Feb 7, 2012 at 4:09 PM, Peter Siegel <siegelpeter2009 at gmail.com>wrote: + +> Hi! +> +> I'm just wondering? Is there who knows about debugging with SDB on +> ARM? the Meego Addin should have been able to do this, and the Mono +> for the Iphone also uses the SDB to debug so i expected it to work. +> I'm willing to investigate this issue on my own, but any help would be +> really appreciated. +> +> thanks +> +> Peter +> +> Am 29. Januar 2012 15:18 schrieb Peter Siegel <siegelpeter2009 at gmail.com>: +> > Hi! +> > +> > I tried to do single step debugging using the mono sdb with +> > monodevelop remotely on an arm target... +> > I modified the Meego addin to be able to debug remotely on any Linux +> > System. It's an Linux Remote Debugging addin now :-) +> > +> > It works very well on the same cpu architecture. Now I can debug my +> > Linux Mono Programs from windows, but some debuging features do not +> > work if the remote target is an Arm Plattform. +> > +> > It connects without an exception and the Programm starts, when the +> > remote program throws an exception, the exception caught window opens +> > with no information at all and instance is "evaluating". On the +> > Remote Arm box, the Mono process has stopped +> > +> > When i insert an breakpoint the Program seems to pauses, but when i +> > press continue it crashes: +> > +> > Loaded assembly: /root/test/testproj.exe +> > Resolved pending breakpoint at +> > 'C:\Users\PeterS\Documents\testproj\testproj\Main.cs:11' to Void +> > testproj.MainClass:Main (String[]) [0x00011]. +> > converting method System.OutOfMemoryException:.ctor (string) +> > Method System.OutOfMemoryException:.ctor (string) emitted at +> > 0xb6ee4b68 to 0xb6ee4c20 (code length 184) [testproj.exe] +> > converting method (wrapper runtime-invoke) +> > <Module>:runtime_invoke_void__this___object +> > (object,intptr,intptr,intptr) +> > Method (wrapper runtime-invoke) +> > <Module>:runtime_invoke_void__this___object +> > (object,intptr,intptr,intptr) emitted at 0xb6ee4c48 to 0xb6ee4f2c +> > (code length 740) [testproj.exe] +> > converting method System.SystemException:.ctor (string) +> > Method System.SystemException:.ctor (string) emitted at 0xb6ee4f30 to +> > 0xb6ee4fe8 (code length 184) [testproj.exe] +> > converting method System.Exception:.ctor (string) +> > Method System.Exception:.ctor (string) emitted at 0xb6ee4ff8 to +> > 0xb6ee50d4 (code length 220) [testproj.exe] +> > converting method System.Exception:set_HResult (int) +> > Method System.Exception:set_HResult (int) emitted at 0xb6ee50d8 to +> > 0xb6ee5160 (code length 136) [testproj.exe] +> > converting method System.NullReferenceException:.ctor (string) +> > Method System.NullReferenceException:.ctor (string) emitted at +> > 0xb6ee5160 to 0xb6ee5218 (code length 184) [testproj.exe] +> > converting method System.StackOverflowException:.ctor (string) +> > Method System.StackOverflowException:.ctor (string) emitted at +> > 0xb6ee5218 to 0xb6ee52a0 (code length 136) [testproj.exe] +> > converting method testproj.MainClass:Main (string[]) +> > Method testproj.MainClass:Main (string[]) emitted at 0xb6ee52b0 to +> > 0xb6ee5490 (code length 480) [testproj.exe] +> > converting method (wrapper runtime-invoke) +> > <Module>:runtime_invoke_void_object (object,intptr,intptr,intptr) +> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_void_object +> > (object,intptr,intptr,intptr) emitted at 0xb6ee54b8 to 0xb6ee5794 +> > (code length 732) [testproj.exe] +> > converting method System.Console:WriteLine (string) +> > Method System.Console:WriteLine (string) emitted at 0xb6ee5798 to +> > 0xb6ee5834 (code length 156) [testproj.exe] +> > converting method System.Console:.cctor () +> > Method System.Console:.cctor () emitted at 0xb6ee5870 to 0xb6ee6358 +> > (code length 2792) [testproj.exe] +> > converting method (wrapper runtime-invoke) object:runtime_invoke_void +> > (object,intptr,intptr,intptr) +> > Method (wrapper runtime-invoke) object:runtime_invoke_void +> > (object,intptr,intptr,intptr) emitted at 0xb6ee6440 to 0xb6ee670c +> > (code length 716) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_fast (intptr) +> > Method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_fast (intptr) emitted at +> > 0xb6ee6718 to 0xb6ee6810 (code length 248) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.Text.Encoding:InternalCodePage (int&) +> > Method (wrapper managed-to-native) +> > System.Text.Encoding:InternalCodePage (int&) emitted at 0xb6ee6810 to +> > 0xb6ee6908 (code length 248) [testproj.exe] +> > converting method System.Text.Encoding:.cctor () +> > Method System.Text.Encoding:.cctor () emitted at 0xb6ee6920 to +> > 0xb6ee7298 (code length 2424) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_array_new_specific (intptr,int) +> > Method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_array_new_specific (intptr,int) emitted at +> > 0xb6ee72a8 to 0xb6ee73a8 (code length 256) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) +> > Method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) emitted at +> > 0xb6ee73a8 to 0xb6ee74a0 (code length 248) [testproj.exe] +> > converting method (wrapper stelemref) object:virt_stelemref_object +> > (intptr,object) +> > Method (wrapper stelemref) object:virt_stelemref_object +> > (intptr,object) emitted at 0xb6ee74a0 to 0xb6ee7558 (code length 184) +> > [testproj.exe] +> > converting method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) +> > Method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) emitted at +> > 0xb6ee7558 to 0xb6ee7650 (code length 248) [testproj.exe] +> > converting method object:.ctor () +> > Method object:.ctor () emitted at 0xb6ee7650 to 0xb6ee76a8 (code +> > length 88) [testproj.exe] +> > converting method System.Text.Encoding:get_UTF8Unmarked () +> > Method System.Text.Encoding:get_UTF8Unmarked () emitted at 0xb6ee76a8 +> > to 0xb6ee792c (code length 644) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.Threading.Monitor:Enter (object) +> > Method (wrapper managed-to-native) System.Threading.Monitor:Enter +> > (object) emitted at 0xb6ee7950 to 0xb6ee7a8c (code length 316) +> > [testproj.exe] +> > converting method System.Text.UTF8Encoding:.ctor (bool,bool) +> > Method System.Text.UTF8Encoding:.ctor (bool,bool) emitted at +> > 0xb6ee7a90 to 0xb6ee7d94 (code length 772) [testproj.exe] +> > converting method System.Text.Encoding:.ctor (int) +> > Method System.Text.Encoding:.ctor (int) emitted at 0xb6ee7de0 to +> > 0xb6ee8258 (code length 1144) [testproj.exe] +> > converting method System.Text.DecoderFallback:get_StandardSafeFallback () +> > converting method System.Text.DecoderFallback:.cctor () +> > Method System.Text.DecoderFallback:.cctor () emitted at 0xb6ee8270 to +> > 0xb6ee83a0 (code length 304) [testproj.exe] +> > converting method System.Text.DecoderExceptionFallback:.ctor () +> > Method System.Text.DecoderExceptionFallback:.ctor () emitted at +> > 0xb6ee83c8 to 0xb6ee8448 (code length 128) [testproj.exe] +> > converting method System.Text.DecoderFallback:.ctor () +> > Method System.Text.DecoderFallback:.ctor () emitted at 0xb6ee8458 to +> > 0xb6ee84d4 (code length 124) [testproj.exe] +> > converting method System.Text.DecoderReplacementFallback:.ctor () +> > Method System.Text.DecoderReplacementFallback:.ctor () emitted at +> > 0xb6ee84d8 to 0xb6ee8560 (code length 136) [testproj.exe] +> > converting method System.Text.DecoderReplacementFallback:.ctor (string) +> > Method System.Text.DecoderReplacementFallback:.ctor (string) emitted +> > at 0xb6ee8560 to 0xb6ee866c (code length 268) [testproj.exe] +> > Method System.Text.DecoderFallback:get_StandardSafeFallback () emitted +> > at 0xb6ee8670 to 0xb6ee86ec (code length 124) [testproj.exe] +> > converting method System.Text.EncoderFallback:get_StandardSafeFallback () +> > converting method System.Text.EncoderFallback:.cctor () +> > Method System.Text.EncoderFallback:.cctor () emitted at 0xb6ee86f0 to +> > 0xb6ee8820 (code length 304) [testproj.exe] +> > converting method System.Text.EncoderExceptionFallback:.ctor () +> > Method System.Text.EncoderExceptionFallback:.ctor () emitted at +> > 0xb6ee8848 to 0xb6ee88c8 (code length 128) [testproj.exe] +> > converting method System.Text.EncoderFallback:.ctor () +> > Method System.Text.EncoderFallback:.ctor () emitted at 0xb6ee88d8 to +> > 0xb6ee8954 (code length 124) [testproj.exe] +> > converting method System.Text.EncoderReplacementFallback:.ctor () +> > Method System.Text.EncoderReplacementFallback:.ctor () emitted at +> > 0xb6ee8958 to 0xb6ee89e0 (code length 136) [testproj.exe] +> > converting method System.Text.EncoderReplacementFallback:.ctor (string) +> > Method System.Text.EncoderReplacementFallback:.ctor (string) emitted +> > at 0xb6ee89e0 to 0xb6ee8aec (code length 268) [testproj.exe] +> > Method System.Text.EncoderFallback:get_StandardSafeFallback () emitted +> > at 0xb6ee8af0 to 0xb6ee8b6c (code length 124) [testproj.exe] +> > converting method System.Text.Encoding:SetFallbackInternal +> > (System.Text.EncoderFallback,System.Text.DecoderFallback) +> > Method System.Text.Encoding:SetFallbackInternal +> > (System.Text.EncoderFallback,System.Text.DecoderFallback) emitted at +> > 0xb6ee8b70 to 0xb6ee8c80 (code length 272) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.Threading.Monitor:Exit (object) +> > Method (wrapper managed-to-native) System.Threading.Monitor:Exit +> > (object) emitted at 0xb6ee8c80 to 0xb6ee8dbc (code length 316) +> > [testproj.exe] +> > converting method System.Console:OpenStandardError (int) +> > Method System.Console:OpenStandardError (int) emitted at 0xb6ee8dc0 to +> > 0xb6ee8e48 (code length 136) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.IO.MonoIO:get_ConsoleError () +> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleError +> > () emitted at 0xb6ee8e60 to 0xb6ee8f50 (code length 240) +> > [testproj.exe] +> > converting method System.IO.MonoIO:.cctor () +> > Method System.IO.MonoIO:.cctor () emitted at 0xb6ee8f50 to 0xb6ee9010 +> > (code length 192) [testproj.exe] +> > converting method intptr:op_Explicit (long) +> > Method intptr:op_Explicit (long) emitted at 0xb6ee9020 to 0xb6ee90c0 +> > (code length 160) [testproj.exe] +> > converting method intptr:.ctor (long) +> > Method intptr:.ctor (long) emitted at 0xb6ee90d0 to 0xb6ee9160 (code +> > length 144) [testproj.exe] +> > converting method System.Console:Open (intptr,System.IO.FileAccess,int) +> > Method System.Console:Open (intptr,System.IO.FileAccess,int) emitted +> > at 0xb6ee9160 to 0xb6ee9354 (code length 500) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_specific (intptr) +> > Method (wrapper managed-to-native) +> > object:__icall_wrapper_mono_object_new_specific (intptr) emitted at +> > 0xb6ee9370 to 0xb6ee9468 (code length 248) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.FileStream:.ctor +> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +> > Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor +> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee9468 +> > to 0xb6ee9628 (code length 448) [testproj.exe] +> > converting method System.IO.FileStream:.cctor () +> > Method System.IO.FileStream:.cctor () emitted at 0xb6ee9640 to +> > 0xb6ee96d8 (code length 152) [testproj.exe] +> > converting method System.IO.FileStream:.ctor +> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +> > Method System.IO.FileStream:.ctor +> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee96e8 +> > to 0xb6ee9d74 (code length 1676) [testproj.exe] +> > converting method System.IO.Stream:.ctor () +> > Method System.IO.Stream:.ctor () emitted at 0xb6ee9dc8 to 0xb6ee9e48 +> > (code length 128) [testproj.exe] +> > converting method System.IO.Stream:.cctor () +> > Method System.IO.Stream:.cctor () emitted at 0xb6ee9e58 to 0xb6ee9efc +> > (code length 164) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.NullStream:.ctor () +> > Method (wrapper remoting-invoke-with-check) System.IO.NullStream:.ctor +> > () emitted at 0xb6ee9f00 to 0xb6ee9fd4 (code length 212) +> > [testproj.exe] +> > converting method System.IO.NullStream:.ctor () +> > Method System.IO.NullStream:.ctor () emitted at 0xb6ee9ff0 to +> > 0xb6eea070 (code length 128) [testproj.exe] +> > converting method System.MarshalByRefObject:.ctor () +> > Method System.MarshalByRefObject:.ctor () emitted at 0xb6eea070 to +> > 0xb6eea0ec (code length 124) [testproj.exe] +> > converting method intptr:op_Equality (intptr,intptr) +> > Method intptr:op_Equality (intptr,intptr) emitted at 0xb6eea0f0 to +> > 0xb6eea188 (code length 152) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.IO.MonoIO:GetFileType (intptr,System.IO.MonoIOError&) +> > Method (wrapper managed-to-native) System.IO.MonoIO:GetFileType +> > (intptr,System.IO.MonoIOError&) emitted at 0xb6eea188 to 0xb6eea288 +> > (code length 256) [testproj.exe] +> > converting method System.IO.FileStream:InitBuffer (int,bool) +> > Method System.IO.FileStream:InitBuffer (int,bool) emitted at +> > 0xb6eea288 to 0xb6eea72c (code length 1188) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.UnexceptionalStreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding) +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.UnexceptionalStreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea748 to +> > 0xb6eea844 (code length 252) [testproj.exe] +> > converting method System.IO.UnexceptionalStreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding) +> > Method System.IO.UnexceptionalStreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea860 to +> > 0xb6eea8f0 (code length 144) [testproj.exe] +> > converting method System.IO.StreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding) +> > Method System.IO.StreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea900 to +> > 0xb6eea994 (code length 148) [testproj.exe] +> > converting method System.IO.StreamWriter:.cctor () +> > Method System.IO.StreamWriter:.cctor () emitted at 0xb6eea9a0 to +> > 0xb6eeaa74 (code length 212) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.StreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding,int) +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.StreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaa80 to +> > 0xb6eeab98 (code length 280) [testproj.exe] +> > converting method System.IO.StreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding,int) +> > Method System.IO.StreamWriter:.ctor +> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaba8 to +> > 0xb6eeae54 (code length 684) [testproj.exe] +> > converting method System.IO.TextWriter:.ctor () +> > Method System.IO.TextWriter:.ctor () emitted at 0xb6eeae70 to +> > 0xb6eeaf34 (code length 196) [testproj.exe] +> > converting method System.IO.TextWriter:.cctor () +> > Method System.IO.TextWriter:.cctor () emitted at 0xb6eeaf50 to +> > 0xb6eeaff4 (code length 164) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.TextWriter/NullTextWriter:.ctor () +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.TextWriter/NullTextWriter:.ctor () emitted at 0xb6eeb000 to +> > 0xb6eeb0d4 (code length 212) [testproj.exe] +> > converting method System.IO.TextWriter/NullTextWriter:.ctor () +> > Method System.IO.TextWriter/NullTextWriter:.ctor () emitted at +> > 0xb6eeb0f0 to 0xb6eeb170 (code length 128) [testproj.exe] +> > converting method System.Environment:get_NewLine () +> > Method System.Environment:get_NewLine () emitted at 0xb6eeb170 to +> > 0xb6eeb2a8 (code length 312) [testproj.exe] +> > converting method (wrapper managed-to-native) +> System.Environment:GetNewLine () +> > Method (wrapper managed-to-native) System.Environment:GetNewLine () +> > emitted at 0xb6eeb2b8 to 0xb6eeb3a8 (code length 240) [testproj.exe] +> > converting method string:ToCharArray () +> > Method string:ToCharArray () emitted at 0xb6eeb3a8 to 0xb6eeb434 (code +> > length 140) [testproj.exe] +> > converting method string:.cctor () +> > Method string:.cctor () emitted at 0xb6eeb440 to 0xb6eeb554 (code +> > length 276) [testproj.exe] +> > converting method (wrapper managed-to-native) string:GetLOSLimit () +> > Method (wrapper managed-to-native) string:GetLOSLimit () emitted at +> > 0xb6eeb570 to 0xb6eeb660 (code length 240) [testproj.exe] +> > converting method string:memcpy (byte*,byte*,int) +> > Method string:memcpy (byte*,byte*,int) emitted at 0xb6eeb660 to +> > 0xb6eebac8 (code length 1128) [testproj.exe] +> > converting method string:memcpy4 (byte*,byte*,int) +> > Method string:memcpy4 (byte*,byte*,int) emitted at 0xb6eebaf0 to +> > 0xb6eebf10 (code length 1056) [testproj.exe] +> > converting method string:ToCharArray (int,int) +> > Method string:ToCharArray (int,int) emitted at 0xb6eebf10 to +> > 0xb6eec32c (code length 1052) [testproj.exe] +> > converting method string:CharCopy (char*,char*,int) +> > Method string:CharCopy (char*,char*,int) emitted at 0xb6eec338 to +> > 0xb6eec5d8 (code length 672) [testproj.exe] +> > converting method System.IO.NullStream:get_CanWrite () +> > Method System.IO.NullStream:get_CanWrite () emitted at 0xb6eec5d8 to +> > 0xb6eec654 (code length 124) [testproj.exe] +> > converting method System.IO.StreamWriter:Initialize +> (System.Text.Encoding,int) +> > Method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +> > emitted at 0xb6eec658 to 0xb6eec8f4 (code length 668) [testproj.exe] +> > converting method System.Math:Max (int,int) +> > Method System.Math:Max (int,int) emitted at 0xb6eec8f8 to 0xb6eec9dc +> > (code length 228) [testproj.exe] +> > converting method System.Text.UTF8Encoding:GetMaxByteCount (int) +> > Method System.Text.UTF8Encoding:GetMaxByteCount (int) emitted at +> > 0xb6eec9e0 to 0xb6eecaec (code length 268) [testproj.exe] +> > converting method System.IO.NullStream:get_CanSeek () +> > Method System.IO.NullStream:get_CanSeek () emitted at 0xb6eecaf8 to +> > 0xb6eecb74 (code length 124) [testproj.exe] +> > converting method System.IO.NullStream:get_Position () +> > Method System.IO.NullStream:get_Position () emitted at 0xb6eecb78 to +> > 0xb6eecbf8 (code length 128) [testproj.exe] +> > converting method System.IO.FileStream:get_CanWrite () +> > Method System.IO.FileStream:get_CanWrite () emitted at 0xb6eecbf8 to +> > 0xb6eeccf0 (code length 248) [testproj.exe] +> > converting method System.IO.FileStream:get_CanSeek () +> > Method System.IO.FileStream:get_CanSeek () emitted at 0xb6eeccf0 to +> > 0xb6eecd70 (code length 128) [testproj.exe] +> > converting method System.IO.StreamWriter:set_AutoFlush (bool) +> > Method System.IO.StreamWriter:set_AutoFlush (bool) emitted at +> > 0xb6eecd70 to 0xb6eece5c (code length 236) [testproj.exe] +> > converting method System.IO.UnexceptionalStreamWriter:Flush () +> > Method System.IO.UnexceptionalStreamWriter:Flush () emitted at +> > 0xb6eece60 to 0xb6eecf4c (code length 236) [testproj.exe] +> > converting method System.IO.StreamWriter:Flush () +> > Method System.IO.StreamWriter:Flush () emitted at 0xb6eecf58 to +> > 0xb6eed0dc (code length 388) [testproj.exe] +> > converting method System.IO.StreamWriter:Decode () +> > Method System.IO.StreamWriter:Decode () emitted at 0xb6eed0f8 to +> > 0xb6eed308 (code length 528) [testproj.exe] +> > converting method System.IO.TextWriter:Synchronized +> (System.IO.TextWriter,bool) +> > Method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +> > emitted at 0xb6eed320 to 0xb6eed5c0 (code length 672) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) emitted +> > at 0xb6eed5d8 to 0xb6eed6d4 (code length 252) [testproj.exe] +> > converting method System.IO.SynchronizedWriter:.ctor +> (System.IO.TextWriter,bool) +> > Method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +> > emitted at 0xb6eed6f0 to 0xb6eed7d0 (code length 224) [testproj.exe] +> > converting method System.ConsoleDriver:get_IsConsole () +> > Method System.ConsoleDriver:get_IsConsole () emitted at 0xb6eed7d0 to +> > 0xb6eed9b0 (code length 480) [testproj.exe] +> > converting method System.ConsoleDriver:.cctor () +> > Method System.ConsoleDriver:.cctor () emitted at 0xb6eed9e0 to +> > 0xb6eedc6c (code length 652) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.IO.MonoIO:get_ConsoleOutput () +> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleOutput +> > () emitted at 0xb6eedca8 to 0xb6eedd98 (code length 240) +> > [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.ConsoleDriver:Isatty (intptr) +> > Method (wrapper managed-to-native) System.ConsoleDriver:Isatty +> > (intptr) emitted at 0xb6eedd98 to 0xb6eede90 (code length 248) +> > [testproj.exe] +> > converting method System.ConsoleDriver:CreateNullConsoleDriver () +> > Method System.ConsoleDriver:CreateNullConsoleDriver () emitted at +> > 0xb6eede90 to 0xb6eedf1c (code length 140) [testproj.exe] +> > converting method System.NullConsoleDriver:.ctor () +> > Method System.NullConsoleDriver:.ctor () emitted at 0xb6eedf28 to +> > 0xb6eedfa4 (code length 124) [testproj.exe] +> > converting method System.Console:OpenStandardOutput (int) +> > Method System.Console:OpenStandardOutput (int) emitted at 0xb6eedfa8 +> > to 0xb6eee030 (code length 136) [testproj.exe] +> > converting method System.Console:OpenStandardInput (int) +> > Method System.Console:OpenStandardInput (int) emitted at 0xb6eee030 to +> > 0xb6eee0b8 (code length 136) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.IO.MonoIO:get_ConsoleInput () +> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleInput +> > () emitted at 0xb6eee0b8 to 0xb6eee1a8 (code length 240) +> > [testproj.exe] +> > converting method System.IO.UnexceptionalStreamReader:.cctor () +> > Method System.IO.UnexceptionalStreamReader:.cctor () emitted at +> > 0xb6eee1a8 to 0xb6eee300 (code length 344) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.UnexceptionalStreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding) +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.UnexceptionalStreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee300 to +> > 0xb6eee3fc (code length 252) [testproj.exe] +> > converting method System.IO.UnexceptionalStreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding) +> > Method System.IO.UnexceptionalStreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee418 to +> > 0xb6eee4a8 (code length 144) [testproj.exe] +> > converting method System.IO.StreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding) +> > Method System.IO.StreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee4b8 to +> > 0xb6eee554 (code length 156) [testproj.exe] +> > converting method System.IO.StreamReader:.cctor () +> > Method System.IO.StreamReader:.cctor () emitted at 0xb6eee560 to +> > 0xb6eee648 (code length 232) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.StreamReader/NullStreamReader:.ctor () +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.StreamReader/NullStreamReader:.ctor () emitted at 0xb6eee658 +> > to 0xb6eee72c (code length 212) [testproj.exe] +> > converting method System.IO.StreamReader/NullStreamReader:.ctor () +> > Method System.IO.StreamReader/NullStreamReader:.ctor () emitted at +> > 0xb6eee748 to 0xb6eee7c8 (code length 128) [testproj.exe] +> > converting method System.IO.StreamReader:.ctor () +> > Method System.IO.StreamReader:.ctor () emitted at 0xb6eee7d8 to +> > 0xb6eee858 (code length 128) [testproj.exe] +> > converting method System.IO.TextReader:.ctor () +> > Method System.IO.TextReader:.ctor () emitted at 0xb6eee868 to +> > 0xb6eee8e8 (code length 128) [testproj.exe] +> > converting method System.IO.TextReader:.cctor () +> > Method System.IO.TextReader:.cctor () emitted at 0xb6eee8e8 to +> > 0xb6eee98c (code length 164) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.TextReader/NullTextReader:.ctor () +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.TextReader/NullTextReader:.ctor () emitted at 0xb6eee998 to +> > 0xb6eeea6c (code length 212) [testproj.exe] +> > converting method System.IO.TextReader/NullTextReader:.ctor () +> > Method System.IO.TextReader/NullTextReader:.ctor () emitted at +> > 0xb6eeea88 to 0xb6eeeb08 (code length 128) [testproj.exe] +> > converting method System.IO.StreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding,bool,int) +> > Method System.IO.StreamReader:.ctor +> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeeb08 +> > to 0xb6eeebd8 (code length 208) [testproj.exe] +> > converting method System.IO.StreamReader:Initialize +> > (System.IO.Stream,System.Text.Encoding,bool,int) +> > Method System.IO.StreamReader:Initialize +> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeebe8 +> > to 0xb6eef5b8 (code length 2512) [testproj.exe] +> > converting method System.IO.FileStream:get_CanRead () +> > Method System.IO.FileStream:get_CanRead () emitted at 0xb6eef5b8 to +> > 0xb6eef6b0 (code length 248) [testproj.exe] +> > converting method System.Text.UTF8Encoding:GetMaxCharCount (int) +> > Method System.Text.UTF8Encoding:GetMaxCharCount (int) emitted at +> > 0xb6eef6b0 to 0xb6eef7b8 (code length 264) [testproj.exe] +> > converting method System.Text.UTF8Encoding:GetDecoder () +> > Method System.Text.UTF8Encoding:GetDecoder () emitted at 0xb6eef7b8 to +> > 0xb6eef858 (code length 160) [testproj.exe] +> > converting method System.Text.Encoding:get_DecoderFallback () +> > Method System.Text.Encoding:get_DecoderFallback () emitted at +> > 0xb6eef870 to 0xb6eef8f0 (code length 128) [testproj.exe] +> > converting method System.Text.UTF8Encoding/UTF8Decoder:.ctor +> > (System.Text.DecoderFallback) +> > Method System.Text.UTF8Encoding/UTF8Decoder:.ctor +> > (System.Text.DecoderFallback) emitted at 0xb6eef8f0 to 0xb6eef9f8 +> > (code length 264) [testproj.exe] +> > converting method System.Text.Decoder:.ctor () +> > Method System.Text.Decoder:.ctor () emitted at 0xb6eefa10 to +> > 0xb6eefad4 (code length 196) [testproj.exe] +> > converting method System.Text.Decoder:set_Fallback +> (System.Text.DecoderFallback) +> > Method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +> > emitted at 0xb6eefad8 to 0xb6eefbe8 (code length 272) [testproj.exe] +> > converting method System.Text.UTF8Encoding:GetPreamble () +> > Method System.Text.UTF8Encoding:GetPreamble () emitted at 0xb6eefbe8 +> > to 0xb6eefd10 (code length 296) [testproj.exe] +> > converting method (wrapper stfld) +> > object:__stfld_wrapper_0x34ee68_System.Int32 +> > (object,intptr,intptr,intptr,int) +> > Method (wrapper stfld) object:__stfld_wrapper_0x34ee68_System.Int32 +> > (object,intptr,intptr,intptr,int) emitted at 0xb6eefd10 to 0xb6eefe7c +> > (code length 364) [testproj.exe] +> > converting method (wrapper ldfld) +> > object:__ldfld_wrapper_0x34ee68_System.Int32 +> > (object,intptr,intptr,intptr) +> > Method (wrapper ldfld) object:__ldfld_wrapper_0x34ee68_System.Int32 +> > (object,intptr,intptr,intptr) emitted at 0xb6eefe88 to 0xb6eeffd8 +> > (code length 336) [testproj.exe] +> > converting method System.IO.TextReader:Synchronized +> (System.IO.TextReader) +> > Method System.IO.TextReader:Synchronized (System.IO.TextReader) +> > emitted at 0xb6eeffe8 to 0xb6ef0278 (code length 656) [testproj.exe] +> > converting method (wrapper remoting-invoke-with-check) +> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +> > Method (wrapper remoting-invoke-with-check) +> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) emitted at +> > 0xb6ef0290 to 0xb6ef0378 (code length 232) [testproj.exe] +> > converting method System.IO.SynchronizedReader:.ctor +> (System.IO.TextReader) +> > Method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +> > emitted at 0xb6ef0390 to 0xb6ef0440 (code length 176) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.GC:SuppressFinalize (object) +> > Method (wrapper managed-to-native) System.GC:SuppressFinalize (object) +> > emitted at 0xb6ef0440 to 0xb6ef057c (code length 316) [testproj.exe] +> > converting method System.IO.SynchronizedWriter:WriteLine (string) +> > Method System.IO.SynchronizedWriter:WriteLine (string) emitted at +> > 0xb6ef0580 to 0xb6ef06ec (code length 364) [testproj.exe] +> > converting method System.IO.TextWriter:WriteLine (string) +> > Method System.IO.TextWriter:WriteLine (string) emitted at 0xb6ef06f0 +> > to 0xb6ef07b8 (code length 200) [testproj.exe] +> > converting method System.IO.UnexceptionalStreamWriter:Write (string) +> > Method System.IO.UnexceptionalStreamWriter:Write (string) emitted at +> > 0xb6ef07b8 to 0xb6ef08ac (code length 244) [testproj.exe] +> > converting method System.IO.StreamWriter:Write (string) +> > Method System.IO.StreamWriter:Write (string) emitted at 0xb6ef08b8 to +> > 0xb6ef0a40 (code length 392) [testproj.exe] +> > converting method System.IO.StreamWriter:LowLevelWrite (string) +> > Method System.IO.StreamWriter:LowLevelWrite (string) emitted at +> > 0xb6ef0a50 to 0xb6ef0e94 (code length 1092) [testproj.exe] +> > converting method System.Text.UTF8Encoding:GetBytes +> (char[],int,int,byte[],int) +> > Method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +> > emitted at 0xb6ef0e98 to 0xb6ef1010 (code length 376) [testproj.exe] +> > converting method System.Text.Encoding:get_EncoderFallback () +> > Method System.Text.Encoding:get_EncoderFallback () emitted at +> > 0xb6ef1028 to 0xb6ef10a8 (code length 128) [testproj.exe] +> > converting method System.Text.UTF8Encoding:InternalGetBytes +> > +> (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> > Method System.Text.UTF8Encoding:InternalGetBytes +> > +> (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> > emitted at 0xb6ef10a8 to 0xb6ef1878 (code length 2000) [testproj.exe] +> > converting method System.Text.UTF8Encoding:InternalGetBytes +> > +> (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> > Method System.Text.UTF8Encoding:InternalGetBytes +> > +> (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +> > emitted at 0xb645a000 to 0xb645b31c (code length 4892) [testproj.exe] +> > converting method System.IO.StreamWriter:FlushBytes () +> > Method System.IO.StreamWriter:FlushBytes () emitted at 0xb645b338 to +> > 0xb645b558 (code length 544) [testproj.exe] +> > converting method System.IO.FileStream:Write (byte[],int,int) +> > Method System.IO.FileStream:Write (byte[],int,int) emitted at +> > 0xb645b558 to 0xb645b9cc (code length 1140) [testproj.exe] +> > converting method System.IO.FileStream:WriteInternal (byte[],int,int) +> > Method System.IO.FileStream:WriteInternal (byte[],int,int) emitted at +> > 0xb645b9d8 to 0xb645bed0 (code length 1272) [testproj.exe] +> > converting method System.IO.FileStream:FlushBuffer () +> > Method System.IO.FileStream:FlushBuffer () emitted at 0xb645bf18 to +> > 0xb645bf9c (code length 132) [testproj.exe] +> > converting method System.IO.FileStream:FlushBuffer (System.IO.Stream) +> > Method System.IO.FileStream:FlushBuffer (System.IO.Stream) emitted at +> > 0xb645bfa8 to 0xb645c4fc (code length 1364) [testproj.exe] +> > converting method (wrapper ldfld) +> > object:__ldfld_wrapper_0x350250_System.Int64 +> > (object,intptr,intptr,intptr) +> > Method (wrapper ldfld) object:__ldfld_wrapper_0x350250_System.Int64 +> > (object,intptr,intptr,intptr) emitted at 0xb645c500 to 0xb645c654 +> > (code length 340) [testproj.exe] +> > coStarted +> > nverting method (wrapper stfld) +> > object:__stfld_wrapper_0x350250_System.Int64 +> > (object,intptr,intptr,intptr,long) +> > Method (wrapper stfld) object:__stfld_wrapper_0x350250_System.Int64 +> > (object,intptr,intptr,intptr,long) emitted at 0xb645c658 to 0xb645c7e4 +> > (code length 396) [testproj.exe] +> > converting method (wrapper managed-to-native) System.IO.MonoIO:Write +> > (intptr,byte[],int,int,System.IO.MonoIOError&) +> > Method (wrapper managed-to-native) System.IO.MonoIO:Write +> > (intptr,byte[],int,int,System.IO.MonoIOError&) emitted at 0xb645c7e8 +> > to 0xb645c918 (code length 304) [testproj.exe] +> > converting method System.IO.FileStream:Flush () +> > Method System.IO.FileStream:Flush () emitted at 0xb645c918 to +> > 0xb645ca18 (code length 256) [testproj.exe] +> > converting method System.IO.TextWriter:WriteLine () +> > Method System.IO.TextWriter:WriteLine () emitted at 0xb645ca18 to +> > 0xb645caac (code length 148) [testproj.exe] +> > converting method System.IO.UnexceptionalStreamWriter:Write (char[]) +> > Method System.IO.UnexceptionalStreamWriter:Write (char[]) emitted at +> > 0xb645cab0 to 0xb645cba4 (code length 244) [testproj.exe] +> > converting method System.IO.StreamWriter:Write (char[]) +> > Method System.IO.StreamWriter:Write (char[]) emitted at 0xb645cbb0 to +> > 0xb645cd44 (code length 404) [testproj.exe] +> > converting method System.IO.StreamWriter:LowLevelWrite (char[],int,int) +> > Method System.IO.StreamWriter:LowLevelWrite (char[],int,int) emitted +> > at 0xb645cd50 to 0xb645d04c (code length 764) [testproj.exe] +> > converting method System.Buffer:BlockCopy +> > (System.Array,int,System.Array,int,int) +> > Method System.Buffer:BlockCopy (System.Array,int,System.Array,int,int) +> > emitted at 0xb645d058 to 0xb645d458 (code length 1024) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.Buffer:BlockCopyInternal +> > (System.Array,int,System.Array,int,int) +> > Method (wrapper managed-to-native) System.Buffer:BlockCopyInternal +> > (System.Array,int,System.Array,int,int) emitted at 0xb645d470 to +> > 0xb645d5a0 (code length 304) [testproj.exe] +> > converting method System.ExecutionEngineException:.ctor () +> > Method System.ExecutionEngineException:.ctor () emitted at 0xb645d5a0 +> > to 0xb645d638 (code length 152) [testproj.exe] +> > converting method (wrapper runtime-invoke) +> > object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) +> > Method (wrapper runtime-invoke) object:runtime_invoke_void__this__ +> > (object,intptr,intptr,intptr) emitted at 0xb645d638 to 0xb645d90c +> > (code length 724) [testproj.exe] +> > converting method Locale:GetText (string) +> > Method Locale:GetText (string) emitted at 0xb645d910 to 0xb645d98c +> > (code length 124) [testproj.exe] +> > converting method System.Exception:ToString () +> > Method System.Exception:ToString () emitted at 0xb645d990 to +> > 0xb645dd04 (code length 884) [testproj.exe] +> > converting method (wrapper runtime-invoke) +> > <Module>:runtime_invoke_object__this__ (object,intptr,intptr,intptr) +> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_object__this__ +> > (object,intptr,intptr,intptr) emitted at 0xb645dd28 to 0xb645e004 +> > (code length 732) [testproj.exe] +> > converting method System.Exception:get_ClassName () +> > Method System.Exception:get_ClassName () emitted at 0xb645e008 to +> > 0xb645e104 (code length 252) [testproj.exe] +> > converting method System.Exception:GetType () +> > Method System.Exception:GetType () emitted at 0xb645e110 to 0xb645e194 +> > (code length 132) [testproj.exe] +> > converting method System.MonoType:ToString () +> > Method System.MonoType:ToString () emitted at 0xb645e198 to 0xb645e220 +> > (code length 136) [testproj.exe] +> > converting method (wrapper managed-to-native) +> > System.MonoType:getFullName (System.MonoType,bool,bool) +> > Method (wrapper managed-to-native) System.MonoType:getFullName +> > (System.MonoType,bool,bool) emitted at 0xb645e230 to 0xb645e394 (code +> > length 356) [testproj.exe] +> > converting method System.Text.StringBuilder:.ctor (string) +> > Method System.Text.StringBuilder:.ctor (string) emitted at 0xb645e398 +> > to 0xb645e520 (code length 392) [testproj.exe] +> > converting method System.Text.StringBuilder:Append (string) +> > Method System.Text.StringBuilder:Append (string) emitted at 0xb645e520 +> > to 0xb645e8c4 (code length 932) [testproj.exe] +> > converting method +> > Unhandled Exception: System.ExecutionEngineException: SIGILL +> > [ERROR] FATAL UNHANDLED EXCEPTION: System.ExecutionEngineException: +> SIGILL +> > +> > +> > What can i do? +> > +> > +> > thanks Peter +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120207/88d1217f/attachment-0001.html> ++ + + +
Unlikely, looks like an illegal instruction, so probably a JIT issue. +Maybe a bad Mono build or revision. + +The reason you have OutOfMemoryException appearing in the traces is +that Mono creates that exception at startup, in case it's ever needed, +since it won't be possible to create it if the program actually runs +out of memory. + +2012/2/7 Jeff Stedfast <jeff at xamarin.com>: +> Hi Peter, +> +> Looks like you are running out of memory for some reason. Beyond that, I +> have no idea. +> +> Jeff +> +> +> On Tue, Feb 7, 2012 at 4:09 PM, Peter Siegel <siegelpeter2009 at gmail.com> +> wrote: +>> +>> Hi! +>> +>> I'm just wondering? Is there who knows about debugging with SDB on +>> ARM? the Meego Addin should have been able to do this, and the Mono +>> for the Iphone also uses the SDB to debug so i expected it to work. +>> I'm willing to investigate this issue on my own, but any help would be +>> really appreciated. +>> +>> thanks +>> +>> Peter +>> +>> Am 29. Januar 2012 15:18 schrieb Peter Siegel <siegelpeter2009 at gmail.com>: +>> > Hi! +>> > +>> > I tried to do single step debugging using the mono sdb with +>> > monodevelop remotely on an arm target... +>> > I modified the Meego addin to be able to debug remotely on any Linux +>> > System. It's an Linux Remote Debugging addin now :-) +>> > +>> > It works very well on the same cpu architecture. Now I can debug my +>> > Linux Mono Programs from windows, but some debuging features do not +>> > work if the remote target is an Arm Plattform. +>> > +>> > It connects without an exception and the Programm starts, when the +>> > remote program throws an exception, the exception caught window opens +>> > with no information at all and instance is "evaluating". On the +>> > Remote Arm box, the Mono process has stopped +>> > +>> > When i insert an breakpoint the Program seems to pauses, but when i +>> > press continue it crashes: +>> > +>> > Loaded assembly: /root/test/testproj.exe +>> > Resolved pending breakpoint at +>> > 'C:\Users\PeterS\Documents\testproj\testproj\Main.cs:11' to Void +>> > testproj.MainClass:Main (String[]) [0x00011]. +>> > converting method System.OutOfMemoryException:.ctor (string) +>> > Method System.OutOfMemoryException:.ctor (string) emitted at +>> > 0xb6ee4b68 to 0xb6ee4c20 (code length 184) [testproj.exe] +>> > converting method (wrapper runtime-invoke) +>> > <Module>:runtime_invoke_void__this___object +>> > (object,intptr,intptr,intptr) +>> > Method (wrapper runtime-invoke) +>> > <Module>:runtime_invoke_void__this___object +>> > (object,intptr,intptr,intptr) emitted at 0xb6ee4c48 to 0xb6ee4f2c +>> > (code length 740) [testproj.exe] +>> > converting method System.SystemException:.ctor (string) +>> > Method System.SystemException:.ctor (string) emitted at 0xb6ee4f30 to +>> > 0xb6ee4fe8 (code length 184) [testproj.exe] +>> > converting method System.Exception:.ctor (string) +>> > Method System.Exception:.ctor (string) emitted at 0xb6ee4ff8 to +>> > 0xb6ee50d4 (code length 220) [testproj.exe] +>> > converting method System.Exception:set_HResult (int) +>> > Method System.Exception:set_HResult (int) emitted at 0xb6ee50d8 to +>> > 0xb6ee5160 (code length 136) [testproj.exe] +>> > converting method System.NullReferenceException:.ctor (string) +>> > Method System.NullReferenceException:.ctor (string) emitted at +>> > 0xb6ee5160 to 0xb6ee5218 (code length 184) [testproj.exe] +>> > converting method System.StackOverflowException:.ctor (string) +>> > Method System.StackOverflowException:.ctor (string) emitted at +>> > 0xb6ee5218 to 0xb6ee52a0 (code length 136) [testproj.exe] +>> > converting method testproj.MainClass:Main (string[]) +>> > Method testproj.MainClass:Main (string[]) emitted at 0xb6ee52b0 to +>> > 0xb6ee5490 (code length 480) [testproj.exe] +>> > converting method (wrapper runtime-invoke) +>> > <Module>:runtime_invoke_void_object (object,intptr,intptr,intptr) +>> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_void_object +>> > (object,intptr,intptr,intptr) emitted at 0xb6ee54b8 to 0xb6ee5794 +>> > (code length 732) [testproj.exe] +>> > converting method System.Console:WriteLine (string) +>> > Method System.Console:WriteLine (string) emitted at 0xb6ee5798 to +>> > 0xb6ee5834 (code length 156) [testproj.exe] +>> > converting method System.Console:.cctor () +>> > Method System.Console:.cctor () emitted at 0xb6ee5870 to 0xb6ee6358 +>> > (code length 2792) [testproj.exe] +>> > converting method (wrapper runtime-invoke) object:runtime_invoke_void +>> > (object,intptr,intptr,intptr) +>> > Method (wrapper runtime-invoke) object:runtime_invoke_void +>> > (object,intptr,intptr,intptr) emitted at 0xb6ee6440 to 0xb6ee670c +>> > (code length 716) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_fast (intptr) +>> > Method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_fast (intptr) emitted at +>> > 0xb6ee6718 to 0xb6ee6810 (code length 248) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.Text.Encoding:InternalCodePage (int&) +>> > Method (wrapper managed-to-native) +>> > System.Text.Encoding:InternalCodePage (int&) emitted at 0xb6ee6810 to +>> > 0xb6ee6908 (code length 248) [testproj.exe] +>> > converting method System.Text.Encoding:.cctor () +>> > Method System.Text.Encoding:.cctor () emitted at 0xb6ee6920 to +>> > 0xb6ee7298 (code length 2424) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_array_new_specific (intptr,int) +>> > Method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_array_new_specific (intptr,int) emitted at +>> > 0xb6ee72a8 to 0xb6ee73a8 (code length 256) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) +>> > Method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) emitted at +>> > 0xb6ee73a8 to 0xb6ee74a0 (code length 248) [testproj.exe] +>> > converting method (wrapper stelemref) object:virt_stelemref_object +>> > (intptr,object) +>> > Method (wrapper stelemref) object:virt_stelemref_object +>> > (intptr,object) emitted at 0xb6ee74a0 to 0xb6ee7558 (code length 184) +>> > [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) +>> > Method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) emitted at +>> > 0xb6ee7558 to 0xb6ee7650 (code length 248) [testproj.exe] +>> > converting method object:.ctor () +>> > Method object:.ctor () emitted at 0xb6ee7650 to 0xb6ee76a8 (code +>> > length 88) [testproj.exe] +>> > converting method System.Text.Encoding:get_UTF8Unmarked () +>> > Method System.Text.Encoding:get_UTF8Unmarked () emitted at 0xb6ee76a8 +>> > to 0xb6ee792c (code length 644) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.Threading.Monitor:Enter (object) +>> > Method (wrapper managed-to-native) System.Threading.Monitor:Enter +>> > (object) emitted at 0xb6ee7950 to 0xb6ee7a8c (code length 316) +>> > [testproj.exe] +>> > converting method System.Text.UTF8Encoding:.ctor (bool,bool) +>> > Method System.Text.UTF8Encoding:.ctor (bool,bool) emitted at +>> > 0xb6ee7a90 to 0xb6ee7d94 (code length 772) [testproj.exe] +>> > converting method System.Text.Encoding:.ctor (int) +>> > Method System.Text.Encoding:.ctor (int) emitted at 0xb6ee7de0 to +>> > 0xb6ee8258 (code length 1144) [testproj.exe] +>> > converting method System.Text.DecoderFallback:get_StandardSafeFallback +>> > () +>> > converting method System.Text.DecoderFallback:.cctor () +>> > Method System.Text.DecoderFallback:.cctor () emitted at 0xb6ee8270 to +>> > 0xb6ee83a0 (code length 304) [testproj.exe] +>> > converting method System.Text.DecoderExceptionFallback:.ctor () +>> > Method System.Text.DecoderExceptionFallback:.ctor () emitted at +>> > 0xb6ee83c8 to 0xb6ee8448 (code length 128) [testproj.exe] +>> > converting method System.Text.DecoderFallback:.ctor () +>> > Method System.Text.DecoderFallback:.ctor () emitted at 0xb6ee8458 to +>> > 0xb6ee84d4 (code length 124) [testproj.exe] +>> > converting method System.Text.DecoderReplacementFallback:.ctor () +>> > Method System.Text.DecoderReplacementFallback:.ctor () emitted at +>> > 0xb6ee84d8 to 0xb6ee8560 (code length 136) [testproj.exe] +>> > converting method System.Text.DecoderReplacementFallback:.ctor (string) +>> > Method System.Text.DecoderReplacementFallback:.ctor (string) emitted +>> > at 0xb6ee8560 to 0xb6ee866c (code length 268) [testproj.exe] +>> > Method System.Text.DecoderFallback:get_StandardSafeFallback () emitted +>> > at 0xb6ee8670 to 0xb6ee86ec (code length 124) [testproj.exe] +>> > converting method System.Text.EncoderFallback:get_StandardSafeFallback +>> > () +>> > converting method System.Text.EncoderFallback:.cctor () +>> > Method System.Text.EncoderFallback:.cctor () emitted at 0xb6ee86f0 to +>> > 0xb6ee8820 (code length 304) [testproj.exe] +>> > converting method System.Text.EncoderExceptionFallback:.ctor () +>> > Method System.Text.EncoderExceptionFallback:.ctor () emitted at +>> > 0xb6ee8848 to 0xb6ee88c8 (code length 128) [testproj.exe] +>> > converting method System.Text.EncoderFallback:.ctor () +>> > Method System.Text.EncoderFallback:.ctor () emitted at 0xb6ee88d8 to +>> > 0xb6ee8954 (code length 124) [testproj.exe] +>> > converting method System.Text.EncoderReplacementFallback:.ctor () +>> > Method System.Text.EncoderReplacementFallback:.ctor () emitted at +>> > 0xb6ee8958 to 0xb6ee89e0 (code length 136) [testproj.exe] +>> > converting method System.Text.EncoderReplacementFallback:.ctor (string) +>> > Method System.Text.EncoderReplacementFallback:.ctor (string) emitted +>> > at 0xb6ee89e0 to 0xb6ee8aec (code length 268) [testproj.exe] +>> > Method System.Text.EncoderFallback:get_StandardSafeFallback () emitted +>> > at 0xb6ee8af0 to 0xb6ee8b6c (code length 124) [testproj.exe] +>> > converting method System.Text.Encoding:SetFallbackInternal +>> > (System.Text.EncoderFallback,System.Text.DecoderFallback) +>> > Method System.Text.Encoding:SetFallbackInternal +>> > (System.Text.EncoderFallback,System.Text.DecoderFallback) emitted at +>> > 0xb6ee8b70 to 0xb6ee8c80 (code length 272) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.Threading.Monitor:Exit (object) +>> > Method (wrapper managed-to-native) System.Threading.Monitor:Exit +>> > (object) emitted at 0xb6ee8c80 to 0xb6ee8dbc (code length 316) +>> > [testproj.exe] +>> > converting method System.Console:OpenStandardError (int) +>> > Method System.Console:OpenStandardError (int) emitted at 0xb6ee8dc0 to +>> > 0xb6ee8e48 (code length 136) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.IO.MonoIO:get_ConsoleError () +>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleError +>> > () emitted at 0xb6ee8e60 to 0xb6ee8f50 (code length 240) +>> > [testproj.exe] +>> > converting method System.IO.MonoIO:.cctor () +>> > Method System.IO.MonoIO:.cctor () emitted at 0xb6ee8f50 to 0xb6ee9010 +>> > (code length 192) [testproj.exe] +>> > converting method intptr:op_Explicit (long) +>> > Method intptr:op_Explicit (long) emitted at 0xb6ee9020 to 0xb6ee90c0 +>> > (code length 160) [testproj.exe] +>> > converting method intptr:.ctor (long) +>> > Method intptr:.ctor (long) emitted at 0xb6ee90d0 to 0xb6ee9160 (code +>> > length 144) [testproj.exe] +>> > converting method System.Console:Open (intptr,System.IO.FileAccess,int) +>> > Method System.Console:Open (intptr,System.IO.FileAccess,int) emitted +>> > at 0xb6ee9160 to 0xb6ee9354 (code length 500) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_specific (intptr) +>> > Method (wrapper managed-to-native) +>> > object:__icall_wrapper_mono_object_new_specific (intptr) emitted at +>> > 0xb6ee9370 to 0xb6ee9468 (code length 248) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.FileStream:.ctor +>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +>> > Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor +>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee9468 +>> > to 0xb6ee9628 (code length 448) [testproj.exe] +>> > converting method System.IO.FileStream:.cctor () +>> > Method System.IO.FileStream:.cctor () emitted at 0xb6ee9640 to +>> > 0xb6ee96d8 (code length 152) [testproj.exe] +>> > converting method System.IO.FileStream:.ctor +>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +>> > Method System.IO.FileStream:.ctor +>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee96e8 +>> > to 0xb6ee9d74 (code length 1676) [testproj.exe] +>> > converting method System.IO.Stream:.ctor () +>> > Method System.IO.Stream:.ctor () emitted at 0xb6ee9dc8 to 0xb6ee9e48 +>> > (code length 128) [testproj.exe] +>> > converting method System.IO.Stream:.cctor () +>> > Method System.IO.Stream:.cctor () emitted at 0xb6ee9e58 to 0xb6ee9efc +>> > (code length 164) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.NullStream:.ctor () +>> > Method (wrapper remoting-invoke-with-check) System.IO.NullStream:.ctor +>> > () emitted at 0xb6ee9f00 to 0xb6ee9fd4 (code length 212) +>> > [testproj.exe] +>> > converting method System.IO.NullStream:.ctor () +>> > Method System.IO.NullStream:.ctor () emitted at 0xb6ee9ff0 to +>> > 0xb6eea070 (code length 128) [testproj.exe] +>> > converting method System.MarshalByRefObject:.ctor () +>> > Method System.MarshalByRefObject:.ctor () emitted at 0xb6eea070 to +>> > 0xb6eea0ec (code length 124) [testproj.exe] +>> > converting method intptr:op_Equality (intptr,intptr) +>> > Method intptr:op_Equality (intptr,intptr) emitted at 0xb6eea0f0 to +>> > 0xb6eea188 (code length 152) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.IO.MonoIO:GetFileType (intptr,System.IO.MonoIOError&) +>> > Method (wrapper managed-to-native) System.IO.MonoIO:GetFileType +>> > (intptr,System.IO.MonoIOError&) emitted at 0xb6eea188 to 0xb6eea288 +>> > (code length 256) [testproj.exe] +>> > converting method System.IO.FileStream:InitBuffer (int,bool) +>> > Method System.IO.FileStream:InitBuffer (int,bool) emitted at +>> > 0xb6eea288 to 0xb6eea72c (code length 1188) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.UnexceptionalStreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding) +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.UnexceptionalStreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea748 to +>> > 0xb6eea844 (code length 252) [testproj.exe] +>> > converting method System.IO.UnexceptionalStreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding) +>> > Method System.IO.UnexceptionalStreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea860 to +>> > 0xb6eea8f0 (code length 144) [testproj.exe] +>> > converting method System.IO.StreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding) +>> > Method System.IO.StreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea900 to +>> > 0xb6eea994 (code length 148) [testproj.exe] +>> > converting method System.IO.StreamWriter:.cctor () +>> > Method System.IO.StreamWriter:.cctor () emitted at 0xb6eea9a0 to +>> > 0xb6eeaa74 (code length 212) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.StreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding,int) +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.StreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaa80 to +>> > 0xb6eeab98 (code length 280) [testproj.exe] +>> > converting method System.IO.StreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding,int) +>> > Method System.IO.StreamWriter:.ctor +>> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaba8 to +>> > 0xb6eeae54 (code length 684) [testproj.exe] +>> > converting method System.IO.TextWriter:.ctor () +>> > Method System.IO.TextWriter:.ctor () emitted at 0xb6eeae70 to +>> > 0xb6eeaf34 (code length 196) [testproj.exe] +>> > converting method System.IO.TextWriter:.cctor () +>> > Method System.IO.TextWriter:.cctor () emitted at 0xb6eeaf50 to +>> > 0xb6eeaff4 (code length 164) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.TextWriter/NullTextWriter:.ctor () +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.TextWriter/NullTextWriter:.ctor () emitted at 0xb6eeb000 to +>> > 0xb6eeb0d4 (code length 212) [testproj.exe] +>> > converting method System.IO.TextWriter/NullTextWriter:.ctor () +>> > Method System.IO.TextWriter/NullTextWriter:.ctor () emitted at +>> > 0xb6eeb0f0 to 0xb6eeb170 (code length 128) [testproj.exe] +>> > converting method System.Environment:get_NewLine () +>> > Method System.Environment:get_NewLine () emitted at 0xb6eeb170 to +>> > 0xb6eeb2a8 (code length 312) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.Environment:GetNewLine () +>> > Method (wrapper managed-to-native) System.Environment:GetNewLine () +>> > emitted at 0xb6eeb2b8 to 0xb6eeb3a8 (code length 240) [testproj.exe] +>> > converting method string:ToCharArray () +>> > Method string:ToCharArray () emitted at 0xb6eeb3a8 to 0xb6eeb434 (code +>> > length 140) [testproj.exe] +>> > converting method string:.cctor () +>> > Method string:.cctor () emitted at 0xb6eeb440 to 0xb6eeb554 (code +>> > length 276) [testproj.exe] +>> > converting method (wrapper managed-to-native) string:GetLOSLimit () +>> > Method (wrapper managed-to-native) string:GetLOSLimit () emitted at +>> > 0xb6eeb570 to 0xb6eeb660 (code length 240) [testproj.exe] +>> > converting method string:memcpy (byte*,byte*,int) +>> > Method string:memcpy (byte*,byte*,int) emitted at 0xb6eeb660 to +>> > 0xb6eebac8 (code length 1128) [testproj.exe] +>> > converting method string:memcpy4 (byte*,byte*,int) +>> > Method string:memcpy4 (byte*,byte*,int) emitted at 0xb6eebaf0 to +>> > 0xb6eebf10 (code length 1056) [testproj.exe] +>> > converting method string:ToCharArray (int,int) +>> > Method string:ToCharArray (int,int) emitted at 0xb6eebf10 to +>> > 0xb6eec32c (code length 1052) [testproj.exe] +>> > converting method string:CharCopy (char*,char*,int) +>> > Method string:CharCopy (char*,char*,int) emitted at 0xb6eec338 to +>> > 0xb6eec5d8 (code length 672) [testproj.exe] +>> > converting method System.IO.NullStream:get_CanWrite () +>> > Method System.IO.NullStream:get_CanWrite () emitted at 0xb6eec5d8 to +>> > 0xb6eec654 (code length 124) [testproj.exe] +>> > converting method System.IO.StreamWriter:Initialize +>> > (System.Text.Encoding,int) +>> > Method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +>> > emitted at 0xb6eec658 to 0xb6eec8f4 (code length 668) [testproj.exe] +>> > converting method System.Math:Max (int,int) +>> > Method System.Math:Max (int,int) emitted at 0xb6eec8f8 to 0xb6eec9dc +>> > (code length 228) [testproj.exe] +>> > converting method System.Text.UTF8Encoding:GetMaxByteCount (int) +>> > Method System.Text.UTF8Encoding:GetMaxByteCount (int) emitted at +>> > 0xb6eec9e0 to 0xb6eecaec (code length 268) [testproj.exe] +>> > converting method System.IO.NullStream:get_CanSeek () +>> > Method System.IO.NullStream:get_CanSeek () emitted at 0xb6eecaf8 to +>> > 0xb6eecb74 (code length 124) [testproj.exe] +>> > converting method System.IO.NullStream:get_Position () +>> > Method System.IO.NullStream:get_Position () emitted at 0xb6eecb78 to +>> > 0xb6eecbf8 (code length 128) [testproj.exe] +>> > converting method System.IO.FileStream:get_CanWrite () +>> > Method System.IO.FileStream:get_CanWrite () emitted at 0xb6eecbf8 to +>> > 0xb6eeccf0 (code length 248) [testproj.exe] +>> > converting method System.IO.FileStream:get_CanSeek () +>> > Method System.IO.FileStream:get_CanSeek () emitted at 0xb6eeccf0 to +>> > 0xb6eecd70 (code length 128) [testproj.exe] +>> > converting method System.IO.StreamWriter:set_AutoFlush (bool) +>> > Method System.IO.StreamWriter:set_AutoFlush (bool) emitted at +>> > 0xb6eecd70 to 0xb6eece5c (code length 236) [testproj.exe] +>> > converting method System.IO.UnexceptionalStreamWriter:Flush () +>> > Method System.IO.UnexceptionalStreamWriter:Flush () emitted at +>> > 0xb6eece60 to 0xb6eecf4c (code length 236) [testproj.exe] +>> > converting method System.IO.StreamWriter:Flush () +>> > Method System.IO.StreamWriter:Flush () emitted at 0xb6eecf58 to +>> > 0xb6eed0dc (code length 388) [testproj.exe] +>> > converting method System.IO.StreamWriter:Decode () +>> > Method System.IO.StreamWriter:Decode () emitted at 0xb6eed0f8 to +>> > 0xb6eed308 (code length 528) [testproj.exe] +>> > converting method System.IO.TextWriter:Synchronized +>> > (System.IO.TextWriter,bool) +>> > Method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +>> > emitted at 0xb6eed320 to 0xb6eed5c0 (code length 672) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) emitted +>> > at 0xb6eed5d8 to 0xb6eed6d4 (code length 252) [testproj.exe] +>> > converting method System.IO.SynchronizedWriter:.ctor +>> > (System.IO.TextWriter,bool) +>> > Method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +>> > emitted at 0xb6eed6f0 to 0xb6eed7d0 (code length 224) [testproj.exe] +>> > converting method System.ConsoleDriver:get_IsConsole () +>> > Method System.ConsoleDriver:get_IsConsole () emitted at 0xb6eed7d0 to +>> > 0xb6eed9b0 (code length 480) [testproj.exe] +>> > converting method System.ConsoleDriver:.cctor () +>> > Method System.ConsoleDriver:.cctor () emitted at 0xb6eed9e0 to +>> > 0xb6eedc6c (code length 652) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.IO.MonoIO:get_ConsoleOutput () +>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleOutput +>> > () emitted at 0xb6eedca8 to 0xb6eedd98 (code length 240) +>> > [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.ConsoleDriver:Isatty (intptr) +>> > Method (wrapper managed-to-native) System.ConsoleDriver:Isatty +>> > (intptr) emitted at 0xb6eedd98 to 0xb6eede90 (code length 248) +>> > [testproj.exe] +>> > converting method System.ConsoleDriver:CreateNullConsoleDriver () +>> > Method System.ConsoleDriver:CreateNullConsoleDriver () emitted at +>> > 0xb6eede90 to 0xb6eedf1c (code length 140) [testproj.exe] +>> > converting method System.NullConsoleDriver:.ctor () +>> > Method System.NullConsoleDriver:.ctor () emitted at 0xb6eedf28 to +>> > 0xb6eedfa4 (code length 124) [testproj.exe] +>> > converting method System.Console:OpenStandardOutput (int) +>> > Method System.Console:OpenStandardOutput (int) emitted at 0xb6eedfa8 +>> > to 0xb6eee030 (code length 136) [testproj.exe] +>> > converting method System.Console:OpenStandardInput (int) +>> > Method System.Console:OpenStandardInput (int) emitted at 0xb6eee030 to +>> > 0xb6eee0b8 (code length 136) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.IO.MonoIO:get_ConsoleInput () +>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleInput +>> > () emitted at 0xb6eee0b8 to 0xb6eee1a8 (code length 240) +>> > [testproj.exe] +>> > converting method System.IO.UnexceptionalStreamReader:.cctor () +>> > Method System.IO.UnexceptionalStreamReader:.cctor () emitted at +>> > 0xb6eee1a8 to 0xb6eee300 (code length 344) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.UnexceptionalStreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding) +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.UnexceptionalStreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee300 to +>> > 0xb6eee3fc (code length 252) [testproj.exe] +>> > converting method System.IO.UnexceptionalStreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding) +>> > Method System.IO.UnexceptionalStreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee418 to +>> > 0xb6eee4a8 (code length 144) [testproj.exe] +>> > converting method System.IO.StreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding) +>> > Method System.IO.StreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee4b8 to +>> > 0xb6eee554 (code length 156) [testproj.exe] +>> > converting method System.IO.StreamReader:.cctor () +>> > Method System.IO.StreamReader:.cctor () emitted at 0xb6eee560 to +>> > 0xb6eee648 (code length 232) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.StreamReader/NullStreamReader:.ctor () +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.StreamReader/NullStreamReader:.ctor () emitted at 0xb6eee658 +>> > to 0xb6eee72c (code length 212) [testproj.exe] +>> > converting method System.IO.StreamReader/NullStreamReader:.ctor () +>> > Method System.IO.StreamReader/NullStreamReader:.ctor () emitted at +>> > 0xb6eee748 to 0xb6eee7c8 (code length 128) [testproj.exe] +>> > converting method System.IO.StreamReader:.ctor () +>> > Method System.IO.StreamReader:.ctor () emitted at 0xb6eee7d8 to +>> > 0xb6eee858 (code length 128) [testproj.exe] +>> > converting method System.IO.TextReader:.ctor () +>> > Method System.IO.TextReader:.ctor () emitted at 0xb6eee868 to +>> > 0xb6eee8e8 (code length 128) [testproj.exe] +>> > converting method System.IO.TextReader:.cctor () +>> > Method System.IO.TextReader:.cctor () emitted at 0xb6eee8e8 to +>> > 0xb6eee98c (code length 164) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.TextReader/NullTextReader:.ctor () +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.TextReader/NullTextReader:.ctor () emitted at 0xb6eee998 to +>> > 0xb6eeea6c (code length 212) [testproj.exe] +>> > converting method System.IO.TextReader/NullTextReader:.ctor () +>> > Method System.IO.TextReader/NullTextReader:.ctor () emitted at +>> > 0xb6eeea88 to 0xb6eeeb08 (code length 128) [testproj.exe] +>> > converting method System.IO.StreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding,bool,int) +>> > Method System.IO.StreamReader:.ctor +>> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeeb08 +>> > to 0xb6eeebd8 (code length 208) [testproj.exe] +>> > converting method System.IO.StreamReader:Initialize +>> > (System.IO.Stream,System.Text.Encoding,bool,int) +>> > Method System.IO.StreamReader:Initialize +>> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeebe8 +>> > to 0xb6eef5b8 (code length 2512) [testproj.exe] +>> > converting method System.IO.FileStream:get_CanRead () +>> > Method System.IO.FileStream:get_CanRead () emitted at 0xb6eef5b8 to +>> > 0xb6eef6b0 (code length 248) [testproj.exe] +>> > converting method System.Text.UTF8Encoding:GetMaxCharCount (int) +>> > Method System.Text.UTF8Encoding:GetMaxCharCount (int) emitted at +>> > 0xb6eef6b0 to 0xb6eef7b8 (code length 264) [testproj.exe] +>> > converting method System.Text.UTF8Encoding:GetDecoder () +>> > Method System.Text.UTF8Encoding:GetDecoder () emitted at 0xb6eef7b8 to +>> > 0xb6eef858 (code length 160) [testproj.exe] +>> > converting method System.Text.Encoding:get_DecoderFallback () +>> > Method System.Text.Encoding:get_DecoderFallback () emitted at +>> > 0xb6eef870 to 0xb6eef8f0 (code length 128) [testproj.exe] +>> > converting method System.Text.UTF8Encoding/UTF8Decoder:.ctor +>> > (System.Text.DecoderFallback) +>> > Method System.Text.UTF8Encoding/UTF8Decoder:.ctor +>> > (System.Text.DecoderFallback) emitted at 0xb6eef8f0 to 0xb6eef9f8 +>> > (code length 264) [testproj.exe] +>> > converting method System.Text.Decoder:.ctor () +>> > Method System.Text.Decoder:.ctor () emitted at 0xb6eefa10 to +>> > 0xb6eefad4 (code length 196) [testproj.exe] +>> > converting method System.Text.Decoder:set_Fallback +>> > (System.Text.DecoderFallback) +>> > Method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +>> > emitted at 0xb6eefad8 to 0xb6eefbe8 (code length 272) [testproj.exe] +>> > converting method System.Text.UTF8Encoding:GetPreamble () +>> > Method System.Text.UTF8Encoding:GetPreamble () emitted at 0xb6eefbe8 +>> > to 0xb6eefd10 (code length 296) [testproj.exe] +>> > converting method (wrapper stfld) +>> > object:__stfld_wrapper_0x34ee68_System.Int32 +>> > (object,intptr,intptr,intptr,int) +>> > Method (wrapper stfld) object:__stfld_wrapper_0x34ee68_System.Int32 +>> > (object,intptr,intptr,intptr,int) emitted at 0xb6eefd10 to 0xb6eefe7c +>> > (code length 364) [testproj.exe] +>> > converting method (wrapper ldfld) +>> > object:__ldfld_wrapper_0x34ee68_System.Int32 +>> > (object,intptr,intptr,intptr) +>> > Method (wrapper ldfld) object:__ldfld_wrapper_0x34ee68_System.Int32 +>> > (object,intptr,intptr,intptr) emitted at 0xb6eefe88 to 0xb6eeffd8 +>> > (code length 336) [testproj.exe] +>> > converting method System.IO.TextReader:Synchronized +>> > (System.IO.TextReader) +>> > Method System.IO.TextReader:Synchronized (System.IO.TextReader) +>> > emitted at 0xb6eeffe8 to 0xb6ef0278 (code length 656) [testproj.exe] +>> > converting method (wrapper remoting-invoke-with-check) +>> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +>> > Method (wrapper remoting-invoke-with-check) +>> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) emitted at +>> > 0xb6ef0290 to 0xb6ef0378 (code length 232) [testproj.exe] +>> > converting method System.IO.SynchronizedReader:.ctor +>> > (System.IO.TextReader) +>> > Method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +>> > emitted at 0xb6ef0390 to 0xb6ef0440 (code length 176) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.GC:SuppressFinalize (object) +>> > Method (wrapper managed-to-native) System.GC:SuppressFinalize (object) +>> > emitted at 0xb6ef0440 to 0xb6ef057c (code length 316) [testproj.exe] +>> > converting method System.IO.SynchronizedWriter:WriteLine (string) +>> > Method System.IO.SynchronizedWriter:WriteLine (string) emitted at +>> > 0xb6ef0580 to 0xb6ef06ec (code length 364) [testproj.exe] +>> > converting method System.IO.TextWriter:WriteLine (string) +>> > Method System.IO.TextWriter:WriteLine (string) emitted at 0xb6ef06f0 +>> > to 0xb6ef07b8 (code length 200) [testproj.exe] +>> > converting method System.IO.UnexceptionalStreamWriter:Write (string) +>> > Method System.IO.UnexceptionalStreamWriter:Write (string) emitted at +>> > 0xb6ef07b8 to 0xb6ef08ac (code length 244) [testproj.exe] +>> > converting method System.IO.StreamWriter:Write (string) +>> > Method System.IO.StreamWriter:Write (string) emitted at 0xb6ef08b8 to +>> > 0xb6ef0a40 (code length 392) [testproj.exe] +>> > converting method System.IO.StreamWriter:LowLevelWrite (string) +>> > Method System.IO.StreamWriter:LowLevelWrite (string) emitted at +>> > 0xb6ef0a50 to 0xb6ef0e94 (code length 1092) [testproj.exe] +>> > converting method System.Text.UTF8Encoding:GetBytes +>> > (char[],int,int,byte[],int) +>> > Method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +>> > emitted at 0xb6ef0e98 to 0xb6ef1010 (code length 376) [testproj.exe] +>> > converting method System.Text.Encoding:get_EncoderFallback () +>> > Method System.Text.Encoding:get_EncoderFallback () emitted at +>> > 0xb6ef1028 to 0xb6ef10a8 (code length 128) [testproj.exe] +>> > converting method System.Text.UTF8Encoding:InternalGetBytes +>> > +>> > (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>> > Method System.Text.UTF8Encoding:InternalGetBytes +>> > +>> > (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>> > emitted at 0xb6ef10a8 to 0xb6ef1878 (code length 2000) [testproj.exe] +>> > converting method System.Text.UTF8Encoding:InternalGetBytes +>> > +>> > (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>> > Method System.Text.UTF8Encoding:InternalGetBytes +>> > +>> > (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>> > emitted at 0xb645a000 to 0xb645b31c (code length 4892) [testproj.exe] +>> > converting method System.IO.StreamWriter:FlushBytes () +>> > Method System.IO.StreamWriter:FlushBytes () emitted at 0xb645b338 to +>> > 0xb645b558 (code length 544) [testproj.exe] +>> > converting method System.IO.FileStream:Write (byte[],int,int) +>> > Method System.IO.FileStream:Write (byte[],int,int) emitted at +>> > 0xb645b558 to 0xb645b9cc (code length 1140) [testproj.exe] +>> > converting method System.IO.FileStream:WriteInternal (byte[],int,int) +>> > Method System.IO.FileStream:WriteInternal (byte[],int,int) emitted at +>> > 0xb645b9d8 to 0xb645bed0 (code length 1272) [testproj.exe] +>> > converting method System.IO.FileStream:FlushBuffer () +>> > Method System.IO.FileStream:FlushBuffer () emitted at 0xb645bf18 to +>> > 0xb645bf9c (code length 132) [testproj.exe] +>> > converting method System.IO.FileStream:FlushBuffer (System.IO.Stream) +>> > Method System.IO.FileStream:FlushBuffer (System.IO.Stream) emitted at +>> > 0xb645bfa8 to 0xb645c4fc (code length 1364) [testproj.exe] +>> > converting method (wrapper ldfld) +>> > object:__ldfld_wrapper_0x350250_System.Int64 +>> > (object,intptr,intptr,intptr) +>> > Method (wrapper ldfld) object:__ldfld_wrapper_0x350250_System.Int64 +>> > (object,intptr,intptr,intptr) emitted at 0xb645c500 to 0xb645c654 +>> > (code length 340) [testproj.exe] +>> > coStarted +>> > nverting method (wrapper stfld) +>> > object:__stfld_wrapper_0x350250_System.Int64 +>> > (object,intptr,intptr,intptr,long) +>> > Method (wrapper stfld) object:__stfld_wrapper_0x350250_System.Int64 +>> > (object,intptr,intptr,intptr,long) emitted at 0xb645c658 to 0xb645c7e4 +>> > (code length 396) [testproj.exe] +>> > converting method (wrapper managed-to-native) System.IO.MonoIO:Write +>> > (intptr,byte[],int,int,System.IO.MonoIOError&) +>> > Method (wrapper managed-to-native) System.IO.MonoIO:Write +>> > (intptr,byte[],int,int,System.IO.MonoIOError&) emitted at 0xb645c7e8 +>> > to 0xb645c918 (code length 304) [testproj.exe] +>> > converting method System.IO.FileStream:Flush () +>> > Method System.IO.FileStream:Flush () emitted at 0xb645c918 to +>> > 0xb645ca18 (code length 256) [testproj.exe] +>> > converting method System.IO.TextWriter:WriteLine () +>> > Method System.IO.TextWriter:WriteLine () emitted at 0xb645ca18 to +>> > 0xb645caac (code length 148) [testproj.exe] +>> > converting method System.IO.UnexceptionalStreamWriter:Write (char[]) +>> > Method System.IO.UnexceptionalStreamWriter:Write (char[]) emitted at +>> > 0xb645cab0 to 0xb645cba4 (code length 244) [testproj.exe] +>> > converting method System.IO.StreamWriter:Write (char[]) +>> > Method System.IO.StreamWriter:Write (char[]) emitted at 0xb645cbb0 to +>> > 0xb645cd44 (code length 404) [testproj.exe] +>> > converting method System.IO.StreamWriter:LowLevelWrite (char[],int,int) +>> > Method System.IO.StreamWriter:LowLevelWrite (char[],int,int) emitted +>> > at 0xb645cd50 to 0xb645d04c (code length 764) [testproj.exe] +>> > converting method System.Buffer:BlockCopy +>> > (System.Array,int,System.Array,int,int) +>> > Method System.Buffer:BlockCopy (System.Array,int,System.Array,int,int) +>> > emitted at 0xb645d058 to 0xb645d458 (code length 1024) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.Buffer:BlockCopyInternal +>> > (System.Array,int,System.Array,int,int) +>> > Method (wrapper managed-to-native) System.Buffer:BlockCopyInternal +>> > (System.Array,int,System.Array,int,int) emitted at 0xb645d470 to +>> > 0xb645d5a0 (code length 304) [testproj.exe] +>> > converting method System.ExecutionEngineException:.ctor () +>> > Method System.ExecutionEngineException:.ctor () emitted at 0xb645d5a0 +>> > to 0xb645d638 (code length 152) [testproj.exe] +>> > converting method (wrapper runtime-invoke) +>> > object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) +>> > Method (wrapper runtime-invoke) object:runtime_invoke_void__this__ +>> > (object,intptr,intptr,intptr) emitted at 0xb645d638 to 0xb645d90c +>> > (code length 724) [testproj.exe] +>> > converting method Locale:GetText (string) +>> > Method Locale:GetText (string) emitted at 0xb645d910 to 0xb645d98c +>> > (code length 124) [testproj.exe] +>> > converting method System.Exception:ToString () +>> > Method System.Exception:ToString () emitted at 0xb645d990 to +>> > 0xb645dd04 (code length 884) [testproj.exe] +>> > converting method (wrapper runtime-invoke) +>> > <Module>:runtime_invoke_object__this__ (object,intptr,intptr,intptr) +>> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_object__this__ +>> > (object,intptr,intptr,intptr) emitted at 0xb645dd28 to 0xb645e004 +>> > (code length 732) [testproj.exe] +>> > converting method System.Exception:get_ClassName () +>> > Method System.Exception:get_ClassName () emitted at 0xb645e008 to +>> > 0xb645e104 (code length 252) [testproj.exe] +>> > converting method System.Exception:GetType () +>> > Method System.Exception:GetType () emitted at 0xb645e110 to 0xb645e194 +>> > (code length 132) [testproj.exe] +>> > converting method System.MonoType:ToString () +>> > Method System.MonoType:ToString () emitted at 0xb645e198 to 0xb645e220 +>> > (code length 136) [testproj.exe] +>> > converting method (wrapper managed-to-native) +>> > System.MonoType:getFullName (System.MonoType,bool,bool) +>> > Method (wrapper managed-to-native) System.MonoType:getFullName +>> > (System.MonoType,bool,bool) emitted at 0xb645e230 to 0xb645e394 (code +>> > length 356) [testproj.exe] +>> > converting method System.Text.StringBuilder:.ctor (string) +>> > Method System.Text.StringBuilder:.ctor (string) emitted at 0xb645e398 +>> > to 0xb645e520 (code length 392) [testproj.exe] +>> > converting method System.Text.StringBuilder:Append (string) +>> > Method System.Text.StringBuilder:Append (string) emitted at 0xb645e520 +>> > to 0xb645e8c4 (code length 932) [testproj.exe] +>> > converting method +>> > Unhandled Exception: System.ExecutionEngineException: SIGILL +>> > [ERROR] FATAL UNHANDLED EXCEPTION: System.ExecutionEngineException: +>> > SIGILL +>> > +>> > +>> > What can i do? +>> > +>> > +>> > thanks Peter +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
ok i'll try to build mono on arm from the sources this weekend. +Perhaps this will help. Are there any commandline switches which give +more information about the error or is there a way to attach a +debugger to the runtime? + +thanks Peter + + +Am 15. Februar 2012 20:32 schrieb Michael Hutchinson <m.j.hutchinson at gmail.com>: +> Unlikely, looks like an illegal instruction, so probably a JIT issue. +> Maybe a bad Mono build or revision. +> +> The reason you have OutOfMemoryException appearing in the traces is +> that Mono creates that exception at startup, in case it's ever needed, +> since it won't be possible to create it if the program actually runs +> out of memory. +> +> 2012/2/7 Jeff Stedfast <jeff at xamarin.com>: +>> Hi Peter, +>> +>> Looks like you are running out of memory for some reason. Beyond that, I +>> have no idea. +>> +>> Jeff +>> +>> +>> On Tue, Feb 7, 2012 at 4:09 PM, Peter Siegel <siegelpeter2009 at gmail.com> +>> wrote: +>>> +>>> Hi! +>>> +>>> I'm just wondering? Is there who knows about debugging with SDB on +>>> ARM? the Meego Addin should have been able to do this, and the Mono +>>> for the Iphone also uses the SDB to debug so i expected it to work. +>>> I'm willing to investigate this issue on my own, but any help would be +>>> really appreciated. +>>> +>>> thanks +>>> +>>> Peter +>>> +>>> Am 29. Januar 2012 15:18 schrieb Peter Siegel <siegelpeter2009 at gmail.com>: +>>> > Hi! +>>> > +>>> > I tried to do single step debugging using the mono sdb with +>>> > monodevelop remotely on an arm target... +>>> > I modified the Meego addin to be able to debug remotely on any Linux +>>> > System. It's an Linux Remote Debugging addin now :-) +>>> > +>>> > It works very well on the same cpu architecture. Now I can debug my +>>> > Linux Mono Programs from windows, but some debuging features do not +>>> > work if the remote target is an Arm Plattform. +>>> > +>>> > It connects without an exception and the Programm starts, when the +>>> > remote program throws an exception, the exception caught window opens +>>> > with no information at all and instance is "evaluating". On the +>>> > Remote Arm box, the Mono process has stopped +>>> > +>>> > When i insert an breakpoint the Program seems to pauses, but when i +>>> > press continue it crashes: +>>> > +>>> > Loaded assembly: /root/test/testproj.exe +>>> > Resolved pending breakpoint at +>>> > 'C:\Users\PeterS\Documents\testproj\testproj\Main.cs:11' to Void +>>> > testproj.MainClass:Main (String[]) [0x00011]. +>>> > converting method System.OutOfMemoryException:.ctor (string) +>>> > Method System.OutOfMemoryException:.ctor (string) emitted at +>>> > 0xb6ee4b68 to 0xb6ee4c20 (code length 184) [testproj.exe] +>>> > converting method (wrapper runtime-invoke) +>>> > <Module>:runtime_invoke_void__this___object +>>> > (object,intptr,intptr,intptr) +>>> > Method (wrapper runtime-invoke) +>>> > <Module>:runtime_invoke_void__this___object +>>> > (object,intptr,intptr,intptr) emitted at 0xb6ee4c48 to 0xb6ee4f2c +>>> > (code length 740) [testproj.exe] +>>> > converting method System.SystemException:.ctor (string) +>>> > Method System.SystemException:.ctor (string) emitted at 0xb6ee4f30 to +>>> > 0xb6ee4fe8 (code length 184) [testproj.exe] +>>> > converting method System.Exception:.ctor (string) +>>> > Method System.Exception:.ctor (string) emitted at 0xb6ee4ff8 to +>>> > 0xb6ee50d4 (code length 220) [testproj.exe] +>>> > converting method System.Exception:set_HResult (int) +>>> > Method System.Exception:set_HResult (int) emitted at 0xb6ee50d8 to +>>> > 0xb6ee5160 (code length 136) [testproj.exe] +>>> > converting method System.NullReferenceException:.ctor (string) +>>> > Method System.NullReferenceException:.ctor (string) emitted at +>>> > 0xb6ee5160 to 0xb6ee5218 (code length 184) [testproj.exe] +>>> > converting method System.StackOverflowException:.ctor (string) +>>> > Method System.StackOverflowException:.ctor (string) emitted at +>>> > 0xb6ee5218 to 0xb6ee52a0 (code length 136) [testproj.exe] +>>> > converting method testproj.MainClass:Main (string[]) +>>> > Method testproj.MainClass:Main (string[]) emitted at 0xb6ee52b0 to +>>> > 0xb6ee5490 (code length 480) [testproj.exe] +>>> > converting method (wrapper runtime-invoke) +>>> > <Module>:runtime_invoke_void_object (object,intptr,intptr,intptr) +>>> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_void_object +>>> > (object,intptr,intptr,intptr) emitted at 0xb6ee54b8 to 0xb6ee5794 +>>> > (code length 732) [testproj.exe] +>>> > converting method System.Console:WriteLine (string) +>>> > Method System.Console:WriteLine (string) emitted at 0xb6ee5798 to +>>> > 0xb6ee5834 (code length 156) [testproj.exe] +>>> > converting method System.Console:.cctor () +>>> > Method System.Console:.cctor () emitted at 0xb6ee5870 to 0xb6ee6358 +>>> > (code length 2792) [testproj.exe] +>>> > converting method (wrapper runtime-invoke) object:runtime_invoke_void +>>> > (object,intptr,intptr,intptr) +>>> > Method (wrapper runtime-invoke) object:runtime_invoke_void +>>> > (object,intptr,intptr,intptr) emitted at 0xb6ee6440 to 0xb6ee670c +>>> > (code length 716) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_fast (intptr) +>>> > Method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_fast (intptr) emitted at +>>> > 0xb6ee6718 to 0xb6ee6810 (code length 248) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.Text.Encoding:InternalCodePage (int&) +>>> > Method (wrapper managed-to-native) +>>> > System.Text.Encoding:InternalCodePage (int&) emitted at 0xb6ee6810 to +>>> > 0xb6ee6908 (code length 248) [testproj.exe] +>>> > converting method System.Text.Encoding:.cctor () +>>> > Method System.Text.Encoding:.cctor () emitted at 0xb6ee6920 to +>>> > 0xb6ee7298 (code length 2424) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_array_new_specific (intptr,int) +>>> > Method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_array_new_specific (intptr,int) emitted at +>>> > 0xb6ee72a8 to 0xb6ee73a8 (code length 256) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) +>>> > Method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) emitted at +>>> > 0xb6ee73a8 to 0xb6ee74a0 (code length 248) [testproj.exe] +>>> > converting method (wrapper stelemref) object:virt_stelemref_object +>>> > (intptr,object) +>>> > Method (wrapper stelemref) object:virt_stelemref_object +>>> > (intptr,object) emitted at 0xb6ee74a0 to 0xb6ee7558 (code length 184) +>>> > [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) +>>> > Method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) emitted at +>>> > 0xb6ee7558 to 0xb6ee7650 (code length 248) [testproj.exe] +>>> > converting method object:.ctor () +>>> > Method object:.ctor () emitted at 0xb6ee7650 to 0xb6ee76a8 (code +>>> > length 88) [testproj.exe] +>>> > converting method System.Text.Encoding:get_UTF8Unmarked () +>>> > Method System.Text.Encoding:get_UTF8Unmarked () emitted at 0xb6ee76a8 +>>> > to 0xb6ee792c (code length 644) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.Threading.Monitor:Enter (object) +>>> > Method (wrapper managed-to-native) System.Threading.Monitor:Enter +>>> > (object) emitted at 0xb6ee7950 to 0xb6ee7a8c (code length 316) +>>> > [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:.ctor (bool,bool) +>>> > Method System.Text.UTF8Encoding:.ctor (bool,bool) emitted at +>>> > 0xb6ee7a90 to 0xb6ee7d94 (code length 772) [testproj.exe] +>>> > converting method System.Text.Encoding:.ctor (int) +>>> > Method System.Text.Encoding:.ctor (int) emitted at 0xb6ee7de0 to +>>> > 0xb6ee8258 (code length 1144) [testproj.exe] +>>> > converting method System.Text.DecoderFallback:get_StandardSafeFallback +>>> > () +>>> > converting method System.Text.DecoderFallback:.cctor () +>>> > Method System.Text.DecoderFallback:.cctor () emitted at 0xb6ee8270 to +>>> > 0xb6ee83a0 (code length 304) [testproj.exe] +>>> > converting method System.Text.DecoderExceptionFallback:.ctor () +>>> > Method System.Text.DecoderExceptionFallback:.ctor () emitted at +>>> > 0xb6ee83c8 to 0xb6ee8448 (code length 128) [testproj.exe] +>>> > converting method System.Text.DecoderFallback:.ctor () +>>> > Method System.Text.DecoderFallback:.ctor () emitted at 0xb6ee8458 to +>>> > 0xb6ee84d4 (code length 124) [testproj.exe] +>>> > converting method System.Text.DecoderReplacementFallback:.ctor () +>>> > Method System.Text.DecoderReplacementFallback:.ctor () emitted at +>>> > 0xb6ee84d8 to 0xb6ee8560 (code length 136) [testproj.exe] +>>> > converting method System.Text.DecoderReplacementFallback:.ctor (string) +>>> > Method System.Text.DecoderReplacementFallback:.ctor (string) emitted +>>> > at 0xb6ee8560 to 0xb6ee866c (code length 268) [testproj.exe] +>>> > Method System.Text.DecoderFallback:get_StandardSafeFallback () emitted +>>> > at 0xb6ee8670 to 0xb6ee86ec (code length 124) [testproj.exe] +>>> > converting method System.Text.EncoderFallback:get_StandardSafeFallback +>>> > () +>>> > converting method System.Text.EncoderFallback:.cctor () +>>> > Method System.Text.EncoderFallback:.cctor () emitted at 0xb6ee86f0 to +>>> > 0xb6ee8820 (code length 304) [testproj.exe] +>>> > converting method System.Text.EncoderExceptionFallback:.ctor () +>>> > Method System.Text.EncoderExceptionFallback:.ctor () emitted at +>>> > 0xb6ee8848 to 0xb6ee88c8 (code length 128) [testproj.exe] +>>> > converting method System.Text.EncoderFallback:.ctor () +>>> > Method System.Text.EncoderFallback:.ctor () emitted at 0xb6ee88d8 to +>>> > 0xb6ee8954 (code length 124) [testproj.exe] +>>> > converting method System.Text.EncoderReplacementFallback:.ctor () +>>> > Method System.Text.EncoderReplacementFallback:.ctor () emitted at +>>> > 0xb6ee8958 to 0xb6ee89e0 (code length 136) [testproj.exe] +>>> > converting method System.Text.EncoderReplacementFallback:.ctor (string) +>>> > Method System.Text.EncoderReplacementFallback:.ctor (string) emitted +>>> > at 0xb6ee89e0 to 0xb6ee8aec (code length 268) [testproj.exe] +>>> > Method System.Text.EncoderFallback:get_StandardSafeFallback () emitted +>>> > at 0xb6ee8af0 to 0xb6ee8b6c (code length 124) [testproj.exe] +>>> > converting method System.Text.Encoding:SetFallbackInternal +>>> > (System.Text.EncoderFallback,System.Text.DecoderFallback) +>>> > Method System.Text.Encoding:SetFallbackInternal +>>> > (System.Text.EncoderFallback,System.Text.DecoderFallback) emitted at +>>> > 0xb6ee8b70 to 0xb6ee8c80 (code length 272) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.Threading.Monitor:Exit (object) +>>> > Method (wrapper managed-to-native) System.Threading.Monitor:Exit +>>> > (object) emitted at 0xb6ee8c80 to 0xb6ee8dbc (code length 316) +>>> > [testproj.exe] +>>> > converting method System.Console:OpenStandardError (int) +>>> > Method System.Console:OpenStandardError (int) emitted at 0xb6ee8dc0 to +>>> > 0xb6ee8e48 (code length 136) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.IO.MonoIO:get_ConsoleError () +>>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleError +>>> > () emitted at 0xb6ee8e60 to 0xb6ee8f50 (code length 240) +>>> > [testproj.exe] +>>> > converting method System.IO.MonoIO:.cctor () +>>> > Method System.IO.MonoIO:.cctor () emitted at 0xb6ee8f50 to 0xb6ee9010 +>>> > (code length 192) [testproj.exe] +>>> > converting method intptr:op_Explicit (long) +>>> > Method intptr:op_Explicit (long) emitted at 0xb6ee9020 to 0xb6ee90c0 +>>> > (code length 160) [testproj.exe] +>>> > converting method intptr:.ctor (long) +>>> > Method intptr:.ctor (long) emitted at 0xb6ee90d0 to 0xb6ee9160 (code +>>> > length 144) [testproj.exe] +>>> > converting method System.Console:Open (intptr,System.IO.FileAccess,int) +>>> > Method System.Console:Open (intptr,System.IO.FileAccess,int) emitted +>>> > at 0xb6ee9160 to 0xb6ee9354 (code length 500) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_specific (intptr) +>>> > Method (wrapper managed-to-native) +>>> > object:__icall_wrapper_mono_object_new_specific (intptr) emitted at +>>> > 0xb6ee9370 to 0xb6ee9468 (code length 248) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.FileStream:.ctor +>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +>>> > Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor +>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee9468 +>>> > to 0xb6ee9628 (code length 448) [testproj.exe] +>>> > converting method System.IO.FileStream:.cctor () +>>> > Method System.IO.FileStream:.cctor () emitted at 0xb6ee9640 to +>>> > 0xb6ee96d8 (code length 152) [testproj.exe] +>>> > converting method System.IO.FileStream:.ctor +>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +>>> > Method System.IO.FileStream:.ctor +>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee96e8 +>>> > to 0xb6ee9d74 (code length 1676) [testproj.exe] +>>> > converting method System.IO.Stream:.ctor () +>>> > Method System.IO.Stream:.ctor () emitted at 0xb6ee9dc8 to 0xb6ee9e48 +>>> > (code length 128) [testproj.exe] +>>> > converting method System.IO.Stream:.cctor () +>>> > Method System.IO.Stream:.cctor () emitted at 0xb6ee9e58 to 0xb6ee9efc +>>> > (code length 164) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.NullStream:.ctor () +>>> > Method (wrapper remoting-invoke-with-check) System.IO.NullStream:.ctor +>>> > () emitted at 0xb6ee9f00 to 0xb6ee9fd4 (code length 212) +>>> > [testproj.exe] +>>> > converting method System.IO.NullStream:.ctor () +>>> > Method System.IO.NullStream:.ctor () emitted at 0xb6ee9ff0 to +>>> > 0xb6eea070 (code length 128) [testproj.exe] +>>> > converting method System.MarshalByRefObject:.ctor () +>>> > Method System.MarshalByRefObject:.ctor () emitted at 0xb6eea070 to +>>> > 0xb6eea0ec (code length 124) [testproj.exe] +>>> > converting method intptr:op_Equality (intptr,intptr) +>>> > Method intptr:op_Equality (intptr,intptr) emitted at 0xb6eea0f0 to +>>> > 0xb6eea188 (code length 152) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.IO.MonoIO:GetFileType (intptr,System.IO.MonoIOError&) +>>> > Method (wrapper managed-to-native) System.IO.MonoIO:GetFileType +>>> > (intptr,System.IO.MonoIOError&) emitted at 0xb6eea188 to 0xb6eea288 +>>> > (code length 256) [testproj.exe] +>>> > converting method System.IO.FileStream:InitBuffer (int,bool) +>>> > Method System.IO.FileStream:InitBuffer (int,bool) emitted at +>>> > 0xb6eea288 to 0xb6eea72c (code length 1188) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.UnexceptionalStreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.UnexceptionalStreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea748 to +>>> > 0xb6eea844 (code length 252) [testproj.exe] +>>> > converting method System.IO.UnexceptionalStreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) +>>> > Method System.IO.UnexceptionalStreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea860 to +>>> > 0xb6eea8f0 (code length 144) [testproj.exe] +>>> > converting method System.IO.StreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) +>>> > Method System.IO.StreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea900 to +>>> > 0xb6eea994 (code length 148) [testproj.exe] +>>> > converting method System.IO.StreamWriter:.cctor () +>>> > Method System.IO.StreamWriter:.cctor () emitted at 0xb6eea9a0 to +>>> > 0xb6eeaa74 (code length 212) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.StreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding,int) +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.StreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaa80 to +>>> > 0xb6eeab98 (code length 280) [testproj.exe] +>>> > converting method System.IO.StreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding,int) +>>> > Method System.IO.StreamWriter:.ctor +>>> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaba8 to +>>> > 0xb6eeae54 (code length 684) [testproj.exe] +>>> > converting method System.IO.TextWriter:.ctor () +>>> > Method System.IO.TextWriter:.ctor () emitted at 0xb6eeae70 to +>>> > 0xb6eeaf34 (code length 196) [testproj.exe] +>>> > converting method System.IO.TextWriter:.cctor () +>>> > Method System.IO.TextWriter:.cctor () emitted at 0xb6eeaf50 to +>>> > 0xb6eeaff4 (code length 164) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.TextWriter/NullTextWriter:.ctor () +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.TextWriter/NullTextWriter:.ctor () emitted at 0xb6eeb000 to +>>> > 0xb6eeb0d4 (code length 212) [testproj.exe] +>>> > converting method System.IO.TextWriter/NullTextWriter:.ctor () +>>> > Method System.IO.TextWriter/NullTextWriter:.ctor () emitted at +>>> > 0xb6eeb0f0 to 0xb6eeb170 (code length 128) [testproj.exe] +>>> > converting method System.Environment:get_NewLine () +>>> > Method System.Environment:get_NewLine () emitted at 0xb6eeb170 to +>>> > 0xb6eeb2a8 (code length 312) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.Environment:GetNewLine () +>>> > Method (wrapper managed-to-native) System.Environment:GetNewLine () +>>> > emitted at 0xb6eeb2b8 to 0xb6eeb3a8 (code length 240) [testproj.exe] +>>> > converting method string:ToCharArray () +>>> > Method string:ToCharArray () emitted at 0xb6eeb3a8 to 0xb6eeb434 (code +>>> > length 140) [testproj.exe] +>>> > converting method string:.cctor () +>>> > Method string:.cctor () emitted at 0xb6eeb440 to 0xb6eeb554 (code +>>> > length 276) [testproj.exe] +>>> > converting method (wrapper managed-to-native) string:GetLOSLimit () +>>> > Method (wrapper managed-to-native) string:GetLOSLimit () emitted at +>>> > 0xb6eeb570 to 0xb6eeb660 (code length 240) [testproj.exe] +>>> > converting method string:memcpy (byte*,byte*,int) +>>> > Method string:memcpy (byte*,byte*,int) emitted at 0xb6eeb660 to +>>> > 0xb6eebac8 (code length 1128) [testproj.exe] +>>> > converting method string:memcpy4 (byte*,byte*,int) +>>> > Method string:memcpy4 (byte*,byte*,int) emitted at 0xb6eebaf0 to +>>> > 0xb6eebf10 (code length 1056) [testproj.exe] +>>> > converting method string:ToCharArray (int,int) +>>> > Method string:ToCharArray (int,int) emitted at 0xb6eebf10 to +>>> > 0xb6eec32c (code length 1052) [testproj.exe] +>>> > converting method string:CharCopy (char*,char*,int) +>>> > Method string:CharCopy (char*,char*,int) emitted at 0xb6eec338 to +>>> > 0xb6eec5d8 (code length 672) [testproj.exe] +>>> > converting method System.IO.NullStream:get_CanWrite () +>>> > Method System.IO.NullStream:get_CanWrite () emitted at 0xb6eec5d8 to +>>> > 0xb6eec654 (code length 124) [testproj.exe] +>>> > converting method System.IO.StreamWriter:Initialize +>>> > (System.Text.Encoding,int) +>>> > Method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +>>> > emitted at 0xb6eec658 to 0xb6eec8f4 (code length 668) [testproj.exe] +>>> > converting method System.Math:Max (int,int) +>>> > Method System.Math:Max (int,int) emitted at 0xb6eec8f8 to 0xb6eec9dc +>>> > (code length 228) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:GetMaxByteCount (int) +>>> > Method System.Text.UTF8Encoding:GetMaxByteCount (int) emitted at +>>> > 0xb6eec9e0 to 0xb6eecaec (code length 268) [testproj.exe] +>>> > converting method System.IO.NullStream:get_CanSeek () +>>> > Method System.IO.NullStream:get_CanSeek () emitted at 0xb6eecaf8 to +>>> > 0xb6eecb74 (code length 124) [testproj.exe] +>>> > converting method System.IO.NullStream:get_Position () +>>> > Method System.IO.NullStream:get_Position () emitted at 0xb6eecb78 to +>>> > 0xb6eecbf8 (code length 128) [testproj.exe] +>>> > converting method System.IO.FileStream:get_CanWrite () +>>> > Method System.IO.FileStream:get_CanWrite () emitted at 0xb6eecbf8 to +>>> > 0xb6eeccf0 (code length 248) [testproj.exe] +>>> > converting method System.IO.FileStream:get_CanSeek () +>>> > Method System.IO.FileStream:get_CanSeek () emitted at 0xb6eeccf0 to +>>> > 0xb6eecd70 (code length 128) [testproj.exe] +>>> > converting method System.IO.StreamWriter:set_AutoFlush (bool) +>>> > Method System.IO.StreamWriter:set_AutoFlush (bool) emitted at +>>> > 0xb6eecd70 to 0xb6eece5c (code length 236) [testproj.exe] +>>> > converting method System.IO.UnexceptionalStreamWriter:Flush () +>>> > Method System.IO.UnexceptionalStreamWriter:Flush () emitted at +>>> > 0xb6eece60 to 0xb6eecf4c (code length 236) [testproj.exe] +>>> > converting method System.IO.StreamWriter:Flush () +>>> > Method System.IO.StreamWriter:Flush () emitted at 0xb6eecf58 to +>>> > 0xb6eed0dc (code length 388) [testproj.exe] +>>> > converting method System.IO.StreamWriter:Decode () +>>> > Method System.IO.StreamWriter:Decode () emitted at 0xb6eed0f8 to +>>> > 0xb6eed308 (code length 528) [testproj.exe] +>>> > converting method System.IO.TextWriter:Synchronized +>>> > (System.IO.TextWriter,bool) +>>> > Method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +>>> > emitted at 0xb6eed320 to 0xb6eed5c0 (code length 672) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) emitted +>>> > at 0xb6eed5d8 to 0xb6eed6d4 (code length 252) [testproj.exe] +>>> > converting method System.IO.SynchronizedWriter:.ctor +>>> > (System.IO.TextWriter,bool) +>>> > Method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +>>> > emitted at 0xb6eed6f0 to 0xb6eed7d0 (code length 224) [testproj.exe] +>>> > converting method System.ConsoleDriver:get_IsConsole () +>>> > Method System.ConsoleDriver:get_IsConsole () emitted at 0xb6eed7d0 to +>>> > 0xb6eed9b0 (code length 480) [testproj.exe] +>>> > converting method System.ConsoleDriver:.cctor () +>>> > Method System.ConsoleDriver:.cctor () emitted at 0xb6eed9e0 to +>>> > 0xb6eedc6c (code length 652) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.IO.MonoIO:get_ConsoleOutput () +>>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleOutput +>>> > () emitted at 0xb6eedca8 to 0xb6eedd98 (code length 240) +>>> > [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.ConsoleDriver:Isatty (intptr) +>>> > Method (wrapper managed-to-native) System.ConsoleDriver:Isatty +>>> > (intptr) emitted at 0xb6eedd98 to 0xb6eede90 (code length 248) +>>> > [testproj.exe] +>>> > converting method System.ConsoleDriver:CreateNullConsoleDriver () +>>> > Method System.ConsoleDriver:CreateNullConsoleDriver () emitted at +>>> > 0xb6eede90 to 0xb6eedf1c (code length 140) [testproj.exe] +>>> > converting method System.NullConsoleDriver:.ctor () +>>> > Method System.NullConsoleDriver:.ctor () emitted at 0xb6eedf28 to +>>> > 0xb6eedfa4 (code length 124) [testproj.exe] +>>> > converting method System.Console:OpenStandardOutput (int) +>>> > Method System.Console:OpenStandardOutput (int) emitted at 0xb6eedfa8 +>>> > to 0xb6eee030 (code length 136) [testproj.exe] +>>> > converting method System.Console:OpenStandardInput (int) +>>> > Method System.Console:OpenStandardInput (int) emitted at 0xb6eee030 to +>>> > 0xb6eee0b8 (code length 136) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.IO.MonoIO:get_ConsoleInput () +>>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleInput +>>> > () emitted at 0xb6eee0b8 to 0xb6eee1a8 (code length 240) +>>> > [testproj.exe] +>>> > converting method System.IO.UnexceptionalStreamReader:.cctor () +>>> > Method System.IO.UnexceptionalStreamReader:.cctor () emitted at +>>> > 0xb6eee1a8 to 0xb6eee300 (code length 344) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.UnexceptionalStreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.UnexceptionalStreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee300 to +>>> > 0xb6eee3fc (code length 252) [testproj.exe] +>>> > converting method System.IO.UnexceptionalStreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) +>>> > Method System.IO.UnexceptionalStreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee418 to +>>> > 0xb6eee4a8 (code length 144) [testproj.exe] +>>> > converting method System.IO.StreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) +>>> > Method System.IO.StreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee4b8 to +>>> > 0xb6eee554 (code length 156) [testproj.exe] +>>> > converting method System.IO.StreamReader:.cctor () +>>> > Method System.IO.StreamReader:.cctor () emitted at 0xb6eee560 to +>>> > 0xb6eee648 (code length 232) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.StreamReader/NullStreamReader:.ctor () +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.StreamReader/NullStreamReader:.ctor () emitted at 0xb6eee658 +>>> > to 0xb6eee72c (code length 212) [testproj.exe] +>>> > converting method System.IO.StreamReader/NullStreamReader:.ctor () +>>> > Method System.IO.StreamReader/NullStreamReader:.ctor () emitted at +>>> > 0xb6eee748 to 0xb6eee7c8 (code length 128) [testproj.exe] +>>> > converting method System.IO.StreamReader:.ctor () +>>> > Method System.IO.StreamReader:.ctor () emitted at 0xb6eee7d8 to +>>> > 0xb6eee858 (code length 128) [testproj.exe] +>>> > converting method System.IO.TextReader:.ctor () +>>> > Method System.IO.TextReader:.ctor () emitted at 0xb6eee868 to +>>> > 0xb6eee8e8 (code length 128) [testproj.exe] +>>> > converting method System.IO.TextReader:.cctor () +>>> > Method System.IO.TextReader:.cctor () emitted at 0xb6eee8e8 to +>>> > 0xb6eee98c (code length 164) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.TextReader/NullTextReader:.ctor () +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.TextReader/NullTextReader:.ctor () emitted at 0xb6eee998 to +>>> > 0xb6eeea6c (code length 212) [testproj.exe] +>>> > converting method System.IO.TextReader/NullTextReader:.ctor () +>>> > Method System.IO.TextReader/NullTextReader:.ctor () emitted at +>>> > 0xb6eeea88 to 0xb6eeeb08 (code length 128) [testproj.exe] +>>> > converting method System.IO.StreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding,bool,int) +>>> > Method System.IO.StreamReader:.ctor +>>> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeeb08 +>>> > to 0xb6eeebd8 (code length 208) [testproj.exe] +>>> > converting method System.IO.StreamReader:Initialize +>>> > (System.IO.Stream,System.Text.Encoding,bool,int) +>>> > Method System.IO.StreamReader:Initialize +>>> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeebe8 +>>> > to 0xb6eef5b8 (code length 2512) [testproj.exe] +>>> > converting method System.IO.FileStream:get_CanRead () +>>> > Method System.IO.FileStream:get_CanRead () emitted at 0xb6eef5b8 to +>>> > 0xb6eef6b0 (code length 248) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:GetMaxCharCount (int) +>>> > Method System.Text.UTF8Encoding:GetMaxCharCount (int) emitted at +>>> > 0xb6eef6b0 to 0xb6eef7b8 (code length 264) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:GetDecoder () +>>> > Method System.Text.UTF8Encoding:GetDecoder () emitted at 0xb6eef7b8 to +>>> > 0xb6eef858 (code length 160) [testproj.exe] +>>> > converting method System.Text.Encoding:get_DecoderFallback () +>>> > Method System.Text.Encoding:get_DecoderFallback () emitted at +>>> > 0xb6eef870 to 0xb6eef8f0 (code length 128) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding/UTF8Decoder:.ctor +>>> > (System.Text.DecoderFallback) +>>> > Method System.Text.UTF8Encoding/UTF8Decoder:.ctor +>>> > (System.Text.DecoderFallback) emitted at 0xb6eef8f0 to 0xb6eef9f8 +>>> > (code length 264) [testproj.exe] +>>> > converting method System.Text.Decoder:.ctor () +>>> > Method System.Text.Decoder:.ctor () emitted at 0xb6eefa10 to +>>> > 0xb6eefad4 (code length 196) [testproj.exe] +>>> > converting method System.Text.Decoder:set_Fallback +>>> > (System.Text.DecoderFallback) +>>> > Method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +>>> > emitted at 0xb6eefad8 to 0xb6eefbe8 (code length 272) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:GetPreamble () +>>> > Method System.Text.UTF8Encoding:GetPreamble () emitted at 0xb6eefbe8 +>>> > to 0xb6eefd10 (code length 296) [testproj.exe] +>>> > converting method (wrapper stfld) +>>> > object:__stfld_wrapper_0x34ee68_System.Int32 +>>> > (object,intptr,intptr,intptr,int) +>>> > Method (wrapper stfld) object:__stfld_wrapper_0x34ee68_System.Int32 +>>> > (object,intptr,intptr,intptr,int) emitted at 0xb6eefd10 to 0xb6eefe7c +>>> > (code length 364) [testproj.exe] +>>> > converting method (wrapper ldfld) +>>> > object:__ldfld_wrapper_0x34ee68_System.Int32 +>>> > (object,intptr,intptr,intptr) +>>> > Method (wrapper ldfld) object:__ldfld_wrapper_0x34ee68_System.Int32 +>>> > (object,intptr,intptr,intptr) emitted at 0xb6eefe88 to 0xb6eeffd8 +>>> > (code length 336) [testproj.exe] +>>> > converting method System.IO.TextReader:Synchronized +>>> > (System.IO.TextReader) +>>> > Method System.IO.TextReader:Synchronized (System.IO.TextReader) +>>> > emitted at 0xb6eeffe8 to 0xb6ef0278 (code length 656) [testproj.exe] +>>> > converting method (wrapper remoting-invoke-with-check) +>>> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +>>> > Method (wrapper remoting-invoke-with-check) +>>> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) emitted at +>>> > 0xb6ef0290 to 0xb6ef0378 (code length 232) [testproj.exe] +>>> > converting method System.IO.SynchronizedReader:.ctor +>>> > (System.IO.TextReader) +>>> > Method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +>>> > emitted at 0xb6ef0390 to 0xb6ef0440 (code length 176) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.GC:SuppressFinalize (object) +>>> > Method (wrapper managed-to-native) System.GC:SuppressFinalize (object) +>>> > emitted at 0xb6ef0440 to 0xb6ef057c (code length 316) [testproj.exe] +>>> > converting method System.IO.SynchronizedWriter:WriteLine (string) +>>> > Method System.IO.SynchronizedWriter:WriteLine (string) emitted at +>>> > 0xb6ef0580 to 0xb6ef06ec (code length 364) [testproj.exe] +>>> > converting method System.IO.TextWriter:WriteLine (string) +>>> > Method System.IO.TextWriter:WriteLine (string) emitted at 0xb6ef06f0 +>>> > to 0xb6ef07b8 (code length 200) [testproj.exe] +>>> > converting method System.IO.UnexceptionalStreamWriter:Write (string) +>>> > Method System.IO.UnexceptionalStreamWriter:Write (string) emitted at +>>> > 0xb6ef07b8 to 0xb6ef08ac (code length 244) [testproj.exe] +>>> > converting method System.IO.StreamWriter:Write (string) +>>> > Method System.IO.StreamWriter:Write (string) emitted at 0xb6ef08b8 to +>>> > 0xb6ef0a40 (code length 392) [testproj.exe] +>>> > converting method System.IO.StreamWriter:LowLevelWrite (string) +>>> > Method System.IO.StreamWriter:LowLevelWrite (string) emitted at +>>> > 0xb6ef0a50 to 0xb6ef0e94 (code length 1092) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:GetBytes +>>> > (char[],int,int,byte[],int) +>>> > Method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +>>> > emitted at 0xb6ef0e98 to 0xb6ef1010 (code length 376) [testproj.exe] +>>> > converting method System.Text.Encoding:get_EncoderFallback () +>>> > Method System.Text.Encoding:get_EncoderFallback () emitted at +>>> > 0xb6ef1028 to 0xb6ef10a8 (code length 128) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:InternalGetBytes +>>> > +>>> > (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>> > Method System.Text.UTF8Encoding:InternalGetBytes +>>> > +>>> > (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>> > emitted at 0xb6ef10a8 to 0xb6ef1878 (code length 2000) [testproj.exe] +>>> > converting method System.Text.UTF8Encoding:InternalGetBytes +>>> > +>>> > (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>> > Method System.Text.UTF8Encoding:InternalGetBytes +>>> > +>>> > (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>> > emitted at 0xb645a000 to 0xb645b31c (code length 4892) [testproj.exe] +>>> > converting method System.IO.StreamWriter:FlushBytes () +>>> > Method System.IO.StreamWriter:FlushBytes () emitted at 0xb645b338 to +>>> > 0xb645b558 (code length 544) [testproj.exe] +>>> > converting method System.IO.FileStream:Write (byte[],int,int) +>>> > Method System.IO.FileStream:Write (byte[],int,int) emitted at +>>> > 0xb645b558 to 0xb645b9cc (code length 1140) [testproj.exe] +>>> > converting method System.IO.FileStream:WriteInternal (byte[],int,int) +>>> > Method System.IO.FileStream:WriteInternal (byte[],int,int) emitted at +>>> > 0xb645b9d8 to 0xb645bed0 (code length 1272) [testproj.exe] +>>> > converting method System.IO.FileStream:FlushBuffer () +>>> > Method System.IO.FileStream:FlushBuffer () emitted at 0xb645bf18 to +>>> > 0xb645bf9c (code length 132) [testproj.exe] +>>> > converting method System.IO.FileStream:FlushBuffer (System.IO.Stream) +>>> > Method System.IO.FileStream:FlushBuffer (System.IO.Stream) emitted at +>>> > 0xb645bfa8 to 0xb645c4fc (code length 1364) [testproj.exe] +>>> > converting method (wrapper ldfld) +>>> > object:__ldfld_wrapper_0x350250_System.Int64 +>>> > (object,intptr,intptr,intptr) +>>> > Method (wrapper ldfld) object:__ldfld_wrapper_0x350250_System.Int64 +>>> > (object,intptr,intptr,intptr) emitted at 0xb645c500 to 0xb645c654 +>>> > (code length 340) [testproj.exe] +>>> > coStarted +>>> > nverting method (wrapper stfld) +>>> > object:__stfld_wrapper_0x350250_System.Int64 +>>> > (object,intptr,intptr,intptr,long) +>>> > Method (wrapper stfld) object:__stfld_wrapper_0x350250_System.Int64 +>>> > (object,intptr,intptr,intptr,long) emitted at 0xb645c658 to 0xb645c7e4 +>>> > (code length 396) [testproj.exe] +>>> > converting method (wrapper managed-to-native) System.IO.MonoIO:Write +>>> > (intptr,byte[],int,int,System.IO.MonoIOError&) +>>> > Method (wrapper managed-to-native) System.IO.MonoIO:Write +>>> > (intptr,byte[],int,int,System.IO.MonoIOError&) emitted at 0xb645c7e8 +>>> > to 0xb645c918 (code length 304) [testproj.exe] +>>> > converting method System.IO.FileStream:Flush () +>>> > Method System.IO.FileStream:Flush () emitted at 0xb645c918 to +>>> > 0xb645ca18 (code length 256) [testproj.exe] +>>> > converting method System.IO.TextWriter:WriteLine () +>>> > Method System.IO.TextWriter:WriteLine () emitted at 0xb645ca18 to +>>> > 0xb645caac (code length 148) [testproj.exe] +>>> > converting method System.IO.UnexceptionalStreamWriter:Write (char[]) +>>> > Method System.IO.UnexceptionalStreamWriter:Write (char[]) emitted at +>>> > 0xb645cab0 to 0xb645cba4 (code length 244) [testproj.exe] +>>> > converting method System.IO.StreamWriter:Write (char[]) +>>> > Method System.IO.StreamWriter:Write (char[]) emitted at 0xb645cbb0 to +>>> > 0xb645cd44 (code length 404) [testproj.exe] +>>> > converting method System.IO.StreamWriter:LowLevelWrite (char[],int,int) +>>> > Method System.IO.StreamWriter:LowLevelWrite (char[],int,int) emitted +>>> > at 0xb645cd50 to 0xb645d04c (code length 764) [testproj.exe] +>>> > converting method System.Buffer:BlockCopy +>>> > (System.Array,int,System.Array,int,int) +>>> > Method System.Buffer:BlockCopy (System.Array,int,System.Array,int,int) +>>> > emitted at 0xb645d058 to 0xb645d458 (code length 1024) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.Buffer:BlockCopyInternal +>>> > (System.Array,int,System.Array,int,int) +>>> > Method (wrapper managed-to-native) System.Buffer:BlockCopyInternal +>>> > (System.Array,int,System.Array,int,int) emitted at 0xb645d470 to +>>> > 0xb645d5a0 (code length 304) [testproj.exe] +>>> > converting method System.ExecutionEngineException:.ctor () +>>> > Method System.ExecutionEngineException:.ctor () emitted at 0xb645d5a0 +>>> > to 0xb645d638 (code length 152) [testproj.exe] +>>> > converting method (wrapper runtime-invoke) +>>> > object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) +>>> > Method (wrapper runtime-invoke) object:runtime_invoke_void__this__ +>>> > (object,intptr,intptr,intptr) emitted at 0xb645d638 to 0xb645d90c +>>> > (code length 724) [testproj.exe] +>>> > converting method Locale:GetText (string) +>>> > Method Locale:GetText (string) emitted at 0xb645d910 to 0xb645d98c +>>> > (code length 124) [testproj.exe] +>>> > converting method System.Exception:ToString () +>>> > Method System.Exception:ToString () emitted at 0xb645d990 to +>>> > 0xb645dd04 (code length 884) [testproj.exe] +>>> > converting method (wrapper runtime-invoke) +>>> > <Module>:runtime_invoke_object__this__ (object,intptr,intptr,intptr) +>>> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_object__this__ +>>> > (object,intptr,intptr,intptr) emitted at 0xb645dd28 to 0xb645e004 +>>> > (code length 732) [testproj.exe] +>>> > converting method System.Exception:get_ClassName () +>>> > Method System.Exception:get_ClassName () emitted at 0xb645e008 to +>>> > 0xb645e104 (code length 252) [testproj.exe] +>>> > converting method System.Exception:GetType () +>>> > Method System.Exception:GetType () emitted at 0xb645e110 to 0xb645e194 +>>> > (code length 132) [testproj.exe] +>>> > converting method System.MonoType:ToString () +>>> > Method System.MonoType:ToString () emitted at 0xb645e198 to 0xb645e220 +>>> > (code length 136) [testproj.exe] +>>> > converting method (wrapper managed-to-native) +>>> > System.MonoType:getFullName (System.MonoType,bool,bool) +>>> > Method (wrapper managed-to-native) System.MonoType:getFullName +>>> > (System.MonoType,bool,bool) emitted at 0xb645e230 to 0xb645e394 (code +>>> > length 356) [testproj.exe] +>>> > converting method System.Text.StringBuilder:.ctor (string) +>>> > Method System.Text.StringBuilder:.ctor (string) emitted at 0xb645e398 +>>> > to 0xb645e520 (code length 392) [testproj.exe] +>>> > converting method System.Text.StringBuilder:Append (string) +>>> > Method System.Text.StringBuilder:Append (string) emitted at 0xb645e520 +>>> > to 0xb645e8c4 (code length 932) [testproj.exe] +>>> > converting method +>>> > Unhandled Exception: System.ExecutionEngineException: SIGILL +>>> > [ERROR] FATAL UNHANDLED EXCEPTION: System.ExecutionEngineException: +>>> > SIGILL +>>> > +>>> > +>>> > What can i do? +>>> > +>>> > +>>> > thanks Peter +>>> _______________________________________________ +>>> Monodevelop-devel-list mailing list +>>> Monodevelop-devel-list at lists.ximian.com +>>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +> +> +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com ++ + + +
This question would be better asked on the Mono mailing list, not +MonoDevelop. You also will need to provide more info about the version +of Mono and the target platform. + +On 17 February 2012 10:44, Peter Siegel <siegelpeter2009 at gmail.com> wrote: +> ok i'll try to build mono on arm from the sources this weekend. +> Perhaps this will help. Are there any commandline switches which give +> more information about the error or is there a way to attach a +> debugger to the runtime? +> +> thanks Peter +> +> +> Am 15. Februar 2012 20:32 schrieb Michael Hutchinson <m.j.hutchinson at gmail.com>: +>> Unlikely, looks like an illegal instruction, so probably a JIT issue. +>> Maybe a bad Mono build or revision. +>> +>> The reason you have OutOfMemoryException appearing in the traces is +>> that Mono creates that exception at startup, in case it's ever needed, +>> since it won't be possible to create it if the program actually runs +>> out of memory. +>> +>> 2012/2/7 Jeff Stedfast <jeff at xamarin.com>: +>>> Hi Peter, +>>> +>>> Looks like you are running out of memory for some reason. Beyond that, I +>>> have no idea. +>>> +>>> Jeff +>>> +>>> +>>> On Tue, Feb 7, 2012 at 4:09 PM, Peter Siegel <siegelpeter2009 at gmail.com> +>>> wrote: +>>>> +>>>> Hi! +>>>> +>>>> I'm just wondering? Is there who knows about debugging with SDB on +>>>> ARM? the Meego Addin should have been able to do this, and the Mono +>>>> for the Iphone also uses the SDB to debug so i expected it to work. +>>>> I'm willing to investigate this issue on my own, but any help would be +>>>> really appreciated. +>>>> +>>>> thanks +>>>> +>>>> Peter +>>>> +>>>> Am 29. Januar 2012 15:18 schrieb Peter Siegel <siegelpeter2009 at gmail.com>: +>>>> > Hi! +>>>> > +>>>> > I tried to do single step debugging using the mono sdb with +>>>> > monodevelop remotely on an arm target... +>>>> > I modified the Meego addin to be able to debug remotely on any Linux +>>>> > System. It's an Linux Remote Debugging addin now :-) +>>>> > +>>>> > It works very well on the same cpu architecture. Now I can debug my +>>>> > Linux Mono Programs from windows, but some debuging features do not +>>>> > work if the remote target is an Arm Plattform. +>>>> > +>>>> > It connects without an exception and the Programm starts, when the +>>>> > remote program throws an exception, the exception caught window opens +>>>> > with no information at all and instance is "evaluating". On the +>>>> > Remote Arm box, the Mono process has stopped +>>>> > +>>>> > When i insert an breakpoint the Program seems to pauses, but when i +>>>> > press continue it crashes: +>>>> > +>>>> > Loaded assembly: /root/test/testproj.exe +>>>> > Resolved pending breakpoint at +>>>> > 'C:\Users\PeterS\Documents\testproj\testproj\Main.cs:11' to Void +>>>> > testproj.MainClass:Main (String[]) [0x00011]. +>>>> > converting method System.OutOfMemoryException:.ctor (string) +>>>> > Method System.OutOfMemoryException:.ctor (string) emitted at +>>>> > 0xb6ee4b68 to 0xb6ee4c20 (code length 184) [testproj.exe] +>>>> > converting method (wrapper runtime-invoke) +>>>> > <Module>:runtime_invoke_void__this___object +>>>> > (object,intptr,intptr,intptr) +>>>> > Method (wrapper runtime-invoke) +>>>> > <Module>:runtime_invoke_void__this___object +>>>> > (object,intptr,intptr,intptr) emitted at 0xb6ee4c48 to 0xb6ee4f2c +>>>> > (code length 740) [testproj.exe] +>>>> > converting method System.SystemException:.ctor (string) +>>>> > Method System.SystemException:.ctor (string) emitted at 0xb6ee4f30 to +>>>> > 0xb6ee4fe8 (code length 184) [testproj.exe] +>>>> > converting method System.Exception:.ctor (string) +>>>> > Method System.Exception:.ctor (string) emitted at 0xb6ee4ff8 to +>>>> > 0xb6ee50d4 (code length 220) [testproj.exe] +>>>> > converting method System.Exception:set_HResult (int) +>>>> > Method System.Exception:set_HResult (int) emitted at 0xb6ee50d8 to +>>>> > 0xb6ee5160 (code length 136) [testproj.exe] +>>>> > converting method System.NullReferenceException:.ctor (string) +>>>> > Method System.NullReferenceException:.ctor (string) emitted at +>>>> > 0xb6ee5160 to 0xb6ee5218 (code length 184) [testproj.exe] +>>>> > converting method System.StackOverflowException:.ctor (string) +>>>> > Method System.StackOverflowException:.ctor (string) emitted at +>>>> > 0xb6ee5218 to 0xb6ee52a0 (code length 136) [testproj.exe] +>>>> > converting method testproj.MainClass:Main (string[]) +>>>> > Method testproj.MainClass:Main (string[]) emitted at 0xb6ee52b0 to +>>>> > 0xb6ee5490 (code length 480) [testproj.exe] +>>>> > converting method (wrapper runtime-invoke) +>>>> > <Module>:runtime_invoke_void_object (object,intptr,intptr,intptr) +>>>> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_void_object +>>>> > (object,intptr,intptr,intptr) emitted at 0xb6ee54b8 to 0xb6ee5794 +>>>> > (code length 732) [testproj.exe] +>>>> > converting method System.Console:WriteLine (string) +>>>> > Method System.Console:WriteLine (string) emitted at 0xb6ee5798 to +>>>> > 0xb6ee5834 (code length 156) [testproj.exe] +>>>> > converting method System.Console:.cctor () +>>>> > Method System.Console:.cctor () emitted at 0xb6ee5870 to 0xb6ee6358 +>>>> > (code length 2792) [testproj.exe] +>>>> > converting method (wrapper runtime-invoke) object:runtime_invoke_void +>>>> > (object,intptr,intptr,intptr) +>>>> > Method (wrapper runtime-invoke) object:runtime_invoke_void +>>>> > (object,intptr,intptr,intptr) emitted at 0xb6ee6440 to 0xb6ee670c +>>>> > (code length 716) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_fast (intptr) +>>>> > Method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_fast (intptr) emitted at +>>>> > 0xb6ee6718 to 0xb6ee6810 (code length 248) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.Text.Encoding:InternalCodePage (int&) +>>>> > Method (wrapper managed-to-native) +>>>> > System.Text.Encoding:InternalCodePage (int&) emitted at 0xb6ee6810 to +>>>> > 0xb6ee6908 (code length 248) [testproj.exe] +>>>> > converting method System.Text.Encoding:.cctor () +>>>> > Method System.Text.Encoding:.cctor () emitted at 0xb6ee6920 to +>>>> > 0xb6ee7298 (code length 2424) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_array_new_specific (intptr,int) +>>>> > Method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_array_new_specific (intptr,int) emitted at +>>>> > 0xb6ee72a8 to 0xb6ee73a8 (code length 256) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) +>>>> > Method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) emitted at +>>>> > 0xb6ee73a8 to 0xb6ee74a0 (code length 248) [testproj.exe] +>>>> > converting method (wrapper stelemref) object:virt_stelemref_object +>>>> > (intptr,object) +>>>> > Method (wrapper stelemref) object:virt_stelemref_object +>>>> > (intptr,object) emitted at 0xb6ee74a0 to 0xb6ee7558 (code length 184) +>>>> > [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) +>>>> > Method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_ptrfree (intptr) emitted at +>>>> > 0xb6ee7558 to 0xb6ee7650 (code length 248) [testproj.exe] +>>>> > converting method object:.ctor () +>>>> > Method object:.ctor () emitted at 0xb6ee7650 to 0xb6ee76a8 (code +>>>> > length 88) [testproj.exe] +>>>> > converting method System.Text.Encoding:get_UTF8Unmarked () +>>>> > Method System.Text.Encoding:get_UTF8Unmarked () emitted at 0xb6ee76a8 +>>>> > to 0xb6ee792c (code length 644) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.Threading.Monitor:Enter (object) +>>>> > Method (wrapper managed-to-native) System.Threading.Monitor:Enter +>>>> > (object) emitted at 0xb6ee7950 to 0xb6ee7a8c (code length 316) +>>>> > [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:.ctor (bool,bool) +>>>> > Method System.Text.UTF8Encoding:.ctor (bool,bool) emitted at +>>>> > 0xb6ee7a90 to 0xb6ee7d94 (code length 772) [testproj.exe] +>>>> > converting method System.Text.Encoding:.ctor (int) +>>>> > Method System.Text.Encoding:.ctor (int) emitted at 0xb6ee7de0 to +>>>> > 0xb6ee8258 (code length 1144) [testproj.exe] +>>>> > converting method System.Text.DecoderFallback:get_StandardSafeFallback +>>>> > () +>>>> > converting method System.Text.DecoderFallback:.cctor () +>>>> > Method System.Text.DecoderFallback:.cctor () emitted at 0xb6ee8270 to +>>>> > 0xb6ee83a0 (code length 304) [testproj.exe] +>>>> > converting method System.Text.DecoderExceptionFallback:.ctor () +>>>> > Method System.Text.DecoderExceptionFallback:.ctor () emitted at +>>>> > 0xb6ee83c8 to 0xb6ee8448 (code length 128) [testproj.exe] +>>>> > converting method System.Text.DecoderFallback:.ctor () +>>>> > Method System.Text.DecoderFallback:.ctor () emitted at 0xb6ee8458 to +>>>> > 0xb6ee84d4 (code length 124) [testproj.exe] +>>>> > converting method System.Text.DecoderReplacementFallback:.ctor () +>>>> > Method System.Text.DecoderReplacementFallback:.ctor () emitted at +>>>> > 0xb6ee84d8 to 0xb6ee8560 (code length 136) [testproj.exe] +>>>> > converting method System.Text.DecoderReplacementFallback:.ctor (string) +>>>> > Method System.Text.DecoderReplacementFallback:.ctor (string) emitted +>>>> > at 0xb6ee8560 to 0xb6ee866c (code length 268) [testproj.exe] +>>>> > Method System.Text.DecoderFallback:get_StandardSafeFallback () emitted +>>>> > at 0xb6ee8670 to 0xb6ee86ec (code length 124) [testproj.exe] +>>>> > converting method System.Text.EncoderFallback:get_StandardSafeFallback +>>>> > () +>>>> > converting method System.Text.EncoderFallback:.cctor () +>>>> > Method System.Text.EncoderFallback:.cctor () emitted at 0xb6ee86f0 to +>>>> > 0xb6ee8820 (code length 304) [testproj.exe] +>>>> > converting method System.Text.EncoderExceptionFallback:.ctor () +>>>> > Method System.Text.EncoderExceptionFallback:.ctor () emitted at +>>>> > 0xb6ee8848 to 0xb6ee88c8 (code length 128) [testproj.exe] +>>>> > converting method System.Text.EncoderFallback:.ctor () +>>>> > Method System.Text.EncoderFallback:.ctor () emitted at 0xb6ee88d8 to +>>>> > 0xb6ee8954 (code length 124) [testproj.exe] +>>>> > converting method System.Text.EncoderReplacementFallback:.ctor () +>>>> > Method System.Text.EncoderReplacementFallback:.ctor () emitted at +>>>> > 0xb6ee8958 to 0xb6ee89e0 (code length 136) [testproj.exe] +>>>> > converting method System.Text.EncoderReplacementFallback:.ctor (string) +>>>> > Method System.Text.EncoderReplacementFallback:.ctor (string) emitted +>>>> > at 0xb6ee89e0 to 0xb6ee8aec (code length 268) [testproj.exe] +>>>> > Method System.Text.EncoderFallback:get_StandardSafeFallback () emitted +>>>> > at 0xb6ee8af0 to 0xb6ee8b6c (code length 124) [testproj.exe] +>>>> > converting method System.Text.Encoding:SetFallbackInternal +>>>> > (System.Text.EncoderFallback,System.Text.DecoderFallback) +>>>> > Method System.Text.Encoding:SetFallbackInternal +>>>> > (System.Text.EncoderFallback,System.Text.DecoderFallback) emitted at +>>>> > 0xb6ee8b70 to 0xb6ee8c80 (code length 272) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.Threading.Monitor:Exit (object) +>>>> > Method (wrapper managed-to-native) System.Threading.Monitor:Exit +>>>> > (object) emitted at 0xb6ee8c80 to 0xb6ee8dbc (code length 316) +>>>> > [testproj.exe] +>>>> > converting method System.Console:OpenStandardError (int) +>>>> > Method System.Console:OpenStandardError (int) emitted at 0xb6ee8dc0 to +>>>> > 0xb6ee8e48 (code length 136) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.IO.MonoIO:get_ConsoleError () +>>>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleError +>>>> > () emitted at 0xb6ee8e60 to 0xb6ee8f50 (code length 240) +>>>> > [testproj.exe] +>>>> > converting method System.IO.MonoIO:.cctor () +>>>> > Method System.IO.MonoIO:.cctor () emitted at 0xb6ee8f50 to 0xb6ee9010 +>>>> > (code length 192) [testproj.exe] +>>>> > converting method intptr:op_Explicit (long) +>>>> > Method intptr:op_Explicit (long) emitted at 0xb6ee9020 to 0xb6ee90c0 +>>>> > (code length 160) [testproj.exe] +>>>> > converting method intptr:.ctor (long) +>>>> > Method intptr:.ctor (long) emitted at 0xb6ee90d0 to 0xb6ee9160 (code +>>>> > length 144) [testproj.exe] +>>>> > converting method System.Console:Open (intptr,System.IO.FileAccess,int) +>>>> > Method System.Console:Open (intptr,System.IO.FileAccess,int) emitted +>>>> > at 0xb6ee9160 to 0xb6ee9354 (code length 500) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_specific (intptr) +>>>> > Method (wrapper managed-to-native) +>>>> > object:__icall_wrapper_mono_object_new_specific (intptr) emitted at +>>>> > 0xb6ee9370 to 0xb6ee9468 (code length 248) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.FileStream:.ctor +>>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +>>>> > Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor +>>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee9468 +>>>> > to 0xb6ee9628 (code length 448) [testproj.exe] +>>>> > converting method System.IO.FileStream:.cctor () +>>>> > Method System.IO.FileStream:.cctor () emitted at 0xb6ee9640 to +>>>> > 0xb6ee96d8 (code length 152) [testproj.exe] +>>>> > converting method System.IO.FileStream:.ctor +>>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) +>>>> > Method System.IO.FileStream:.ctor +>>>> > (intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee96e8 +>>>> > to 0xb6ee9d74 (code length 1676) [testproj.exe] +>>>> > converting method System.IO.Stream:.ctor () +>>>> > Method System.IO.Stream:.ctor () emitted at 0xb6ee9dc8 to 0xb6ee9e48 +>>>> > (code length 128) [testproj.exe] +>>>> > converting method System.IO.Stream:.cctor () +>>>> > Method System.IO.Stream:.cctor () emitted at 0xb6ee9e58 to 0xb6ee9efc +>>>> > (code length 164) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.NullStream:.ctor () +>>>> > Method (wrapper remoting-invoke-with-check) System.IO.NullStream:.ctor +>>>> > () emitted at 0xb6ee9f00 to 0xb6ee9fd4 (code length 212) +>>>> > [testproj.exe] +>>>> > converting method System.IO.NullStream:.ctor () +>>>> > Method System.IO.NullStream:.ctor () emitted at 0xb6ee9ff0 to +>>>> > 0xb6eea070 (code length 128) [testproj.exe] +>>>> > converting method System.MarshalByRefObject:.ctor () +>>>> > Method System.MarshalByRefObject:.ctor () emitted at 0xb6eea070 to +>>>> > 0xb6eea0ec (code length 124) [testproj.exe] +>>>> > converting method intptr:op_Equality (intptr,intptr) +>>>> > Method intptr:op_Equality (intptr,intptr) emitted at 0xb6eea0f0 to +>>>> > 0xb6eea188 (code length 152) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.IO.MonoIO:GetFileType (intptr,System.IO.MonoIOError&) +>>>> > Method (wrapper managed-to-native) System.IO.MonoIO:GetFileType +>>>> > (intptr,System.IO.MonoIOError&) emitted at 0xb6eea188 to 0xb6eea288 +>>>> > (code length 256) [testproj.exe] +>>>> > converting method System.IO.FileStream:InitBuffer (int,bool) +>>>> > Method System.IO.FileStream:InitBuffer (int,bool) emitted at +>>>> > 0xb6eea288 to 0xb6eea72c (code length 1188) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.UnexceptionalStreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.UnexceptionalStreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea748 to +>>>> > 0xb6eea844 (code length 252) [testproj.exe] +>>>> > converting method System.IO.UnexceptionalStreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) +>>>> > Method System.IO.UnexceptionalStreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea860 to +>>>> > 0xb6eea8f0 (code length 144) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) +>>>> > Method System.IO.StreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea900 to +>>>> > 0xb6eea994 (code length 148) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:.cctor () +>>>> > Method System.IO.StreamWriter:.cctor () emitted at 0xb6eea9a0 to +>>>> > 0xb6eeaa74 (code length 212) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.StreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding,int) +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.StreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaa80 to +>>>> > 0xb6eeab98 (code length 280) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding,int) +>>>> > Method System.IO.StreamWriter:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaba8 to +>>>> > 0xb6eeae54 (code length 684) [testproj.exe] +>>>> > converting method System.IO.TextWriter:.ctor () +>>>> > Method System.IO.TextWriter:.ctor () emitted at 0xb6eeae70 to +>>>> > 0xb6eeaf34 (code length 196) [testproj.exe] +>>>> > converting method System.IO.TextWriter:.cctor () +>>>> > Method System.IO.TextWriter:.cctor () emitted at 0xb6eeaf50 to +>>>> > 0xb6eeaff4 (code length 164) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.TextWriter/NullTextWriter:.ctor () +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.TextWriter/NullTextWriter:.ctor () emitted at 0xb6eeb000 to +>>>> > 0xb6eeb0d4 (code length 212) [testproj.exe] +>>>> > converting method System.IO.TextWriter/NullTextWriter:.ctor () +>>>> > Method System.IO.TextWriter/NullTextWriter:.ctor () emitted at +>>>> > 0xb6eeb0f0 to 0xb6eeb170 (code length 128) [testproj.exe] +>>>> > converting method System.Environment:get_NewLine () +>>>> > Method System.Environment:get_NewLine () emitted at 0xb6eeb170 to +>>>> > 0xb6eeb2a8 (code length 312) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.Environment:GetNewLine () +>>>> > Method (wrapper managed-to-native) System.Environment:GetNewLine () +>>>> > emitted at 0xb6eeb2b8 to 0xb6eeb3a8 (code length 240) [testproj.exe] +>>>> > converting method string:ToCharArray () +>>>> > Method string:ToCharArray () emitted at 0xb6eeb3a8 to 0xb6eeb434 (code +>>>> > length 140) [testproj.exe] +>>>> > converting method string:.cctor () +>>>> > Method string:.cctor () emitted at 0xb6eeb440 to 0xb6eeb554 (code +>>>> > length 276) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) string:GetLOSLimit () +>>>> > Method (wrapper managed-to-native) string:GetLOSLimit () emitted at +>>>> > 0xb6eeb570 to 0xb6eeb660 (code length 240) [testproj.exe] +>>>> > converting method string:memcpy (byte*,byte*,int) +>>>> > Method string:memcpy (byte*,byte*,int) emitted at 0xb6eeb660 to +>>>> > 0xb6eebac8 (code length 1128) [testproj.exe] +>>>> > converting method string:memcpy4 (byte*,byte*,int) +>>>> > Method string:memcpy4 (byte*,byte*,int) emitted at 0xb6eebaf0 to +>>>> > 0xb6eebf10 (code length 1056) [testproj.exe] +>>>> > converting method string:ToCharArray (int,int) +>>>> > Method string:ToCharArray (int,int) emitted at 0xb6eebf10 to +>>>> > 0xb6eec32c (code length 1052) [testproj.exe] +>>>> > converting method string:CharCopy (char*,char*,int) +>>>> > Method string:CharCopy (char*,char*,int) emitted at 0xb6eec338 to +>>>> > 0xb6eec5d8 (code length 672) [testproj.exe] +>>>> > converting method System.IO.NullStream:get_CanWrite () +>>>> > Method System.IO.NullStream:get_CanWrite () emitted at 0xb6eec5d8 to +>>>> > 0xb6eec654 (code length 124) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:Initialize +>>>> > (System.Text.Encoding,int) +>>>> > Method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +>>>> > emitted at 0xb6eec658 to 0xb6eec8f4 (code length 668) [testproj.exe] +>>>> > converting method System.Math:Max (int,int) +>>>> > Method System.Math:Max (int,int) emitted at 0xb6eec8f8 to 0xb6eec9dc +>>>> > (code length 228) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:GetMaxByteCount (int) +>>>> > Method System.Text.UTF8Encoding:GetMaxByteCount (int) emitted at +>>>> > 0xb6eec9e0 to 0xb6eecaec (code length 268) [testproj.exe] +>>>> > converting method System.IO.NullStream:get_CanSeek () +>>>> > Method System.IO.NullStream:get_CanSeek () emitted at 0xb6eecaf8 to +>>>> > 0xb6eecb74 (code length 124) [testproj.exe] +>>>> > converting method System.IO.NullStream:get_Position () +>>>> > Method System.IO.NullStream:get_Position () emitted at 0xb6eecb78 to +>>>> > 0xb6eecbf8 (code length 128) [testproj.exe] +>>>> > converting method System.IO.FileStream:get_CanWrite () +>>>> > Method System.IO.FileStream:get_CanWrite () emitted at 0xb6eecbf8 to +>>>> > 0xb6eeccf0 (code length 248) [testproj.exe] +>>>> > converting method System.IO.FileStream:get_CanSeek () +>>>> > Method System.IO.FileStream:get_CanSeek () emitted at 0xb6eeccf0 to +>>>> > 0xb6eecd70 (code length 128) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:set_AutoFlush (bool) +>>>> > Method System.IO.StreamWriter:set_AutoFlush (bool) emitted at +>>>> > 0xb6eecd70 to 0xb6eece5c (code length 236) [testproj.exe] +>>>> > converting method System.IO.UnexceptionalStreamWriter:Flush () +>>>> > Method System.IO.UnexceptionalStreamWriter:Flush () emitted at +>>>> > 0xb6eece60 to 0xb6eecf4c (code length 236) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:Flush () +>>>> > Method System.IO.StreamWriter:Flush () emitted at 0xb6eecf58 to +>>>> > 0xb6eed0dc (code length 388) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:Decode () +>>>> > Method System.IO.StreamWriter:Decode () emitted at 0xb6eed0f8 to +>>>> > 0xb6eed308 (code length 528) [testproj.exe] +>>>> > converting method System.IO.TextWriter:Synchronized +>>>> > (System.IO.TextWriter,bool) +>>>> > Method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +>>>> > emitted at 0xb6eed320 to 0xb6eed5c0 (code length 672) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) emitted +>>>> > at 0xb6eed5d8 to 0xb6eed6d4 (code length 252) [testproj.exe] +>>>> > converting method System.IO.SynchronizedWriter:.ctor +>>>> > (System.IO.TextWriter,bool) +>>>> > Method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +>>>> > emitted at 0xb6eed6f0 to 0xb6eed7d0 (code length 224) [testproj.exe] +>>>> > converting method System.ConsoleDriver:get_IsConsole () +>>>> > Method System.ConsoleDriver:get_IsConsole () emitted at 0xb6eed7d0 to +>>>> > 0xb6eed9b0 (code length 480) [testproj.exe] +>>>> > converting method System.ConsoleDriver:.cctor () +>>>> > Method System.ConsoleDriver:.cctor () emitted at 0xb6eed9e0 to +>>>> > 0xb6eedc6c (code length 652) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.IO.MonoIO:get_ConsoleOutput () +>>>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleOutput +>>>> > () emitted at 0xb6eedca8 to 0xb6eedd98 (code length 240) +>>>> > [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.ConsoleDriver:Isatty (intptr) +>>>> > Method (wrapper managed-to-native) System.ConsoleDriver:Isatty +>>>> > (intptr) emitted at 0xb6eedd98 to 0xb6eede90 (code length 248) +>>>> > [testproj.exe] +>>>> > converting method System.ConsoleDriver:CreateNullConsoleDriver () +>>>> > Method System.ConsoleDriver:CreateNullConsoleDriver () emitted at +>>>> > 0xb6eede90 to 0xb6eedf1c (code length 140) [testproj.exe] +>>>> > converting method System.NullConsoleDriver:.ctor () +>>>> > Method System.NullConsoleDriver:.ctor () emitted at 0xb6eedf28 to +>>>> > 0xb6eedfa4 (code length 124) [testproj.exe] +>>>> > converting method System.Console:OpenStandardOutput (int) +>>>> > Method System.Console:OpenStandardOutput (int) emitted at 0xb6eedfa8 +>>>> > to 0xb6eee030 (code length 136) [testproj.exe] +>>>> > converting method System.Console:OpenStandardInput (int) +>>>> > Method System.Console:OpenStandardInput (int) emitted at 0xb6eee030 to +>>>> > 0xb6eee0b8 (code length 136) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.IO.MonoIO:get_ConsoleInput () +>>>> > Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleInput +>>>> > () emitted at 0xb6eee0b8 to 0xb6eee1a8 (code length 240) +>>>> > [testproj.exe] +>>>> > converting method System.IO.UnexceptionalStreamReader:.cctor () +>>>> > Method System.IO.UnexceptionalStreamReader:.cctor () emitted at +>>>> > 0xb6eee1a8 to 0xb6eee300 (code length 344) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.UnexceptionalStreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.UnexceptionalStreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee300 to +>>>> > 0xb6eee3fc (code length 252) [testproj.exe] +>>>> > converting method System.IO.UnexceptionalStreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) +>>>> > Method System.IO.UnexceptionalStreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee418 to +>>>> > 0xb6eee4a8 (code length 144) [testproj.exe] +>>>> > converting method System.IO.StreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) +>>>> > Method System.IO.StreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee4b8 to +>>>> > 0xb6eee554 (code length 156) [testproj.exe] +>>>> > converting method System.IO.StreamReader:.cctor () +>>>> > Method System.IO.StreamReader:.cctor () emitted at 0xb6eee560 to +>>>> > 0xb6eee648 (code length 232) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.StreamReader/NullStreamReader:.ctor () +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.StreamReader/NullStreamReader:.ctor () emitted at 0xb6eee658 +>>>> > to 0xb6eee72c (code length 212) [testproj.exe] +>>>> > converting method System.IO.StreamReader/NullStreamReader:.ctor () +>>>> > Method System.IO.StreamReader/NullStreamReader:.ctor () emitted at +>>>> > 0xb6eee748 to 0xb6eee7c8 (code length 128) [testproj.exe] +>>>> > converting method System.IO.StreamReader:.ctor () +>>>> > Method System.IO.StreamReader:.ctor () emitted at 0xb6eee7d8 to +>>>> > 0xb6eee858 (code length 128) [testproj.exe] +>>>> > converting method System.IO.TextReader:.ctor () +>>>> > Method System.IO.TextReader:.ctor () emitted at 0xb6eee868 to +>>>> > 0xb6eee8e8 (code length 128) [testproj.exe] +>>>> > converting method System.IO.TextReader:.cctor () +>>>> > Method System.IO.TextReader:.cctor () emitted at 0xb6eee8e8 to +>>>> > 0xb6eee98c (code length 164) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.TextReader/NullTextReader:.ctor () +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.TextReader/NullTextReader:.ctor () emitted at 0xb6eee998 to +>>>> > 0xb6eeea6c (code length 212) [testproj.exe] +>>>> > converting method System.IO.TextReader/NullTextReader:.ctor () +>>>> > Method System.IO.TextReader/NullTextReader:.ctor () emitted at +>>>> > 0xb6eeea88 to 0xb6eeeb08 (code length 128) [testproj.exe] +>>>> > converting method System.IO.StreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding,bool,int) +>>>> > Method System.IO.StreamReader:.ctor +>>>> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeeb08 +>>>> > to 0xb6eeebd8 (code length 208) [testproj.exe] +>>>> > converting method System.IO.StreamReader:Initialize +>>>> > (System.IO.Stream,System.Text.Encoding,bool,int) +>>>> > Method System.IO.StreamReader:Initialize +>>>> > (System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeebe8 +>>>> > to 0xb6eef5b8 (code length 2512) [testproj.exe] +>>>> > converting method System.IO.FileStream:get_CanRead () +>>>> > Method System.IO.FileStream:get_CanRead () emitted at 0xb6eef5b8 to +>>>> > 0xb6eef6b0 (code length 248) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:GetMaxCharCount (int) +>>>> > Method System.Text.UTF8Encoding:GetMaxCharCount (int) emitted at +>>>> > 0xb6eef6b0 to 0xb6eef7b8 (code length 264) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:GetDecoder () +>>>> > Method System.Text.UTF8Encoding:GetDecoder () emitted at 0xb6eef7b8 to +>>>> > 0xb6eef858 (code length 160) [testproj.exe] +>>>> > converting method System.Text.Encoding:get_DecoderFallback () +>>>> > Method System.Text.Encoding:get_DecoderFallback () emitted at +>>>> > 0xb6eef870 to 0xb6eef8f0 (code length 128) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding/UTF8Decoder:.ctor +>>>> > (System.Text.DecoderFallback) +>>>> > Method System.Text.UTF8Encoding/UTF8Decoder:.ctor +>>>> > (System.Text.DecoderFallback) emitted at 0xb6eef8f0 to 0xb6eef9f8 +>>>> > (code length 264) [testproj.exe] +>>>> > converting method System.Text.Decoder:.ctor () +>>>> > Method System.Text.Decoder:.ctor () emitted at 0xb6eefa10 to +>>>> > 0xb6eefad4 (code length 196) [testproj.exe] +>>>> > converting method System.Text.Decoder:set_Fallback +>>>> > (System.Text.DecoderFallback) +>>>> > Method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +>>>> > emitted at 0xb6eefad8 to 0xb6eefbe8 (code length 272) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:GetPreamble () +>>>> > Method System.Text.UTF8Encoding:GetPreamble () emitted at 0xb6eefbe8 +>>>> > to 0xb6eefd10 (code length 296) [testproj.exe] +>>>> > converting method (wrapper stfld) +>>>> > object:__stfld_wrapper_0x34ee68_System.Int32 +>>>> > (object,intptr,intptr,intptr,int) +>>>> > Method (wrapper stfld) object:__stfld_wrapper_0x34ee68_System.Int32 +>>>> > (object,intptr,intptr,intptr,int) emitted at 0xb6eefd10 to 0xb6eefe7c +>>>> > (code length 364) [testproj.exe] +>>>> > converting method (wrapper ldfld) +>>>> > object:__ldfld_wrapper_0x34ee68_System.Int32 +>>>> > (object,intptr,intptr,intptr) +>>>> > Method (wrapper ldfld) object:__ldfld_wrapper_0x34ee68_System.Int32 +>>>> > (object,intptr,intptr,intptr) emitted at 0xb6eefe88 to 0xb6eeffd8 +>>>> > (code length 336) [testproj.exe] +>>>> > converting method System.IO.TextReader:Synchronized +>>>> > (System.IO.TextReader) +>>>> > Method System.IO.TextReader:Synchronized (System.IO.TextReader) +>>>> > emitted at 0xb6eeffe8 to 0xb6ef0278 (code length 656) [testproj.exe] +>>>> > converting method (wrapper remoting-invoke-with-check) +>>>> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +>>>> > Method (wrapper remoting-invoke-with-check) +>>>> > System.IO.SynchronizedReader:.ctor (System.IO.TextReader) emitted at +>>>> > 0xb6ef0290 to 0xb6ef0378 (code length 232) [testproj.exe] +>>>> > converting method System.IO.SynchronizedReader:.ctor +>>>> > (System.IO.TextReader) +>>>> > Method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +>>>> > emitted at 0xb6ef0390 to 0xb6ef0440 (code length 176) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.GC:SuppressFinalize (object) +>>>> > Method (wrapper managed-to-native) System.GC:SuppressFinalize (object) +>>>> > emitted at 0xb6ef0440 to 0xb6ef057c (code length 316) [testproj.exe] +>>>> > converting method System.IO.SynchronizedWriter:WriteLine (string) +>>>> > Method System.IO.SynchronizedWriter:WriteLine (string) emitted at +>>>> > 0xb6ef0580 to 0xb6ef06ec (code length 364) [testproj.exe] +>>>> > converting method System.IO.TextWriter:WriteLine (string) +>>>> > Method System.IO.TextWriter:WriteLine (string) emitted at 0xb6ef06f0 +>>>> > to 0xb6ef07b8 (code length 200) [testproj.exe] +>>>> > converting method System.IO.UnexceptionalStreamWriter:Write (string) +>>>> > Method System.IO.UnexceptionalStreamWriter:Write (string) emitted at +>>>> > 0xb6ef07b8 to 0xb6ef08ac (code length 244) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:Write (string) +>>>> > Method System.IO.StreamWriter:Write (string) emitted at 0xb6ef08b8 to +>>>> > 0xb6ef0a40 (code length 392) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:LowLevelWrite (string) +>>>> > Method System.IO.StreamWriter:LowLevelWrite (string) emitted at +>>>> > 0xb6ef0a50 to 0xb6ef0e94 (code length 1092) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:GetBytes +>>>> > (char[],int,int,byte[],int) +>>>> > Method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +>>>> > emitted at 0xb6ef0e98 to 0xb6ef1010 (code length 376) [testproj.exe] +>>>> > converting method System.Text.Encoding:get_EncoderFallback () +>>>> > Method System.Text.Encoding:get_EncoderFallback () emitted at +>>>> > 0xb6ef1028 to 0xb6ef10a8 (code length 128) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:InternalGetBytes +>>>> > +>>>> > (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>>> > Method System.Text.UTF8Encoding:InternalGetBytes +>>>> > +>>>> > (char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>>> > emitted at 0xb6ef10a8 to 0xb6ef1878 (code length 2000) [testproj.exe] +>>>> > converting method System.Text.UTF8Encoding:InternalGetBytes +>>>> > +>>>> > (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>>> > Method System.Text.UTF8Encoding:InternalGetBytes +>>>> > +>>>> > (char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +>>>> > emitted at 0xb645a000 to 0xb645b31c (code length 4892) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:FlushBytes () +>>>> > Method System.IO.StreamWriter:FlushBytes () emitted at 0xb645b338 to +>>>> > 0xb645b558 (code length 544) [testproj.exe] +>>>> > converting method System.IO.FileStream:Write (byte[],int,int) +>>>> > Method System.IO.FileStream:Write (byte[],int,int) emitted at +>>>> > 0xb645b558 to 0xb645b9cc (code length 1140) [testproj.exe] +>>>> > converting method System.IO.FileStream:WriteInternal (byte[],int,int) +>>>> > Method System.IO.FileStream:WriteInternal (byte[],int,int) emitted at +>>>> > 0xb645b9d8 to 0xb645bed0 (code length 1272) [testproj.exe] +>>>> > converting method System.IO.FileStream:FlushBuffer () +>>>> > Method System.IO.FileStream:FlushBuffer () emitted at 0xb645bf18 to +>>>> > 0xb645bf9c (code length 132) [testproj.exe] +>>>> > converting method System.IO.FileStream:FlushBuffer (System.IO.Stream) +>>>> > Method System.IO.FileStream:FlushBuffer (System.IO.Stream) emitted at +>>>> > 0xb645bfa8 to 0xb645c4fc (code length 1364) [testproj.exe] +>>>> > converting method (wrapper ldfld) +>>>> > object:__ldfld_wrapper_0x350250_System.Int64 +>>>> > (object,intptr,intptr,intptr) +>>>> > Method (wrapper ldfld) object:__ldfld_wrapper_0x350250_System.Int64 +>>>> > (object,intptr,intptr,intptr) emitted at 0xb645c500 to 0xb645c654 +>>>> > (code length 340) [testproj.exe] +>>>> > coStarted +>>>> > nverting method (wrapper stfld) +>>>> > object:__stfld_wrapper_0x350250_System.Int64 +>>>> > (object,intptr,intptr,intptr,long) +>>>> > Method (wrapper stfld) object:__stfld_wrapper_0x350250_System.Int64 +>>>> > (object,intptr,intptr,intptr,long) emitted at 0xb645c658 to 0xb645c7e4 +>>>> > (code length 396) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) System.IO.MonoIO:Write +>>>> > (intptr,byte[],int,int,System.IO.MonoIOError&) +>>>> > Method (wrapper managed-to-native) System.IO.MonoIO:Write +>>>> > (intptr,byte[],int,int,System.IO.MonoIOError&) emitted at 0xb645c7e8 +>>>> > to 0xb645c918 (code length 304) [testproj.exe] +>>>> > converting method System.IO.FileStream:Flush () +>>>> > Method System.IO.FileStream:Flush () emitted at 0xb645c918 to +>>>> > 0xb645ca18 (code length 256) [testproj.exe] +>>>> > converting method System.IO.TextWriter:WriteLine () +>>>> > Method System.IO.TextWriter:WriteLine () emitted at 0xb645ca18 to +>>>> > 0xb645caac (code length 148) [testproj.exe] +>>>> > converting method System.IO.UnexceptionalStreamWriter:Write (char[]) +>>>> > Method System.IO.UnexceptionalStreamWriter:Write (char[]) emitted at +>>>> > 0xb645cab0 to 0xb645cba4 (code length 244) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:Write (char[]) +>>>> > Method System.IO.StreamWriter:Write (char[]) emitted at 0xb645cbb0 to +>>>> > 0xb645cd44 (code length 404) [testproj.exe] +>>>> > converting method System.IO.StreamWriter:LowLevelWrite (char[],int,int) +>>>> > Method System.IO.StreamWriter:LowLevelWrite (char[],int,int) emitted +>>>> > at 0xb645cd50 to 0xb645d04c (code length 764) [testproj.exe] +>>>> > converting method System.Buffer:BlockCopy +>>>> > (System.Array,int,System.Array,int,int) +>>>> > Method System.Buffer:BlockCopy (System.Array,int,System.Array,int,int) +>>>> > emitted at 0xb645d058 to 0xb645d458 (code length 1024) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.Buffer:BlockCopyInternal +>>>> > (System.Array,int,System.Array,int,int) +>>>> > Method (wrapper managed-to-native) System.Buffer:BlockCopyInternal +>>>> > (System.Array,int,System.Array,int,int) emitted at 0xb645d470 to +>>>> > 0xb645d5a0 (code length 304) [testproj.exe] +>>>> > converting method System.ExecutionEngineException:.ctor () +>>>> > Method System.ExecutionEngineException:.ctor () emitted at 0xb645d5a0 +>>>> > to 0xb645d638 (code length 152) [testproj.exe] +>>>> > converting method (wrapper runtime-invoke) +>>>> > object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) +>>>> > Method (wrapper runtime-invoke) object:runtime_invoke_void__this__ +>>>> > (object,intptr,intptr,intptr) emitted at 0xb645d638 to 0xb645d90c +>>>> > (code length 724) [testproj.exe] +>>>> > converting method Locale:GetText (string) +>>>> > Method Locale:GetText (string) emitted at 0xb645d910 to 0xb645d98c +>>>> > (code length 124) [testproj.exe] +>>>> > converting method System.Exception:ToString () +>>>> > Method System.Exception:ToString () emitted at 0xb645d990 to +>>>> > 0xb645dd04 (code length 884) [testproj.exe] +>>>> > converting method (wrapper runtime-invoke) +>>>> > <Module>:runtime_invoke_object__this__ (object,intptr,intptr,intptr) +>>>> > Method (wrapper runtime-invoke) <Module>:runtime_invoke_object__this__ +>>>> > (object,intptr,intptr,intptr) emitted at 0xb645dd28 to 0xb645e004 +>>>> > (code length 732) [testproj.exe] +>>>> > converting method System.Exception:get_ClassName () +>>>> > Method System.Exception:get_ClassName () emitted at 0xb645e008 to +>>>> > 0xb645e104 (code length 252) [testproj.exe] +>>>> > converting method System.Exception:GetType () +>>>> > Method System.Exception:GetType () emitted at 0xb645e110 to 0xb645e194 +>>>> > (code length 132) [testproj.exe] +>>>> > converting method System.MonoType:ToString () +>>>> > Method System.MonoType:ToString () emitted at 0xb645e198 to 0xb645e220 +>>>> > (code length 136) [testproj.exe] +>>>> > converting method (wrapper managed-to-native) +>>>> > System.MonoType:getFullName (System.MonoType,bool,bool) +>>>> > Method (wrapper managed-to-native) System.MonoType:getFullName +>>>> > (System.MonoType,bool,bool) emitted at 0xb645e230 to 0xb645e394 (code +>>>> > length 356) [testproj.exe] +>>>> > converting method System.Text.StringBuilder:.ctor (string) +>>>> > Method System.Text.StringBuilder:.ctor (string) emitted at 0xb645e398 +>>>> > to 0xb645e520 (code length 392) [testproj.exe] +>>>> > converting method System.Text.StringBuilder:Append (string) +>>>> > Method System.Text.StringBuilder:Append (string) emitted at 0xb645e520 +>>>> > to 0xb645e8c4 (code length 932) [testproj.exe] +>>>> > converting method +>>>> > Unhandled Exception: System.ExecutionEngineException: SIGILL +>>>> > [ERROR] FATAL UNHANDLED EXCEPTION: System.ExecutionEngineException: +>>>> > SIGILL +>>>> > +>>>> > +>>>> > What can i do? +>>>> > +>>>> > +>>>> > thanks Peter +>>>> _______________________________________________ +>>>> Monodevelop-devel-list mailing list +>>>> Monodevelop-devel-list at lists.ximian.com +>>>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>>> +>>> +>>> +>>> _______________________________________________ +>>> Monodevelop-devel-list mailing list +>>> Monodevelop-devel-list at lists.ximian.com +>>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>>> +>> +>> +>> +>> -- +>> Michael Hutchinson +>> http://mjhutchinson.com +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Tue Feb 7 21:09:01 UTC 2012
+ Ending: Fri Feb 17 16:07:04 UTC 2012
+ Messages: 5
+
+ Last message date:
+ Fri Feb 17 16:07:04 UTC 2012
+ Archived on: Fri Feb 17 16:07:12 UTC 2012
+
+
+
Starting: Tue Feb 7 21:09:01 UTC 2012
+ Ending: Fri Feb 17 16:07:04 UTC 2012
+ Messages: 5
+
+ Last message date:
+ Fri Feb 17 16:07:04 UTC 2012
+ Archived on: Fri Feb 17 16:07:12 UTC 2012
+
+
+
Starting: Tue Feb 7 21:09:01 UTC 2012
+ Ending: Fri Feb 17 16:07:04 UTC 2012
+ Messages: 5
+
+ Last message date:
+ Fri Feb 17 16:07:04 UTC 2012
+ Archived on: Fri Feb 17 16:07:12 UTC 2012
+
+
+
Starting: Tue Feb 7 21:09:01 UTC 2012
+ Ending: Fri Feb 17 16:07:04 UTC 2012
+ Messages: 5
+
+ Last message date:
+ Fri Feb 17 16:07:04 UTC 2012
+ Archived on: Fri Feb 17 16:07:12 UTC 2012
+
+
+
Starting: Tue Feb 7 21:09:01 UTC 2012
+ Ending: Fri Feb 17 16:07:04 UTC 2012
+ Messages: 5
+
+ Last message date:
+ Fri Feb 17 16:07:04 UTC 2012
+ Archived on: Fri Feb 17 16:07:12 UTC 2012
+
+
+
Hi! + +I tried to do single step debugging using the mono sdb with +monodevelop remotely on an arm target... +I modified the Meego addin to be able to debug remotely on any Linux +System. It's an Linux Remote Debugging addin now :-) + +It works very well on the same cpu architecture. Now I can debug my +Linux Mono Programs from windows, but some debuging features do not +work if the remote target is an Arm Plattform. + +It connects without an exception and the Programm starts, when the +remote program throws an exception, the exception caught window opens +with no information at all and instance is "evaluating". On the +Remote Arm box, the Mono process has stopped + +When i insert an breakpoint the Program seems to pauses, but when i +press continue it crashes: + +Loaded assembly: /root/test/testproj.exe +Resolved pending breakpoint at +'C:\Users\PeterS\Documents\testproj\testproj\Main.cs:11' to Void +testproj.MainClass:Main (String[]) [0x00011]. +converting method System.OutOfMemoryException:.ctor (string) +Method System.OutOfMemoryException:.ctor (string) emitted at +0xb6ee4b68 to 0xb6ee4c20 (code length 184) [testproj.exe] +converting method (wrapper runtime-invoke) +<Module>:runtime_invoke_void__this___object +(object,intptr,intptr,intptr) +Method (wrapper runtime-invoke) +<Module>:runtime_invoke_void__this___object +(object,intptr,intptr,intptr) emitted at 0xb6ee4c48 to 0xb6ee4f2c +(code length 740) [testproj.exe] +converting method System.SystemException:.ctor (string) +Method System.SystemException:.ctor (string) emitted at 0xb6ee4f30 to +0xb6ee4fe8 (code length 184) [testproj.exe] +converting method System.Exception:.ctor (string) +Method System.Exception:.ctor (string) emitted at 0xb6ee4ff8 to +0xb6ee50d4 (code length 220) [testproj.exe] +converting method System.Exception:set_HResult (int) +Method System.Exception:set_HResult (int) emitted at 0xb6ee50d8 to +0xb6ee5160 (code length 136) [testproj.exe] +converting method System.NullReferenceException:.ctor (string) +Method System.NullReferenceException:.ctor (string) emitted at +0xb6ee5160 to 0xb6ee5218 (code length 184) [testproj.exe] +converting method System.StackOverflowException:.ctor (string) +Method System.StackOverflowException:.ctor (string) emitted at +0xb6ee5218 to 0xb6ee52a0 (code length 136) [testproj.exe] +converting method testproj.MainClass:Main (string[]) +Method testproj.MainClass:Main (string[]) emitted at 0xb6ee52b0 to +0xb6ee5490 (code length 480) [testproj.exe] +converting method (wrapper runtime-invoke) +<Module>:runtime_invoke_void_object (object,intptr,intptr,intptr) +Method (wrapper runtime-invoke) <Module>:runtime_invoke_void_object +(object,intptr,intptr,intptr) emitted at 0xb6ee54b8 to 0xb6ee5794 +(code length 732) [testproj.exe] +converting method System.Console:WriteLine (string) +Method System.Console:WriteLine (string) emitted at 0xb6ee5798 to +0xb6ee5834 (code length 156) [testproj.exe] +converting method System.Console:.cctor () +Method System.Console:.cctor () emitted at 0xb6ee5870 to 0xb6ee6358 +(code length 2792) [testproj.exe] +converting method (wrapper runtime-invoke) object:runtime_invoke_void +(object,intptr,intptr,intptr) +Method (wrapper runtime-invoke) object:runtime_invoke_void +(object,intptr,intptr,intptr) emitted at 0xb6ee6440 to 0xb6ee670c +(code length 716) [testproj.exe] +converting method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_fast (intptr) +Method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_fast (intptr) emitted at +0xb6ee6718 to 0xb6ee6810 (code length 248) [testproj.exe] +converting method (wrapper managed-to-native) +System.Text.Encoding:InternalCodePage (int&) +Method (wrapper managed-to-native) +System.Text.Encoding:InternalCodePage (int&) emitted at 0xb6ee6810 to +0xb6ee6908 (code length 248) [testproj.exe] +converting method System.Text.Encoding:.cctor () +Method System.Text.Encoding:.cctor () emitted at 0xb6ee6920 to +0xb6ee7298 (code length 2424) [testproj.exe] +converting method (wrapper managed-to-native) +object:__icall_wrapper_mono_array_new_specific (intptr,int) +Method (wrapper managed-to-native) +object:__icall_wrapper_mono_array_new_specific (intptr,int) emitted at +0xb6ee72a8 to 0xb6ee73a8 (code length 256) [testproj.exe] +converting method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) +Method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_ptrfree_box (intptr) emitted at +0xb6ee73a8 to 0xb6ee74a0 (code length 248) [testproj.exe] +converting method (wrapper stelemref) object:virt_stelemref_object +(intptr,object) +Method (wrapper stelemref) object:virt_stelemref_object +(intptr,object) emitted at 0xb6ee74a0 to 0xb6ee7558 (code length 184) +[testproj.exe] +converting method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_ptrfree (intptr) +Method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_ptrfree (intptr) emitted at +0xb6ee7558 to 0xb6ee7650 (code length 248) [testproj.exe] +converting method object:.ctor () +Method object:.ctor () emitted at 0xb6ee7650 to 0xb6ee76a8 (code +length 88) [testproj.exe] +converting method System.Text.Encoding:get_UTF8Unmarked () +Method System.Text.Encoding:get_UTF8Unmarked () emitted at 0xb6ee76a8 +to 0xb6ee792c (code length 644) [testproj.exe] +converting method (wrapper managed-to-native) +System.Threading.Monitor:Enter (object) +Method (wrapper managed-to-native) System.Threading.Monitor:Enter +(object) emitted at 0xb6ee7950 to 0xb6ee7a8c (code length 316) +[testproj.exe] +converting method System.Text.UTF8Encoding:.ctor (bool,bool) +Method System.Text.UTF8Encoding:.ctor (bool,bool) emitted at +0xb6ee7a90 to 0xb6ee7d94 (code length 772) [testproj.exe] +converting method System.Text.Encoding:.ctor (int) +Method System.Text.Encoding:.ctor (int) emitted at 0xb6ee7de0 to +0xb6ee8258 (code length 1144) [testproj.exe] +converting method System.Text.DecoderFallback:get_StandardSafeFallback () +converting method System.Text.DecoderFallback:.cctor () +Method System.Text.DecoderFallback:.cctor () emitted at 0xb6ee8270 to +0xb6ee83a0 (code length 304) [testproj.exe] +converting method System.Text.DecoderExceptionFallback:.ctor () +Method System.Text.DecoderExceptionFallback:.ctor () emitted at +0xb6ee83c8 to 0xb6ee8448 (code length 128) [testproj.exe] +converting method System.Text.DecoderFallback:.ctor () +Method System.Text.DecoderFallback:.ctor () emitted at 0xb6ee8458 to +0xb6ee84d4 (code length 124) [testproj.exe] +converting method System.Text.DecoderReplacementFallback:.ctor () +Method System.Text.DecoderReplacementFallback:.ctor () emitted at +0xb6ee84d8 to 0xb6ee8560 (code length 136) [testproj.exe] +converting method System.Text.DecoderReplacementFallback:.ctor (string) +Method System.Text.DecoderReplacementFallback:.ctor (string) emitted +at 0xb6ee8560 to 0xb6ee866c (code length 268) [testproj.exe] +Method System.Text.DecoderFallback:get_StandardSafeFallback () emitted +at 0xb6ee8670 to 0xb6ee86ec (code length 124) [testproj.exe] +converting method System.Text.EncoderFallback:get_StandardSafeFallback () +converting method System.Text.EncoderFallback:.cctor () +Method System.Text.EncoderFallback:.cctor () emitted at 0xb6ee86f0 to +0xb6ee8820 (code length 304) [testproj.exe] +converting method System.Text.EncoderExceptionFallback:.ctor () +Method System.Text.EncoderExceptionFallback:.ctor () emitted at +0xb6ee8848 to 0xb6ee88c8 (code length 128) [testproj.exe] +converting method System.Text.EncoderFallback:.ctor () +Method System.Text.EncoderFallback:.ctor () emitted at 0xb6ee88d8 to +0xb6ee8954 (code length 124) [testproj.exe] +converting method System.Text.EncoderReplacementFallback:.ctor () +Method System.Text.EncoderReplacementFallback:.ctor () emitted at +0xb6ee8958 to 0xb6ee89e0 (code length 136) [testproj.exe] +converting method System.Text.EncoderReplacementFallback:.ctor (string) +Method System.Text.EncoderReplacementFallback:.ctor (string) emitted +at 0xb6ee89e0 to 0xb6ee8aec (code length 268) [testproj.exe] +Method System.Text.EncoderFallback:get_StandardSafeFallback () emitted +at 0xb6ee8af0 to 0xb6ee8b6c (code length 124) [testproj.exe] +converting method System.Text.Encoding:SetFallbackInternal +(System.Text.EncoderFallback,System.Text.DecoderFallback) +Method System.Text.Encoding:SetFallbackInternal +(System.Text.EncoderFallback,System.Text.DecoderFallback) emitted at +0xb6ee8b70 to 0xb6ee8c80 (code length 272) [testproj.exe] +converting method (wrapper managed-to-native) +System.Threading.Monitor:Exit (object) +Method (wrapper managed-to-native) System.Threading.Monitor:Exit +(object) emitted at 0xb6ee8c80 to 0xb6ee8dbc (code length 316) +[testproj.exe] +converting method System.Console:OpenStandardError (int) +Method System.Console:OpenStandardError (int) emitted at 0xb6ee8dc0 to +0xb6ee8e48 (code length 136) [testproj.exe] +converting method (wrapper managed-to-native) +System.IO.MonoIO:get_ConsoleError () +Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleError +() emitted at 0xb6ee8e60 to 0xb6ee8f50 (code length 240) +[testproj.exe] +converting method System.IO.MonoIO:.cctor () +Method System.IO.MonoIO:.cctor () emitted at 0xb6ee8f50 to 0xb6ee9010 +(code length 192) [testproj.exe] +converting method intptr:op_Explicit (long) +Method intptr:op_Explicit (long) emitted at 0xb6ee9020 to 0xb6ee90c0 +(code length 160) [testproj.exe] +converting method intptr:.ctor (long) +Method intptr:.ctor (long) emitted at 0xb6ee90d0 to 0xb6ee9160 (code +length 144) [testproj.exe] +converting method System.Console:Open (intptr,System.IO.FileAccess,int) +Method System.Console:Open (intptr,System.IO.FileAccess,int) emitted +at 0xb6ee9160 to 0xb6ee9354 (code length 500) [testproj.exe] +converting method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_specific (intptr) +Method (wrapper managed-to-native) +object:__icall_wrapper_mono_object_new_specific (intptr) emitted at +0xb6ee9370 to 0xb6ee9468 (code length 248) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.FileStream:.ctor +(intptr,System.IO.FileAccess,bool,int,bool,bool) +Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor +(intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee9468 +to 0xb6ee9628 (code length 448) [testproj.exe] +converting method System.IO.FileStream:.cctor () +Method System.IO.FileStream:.cctor () emitted at 0xb6ee9640 to +0xb6ee96d8 (code length 152) [testproj.exe] +converting method System.IO.FileStream:.ctor +(intptr,System.IO.FileAccess,bool,int,bool,bool) +Method System.IO.FileStream:.ctor +(intptr,System.IO.FileAccess,bool,int,bool,bool) emitted at 0xb6ee96e8 +to 0xb6ee9d74 (code length 1676) [testproj.exe] +converting method System.IO.Stream:.ctor () +Method System.IO.Stream:.ctor () emitted at 0xb6ee9dc8 to 0xb6ee9e48 +(code length 128) [testproj.exe] +converting method System.IO.Stream:.cctor () +Method System.IO.Stream:.cctor () emitted at 0xb6ee9e58 to 0xb6ee9efc +(code length 164) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.NullStream:.ctor () +Method (wrapper remoting-invoke-with-check) System.IO.NullStream:.ctor +() emitted at 0xb6ee9f00 to 0xb6ee9fd4 (code length 212) +[testproj.exe] +converting method System.IO.NullStream:.ctor () +Method System.IO.NullStream:.ctor () emitted at 0xb6ee9ff0 to +0xb6eea070 (code length 128) [testproj.exe] +converting method System.MarshalByRefObject:.ctor () +Method System.MarshalByRefObject:.ctor () emitted at 0xb6eea070 to +0xb6eea0ec (code length 124) [testproj.exe] +converting method intptr:op_Equality (intptr,intptr) +Method intptr:op_Equality (intptr,intptr) emitted at 0xb6eea0f0 to +0xb6eea188 (code length 152) [testproj.exe] +converting method (wrapper managed-to-native) +System.IO.MonoIO:GetFileType (intptr,System.IO.MonoIOError&) +Method (wrapper managed-to-native) System.IO.MonoIO:GetFileType +(intptr,System.IO.MonoIOError&) emitted at 0xb6eea188 to 0xb6eea288 +(code length 256) [testproj.exe] +converting method System.IO.FileStream:InitBuffer (int,bool) +Method System.IO.FileStream:InitBuffer (int,bool) emitted at +0xb6eea288 to 0xb6eea72c (code length 1188) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.UnexceptionalStreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding) +Method (wrapper remoting-invoke-with-check) +System.IO.UnexceptionalStreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea748 to +0xb6eea844 (code length 252) [testproj.exe] +converting method System.IO.UnexceptionalStreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding) +Method System.IO.UnexceptionalStreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea860 to +0xb6eea8f0 (code length 144) [testproj.exe] +converting method System.IO.StreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding) +Method System.IO.StreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding) emitted at 0xb6eea900 to +0xb6eea994 (code length 148) [testproj.exe] +converting method System.IO.StreamWriter:.cctor () +Method System.IO.StreamWriter:.cctor () emitted at 0xb6eea9a0 to +0xb6eeaa74 (code length 212) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.StreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding,int) +Method (wrapper remoting-invoke-with-check) +System.IO.StreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaa80 to +0xb6eeab98 (code length 280) [testproj.exe] +converting method System.IO.StreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding,int) +Method System.IO.StreamWriter:.ctor +(System.IO.Stream,System.Text.Encoding,int) emitted at 0xb6eeaba8 to +0xb6eeae54 (code length 684) [testproj.exe] +converting method System.IO.TextWriter:.ctor () +Method System.IO.TextWriter:.ctor () emitted at 0xb6eeae70 to +0xb6eeaf34 (code length 196) [testproj.exe] +converting method System.IO.TextWriter:.cctor () +Method System.IO.TextWriter:.cctor () emitted at 0xb6eeaf50 to +0xb6eeaff4 (code length 164) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.TextWriter/NullTextWriter:.ctor () +Method (wrapper remoting-invoke-with-check) +System.IO.TextWriter/NullTextWriter:.ctor () emitted at 0xb6eeb000 to +0xb6eeb0d4 (code length 212) [testproj.exe] +converting method System.IO.TextWriter/NullTextWriter:.ctor () +Method System.IO.TextWriter/NullTextWriter:.ctor () emitted at +0xb6eeb0f0 to 0xb6eeb170 (code length 128) [testproj.exe] +converting method System.Environment:get_NewLine () +Method System.Environment:get_NewLine () emitted at 0xb6eeb170 to +0xb6eeb2a8 (code length 312) [testproj.exe] +converting method (wrapper managed-to-native) System.Environment:GetNewLine () +Method (wrapper managed-to-native) System.Environment:GetNewLine () +emitted at 0xb6eeb2b8 to 0xb6eeb3a8 (code length 240) [testproj.exe] +converting method string:ToCharArray () +Method string:ToCharArray () emitted at 0xb6eeb3a8 to 0xb6eeb434 (code +length 140) [testproj.exe] +converting method string:.cctor () +Method string:.cctor () emitted at 0xb6eeb440 to 0xb6eeb554 (code +length 276) [testproj.exe] +converting method (wrapper managed-to-native) string:GetLOSLimit () +Method (wrapper managed-to-native) string:GetLOSLimit () emitted at +0xb6eeb570 to 0xb6eeb660 (code length 240) [testproj.exe] +converting method string:memcpy (byte*,byte*,int) +Method string:memcpy (byte*,byte*,int) emitted at 0xb6eeb660 to +0xb6eebac8 (code length 1128) [testproj.exe] +converting method string:memcpy4 (byte*,byte*,int) +Method string:memcpy4 (byte*,byte*,int) emitted at 0xb6eebaf0 to +0xb6eebf10 (code length 1056) [testproj.exe] +converting method string:ToCharArray (int,int) +Method string:ToCharArray (int,int) emitted at 0xb6eebf10 to +0xb6eec32c (code length 1052) [testproj.exe] +converting method string:CharCopy (char*,char*,int) +Method string:CharCopy (char*,char*,int) emitted at 0xb6eec338 to +0xb6eec5d8 (code length 672) [testproj.exe] +converting method System.IO.NullStream:get_CanWrite () +Method System.IO.NullStream:get_CanWrite () emitted at 0xb6eec5d8 to +0xb6eec654 (code length 124) [testproj.exe] +converting method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +Method System.IO.StreamWriter:Initialize (System.Text.Encoding,int) +emitted at 0xb6eec658 to 0xb6eec8f4 (code length 668) [testproj.exe] +converting method System.Math:Max (int,int) +Method System.Math:Max (int,int) emitted at 0xb6eec8f8 to 0xb6eec9dc +(code length 228) [testproj.exe] +converting method System.Text.UTF8Encoding:GetMaxByteCount (int) +Method System.Text.UTF8Encoding:GetMaxByteCount (int) emitted at +0xb6eec9e0 to 0xb6eecaec (code length 268) [testproj.exe] +converting method System.IO.NullStream:get_CanSeek () +Method System.IO.NullStream:get_CanSeek () emitted at 0xb6eecaf8 to +0xb6eecb74 (code length 124) [testproj.exe] +converting method System.IO.NullStream:get_Position () +Method System.IO.NullStream:get_Position () emitted at 0xb6eecb78 to +0xb6eecbf8 (code length 128) [testproj.exe] +converting method System.IO.FileStream:get_CanWrite () +Method System.IO.FileStream:get_CanWrite () emitted at 0xb6eecbf8 to +0xb6eeccf0 (code length 248) [testproj.exe] +converting method System.IO.FileStream:get_CanSeek () +Method System.IO.FileStream:get_CanSeek () emitted at 0xb6eeccf0 to +0xb6eecd70 (code length 128) [testproj.exe] +converting method System.IO.StreamWriter:set_AutoFlush (bool) +Method System.IO.StreamWriter:set_AutoFlush (bool) emitted at +0xb6eecd70 to 0xb6eece5c (code length 236) [testproj.exe] +converting method System.IO.UnexceptionalStreamWriter:Flush () +Method System.IO.UnexceptionalStreamWriter:Flush () emitted at +0xb6eece60 to 0xb6eecf4c (code length 236) [testproj.exe] +converting method System.IO.StreamWriter:Flush () +Method System.IO.StreamWriter:Flush () emitted at 0xb6eecf58 to +0xb6eed0dc (code length 388) [testproj.exe] +converting method System.IO.StreamWriter:Decode () +Method System.IO.StreamWriter:Decode () emitted at 0xb6eed0f8 to +0xb6eed308 (code length 528) [testproj.exe] +converting method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +Method System.IO.TextWriter:Synchronized (System.IO.TextWriter,bool) +emitted at 0xb6eed320 to 0xb6eed5c0 (code length 672) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +Method (wrapper remoting-invoke-with-check) +System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) emitted +at 0xb6eed5d8 to 0xb6eed6d4 (code length 252) [testproj.exe] +converting method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +Method System.IO.SynchronizedWriter:.ctor (System.IO.TextWriter,bool) +emitted at 0xb6eed6f0 to 0xb6eed7d0 (code length 224) [testproj.exe] +converting method System.ConsoleDriver:get_IsConsole () +Method System.ConsoleDriver:get_IsConsole () emitted at 0xb6eed7d0 to +0xb6eed9b0 (code length 480) [testproj.exe] +converting method System.ConsoleDriver:.cctor () +Method System.ConsoleDriver:.cctor () emitted at 0xb6eed9e0 to +0xb6eedc6c (code length 652) [testproj.exe] +converting method (wrapper managed-to-native) +System.IO.MonoIO:get_ConsoleOutput () +Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleOutput +() emitted at 0xb6eedca8 to 0xb6eedd98 (code length 240) +[testproj.exe] +converting method (wrapper managed-to-native) +System.ConsoleDriver:Isatty (intptr) +Method (wrapper managed-to-native) System.ConsoleDriver:Isatty +(intptr) emitted at 0xb6eedd98 to 0xb6eede90 (code length 248) +[testproj.exe] +converting method System.ConsoleDriver:CreateNullConsoleDriver () +Method System.ConsoleDriver:CreateNullConsoleDriver () emitted at +0xb6eede90 to 0xb6eedf1c (code length 140) [testproj.exe] +converting method System.NullConsoleDriver:.ctor () +Method System.NullConsoleDriver:.ctor () emitted at 0xb6eedf28 to +0xb6eedfa4 (code length 124) [testproj.exe] +converting method System.Console:OpenStandardOutput (int) +Method System.Console:OpenStandardOutput (int) emitted at 0xb6eedfa8 +to 0xb6eee030 (code length 136) [testproj.exe] +converting method System.Console:OpenStandardInput (int) +Method System.Console:OpenStandardInput (int) emitted at 0xb6eee030 to +0xb6eee0b8 (code length 136) [testproj.exe] +converting method (wrapper managed-to-native) +System.IO.MonoIO:get_ConsoleInput () +Method (wrapper managed-to-native) System.IO.MonoIO:get_ConsoleInput +() emitted at 0xb6eee0b8 to 0xb6eee1a8 (code length 240) +[testproj.exe] +converting method System.IO.UnexceptionalStreamReader:.cctor () +Method System.IO.UnexceptionalStreamReader:.cctor () emitted at +0xb6eee1a8 to 0xb6eee300 (code length 344) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.UnexceptionalStreamReader:.ctor +(System.IO.Stream,System.Text.Encoding) +Method (wrapper remoting-invoke-with-check) +System.IO.UnexceptionalStreamReader:.ctor +(System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee300 to +0xb6eee3fc (code length 252) [testproj.exe] +converting method System.IO.UnexceptionalStreamReader:.ctor +(System.IO.Stream,System.Text.Encoding) +Method System.IO.UnexceptionalStreamReader:.ctor +(System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee418 to +0xb6eee4a8 (code length 144) [testproj.exe] +converting method System.IO.StreamReader:.ctor +(System.IO.Stream,System.Text.Encoding) +Method System.IO.StreamReader:.ctor +(System.IO.Stream,System.Text.Encoding) emitted at 0xb6eee4b8 to +0xb6eee554 (code length 156) [testproj.exe] +converting method System.IO.StreamReader:.cctor () +Method System.IO.StreamReader:.cctor () emitted at 0xb6eee560 to +0xb6eee648 (code length 232) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.StreamReader/NullStreamReader:.ctor () +Method (wrapper remoting-invoke-with-check) +System.IO.StreamReader/NullStreamReader:.ctor () emitted at 0xb6eee658 +to 0xb6eee72c (code length 212) [testproj.exe] +converting method System.IO.StreamReader/NullStreamReader:.ctor () +Method System.IO.StreamReader/NullStreamReader:.ctor () emitted at +0xb6eee748 to 0xb6eee7c8 (code length 128) [testproj.exe] +converting method System.IO.StreamReader:.ctor () +Method System.IO.StreamReader:.ctor () emitted at 0xb6eee7d8 to +0xb6eee858 (code length 128) [testproj.exe] +converting method System.IO.TextReader:.ctor () +Method System.IO.TextReader:.ctor () emitted at 0xb6eee868 to +0xb6eee8e8 (code length 128) [testproj.exe] +converting method System.IO.TextReader:.cctor () +Method System.IO.TextReader:.cctor () emitted at 0xb6eee8e8 to +0xb6eee98c (code length 164) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.TextReader/NullTextReader:.ctor () +Method (wrapper remoting-invoke-with-check) +System.IO.TextReader/NullTextReader:.ctor () emitted at 0xb6eee998 to +0xb6eeea6c (code length 212) [testproj.exe] +converting method System.IO.TextReader/NullTextReader:.ctor () +Method System.IO.TextReader/NullTextReader:.ctor () emitted at +0xb6eeea88 to 0xb6eeeb08 (code length 128) [testproj.exe] +converting method System.IO.StreamReader:.ctor +(System.IO.Stream,System.Text.Encoding,bool,int) +Method System.IO.StreamReader:.ctor +(System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeeb08 +to 0xb6eeebd8 (code length 208) [testproj.exe] +converting method System.IO.StreamReader:Initialize +(System.IO.Stream,System.Text.Encoding,bool,int) +Method System.IO.StreamReader:Initialize +(System.IO.Stream,System.Text.Encoding,bool,int) emitted at 0xb6eeebe8 +to 0xb6eef5b8 (code length 2512) [testproj.exe] +converting method System.IO.FileStream:get_CanRead () +Method System.IO.FileStream:get_CanRead () emitted at 0xb6eef5b8 to +0xb6eef6b0 (code length 248) [testproj.exe] +converting method System.Text.UTF8Encoding:GetMaxCharCount (int) +Method System.Text.UTF8Encoding:GetMaxCharCount (int) emitted at +0xb6eef6b0 to 0xb6eef7b8 (code length 264) [testproj.exe] +converting method System.Text.UTF8Encoding:GetDecoder () +Method System.Text.UTF8Encoding:GetDecoder () emitted at 0xb6eef7b8 to +0xb6eef858 (code length 160) [testproj.exe] +converting method System.Text.Encoding:get_DecoderFallback () +Method System.Text.Encoding:get_DecoderFallback () emitted at +0xb6eef870 to 0xb6eef8f0 (code length 128) [testproj.exe] +converting method System.Text.UTF8Encoding/UTF8Decoder:.ctor +(System.Text.DecoderFallback) +Method System.Text.UTF8Encoding/UTF8Decoder:.ctor +(System.Text.DecoderFallback) emitted at 0xb6eef8f0 to 0xb6eef9f8 +(code length 264) [testproj.exe] +converting method System.Text.Decoder:.ctor () +Method System.Text.Decoder:.ctor () emitted at 0xb6eefa10 to +0xb6eefad4 (code length 196) [testproj.exe] +converting method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +Method System.Text.Decoder:set_Fallback (System.Text.DecoderFallback) +emitted at 0xb6eefad8 to 0xb6eefbe8 (code length 272) [testproj.exe] +converting method System.Text.UTF8Encoding:GetPreamble () +Method System.Text.UTF8Encoding:GetPreamble () emitted at 0xb6eefbe8 +to 0xb6eefd10 (code length 296) [testproj.exe] +converting method (wrapper stfld) +object:__stfld_wrapper_0x34ee68_System.Int32 +(object,intptr,intptr,intptr,int) +Method (wrapper stfld) object:__stfld_wrapper_0x34ee68_System.Int32 +(object,intptr,intptr,intptr,int) emitted at 0xb6eefd10 to 0xb6eefe7c +(code length 364) [testproj.exe] +converting method (wrapper ldfld) +object:__ldfld_wrapper_0x34ee68_System.Int32 +(object,intptr,intptr,intptr) +Method (wrapper ldfld) object:__ldfld_wrapper_0x34ee68_System.Int32 +(object,intptr,intptr,intptr) emitted at 0xb6eefe88 to 0xb6eeffd8 +(code length 336) [testproj.exe] +converting method System.IO.TextReader:Synchronized (System.IO.TextReader) +Method System.IO.TextReader:Synchronized (System.IO.TextReader) +emitted at 0xb6eeffe8 to 0xb6ef0278 (code length 656) [testproj.exe] +converting method (wrapper remoting-invoke-with-check) +System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +Method (wrapper remoting-invoke-with-check) +System.IO.SynchronizedReader:.ctor (System.IO.TextReader) emitted at +0xb6ef0290 to 0xb6ef0378 (code length 232) [testproj.exe] +converting method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +Method System.IO.SynchronizedReader:.ctor (System.IO.TextReader) +emitted at 0xb6ef0390 to 0xb6ef0440 (code length 176) [testproj.exe] +converting method (wrapper managed-to-native) +System.GC:SuppressFinalize (object) +Method (wrapper managed-to-native) System.GC:SuppressFinalize (object) +emitted at 0xb6ef0440 to 0xb6ef057c (code length 316) [testproj.exe] +converting method System.IO.SynchronizedWriter:WriteLine (string) +Method System.IO.SynchronizedWriter:WriteLine (string) emitted at +0xb6ef0580 to 0xb6ef06ec (code length 364) [testproj.exe] +converting method System.IO.TextWriter:WriteLine (string) +Method System.IO.TextWriter:WriteLine (string) emitted at 0xb6ef06f0 +to 0xb6ef07b8 (code length 200) [testproj.exe] +converting method System.IO.UnexceptionalStreamWriter:Write (string) +Method System.IO.UnexceptionalStreamWriter:Write (string) emitted at +0xb6ef07b8 to 0xb6ef08ac (code length 244) [testproj.exe] +converting method System.IO.StreamWriter:Write (string) +Method System.IO.StreamWriter:Write (string) emitted at 0xb6ef08b8 to +0xb6ef0a40 (code length 392) [testproj.exe] +converting method System.IO.StreamWriter:LowLevelWrite (string) +Method System.IO.StreamWriter:LowLevelWrite (string) emitted at +0xb6ef0a50 to 0xb6ef0e94 (code length 1092) [testproj.exe] +converting method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +Method System.Text.UTF8Encoding:GetBytes (char[],int,int,byte[],int) +emitted at 0xb6ef0e98 to 0xb6ef1010 (code length 376) [testproj.exe] +converting method System.Text.Encoding:get_EncoderFallback () +Method System.Text.Encoding:get_EncoderFallback () emitted at +0xb6ef1028 to 0xb6ef10a8 (code length 128) [testproj.exe] +converting method System.Text.UTF8Encoding:InternalGetBytes +(char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +Method System.Text.UTF8Encoding:InternalGetBytes +(char[],int,int,byte[],int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +emitted at 0xb6ef10a8 to 0xb6ef1878 (code length 2000) [testproj.exe] +converting method System.Text.UTF8Encoding:InternalGetBytes +(char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +Method System.Text.UTF8Encoding:InternalGetBytes +(char*,int,byte*,int,System.Text.EncoderFallback,System.Text.EncoderFallbackBuffer&,char&,bool) +emitted at 0xb645a000 to 0xb645b31c (code length 4892) [testproj.exe] +converting method System.IO.StreamWriter:FlushBytes () +Method System.IO.StreamWriter:FlushBytes () emitted at 0xb645b338 to +0xb645b558 (code length 544) [testproj.exe] +converting method System.IO.FileStream:Write (byte[],int,int) +Method System.IO.FileStream:Write (byte[],int,int) emitted at +0xb645b558 to 0xb645b9cc (code length 1140) [testproj.exe] +converting method System.IO.FileStream:WriteInternal (byte[],int,int) +Method System.IO.FileStream:WriteInternal (byte[],int,int) emitted at +0xb645b9d8 to 0xb645bed0 (code length 1272) [testproj.exe] +converting method System.IO.FileStream:FlushBuffer () +Method System.IO.FileStream:FlushBuffer () emitted at 0xb645bf18 to +0xb645bf9c (code length 132) [testproj.exe] +converting method System.IO.FileStream:FlushBuffer (System.IO.Stream) +Method System.IO.FileStream:FlushBuffer (System.IO.Stream) emitted at +0xb645bfa8 to 0xb645c4fc (code length 1364) [testproj.exe] +converting method (wrapper ldfld) +object:__ldfld_wrapper_0x350250_System.Int64 +(object,intptr,intptr,intptr) +Method (wrapper ldfld) object:__ldfld_wrapper_0x350250_System.Int64 +(object,intptr,intptr,intptr) emitted at 0xb645c500 to 0xb645c654 +(code length 340) [testproj.exe] +coStarted +nverting method (wrapper stfld) +object:__stfld_wrapper_0x350250_System.Int64 +(object,intptr,intptr,intptr,long) +Method (wrapper stfld) object:__stfld_wrapper_0x350250_System.Int64 +(object,intptr,intptr,intptr,long) emitted at 0xb645c658 to 0xb645c7e4 +(code length 396) [testproj.exe] +converting method (wrapper managed-to-native) System.IO.MonoIO:Write +(intptr,byte[],int,int,System.IO.MonoIOError&) +Method (wrapper managed-to-native) System.IO.MonoIO:Write +(intptr,byte[],int,int,System.IO.MonoIOError&) emitted at 0xb645c7e8 +to 0xb645c918 (code length 304) [testproj.exe] +converting method System.IO.FileStream:Flush () +Method System.IO.FileStream:Flush () emitted at 0xb645c918 to +0xb645ca18 (code length 256) [testproj.exe] +converting method System.IO.TextWriter:WriteLine () +Method System.IO.TextWriter:WriteLine () emitted at 0xb645ca18 to +0xb645caac (code length 148) [testproj.exe] +converting method System.IO.UnexceptionalStreamWriter:Write (char[]) +Method System.IO.UnexceptionalStreamWriter:Write (char[]) emitted at +0xb645cab0 to 0xb645cba4 (code length 244) [testproj.exe] +converting method System.IO.StreamWriter:Write (char[]) +Method System.IO.StreamWriter:Write (char[]) emitted at 0xb645cbb0 to +0xb645cd44 (code length 404) [testproj.exe] +converting method System.IO.StreamWriter:LowLevelWrite (char[],int,int) +Method System.IO.StreamWriter:LowLevelWrite (char[],int,int) emitted +at 0xb645cd50 to 0xb645d04c (code length 764) [testproj.exe] +converting method System.Buffer:BlockCopy +(System.Array,int,System.Array,int,int) +Method System.Buffer:BlockCopy (System.Array,int,System.Array,int,int) +emitted at 0xb645d058 to 0xb645d458 (code length 1024) [testproj.exe] +converting method (wrapper managed-to-native) +System.Buffer:BlockCopyInternal +(System.Array,int,System.Array,int,int) +Method (wrapper managed-to-native) System.Buffer:BlockCopyInternal +(System.Array,int,System.Array,int,int) emitted at 0xb645d470 to +0xb645d5a0 (code length 304) [testproj.exe] +converting method System.ExecutionEngineException:.ctor () +Method System.ExecutionEngineException:.ctor () emitted at 0xb645d5a0 +to 0xb645d638 (code length 152) [testproj.exe] +converting method (wrapper runtime-invoke) +object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) +Method (wrapper runtime-invoke) object:runtime_invoke_void__this__ +(object,intptr,intptr,intptr) emitted at 0xb645d638 to 0xb645d90c +(code length 724) [testproj.exe] +converting method Locale:GetText (string) +Method Locale:GetText (string) emitted at 0xb645d910 to 0xb645d98c +(code length 124) [testproj.exe] +converting method System.Exception:ToString () +Method System.Exception:ToString () emitted at 0xb645d990 to +0xb645dd04 (code length 884) [testproj.exe] +converting method (wrapper runtime-invoke) +<Module>:runtime_invoke_object__this__ (object,intptr,intptr,intptr) +Method (wrapper runtime-invoke) <Module>:runtime_invoke_object__this__ +(object,intptr,intptr,intptr) emitted at 0xb645dd28 to 0xb645e004 +(code length 732) [testproj.exe] +converting method System.Exception:get_ClassName () +Method System.Exception:get_ClassName () emitted at 0xb645e008 to +0xb645e104 (code length 252) [testproj.exe] +converting method System.Exception:GetType () +Method System.Exception:GetType () emitted at 0xb645e110 to 0xb645e194 +(code length 132) [testproj.exe] +converting method System.MonoType:ToString () +Method System.MonoType:ToString () emitted at 0xb645e198 to 0xb645e220 +(code length 136) [testproj.exe] +converting method (wrapper managed-to-native) +System.MonoType:getFullName (System.MonoType,bool,bool) +Method (wrapper managed-to-native) System.MonoType:getFullName +(System.MonoType,bool,bool) emitted at 0xb645e230 to 0xb645e394 (code +length 356) [testproj.exe] +converting method System.Text.StringBuilder:.ctor (string) +Method System.Text.StringBuilder:.ctor (string) emitted at 0xb645e398 +to 0xb645e520 (code length 392) [testproj.exe] +converting method System.Text.StringBuilder:Append (string) +Method System.Text.StringBuilder:Append (string) emitted at 0xb645e520 +to 0xb645e8c4 (code length 932) [testproj.exe] +converting method +Unhandled Exception: System.ExecutionEngineException: SIGILL +[ERROR] FATAL UNHANDLED EXCEPTION: System.ExecutionEngineException: SIGILL + + +What can i do? + + +thanks Peter ++ + +
Starting: Sun Jan 29 14:18:38 UTC 2012
+ Ending: Sun Jan 29 14:18:38 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Sun Jan 29 14:18:38 UTC 2012
+ Archived on: Sun Jan 29 14:18:44 UTC 2012
+
+
+
Starting: Sun Jan 29 14:18:38 UTC 2012
+ Ending: Sun Jan 29 14:18:38 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Sun Jan 29 14:18:38 UTC 2012
+ Archived on: Sun Jan 29 14:18:44 UTC 2012
+
+
+
Starting: Sun Jan 29 14:18:38 UTC 2012
+ Ending: Sun Jan 29 14:18:38 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Sun Jan 29 14:18:38 UTC 2012
+ Archived on: Sun Jan 29 14:18:44 UTC 2012
+
+
+
Starting: Sun Jan 29 14:18:38 UTC 2012
+ Ending: Sun Jan 29 14:18:38 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Sun Jan 29 14:18:38 UTC 2012
+ Archived on: Sun Jan 29 14:18:44 UTC 2012
+
+
+
Starting: Sun Jan 29 14:18:38 UTC 2012
+ Ending: Sun Jan 29 14:18:38 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Sun Jan 29 14:18:38 UTC 2012
+ Archived on: Sun Jan 29 14:18:44 UTC 2012
+
+
+
I'm attempting to make some changes in MonoDevelop (and its plugins) on +the Mac and am having difficulty getting things to build. + +Here's what I'm doing (from +http://monodevelop.com/Developers/Mac_Support/Building_MonoDevelop_on_OS_X +) + +> git clone https://github.com/mono/monodevelop.git +> cd monodevelop +> export ACLOCAL_FLAGS="-I +/Library/Frameworks/Mono.framework/Versions/Current/share/aclocal", +> export +PATH="/Library/Frameworks/Mono.framework/Versions/Current/bin:$PATH" +> ./configure --profile=mac + +If I run + +> make && cd main/build/MacOSX && make + +I get a usable MonoDevelop.app. However, opening main/Main.sln and +selecting the "DebugMac" project fails quickly with a large number of +namespace errors (missing assembly references?). + +Is Main.sln kept buildable on the Mac? + +I'd like to debug my MonoDevelop changes, and since MonoDevelop lacks an +"attach to process", I'd assume the only way to do this is to build and +launch from inside MonoDevelop. Is there another way to debug my changes +(mdb?)? + +I've asked on IRC the last few days to no avail. + +Thanks, +--Chris +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120309/64727cef/attachment.html> ++ + + + +
Hi, + +My name is Wojciech Gawroński and I'm a Polish Computer Science student from +Silesian University of Technology in Gliwice. +I'm interested in extending Monodevelop and I've got some questions about +details of specified topics. + +- Code metrics - Do you have foundation for this task or student should do +it from scratch (with all parsing and AST trees related problems)? +- JS Support - Can I use something like Esprima or treehugger.js (with a C# +port) or it should be based on the mentioned ActionScript parser from +FlashDevelop? +- C# Refactorings - Again, It should be done from scratch? How about really +complex and advanced refactoring which are possible in for e.g. ReSharper +tool? + +Thanks in advance for provided details and I look forward to your answer. + +Yours sincerely, +-- +Wojciech Gawroński (afronski) +Silesian University of Technology +Gliwice, Poland + + + ++ + + + + + +
Hi Wojciech, + +2012/3/19 Wojciech Gawroński <afronski at gmail.com> + +> Hi, +> +> My name is Wojciech Gawroński and I'm a Polish Computer Science student +> from +> Silesian University of Technology in Gliwice. +> I'm interested in extending Monodevelop and I've got some questions about +> details of specified topics. +> +> - Code metrics - Do you have foundation for this task or student should do +> it from scratch (with all parsing and AST trees related problems)? +> + +MonoDevelop already has an AST for at least C#, not sure about other +languages - but the focus for code metrics is likely for C# anyway. + + +> - JS Support - Can I use something like Esprima or treehugger.js (with a C# +> port) or it should be based on the mentioned ActionScript parser from +> FlashDevelop? +> + +I'll let Michael Hutchinson answer this question, because I honestly don't +know. I suspect that as long as they are under an appropriate license, it +doesn't matter. (Appropriate being MIT/X11, Apache 2.0, or something like +that). + + +> - C# Refactorings - Again, It should be done from scratch? How about really +> complex and advanced refactoring which are possible in for e.g. ReSharper +> tool? +> + +There is already some API to facilitate refactoring, but I'm not sure what +is needed. The best person to answer this question would be Mike Krueger. + + +Hope that helps, + +Jeff +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120319/f3f0fd4d/attachment.html> ++ + + + + + + +
http://lists.ximian.com/mailman/listinfo/mono-devel-listOnce again, the +Mono team is happy to announce that we are participating in the Google +Summer of Code 2012! Last year was a great success, and we hope this year +will be even better! + +>From now until the 26th, students and mentoring organizations come together +to discuss project ideas. Take this time to introduce yourself, get to know +the community, discuss your ideas with us, fix bugs, file some patches and +show us how excited you are about coding the summer away! + +As usual, project ideas and rules are available on our GSoC +page<http://mono-project.com/Gsoc> [1]. The +ideas list has been updated recently, so don't be surprised if some things +have moved around or disappeared. Feel free to choose one or more ideas +from that page, or tell us about your own awesome idea! + +Our mailing lists should be your first stop (like this one). In general, +Mono devs can be found in the +mono<http://lists.ximian.com/mailman/listinfo/mono-list>or +mono-devel <http://lists.ximian.com/mailman/listinfo/mono-devel-list>mailing +lists. There's also the +monodevelop-devel<http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list>mailing +list for MD development, and you can reach the docs team for docs +or orchard-related projects in the +mono-docs<http://lists.ximian.com/mailman/listinfo/mono-docs-list>list. +This is by no means exhaustive as there are plenty of other mailing +lists available, which you can find +here<http://mono-project.com/Mailing_Lists> [2]. If +your idea involves an external project, you should also contact the +developers in project-specific mailing lists as well. + +And, of course, IRC is where everyone is, in the irc.gnome.org server. +There's the #mono channel, for general Mono discussions, #monodev for Mono +development, #monodevelop for MonoDevelop, and #monosoc for GSoC-specific +questions and saying hi to your fellow students. + +If you're interested in mentoring or other administrative questions, send +an email to the Mono GSoC admins at soc at xamarin.com. + + +Happy coding! + +-------- +[1] http://mono-project.com/Gsoc +[2] http://mono-project.com/Mailing_Lists + +* Google Summer of Code program: http://code.google.com/soc +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120320/d6f525be/attachment.html> ++ + + + + + + +
Hi everyone! +My name is Igor and I decided to improve F# bindings as a gsoc project. I +have strong desire to jump into and want to ask your opinion on which bugs +could be picked up as my first. + +Thank you. + +Regards, Igor. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120320/81c1067e/attachment.html> ++ + + + + + + +
Hi, + +>> - Code metrics - Do you have foundation for this task or student should do +>> it from scratch (with all parsing and AST trees related problems)? +> +> +> MonoDevelop already has an AST for at least C#, not sure about other +> languages - but the focus for code metrics is likely for C# anyway. + +Who's mentoring this task? +And which code metrics should be done at first? +Are there any bugs or smaller tasks which can be done as a "warm-up task"? + +Yours sincerely, +-- +Wojciech Gawroński (afronski) +Silesian University of Technology +Gliwice, Poland + + +W dniu 19 marca 2012 20:20 użytkownik Jeff Stedfast <jeff at xamarin.com> napisał: +> Hi Wojciech, +> +> 2012/3/19 Wojciech Gawroński <afronski at gmail.com> +>> +>> Hi, +>> +>> My name is Wojciech Gawroński and I'm a Polish Computer Science student +>> from +>> Silesian University of Technology in Gliwice. +>> I'm interested in extending Monodevelop and I've got some questions about +>> details of specified topics. +>> +>> - Code metrics - Do you have foundation for this task or student should do +>> it from scratch (with all parsing and AST trees related problems)? +> +> +> MonoDevelop already has an AST for at least C#, not sure about other +> languages - but the focus for code metrics is likely for C# anyway. +> +>> +>> - JS Support - Can I use something like Esprima or treehugger.js (with a +>> C# +>> port) or it should be based on the mentioned ActionScript parser from +>> FlashDevelop? +> +> +> I'll let Michael Hutchinson answer this question, because I honestly don't +> know. I suspect that as long as they are under an appropriate license, it +> doesn't matter. (Appropriate being MIT/X11, Apache 2.0, or something like +> that). +> +>> +>> - C# Refactorings - Again, It should be done from scratch? How about +>> really +>> complex and advanced refactoring which are possible in for e.g. ReSharper +>> tool? +> +> +> There is already some API to facilitate refactoring, but I'm not sure what +> is needed. The best person to answer this question would be Mike Krueger. +> +> +> Hope that helps, +> +> Jeff +> ++ + + + + +
Hello + +How can I determine the current position in the editor in terms of +namespace, class, method / property etc? + +Im asking in relation to the MonoDoc addin idea on the GSoC ideas page, +trying to piece together how this would work. + +Best Regards + +Gary +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120321/b4d1b6b8/attachment.html> ++ + + + + + + +
Hi! +My name is Igor and I am interesting in improving F# bindings for +MonoDevelop su as integrating F# language binding into the main branch of +MonoDevelop. I have already downloaded sources of F# language bindings +project so I want to know what should I learn and where should I start? + +Thank you! + +Regards, Igor. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120321/8e7f4911/attachment.html> ++ + + + + + + +
Hello, + +Sega Able wrote: +> Hi! +> My name is Igor and I am interesting in improving F# bindings for +> MonoDevelop su as integrating F# language binding into the main branch +> of MonoDevelop. I have already downloaded sources of F# language +> bindings project so I want to know what should I learn and where +> should I start? + +Nice, and welcome :) I have a couple of ideas for starting: + +- Right now, the build is far from ideal, we cannot even use standard +dependency paths. Say, we are encouraged to use something like /devel to +put our own builds, to not conflict with existing stable installation. +Current fsharpbinding build cannot work with that. + - I got some fix for build issue locally [*1] but it's still far less +ideal. +- After you get "make install" successfully done, F# projects still +doesn't show up. I *assume* this is due to some monodevelop changes (in +addin path name or whatever). +- Add some more F# source templates like we have for C# or VB. I assume +this is easy. + +I have some more ideas but won't be good starters :) Anyways hope this +helps. + +[*1] +https://github.com/atsushieno/fsharpbinding/commit/3ce31bcc4ded6623b3cde15b0a2aaf3c2a84455e + +Atsushi Eno + + ++ + + + + + + +
Hi, + +My name is Peter and I’d like to participate in developing MD under GSoC +2012. I have some experience in web development in .NET hence the +projects related to ASP .NET MVC draw my attention. I’m particularly +interested in adding Razor syntax support to Mono Develop – syntax +highlighting, code completion, new project templates etc. - but I have +some questions that hopefully could be answered by more experienced +developers. + +My questions are generally about the difficulty of the task. I started +browsing the code and investigating the add-ins. I’ve also read several +articles for developers but I can’t precisely assess the complexity of +the Razor support task. I think that adding syntax highlighting wouldn’t +be too hard, but a good Razor parser and code completion seems to me a +bit challenging. Am I right or is it just the wrong impression? Will it +be possible to use the existing ASP and HTML parsers to provide Razor +syntax support? I’d be grateful for some feedback so that I could +prepare a feasible timeline for my application. + +I’d also like to ask if you have any other ideas related to mvc, maybe +of greater importance than Razor, that you would like to have +implemented. Support for MVC 3 from your tasks list seems like an +important thing to me. What features in this area are most important to +you? Adding new templates and project types that guarantee building and +running mvc 3 without any hacks, bug fixing, maybe something else? + +Thanks in advance for your help. + +Regards, +Piotr Dowgiallo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120323/00a643c2/attachment.html> ++ + + + + + + +
If you look at +http://haacked.com/archive/2011/01/06/razor-syntax-quick-reference.aspx you'll +see that even syntax-highlighting isn't a simple task, as there are many +conditions for transitioning between html and code blocks and back in the +syntax, but yes it is the simplest goal. Code completion is a lot harder +and I don't think the individual parsers for HTML and C# are easily +reusable, as there is some difficulty in keeping a sane shared context for +both, probably it would be needed a refactoring of both to accommodate the +needs of a Razor-compatible code completion engine. + +Said that some partial goals can be set and achieved towards enabling +editing Razor views, and on the general workflow of creating a MVC 3 app in +MonoDevelop. Don't give up. + +Fun, + +Rafael "Monoman" Teixeira +--------------------------------------- +"The most exciting phrase to hear in science, the one that heralds new +discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" +Isaac Asimov +US science fiction novelist & scholar (1920 - 1992) + + +2012/3/23 Sparek <sparekd at gmail.com> + +> Hi, +> +> My name is Peter and I’d like to participate in developing MD under GSoC +> 2012. I have some experience in web development in .NET hence the projects +> related to ASP .NET MVC draw my attention. I’m particularly interested in +> adding Razor syntax support to Mono Develop – syntax highlighting, code +> completion, new project templates etc. - but I have some questions that +> hopefully could be answered by more experienced developers. +> +> My questions are generally about the difficulty of the task. I started +> browsing the code and investigating the add-ins. I’ve also read several +> articles for developers but I can’t precisely assess the complexity of the +> Razor support task. I think that adding syntax highlighting wouldn’t be too +> hard, but a good Razor parser and code completion seems to me a bit +> challenging. Am I right or is it just the wrong impression? Will it be +> possible to use the existing ASP and HTML parsers to provide Razor syntax +> support? I’d be grateful for some feedback so that I could prepare a +> feasible timeline for my application. +> +> I’d also like to ask if you have any other ideas related to mvc, maybe of +> greater importance than Razor, that you would like to have implemented. +> Support for MVC 3 from your tasks list seems like an important thing to me. +> What features in this area are most important to you? Adding new templates +> and project types that guarantee building and running mvc 3 without any +> hacks, bug fixing, maybe something else? +> +> Thanks in advance for your help. +> +> Regards, +> Piotr Dowgiallo +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120323/26599677/attachment.html> ++ + + + + + + +
2012/3/23 Sparek <sparekd at gmail.com>: +> Hi, +> +> My name is Peter and I’d like to participate in developing MD under GSoC +> 2012. I have some experience in web development in .NET hence the projects +> related to ASP .NET MVC draw my attention. I’m particularly interested in +> adding Razor syntax support to Mono Develop – syntax highlighting, code +> completion, new project templates etc. - but I have some questions that +> hopefully could be answered by more experienced developers. +> +> My questions are generally about the difficulty of the task. I started +> browsing the code and investigating the add-ins. I’ve also read several +> articles for developers but I can’t precisely assess the complexity of the +> Razor support task. I think that adding syntax highlighting wouldn’t be too +> hard, but a good Razor parser and code completion seems to me a bit +> challenging. Am I right or is it just the wrong impression? Will it be +> possible to use the existing ASP and HTML parsers to provide Razor syntax +> support? I’d be grateful for some feedback so that I could prepare a +> feasible timeline for my application. + +It is a challenging project, but I believe it's doable in the GSoC +timeframe. The main challenge is in building a Razor parser. Then you +should integrate with the existing HTML and C# completion engines. + +The current ASPX completion support uses a multi-pass approach to code +completion. It's basically an extension of the HTML parser and +completion engine that adds support for ASPX tags, and defers C# +regions to the C# parser and completion engine. + +You right that syntax highlighting is usually simpler - it doesn't +track any document structure, it's really just a tokenizer. It uses +the C# token-based highlighter to highlight the regions it identifies +as C#. Unfortunately this makes it hard to do "semantic highlighting" +but that's not really a big deal. It should be pretty easy to modify +it to support Razor. + +That said, for Razor, the syntax highlighter's logic for identifying +C# and HTML regions may provide a good basis for the code completion +parser, since it could be used to identify regiosn to be deferred to +the existing HTML and C# completion engines. + +For code completion, you'll definitely need to defer C# regions to the +C# completion engine - C# completion is very complex. But I'm not sure +yet whether it would be better to try to extend the existing ASPX +parser to handle Razor C# regions, or to write a new Razor parser that +would defer HTML regions to the HTML completion engine, or reimplement +HTML completion on top of a new Razor parser. + +> I’d also like to ask if you have any other ideas related to mvc, maybe of +> greater importance than Razor, that you would like to have implemented. +> Support for MVC 3 from your tasks list seems like an important thing to me. +> What features in this area are most important to you? Adding new templates +> and project types that guarantee building and running mvc 3 without any +> hacks, bug fixing, maybe something else? + +The isn't much more to basic ASP.NET MVC3 support than adding +templates. Beyond that, there's a lot that could be done to make +ASP.NET support more awesome - but we leave the details up to you, so +that your proposal can show your understanding of what will make it a +great experience. Here are some ideas of things that *could* be done, +in no particular order: +* support for targeting different web browsers +* make HTML completion in ASP.NET content pages use the context from +the master page +* inline CSS code completion in aspx/html pages +* a split browser/source view for previewing your code as you write it +* support for the "find references" command (and rename command) to +find things in aspx pages +* make C# tooltips work in aspx pages +* a "go to view" command in MVC controller source code, and vice versa +* create a unit test project when creating new ASP.NET MVC projects +* support for deploying and debugging on remote servers +* more unit tests for the aspx completion engine, so it doesn't bitrot again + +You can find a few more at +http://monodevelop.com/Developers/Tasks/Web_Development, but these +aren't exhaustive lists - I'm sure there's a lot of things I haven't +listed here that would be worth doing. The key to a good proposal is +to identify things with the most "bang for the buck" for improving the +ASP.NET experience in MD and making sure it's robust. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + + + +
2012/3/20 Gary Barnett <garybarnett101 at gmail.com>: +> How can I determine the current position in the editor in terms of +> namespace, class, method / property etc? +> +> Im asking in relation to the MonoDoc addin idea on the GSoC ideas page, +> trying to piece together how this would work. + +A pad could subscribe to the workspace's active document change event, +then subscribe to the document's caret position change event. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + +
2012/3/9 Chris Hamons <chris.hamons at ni.com>: +> I'm attempting to make some changes in MonoDevelop (and its plugins) on the +> Mac and am having difficulty getting things to build. +> +> Here's what I'm doing (from +> http://monodevelop.com/Developers/Mac_Support/Building_MonoDevelop_on_OS_X) +> +>> git clone https://github.com/mono/monodevelop.git +>> cd monodevelop +>> export ACLOCAL_FLAGS="-I +>> /Library/Frameworks/Mono.framework/Versions/Current/share/aclocal", +>> export +>> PATH="/Library/Frameworks/Mono.framework/Versions/Current/bin:$PATH" +>> ./configure --profile=mac +> +> If I run +> +>> make && cd main/build/MacOSX && make +> +> I get a usable MonoDevelop.app. However, opening main/Main.sln and selecting +> the "DebugMac" project fails quickly with a large number of namespace errors +> (missing assembly references?). +> +> Is Main.sln kept buildable on the Mac? +> +> I'd like to debug my MonoDevelop changes, and since MonoDevelop lacks an +> "attach to process", I'd assume the only way to do this is to build and +> launch from inside MonoDevelop. Is there another way to debug my changes +> (mdb?)? +> +> I've asked on IRC the last few days to no avail. + +Main.sln should be buildable on Mac- what errors are you getting? + +That said, I generally build from the makefiles, because building MD +in MD triggers MD's GTK# design tool to regenerate its code, which +slows the build down a lot (and sometimes breaks it). If you disable +"build before run" in MD prefs, you can build from the makefiles but +run (and debug) from MD without building. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
> Main.sln should be buildable on Mac- what errors are you getting? + +Things like [Just pulled latest git] ( +http://dl.dropbox.com/u/8791050/macbuild.txt): + +/Users/donblas/Development/mono/monodevelop/main/src/core/MonoDevelop.Projects.Formats.MSBuild/MonoDevelop.Projects.Formats.MSBuild/ProjectBuilder.cs(33,17): +error CS0234: The type or namespace name `Build' does not exist in the +namespace `Microsoft'. Are you missing an assembly reference? + +> If you disable "build before run" in MD prefs, you can build from the +makefiles but +> run (and debug) from MD without building. + +This is amazingly helpful, I'll keep that in mind. + +Thanks, +--Chris + + + +From: Michael Hutchinson <m.j.hutchinson at gmail.com> +To: Chris Hamons <chris.hamons at ni.com> +Cc: monodevelop-devel-list at lists.ximian.com +Date: 03/23/2012 06:39 PM +Subject: Re: [Monodevelop-devel] Main.sln broken on Mac? + + + +2012/3/9 Chris Hamons <chris.hamons at ni.com>: +> I'm attempting to make some changes in MonoDevelop (and its plugins) on +the +> Mac and am having difficulty getting things to build. +> +> Here's what I'm doing (from +> +http://monodevelop.com/Developers/Mac_Support/Building_MonoDevelop_on_OS_X +) +> +>> git clone https://github.com/mono/monodevelop.git +>> cd monodevelop +>> export ACLOCAL_FLAGS="-I +>> /Library/Frameworks/Mono.framework/Versions/Current/share/aclocal", +>> export +>> PATH="/Library/Frameworks/Mono.framework/Versions/Current/bin:$PATH" +>> ./configure --profile=mac +> +> If I run +> +>> make && cd main/build/MacOSX && make +> +> I get a usable MonoDevelop.app. However, opening main/Main.sln and +selecting +> the "DebugMac" project fails quickly with a large number of namespace +errors +> (missing assembly references?). +> +> Is Main.sln kept buildable on the Mac? +> +> I'd like to debug my MonoDevelop changes, and since MonoDevelop lacks an +> "attach to process", I'd assume the only way to do this is to build and +> launch from inside MonoDevelop. Is there another way to debug my changes +> (mdb?)? +> +> I've asked on IRC the last few days to no avail. + +Main.sln should be buildable on Mac- what errors are you getting? + +That said, I generally build from the makefiles, because building MD +in MD triggers MD's GTK# design tool to regenerate its code, which +slows the build down a lot (and sometimes breaks it). If you disable +"build before run" in MD prefs, you can build from the makefiles but +run (and debug) from MD without building. + +-- +Michael Hutchinson +http://mjhutchinson.com + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120326/cd4d7812/attachment.html> ++ + + +
On 26 March 2012 11:33, Chris Hamons <chris.hamons at ni.com> wrote: +>> Main.sln should be buildable on Mac- what errors are you getting? +> +> Things like [Just pulled latest git] +> (http://dl.dropbox.com/u/8791050/macbuild.txt): +> +> /Users/donblas/Development/mono/monodevelop/main/src/core/MonoDevelop.Projects.Formats.MSBuild/MonoDevelop.Projects.Formats.MSBuild/ProjectBuilder.cs(33,17): +> error CS0234: The type or namespace name `Build' does not exist in the +> namespace `Microsoft'. Are you missing an assembly reference? + +Ah. The project files were edited on Windows in such a way that MD's +makefile integration on Mac could no longer handle them. This meant +that if MD saved those project files for any reason, it would would +corrupt them. I though it had been fixed by turning off the makefile +integration on those files, but it turns out that only one had been +fixed. I have now fixed the other two in master. + +Please update from git and revert any local changes to +main/src/core/MonoDevelop.Projects.Formats.MSBuild. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Hi everyone, + +Student proposals are now being accepted for Google Summer of Code! + +You can find a proposal template at the Mono SoC page ( +http://www.google-melange.com/gsoc/org/google/gsoc2012/mono). + +This template has been updated to provide more guidance on the info you +should include on your application, so check it out before you submit your +proposal. + +Good luck! + +andreia gaita +-------------------- +blog.worldofcoding.com +andreiagaita.net +github.com/andreiagaita +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120327/39d1704c/attachment.html> ++ + + + + + +
On 23 March 2012 19:35, Michael Hutchinson <m.j.hutchinson at gmail.com> wrote: +> It is a challenging project, but I believe it's doable in the GSoC +> timeframe. The main challenge is in building a Razor parser. Then you +> should integrate with the existing HTML and C# completion engines. + +Update - Microsoft open-sourced their Razor parser yesterday, and it +has an incremental parser for use in editors: +http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/c5fcf6b687f0#src%2fSystem.Web.Razor%2fRazorEditorParser.cs + +This is great - not only do we not have to write a parser, we can be +sure it will behave correctly. There will still be challenges plugging +this incremental parser into MD's syntax highlighting engine and +background parser system, and making it hand off regions to C# and +HMTL highlighting and completion engines. But hopefully this will free +up some time to work on more advanced editing features such as source +tooltips, or maybe even rename refactoring support. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
2012/3/28 Michael Hutchinson <m.j.hutchinson at gmail.com> + +> On 23 March 2012 19:35, Michael Hutchinson <m.j.hutchinson at gmail.com> +> wrote: +> > It is a challenging project, but I believe it's doable in the GSoC +> > timeframe. The main challenge is in building a Razor parser. Then you +> > should integrate with the existing HTML and C# completion engines. +> +> Update - Microsoft open-sourced their Razor parser yesterday, and it +> has an incremental parser for use in editors: +> +> http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/c5fcf6b687f0#src%2fSystem.Web.Razor%2fRazorEditorParser.cs +> +> This is great - not only do we not have to write a parser, we can be +> sure it will behave correctly. There will still be challenges plugging +> this incremental parser into MD's syntax highlighting engine and +> background parser system, and making it hand off regions to C# and +> HMTL highlighting and completion engines. But hopefully this will free +> up some time to work on more advanced editing features such as source +> tooltips, or maybe even rename refactoring support. +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> + +This is really good news. I'll have to make some changes to my application +to take this fact into account. I’m really grateful for all the provided +answers, because they helped me understand better which features are of +paramount importance. I have one more question related to GSoC. I was told +that it’s always better to send proposals as early as possible. Does it +mean that I should expect some feedback even before the application +deadline, e.g. some hints or changes proposition? Or do you check all the +applications only after deadline, so it’s better to tinker with the details +till the very last day of application period? + + + Piotr Dowgiallo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120328/d5df46c9/attachment.html> ++ + + +
On 28 March 2012 17:09, sparek <sparekd at gmail.com> wrote: +> This is really good news. I'll have to make some changes to my application +> to take this fact into account. I’m really grateful for all the provided +> answers, because they helped me understand better which features are of +> paramount importance. I have one more question related to GSoC. I was told +> that it’s always better to send proposals as early as possible. Does it mean +> that I should expect some feedback even before the application deadline, +> e.g. some hints or changes proposition? Or do you check all the applications +> only after deadline, so it’s better to tinker with the details till the very +> last day of application period? + +We do often provide feedback on proposals before the deadline, and you +can update your application after you submit it, so it may give you a +chance to improve your application in response to feedback, and you +won't risk missing the deadline. + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
On 28 March 2012 21:24, Madushanka fonseka <madushankaf at gmail.com> wrote: +> Hi, +> I am a Sri Lankan Computer Science and engineering student that follows an +> MSC at University of Moratuwa, Sri lanka. +> I am interested in the Gsoc2012 projects related to Monodevelop and +> specifially on the project related to "Make ASP.NET Awesome in +> MonoDevelop". +> +> AS per my knowledge some of the new key features Microsoft introduced in +> ASp.net mvc 2 are, strongly type html helpers, both client and server side +> validation, introduction of areas etc in validation feature Microsoft used +> their scripting files. +> +> regarding implementing strongly typed html helpers +> +> Here I think the support of System.Linq and System.Linq.Expressions in +> hugely required and we need to modify the existing +> helper classes in order to add TextBoxFor like classes. +> +> I have expirience in working with "Awesome MVC"(awesome.codeplex.com/) which +> is available in codeplex we site and I think I have +> the architectural knowledge on this.... +> +> regarding validations +> +> Can we use (do we have rights ) to use Jquery if we are to implment +> client/server side validations in implementing +> asp.ne mvc 2 in MD ??? +> +> Do we have that Annotation support or do we have to implement that as well +> (I think as of now "System.ComponentModel" does not have the annotation +> classes implemented)??? +> +> I would like to know the answers for these queries to proceed on this... + +Mono has a full ASP.NET MVC 3.0 implementation already, this project +is about improving the ASP.NET support in the MonoDevelop IDE to make +it easy to develop ASP.MVC sites. + +Andreia summarized this quite nicely in an email to mono-devel-list: + +"From the chatter I've heard about this today, improving ASP.NET +involves getting the support in MD up to date and making sure it's a +smooth experience for users. Things like ASP.NET MVC3 support, fixing +bugs, adding features. + +Since there's a big scope in this project, you can tell us in your +proposal what you think would make it better in your proposal. What do +ASP.NET developers do on VS that MD could do and doesn't? What are +nice features to have? Are there long-standing bugs or requests in +forums or bugtrackers that could be fixed and would really improve the +ASP.NET experience in MD? This could be improving the coding +experience, or the debugging experience, testing, designing, +refactoring, the UI, etc, etc." + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Fri Mar 9 19:54:17 UTC 2012
+ Ending: Thu Mar 29 19:44:37 UTC 2012
+ Messages: 21
+
+ Last message date:
+ Thu Mar 29 19:44:37 UTC 2012
+ Archived on: Thu Mar 29 19:44:41 UTC 2012
+
+
+
Starting: Fri Mar 9 19:54:17 UTC 2012
+ Ending: Thu Mar 29 19:44:37 UTC 2012
+ Messages: 21
+
+ Last message date:
+ Thu Mar 29 19:44:37 UTC 2012
+ Archived on: Thu Mar 29 19:44:41 UTC 2012
+
+
+
Starting: Fri Mar 9 19:54:17 UTC 2012
+ Ending: Thu Mar 29 19:44:37 UTC 2012
+ Messages: 21
+
+ Last message date:
+ Thu Mar 29 19:44:37 UTC 2012
+ Archived on: Thu Mar 29 19:44:41 UTC 2012
+
+
+
Starting: Fri Mar 9 19:54:17 UTC 2012
+ Ending: Thu Mar 29 19:44:37 UTC 2012
+ Messages: 21
+
+ Last message date:
+ Thu Mar 29 19:44:37 UTC 2012
+ Archived on: Thu Mar 29 19:44:41 UTC 2012
+
+
+
Starting: Fri Mar 9 19:54:17 UTC 2012
+ Ending: Thu Mar 29 19:44:37 UTC 2012
+ Messages: 21
+
+ Last message date:
+ Thu Mar 29 19:44:37 UTC 2012
+ Archived on: Thu Mar 29 19:44:41 UTC 2012
+
+
+
Hi, + +I’ve been accepted for Google Summer of Code with project ‘Support for +ASP .NET MVC in MonoDevelop’ where my goals for the second half of +coding are to create Razor syntax highlighter and hopefully code +completion engine. I’ve been investigating the existing code - the +parsers, highlighters and code completion engines, especially those in +AspNet Addin, and the relations between all those parts. I think I +understand how they work, but I have some questions to the more +experienced developers which could help me understand better the code +and prepare a good, working implementation. + +I’d like to start my implementation with syntax highlighter, which is +probably an easier part. Creating XML syntax mode seems to not be enough +for Razor syntax, so I decided to create the highlighter in C#, deriving +from Mono.TextEditor.Highlighting.SyntaxMode. AspNet SyntaxMode may be a +good reference here, because I’ll be facing similar issues related to +passing some fragments from html to C# engines. Is it a good idea? + +As you probably know, Razor parser was open-sourced a few weeks ago, so +the best approach is to use the working solution and integrate it with +MD. I’m trying to understand the code, and as I can see a lot of things +were implemented, e.g. parser, tokenizer, editor-related classes +(http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/a6a917711a44#src%2fSystem.Web.Razor%2fRazorEditorParser.cs),as +well as classes like AutoCompleteEditHandler, but I’m not yet aware to +what extent it’ll be possible to use it in my project. My idea is to +create wrappers around the open-sourced code and integrate them with MD +architecture and extension points.Is it ok? + +Generally, I have a vision of implementation, but I’d like to ask you +for some high-level advice. Are there any pitfalls I can’t see, or +should I avoid any specific approaches? As more experienced developers, +maybe you have your own ideas or tips related to integrating the Razor +parser with MD that might help me? Of course I’ll be investigating the +code deeper and deeper and my vision of the project will soon get clear, +but any help will be welcome, because I really would like to do this in +a good, proper way. +Thanks in advance. + +Piotr Dowgiallo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20120517/b342d940/attachment.html> ++ + +
Starting: Thu May 17 18:12:27 UTC 2012
+ Ending: Thu May 17 18:12:27 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Thu May 17 18:12:27 UTC 2012
+ Archived on: Thu May 17 18:12:40 UTC 2012
+
+
+
Starting: Thu May 17 18:12:27 UTC 2012
+ Ending: Thu May 17 18:12:27 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Thu May 17 18:12:27 UTC 2012
+ Archived on: Thu May 17 18:12:40 UTC 2012
+
+
+
Starting: Thu May 17 18:12:27 UTC 2012
+ Ending: Thu May 17 18:12:27 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Thu May 17 18:12:27 UTC 2012
+ Archived on: Thu May 17 18:12:40 UTC 2012
+
+
+
Starting: Thu May 17 18:12:27 UTC 2012
+ Ending: Thu May 17 18:12:27 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Thu May 17 18:12:27 UTC 2012
+ Archived on: Thu May 17 18:12:40 UTC 2012
+
+
+
Starting: Thu May 17 18:12:27 UTC 2012
+ Ending: Thu May 17 18:12:27 UTC 2012
+ Messages: 1
+
+ Last message date:
+ Thu May 17 18:12:27 UTC 2012
+ Archived on: Thu May 17 18:12:40 UTC 2012
+
+
+
Hello Team Mono, +I am a student from India studying in a premier institute, BITS-Pilani. I +have gone through your list of ideas for various projects and found them +quite interesting. I love the idea of open source and am really excited +about making a contribution through GSoC 2013. I found the idea: 'Make +ASP.NET Awesome in Xamarin Studio' particularly interesting and would like +to enquire more about this project. I have worked with ASP.NET and C# for +around an year and I may be able to use those skills for this project. I +know C, Java and Python as well. Please send me a few details about what is +expected to be done in this project and what tools to use to start +development. + +Thanking You, +Siddharth Jain +India +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130412/d2a8f60b/attachment.html> ++ + + + +
Hello, I am interesting in implementing css support. What would be better +to do at first? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130413/b9e9e7c9/attachment.html> ++ + + + +
Hi all, + +My name is Galina. I study IT product design and in my free time I learn programming. I have also taken a half a year academic course in C# programming and that is why I am so interested in mono project. You have a bunch of interesting projects for students and I would like to work on the one called Color Scheme Editor. I wonder if somebody has any ideas what would be the main/first steps for the project or give me some hints where I could go for inspiration. Thanks in advance. + +Best regards/ Med venlig hilsen, + +Galina Orlova +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130414/6b932574/attachment.html> ++ + + + + +
How can I contact with the mentor (Michael Hutchinson, Bojan Rajkovic) of +this project? Is it through this mailing list? As this is my first +appearance in GSOC I have not a concrete idea about this. Before applying +this project I need to know some more information about this project. Sorry +for such a late contact as I have heard about it lately. + +Thank you. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130414/ba033dda/attachment.html> ++ + + + + +
Hi, + +I'm an undergraduate based on Sri Lanka and I like to participate in Google +Summer of Code 2013 in the category of .NET programming language. As I'm +familiar with C# .NET, I found MonoDevelop is a great project to contribute +in this season. + +I'm interested mainly on back-end (core lib) development and I +found MonoDevelop category is suitable for me. I'm interested in the +proposed project named "Source Analysis". Since then I'm on Google looking +for; +1 NRefactory and Source analysis +2 Source analysis using NRefactory and I am going through downloaded GIT +zip repository of MonoDevelop + +So, it would be very helpful if I can get some guide on how should I +proceed further with the project "Source Analysis". + +Thanks +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130414/38d8135a/attachment.html> ++ + + + + + +
Hi, + +I'm Shovon from Bangladesh, studying B.Sc in Computer Science and +Engineering. +I am willing to participate in Google Summer of Code 2013. As I'm familiar +with C++, html, CSS, and .net framework, I think this project will suit for +me. + +So, it would be very much helpful if I get some guideline of this project. + +Thank you. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130415/4eb08fe3/attachment.html> ++ + + + + + +
Hi, + +I'm Shovon from Bangladesh, studying B.Sc in Computer Science and +Engineering. +I am willing to participate in Google Summer of Code 2013. As I'm familiar +with C++, html, CSS, and .net framework, I think this project will suit for +me. + +So, it would be very much helpful if I get some guideline of this project +before applying for this project. + +Thank you. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130415/a9b6481d/attachment.html> ++ + + + + + + +
Dear All, + +I am currently a master student in Software Engineering at Faculty of +Electrical Engineering and Computing, member of the University of Zagreb +(Croatia). +The project that catches my attention is the implementation of a better +formatting engine for Xamarian Studio. I have downloaded the newest source +for MonoDevelop from Git, and at the beginning I'm having trouble finding +the current implementation of the indentation engine. I would appreciate if +someone would help me with that. +Also, any additional information would be great, so that I can get a better +understanding of the difficulty of this project. + +Thank You, +Matej Miklečić. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130417/8c157aa7/attachment.html> ++ + + + + + + +
Hi, + +The indenter is here: +https://github.com/mono/monodevelop/blob/master/main/src/addins/CSharpBinding/MonoDevelop.CSharp.Formatting/CSharpIndentEngine.cs + +There is also an on the fly formatter that reformats statements and +blocks when the closing semicolon/brace is types: +https://github.com/mono/monodevelop/blob/master/main/src/addins/CSharpBinding/MonoDevelop.CSharp.Formatting/OnTheFlyFormatter.cs + +Unfortunately the indenter has not been well maintained for some time, +and does not handle newer C# constructs well (lambda, etc), and does +not respect the code formatting style settings. + +The goal of this project would be to improve the intenter so that it's +more maintainable and respects all the formatting settings. Ideally it +would use the on the fly formatter to calculate the indent when +possible, with perhaps some fallback heuristics when the on the fly +formatter fails. + +- Michael + + +On 17 April 2013 14:45, Matej Miklečić <matej.miklecic at gmail.com> wrote: +> Dear All, +> +> I am currently a master student in Software Engineering at Faculty of +> Electrical Engineering and Computing, member of the University of Zagreb +> (Croatia). +> The project that catches my attention is the implementation of a better +> formatting engine for Xamarian Studio. I have downloaded the newest source +> for MonoDevelop from Git, and at the beginning I'm having trouble finding +> the current implementation of the indentation engine. I would appreciate if +> someone would help me with that. +> Also, any additional information would be great, so that I can get a better +> understanding of the difficulty of this project. +> +> Thank You, +> Matej Miklečić. +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + + +
The project page has an overview of the project and some examples of +things that could be done: +http://www.mono-project.com/StudentProjects#Make_ASP.NET_Awesome_in_Xamarin_Studio + +This particular project is very flexible. I'm looking for a student +who knows how to create a good development experience, so the proposal +is a chance to show that you're capable of looking at what's already +there and seeing what could be improved, and doing research comparing +it to other development tools such as Visual Studio. If you have +specific questions about the how/why of various things please ask, but +I'm not going to give an itemized list of tasks for this project - I +want to see what you can come up with :) + +On 12 April 2013 07:15, Siddharth Jain <sid270592 at gmail.com> wrote: +> Hello Team Mono, +> I am a student from India studying in a premier institute, BITS-Pilani. I +> have gone through your list of ideas for various projects and found them +> quite interesting. I love the idea of open source and am really excited +> about making a contribution through GSoC 2013. I found the idea: 'Make +> ASP.NET Awesome in Xamarin Studio' particularly interesting and would like +> to enquire more about this project. I have worked with ASP.NET and C# for +> around an year and I may be able to use those skills for this project. I +> know C, Java and Python as well. Please send me a few details about what is +> expected to be done in this project and what tools to use to start +> development. +> +> Thanking You, +> Siddharth Jain +> India +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
You can find some examples of writing source analysis issues here: +http://mikemdblog.blogspot.com/2012/04/how-to-write-c-issue-provider.html + +For ideas of rules and context actions, I suggest looking at other +static analysis tools for C# (e.g. Resharper, FXCop). + +On 14 April 2013 11:31, FM Irshad <fmir864 at gmail.com> wrote: +> Hi, +> +> I'm an undergraduate based on Sri Lanka and I like to participate in Google +> Summer of Code 2013 in the category of .NET programming language. As I'm +> familiar with C# .NET, I found MonoDevelop is a great project to contribute +> in this season. +> +> I'm interested mainly on back-end (core lib) development and I found +> MonoDevelop category is suitable for me. I'm interested in the proposed +> project named "Source Analysis". Since then I'm on Google looking for; +> 1 NRefactory and Source analysis +> 2 Source analysis using NRefactory and I am going through downloaded GIT zip +> repository of MonoDevelop +> +> So, it would be very helpful if I can get some guide on how should I proceed +> further with the project "Source Analysis". +> +> Thanks +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
The core of this project is writing a good CSS parser - although, if +you can find an existing open-source (and appropriately licensed) CSS +parser, you would ideally use that and focus on other things. Based on +this parser you would then implement CSS code completion and syntax +highlighting. You would also have to create the code completion +database so that the completion would know what properties/selectors +were available for different CSS standards. + +There is some flexibility exactly what features you include in your +proposal - for example, you could also include document outline and +breadcrumb, inline completion in Razor pages, error underlining for +CSS properties not supported by current browser profile, stuff like +that - but at minimum I would expect the parser and completion engine +to be completed for the project to be considered a success. + +On 14 April 2013 14:32, Shovon Jamali <shovonjamali at gmail.com> wrote: +> Hi, +> +> I'm Shovon from Bangladesh, studying B.Sc in Computer Science and +> Engineering. +> I am willing to participate in Google Summer of Code 2013. As I'm familiar +> with C++, html, CSS, and .net framework, I think this project will suit for +> me. +> +> So, it would be very much helpful if I get some guideline of this project +> before applying for this project. +> +> Thank you. +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
On 14 April 2013 07:07, Galina Orlova <gala_orlova at yahoo.com> wrote: +> My name is Galina. I study IT product design and in my free time I learn +> programming. I have also taken a half a year academic course in C# +> programming and that is why I am so interested in mono project. You have a +> bunch of interesting projects for students and I would like to work on the +> one called Color Scheme Editor. I wonder if somebody has any ideas what +> would be the main/first steps for the project or give me some hints where I +> could go for inspiration. Thanks in advance. + +The first step would be to look at the existing color scheme editor +and thinking of ways you could improve it. It's currently just a big +list of colors, which isn't a very good editing experience. + +You might for example have a more interactive way of editing colors on +a sample document like this: http://studiostyl.es/schemes/create +Or a tool for generating a scheme based on several core colors: +http://frickinsweet.com/tools +Or perhaps some kind of contrast/color theory based engine for +identifying and highlighting potential problems in color schemes e.g. +black text on black background... + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Hello, + +I've looked at the project ideas page to help me decide which +proposal(s) to make and the "Source Analysis" idea caught my +attention. + +If I understand this correctly, it's about checking for code issues +and offering the option to correct them. +This project reminds me of Gendarme, although Gendarme runs on +compiled executables/libraries and does not offer the option to fix +the code automatically. +Is that the sort of issues you wish to see the source analysis check for? + +One thing I noticed is that (git master) MonoDevelop has a +"MonoDevelop.CSharp.Refactoring.CodeIssues.NamingInspection" +interface, but I don't see any warnings in the editor. Am I looking at +the wrong place? Am I doing something wrong? + +If I was assigned to this project, I'd start with something simple +like directly extracting a lambda expression to a method (which +currently requires two steps), and then advance for more complex +stuff. +The possibilities include: + +1. Check for switch statements on enums that do not include a default +case/are missing cases +2. Check for unused exceptions (equivalent of +CheckNewExceptionWithoutThrowingRule in Gendarme, but with the option +to fix it by adding a 'throw') +3. If a class has a public method with no arguments named 'Dispose' +but does not implement IDisposable, show a warning (similar to +OnlyUseDisposeForIDisposableTypesRule in Gendarme) and show the option +to fix by adding IDisposable to list of implemented interfaces. +4. Option to convert query syntax LINQ expression to the equivalent +method syntax. +For instance, "from x in y select x + 1" would become "y.Select(x => x + 1)" +Also, the reverse operation could be available. +5. (No warning - just an available refactoring action) Convert if or +?: expression to ??, if applicable. +6. DoNotLockOnThisOrTypesRule equivalent - option to create a private +mutex object +7. Same for DoNotUseMethodImplOptionsSynchronizedRule. +8. DoNotUseThreadStaticWithInstanceFieldsRule - option to either +remove the attribute or make field static +9. Option to remove (or add) redundant access modifiers (such as +private for class fields) +10. Option to remove unused private fields or methods +11. Equivalent of DoNotDestroyStackTraceRule and option to fix +12. XamarinStudio bug #10351 https://bugzilla.xamarin.com/show_bug.cgi?id=10351 + +I'm not sure how long each of these tasks take (since I'm not yet very +familiar with the MonoDevelop code), so I'd like some feedback to know +not only if this is what's intended, but also how many of these tasks +should be done (are these too many? too few? just enough?) +I know C# (it's currently one of my most frequently used +languages),but not NRefactory (so I don't yet know how hard these +tasks are nor how long they should take) + +By the way, I've noticed a bug in MonoDevelop (git master) while I was +using the current refactoring tools: +When I have this code: +var y = (Func<int, int>)(x => x); +"Convert to anonymous delegate" generates this (incorrect) code: +var y = (Func<int, int>)(delegate (int x) { + x; +}); +Note the lack of a return statement. +(I guess fixing this rule could be a good starting point to learn how +things are currently done if it isn't fixed until the project starts.) + +Thank you for your time, +Luís Reis ++ + + +
Yes, you're on the right track :) + +Source analysis exists in MD already - the project is about creating +more rules for it, and possibly more infrastructure, e.g. solution +wide analysis, pad showing all rules, UI for managing rule style +options, spell checking service etc. You could also create some +context actions (e.g. inline method) and refactorings (e.g. reorder +parameters). Since it's flexible and broad, we could potentially have +several students accepted for this project but working on different +rules/actions/refactorings/infrastructure. + +You can enable source analysis in Preferences->Source analysis. As of +MD 3.0.9+, context actions are always available via at-enter or the +context menu, though when source analysis is enabled, they are also +accessible via a hint marker on the source editor. + +You can find an article on writing source analysis rules here: +http://mikemdblog.blogspot.com/2012/04/how-to-write-c-issue-provider.html + +It's essentially up to you to propose rules or infrastructure pieces +you'd like to work on :) + + +On 25 April 2013 18:02, Luís Reis <luiscubal at gmail.com> wrote: +> Hello, +> +> I've looked at the project ideas page to help me decide which +> proposal(s) to make and the "Source Analysis" idea caught my +> attention. +> +> If I understand this correctly, it's about checking for code issues +> and offering the option to correct them. +> This project reminds me of Gendarme, although Gendarme runs on +> compiled executables/libraries and does not offer the option to fix +> the code automatically. +> Is that the sort of issues you wish to see the source analysis check for? +> +> One thing I noticed is that (git master) MonoDevelop has a +> "MonoDevelop.CSharp.Refactoring.CodeIssues.NamingInspection" +> interface, but I don't see any warnings in the editor. Am I looking at +> the wrong place? Am I doing something wrong? +> +> If I was assigned to this project, I'd start with something simple +> like directly extracting a lambda expression to a method (which +> currently requires two steps), and then advance for more complex +> stuff. +> The possibilities include: +> +> 1. Check for switch statements on enums that do not include a default +> case/are missing cases +> 2. Check for unused exceptions (equivalent of +> CheckNewExceptionWithoutThrowingRule in Gendarme, but with the option +> to fix it by adding a 'throw') +> 3. If a class has a public method with no arguments named 'Dispose' +> but does not implement IDisposable, show a warning (similar to +> OnlyUseDisposeForIDisposableTypesRule in Gendarme) and show the option +> to fix by adding IDisposable to list of implemented interfaces. +> 4. Option to convert query syntax LINQ expression to the equivalent +> method syntax. +> For instance, "from x in y select x + 1" would become "y.Select(x => x + 1)" +> Also, the reverse operation could be available. +> 5. (No warning - just an available refactoring action) Convert if or +> ?: expression to ??, if applicable. +> 6. DoNotLockOnThisOrTypesRule equivalent - option to create a private +> mutex object +> 7. Same for DoNotUseMethodImplOptionsSynchronizedRule. +> 8. DoNotUseThreadStaticWithInstanceFieldsRule - option to either +> remove the attribute or make field static +> 9. Option to remove (or add) redundant access modifiers (such as +> private for class fields) +> 10. Option to remove unused private fields or methods +> 11. Equivalent of DoNotDestroyStackTraceRule and option to fix +> 12. XamarinStudio bug #10351 https://bugzilla.xamarin.com/show_bug.cgi?id=10351 +> +> I'm not sure how long each of these tasks take (since I'm not yet very +> familiar with the MonoDevelop code), so I'd like some feedback to know +> not only if this is what's intended, but also how many of these tasks +> should be done (are these too many? too few? just enough?) +> I know C# (it's currently one of my most frequently used +> languages),but not NRefactory (so I don't yet know how hard these +> tasks are nor how long they should take) +> +> By the way, I've noticed a bug in MonoDevelop (git master) while I was +> using the current refactoring tools: +> When I have this code: +> var y = (Func<int, int>)(x => x); +> "Convert to anonymous delegate" generates this (incorrect) code: +> var y = (Func<int, int>)(delegate (int x) { +> x; +> }); +> Note the lack of a return statement. +> (I guess fixing this rule could be a good starting point to learn how +> things are currently done if it isn't fixed until the project starts.) +> +> Thank you for your time, +> Luís Reis +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
Starting: Fri Apr 12 11:15:34 UTC 2013
+ Ending: Fri Apr 26 01:32:03 UTC 2013
+ Messages: 15
+
+ Last message date:
+ Fri Apr 26 01:32:03 UTC 2013
+ Archived on: Fri Apr 26 01:32:27 UTC 2013
+
+
+
Starting: Fri Apr 12 11:15:34 UTC 2013
+ Ending: Fri Apr 26 01:32:03 UTC 2013
+ Messages: 15
+
+ Last message date:
+ Fri Apr 26 01:32:03 UTC 2013
+ Archived on: Fri Apr 26 01:32:27 UTC 2013
+
+
+
Starting: Fri Apr 12 11:15:34 UTC 2013
+ Ending: Fri Apr 26 01:32:03 UTC 2013
+ Messages: 15
+
+ Last message date:
+ Fri Apr 26 01:32:03 UTC 2013
+ Archived on: Fri Apr 26 01:32:27 UTC 2013
+
+
+
Starting: Fri Apr 12 11:15:34 UTC 2013
+ Ending: Fri Apr 26 01:32:03 UTC 2013
+ Messages: 15
+
+ Last message date:
+ Fri Apr 26 01:32:03 UTC 2013
+ Archived on: Fri Apr 26 01:32:27 UTC 2013
+
+
+
Starting: Fri Apr 12 11:15:34 UTC 2013
+ Ending: Fri Apr 26 01:32:03 UTC 2013
+ Messages: 15
+
+ Last message date:
+ Fri Apr 26 01:32:03 UTC 2013
+ Archived on: Fri Apr 26 01:32:27 UTC 2013
+
+
+
I think this has something do do with the compiler name changes, i.e. "mcs" +is no longer the 1.0 framework's compiler, it can compile for any framework +and defaults to 4.5. This means you're building gnome# with the 4.5 +framework, when it expects to be built with the 1.0 framework. And somehow +it's using the 2.0 Mono.Cairo too. Maybe ART# got compiled against the +system GTK# and GNOME# is compiling against the locally built GTK#. + +Not sure why that would fail in this way though. + + +On 31 December 2012 10:19, Jeremy Reeve <jezz at kamelio.co.uk> wrote: + +> +> Hi there, +> +> I'm trying to compile monodevelop (master) on my Fedora 17 system. I +> would like to try out the F# support and from what I can gather, that is +> best done with mono/monodevelop 3+ +> +> I've compiled the entire mono stack locally which consists of: +> +> mono (master) +> fsharp (master) +> gtk-sharp (gtk-sharp-2-12-branch) <== not sure this is correct... +> gnome-sharp (master) +> monodevelop (master) +> +> Configuring gnome-sharp: +> +> [jsr at hermes gnome-sharp]$ ./bootstrap-2.24 --prefix=/home/jsr/local +> + sed -e s/@GNOME_SHARP_VERSION@/2.24.2/ -e +> s/@GTK_REQUIRED_VERSION@/2.13.0/ -e +> s/@GTK_SHARP_REQUIRED_VERSION@/2.12.2/ -e +> s/@GNOME_REQUIRED_VERSION@/2.23.0/ -e +> s/@GNOMECANVAS_REQUIRED_VERSION@/2.20.0/ -e +> 's/@VERSIONCSDEFINES@/-define:GTK_SHARP_2_6 -define:GTK_SHARP_2_8 +> -define:GNOME_SHARP_2_16 -define:GNOME_SHARP_2_20 +> -define:GNOME_SHARP_2_24/' -e 's/@VERSIONCFLAGS@/-DGTK_SHARP_2_6 +> -DGTK_SHARP_2_8 -DGNOME_SHARP_2_16 -DGNOME_SHARP_2_20 +> -DGNOME_SHARP_2_24/' -e 's/@POLICY_VERSIONS@/2.4 2.6 2.8 2.16 2.20/' -e +> s/@ASSEMBLY_VERSION@/2.24.0.0/ ./configure.in.in +> Running libtoolize... +> libtoolize: putting auxiliary files in `.'. +> libtoolize: copying file `./ltmain.sh' +> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in +> and +> libtoolize: rerunning libtoolize, to keep the correct libtool macros +> in-tree. +> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. +> Running aclocal ... +> Running autoheader... +> Running automake --foreign ... +> Running autoconf ... +> Running ./configure --enable-maintainer-mode --enable-compile-warnings +> --prefix=/home/jsr/local ... +> configure: WARNING: unrecognized options: --enable-compile-warnings +> checking build system type... x86_64-unknown-linux-gnu +> checking host system type... x86_64-unknown-linux-gnu +> checking target system type... x86_64-unknown-linux-gnu +> checking for a BSD-compatible install... /usr/bin/install -c +> checking whether build environment is sane... yes +> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p +> checking for gawk... gawk +> checking whether make sets $(MAKE)... yes +> checking whether to enable maintainer-specific portions of Makefiles... +> yes +> checking for gcc... gcc +> checking for gcc... (cached) gcc +> checking whether the C compiler works... yes +> checking for C compiler default output file name... a.out +> checking for suffix of executables... +> checking whether we are cross compiling... no +> checking for suffix of object files... o +> checking whether we are using the GNU C compiler... yes +> checking whether gcc accepts -g... yes +> checking for gcc option to accept ISO C89... none needed +> checking for style of include used by make... GNU +> checking dependency style of gcc... gcc3 +> checking for gcc... (cached) gcc +> checking whether we are using the GNU C compiler... (cached) yes +> checking whether gcc accepts -g... (cached) yes +> checking for gcc option to accept ISO C89... (cached) none needed +> checking dependency style of gcc... (cached) gcc3 +> checking how to run the C preprocessor... gcc -E +> checking for grep that handles long lines and -e... /usr/bin/grep +> checking for egrep... /usr/bin/grep -E +> checking for ANSI C header files... yes +> checking how to print strings... printf +> checking for a sed that does not truncate output... /usr/bin/sed +> checking for fgrep... /usr/bin/grep -F +> checking for ld used by gcc... /usr/bin/ld +> checking if the linker (/usr/bin/ld) is GNU ld... yes +> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B +> checking the name lister (/usr/bin/nm -B) interface... BSD nm +> checking whether ln -s works... yes +> checking the maximum length of command line arguments... 1572864 +> checking whether the shell understands some XSI constructs... yes +> checking whether the shell understands "+="... yes +> checking how to convert x86_64-unknown-linux-gnu file names to +> x86_64-unknown-linux-gnu format... func_convert_file_noop +> checking how to convert x86_64-unknown-linux-gnu file names to toolchain +> format... func_convert_file_noop +> checking for /usr/bin/ld option to reload object files... -r +> checking for objdump... objdump +> checking how to recognize dependent libraries... pass_all +> checking for dlltool... dlltool +> checking how to associate runtime and link libraries... printf %s\n +> checking for ar... ar +> checking for archiver @FILE support... @ +> checking for strip... strip +> checking for ranlib... ranlib +> checking command to parse /usr/bin/nm -B output from gcc object... ok +> checking for sysroot... no +> checking for mt... no +> checking if : is a manifest tool... no +> checking for sys/types.h... yes +> checking for sys/stat.h... yes +> checking for stdlib.h... yes +> checking for string.h... yes +> checking for memory.h... yes +> checking for strings.h... yes +> checking for inttypes.h... yes +> checking for stdint.h... yes +> checking for unistd.h... yes +> checking for dlfcn.h... yes +> checking for objdir... .libs +> checking if gcc supports -fno-rtti -fno-exceptions... no +> checking for gcc option to produce PIC... -fPIC -DPIC +> checking if gcc PIC flag -fPIC -DPIC works... yes +> checking if gcc static flag -static works... no +> checking if gcc supports -c -o file.o... yes +> checking if gcc supports -c -o file.o... (cached) yes +> checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports +> shared libraries... yes +> checking whether -lc should be explicitly linked in... no +> checking dynamic linker characteristics... GNU/Linux ld.so +> checking how to hardcode library paths into programs... immediate +> checking whether stripping libraries is possible... yes +> checking if libtool supports shared libraries... yes +> checking whether to build shared libraries... yes +> checking whether to build static libraries... yes +> checking size of void *... 8 +> checking for pkg-config... /usr/bin/pkg-config +> checking pkg-config is at least version 0.9.0... yes +> checking for MONO_DEPENDENCY... yes +> checking for gacutil... /home/jsr/local/bin/gacutil +> checking for al... /home/jsr/local/bin/al +> checking for mono... /home/jsr/local/bin/mono +> checking for mcs... /home/jsr/local/bin/mcs +> checking for MONO_CAIRO... yes +> checking for GTKSHARP... yes +> checking for GLADESHARP... yes +> checking for GAPI... yes +> checking for gapi2-parser... /home/jsr/local/bin/gapi2-parser +> checking for gapi2-codegen... /home/jsr/local/bin/gapi2-codegen +> checking for gapi2-fixup... /home/jsr/local/bin/gapi2-fixup +> checking for LIBART... yes +> checking for GNOMEVFS... yes +> checking for GNOME... yes +> configure: creating ./config.status +> config.status: creating AssemblyInfo.cs +> config.status: creating Makefile +> config.status: creating policy.config +> config.status: creating sources/Makefile +> config.status: creating art/Makefile +> config.status: creating art/art-sharp.dll.config +> config.status: creating art/art-sharp-2.0.pc +> config.status: creating gnome/Makefile +> config.status: creating gnome/gnome-sharp.dll.config +> config.status: creating gnome/gnome-sharp-2.0.pc +> config.status: creating gnome/glue/Makefile +> config.status: creating gnomevfs/Makefile +> config.status: creating gnomevfs/gnome-vfs-sharp.dll.config +> config.status: creating gnomevfs/gnome-vfs-sharp-2.0.pc +> config.status: creating gconf/Makefile +> config.status: creating gconf/doc/Makefile +> config.status: creating gconf/GConf/Makefile +> config.status: creating gconf/GConf/gconf-sharp.dll.config +> config.status: creating gconf/GConf/gconf-sharp-2.0.pc +> config.status: creating gconf/GConf.PropertyEditors/Makefile +> config.status: creating +> gconf/GConf.PropertyEditors/gconf-sharp-peditors-2.0.pc +> config.status: creating gconf/tools/Makefile +> config.status: creating gconf/tools/gconfsharp2-schemagen +> config.status: creating sample/Makefile +> config.status: creating sample/gconf/Makefile +> config.status: creating sample/gnomevfs/Makefile +> config.status: creating config.h +> config.status: config.h is unchanged +> config.status: executing depfiles commands +> config.status: executing libtool commands +> configure: WARNING: unrecognized options: --enable-compile-warnings +> --- +> Configuration summary +> +> * Installation prefix = /home/jsr/local +> * C# compiler: /home/jsr/local/bin/mcs -debug -define:GTK_SHARP_2_6 +> -define:GTK_SHARP_2_8 -define:GNOME_SHARP_2_16 -define:GNOME_SHARP_2_20 +> -define:GNOME_SHARP_2_24 +> +> Optional assemblies included in the build: +> +> * art-sharp.dll: yes +> * gnomevfs-sharp.dll: yes +> * gnome-sharp.dll: yes +> +> NOTE: if any of the above say 'no' you may install the +> corresponding development packages for them, rerun +> autogen.sh to include them in the build. +> +> gnome-sharp.dll requires libgnomecanvas, libgnome, +> and libgnomeui. +> --- +> Now type `make' to compile +> [jsr at hermes gnome-sharp]$ +> +> +> My gnome-sharp build fails with the following: +> +> [jsr at hermes gnome-sharp]$ make +> make all-recursive +> make[1]: Entering directory `/home/jsr/dev/gnome-sharp' +> Making all in sources +> make[2]: Entering directory `/home/jsr/dev/gnome-sharp/sources' +> make[2]: Nothing to be done for `all'. +> make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/sources' +> Making all in art +> make[2]: Entering directory `/home/jsr/dev/gnome-sharp/art' +> make[2]: Nothing to be done for `all'. +> make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/art' +> Making all in gnomevfs +> make[2]: Entering directory `/home/jsr/dev/gnome-sharp/gnomevfs' +> Making all in . +> make[3]: Entering directory `/home/jsr/dev/gnome-sharp/gnomevfs' +> make[3]: Nothing to be done for `all-am'. +> make[3]: Leaving directory `/home/jsr/dev/gnome-sharp/gnomevfs' +> make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/gnomevfs' +> Making all in gnome +> make[2]: Entering directory `/home/jsr/dev/gnome-sharp/gnome' +> Making all in . +> make[3]: Entering directory `/home/jsr/dev/gnome-sharp/gnome' +> /home/jsr/local/bin/mcs -debug -define:GTK_SHARP_2_6 +> -define:GTK_SHARP_2_8 -define:GNOME_SHARP_2_16 -define:GNOME_SHARP_2_20 +> -define:GNOME_SHARP_2_24 -nowarn:0169,0612,0618 -unsafe +> -out:gnome-sharp.dll -target:library +> -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/pango-sharp.dll +> -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll +> -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gdk-sharp.dll +> -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll +> -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glib-sharp.dll +> /r:../art/art-sharp.dll /r:../gnomevfs/gnome-vfs-sharp.dll +> -r:/home/jsr/local/lib/pkgconfig/../../lib/mono/2.0/Mono.Cairo.dll +> generated/*.cs ./BonoboUIVerb.cs ./IconTheme.cs ./Modules.cs +> AssemblyInfo.cs +> AssemblyInfo.cs(6,11): warning CS1699: Use compiler option `keyfile' or +> appropriate project settings instead of `AssemblyKeyFile' attribute +> generated/App.cs(41,17): warning CS0108: `Gnome.App.Name' hides +> inherited member `Gtk.Widget.Name'. Use the new keyword if hiding was +> intended +> /home/jsr/local/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll +> (Location of the symbol related to previous warning) +> generated/ThemeFile.cs(41,26): warning CS0809: Obsolete member +> `Gnome.ThemeFile.ToString()' overrides non-obsolete member +> `object.ToString()' +> /home/jsr/local/lib/mono/4.5/mscorlib.dll (Location of the symbol +> related to previous warning) +> generated/CanvasShape.cs(200,41): error CS0030: Cannot convert type +> `GLib.Value' to `Art.VpathDash' +> Compilation failed: 1 error(s), 3 warnings +> make[3]: *** [gnome-sharp.dll] Error 1 +> make[3]: Leaving directory `/home/jsr/dev/gnome-sharp/gnome' +> make[2]: *** [all-recursive] Error 1 +> make[2]: Leaving directory `/home/jsr/dev/gnome-sharp/gnome' +> make[1]: *** [all-recursive] Error 1 +> make[1]: Leaving directory `/home/jsr/dev/gnome-sharp' +> make: *** [all] Error 2 +> [jsr at hermes gnome-sharp]$ +> +> +> If I've left out any information helpful to resolution of the problem, +> I'd be more than happy to provide it. +> +> Any help appreciated. +> +> Regards...Jeremy +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130109/c80e74e4/attachment-0001.html> ++ + + +
+Hi Michael, + +On Wed, 2013-01-09 at 16:33 +0000, Michael Hutchinson wrote: +> I think this has something do do with the compiler name changes, i.e. +> "mcs" is no longer the 1.0 framework's compiler, it can compile for +> any framework and defaults to 4.5. This means you're building gnome# +> with the 4.5 framework, when it expects to be built with the 1.0 +> framework. And somehow it's using the 2.0 Mono.Cairo too. Maybe ART# +> got compiled against the system GTK# and GNOME# is compiling against +> the locally built GTK#. +> +> +> Not sure why that would fail in this way though. +> + +Thanks for looking at this. It turned out to be a case of user error. +It seems that I ran the original build while there was a system mono + +gnome# library installed which in turn generated the C# sources by +inspecting the system libraries. The subsequent shift to a parallel +mono stack obviously didn't affect the already generated sources. + +Executing a "make clean" caused the sources to be regenerated and +resolved the problem. + +Regards...Jeremy + + ++ + + +
Hi everyone, + +with the last few commits the Debugger is totally broken. You cannot set +the breakpoint via mouse (you can do it via the menu) when the debugger +reaches a breakpoint another exception will be thrown. Also you cannot +investigate any local variables and so one. +Fix it please. + +Regards +Marcel Hellwig + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: signature.asc +Type: application/pgp-signature +Size: 899 bytes +Desc: OpenPGP digital signature +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/3e43b7c2/attachment.pgp> ++ + + +
Hey, + +What platform/target are you trying to debug? + + +On Thu, Jan 10, 2013 at 11:19 AM, Marcel Hellwig <keks at cookiesoft.de> wrote: + +> Hi everyone, +> +> with the last few commits the Debugger is totally broken. You cannot set +> the breakpoint via mouse (you can do it via the menu) when the debugger +> reaches a breakpoint another exception will be thrown. Also you cannot +> investigate any local variables and so one. +> Fix it please. +> +> Regards +> Marcel Hellwig +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/2e802912/attachment.html> ++ + + +
Am 10.01.2013 17:26, schrieb Miguel de Icaza: +> Hey, +> +> What platform/target are you trying to debug? +Fedora 17 x64 + + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: signature.asc +Type: application/pgp-signature +Size: 899 bytes +Desc: OpenPGP digital signature +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/f8d38b95/attachment.pgp> ++ + + +
Hi Marcel, + +What commits to what branch? + +I'm able to add breakpoints with the mouse just fine. I get no exceptions +when breakpoints are hit. + +What am I missing? + +Jeff + +On Thu, Jan 10, 2013 at 11:19 AM, Marcel Hellwig <keks at cookiesoft.de> wrote: + +> Hi everyone, +> +> with the last few commits the Debugger is totally broken. You cannot set +> the breakpoint via mouse (you can do it via the menu) when the debugger +> reaches a breakpoint another exception will be thrown. Also you cannot +> investigate any local variables and so one. +> Fix it please. +> +> Regards +> Marcel Hellwig +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/534d1704/attachment.html> ++ + + +
Am 10.01.2013 17:57, schrieb Jeff Stedfast: +> Hi Marcel, +> +> What commits to what branch? +> +> I'm able to add breakpoints with the mouse just fine. I get no +> exceptions when breakpoints are hit. +> +> What am I missing? + +Don't know +configure is with main, database and debugger, then make and make install. +Here is the stacktrace + +System.MissingMethodException: Method not found: +'Mono.Debugging.Client.BreakpointStore.Toggle'. + at Mono.TextEditor.Margin.MousePressed +(Mono.TextEditor.MarginMouseEventArgs args) [0x0000b] in +/home/marcel/tmp/mono/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/Margin.cs:86 + + at Mono.TextEditor.IconMargin.MousePressed +(Mono.TextEditor.MarginMouseEventArgs args) [0x00000] in +/home/marcel/tmp/mono/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/IconMargin.cs:73 + + at Mono.TextEditor.TextEditor.OnButtonPressEvent (Gdk.EventButton e) +[0x000a3] in +/home/marcel/tmp/mono/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/TextEditor.cs:1025 + + at Gtk.Widget.buttonpressevent_cb (IntPtr widget, IntPtr evnt) +[0x00000] in <filename unknown>:0 + +Regards +Marcel + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: signature.asc +Type: application/pgp-signature +Size: 899 bytes +Desc: OpenPGP digital signature +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/e649e248/attachment.pgp> ++ + + +
Looks like your build is broken. Try rebuilding - the debugger API changed +and it looks like your text editor wasn't rebuilt. + +Jeff + +On Thu, Jan 10, 2013 at 12:00 PM, Marcel Hellwig <keks at cookiesoft.de> wrote: + +> Am 10.01.2013 17:57, schrieb Jeff Stedfast: +> > Hi Marcel, +> > +> > What commits to what branch? +> > +> > I'm able to add breakpoints with the mouse just fine. I get no +> > exceptions when breakpoints are hit. +> > +> > What am I missing? +> +> Don't know +> configure is with main, database and debugger, then make and make install. +> Here is the stacktrace +> +> System.MissingMethodException: Method not found: +> 'Mono.Debugging.Client.BreakpointStore.Toggle'. +> at Mono.TextEditor.Margin.MousePressed +> (Mono.TextEditor.MarginMouseEventArgs args) [0x0000b] in +> +> /home/marcel/tmp/mono/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/Margin.cs:86 +> +> at Mono.TextEditor.IconMargin.MousePressed +> (Mono.TextEditor.MarginMouseEventArgs args) [0x00000] in +> +> /home/marcel/tmp/mono/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/IconMargin.cs:73 +> +> at Mono.TextEditor.TextEditor.OnButtonPressEvent (Gdk.EventButton e) +> [0x000a3] in +> +> /home/marcel/tmp/mono/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/TextEditor.cs:1025 +> +> at Gtk.Widget.buttonpressevent_cb (IntPtr widget, IntPtr evnt) +> [0x00000] in <filename unknown>:0 +> +> Regards +> Marcel +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/3be6554c/attachment.html> ++ + + +
Am 10.01.2013 18:31, schrieb Jeff Stedfast: +> Looks like your build is broken. Try rebuilding - the debugger API +> changed and it looks like your text editor wasn't rebuilt. +Not working as expected. Had to reclone monodev from github and compile +to solve problem... not funny ;) +Thanks anyway. + +Regards + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: signature.asc +Type: application/pgp-signature +Size: 899 bytes +Desc: OpenPGP digital signature +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/612141ef/attachment-0001.pgp> ++ + + +
For future reference, you could probably just `git clean -xdf` instead of +re-cloning. + +Jeff + +On Thu, Jan 10, 2013 at 5:16 PM, Marcel Hellwig <keks at cookiesoft.de> wrote: + +> Am 10.01.2013 18:31, schrieb Jeff Stedfast: +> > Looks like your build is broken. Try rebuilding - the debugger API +> > changed and it looks like your text editor wasn't rebuilt. +> Not working as expected. Had to reclone monodev from github and compile +> to solve problem... not funny ;) +> Thanks anyway. +> +> Regards +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130110/8339665a/attachment.html> ++ + + +
Hi everyone, + +Is there any way to display inline documentation for +classes/structs/methods of mono like in Visualstudio? + +Regards +Marcel Hellwig + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: signature.asc +Type: application/pgp-signature +Size: 901 bytes +Desc: OpenPGP digital signature +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130115/3463bf88/attachment.pgp> ++ + + +
MonoDevelop automatically discovers docs from installed MonoDoc docs, .xml +doc comments beside the dlls, and xml doc comments in source code. If this +isn't working for you please file a bug with more details. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130118/4776144d/attachment.html> ++ + + +
Am 18.01.2013 23:40, schrieb Michael Hutchinson: +> MonoDevelop automatically discovers docs from installed MonoDoc docs, +> .xml doc comments beside the dlls, and xml doc comments in source +> code. If this isn't working for you please file a bug with more details. +Is there some way to debug this, e.g. see what path monodevelop is +looking at and any errors occuring? + +Regards + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: signature.asc +Type: application/pgp-signature +Size: 901 bytes +Desc: OpenPGP digital signature +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130119/6ce3b74a/attachment.pgp> ++ + +
Starting: Wed Jan 9 16:33:55 UTC 2013
+ Ending: Fri Jan 18 23:31:44 UTC 2013
+ Messages: 13
+
+ Last message date:
+ Fri Jan 18 23:31:44 UTC 2013
+ Archived on: Fri Jan 18 23:31:49 UTC 2013
+
+
+
Starting: Wed Jan 9 16:33:55 UTC 2013
+ Ending: Fri Jan 18 23:31:44 UTC 2013
+ Messages: 13
+
+ Last message date:
+ Fri Jan 18 23:31:44 UTC 2013
+ Archived on: Fri Jan 18 23:31:49 UTC 2013
+
+
+
Starting: Wed Jan 9 16:33:55 UTC 2013
+ Ending: Fri Jan 18 23:31:44 UTC 2013
+ Messages: 13
+
+ Last message date:
+ Fri Jan 18 23:31:44 UTC 2013
+ Archived on: Fri Jan 18 23:31:49 UTC 2013
+
+
+
Starting: Wed Jan 9 16:33:55 UTC 2013
+ Ending: Fri Jan 18 23:31:44 UTC 2013
+ Messages: 13
+
+ Last message date:
+ Fri Jan 18 23:31:44 UTC 2013
+ Archived on: Fri Jan 18 23:31:49 UTC 2013
+
+
+
Starting: Wed Jan 9 16:33:55 UTC 2013
+ Ending: Fri Jan 18 23:31:44 UTC 2013
+ Messages: 13
+
+ Last message date:
+ Fri Jan 18 23:31:44 UTC 2013
+ Archived on: Fri Jan 18 23:31:49 UTC 2013
+
+
+
Hiya, + +I'm trying to add some command extensions for my p4 addin for monodevelop, +I've got a bit lost. + +https://github.com/inorton/XR.Mono.Perforce/blob/master/XR.MonoDevelop.Perforce/XR.MonoDevelop.Perforce.addin.xml + +The xml results in <unknown command> menu items rather than "Edit file.." +or "Submit changes.." as I wanted. Any help would be greatly appreciated. + +Ian +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130702/efa024d2/attachment.html> ++ + + +
The ids of the CommandItem elements must match the ids of the commands. Also, make sure you define an enum value for each command. See http://monodevelop.com/Developers/Articles/The_Command_System. + +El 02/07/2013, a las 10:07, Ian Norton <inorton at gmail.com> escribió: + +> Hiya, +> +> I'm trying to add some command extensions for my p4 addin for monodevelop, I've got a bit lost. +> +> https://github.com/inorton/XR.Mono.Perforce/blob/master/XR.MonoDevelop.Perforce/XR.MonoDevelop.Perforce.addin.xml +> +> The xml results in <unknown command> menu items rather than "Edit file.." or "Submit changes.." as I wanted. Any help would be greatly appreciated. +> +> Ian +> _______________________________________________ +> Mono-list maillist - Mono-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/mono-list + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130709/77cc7f62/attachment.html> ++ + + +
Hello + +Can anyone tell me about Mono project more. Can a student with C and C plus +plus experience can work with this project?? + +-- +Shivam Agarwal ++919045295681 +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130717/3bd6af07/attachment.html> ++ + + +
Hi, + +I'm currently working on adding refactoring to the F# language binding for +MonoDevelop. I've added a few new refactorings using the +MonoDevelop/Refactoring/Refactorings extension point. + +However, one of them is a "Rename" refactoring and because the default +"Rename" is still available in F# files, the user is presented with two +"Rename" options: my one and the default one (which doesn't work in F#). + +I'd like there to only be one available option, and was wondering what the +best way to do that is. Unfortunately, I don't think I can solve it without +modifying MonoDevelop.Refactoring. The options that come to mind are: + + * Change MonoDevelop.Refactoring.Rename so it is unavailable in F# files + * Add some extension points to MonoDevelop.Refactoring.Rename and extend +those in my add-in + +Any ideas? + +Cheers, + +Lewis +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130724/ae8d4bbc/attachment.html> ++ + + +
Hello! Are there any examples of how the ExtensibleTreeView works? I did +some research of SolutionPad that uses it, but still don't understand it. +Its method AddChild takes an object as argument, and this is what confuses +me. + +For example, the SolutionPad simply iterates through the workspaces and +adds them as children. What is going on after that is pure magic. How it +extracts solutions and projects from those workspaces? + +Could someone explain use of it? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130726/0272a050/attachment.html> ++ + + +
I think this document will answer most of your questions: + +http://monodevelop.com/Developers/Articles/Extending_the_Project_Pad + +> Hello! Are there any examples of how the ExtensibleTreeView works? I did some research of SolutionPad that uses it, but still don't understand it. Its method AddChild takes an object as argument, and this is what confuses me. +> +> For example, the SolutionPad simply iterates through the workspaces and adds them as children. What is going on after that is pure magic. How it extracts solutions and projects from those workspaces? +> +> Could someone explain use of it? +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130726/cb6c0c22/attachment.html> ++ + +
Starting: Tue Jul 2 08:07:36 UTC 2013
+ Ending: Fri Jul 26 17:26:20 UTC 2013
+ Messages: 6
+
+ Last message date:
+ Fri Jul 26 17:26:20 UTC 2013
+ Archived on: Fri Jul 26 17:26:20 UTC 2013
+
+
+
Starting: Tue Jul 2 08:07:36 UTC 2013
+ Ending: Fri Jul 26 17:26:20 UTC 2013
+ Messages: 6
+
+ Last message date:
+ Fri Jul 26 17:26:20 UTC 2013
+ Archived on: Fri Jul 26 17:26:20 UTC 2013
+
+
+
Starting: Tue Jul 2 08:07:36 UTC 2013
+ Ending: Fri Jul 26 17:26:20 UTC 2013
+ Messages: 6
+
+ Last message date:
+ Fri Jul 26 17:26:20 UTC 2013
+ Archived on: Fri Jul 26 17:26:20 UTC 2013
+
+
+
Starting: Tue Jul 2 08:07:36 UTC 2013
+ Ending: Fri Jul 26 17:26:20 UTC 2013
+ Messages: 6
+
+ Last message date:
+ Fri Jul 26 17:26:20 UTC 2013
+ Archived on: Fri Jul 26 17:26:20 UTC 2013
+
+
+
Starting: Tue Jul 2 08:07:36 UTC 2013
+ Ending: Fri Jul 26 17:26:20 UTC 2013
+ Messages: 6
+
+ Last message date:
+ Fri Jul 26 17:26:20 UTC 2013
+ Archived on: Fri Jul 26 17:26:20 UTC 2013
+
+
+
Hiya Everyone, + +I've started work (again) on a perforce plugin for MD. I've not got very +far yet and am implementing the Repository and have some questions. + +1. What is a RevisionPath? how does it map to files, local changes and repo +state? +2. I need to perform a perforce command to 'edit' a file right before the +user types changes in the text editor, how can I hook into this? + +Many thanks + +Ian +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130618/6c91c395/attachment.html> ++ + +
Starting: Tue Jun 18 17:12:04 UTC 2013
+ Ending: Tue Jun 18 17:12:04 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Jun 18 17:12:04 UTC 2013
+ Archived on: Tue Jun 18 17:12:08 UTC 2013
+
+
+
Starting: Tue Jun 18 17:12:04 UTC 2013
+ Ending: Tue Jun 18 17:12:04 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Jun 18 17:12:04 UTC 2013
+ Archived on: Tue Jun 18 17:12:08 UTC 2013
+
+
+
Starting: Tue Jun 18 17:12:04 UTC 2013
+ Ending: Tue Jun 18 17:12:04 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Jun 18 17:12:04 UTC 2013
+ Archived on: Tue Jun 18 17:12:08 UTC 2013
+
+
+
Starting: Tue Jun 18 17:12:04 UTC 2013
+ Ending: Tue Jun 18 17:12:04 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Jun 18 17:12:04 UTC 2013
+ Archived on: Tue Jun 18 17:12:08 UTC 2013
+
+
+
Starting: Tue Jun 18 17:12:04 UTC 2013
+ Ending: Tue Jun 18 17:12:04 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Jun 18 17:12:04 UTC 2013
+ Archived on: Tue Jun 18 17:12:08 UTC 2013
+
+
+
Hey Everyone +I'm A Unity user actually owning a small company doing game development and +game technology development. +We usually use visual studio but are thinking of miggrating to MonoDevelop +cause it supports debugging in unity but there is a problem for me +personally. +I use Screen magnifier program of windows to make stuff larger because i'm +low vision and can not read the normal text but MonoDevelop doesn't notify +the magnifier program to follow the text cursor so i am not able to use it +even if i want to. I'm not sure about the status in mac but it was not +supported at OSX1.7 and MonoDevelop version of the time. + +Does anyone have any idea of how much work is it to add the support to +MonoDevelop? + +I understand that it can not be a priority and the number of users needing +this is low and even it's not critical for me because i already use visual +studio express for daily work but would be happy to switch. + +Cheers + +-- +-asm + +Ashkan Saeedi Mazdeh +Founder and CEO NoOpArmy +Skype: ashkan_gc +cell: +(98)9193046544 +LinkedIn http://ir.linkedin.com/in/ashkansaeedimazdeh +http://www.nooparmy.com +*//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////* +*//Try to become not a man of success, but try rather to become a man of +value.* +*//Einstein* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20131126/0cdb6081/attachment.html> ++ + + +
There are a couple of elements here. + +The first one would be to make MonoDevelop use the accessibility features. + While it is a relatively large project, it does not have to be an +all-or-nothing issue, so it can be evolved to support it. + +The second issue would be to map Atk to the underlying OSX APIs, and that I +have no idea how much work would be. + + +On Tue, Nov 26, 2013 at 4:41 AM, Ashkan Saeedi Mazdeh < +ashkan.saeedi.1989 at gmail.com> wrote: + +> Hey Everyone +> I'm A Unity user actually owning a small company doing game development +> and game technology development. +> We usually use visual studio but are thinking of miggrating to MonoDevelop +> cause it supports debugging in unity but there is a problem for me +> personally. +> I use Screen magnifier program of windows to make stuff larger because i'm +> low vision and can not read the normal text but MonoDevelop doesn't notify +> the magnifier program to follow the text cursor so i am not able to use it +> even if i want to. I'm not sure about the status in mac but it was not +> supported at OSX1.7 and MonoDevelop version of the time. +> +> Does anyone have any idea of how much work is it to add the support to +> MonoDevelop? +> +> I understand that it can not be a priority and the number of users needing +> this is low and even it's not critical for me because i already use visual +> studio express for daily work but would be happy to switch. +> +> Cheers +> +> -- +> -asm +> +> Ashkan Saeedi Mazdeh +> Founder and CEO NoOpArmy +> Skype: ashkan_gc +> cell: +(98)9193046544 +> LinkedIn http://ir.linkedin.com/in/ashkansaeedimazdeh +> http://www.nooparmy.com +> +> *//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////* +> *//Try to become not a man of success, but try rather to become a man of +> value.* +> *//Einstein* +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20131126/a2e10480/attachment.html> ++ + + +
Thanks for the quick reply Miguel +My main concern is windows so actually it's about MSAA and GTK#, I +mentioned that also OSX has the same problem as well. + +I just wrote these here with the hope that someone interested could be +found and work on it one day. +I myself personally never worked with any accessibility APIs and don't have +much info on it so can not do the work in a time that i can afford to put +on it now. + + +On Tue, Nov 26, 2013 at 10:15 PM, Miguel de Icaza <miguel at xamarin.com>wrote: + +> There are a couple of elements here. +> +> The first one would be to make MonoDevelop use the accessibility features. +> While it is a relatively large project, it does not have to be an +> all-or-nothing issue, so it can be evolved to support it. +> +> The second issue would be to map Atk to the underlying OSX APIs, and that +> I have no idea how much work would be. +> +> +> On Tue, Nov 26, 2013 at 4:41 AM, Ashkan Saeedi Mazdeh < +> ashkan.saeedi.1989 at gmail.com> wrote: +> +>> Hey Everyone +>> I'm A Unity user actually owning a small company doing game development +>> and game technology development. +>> We usually use visual studio but are thinking of miggrating to +>> MonoDevelop cause it supports debugging in unity but there is a problem for +>> me personally. +>> I use Screen magnifier program of windows to make stuff larger because +>> i'm low vision and can not read the normal text but MonoDevelop doesn't +>> notify the magnifier program to follow the text cursor so i am not able to +>> use it even if i want to. I'm not sure about the status in mac but it was +>> not supported at OSX1.7 and MonoDevelop version of the time. +>> +>> Does anyone have any idea of how much work is it to add the support to +>> MonoDevelop? +>> +>> I understand that it can not be a priority and the number of users +>> needing this is low and even it's not critical for me because i already use +>> visual studio express for daily work but would be happy to switch. +>> +>> Cheers +>> +>> -- +>> -asm +>> +>> Ashkan Saeedi Mazdeh +>> Founder and CEO NoOpArmy +>> Skype: ashkan_gc +>> cell: +(98)9193046544 +>> LinkedIn http://ir.linkedin.com/in/ashkansaeedimazdeh +>> http://www.nooparmy.com +>> +>> *//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////* +>> *//Try to become not a man of success, but try rather to become a man of +>> value.* +>> *//Einstein* +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> +> + + +-- +-asm + +Ashkan Saeedi Mazdeh +Founder and CEO NoOpArmy +Skype: ashkan_gc +cell: +(98)9193046544 +LinkedIn http://ir.linkedin.com/in/ashkansaeedimazdeh +http://www.nooparmy.com +*//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////* +*//Try to become not a man of success, but try rather to become a man of +value.* +*//Einstein* +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20131127/85103f43/attachment.html> ++ + +
Starting: Tue Nov 26 09:41:26 UTC 2013
+ Ending: Wed Nov 27 07:26:05 UTC 2013
+ Messages: 3
+
+ Last message date:
+ Wed Nov 27 07:26:05 UTC 2013
+ Archived on: Mon Dec 2 13:27:53 UTC 2013
+
+
+
Starting: Tue Nov 26 09:41:26 UTC 2013
+ Ending: Wed Nov 27 07:26:05 UTC 2013
+ Messages: 3
+
+ Last message date:
+ Wed Nov 27 07:26:05 UTC 2013
+ Archived on: Mon Dec 2 13:27:53 UTC 2013
+
+
+
Starting: Tue Nov 26 09:41:26 UTC 2013
+ Ending: Wed Nov 27 07:26:05 UTC 2013
+ Messages: 3
+
+ Last message date:
+ Wed Nov 27 07:26:05 UTC 2013
+ Archived on: Mon Dec 2 13:27:53 UTC 2013
+
+
+
Starting: Tue Nov 26 09:41:26 UTC 2013
+ Ending: Wed Nov 27 07:26:05 UTC 2013
+ Messages: 3
+
+ Last message date:
+ Wed Nov 27 07:26:05 UTC 2013
+ Archived on: Mon Dec 2 13:27:53 UTC 2013
+
+
+
Starting: Tue Nov 26 09:41:26 UTC 2013
+ Ending: Wed Nov 27 07:26:05 UTC 2013
+ Messages: 3
+
+ Last message date:
+ Wed Nov 27 07:26:05 UTC 2013
+ Archived on: Mon Dec 2 13:27:53 UTC 2013
+
+
+
+Hello + +I'm + using openSUSE 12.3 and installed mono 3.0.4 the default that is +available from packages and the latest stable Monodevelop 4.1.7 from +git. +I created an mvc4 application using this post + +http://curtis.schlak.com/2013/09/29/setup-asp-net-mvc-4-on-monodevelop.html + + +When i start this web application from terminal it gives me the following exception + +System.InvalidOperationException +The view 'Index' or its master was not +found or no view engine supports the searched locations. The following +locations were searched: + +~/Views/Home/Index.aspx +~/Views/Home/Index.ascx +~/Views/Shared/Index.aspx +~/Views/Shared/Index.ascx +~/Views/Home/Index.cshtml +~/Views/Home/Index.vbhtml +~/Views/Shared/Index.cshtml +~/Views/Shared/Index.vbhtml +Description: HTTP 500.Error processing request. +Details: Non-web exception. Exception origin (name of application or object): System.Web.Mvc. +Exception stack trace: +at System.Web.Mvc.ViewResult.FindView +(System.Web.Mvc.ControllerContext context) [0x00000] in <filename +unknown>:0 +at System.Web.Mvc.ViewResultBase.ExecuteResult +(System.Web.Mvc.ControllerContext context) [0x00000] in <filename +unknown>:0 +at System.Web.Mvc.ControllerActionInvoker.InvokeActionResult +(System.Web.Mvc.ControllerContext controllerContext, +System.Web.Mvc.ActionResult actionResult) [0x00000] in <filename +unknown>:0 +at +System.Web.Mvc.ControllerActionInvoker+<>c__DisplayClass1a.<InvokeActionResultWithFilters>b__17 +() [0x00000] in <filename unknown>:0 +at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter +(IResultFilter filter, System.Web.Mvc.ResultExecutingContext preContext, +System.Func`1 continuation) [0x00000] in <filename unknown>:0 +Version Information: 3.0.4 (tarball Thu Mar 7 10:35:21 UTC 2013); ASP.NET Version: 4.0.30319.17020 + +Also I have an additional error that i cannot start xsp4 from Monodevelop. This disables me the advantage of debugging. +The error is following: + +Could not launch web server. The "xsp4" web server could not be started. Make sure that it is installed. +I can't see the rest of the message. + +Or when i run without debugging there is an exception with following stack trace + +Handling exception type TypeLoadException +Message is Could not load type 'Mono.WebServer.XSPWebSource' from assembly 'xsp4'. +IsTerminating is set to True +System.TypeLoadException: Could not load type 'Mono.WebServer.XSPWebSource' from assembly 'xsp4'. + + at Mono.WebServer.XSP.Server.Main (System.String[] args) [0x00025] in +/home/abuild/rpmbuild/BUILD/xsp-2.10.2/src/Mono.WebServer.XSP/main.cs:258 +[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could +not load type 'Mono.WebServer.XSPWebSource' from assembly 'xsp4'. + +at Mono.WebServer.XSP.Server.Main (System.String[] args) [0x00025] in +/home/abuild/rpmbuild/BUILD/xsp-2.10.2/src/Mono.WebServer.XSP/main.cs:258 + +Can somebody give a tip what are these errors? + + +Thank you, +Robert Lebovich. ++ + +
Starting: Tue Oct 1 16:33:29 UTC 2013
+ Ending: Tue Oct 1 16:33:29 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Oct 1 16:33:29 UTC 2013
+ Archived on: Tue Oct 1 16:33:36 UTC 2013
+
+
+
Starting: Tue Oct 1 16:33:29 UTC 2013
+ Ending: Tue Oct 1 16:33:29 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Oct 1 16:33:29 UTC 2013
+ Archived on: Tue Oct 1 16:33:36 UTC 2013
+
+
+
Starting: Tue Oct 1 16:33:29 UTC 2013
+ Ending: Tue Oct 1 16:33:29 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Oct 1 16:33:29 UTC 2013
+ Archived on: Tue Oct 1 16:33:36 UTC 2013
+
+
+
Starting: Tue Oct 1 16:33:29 UTC 2013
+ Ending: Tue Oct 1 16:33:29 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Oct 1 16:33:29 UTC 2013
+ Archived on: Tue Oct 1 16:33:36 UTC 2013
+
+
+
Starting: Tue Oct 1 16:33:29 UTC 2013
+ Ending: Tue Oct 1 16:33:29 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Tue Oct 1 16:33:29 UTC 2013
+ Archived on: Tue Oct 1 16:33:36 UTC 2013
+
+
+
Hi,
+I've run into a problem when trying to open one of my F# projects using Xamarin Studio, and so I cloned the monodevelop source code from github to try to debug the problem.I was able to build successfully using VS2012, but on startup IdeApp.CommandService.GetCommandInfo("MonoDevelop.Debugger.DebugCommands.Debug") on MainToolbar.cs:847 fails to find the command. I have the MONO_ADDINS_REGISTRY env var pointing to build/bin.Am I missing anything on my setup to make this work?
+Thanks an Regards,Gustavo Guerra
+PS: Please let me know if there is a more appropriate place to ask these kind of questions
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20130922/b8669443/attachment.html>
+
+
+
+ Starting: Sun Sep 22 18:21:12 UTC 2013
+ Ending: Sun Sep 22 18:21:12 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Sun Sep 22 18:21:12 UTC 2013
+ Archived on: Sun Sep 22 18:26:16 UTC 2013
+
+
+
Starting: Sun Sep 22 18:21:12 UTC 2013
+ Ending: Sun Sep 22 18:21:12 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Sun Sep 22 18:21:12 UTC 2013
+ Archived on: Sun Sep 22 18:26:16 UTC 2013
+
+
+
Starting: Sun Sep 22 18:21:12 UTC 2013
+ Ending: Sun Sep 22 18:21:12 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Sun Sep 22 18:21:12 UTC 2013
+ Archived on: Sun Sep 22 18:26:16 UTC 2013
+
+
+
Starting: Sun Sep 22 18:21:12 UTC 2013
+ Ending: Sun Sep 22 18:21:12 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Sun Sep 22 18:21:12 UTC 2013
+ Archived on: Sun Sep 22 18:26:16 UTC 2013
+
+
+
Starting: Sun Sep 22 18:21:12 UTC 2013
+ Ending: Sun Sep 22 18:21:12 UTC 2013
+ Messages: 1
+
+ Last message date:
+ Sun Sep 22 18:21:12 UTC 2013
+ Archived on: Sun Sep 22 18:26:16 UTC 2013
+
+
+
Hello! At this Summer I will be working on a GSoC project (XUnit support +for MonoDevelop). Now I am planning my work, and I thought I could share my +ideas to get your opinions before go any further. I would appreciate your +help. + +The first task, probably, is to abstract existing code from NUnit +dependencies. Bellow are my intentions, how I imaging the start of this +process. + +TODO: + +Delegate actual test discovery/creation to the new interface called +ITestDiscoverer. Make ITestProvider (or maybe an implementing class) the +point where an addin can register its ITestDiscoverer implementation. + +This gives us a way to have multiple test discoverers for a single test +provider. For example, XUnitTestDiscoverer and NUnitTestDiscoverer might +register themselves to the DotNetTestProvider, and when the test creation +process happens the provider uses both discoverers to create tests, then +merges the tests into a single tree. At the same time another test provider +builds its own tree which is not supposed to be merged with the first (but +both trees will have the same parent node since they are built from the +same IWorkspaceObject). Simply, it's just a way to have several "domains" +(e.g. DotNetTestProvider, JsTestProvider, MyTestProvider) which can be +introduced and extended by plugins. + +The changes will force NUnitService to change its return type from UnitTest +to List<UnitTest>. However, it's not a big issue and can be fixed without +breaking a lot of things. + +Link - https://github.com/x2bool/monodevelop/tree/soc/main/src/addins/NUnit +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140429/f2da5b8a/attachment.html> ++ + +
Starting: Tue Apr 29 11:53:54 UTC 2014
+ Ending: Tue Apr 29 11:53:54 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Tue Apr 29 11:53:54 UTC 2014
+ Archived on: Tue Apr 29 11:53:57 UTC 2014
+
+
+
Starting: Tue Apr 29 11:53:54 UTC 2014
+ Ending: Tue Apr 29 11:53:54 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Tue Apr 29 11:53:54 UTC 2014
+ Archived on: Tue Apr 29 11:53:57 UTC 2014
+
+
+
Starting: Tue Apr 29 11:53:54 UTC 2014
+ Ending: Tue Apr 29 11:53:54 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Tue Apr 29 11:53:54 UTC 2014
+ Archived on: Tue Apr 29 11:53:57 UTC 2014
+
+
+
Starting: Tue Apr 29 11:53:54 UTC 2014
+ Ending: Tue Apr 29 11:53:54 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Tue Apr 29 11:53:54 UTC 2014
+ Archived on: Tue Apr 29 11:53:57 UTC 2014
+
+
+
Starting: Tue Apr 29 11:53:54 UTC 2014
+ Ending: Tue Apr 29 11:53:54 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Tue Apr 29 11:53:54 UTC 2014
+ Archived on: Tue Apr 29 11:53:57 UTC 2014
+
+
+
Is it possible to write an addin in f# that will work on a client machine +without additional installations/configuration? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140225/edb149f8/attachment.html> ++ + + + + +
I am an undergraduate student Devashish Badlani currently an intern from IIT Bombay in Khan Academy Founation for Learning Equality, I have the experience of having contributed to open source +I have keen interest in this project as I have the experince to have handled JSON file as is stated in my project I have posted on githubhttps://github.com/deebee07/TemplateProject + +I have all the prerequisite to complete the task + +Debugger Visualizers + + +There is plenty of room to improve the debugging experience with visualizer pop-ups that provide more useful ways to inspect common kinds of data - for example, collection visualizers that allow searching for items in the collection, XML/JSON visualizers that provide a structured, searchable tree view of the document, and so-on. Your proposal should include a list of visualizers that you propose to implement, and describe why they are useful. + +Deliverables: A set of useful debugger visualizers. + +Mentors: Michael Hutchinson, Jeffrey Stedfast +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140225/bc1c5ce1/attachment.html> ++ + + +
I can't see why not, but you may have to bundle runtime libraries with +the addin if you can't rely them being in the GAC. + +On 25 February 2014 05:31, Sergey Khabibullin <x2bool at gmail.com> wrote: +> Is it possible to write an addin in f# that will work on a client machine +> without additional installations/configuration? +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + +
Thanks for the reply. What is the minimum that I have to bundle? +FSharp.Core? + + +On Wed, Feb 26, 2014 at 8:28 AM, Sergey Khabibullin +<sergey at khabibullin.com>wrote: + +> Thanks for the reply. What is the minimum that I have to bundle? +> FSharp.Core? +> +> 26.02.2014, 03:43, "Michael Hutchinson" <m.j.hutchinson at gmail.com>: +> +> I can't see why not, but you may have to bundle runtime libraries with +> the addin if you can't rely them being in the GAC. +> +> On 25 February 2014 05:31, Sergey Khabibullin <x2bool at gmail.com> wrote: +> +> Is it possible to write an addin in f# that will work on a client machine +> without additional installations/configuration? +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140226/4747fee2/attachment.html> ++ + + + + +
Not sure offhand, sorry. You could try inspecting the compiled addin +dll and see what it depends on. + +On 25 February 2014 23:33, Sergey Khabibullin <x2bool at gmail.com> wrote: +> Thanks for the reply. What is the minimum that I have to bundle? +> FSharp.Core? +> +> +> On Wed, Feb 26, 2014 at 8:28 AM, Sergey Khabibullin <sergey at khabibullin.com> +> wrote: +>> +>> Thanks for the reply. What is the minimum that I have to bundle? +>> FSharp.Core? +>> +>> 26.02.2014, 03:43, "Michael Hutchinson" <m.j.hutchinson at gmail.com>: +>> +>> I can't see why not, but you may have to bundle runtime libraries with +>> the addin if you can't rely them being in the GAC. +>> +>> On 25 February 2014 05:31, Sergey Khabibullin <x2bool at gmail.com> wrote: +>> +>> Is it possible to write an addin in f# that will work on a client machine +>> without additional installations/configuration? +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> -- +>> Michael Hutchinson +>> http://mjhutchinson.com +> +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Hi, + +Do you have any specific questions? :) + +- M + +On 25 February 2014 04:04, Devashish Badlani <deebee2307 at yahoo.com> wrote: +> I am an undergraduate student Devashish Badlani currently an intern from IIT +> Bombay in Khan Academy Founation for Learning Equality, I have the +> experience of having contributed to open source +> I have keen interest in this project as I have the experince to have handled +> JSON file as is stated in my project I have posted on +> githubhttps://github.com/deebee07/TemplateProject +> +> I have all the prerequisite to complete the task +> +> Debugger Visualizers +> +> +> There is plenty of room to improve the debugging experience with visualizer +> pop-ups that provide more useful ways to inspect common kinds of data - for +> example, collection visualizers that allow searching for items in the +> collection, XML/JSON visualizers that provide a structured, searchable tree +> view of the document, and so-on. Your proposal should include a list of +> visualizers that you propose to implement, and describe why they are useful. +> +> Deliverables: A set of useful debugger visualizers. +> +> Mentors: Michael Hutchinson, Jeffrey Stedfast +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + +
An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140226/cb08c818/attachment.html> ++ + +
Starting: Tue Feb 25 09:04:39 UTC 2014
+ Ending: Thu Feb 27 21:54:56 UTC 2014
+ Messages: 7
+
+ Last message date:
+ Thu Feb 27 21:54:56 UTC 2014
+ Archived on: Fri Feb 28 12:55:27 UTC 2014
+
+
+
Starting: Tue Feb 25 09:04:39 UTC 2014
+ Ending: Thu Feb 27 21:54:56 UTC 2014
+ Messages: 7
+
+ Last message date:
+ Thu Feb 27 21:54:56 UTC 2014
+ Archived on: Fri Feb 28 12:55:27 UTC 2014
+
+
+
Starting: Tue Feb 25 09:04:39 UTC 2014
+ Ending: Thu Feb 27 21:54:56 UTC 2014
+ Messages: 7
+
+ Last message date:
+ Thu Feb 27 21:54:56 UTC 2014
+ Archived on: Fri Feb 28 12:55:27 UTC 2014
+
+
+
Starting: Tue Feb 25 09:04:39 UTC 2014
+ Ending: Thu Feb 27 21:54:56 UTC 2014
+ Messages: 7
+
+ Last message date:
+ Thu Feb 27 21:54:56 UTC 2014
+ Archived on: Fri Feb 28 12:55:27 UTC 2014
+
+
+
Starting: Tue Feb 25 09:04:39 UTC 2014
+ Ending: Thu Feb 27 21:54:56 UTC 2014
+ Messages: 7
+
+ Last message date:
+ Thu Feb 27 21:54:56 UTC 2014
+ Archived on: Fri Feb 28 12:55:27 UTC 2014
+
+
+
+Hi + +I'm currently reviewing the text editor API. We've a method called: + +public char GetCharAt (int < span class="n" style="box-sizing: +border-box; color: rgb(51, 51, 51);">offset) + + +And atm I think about replacing it with : + +public char this[int offset] + +Maybe even add a setter to that - then the editor may feel a bit more +like a string from a certain PoV. +The question is: Is that a good or bad choice - how are you feeling +about it ? + +The text editor has 3 layers: Text, Document and Editor - each layer +adds something on top of the text. The GetCharAt is a functionality from +the Text. On this level there is just text. I think the indexer makes +sense there. But how about the upper layers? At Document level the +editor becomes a collection of lines as well. + +I would love to hear some opinions. (About the speed: In this is a very +lightweight operation - in our current Implementation it's done in O(1) +in the worst case I can imagine that it becomes an O(log N) one). + +Regards +Mike + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140620/891ca9c4/attachment.html> ++ + + +
Hi Mike, + +I like the API change you are suggesting. + +Jeff + + + +On Fri, Jun 20, 2014 at 1:16 PM, Mike Krüger <mkrueger at xamarin.com> wrote: + +> +> Hi +> +> I'm currently reviewing the text editor API. We've a method called: +> +> public char GetCharAt (int +> < +> span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51);">offset) +> +> +> And atm I think about replacing it with : +> +> public char this[int offset] +> +> Maybe even add a setter to that - then the editor may feel a bit more like +> a string from a certain PoV. +> The question is: Is that a good or bad choice - how are you feeling about +> it ? +> +> The text editor has 3 layers: Text, Document and Editor - each layer adds +> something on top of the text. The GetCharAt is a functionality from the +> Text. On this level there is just text. I think the indexer makes sense +> there. But how about the upper layers? At Document level the editor becomes +> a collection of lines as well. +> +> I would love to hear some opinions. (About the speed: In this is a very +> lightweight operation - in our current Implementation it's done in O(1) in +> the worst case I can imagine that it becomes an O(log N) one). +> +> Regards +> Mike +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140620/8e373aef/attachment.html> ++ + + +
Hi + +To be fair it's something I've borrowed from Roslyn. + +Regards +Mike +> Hi Mike, +> +> I like the API change you are suggesting. +> +> Jeff +> +> +> +> On Fri, Jun 20, 2014 at 1:16 PM, Mike Krüger <mkrueger at xamarin.com +> <mailto:mkrueger at xamarin.com>> wrote: +> +> +> Hi +> +> I'm currently reviewing the text editor API. We've a method called: +> +> public char GetCharAt (int < span class="n" style="box-sizing: +> border-box; color: rgb(51, 51, 51);">offset) +> +> +> And atm I think about replacing it with : +> +> public char this[int offset] +> +> Maybe even add a setter to that - then the editor may feel a bit +> more like a string from a certain PoV. +> The question is: Is that a good or bad choice - how are you +> feeling about it ? +> +> The text editor has 3 layers: Text, Document and Editor - each +> layer adds something on top of the text. The GetCharAt is a +> functionality from the Text. On this level there is just text. I +> think the indexer makes sense there. But how about the upper +> layers? At Document level the editor becomes a collection of lines +> as well. +> +> I would love to hear some opinions. (About the speed: In this is a +> very lightweight operation - in our current Implementation it's +> done in O(1) in the worst case I can imagine that it becomes an +> O(log N) one). +> +> Regards +> Mike +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> <mailto:Monodevelop-devel-list at lists.ximian.com> +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140620/7d32d021/attachment-0001.html> ++ + + +
To be fair, it's also kinda obvious :-) + + +On Fri, Jun 20, 2014 at 1:53 PM, Mike Krüger <mkrueger at xamarin.com> wrote: + +> Hi +> +> To be fair it's something I've borrowed from Roslyn. +> +> Regards +> Mike +> +> Hi Mike, +> +> I like the API change you are suggesting. +> +> Jeff +> +> +> +> On Fri, Jun 20, 2014 at 1:16 PM, Mike Krüger <mkrueger at xamarin.com> wrote: +> +>> +>> Hi +>> +>> I'm currently reviewing the text editor API. We've a method called: +>> +>> public char GetCharAt (int +>> < +>> span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51);">offset) +>> +>> +>> And atm I think about replacing it with : +>> +>> public char this[int offset] +>> +>> Maybe even add a setter to that - then the editor may feel a bit more +>> like a string from a certain PoV. +>> The question is: Is that a good or bad choice - how are you feeling about +>> it ? +>> +>> The text editor has 3 layers: Text, Document and Editor - each layer adds +>> something on top of the text. The GetCharAt is a functionality from the +>> Text. On this level there is just text. I think the indexer makes sense +>> there. But how about the upper layers? At Document level the editor becomes +>> a collection of lines as well. +>> +>> I would love to hear some opinions. (About the speed: In this is a very +>> lightweight operation - in our current Implementation it's done in O(1) in +>> the worst case I can imagine that it becomes an O(log N) one). +>> +>> Regards +>> Mike +>> +>> +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140620/0e52a73b/attachment.html> ++ + + +
I think it is obvious and intuitive at the Text level, but for Document +and Editor then it becomes a bit less intuitive. + +As Mike said, the Document has lines as well as characters. How often is +someone going to want to use the index as a line vs as a character? +Which would you assume is which? I think it is probably clearer to keep +the methods at those levels so that you don't have to check the return +type to know what you're indexing. + + + +On 20/06/14 19:21, Jeff Stedfast wrote: +> To be fair, it's also kinda obvious :-) +> +> +> On Fri, Jun 20, 2014 at 1:53 PM, Mike Krüger <mkrueger at xamarin.com +> <mailto:mkrueger at xamarin.com>> wrote: +> +> Hi +> +> To be fair it's something I've borrowed from Roslyn. +> +> Regards +> Mike +> +>> Hi Mike, +>> +>> I like the API change you are suggesting. +>> +>> Jeff +>> +>> +>> +>> On Fri, Jun 20, 2014 at 1:16 PM, Mike Krüger <mkrueger at xamarin.com +>> <mailto:mkrueger at xamarin.com>> wrote: +>> +>> +>> Hi +>> +>> I'm currently reviewing the text editor API. We've a method +>> called: +>> +>> public char GetCharAt (int < span class="n" style="box-sizing: +>> border-box; color: rgb(51, 51, 51);">offset) +>> +>> +>> And atm I think about replacing it with : +>> +>> public char this[int offset] +>> +>> Maybe even add a setter to that - then the editor may feel a +>> bit more like a string from a certain PoV. +>> The question is: Is that a good or bad choice - how are you +>> feeling about it ? +>> +>> The text editor has 3 layers: Text, Document and Editor - each +>> layer adds something on top of the text. The GetCharAt is a +>> functionality from the Text. On this level there is just text. +>> I think the indexer makes sense there. But how about the upper +>> layers? At Document level the editor becomes a collection of +>> lines as well. +>> +>> I would love to hear some opinions. (About the speed: In this +>> is a very lightweight operation - in our current +>> Implementation it's done in O(1) in the worst case I can +>> imagine that it becomes an O(log N) one). +>> +>> Regards +>> Mike +>> +>> +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> <mailto:Monodevelop-devel-list at lists.ximian.com> +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> +> +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> ++ + + +
Hi + +We've 3 levels: + +ITextSource -> IDocument -> TextEditor + +And they inherit from each other. So if you've a text source you're +having either the GetCharAt or indexer way of accessing the characters. + +With the new API I want it to make it easier to write code for the +ITextSource or IDocument level and use a text editor object with it. +Depends on the way we want to look at the whole thing. + +If we treat the text as char[] and lines, syntax highlighting, text +markers etc. is just meta data to the char array I think the indexer +makes sense. If we say the work with text is more complex and maybe the +O(1) cost of getting a char will change then the GetCharAt approach is +better. +I'm not really certain which way is the best. + +But one thing is for sure: We either have the indexer at all levels or not. + +Regards +Mike +> I think it is obvious and intuitive at the Text level, but for Document +> and Editor then it becomes a bit less intuitive. +> +> As Mike said, the Document has lines as well as characters. How often is +> someone going to want to use the index as a line vs as a character? +> Which would you assume is which? I think it is probably clearer to keep +> the methods at those levels so that you don't have to check the return +> type to know what you're indexing. + ++ + + +
> +> Hi +> +> I'm currently reviewing the text editor API. We've a method called: +> +> public char GetCharAt (int +> < +> span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51);">offset) +> +> And atm I think about replacing it with : +> +> public char this[int offset] +> +> Maybe even add a setter to that - then the editor may feel a bit more like a string from a certain PoV. +> The question is: Is that a good or bad choice - how are you feeling about it ? + +Bad. It makes the api harder to discover (no code completion) and harder to understand. Indexers should only be used for classes which are collections (and a text editor is not a collection, it just happens to contain a collection of chars, among many other things). + +> +> The text editor has 3 layers: Text, Document and Editor - each layer adds something on top of the text. The GetCharAt is a functionality from the Text. On this level there is just text. I think the indexer makes sense there. But how about the upper layers? At Document level the editor becomes a collection of lines as well. +> +> I would love to hear some opinions. (About the speed: In this is a very lightweight operation - in our current Implementation it's done in O(1) in the worst case I can imagine that it becomes an O(log N) one). +> +> Regards +> Mike +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140623/3d363a8e/attachment.html> ++ + + +
Thinking about the last message from Lluis, maybe conceptually the better +would be an indirection of sorts: a readonly property Chars that implements +an interface that is indexed? Performance-wise it can be a problem if the +jit can't optimize it into the equivalent optimized form of GetCharAt, also +null-checks, may be coded (not necessarily needed, but coded) that may be +hard to optimize out, too. Under the wraps it would need to do all the +buffer handling (maybe with paging) that GetCharAt is indeed obliged to +handle, maybe split between the property getter and the indexer getter and +setter. + +Just my 2 cents, + +Rafael Teixeira +O..:.)oooo + + +On Mon, Jun 23, 2014 at 6:44 AM, Lluis Sanchez Gual <slluis.devel at gmail.com> +wrote: + +> +> Hi +> +> I'm currently reviewing the text editor API. We've a method called: +> +> public char GetCharAt (int +> < +> span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51);">offset) +> +> +> And atm I think about replacing it with : +> +> public char this[int offset] +> +> Maybe even add a setter to that - then the editor may feel a bit more like +> a string from a certain PoV. +> The question is: Is that a good or bad choice - how are you feeling about +> it ? +> +> +> Bad. It makes the api harder to discover (no code completion) and harder +> to understand. Indexers should only be used for classes which are +> collections (and a text editor is not a collection, it just happens to +> contain a collection of chars, among many other things). +> +> +> The text editor has 3 layers: Text, Document and Editor - each layer adds +> something on top of the text. The GetCharAt is a functionality from the +> Text. On this level there is just text. I think the indexer makes sense +> there. But how about the upper layers? At Document level the editor becomes +> a collection of lines as well. +> +> I would love to hear some opinions. (About the speed: In this is a very +> lightweight operation - in our current Implementation it's done in O(1) in +> the worst case I can imagine that it becomes an O(log N) one). +> +> Regards +> Mike +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140623/7bee990e/attachment.html> ++ + + +
Hi + +I chose to stay with GetCharAt because most people preferred it (only +Jeff liked the indexer). + +I don't think it's 'hard' to discover. The indexer makes sense IMO. It +shouldn't be looked at the editor/document level - just at the +ITextSource. That's very close to a char[] ... the document & editor is +just extending that. I had to 'discover' that in the roslyn API ... took +me about < 5 seconds. In the Roslyn version it's needed to use the +Roslyn text API from time to time - then we would need to mix GetCharAt +and Indexers anyways. This would be more consistent. + +The GetCharAt OTOH is easier to read/in line with GetTextAt - and - I +can't guarantee that it will stay O(1). One strong argument for staying +with GetCharAt is that we need fewer code changes and we're all used to +that. + +btw. the API can still be changed. I would like to hear opinions - I +just wanted to bring up one topic to start the discussion about that. +Working with text is an important feature of the IDE. + +Regards +Mike + +> Thinking about the last message from Lluis, maybe conceptually the +> better would be an indirection of sorts: a readonly property Chars +> that implements an interface that is indexed? Performance-wise it can +> be a problem if the jit can't optimize it into the equivalent +> optimized form of GetCharAt, also null-checks, may be coded (not +> necessarily needed, but coded) that may be hard to optimize out, too. +> Under the wraps it would need to do all the buffer handling (maybe +> with paging) that GetCharAt is indeed obliged to handle, maybe split +> between the property getter and the indexer getter and setter. +> +> Just my 2 cents, +> +> Rafael Teixeira +> O..:.)oooo +> +> +> On Mon, Jun 23, 2014 at 6:44 AM, Lluis Sanchez Gual +> <slluis.devel at gmail.com <mailto:slluis.devel at gmail.com>> wrote: +> +>> +>> Hi +>> +>> I'm currently reviewing the text editor API. We've a method called: +>> +>> public char GetCharAt (int < span class="n" style="box-sizing: +>> border-box; color: rgb(51, 51, 51);">offset) +>> +>> And atm I think about replacing it with : +>> +>> public char this[int offset] +>> +>> Maybe even add a setter to that - then the editor may feel a bit +>> more like a string from a certain PoV. +>> The question is: Is that a good or bad choice - how are you +>> feeling about it ? +> +> Bad. It makes the api harder to discover (no code completion) and +> harder to understand. Indexers should only be used for classes +> which are collections (and a text editor is not a collection, it +> just happens to contain a collection of chars, among many other +> things). +> +>> +>> The text editor has 3 layers: Text, Document and Editor - each +>> layer adds something on top of the text. The GetCharAt is a +>> functionality from the Text. On this level there is just text. I +>> think the indexer makes sense there. But how about the upper +>> layers? At Document level the editor becomes a collection of +>> lines as well. +>> +>> I would love to hear some opinions. (About the speed: In this is +>> a very lightweight operation - in our current Implementation it's +>> done in O(1) in the worst case I can imagine that it becomes an +>> O(log N) one). +>> +>> Regards +>> Mike +>> +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> <mailto:Monodevelop-devel-list at lists.ximian.com> +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> <mailto:Monodevelop-devel-list at lists.ximian.com> +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140623/86c8d2c8/attachment.html> ++ + + +
Maaaaaan, I guess now I know how important *my* opinions are :p + +Jeff + + +On Mon, Jun 23, 2014 at 4:29 PM, Mike Krüger <mkrueger at xamarin.com> wrote: + +> Hi +> +> I chose to stay with GetCharAt because most people preferred it (only +> Jeff liked the indexer). +> +> I don't think it's 'hard' to discover. The indexer makes sense IMO. It +> shouldn't be looked at the editor/document level - just at the ITextSource. +> That's very close to a char[] ... the document & editor is just extending +> that. I had to 'discover' that in the roslyn API ... took me about < 5 +> seconds. In the Roslyn version it's needed to use the Roslyn text API from +> time to time - then we would need to mix GetCharAt and Indexers anyways. +> This would be more consistent. +> +> The GetCharAt OTOH is easier to read/in line with GetTextAt - and - I +> can't guarantee that it will stay O(1). One strong argument for staying +> with GetCharAt is that we need fewer code changes and we're all used to +> that. +> +> btw. the API can still be changed. I would like to hear opinions - I just +> wanted to bring up one topic to start the discussion about that. Working +> with text is an important feature of the IDE. +> +> Regards +> Mike +> +> +> Thinking about the last message from Lluis, maybe conceptually the +> better would be an indirection of sorts: a readonly property Chars that +> implements an interface that is indexed? Performance-wise it can be a +> problem if the jit can't optimize it into the equivalent optimized form of +> GetCharAt, also null-checks, may be coded (not necessarily needed, but +> coded) that may be hard to optimize out, too. Under the wraps it would need +> to do all the buffer handling (maybe with paging) that GetCharAt is indeed +> obliged to handle, maybe split between the property getter and the indexer +> getter and setter. +> +> Just my 2 cents, +> +> Rafael Teixeira +> O..:.)oooo +> +> +> On Mon, Jun 23, 2014 at 6:44 AM, Lluis Sanchez Gual < +> slluis.devel at gmail.com> wrote: +> +>> +>> Hi +>> +>> I'm currently reviewing the text editor API. We've a method called: +>> +>> public char GetCharAt (int +>> < +>> span class="n" style="box-sizing: border-box; color: rgb(51, 51, 51);">offset) +>> +>> +>> And atm I think about replacing it with : +>> +>> public char this[int offset] +>> +>> Maybe even add a setter to that - then the editor may feel a bit more +>> like a string from a certain PoV. +>> The question is: Is that a good or bad choice - how are you feeling about +>> it ? +>> +>> +>> Bad. It makes the api harder to discover (no code completion) and +>> harder to understand. Indexers should only be used for classes which are +>> collections (and a text editor is not a collection, it just happens to +>> contain a collection of chars, among many other things). +>> +>> +>> The text editor has 3 layers: Text, Document and Editor - each layer adds +>> something on top of the text. The GetCharAt is a functionality from the +>> Text. On this level there is just text. I think the indexer makes sense +>> there. But how about the upper layers? At Document level the editor becomes +>> a collection of lines as well. +>> +>> I would love to hear some opinions. (About the speed: In this is a very +>> lightweight operation - in our current Implementation it's done in O(1) in +>> the worst case I can imagine that it becomes an O(log N) one). +>> +>> Regards +>> Mike +>> +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> +>> +>> _______________________________________________ +>> Monodevelop-devel-list mailing list +>> Monodevelop-devel-list at lists.ximian.com +>> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +>> +>> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140623/3129f14d/attachment-0001.html> ++ + +
Starting: Fri Jun 20 17:16:41 UTC 2014
+ Ending: Mon Jun 23 21:10:38 UTC 2014
+ Messages: 10
+
+ Last message date:
+ Mon Jun 23 21:10:38 UTC 2014
+ Archived on: Mon Jun 23 21:10:44 UTC 2014
+
+
+
Starting: Fri Jun 20 17:16:41 UTC 2014
+ Ending: Mon Jun 23 21:10:38 UTC 2014
+ Messages: 10
+
+ Last message date:
+ Mon Jun 23 21:10:38 UTC 2014
+ Archived on: Mon Jun 23 21:10:44 UTC 2014
+
+
+
Starting: Fri Jun 20 17:16:41 UTC 2014
+ Ending: Mon Jun 23 21:10:38 UTC 2014
+ Messages: 10
+
+ Last message date:
+ Mon Jun 23 21:10:38 UTC 2014
+ Archived on: Mon Jun 23 21:10:44 UTC 2014
+
+
+
Starting: Fri Jun 20 17:16:41 UTC 2014
+ Ending: Mon Jun 23 21:10:38 UTC 2014
+ Messages: 10
+
+ Last message date:
+ Mon Jun 23 21:10:38 UTC 2014
+ Archived on: Mon Jun 23 21:10:44 UTC 2014
+
+
+
Starting: Fri Jun 20 17:16:41 UTC 2014
+ Ending: Mon Jun 23 21:10:38 UTC 2014
+ Messages: 10
+
+ Last message date:
+ Mon Jun 23 21:10:38 UTC 2014
+ Archived on: Mon Jun 23 21:10:44 UTC 2014
+
+
+
Hello. + +Before I introduce myself and my proposal, I should ask: Any chance +XUnit.net support for MonoDevelop might be approved as a project for GSoC? + +Thanks! +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140303/685c2a63/attachment.html> ++ + + +
Yes :) + +On 3 March 2014 00:15, Sergey Khabibullin <x2bool at gmail.com> wrote: +> Hello. +> +> Before I introduce myself and my proposal, I should ask: Any chance +> XUnit.net support for MonoDevelop might be approved as a project for GSoC? +> +> Thanks! +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + +
Hello. My name is Sergey. I am a student at Moscow Technological Institute +(formerly known as World Technological University UNESCO). +I am looking forward for GSoC 2014. + +I know that proposal should be made later at offical Google Summer of Code +site, but I was told that it would be better to contact with +mentoring organisation earlier. + +I was around Mono since I moved my development activities from Windows to +Linux. And I am happy that I haven't had to trade one of my favorite +programming languages for something else. + +I studied Mono's project list for GSoC, but I want to propose something +else. My target is MonoDevelop (Xamarin Studio), specifically an Xunit.net +test runner. I was planning an addin for MonoDevelop since the past autumn, +and I have studied for that purpose Mono.Addins, Xunit sources, NUnit addin +and, of course, basics of MonoDevelop's internals. + +At this moment my only opensource activity is this little project ( +https://github.com/x2bool/NCaptcha/wiki). The project was written +~2 years ago, and it's not the best code humanity has ever written. +However, the code does it's job. + +My hope is to make the Xunit addin that will copy (at least most of the +parts) the functionality of the existing NUnit addin. I think it would be +wise to target the Xunit 2.0 (now in beta) release. The Xunit.net itself +doesn't seem to be the hardest part, but it will require some amount of +code. I see the hardest challenge in GUI integration because I am not +familiar with Gtk-Sharp. But if it's more or less like Java Swing or +Android's GUI framework this shouldn't be impossible. + +As I understand my chances will increase if I will do some work to show my +skills. What should I do? Can I pick up a random bug from bugzilla, work on +it and make a pull request? + + +On Tue, Mar 4, 2014 at 8:49 AM, Michael Hutchinson <m.j.hutchinson at gmail.com +> wrote: + +> Yes :) +> +> On 3 March 2014 00:15, Sergey Khabibullin <x2bool at gmail.com> wrote: +> > Hello. +> > +> > Before I introduce myself and my proposal, I should ask: Any chance +> > XUnit.net support for MonoDevelop might be approved as a project for +> GSoC? +> > +> > Thanks! +> > +> > _______________________________________________ +> > Monodevelop-devel-list mailing list +> > Monodevelop-devel-list at lists.ximian.com +> > http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> > +> +> +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140304/2084d085/attachment.html> ++ + + +
On 4 March 2014 12:51, Sergey Khabibullin <x2bool at gmail.com> wrote: +> Hello. My name is Sergey. I am a student at Moscow Technological Institute +> (formerly known as World Technological University UNESCO). +> I am looking forward for GSoC 2014. +> +> I know that proposal should be made later at offical Google Summer of Code +> site, but I was told that it would be better to contact with +> mentoring organisation earlier. +> +> I was around Mono since I moved my development activities from Windows to +> Linux. And I am happy that I haven't had to trade one of my favorite +> programming languages for something else. +> +> I studied Mono's project list for GSoC, but I want to propose something +> else. My target is MonoDevelop (Xamarin Studio), specifically an Xunit.net +> test runner. I was planning an addin for MonoDevelop since the past autumn, +> and I have studied for that purpose Mono.Addins, Xunit sources, NUnit addin +> and, of course, basics of MonoDevelop's internals. +> +> At this moment my only opensource activity is this little project +> (https://github.com/x2bool/NCaptcha/wiki). The project was written +> ~2 years ago, and it's not the best code humanity has ever written. However, +> the code does it's job. +> +> My hope is to make the Xunit addin that will copy (at least most of the +> parts) the functionality of the existing NUnit addin. I think it would be +> wise to target the Xunit 2.0 (now in beta) release. The Xunit.net itself +> doesn't seem to be the hardest part, but it will require some amount of +> code. I see the hardest challenge in GUI integration because I am not +> familiar with Gtk-Sharp. But if it's more or less like Java Swing or +> Android's GUI framework this shouldn't be impossible. + +Yeah, GTK# isn't difficult to pick up. + +That said, I don't think much (if any) GUI work is necessary to +integrate XUnit - the sensible way to do this would be to plug in +XUnit as a test provider/runner into the existing unit test addin. +There would be some work to finish abstracting out the NUnit +dependency from the existing addin - maybe even modeling this +abstraction on the VS2012 unit test runner interfaces +(http://blogs.msdn.com/b/bhuvaneshwari/archive/2012/03/13/authoring-a-new-visual-studio-test-adapter.aspx) +to make it easier to port over OSS unit test adaptors from VS. + +> As I understand my chances will increase if I will do some work to show my +> skills. What should I do? Can I pick up a random bug from bugzilla, work on +> it and make a pull request? + +Yep. Preferably something you're interested in. And feel free to ask +questions if you're not sure how to approach the bug :) + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + +
Hello; + + + I've been around the #monosoc and #monodev channels for a bit now under the nick TCD; I was interested in applying for GSoC to work on the source code analysis/refactoring area. + + +I've talked through it with some people to a degree over IRC, but I've come to drafting my proposal and hit some points I wanted to discuss further. + + +a) I know that NRefactory is used 'under the hood' for analysis; would therefore most work with code actions and refactoring be done within the NRefactory project? I noticed there are a lot (a huge amount already) of actions in MD, but the only code I could seem to find in the MD base itself was for interfacing with code actions. + + +b) Would research time - that is, thorough research rather than skimming - fall under the GSoC project time, or would it be something to be done prior to the project? Obviously work to see what, say, Visual Studio or Eclipse provides in the way of code actions would be needed to see what MD is lacking. + + +c) I'm having some issues with the idea of the scale of the project; on the surface, it seems that code actions would not take up much of the 3 months of work (unless there were a LOT being added). Would something extra on top be expected in a good proposal? I had an idea to add a step-through analyser to see and very quickly fix any potential code issues in the selected scope (file, project, solution) or some kind of further visualisation of the analysis - for instance, providing further detail to the actions listed in the menu (what contributes a 'simplify negative relational expression' for example?) - but since I wasn't 100% sure of the scale of the project, I didn't know whether these would fall under stretch goals if time permits or not. + + Obviously it'd depend on my work speed, but right now when trying to sketch out a battleplan I get to 'week 1, detailed research and make sure I can work my way around the codebase, week 2+ implement things?' :) + + +Thank you for your time, + + +Mark/TCD + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140307/a417ac28/attachment.html> ++ + + + + + + +
Hi Mark, + +Sorry for the late reply, GMail decided to mark this as spam for some +reason known only to itself... + +a) Yes, it's a mixture. NRefactory does have systems for defining code +actions and code issues. An IDE (i.e. MD/XS/#D) implements the GUI and +some high-level services needed by the code actions/issues, and +automatically gets all the ones defined in NRefactory. However, there +are some actions/issues/refactorings things that need to implement a +UI, or need access to the project model beyond that available in +NRefactory, and these are implemented in MD/XS. Basically, it would +depend on what exactly you were implementing. Some things could be +done in NR, some could be done in MD, and in some cases it would make +sense to extend the NR abstractions and implement them in MD. + +b) This would be another common-sense, case-by-case kind of thing. +Research is great as long as it has some outcome e.g. something like +"I tried implementing the algorithm from this paper but it didn't +perform was well as I hoped" is fine but "I spent a week just reading +papers" probably isn't. + +c) code issues and code actions are an unending rabbit hole since +they're about detecting potential problems and improvements in the +code - which to solve perfectly, requires solving the halting problem, +or maybe some kind of strong AI :) Some are almost trivial, e.g. the +existing "extract local from expression", and some are incredibly +complicated, e.g. detecting null dereferences took weeks to implement +and still only handles some locals. + +It's all about "bang for the buck". If the code +issue/action/refactoring useful enough assisting users in writing good +code to be worth your time implementing it and the overhead of having +it as part of the IDE? + +- M + +On 7 March 2014 18:34, garnett m. (mg10g13) <mg10g13 at soton.ac.uk> wrote: +> Hello; +> +> +> I've been around the #monosoc and #monodev channels for a bit now under +> the nick TCD; I was interested in applying for GSoC to work on the source +> code analysis/refactoring area. +> +> +> I've talked through it with some people to a degree over IRC, but I've come +> to drafting my proposal and hit some points I wanted to discuss further. +> +> +> a) I know that NRefactory is used 'under the hood' for analysis; would +> therefore most work with code actions and refactoring be done within the +> NRefactory project? I noticed there are a lot (a huge amount already) of +> actions in MD, but the only code I could seem to find in the MD base itself +> was for interfacing with code actions. +> +> +> b) Would research time - that is, thorough research rather than skimming - +> fall under the GSoC project time, or would it be something to be done prior +> to the project? Obviously work to see what, say, Visual Studio or Eclipse +> provides in the way of code actions would be needed to see what MD is +> lacking. +> +> +> c) I'm having some issues with the idea of the scale of the project; on the +> surface, it seems that code actions would not take up much of the 3 months +> of work (unless there were a LOT being added). Would something extra on top +> be expected in a good proposal? I had an idea to add a step-through analyser +> to see and very quickly fix any potential code issues in the selected scope +> (file, project, solution) or some kind of further visualisation of the +> analysis - for instance, providing further detail to the actions listed in +> the menu (what contributes a 'simplify negative relational expression' for +> example?) - but since I wasn't 100% sure of the scale of the project, I +> didn't know whether these would fall under stretch goals if time permits or +> not. +> +> Obviously it'd depend on my work speed, but right now when trying to +> sketch out a battleplan I get to 'week 1, detailed research and make sure I +> can work my way around the codebase, week 2+ implement things?' :) +> +> +> Thank you for your time, +> +> +> Mark/TCD +> +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +Michael Hutchinson +http://mjhutchinson.com ++ + + + + + + +
Hey, that's me, again. + +I've been investigating a bug from bugzilla, but found other bug (at least +I think so). +When moving or copying a directory within a project MonoDevelop won't save +moved directories in .csproj. +It saves files but not directories. And I don't think it's a normal +behavior. + +To check this you could create a project with this structure - +/Folder1/Folder2/Folder3/MyClass.cs. +Then drag the Folder3 to the Folder1. Now you might close MD and check the +.csproj. +MyClass.cs will be in the project, but not the Folder3. + +I tried to fix this: https://github.com/x2bool/monodevelop/compare/bug + +I also tried to model Visual Studio's test adapter you suggested earlier, +applying all that to MonoDevelop. +I almost done and will publish results in two or three days. + +Thanks. + + + +On Wed, Mar 5, 2014 at 10:06 PM, Michael Hutchinson < +m.j.hutchinson at gmail.com> wrote: + +> On 4 March 2014 12:51, Sergey Khabibullin <x2bool at gmail.com> wrote: +> > Hello. My name is Sergey. I am a student at Moscow Technological +> Institute +> > (formerly known as World Technological University UNESCO). +> > I am looking forward for GSoC 2014. +> > +> > I know that proposal should be made later at offical Google Summer of +> Code +> > site, but I was told that it would be better to contact with +> > mentoring organisation earlier. +> > +> > I was around Mono since I moved my development activities from Windows to +> > Linux. And I am happy that I haven't had to trade one of my favorite +> > programming languages for something else. +> > +> > I studied Mono's project list for GSoC, but I want to propose something +> > else. My target is MonoDevelop (Xamarin Studio), specifically an +> Xunit.net +> > test runner. I was planning an addin for MonoDevelop since the past +> autumn, +> > and I have studied for that purpose Mono.Addins, Xunit sources, NUnit +> addin +> > and, of course, basics of MonoDevelop's internals. +> > +> > At this moment my only opensource activity is this little project +> > (https://github.com/x2bool/NCaptcha/wiki). The project was written +> > ~2 years ago, and it's not the best code humanity has ever written. +> However, +> > the code does it's job. +> > +> > My hope is to make the Xunit addin that will copy (at least most of the +> > parts) the functionality of the existing NUnit addin. I think it would be +> > wise to target the Xunit 2.0 (now in beta) release. The Xunit.net itself +> > doesn't seem to be the hardest part, but it will require some amount of +> > code. I see the hardest challenge in GUI integration because I am not +> > familiar with Gtk-Sharp. But if it's more or less like Java Swing or +> > Android's GUI framework this shouldn't be impossible. +> +> Yeah, GTK# isn't difficult to pick up. +> +> That said, I don't think much (if any) GUI work is necessary to +> integrate XUnit - the sensible way to do this would be to plug in +> XUnit as a test provider/runner into the existing unit test addin. +> There would be some work to finish abstracting out the NUnit +> dependency from the existing addin - maybe even modeling this +> abstraction on the VS2012 unit test runner interfaces +> ( +> http://blogs.msdn.com/b/bhuvaneshwari/archive/2012/03/13/authoring-a-new-visual-studio-test-adapter.aspx +> ) +> to make it easier to port over OSS unit test adaptors from VS. +> +> > As I understand my chances will increase if I will do some work to show +> my +> > skills. What should I do? Can I pick up a random bug from bugzilla, work +> on +> > it and make a pull request? +> +> Yep. Preferably something you're interested in. And feel free to ask +> questions if you're not sure how to approach the bug :) +> +> -- +> Michael Hutchinson +> http://mjhutchinson.com +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140312/dd53a69c/attachment.html> ++ + + + +
Dear Mono Community, +I am interested in doing Debugger Visualizer project (specified at +http://www.mono-project.com/StudentProjects#MonoDevelop_.2F_Xamarin_Studio_IDE) +as part of GSoC 14. +I have background in C# and Java and have some experience doing projects in +.Net. I am attracted to Mono because it allows users to feel free of the +limitations of Microsoft platform while at the same time, enjoy .Net +programming. + +While exploring Xamarin, I came across a bug which I have reported at +bugzilla + +https://bugzilla.xamarin.com/show_bug.cgi?id=18326 + +I am preparing a list of Debugger visualizers that will be implemented +during gsoc. If you have some suggestions, please let me know. + +Regards, +Abdul Rauf +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140312/2668e056/attachment.html> ++ + + + + + +
Hey, + + +I've written up a draft of my proposal about source code refactoring. However I know there's at least a couple of issues I wanted to raise: + + +https://docs.google.com/document/d/1lXSLW4oEdFnTLlLVZXcJeeOBUdBU7yfO-N5My7nel_M/edit?usp=sharing + + +1) The timeframe. Since I've not really done a project of anywhere near this size, I can't really base it off previous work I've done. Equally the quality would need to be consistent (I'd like to think my previous projects have been of good quality, but there's definitely a few lapses when I've been rushing to get it to work - I wouldn't repeat those!). Whilst I don't want to underestimate how much time I'd give per action, I don't want to look like I'm achieveing very little per week. So would I need to assign more time to each? Or is it about right and I'd move my stretch goal (or some other stretch goal) into the main project? + + +2) I've identified the main points - but I'm sure that the list would grow both from further research and just small things I find from doing the bigger things. Is it fine to miss these out until after the application period? + + +3) Anything else that needs a touchup? Would I need to go into more detail as to how I'm going to implement X, Y, and Z - or is just saying 'I will do X and I need to make sure I consider this, this, and this'? The deliverables section seems a bit empty too. + + +Thanks again! + + +-Mark +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140314/9292603b/attachment.html> ++ + + + + + +
Hello, Mark. + +I've read your proposal and I have some feedback: +"Replace some instance(s) of repeated code or expressions": There is +already a "Declare local variable" action. I think it could be a good +starting point for this feature. +The "add abstract keyword" action for methods which already have a body: +Would this be related to your "move method up/down in the inheritance +chain" action? +"Develop, or begin to develop, a unit testing framework for code actions +and refactoring. " This already +exists<https://github.com/icsharpcode/NRefactory/tree/master/ICSharpCode.NRefactory.Tests>. +See the existing code action tests for examples. +Add the async modifier to methods that use await: I like this idea but I +don't see why a new type of submenu is needed. Can't you just make it an +ordinary code issue/code issue fix? + +Good luck. +Luís Reis + + + +2014-03-14 0:02 GMT+00:00 garnett m. (mg10g13) <mg10g13 at soton.ac.uk>: + +> Hey, +> +> +> I've written up a draft of my proposal about source code refactoring. +> However I know there's at least a couple of issues I wanted to raise: +> +> +> +> https://docs.google.com/document/d/1lXSLW4oEdFnTLlLVZXcJeeOBUdBU7yfO-N5My7nel_M/edit?usp=sharing +> +> +> 1) The timeframe. Since I've not really done a project of anywhere near +> this size, I can't really base it off previous work I've done. Equally the +> quality would need to be consistent (I'd like to think my previous projects +> have been of good quality, but there's definitely a few lapses when I've +> been rushing to get it to work - I wouldn't repeat those!). Whilst I don't +> want to underestimate how much time I'd give per action, I don't want to +> look like I'm achieveing very little per week. So would I need to assign +> more time to each? Or is it about right and I'd move my stretch goal (or +> some other stretch goal) into the main project? +> +> +> 2) I've identified the main points - but I'm sure that the list would +> grow both from further research and just small things I find from doing the +> bigger things. Is it fine to miss these out until after the application +> period? +> +> +> 3) Anything else that needs a touchup? Would I need to go into more +> detail as to how I'm going to implement X, Y, and Z - or is just saying 'I +> will do X and I need to make sure I consider this, this, and this'? The +> deliverables section seems a bit empty too. +> +> +> Thanks again! +> +> +> -Mark +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140314/a6a98284/attachment.html> ++ + + + + + +
Hi, + +My name is Yuanchen from China.And I'm a undergraduate student major in +communication engineering. + +And I see the project of Color Scheme Editor. And i think this is an +excellent idea,I want to do sth about it. + +Every time I program sth in C, I often get confused when there are several +data types or some problem like this.So sometimes I just use some tools +like notepad+ to code sth,but it is still not a good solution. + + +If the color editor works better or the user can edit it ,this problem will +be solved to large extent.We can offer several kinds of color solutions +which can let the user distinguish every type or some links.Or we can just +let users choose the color they perfer,we just offer a editor. + +Regards! +Yuanchen +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140307/56787faf/attachment.html> ++ + + + +
Hi, + +My name is Yuanchen from China.And I'm a undergraduate student major in +communication engineering. + +And I see the project of Color Scheme Editor. And i think this is an +excellent idea,I want to do sth helpful about it. + +Every time I program sth in C, I often get confused when there are several +data types or silmiliar problems like this.So sometimes I just use some +tools like notepad+ to code sth,but it is still not a good solution. + +If the color editor works better or the user can edit it by themself ,this +problem will be solved to large extent.We can offer several kinds of color +solutions which can let the users distinguish every type or some links.Or +we can just let users choose the color they perfer,we just offer a editor. + +I would appreciate it very much if you give me some advice! + +Regards, +Yuanchen +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140309/e5b2129a/attachment.html> ++ + + +
Hello, My name is Denis. +I'm from Russia. + +Recently I discovered the GSoC and now i have a burning desire to take part +in the Summer Coding +I want to suggest my idea. + +At the present time MonoDevelop supports only syntax of the LINQ features, +but there is no such SQL queries editor as in the Visual Studio. In my +opinion it is a very interesting topic for implementation, because the +interaction with the database exists in a great number of different other +applications. +I have already started a small project and have made a simple website, +where the modified solution is presented. +On the website you can also read about the changes submitted to the file. +https://sites.google.com/site/myprojectofmonodevelop/ +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140321/8f0a264c/attachment.html> ++ + + +
Hello. I tried myself on the bug-14530 and made a pull request - +https://github.com/mono/monodevelop/pull/512 +Could someone take a look? + +I have been thinking about my proposal and I'd like to add implementation +details on this weekend. But currently it says: "Content of this proposal +is not editable at this moment, because student application period is over. +If you still need to make some changes, please send a comment to the +organization. They can enable modifications for this proposal". + +Could you enable it for this weekend? Or do I have to publish it here? + + + +On Wed, Mar 12, 2014 at 4:42 PM, Sergey Khabibullin <x2bool at gmail.com>wrote: + +> Hey, that's me, again. +> +> I've been investigating a bug from bugzilla, but found other bug (at least +> I think so). +> When moving or copying a directory within a project MonoDevelop won't save +> moved directories in .csproj. +> It saves files but not directories. And I don't think it's a normal +> behavior. +> +> To check this you could create a project with this structure - +> /Folder1/Folder2/Folder3/MyClass.cs. +> Then drag the Folder3 to the Folder1. Now you might close MD and check the +> .csproj. +> MyClass.cs will be in the project, but not the Folder3. +> +> I tried to fix this: https://github.com/x2bool/monodevelop/compare/bug +> +> I also tried to model Visual Studio's test adapter you suggested earlier, +> applying all that to MonoDevelop. +> I almost done and will publish results in two or three days. +> +> Thanks. +> +> +> +> On Wed, Mar 5, 2014 at 10:06 PM, Michael Hutchinson < +> m.j.hutchinson at gmail.com> wrote: +> +>> On 4 March 2014 12:51, Sergey Khabibullin <x2bool at gmail.com> wrote: +>> > Hello. My name is Sergey. I am a student at Moscow Technological +>> Institute +>> > (formerly known as World Technological University UNESCO). +>> > I am looking forward for GSoC 2014. +>> > +>> > I know that proposal should be made later at offical Google Summer of +>> Code +>> > site, but I was told that it would be better to contact with +>> > mentoring organisation earlier. +>> > +>> > I was around Mono since I moved my development activities from Windows +>> to +>> > Linux. And I am happy that I haven't had to trade one of my favorite +>> > programming languages for something else. +>> > +>> > I studied Mono's project list for GSoC, but I want to propose something +>> > else. My target is MonoDevelop (Xamarin Studio), specifically an +>> Xunit.net +>> > test runner. I was planning an addin for MonoDevelop since the past +>> autumn, +>> > and I have studied for that purpose Mono.Addins, Xunit sources, NUnit +>> addin +>> > and, of course, basics of MonoDevelop's internals. +>> > +>> > At this moment my only opensource activity is this little project +>> > (https://github.com/x2bool/NCaptcha/wiki). The project was written +>> > ~2 years ago, and it's not the best code humanity has ever written. +>> However, +>> > the code does it's job. +>> > +>> > My hope is to make the Xunit addin that will copy (at least most of the +>> > parts) the functionality of the existing NUnit addin. I think it would +>> be +>> > wise to target the Xunit 2.0 (now in beta) release. The Xunit.net itself +>> > doesn't seem to be the hardest part, but it will require some amount of +>> > code. I see the hardest challenge in GUI integration because I am not +>> > familiar with Gtk-Sharp. But if it's more or less like Java Swing or +>> > Android's GUI framework this shouldn't be impossible. +>> +>> Yeah, GTK# isn't difficult to pick up. +>> +>> That said, I don't think much (if any) GUI work is necessary to +>> integrate XUnit - the sensible way to do this would be to plug in +>> XUnit as a test provider/runner into the existing unit test addin. +>> There would be some work to finish abstracting out the NUnit +>> dependency from the existing addin - maybe even modeling this +>> abstraction on the VS2012 unit test runner interfaces +>> ( +>> http://blogs.msdn.com/b/bhuvaneshwari/archive/2012/03/13/authoring-a-new-visual-studio-test-adapter.aspx +>> ) +>> to make it easier to port over OSS unit test adaptors from VS. +>> +>> > As I understand my chances will increase if I will do some work to show +>> my +>> > skills. What should I do? Can I pick up a random bug from bugzilla, +>> work on +>> > it and make a pull request? +>> +>> Yep. Preferably something you're interested in. And feel free to ask +>> questions if you're not sure how to approach the bug :) +>> +>> -- +>> Michael Hutchinson +>> http://mjhutchinson.com +>> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140327/0fd13e1a/attachment.html> ++ + +
Starting: Mon Mar 3 05:15:09 UTC 2014
+ Ending: Thu Mar 27 07:04:12 UTC 2014
+ Messages: 14
+
+ Last message date:
+ Thu Mar 27 07:04:12 UTC 2014
+ Archived on: Thu Mar 27 07:04:16 UTC 2014
+
+
+
Starting: Mon Mar 3 05:15:09 UTC 2014
+ Ending: Thu Mar 27 07:04:12 UTC 2014
+ Messages: 14
+
+ Last message date:
+ Thu Mar 27 07:04:12 UTC 2014
+ Archived on: Thu Mar 27 07:04:16 UTC 2014
+
+
+
Starting: Mon Mar 3 05:15:09 UTC 2014
+ Ending: Thu Mar 27 07:04:12 UTC 2014
+ Messages: 14
+
+ Last message date:
+ Thu Mar 27 07:04:12 UTC 2014
+ Archived on: Thu Mar 27 07:04:16 UTC 2014
+
+
+
Starting: Mon Mar 3 05:15:09 UTC 2014
+ Ending: Thu Mar 27 07:04:12 UTC 2014
+ Messages: 14
+
+ Last message date:
+ Thu Mar 27 07:04:12 UTC 2014
+ Archived on: Thu Mar 27 07:04:16 UTC 2014
+
+
+
Starting: Mon Mar 3 05:15:09 UTC 2014
+ Ending: Thu Mar 27 07:04:12 UTC 2014
+ Messages: 14
+
+ Last message date:
+ Thu Mar 27 07:04:12 UTC 2014
+ Archived on: Thu Mar 27 07:04:16 UTC 2014
+
+
+
Hello everyone, + +My name is Aleksandr and this summer I will develop a new Color Scheme +Editor for MonoDevelop under taking a part in Google Summer of Code +program. I think about implementation of some features which current +editor lacks. These features are: + +1) Undo/redo operations support; +2) Group styles into tree for more comfortable navigation; +3) Quick styles search for more comfortable navigation too; +4) More detailed code sample (or several samples) to view changes of +scheme immediately; +5) Picking a style from sample document. Like +http://studiostyl.es/schemes/create; +6) User sets just few styles in scheme and then other colors are setting +automatically to provide good compatibility with colors sett by user. + +I would be glad to see any feedback about my plan. You can discuss my +ideas or propose yours. I would like to understand the wishes of community. + +Regards, +Aleksandr Shevchenko ++ + + +
My understanding that the magic happens when calling this method: +*Runtime.ProcessService.CreateExternalProcessObject(typeof(RemoteExecutor), +executionContext)* where *executionContext* is +*Runtime.ProcessService.GetDebugExecutionMode()*. Is that right? + +My guess - it creates an *AppDomain*, and any code executed on that domain +is automatically debuggable. + +Given so, how do I create an object of type T inside the domain? I tried to +pass the assembly and type information to *RemoteExecutor* to create the +object using Activator. This approach fails with *FileNotFoundException*: +it can't load the dll where the type T resides for some reason, while the +dll is 100% present. + +Could someone explain how to create an object of known type T on the side +of the newly created *AppDomain*? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20140526/3b43789e/attachment.html> ++ + +
Starting: Wed May 21 06:03:25 UTC 2014
+ Ending: Mon May 26 07:37:54 UTC 2014
+ Messages: 2
+
+ Last message date:
+ Mon May 26 07:37:54 UTC 2014
+ Archived on: Mon May 26 07:37:57 UTC 2014
+
+
+
Starting: Wed May 21 06:03:25 UTC 2014
+ Ending: Mon May 26 07:37:54 UTC 2014
+ Messages: 2
+
+ Last message date:
+ Mon May 26 07:37:54 UTC 2014
+ Archived on: Mon May 26 07:37:57 UTC 2014
+
+
+
Starting: Wed May 21 06:03:25 UTC 2014
+ Ending: Mon May 26 07:37:54 UTC 2014
+ Messages: 2
+
+ Last message date:
+ Mon May 26 07:37:54 UTC 2014
+ Archived on: Mon May 26 07:37:57 UTC 2014
+
+
+
Starting: Wed May 21 06:03:25 UTC 2014
+ Ending: Mon May 26 07:37:54 UTC 2014
+ Messages: 2
+
+ Last message date:
+ Mon May 26 07:37:54 UTC 2014
+ Archived on: Mon May 26 07:37:57 UTC 2014
+
+
+
Starting: Wed May 21 06:03:25 UTC 2014
+ Ending: Mon May 26 07:37:54 UTC 2014
+ Messages: 2
+
+ Last message date:
+ Mon May 26 07:37:54 UTC 2014
+ Archived on: Mon May 26 07:37:57 UTC 2014
+
+
+
Hi, + +shovonjamali at gmail.com wants to follow you. + +****** Is shovonjamali at gmail.com you friend? ****** +If Yes please follow the link below: +http://invites.flipmailer.com/signup_e.html?fullname=&email=monodevelop-devel-list@lists.ximian.com&invitername=shovonjamali@gmail.com&inviterid=32367313&userid=0&token=0&emailmasterid=b24a222d-e967-4160-a000-96171ca24f84&from=shovonjamali@gmail.com&src=txt_yes + +If No please follow the link below: +http://invites.flipmailer.com/signup_e.html?fullname=&email=monodevelop-devel-list@lists.ximian.com&invitername=shovonjamali@gmail.com&inviterid=32367313&userid=0&token=0&emailmasterid=b24a222d-e967-4160-a000-96171ca24f84&from=shovonjamali@gmail.com&src=txt_no + + +Follow the link below to remove yourself from all such emails +http://invites.flipmailer.com/uns_inviter.jsp?email=monodevelop-devel-list@lists.ximian.com&iid=b24a222d-e967-4160-a000-96171ca24f84&from=shovonjamali@gmail.com + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20141013/eb81c1db/attachment.html> ++ + +
Starting: Mon Oct 13 19:33:06 UTC 2014
+ Ending: Mon Oct 13 19:33:06 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Mon Oct 13 19:33:06 UTC 2014
+ Archived on: Mon Oct 13 21:27:11 UTC 2014
+
+
+
Starting: Mon Oct 13 19:33:06 UTC 2014
+ Ending: Mon Oct 13 19:33:06 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Mon Oct 13 19:33:06 UTC 2014
+ Archived on: Mon Oct 13 21:27:11 UTC 2014
+
+
+
Starting: Mon Oct 13 19:33:06 UTC 2014
+ Ending: Mon Oct 13 19:33:06 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Mon Oct 13 19:33:06 UTC 2014
+ Archived on: Mon Oct 13 21:27:11 UTC 2014
+
+
+
Starting: Mon Oct 13 19:33:06 UTC 2014
+ Ending: Mon Oct 13 19:33:06 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Mon Oct 13 19:33:06 UTC 2014
+ Archived on: Mon Oct 13 21:27:11 UTC 2014
+
+
+
Starting: Mon Oct 13 19:33:06 UTC 2014
+ Ending: Mon Oct 13 19:33:06 UTC 2014
+ Messages: 1
+
+ Last message date:
+ Mon Oct 13 19:33:06 UTC 2014
+ Archived on: Mon Oct 13 21:27:11 UTC 2014
+
+
+
Hi Marius/All, + +I am Udbhav Vats, 2nd year sophomore, currently pursuing my Bachelors +degree in Information Technology from IIIT Bangalore. I am comfortable in +working with following programming languages : Java, c++, c#, c and have +worked in python scripting language too. I have used GIT version control +before and have a sound understanding of source version control. + +I feel that with the support of GIT and Subversion already in place, +Mercurial is an important and widely used version control tool and an Addin +support for it will prove to be very valuable for MonoDevelop. + +To begin with, I am trying to setup/build MonoDevelop from GitHub on my +windows machine and following the steps mentioned in the wiki +<http://www.monodevelop.com/developers/building-monodevelop/>. I will +create the simple date command Addin, following the Addin creation article +<http://www.monodevelop.com/developers/articles/creating-a-simple-add-in/> to +get a basic overview of how addins are created for MonoDevelop. I am also +taking a look at the source code at github ( +https://github.com/mono/monodevelop/tree/master/main/src/addins/VersionControl) +for GIT and Subversion support to get an idea of how those addins were +implemented. + +I will start taking a look at Mercurial APIs and see how we can integrate +it with MonoDevelop. +For creating a strong proposal and a clear and detailed timeline, I would +appreciate guidance from MonoDevelop community and Marius. Kindly let me +know the right approach that I should take or if there is anything that I +should get myself acquainted with. + +Regards, +Udbhav +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150304/7261b3dc/attachment.html> ++ + + +
Hi evererybody, + +I study computer engineering (Bsc) at University of Budapest for 2 years. + +I am interested in debugging process, so I chose "debugger tasks window +support" project from the list. + + I would like to take part in developing, what kind of sources should I +read in order to become capeble of it? I have found this +https://github.com/mono/debugger-libs, I think it is the relevant part for +all kind of debugging. Am I searching in the right place? + +I am new to Mono project but I have being developing with C# for +years,and have experince with many .NET technology:EF, WPF, WP8, i +hope it could be enough. + +Thanks for advices:) + +Best regards +Bence +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150305/4eab18ca/attachment.html> ++ + + +
Hi Bence, + +I'm happy that you are interested in this idea. +I quickly looked at this few months ago... There are few methods in runtime +that are just for debugger needs like get all schedulers +<https://github.com/mono/referencesource/blob/mono/mscorlib/system/threading/Tasks/TaskScheduler.cs#L562-L572> +, get all scheduled(queued) tasks in scheduler +<https://github.com/mono/referencesource/blob/mono/mscorlib/system/threading/Tasks/TaskScheduler.cs#L523-L537> +and +somewhere in threadpool for currently executing tasks, but I'm not 100% +which one is it, maybe this information has to be tracked via start/end of +tasks... + +Calling static methods from MonoDevelop shouldn't be much of problem... +Once this information is on MonoDevelop side. Information will have to be +displayed in new "Tasks window" pad, you can look at "Threads window +<https://github.com/mono/monodevelop/blob/master/main/src/addins/MonoDevelop.Debugger/MonoDevelop.Debugger/ThreadsPad.cs>" +pad to see how this can be implemented. Of course there will be more glue +code to connect all this... + +Regards, +David + +2015-03-05 23:55 GMT+01:00 Bence Tilk <bence.tilk at gmail.com>: + +> Hi evererybody, +> +> I study computer engineering (Bsc) at University of Budapest for 2 years. +> +> I am interested in debugging process, so I chose "debugger tasks window +> support" project from the list. +> +> I would like to take part in developing, what kind of sources should I +> read in order to become capeble of it? I have found this +> https://github.com/mono/debugger-libs, I think it is the relevant part +> for all kind of debugging. Am I searching in the right place? +> +> I am new to Mono project but I have being developing with C# for years,and have experince with many .NET technology:EF, WPF, WP8, i hope it could be enough. +> +> Thanks for advices:) +> +> Best regards +> Bence +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150306/eface8d6/attachment.html> ++ + + +
Hi, + I am Abhinav. I am currently in 2nd Year B.Tech. I want to contribute to +the Mono Development in the Compilers and tools section under GSoC '15. +. +Any suggestions of how to progress will be helpful! +Regards, +Abhinav +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150313/55c98aa9/attachment.html> ++ + + +
Hello, +I am Simon Larsen, currently I am studying Software Engineering (B.Sc) at the Southern University Denmark. I hope to participate in this years GSoC program and have found the Mono project to be very interesting. I've used both the Monodevelop IDE and the Mono runtime to build applications through Unity3d and Xamarin Studio and would love to contribute to this development environment. +I've looked through the GSoC project ideas list and I'm interested in working with the Monodevelop IDE. Particularly I'm interested in working on the "MD Class Diagrams" project as this is very relevant to my current semester (UP and UML) and I've always been a fan of code generation. +I'm new to the whole GSoC process, so I'm not entirely sure how to proceed from here? Any advice would be much appreciated. Thank you. +Regards,Simon Larsen +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150315/1a4de4d5/attachment.html> ++ + + +
Hello again, + +Maybe my previous mail was a little too wide/open. I've been thinking a little more about the project idea (MD Class Diagrams) and what exactly was being asked for. The project describes that the addin should generate class diagrams, but to what extend? Would gtk# be involved to interact with a generated class diagram - say the classes were placed illogically or the arrows needed to be moved/removed. Or would we draw the class diagram(s) onto a Bitmap? + +As for actually generating the classes, their attributes and their relations, how'd we determine which namespace (or entire solution?) we should generate a diagram(s) for. Should we call the addin from the command line, gtk# interface or maybe it's possible to add another option to the contextual menu when right clicking a solution? + +Lastly, I'm assuming reflection is the way to go and that we'd be working on source files (.cs). In any which case I assume the Assembly class could be used? +>From .cs files https://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecutingassembly%28v=vs.110%29.aspxFrom .dll files https://msdn.microsoft.com/en-us/library/1009fa28(v=vs.110).aspx +So that's a lot of questions and a few assumptions. Hope to hear back from you! +Regards,Simon Larsen +From: simon333_333 at hotmail.com +To: monodevelop-devel-list at lists.ximian.com +Subject: GSoC project +Date: Sun, 15 Mar 2015 00:03:09 +0100 + + + + +Hello, +I am Simon Larsen, currently I am studying Software Engineering (B.Sc) at the Southern University Denmark. I hope to participate in this years GSoC program and have found the Mono project to be very interesting. I've used both the Monodevelop IDE and the Mono runtime to build applications through Unity3d and Xamarin Studio and would love to contribute to this development environment. +I've looked through the GSoC project ideas list and I'm interested in working with the Monodevelop IDE. Particularly I'm interested in working on the "MD Class Diagrams" project as this is very relevant to my current semester (UP and UML) and I've always been a fan of code generation. +I'm new to the whole GSoC process, so I'm not entirely sure how to proceed from here? Any advice would be much appreciated. Thank you. +Regards,Simon Larsen +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150317/fc6172f6/attachment.html> ++ + + +
Sorry for the late reply. + +I'm actually more interested in the use of the diagram for interactively +exploring class relationships, like the visual studio class diagram tool +allows. Editing would be good too, but I think it could be considered a +stretch goal for GSoC. The important thing is a really nice canvas widget +and solid core functionality. + +So yes, gtk# would be needed for the widget. The MonoDevelop type system +can provide all the data and the MonoDevelop refactoring systems can be +used for editing. + +Compatibility with the VS .cd format would be nice but isn't a must-have. + +- m +On Mar 17, 2015 2:15 PM, "simon larsen" <simon333_333 at hotmail.com> wrote: + +> Hello again, +> +> +> Maybe my previous mail was a little too wide/open. I've been thinking a +> little more about the project idea (*MD Class Diagrams*) and what exactly +> was being asked for. The project describes that the addin should generate +> class diagrams, but to what extend? Would gtk# be involved to interact with +> a generated class diagram - say the classes were placed illogically or the +> arrows needed to be moved/removed. Or would we draw the class diagram(s) +> onto a Bitmap? +> +> +> As for actually generating the classes, their attributes and their +> relations, how'd we determine which namespace (or entire solution?) we +> should generate a diagram(s) for. Should we call the addin from the command +> line, gtk# interface or maybe it's possible to add another option to the +> contextual menu when right clicking a solution? +> +> +> Lastly, I'm assuming reflection is the way to go and that we'd be working +> on source files (.cs). In any which case I assume the Assembly class could +> be used? +> +> From .cs files +> https://msdn.microsoft.com/en-us/library/system.reflection.assembly.getexecutingassembly%28v=vs.110%29.aspx +> From .dll files +> https://msdn.microsoft.com/en-us/library/1009fa28(v=vs.110).aspx +> +> So that's a lot of questions and a few assumptions. Hope to hear back from +> you! +> +> Regards, +> Simon Larsen +> +> ------------------------------ +> From: simon333_333 at hotmail.com +> To: monodevelop-devel-list at lists.ximian.com +> Subject: GSoC project +> Date: Sun, 15 Mar 2015 00:03:09 +0100 +> +> Hello, +> +> I am Simon Larsen, currently I am studying Software Engineering (B.Sc) at +> the Southern University Denmark. I hope to participate in this years GSoC +> program and have found the Mono project to be very interesting. I've used +> both the Monodevelop IDE and the Mono runtime to build applications through +> Unity3d and Xamarin Studio and would love to contribute to this development +> environment. +> +> I've looked through the GSoC project ideas list and I'm interested in +> working with the Monodevelop IDE. Particularly I'm interested in working on +> the "MD Class Diagrams" project as this is very relevant to my current +> semester (UP and UML) and I've always been a fan of code generation. +> +> I'm new to the whole GSoC process, so I'm not entirely sure how to proceed +> from here? Any advice would be much appreciated. Thank you. +> +> Regards, +> Simon Larsen +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150318/958f1b46/attachment.html> ++ + + +
Hi, +How can I disable the unsupported packages `extras/JavaBinding` and +`extras/ValaBinding`<ref>https://github.com/mono/monodevelop</ref> when +I open the `monodevelop` source tree in `monodevelop` itself? + +Any help or pointers are appreciated. + +-Kalle + +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: signature.asc +Type: application/pgp-signature +Size: 484 bytes +Desc: not available +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150320/65a37c8b/attachment.pgp> ++ + + + +
Hi, + I am willing to work for improving the default arguments binding and +inline code handling of CPPSharp. I had sent a mail earlier to for working +which did not get much response. +I have submitted a proposal for this project on GSoC website. I hope the +mentor and other community members will review the proposal and guide me to +work for this project by providing reviews to help me improve my proposal +and approach to the problem.. +. +Abhinav +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20150322/1adf0438/attachment.html> ++ + + +
I would suggest opening main/Main.sln instead of the top-level workspace. + +- m + +On 20 March 2015 at 17:06, Karl-Philipp Richter <richter at richtercloud.de> wrote: +> Hi, +> How can I disable the unsupported packages `extras/JavaBinding` and +> `extras/ValaBinding`<ref>https://github.com/mono/monodevelop</ref> when +> I open the `monodevelop` source tree in `monodevelop` itself? +> +> Any help or pointers are appreciated. +> +> -Kalle +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +~ https://mhut.ch ++ + +
Starting: Wed Mar 4 12:30:10 UTC 2015
+ Ending: Thu Mar 26 20:43:57 UTC 2015
+ Messages: 10
+
+ Last message date:
+ Thu Mar 26 20:43:57 UTC 2015
+ Archived on: Thu Mar 26 20:44:21 UTC 2015
+
+
+
Starting: Wed Mar 4 12:30:10 UTC 2015
+ Ending: Thu Mar 26 20:43:57 UTC 2015
+ Messages: 10
+
+ Last message date:
+ Thu Mar 26 20:43:57 UTC 2015
+ Archived on: Thu Mar 26 20:44:21 UTC 2015
+
+
+
Starting: Wed Mar 4 12:30:10 UTC 2015
+ Ending: Thu Mar 26 20:43:57 UTC 2015
+ Messages: 10
+
+ Last message date:
+ Thu Mar 26 20:43:57 UTC 2015
+ Archived on: Thu Mar 26 20:44:21 UTC 2015
+
+
+
Starting: Wed Mar 4 12:30:10 UTC 2015
+ Ending: Thu Mar 26 20:43:57 UTC 2015
+ Messages: 10
+
+ Last message date:
+ Thu Mar 26 20:43:57 UTC 2015
+ Archived on: Thu Mar 26 20:44:21 UTC 2015
+
+
+
Starting: Wed Mar 4 12:30:10 UTC 2015
+ Ending: Thu Mar 26 20:43:57 UTC 2015
+ Messages: 10
+
+ Last message date:
+ Thu Mar 26 20:43:57 UTC 2015
+ Archived on: Thu Mar 26 20:44:21 UTC 2015
+
+
+
Hi + +When changing the mime type to a Mono.TextEditor.Document, the new +syntax highlight colors are not drawn in the TextArea, + +I followeed Mike's suggestions on this thread, "dynamically change the +MimeType on Mono.TextEditor": + +http://lists.ximian.com/pipermail/monodevelop-list/2012-February/014475.html + +So, I tried the following code: + +editor.Document.MimeType = "text/html"; +Mono.TextEditor.Highlighting.SyntaxModeService.WaitUpdate(editor.Document); +editor.Document.CommitUpdateAll(); + +But it still does nothing :-( + +Any other suggestion? + +Thanks in advance. + + Daniel + ++ + + +
Hi
+
+In which scenario are you using the text editor ? Inside monodevelop (which
+version ?) or stand alone ?
+
+In general changing the mime type should've an immediate effect. You try to
+use SyntaxModeService.GetSyntaxMode("text/html") and see if it returns
+something and try setting editor.Document.SyntaxMode manually. (but as said
+changing the mime type should do all that)
+
+Regards
+Mike
+
+On Wed, Nov 18, 2015 at 2:30 PM, Daniel Peñalba <dpenalba at codicesoftware.com
+> wrote:
+
+> Hi
+>
+> When changing the mime type to a Mono.TextEditor.Document, the new syntax
+> highlight colors are not drawn in the TextArea,
+>
+> I followeed Mike's suggestions on this thread, "dynamically change the
+> MimeType on Mono.TextEditor":
+>
+>
+> http://lists.ximian.com/pipermail/monodevelop-list/2012-February/014475.html
+>
+> So, I tried the following code:
+>
+> editor.Document.MimeType = "text/html";
+> Mono.TextEditor.Highlighting.SyntaxModeService.WaitUpdate(editor.Document);
+> editor.Document.CommitUpdateAll();
+>
+> But it still does nothing :-(
+>
+> Any other suggestion?
+>
+> Thanks in advance.
+>
+> Daniel
+>
+> _______________________________________________
+> Monodevelop-devel-list mailing list
+> Monodevelop-devel-list at lists.ximian.com
+> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20151118/87441bec/attachment.html>
+
+
+
+ Starting: Wed Nov 18 13:30:02 UTC 2015
+ Ending: Wed Nov 18 14:59:35 UTC 2015
+ Messages: 2
+
+ Last message date:
+ Wed Nov 18 14:59:35 UTC 2015
+ Archived on: Wed Nov 18 14:59:39 UTC 2015
+
+
+
Starting: Wed Nov 18 13:30:02 UTC 2015
+ Ending: Wed Nov 18 14:59:35 UTC 2015
+ Messages: 2
+
+ Last message date:
+ Wed Nov 18 14:59:35 UTC 2015
+ Archived on: Wed Nov 18 14:59:39 UTC 2015
+
+
+
Starting: Wed Nov 18 13:30:02 UTC 2015
+ Ending: Wed Nov 18 14:59:35 UTC 2015
+ Messages: 2
+
+ Last message date:
+ Wed Nov 18 14:59:35 UTC 2015
+ Archived on: Wed Nov 18 14:59:39 UTC 2015
+
+
+
Starting: Wed Nov 18 13:30:02 UTC 2015
+ Ending: Wed Nov 18 14:59:35 UTC 2015
+ Messages: 2
+
+ Last message date:
+ Wed Nov 18 14:59:35 UTC 2015
+ Archived on: Wed Nov 18 14:59:39 UTC 2015
+
+
+
Starting: Wed Nov 18 13:30:02 UTC 2015
+ Ending: Wed Nov 18 14:59:35 UTC 2015
+ Messages: 2
+
+ Last message date:
+ Wed Nov 18 14:59:35 UTC 2015
+ Archived on: Wed Nov 18 14:59:39 UTC 2015
+
+
+
Hi, + +You can find some info here: +https://mhut.ch/journal/2016/04/19/msbuild_code_generation_vs2015 +https://mhut.ch/journal/2015/06/30/build_time_code_generation_msbuild + +- mikayla + +On 13 May 2016 at 16:07, Hartwig, Tyler C <Tyler_Hartwig at baylor.edu> wrote: +> Hi Miguel, +> +> +> I am wanting to mimic what Android studio does. The idea is when a user +> saves a .rs file, or makes a change (similar to the iOS UI designer) there +> would be a separate generated C# file which is updated and aids in using the +> renderscript file. Currently you'd need to use Android studio to create a +> java lib separately and bind this in the C# project. This would be tedious +> for changing your renderscript code. +> +> +> Thanks, +> +> Tyler Hartwig +> +> ________________________________ +> From: Miguel de Icaza <miguel at xamarin.com> +> Sent: Friday, May 13, 2016 2:42:52 PM +> To: Hartwig, Tyler C +> Cc: monodevelop-devel-list at lists.ximian.com +> Subject: Re: [Monodevelop-devel] Custom RenderScript C# Code Generation +> Project +> +> To give you some guidance, can you describe what is the user experience that +> you are aiming for? +> +> On Monday, May 9, 2016, Hartwig, Tyler C <Tyler_Hartwig at baylor.edu> wrote: +>> +>> Hi all, +>> +>> +>> This summer I am going to be working with Custom RenderScripts with +>> Xamarin and Android. Currently Xamarin Studio does not support generating +>> the C# helper classes for consuming user-defined RenderScripts. I would like +>> to contribute to Xamarin Studio and implement this. Is it possible to get a +>> mentor or guidance on something like this? +>> +>> +>> Thanks, +>> +>> Tyler Hartwig +> +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.ximian.com +> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list +> + + + +-- +~ https://mhut.ch ++ + +
Starting: Mon Aug 1 19:00:58 UTC 2016
+ Ending: Mon Aug 1 19:00:58 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Aug 1 19:00:58 UTC 2016
+ Archived on: Mon Aug 1 19:01:22 UTC 2016
+
+
+
Starting: Mon Aug 1 19:00:58 UTC 2016
+ Ending: Mon Aug 1 19:00:58 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Aug 1 19:00:58 UTC 2016
+ Archived on: Mon Aug 1 19:01:22 UTC 2016
+
+
+
Starting: Mon Aug 1 19:00:58 UTC 2016
+ Ending: Mon Aug 1 19:00:58 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Aug 1 19:00:58 UTC 2016
+ Archived on: Mon Aug 1 19:01:22 UTC 2016
+
+
+
Starting: Mon Aug 1 19:00:58 UTC 2016
+ Ending: Mon Aug 1 19:00:58 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Aug 1 19:00:58 UTC 2016
+ Archived on: Mon Aug 1 19:01:22 UTC 2016
+
+
+
Starting: Mon Aug 1 19:00:58 UTC 2016
+ Ending: Mon Aug 1 19:00:58 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Aug 1 19:00:58 UTC 2016
+ Archived on: Mon Aug 1 19:01:22 UTC 2016
+
+
+
Hi All, + +I'm Samurdhi Karunarathne and I'm a student at the Faculty of Engineering, +University of Peradeniya, Sri Lanka. I came across this project to improve +the auto-detection system of MonoDevelop on the GSoC 2016 ideas page. I am +quite interested in this project since I was engaged in a project which +dealt with natural language detection last year. It's an automated text and +call handling app called SiRA for Android that interprets small text +messages and automatically replies to them( +https://github.com/samurdhilbk/SiRA). So I'm quite excited to engage in it +for GSoC 2016. Hoping for some guidelines to get myself started. + +Regards, +Samurdhi +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20160223/15288d24/attachment.html> ++ + +
Starting: Mon Feb 22 23:44:15 UTC 2016
+ Ending: Mon Feb 22 23:44:15 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Feb 22 23:44:15 UTC 2016
+ Archived on: Mon Feb 22 23:44:18 UTC 2016
+
+
+
Starting: Mon Feb 22 23:44:15 UTC 2016
+ Ending: Mon Feb 22 23:44:15 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Feb 22 23:44:15 UTC 2016
+ Archived on: Mon Feb 22 23:44:18 UTC 2016
+
+
+
Starting: Mon Feb 22 23:44:15 UTC 2016
+ Ending: Mon Feb 22 23:44:15 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Feb 22 23:44:15 UTC 2016
+ Archived on: Mon Feb 22 23:44:18 UTC 2016
+
+
+
Starting: Mon Feb 22 23:44:15 UTC 2016
+ Ending: Mon Feb 22 23:44:15 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Feb 22 23:44:15 UTC 2016
+ Archived on: Mon Feb 22 23:44:18 UTC 2016
+
+
+
Starting: Mon Feb 22 23:44:15 UTC 2016
+ Ending: Mon Feb 22 23:44:15 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Mon Feb 22 23:44:15 UTC 2016
+ Archived on: Mon Feb 22 23:44:18 UTC 2016
+
+
+
I cannot find an example of a pad written in XWT. Is it possible to build +controls inside a pad using XWT framework? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20160128/24adec3c/attachment.html> ++ + +
Starting: Thu Jan 28 18:38:11 UTC 2016
+ Ending: Thu Jan 28 18:38:11 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Thu Jan 28 18:38:11 UTC 2016
+ Archived on: Thu Jan 28 18:38:14 UTC 2016
+
+
+
Starting: Thu Jan 28 18:38:11 UTC 2016
+ Ending: Thu Jan 28 18:38:11 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Thu Jan 28 18:38:11 UTC 2016
+ Archived on: Thu Jan 28 18:38:14 UTC 2016
+
+
+
Starting: Thu Jan 28 18:38:11 UTC 2016
+ Ending: Thu Jan 28 18:38:11 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Thu Jan 28 18:38:11 UTC 2016
+ Archived on: Thu Jan 28 18:38:14 UTC 2016
+
+
+
Starting: Thu Jan 28 18:38:11 UTC 2016
+ Ending: Thu Jan 28 18:38:11 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Thu Jan 28 18:38:11 UTC 2016
+ Archived on: Thu Jan 28 18:38:14 UTC 2016
+
+
+
Starting: Thu Jan 28 18:38:11 UTC 2016
+ Ending: Thu Jan 28 18:38:11 UTC 2016
+ Messages: 1
+
+ Last message date:
+ Thu Jan 28 18:38:11 UTC 2016
+ Archived on: Thu Jan 28 18:38:14 UTC 2016
+
+
+
Hi all, + + +This summer I am going to be working with Custom RenderScripts with Xamarin and Android. Currently Xamarin Studio does not support generating the C# helper classes for consuming user-defined RenderScripts. I would like to contribute to Xamarin Studio and implement this. Is it possible to get a mentor or guidance on something like this? + + +Thanks, + +Tyler Hartwig +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20160509/ed604f31/attachment.html> ++ + + +
To give you some guidance, can you describe what is the user experience +that you are aiming for? + +On Monday, May 9, 2016, Hartwig, Tyler C <Tyler_Hartwig at baylor.edu> wrote: + +> Hi all, +> +> +> This summer I am going to be working with Custom RenderScripts with +> Xamarin and Android. Currently Xamarin Studio does not support generating +> the C# helper classes for consuming user-defined RenderScripts. I would +> like to contribute to Xamarin Studio and implement this. Is it possible to +> get a mentor or guidance on something like this? +> +> +> Thanks, +> +> Tyler Hartwig +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20160513/06ced9e7/attachment.html> ++ + + +
Hi Miguel, + + +I am wanting to mimic what Android studio does. The idea is when a user saves a .rs file, or makes a change (similar to the iOS UI designer) there would be a separate generated C# file which is updated and aids in using the renderscript file. Currently you'd need to use Android studio to create a java lib separately and bind this in the C# project. This would be tedious for changing your renderscript code. + + +Thanks, + +Tyler Hartwig + +________________________________ +From: Miguel de Icaza <miguel at xamarin.com> +Sent: Friday, May 13, 2016 2:42:52 PM +To: Hartwig, Tyler C +Cc: monodevelop-devel-list at lists.ximian.com +Subject: Re: [Monodevelop-devel] Custom RenderScript C# Code Generation Project + +To give you some guidance, can you describe what is the user experience that you are aiming for? + +On Monday, May 9, 2016, Hartwig, Tyler C <Tyler_Hartwig at baylor.edu<mailto:Tyler_Hartwig at baylor.edu>> wrote: + +Hi all, + + +This summer I am going to be working with Custom RenderScripts with Xamarin and Android. Currently Xamarin Studio does not support generating the C# helper classes for consuming user-defined RenderScripts. I would like to contribute to Xamarin Studio and implement this. Is it possible to get a mentor or guidance on something like this? + + +Thanks, + +Tyler Hartwig +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20160513/18b01046/attachment.html> ++ + +
Starting: Mon May 9 20:59:31 UTC 2016
+ Ending: Fri May 13 20:07:44 UTC 2016
+ Messages: 3
+
+ Last message date:
+ Fri May 13 20:07:44 UTC 2016
+ Archived on: Fri May 13 20:41:21 UTC 2016
+
+
+
Starting: Mon May 9 20:59:31 UTC 2016
+ Ending: Fri May 13 20:07:44 UTC 2016
+ Messages: 3
+
+ Last message date:
+ Fri May 13 20:07:44 UTC 2016
+ Archived on: Fri May 13 20:41:21 UTC 2016
+
+
+
Starting: Mon May 9 20:59:31 UTC 2016
+ Ending: Fri May 13 20:07:44 UTC 2016
+ Messages: 3
+
+ Last message date:
+ Fri May 13 20:07:44 UTC 2016
+ Archived on: Fri May 13 20:41:21 UTC 2016
+
+
+
Starting: Mon May 9 20:59:31 UTC 2016
+ Ending: Fri May 13 20:07:44 UTC 2016
+ Messages: 3
+
+ Last message date:
+ Fri May 13 20:07:44 UTC 2016
+ Archived on: Fri May 13 20:41:21 UTC 2016
+
+
+
Starting: Mon May 9 20:59:31 UTC 2016
+ Ending: Fri May 13 20:07:44 UTC 2016
+ Messages: 3
+
+ Last message date:
+ Fri May 13 20:07:44 UTC 2016
+ Archived on: Fri May 13 20:41:21 UTC 2016
+
+
+
Hi, + +I’m Michael Viveros and I’m interested in the Improve Auto-Documentation System project <http://www.mono-project.com/community/google-summer-of-code/projects/#improve-auto-documentation-system> for GSOC 2017 (mentor Mike Krüger). + +Below are some questions. + +1. What is an example of generating "documentation comments based on the member types and naming conventions"? +I read over the monodoc page <http://www.mono-project.com/docs/tools+libraries/tools/monodoc/generating-documentation/> about Generating Documentation but that was more about extracting documentation from code comments as opposed to actually generating documentation. + +For example, maybe the auto-documentation system would take in something like `int addNumbers(int x, int y)` and produce “this function adds two integers”. +The output gets the “adds” part as a verb from the method stub and it gets the “two integers”part from the parameters to the method. + +2. Where is the source code for the auto-documentation addin? + +3. Do you have any initial ideas for how to use NLP to improve the auto-documentation system? +I know this is the main topic of the project but I just wanted to know if anyone has looked into it yet so I could have a starting point for my proposal. +I saw on the Mono GSOC Trello board <https://trello.com/c/XncDuYUx/31-improve-auto-documentation-system> a link to Recurrent neural networks <http://karpathy.github.io/2015/05/21/rnn-effectiveness/> and it looked like they could be used to train a model to generate documentation after feeding it in sample methods. + +Michael +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.dot.net/pipermail/monodevelop-devel-list/attachments/20170319/d48efd48/attachment.html> ++ + + +
Hi, + +The source code of the existing addin is at +https://github.com/mono/monodevelop/tree/master/main/src/addins/MonoDevelop.DocFood + +It uses some heuristics and the .NET naming conventions to stub out +doc comments. You can try it out in the existing version of +MonoDevelop / Xamarin Studio / VS for Mac. + +For example, it generated this doc comment based simply on the .NET +conventions for use of the word "Is" in property names: + +/// <summary> +/// Gets a value indicating whether this <see cref="T:TestClass"/> is hidden. +/// </summary> +/// <value><c>true</c> if is hidden; otherwise, <c>false</c>.</value> +public bool IsHidden { get; } + +The project is simply to generate _better_ doc comments, by whatever +means you choose. In particular, there are a few cases where the +heuristics can break down and generate some pretty silly results. + +- mikayla + +On 19 March 2017 at 11:02, Michael Viveros <michaelviveros at gmail.com> wrote: +> Hi, +> +> I’m Michael Viveros and I’m interested in the Improve Auto-Documentation +> System project for GSOC 2017 (mentor Mike Krüger). +> +> Below are some questions. +> +> 1. What is an example of generating "documentation comments based on the +> member types and naming conventions"? +> I read over the monodoc page about Generating Documentation but that was +> more about extracting documentation from code comments as opposed to +> actually generating documentation. +> +> For example, maybe the auto-documentation system would take in something +> like `int addNumbers(int x, int y)` and produce “this function adds two +> integers”. +> The output gets the “adds” part as a verb from the method stub and it gets +> the “two integers”part from the parameters to the method. +> +> 2. Where is the source code for the auto-documentation addin? +> +> 3. Do you have any initial ideas for how to use NLP to improve the +> auto-documentation system? +> I know this is the main topic of the project but I just wanted to know if +> anyone has looked into it yet so I could have a starting point for my +> proposal. +> I saw on the Mono GSOC Trello board a link to Recurrent neural networks and +> it looked like they could be used to train a model to generate documentation +> after feeding it in sample methods. +> +> Michael +> +> _______________________________________________ +> Monodevelop-devel-list mailing list +> Monodevelop-devel-list at lists.dot.net +> http://lists.dot.net/mailman/listinfo/monodevelop-devel-list +> + + + +-- +~ https://mhut.ch ++ + +
Starting: Sun Mar 19 15:02:01 UTC 2017
+ Ending: Wed Mar 22 22:18:47 UTC 2017
+ Messages: 2
+
+ Last message date:
+ Wed Mar 22 22:18:47 UTC 2017
+ Archived on: Wed Mar 22 22:19:10 UTC 2017
+
+
+
Starting: Sun Mar 19 15:02:01 UTC 2017
+ Ending: Wed Mar 22 22:18:47 UTC 2017
+ Messages: 2
+
+ Last message date:
+ Wed Mar 22 22:18:47 UTC 2017
+ Archived on: Wed Mar 22 22:19:10 UTC 2017
+
+
+
Starting: Sun Mar 19 15:02:01 UTC 2017
+ Ending: Wed Mar 22 22:18:47 UTC 2017
+ Messages: 2
+
+ Last message date:
+ Wed Mar 22 22:18:47 UTC 2017
+ Archived on: Wed Mar 22 22:19:10 UTC 2017
+
+
+
Starting: Sun Mar 19 15:02:01 UTC 2017
+ Ending: Wed Mar 22 22:18:47 UTC 2017
+ Messages: 2
+
+ Last message date:
+ Wed Mar 22 22:18:47 UTC 2017
+ Archived on: Wed Mar 22 22:19:10 UTC 2017
+
+
+
Starting: Sun Mar 19 15:02:01 UTC 2017
+ Ending: Wed Mar 22 22:18:47 UTC 2017
+ Messages: 2
+
+ Last message date:
+ Wed Mar 22 22:18:47 UTC 2017
+ Archived on: Wed Mar 22 22:19:10 UTC 2017
+
+
+
Hello, + + Please be advised that this list, along with all other lists at lists.dot.net, is being retired, effective immediately. Archives of all lists will be kept for historical purposes. + + Thank you for your contribution to lists.dot.net! + + -The Xamarin Team at Microsoft ++ + + +
Hello, + + Please be advised that this list, along with all other lists at lists.dot.net, is being retired, effective immediately. Archives of all lists will be kept for historical purposes. + + Thank you for your contribution to lists.dot.net! + + -The Xamarin Team at Microsoft ++ + +
Starting: Tue May 22 17:22:29 UTC 2018
+ Ending: Tue May 22 17:23:29 UTC 2018
+ Messages: 2
+
+ Last message date:
+ Tue May 22 17:23:29 UTC 2018
+ Archived on: Tue May 22 17:23:31 UTC 2018
+
+
+
Starting: Tue May 22 17:22:29 UTC 2018
+ Ending: Tue May 22 17:23:29 UTC 2018
+ Messages: 2
+
+ Last message date:
+ Tue May 22 17:23:29 UTC 2018
+ Archived on: Tue May 22 17:23:31 UTC 2018
+
+
+
Starting: Tue May 22 17:22:29 UTC 2018
+ Ending: Tue May 22 17:23:29 UTC 2018
+ Messages: 2
+
+ Last message date:
+ Tue May 22 17:23:29 UTC 2018
+ Archived on: Tue May 22 17:23:31 UTC 2018
+
+
+
Starting: Tue May 22 17:22:29 UTC 2018
+ Ending: Tue May 22 17:23:29 UTC 2018
+ Messages: 2
+
+ Last message date:
+ Tue May 22 17:23:29 UTC 2018
+ Archived on: Tue May 22 17:23:31 UTC 2018
+
+
+
Starting: Tue May 22 17:22:29 UTC 2018
+ Ending: Tue May 22 17:23:29 UTC 2018
+ Messages: 2
+
+ Last message date:
+ Tue May 22 17:23:29 UTC 2018
+ Archived on: Tue May 22 17:23:31 UTC 2018
+
+
+
fileName
+- /// fileName
+- /// fileName
+- /// fileName
+- /// IDotNetLanguageBinding interface is the base interface
+- /// of all language bindings avaiable.
+- /// IDotNetLanguageBinding interface is the base interface
+- /// of all language bindings avaiable.
+- ///