[Mono-dev] AIX / Mono System Requirements
Hi, I have a newbie question about Mono regarding System Requirements. Short Version: Does it make any sense to try to use/compile Mono under AIX right now? Or should I better be using Linux and with which Kernel (2.4 or better 2.6?)? Long version: I have been a long time user of Java but it never really made me happy, especially when it came to socket programming. I needed a separate Thread for listening to a socket, i.e. memory for each socket, and when NIO came I had to write my own Threadpool. And Java did not really seemed to be built for Linux (Core dumps, out of memory, etc.). So I thought ok, I build my chat server with Mono. I will have built-in Thread Pools, Asynchronous IO, NPTL and epoll using Linux. And it's open source. Great! All my dreams come true! Since this is a student chat I went to my university today to ask if they would host it. They agreed (great!), but they are using AIX (64bit but should compile 32bit as well) and not Linux (and cannot give me a root accout as well). So my question is: Is it generally a good idea to try running Mono under AIX? Can I compile Mono under AIX without trouble and what will I have then? Does this mean no JIT, i.e. how well does the non-JIT version run? Should I better get my own dedicated Linux server (or VServer) somewhere else - which would cost me some money? When using a VServer, this could mean Linux Kernel 2.4. Does Mono (for a Socket-Server and ASP.Net, no GTK, but using Bitmap class) work well under 2.4 (no NPTL and epoll?). Thank you Any answer would be greatly appreciated Bernhard Herzog ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C++ to C# to C++ interop, how can I do this in a mono-compliant way?
Hello,
Is there any way to have this work under Mono? Please realize that
the basic need is to have 1 instance of a C++ exe call into a .NET
dll, and have that DLL be able to then execute functions in the C++
exe that called it. So this requires a mono-equivlant of PInvoke,
plus a way to have the C++ app call the C# app.
Help on this would be appreciated, otherwise it'll be Windows only!
If you do not mind writing some bridge code, just use P/Invoke on the C#
side to call your C++ code.
Notice that all the entry points that you will access have to be:
extern C { }
So that P/Invoke can locate them.
For calling from C++ to managed land, you can use function pointers:
register a delegate as a function pointer with your C++ code and have
that be your gateway to communicate back:
file.c:
typedef void (*mono_print_hello_fn) ();
mono_print_hello_fn printer;
routine ()
{
(*printer) ();
}
set_hello_func (mono_print_hello_fn f)
{
printer = f;
}
From C# you call:
delegate void MyPrinter ();
[DllImport (...)]
extern static int set_hello_func (MyPrinter f);
Main ()
{
set_hello_func (new MyPrinter (func));
}
void MyPrinter ()
{
Console.WriteLine (Hello);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] msdn-browse
Hello, I noticed on the svn branch a nice little utility for browsing msdn without having to pratt about with the MSDN website. I've run makefile, but all I get back is this (the code fails to compile) This is a recent mcs regression, we should be fixing it tomorrow (Martin is on vacation, and he introduced the regression). Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] C++ wrapper ?
Hello, If I want to wrap a c++ class library what should I do ? For me it seems like I have to do the following: 1. Make a ANSI c interface file calling the C++ functions, interfacefile_1 2. use csharps DLLImport directive making a wrapper class i csharp, interfacefile_2 But then I have still two problems I. A lot of arguments and return values are of C++ std template types, like vector, string etc. II. I must create the object in c++ before I can start to use it. A solution to both I and II is to make a simpler interface in C++ and adding a init function whichs creates the original object when called, interfacefile_3 ? So then the call stack looks like: C++ class I want to use C++ wrapper to simplify arguments, and to add a functrion for creation of original class c wrapper to become compatible with the c# DLL import directive a c# wrapper using DLL import I know it is possible to skip c wrapper file and using the callnames of c++, but since this is not compiler independent I prefer not to do it this way. So my question is: Is there no easier way to interface to c++ code ? Had it only been one class I think I could have used swig, but I donæt see how I can use swig when I have many C++ classes. Best regards IB ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Hello, Paul F. Johnson wrote: We had some good movement on this, but the idea seems to have gone dead. As for me, the idea hasn't gone dead, i'm waiting for comments from key developers. However, bringing this on the mono mailing lists again is a good idea :-). Are we going to have a Gnome style bug splatting day on the 3rd or 10th Sept? Not on the 3rd, probably not on the 10th neither if nobody among key developers speaks up. Maybe we should setup the first bug day without wating from comments and see if everything goes well. The only problem is that many of us won't have the needed credentials to modify bugs status, so we'd have to e-mail the developers and tell them we think that this bug should be marked as this, we were able to reproduce it on the following platform, under these conditions, etc.. It could be tedious, but it can't hurt the Mono project to have more people at a time looking at the bugzilla. Also, this first try would help us organize better for the first official bug day. What do you think about this ? -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] .NET Remoting: Upload of a file from a Win32 MS .NET client to a Linux Mono .NET server.
Hi there.
This is the first time I send a mail to this list.
I am currently trying to set up a .NET Remoting application.
For the communication I use HTTP with binary formating
as a communication channel.
I have got the application work with MS .NET Win32 on both
the client and server side.
After some struggle (with configuration files and custom channel)
I am now able to do remote invocations from my Win32 MS .NET client
to my Linux (Fedora3) Mono .NET host (console) application.
All works well having primitive datatypes and DataSets as parameters
and returns in the methods.
The problems (now) arise when i try to upload a zip file from
the client to the server.
I use a parameter with a (File)Stream object to do callbacks
to Read the file in blocks from the client into the server.
When calling the Read(buffer, 0, buffer.Length) method
I get index out of range exception messages on my the Mono server.
Here is the code snippet for a simplified test example :
public class RemoteObject : MarshalByRefObject
{
...
// AFAIK not more than 350 Kb can be serialized in .NET.
//private const int PORTION_SIZE = (256 * 1024);
//private const int PORTION_SIZE = 1024;
private const int PORTION_SIZE = 64;
...
/// summary
/// Method FileUpload to test the remoting.
/// /summary
public bool FileUpload(Stream fileIn, long fileInLength)
{
bool returnValue = false;
// Download large files in shunks.
long bytesDownloadedIn = 0L;
FileStream fileOut = new FileStream(FileOut.txt,
FileMode.OpenOrCreate, FileAccess.Write);
long bytesDownloadedOut = 0L;
try
{
for (bytesDownloadedIn = 0L; bytesDownloadedIn
fileInLength; )
{
// request the next portion
int sizeToRead = (int)Math.Min(PORTION_SIZE,
fileInLength -
bytesDownloadedIn);
byte[] buffer = new byte[sizeToRead];
fileIn.Read(buffer, 0, buffer.Length); //err
// update counters
bytesDownloadedIn += buffer.Length;
// save it into the file
fileOut.Write(buffer, 0, buffer.Length);
fileOut.Flush();
bytesDownloadedOut = bytesDownloadedIn;
}
returnValue = true;
}
catch (RemotingException remex)
{
Console.WriteLine(FileUpload - RemotingException: +
remex.Message);
returnValue = false;
}
catch (IOException ioex)
{
Console.WriteLine(FileUpload - IOException: + ioex.Message);
returnValue = false;
}
catch (Exception ex)
{
Console.WriteLine(FileUpload - Exception: + ex.Message);
returnValue = false;
}
finally
{
fileOut.Close();
}
return returnValue;
}
...
}
The error occur at err above.
The error message I get on the Mono server is:
EXCEPTION handling: IndexOutOfRangeException
EXCEPTION handling: IndexOutOfRangeException
FileUpload - Exception: Array index is out of range.
I have elaborated using FileStream and Stream,
using different PORTION_SIZE and doing the
buffer 1 byte longer than the sizeToRead.
The fileInLength is set at the client (to fileIn.Length)
to avoid an extra roundtrip.
Can anyone advice me how I should do to upload
a file from Win32 MS .NET to Linux Mono .NET.
The issue is critical to get my application to work on Mono.
Is there some other stream class I can use to transfer
a file from the client to the server.
As an aside I also want to report back the progress
of the file upload to the client.
I want to update a progressbar on my Win32 client.
I have succeded to do that on my pure Win32 application,
though some progressbar handling technique.
Am I expected to get any trouble using the ProgressBar
indirectly as a method parameter?.
Regards
Yngve Zackrisson
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Paul F. Johnson wrote: However, bringing this on the mono mailing lists again is a good idea :-). It was my son that reminded me - he thinks the idea of bugs in software is funny (he is 7 and to him, bugs are what you squish with a shoe!) :-). Are we going to have a Gnome style bug splatting day on the 3rd or 10th Sept? Not on the 3rd, probably not on the 10th neither if nobody among key developers speaks up. I think we should poke them with a stick. Not a nasty stick, possibly one with a feather on the end ;-) Does any developer read this thread ? If so, could you please tell us how relevant our idea is ? Maybe we should setup the first bug day without wating from comments and see if everything goes well. A dry run? Sounds like it could be interesting. A dry run, indeed. The only problem is that many of us won't have the needed credentials to modify bugs status, so we'd have to e-mail the developers and tell them we think that this bug should be marked as this, we were able to reproduce it on the following platform, under these conditions, etc.. Which is the idea of the triage (from my understanding). Bugs roll in, tested and if it fails due to not a programming fault, then it gets passed to the code doctors who know it's a genuine problem and not just someone messed up. I totally agree on that. As to having the credentials, you're right. In the past I've been part of a porting effort to get gcc onto RISC OS and parts of that were mind blowing! From what I've seen, mono is almost as bad, but does have the advantage of C# being quite an easy language which is simple enough to follow. By credentials, i meant that any non developer can't modify a bugs status, IIRC. This is annoying if we want to triage bugs, since we have to ask someone who has the right to modify bug status to do so. What I would suggest is this. If we can get one of the key developers (Jordi, Ben, Peter, Miguel or anyone else for that matter) and a couple of those who understand the compilers innards (patch submitters) and do a couple of dry run scenarios (say we take a random selection of bug reports), we try and get the faults to occur and then pass them over. and we tell them how we would modify the bug properties (branch concerned, milestone, component, priority, severity, etc.) These faults don't have to be real ones either. Can you tell us more about this ? I don't understand how we could use fake bugs. This will serve to do a couple of things. Firstly, it will help with time difference problems and any communication difficulties. It'll also demonstrate the work required plus give us (the non Novell people) a work out! Again, I totally agree with you. All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Hi, These faults don't have to be real ones either. Can you tell us more about this ? I don't understand how we could use fake bugs. Better known as googlies (from the cricket term). Basically, one of the developers reports a fault (under an assumed name of course) which on the surface looks completely correct, but has a very small fault in. If we detect the fault correctly, then those looking at the bugs know not only how much folks know, but also their attention to detail. It helps build confidence in the triage team. TTFN Paul -- Logic, my dear Zoe, is merely the ability to be wrong with authority - Dr Who ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Paul F. Johnson wrote: These faults don't have to be real ones either. Can you tell us more about this ? I don't understand how we could use fake bugs. Basically, one of the developers reports a fault (under an assumed name of course) which on the surface looks completely correct, but has a very small fault in. It sounds like a good idea to me. -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C++ to C# to C++ interop, how can I do this in a mono-compliant way?
J wrote: I am looking for a way of having a C++ exe integrate with a .NET dll. I have a solution working under Windows (Microsoft.NET 1.1) however I would like to make this function under Mono. Here are the details: I currently am writing a C# wrapper of a C++ game engine. (T2D by garagegames) I wrote this on Windows (CLR v1.1) and the main way this works is by adding Managed code to the C++ engine (so now it is mixed Managed/Unmanaged C++) so it can directly call into my C# DLL, and using PInvoke to have the C# DLL talk balk to the C++ engine. The C++ engine itself is OS agnostic (it works on windows, linux and mac), and I would love to make this C# wrapper work under mono, so that it is OS agnostic as well. However, http://www.go-mono.com/faq.html#63 informs me that Mixed mode assemblies do not work under mono. Is there any way to have this work under Mono? Please realize that the basic need is to have 1 instance of a C++ exe call into a .NET dll, and have that DLL be able to then execute functions in the C++ exe that called it. So this requires a mono-equivlant of PInvoke, plus a way to have the C++ app call the C# app. Help on this would be appreciated, otherwise it'll be Windows only! You have 2 options to make this work under Mono: 1. Embed the Mono runtime in you C++ app. Have a look at samples/embed of the Mono source package. From C++ you can access the managed code using Mono's metadata API. C# can access unmaged code using internal calls you have to provide. pros - pretty straightforward (IMHO) but still a lot of work. cons - only for Mono. It won't work unter MSFT's runtime. 2. Build a C wrapper for the C++ library making it p/invoke compatible. pros - the wrapper can be made platform independend cons - a lot of work I'd go for (2) because it is portable. (1) has more optimizing potential because you can mix C++ and C# at some level. Rob ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Marshal Variable length structure Array in Mono
Title: Marshal Variable length structure Array in Mono
Hi ,
I want to marshal following C structure .
[C]
struct Foo
{
int First;
int Second;
};
struct FooList
{
int Count;
Foo List[1];
};
void GetFooList(struct * FooList fList);
I am doing it following way
[C#]
[StructLayout(LayoutKind.Sequential)]
class Foo
{
public Int32 First;
public Int32 Second;
}
[StructLayout(LayoutKind.Sequential)]
class FooList
{
public Int32 Count;
private IntPtr list;//pointer to first
public Foo[] Foos
{
// HOW TO DO THIS
}
}
My problem is how to form objects from IntPtr and return as Foo[].
(If i directly use Marshal.PtrToStruct(list,typeof(Foo)); it throws object reference not set to object while access Foo.First.)
I googled about it and I found a solution which uses kernel32.dll and uses GlobalFree, GlobalAlloc API's.
I want to run this on Mono. I am new to Interop Please help.
Thank in Advance.
-YoGi
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .NET Remoting: Upload of a file from a Win32 MS .NET client to a Linux Mono .NET server.
Yngve,
The problems (now) arise when i try to upload a zip file from
the client to the server.
I use a parameter with a (File)Stream object to do callbacks
to Read the file in blocks from the client into the server.
When calling the Read(buffer, 0, buffer.Length) method
I get index out of range exception messages on my the Mono server.
Here is the code snippet for a simplified test example :
public class RemoteObject : MarshalByRefObject
{
...
// AFAIK not more than 350 Kb can be serialized in .NET.
//private const int PORTION_SIZE = (256 * 1024);
//private const int PORTION_SIZE = 1024;
private const int PORTION_SIZE = 64;
...
/// summary
/// Method FileUpload to test the remoting.
/// /summary
public bool FileUpload(Stream fileIn, long fileInLength)
{
bool returnValue = false;
// Download large files in shunks.
long bytesDownloadedIn = 0L;
FileStream fileOut = new FileStream(FileOut.txt,
FileMode.OpenOrCreate, FileAccess.Write);
long bytesDownloadedOut = 0L;
try
{
for (bytesDownloadedIn = 0L; bytesDownloadedIn
fileInLength; )
{
// request the next portion
int sizeToRead = (int)Math.Min(PORTION_SIZE,
fileInLength -
bytesDownloadedIn);
since bytesDownloadedId is 0 in the first loop,
sizeToRead will be 0 as well.
byte[] buffer = new byte[sizeToRead];
fileIn.Read(buffer, 0, buffer.Length); //err
// update counters
Well, you're reading 0 bytes. The current Mono runtime
doesn't throw an exception any more.
Which Mono version are you using?
Can anyone advice me how I should do to upload
a file from Win32 MS .NET to Linux Mono .NET.
The issue is critical to get my application to work on Mono.
Is there some other stream class I can use to transfer
a file from the client to the server.
Using a Stream as an argument for a remoting method
is pretty bad, since Stream is quite chatty. You'll end up
having a lot of traffic between client and server.
Additionaly, because Streams are MarshalByRef objects,
the server will callback into the client giving you
a lot of trouble with firewalls.
You may try this chunky approach (untested):
Hashtable handles = new HashTable ();
Random rng = new Random ();
public int Open ()
{
int handle;
do {
handle = rng.Next ();
} while (handles.Contains (handle);
handles [handle] = File.OpenWrite ();
return handle;
}
public void Write (int handle, byte[] data, int offset, int count)
{
Stream stm = handles [handle] as Stream;
if (stm == null) throw new IOException (no such handle);
stm.Write (data, offset, count)
}
public void Close (int handle)
{
Stream stm = handles [handle] as Stream;
if (stm == null) throw new IOException (no such handle);
stm.Close ();
handles.Remove (stm);
}
As an aside I also want to report back the progress
of the file upload to the client.
I want to update a progressbar on my Win32 client.
I have succeded to do that on my pure Win32 application,
though some progressbar handling technique.
Am I expected to get any trouble using the ProgressBar
indirectly as a method parameter?.
Don't do that. Use the chunky approach above so you can
update the progress bar on the client. Even w/out the
chunky stuff, you should always use threads on the client
for time consuming operations. With some care (use the Invoke
method) you can update the ProgressBar from the upload thread.
Rob
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] header have been already sent ?
I'm back from my holydays... and i've updated mono from svn... It seems that there are many changes in ASP.NET Many web application that worked before doesn't work now... The first error I experience is an xsp error : [EMAIL PROTECTED] /home/monoapp/FicheClient $ xsp xsp Listening on port: 8080 Listening on address: 0.0.0.0 Root directory: /home/monoapp/FicheClient Hit Return to stop the server. Internal error: we are missing one catch System.Web.HttpException: header have been already sent in 0x00109 System.Web.HttpResponse:Redirect (System.String url, Boolean endResponse) in 0xf System.Web.HttpResponse:Redirect (System.String url) in 0x00180 System.Web.Security.FormsAuthenticationModule:OnEndRequest (System.Object sender, System.EventArgs args) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs) in 0x00032 System.Web.HttpApplication:PipelineDone () does anyone know something about this? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] default_opt and aot
When running exception.exe after the test_0_ulong_cast (both tests did fail with 1 and 4 as the values instead of 0). Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: Zoltan Varga [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 8:54 AM To: Gary M. Smithrud Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] default_opt and aot Hi, default_opt is initialized in mini_init () before aot_init is called, so this should not happen. Which test is core dumping for you ? Zoltan On 8/31/05, Gary Smithrud [EMAIL PROTECTED] wrote: I'm trying to get the 8/29 source tarball built on Solaris and it is core dumping when performing make check. The issue is that mono_aot_get_method is being called and aot_mutex is 0 (the coredump is occurring in LeaveCriticalSection.) It looks like that the default_opt of 0 is causing the aot_init to not be called and thus the aot_mutex is not initialized. Is there a way to set the default_opt from outside (I don't have time to track down how to do this)? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security
Harry,
The latest patch that I sent to the
maintainers doesnt use the delegate BeginInvoke any more. It uses an
asynchronous BeginRead or BeginWrite call to the innerStream to kick off the
handshake in a background thread.
-JD Conley
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harry Holt
Sent: Wednesday, August 31, 2005
6:12 AM
To:
mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Re:
[PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security
This seems to work fine
on W2k. Running under IIS5.1 on WXP, though, it always throws an
ObjectDisposedException in SSLStreamBase.cs when a bind
over SSL is attempted.
Won't this:
if (workthreads =
(maxworkthreads - 4))
{
async = false;
}
cause the SSL Stream to use synchronous handshake until threads start getting
used?
I would also recommend changing this:
protected void checkDisposed()
{
if (this.disposed)
{
throw new ObjectDisposedException(The Stream is closed.);
}
}
to this:
protected void checkDisposed()
{
if (this.disposed)
{
throw new ObjectDisposedException(this.GetType().Name, The Stream is
closed.);
}
}
which produces a more readable error message.
Thx... HH
On 8/25/05, Sebastien
Pouliot [EMAIL PROTECTED]
wrote:
Hello JD,
On Wed, 2005-24-08 at 21:12 -0700, JD Conley
wrote:
I took the plunge and fully implemented async Ssl streams for both
client and server.This fixes
http://bugzilla.ximian.com/show_bug.cgi?id=75687
as well as other bugs
I've been talking with Sebastien and Carlos about off list. This patch
passes the SocketHell tests that I contributed to them last week
(multi threaded concurrent async streaming through TCP sockets).
Wow! That's the kind of surprise I like when I wake up :-)
It's also a bit of a re-factor, though I only touched two classes and
added one.I pulled most of the code out of the individual
SslClientStream and SslServerStream and moved it down into a new
abstract SslStreamBase.Client and server are now practically
the
same implementation.I left all existing interfaces present,
but
obviously had to add some new ones.
We always sticked to the Fx 1.2 preview specs for the Ssl[Client|
Server]Stream API and didn't planned to change this before implementing
the new SslStream (in System.dll) for 2.0 - BUT this isn't a major
problem if it doesn't break binary compatibility (for current
applications linked with Mono.Security.dll).
The only gotcha is if you start running low on threadpool
threads.
Then the Ssl Stream will fall back to a synchronous handshake. The
other option here is to spawn a thread ourselves for the handshake
instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is
that available to Mono.Security?), or just live with a synchronous
handshake. Of course, 99.999% of the time this issue won't occur and
won't be a problem unless you have both client and server sharing the
same Threadpool causing a deadlock.
That's not worse than the original (where the handshake was always
synchronous).
I hope this helps and gets integrated.It's definitely
necessary for
our implementation.
1. I'll review the patch and, in doing so, check for possible binary
compatibility problems. I'm sure Carlos will do likewise;
2. I'll make public a new Mono.Security.dll assembly so that people that
depends on Ssl*Stream may tests it and report any problem/difference;
3. I'll run the regressions tests, the tools under /mcs/class/
Mono.Security/Test/tools/*, to see if it works in previously reported
conditions.
4. Commit (both the patch and your SocketHell tests). Hopefully we can
do all this before the next release.
Many thanks!
--
Sebastien
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Robbie the Nanobot says:
Only YOU can prevent gray goo
(NEVER release nanobot assemblers without replication limiting code)
http://lizardslounge.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Custom surrogates and serialization
Hi!
I've recently started a project trying to get some fairly complex
software that was written for .Net 1.1 working on Mono, and so far I've
found almost everything works quite well with minimal changes needed.
I have run into a few issues, and I’m hoping that someone can take a
look at them. I was able to boil down a few into small test cases, and
I've filed some bugs with my test cases attached (#75947 and #75950).
Please let me know if I need to provide more information for these issues.
I'm now working on some problems with Xml serialization, and this is
where the bulk of the problems I'm getting have been. The first is that
our software uses a custom serializer surrogate for
System.Net.IPAddress, in order to handle differences between .Net 1.0
and 1.1. On Mono, our custom serializer doesn't work; it gets the error
The attempted operation is not supported for the type of object
referenced instead. My surrogate code is:
public object SetObjectData(
System.Object obj,
System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context,
System.Runtime.Serialization.ISurrogateSelector selector)
{
System.String ipStr = info.GetString( address );
System.Net.IPAddress newIP
= System.Net.IPAddress.Parse( ipStr );
System.Net.IPAddress ipAddress = (System.Net.IPAddress)obj;
// This line throws the exception
ipAddress.Address = newIP.Address;
return obj;
}
The problem seems to be that when the deserializer creates the new
IPAddress object the AddressFamily field ends up uninitialized, and the
Address property set fails.
Unfortunately the deserializer also mimics the .Net 1.0 behaviour where
the return value of SetObjectData is ignored, so I can't just create a
new IPAddress and return it instead (in .Net 1.1, this bug is supposedly
fixed).
I've got a few more issues I've found in the SOAP serializer using
surrogates, but I'm still working on tracking them down.
Thanks for any information anyone can provide!
Chris Micacchi
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch for Mono.Cairo to rename SurfaceImage and Patterns
Hello,
Here is a patch to rename SurfaceImage to ImageSurface and
implement the type-hierarchy for Patterns in the cairo docs.
After this I think I will only have 1 more patch with an api change
to make the Surfaces a hierarchy of types also. Thanks to Hisham for
taking care of everything so far.
Index: Mono.Cairo/Cairo.cs
===
--- Mono.Cairo/Cairo.cs (revision 49350)
+++ Mono.Cairo/Cairo.cs (working copy)
@@ -626,31 +626,31 @@
[StructLayout(LayoutKind.Sequential)]
public struct FontExtents
{
-public double ascent;
-public double descent;
-public double height;
-public double max_x_advance;
-public double max_y_advance;
+public double Ascent;
+public double Descent;
+public double Height;
+public double MaxXAdvance;
+public double MaxYAdvance;
}
[StructLayout(LayoutKind.Sequential)]
public struct TextExtents
{
-public double x_bearing;
-public double y_bearing;
-public double width;
-public double height;
-public double x_advance;
-public double y_advance;
+public double XBearing;
+public double YBearing;
+public double Width;
+public double Height;
+public double XAdvance;
+public double YAdvance;
}
[StructLayout(LayoutKind.Sequential)]
public struct Glyph
{
-public long index;
-public double x;
-public double y;
+public long Index;
+public double X;
+public double Y;
}
public delegate void ClosePathCallback (object closure);
Index: Mono.Cairo/Pattern.cs
===
--- Mono.Cairo/Pattern.cs (revision 49350)
+++ Mono.Cairo/Pattern.cs (working copy)
@@ -33,18 +33,18 @@
namespace Cairo {
-public class PatternLinear : Pattern
+public class LinearGradient : Gradient
{
- public PatternLinear (double x0, double y0, double x1, double y1) : base()
+ public LinearGradient (double x0, double y0, double x1, double y1) : base()
{
pattern = CairoAPI.cairo_pattern_create_linear (x0, y0, x1, y1);
Reference ();
}
}
-public class PatternRadial : Pattern
-{
- public PatternRadial (double cx0, double cy0, double radius0,
+public class RadialGradient : Gradient
+ {
+ public RadialGradient (double cx0, double cy0, double radius0,
double cx1, double cy1, double radius1) : base()
{
pattern = CairoAPI.cairo_pattern_create_radial (cx0, cy0, radius0,
@@ -53,14 +53,52 @@
}
}
-public class PatternRgba : Pattern
-{
- public PatternRgba (double r, double g, double b, double a) : base ()
+ public class Gradient : Pattern
{
- pattern = CairoAPI.cairo_pattern_create_rgba (r, g, b, a);
- Reference();
+public Status AddColorStop (double offset, Cairo.Color c)
+{
+return CairoAPI.cairo_pattern_add_color_stop_rgba (pattern, offset,
+ c.R, c.G, c.B, c.A);
+}
+
+public Status AddColorStopRgb (double offset, Cairo.Color c)
+{
+return CairoAPI.cairo_pattern_add_color_stop_rgb (pattern, offset,
+ c.R, c.G, c.B);
+}
}
- }
+
+ // FIXME: probably will change to a better name at some point
+ public class SolidPattern : Pattern
+ {
+ public SolidPattern (Color color, bool solid)
+ {
+if (solid)
+ pattern = CairoAPI.cairo_pattern_create_rgb (color.R, color.G, color.B);
+else
+ pattern = CairoAPI.cairo_pattern_create_rgba (color.R, color.G, color.B, color.A);
+Reference ();
+ }
+ }
+
+ public class SurfacePattern : Pattern
+ {
+ public SurfacePattern (Surface surface)
+ {
+pattern = CairoAPI.cairo_pattern_create_for_surface (surface.Pointer);
+Reference ();
+ }
+
+ public Extend Extend {
+set { CairoAPI.cairo_pattern_set_extend (pattern, value); }
+get { return CairoAPI.cairo_pattern_get_extend (pattern); }
+ }
+
+ public Filter Filter {
+set { CairoAPI.cairo_pattern_set_filter (pattern, value); }
+get { return CairoAPI.cairo_pattern_get_filter (pattern); }
+ }
+ }
public class Pattern
{
@@ -89,19 +127,7 @@
{
CairoAPI.cairo_pattern_destroy (pattern);
Re: [Mono-dev] ** ERROR **: file exceptions-ia64.c:
Hi, This has just been fixed in SVN. Zoltan On 9/1/05, Kevin [EMAIL PROTECTED] wrote: Jonathan, thanks for the tip on monolite. I should have read more of the README myself. I am now facing an assertion problem and was wondering whether anyone came across the following? ** ERROR **: file exceptions-ia64.c: line 581 (mono_arch_handle_exception): assertion failed: (res = 0) aborting... make[7]: *** [../class/lib/net_1_1_bootstrap/mcs.exe] Aborted make[7]: Leaving directory `/home/veragoo/mono/mcs/mcs' make[6]: *** [do-all] Error 2 make[6]: Leaving directory `/home/veragoo/mono/mcs/mcs' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/veragoo/mono/mcs' make[4]: *** [profile-do--net_1_1_bootstrap--all] Error 2 make[4]: Leaving directory `/home/veragoo/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/home/veragoo/mono/mcs' make[2]: *** [all-local] Error 1 make[2]: Leaving directory `/home/veragoo/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/veragoo/mono/mono' make: *** [all] Error 2 --- Thanks Kevin On 8/26/05, Jonathan S. Chambers [EMAIL PROTECTED] wrote: Did you get monolite; i.e. 'make get-monolite-latest'? - Jonathan -Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Sent: Thu 8/25/2005 8:57 PM To: mono-devel-list@lists.ximian.com Cc: Subject:[Mono-dev] mono on IA64 - help compiling Hello all, I have tried to compile mono on one of the Itanium2 machines at work, but at some point it asks for an existing mcs compiler. I am not sure how to solve this, as i am guessing that installing the binaries won't work there, or will they? Could anyone please advise. PS: I have pasted the error below. Thanks in advance Kevin -- START ERROR--- make[3]: Entering directory `/home/veragoo/mono/mcs' make profile-do--default--all profile-do--net_2_0--all make[4]: Entering directory `/home/veragoo/mono/mcs' make PROFILE=basic all make[5]: Entering directory `/home/veragoo/mono/mcs' *** The compiler 'mcs' doesn't appear to be usable. *** You need a C# compiler installed to build MCS (make sure mcs works from the command line) *** Read INSTALL.txt for information on how to bootstrap a Mono installation. make[5]: *** [do-profile-check] Error 1 make[5]: Leaving directory `/home/veragoo/mono/mcs' make[4]: *** [profile-do--basic--all] Error 2 make[4]: Leaving directory `/home/veragoo/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/home/veragoo/mono/mcs' make[2]: *** [all-local] Error 1 make[2]: Leaving directory `/home/veragoo/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/veragoo/mono/mono' make: *** [all] Error 2 END ERROR-- -- Cheers, Kevin ( http://www. ) Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Cheers, Kevin ( http://www. ) Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved. -- Cheers, Kevin ( http://www. ) Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] expected corlib 37, found 38
Thank you! I also found this documented in one of the INSTALL-files now. I should better read the documentation first next time. Mixing version from SVN and releases was not a good idea, now that I have compiled everything myself it is working. I even had to recompile my own application. I am having some new problems in my web-application now - but I suppose this is because of all that changes in the web controls / web application domain. Bernhard - Original Message - From: Zoltan Varga [EMAIL PROTECTED] To: Bernhard Herzog [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Friday, September 02, 2005 2:44 PM Subject: Re: [Mono-dev] expected corlib 37, found 38 Hi, This means the runtime you have installed on your system is older than the mscorlib.dll. You can usually fix that by typeing 'make install' in the mono/mono directory. Zoltan On 8/31/05, Bernhard Herzog [EMAIL PROTECTED] wrote: Hello! Sorry for this newbie question and if it has been asked before: I wanted to try the new System.Web.dll so I did an svn update and tried to compile. I don't remember everything I did, but suddenly I got something like: Corlib not in sync with this runtime: expected corlib version 37, found 40. Download a newer corlib or a newer runtime at http://www.go-mono.com/daily. I went to go-mono.com/daily and downloaded monocharge. But this archive did not contain a gacutil.exe, so I used the one I had and still got the error. I did some experiments copying dlls and stuff and finally downloaded mono-1.1.8.20050830 and compiled it (configure, make, make install). Now when running gacutil I get: Corlib not in sync with this runtime: expected corlib version 37, found 38. Download a newer corlib or a newer runtime at http://www.go-mono.com/daily. Am I doing something wrong here? Thank you Bernhard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Zac Bowling has invited you to open a Google mail account
--- Zac Bowling has invited you to open a free Gmail account. To accept this invitation and register for your account, visit http://mail.google.com/mail/a-fdc691e1c6-e9b66c8a2c-9e24b69030 Once you create your account, Zac Bowling will be notified with your new email address so you can stay in touch with Gmail! If you haven't already heard about Gmail, it's a new search-based webmail service that offers: - Over 2,500 megabytes (two gigabytes) of free storage - Built-in Google search that instantly finds any message you want - Automatic arrangement of messages and related replies into conversations - Text ads and related pages that are relevant to the content of your messages Gmail is still in an early stage of development. But if you set up an account, you'll be able to keep it even after we make Gmail more widely available. We might also ask for your comments and suggestions periodically and we appreciate your help in making Gmail even better. Thanks, The Gmail Team To learn more about Gmail before registering, visit: http://mail.google.com/mail/help/benefits.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch to add more surfaces to Mono.Cairo
Hello,
Here is a patch to add an XlibSurface and Win32Surface to Mono.Cairo.
I updated the samples and they still work and added one
for win32 (only tested with .net).
Index: Mono.Cairo/Cairo.cs
===
--- Mono.Cairo/Cairo.cs (revision 49350)
+++ Mono.Cairo/Cairo.cs (working copy)
@@ -356,6 +356,9 @@
[DllImport (CairoImp)]
public static extern IntPtr cairo_xlib_surface_create (IntPtr dpi,
IntPtr win, IntPtr visual, int w, int h);
+
+ [DllImport (CairoImp)]
+public static extern void cairo_xlib_surface_set_drawable (IntPtr surface, IntPtr drawable, int width, int height);
[DllImport (CairoImp)]
public static extern void cairo_xlib_surface_set_size (IntPtr surface, int width, int height);
@@ -394,6 +397,21 @@
[DllImport (CairoImp)]
public static extern void cairo_surface_write_to_png (IntPtr surface, string filename);
+[DllImport (CairoImp)]
+public static extern IntPtr cairo_pdf_surface_create (string filename, double width, double height);
+
+[DllImport (CairoImp)]
+public static extern void cairo_pdf_surface_set_dpi (IntPtr surface, double x_dpi, double y_dpi);
+
+[DllImport (CairoImp)]
+public static extern IntPtr cairo_ps_surface_create (string filename, double width, double height);
+
+[DllImport (CairoImp)]
+public static extern void cairo_ps_surface_set_dpi (IntPtr surface, double x_dpi, double y_dpi);
+
+[DllImport (CairoImp)]
+public static extern IntPtr cairo_win32_surface_create (IntPtr hdc);
+
//
// Matrix
//
Index: Mono.Cairo/Graphics.cs
===
--- Mono.Cairo/Graphics.cs (revision 49350)
+++ Mono.Cairo/Graphics.cs (working copy)
@@ -618,6 +618,11 @@
public double FontSize {
set { CairoAPI.cairo_set_font_size (state, value); }
}
+
+ public void ShowPage ()
+ {
+ CairoAPI.cairo_show_page (state);
+ }
public void ShowText (string str)
{
Index: Mono.Cairo/Surface.cs
===
--- Mono.Cairo/Surface.cs (revision 49350)
+++ Mono.Cairo/Surface.cs (working copy)
@@ -59,6 +59,77 @@
}
}
+
+ #if UNSTABLE
+ public class PdfSurface : Surface
+ {
+ public PdfSurface (string filename, double width, double height)
+ {
+ surface = CairoAPI.cairo_pdf_surface_create (filename, width, height);
+
+ CairoAPI.cairo_surface_reference (surface);
+ }
+
+ public void SetDPI (double x_dpi, double y_dpi)
+ {
+ CairoAPI.cairo_pdf_surface_set_dpi (surface, x_dpi, y_dpi);
+ }
+ }
+
+ public class PostscriptSurface : Surface
+ {
+ public PostscriptSurface (string filename, double width, double height)
+ {
+ surface = CairoAPI.cairo_ps_surface_create (filename, width, height);
+
+ CairoAPI.cairo_surface_reference (surface);
+ }
+
+ public void SetDPI (double x_dpi, double y_dpi)
+ {
+ CairoAPI.cairo_ps_surface_set_dpi (surface, x_dpi, y_dpi);
+ }
+ }
+ #endif
+
+ public class Win32Surface : Surface
+ {
+ public Win32Surface (IntPtr hdc)
+ {
+ surface = CairoAPI.cairo_win32_surface_create (hdc);
+
+ CairoAPI.cairo_surface_reference (surface);
+ }
+ }
+
+ public class XlibSurface : Surface
+ {
+ public XlibSurface (IntPtr display, IntPtr drawable, IntPtr visual, int width, int height)
+ {
+ surface = CairoAPI.cairo_xlib_surface_create (display, drawable, visual, width, height);
+
+ CairoAPI.cairo_surface_reference (surface);
+ }
+
+ /* FIXME: has the same parameters as above
+ public XlibSurface (IntPtr display, IntPtr bitmap, IntPtr screen, int width, int height)
+ {
+ surface = CairoAPI.cairo_xlib_surface_create_for_bitmap (display, bitmap, screen, width, height);
+
+ CairoAPI.cairo_surface_reference (surface);
+ }
+ */
+
+ public void SetDrawable (IntPtr drawable, int width, int height)
+ {
+ CairoAPI.cairo_xlib_surface_set_drawable (surface, drawable, width, height);
+ }
+
+ public void SetSize (int width, int height)
+ {
+ CairoAPI.cairo_xlib_surface_set_size (surface, width, height);
+ }
+ }
public class Surface : IDisposable
{
@@ -89,16 +160,6 @@
}
}
- public static Cairo.Surface CreateForXlib (IntPtr display, IntPtr win,
- IntPtr visual, int w,
- int h)
- {
- IntPtr p = CairoAPI.cairo_xlib_surface_create (display, win,
- visual, w, h);
- if(p == IntPtr.Zero) System.Console.WriteLine(Failed creating surface);
- return new Cairo.Surface (p, false);
- }
-
public static Cairo.Surface CreateForImage (
Re: [Mono-dev] [PATCH][GMCS] add MakeGenericMethod to MethodInfo
I attach the more complete and correct patch - MakeGenericMethod is added to MethodBase instead of MethodInfo, I made necessary changes to gmcs and mbas, also the change to GenericParameterAttributes is included. One question I would like to ask is if I should also change the runtime icalls from BindTypeParameters to MakeGenericType / MakeGenericMethod, or should this be left for another patch. If this patch is ok in its state, I will commit. 2005/8/30, Michal Moskal [EMAIL PROTECTED]: Hello, The MS Aug CTP release removes BindGenericParameters/Arguments methods from System.Type and MethodInfo. Instead MakeGenericType and MakeGenericMethod should be used. Mono has the first one implemneted. The attached patch implemnets the second one. 2005-08-30 Michal Moskal [EMAIL PROTECTED] * MethodInfo.cs: Add MakeGenericMethod to match Aug CTP API. -- Michal Moskal, http://nemerle.org/~malekith/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH][GMCS] add MakeGenericMethod to MethodInfo
And the file goes here...
2005/9/2, Kamil Skalski [EMAIL PROTECTED]:
I attach the more complete and correct patch - MakeGenericMethod is
added to MethodBase instead of MethodInfo, I made necessary changes to
gmcs and mbas, also the change to GenericParameterAttributes is
included.
One question I would like to ask is if I should also change the
runtime icalls from BindTypeParameters to MakeGenericType /
MakeGenericMethod, or should this be left for another patch. If this
patch is ok in its state, I will commit.
2005/8/30, Michal Moskal [EMAIL PROTECTED]:
Hello,
The MS Aug CTP release removes BindGenericParameters/Arguments methods
from System.Type and MethodInfo. Instead MakeGenericType and
MakeGenericMethod should be used. Mono has the first one implemneted.
The attached patch implemnets the second one.
2005-08-30 Michal Moskal [EMAIL PROTECTED]
* MethodInfo.cs: Add MakeGenericMethod to match Aug CTP API.
--
Michal Moskal,
http://nemerle.org/~malekith/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Kamil Skalski
http://nazgul.omega.pl
--
Kamil Skalski
http://nazgul.omega.pl
Index: bmcs/generic.cs
===
--- bmcs/generic.cs (wersja 49356)
+++ bmcs/generic.cs (kopia robocza)
@@ -33,7 +33,7 @@
}
public bool HasValueTypeConstraint {
- get { return (Attributes GenericParameterAttributes.ValueTypeConstraint) != 0; }
+ get { return (Attributes GenericParameterAttributes.NotNullableValueTypeConstraint) != 0; }
}
public virtual bool HasClassConstraint {
@@ -195,7 +195,7 @@
if (sc == SpecialConstraint.ReferenceType)
attrs |= GenericParameterAttributes.ReferenceTypeConstraint;
else
- attrs |= GenericParameterAttributes.ValueTypeConstraint;
+ attrs |= GenericParameterAttributes.NotNullableValueTypeConstraint;
continue;
}
@@ -1733,7 +1733,7 @@
if (tc != null)
return tc.IsGeneric ? tc.CountTypeParameters : 0;
else
-return t.HasGenericArguments ? t.GetGenericArguments ().Length : 0;
+return t.IsGenericType ? t.GetGenericArguments ().Length : 0;
}
public static Type[] GetTypeArguments (Type t)
@@ -2171,7 +2171,7 @@
if (infered_types [i] == null)
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
@@ -2241,7 +2241,7 @@
if (!InferTypeArguments (param_types, arg_types, infered_types))
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
@@ -2269,7 +2269,7 @@
if (!InferTypeArguments (param_types, arg_types, infered_types))
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
Index: bmcs/ecore.cs
===
--- bmcs/ecore.cs (wersja 49356)
+++ bmcs/ecore.cs (kopia robocza)
@@ -2992,7 +2992,7 @@
if (gen_params.Length != atypes.Length)
continue;
-list.Add (mi.BindGenericParameters (atypes));
+list.Add (mi.MakeGenericMethod (atypes));
}
if (list.Count 0) {
Index: gmcs/generic.cs
===
--- gmcs/generic.cs (wersja 49356)
+++ gmcs/generic.cs (kopia robocza)
@@ -33,7 +33,7 @@
}
public bool HasValueTypeConstraint {
- get { return (Attributes GenericParameterAttributes.ValueTypeConstraint) != 0; }
+ get { return (Attributes GenericParameterAttributes.NotNullableValueTypeConstraint) != 0; }
}
public virtual bool HasClassConstraint {
@@ -199,7 +199,7 @@
if (sc == SpecialConstraint.ReferenceType)
attrs |= GenericParameterAttributes.ReferenceTypeConstraint;
else
- attrs |= GenericParameterAttributes.ValueTypeConstraint;
+ attrs |= GenericParameterAttributes.NotNullableValueTypeConstraint;
continue;
}
@@ -1692,7 +1692,7 @@
if (tc != null)
return tc.IsGeneric ? tc.CountTypeParameters : 0;
else
-return t.HasGenericArguments ? t.GetGenericArguments ().Length : 0;
+return t.IsGenericType ? t.GetGenericArguments ().Length : 0;
}
public static Type[] GetTypeArguments (Type t)
@@ -2128,7 +2128,7 @@
if (infered_types [i] == null)
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
@@ -2199,7 +2199,7 @@
if (!InferTypeArguments (param_types, arg_types, infered_types))
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
[Mono-dev] Pre-release notes.
Hello, As it happens with every release, I can not keep track of all the developments in the tree, and I would like to list all the major highlights in this upcoming Mono release. Please review my release notes and send me any relevant comments on things that might be missing: http://www.go-mono.com/archive/1.1.9 Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Julien Gilli wrote: Hello, Paul F. Johnson wrote: We had some good movement on this, but the idea seems to have gone dead. As for me, the idea hasn't gone dead, i'm waiting for comments from key developers. However, bringing this on the mono mailing lists again is a good idea :-). Why not just immediately tuckle existing bugs? I have been fixing mcs bugs those days. I don't know much about mcs internals, so I often ask about them on irc. What were you guys doing since the beginning of this discussion? I would like to know what is the reason you guys need something special than immediate bugfixing. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch to fix Mono.Cairo.Operator
Hello,
One more patch to make Cairo.Operator match
cairo_operator_t in cairo 1.0, I guess the other values were either
from an older cairo or when Mono.Cairo was being used to emulate another
library.
Index: Mono.Cairo/Cairo.cs
===
--- Mono.Cairo/Cairo.cs (revision 49350)
+++ Mono.Cairo/Cairo.cs (working copy)
@@ -533,46 +533,23 @@
}
public enum Operator {
-Clear = 0,
-Src = 1,
-Dst = 2,
-Over = 3,
-OverReverse = 4,
-In = 5,
-InReverse = 6,
-Out = 7,
-OutReverse = 8,
-Atop = 9,
-AtopReverse = 10,
-Xor = 11,
-Add = 12,
-Saturate = 13,
-
-DisjointClear = 16,
-DisjointSrc = 17,
-DisjointDst = 18,
-DisjointOver = 19,
-DisjointOverReverse = 20,
-DisjointIn = 21,
-DisjointInReverse = 22,
-DisjointOut = 23,
-DisjointOutReverse = 24,
-DisjointAtop = 25,
-DisjointAtopReverse = 26,
-DisjointXor = 27,
+ Clear,
-ConjointClear = 32,
-ConjointSrc = 33,
-ConjointDst = 34,
-ConjointOver = 35,
-ConjointOverReverse = 36,
-ConjointIn = 37,
-ConjointInReverse = 38,
-ConjointOut = 39,
-ConjointOutReverse = 40,
-ConjointAtop = 41,
-ConjointAtopReverse = 42,
-ConjointXor = 43
+ Source,
+ Over,
+ In,
+ Out,
+ Atop,
+
+ Dest,
+ DestOver,
+ DestIn,
+ DestOut,
+ DestAtop,
+
+ Xor,
+ Add,
+ Saturate,
}
public enum FillRule {
Index: Samples/png/circles.cs
===
--- Samples/png/circles.cs (revision 49350)
+++ Samples/png/circles.cs (working copy)
@@ -117,7 +117,8 @@
gr.Restore ();
- gr.Operator = Operator.OutReverse;
+ // FIXME: OutReverse is not in 1.0
+ //gr.Operator = Operator.OutReverse;
punch.Show (gr, width, height);
Index: Samples/gtk/circles.cs
===
--- Samples/gtk/circles.cs (revision 49350)
+++ Samples/gtk/circles.cs (working copy)
@@ -144,7 +144,8 @@
gr.Restore ();
- gr.Operator = Operator.OutReverse;
+ // FIXME: Operator.OutReverse is not in cairo 1.0
+ //gr.Operator = Operator.OutReverse;
punch.Show (gr, width, height);
Index: ChangeLog
===
--- ChangeLog (revision 49350)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2005-09-02 John Luke [EMAIL PROTECTED]
+
+ * Mono.Cairo/Cairo.cs: only use operators in cairo_operator_t
+
2005-09-01 John Luke [EMAIL PROTECTED]
* Mono.Cairo/Cairo.cs: p/invoke the windows dll name
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [Mono-list] Mono.Security.dll async SSL preview
Hello, A modified version of JD's patch is now in SVN. The changes are minor: (a) make it compile under 1.x (can't call Invoke on a delegate); (b) make the API to look more like the original (i.e. internalize ;-) My tests didn't show any difference between this version and the previous one (i.e. the original patch). Mono 1.1.9 is coming very soon now so if you depend, directly or indirectly, on the SSL/TLS classes please do test this new version - either with SVN or as a new attachment to the bug report. http://bugzilla.ximian.com/showattachment.cgi?attach_id=15686 Thanks. On Tue, 2005-30-08 at 14:08 -0400, Sebastien Pouliot wrote: Hello everyone, I completed a _successful_ test run of the latest JD's async SSL patch (attached). History has shown that testing SSL isn't as simple as I would like ;-) so I decided to let people test it for themselves before committing the (rather large) changes to SVN. If everything goes well (e.g. I don't hear from anyone), this [*] will be committed to SVN on Friday. [*] some new visible API may be hidden (internal) before being committed. However they shouldn't affect compatibility. This new Mono.Security.dll assembly can be downloaded from http://bugzilla.ximian.com/showattachment.cgi?attach_id=15663 just renamed the file to Mono.Security.dll and install it with gacutil before starting your tests. And again a big thanks to JD :-) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch for Mono.Cairo to rename SurfaceImage and Patterns
I will look into this on Sunday as I will be offline most of the day on Saturday. Thanks for your hard work! Hisham. On 9/2/05, John Luke [EMAIL PROTECTED] wrote: Hello, Here is a patch to rename SurfaceImage to ImageSurface and implement the type-hierarchy for Patterns in the cairo docs. After this I think I will only have 1 more patch with an api change to make the Surfaces a hierarchy of types also. Thanks to Hisham for taking care of everything so far. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .NET Remoting: Upload of a file from a Win32 MS .NET client to a Linux Mono .NET server.
Sorry, replied off the list, here is a copy: On 9/2/05, Yngve Zackrisson [EMAIL PROTECTED] wrote: Hi there. The problems (now) arise when i try to upload a zip file from the client to the server. I use a parameter with a (File)Stream object to do callbacks I did not check all your code, but generally this is a bad idea to pass a Stream object as remoting parameter. That way, when you invoke a remote call lets say to Read method, you are passing the buffer array as well in both directions, thus doubling the traffic. A better approach is to have a remote method like byte[] ReadChunk(int start, int end) or something like that. Now, you can control from the client how big chunks you want to receive, and the buffer is only passed from server to client. Knowing the original size of the file and the chunks/bytes you already read, you can easily maintain and update a progress indicator. This is a good article on the topic: http://www.genuinechannels.com/Content.aspx?id=23type=1 Cheers Sunny -- Svetoslav Milenov (Sunny) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Day
Hi, As for me, the idea hasn't gone dead, i'm waiting for comments from key developers. However, bringing this on the mono mailing lists again is a good idea :-). Why not just immediately tuckle existing bugs? I have been fixing mcs bugs those days. I don't know much about mcs internals, so I often ask about them on irc. The idea was to have something similar to the Gnome bug days. Given the project is nearing the beta of 1.2, it was suggested that this may be a way forward to have a concerted effort for bug diagnosis and fixing. TTFN Paul -- A lot of football success is in the mind. You must believe you are the best and then make sure that you are. In my time at Liverpool we always said we had the best two teams on Merseyside, Liverpool and Liverpool Reserves. - Bill Shankly ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on OSX 10.4 (Cocoa and Threading)
On Sep 1, 2005, at 10:52 PM, Frank Bergmann wrote: I must say I had trouble creating a test case (since it is a rather big project). I found out the following though: Under Win32 I used the Mutex class during thread spawning to ensure thread safety. Under OS X these Mutex's caused a deadlock. Even after creation the first WaitOne() would not return. Writing up a test case did not work out again, as every simple use of the Mutex class did what it was supposed to do. So for now I removed them and watch my step. I suspect there may be a bug in the mono Mutex/Monitor implementation under OS X. I have experienced similar deadlocks. The toy code I posted for bug #75558 sometimes exhibits deadlocking behaviour under 10.4.2: http://bugs.ximian.com/show_bug.cgi?id=75558 -Allan -- Allan Hsu allan at counterpop dot net 1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Windows.Forms and mbas
I'm trying to get the following example working on winxp with mono-1.0.5: imports Systemimports System.Windows.Forms Module Hello sub Main() dim f as new System.Windows.Forms.Form() dim c as new Collection()Console.WriteLine(Hello World vb.mono) end sub end module I'm compilingthe program using mbas /r:System.Windows.Forms helloworld.vb Upon execution I get the following error: Unhandled Exception: System.ArgumentException: Invalid Parameter. A null reference or invalid value was found.in 0x00073 System.Drawing.GDIPlus:CheckStatus (System.Drawing.Status)in 0x00182 System.Drawing.Font:FromHfont (intptr)in 0x00015 System.Windows.Forms.Control:get_DefaultFont ()in 0x001af System.Windows.Forms.Control:.ctor ()in 0x00010 System.Windows.Forms.ScrollableControl:.ctor ()in 0x00012 System.Windows.Forms.ContainerControl:.ctor ()in 0x00016 System.Windows.Forms.Form:.ctor ()in 0x0004c (wrapper remoting-invoke-with-check) System.Windows.Forms.Form:.cto r ()in 0x00028 Hello:Main () ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
