[Mono-dev] Disable checks for obfuscated assemblies?
Is it possible to disable monos IL checks? The assembly runs perfectly fine on windows but is stopped on mono because of obfuscation like br 2 pop 2: -- View this message in context: http://mono.1490590.n4.nabble.com/Disable-checks-for-obfuscated-assemblies-tp3431772p3431772.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Performance issue with DataTable.Load on large data sets
Hi mono-devers! I'm currently working on a rather large webproject, where we are using a combination of mono 2.10.1 and MySQL. Over the past week, I have observed that loading large datasets (5000+ rows) from mysql into a DataTable takes a very long time. It's done somewhat like this: code comm.CommandText = query; comm.CommandTimeout = MySQLConnection.timeout; MySqlDataReader reader = (MySqlDataReader)comm.ExecuteReader(); DataTable dt = new DataTable(); dt.Load(reader); // - this is killing mono reader.Close(); /code I have created a small testprogram, compiled it on my linux machine and executed it. It takes 15 seconds to do such operation under mono - but on windows it takes only 0.4 seconds (with the same executable, fetching the same data). I have profiled the application on windows, and it seems that the .net framework is using specialized methods for loading data from a datareader. I have been looking through the implementation in mono, in regard to DataTable.Load, and I can see that a lot of validation and other stuff is going on, which could explain the huge difference. I'm also working on a mono log profile trace, to dig a little deeper. Would it be OK, if I tried to patch the current mono implementation to gain the same speeds as .net? The reason for asking, is that I know that I cannot contribute to Mono if I have seen the actual code in .NET (but does a profile result count as seeing the code?) Best regards, Nicklas Overgaard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Disable checks for obfuscated assemblies?
Mono has code to work around thing kind of IL shenanigans, what you're seeing is probably a trick it doesn't handle yet. Disabling it will only make things worse. If you can provide a simple obfuscated assembly that fails to run with 2.10 please file a bug report and I'll take a look. On Wed, Apr 6, 2011 at 5:49 PM, high6 pooop...@hotmail.com wrote: Is it possible to disable monos IL checks? The assembly runs perfectly fine on windows but is stopped on mono because of obfuscation like br 2 pop 2: -- View this message in context: http://mono.1490590.n4.nabble.com/Disable-checks-for-obfuscated-assemblies-tp3431772p3431772.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Performance issue with DataTable.Load on large data sets
Hi again, I now have a profile log, created with the new mono profiler. It shows, that the method EndLoadData is using up almost all of the time (16 minutes of the 17 minutes it took to create the dump). When looking in the file DbDataAdapter.cs line 355 in current GIT head, the BeginLoadData and EndLoadData methods are called for each iteration in the DataReader's data. This means that for each row we add to the DataTable, the DataSet is begin asked to enforce constraints and other stuff in the datatable. According to MSDN: http://msdn.microsoft.com/en-us/library/system.data.datatable.beginloaddata.aspx BeginLoadData Turns off notifications, index maintenance, and constraints while loading data. So would'nt it make sense to move BeginLoad.. and EndLoad.. out of the loop? Well, I'm trying it out :) Best regards, Nicklas Overgaard On Thu, 2011-04-07 at 14:58 +0200, Nicklas Overgaard wrote: Hi mono-devers! I'm currently working on a rather large webproject, where we are using a combination of mono 2.10.1 and MySQL. Over the past week, I have observed that loading large datasets (5000+ rows) from mysql into a DataTable takes a very long time. It's done somewhat like this: code comm.CommandText = query; comm.CommandTimeout = MySQLConnection.timeout; MySqlDataReader reader = (MySqlDataReader)comm.ExecuteReader(); DataTable dt = new DataTable(); dt.Load(reader); // - this is killing mono reader.Close(); /code I have created a small testprogram, compiled it on my linux machine and executed it. It takes 15 seconds to do such operation under mono - but on windows it takes only 0.4 seconds (with the same executable, fetching the same data). I have profiled the application on windows, and it seems that the .net framework is using specialized methods for loading data from a datareader. I have been looking through the implementation in mono, in regard to DataTable.Load, and I can see that a lot of validation and other stuff is going on, which could explain the huge difference. I'm also working on a mono log profile trace, to dig a little deeper. Would it be OK, if I tried to patch the current mono implementation to gain the same speeds as .net? The reason for asking, is that I know that I cannot contribute to Mono if I have seen the actual code in .NET (but does a profile result count as seeing the code?) Best regards, Nicklas Overgaard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Performance issue with DataTable.Load on large data sets
Hi again, Sorry for the spamming. Moving out the Begin and End load methods reduced DataTable.Load time to 1.7 seconds on my test machine, so we are getting there! /Nicklas On Thu, 2011-04-07 at 19:29 +0200, Nicklas Overgaard wrote: Hi again, I now have a profile log, created with the new mono profiler. It shows, that the method EndLoadData is using up almost all of the time (16 minutes of the 17 minutes it took to create the dump). When looking in the file DbDataAdapter.cs line 355 in current GIT head, the BeginLoadData and EndLoadData methods are called for each iteration in the DataReader's data. This means that for each row we add to the DataTable, the DataSet is begin asked to enforce constraints and other stuff in the datatable. According to MSDN: http://msdn.microsoft.com/en-us/library/system.data.datatable.beginloaddata.aspx BeginLoadData Turns off notifications, index maintenance, and constraints while loading data. So would'nt it make sense to move BeginLoad.. and EndLoad.. out of the loop? Well, I'm trying it out :) Best regards, Nicklas Overgaard On Thu, 2011-04-07 at 14:58 +0200, Nicklas Overgaard wrote: Hi mono-devers! I'm currently working on a rather large webproject, where we are using a combination of mono 2.10.1 and MySQL. Over the past week, I have observed that loading large datasets (5000+ rows) from mysql into a DataTable takes a very long time. It's done somewhat like this: code comm.CommandText = query; comm.CommandTimeout = MySQLConnection.timeout; MySqlDataReader reader = (MySqlDataReader)comm.ExecuteReader(); DataTable dt = new DataTable(); dt.Load(reader); // - this is killing mono reader.Close(); /code I have created a small testprogram, compiled it on my linux machine and executed it. It takes 15 seconds to do such operation under mono - but on windows it takes only 0.4 seconds (with the same executable, fetching the same data). I have profiled the application on windows, and it seems that the .net framework is using specialized methods for loading data from a datareader. I have been looking through the implementation in mono, in regard to DataTable.Load, and I can see that a lot of validation and other stuff is going on, which could explain the huge difference. I'm also working on a mono log profile trace, to dig a little deeper. Would it be OK, if I tried to patch the current mono implementation to gain the same speeds as .net? The reason for asking, is that I know that I cannot contribute to Mono if I have seen the actual code in .NET (but does a profile result count as seeing the code?) Best regards, Nicklas Overgaard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono-devel-list Digest, Vol 72, Issue 10
On 7 April 2011 05:56, Sharp Blade无厚之刃 sharper.than.bla...@gmail.com wrote: Hello! Well,since I have a lot of experience with Antlr on C#,it does not seem to be a good choice to use jay.And the makefile grammar is quiet simple,I wonder if I could write the parser by hand. Sharp Hello! Unfortunately, the Makefile grammar is not as simple as you think, and simple or not, writing parsers by hand is generally discouraged nowadays, for the simple reason of:- why re-invent the wheel? There are tools available for parser (and lexer) generation, which are tried and tested and I think you'll find you'll make more mistakes rolling your own parser, than you'll get if you use a parser generator. Also, writing an LALR, LR(1) or indeed any bottom-up parser by hand is quite challenging - even for the simplest grammars. If you really went down this route, you'd be best off writing a top-down parser, which can exponentially increase in size as a grammar increases. But, I still wouldn't recommend it, as the more you get into the grammar, the more you'll find yourself changing your parser and wishing you'd used a generator. You'll also need to construct a lexer for the Makefile - which is itself a daunting challenge. Particularly because the Makefile syntax is really quite complex (since it's heavily context-based), so you'd have trouble implementing a lexer and parser yourself. Hope this helps, -- Tom. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono-devel-list Digest, Vol 72, Issue 10
Just be aware that not all grammars can express all languages, and so not all parser-generators can parse all languages. GNU Make does not use a parser-generator to parse Makefiles - perhaps there's a good reason. You say that a lexer for Make would be very context-dependent, and most parse-generators don't handle that well at all. Generally, parsing is a pretty simple problem in the first place and I think that parser-generators often introduce more problems than they solve. Why can't you nest block comments in C? Because of a limited lexer-generator. Do a quick google for a Make grammar for Antlr or Jay and see if anyone else has managed it. Regards, Chris Seaton On 7 Apr 2011, at 19:30, Tom Spink wrote: On 7 April 2011 05:56, Sharp Blade无厚之刃 sharper.than.bla...@gmail.com wrote: Hello! Well,since I have a lot of experience with Antlr on C#,it does not seem to be a good choice to use jay.And the makefile grammar is quiet simple,I wonder if I could write the parser by hand. Sharp Hello! Unfortunately, the Makefile grammar is not as simple as you think, and simple or not, writing parsers by hand is generally discouraged nowadays, for the simple reason of:- why re-invent the wheel? There are tools available for parser (and lexer) generation, which are tried and tested and I think you'll find you'll make more mistakes rolling your own parser, than you'll get if you use a parser generator. Also, writing an LALR, LR(1) or indeed any bottom-up parser by hand is quite challenging - even for the simplest grammars. If you really went down this route, you'd be best off writing a top-down parser, which can exponentially increase in size as a grammar increases. But, I still wouldn't recommend it, as the more you get into the grammar, the more you'll find yourself changing your parser and wishing you'd used a generator. You'll also need to construct a lexer for the Makefile - which is itself a daunting challenge. Particularly because the Makefile syntax is really quite complex (since it's heavily context-based), so you'd have trouble implementing a lexer and parser yourself. Hope this helps, -- Tom. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] GSoC Application 2011 for Axiom
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.b...@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 mono...@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.b...@gmail.com 2nd Year Undergraduate | B.E. (Hons.) - Electronics Instrumentation BITS-Pilani. ___ Monodevelop-list mailing list monodevelop-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monodevelop-list -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Trouble compiling Mono on Cygwin
Hi, Thanks for the advice, but how to configure mono for an ARM build? I'm building as part of a androidmono build (https://github.com/koush/androidmono) and it seems that I have to first configure the build correctly to be able to build it with the NDK. And additionally, can Mono be directly built on Android by just using the NDK version of GCC? - Timo Heinäpurola Raccoon Interactive http://www.raccoon-interactive.com @raccoon_int -- View this message in context: http://mono.1490590.n4.nabble.com/Trouble-compiling-Mono-on-Cygwin-tp3421942p3434259.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono-devel-list Digest, Vol 72, Issue 10
2011/4/7 Chris Seaton ch...@chrisseaton.com: Just be aware that not all grammars can express all languages, and so not all parser-generators can parse all languages. GNU Make does not use a parser-generator to parse Makefiles - perhaps there's a good reason. You say that a lexer for Make would be very context-dependent, and most parse-generators don't handle that well at all. Good points! But, there are tools available that make context-sensitive lexing and parsing much easier - flex and bison, for example. Generally, parsing is a pretty simple problem in the first place and I think that parser-generators often introduce more problems than they solve. Why can't you nest block comments in C? Because of a limited lexer-generator. Well - okay... but you can use a better lexer generator. Writing lexers and parsers by hand does have it's merits - for both academic and practical reasons (e.g. at University, I thoroughly enjoyed making a finite-state-machine based lexer, and writing an LALR parsing table by hand), but when tools that are purpose built for solving a complex problem - because in fact parsing /is/ a complex problem - then those tools should be utilised as an aid to reduce the amount of time you have to spend debugging and altering your own implementation. The reason I say that parsing /is/ a complex problem is because parsing isn't just about matching input to a specified grammar, it's also about building a data structure describing what the input is representing, and giving feedback when the input does not conform to syntax. Taking into account this, although it seems that all you're trying to do is recognise input, it's actually quite complicated when you start having to deal with and process this input. Do a quick google for a Make grammar for Antlr or Jay and see if anyone else has managed it. I presume you mention this because there aren't any. Touche, Chris. ;-) Regards, Chris Seaton -- Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono-devel-list Digest, Vol 72, Issue 10
I'd just like to add, the Coco/R parser generator actually helps in both problems here: It has the CONTEXT keyword, LL(1) conflict resolvers (and lets you peek in the token stream), and finally, actually lets you define nested comments :) Regards, Alex 2011/4/7 Tom Spink tsp...@gmail.com: 2011/4/7 Chris Seaton ch...@chrisseaton.com: Just be aware that not all grammars can express all languages, and so not all parser-generators can parse all languages. GNU Make does not use a parser-generator to parse Makefiles - perhaps there's a good reason. You say that a lexer for Make would be very context-dependent, and most parse-generators don't handle that well at all. Good points! But, there are tools available that make context-sensitive lexing and parsing much easier - flex and bison, for example. Generally, parsing is a pretty simple problem in the first place and I think that parser-generators often introduce more problems than they solve. Why can't you nest block comments in C? Because of a limited lexer-generator. Well - okay... but you can use a better lexer generator. Writing lexers and parsers by hand does have it's merits - for both academic and practical reasons (e.g. at University, I thoroughly enjoyed making a finite-state-machine based lexer, and writing an LALR parsing table by hand), but when tools that are purpose built for solving a complex problem - because in fact parsing /is/ a complex problem - then those tools should be utilised as an aid to reduce the amount of time you have to spend debugging and altering your own implementation. The reason I say that parsing /is/ a complex problem is because parsing isn't just about matching input to a specified grammar, it's also about building a data structure describing what the input is representing, and giving feedback when the input does not conform to syntax. Taking into account this, although it seems that all you're trying to do is recognise input, it's actually quite complicated when you start having to deal with and process this input. Do a quick google for a Make grammar for Antlr or Jay and see if anyone else has managed it. I presume you mention this because there aren't any. Touche, Chris. ;-) Regards, Chris Seaton -- Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monodis implemented with Cecil
Hello all, Thanks for your feedback. Miguel: Are you also planning on adding the table dumping features? They are not necessary if we keep monodis around. I will probably work on this last, but I hope to get around to it, yeah. That way we can remove monodis and the burden of maintaining it, instead of just adding to the maintenance burden. Jb: As I wrote in my earlier mail, there's a lot of code that can be lifted from: Thanks, I've seen that and I am referring to it. My goal of being character-for-character the same as monodis means that I'm not using your existing code as is. ildasm should be in mcs/tools, ilasm is in mcs just for historical reasons. Also I don't think we should require python for the tests, a simple Makefile should be enough. Thanks, I've moved it to tools, and I've rewritten by tests in Make. Marek: Another drawback is that it's very easy to crash/SIGSEGV monodis with broken metadata/MSIL. If the new version could be made more robust that would be great too. Hopefully it will be. When I get around to it, I could get hold of some broken files and perhaps implement some kind of error recovery logic, but that's for the future. Regards, Chris Seaton ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Are constructors class methods or not?
When I disassemble a simple hello world C# program using monodis I have these two lines .custom instance void class [mscorlib]System.Runtime.CompilerServices.RuntimeCompatibilityAttribute::'.ctor'() = ( IL_0001: call instance void object::'.ctor'() In the former the constructor is marked as class, in the latter it is not. Which is correct? Or does the place it is being used lead to the difference? Are constructor methods class methods or not? Regards, Chris Seaton___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
