date:20130807

Re: [Mono-dev] Mono 3.2.1 OS X Build on Mountain Lion with threads failure [libmonoruntime_la-threads.lo] Error 1

2013-08-07 Thread Michael Franz

Zoltan,

Your suggestion worked!  Thank you!

How do we get the OS X build instructions updated?  This is the page I was
working from.  http://mono-project.com/Compiling_Mono_on_OSX

Michael


On Wed, Aug 7, 2013 at 3:54 AM, Zoltan Varga  wrote:

> Hi,
>
>  Instead of CFLAGS="-m32", try configure --build=i386-apple-darwin11.2.0
> or something.
>
>  Zoltan
>
>
> On Wed, Aug 7, 2013 at 4:13 AM, Michael Franz  wrote:
>
>> Hi,
>>
>> I download the latest tar file 
>> (mono-3.2.1.tar.bz2)
>>  and
>> followed the OS X build instructions.  The 32 bit build is failing, similar
>> to this old thread
>> http://mono.1490590.n4.nabble.com/mono-io-layer-mono-mutex-h-Errors-in-Current-Master-td3515845.html#a3515916.
>>   The 64 bit build works just fine.  How do I get more details of the
>> exact error?
>>
>>   $ CC='cc -m32' ./configure --prefix=DIR --enable-nls=no
>>   $ make
>>
>> Making all in metadata
>>   CC   libmonoruntime_la-threads.lo
>> make[3]: *** [libmonoruntime_la-threads.lo] Error 1
>> make[2]: *** [all-recursive] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>> I have tried 'make V=1', but that just seems to give me the information
>> about the command used to build and not the details on the problem.
>>
>> My system detail ares:
>> mono-3.2.1$ uname -a
>> Darwin MacMini.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1
>> 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
>>
>> mono-3.2.1$ gcc --version
>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
>> 5658) (LLVM build 2336.11.00)
>>
>> Any help is appreciated.
>>
>> Michael
>>
>> ___
>> 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] New Property on System.Web.Hosting.HostingEnvironment

2013-08-07 Thread Martin Thwaites

I didn't just plan on waiting,  I've worked around it.

The reason for the mail was to highlight it so that if anyone was working
on that section they were aware that it could do with being added.

It's something pretty fundamental to the building MVC sites, so if
promoting mono to the wider MVC audience is important, it's needed.

Although I have no idea how I would go about implementing the property, I
will give it a go.  I have never contributed code to n open source, and
given the size of the mono code base, it's quite a daunting prospect.

To be clear I'm not under the illusion that I can ask and it will be done.
On Aug 7, 2013 12:02 PM, "Atsushi Eno" 
wrote:

> From your message I assume you think you can wait for someone to implement
> it, but there is no one working on ASP.NET stack. So you are the most
> likely one who understand what it is and who is most able to implement it.
>
> Atsushi Eno
>
> Martin Thwaites wrote:
>
>> I'm not sure of the best place to raise this, it's not a bug really, but
>> a property that seems to be new to the framework.
>>
>> System.Web.Hosting.**HostingEnvironment has the property
>> "InClientBuildManager" and it looks like it was added in 3.5.
>>
>> The reason I think it's an important thing to get added soon is the fact
>> that WebActivatorEx uses it, and it's part of just about every NuGet
>> package for MVC.  So if people want to move over to mono, this could be a
>> major issue.
>>
>> On the plus side, WebActivatorEx handles it well, so you just get an
>> exception on first run.
>>
>> http://msdn.microsoft.com/en-**us/library/system.web.hosting.**
>> hostingenvironment.**inclientbuildmanager(v=vs.100)**.aspx<
>> http://msdn.microsoft.com/en-**us/library/system.web.hosting.**
>> hostingenvironment.**inclientbuildmanager%28v=vs.**100%29.aspx
>> >
>>
>>
>> __**_
>> 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] error executing the compiled EXE edited Mono Inside Windows Environment

2013-08-07 Thread Daniel Lo Nigro

What was the exact error message you got?


On Thu, Aug 1, 2013 at 3:49 AM, bpescarolli wrote:

> I created a HelloWord.exe (application interface gtk 2.0) in Mono within my
> Lubuntu 13.04
> I caught this one Release executable tried run it on a machine with Win XP
> .. just curious, with. NET installed.
>
> and returns an error like "Unable to start HelloWord.exe ..."
>
> how do I create an application within my Lubuntu Mono that runs on both
> Windows Environments with. NET installed or Linux environments that have
> the
> Wine or Mono runtime installed?
>
> I have to have installed on my Mono Winforms? makes if yes how?
>
> Help me , please!
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/error-executing-the-compiled-EXE-edited-Mono-Inside-Windows-Environment-tp4660343.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] error executing the compiled EXE edited Mono Inside Windows Environment

2013-08-07 Thread Rafael Teixeira

Probably you didn't install gtk and gtk# on your windows machine,
which is a dependency of your application. Exe files aren't
self-contained apps, they depend on libraries and those need to either
be installed globally in the system (as in this case because the gtk
part is mixed native/managed code) or carried alongside the executable
(for fully managed OS-independent libraries).

Good learning,
Rafael Teixeira
O..:.)


On Wed, Jul 31, 2013 at 2:49 PM, bpescarolli
 wrote:
> I created a HelloWord.exe (application interface gtk 2.0) in Mono within my
> Lubuntu 13.04
> I caught this one Release executable tried run it on a machine with Win XP
> .. just curious, with. NET installed.
>
> and returns an error like "Unable to start HelloWord.exe ..."
>
> how do I create an application within my Lubuntu Mono that runs on both
> Windows Environments with. NET installed or Linux environments that have the
> Wine or Mono runtime installed?
>
> I have to have installed on my Mono Winforms? makes if yes how?
>
> Help me , please!
>
>
>
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/error-executing-the-compiled-EXE-edited-Mono-Inside-Windows-Environment-tp4660343.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] NancyFX self hosting (HttpListener) locking up on linux

2013-08-07 Thread Andrés G. Aragoneses

If you're able to reproduce it with 3.3 and not with 2.10.x, you should 
definitely open a bug report for it in http://bugzilla.xamarin.com/ 
stating "[regression]" in the bug summary.


Also, I would open a separate bug report for the segfault you're getting 
when running with MONO_DISABLE_AIO (pasting the backtrace of the 
segfault, with debug symbols installed).


On 07/08/13 14:02, Alfred Hall wrote:

Tried running it with sgen or boehm on 2.10? Worth trying both I think.
Also how about 3.3 (master) ?

-Original message-
*From:* Nikita Tsukanov 
*Sent:* Wednesday 7th August 2013 12:54
*To:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
locking up on linux

I've rewritten my SCGI server to work with TPL directly instead of
using async/await to make it run on mono 2.10. Then I've tried to
run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
backend and to hammer it with jmeter. 500K requests without any
lockups on Mono 2.10, lockup at 22164th request on mono 3.2.

Server source code is still on GitHub -
https://github.com/kekekeks/scgi-sharp


2013/8/7 Greg Young mailto:gregoryyou...@gmail.com>>

I believe attaching a debugger changes things like optimizations
from occurring (not positive but it does in clr)


On Wednesday, August 7, 2013, Nikita Tsukanov wrote:

Huh, it doesn't require debugger to be _attched_, just
debugging subsystem initialized i. e. if I launch this
program as a "debugger" it doesn't lock up.

publicstaticvoidMain(string[]args)
{
intport=27042;
if(args.Length !=0)
port=int.Parse(args[0]);
while(true)
{
varvm= 
Mono.Debugger.Soft.VirtualMachineManager.Listen(newIPEndPoint(IPAddress.Loopback,port));
vm.Resume();
vm.Detach();
}
}

I'll use running with
--debugger-agent=transport=dt_socket,address=127.0.0.1:27042
 as a temporary workaround since
performance doesn't degrade a lot.


2013/8/7 Nikita Tsukanov 

I suspect that the problem is actually with thread pool
itself. I've created socket layer implementation using
libevent (wrapped with Oars) and send/recv that utilizes
thread pool for cases when it's unable to complete
operation synchronously. It survives longer, but still
locks up after a while. Same behavior with debugger -
I'm unable to reproduce the issue when running under it.
I also unable to grab thread stack traces, it prints
"Full thread dump: " and nothing else.


2013/8/7 Greg Young 

We will see your test then as it will probably
affect us as well


On Tuesday, August 6, 2013, Nikita Tsukanov wrote:

Greg, I've tried running my server with mono
compiled from master (with pull request #703
merged in), still freezes after a while.


2013/8/7 Greg Young 

Do you have our pull req? We are stable
after (and seriously read history of this list)


On Tuesday, August 6, 2013, Nikita Tsukanov
wrote:

https://github.com/kekekeks/scgi-sharp -
here is my SCGI server with host for
NancyFx. If you run Sandbox.exe with
--echo-server it will not use nancy
infrastructure and will respond
directly. It locks up after several
thousands of requests under jmeter.

Simple nginx configuration:

location /
{
include /etc/nginx/scgi_params;
scgi_pass 127.0.0.1:10081
;
}

Now I'm looking for alternative socket
library to use it as a replacement for
System.Net.Sockets.


2013/8/6 Greg Young


Actually not that surprised we also
found out file stream.flush(true)
only works sometimes and ms never
back support

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

2013-08-07 Thread Alfred Hall

Tried running it with sgen or boehm on 2.10? Worth trying both I think. Also 
how about 3.3 (master) ?
-Original message-
From: Nikita Tsukanov 
Sent: Wednesday 7th August 2013 12:54
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

I've rewritten my SCGI server to work with TPL directly instead of using 
async/await to make it run on mono 2.10. Then I've tried to run it with mono 
2.10.8.1 and mono 3.2 with System.Net.Sockets backend and to hammer it with 
jmeter. 500K requests without any lockups on Mono 2.10, lockup at 22164th 
request on mono 3.2. 

Server source code is still on GitHub - https://github.com/kekekeks/scgi-sharp

2013/8/7 Greg Young mailto:gregoryyou...@gmail.com> >
I believe attaching a debugger changes things like optimizations from occurring 
(not positive but it does in clr)

On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
Huh, it doesn't require debugger to be _attched_, just debugging subsystem 
initialized i. e. if I launch this program as a "debugger" it doesn't lock up.

public static void Main (string[] args)
{
  int port = 27042;
  if (args.Length != 0)
    port = int.Parse (args [0]);
  while (true)
  {
    var vm = Mono.Debugger.Soft.VirtualMachineManager.Listen (new IPEndPoint 
(IPAddress.Loopback, port));
    vm.Resume ();
    vm.Detach ();
  }
}

I'll use running with 
--debugger-agent=transport=dt_socket,address=127.0.0.1:27042 
 as a temporary workaround since performance doesn't 
degrade a lot.

2013/8/7 Nikita Tsukanov 
I suspect that the problem is actually with thread pool itself. I've created 
socket layer implementation using libevent (wrapped with Oars) and send/recv 
that utilizes thread pool for cases when it's unable to complete operation 
synchronously. It survives longer, but still locks up after a while. Same 
behavior with debugger - I'm unable to reproduce the issue when running under 
it. I also unable to grab thread stack traces, it prints "Full thread dump: " 
and nothing else.

2013/8/7 Greg Young 
We will see your test then as it will probably affect us as well

On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried running my server with mono compiled from master (with pull 
request #703 merged in), still freezes after a while.

2013/8/7 Greg Young 
Do you have our pull req? We are stable after (and seriously read history of 
this list)

On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
https://github.com/kekekeks/scgi-sharp - here is my SCGI server with host for 
NancyFx. If you run Sandbox.exe with --echo-server it will not use nancy 
infrastructure and will respond directly. It locks up after several thousands 
of requests under jmeter.

Simple nginx configuration:

location /
{
   include /etc/nginx/scgi_params;
   scgi_pass 127.0.0.1:10081  ;
}

Now I'm looking for alternative socket library to use it as a replacement for 
System.Net.Sockets.

2013/8/6 Greg Young 
Actually not that surprised we also found out file stream.flush(true) only 
works sometimes and ms never back supported it to actually work :)

On Tuesday, August 6, 2013, Alfred Hall wrote:

Yeah you're having exactly the same issues as I am. I'm surprised others 
haven't had this problem before. Not sure who works on this area of the mono 
codebase these days. If you got a minimal test case it may be worth us raising 
a Xamarin bug in bugzilla.
-Original message-
From: Nikita Tsukanov 
Sent: Tuesday 6th August 2013 20:18
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

Running with mono from master haven't helped.

And I'm not sure what the hell is going on, but I cann't reproduce the issue 
when running under... Monodevelop's debugger. It runs perfectly under it, but 
when I try to run the same binary from console (even with --debug option) it 
locks up or segfaults. Does anyone know what does it mean?

2013/8/6 Nikita Tsukanov 
Great. It locked up with my more complex logic. 
Funny fact: NancyFx increases request processing time from 2ms to 70ms with the 
same echo response.
Another funny fact: with MONO_DISABLE_AIO I've got segfault.

Now I'll try to use build patched mono. Not sure that it's the same issue, 
because in my case it never tries to read and write simultane

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

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

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

2013-08-07 Thread Nikita Tsukanov

Ehm. Tried to run NancyFx with HttpListener on mono 2.10.8.1 (from ubuntu
repos) on my desktop machine. No lockups.


2013/8/7 Nikita Tsukanov 

> I've rewritten my SCGI server to work with TPL directly instead of using
> async/await to make it run on mono 2.10. Then I've tried to run it with
> mono 2.10.8.1 and mono 3.2 with System.Net.Sockets backend and to hammer it
> with jmeter. 500K requests without any lockups on Mono 2.10, lockup at
> 22164th request on mono 3.2.
>
> Server source code is still on GitHub -
> https://github.com/kekekeks/scgi-sharp
>
>
> 2013/8/7 Greg Young 
>
>> I believe attaching a debugger changes things like optimizations from
>> occurring (not positive but it does in clr)
>>
>>
>> On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
>>
>>> Huh, it doesn't require debugger to be _attched_, just debugging
>>> subsystem initialized i. e. if I launch this program as a "debugger" it
>>> doesn't lock up.
>>>
>>> public static void Main (string[] args)
>>> {
>>>   int port = 27042;
>>>   if (args.Length != 0)
>>> port = int.Parse (args [0]);
>>>   while (true)
>>>   {
>>> var vm = Mono.Debugger.Soft.VirtualMachineManager.Listen (new
>>> IPEndPoint (IPAddress.Loopback, port));
>>> vm.Resume ();
>>> vm.Detach ();
>>>   }
>>> }
>>>
>>> I'll use running with --debugger-agent=transport=dt_socket,address=
>>> 127.0.0.1:27042 as a temporary workaround since performance doesn't
>>> degrade a lot.
>>>
>>>
>>> 2013/8/7 Nikita Tsukanov 
>>>
>>> I suspect that the problem is actually with thread pool itself. I've
>>> created socket layer implementation using libevent (wrapped with Oars) and
>>> send/recv that utilizes thread pool for cases when it's unable to complete
>>> operation synchronously. It survives longer, but still locks up after a
>>> while. Same behavior with debugger - I'm unable to reproduce the issue when
>>> running under it. I also unable to grab thread stack traces, it prints
>>> "Full thread dump: " and nothing else.
>>>
>>>
>>> 2013/8/7 Greg Young 
>>>
>>> We will see your test then as it will probably affect us as well
>>>
>>>
>>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>>
>>> Greg, I've tried running my server with mono compiled from master (with
>>> pull request #703 merged in), still freezes after a while.
>>>
>>>
>>> 2013/8/7 Greg Young 
>>>
>>> Do you have our pull req? We are stable after (and seriously read
>>> history of this list)
>>>
>>>
>>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>>
>>> https://github.com/kekekeks/scgi-sharp - here is my SCGI server with
>>> host for NancyFx. If you run Sandbox.exe with --echo-server it will not use
>>> nancy infrastructure and will respond directly. It locks up after several
>>> thousands of requests under jmeter.
>>>
>>> Simple nginx configuration:
>>>
>>> location /
>>> {
>>>include /etc/nginx/scgi_params;
>>>scgi_pass 127.0.0.1:10081;
>>> }
>>>
>>> Now I'm looking for alternative socket library to use it as a
>>> replacement for System.Net.Sockets.
>>>
>>>
>>> 2013/8/6 Greg Young 
>>>
>>> Actually not that surprised we also found out file stream.flush(true)
>>> only works sometimes and ms never back supported it to actually work :)
>>>
>>>
>>> On Tuesday, August 6, 2013, Alfred Hall wrote:
>>>
>>> **
>>> Yeah you're having exactly the same issues as I am. I'm surprised others
>>> haven't had this problem before. Not sure who works on this area of the
>>> mono codebase these days. If you got a minimal test case it may be worth us
>>> raising a Xamarin bug in bugzilla.
>>>
>>> -Original message-
>>> *From:* Nikita Tsukanov 
>>> *Sent:* Tuesday 6th August 2013 20:18
>>> *To:* mono-devel-list@lists.ximian.com
>>> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking
>>> up on linux
>>>
>>> Running with mono from master haven't helped.
>>>
>>> And I'm not sure what the hell is going on, but I cann't reproduce the
>>> issue when running under... Monodevelop's debugger. It runs perfectly under
>>> it, but when I try to run the same binary from console (even with --debug
>>> option) it locks up or segfaults. Does anyone know what does it mean?
>>>
>>>
>>> 2013/8/6 Nikita Tsukanov 
>>>
>>> Great. It locked up with my more complex logic.
>>> Funny fact: NancyFx increases request processing time from 2ms to 70ms
>>> with the same echo response.
>>> Another funny fact: with MONO_DISABLE_AIO I've got segfault.
>>>
>>> Now I'll try to use build patched mono. Not sure that it's the same
>>> issue, because in my case it never tries to read and write simultane
>>>
>>>
>>
>> --
>> 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] NancyFX self hosting (HttpListener) locking up on linux

2013-08-07 Thread Nikita Tsukanov

I've rewritten my SCGI server to work with TPL directly instead of using
async/await to make it run on mono 2.10. Then I've tried to run it with
mono 2.10.8.1 and mono 3.2 with System.Net.Sockets backend and to hammer it
with jmeter. 500K requests without any lockups on Mono 2.10, lockup at
22164th request on mono 3.2.

Server source code is still on GitHub -
https://github.com/kekekeks/scgi-sharp


2013/8/7 Greg Young 

> I believe attaching a debugger changes things like optimizations from
> occurring (not positive but it does in clr)
>
>
> On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
>
>> Huh, it doesn't require debugger to be _attched_, just debugging
>> subsystem initialized i. e. if I launch this program as a "debugger" it
>> doesn't lock up.
>>
>> public static void Main (string[] args)
>> {
>>   int port = 27042;
>>   if (args.Length != 0)
>> port = int.Parse (args [0]);
>>   while (true)
>>   {
>> var vm = Mono.Debugger.Soft.VirtualMachineManager.Listen (new
>> IPEndPoint (IPAddress.Loopback, port));
>> vm.Resume ();
>> vm.Detach ();
>>   }
>> }
>>
>> I'll use running with --debugger-agent=transport=dt_socket,address=
>> 127.0.0.1:27042 as a temporary workaround since performance doesn't
>> degrade a lot.
>>
>>
>> 2013/8/7 Nikita Tsukanov 
>>
>> I suspect that the problem is actually with thread pool itself. I've
>> created socket layer implementation using libevent (wrapped with Oars) and
>> send/recv that utilizes thread pool for cases when it's unable to complete
>> operation synchronously. It survives longer, but still locks up after a
>> while. Same behavior with debugger - I'm unable to reproduce the issue when
>> running under it. I also unable to grab thread stack traces, it prints
>> "Full thread dump: " and nothing else.
>>
>>
>> 2013/8/7 Greg Young 
>>
>> We will see your test then as it will probably affect us as well
>>
>>
>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>
>> Greg, I've tried running my server with mono compiled from master (with
>> pull request #703 merged in), still freezes after a while.
>>
>>
>> 2013/8/7 Greg Young 
>>
>> Do you have our pull req? We are stable after (and seriously read history
>> of this list)
>>
>>
>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>
>> https://github.com/kekekeks/scgi-sharp - here is my SCGI server with
>> host for NancyFx. If you run Sandbox.exe with --echo-server it will not use
>> nancy infrastructure and will respond directly. It locks up after several
>> thousands of requests under jmeter.
>>
>> Simple nginx configuration:
>>
>> location /
>> {
>>include /etc/nginx/scgi_params;
>>scgi_pass 127.0.0.1:10081;
>> }
>>
>> Now I'm looking for alternative socket library to use it as a replacement
>> for System.Net.Sockets.
>>
>>
>> 2013/8/6 Greg Young 
>>
>> Actually not that surprised we also found out file stream.flush(true)
>> only works sometimes and ms never back supported it to actually work :)
>>
>>
>> On Tuesday, August 6, 2013, Alfred Hall wrote:
>>
>> **
>> Yeah you're having exactly the same issues as I am. I'm surprised others
>> haven't had this problem before. Not sure who works on this area of the
>> mono codebase these days. If you got a minimal test case it may be worth us
>> raising a Xamarin bug in bugzilla.
>>
>> -Original message-
>> *From:* Nikita Tsukanov 
>> *Sent:* Tuesday 6th August 2013 20:18
>> *To:* mono-devel-list@lists.ximian.com
>> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up
>> on linux
>>
>> Running with mono from master haven't helped.
>>
>> And I'm not sure what the hell is going on, but I cann't reproduce the
>> issue when running under... Monodevelop's debugger. It runs perfectly under
>> it, but when I try to run the same binary from console (even with --debug
>> option) it locks up or segfaults. Does anyone know what does it mean?
>>
>>
>> 2013/8/6 Nikita Tsukanov 
>>
>> Great. It locked up with my more complex logic.
>> Funny fact: NancyFx increases request processing time from 2ms to 70ms
>> with the same echo response.
>> Another funny fact: with MONO_DISABLE_AIO I've got segfault.
>>
>> Now I'll try to use build patched mono. Not sure that it's the same
>> issue, because in my case it never tries to read and write simultane
>>
>>
>
> --
> 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] New Property on System.Web.Hosting.HostingEnvironment

2013-08-07 Thread Atsushi Eno

From your message I assume you think you can wait for someone to 
implement it, but there is no one working on ASP.NET stack. So you are 
the most likely one who understand what it is and who is most able to 
implement it.


Atsushi Eno

Martin Thwaites wrote:
I'm not sure of the best place to raise this, it's not a bug really, 
but a property that seems to be new to the framework.


System.Web.Hosting.HostingEnvironment has the property 
"InClientBuildManager" and it looks like it was added in 3.5.


The reason I think it's an important thing to get added soon is the 
fact that WebActivatorEx uses it, and it's part of just about every 
NuGet package for MVC.  So if people want to move over to mono, this 
could be a major issue.


On the plus side, WebActivatorEx handles it well, so you just get an 
exception on first run.


http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.inclientbuildmanager(v=vs.100).aspx 




___
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] NancyFX self hosting (HttpListener) locking up on linux

2013-08-07 Thread Greg Young

I believe attaching a debugger changes things like optimizations from
occurring (not positive but it does in clr)

On Wednesday, August 7, 2013, Nikita Tsukanov wrote:

> Huh, it doesn't require debugger to be _attched_, just debugging subsystem
> initialized i. e. if I launch this program as a "debugger" it doesn't lock
> up.
>
> public static void Main (string[] args)
> {
>   int port = 27042;
>   if (args.Length != 0)
> port = int.Parse (args [0]);
>   while (true)
>   {
> var vm = Mono.Debugger.Soft.VirtualMachineManager.Listen (new
> IPEndPoint (IPAddress.Loopback, port));
> vm.Resume ();
> vm.Detach ();
>   }
> }
>
> I'll use running with --debugger-agent=transport=dt_socket,address=
> 127.0.0.1:27042 as a temporary workaround since performance doesn't
> degrade a lot.
>
>
> 2013/8/7 Nikita Tsukanov 
>
> I suspect that the problem is actually with thread pool itself. I've
> created socket layer implementation using libevent (wrapped with Oars) and
> send/recv that utilizes thread pool for cases when it's unable to complete
> operation synchronously. It survives longer, but still locks up after a
> while. Same behavior with debugger - I'm unable to reproduce the issue when
> running under it. I also unable to grab thread stack traces, it prints
> "Full thread dump: " and nothing else.
>
>
> 2013/8/7 Greg Young 
>
> We will see your test then as it will probably affect us as well
>
>
> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>
> Greg, I've tried running my server with mono compiled from master (with
> pull request #703 merged in), still freezes after a while.
>
>
> 2013/8/7 Greg Young 
>
> Do you have our pull req? We are stable after (and seriously read history
> of this list)
>
>
> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>
> https://github.com/kekekeks/scgi-sharp - here is my SCGI server with host
> for NancyFx. If you run Sandbox.exe with --echo-server it will not use
> nancy infrastructure and will respond directly. It locks up after several
> thousands of requests under jmeter.
>
> Simple nginx configuration:
>
> location /
> {
>include /etc/nginx/scgi_params;
>scgi_pass 127.0.0.1:10081;
> }
>
> Now I'm looking for alternative socket library to use it as a replacement
> for System.Net.Sockets.
>
>
> 2013/8/6 Greg Young 
>
> Actually not that surprised we also found out file stream.flush(true) only
> works sometimes and ms never back supported it to actually work :)
>
>
> On Tuesday, August 6, 2013, Alfred Hall wrote:
>
> **
> Yeah you're having exactly the same issues as I am. I'm surprised others
> haven't had this problem before. Not sure who works on this area of the
> mono codebase these days. If you got a minimal test case it may be worth us
> raising a Xamarin bug in bugzilla.
>
> -Original message-
> *From:* Nikita Tsukanov 
> *Sent:* Tuesday 6th August 2013 20:18
> *To:* mono-devel-list@lists.ximian.com
> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up
> on linux
>
> Running with mono from master haven't helped.
>
> And I'm not sure what the hell is going on, but I cann't reproduce the
> issue when running under... Monodevelop's debugger. It runs perfectly under
> it, but when I try to run the same binary from console (even with --debug
> option) it locks up or segfaults. Does anyone know what does it mean?
>
>
> 2013/8/6 Nikita Tsukanov 
>
> Great. It locked up with my more complex logic.
> Funny fact: NancyFx increases request processing time from 2ms to 70ms
> with the same echo response.
> Another funny fact: with MONO_DISABLE_AIO I've got segfault.
>
> Now I'll try to use build patched mono. Not sure that it's the same issue,
> because in my case it never tries to read and write simultane
>
>

-- 
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] NancyFX self hosting (HttpListener) locking up on linux

2013-08-07 Thread Nikita Tsukanov

Huh, it doesn't require debugger to be _attched_, just debugging subsystem
initialized i. e. if I launch this program as a "debugger" it doesn't lock
up.

public static void Main (string[] args)
{
  int port = 27042;
  if (args.Length != 0)
port = int.Parse (args [0]);
  while (true)
  {
var vm = Mono.Debugger.Soft.VirtualMachineManager.Listen (new IPEndPoint
 (IPAddress.Loopback, port));
vm.Resume ();
vm.Detach ();
  }
}

I'll use running with --debugger-agent=transport=dt_socket,address=
127.0.0.1:27042 as a temporary workaround since performance doesn't degrade
a lot.


2013/8/7 Nikita Tsukanov 

> I suspect that the problem is actually with thread pool itself. I've
> created socket layer implementation using libevent (wrapped with Oars) and
> send/recv that utilizes thread pool for cases when it's unable to complete
> operation synchronously. It survives longer, but still locks up after a
> while. Same behavior with debugger - I'm unable to reproduce the issue when
> running under it. I also unable to grab thread stack traces, it prints
> "Full thread dump: " and nothing else.
>
>
> 2013/8/7 Greg Young 
>
>> We will see your test then as it will probably affect us as well
>>
>>
>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>
>>> Greg, I've tried running my server with mono compiled from master (with
>>> pull request #703 merged in), still freezes after a while.
>>>
>>>
>>> 2013/8/7 Greg Young 
>>>
>>> Do you have our pull req? We are stable after (and seriously read
>>> history of this list)
>>>
>>>
>>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>>
>>> https://github.com/kekekeks/scgi-sharp - here is my SCGI server with
>>> host for NancyFx. If you run Sandbox.exe with --echo-server it will not use
>>> nancy infrastructure and will respond directly. It locks up after several
>>> thousands of requests under jmeter.
>>>
>>> Simple nginx configuration:
>>>
>>> location /
>>> {
>>>include /etc/nginx/scgi_params;
>>>scgi_pass 127.0.0.1:10081;
>>> }
>>>
>>> Now I'm looking for alternative socket library to use it as a
>>> replacement for System.Net.Sockets.
>>>
>>>
>>> 2013/8/6 Greg Young 
>>>
>>> Actually not that surprised we also found out file stream.flush(true)
>>> only works sometimes and ms never back supported it to actually work :)
>>>
>>>
>>> On Tuesday, August 6, 2013, Alfred Hall wrote:
>>>
>>> **
>>> Yeah you're having exactly the same issues as I am. I'm surprised others
>>> haven't had this problem before. Not sure who works on this area of the
>>> mono codebase these days. If you got a minimal test case it may be worth us
>>> raising a Xamarin bug in bugzilla.
>>>
>>> -Original message-
>>> *From:* Nikita Tsukanov 
>>> *Sent:* Tuesday 6th August 2013 20:18
>>> *To:* mono-devel-list@lists.ximian.com
>>> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking
>>> up on linux
>>>
>>> Running with mono from master haven't helped.
>>>
>>> And I'm not sure what the hell is going on, but I cann't reproduce the
>>> issue when running under... Monodevelop's debugger. It runs perfectly under
>>> it, but when I try to run the same binary from console (even with --debug
>>> option) it locks up or segfaults. Does anyone know what does it mean?
>>>
>>>
>>> 2013/8/6 Nikita Tsukanov 
>>>
>>> Great. It locked up with my more complex logic.
>>> Funny fact: NancyFx increases request processing time from 2ms to 70ms
>>> with the same echo response.
>>> Another funny fact: with MONO_DISABLE_AIO I've got segfault.
>>>
>>> Now I'll try to use build patched mono. Not sure that it's the same
>>> issue, because in my case it never tries to read and write simultaneously
>>>  on the same socket.
>>>
>>>
>>> 2013/8/6 Greg Young 
>>>
>>> There are many cases the patch we provided does not affect eg no overlap
>>> in io between send/receive
>>>
>>>
>>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>>
>>> Interesting... I've written a simple server using only
>>> Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and then
>>> sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it
>>> still responds with "Lorem ipsum ..." perfectly. I'll try to "port" my SCGI
>>> server logic from NetworkStream to Socket and see what will happen.
>>>
>>>
>>> 2013/8/6 "Andrés G. Aragoneses" 
>>>
>>> On 06/08/13 18:42, Nikita Tsukanov wrote:
>>>
>>> Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30
>>> 21:08:00 UTC 2013)
>>>
>>>
>>> Mono 3.2.0 does *not* hav
>>>
>>>
>>
>> --
>> 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] Mono 3.2.1 OS X Build on Mountain Lion with threads failure [libmonoruntime_la-threads.lo] Error 1

2013-08-07 Thread Zoltan Varga

Hi,

 Instead of CFLAGS="-m32", try configure --build=i386-apple-darwin11.2.0 or
something.

 Zoltan


On Wed, Aug 7, 2013 at 4:13 AM, Michael Franz  wrote:

> Hi,
>
> I download the latest tar file 
> (mono-3.2.1.tar.bz2)
>  and
> followed the OS X build instructions.  The 32 bit build is failing, similar
> to this old thread
> http://mono.1490590.n4.nabble.com/mono-io-layer-mono-mutex-h-Errors-in-Current-Master-td3515845.html#a3515916.
>   The 64 bit build works just fine.  How do I get more details of the
> exact error?
>
>   $ CC='cc -m32' ./configure --prefix=DIR --enable-nls=no
>   $ make
>
> Making all in metadata
>   CC   libmonoruntime_la-threads.lo
> make[3]: *** [libmonoruntime_la-threads.lo] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> I have tried 'make V=1', but that just seems to give me the information
> about the command used to build and not the details on the problem.
>
> My system detail ares:
> mono-3.2.1$ uname -a
> Darwin MacMini.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1
> 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
>
> mono-3.2.1$ gcc --version
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
> 5658) (LLVM build 2336.11.00)
>
> Any help is appreciated.
>
> Michael
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono 3.2.1 OS X Build on Mountain Lion with threads failure [libmonoruntime_la-threads.lo] Error 1

Re: [Mono-dev] New Property on System.Web.Hosting.HostingEnvironment

Re: [Mono-dev] error executing the compiled EXE edited Mono Inside Windows Environment

Re: [Mono-dev] error executing the compiled EXE edited Mono Inside Windows Environment

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

Re: [Mono-dev] New Property on System.Web.Hosting.HostingEnvironment

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

Re: [Mono-dev] Mono 3.2.1 OS X Build on Mountain Lion with threads failure [libmonoruntime_la-threads.lo] Error 1

12 matches

Site Navigation

Mail list logo

Footer information