Hi,
I seem to be having a problem running the non-error tests for MCS on
Windows. The error tests run (although some of them report errors). When I
go into mcs/tests and run "make run-test-local", I get the following error:
The assembly mscorlib.dll was not found or could not be loaded.
It should
Ah, yes. I forgot to check that m_buffer.Length == 0 is explicitly disallowed
in the constructor, so yes, eliminating an extra if will speed things up.
Here's another patch which is, again, MIT/X11 licensed.
On Jan 11, 2010, at 3:58 PM, Kornél Pál wrote:
Hi,
This actually means 1 == m_buffer.
Oh, those are nice tests. Thanks for writing them :-)
I'll examine the failing tests and will fix identified bugs.
Atsushi Eno
Tiaan Geldenhuys wrote:
> Thanks, Atsushi. Fair enough, see the attachment for the enhanced tests
> that you can also apply to the trunk; the test for my earlier patch
Hi,
This actually means 1 == m_buffer.Length that effectively means no
buffering. As such there is no use to optimize (special case) for 1 ==
m_buffer.Length.
The code will continue to function properly in this special case and
will be faster in more likely (truly buffered) use cases by simply
Alan,
Here you go. I hope these are up to spec. Again, these patches are MIT/X11
licensed.
1) Removed the spurious white space changes
2) Added test cases for ReadByte and WriteByte on non-readable and non-writable
streams respectively.
Index: mcs/class/corlib/System.IO/BufferedStream.cs
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 wrote:
> Hey,
>
> This patch does three things:
>
> 1) Optimises away some allocations - good
> 2) Added extra checks which throw exceptions - without
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 s
Sorry, for double posting this patch. Snow Leopard's Mail.app w/ Exchange
support turned my "This is contributed under the MIT/X11 license" into an
attachment.
For the record, the code in this patch is contributed under the MIT/X11 license
Index: mcs/class/corlib/System.IO/BufferedStream.cs
===
Attached is a patch that fixes the naive implementation of ReadByte and
WriteByte on BufferedStream
Index: mcs/class/corlib/System.IO/BufferedStream.cs
===
--- mcs/class/corlib/System.IO/BufferedStream.cs(revision 147679)
+++
Under gmcs r149310 pulled from SVN trunk this morning, I get a warning about
unused const members that did not appear in 147679.
ws1048-snow:monoscripts tom.philpot$ /opt/mono-r149310/bin/gmcs
~/CompilerTest.cs
/Users/tom.philpot/CompilerTest.cs(18,30): warning CS0169: The private constant
`App
I'll try to summarize it:
The Mono VM is basically the same for all the platforms supported.
There's just some IFDEFs around, mostly in the native code part, for
MacOSX, and configuration macros to enable building it for that
platform (OS plus CPU choices);
The native part of Mono, is contained i
Thanks Danie.
On Mon, Jan 11, 2010 at 1:52 PM, Daniel Morgan wrote:
> There is UNO bindings for Mono.
>
> I do not know if it still works with the latest mono and openoffice.org.
>
> Also, you probably would need openoffice.org from go-oo.org instead of the
> plain openoffice.org. I believe th
@ Rafael
Thanks for the information. It was very useful indeed.
I'll need to learn about the IL, which I think I can find lots of
resources out there.
But I also like to understand, a bit more, how the Mono VM for
MacOSX works; could you show me what resources are good please?
The Mono Hackers p
Hi London,
First answering your latest question: Yes, Monodevelop is mostly written in C#.
Back to what I could understand as your main question:
To write a compiler for a new language that will run on Mono/,NET, you can:
-1- Write it in C#, or another Managed Language. The main advantage
here i
Is anyone still working on UNO bindings or has this started at all ?
I like to ask a few questions but I'm not sure
what is the status of COM and XPCOM support at the moment ?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists
That thread has lots of useful information actually but I might
have confused you. We use Mono/C# to make addins don't we?
I like to go a bit deeper to C/C++/ObjC level in MacOSX.
What I was asking in my first email was something mentioned
in this page:
http://www.mono-project.com/Contributing
a
16 matches
Mail list logo