[Mono-dev] SVN does not compile

2007-10-02 Thread Mads Bondo Dydensborg
Hi there Just a short message to let those responsible know, that svn has not compiled for about three days now. make[8]: Entering directory `/home/compile/Compile/Mono/mcs/class/System.Data' ../../jay/jay -ct < ../../jay/skeleton.cs Mono.Data.SqlExpressions/Parser.jay >Mono.Data.SqlExpressions

[Mono-dev] C# pointer dereference NRE bug

2007-10-02 Thread StApostol
The following code runs correctly under .Net but produces an NRE under Mono 1.2.5 (both mcs and gmcs): using System; namespace Bug { unsafe class Demo { static void Foo(int[] data) { fixed (int* data_ptr = data) { /* Do something */ } } public static void M

Re: [Mono-dev] C# pointer dereference NRE bug

2007-10-02 Thread Jb Evain
On 10/2/07, StApostol <[EMAIL PROTECTED]> wrote: > The following code runs correctly under .Net but produces an NRE under Mono > 1.2.5 (both mcs and gmcs): It's a mcs/gmcs bug. The csc compiled version executes fine on Mono 1.2.5, while the mcs compiled version fails with the same exception on .ne

Re: [Mono-dev] C# pointer dereference NRE bug

2007-10-02 Thread StApostol
Filed as bug #330069 (https://bugzilla.novell.com/show_bug.cgi?id=330069) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Miguel de Icaza
Hey Cody, > I just want to quickly point out that we have made numerous improvements > to the look and functionality of gtk+ on Win32 during the 2.10-2.12 > cycle, and we are still working to further improve it. If there are any > particular issues that are blockers for you in gtk+, please file b

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Brad Taylor
Miguel, > You guys are maintaining the Gtk# installer for Windows, right? Yes -- I maintain the installer, and Cody does all the bug squashing with gtk+ and win32. (Full Disclosure: We're both employed by Medsphere) > I wonder if we could merge the efforts? Are you talking about merging effort

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Miguel de Icaza
Hello, > We had discussed this about a year ago and decided that we had different > interests, since we were focused on using MS .NET on Windows, and the > Mono team wanted to (rightfully so) focus on Mono on Windows. Are the binaries for .NET and Mono any different, other than the GAC install di

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Wade Berrier
On Tue, 2007-10-02 at 16:56 -0400, Miguel de Icaza wrote: > Hello, > > > We had discussed this about a year ago and decided that we had different > > interests, since we were focused on using MS .NET on Windows, and the > > Mono team wanted to (rightfully so) focus on Mono on Windows. > > Are the

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Brad Taylor
Hey, > > > We had discussed this about a year ago and decided that we had different > > > interests, since we were focused on using MS .NET on Windows, and the > > > Mono team wanted to (rightfully so) focus on Mono on Windows. > > > > Are the binaries for .NET and Mono any different, other than

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Mirco Bauer
On Tue, 2007-10-02 at 11:42 -0700, Brad Taylor wrote: > Miguel, > > > You guys are maintaining the Gtk# installer for Windows, right? > > Yes -- I maintain the installer, and Cody does all the bug squashing > with gtk+ and win32. (Full Disclosure: We're both employed by > Medsphere) Ah, this is

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Mirco Bauer
[please CC me, I am subcribe to the list but I miss replies very fast] On Mon, 2007-09-24 at 11:14 +0200, "Andrés G. Aragoneses [ knocte ]" wrote: > We've also researched about the best portable I18N method, and we have > discarded Mono.Posix until bug > https://bugzilla.novell.com/show_bug.cgi?

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Miguel de Icaza
> Yes, I think this is possible, however it would force you guys to ship > Mono in a separate installer. I think we can do that; If we can do installers with dependencies (if we move to MSI) then we can just have one that has everything, right? > While we're chatting, if anyone is interested i

Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)

2007-10-02 Thread Brad Taylor
Hey Mirco, > Ah, this is good to know who maintains that installer. I tried the 2.10 > installer once and ran into real problems and could not find the correct > contact for it. We're currently trying to track down some crashers we're seeing with PerformQueuedUnrefs () in Gtk# 2.10.2 with TreeMod

[Mono-dev] gettext and Gtk#

2007-10-02 Thread Miguel de Icaza
> Regarding your feature request, of a fully managed gettext > implementation for Mono, that would only work partly if you use glade, > as glade will always use the unmanaged version. We could always change that. ___ Mono-devel-list mailing list Mono-de

[Mono-dev] Cross Compile for Embedded Linux PPC

2007-10-02 Thread Dan Osawa
Hello, I'm trying to build a very minimal Mono (non-gui apps) for an embedded PPC Linux system. I would like to cross compile it on my IA32 Fedora Core system, which has the cross compiler tools located under /opt/Arabella. Are there ./configure paramters that I can use to achieve this? Thanks,

[Mono-dev] gnome-keyring-sharp due for the GAC

2007-10-02 Thread Alp Toker
This evening I committed a patch to make Gnome.Keyring, the managed Gnome keyring client implementation written by Gonzalo, installable to the GAC. The patch is based on what's already packaged by OpenSUSE, who have been pushing the envelope to make this library fully installable. The Debian g

Re: [Mono-dev] gnome-keyring-sharp due for the GAC

2007-10-02 Thread Miguel de Icaza
> This is the last chance to make API-breaking changes or even obsoletions > before we stabilize and make the release, so application authors and > packagers should speak up as soon as possible if they are uncomfortable > with any aspect of the library. At this stage, only critical changes > w