[Mono-dev] Dllimporting Fortran API in C#

2006-07-14 Thread Sunil Venkateswara
I am exporting a function in fortran and in another fortran program importing this API as follows, it works fine !-- ! FORTRAN EXPORT !--- MODULE TestExport PUBLIC GETSTRING Contains SUBROUTINE GETSTRING(str) !DEC$ ATTRIBUTES DLLEXPORT::GETSTRING CHARACTER(LEN=*) :: str

Re: [Mono-dev] Dllimporting Fortran API in C#

2006-07-14 Thread Jonathan Pryor
This message really belongs on mono-list, but I'll answer it here... On Fri, 2006-07-14 at 11:51 +0530, Sunil Venkateswara wrote: I am exporting a function in fortran...[and] to import the same fortran code by DLLIMPORT, using the following code ( added a write call and removed module

Re: [Mono-dev] Packaging NAnt

2006-07-14 Thread Rafael Teixeira
inline On 7/13/06, Wade Berrier [EMAIL PROTECTED] wrote: Hi, In trying to build and package nant, I've found that nant has some internal libraries that reference the 1.0 profile of .NET: berrier:/usr/src/packages/SPECS # rpm -i ../RPMS/noarch/nant-0.85_rc4-1.noarch.rpm error: Failed

Re: [Mono-dev] COM Interop Patch

2006-07-14 Thread Zoltan Varga
Hi, Here are my comments: - class.c OK - loader.c: - why is signature-cominterop needed, ie IS_IMPORT (m-klass) can be used instead ? - domain.c: OK - image.c: OK - metadata.c: - The comment of mono_metadata_type_dup_mp is incorrect, also: -

Re: [Mono-dev] Incremental C# compiler

2006-07-14 Thread Jonathan Gilbert
At 09:28 AM 13/07/2006 -0500, Jerry Haltom wrote: The only use I've ever had for edit and continue, which to me, is a very important use, is in the debugger. I can step through code, find an error, and quickly replace it immediately, and test the results locally in that method by stepping back and

Re: [Mono-dev] COM Interop Patch

2006-07-14 Thread Jon Chambers
Thanks for the review Zoltan. I am addressing the issues you brought up. The only issue is with the two methods needed for a COM call and their caching. The first method (the one that calls the other generated method) is the one I need to cache. You said I shouldn't mark it as wrapper type

Re: [Mono-dev] COM Interop Patch

2006-07-14 Thread Zoltan Varga
Hi, Since that method is not a native wrapper, it should go into the cominterop cache. Zoltan On 7/14/06, Jon Chambers [EMAIL PROTECTED] wrote: Thanks for the review Zoltan. I am addressing the issues you brought up. The only issue

[Mono-dev] [PATCH] Implement Graphics.ReleaseHdc()

2006-07-14 Thread Jonathan Pobst
Patch to implement 2.0 parameterless Graphics.ReleaseHdc() - Creates a private variable to hold the IntPtr that GetHdc() returns. - Stores IntPtr to private variable in GetHdc(). - In ReleaseHdc(), call ReleaseHdc(IntPtr) passing stored IntPtr. - Set private variable back to IntPtr.Zero. Please

[Mono-dev] Weird bug in new port

2006-07-14 Thread Bill Seurer
We're seeing a weird bug in the port (of Mono 1.1.15) we are working on for PASE on i5/OS (i.e., AIX). Here's a good example. If I run this C# program (a small extract from something else): class MainClass { public static void Main(string[] args) { int i;

Re: [Mono-dev] [PATCH] Implement Graphics.ReleaseHdc()

2006-07-14 Thread Sebastien Pouliot
Hello Jonathan, Please add a space before the starting parenthesis (see Mono source code guidelines in the wiki) and, more importantly, provide some unit test cases for ReleaseHdc (e.g. what happens on a second call to ReleaseHdc ?). I'll commit everything asap (or, at worse, when I get back

Re: [Mono-dev] [PATCH] Implement Graphics.ReleaseHdc()

2006-07-14 Thread Jon Chambers
Jonathan, Not sure, but would the hdc need disposed (in the Dispose method) if the user never calls ReleaseHdc?Thanks,JonathanOn 7/14/06, Sebastien Pouliot [EMAIL PROTECTED] wrote: Hello Jonathan,Please add a space before the starting parenthesis (see Mono source codeguidelines in the wiki) and,