Hey, Nice resume.
On Mon, 2006-10-30 at 20:08 -0600, Jonathan Pobst wrote: ... > - Mono Not Supported / Implemented rules > > Another great idea I heard was creating something to analyze assemblies > for things that are not supported in Mono yet. Most likely this would > be a part of Gendarme (if it runs on Windows?). You should take the time to check out Gendarme from SVN. It's worth it and, by looking at the file names, would quickly answer your question. <spoiler>The .sln and .csproj files in Gendarme SVN (and source tarball) aren't fakes</spoiler> > Some portability rules would be: > - Calling methods that do not exist in Mono (useful for seeing what > 2.0 features you use that mono does not have yet) > - Calling methods that are marked with [MonoTODO] > - Calling methods that throw a NotSupportedException This is (well should be) all the same rule. We need to extract those information in a file (e.g. once by Mono release) which would be easy using (again) Cecil. Then have a (Gendarme) rule to check all (e.g. direct, virtual, interfaces...) calls made by an assembly against the file. Obviously you can run Gendarme (or a custom runner) with a single rule on a set of assemblies (e.g. all assemblies in a solution) but it may be more complex to implement for web projects (e.g. aspx pages). > Ideally, this would exist in the above VS plugin. At the very least, it > should produce a report listing the errors. This is exactly what Gendarme does (see my blog in my signature for a, albeit old, sample). It's also one of the reason to re-use Gendarme for this task. > More advanced, and if > possible, some sort of integration to take you directly to places in > your source code, or mark them as warnings on compile. This has been discussed in the mono-devel mailing list, look for subject with "Gendarme" inside, as this is a new feature (mdb/pdb support) being implemented in Cecil. ... > I think one of the most important things I came away from the meeting is > Miguel's sincere commitment to courting Windows developers for Mono. > However, I think there are roughly zero (?) Windows developers on the > Novell team, Thanks. I (and a few others) will take that as a compliment ;-) Not that I ever considered myself a "insert any registered trademark" developer but I admit I still have the 2 *pre-release* volumes of "Microsoft Win32 Application Programming Interfaces". OTOH I don't recall all the OS names I've written software for... (embedded systems are great for 404) Anyway it does prove that Windows developers can learn new tricks too ;-) > so they don't really know the way Windows developers work > and how they expect things to work. Keeping with Pareto's rule, I guess this is part your 20% wrong, 80% of the time (which is, obviously, an abuse of language ;-) Knowing the way, or expectations, is one thing but making it a "perfect fit" is quite another. This gets even less trivial with limited man-power and other priorities in Mono (and that's not limited to Novell!). I think we should be looking at an intermediate (do I dare say "good enough" ?) step(s) - which are much less obvious that a "perfect" solution would be. > They were very actively seeking > feedback from Windows developers. The above is a start. If you're keeping a list (which I guess should be in the wiki) then please add the "[EMAIL PROTECTED]@$# cygwin build dependency" to build Mono and execute it's test suite. > Please be sure to add yours! Yes, please do! -- Sebastien Pouliot <[EMAIL PROTECTED]> Blog: http://pages.infinit.net/ctech/ _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list