Re: [Mono-dev] Bugs
Hi, I've got a bit of a sticky error. I don't have any native code in this particular application, but what I'm seeing is after some time of running (this is a server-side app running via upstart on Ubuntu), I get this nasty error. * Assertion at metadata.c:965, condition `idx t-rows' not met This looks like our runtime bug during exception stack trace construction. You could work around it by not calling ToString but it's possible that the original exception has same cause as the crash during ToString. Any kind of repro would be helpful to track this down. Thanks Marek Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Reflection.MonoMethodInfo.get_parameter_info (intptr,System.Reflection.MemberInfo) 0x at System.Reflection.MonoMethodInfo.GetParametersInfo (intptr,System.Reflection.MemberInfo) 0x00011 at System.Reflection.MonoMethod.GetParametersInternal () 0x00013 at System.Exception.GetFullNameForStackTrace (System.Text.StringBuilder,System.Reflection.MethodBase) 0x0002d at System.Exception.AddFrames (System.Text.StringBuilder,string,string,System.Diagnostics.StackTrace) 0x00174 at System.Exception.get_StackTrace () 0x00158 at System.Exception.ToString () 0x000fc at (wrapper runtime-invoke) Module.runtime_invoke_object__this__ (object,intptr,intptr,intptr) 0x Native stacktrace: mono() [0x4b20bc] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fd05dd3b340] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7fd05d99ccc9] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7fd05d9a00d8] mono() [0x6294f9] mono() [0x629707] mono() [0x629856] mono(mono_metadata_decode_row+0xd3) [0x55d503] mono(mono_method_get_param_names+0x224) [0x546ec4] mono() [0x5c5294] [0x416b4e28] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Anyone have any suggestions on what might be causing this or something I can do to avoid it? -- Jerod Venema *Frozen Mountain Software* 919-300-5141 (United States) 604-227-2453 (Canada) 888-379-6686 (Toll Free) www.frozenmountain.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] Is operator behavior with mono version
Hi, I am facing one problem while using 'is' operator with mono.When i run my test with mono version(2.10.8) it works fine but when i run with mono (3.2.8) it caught under infinite loop. This looks like a regression in some of version between but I can still reproduce it with Mono master. Could you fill a bug report? Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ReferenceSource of System.Text.UnicodeEncoding breaks System.Data.Odbc.OdbcDataReader.GetColumn(int)
Hi, We use the attached patch for Mono 4.0.1 which changes the implementation of System.Data.Odbc.OdbcDataReader.GetColumn(int) to make it work with either implementation of System.Text.UnicodeEncoding.GetString. Could you please send a pull request with the change? Does it make sense to bring in patches like this or will System.Data.Odbc be replaced by ReferenceSource in the (near) future? That's not very likely, reference sources code has quite few hard windows dependencies and I don't think we'll replace it or at least not very soon. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Strange enum issue
Hi Neale, ves_icall_System_Enum_GetEnumValuesAndNames.3229: 0. field=System_Runtime value=0 ves_icall_System_Enum_GetEnumValuesAndNames.3229: 1. field=System_Runtime_InteropServices_WindowsRuntime value=16777216 ves_icall_System_Enum_GetEnumValuesAndNames.3229: 2. field=System_ObjectModel value=33554432 ves_icall_System_Enum_GetEnumValuesAndNames.3229: 3. field=System_Runtime_WindowsRuntime value=50331648 ves_icall_System_Enum_GetEnumValuesAndNames.3229: 4. field=System_Runtime_WindowsRuntime_UI_Xaml value=67108864 ves_icall_System_Enum_GetEnumValuesAndNames.3229: 5. field=Count value=83886080 Note 16777216 is hex 1000. Now to find out how that value gets placed there and to do some byte swapping on it. You are probably looking for https://github.com/mono/mono/blob/master/mono/metadata/icall.c#L2961. There has been no endian changes there for years but due to different codepath this is now hit more often before. Marek P.S. I am wondering if it would be worth it to create a routine or more in icall.c to do the byte swap for 2/4/8 byte integers rather than coding up clumsy stuff in managed code. On 3/10/15, 3:01 PM, Robert Jordan robe...@gmx.net wrote: There was a recent commit which added MS' reference source Enum support to Mono: https://github.com/mono/mono/commit/65dba595eaea2c871d1f72fbdc04f6440350af 96 Maybe it's an endian-related issue. ___ 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] System.Net and SynchronizationContext
Hi, I have discovered that the Mono implementation of WebClient doesn't behave as described in this MSDN article: https://msdn.microsoft.com/en-us/magazine/gg598924.aspx Specifically all Async methods don't capure the current SynchronizationContext to later run the event handlers on it. I can probably provide some patches but I don't know if there are plans to replace that code with the one MS open sourced. The code was replaced. Mono 4.0 and anything newer will have same code as .net. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problems with 3.12.0
Hi, After a long gap, we have upgraded our unchanged working ASP code from 3.0.6 to 3.12.0. However we get a new exception which we can't understand or find reference to in Google. Would anybody know what might be wrong? This kind of error messages mean you are referencing same assembly (assemblies with same assembly name) from different locations. In this case it's System.Data.DataSetExtensions. This could be mono bug or you simply having duplicate entries in web.config. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Plans for new types/methods in .NET 4.6
Hi, Hey, I'm wondering what the current plan for new types and methods (like System.Array.Empty) in .NET 4.6 is? Will Mono stick to the net_4_5 profile or will a new profile be created? I think you could use same profile but different define as we'll probably not include such changes in our mobile profiles before the public API is stable. On the other hand I am not sure it's worth the effort. I expect Microsoft to release update to their reference sources as soon as they release official beta but that's only my expectation. It'd be best to get confirmation what are their plans with reference sources going forward. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] End line/column information in symbol files
Hello, I am seeing the starting line and column numbers, just not the ending ones. You are saying that the compiler is not providing these values? The place exists where to put these values in the symbol file but they always seem to be -1. Correct, it's one of not implemented compiler features. Is there a reason this is not supported? Would a patch to fix this to welcomed? Yes, why not? Thanks Marek *From:* Zoltan Varga [mailto:var...@gmail.com] *Sent:* Monday, January 5, 2015 4:23 PM *To:* Zinkevicius, Matt *Cc:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] End line/column information in symbol files Hi, There is a tool named mdbdump in mcs/class/lib/net_4_5/mdbdumb.exe which can be used to dump the contents of .mdb files. In this case, mcs currently doesn't generate column numbers, so sdb cannot return them. Zoltan On Mon, Jan 5, 2015 at 6:12 PM, Zinkevicius, Matt matt.zinkevic...@hp.com wrote: Hello, When debugging our program on Linux with Mono 3.10, I’ve noticed that the source code sequence points that the soft debugger gives never include valid end line or end column numbers. They are always set to -1. Is this because the mono compiler doesn’t include these values in the mdb symbol files? Perhaps I’m doing something wrong when invoking the soft debugger library? Thanks, Matt Zinkevicius ___ 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] Heads up: Elimination of the 2.0 and 4.0 profiles
Hello Sergey, I'll try to reformulate my question. Do I understand correctly that in new version of mono it will not be possible to compile assembly for Mono/.NET 3.5 target and use the compiled assembly in Unity 3D (because of referencing different corlib libraries in Unity (corlib 2.0) and compiled assembly (if corlib 2.0 is removed))? That's correct. You cannot compile code using (targeting) 4.x profile and run it using 2.0 mscorlib. Due to simple reason that 4.x introduces new apis which are not available in 2.0. Good example is Monitor.Enter (object, ref bool) method. Marek On Fri, 2014-10-24 at 12:22 -0400, Miguel de Icaza wrote: Hey, There is no 3.5 profile. There are currently only 2.0, 4.0 (reference assemblies), 4.5 and the mobile versions (mobile, android, ios). What you think is 3.5 are assemblies introduced at 3.5, but we ship with the above 4.0/4.5 ones. On Fri, Oct 24, 2014 at 12:33 AM, xplicit s...@ngs.ru wrote: Miguel de Icaza-6 wrote We are going to remove the build for the .NET 2.0 APIs from Mono which are currently provided for bug/feature-compatibility for .NET 2.0 applications. Will you save .NET 3.5 or you are going to remove corlib 2.0 at all? Removing 2.0 profile is a good thing, but without support of .NET 3.5 it would be difficult to work with Unity 3D at least. -- View this message in context: http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664345.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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] a set of tests to find out the difference between .Net and Mono implementation
Hi, i tried it myself, and find out several issues, which are mainly against Mono 3.10 from development tree. Thanks for the analysis more comments inline. 1. GC thought GC.Collect() does not guarantee all the inaccessible objects are finalized and reclaimed, .Net implementation usually be able to delete all the inaccessible objects. impacts, delegate_pinning_test, it make sure the delegate / event in .net will release the object after itself has been released. weak_pointer_test, weak_pointer is a simple wrapper of WeakReference, which is strong-typed. event_disposer_test, event_disposer is a strong-typed pointer, which provide disposing event when disposing. lifetime_binder_test, lifetime_binder is a collection to avoid the object to be finalized. Strictly speaking if something is not guaranteed then even Mono cannot guarantee it. GC is tricky and we have some holes in our WeakReference implementation and it'd be helpful if you can provide reliable test case. 2. char.GetHashCode() the implementation of simhash / himming_distance uses char.GetHashCode(), according to Mono implementation, this function returns char as int, and cause the similarity of two adjusted characters to be small. while .Net implementation seems having some magic. the impact is hamming_distance of ABC and DEF is 1, instead of a number in range [0, 1). impacts, simhash_test This is just different implementation detail. You should not rely on exact GetHashCode result. 3. System.Threading.Thread.Priority is not implemented impacts thread_timing_test, thread_timing is an IDisposable to temporarily adjust thread priority. There is a pull request for this in the queue but it hasn't been merged yet. 4. Environment.TickCount() is not consistent with DateTime.Now i.e. DateTime.Now increased 1000 milliseconds, Environment.TickCount() increased only 950 milliseconds. though the definition of Environment.TickCount() and DateTime.Now do not guarantee they are the same, .Net implementation does not have such large difference. impacts, event_comb_waitfor_test, the difference itself is not consistent, so the failures may not happen always. This could be consider as minor bug, please fill bug report with repro. 5. Encoding.GetEncoding(string) may not be able to return correct Encoding instance, even the EncodingInfo is from Encoding.GetEncodings() impacts, web_extension_test, according to msdn, the Encoding.GetEncoding(EncodingInfo.WebName) should always return a valid Encoding instance. Sound like a bug to me. Could you fill bug report with repro for this. 6. Process.Start does not be able to execute the binary if it does not have execute permission in Windows platform, the file by default has execute permission, while in Linux, it's not. i do not think this is a Mono issue, but will it be better to help set the execute permission if Process.Start calls a non-executable file? or at least provide a more friendly exception, current the error message is 'Cannot find the specified file', which is confusing. We cannot just set the execution permission but reporting more useful exception is good idea. Could you fill bug/enhancement report for this. there are several other issues related to the Thread.ManagedThreadId(), or thread scheduling, which may more depend on OS, and cause the cases not be able to run. i am continually working on them. hope i can find out more differences later. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] Failing to compile on Linux in last few days - %(Culture)
Hellom (cross posting to Mono Development list because it seems to be a problem in Mono git master) This is indeed mono master issue which should be fixed in latest mono master. Thanks for reporting Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Roslyn on OS X
Hi, You've mostly done it. We have a bug in xbuild which causes this on second build. Clean all intermediate obj folders and run xbuild again. Unfortunately, that didn’t do it for me. I tried a few different cleaning options, but I’m still getting the same error: (*) rm -fr Binaries xbuild … (*) rm Binaries/Debug/Microsoft.CodeAnalysis.* xbuild … # This is the assembly containing the internal classes we’re trying to access; Release configs have the same issue (*) xbuild /target:clean Src/Compilers/CSharp/csc/csc.csproj xbuild … None of these do what I suggested. You need to delete folders like Src/Compilers/CSharp/Desktop/obj/ Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Roslyn on OS X
Hello, I’m relatively new to Mono and attempting to build Roslyn on OS X (10.9), but haven’t made much progress. I’m hoping I’m missing something obvious. So here’s what I’ve done: (1) Noting that a recent build from master is required, build mono from source (from https://github.com/mono/mono): a. Install MDK (I’ve also tried wiping the MDK and using make get-monolite-latest; both ways successfully build mono and fail in the same way building Roslyn) b. git clone https://github.com/mono/mono.git c. ./configure --prefix-/usr/local/mono.git --enable-nls=no d. make make install e. add /usr/local/mono.git/bin to front of $PATH (2) Build Roslyn (from https://github.com/mono/roslyn): a. git clone https://github.com/mono/roslyn.git c. xbuild Src/Compilers/CSharp/csc/csc.csproj d. Get error about missing PCL reference assembiles e. Copy assemblies from a Windows box to /usr/local/mono.git/lib/mono/xbuild-frameworks/.NETPortable f. xbuild Src/Compilers/CSharp/csc/csc.csproj g. Get errors relating to csc2.exe h. Apply “Manual changes needed” from README.md Microsoft.Net.ToolsetCompilers.props, which must have been fetched during the last xbuild. i. xbuild Src/Compilers/CSharp/csc/csc.csproj j. 30 Warning, 5896 Errors You've mostly done it. We have a bug in xbuild which causes this on second build. Clean all intermediate obj folders and run xbuild again. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Hi System.xml.parse error in compiling mono
Hello, *I successfully make install the mono code in ubuntu 12.04* *when i do the same steps in ubuntu 14.04 i get this error* Bootstrap compiler: Mono C# compiler version 3.2.8.0 MCS [build] System.Xml.dll System.Xml.XPath/Parser.jay(12,0): error CS1525: Unexpected symbol `using' This is weird error. Did you try to build in parallel ? Also showing what is actually in file System.Xml.XPath/Parser.jay around reports lines would help too. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Hi System.xml.parse error in compiling mono
Hello, No i didn't build in parallel. just a simple make command with no parameter. when i ran the Make command for the first time i got an error said Perl XML:Parser wasn't installed. so i installed XML::Parser by apt-get libexpat1-dev then i ran into this error. That's probably it. Try to clean your code and rebuild again. Marek On Wed, Jul 16, 2014 at 8:26 PM, Marek Safar marek.sa...@gmail.com wrote: Hello, *I successfully make install the mono code in ubuntu 12.04* *when i do the same steps in ubuntu 14.04 i get this error* Bootstrap compiler: Mono C# compiler version 3.2.8.0 MCS [build] System.Xml.dll System.Xml.XPath/Parser.jay(12,0): error CS1525: Unexpected symbol `using' This is weird error. Did you try to build in parallel ? Also showing what is actually in file System.Xml.XPath/Parser.jay around reports lines would help too. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Editing mono in IDE?
Hello, You would most likely like to create your own solution from existing sources... You don't have to. Opening a csproj file you are interested in will generate sln file for you when you open it in VS/XS and will have all dependencies you need. This is for the case you have working master mono and want to write/debug code in XS/VS. Marek These days I've been working on Microsoft.Build.dll these days with my own solution and projects [*1] because the centralized msvc/scripts/net_4_5.sln is quite useless (too big). And I can't think of any generalized way of generating appropriate set of projects for each classlib assembly. [*1] https://github.com/atsushieno/mono/blob/msbuilddll2/msvc/ scripts/net_4_5_msbuild.sln Atsushi Eno Hüning, Christian wrote: Hi, I wondered if there is a way to efficiently and effectively develop mono with an IDE like Xamarin Studio / Visual Studio? I couldn’t find a central .sln file or something (did find quite a lot .sln files, but none that seemed to be THE solution file, if there is any). Is that even intended? Cheers Christian ___ 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] Patch for NetworkInformation on OSX
Hi,
Please sent suggested change/fix as a git pull request.
Thanks
Marek
I just ran into a problem regarding the usage of
System.Net.NetworkInformation.NetworkInterface.cs on OSX. Especially the
Properties „SupportsMulticast“ and „OperationalStatus“ were not implemented
properly (always returning false / unknown). So I just fixed that.
On http://mono-project.com/Contributing#Ways_to_Contribute it’s written
to post patches to this mailing list, so I do :)
My solution basically works by extracting the ifa_flags via getifaddrs and
storing the flags in the MacOsNetworkInterface class inside of
NetworkInterface.cs. I can then implement the two properties like so:
public override OperationalStatus OperationalStatus {
get {
if(((MacOsInterfaceFlags)_ifa_flags MacOsInterfaceFlags.
IFF_UP) == MacOsInterfaceFlags.IFF_UP){
return OperationalStatus.Up;
}
return OperationalStatus.Unknown;
}
}
public override bool SupportsMulticast {
get {
return ((MacOsInterfaceFlags)_ifa_flags
MacOsInterfaceFlags.IFF_MULTICAST) == MacOsInterfaceFlags.IFF_MULTICAST;
}
}
MacOsInterfaceFlags is an Enum residing in
MacOsNetworkInterfaceMarshal.cs:
internal enum MacOsInterfaceFlags {
IFF_UP = 0x1,/* interface is up */
IFF_BROADCAST = 0x2,/* broadcast address valid */
IFF_DEBUG = 0x4,/* turn on debugging */
IFF_LOOPBACK = 0x8,/* is a loopback net */
IFF_POINTOPOINT = 0x10,/* interface is point-to-point link
*/
IFF_NOTRAILERS = 0x20,/* avoid use of trailers */
IFF_RUNNING = 0x40,/* resources allocated */
IFF_NOARP = 0x80,/* no address resolution protocol */
IFF_PROMISC = 0x100,/* receive all packets */
IFF_ALLMULTI = 0x200,/* receive all multicast packets */
IFF_OACTIVE = 0x400,/* transmission in progress */
IFF_SIMPLEX = 0x800,/* can't hear own transmissions */
IFF_LINK0 = 0x1000,/* per link layer defined bit */
IFF_LINK1 = 0x2000,/* per link layer defined bit */
IFF_LINK2 = 0x4000,/* per link layer defined bit */
IFF_MULTICAST = 0x8000/* supports multicast */
}
So is this a valid solution? It works well in my project and the
corresponding test cases.
Cheers,
Christian
---
Christian Hüning, BSc.
Fakultät Technik und Informatik, Department Informatik
Berliner Tor 7
20099 Hamburg
Tel.: +49 40 / 42875 - 8436
Mobil: +49 40 / 180 55 44 5
Web: http://www.mars-group.org
___
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] AssemblyFileVersion
Hi, When compiling an assembly , the File version info of the file is set by reading the AssemblyInfo.AssemblyFileVersion attribute. On mono it seems to be reading the AssemblyVersion attribute. At first look this looks like mono bug. Please fill a bug report. Thanks Marek As a test, set these 2 attributes into an assembly: [assembly: AssemblyVersion(2011.04.0.0)] [assembly : AssemblyFileVersion(2011.02.0.0)] Then build it and try this: Assembly executingAssembly = Assembly.GetAssembly(typeof(Runtime)); FileVersionInfo fvi = FileVersionInfo.GetVersionInfo(executingAssembly.Location); string version1 = fvi.FileVersion; Console.WriteLine(version: +version1); In our test it was returning 2011.04.0.0 but on Windows it would return 2011.02.0.0 and right clicking on the files in Windows Explorer would show the same things. Could Linux be putting this in a different area? Neale ___ 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] mcs warnings
Hello,
You can report it as a bug.
Thanks
Marek
On Mon, Mar 24, 2014 at 6:20 AM, Greg Young gregoryyou...@gmail.com wrote:
Is this worth reporting as a bug or do you think the people working on mcs
already know about it since its happening in the mono sources? :)
On Fri, Mar 21, 2014 at 5:35 PM, Marek Safar marek.sa...@gmail.comwrote:
Hello,
Also should the line number be pointing to the actual line in the
source? In this case it was pointing at a }catch{} (on the first one). I
don't see how index is not being used there
Yes, in this case the warning location is definitely wrong.
Regards,
Marek
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mcs warnings
Hello,
Also should the line number be pointing to the actual line in the source?
In this case it was pointing at a }catch{} (on the first one). I don't see
how index is not being used there
Yes, in this case the warning location is definitely wrong.
Regards,
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [GSoC-2014] Optimizing Switch statements
Hello, I am interested in doing the C# Compiler switch statement enhancements for this years Google Summer of code. The last couple of days I have been going through the sourcecode for the C# compiler and the JIT compiler. The main question I have is where the focus of this project should be. Is it in the source - IL translation or in the IL - machinecode translation? It does not really matter both transformations need optimization. You can choose whichever you would like to work on or even mixture both. Regards, Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Anyone taking care of TPL dataflow?
Hi, I know Mono is getting its second life due to the brilliant Mobile idea (Android/iOS). But it seems that the bcl/server stuff needs some love now. We bumped into an issue of TPL dataflow library and submitted an issue here: https://bugzilla.xamarin.com/show_bug.cgi?id=16940 TPL Dataflow is no longer part of .NET framework hence nobody really maintains the code. If you need it or your project depends on TPL Dataflow you are better using the version Microsoft made available on nuget. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition
Hi,
This API is broken by design and it's not clear what it should really do.
It'd probably be better to check with EF devs whether they really intended
to use it and for what purposes. Even for naive implementation please write
unit test and check whether it passes on .net
http://stackoverflow.com/questions/2494421/how-does-assemblyname-referencematchesdefinition-work
Marek
On Tue, Aug 27, 2013 at 5:29 PM, mlgo mlint...@sinenomine.net wrote:
According to
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx
The following is what is expected to be returned from
ReferenceMatchesDefinition.
Returns a value indicating whether two assembly names are the same. The
comparison is based on the simple assembly names.
This seems naïve but below is a tentative implementation of that. Any
ideas?
public static bool ReferenceMatchesDefinition (AssemblyName reference,
AssemblyName definition)
{
if (reference == null)
throw new ArgumentNullException
(reference);
if (definition == null)
throw new ArgumentNullException
(definition);
if (reference.Name != definition.Name)
return false;
return reference.Name.Equals(definition.Name);
}
--
View this message in context:
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683.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] How to skip building .net 2.0/3.x and build only 4.x?
Hi,
One one question please: what is the opposite parameter? Neither of
--without-net20 and --with-net20=no I tried worked for me.
The syntax is mostly in the form --with-{profile}=yes,no. For more details
use configure --help
Marek
2013/6/16 Marek Safar marek.sa...@gmail.com
Hi,
How can I configure the build from source to do not build .NET 2.0/3.5
but say include MonoDroid?
Explore --with-{profile-name} configure options.
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to skip building .net 2.0/3.x and build only 4.x?
Hi,
How can I configure the build from source to do not build .NET 2.0/3.5 but
say include MonoDroid?
Explore --with-{profile-name} configure options.
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UTF8 encoding/decoding
Hi, I've discovered the directory /mono/mcs/class/corlib/Test/System.Text just now ... I never noticed it before, sorry. The problem with my tests is that they are written for comparing its output against the output of an existing reference runtime (in this moment ms-net). I will take a look to the existing UTF8EncodingTest.cs (and others), and I will try to add more test cases to cover the bugs that I reported and some other problems that I saw in the old implementation. As you can imagine I'm not very familiarized with the Mono sources, and I haven't found a mono tests' policy (how tests are integrated, best practices, etc), how the test mechanism is used (other description more specific for the mono case than than http://nunit.com/ web page), ... So any help like docs, links... will be useful :D You can find general Mono tests page here http://www.mono-project.com/Test_Suite Marek On Mon, Apr 29, 2013 at 6:48 PM, Marek Safar marek.sa...@gmail.comwrote: Hi Gerardo, This is very good Mono improvement. Could change your tests to fit mono nunit test style. It should not be too hard if you need guidance let me know or look how it's done for other mono parts. Secondly to make the review and merge easier for us could you send pull request with your changes. Thanks Marek I am Gerardo García Peña and I'm new in this list. Some months ago started working with mono in a project which demands a very precise manipulation of UTF8 (and other encodings) streams. When I started to write code I observed that the mono UTF8 implementation is very buggy, while the MS.NET implementation is quite good. Then I started to isolate the bugs and filled some bugs in the Ximian's bugzilla [1] [2]. They're still there and unfixed, but I think they are important: an incompatibility in the text codec subsystems virtually affects any application that need portability between Microsoft and Mono platforms. Specially from the data integrity point of view, and in some cases availability security issues (indexes and counters reported by the conversion methods and throwed exceptions could make apps running on the Mono environment to enter into infinite loops, making apps running on the mono runtime vulnerable to DoS attacks). The bugs are still there (unresolved), and during this time I have found some more, so I decided to start patching the UTF8 libraries (and in the future, if this patch is accepted, I will continue working on other buggy codec that appears). The patch that I propose is an important modification of the file /mono/mcs/class/corlib/System.Text/UTF8Encoding.cs and some minor changes in other generic classes in System.Text. The targets of my patch are the following: - give a complete and good quality UTF8 coder decoder implementation, - at least it is as much efficient as the old implementation, - better error handling and quick resync when bad sequences are found, - fix the index field in the Fallback exceptions (it is a key feature if one program want to handle strings with errors), - refactorize and make code more maintainable, - full compatibility with the .NET implementation (behaviour is exactly the same in front of bad and good sequences), - complete some pending or incomplete features (MonoTODO) like Encoder::FallbackException::IsUnknownSurrogate() or use of BOM preambles. Please note that in spite of presenting a full-compatible implementation of this codec with the Microsoft implementation, my changes are not based on Microsoft's work, and they are totally written from scratch. I have not reversed any code and the behaviour of my patches has been tunned using an extensive and exhaustive test case. My test case uses several public UTF8 test cases and one specific and giant UTF16 test case built automatically. The test case must be executed first on the Mono runtime environment and once again on the Microsoft runtime. The output of the test case are two directories (one for mono, another for net) documenting the output of (and exceptions thrown) the Convert() method. Once both executions are finished, it should not exist any difference between the two output directories. The test case is focused only on the Convert() method because it allows to test any variation of the input. My implementation (and probably Microsoft's too) is based on two coder/decoder functions that are called by all the other public methods. Because that reason the best way to test both implementations is using the method that exposes more directly the internal decoder/encoder. I posted the changes and my test suite in a github branch, and I also have attached them to this mail (if you want to test it quickly without doing any git operation): - mono branch with my patches https://github.com/killabytenow/mono - test suite https://github.com/killabytenow/mono-System.Text.UTF8Encoding-test To run
Re: [Mono-dev] UTF8 encoding/decoding
Hi Gerardo, This is very good Mono improvement. Could change your tests to fit mono nunit test style. It should not be too hard if you need guidance let me know or look how it's done for other mono parts. Secondly to make the review and merge easier for us could you send pull request with your changes. Thanks Marek I am Gerardo García Peña and I'm new in this list. Some months ago started working with mono in a project which demands a very precise manipulation of UTF8 (and other encodings) streams. When I started to write code I observed that the mono UTF8 implementation is very buggy, while the MS.NET implementation is quite good. Then I started to isolate the bugs and filled some bugs in the Ximian's bugzilla [1] [2]. They're still there and unfixed, but I think they are important: an incompatibility in the text codec subsystems virtually affects any application that need portability between Microsoft and Mono platforms. Specially from the data integrity point of view, and in some cases availability security issues (indexes and counters reported by the conversion methods and throwed exceptions could make apps running on the Mono environment to enter into infinite loops, making apps running on the mono runtime vulnerable to DoS attacks). The bugs are still there (unresolved), and during this time I have found some more, so I decided to start patching the UTF8 libraries (and in the future, if this patch is accepted, I will continue working on other buggy codec that appears). The patch that I propose is an important modification of the file /mono/mcs/class/corlib/System.Text/UTF8Encoding.cs and some minor changes in other generic classes in System.Text. The targets of my patch are the following: - give a complete and good quality UTF8 coder decoder implementation, - at least it is as much efficient as the old implementation, - better error handling and quick resync when bad sequences are found, - fix the index field in the Fallback exceptions (it is a key feature if one program want to handle strings with errors), - refactorize and make code more maintainable, - full compatibility with the .NET implementation (behaviour is exactly the same in front of bad and good sequences), - complete some pending or incomplete features (MonoTODO) like Encoder::FallbackException::IsUnknownSurrogate() or use of BOM preambles. Please note that in spite of presenting a full-compatible implementation of this codec with the Microsoft implementation, my changes are not based on Microsoft's work, and they are totally written from scratch. I have not reversed any code and the behaviour of my patches has been tunned using an extensive and exhaustive test case. My test case uses several public UTF8 test cases and one specific and giant UTF16 test case built automatically. The test case must be executed first on the Mono runtime environment and once again on the Microsoft runtime. The output of the test case are two directories (one for mono, another for net) documenting the output of (and exceptions thrown) the Convert() method. Once both executions are finished, it should not exist any difference between the two output directories. The test case is focused only on the Convert() method because it allows to test any variation of the input. My implementation (and probably Microsoft's too) is based on two coder/decoder functions that are called by all the other public methods. Because that reason the best way to test both implementations is using the method that exposes more directly the internal decoder/encoder. I posted the changes and my test suite in a github branch, and I also have attached them to this mail (if you want to test it quickly without doing any git operation): - mono branch with my patches https://github.com/killabytenow/mono - test suite https://github.com/killabytenow/mono-System.Text.UTF8Encoding-test To run the test suite, run the makefile and then execute the program convert.exe in the two platforms. You'll get a 'cnvout-mono' and 'cnvout-other' directories which will contain the output of each test run. Once they have finished run the 'mkdiff.sh' shell script. This script will make a 'cnvout-diff' directory, which should be empty if all files are equal. I know that it is an important patch because it affects the corlib libraries which are critical for the Mono runtime. If you have any question or note about the code, or if I can do anything to improve this patch, I will be glad to help. Thanks in advance, Gerardo García Peña [1] 10692 https://bugzilla.xamarin.com/show_bug.cgi?id=10692 [2] 10697 https://bugzilla.xamarin.com/show_bug.cgi?id=10697 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list
Re: [Mono-dev] msgpack-cli causes internal compiler error on 3.x?
Hi, I cannot but I only tried xbuild MsgPack.mono.sln which does not cause internal error but does not compile successfully either. If you can fill a bug report with steps you are doing I can try to build it again. Marek On Fri, Feb 22, 2013 at 6:44 PM, Brandon Perry bperry.volat...@gmail.comwrote: Hi, can anyone reproduce and error I am getting with mono 3.x in compiling the following github repo: https://github.com/msgpack/msgpack-cli I get an internal compiler error. This works with 2.10. -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ 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] Entity Framework - new issues
Hi, Could you fill a bug report for the issue. Thanks Marek On Sat, Feb 9, 2013 at 3:30 PM, Олег olegm-developm...@yandex.ru wrote: Many thanks to Atsushi Eno for a solution for previous defect in System.Xml. But there are new issues with EF. I tried to create simplest console application (file Test.zip attached to this letter, contains MonoDevelop project), it fails with following exception: System.ArgumentException: An element with the same key already exists in the dictionary. at System.Collections.Generic.**Dictionary`2[System.String,**System.Object].Add (System.String key, System.Object value) [0x0007e] in /usr/ports/lang/mono/work/**mono-3.0.3/mcs/class/corlib/** System.Collections.Generic/**Dictionary.cs:423 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.** TypeUsageBuilder.**HandleNullableAttribute (System.Xml.XmlReader reader) [0x00015] in /usr/ports/lang/mono/work/**mono-3.0.3/external/** entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**TypeUsageBuilder.cs:605 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.** TypeUsageBuilder.**InternalHandleAttribute (System.Xml.XmlReader reader) [0x00010] in /usr/ports/lang/mono/work/**mono-3.0.3/external/** entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**TypeUsageBuilder.cs:300 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.** TypeUsageBuilder.**HandleAttribute (System.Xml.XmlReader reader) [0x0] in /usr/ports/lang/mono/work/**mono-3.0.3/external/** entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**TypeUsageBuilder.cs:291 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.** StructuredProperty.**HandleAttribute (System.Xml.XmlReader reader) [0x00040] in /usr/ports/lang/mono/work/**mono-3.0.3/external/** entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**StructuredProperty.cs:227 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**SchemaElement.ParseAttribute (System.Xml.XmlReader reader) [0x0006a] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**SchemaElement.cs:592 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**SchemaElement.Parse (System.Xml.XmlReader reader) [0x0001d] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**SchemaElement.cs:193 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.** StructuredType.**HandlePropertyElement (System.Xml.XmlReader reader) [0x7] in /usr/ports/lang/mono/work/**mono-3.0.3/external/** entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**StructuredType.cs:387 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**StructuredType.HandleElement (System.Xml.XmlReader reader) [0x0001f] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**StructuredType.cs:267 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**SchemaEntityType.HandleElement (System.Xml.XmlReader reader) [0x0] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**ItemType.cs:198 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**SchemaElement.ParseElement (System.Xml.XmlReader reader) [0x0002c] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**SchemaElement.cs:746 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**SchemaElement.Parse (System.Xml.XmlReader reader) [0x000d0] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**SchemaElement.cs:220 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**Schema.HandleEntityTypeElement (System.Xml.XmlReader reader) [0x7] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**Schema.cs:1023 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**Schema.HandleElement (System.Xml.XmlReader reader) [0x0001f] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**Schema.cs:592 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**SchemaElement.ParseElement (System.Xml.XmlReader reader) [0x0002c] in /usr/ports/lang/mono/work/** mono-3.0.3/external/**entityframework/src/**EntityFramework/Core/** EntityModel/SchemaObjectModel/**SchemaElement.cs:746 at System.Data.Entity.Core.**EntityModel.SchemaObjectModel.**SchemaElement.Parse (System.Xml.XmlReader reader) [0x000d0] in
Re: [Mono-dev] Distinction between generic type and instance type
Hey, As a follow-up to my question about the way in which Mono handles generic types (see Handling of generics by Mono compiler on January 15), please do you know whether the distinction being made by Mono between a generic type and the instance type corresponding to it is only of relevance to the compiler, or does it have real implications for an application-level developer? (This relates to the comment Marek Safar made in the previous thread, namely: Compiled generic types always exist at least as open (generic) types, usually TypeContainer(s) but can at the same time exist as InflatedTypeSpec too when accesses from within the type.) That's correct but all this applies to mcs internals only. Mono runtime handles this differently. I'm working on a static analysis tool, and it would arguably be quite helpful to blur the distinction between the two for the purposes of writing queries over the source code (i.e. query writers shouldn't necessarily have to know about compiler internals), but I'm loath to make that change if there's a practical difference between the two that's relevant even outside the compiler. That's should be possible when you don't need to define generic types or handle expressions like var a = typeof (Foo,,,); Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.CSharp.Evaluator: x.GetType Bug?
Hi,
This is regarding Mono 3.0.3: Mono.CSharp.Evaluator
When I instantiate an Evaluator and then then evaluate following input:
var context = new CompilerContext(new CompilerSettings(), new
ConsoleReportPrinter());
var evaluator = new Evaluator(context);
evaluator.DescribeTypeExpressions = true;
object result = null;
bool set = false;
evaluator.Evaluate(class A{ public int X;}, out result, out set);
//this works
evaluator.Evaluate(var a = new A();a.GetType();, out result, out
set);
Console.WriteLine(result);
//this doesnt work
evaluator.Evaluate(var a = new A();, out result, out set);
//Error here:
evaluator.Evaluate(a.GetType();, out result, out set);
Console.WriteLine(result);
I get an error in the second last line:
System.IO.FileNotFoundException: Could not load file or assembly 'eval-0,
Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' o
r one of its dependencies. The system cannot find the file specified.
File name: 'eval-0, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
at InteractiveExpressionClass.Host(Object $retval)
at Mono.CSharp.Evaluator.Evaluate(String input, Object result, Boolean
result_set)
at MonoEval.Program.Main(String[] args) in
C:\Users\Luke\Dev\Samples\MonoEval\Program.cs:line 30
This seems to happen only when run on .NET. Could you fill a bug report.
Thanks
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Question about LiftedBinaryOperator in mcs source
Hi,
I'm working on project that uses Mono as its C# parser. It uses the AST
that comes from calling Resolve.
I'm having trouble understanding what happens to LiftedBinaryOperator.
In particular, this code seems strange:
if (left_orig is NullLiteral) {
left = right;
One of the effects of this assignment is that, if a user operator is
involved, the corresponding UserOperatorCall will have right as both of
its arguments.
If I replace the assignment with, say:
left = LiftedNull.Create (right.Type, left.Location);
I get parse errors.
It seems that at least one of the goals is to trigger a check for left !=
right.
This is kind of trick to simplify handling of comparisons which always end
up with constant result but are allowed by the language.
For example
bool b = false;
var x = null != b;
If you found a case where this breaks valid C# code, please fill a bug
report with C# example.
Another mysterious thing I noticed is that, in the AST for code like:
int i;
int ?oi;
i + oi;
the AST is a LiftedBinaryOperator where right is an Unwrap with type int
(this part I understand), while left is an EmptyCast with type int?,
which I find mysterious. It looks like the EmitOperator call casts it
back to its original type:
if (left.Type.IsNullableType) {
l = NullableInfo.GetUnderlyingType (left.Type);
left = EmptyCast.Create (left, l);
}
Correct, that's just another wrap so we can use same emit operator routine.
It would be great if you could explains how all this works.
All nullable handling is tricky especially cases involving user operators
mainly because C# spec is light on details about nullable handling and does
not match csc implementation quite few cases.
Sorry for late reply I somehow missed your email.
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Handling of generics by Mono compiler
Hi Stuart,
Please do you know if there is a one-to-one correspondence between
InflatedTypeSpec in the Mono code and C# constructed types? Or is
InflatedTypeSpec used for both generic and constructed types?
They are pretty closely matched. Compiled generic types always exist at
least as open (generic) types, usually TypeContainer(s) but can at the same
time exist as InflatedTypeSpec too when accesses from within the type. For
example in the following sample enum parent container will be
InflatedTypeSpec.
class CT
{
public enum E
{
}
}
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Beginner's bugs
Hi, You can browse all bugs here https://bugzilla.xamarin.com/describecomponents.cgi split by category. We don't have beginners tag or anything similar but you can work on any bugs you think matches your experience. Marek On Thu, Jan 10, 2013 at 5:17 AM, OS tripathi.shash...@gmail.com wrote: Is there a way where I could check out bugs that are for beginners? Or any place where the bugs are catalogued or something? Shashvat ___ 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] Upcoming pull request; Generating csproj files and compiling Mono in Visual Studio
Hi J-M, I finally followed up on some upgrades to the build process generating the visual studio csproj and solution files. For reference prior discussions are at http://lists.ximian.com/pipermail/mono-devel-list/2012-May/thread.html#38852 . I have a fork at https://github.com/jmp75/mono/commits/master. Before submitting my first pull request I'd like to double-check where the bar is. Mostly, I do not know who uses these .csproj files and for what; if you do, I'd like to hear advice/comment from you. The work looks good just few comments. Match names of sln files to Mono profiles (e.g net_2_0, net_4_5, etc). I don't think we need to include basic or build profiles, they are bootstrap profiles which are not needed when you have VS/MD installed. Please check Mono coding guidelines before submitting the pull request. Marek Current status is: - Generates distinct project files for successive versions of assemblies whose build is iterative (circular dependencies) - Projects reference other projects, in preference to referencing relative paths to a DLL. - Most assemblies then compile in visual studio, BUT there are some issues yet to weed out (mcs-build, some unit test assemblies) - Multiple solutions files are generated, with different scopes (the full one has ~300 projects) - Tested on a Windows+cygwin+Mono+MS.NET setup. Not yet run on Linux. I'll polish what I can, meaning documentation and hopefully figure out some compilation issues, but don't want to raise the bar and delay the pull request unnecessarily. Regards, J-M ___ 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] DLR with Mono.CSharp.Evaluator: The predefined type Microsoft.CSharp.RuntimeBinder.Binder' is not defined or imported
Hello,
I'm currently implementing REPL functionality in my app that embeds mono
runtime (3.0.1), and I've encountered some issues when evaluating code that
contains dynamic invocation.
For example, consider this simple dynamic class:
public class Foo : DynamicObject {
public override bool TryGetMember(GetMemberBinder binder, out object
result) {
result = 5;
return true;
}
}
The following Evaluator initialization:
var settings = new CompilerSettings();
var printer = new ConsoleReportPrinter();
eval = new Evaluator(new CompilerContext(settings, printer));
eval.ReferenceAssembly(typeof(REPL).Assembly);
eval.Run(using System;);
And the evaluation
dynamic f = new Program.Foo();
f.Whatever;
gives following error:
error CS0518: The predefined type Microsoft.CSharp.RuntimeBinder.Binder'
is not defined or imported (1,4): error CS1969: Dynamic operation cannot be
compiled without `Microsoft.CSharp.dll' assembly reference.
This is strange, are you embedding correct runtime version (4.0) ?
I have tried to cook full sample based on your code and it works without
error for me as a standalone app.
using System;
using System.Dynamic;
using Mono.CSharp;
public class Foo : DynamicObject
{
public override bool TryGetMember(GetMemberBinder binder, out object
result)
{
Console.WriteLine(called);
result = 5;
return true;
}
}
class C
{
public static void Main()
{
var settings = new CompilerSettings();
var printer = new ConsoleReportPrinter();
var eval = new Evaluator(new CompilerContext(settings, printer));
eval.ReferenceAssembly(typeof(Foo).Assembly);
eval.Run(using System;);
eval.Run(dynamic f = new Foo(););
eval.Run(f.Whatever;);
}
}
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent of csc /link for mcs (COM interop)?
Hi Peter, In investigating the ability to drop in mcs as a replacement for csc (currently trying out mono 2.11.4), I've run into issues in compiling things from some Microsoft C# 4.0 code samples that involve COM interop. Here's a simplified example: COM has never been high on our priority (quite opposite to be honest), you can expect few more issues to be discovered. This leads me to two questions: (1) Is there any plan to support an equivalent of csc -link (aka /link)? Or is there some other work-around I don't know about? You are the first one using this feature and reporting it. Please fill a bug report. (2) It appears that the is not supported by the C# language+cannot be assigned to issue a bug. Is that correct? (If so, I can file it.) Correct, this looks like compiler bug. And a bonus question: (3) For general C# language issues where csc willingly compiles something that is arguably not adherent to the language spec, but mcs rejects it, does the Mono team consider that a valid bug or enhancement request? (Is there a duplicate Microsoft's bugs mode for mcs?) It really depends on the specific case. We trying to be highly compatible with csc even in cases where C# standart is ambiguous or unclear. There are few special cases where we are compatible with C# standard but not with Microsoft C# compiler but they are all very special corner cases. Regards, Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch to make mcs bundlable
Hi,
Patch applied.
Thanks
Marek
I'm trying to bundle an application that uses the mcs, that's why I need to
bundle mcs as well.
When I tried I've get the following exception:
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentOutOfRangeException:
Cannot be negative.
at System.String.Substring (Int32 startIndex, Int32 length) [0x0] in
filename unknown:0
at Mono.CSharp.StaticLoader..ctor (Mono.CSharp.StaticImporter importer,
Mono.CSharp.CompilerContext compiler) [0x0] in filename unknown:0
at Mono.CSharp.Driver.Compile () [0x0] in filename unknown:0
at Mono.CSharp.Driver.Main (System.String[] args) [0x0] in filename
unknown:0
The code causing this is in ikvm.cs:
var corlib_path = Path.GetDirectoryName (typeof
(object).Assembly.Location);
string fx_path = corlib_path.Substring (0, corlib_path.LastIndexOf
(Path.DirectorySeparatorChar));
if (compiler.Settings.StdLib) { ...
When mcs is bundled corlib_path is empty and this cause the
corlib_path.LastIndexOf to return a -1, but
both corlib_path and fx_path are used only inside the if
(compiler.Setting.StdLib) then branch.
I then tried moving the two lines inside the if body. Passed -nostdlib to
the mcs during compilation and an explicit reference to a mscorlib.dll
file.
In this way everything works.
I thus propose to apply the patch that I'm attaching.
Just out of curiosity, is there any reason for which fx_path is not
computed
using Path.GetDirectoryName(corlib_path) (and for which corlib_path is not
checked to be not empty)?
Thanks.
--Tommaso
mcs.nostdlib.patch
http://mono.1490590.n4.nabble.com/file/n4657173/mcs.nostdlib.patch
--
View this message in context:
http://mono.1490590.n4.nabble.com/patch-to-make-mcs-bundlable-tp4657173.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] EF fails with NotImplementedException
Hi,
I was trying to run a simple EF app using Mono 3.0 on Mac OS X but I got
this error:
Please fill a bug report. Our System.Data implementation which EF relies on
is not complete and there will be issues like yours where underlying code
is not implemented or buggy.
Thanks
Marek
Unhandled Exception:
System.NotImplementedException: The requested feature is not implemented.
at System.Data.Common.DbProviderFactories.GetFactory
(System.Data.Common.DbConnection connection) [0x0] in filename
unknown:0
at System.Data.Entity.Core.Common.DbProviderServices.GetProviderFactory
(System.Data.Common.DbConnection connection) [0x0] in filename
unknown:0
at
System.Data.Entity.Utilities.DbConnectionExtensions.GetProviderInvariantName
(System.Data.Common.DbConnection connection) [0x0] in filename
unknown:0
at System.Data.Entity.Internal.InternalConnection.get_ProviderName ()
[0x0] in filename unknown:0
at System.Data.Entity.Internal.LazyInternalContext.get_ProviderName ()
[0x0] in filename unknown:0
at System.Data.Entity.Internal.DefaultModelCacheKeyFactory.Create
(System.Data.Entity.DbContext context) [0x0] in filename unknown:0
at System.Data.Entity.Internal.LazyInternalContext.InitializeContext ()
[0x0] in filename unknown:0
at System.Data.Entity.Internal.InternalContext.Initialize () [0x0]
in filename unknown:0
at
System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType
(System.Type entityType) [0x0] in filename unknown:0
at
System.Data.Entity.Internal.Linq.InternalSet`1[EFTest.User].Initialize ()
[0x0] in filename unknown:0
at
System.Data.Entity.Internal.Linq.InternalSet`1[EFTest.User].GetEnumerator
() [0x0] in filename unknown:0
at
System.Data.Entity.Infrastructure.DbQuery`1[EFTest.User].System.Collections.Generic.IEnumerableTResult.GetEnumerator
() [0x0] in filename unknown:0
at EFTest.MainClass.Main (System.String[] args) [0x00018] in
/Users/eddy/Projects/EFTest/EFTest/Main.cs:46
The same code works fine with MS .NET.
// Main.cs
using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Common;
using System.Data.Entity;
using System.Data.SqlClient;
using System.Linq;
namespace EFTest
{
[Table(user)]
class User
{
[Key]
[Column(user_id)]
public string UserName { get; set; }
public string Password { get; set; }
public string Email { get; set; }
public override string ToString ()
{
return string.Format ({0}, {1}, {2}, UserName, Password, Email);
}
}
class SampleEntities : DbContext
{
public SampleEntities (DbConnection conn) : base(conn, true)
{
}
public DbSetUser Users { get; set; }
}
class MainClass
{
public static void Main (string[] args)
{
var em = new SampleEntities (new SqlConnection (server=localhost; +
database=ef_demo; +
uid=developer; +
pwd=123456;));
foreach (var item in em.Users) {
Console.WriteLine (item);
}
}
}
}
// ef_test.sql
CREATE DATABASE ef_test;
GO
USE ef_test;
GO
CREATE TABLE [user] (
user_id varchar(20) NOT NULL,
password varchar(40) NOT NULL,
email varchar(250) NOT NULL,
PRIMARY KEY (user_id)
);
GO
INSERT INTO [user] VALUES ('admin', '123456', 'ad...@company.com'),
('user', '123456', 'u...@company.com'),
('guest', '123456', 'gu...@company.com');
GO
Thanks,
--
Eddy Zavaleta
___
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] Namespace System.Data.EntityClient not found mono 2.11.4
Hi, I downloaded mono 2.11.4, i have EF code made with VS and .net 4.0, when i build the project in Linux the result is, the type or namespace names: System.Data.EntityClient System.Data.Metadata.Edm System.Data.Objects.DataClasses System.Data.Objects does not exist in the namespace System.data i'm don't find the Syste.Data.Entity.dll assembly, then, mono 2.11.4 comes with EF support? Only EntityFramework 6 was open sourced which comes with different assembly names (EntityFramework.dll) and namespaces. Previous versions are not available on Mono. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.TypeLoadExceptions in mono 2.11.4
Hi, I am just guessing here but this looks like you are running newly compiled compiler using 2.0 mono (old version?). You are better to check http://www.mono-project.com/Logging_Runtime_Events which should help you find out what is really getting loaded. Marek On Tue, Oct 9, 2012 at 7:00 PM, sebastian sebast...@palladiumconsulting.com wrote: I've just freshly built mono 2.11.4 from source using RHEL using $ uname -a Linux myhostname 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux $ gcc --version gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) And all functionality seems to fail with the same System.TypeLoadException $ mcs Unhandled Exception: System.TypeLoadException: Could not load type 'Mono.CSharp.CompilerSettings' from assembly 'mcs, Version=2.11.4.0, Culture=neutral, PublicKeyToken=null'. at Mono.CSharp.CommandLineParser..ctor (System.IO.TextWriter errorOutput) [0x0] in filename unknown:0 at Mono.CSharp.Driver.Main (System.String[] args) [0x0] in filename unknown:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type 'Mono.CSharp.CompilerSettings' from assembly 'mcs, Version=2.11.4.0, Culture=neutral, PublicKeyToken=null'. at Mono.CSharp.CommandLineParser..ctor (System.IO.TextWriter errorOutput) [0x0] in filename unknown:0 at Mono.CSharp.Driver.Main (System.String[] args) [0x0] in filename unknown:0 The same happens whether running a hello world program, NUnit test, built-in applications, etc. Obviously something is configured or built incorrectly, but I am at a loss as to what, as the configure, make, and make install steps all ran without error. Where do I start looking? Thanks, Sebastian ___ 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] build problem on head
Hello, I was building with the latest LLVM and mono on ubuntu. Got the following error: make[8]: Entering directory `/home/jshore/Srcs/mono/mcs/class/System.Web.Http.SelfHost' make[8]: *** No rule to make target `../../../external/aspnetwebstack/src/System.Web.Http.Selfhost/HttpRequestMessageExtensions.cs', needed by `../../class/lib/net_4_5/System.Web.Http.SelfHost.dll'. Stop. This error has been fixed. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Stack overflow in Array.Sort for large arrays
Hi, I cannot reproduce the issue. Could you fill a bug report with test case how to reproduce it. Thanks Marek On Thu, Aug 2, 2012 at 7:21 PM, Martin Potter martin.pot...@logos.comwrote: I am currently working on testing Mono to 2.11 with the hope to ease the transition to 2.12 when it is release. When testing, I found a nasty bug when sorting a large (228,000 elements) Listint that resulted in a stack overflow. The partial stack trace from the crash: System.Collections.Generic.List`1int:Sort () System.Array:Sortint (int[],int,int) System.Array:Sortint (int[],int,int,System.Collections.Generic.IComparer`1int) System.Array:SortImplint, int (int[],int[],int,int,System.Collections.Generic.IComparer`1int) System.Array:qsortint, int (int[],int[],int,int) ... System.Array:qsortint, int (int[],int[],int,int) Upon pulling the related sorting code from System.Array into a separate project, I determined that the stack overflow was occurring for this particular List/Array due to the fact that over half of the list elements were same number. It appears that this occurs as a result of the change to the various qsort methods in https://github.com/mono/mono/commit/d97cdb0c124729152be551c421c4a11732e45fc9, which introduced a change in the treatment of elements with equal values. Reverting this commit fixes the stack overflow in the test app. In testing, I noticed that the old qsort code was significantly faster sorting when there were lots of duplicate values, was there are particular reason for changing the logic for dealing with equal values? — Martin ___ 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] Bug fix for mcs (typo in error message)
Hi, There's an error message that says in not public when it meant to say is not public. The enclosed patch takes care of it. Patch applied. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] workflow foundation 4
Hi, I'm ceo of Natan, software development company in France. We are interesting in contributing. What is the first step we need to take to get started ? This is good starting point. http://www.mono-project.com/Contributing I don't think anyone is working on WWF4, so you are free to implement any part of it you like. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Few questions about Linq implementation
Hi, I have few question regarding linq implementation in mono. 1. Afaik current is based on dblinq (http://code.google.com/p/dblinq2007), which not much active from some time, so did mono team created a fork of it or using same code? Mono is using same code as dblinq2007. 2. Sometime back there was a discussion about rewriting linq implementation using relinq, is anybody working on it? If somebody want to take it up, what should be his priorities? Exposed API and library behaviour should be same as System.Data.Linq Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono and Microsoft open sourced Entity Framework
Hi, Yes, we are working on EF integration. Marek On Tue, Jul 24, 2012 at 9:09 PM, Daniel Morgan monodanm...@yahoo.comwrote: Since Microsoft has open sourced the Entity Framework, is anyone working on getting it to work on Mono? ___ 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] Initialization of array of enum - trying to not use RuntimeInternals.InitializeArray
Hello John,
There is a known bug in the Microsoft CLR on the x86_64 platform with
regards to initializing an array whose members are enum values
(http://connect.microsoft.com/VisualStudio/feedback/details/635365/runtimehelpers-initializearray-fails-on-64b-framework).
It appears that the Microsoft csc compiler somehow works around this
whereas gmcs does not. For example, the following compiled with gmcs
does not run on the Microsoft CLR on x86_64 (it throws an exception in
InitializeArray) but does when compiled with csc:
class Program
{
enum e { A, B, C, D, E };
static void Main()
{
e[] array = new e[] { e.A, e.B, e.C, e.D, e.E };
}
}
I appreciate this is apparently a bug with the Microsoft 64 bit CLR
rather than mono, but at the moment Microsoft's csc appears to work
around this where mono does not. Is there a way of telling gmcs to
not use a call to InitializeArray when instantiating arrays of enums
(instead doing something like: e[] array = new e[5]; e[0] = e.A; e[1]
= e.B; ... for the above example), or if not would there be any
support for adding this (e.g. via an optional command line flag to gmcs)?
Expanding the initialization is the easiest option how to workaround
this .net bug. Because the scope of the bug is quite limited and easy to
workaround I don't think it's work adding special handling for it.
Microsoft already fixed the issue but I am not sure whether there is a
hotfix available for .NET 2.0
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fail to run aspx web application on mod_mono-2.10 ( .Net 4 framework )
Hi, i tried to debug more deeper, got an error : `0169' is not a valid warning number Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'System.Core'. at Mono.CSharp.CompilerSettings.SetIgnoreWarning (Int32 code) [0x0] in filename unknown:0 at Mono.CSharp.CommandLineParser.ParseOption (System.String option, System.String[] args, Mono.CSharp.CompilerSettings settings) [0x0] in filename unknown:0 here's string content from BuilArgs both for xsp4 and mod-mono What is missing is how mod-mono calls C# compiler, from your log it looks like it forces 4.0 runtime for it where you need 4.5 runtime. This could be just wrong path settings, try to run mod-mono with path set to /opt/mono/lib/mono/4.5/ Marek --- mod-mono /target:library /lib:/home/anas/temp/WebApp4/Bin /debug+ /optimize- /warn:4 /out:/tmp/apache-temp-aspnet-0/f6c3a887/App_global.asax_1eff02c.dll /r:/opt/mono/lib/mono/4.0/Microsoft.CSharp.dll /r:/opt/mono/lib/mono/4.0/System.dll /r:/opt/mono/lib/mono/4.0/System.Configuration.dll /r:/opt/mono/lib/mono/4.0/System.Web.dll /r:/opt/mono/lib/mono/4.0/System.Data.dll /r:/opt/mono/lib/mono/4.0/System.Web.Services.dll /r:/opt/mono/lib/mono/4.0/System.Xml.dll /r:/opt/mono/lib/mono/4.0/System.Drawing.dll /r:/opt/mono/lib/mono/4.0/System.EnterpriseServices.dll /r:/opt/mono/lib/mono/4.0/System.IdentityModel.dll /r:/opt/mono/lib/mono/4.0/System.Runtime.Serialization.dll /r:/opt/mono/lib/mono/4.0/System.Xaml.dll /r:/opt/mono/lib/mono/4.0/System.ServiceModel.dll /r:/opt/mono/lib/mono/4.0/System.ServiceModel.Web.dll /r:/opt/mono/lib/mono/4.0/System.Core.dll /r:/opt/mono/lib/mono/4.0/System.Web.Extensions.dll /r:/opt/mono/lib/mono/4.0/System.Data.DataSetExtensions.dll /r:/opt/mono/lib/mono/4.0/System.Xml.Linq.dll /r:/opt/mono/lib/mono/4.0/System.ComponentModel.DataAnnotations.dll /r:/opt/mono/lib/mono/4.0/System.Web.DynamicData.dll /r:/opt/mono/lib/mono/4.0/System.Data.Linq.dll /r:/opt/mono/lib/mono/4.0/System.Web.ApplicationServices.dll /r:/tmp/apache-temp-aspnet-0/59d988b0/assembly/shadow/03dd29fd/cc4cc42e_cf91edd3_0001/WebApp4.dll /nowarn:0169 /d:DEBUG /noconfig /sdk:4 -- /tmp/apache-temp-aspnet-0/f6c3a887/App_global.asax_1eff02c_0.cs --- xsp4 /target:library /lib:/home/anas/temp/WebApp4/bin /debug+ /optimize- /warn:4 /out:/tmp/anas-temp-aspnet-0/fe1e55c0/App_global.asax_39600c7.dll /r:/opt/mono/lib/mono/gac/Microsoft.CSharp/4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.dll /r:/opt/mono/lib/mono/4.0/System.dll /r:/opt/mono/lib/mono/4.0/System.Configuration.dll /r:/opt/mono/lib/mono/4.0/System.Web.dll /r:/opt/mono/lib/mono/gac/System.Data/4.0.0.0__b77a5c561934e089/System.Data.dll /r:/opt/mono/lib/mono/gac/System.Web.Services/4.0.0.0__b03f5f7f11d50a3a/System.Web.Services.dll /r:/opt/mono/lib/mono/4.0/System.Xml.dll /r:/opt/mono/lib/mono/gac/System.Drawing/4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll /r:/opt/mono/lib/mono/gac/System.EnterpriseServices/4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll /r:/opt/mono/lib/mono/gac/System.IdentityModel/4.0.0.0__b77a5c561934e089/System.IdentityModel.dll /r:/opt/mono/lib/mono/gac/System.Runtime.Serialization/4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll /r:/opt/mono/lib/mono/gac/System.Xaml/4.0.0.0__b77a5c561934e089/System.Xaml.dll /r:/opt/mono/lib/mono/gac/System.ServiceModel/4.0.0.0__b77a5c561934e089/System.ServiceModel.dll /r:/opt/mono/lib/mono/gac/System.ServiceModel.Web/4.0.0.0__31bf3856ad364e35/System.ServiceModel.Web.dll /r:/opt/mono/lib/mono/4.0/System.Core.dll /r:/opt/mono/lib/mono/gac/System.Web.Extensions/4.0.0.0__31bf3856ad364e35/System.Web.Extensions.dll /r:/opt/mono/lib/mono/gac/System.Data.DataSetExtensions/4.0.0.0__b77a5c561934e089/System.Data.DataSetExtensions.dll /r:/opt/mono/lib/mono/gac/System.Xml.Linq/4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll /r:/opt/mono/lib/mono/gac/System.ComponentModel.DataAnnotations/4.0.0.0__31bf3856ad364e35/System.ComponentModel.DataAnnotations.dll /r:/opt/mono/lib/mono/gac/System.Web.DynamicData/4.0.0.0__31bf3856ad364e35/System.Web.DynamicData.dll /r:/opt/mono/lib/mono/gac/System.Data.Linq/4.0.0.0__b77a5c561934e089/System.Data.Linq.dll /r:/opt/mono/lib/mono/gac/System.Web.ApplicationServices/4.0.0.0__31bf3856ad364e35/System.Web.ApplicationServices.dll /r:/home/anas/temp/WebApp4/bin/WebApp4.dll /nowarn:0169 /d:DEBUG /noconfig /sdk:4 -- /tmp/anas-temp-aspnet-0/fe1e55c0/App_global.asax_39600c7_0.cs output = /tmp/anas-temp-aspnet-0/fe1e55c0/App_global.asax_39600c7.dll any clue why such an error happen only on mod_mono ? On Fri, Jul 13, 2012 at 4:52 PM, Anas Muzakir anas.muza...@gmail.comwrote: Hi Rob, Thanks for reply, I've tested options.OutputAssembly variable and it points to valid path. and I also execute mcs manually using string parameter that comes from BuilArgs function, and i can confirm this manual execution able to generate the dll file. i run it with this
Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
Hi, ** Thanks Miguel, your description helped me figure out a couple of key things. I’m gradually getting on top of the mcs/class build process and its translation to VS solutions/projects. There was already a lot of prior work done by Sebastien Pouliot (I think) a few years ago. That's not correct, all projects were regenerated recently. About the corlib-build issue, you don't need to build any of *-build.csproj projects, they are needed only on systems with no .NET 4 API. I have done some work on cleaning this up recently but it's not yet finished. Marek ** ** One thing I came across is that the project for “corlib-build” builds if targeting .Net 2.0, but fails on .NET 4.0 with a few errors such as follows. The only related issue I found ( https://github.com/nikhilk/scriptsharp/issues/156) suggests that .NET4.5 may be the issue. Any advice on handling this is welcome. I need to add project dependencies on a couple of outputs from the “basic” profile to overcome the issue and still target 4.0. However I do not like the departure from the cygwin build process. ** ** The type 'System.Diagnostics.TextWriterTraceListener' is defined in an assembly that is not referenced. You must add a reference to assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. C:\src\mono\mono\mcs\class\corlib\System.Diagnostics\ConditionalAttribute.cs 35 11 corlib-build The type 'System.Collections.Generic.ISet`1T0' is defined in an assembly that is not referenced. You must add a reference to assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. C:\src\mono\mono\mcs\class\corlib\System.Collections.Generic\CollectionDebuggerView.cs 32 11corlib-build ** ** ** ** Cheers, J-M ** ** *From:* Miguel Mudge [mailto:michael.mu...@welchallyn.com] *Sent:* Saturday, 12 May 2012 12:34 AM *To:* Perraud, Jean-Michel (CLW, Black Mountain) *Cc:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files ** ** Making progress with msvc, with a lot of second guessing, but I cannot seem to fully get out of the circular dependencies easily. After fixing a few things, there seems to be a two to three stage build process (‘basic’, ‘build’ and, well, the huge rest). I can build the ‘basic’ stuff with references being the MS.NET libraries it defaults to, but the ‘build’ phase fails both with dependencies on the basic system or the MS.NETlibraries (missing implementations or ambiguous references). Well done for you to sort it all out. ** ** Our build uses *none* of the MS.NET libraries - every project *only* depends on other projects in the same Mono solution file. All of the projects reference the mscorlib project built in that solution, *never* Microsoft's mscorlib.dll (see Project Properties - Build - Advanced - Do not reference mscorlib.dll). ** ** mscorlib has these compilation symbols: INSIDE_CORLIB LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 And it has a few links to external files: Aes.cs, Consts.cs, Locale.cs, MonoTODOAttribute.cs, SemaphoreFullException, TimeZoneInfo.AdjustmentRule.cs, TimeZoneInfo.Android.cs, TimeZoneInfo.cs, TimeZoneInfo.TransitionTime.cs. We were able to determine most of those files by looking at corlib.dll.sources - definitely look at the .sources files for the other DLLs too... although it's better to look at the Linux build in-action. ** ** You should be able to build mscorlib with the above info. Here is the info for system (notice the dash, as in minus): ** ** System -XML -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 CONFIGURATION_2_0 Depends on: mscorlib project ** ** System.Xml then depends on the above. ** ** System -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 CONFIGURATION_2_0 XML_DEP Depends on: mscorlib project, System.Xml project ** ** Mono.Security then depends on mscorlib and System -Config Mono.Configuration then depends on mscorlib, System.Xml and System -Config ** ** System: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 CONFIGURATION_2_0 CONFIGURATION_DEP XML_DEP SECURITY_DEP Depends on: mscorlib, System.Xml, System.Configuration, Mono.Security ** ** Don't trust the above though - I think there's a missing step, there may need to be 4 builds of System (one before XML_DEP is added, one before SECURITY_DEP is added, one before CONFIGURATION_DEP is added, then the final build with all 3 constants added). ** ** The best thing to do is compile mcs in Linux and gather this information:* *** - The order in which each library is built - including if it is built multiple times. - What dependencies each build has. - What compile-time constants are set. - What files are a part of the build.
Re: [Mono-dev] Compiler Error CS1902 in mono/master
Hi, You are hitting MonoDevelop bug where it's calling C# compiler with wrong arguments. In this particular case it's -debug:+ which is not valid. I am not sure there has been fix for it in 2.8 version but the latest release should work Marek I am testing current mono/master in Ubuntu Precise. I have installed Mono in /opt/mono-2.11. I am using MonoDevelop 2.8.6.3 from the distribution and added the new parallel environment using MonoDevelop's options. When using runtime verions 2.8.10.1 everything works as expected. However, if I switch to runtime version 2.11.2 I do get the following error: error CS1902: Invalid debug option '+'. Valid options are 'full' or 'pdbonly' This means that there's at least a bug in the error message itself. The page at http://man.he.net/man1/gmcs lists the parameter + as valid for the /debug option. Does anybody know what's going on here? Is it now required to always use the newest version of MonoDevelop when testing mono/master? ___ 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] build error (No rule to make target `../../../external/cecil/Mono.Collections.Generic/Collection.cs')
Hi, Try to reconfigure your mono. Marek These days (after 2012/Apr/28) master HEAD of Mono cannot build at my FreeBSD box. Following is error message. gmake[7]: Entering directory `/export/home/ksmakoto/Mono/mono/mcs/class/Mono.Cecil' gmake[7]: Leaving directory `/export/home/ksmakoto/Mono/mono/mcs/class/Mono.Cecil' gmake[7]: Entering directory `/export/home/ksmakoto/Mono/mono/mcs/class/Mono.Cecil' gmake all-local gmake[8]: Entering directory `/export/home/ksmakoto/Mono/mono/mcs/class/Mono.Cecil' gmake[8]: *** No rule to make target `../../../external/cecil/Mono.Collections.Generic/Collection.cs', needed by `../../class/lib/net_2_0/Mono.Cecil.dll'. Stop. gmake[8]: Leaving directory `/export/home/ksmakoto/Mono/mono/mcs/class/Mono.Cecil' gmake[7]: *** [do-all] Error 2 gmake[7]: Leaving directory `/export/home/ksmakoto/Mono/mono/mcs/class/Mono.Cecil' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/export/home/ksmakoto/Mono/mono/mcs/class' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/export/home/ksmakoto/Mono/mono/mcs' gmake[4]: *** [profile-do--net_2_0--all] Error 2 gmake[4]: Leaving directory `/export/home/ksmakoto/Mono/mono/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/export/home/ksmakoto/Mono/mono/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/export/home/ksmakoto/Mono/BUILD' gmake: *** [all] Error 2 ___ 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] Compiling mono? I give up [not proceeding] - if anything obvious i'm doing wrong let me know
Hello, Here's the problem copied/pasted directly from command line of both programs: mono: symbol lookup error: /home/robwilkens/mono/lib/libglibsharpglue-2.so: undefined symbol: g_thread_supported This is gtk-sharp issue when running on glib = 2.31. Plenty of info here, https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/911125 Patch that fixes the issue https://gist.github.com/2570657 Jo Shields helped me to find it out. Marek Oddly enough, i tried googling the error message (copy/paste) from libglibsharpglue to the end of the line, and nothing came up.. I guess i'm the first one to run across this particular problem, or at least the first to ask publicly. I get the same error from both programs that i was trying to test before (namely: monodevelop and GhettoGtkAdmin)... Is this mono or should i look for a gtk-sharp mailing list and ask there? Thanks, Rob ___ 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] high-freq use of compiler as a service or reflection.emit
Hello, I have an application where rules are generated (as part of a genetic algorithm). Rather than evaluate the rules in interpreted form (which are 5x or more slower than the equivalent compiled code), thinking to use reflection.emit or the mono compiler as a service. Compiler as a service is most likely too heavy weight for you, it does all complicated logic behind C# and unless your input rules are very complex you won't benefit from it. I think the most suitable options for you would be System.Linq.Expressions. It's very easy to use abstraction on top of reflection.emit and it does some simple optimizations too. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build fails: name `AllowReversePInvokeCallsAttribute' does not exist
Hello, Just follow what the error message says You need Mono version 2.4 or better installed to build MCS Marek I'm trying to build mono from git sources ./autogen.sh --prefix=/usr/local make sudo make install , but unfortunately it fails like this: make[6]: Entering directory `/home/tavasti/build/mono/mcs' build/common/basic-profile-check.cs(13,67): error CS0234: The type or namespace name `AllowReversePInvokeCallsAttribute' does not exist in the namespace `System.Runtime.InteropServices'. Are you missing an assembly reference? Compilation failed: 1 error(s), 0 warnings make[6]: *** [build/deps/basic-profile-check.exe] Error 1 make[6]: Leaving directory `/home/tavasti/build/mono/mcs' *** The compiler 'gmcs' doesn't appear to be usable. *** You need Mono version 2.4 or better installed to build MCS *** Read INSTALL.txt for information on how to bootstrap a Mono installation. make[5]: *** [do-profile-check] Error 1 make[5]: Leaving directory `/home/tavasti/build/mono/mcs' make[4]: *** [profile-do--basic--all] Error 2 make[4]: Leaving directory `/home/tavasti/build/mono/mcs' make[3]: *** [profiles-do--all] Error 2 Any hints? --Tavasti ___ 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] DateTime.ParseExact bug ?
Hi,
Please fill a bug report at http://bugzilla.xamarin.com/
Thanks
Marek
Nodbody?
Anywho, since it's an incompability with .net I guess that I should
file a bug somewhere?
Best regards,
Nicklas
On 2011-09-19 00:04, Nicklas Overgaard wrote:
Yes, i'm very sure - it's copy-paste from the solrnet source code:
https://github.com/mausch/SolrNet/blob/master/SolrNet/Impl/FieldParsers/DateTimeFieldParser.cs
And the code-snippet I attached below does indeed work on windows in
.net :)
/Nicklas
On 2011-09-18 23:00, Stefano Canepa wrote:
Nicklas Overgaard at Sun, 18 Sep 2011 18:34:08 +0200 wrote:
NO Hi,
NO I'm currently working with Solr and SolrNet for a project. However, i'm
NO encountering errors when SolrNet is parsing date times...
NO I have located the date-time parsing code in SolrNet, and made a sample
NO test application shown below:
NO code start
NO using System;
NO using System.Linq;
NO using System.Globalization;
NO namespace datetimeparsing
NO {
NO class MainClass
NO {
NO public static void Main (string[] args)
NO {
NO string s = 1984-09-17T09:00:00Z;
NO DateTime dt= DateTime.ParseExact(s,
NO -MM-dd'T'HH:mm:ss.FFF'Z', CultureInfo.InvariantCulture);
NO }
NO }
NO }
NO /code end
Are you sure about the format string? I think that you need to write only
FF'Z instead of FFF'Z. Did you take a look at mono source code?
Bye
Stefano
___
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] Need PutVar method on Mono.CSharp.Evaluator
Hello, Hi, I am new to Mono, but becoming a big fan quickly (more detail below regarding what I am doing with it). To get right to the point, however, I would appreciate advice on how to *programmatically* set the value of a variable that can be seen inside the Evaluator, e.g., var temp = Evaluator.Evaluate(...); Evaluator.PutVar(x, temp); // so such method exists! Evaluator.Run(... x ...); You can simply run C# statement which will do the assignment. Trivial example can look like this Evaluator.Run(x = whatever); Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiler crashes
Hi, Could you please fill C# compiler bug report Thanks Marek $ mono --version Mono JIT compiler version 2.10.2 (tarball Thu June 30 20:35:21 UTC 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:Included Boehm (with typed GC and Parallel Mark) $ gmcs --version Mono C# compiler version 2.10.2.0 Ubuntu 11.04. I've got the same results on openSuSE 12.1 and Mono from the repo from go-mono.com site. Regards, Nikita -- View this message in context: http://mono.1490590.n4.nabble.com/Compiler-crashes-tp3695350p3695429.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] Support for Portable Class Libraries (PCL)
Hi, Would you mind sending a link to the relevant issue on bugzilla so I can track it? https://bugzilla.novell.com/show_bug.cgi?id=608069 Marek On Sat, Jul 2, 2011 at 1:32 AM, Marek Safar marek.sa...@gmail.com mailto:marek.sa...@gmail.com wrote: Hello, Microsoft has recently introduced support for Portable Class Libraries, allowing the same DLL to be reused for both .Net 4 and Silverlight 4 without recompiling the source. There are restrictions on which APIs are available, and some minor API changes from their non-portable equivalents to gain consistency across the platforms. http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981 What additional development effort would be required for the Mono project to deliver equivalent Portable Class Library system library implementations, to be used as library references when compiling .Net 4 / Silverlight 4 portable code with gmcs? We don't have Portable .NET profile. The first step would be to create this build profile and probably use linker or hack the compiler to strip all IL code as it's not needed. On top of that runtime support for retargetable assemblies is needed. There is already a bug report about this feature in bugzilla. I think that's all what is needed. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- | Kaazing Corporation | John Fallows | CTO | +1.650.960.8148 444 Castro St, Suite 1100 | Mountain View, CA 94041, USA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Support for Portable Class Libraries (PCL)
Hello, Microsoft has recently introduced support for Portable Class Libraries, allowing the same DLL to be reused for both .Net 4 and Silverlight 4 without recompiling the source. There are restrictions on which APIs are available, and some minor API changes from their non-portable equivalents to gain consistency across the platforms. http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981 What additional development effort would be required for the Mono project to deliver equivalent Portable Class Library system library implementations, to be used as library references when compiling .Net 4 / Silverlight 4 portable code with gmcs? We don't have Portable .NET profile. The first step would be to create this build profile and probably use linker or hack the compiler to strip all IL code as it's not needed. On top of that runtime support for retargetable assemblies is needed. There is already a bug report about this feature in bugzilla. I think that's all what is needed. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Possible QuickSort optimizations for Array.Sort()
Hello,
public class SortT {
public delegate int Comparison (T v0, T v1);
You don't need yet another delegate, just use standard Func
static readonly int INSERTIONSORT_THRESHOLD = 7;
Why not to used const int ?
More importantly what is performance of sorting array of 10-20 elements
called 100 times ?
Thanks
Marek
Attached you'll find qsort.cs which includes 3 QuickSort implementations:
1. QuickSortBasic[R]: This is a basic QuickSort implementation and the
one currently in use as the sorting function in Array.Sort(). This
implementation always uses the middle element as the pivot.
2. QuickSortMedian[R]: This implementation is also a basic QuickSort
implementation which attempts choose a better pivot based on the
first, last, and middle elements. For sorted inputs and random inputs,
this seems to help performance somewhat as the array gets larger and
larger. However, for reverse-sorted inputs, it seems to kill
performance. Perhaps if I choose 3 random points to feed into Median()
it will do better.
3. QuickSortInsertion[R]: This implementation includes the above perf
trick and also includes an Insertion Sort fallback when partitions are
broken down smaller than some threshold # of elements (7 in the
attached code). It also falls back to Insertion Sort when it
encounters a worst-case scenario. As always, the performance
improvement with this is greater as the number of elements increases
and/or as the comparison function becomes more complex.
You'll notice that the attached test program will print out the number
of comparisons that each sort routine uses in order to complete its
job. It's important to keep in mind that the more complex the
comparison function is, the more important it is that the number of
comparisons is kept to a minimum.
Here are some example runs:
[fejj@warpig sorting]$ mono ./qsort.exe -random 1
Basic QuickSort comparisons needed: 3807986012
QuickSort+Median comparisons needed:3077915654
QuickSort+Insertion comparisons needed: 3021355043
Basic QuickSort finished in: 00:00:43.8178721s
QuickSort+Median finished in:00:00:37.3047443s
QuickSort+Insertion finished in: 00:00:36.6122681s
[fejj@warpig sorting]$ mono ./qsort.exe -sorted 1
Basic QuickSort comparisons needed: 2632227866
QuickSort+Median comparisons needed:2632227867
QuickSort+Insertion comparisons needed: 2483222808
Basic QuickSort finished in: 00:00:21.8213618s
QuickSort+Median finished in:00:00:21.2622527s
QuickSort+Insertion finished in: 00:00:19.0837352s
(Note: I reduced the array size here due to wanting to head home for
dinner)
[fejj@warpig sorting]$ mono ./qsort.exe -reversed 1
Basic QuickSort comparisons needed: 129546
QuickSort+Median comparisons needed:12522499
QuickSort+Insertion comparisons needed: 39993
Basic QuickSort finished in: 00:00:00.0016905s
QuickSort+Median finished in:00:00:00.0911385s
QuickSort+Insertion finished in: 00:00:00.0008721s
Jeff
___
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, I have named it ildasm to match the managed ilasm. The new name also means that it can live alongside monodis for the time being. Monodis has a major drawback, its dependency on picking up the right mscorlib.dll to work, your effort will fix that problem and get rid of one of the most annoying things of monodis. 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. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using the generic type `System.FuncT1, T2, T3, T4, T5, T6, T7, T8, T9, TResult' requires `10' type argument(s)
Hello, Please fill a bug report and provide full xbuild output. Thanks Marek I have a console app which builds and runs under Windows fine. But when I'm trying to build it under Mono, I'm getting next errors: godfather@debian: $ xbuild MyProject.sln Indicator/ADXReader.cs(71,42): error CS0305: Using the generic type `System.FuncT1,T2,T3,T4,T5,T6,T7,T8,T9,TResult' requires `10' type argument(s) /usr/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll (Location of the symbol related to previous error) Indicator/ADXReader.cs(75,46): error CS0305: Using the generic type `System.FuncT1,T2,T3,T4,T5,T6,T7,T8,T9,TResult' requires `10' type argument(s) /usr/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll (Location of the symbol related to previous error) while in code I have just such lines: 71: privatereadonly Funcdouble, double, bool predicate; 75: publicOperationInfo(Funcdouble, double, bool predicate, Op operation) I was unable to reproduce that in stand-alone test app though ..( godfather@debian: $ mcs --version Mono C# compiler version 2.11.0.0 godfather@debian $ mono --version Mono JIT compiler version 2.11 (master/7420834 Sat Mar 26 12:56:34 MSK 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: x86 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:Included Boehm (with typed GC and Parallel Mark) What can I do? TIA Alex ___ 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] Unable to build neither Mono 2.10.1 nor 2.10
Hello, You cannot use parallel build (usually make -j) with Mono 2.10 Marek Hi, I'm trying to build Mono both 2.10.1 and 2.10 from source archive downloaded from http://ftp.novell.com/pub/mono/sources/mono/ OS Debian 6 $ uname -a Linux debian 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux but with equal errors in both archives: * Generating code into 'autogenerated-api-0-9.cs' Missing method System.Type::op_Inequality(Type,Type) in assembly /usr/src/mono/mono-2.10/mcs/class/lib/net_2_0/mscorlib.dll, referenced in assembly /usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/apigen/RabbitMQ.Client.Apigen.exe Unhandled Exception: System.MissingMethodException: Method not found: 'System.Type.op_Inequality'. at RabbitMQ.Client.Apigen.Apigen.MaybeEmitModelMethod (System.Reflection.MethodInfo method) [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in filename unknown:0 Missing method System.Type::op_Inequality(Type,Type) in assembly /usr/src/mono/mono-2.10/mcs/class/lib/net_2_0/mscorlib.dll, referenced in assembly /usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/apigen/RabbitMQ.Client.Apigen.exe Missing method System.Type::op_Inequality(Type,Type) in assembly /usr/src/mono/mono-2.10/mcs/class/lib/net_2_0/mscorlib.dll, referenced in assembly /usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/apigen/RabbitMQ.Client.Apigen.exe make[9]: *** [autogenerated-api-qpid-0-8.cs] Error 1 make[9]: *** Waiting for unfinished jobs MONO_PATH=./../../../../class/lib/net_4_0:$MONO_PATH /usr/src/mono/mono-2.10/runtime/mono-wrapper ../../src/apigen/RabbitMQ.Client.Apigen.exe /n:v0_8 /apiName:AMQP_0_8 amqp0-8.stripped.xml autogenerated-api-0-8.cs Unhandled Exception: System.MissingMethodException: Method not found: 'System.Type.op_Inequality'. at RabbitMQ.Client.Apigen.Apigen.MaybeEmitModelMethod (System.Reflection.MethodInfo method) [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in filename unknown:0 make[9]: *** [autogenerated-api-0-9.cs] Error 1 Unhandled Exception: System.MissingMethodException: Method not found: 'System.Type.op_Inequality'. at RabbitMQ.Client.Apigen.Apigen.MaybeEmitModelMethod (System.Reflection.MethodInfo method) [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in filename unknown:0 at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in filename unknown:0 make[9]: *** [autogenerated-api-0-8.cs] Error 1 make[9]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/docs/specs' make[8]: *** [do-all] Error 2 make[8]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/docs/specs' make[7]: *** [all-recursive] Error 1 make[7]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client' * Loading spec from 'amqp0-8.stripped.xml' make[6]: *** [all-recursive] Error 1 * Parsing spec make[6]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class' * Generating code into 'autogenerated-api-0-8.cs' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/usr/src/mono/mono-2.10/mcs' make[4]: *** [profile-do--net_2_0--all] Error 2 make[4]: *** Waiting for unfinished jobs make[9]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/docs/specs' make[8]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/docs/specs' make[8]: Entering directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/client' make[8]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/client' make[8]: Entering directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/client' make all-local make[9]: Entering directory `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/client' MCS [net_4_0] RabbitMQ.Client.dll
Re: [Mono-dev] Covariance, contravariance and name hiding
Hello,
Could you please fill a bug report
Thanks
Marek
Hi!
I have the following code:
===begin source code===
interface InterfaceWithCovarianceout TException
where TException: Exception
{
TException Error { get; }
}
interface InterfaceWithContravariancein TException:
InterfaceWithCovarianceException
where TException : Exception
{
new TException Error{set;}
}
===end source code===
Microsoft csc.exe compiles this code successfully, because Error property
from InterfaceWithCovariance is get_Error method, and Error property from
InterfaceWithContravariance is set_Error method. But Mono compiler emits the
following error:
The contravariant type parameter `TException' must be covariantly valid on
`ClassLibrary1.InterfaceWithContravarianceTException.Error' (CS1961)
I think, this error is occured because compiler use property name when
analyze covariance/contravariance instead of property accessor method.
Thanks.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] csproj files for Mono's class libraries.
Hello, project will require NUnit addin (am not sure if it exists for 2010) and thus excludes Express users. You don't need nunit addin, you can use any internal or external tool which can run nunit including nunit-console. The trouble is to build with correct nunit framework version to be able to use the tool. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] csproj files for Mono's class libraries.
Hello, The newer system should be as convenient as dll.sources model. Without as easy step as to add just one line for new Foo.cs in Bar.dll.sources (or more importantly for contribution, FooTest.cs in Bar_test.dll.sources), I'm not likely enthusiastic to contribute new code. If all you change is the .sources file, re-creating the project is a matter of running the tool. Updating it from the makefile is easy, updating it from the csproj itself does not sound trivial though, I am open to suggestions how how we can handle this. We could create a simple Task which does .sources to Compile Include= / on the fly or drop .sources completely and use .csproj only Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] csproj files for Mono's class libraries.
Hello, You can have the csproj reference the .sources file externally, and use a small Task to transform the list of files into Compile elements. This works in VS for building, but does not show the sources as files in the csproj via the UI. So, depending what you want... Something like this http://stackoverflow.com/questions/3187666/msbuild-custom-task-to-run-custom-tool-to-generate-classes-for-linq-to-sql-model our xbuild master can probably give better guidance. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent C# compiler changes
Hello, I'm having trouble building today's tarball (20110204). 'mod' fails to build: make[8]: Entering directory `/xxx/home/baileyj/mono-20110204/mcs/tools/mod' MCS [net_4_0] mod.exe error CS0006: Metadata file `./../../class/lib/net_2_0/monodoc.dll' could not be found Compilation failed: 1 error(s), 0 warnings Could it be related to the new SDK flag? monodoc.dll does not show up under any directory after running make. I don't think it's related, this looks like you are building 4.0 profile only which is not (yet) allowed. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Recent C# compiler changes
Hello, In the recent weeks I have made several changes to how Mono C# compiler is build and works. With the current master version we no longer use and build System.Reflection based C# compilers (gmcs.exe, smcs.exe, dmcs.exe). The new C# compiler (called mcs.exe) is based on IKVM.Reflection which allows us to build mscorlib independent version of C# compiler. The compiler scripts (gmcs, dmcs) are still working just internally call different program. A new compiler option has been introduced called sdk with 2 values at the moment (2, 4). It allows to build against predefined framework version without manually specifying mscorlib location when compiling directly using mcs compiler. The default value is 4. On top of that mcs.exe is now .net 4 application which means you need to install mono including .net 4.0 support to be able to compile any C# program. All changes apply to mono master only and will be part of the following Mono's release after 2.10. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent C# compiler changes
Hello, install mono including .net 4.0 support to be able to compile any C# program. What's the lowest Mono version that can be used to bootstrap the current git version? I have not really tested it but Mono 2.4 or newer should work. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent C# compiler changes
Hello, I think both ways should be supported. If it starts with a number and is a valid constant, use it. (easier for people building interactively in the command line), but for any other pattern try to just concat as suggested (easier for makefiles and to support custom frameworks) Yes, I'll implement it along these lines. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] build failure on processing NpgsqlState.resx
Hello, The latest Windows build is broken at Npgsql in net_2_0 profile. Looks like the build change that switched to use mcs/class/lib/build did it. That should be fixed now. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can't build current mono master branch
Hello, Hi folks, I can't build current mono from github master branch on my linux machine (Ubuntu 11.04, parallel mono environment): Update to the latest master, the issue should have been fixed there. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)
Hello, In membercache.cs.AddBaseType () line 219, if entry.Value.Count == 1, entry.Value is a MemberSpec[] which will cause the list.Add(ce) on Line 234 to fail. Gmcs.exe fails with CS0584: Internal compiler error: Collection is read-only (in ecore.cs:433) when this case is encountered. I ran across this error while compiling our code with Mono 2.9 from master today. I'm not sure how to reproduce the error, otherwise I'd have submitted a test case. This issue should now be fixed. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Too many open files when adding many embedded resources
Hello, Building Mono 2.9 from git master, we're encountering an issue where an assembly with lots of embedded resources (approx 4000), where gmcs is throwing Too many open files exception. The culprit seems to be that a new file handle is opened for every embedded resource when it's added. Mono 2.6 doesn't have this problem, so it appears to be a regression The issue should be fixed. Could you please test it? Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add async to dmcs
Hello, As a starting point, I've added the async method modifier to dmcs, which will be recognized when -langversion:Future is passed. This is my first foray into the mcs codebase and I just want to make sure I'm on the right track before going much further. The patch is attached and also applied at https://github.com/nirvanai/mono. Patch applied. Please use pull request on github next time. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# source-to-source compiler
Hello, I just noticed this thread, and I'm curious, when you say: The async/await is about asynchrony and spawn/sync is about parallelism. These are 2 different things which should not be mixed together. Do you mean they should not be confused, or do you literally mean that these technologies (or paradigms, if you will) should not be combined? If this is the case, I'm curious to learn why you say that, since I'm toying with idea of hybrid threading for a concurrency framework I'm working on (https://github.com/nirvanai/Cirrus). I don't see any problem combining these two together when needed, my point was simply that they mean 2 different things. Mono C# compiler has no async support yet (the .NET preview has been announced few days ago!) but we are fully aware of it and we will implement it as soon as time permits. I implemented async methods (before I knew they were to be a language feature) using Cecil for the framework I mentioned. I think the coroutine transformation I'm doing is pretty similar to the way Microsoft is doing things in their async preview. I'd certainly be willing to take a stab at adding async support to the Mono C# compiler if/when you think that might be beneficial. Patches are always welcomed. However, the approach will be different as the rewrite will happen at expression level (you don't need Cecil). Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Generic Constraints Regression in 2.8
Hello,
Could you please fill a bug report.
Thanks
Marek
Except that Y is constrained to be of type Z and so is guaranteed to
be a reference type.
On Mon, Nov 15, 2010 at 12:30 AM, Bojan Rajkovic
severedcr...@gmail.com mailto:severedcr...@gmail.com wrote:
On Nov 14, 2010, at 10:16 PM, Tom Philpot wrote:
The following code compiled with a warning on Mono 2.7 (as of
147679) but has an error in 2.8.
namespace Application
{
public class Z {}
public class AX, Y
where Y : Z
where X : Y
{
protected void SomeOperation(Y y)
{
X x = y as X;
}
}
public class Foo { public static void Main() {} }
}
/opt/mono-2.8/bin/gmcs CS0413Regression.cs
CS0413Regression.cs(12,33): error CS0413: The `as' operator
cannot be used with a non-reference type parameter `X'. Consider
adding `class' or a reference type constraint
Compilation failed: 1 error(s), 0 warnings
/opt/mono-r147679/bin/gmcs CS0413Regression.cs
CS0413Regression.cs(12,27): warning CS0219: The variable `x' is
assigned but its value is never used
Compilation succeeded - 1 warning(s)
The error message here is the correct thing to do—as casts are
only valid with reference types, because they can result in null,
which is invalid for a value type. If this raised only a warning
in gmcs earlier, it was a bug.
—Bojan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto: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
mailto: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] C# source-to-source compiler
Hello, Thanks! Raphael said exactly the same thing to me. Now I have two questions: - How much does the async stuff in C# 5.0 resemble the Cilk spawn-sync model? And how much async stuff is implemented in the mono trunk? The async/await is about asynchrony and spawn/sync is about parallelism. These are 2 different things which should not be mixed together. Mono C# compiler has no async support yet (the .NET preview has been announced few days ago!) but we are fully aware of it and we will implement it as soon as time permits. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] async / await / Task
Hello, Do you know about this stuff? This should be available with C# 5, but I understand that this has nothing new on the CLR. Do you have any plan? We are very aware of this feature. However, we usually start working on new features when at least Beta1 is released as there are generally many changes between CTPs and Beta. This particular features does not require CLR changes but that's not as important as whether it will require a new mscorlib. Again, this is very early to say as the async will bring a new pattern to .net framework and it's not clear yet how existing asynchronous methods will be changed or updated or whether there will have a new Async implementation. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in mono or our code?
Hello,
Could you please fill a bug report with all details how to reproduce the
issue and actual error message?
Thanks
Marek
When compiling our code
(http://github.com/davidiw/brunet/blob/master/src/Brunet/Concurrent/ExclusiveServer.cs)
using 2.8 and git master head, I receive a very long error message. The
key points are:
[csc] mono_image_get_method_on_inst_token: don't know how to
handle System.Reflection.Emit.ConstructorOnTypeBuilderInst
[csc] Stacktrace:
[csc]
[csc] at (wrapper managed-to-native)
System.Reflection.Emit.ModuleBuilder.getToken
(System.Reflection.Emit.ModuleBuilder,object)0x0004c
[csc] at (wrapper managed-to-native)
System.Reflection.Emit.ModuleBuilder.getToken
(System.Reflection.Emit.ModuleBuilder,object)0x0004c
I can do more debugging, but I figure this is a quick fix for those in
the know.
Also, I found this faulty:
diff --git a/mono/metadata/reflection.c b/mono/metadata/reflection.c
index 7bc8471..3cc8522 100644
--- a/mono/metadata/reflection.c
+++ b/mono/metadata/reflection.c
@@ -2831,7 +2831,7 @@ mono_image_get_ctor_on_inst_token
(MonoDynamicImage *assembly, MonoReflectionCto
token = mono_image_get_memberref_token (assembly,
klass-byval_arg, mm-name, sig);
} else {
char *name = mono_type_get_full_name (mono_object_class
(c-cb));
- g_error (mono_image_get_method_on_inst_token: don't
know how to handle %s, name);
+ g_error (mono_image_get_ctor_on_inst_token: don't know
how to handle %s, name);
}
Regards,
David
___
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] Does anyone know why the c# type dynamic does not work in mono c# REPL 2.8?
Hello,
Does anyone know why the c# type dynamic does not work in mono c# REPL 2.8?
Enter statements below.
csharp dynamic x = 4;
{interactive}(1,10): error CS8088: Your .NET Runtime does not support
``void' or
`void*' field type'. Please use the latest Mono runtime instead.
It should work, could you please fill a bug report ?
Thanks
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Generic Variance Bug
Hello,
using mono from trunk, the following code compiles fine:
== buggy.cs==
namespace Buggy
{
public interface ITest
{
}
public interface ITestSpecialized : ITest
{
}
public interface IGenericout TTest where TTest : ITest
{
TTest Function();
}
public interface IDerived : IGenericITest
{
}
public abstract class ImplementationTTest : IGenericTTest
where TTest : ITest
{
public TTest Function()
{
throw new System.NotImplementedException();
}
}
public class MyClass : ImplementationITestSpecialized, IDerived
{
}
}
This should not actually compile as the interface is not implemented. I
have pushed a fix for this in master.
Thanks
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Confusion between float and System.Single (pt 2)
Hello Charles, Sorry, I mistakenly pressed Ctrl-S before I was finished Gmcs from the version of mono I git cloned yesterday (25th August) has produced an error where there was no error using mono 2.6.7 You have found a bug which I just fixed, please update to the newest git version. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] base call hoisting (error) and MonoDevelop w/Moonlight
Hello, I ran into this last weekend. It's a regression in the compiler. I was going to send a patch in Monday, but somebody on the mono team already did. I believe it's on monobin. They posted it on IRC, but I guess nobody has applied it yet. It's not really regression, gmcs produced invalid IL for such construct which I have discovered recently and until I implement this feature gmcs reports ICE instead of generating invalid IL. What you need to do is move the base calls into their own method and call that method for the base hoist error. Correct, the workaround is simple. Just move the call into a method Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi, I'm trying to keep differences minimal, and I have no intention to drop System.Reflection support: #if IKVM_REF_EMIT using IKVM.Reflection; using IKVM.Reflection.Emit; using Type = IKVM.Reflection.Type; #else using System.Reflection; using System.Reflection.Emit; #endif I'd prefer not to go this route but it will require some gmcs refactoring to avoid it. My other modifications are around hacks for overcoming limitations of System.Reflection[.Emit] that make mcs depend on the Mono runtime, so actually I'm just trying to make the code hack free. My understanding is that basically we only have two compilers: - static: mcs.exe, gmcs.exe, smcs.exe, dmcs.exe (for each profile) - dynamic: Mono.CSharp.dll, that is used by Microsoft.CSharp.dll and csharp.exe That's not entirely accurate. We have REPL mode which is another dynamic version of all *mcs.exe running on top of SRE and there is possibility in near future for MD to plug-in with it's own type system mostly based on Cecil and most likely another type system is coming with .NET v-next which should expose C# DOM via .NET interfaces. As I see (based on your explanation) only the dynamic (as in the above list) compiler is using MakeExpression methods that will have to use System.Reflection anyway because they generate code that can be executed without saving an assembly first that requires runtime support. Because of conditional compilation and minimal code changes, having support for both SRE implementations - in my opinion - is not (significantly) increasing code maintenance requirements. If the above assumptations are correct then all the MakeExpression methods can safely be #if-ed out when building the static compilers and thus there are no features that cannot be implemented by using IKVM.Reflection. Is this correct? IKVM SRE like interface is quite disadvantage here. Presumably you could reference IKVM with extern alias to avoid System.Type conflicts otherwise we would have to alias every IKVM namespace. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Getting rid of SRE CompilerContext
Hi, [1]Actually not all compiler context hacks can go away, but only those strictly required to compile corlib will remain. gmcs no longer sets the flag so from gmcs perspective all CC hacks can go. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hello Kornél, Thanks for the proof of concept of using System.Reflection.Emit with latest gmcs. I'll look into this more deeply when I iron out all regressions caused by the big change. It would be interesting to get some numbers out, I don't believe there should be much difference between SR(E) and IKVM but one never know. If you are going to do some testing use any real user assembly (not mscorlib), for instance System.Web or MD. Regards, Marek mcs creates an assembly, then creates types, and only after that is processing the custom attributes. This is how attributes and even assembly name (not the name part) can change after definition. Although there are some other self referencing cases, this order of creation/definition is required especially when building mscorlib.dll. At least some cases of these requirements could be eliminated by doing dependency analysis but there is no use to introduce extra complexity when the solution is very simple. All of these functions are implemented as hacks in Mono's System.Reflection.Emit. Blob encoded pseudo custom attributes are supported by Mono. I've added decoding because they weren't ignored, exceptions were thrown instead. I think that the only problem is that I've removed the exception when emitting backward jumps but since things were working so far, I haven't tried to resove that issue yet. (This is a work-in-progress state.) Unlike Java, C# has support for backward jumps, so does System.Reflection.Emit so support for that will have to be implemented. Some notes on IKVM.Reflection: First of all, thank you very much for creating it, since it's very unique. Based on your questions I belive that you are trying to remain compatible with MS.NET. This good, because both IKVM and mcs has a dynamic mode that is generating code for direct execution that requires System.Reflection.Emit. And to some extent enables IKVM.Reflection to be a drop-in replacement for System.Reflection.Emit on runtimes that have no built-in support. I on the other hand belive that removing arbitrary limitations of System.Reflection.Emit (like preventing access to TypeBuilder's member-builders), and adding missing functionality would make sense. Mono.Cecil is a great tool but it targets tools operating on metadata rather and is too abstract and complex for compilers. It also has a larger memory footprint. So I belive that there is a need for IKVM.Reflection as a replacement for MS.NET's System.Reflection.Emit as well. I also like the concept of having a Universe since that makes possible to have multiple compiler instances in the same AppDomain. I belive that pseudo custom attributes and unmanaged resource generation does not fit well to the concept of System.Reflection.Emit. I would rather remove support for both of these and introduce __methods for setting metadata that currently is built from pseudo custom attributes. Unmanaged resource generation could be automated (and customized) by using a dedicated class. This would be much faster than encoding (either binary or just the constructor arguments) and then decoding pseudo custom attributes. I also belive that CustomAttributeData should not be used as a provider, __GetCustomAttributes (non-standard since is returning constructor arguments rather than class instance) methods should be added to reflection classes. An ICustomAttributeProvider interface (with IsDefined and __GetCustomAttributes methods) would be very useful as well. As a conclusion I would be happy to see features (that make sense) in IKVM.Reflection.Emit that are not present in System.Reflection.Emit. Kornél Jeroen Frijters wrote: Hi, Thanks for the IKVM.Reflection patches. I have a few questions about some of the changes. - Why are the various _SetAttributes methods and the AssemblyBuilder.__SetName() methods necessary? - Do you really need blob encoded pseudo custom attributes in the version info? I intentionally don't suppor that (and also include the attributes as regular attributes) to be compatible with .NET - Why are all the stack height asserts commented out in ILGenerator, do you think they are wrong? Thanks, Jeroen -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Tuesday, May 04, 2010 2:03 PM To: mono-devel Cc: Miguel de Icaza; Marek Safar; Jeroen Frijters Subject: Porting mcs to IKVM.Reflection Hi, Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a try to port mcs to IKVM.Reflection. I addition to being able to have a single binary, mcs could run on MS.NET and we would not have to break MS.NET compatibility in System.Reflection. I've attached some work in progress patches both for mcs and IKVM.Reflection. I was impressed by the result that mcs is able to bootstrap itself, compile mscorlib.dll and its other requirements, and the resulting mcs is able
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi Kornél Can you please tell when are MakeExpression methods used and whether are they required for code generation by mcs? The problem is that SLE MakeExpression methods require System.Reflection types. I was unable to find out when are MakeExpression methods used so I cannot come up with a solution. MakeExpression is used by dynamic C# compiler for dynamic code generation. MakeExpression uses System.Type type-system and always will, therefore gmcs must work with System.Type. You can browse /mcs/class/Microsoft.CSharp for more details. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch to corlib that causes compile to segfault
Hi Chris, Attached is the patch that causes compiling corlib to segfault on the default profile. It does not segfault with PROFILE=net_4_0 The code is not final, and is a bit of a mess. I have applied the patch with few cleanups. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch 1/2 - System.Diagnostics.Contracts in corlib
Hello, Some of the existing code was protected by #if NET_2_1 || NET_4_0 (e.g. PureAttribute) And other parts of the code were always compiled, but made internal if not NET_2_1 or NET_4_0 (e.g. Contract.cs) So I left these as they are, and did the same in new files that I introduced, which meant the call to Environment.FailFast() had to have the additional #if NET_4_0. However, if it would be better to change all files to be completely surrounded by #if NET_4_0 then please let me know. Keep existing code without change and any new stuff add as NET_4_0 only The private exception class ContractException is specified in the MS documentation: http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf See sections 7.6, 7.3, 7.4 And I have verified what I have implemented is the same as MS. Quite strange design but fair enough The private exception class ContractShouldAssertException is because, in some circumstances, the code should Assert, but there appears to be no simple way to do this from within corlib, so I throw this exception instead. However, this will never occur because it is guarded by if (Environment.UserInteractive) which currently always returns false. I have put a FIXME comment at both places in the code where this is done. If there is a better way to implement this, please let me know. This is trick you will have to try to implement it correctly yourself or ask runtime guys to do it. My understanding is that you want to terminate the process without missing any catch/finally clause but without throwing an exception (could be captured at higher level and stop the shutdown). Good work, you can commit the patch after the minor fixes. Thanks Marek Kind regards Chris Marek Safar wrote: Hello, Few comments from me - All code is #if NET_4_0 there is no need for further nested #if - Why did you have to introduce private exception classes ? Marek -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] Im Auftrag von Chris Bacon Gesendet: Mittwoch, 16. Juni 2010 12:03 An: Marek Safar Cc: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Patch 1/2 - System.Diagnostics.Contracts in corlib Hi, Attached is a new, improved, patch that keeps existing formatting. Sorry for the mistake. Kind regards Chris Marek Safar wrote: Hi Chris, Attached is a patch to corlib containing updates the System.Diagnostics.Contracts as part of the GSoC work I am doing. I'm sure there will be parts of this I haven't done quite right, so please let me know what they are, and I'll sort them out. Can you keep existing formatting, most of the changes are about changing tabs to spaces. Please send a new set of patches without any noise (lines you have not changed) Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch 2/2 - Tests for System.Diagnostics.Contracts in corlib
Hello Chris, Only a few small issues +#define CONTRACTS_FULL +#define DEBUG + Undefined these at the end of each file. They perhaps should be inside #if NET_4_0 too. +// Required when compiling/running under .NET3.5 +delegate void ActionT1, T2, T3, T4, T5 (T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5); + Why is it needed when NET_4_0 is used for whole file ? When fixed please commit. Thanks! Marek Hi, I've attached a new patch with slightly better formatting - it uses tabs rather than spaces. Kind regards Chris Chris Bacon wrote: Hi, Here are the tests to add to corlib for System.Diagnostics.Contracts. Please let me know what changes are required. Kind regards Chris ___ 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] Patch 1/2 - System.Diagnostics.Contracts in corlib
Hello, Few comments from me - All code is #if NET_4_0 there is no need for further nested #if - Why did you have to introduce private exception classes ? Marek -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] Im Auftrag von Chris Bacon Gesendet: Mittwoch, 16. Juni 2010 12:03 An: Marek Safar Cc: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Patch 1/2 - System.Diagnostics.Contracts in corlib Hi, Attached is a new, improved, patch that keeps existing formatting. Sorry for the mistake. Kind regards Chris Marek Safar wrote: Hi Chris, Attached is a patch to corlib containing updates the System.Diagnostics.Contracts as part of the GSoC work I am doing. I'm sure there will be parts of this I haven't done quite right, so please let me know what they are, and I'll sort them out. Can you keep existing formatting, most of the changes are about changing tabs to spaces. Please send a new set of patches without any noise (lines you have not changed) Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch 1/2 - System.Diagnostics.Contracts in corlib
Hi Chris, Attached is a patch to corlib containing updates the System.Diagnostics.Contracts as part of the GSoC work I am doing. I'm sure there will be parts of this I haven't done quite right, so please let me know what they are, and I'll sort them out. Can you keep existing formatting, most of the changes are about changing tabs to spaces. Please send a new set of patches without any noise (lines you have not changed) Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Patch applied Thanks ChangeLog: Don't make compiler generated classes sealed by default. Emit and close top level compiler generated classes as well. ReferenceEquality comparer: Use RuntimeHelpers.GetHashCode that is the default GetHashCode implementation based. (Also note that some SRE classes haven no support for GetHashCode in MS.NET.) Please review the patch. Thanks. Kornél ___ 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] Removing Obsolete Code from Mono 2.8
Hello, With the upcoming release of Mono 2.8 we are dropping the 1.0 profile as developers moved a long time ago to the generics-based 2.0 profile and because it is maintenance burden for us. In addition to this, I would like to stop distributing some libraries that were either never completed and are not being actively maintained. We could move these libraries to a separate module if people would like to maintain them or keep distributing them. Here is what I have in mind: * Drop Microsoft.JScript and `mjs' We should drop Microsoft.Vsa as well then. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Hello Kornél, Don't make compiler generated classes sealed by default. What is benefit of not doing that? This is also related to the same class because that was explicitly removing the sealed modifier to enable the static modifier. Although currently only a single compiler generated class benefits from both of these modifications I don't see any drawbacks and in my opinion the changes result in a more properly designed compiler generated class infrastructure. I am not sure what does more properly designed compiler generated class infrastructure mean but removing sealed from other generated classes it's not. The fix should be to add a new overload to avoid clearing the sealed flag. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Hi Kornél, ChangeLog: Don't make compiler generated classes sealed by default. What is benefit of not doing that? Emit and close top level compiler generated classes as well. They are already closed. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Moonlight project compile error in MonoDevelop
Hello Peter, I'm running Mono Develop 2.2.1 on openSUSE 11.1 (the VM from the mono tools distribution) and trying to compile a moonlight c# project. I have copied moonlight distribution folder from my MAC and put it on /usr/lib. The project has a class file that derives from Stream and I get the following error: Commons.Utils/IO/MultiBufferStream.cs(38,38): Error CS0505: ` MultiBufferStream.Seek(long, System.IO.SeekOrigin)': cannot override because `System.IO.Stream.Seek(long, int)' is not a method (CS0505) (Commons.Utils.SL) Please fill a bug report with explanation how to reproduce the issue. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
