Hi,
I think this is ok to check in. One possible improvement would be the one that
Ben mentioned. The ToString() methods are ok, since the MS implementation
overrides them too.
Zoltan
On 4/20/05, Carlos Alberto Cortez [EMAIL
what is the default stack alignment for different platforms(x86, arch, ppc)
in case of emitted code? Whether it is possible to change default stack
alignment for the emittted, if yes how i could change the stack alignment ?
Please someone help me out to find answer for these question.
On Wed, 2005-04-20 at 16:56 +0200, BRUNET Pierre-Marie - stagiaire
wrote:
Hi, I'm french student working on Mono for a University project. I
wonder if Mono launchs a thread for each processor if a multithread C#
program running over Mono.
No. Mono will launch a thread for each
On Thu, 2005-04-21 at 06:36 -0400, Jonathan Pryor wrote:
Mono also has a ThreadPool, for which threads are created on-demand.
The ThreadPool supports a maximum of 50 threads/CPU on Linux, 25/CPU on
Windows.
Those numbers are the default, not a maximum.
-Gonzalo
Hi,
A long known problem with mono for VB.Net developers was that
Microsft.VisualBasic.* didn't support default values for optional
parameters. The problem has been nicely explained by Jambu at
http://www.gnomebangalore.org/?q=node/view/498. I had written about it
in my blog about a month back.
Hello Daryn,
I'm having a problem signing some code (the pvk spc are valid,
and work
fine for signing on windows using signcode.exe)
1. signcode -spc mycert.spc -v mykey.pvk -t
http://timestamp.verisign.com/scripts/timstamp.dll Setup.exe
Mono SignCode - version 1.1.5.0
Jonathan Pryor wrote:
On Wed, 2005-04-20 at 16:56 +0200, BRUNET Pierre-Marie - stagiaire
wrote:
Hi, I'm french student working on Mono for a University project. I
wonder if Mono launchs a thread for each processor if a multithread C#
program running over Mono.
Mono also has a
Is there a reason for replication of such low thread limits from .NET?
It is PITA to change those programmatically
on Windows (non-portable), and I wonder how can same be done on Mono?
The reason, I think, for this is that there shouldn't be too many threads
spawned. Now... if you want to
Thomas Harning Jr. wrote:
Is there a reason for replication of such low thread limits from .NET?
It is PITA to change those programmatically
on Windows (non-portable), and I wonder how can same be done on Mono?
The reason, I think, for this is that there shouldn't be too many threads spawned.
On Thursday 21 April 2005 09:25, Alex Chudnovsky wrote:
I found a solution (hack really) to make .NET programmatically change
maximum limit of threads on Windows,
Would you be so kind to share it?
Sunny
--
Get Firefox
http://www.spreadfirefox.com/?q=affiliatesid=10745t=85
On Thursday 21 April 2005 09:53, Alex Chudnovsky wrote:
Sunny wrote:
On Thursday 21 April 2005 09:25, Alex Chudnovsky wrote:
I found a solution (hack really) to make .NET programmatically change
maximum limit of threads on Windows,
Would you be so kind to share it?
Its here:
Sunny wrote:
On Thursday 21 April 2005 09:53, Alex Chudnovsky wrote:
Yes, this does not help you when dealing with blocking sockets. So maybe it is
better to implement your own dynamic size pool to handle this. Or, if these
threads stay in blocked state very long, maybe you will find that just
Hi,
I've compiled mono, mcs and the debugger from a fresh svn co. The
compilation works fine, but if I want to set a breakpoint with the
commandline debugger, I'll get the output No Stack. I'm not sure if
this is a problem of the compiler or a problem of the debugger. Is there
anything more to
Hello,
I start developing an application using mono/GTK# last year (xbgm.sf.net). I
keep upgrading mono and GTK# since.
I recently get a bug report from an user telling me than something was not
working.
So i start working on it to find out why. And After 3 days on it, i figure out
than my
On Thu, 2005-04-21 at 16:44 +0100, Alex Chudnovsky wrote:
Sunny wrote:
I understand desire to have maximum compatibility with actual .NET, but
surely having higher limits on number of threads is not something that
would be bad? From what I understand Windows Socket IO uses Completion
Gonzalo Paniagua Javier wrote:
On Thu, 2005-04-21 at 16:44 +0100, Alex Chudnovsky wrote:
I understand desire to have maximum compatibility with actual .NET, but
surely having higher limits on number of threads is not something that
would be bad? From what I understand Windows Socket IO uses
I've disabled this for the time being as it breaks the build for people
on mac. I sent raja details about what is going on.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
On 4/21/05, Ankit Jain [EMAIL PROTECTED] wrote:
Hi,
...
So, the idea is - dissassemble Microsoft.VisualBasic.dll --
fixup_with_script -- assemble back.
Writing the script wasnt much of a problem, but it turned out that
monodis and ilasm had *some* bugs cos of which the roundtrip wouldnt
On Thu, 2005-04-21 at 20:36 +0100, Alex Chudnovsky wrote:
From what I understood blocking IO (at least for sockets) is done by
actually using async IO and making artificial wait for its to finish and
then return result, and therefore usage of number of threads should be
as much or higher
Hey,
Attached is a patch with changes for AssemblyName, to behave like
the .Net impl.
I still don't know which was the intention of that code in Version
property, anyway.
Any comments?
Carlos.
Index: AssemblyName.cs
===
---
Hi,
Could we possibly cook a similar solution using Cecil, instead of
disassembling and reassembling? Looks like something that is
potentially less-breakable over the time axis.
Yup..thats what we wanna do, but Cecil doesnt have write support as of
now. I'll try to contribute to write-support
21 matches
Mail list logo
