Re: [Mono-devel-list] DataSet and DataRelation problems ...
Okie dokie ! Everything seems to be ok ! Thanks for yor help ! Bye ! Ps : The installer is just great Thanks !!! Atsushi Eno wrote: Hello, mono 1.0.2 is pretty old. I fixed several bugs around DataSet XML processing in mono 1.1.4 and later. It would be best if you try the latest daily build from source: http://mono.ximian.com/daily/ If you still have problem, please file a bug details here, with sample runnable code and expected output: http://bugzilla.ximian.com/ Thanks Atsushi Eno xiii29 wrote: Hello ! I've a strange problem with DataRelation ... When I set some relations on my DataSet, I'm not able to save info when I do MyDataSet.WriteXML ... The strange things is when I execute the binary on Microsoft .Net everything goes fine ... Here is a sample of code when I set the DataRelation : DataColumn dclFather = this.TableFather.Columns[ID]; DataColumn dclSon = this.TableSon.Columns[FK_ID]; this.Data.Relations.Add(dclFather, dclSon); For info, I'm using the 1.0.2 version ... Thanks ! ___ 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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Problems compiling
Hi, I seem to be having a problem compiling libgdiplus. libgdiplus comes up with a pile of errors in font.c cc1: warnings being treated as errors font.c: In function 'GdipCreateFontFamilyFromName': font.c:283: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness font.c:283: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness font.c:283: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:283: warning: pointer targets in passing argument 2 of '__builtin_strcmp' differ in signedness font.c:283: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness font.c:283: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:283: warning: pointer targets in passing argument 2 of '__builtin_strcmp' differ in signedness font.c:283: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness font.c:283: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:283: warning: pointer targets in passing argument 2 of '__builtin_strcmp' differ in signedness font.c:283: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:283: warning: pointer targets in passing argument 2 of '__builtin_strcmp' differ in signedness font.c: In function 'GdipCreateFont': font.c:648: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness font.c:648: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:648: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness font.c:648: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:648: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:648: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness font.c:676: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness font.c:681: warning: pointer targets in passing argument 2 of 'strcpy' differ in signedness font.c:695: warning: pointer targets in passing argument 2 of 'strcpy' differ in signedness font.c: In function 'GdipPrivateAddMemoryFont': font.c:780: warning: pointer targets in passing argument 2 of 'FcConfigAppFontAddFile' differ in signedness make[2]: *** [font.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 This was updated today (12th March) at about 14:30 GMT. Is this a known bug or something else. I have run make distclean on the directory. I'm using gcc 4 under FC rawhide. Everything else builds without a hiccup. -- I like blinking me - Helen, Big Brother 2 contestant signature.asc Description: This is a digitally signed message part
Re: [Mono-devel-list] Sln to make conversion
You can try to use prj2make or prj2make-sharp-gtk (they have very similar capabilities but one has a GUI front end). Prj2make only work with C# projects and solution files for C# projects. It is also intended for Visual Studio .NET 2003. There is also a Visual Studio add-in (vsprj2make). This works nice within the Visual Studio IDE. Prj2make is not perfect but it may prove useful and get you started. Paco JD Conley wrote: We have a pretty big set of .NET solutions/projects that we would like to build in the latest Mono and get running on Linux/OSX. They consist of C#, VB.NET, and one small C++ project that does some native Windows interfacing. At this point it's about .25 million lines of code. Is there a utility somewhere that can create a Mono make compatible environment: generate makefiles, etc? I'm assuming we may have to rip the C++ features out of the code to get a Mono version going at first (it's only a small subset). Once we get the ball rolling with this project we'll probably be contributing quite a few fixes back to Mono and maybe some features. We have a large test suite that utilizes quite a bit of the .NET Framework and VB.NET. Do you guys have a good example of an architecture for building cross platform .NET code, with respect to utilizing each platform's unmanaged strengths where possible (like Windows or OSX specific APIs, for example)? We're also interested in investigating the .NET 2.0 compatible branch of Mono. Does anyone have any comments on its stability at this point? I couldn't find this on the web site. JD Conley ___ 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-devel-list] Build Problems
Hello, I am having some trouble getting Mono to build. I am running the Fedora Core 3 64 bit edition. I am trying to build the stable release, 1.0.6. I used this configure string ./configure --prefix=/usr/local/mono .. everything there worked fine. On make, it errors out at the following: make[3]: Entering directory `/root/compiled/mono/mono-1.0.6/mono/io-layer' if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I../../libgc/include -DMONO_BINDIR=\/usr/local/mono/bin\ -I../.. -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -g -O2 -fno-strict-aliasing -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -MT threads.lo -MD -MP -MF .deps/threads.Tpo -c -o threads.lo threads.c; \ then mv -f .deps/threads.Tpo .deps/threads.Plo; else rm -f .deps/threads.Tpo; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I../../libgc/include -DMONO_BINDIR=\/usr/local/mono/bin\ -I../.. -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -g -O2 -fno-strict-aliasing -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -MT threads.lo -MD -MP -MF .deps/threads.Tpo -c threads.c -fPIC -DPIC -o .libs/threads.o /tmp/cc4yVbOs.s: Assembler messages: /tmp/cc4yVbOs.s:318: Error: suffix or operands invalid for `mov' /tmp/cc4yVbOs.s:395: Error: suffix or operands invalid for `mov' /tmp/cc4yVbOs.s:1717: Error: suffix or operands invalid for `mov' make[3]: *** [threads.lo] Error 1 make[3]: Leaving directory `/root/compiled/mono/mono-1.0.6/mono/io-layer' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/compiled/mono/mono-1.0.6/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/compiled/mono/mono-1.0.6' make: *** [all] Error 2 Any ideas or suggestions would be appreciated. Thanks! -- Aaron Axelsen [EMAIL PROTECTED] Great hosting, low prices. Modevia Web Services LLC -- http://www.modevia.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] patch for TypeBuilder.CreateType() and mcs
Hi,
I'd call it a bug if MCS or GMCS ever calls TypeBuilder.CreateType() on
an already created type.
Is there any situation where this is happening ?
Martin
On Fri, 2005-03-11 at 11:15 +0530, Raja R Harinath wrote:
Atsushi Eno [EMAIL PROTECTED] writes:
Index: mcs/class.cs
===
--- mcs/class.cs(revision 41656)
+++ mcs/class.cs(working copy)
@@ -2118,7 +2118,15 @@
try {
caching_flags |= Flags.CloseTypeCreated;
- TypeBuilder.CreateType ();
+#if NET_2_0
+ if (!TypeBuilder.IsCreated ())
+ TypeBuilder.CreateType ();
+#else
+ try {
+ TypeBuilder.CreateType ();
+ } catch (InvalidOperationException) {
+ }
+#endif
} catch (TypeLoadException){
//
// This is fine, the code still created the type
The NET_2_0 define isn't meaningful in the current mcs code. Does the
try ... catch
version above also work with the .NET 2.0 profile? I suspect it does.
If so, that's the code that should go into mcs.
For 'gmcs', we can use the NET_2_0 variant, again without the #if.
- Hari
___
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
