[Mono-dev] (no subject)
I'm trying to get example working on winxp with mono-1.0.5 which only creates a form: ... dim f as new System.Windows.Forms.Form()... I'm compiling the 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
[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 compiling the 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
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 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
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] .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=23&type=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] 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
[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
[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
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] Type.GUID patch
Here’s a patch for the Type.GUID property. It was previously always returning Guid.Empty. It now returns the value of the GuidAttribute specified on the Type, else it returns Guid.Empty. This seems to be the behavior of .Net. Please review and commit, or give me permission to commit. Thanks, Jonathan S. Chambers Software Development Engineer ANSYS, Inc. Phone: 724.514.3682 Fax: 724.514.3114 E-mail: [EMAIL PROTECTED] ___ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. MonoType.cs.diff Description: MonoType.cs.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[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] [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 (infe
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
[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 ( st
Re: [Mono-dev] Zac Bowling has invited you to open a Google mail account
I didn't think I would have to put Zac in my spam filter, but its looks like I will have to... Zac Bowling <[EMAIL PROTECTED]> wrote: ---Zac Bowling has invited you to open a free Gmail account.To accept this invitation and register for your account, visithttp://mail.google.com/mail/a-fdc691e1c6-e9b66c8a2c-9e24b69030Once 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 messagesGmail 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 TeamTo 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 theminto the address bar of your browser).___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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
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: 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
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
[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);
[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
RE: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security
Harry, The latest patch that I sent to the maintainers doesn’t 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
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
[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] .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; ... /// /// Method FileUpload to test the remoting. /// 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); // // 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
Re: [Mono-dev] C++ wrapper ?
Just a tip Using correctly the extern "C" { ...} construct in your "interfacefile_3" you may not need to write a c wrapper ("interfacefile_2"). The main restriction is that: "You can specify extern "C" for only one instance of an overloaded function; all other instances of an overloaded function have C++ linkage." You can also read; http://developers.sun.com/solaris/articles/external_linkage.html :) On 9/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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 > -- Rafael "Monoman" Teixeira --- I'm trying to become a "Rosh Gadol" before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ 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] Build problems on Solaris 9/sparc
Hi, You most likely have a binary on your system with the name 'mcs'. Remove it, or remove it from your patch, and it should work. Zoltan On 8/31/05, Jason Downs <[EMAIL PROTECTED]> wrote: > Hi, > > I've been trying to get mono 1.1.8.3 built on Solaris 9/sparc. It's not > going very well. The first problem encountered is when the build process > attempts to use mcs for the first time. mcs is there, and is a working > .exe, but it appears to be *invoking* it wrong (note the usage line): > > [...] > make[3]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' > make profile-do--default--all profile-do--net_2_0--all > make[4]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' > make PROFILE=basic all > make[5]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' > make[6]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' > usage: mcs [-cdpVz] [-a string] [-n name] file ... > make[6]: *** [build/deps/basic-profile-check.exe] Error 1 > make[6]: Leaving directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' > *** The compiler 'mcs' doesn't appear to be usable. > *** Falling back to using pre-compiled binaries. Be warned, this may not > work. > make[6]: Entering directory > `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/jay' > make all-local > make[7]: Entering directory > `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/jay' > gcc -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o closure.o > closure.c > [...] > > I've went through all of the various Makefile fragments looking for what could > be the problem, but I've not found it. > > Perhaps unsurprisingly, the build then eventually fails while compiling the > classes: > > [...] > make[8]: Entering directory > `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/class/Mono.Security' > make[8]: *** No rule to make target > `Mono.Math.Prime.Generator/SequentialSearchPrimeGeneratorBase.cs', needed by > `../../class/lib/net_1_1_bootstrap/Mono.Security.dll'. Stop. > make[8]: Leaving directory > `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/class/Mono.Security' > make[7]: *** [do-all] Error 2 > make[7]: Leaving directory > `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/class/Mono.Security' > make[6]: *** [all-recursive] Error 1 > [...] > > Anyone have any ideas why this will not build? It's just Solaris 9 w/ GNU, > nothing particularly special about the environment. Using gcc-3.4.4. > > Has anyone built this version under Solaris 9/sparc? > > (Please include me directly in any replies!) > > -- > Jason Downs > [EMAIL PROTECTED] > > I see a sky full of the stars that change our minds > and lead us back to a world we would not face. > ___ > 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] 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] 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
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
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] 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: 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] Fatal Error In GC: Too Many Threads
JD Conley wrote: The default in the GC for windows is to use 256 threads MAX. We should increase this. Now, the fact that you have 200+ threads running: is that by design in your app or is that a bug in itself? Is there any way I can adjust this value using an environment variable or an API somewhere? See "man mono", MONO_THREADS_PER_CPU. Rob ___ 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; ... /// /// Method FileUpload to test the remoting. /// 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); // // 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 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
Hi, > 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 ;-) > 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. > 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. 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. > 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 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. These faults don't have to be real ones either. 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! Now, if only we can get one of the key developers to play with us! 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
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] Re: [Mono-devel-list] TimeStamp support on oracle...
Le Jeudi 11 Août 2005 04:10, vous avez écrit : > Hello Hubert, > > I committed to svn trunk HEAD support for Oracle TIMESTAMP using an > OciDateTime descriptor. > It is svn revision 48254. Ok i'm back from my holidays... that's why i've not answered before... So I've update my mono from svn and i run a little test : cmd.Connection=new OracleConnection(cnx); cmd.CommandText="SELECT datetime FROM essai"; OracleDataAdapter dta=new OracleDataAdapter(cmd); DataSet ds = new DataSet(); dta.Fill(ds,"TABLE"); Console.WriteLine("OK"); foreach(DataRow row in ds.Tables["TABLE"].Rows) { Console.WriteLine(row["DATETIME"]); } I get : *** glibc detected *** free(): invalid pointer: 0x082fe20c *** Abandon It fails when it does dta.Fill When i do a mono --trace the last line i get is : . . . . . . . . . . ENTER: System.Data.OracleClient.Oci.OciDefineHandle:Dispose (bool)(this:0x5cf00 [System.Data.OracleClient.Oci.OciDefineHandle sqlserver.exe], 1, ) . . . . . . . . . . . ENTER: (wrapper managed-to-native) System.Runtime.InteropServices.Marshal:FreeHGlobal (intptr)(0x82ff9f4, ) > > Please let me know if this works for you or not. > > Thanks, > Daniel > > Hubert FONGARNAND wrote: > >I really need the new TimeStamp type (supported starting from oracle 9). > > It's a MS.NET supported type (i've made tests)... > >I've begin to do a little patch (attached) to add the timestamp type to > >oracle.client... > >but... I've a strange error when i try to do a Fill, it failed with: > > > >Unhandled Exception: System.Data.OracleClient.OracleException: > >in <0x0013d> System.Data.OracleClient.Oci.OciStatementHandle:Fetch () > >in <0x0002c> System.Data.OracleClient.OracleDataReader:Read () > >in <0x002f4> System.Data.Common.DbDataAdapter:FillTable > > (System.Data.DataTable dataTable, IDataReader dataReader, Int32 > > startRecord, Int32 maxRecords, System.Int32 counter) > >in <0x0011f> System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet > >dataSet, System.String srcTable, IDataReader dataReader, Int32 > > startRecord, Int32 maxRecords) > >in <0x000d5> System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet > >dataSet, Int32 startRecord, Int32 maxRecords, System.String srcTable, > >IDbCommand command, CommandBehavior behavior) > >in <0x00044> System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet > >dataSet) > >in <0x007b8> ConsoleIntranet.Class1:TestTimestamp () > >in <0x00015> ConsoleIntranet.Class1:Main (System.String[] args) > > > >Could someone help me how to resolve this issue? ___ 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] mcs patch to say goodbye to SeekableStreamReader
Hello, > Now I blame SeekableStreamReader on bringing UTF8 related bug > (without proof ;-) so I made a patch to eliminate this class. > > Additionally I made tiny modification for 'MZ' executable check > (even with a test case bom-mz.cs that differentiates csc and mcs). > > I'm not sure if it really is the culprit, but now we don't have > tricky stream usage, so now the code should be a bit healthy. In general adding more tests to the xtoken() routine hurts performance, that is why we have avoided it. I also believe that the new code is a bit more difficult to follow: just how many saved variables are we going to have? Before we can do something about this, I would like two tests to be done: time mcs --parse sourcefiles Where sourcefiles means a lot of source code, measure before and after. Then we should measure the impact of the allocation of SavedToken with mono --profile before and after. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] mcs.exe rsp file support
>Your measurement is poorly done: Never claimed it was done well :-) >As I had already told you this afternoon, this kind of patch will not be >accepted into mcs this year. Yeah, I know, and I didn't expect any different. But I like to have the list archives to keep the patch around than my harddisk where chances of it getting lost are high. Also, this way other contributors can chime in, too. Cheers, Peter ___ 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
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
[Mono-dev] [PATCH] GenericParameterAttributes updates
Hello, The MS Aug CTP release removes some fields from GenericParameterAttributes enumeration as well as adds some. The attached patch adds new ones and marks the removed ones with a comment. I would remove them, but I'm not sure something depends on it. 2005-08-30 Michal Moskal <[EMAIL PROTECTED]> * GenericParameterAttributes.cs: Update field names to match Aug CTP API. Mark obsolete ones. -- Michal Moskal, http://nemerle.org/~malekith/ gen-parm.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list