Re: [Mono-dev] Mono.Simd AltiVec port
Hi Sergei, On Tue, Feb 2, 2010 at 6:59 AM, Sergei Dyshel wrote: > Hello all, > > I'm currently working on PowerPC port of Mono which utilizes AltiVec SIMD > instructions. During the development I've encountered an alignment problem: > > As far as I understood from running Mono's JIT, stack-allocated > Mono.Simd.Vector* types are always aligned by 16 byte bound, but global > ones aren't (such as static class members). This is not a problem for SSE > which has unaligned load/stores but AltiVec doesn't have them. Instead of > implementing misaligned loads/stores for AltiVec I think it's better to > force alignment in global variables, as it done in the case of stack. > No, the JIT doesn't align all Vector types to 16 bytes. There are places, like spill, code that still doesn't do it correctly. Not a lot of work to get there, but still not done. If by global variables you mean statics, then making them properly aligned is possible with some trickery. The only issue alignment issue we can't currently fix are heap objects due to how our GC works. Our new GC might eventually gain the ability to properly align such objects, but this is something for the far future. > Can somebody help me with that (e.g. point at relevant places in > 'mini-ppc.c')? > To fix the alignment of stack variables you need to mess with a bunch of places: -The spill code from mini-codegen.c -The var allocation code in mono_allocate_stack_slots (mini.c) To fix the static storage alignment you need to change the code that allocate the statics area to use the proper alignment. This is the same problem as with objects as it uses a gc routine to allocate the memory blob. Fixing this requires boing deep into the GC, which is not something simple. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Not sure if this is a bug
Hi, > You may have to escape spaces in the path. Did you try escaping > all instances of " " with "\ " (that's a backslash, then a space)? No - the code is being run directly from a USB pen. Works fine under Windows but borks under Linux. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.6.x
On Wed, 2010-02-03 at 11:25 -0800, Tom Philpot wrote: > There are several patches for Mac that I'd like to make sure are in > the 2.6.x point release: > > > - Fix for CookieContainer.cs > CookieContainer.cs r149976 > CookieContainerTests.cs r149976 They were already backported. You can easily check this by using either the mailing-list archives [1][2] or the web interface to anonymous svn [3][4]. [1] http://lists.ximian.com/archives/public/mono-patches/ [2] http://lists.ximian.com/archives/public/mono-patches/2010-January/164754.html [3] http://anonsvn.mono-project.com/viewvc/branches/mono-2-6/ [4] http://anonsvn.mono-project.com/viewvc/branches/mono-2-6/mcs/class/System/System.Net/ Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.6.x
On 2010-02-03, at 2:27 AM, matteo tesser wrote: > HI > > The following bug has been fixed on the trunk, I would like it to be > backported: > https://bugzilla.novell.com/show_bug.cgi?id=402833 This patch will not be backported, it changes the behaviour of well tested stable component in a major way with a serious chance of regressions. Geoff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.6.x
There are several patches for Mac that I'd like to make sure are in the 2.6.x point release: - Fix for CookieContainer.cs CookieContainer.cs r149976 CookieContainerTests.cs r149976 - Fix for BufferedStream Read/Write BufferedStream.cs r149799 The following patch contains several other fixes which are already on 2.7 but which may or may not be on 2.6 branch Index: mcs/class/corlib/System/DateTimeOffset.cs === --- mcs/class/corlib/System/DateTimeOffset.cs (revision 147113) +++ mcs/class/corlib/System/DateTimeOffset.cs (working copy) @@ -47,7 +47,7 @@ public DateTimeOffset (DateTime dateTime) { - dt = dateTime; + dt = DateTime.SpecifyKind(dateTime, DateTimeKind.Unspecified); if (dateTime.Kind == DateTimeKind.Utc) utc_offset = TimeSpan.Zero; Index: mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10ItemFormatter.cs === --- mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10ItemFormatter.cs (revision 147113) +++ mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10ItemFormatter.cs (working copy) @@ -499,6 +499,7 @@ writer.WriteEndElement (); } + WriteElementExtensions (writer, Item, Version); if (writeRoot) writer.WriteEndElement (); } Index: mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10FeedFormatter.cs === --- mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10FeedFormatter.cs (revision 147113) +++ mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10FeedFormatter.cs (working copy) @@ -486,6 +486,7 @@ WriteItems (writer, Feed.Items, Feed.BaseUri); + WriteElementExtensions (writer, Feed, Version); if (writeRoot) writer.WriteEndElement (); } Index: mono/mono/io-layer/processes.c === --- mono/mono/io-layer/processes.c (revision 147113) +++ mono/mono/io-layer/processes.c (working copy) @@ -1489,8 +1489,73 @@ } #endif /* UNUSED_CODE */ +#ifdef PLATFORM_MACOSX +#include +#include + gboolean EnumProcesses (guint32 *pids, guint32 len, guint32 *needed) { + guint32 count, fit, i, j; + gint32 err; + gboolean done; + struct kinfo_proc *result; + size_t proclength; + static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 }; + + mono_once (&process_current_once, process_set_current); + + result = NULL; + done = FALSE; + + do { + proclength = 0; + err = sysctl ((int *)name, (sizeof(name) / sizeof(*name)) - 1, NULL, &proclength, NULL, 0); + if (err == -1) { + err = errno; + } + + if (err == 0) { + result = g_malloc (proclength); + if (result == NULL) { + err = ENOMEM; + } + } + + if (err == 0) { + err = sysctl ((int *) name, (sizeof(name) / sizeof(*name)) - 1, result, &proclength, NULL, 0); + if (err == -1) { + err = errno; + } + if (err == 0) { + done = TRUE; + } else if (err == ENOMEM) { + free(result); + result = NULL; + err = 0; + } + } + } while (err == 0 && !done); + + if (err != 0 && result != NULL) { + free (result); + result = NULL; + return(FALSE); + } + + count = proclength / sizeof(struct kinfo_proc); + fit = len / sizeof(guint32); + for (i = 0, j = 0; j< fit && i < count; i++) { + pids [j++] = result [i].kp_proc.p_pid; + } + free (result); + result = NULL; + *needed = j * sizeof(guint32); + + return(TRUE); +} +#else +gboolean EnumProcesses (guint32 *pids, guint32 len, guint32 *needed) +{ GArray *processes = g_array_new (FALSE, FALSE, sizeof(pid_t)); guint32 fit, i, j; DIR *dir; @@ -1528,6 +1593,7 @@ return(TRUE); } +#endif static gboolean process_open_compare (gpo
Re: [Mono-dev] Not sure if this is a bug
You may have to escape spaces in the path. Did you try escaping all instances of " " with "\ " (that's a backslash, then a space)? -- John Feminella Principal Consultant, Distilled Brilliance On Tue, Feb 2, 2010 at 15:24, Paul wrote: > Hi, > > Using md-2.2 and mono-2.6.1 (fedora rawhide). > > Under .NET 3.5, the following works fine. Under mono, it's returning > that the file can't be opened despite it pointing at the correct place > > public void dotheread() > { > try > { > string path_env = > Path.GetDirectoryName(Application.ExecutablePath) > + Path.DirectorySeparatorChar; > Stream stream = File.Open(path_env + > "elements.ele", > FileMode.Open); > BinaryFormatter bf = new BinaryFormatter(); > var elementgo = > (List)bf.Deserialize(stream); > stream.Close(); > } > catch(System.IO.FileNotFoundException) > { > string m = "Unable to find the elements > information file : using " + > Path.GetDirectoryName(Application.ExecutablePath) + > Path.DirectorySeparatorChar + "elements.ele"; > MessageBox.Show(m, "File not found", > MessageBoxButtons.OK); > } > } > > The error box returns > > "Unable to find the elements information file : using /media/USB > DISK/molarity/bin/Debug/elements.ele" > > The file is stored in /media/USB DISK/molarity/bin/Debug/elements.ele - > not sure if the problem is that there is a space between USB and DISK > which could cause an issue. > > Any ideas? > > TTFN > > Paul > > -- > Sie können mich aufreizen und wirklich heiß machen! > > ___ > 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] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)
Hi, I've filed a somewhat nasty bug a few days back (you may lose your data if you trigger it): https://bugzilla.novell.com/show_bug.cgi?id=575813 I'd really appreciate if someone could take a look at this. -- Cheers, Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with BinarySerialization
On 03.02.2010 10:49, PFJ wrote: > > Hi, > > > Robert Jordan wrote: >> >> On 02.02.2010 14:35, PFJ wrote: Thus, the only *clean* way to solve this is introducing a shared assembly implementing the classes you want to serialize. It's a common pattern. >>> >>> As the serializer is only used once, can the other app just deserialize >>> and >>> use it? I've reimplemented the Elements class but now just have a little >>> problem in accessing it... >> >> It doesn't matter how often, in which way or how symmetric >> the de/serialization is performed. What counts is the type identity. >> > > Hmm, I guess that is why after I've sorted out the code (thanks), added in > the Elements class and now have it compiled, I'm getting the same error as I > did originally (SerializationError - can't find 'elements'). Did you create a separate shared assembly or have you just included the Elements class in both projects? The latter does not ensure type identity and it's not what you want. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with BinarySerialization
Hi, Robert Jordan wrote: > > On 02.02.2010 14:35, PFJ wrote: >>> Thus, the only *clean* way to solve this is introducing a shared >>> assembly implementing the classes you want to serialize. It's a >>> common pattern. >>> >> >> As the serializer is only used once, can the other app just deserialize >> and >> use it? I've reimplemented the Elements class but now just have a little >> problem in accessing it... > > It doesn't matter how often, in which way or how symmetric > the de/serialization is performed. What counts is the type identity. > Hmm, I guess that is why after I've sorted out the code (thanks), added in the Elements class and now have it compiled, I'm getting the same error as I did originally (SerializationError - can't find 'elements'). I'm running the debugger on the code that generates the binaryserialized form and when I look at the debug information (I admit, this is under VS2008) it says elementgo Count=111 with a plus icon before the element go. click on the + icon and it says + 0 {elements.Form1.Elements}. click on the + icon and it gives me the copy of the list. Is it this {elements.Form1.Elements} it's objecting to? TTFN Paul -- View this message in context: http://old.nabble.com/Problem-with-BinarySerialization-tp27419333p27433786.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list