[Mono-dev] PR 1359: System.Web.HttpApplication: set StatusCode = 500 when we send an exception to the client
Hi, when we get an exception in InitOnce (in HttpApplication), we send this exception to the browser, without changing StatusCode so we get a wonderful http 200. I've checked and it's the only place where we call FinalErrorWrite and we didn't set StatusCode. https://github.com/mono/mono/pull/1359 Bye Etienne ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] elimination of TARGET_J2EE/TARGET_JVM ?
Hi, Is TARGET_J2EE still in use (and TARGET_JVM), because it really complicate some class? Thanks in advance Etienne ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] elimination of TARGET_J2EE/TARGET_JVM ?
I removed TARGET_JVM with https://github.com/mono/mono/pull/1200, do you still see it somewhere? TARGET_J2EE should be removed too I guess. -- Alex -- View this message in context: http://mono.1490590.n4.nabble.com/elimination-of-TARGET-J2EE-TARGET-JVM-tp4664347p4664348.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] elimination of TARGET_J2EE/TARGET_JVM ?
Hi 2014-10-24 12:37 GMT+02:00 akoeplinger alex.koeplin...@outlook.com: I removed TARGET_JVM with https://github.com/mono/mono/pull/1200, do you still see it somewhere? No (except in changelogs). Writing about TARGET_J2EE i remembered that there was also a TARGET_JVM, so I asked about it in my email without checking TARGET_J2EE should be removed too I guess. I'm reading horrible code right now because TARGET_J2EE doesn't support volatile or synchronised hashtable or -- Alex Etienne ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Replacing missing monolite 110 archive ?
Hi, I'm nearly at the point where I can build mono win32 under Appeyor CI. I'm trying to understand why there appears to be no mono.exe installed, as a prelude to packaging up the build. To do this I am trying to build the latest official release 3.2.3 but this fails without monolite and I cannot get-monolite-latest as the 110 archive for corlib 110 has been removed. Would it be possible to replace the missing monolite-110-latest.tar.gz on the Xamarin site to facilite building of older Mono versions? Thanks, Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] elimination of TARGET_J2EE/TARGET_JVM ?
I think I remember seeing a load of ifdefs for j2ee in Httpapplication. On 24 Oct 2014 11:58, Etienne Champetier champetier.etie...@gmail.com wrote: Hi 2014-10-24 12:37 GMT+02:00 akoeplinger alex.koeplin...@outlook.com: I removed TARGET_JVM with https://github.com/mono/mono/pull/1200, do you still see it somewhere? No (except in changelogs). Writing about TARGET_J2EE i remembered that there was also a TARGET_JVM, so I asked about it in my email without checking TARGET_J2EE should be removed too I guess. I'm reading horrible code right now because TARGET_J2EE doesn't support volatile or synchronised hashtable or -- Alex Etienne ___ 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] elimination of TARGET_J2EE/TARGET_JVM ?
2014-10-24 13:32 GMT+02:00 Martin Thwaites mar...@my2cents.co.uk: I think I remember seeing a load of ifdefs for j2ee in Httpapplication. That's exactly where i am On 24 Oct 2014 11:58, Etienne Champetier champetier.etie...@gmail.com wrote: Hi 2014-10-24 12:37 GMT+02:00 akoeplinger alex.koeplin...@outlook.com: I removed TARGET_JVM with https://github.com/mono/mono/pull/1200, do you still see it somewhere? No (except in changelogs). Writing about TARGET_J2EE i remembered that there was also a TARGET_JVM, so I asked about it in my email without checking TARGET_J2EE should be removed too I guess. I'm reading horrible code right now because TARGET_J2EE doesn't support volatile or synchronised hashtable or -- Alex Etienne ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PR 1359: System.Web.HttpApplication: set StatusCode = 500 when we send an exception to the client
2014-10-24 13:53 GMT+02:00 Etienne Champetier champetier.etie...@gmail.com
:
I know nothing about customerrors,
but we are in the init so we may have fail to parse the config,
so using customerror here is dangerous
Exception e = initialization_exception; HttpException exc =
HttpException.NewWithCode (String.Empty, e,
WebEventCodes.RuntimeErrorRequestAbort); + context.Response.StatusCode =
500; FinalErrorWrite (context.Response, exc.GetHtmlErrorMessage ());
PipelineDone
(); return;
static void FinalErrorWrite (HttpResponse response, string error) { try
{ response.Write (error); response.Flush (true); } catch { response.
Close (); } }
The only think that i'm sure of is that we are sending an exception with
http 200 :)
I can replace 500 with exc.GetHttpCode() if you prefer?
Forget about this, this will send 501 Not Implemented, i prefer 500
2014-10-24 13:33 GMT+02:00 Martin Thwaites mar...@my2cents.co.uk:
Does this need to take into account the customerrors setting in the
Web.config or is that handled further down the pipeline?
On 24 Oct 2014 09:57, Etienne Champetier champetier.etie...@gmail.com
wrote:
Hi,
when we get an exception in InitOnce (in HttpApplication), we send this
exception to the browser, without changing StatusCode so we get a wonderful
http 200.
I've checked and it's the only place where we call FinalErrorWrite and
we didn't set StatusCode.
https://github.com/mono/mono/pull/1359
Bye
Etienne
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PR 1359: System.Web.HttpApplication: set StatusCode = 500 when we send an exception to the client
Is this something that we can unit test to verify against .Net?
On 24 Oct 2014 13:26, Etienne Champetier champetier.etie...@gmail.com
wrote:
2014-10-24 13:53 GMT+02:00 Etienne Champetier
champetier.etie...@gmail.com:
I know nothing about customerrors,
but we are in the init so we may have fail to parse the config,
so using customerror here is dangerous
Exception e = initialization_exception; HttpException exc =
HttpException.NewWithCode (String.Empty, e,
WebEventCodes.RuntimeErrorRequestAbort); + context.Response.StatusCode
= 500; FinalErrorWrite (context.Response, exc.GetHtmlErrorMessage ());
PipelineDone
(); return;
static void FinalErrorWrite (HttpResponse response, string error) { try
{ response.Write (error); response.Flush (true); } catch { response.
Close (); } }
The only think that i'm sure of is that we are sending an exception with
http 200 :)
I can replace 500 with exc.GetHttpCode() if you prefer?
Forget about this, this will send 501 Not Implemented, i prefer 500
2014-10-24 13:33 GMT+02:00 Martin Thwaites mar...@my2cents.co.uk:
Does this need to take into account the customerrors setting in the
Web.config or is that handled further down the pipeline?
On 24 Oct 2014 09:57, Etienne Champetier champetier.etie...@gmail.com
wrote:
Hi,
when we get an exception in InitOnce (in HttpApplication), we send this
exception to the browser, without changing StatusCode so we get a wonderful
http 200.
I've checked and it's the only place where we call FinalErrorWrite and
we didn't set StatusCode.
https://github.com/mono/mono/pull/1359
Bye
Etienne
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PR 1362: Webapp stuck with Key duplication when adding: httpModules
Hi, 4 commits in this PR, 1 that should fix the race condition that lead to the exception, 3 improvements. https://github.com/mono/mono/pull/1362 Etienne ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Memleak in mono_domain_unload
Hello to all, I noticed that mono_domain_unload is leaking memory. I wrote a small test in my application where I create a domain, load an assembly into it, execute the C# main which does nothing and then call mono_domain_unload. The assembly and all its references are loaded with mono_image_open_from_data. It seems like Unity somehow solved this problem. Is there any work to fix this? Or any hint for me? Best regards Sahin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] elimination of TARGET_J2EE/TARGET_JVM ?
They are no longer in use but we're not in a rush to remove the from the code base. If it's making it hard for you to read a piece of code, remove them and submit a pull request - we'd love to kill more of those defines. :) On Fri, Oct 24, 2014 at 2:10 AM, Etienne Champetier champetier.etie...@gmail.com wrote: Hi, Is TARGET_J2EE still in use (and TARGET_JVM), because it really complicate some class? Thanks in advance Etienne ___ 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] Memleak in mono_domain_unload
Please file a bug report with your test case so we can fix any leaks. On Fri, Oct 24, 2014 at 7:56 AM, Vardar Sahin sakirs...@gmail.com wrote: Hello to all, I noticed that mono_domain_unload is leaking memory. I wrote a small test in my application where I create a domain, load an assembly into it, execute the C# main which does nothing and then call mono_domain_unload. The assembly and all its references are loaded with mono_image_open_from_data. It seems like Unity somehow solved this problem. Is there any work to fix this? Or any hint for me? Best regards Sahin ___ 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
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
Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles
Hi Miguel, I think my preference would be to have the 3.x.x series continue (as security fix only) with all the profiles, and essentially have it be a legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base. I think it should continue if people are willing to support it, but the contributors who don't want to have to support it (or don't have the time to implement hacks for it) don't have to. From a communication perspective it would be easier to get across saying that From mono 4.0 onwards, we only support the 4.5 profile rather than 3.11.x onwards as it's not as easy to remember which 3.x number it was when it stopped. A decision and a change like that does really feel major and therefore warrant the change. The other question I have is around the linux distros that ship mono as standard (I think Ubuntu does). Do you perceive this having an affect on them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0 applications and there are some core pieces that rely on it? Thanks, Martin On 22 October 2014 22:18, Miguel de Icaza mig...@xamarin.com wrote: Hey, Mhm, that is a good idea. Will think about it. Right now we were just planning on calling the next one Mono 3.12. But perhaps the time has come for a nice bump! Miguel On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Would you be looking at calling this Mono 4.0? Not that it makes any difference really, it just seems there's been a lot of improvements in recently, and an announcement of a new version me give some renewed interest. Thanks, Martin On 22 October 2014 21:10, Miguel de Icaza mig...@xamarin.com wrote: Hey Alex, It is very repetitive work, so what I wanted to do was to write a perl script to remove the *obvious* ifdefs. The tool would remove only those that match the following criteria (more or less): - Remove toplevel #if NET_2_0 with the final #endif - Only remove those that contain those preprocessor directives And then have a human do the more fine-tuned approach. There are a couple more defines that I remember could be automated, but I would love to have this in the form of a script. I am afraid of applying a patch like that blindly, because there are no exact guarantees of what happened without reviewing the whole file. So a script with the invariants would take a lot of my nervousness out. Also, when I did it once, I had a setup where I rebuilt the assemblies and compared the output. This would ensure that removal of ifdefs did not change the resulting binaries. On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com wrote: Sounds like a good thing ;-) I've got a branch in my fork where I removed the NET_2_0 ifdefs: https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera told me a while ago that removing the 2.0 profile is on the horizon when I asked about why the ifdefs are still there. I refrained from making a PR so far because it is quite huge, do you think now would be a good time? -- Alex -- View this message in context: http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.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] Heads up: Elimination of the 2.0 and 4.0 profiles
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))? 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
Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles
Hello Martin, There is no such thing as a 3.x.x series. It does not exist. It never did. You must be confused. Miguel On Fri, Oct 24, 2014 at 12:34 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, I think my preference would be to have the 3.x.x series continue (as security fix only) with all the profiles, and essentially have it be a legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base. I think it should continue if people are willing to support it, but the contributors who don't want to have to support it (or don't have the time to implement hacks for it) don't have to. From a communication perspective it would be easier to get across saying that From mono 4.0 onwards, we only support the 4.5 profile rather than 3.11.x onwards as it's not as easy to remember which 3.x number it was when it stopped. A decision and a change like that does really feel major and therefore warrant the change. The other question I have is around the linux distros that ship mono as standard (I think Ubuntu does). Do you perceive this having an affect on them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0 applications and there are some core pieces that rely on it? Thanks, Martin On 22 October 2014 22:18, Miguel de Icaza mig...@xamarin.com wrote: Hey, Mhm, that is a good idea. Will think about it. Right now we were just planning on calling the next one Mono 3.12. But perhaps the time has come for a nice bump! Miguel On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Would you be looking at calling this Mono 4.0? Not that it makes any difference really, it just seems there's been a lot of improvements in recently, and an announcement of a new version me give some renewed interest. Thanks, Martin On 22 October 2014 21:10, Miguel de Icaza mig...@xamarin.com wrote: Hey Alex, It is very repetitive work, so what I wanted to do was to write a perl script to remove the *obvious* ifdefs. The tool would remove only those that match the following criteria (more or less): - Remove toplevel #if NET_2_0 with the final #endif - Only remove those that contain those preprocessor directives And then have a human do the more fine-tuned approach. There are a couple more defines that I remember could be automated, but I would love to have this in the form of a script. I am afraid of applying a patch like that blindly, because there are no exact guarantees of what happened without reviewing the whole file. So a script with the invariants would take a lot of my nervousness out. Also, when I did it once, I had a setup where I rebuilt the assemblies and compared the output. This would ensure that removal of ifdefs did not change the resulting binaries. On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com wrote: Sounds like a good thing ;-) I've got a branch in my fork where I removed the NET_2_0 ifdefs: https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera told me a while ago that removing the 2.0 profile is on the horizon when I asked about why the ifdefs are still there. I refrained from making a PR so far because it is quite huge, do you think now would be a good time? -- Alex -- View this message in context: http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.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] Heads up: Elimination of the 2.0 and 4.0 profiles
I can not answer that question, as I am not familiar with the situation, and it seems like you are as confused as I am. There wont be 2.0 reference assemblies anymore. Miguel On Fri, Oct 24, 2014 at 2:05 PM, Sergey Zhukov s...@ngs.ru wrote: 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))? 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
Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles
To make things clear, I had to make a small adjustment to https://github.com/fanf2/unifdef so it didn't complain about C# multiline strings. I had to remove this else if: https://github.com/fanf2/unifdef/blob/90ca2eee76db715943ec4b7ca2892d155ca64075/unifdef.c#L1216-L1220, then it ran fine on the Mono codebase. -- Alex -- View this message in context: http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664367.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles
Hi Miguel, I'm referring to 3.9, 3.10.1, etc. i.e. the current version being 3.10.1. So I guess it should be considered the 3.x series. I'm meaning that we shouldn't preclude there being a 3.11, or 3.12, if there is a critical bug. Also, do you have an answer to the distro question? Thanks, Martin On 24 October 2014 19:13, Miguel de Icaza mig...@xamarin.com wrote: Hello Martin, There is no such thing as a 3.x.x series. It does not exist. It never did. You must be confused. Miguel On Fri, Oct 24, 2014 at 12:34 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, I think my preference would be to have the 3.x.x series continue (as security fix only) with all the profiles, and essentially have it be a legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base. I think it should continue if people are willing to support it, but the contributors who don't want to have to support it (or don't have the time to implement hacks for it) don't have to. From a communication perspective it would be easier to get across saying that From mono 4.0 onwards, we only support the 4.5 profile rather than 3.11.x onwards as it's not as easy to remember which 3.x number it was when it stopped. A decision and a change like that does really feel major and therefore warrant the change. The other question I have is around the linux distros that ship mono as standard (I think Ubuntu does). Do you perceive this having an affect on them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0 applications and there are some core pieces that rely on it? Thanks, Martin On 22 October 2014 22:18, Miguel de Icaza mig...@xamarin.com wrote: Hey, Mhm, that is a good idea. Will think about it. Right now we were just planning on calling the next one Mono 3.12. But perhaps the time has come for a nice bump! Miguel On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Would you be looking at calling this Mono 4.0? Not that it makes any difference really, it just seems there's been a lot of improvements in recently, and an announcement of a new version me give some renewed interest. Thanks, Martin On 22 October 2014 21:10, Miguel de Icaza mig...@xamarin.com wrote: Hey Alex, It is very repetitive work, so what I wanted to do was to write a perl script to remove the *obvious* ifdefs. The tool would remove only those that match the following criteria (more or less): - Remove toplevel #if NET_2_0 with the final #endif - Only remove those that contain those preprocessor directives And then have a human do the more fine-tuned approach. There are a couple more defines that I remember could be automated, but I would love to have this in the form of a script. I am afraid of applying a patch like that blindly, because there are no exact guarantees of what happened without reviewing the whole file. So a script with the invariants would take a lot of my nervousness out. Also, when I did it once, I had a setup where I rebuilt the assemblies and compared the output. This would ensure that removal of ifdefs did not change the resulting binaries. On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com wrote: Sounds like a good thing ;-) I've got a branch in my fork where I removed the NET_2_0 ifdefs: https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera told me a while ago that removing the 2.0 profile is on the horizon when I asked about why the ifdefs are still there. I refrained from making a PR so far because it is quite huge, do you think now would be a good time? -- Alex -- View this message in context: http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.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] Heads up: Elimination of the 2.0 and 4.0 profiles
Ah, I see. Yeah, perhaps we will move to the 4.0 branding, just need to check with folks around here what they think. For distros: nobody in the Linux world really ever cared about this. We kept these profiles with the idea that this was something that actually mattered, and it turns out, it rarely did (in particular in Linux where things are built from scratch) On Fri, Oct 24, 2014 at 3:11 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, I'm referring to 3.9, 3.10.1, etc. i.e. the current version being 3.10.1. So I guess it should be considered the 3.x series. I'm meaning that we shouldn't preclude there being a 3.11, or 3.12, if there is a critical bug. Also, do you have an answer to the distro question? Thanks, Martin On 24 October 2014 19:13, Miguel de Icaza mig...@xamarin.com wrote: Hello Martin, There is no such thing as a 3.x.x series. It does not exist. It never did. You must be confused. Miguel On Fri, Oct 24, 2014 at 12:34 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, I think my preference would be to have the 3.x.x series continue (as security fix only) with all the profiles, and essentially have it be a legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base. I think it should continue if people are willing to support it, but the contributors who don't want to have to support it (or don't have the time to implement hacks for it) don't have to. From a communication perspective it would be easier to get across saying that From mono 4.0 onwards, we only support the 4.5 profile rather than 3.11.x onwards as it's not as easy to remember which 3.x number it was when it stopped. A decision and a change like that does really feel major and therefore warrant the change. The other question I have is around the linux distros that ship mono as standard (I think Ubuntu does). Do you perceive this having an affect on them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0 applications and there are some core pieces that rely on it? Thanks, Martin On 22 October 2014 22:18, Miguel de Icaza mig...@xamarin.com wrote: Hey, Mhm, that is a good idea. Will think about it. Right now we were just planning on calling the next one Mono 3.12. But perhaps the time has come for a nice bump! Miguel On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Miguel, Would you be looking at calling this Mono 4.0? Not that it makes any difference really, it just seems there's been a lot of improvements in recently, and an announcement of a new version me give some renewed interest. Thanks, Martin On 22 October 2014 21:10, Miguel de Icaza mig...@xamarin.com wrote: Hey Alex, It is very repetitive work, so what I wanted to do was to write a perl script to remove the *obvious* ifdefs. The tool would remove only those that match the following criteria (more or less): - Remove toplevel #if NET_2_0 with the final #endif - Only remove those that contain those preprocessor directives And then have a human do the more fine-tuned approach. There are a couple more defines that I remember could be automated, but I would love to have this in the form of a script. I am afraid of applying a patch like that blindly, because there are no exact guarantees of what happened without reviewing the whole file. So a script with the invariants would take a lot of my nervousness out. Also, when I did it once, I had a setup where I rebuilt the assemblies and compared the output. This would ensure that removal of ifdefs did not change the resulting binaries. On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com wrote: Sounds like a good thing ;-) I've got a branch in my fork where I removed the NET_2_0 ifdefs: https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera told me a while ago that removing the 2.0 profile is on the horizon when I asked about why the ifdefs are still there. I refrained from making a PR so far because it is quite huge, do you think now would be a good time? -- Alex -- View this message in context: http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.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] Heads up: Elimination of the 2.0 and 4.0 profiles
Is everything from 4.0 on the correct side currently there? I have seen this cause confusion in the past for many thinking the version numbers somehow match up :) On Friday, October 24, 2014, Miguel de Icaza mig...@xamarin.com wrote: Ah, I see. Yeah, perhaps we will move to the 4.0 branding, just need to check with folks around here what they think. For distros: nobody in the Linux world really ever cared about this. We kept these profiles with the idea that this was something that actually mattered, and it turns out, it rarely did (in particular in Linux where things are built from scratch) On Fri, Oct 24, 2014 at 3:11 PM, Martin Thwaites monofo...@my2cents.co.uk javascript:_e(%7B%7D,'cvml','monofo...@my2cents.co.uk'); wrote: Hi Miguel, I'm referring to 3.9, 3.10.1, etc. i.e. the current version being 3.10.1. So I guess it should be considered the 3.x series. I'm meaning that we shouldn't preclude there being a 3.11, or 3.12, if there is a critical bug. Also, do you have an answer to the distro question? Thanks, Martin On 24 October 2014 19:13, Miguel de Icaza mig...@xamarin.com javascript:_e(%7B%7D,'cvml','mig...@xamarin.com'); wrote: Hello Martin, There is no such thing as a 3.x.x series. It does not exist. It never did. You must be confused. Miguel On Fri, Oct 24, 2014 at 12:34 PM, Martin Thwaites monofo...@my2cents.co.uk javascript:_e(%7B%7D,'cvml','monofo...@my2cents.co.uk'); wrote: Hi Miguel, I think my preference would be to have the 3.x.x series continue (as security fix only) with all the profiles, and essentially have it be a legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base. I think it should continue if people are willing to support it, but the contributors who don't want to have to support it (or don't have the time to implement hacks for it) don't have to. From a communication perspective it would be easier to get across saying that From mono 4.0 onwards, we only support the 4.5 profile rather than 3.11.x onwards as it's not as easy to remember which 3.x number it was when it stopped. A decision and a change like that does really feel major and therefore warrant the change. The other question I have is around the linux distros that ship mono as standard (I think Ubuntu does). Do you perceive this having an affect on them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0 applications and there are some core pieces that rely on it? Thanks, Martin On 22 October 2014 22:18, Miguel de Icaza mig...@xamarin.com javascript:_e(%7B%7D,'cvml','mig...@xamarin.com'); wrote: Hey, Mhm, that is a good idea. Will think about it. Right now we were just planning on calling the next one Mono 3.12. But perhaps the time has come for a nice bump! Miguel On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites monofo...@my2cents.co.uk javascript:_e(%7B%7D,'cvml','monofo...@my2cents.co.uk'); wrote: Hi Miguel, Would you be looking at calling this Mono 4.0? Not that it makes any difference really, it just seems there's been a lot of improvements in recently, and an announcement of a new version me give some renewed interest. Thanks, Martin On 22 October 2014 21:10, Miguel de Icaza mig...@xamarin.com javascript:_e(%7B%7D,'cvml','mig...@xamarin.com'); wrote: Hey Alex, It is very repetitive work, so what I wanted to do was to write a perl script to remove the *obvious* ifdefs. The tool would remove only those that match the following criteria (more or less): - Remove toplevel #if NET_2_0 with the final #endif - Only remove those that contain those preprocessor directives And then have a human do the more fine-tuned approach. There are a couple more defines that I remember could be automated, but I would love to have this in the form of a script. I am afraid of applying a patch like that blindly, because there are no exact guarantees of what happened without reviewing the whole file. So a script with the invariants would take a lot of my nervousness out. Also, when I did it once, I had a setup where I rebuilt the assemblies and compared the output. This would ensure that removal of ifdefs did not change the resulting binaries. On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com javascript:_e(%7B%7D,'cvml','alex.koeplin...@outlook.com'); wrote: Sounds like a good thing ;-) I've got a branch in my fork where I removed the NET_2_0 ifdefs: https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera told me a while ago that removing the 2.0 profile is on the horizon when I asked about why the ifdefs are still there. I refrained from making a PR so far because it is quite huge, do you think now would be a good time? -- Alex -- View this message in context: http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html Sent from the Mono - Dev mailing
[Mono-dev] InvalidCastException - which makes no sense
This is a fun one. I'd love it if anyone could explain this to me.
using (var command = new SqliteCommand(@SELECT COUNT(*) FROM someTable WHERE
someColumn = @someValue , dbConn))
{
command.Parameters.Add(new SqliteParameter(someValue, foobar));
object scalar = command.ExecuteScalar();// object returned has type
Int64
Int64 count64 = (Int64)(scalar); // works
fine. Value is 0
Int32 count32 = (Int32)(Int64)(scalar);// works fine.
Value is 0
Int32 count = (Int32)(scalar); // throws
InvalidCastException
...
}
In the above, scalar is obviously an object, but the object returned by
ExecuteScalar() is of type Int64. The value is 0.
This works fine:
Int64 count64 = (Int64)(scalar);
This works fine:
Int32 count32 = (Int32)(Int64)(scalar);
This throws InvalidCastException:
Int32 count = (Int32)(scalar);
The best I can gather, the object needs to be cast to Int64 before it can be
cast to Int32. Which makes no sense to me, but that's the way it is.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] InvalidCastException - which makes no sense
Hello,
What happens is this. The value returned from ExecuteScalar is boxed.
This basically means that you have a wrapper that indicates the type of the
boxed object, as well as the contents of the boxed object.
The reality is that: (Int64) (scalar) and (Int32) (Int64) (scalar) perform
different operations on this context.
This is what actually happens on the second case:
tmp = Unbox-the-value-which-i-know-is-a-64-bit-value (scalar)
tmp32 = explicit-cast-64-to-32 tmp
They happen to have the same syntax, but they are different operations.
When you tried doing (Int32) scalar, you were telling the compiler
unbox-the-value-which-i-know-is-32-bit-value, but when the runtime went
to unbox this, it noticed it was 64, so it told you InvalidCastException
On Fri, Oct 24, 2014 at 5:23 PM, Edward Ned Harvey (mono)
edward.harvey.m...@clevertrove.com wrote:
This is a fun one. I'd love it if anyone could explain this to me.
using (var command = new SqliteCommand(@SELECT COUNT(*) FROM someTable
WHERE someColumn = @someValue , dbConn))
{
command.Parameters.Add(new SqliteParameter(someValue, foobar));
object scalar = command.ExecuteScalar();// object returned has
type Int64
Int64 count64 = (Int64)(scalar); // works
fine. Value is 0
Int32 count32 = (Int32)(Int64)(scalar);// works fine.
Value is 0
Int32 count = (Int32)(scalar); // throws
InvalidCastException
...
}
In the above, scalar is obviously an object, but the object returned by
ExecuteScalar() is of type Int64. The value is 0.
This works fine:
Int64 count64 = (Int64)(scalar);
This works fine:
Int32 count32 = (Int32)(Int64)(scalar);
This throws InvalidCastException:
Int32 count = (Int32)(scalar);
The best I can gather, the object needs to be cast to Int64 before it can
be cast to Int32. Which makes no sense to me, but that's the way it is.
___
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] InvalidCastException - which makes no sense
Eric Lippert has a good write up about this behavior:
http://blogs.msdn.com/b/ericlippert/archive/2009/03/19/representation-and-identity.aspx
On Oct 24, 2014, at 5:28 PM, Miguel de Icaza mig...@xamarin.com wrote:
Hello,
What happens is this. The value returned from ExecuteScalar is boxed.
This basically means that you have a wrapper that indicates the type of the
boxed object, as well as the contents of the boxed object.
The reality is that: (Int64) (scalar) and (Int32) (Int64) (scalar) perform
different operations on this context.
This is what actually happens on the second case:
tmp = Unbox-the-value-which-i-know-is-a-64-bit-value (scalar)
tmp32 = explicit-cast-64-to-32 tmp
They happen to have the same syntax, but they are different operations.
When you tried doing (Int32) scalar, you were telling the compiler
unbox-the-value-which-i-know-is-32-bit-value, but when the runtime went to
unbox this, it noticed it was 64, so it told you InvalidCastException
On Fri, Oct 24, 2014 at 5:23 PM, Edward Ned Harvey (mono)
edward.harvey.m...@clevertrove.com wrote:
This is a fun one. I'd love it if anyone could explain this to me.
using (var command = new SqliteCommand(@SELECT COUNT(*) FROM someTable
WHERE someColumn = @someValue , dbConn))
{
command.Parameters.Add(new SqliteParameter(someValue, foobar));
object scalar = command.ExecuteScalar();// object returned has
type Int64
Int64 count64 = (Int64)(scalar); // works
fine. Value is 0
Int32 count32 = (Int32)(Int64)(scalar);// works fine.
Value is 0
Int32 count = (Int32)(scalar); // throws
InvalidCastException
...
}
In the above, scalar is obviously an object, but the object returned by
ExecuteScalar() is of type Int64. The value is 0.
This works fine:
Int64 count64 = (Int64)(scalar);
This works fine:
Int32 count32 = (Int32)(Int64)(scalar);
This throws InvalidCastException:
Int32 count = (Int32)(scalar);
The best I can gather, the object needs to be cast to Int64 before it can be
cast to Int32. Which makes no sense to me, but that's the way it is.
___
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] InvalidCastException - which makes no sense
From: Miguel de Icaza [mailto:mig...@xamarin.com] What happens is this. The value returned from ExecuteScalar is boxed. This Got it, thanks. In fact, I simplified to this: Object foo = (Int64)0; Int64 foo64 = (Int64)foo; Int32 foo6432 = (Int32)(Int64)foo; Int32 foo32 = (Int32)foo; // Throws InvalidCastException And I confirmed the behavior is the same in .Net and Mono. So everything makes sense; it's just something I didn't know before. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Review of PR1363: MembershipPasswordAttribute
Hi All, This is part of the ongoing work for the aspnetwebstack. The only thing it's missing is tests around the PasswordStrength regex, however, I'm no good with regex so maybe someone can give me some to add to the test and valid/invalid strings to test against? I'm also hoping that the approach to testing this is ok. Finally, I've done some changes in the formatting a few times, but it's getting to the point where I can't see anything as I've looked at it too much. Please can someone give it a quick look over? Tests pass on Windows and Linux, I don't have a Mac to test it on but it doesn't do anything special. https://github.com/mono/mono/pull/1363 Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
