While Cecil can currently load 4.0 dlls, it does not properly emit the
headers detect running on a 4.0 runtime. The attached patch fixes that.
--
Carlo Kok
RemObjects Software
The Infrastructure Company
http://www.remobjects.com
Index: ChangeLog
My understanding is that no one is working on serial port stack now.
I haven't faced to any serial port issue on linux, but it won't
work on OSX or windows for some cases (bugs filed and/or patch posted).
A problem is that it very often needs the actual hardware to reproduce
issues which is
As Atsushi said, nobody is working in the serial ports these days, but you
can still fill a bug report, and at some point we will try to fix it.
Carlos.
2009/7/13 Atsushi Eno atsushi...@veritas-vos-liberabit.com
My understanding is that no one is working on serial port stack now.
I haven't
Hi Gonzalo,
Inside the threadPool the following code:
threadDone.WaitOne(PoolGrowDelay, false);
Makes thread creation wait 500ms (I guess just forcing the CPU to switch
to another one) each time a new thread is created (when the pool is
growing).
If you remove it, connection problems
Hi all,
On BinaryServerFormatterSink.cs, a new MemoryStream is being created to
attend every remoting call.
Under high load conditions it will make the GC work harder than
required, both decreasing performance and potentially causing memory
problems.
It should be replaced by some sort of
On Mon, 2009-07-13 at 19:36 +0200, pablosantosl...@terra.es wrote:
[...]
That should be modified to make use of the .NET ThreadPool and use
asynchronous operations for accept, read and write (this last one is not
mandatory). There's code in xsp that illustrates the way it should be
done.
On Mon, 2009-07-13 at 19:39 +0200, pablosantosl...@terra.es wrote:
Hi all,
On BinaryServerFormatterSink.cs, a new MemoryStream is being created to
attend every remoting call.
Under high load conditions it will make the GC work harder than
required, both decreasing performance and
On Sun, 2009-07-12 at 00:11 +0200, pablosantosl...@terra.es wrote:
Hi,
I'm having issues with Mono remoting under high performance networking
scenarios. Some clients are rejected since the server is not able to
handle connections.
Look at the following code inside TcpServerChannel
Hi,
On Mon, 2009-07-13 at 19:39 +0200, pablosantosl...@terra.es wrote:
Hi all,
On BinaryServerFormatterSink.cs, a new MemoryStream is being created to
attend every remoting call.
Under high load conditions it will make the GC work harder than
required, both decreasing performance and
Ok, I think you mean IntPtrStream, but I'm not sure it's what I'm
looking for.
I think managed memory would be enough (unless the other is faster :-P),
but I need the stream to reuse preallocated buffers.
pablo
www.plasticscm.com
pablosantosl...@terra.es wrote:
Hi,
On Mon, 2009-07-13
On Mon, 2009-07-13 at 19:59 +0200, pablosantosl...@terra.es wrote:
[...]
Are you volunteering? Have you profiled the application or is this just
a guess?
Testing PlasticSCM under really heavy load (hundreds of clients against
a single server delivering hundreds of Gb over the
I see references to System.Messaging on the Mono website saying it's
not available in Mono, but, after compiling Mono 2.4.2, I see it
produced a System.Messaging.dll assembly. Is the website just
outdated? I'm confused.
--
Cheers, László
___
2009/7/14 Count László de Almásy calm...@gmail.com:
I see references to System.Messaging on the Mono website saying it's
not available in Mono, but, after compiling Mono 2.4.2, I see it
produced a System.Messaging.dll assembly. Is the website just
outdated? I'm confused.
It seems to be
While building mono r137831 from SVN, I get a crash in ³make check². (I had
a coworker duplicate this as well with a fresh checkout of mono and mcs).
I built with the following options:
autogen.sh prefix=/opt/mono
I¹ve attached the error log to the mail.
I¹ve got a couple of regressions since
It appears that the tests broke in r137322, since r137319 ³make check²
succeeds on Mac.
On 7/13/09 7:55 PM, Tom Philpot tom.phil...@logos.com wrote:
While building mono r137831 from SVN, I get a crash in ³make check². (I had a
coworker duplicate this as well with a fresh checkout of mono and
Note that the assembly *did* exist even in Mono 1.0 era. It's just
that not implemented. And our System.Messaging.dll is not supported
in any sense. Some part of the functionality is available through
rabbitmq bridge by Michael.
Atsushi Eno
Seo Sanghyeon wrote:
2009/7/14 Count László de Almásy
that's unfortunate. is there any viable alternative in Mono to System.Messaging?
On Mon, Jul 13, 2009 at 10:42 PM, Atsushi
Enoatsushi...@veritas-vos-liberabit.com wrote:
Note that the assembly *did* exist even in Mono 1.0 era. It's just
that not implemented. And our System.Messaging.dll is not
17 matches
Mail list logo
