Re: [Mono-dev] Support 2-args Socket ctor added in .NET 4.5

2014-10-26 Thread Kornel Pal 

Hi,

This is possible on Unix (and Windows) using the IPV6_V6ONLY socket 
option. I'm not sure however about how widely this is adopted.


Kornel

On 10/26/2014 5:01 AM, Miguel de Icaza wrote:
I am not sure that Unix can support the idiom surfaced by the 
two-parameter Socket.


If K wants to be cross platform, it likely needs to create two 
separate sockets, one for each domain, and not assume that you can 
create a single socket that can be used with multiple domains at once.


Miguel

On Sat, Oct 25, 2014 at 10:38 AM, Kei Nakazawa > wrote:


Hello,

I noticed some test code of Kestrel (web server for ASP.NET
 vNext) fails to compile on Linux hosts.

/kestrel/test/Microsoft.AspNet.Server.KestrelTests/EngineTests.cs(325,34):
error CS1729: 'Socket' does not contain a constructor that takes 2
arguments
ref:

https://github.com/aspnet/KestrelHttpServer/blob/dev/test/Microsoft.AspNet.Server.KestrelTests/EngineTests.cs#L325

It's because 2 args ctor is a new one introduced in .NET 4.5 and
not currently exist on Mono. I found a bugzilla entry mentioning
this issue: https://bugzilla.xamarin.com/show_bug.cgi?id=20048 and
dug Mono code for finding solutions.

After couple of minutes of investigation, I gave up to write a
"clean" dual stack (IPv4/v6) support and wrote a simple proxy ctor:
https://github.com/mono/mono/pull/1364/files (Thanks @martinjt for
reviewing my pull-req.)

As I don't see any demands for IPv4/v6 dual stack support around
ASP.NET  vNext community, I believe hard-coding
protocol version to v4 is just enough and better than nothing at
least for now (of course, full support of dual stack would be great).

Any comments/feedback are welcomed.

Regards, Kei.

___
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

[Mono-dev] PR #1365: [asp.net] Implement the EventHandlerTaskAsyncHelper and HttpTaskAsyncHandler classes

2014-10-26 Thread Kornel Pal 

Hi,

Inspired by the ASP.NET 4.5 Async Pipeline email thread started by 
Martin Thwaites, I realized that there actually is no new async pipeline 
in ASP.NET 4.5, it merely provides wrappers around tasks to ease 
interfacing with the old async pipeline.


I've looked around a bit, but found no suitable implementation for the 
wrapper, so I've created several unit tests to figure out the MS.NET 
behavior. At the end I came up with TaskAsyncResult, a general purpose 
TAP to APM wrapper.


Please review my pull request: https://github.com/mono/mono/pull/1365

Thank you.

Kornel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] PR #1367: [build] Enable dolt on mingw32

2014-10-26 Thread Kornel Pal 

Hi,

Enable dolt on mingw32, something I miss since the change to targeting 
mingw32.


Please review my pull request: https://github.com/mono/mono/pull/1367

Thank you.

Kornel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] PR #1365: [asp.net] Implement the EventHandlerTaskAsyncHelper and HttpTaskAsyncHandler classes

2014-10-26 Thread Kornel Pal 

Hi,

I've found this, that fits Miguel's description:
http://stackoverflow.com/questions/9562836/whats-the-meaning-of-usetaskfriendlysynchronizationcontext

My PR is is independent of any such changes, and given the API design, I 
would be surprised if MS implemented some special handling of these classes.


As for your requirements, I would give aspnetwebstack a try with the 
current pipeline before refactoring the request processing pipeline.


Thank you.

Kornel

On 10/26/2014 2:50 PM, Martin Thwaites wrote:

Hi Miguel,

Does that have implications in regards to this PR? i.e. is it just 
that it doesn't solve the problem, or that the implementation here is 
wrong?


Thanks,
Martin

On 26 October 2014 13:46, Miguel de Icaza <mailto:mig...@xamarin.com>> wrote:


Hello,

The asynchronous pipeline was discussed in various
blogs/interviews.   Some switch enables apparently an entirely
different flow inside asp.net <http://asp.net>.  The surface
changes were minimal, which is why you won't likely find an API.


On Sunday, October 26, 2014, Kornel Pal mailto:kornel...@gmail.com>> wrote:

Hi,

Inspired by the ASP.NET <http://ASP.NET> 4.5 Async Pipeline
email thread started by Martin Thwaites, I realized that there
actually is no new async pipeline in ASP.NET <http://ASP.NET>
4.5, it merely provides wrappers around tasks to ease
interfacing with the old async pipeline.

I've looked around a bit, but found no suitable implementation
for the wrapper, so I've created several unit tests to figure
out the MS.NET <http://MS.NET> behavior. At the end I came up
with TaskAsyncResult, a general purpose TAP to APM wrapper.

Please review my pull request:
https://github.com/mono/mono/pull/1365

Thank you.

Kornel
___
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
<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

Re: [Mono-dev] State of aspnetwebstack on mono

2014-11-02 Thread Kornel Pal 

Hi,

I've noticed that new functionality is going into the wrappers, while in 
my opinion that the functionality belongs to HttpRequest and HttpResponse:


 * HttpRequestBase.ReadEntityBodyMode: returning 0 instead of
   ReadEntityBodyMode.Classic made more sense
 * HttpRequestWrapper.ReadEntityBodyMode: wrapper is not supposed to
   implement functionality, that belongs to HttpRequest
 * HttpRequestWrapper.Abort: wrapper is not supposed to implement
   functionality, that belongs to HttpRequest
 * HttpResponseWrapper.ClientDisconnectedToken: wrapper is not supposed
   to implement functionality, that belongs to HttpResponse

As for the GetBuffer* methods:

 * Mono already implements HttpRequest.GetBufferlessInputStream, so
   hard coding ReadEntityBodyMode.Classic limits Mono's compatibility
 * Implementing GetBufferedInputStream based on the existing
   GetBufferlessInputStream implementation doesn't seem to be too difficult
 * HttpWorkerRequest in 4.5 has support for asynchronous operations,
   but that does not have to be implemented for this to work because
   the Stream base class implements async operations using the sync methods

Thank you.

Kornel

On 11/2/2014 1:52 AM, Miguel de Icaza wrote:


/
/
PR1349: https://github.com/mono/mono/pull/1349
/This is the machine key work, and needs a small tweak before it
can be merged that I will do this week.
/


I believe the TODO can be removed.   Can you do that? See comments on 
pull request.


PR1363: https://github.com/mono/mono/pull/1363
/Another of mine with the MembershipPasswordAttribute
/


Do you mind resending this?  It can no longer be auto-merged from the UI.

PR1365: https://github.com/mono/mono/pull/1365
/This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel
has said he'll take a look at it.
/


Manually aded

PR1370: https://github.com/mono/mono/pull/1370
/Small one implementing a default of the ReadEntityBodyMode
/


Got this one by hand.

PR1371: https://github.com/mono/mono/pull/1371
/Another small one, implementing the ClientDisconnectedToken
/


And this one automatically.

PR1372: https://github.com/mono/mono/pull/1372
/A final small one around the GetBuffer* methods in the httprequest.
/


I do not like this one.  Is there a reason we can not implement the 
required functionality instead?


Miguel

There is 1 final small piece that either myself of Chris Carroll
will get done this week which is around the AppendTrailing slash
and lowercaseUrls properties in RouteBase class.  We just need to
put the implementation together.

Anyway, after applying all of these, my large WebAPI solution not
only compiles, but it also runs!

If you want to checkout what it looks like with all the patches
applied, that would be great, I'd love to have some more
information on whether it does work. I'm sure there will still be
bugs, but if it works mostly, then bug fixing is easy (famous last
words).

https://github.com/martinjt/mono/tree/mvc_allfixes

Thanks for everyone's help.

Martin

On 20 October 2014 20:42, Martin Thwaites
mailto:monofo...@my2cents.co.uk>> wrote:

Hi Miguel,

The code that I'm referring to here is that of the
aspnetwebstack on codeplex. That is to say that they are not
something where you can remove the code and recompile (unless
there as a specific mono implementation which is not ideal). 
The goal is to have the compiled dlls that are available on

nuget work, without tweaking to a person's application.

I'll have a look and see if I can see where it would be used,
but still as you've said on one of my pulls, a half done
implementation is better than none.

Having the application throw a missing method exception should
not be the recommended approach when we can add the property
and default it to false.

Thanks, and please don't think that things won't getting
better with my reviews. I'm learning what you want so I can
review better and help reduce the burden on you and your staff.

Martin

On 20 Oct 2014 20:04, "Miguel de Icaza" mailto:mig...@xamarin.com>> wrote:

As for the properties, although they should do
something to the generated urls, simply adding them
should surely be a valid pull?  the issue at the
moment is that without them, you get an exception even
if it should be false.  I actually think that these
are used by other classes when generating urls, not
the route collection itself, but I don't know for
sure.  Considering that adding them is very low risk,
can we not just accept the pull and ask for further work.

Nope, all they do is allow some code to be compile

Re: [Mono-dev] Crash course on bringing .NET open sourced code to Mono.

2014-11-15 Thread Kornel Pal 
Given these obstacles, I think that going forward with the originally 
announced plan of removing non-4.5 profile support from the current Mono 
code base - without introducing MS code yet - would make the gradual 
adoption of MS code much easer.


On 11/15/2014 2:11 PM, Miguel de Icaza wrote:

It hasn't.   When we do, we will announce.


Two issues: we worked with reference source and the github push is 
only slowly getting the bits.   And the second is that the layout they 
are pushing is different.


On Saturday, November 15, 2014, Martin Thwaites 
mailto:monofo...@my2cents.co.uk>> wrote:


So has it been merged yet?

I'm going to look at the Buffer stuff I shy'd away from before. 
Then look at the MachineKey.Protect stuff to implement the things

I missed.

I've got a separate question around the mismatch in conventions,
but I'll ask that on a different thread.

I'm struggling to contain my excitement at the moment!

Thanks,
Martin

On 15 November 2014 13:03, Miguel de Icaza > wrote:

Hello,

We worked only on System.Configuration, regex, the crypto and
web stack.

The rest you can do, including the web stack.

I took a look at asp.net . I think in the long
term we want to replace most of it, but it needs to be done in
stages, as it still contains a bunch of native stuff.m



Miguel

On Saturday, November 15, 2014, Martin Thwaites
> wrote:

Hi Miguel,

Is there an ETA on merging your "large fork".  I don't
want to get started on anything that you guys have already
done?

Or could you tell us which areas to stay away from for
now?  Personally, I would want to look at some of the
system.web things.

Thanks
Martin

On 15 Nov 2014 03:07, "Miguel de Icaza"
 wrote:

Hey guys,

Sami reached out to me, and was wondering how to get
started in bringing some code to Mono, in particular
WCF to Mono.   So I wrote this small guide for newcomers.

I would say it takes a couple of steps:

  * Build your own local version of Mono on Linux.
  * Make sure it works "mcs" should be able to run
after installing it.
  * Run a trivial self-hosted WCF server/client
  * Make a trivial change to the WCF class library,
and install this version to test you can make
changes locally and have them run:
  o cd mono/mcs/class/System.ServiceModel
  o Make changes
  o make install
  o Run your test again in another window
  o Repeat
  * Make sure you can run the test suite:
  o cd mono/mcs/class/System.ServiceModel
  o make run-test-local

Once you are ready, you can start importing code.  
Ideally, you want to go for high-value targets: the

most buggy parts of Mono's stack (you can check
bugzilla for reports on memory usage, bugs).   Or you
can pick a missing feature.

To import code, modify the relevant ".sources" file in
the System.ServiceModel directory (where you ran the
test) and replace a local file, with a reference to
the "referencesource".

Chances are, you will need to make changes to the
"referencesource" code, since a lot of it is Windows
specific.

Miguel


On Fri, Nov 14, 2014 at 5:25 PM, Sami Ben Grine
 wrote:

Sweet – is there anything I can do to make progress?

I am somewhat ignorant about Mono but I am pretty
ok with .NET and Linux.

thanks



___
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