Tom,
I beleive that we had a problem with this before and I applied a fix.
http://anonsvn.mono-project.com/viewvc?view=revisionrevision=121114
IIRC this code/fix should release all outstanding rcws before the
final collect of other mono objects, including ccws.
Can you investigate if this
Sylvain
Committed to the trunk. r149817
Thanks
-bill
On Mon, Nov 9, 2009 at 7:17 AM, Sylvain Dupont dupo...@gmail.com wrote:
Hi,
The patch attached is a continuation of my previous patch committed in
r136836. It adds support for [in] parameters of type SAFEARRAY[VARIANT], and
also for
Hi,
The attached bug fixes calling a remoting method that has an arguments
that is an out generic.
There is also a test attached.
2009-10-05 Bill Holmes billholme...@gmail.com
* object.c (mono_method_return_message_restore) : Adding the
MONO_TYPE_GENERICINST case to handle
Hi,
The attached patch fixes a bug with calling a COM method using a
delegate. I have also added a unit test for this bug.
2009-09-09 Bill Holmes billholme...@gmail.com
* object.c (mono_object_get_virtual_method) : Call
mono_cominterop_get_invoke if the object is a COM
Hi,
The attached patch fixes Mono on Windows not respecting the
WindowStyle property of the start info when calling Process.Start with
UseShellExecute set to true.
-bill
2009-07-10 Bill Holmes billholme...@gmail.com
* process.c
contains a fix the missing implementation of
g_win32_getlocale in eglib.
-bill
2009-06-23 Bill Holmes billholme...@gmail.com
* locales.c
(ves_icall_System_Globalization_CultureInfo_construct_datetime_format)
(ves_icall_System_Globalization_CultureInfo_construct_number_format
, etc.
3) Changelog entries:
I updated the changelogs in the 3 directories where I made changes.
Thanks,
Sylvain
On Wed, Jun 3, 2009 at 5:02 PM, Bill Holmes billholme...@gmail.com wrote:
Sorry I should have mentioned that I tested this on Win32 and Winx64.
On Wed, Jun 3, 2009 at 5:00 PM
and ves_icall_System_Globalization_CultureInfo_construct_number_format
for Windows to obtain the correct settings.
Also this patch contains a fix the missing implementation of
g_win32_getlocale in eglib.
-bill
2009-06-23 Bill Holmes billholme...@gmail.com
* locales.c
.
http://msdn.microsoft.com/en-us/library/ms684954(VS.85).aspx
This only applies to threads that are stopping (process shutdown) and
are background threads.
-bill
2009-06-22 Bill Holmes billholme...@gmail.com
* object-internals.h : Adding interrupt_on_stop field.
* threads.c
After more discussion on IRC this it was decided to do this using the
dllmap and not an environment variable.
If the target is set to . the declaring assembly directory will be
used when attempting to locate the un-manged library.
-bill
2009-06-03 Bill Holmes billholme...@gmail.com
I tested this patch out and the cominterop.exe test does not work. I
get a return value of 62.
Second I noticed some tab problems with your formatting in cominterop.cs.
Finally It makes it easier for me to commit a patch if you include
ChangeLog entirs.
thanks
-bill
On Sun, May 17, 2009 at
Sorry I should have mentioned that I tested this on Win32 and Winx64.
On Wed, Jun 3, 2009 at 5:00 PM, Bill Holmes billholme...@gmail.com wrote:
I tested this patch out and the cominterop.exe test does not work. I
get a return value of 62.
Second I noticed some tab problems with your
Tom,
Can you test the attached patch against your code? You patch worked
just fine, but I did not want to add the
mono_class_get_all_implemented_interfaces to class.c.
Please let me know if this works for you.
-bill
On Wed, Apr 29, 2009 at 7:20 PM, Tom Hindle tom_hin...@sil.org wrote:
Hi,
with
the suffixes .exe, .cmd, .bat and .com, and the suffixes in the
PATHEXT environment variable.
-bill
2009-06-02 Bill Holmes billholme...@gmail.com
* src/gpath.c (g_find_program_in_path): While searching on Windows
also try additional suffixes .exe, .cmd, .bat, and.com
an environment variable could control
this behavior.
Whit this patch setting MONO_PINVOKE_SEARCH to USE_ASSEMBLY_PATH will
enable this.
-bill
2009-06-01 Bill Holmes billholme...@gmail.com
* loader.c (mono_loader_init): Check for and process
the MONO_PINVOKE_SEARCH environment variable
.patch contains all the changes for BSTR, CoTaskMem
and HGlobal, but I will commit the BSTR fix first and then other
allocator changes second.
-bill
2009-05-28 Bill Holmes billholme...@gmail.com
* marshal-hooks.h : Adding declaration for
mono_install_alloc_hglobal_funcs
. If this is approved I
will be adding similar code for Marshal.AllocCoTaskMem and
Marshal.AllocHGlobal, which will be a separate commit.
2009-05-22 Bill Holmes billholme...@gmail.com
* cominterop.c : mono_string_to_bstr, mono_string_from_bstr and
mono_free_bstr changed to call external hooks
I tested the patch and the test program on my x64 XP machine. (64-bit
and WOW64.)
The test program runs as expected and the runtime tests show no problems.
-bill
On Thu, May 21, 2009 at 9:40 AM, Rodrigo Kumpera kump...@gmail.com wrote:
Here is a test program that can be used to verify how it
Hi,
socket-wrappers.h includes sys/select.h and sys/time.h. These files
are not available for the MSVC builds. The attached patch moves those
include statements to the !WINDOWS part of socket-wrappers.h.
2009-04-24 Bill Holmes billholme...@gmail.com
* socket-wrappers.h : Move
to execute the APC. Adding a sleep
provides that opportunity.
-bill
2009-04-01 Bill Holmes billholme...@gmail.com
* finalizer-abort.cs, finalizer-exception.cs, finalizer-exit.cs :
Adding a sleep to the waiting thread to give Mono on Windows an
opportunity to interrupt
, 2009 at 10:33 AM, Rodrigo Kumpera kump...@gmail.com wrote:
This is only a hack around the fact the we don't support proper interruption
on windows.
2009/4/1 Bill Holmes billholme...@gmail.com
Hi,
On Windows some of the runtime tests are not completing since r127661
(I believe
2009/3/25 Bill Holmes billholme...@gmail.com
Hi,
The attached patch fixes some problems I was seeing with thread IDs on
Winx64.
What I found was that the thread ID argument of CreateThread is a
ulong which is not 64 bits on Winx64. So when called with the address
of a size variable the top
initializes all thread ID variables to zero before calling
CreateThread. Is there a better way to fix this?
-bill
2009-03-25 Bill Holmes billholme...@gmail.com
* appdomain.c (mono_domain_unload),
* attach.c (transport_start_receive),
* threads.c (mono_thread_create_internal
Kornél,
Yes that would work too.
Thanks
-bill
2009/3/25 Kornél Pál kornel...@gmail.com:
Wouldn't just this be enough?
in mono_thread_create_internal:
#ifdef PLATFORM_WIN32
DWORD tid;
#else
gsize tid;
#endif
Kornél
Bill Holmes wrote:
Hi,
The attached patch fixes some problems I
native to managed that include
bool arguments and is not exclusive to COM.
-bill
trunk:
2009-02-13 Bill Holmes billholme...@gmail.com
* object-internals.h : Fixing a typo in the
MonoReflectionComVisibleAttribute struct.
* marshal.c (cominterop_com_visible): Check
Hi,
The attached patch fixes some problems we are seeing with marshaling
bools and IDspatch types in Native code.
I can split the patch separating the bool changes form the dispatch
changes if needed. I would like to apply this to the 2.4 branch as
well.
-bill
2009-02-12 Bill Holmes
Can someone look at this? I will fix my spelling in the ChangeLog
before I commit. ;)
On Tue, Feb 3, 2009 at 1:15 PM, Bill Holmes billholme...@gmail.com wrote:
Hi,
The attached patch corrects an error I introduced with r122252. I
would like to apply it to the 2.4 branch as well.
-bill
Hi,
The attached patch corrects an error I introduced with r122252. I
would like to apply it to the 2.4 branch as well.
-bill
2009-02-03 Bill Holmes billholme...@gmail.com
* socket-io.c (ves_icall_System_Net_Sockets_Socket_Accept_internal):
For Win32, add additoinal break
Miguel,
Please add the attached patch to your changes.
thanks
-bill
2009/1/28 Miguel de Icaza mig...@novell.com:
Hello folks,
For the sake of better supporting proprietary operating systems, we
need to split some of the functionality that today lives inside #ifdefs
in mini.c
The
PM, Bill Holmes wrote:
Hi,
The attached patch fixes the attached test.cs.
Uri.IsWellFormedUriString calls the .ctor which throws an exception.
The .ctor throwing the exception is expected behavior,
IsWellFormedUriString throwing is not expected.
I would also like to apply this to the 2.4
as suggested by Robert?
If so, it is OK to get this on the 2.4 branch.
Miguel.
On Jan 21, 2009, at 12:01 PM, Bill Holmes wrote:
Hi,
The attached patch fixes the attached test.cs.
Uri.IsWellFormedUriString calls the .ctor which throws an exception.
The .ctor throwing the exception
Hi,
Look at the ExtensibleClassFactory.RegisterObjectCreationCallback method.
http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.extensibleclassfactory.registerobjectcreationcallback.aspx
-bill
On Tue, Jan 20, 2009 at 4:22 PM, QbProg tho...@gmail.com wrote:
Hello Mono
Alfredo,
I may not fully understand the problem. Are you simply asking how to
call back into C# from C++?
We use 2 different approaches.
Function pointers. If you pass a C# delegate through the PInvoke
layer C++ will view that as a function pointer.
COM Interop. (Only supported on Windows
Hi,
The attached patch fixes a bug with launching an application on a
network share with mono.
-bill
2009-01-13 Bill Holmes billholme...@gmail.com
* gmisc-win32.c (g_path_is_absolute): Adding support for UNC
paths on Windows.
* mono-path.c (mono_path_canonicalize
Hi,
I was debugging a problem with our application on Winx64 and tracked
it to some non-volatile registers not being preserved (rdi rsi)
Without finding the actual problem I simple scanned the code for
places referencing the other non-volatile registers and added code for
the missing registers.
Tom,
I agree with Kornél. Please add mono_init_com_types to
GetIUnknownForObjectInternal and GetIDispatchForObjectInternal. I do
not understand why it would be needed in QueryInterfaceInternal. Even
if the object is managed, cominterop_ccw_queryinterface would need the
mono_init_com_types
Kornél,
I do agree that this is a general problem and not only an issue with
accept. Also I do know that the patch is a workaround, or as we like
to say treading the symptom and not that cause.
I have spent much time trying to understand the shutdown behavior of
MS. From what I can gather I
Kornél,
I do not understand what you example shows. I can understand the
thread state problems. Is that all?
Are you suggesting that I add to my patch to fix the state problem?
Are you suggesting that the socket implementation is fine in svn and
we need to address the abort/stop thread in a
Kornél,
After reading your mail a bunch more times and messing with the sample
I think I finally get what you were saying.
What I discovered was that the APC callback being a managed method
gives mono a chance to check the thread state when crossing to and
from the managed thread boundary. It
We have dealt with this by registering a global class factory method
(that is implemented in C#) with native C++ code.
I assume you are hosting the mono runtime?
Take a look at the poor code example below and see if that gives you the idea.
-bill
/* C++ code */
void cppMain ()
{
//
that a variable
has changed.
See http://msdn.microsoft.com/en-us/library/ms682653(VS.85).aspx
Thanks
-bill
2008-12-18 Bill Holmes billholme...@gmail.com
* Environment.cs (GetEnvironmentVariable) : Avoiding an nre if
the variable is not set.
* Environment.cs
Hi,
In the get_module_name method the size argument is used as a byte
count but the callers consider it a character count.
See http://msdn.microsoft.com/en-us/library/ms683196(VS.85).aspx
This patch corrects that inconsistency.
Thanks
-bill
2008-12-18 Bill Holmes billholme...@gmail.com
Hi,
The attached patch fixes the attached Program.cs.
2008-12-17 Bill Holmes billholme...@gmail.com
* ListViewItem.cs (ListViewSubItem.ctor): Initalizing the
SubItemStyle member field.
Contributed under MIT/X11 license.
-bill
class Program
{
static void
Kornél,
I tested your case and it appears to work fine with my changes. I
believe that this is because I check for the ThreadState_StopRequested
state. I do not check for ThreadState_AbortRequested. That is
intentional because that is the behavior I observed with MS .net.
Also if I understand
supports Dispatch that is the tricky part. From what I have
read and what I have observed a public object with the ComVisible
attribute set to true support IDispatch. All others only support
IUnknown.
-bill
For CCW_Dispatch.diff
2008-12-09 Bill Holmes [EMAIL PROTECTED]
* object
David,
We may have hit this before. See
http://www.nabble.com/String.GetHashCode-Discussion.-to18496625ef1367.html#a18496625
I lost tack of this issue after that thread but maybe it will help
someone else remember.
-bill
On Mon, Dec 1, 2008 at 9:25 AM, David Suarez
[EMAIL PROTECTED] wrote:
Hi,
We are seeing a problem with applications that host the mono and use
COM. The attached patch includes code that will cause the runtime to
release all COM objects that are registered in the rcw hash map in
marshal.c.
-bill
2008-11-20 Bill Holmes [EMAIL PROTECTED]
* mini.c
Hi,
The attached patch adds an implementation for IMarshal to all COM
callable wrappers. This patch should only affect Windows builds.
I also would like to get this patch into the 2.2 branch.
-bill
2008-11-17 Bill Holmes [EMAIL PROTECTED]
* marshal.h
Hi,
The attached patch is a better implementation of
Process.WaitForInputIdle for Windows. The behavior for all other
platforms has not changed.
I would also like to add this to the 2.2 branch.
2008-11-12 Bill Holmes [EMAIL PROTECTED]
* process.h : Adding method declaration
Hi,
This configuration works correctly for me. I believe the problem is
that you are using the VS Dependency zip-archive. That archive has
not been kept up to date. I know there is documentation somewhere
that points to using it but that should be changed.
From
Hi,
I believe that r118412 fixes
https://bugzilla.novell.com/show_bug.cgi?id=443056 at least.
-bill
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
I'm trying to build Win32_Release_eglib release. genmdesc and monoburg
projects are missing ;..\eglib\src from additional include directories path.
Also eglib library is built too late for both those projects.
This is due to my only laziness. I did not set up the dependency list
correctly
Hi,
Attached is a patch to implement the Null field of the TextReader.
There is also a test.
2008-11-07 William Holmes [EMAIL PROTECTED]
* corlib_test.dll.sources: Add TextReaderTest.cs.
* TextReaderTest.cs: Added a test for the Null field of
the TextReader.
for this.
2008-11-06 Bill Holmes [EMAIL PROTECTED]
* Type.cs (FindMembers): Changing the instantiated type of the
returned MemberInfo array to match the MemberTypes flag
passed in argument 1.
* TypeTest.cs: TypeGetMemberReturnTypeTest added to check
I am fixing this right now.
On Wed, Nov 5, 2008 at 1:36 PM, Alexander M. Batishchev
[EMAIL PROTECTED] wrote:
Hello everybody,
I'm trying to compile Mono from SVN under VS 2008. Opened mono\msvc\mono.sln
and got error (after successful conversion of course) in eglib:
First of all options
Fixed in trunk. r118012
On Wed, Nov 5, 2008 at 1:42 PM, Bill Holmes [EMAIL PROTECTED] wrote:
I am fixing this right now.
On Wed, Nov 5, 2008 at 1:36 PM, Alexander M. Batishchev
[EMAIL PROTECTED] wrote:
Hello everybody,
I'm trying to compile Mono from SVN under VS 2008. Opened mono\msvc
Can someone please look at this?
-bill
On Tue, Oct 21, 2008 at 10:18 AM, Bill Holmes [EMAIL PROTECTED] wrote:
The attached patch is to add some additional preprocessor to
support/map.c. I am starting to add MonoPosixHelper.dll to the VS
build for Winx64.
I do have some questions about
for sys/time.h and utime.h already.
There does not appear to be a check for unistd.h but #define
HAVE_UNISTD_H does appear in config.h. Does a check need to be added?
Is it obvious that I know nothing about autogen, autoconf and make? ;)
-bill
2008-10-21 Bill Holmes [EMAIL PROTECTED
Hi,
Try gmcs instead of mcs.
-bill
2008/10/14 mike horsley [EMAIL PROTECTED]:
I can use the following on MS:
System.Configuration.ConfigurationManager.AppSettings(……..)
This requires a reference to System.Configuration.
I'm trying to do the same on mono 2.0 (using the VMWARE image)
Hello All,
I have found a problem loading ms generated COM interop assemblies.
This patch fixes the problem.
-bill
LoadLib_08_09_18.diff
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Hello All,
The attached patch fixes some problems I was having with
Process.ErrorDataReceived and Process.BeginErrorReadLine.
There are actually two fixes here. The most critical is that the
fields of ProcessAsyncReader dd not match MonoSocketAsyncResult.
The second part removes the extra '\r'
If it's not abusing of your good will. Please add some comments to
Process.cs, Sockets.cs and socket-io.h mentioning this
needs to be sync'ed in 3 places.
I was thinking the same thing. I will add that.
About stripping the '\r', won't that cause problems on unix machines?
I will have to
Hello All,
The following patch was created from the 2.0 branch. I would like to
commit it to the branch as well as the trunk.
Basically on Windows we need to allocate the memory using GlobalAlloc
for these calls.
I have plans to revisit
It would be useful to add unit test cases so this behavior is also
enforced in the code. Mind adding those?
I may not understand what you want. I attached a test for what I
think you want.
-bill
#include glib.h
#include test.h
RESULT
test_memory_zero_size_allocations ()
{
gpointer
Hello All,
Attached is a patch to change eglib memory allocation methods to
return NULL if the size is passed in is zero. If this is approved I
would also like to put it into the 2.0 branch.
I tracked a bug to load_modules in image.c. In this particular case
image-modules was being set to a
Hello All,
Does anyone mind if I backport r108759 to the 2-0 branch? The diff
for that change is attached.
-bill
108759.diff
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Hello All,
I have a patch for the trunk that gets WInx64 back to a running state
with the new Linear IR code. As Zoltan promised it was mostly
relocating some of my previous commits to a new location.
If this patch is too large and needs to be split into smaller changes
I can do that.
As far
generated the method that we are
attempting to call.
I would also like to put this change into the branch as well.
-bill
On Thu, Jul 17, 2008 at 7:14 PM, Bill Holmes [EMAIL PROTECTED] wrote:
Hello All,
I did some investigation on Win32 about why the pinvoke3 runtime test
was failing. What I
Hello Zoltan,
This was a link that was shared with me on IRC.
From http://www.sco.com/developers/devspecs/abi386-4.pdf
A function that returns a structure or union also sets %eax to the
value of the original
address of the caller's area before it returns. Thus when the caller receives
control
Hello All,
The attached patch fixes problems on Winx64 with method calls that
have floats and non-float types mixed in the argument list.
This patch should only affect Winx64 code.
I am asking for approval for the trunk as well as the 2.0 branch.
thanks
-bill
float_x64_08_07_21.diff
Hello All,
The attached patch focuses on fixes needed for calls to manged from
native that pass structs by value.
Although there are no PLATFORM_WIN32 checks in this patch, it should
have no runtime impact on any other platform. This patch only adds
implementation to the ArgValuetypeAddrInIReg
patch first.
Rodrigo
On Mon, Jul 21, 2008 at 8:20 PM, Bill Holmes [EMAIL PROTECTED] wrote:
Hello All,
The attached patch focuses on fixes needed for calls to manged from
native that pass structs by value.
Although there are no PLATFORM_WIN32 checks in this patch, it should
have
Hello All,
The attached patch fixes the vararg.exe runtime test on Winx64. The
MonoTypedRef is not always passed on the stack on Windows. Calling
add_valuetype will select the correct operation.
-bill
MONO_TYPE_TYPEDBYREF.diff
Description: Binary data
I have been asked to move this discussion to the e-mail list from IRC.
Basically we (my company and I) have new unit tests errors in 2.0
that did not occur at 1.9. The errors were traced to the
String.GetHashCode change. I had one of our interns (Mike) research
the change and I wanted to share
Hello All,
I have a small threading patch that needs reviewed. Also contained in
this patch are two unit tests that the changes to threads.c are meant
to address.
-bill
threadInterrupt.diff
Description: Binary data
___
Mono-devel-list mailing list
Hello All,
Attached (cleanStack_08_07_07.diff) is a small patch that should be
specific to Winx64 only that will cleanup the stack after each call
emitted from mono_arch_output_basic_block. The calling convention on
Winx64 requires that the caller always cleans the stack. (At least as
far as I
Zoltan,
Agreed. I have attached an update.
-bill
On Mon, Jul 7, 2008 at 3:03 PM, Zoltan Varga [EMAIL PROTECTED] wrote:
Hi,
It might be easier to define IS_STDCALL as FALSE on windows, since
afaik there is
no stdcall calling convention on winx64.
Zoltan
2008/7/7 Bill
Hello All,
I have made another change to patch. The difference from the last is
that the unwindinfo pointer has been moved from MonoCompile to
MonoCompileArch struct.
-bill
On Tue, Jun 24, 2008 at 2:59 PM, Bill Holmes [EMAIL PROTECTED] wrote:
I have updated the patch with Robert's suggestion
let Bill Holmes give more details, as he has been working on
finishing the port. At this point, I believe the regressions tests on Win64
are only slightly worse than on Win32 (maybe 5-10 more tests failing, IIRC).
I don't believe a full bootstrap has been attempted with mcs yet.
The biggest
I have updated the patch with Robert's suggestion.
-bill
On Sat, Jun 14, 2008 at 6:26 AM, Robert Jordan [EMAIL PROTECTED] wrote:
Bill Holmes wrote:
Hello All,
After a week of digging though awful online documentation I have
finally got a patch for the exception unit tests in the runtime
Hello All,
After a week of digging though awful online documentation I have
finally got a patch for the exception unit tests in the runtime for
Winx64.
The attached patch appends the information to the code block for a
method using structures that MS SEH understands. There is also a
small stack
I have been doing more work with passing arguments to native calls on
Winx64. The attached patch handles the case of an argument that is a
struct that is not able to be passed in a register.
http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx
I spoke to some of you about this on IRC.
The attached patch fixes the compilation errors in MSVC with the eglib targets.
-bill
my_g_bit_nth_msf.diff
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
The attached code is some of the fixes needed for marshaling structs on Winx64.
In mini-amd64 two things have been fixed.
1) Structs containing floats are passed in the integer registers, not
the float registers.
2) Only structs that are 1,2,4,or 8 bytes will be copied into a
register. All
I have updated this patch based off a discussion with Zoltan on IRC.
-bill
On Wed, May 28, 2008 at 11:00 AM, Bill Holmes [EMAIL PROTECTED] wrote:
I have a small patch that seems to have fix a bunch of issues with the
unit tests under mono/tests for Windows x64. Please review and let me
know
Last patch for the week. I promise.
These changes are to make libtest.c ready to be compiled in Visual
Studio. I will be sending the patch for the new VS project and update
to the solution.
The STDCALL statements had to be moved and I added declspec(dllexport)
statements to all methods. At
Hello All,
First of all I apologize to those of you who may view this as spam.
I work for ANSYS Inc. and we have full time positions available that
may be of interest to some of you in this group. The particular
position that I list below works closely with my group and we are
hoping to fill it
Paramesh,
The following link is what I use. I have found it extremely useful.
http://shana.iidbbs.com/en/mono_cygwin_tutorial.html
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
===
--- mono/eglib/ChangeLog (revision 100107)
+++ mono/eglib/ChangeLog (working copy)
@@ -1,5 +1,15 @@
-2007-03-19 Bill Holmes [EMAIL PROTECTED]
+2008-04-08 Bill Holmes [EMAIL PROTECTED]
+ * src/glib.h : Adding declarations for g_ucs4_to_utf16 and g_utf16_to_ucs4.
+
+ * src/gutf8.c
Theses changes are needed for building the mono runtime with Visual
Studio. Please review and let me know if it is OK to commit. The
diff file has Windows end of lines.
thanks
-bill
msvcBuildFixes_2008_03_10.diff
Description: Binary data
___
Thanks Zoltan.
Committed r97889
-bill
On Mon, Mar 10, 2008 at 1:34 PM, Zoltan Varga [EMAIL PROTECTED] wrote:
Hi,
This is ok to check in.
Zoltan
2008/3/10 Bill Holmes [EMAIL PROTECTED]:
Theses changes are needed for building the mono runtime with Visual
Studio. Please
Please review the attached diff file and let me know if it is OK to
commit. It is fixes for a couple of build errors, and bugs with eglib
on Windows.
I am not very confident of my implementation of g_get_charset but it
does work for what I need it to do. Any suggestions on how to make
this
Sorry All. I have to send this again because I found a bug in my
refactoring about 30 seconds after I hit send.
-bill
On Mon, Mar 10, 2008 at 6:52 PM, Bill Holmes [EMAIL PROTECTED] wrote:
Please review the attached diff file and let me know if it is OK to
commit. It is fixes for a couple
I did not want to file a bug on this just yet as it may be related to
https://bugzilla.novell.com/show_bug.cgi?id=319247 . Or it just may
be a bad test case.
The following code under MS.net displays
_activeCount = 1
_activeCount = 0
Where mono displays
_activeCount = 1
_activeCount = 1
I have been able to reproduce this with the 1.2.6_4 install on
Windows. I was able to compile the library and exe using csc and it
does run fine on Mono. Also I have compiled using gmcs and run with
the MS runtime and I get the following exception.
Unhandled Exception:
On 10/18/07, Paolo Molaro [EMAIL PROTECTED] wrote:
You need to also add a test case to the test suite to exercise the new
code.
Here are the tests for my previous commit. OK to commit?
-bill
Index: mono/mono/tests/pinvoke2.cs
===
I ran across some code in my app that marshaled boolean types as U1
and was receiving a g_warning from the mono runtime. marshalling
bool as native type %x is currently not supported
Changing my code to I1 is easy enough but I wonder if U1 should be
supported. This patch does that.
I had to
goto removed
short write case fixed
function definition formatting fixed
thanks
-bill
Index: mono/mono/metadata/file-io.c
===
--- mono/mono/metadata/file-io.c (revision 84466)
+++ mono/mono/metadata/file-io.c (working copy)
@@ -10,6
All,
Here is an updated version of my patch. I apologize in advance if my
attachment is a binary blob again. I am not quite sure what that
meant or what I should do about it. This time I am sending the mail
from SUSE so maybe that will help.
I have applied the changes mentioned by Rodrigo and
Attached is a patch that implements the 2.0 method File.IO.File.Replace.
http://msdn2.microsoft.com/en-us/library/9etk7xw2.aspx
Some implementation details are as follows.
-An internal call was added to perform this operation
-Most argument validation is performed in managed code.
-On windows we
1 - 100 of 106 matches
Mail list logo
