Attached is a tiny patch for BigInteger which removes an unnecessary
instantiation. Anything which makes use of the ModPow operation will
benefit from this.
Alan.
bigintopt.diff
Description: Binary data
___
Mono-devel-list mailing list
Done.
Thanks,
Alan.
On Sat, May 31, 2008 at 2:45 PM, Sebastien Pouliot
[EMAIL PROTECTED] wrote:
Good catch, please commit!
On Sat, 2008-05-31 at 12:34 +0100, Alan McGovern wrote:
Attached is a tiny patch for BigInteger which removes an unnecessary
instantiation. Anything which makes use
Hey,
With the recent talk on GetHashCode(), I was just taking a look at the code.
I decided to try my hand at seeing what would happen performancewise if i
made the function work with an int* as opposed to char*. Turns out i ended
up with something which was 50% slower, but also had 50% less
It's 100% pure managed code, and also a single .cs file. That makes it
trivial to just include as part of your build. You can reference it using an
svn:external (or equivalent) so you always have the latest from svn aswell,
which minimises the need to keep in sync with the working copy.
There's
Hey,
This isn't a full review, it's just me point out some stuff I notice. Here
it goes:
+public IAsyncResult BeginAcceptSocket (AsyncCallback callback,
object state)
+{
+if (server == null)
+throw new ObjectDisposedException (GetType ().FullName);
+
+
There are a few thread-unsafe accesses to the hashtable which I've fixed.
I've also cleaned up how the initial table is populated by removing
redundent calls to CreateDefaults ().
Is this ok to commit?
Index: UriParser.cs
===
---
Hey,
In .NET 2.0, Uri parsing has been moved to designated classes all derived
from UriParser. This makes it possible to have custom parsers for new Uri
schemes. Currently mono doesn't support this properly.
What I think would be the best thing to do would be to change parsing under
all profiles
Hey,
Read here: http://www.mono-project.com/Contributing and also here
http://www.mono-project.com/Coding_Guidelines.
Though my word is most definitely *not* the final word in any discussion, I
will say that if the code isn't covered by NUnit tests, it won't be
committed ;) So just ensure that
] wrote:
Hi,
There are indeed 3 test case files; I forgot to svn add them. I made a new
patch file with all of the files this time. I'll attach the new one.
~Brian
On Tue, Nov 4, 2008 at 4:25 AM, Alan McGovern [EMAIL PROTECTED]wrote:
Hey,
Maybe i'm just confused, but in your original
Hey,
Now that WindowsBase has been moved to mcs, I assume we want its NUnit tests to
be run by the build bot. This poses two problems:
1) Most of the ZipPackage/Package tests will fail because libminizip.so doesn't
exist. This needs to be compiled from source. How should this be integrated
Done.
Alan.
On Thu, Nov 6, 2008 at 3:17 AM, Miguel de Icaza [EMAIL PROTECTED] wrote:
Hello,
1) Most of the ZipPackage/Package tests will fail because
libminizip.so doesn't exist. This needs to be compiled from source.
How should this be integrated with the build? This will also have to
Hi,
On Thu, Nov 6, 2008 at 3:02 PM, Paolo Molaro [EMAIL PROTECTED] wrote:
On 11/05/08 Alan McGovern wrote:
2) minizip exposes 'long' types in it's public API. At the moment I've
wrapped these as IntPtr types. This will run on all platforms except
Win64. To resolve this, we'd need
memory.
Alan.
On Mon, Nov 10, 2008 at 6:17 PM, Paolo Molaro [EMAIL PROTECTED] wrote:
On 11/06/08 Alan McGovern wrote:
However this use case is likely to never be hit in System.IO.Packaging.
The
API requires that when you 'write' data to a zip archive, the data is
also
kept in memory. If you
Also,
If you're actually writing the package to disk, you need free space == size
(package) * 2 as you will have to store a temporary full copy of the package
as well as the final copy.
Alan.
On Mon, Nov 10, 2008 at 7:01 PM, Alan McGovern [EMAIL PROTECTED]wrote:
The only other option
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort to unsafe code,
it's actually substantially slower! I've attached three
implementations of the method here. The original, the safe SIMD and
the unsafe SIMD. The runtimes are
I forgot to mention that I'm on a 1.86GHZ core2duo and i was running
with --optimize=simd.
Alan.
On Sat, Nov 15, 2008 at 2:13 AM, Alan McGovern [EMAIL PROTECTED] wrote:
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort
] = (e.Z 1) | (e.Z 31);
buff[t + 3] = ((e.W 1) | (e.W 31)) ^ ((e.X
2) | (e.X 30));
}
}
}
Rodrigo
On Sat, Nov 15, 2008 at 12:13 AM, Alan McGovern [EMAIL PROTECTED]
wrote:
I found a bit of code in the SHA1 implementation which i thought
Here's my benchmarking file anyway, it may prove useful.
Alan.
On Sun, Nov 16, 2008 at 2:37 AM, Alan McGovern [EMAIL PROTECTED] wrote:
Hey,
On Sat, Nov 15, 2008 at 3:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Alan,
-Getters and setter are a hint of ill vectorized code
Hey,
Would you care to do the same tests on Mono and .Net using class instead
of struct to see what happens? It would be interesting to look at. Also,
include object creation in that as well. Thanks.
There's nothing new here. Passing a struct which is larger than the
size of a pointer by
What error? You're too vague with what is going wrong for a solution
to be proposed.
Alan.
2008/11/30 Paul [EMAIL PROTECTED]:
Hi,
I'm using 1.9.1 with Fedora rawhide.
I've just built a game using MD (source is available at
http://www.all-the-johnsons.co.uk/mono-bugs/NetterPillars.tar.bz2 )
Ah, now this i have seen before. I think the problem is that when you
compile in resources with mono, the namespace isn't prefixed. So if
you compile in foo.bmp, in mono you access it with foo.bmp. If you
compile with VS, it appends a namespace by default, so you access with
The second issue is a limitation of the C# language,
which require extension methods to be defined of sealed classes. This would
mean that code written against mono 2.2 version
of Mono.Simd might not compiler with newer versions.
Well, I'd vote for using the method which is *cleaner* and
On Mon, Dec 1, 2008 at 9:44 PM, CarGa [EMAIL PROTECTED] wrote:
Hello, all!
I was directed here by Atsushi Eno from mono-olive list with this
question/request about GetHashCode() method.
DependencyProperty class (that lays at the very base of entire WWF and WPF
libraries) heavily depends
On Mon, Dec 1, 2008 at 9:44 PM, CarGa [EMAIL PROTECTED] wrote:
Hello, all!
I was directed here by Atsushi Eno from mono-olive list with this
question/request about GetHashCode() method.
DependencyProperty class (that lays at the very base of entire WWF and WPF
libraries) heavily depends on
I am also not all that likely to re-use the existing CLI engine, as
personally I find the code... displeasing...
The time taken to submit patches to make the code pleasing to you would be
significantly less than the time taken to rewrite from scratch. If the
patches are good, they'll be
I really doubt that kind of specific optimisation would ever make it into
mono. Have you tried benchmarking the existing SIMD implementation and
seeing what the raw performance of that is as compared to using the XNA
structs with Mono.SIMD in the background? The difference shouldn't be that
big.
There's no benefits to using mono as opposed to using any of the free
hosting ones out there. Mono doesn't come with a bug tracker, it doesn't
come with space to host downloads, it doesn't come with a wiki of any kind.
You really should consider using a free hosting that gives you all that. For
that
there are much better options out there for new projects.
Alan.
On Wed, Jan 14, 2009 at 12:15 AM, crashfourit crashfou...@gmail.com wrote:
Good point, what about sourceforge?
Alan McGovern-2 wrote:
There's no benefits to using mono as opposed to using any of the free
hosting ones out
Hi,
I reported the same issue yesterday to the developer in charge of the
logging profiler and it is actively being looked at. Hopefully it'll be
fixed soon. If you have issues in future, usually filing a bug on
http://bugzilla.novell.com would be the recommended thing to do.
Alan.
On Sat, Jan
The only good response to that email is summarised pretty well by this
blogpost.
http://www.jprl.com/Blog/archive/development/mono/2009/Jan-19.html
The only addition I'll make is to ask this question: Have you ever
created/distributed a CD which contains a hyperlink? If so, you've just
infringed
But it's the hacks that you added to your program which are causing the
issue in the first place ;) You want a hack to make your hack work. What you
really need is another hack which will work in all cases. Unfortunately I
can't think of a way which will work in all cases.
Alan.
(p.s. i'm not
2009/2/12 Daniel Espinosa eso...@gmail.com
We are working on a project using Mono/C# for a GUI independent library,
but in parallel one library to use GUI objects (the presentation layer)
witch will use the first library as a data provider.
The GUI must works on Linux/Windows among other OSs
Hey,
I pinged the maintainers of the kdebindings package for opensuse and asked
if they were building qyoto. Turns out it's disabled by default by them.
They are now taking a look at creating qyoto packages for opensuse. I assume
this will cover 11.0 and higher. So if you're interested in this,
Hey,
That can be fixed by using a dllmap to reroute the native library to the
correct one for macos. If you can create a patch to update the dllmap to
pick up the correct libraries on MacOS and attach it to bugzilla, it might
be possible to enable the SVN addin by default.
Hey,
The big issue you're having is that you haven't implemented a SIMD algorithm
;) I spent 15 mins 'optimising' your code and came up with this. Notice that
I made everything a SIMD operation. There is no scalar code in the method
anymore. This tripled performance as compared to the non-SIMD
);
xVec=xVec+xDiff;
}
}
return ret;
}
Johann.
2009/2/23 Alan McGovern alan.mcgov...@gmail.com
Hey,
The big issue you're having is that you haven't implemented a SIMD
algorithm ;) I spent 15 mins 'optimising' your code and came up with this.
Notice that I made
Hey,
SVN commits have been taking well over 60 seconds to complete all day. Is
this just a temporary thing or is there an issue with the upgrade?
Thanks,
Alan.
On Tue, Feb 24, 2009 at 5:15 PM, Jonathan Pryor jonpr...@vt.edu wrote:
On Tue, 2009-02-24 at 11:36 +0100, Robert Jordan wrote:
Hey,
They never did understand that,
whether it was in user space or the kernel, if there was a fatal bug in
my filter the machine was no more useful than a doorstop.
So if there's a bug in your filter which caused every 100th request to
bluescreen the computer, yes you're right. Your
Hi,
I just want to know if my serialiazed objects will come through client MS
dotnet and server MONO without problem.
The first response by Robert said:
They are supported.
and
You can expect 100% compatibility with custom classes (those you've
designed yourself).
So yes, you can expect
Just to clarify, you're using a comma as a decimal separator and a dot as a
thousands seperator?
So: 766.6697 ns/call = ~766 thousand ns/call
and 13,0416 ns/call = ~13 ns/call
Alan.
2009/3/15 StApostol stapos...@gmail.com
Hi all,
I just ran some tests to measure performance in
Hi,
Great stuff! I'm going to review this today and commit it if all goes well.
If you have any more bugs, just fire an email to the mono-devel list (CC'ed)
in case I'm not around to deal with them.
Alan.
On Sun, Mar 15, 2009 at 12:22 AM, Yves Dhondt yves.dho...@gmail.com wrote:
Hello,
I
newer emails now.
Alan.
p.s. Thanks for the very detailed bug report. It was very easy to derive
NUnit tests from your descriptions to prevent these issues from surfacing
again.
On Mon, Mar 16, 2009 at 10:52 AM, Alan McGovern alan.mcgov...@gmail.comwrote:
Hi,
Great stuff! I'm going to review
Should be fixed properly in SVN. Let me know if it's not.
Alan.
On Mon, Mar 16, 2009 at 7:36 PM, Yves Dhondt yves.dho...@gmail.com wrote:
Hello,
Revision 129478 fixes the NSPackageProperties string to correctly load
PackageProperties. However, the string is also used by Package.cs for
Working on this one now.
Thanks!
Alan.
On Mon, Mar 16, 2009 at 7:21 PM, Yves Dhondt yves.dho...@gmail.com wrote:
Issue:
---
ZipPackagePart.GetStreamCore in System.IO.Packaging does not handle
Filemode mode input parameter (correctly).
Test program (requires an existing openxml
Hey,
Out of interest, is this a gsoc project?
Alan.
On Fri, Apr 10, 2009 at 6:03 AM, Bartosz Lipinski baalaza...@gmail.comwrote:
It is OK because till last week of May I am going to familiarize
myself with the whole code and trying to create some prototype from
stable version. The real part
dsrbe...@gmail.com wrote:
Yes, it is.
Do you think we can figure something out so that we all benefit?
David
Alan McGovern wrote:
Hey,
Out of interest, is this a gsoc project?
Alan.
On Fri, Apr 10, 2009 at 6:03 AM, Bartosz Lipinski
baalaza...@gmail.commailto:
baalaza...@gmail.com
Hi,
Could you attach that testcase to a bug report and add a verbal description
of what exactly is wrong at http://bugzilla.novell.com . Also mention the
version of windows you're on (which is it?). That's the best way to get the
issue fixed.
Thanks,
Alan.
On Wed, Apr 29, 2009 at 7:50 AM, Rytis
The starting point for what exactly? Do you want to know how mono uses
threads for its GC, or how managed threads interact with the jit/gc. How
unmanaged threads can be registered with the runtime so they can work safely
with managed code? Or maybe you just want to understand how you can write
Hey,
On Fri, May 22, 2009 at 6:02 PM, Brian A. Seklecki
sekle...@noc.cfi.pgh.pa.us wrote:
All:
I haven't hacked on mono before; it's definitely amateur night over
here. Would it be unsound to try to compile the Olive branch against a
vanilla install of Mono 2.0.1 (FC11 or FreeBSD)?
Hey,
On Tue, Jun 30, 2009 at 4:09 PM, Alex Shulgin
alexander.shul...@yessoftware.com wrote:
Alex Shulgin wrote:
Alex Shulgin wrote:
Hi,
In the current version System.Net.NetworkInformation.NetworkInterface
provides limited information about network interfaces on the system (their
names
Hey,
On Wed, Jul 15, 2009 at 1:00 AM, Jon Shemitz jon.shem...@access-company.com
wrote:
Thanks - someone sent me that privately, and it did the trick.
*cough* whoops, I thought I had hit reply to all ;) Glad it's working
anyway.
Alan.
Perhaps `gmcs --help` could explain this better. It
Hey,
Could you take that testcase and info a file a bug report on
bugzilla.novell.com
. This way the isse won't be forgotten about and will be dealt with
properly.
Alan.
On 26 Jul 2009, at 17:50, St4rNin3 st4rn...@gmail.com wrote:
I am having some issues with Regex processing. It
Hey,
On 28 Jul 2009, at 18:36, Miguel de Icaza mig...@novell.com wrote:
Hello Jérémie,
Why are the files in System.Core, could we not put the files in
their final location (which seems to be mscorlib) from the start?
Fromyalkibg to jeremie earlier, i think it's partially because of
Hey,
On 28 Jul 2009, at 22:07, Miguel de Icaza mig...@novell.com wrote:
Hello,
Why are the files in System.Core, could we not put the files in
their final location (which seems to be mscorlib) from the start?
Fromyalkibg to jeremie earlier, i think it's partially because of
legacy
Hi,
Unless I'm missing something, you haven't actually described what the
problem is. Nor have you mentioned what exactly happens on windows, what
happens on linux and what you actually expected to happen. Your example also
appears to be missing information which might help figure out what issue
Hey,
On Thu, Oct 1, 2009 at 6:56 PM, LKeene lionel.ke...@gmail.com wrote:
Has the Task Parallel Library been performance tested on OSX? I've been
having a tough time getting any kind of performance out of my threads on
the
Mac+Mono platform. Maybe this is the solution?
Unlikely. I mean
Calling 'ToString' is just a GC benchmark. Yes, the current mono GC is
slower than the .NET GC in this scenario. Your other tests also do a fair
bit of allocating, so it's quite possible the entire performance loss you're
seeing is just from the GC kicking in. If you want to test how fast you can
What makes you think it's not implemented? If you're attempting to subclass
WebResponse and are seeing NotImplemented exceptions, it's because you must
override those particular methods (and not call the base method!) and you
have not done so. The behaviour is the same on MS.NET.
Alan.
On Fri,
If the key is random, a hashtable is the fastest way. You may be able to eke
some extra speed out of the DictionaryK, V class by ripping all the code
to support generic keys and instead hardcode the key to always be a long.
That should save a bit of time, though whether it'd be noticable or not I
Really what you need to do is benchmark all of the different options using
your expected workload. It's near useless us telling you X is faster or Y is
better without knowing the workload involved.
Alan.
On Wed, Oct 28, 2009 at 2:40 PM, pablosantosl...@terra.es
pablosantosl...@terra.es wrote:
a wrapper to Judy
Alan.
Alan McGovern wrote:
Really what you need to do is benchmark all of the different options
using your expected workload. It's near useless us telling you X is
faster or Y is better without knowing the workload involved.
Alan.
On Wed, Oct 28, 2009 at 2:40 PM
Hey,
On Mon, Nov 9, 2009 at 6:29 PM, Avery Pennarun apenw...@gmail.com wrote:
On Mon, Nov 9, 2009 at 1:10 PM, Miguel de Icaza mig...@novell.com wrote:
I just blogged about a memory fragmentation issue here:
http://tirania.org/blog/archive/2009/Nov-09.html
And I am
Hi,
Thanks for the bug report. Would you be able to file the issue on bugzilla
(with the testcase) and assign it to me (amcgov...@novell.com). That way I
can fix it and have the paper trail to verify the fix works.
If you come across any other issues, just assign them directly to me on
bugzilla.
Product / Component shall I use when I'm
entering a new bug?
Thanks,
Martin
Alan McGovern-2 wrote:
Hi,
Thanks for the bug report. Would you be able to file the issue on
bugzilla
(with the testcase) and assign it to me (amcgov...@novell.com). That way
I
can fix it and have the paper
Hey,
MonoTorrent uses the standard .NET threadpool for all asynchronous sockets.
It's all standard Socket.BeginReceive/Socket.EndReceive calls. I've run it
with ~150 open connections in the past with no issues, though it's worth
noting that 150 open connections != 150 actively transferring
with a
large number of actively transferring connections ( 50) I only need a
handful of threadpool threads. If you starve the threadpool, your
performance will suffer accordingly ;)
Alan.
On Mon, Dec 7, 2009 at 8:17 PM, Alan McGovern alan.mcgov...@gmail.comwrote:
Hey,
MonoTorrent uses the standard
According to the rule - any using statement starting with System. should
be sorted first. It's nothing to do with the assembly that the namespace
comes from.
Alan.
On Tue, Dec 8, 2009 at 11:27 AM, Andrew Mikhailov and...@vitche.com wrote:
The MS defines a code-style rule for the order in
There were two commits to SVN with regards to this bug so it looks like it
was accidently not closed. CC'ing the guy who committed those fixes as he'd
be the one to know whether it should be closed or not.
Alan.
On Wed, Dec 9, 2009 at 10:41 PM, Oskar Berggren oskar.bergg...@gmail.comwrote:
The
Hey,
1) Is the LLVM back-end intended to be a long term solution to code
optimization for performance sensitive code in mono?
2) How confident are you that the issues described can be resolved without
kludge?
3) Would success with the LLVM back-end necessarily curtail efforts to
improve
Hey,
This patch does three things:
1) Optimises away some allocations - good
2) Added extra checks which throw exceptions - without providing testcases -
bad
3) A fair few whitespace changes - bad
Would you be able to submit two patches instead? The first should do the
optimisation, the second
Actually, ignore the part about the 1 = m_buffer.Length. On second reading
that's fine ;)
Alan.
On Mon, Jan 11, 2010 at 11:24 PM, Alan McGovern alan.mcgov...@gmail.comwrote:
Hey,
This patch does three things:
1) Optimises away some allocations - good
2) Added extra checks which throw
Hey,
The main reason why I didn't actually do any work on this at the time is
that it would probably take 1 man month to do the rewrite, pass the existing
tests and write more tests for the new behaviours and I didn't have a month
free to do it ;) Proper support for the new parser API is required
Hey,
Questions 1-3 would be best directed at the developer of csharp-sqlite. He
is not affiliated with mono in any way (that I know of).
As for the final question, I'm not aware of anyone writing an
ADO.NETwrapper for csharp-sqlite. If someone were interested in
creating one, i'm
sure it'd be
come up with a more
definite suggestion.
Cheers,
Matt.
*From:* Alan McGovern [mailto:alan.mcgov...@gmail.com]
*Sent:* 11 February 2010 11:45 PM
*To:* Miguel de Icaza
*Cc:* Matt Dargavel; mono-devel-list@lists.ximian.com
*Subject:* Re
This bug was fixed for 2.4.3 but has regressed again.
https://bugzilla.novell.com/show_bug.cgi?id=583451
Would it be possible to get this fixed for 2.4.4+ ? It does work in the 2.6
branch as of r151801, so no need to prioritise this one now ;)
Alan.
On Tue, Feb 23, 2010 at 11:04 PM, Miguel de
A visual studio compiled binary and mono compiled binary are more or
less identical. Just copy/paste the compiled code to a linux system
and execute it there.
Alan.
On Thu, Apr 8, 2010 at 9:17 AM, Matt Dargavel m...@shout-telecoms.com wrote:
Hi, I suggest you start here:
Can you provide a testcase demonstrating the issue.
Thanks,
Alan.
On Thu, Mar 25, 2010 at 2:59 PM, Stifu st...@free.fr wrote:
MonoDevelop on Windows uses .NET by default, not Mono.
boolean wrote:
Another solution with delegates instead of invoke brings no advantages.
It´s curious on
Can you provide a testcase demonstrating the bug or more clearly
explain what you mean by using code samples?
Thanks,
Alan
On Wed, Mar 24, 2010 at 1:50 AM, Pigo Chu pigo_...@hotmail.com wrote:
I am designing a simple http server use Async Socket model.
And test performance use ab (apache
This is a known issue in our build system. run make clean and/or
make distclean and then autogen and build again. That'll resolve the
problem.
Alan.
On Mon, Mar 1, 2010 at 10:03 PM, Neale Ferguson ne...@sinenomine.net wrote:
Just updated to head, did get-monolite-latest and getting this during
Hey,
Firstly, could you try with a newer mono. If there is a bug in 2.0,
there's not a chance of a new 2.0 release being made and it's also
quite possible that the issue has been fixed since then. If the bug is
still there in mono 2.6+ then file a bug report with all relevant
info. You could also
Hey,
Join us in the #monosoc channel on irc
(http://www.mono-project.com/IRC). Also, I believe the deadline for
proposals is tomorrow so you should probably submit a proposal asap
which can be updated/modified later on as required. If you miss that
deadline, there's not a chance of the project
Is there a testcase for this? This works fine for me, I'm inclined to
believe there's a bug in the testcase.
Alan.
On Fri, Apr 9, 2010 at 4:21 PM, Stefan [At] swieser1...@gmail.com wrote:
socket.BeginReceive(receive_buffer, 0, FlockNode.buffer_size, 0,
new AsyncCallback(ReceiveDone), socket);
Hey,
It really does look like a valid issue but as it stands there's no
testcase to reproduce the issue. I do this *all* the time in the
testcases for MonoTorrent and my callbacks are always invoked. I
explicitly test for this in some of my testcases. There are times when
EndReceive is not
Hey,
As per error message, you're missing libgdiplus. If you install that
everything should work fine.
Alan
On 19 Apr 2010, at 06:12, Lyndon Lu lyndon...@gmail.com wrote:
Hi All,
I have installed mono 2.6.3 from source files in CentOS 5. I can
see that test web page Welcome to
Hey
More than 50% of your patch is whitespace noise which makes it hard to
see what exactly it is you're fixing. Could you submit a patch without
all the extra whitespace changes?
Secondly, I'd personally view any code which relies on the element
ordering in a dictionary as being a bug
Why would a c-cast be so much slower than an 'as' cast? Surely they
should be equivalent or the c-cast should be faster.
Alan.
On Mon, May 10, 2010 at 7:24 PM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
Well, it wasn't really internal, but that does not affect my statement.
Follow this guide:
http://www.mono-project.com/Parallel_Mono_Environments and enter your
parallel environment before compiling the debugger.
Also don't mix SVN versions of mono with released versions of the
debugger. You need to keep everything in sync. Either use 2.6.3 of
both mono and the
You're installing a trunk build of mono with a 2.6.3 release of the
debugger. This is a mismatch. As Michael said, SDB is built into the
runtime these days so could more than likely just use that.
Alan.
On Wed, May 12, 2010 at 7:03 PM, sberryman sh...@golfsigma.com wrote:
I don't have a
It works fine with r156922 from SVN. When building from trunk, always
give the svn revision that you built with.
Alan.
On Sat, May 22, 2010 at 5:36 PM, xplicit s...@ngs.ru wrote:
I have compiled mono 2.7 from trunk and try to use C# 4.0 features. I wrote
simple program:
using System;
I am thinking of a Java/.NET split if you will where we keep what we
can that WILL run under Mono and port the rest to Java. That assumes
we can get the two to play nicely together.
Depending on what it is that doesn't work, it's possible that it'd
only take you a couple of days could fix your
There was a regression in trunk about 2 weeks ago which was fixed
about 4 days ago which was very similar to this. However your testcase
appears to fail on both mono 2.6.4 and svn trunk. Would you be able to
file a bug report with this testcase?
Thanks!
Alan.
On Sat, May 29, 2010 at 2:11 AM,
.
Alan.
On Sun, May 30, 2010 at 4:53 PM, Alan McGovern alan.mcgov...@gmail.com wrote:
There was a regression in trunk about 2 weeks ago which was fixed
about 4 days ago which was very similar to this. However your testcase
appears to fail on both mono 2.6.4 and svn trunk. Would you be able to
file
So the patch fixes the Begin/EndSend issue but breaks BeginConnect?
Maybe that's a good reason to not commit the patch until the issue
with BeginConnect is fixed. Would you be capable of diagnosing andor
fixing the issue or do we need another OSX guy to look at it? You
should probably add
The reason why there are no synchronous calls in silverlight is (I
believe) because you can easily deadlock the plugin by attempting a
synchronous call when using the browser http stack. For the web
request to be completed, the browser has to be able to iterate and if
a plugin is blocking,
101 - 194 of 194 matches
Mail list logo
