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
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
[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] 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 p...@all-the-johnsons.co.uk 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 =
(ListElements)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
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 sys/sysctl.h
+#include sys/proc.h
+
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
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
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] 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.Simd AltiVec port
Hi Sergei, On Tue, Feb 2, 2010 at 6:59 AM, Sergei Dyshel qyron.priv...@gmail.comwrote: 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
