Re: [Mono-dev] [PATCH] HSSA!
On Fri, 18 Nov 2005 22:36:38 +0100, Massimiliano Mantione wrote:
+#define CHECK_HEAP_STATE_LENGTH(__hssa,__bb) do {\
+ int __i = 0;\
+ MonoHssaHeapAddress *__ca =
(__hssa)-addresses_with_known_value;\
+ MonoHssaHeapAddress *__slow_ca = __ca;\
+ while (__ca != NULL) {\
I'm no expert for sure, but why use these huge macro-functions instead
of regular always inlined functions, eg
static __attribute__((always_inline)) check_heap_state_length ...
Does Mono have to be buildable with compilers that don't support that?
thanks -mike
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting URI Exception
Can you please file a bug report for this? thanks! El lun, 21-11-2005 a las 16:09 -0600, Carlos Solorzano escribió: On Nov 21, 2005, at 3:09 PM, Sebastien Pouliot wrote: Hello Carlos, On Mon, 2005-11-21 at 14:56 -0600, Carlos Solorzano wrote: ... Anyways, how would I go about printing out the port number? I didnt really see an option on the URI exception to print the URI. ... You are right seems like a bit of work has gone into the SVN code, I ran my code on the SVN mono If you have mono SVN, then simply edit Uri.cs to print the malformed Uri as part of the exception text. That would give us the problematic Uri. The exception shows up on the remoting client but the Uri Console.WriteLine shows up on the remoting server and it basically prints out for the uriString: 192.168.0.193:-1 --Carlos and now the exception moved from the remoting server to the remoting client, but its the exact same exception however now I have a place where I can catch it, although there isn't anything I can do with it. Any pointers will be greatly welcomed. -- Sebastien Pouliot email: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/ ___ 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: FW: [Mono-dev] Enum serealization proble in System.Xml.Serialization.XmlMapping
El dom, 20-11-2005 a las 01:23 -0800, Vladimir Krasnov escribió:
Hello Lluis,
Please approve the attached patch to
System.Xml.Serialization/XmlTypeMapping.cs
The change looks ok, but please:
* Use == to compare strings.
* you have to apply the fix to the serializer generator, or it will be
useless.
* a nunit test is needed for this.
Thanks!
Lluis.
Vladimir Krasnov
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 8:28 PM
To: Vladimir Krasnov
Cc: mono-devel mailing list
Subject: Re: [Mono-dev] Enum serealization proble in
System.Xml.Serialization.XmlMapping
Ah, now I understand what you wanted to do (serializing flag enums).
BTW I'm not maintaining XmlSerializer stuff; you should ping Lluis
to get your patches approved ;-)
Atsushi Eno
Vladimir Krasnov wrote:
You are right, but this occurs only on not flaggable enums. I suppose
the reason for this behavior is indeed an illegal state for such enum.
The reason it's supported for flaggable enum is that the zero value
means all flags are off.
Anyway the correct patch would be in file
System.Xml.Serialization\XmlTypeMapping.cs line 670 :
if (enumName.Equals(0) IsFlags)
Would you like to commit it or you prefer I'll do?
Vladimir Krasnov
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 6:54 PM
To: Vladimir Krasnov
Cc: mono-devel mailing list
Subject: Re: [Mono-dev] Enum serealization proble in
System.Xml.Serialization.XmlMapping
Oh, I didn't know that enum fields are always initialized as 0.
So your patch is basically to omit the value string instead of
omitting the entire element (or attribute) and it isn't
deserializable anyways (as well as MS.NET), right?
using System;
using System.IO;
using System.Xml.Serialization;
public class Foo
{
public EnumFoo efoo;
public static void Main ()
{
Foo f = new Foo ();
XmlSerializer s = new XmlSerializer (typeof (Foo));
StringWriter sw = new StringWriter ();
s.Serialize (sw, f);
StringReader sr = new StringReader (sw.ToString ());
f = (Foo) s.Deserialize (sr);
Console.WriteLine (f.efoo);
}
}
public enum EnumFoo {
A = 1,
B = 2
}
Cheers,
Atsushi Eno
Vladimir Krasnov wrote:
Hello Atsushi,
What do mean always 0? Is it may be other value if you don't
initialize enum variable?
I'll create test case soon.
Vladimir Krasnov
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 5:34 PM
To: Vladimir Krasnov
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Enum serealization proble in
System.Xml.Serialization.XmlMapping
It would be much better if you avoid application/octet-stream for
your text attachments (it is even unlikely to be read by others).
Are you sure that enum default value is always 0 ?
Also, it looks like you forgot to create NUnit test for your
example case.
Cheers,
Atsushi Eno
Vladimir Krasnov wrote:
Hello All,
There is a problem in serialization of Enum default value, the value
shouldn't be written to the xml.
See attached sample that reproduces the problem.
Also please approve the patch that fixes the problem.
If no one objects I'll commit.
Vladimir Krasnov
___
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-dev] Re: XPath iterator problem
Oops, good catch! Please commit. Thanks! Atsushi Eno Vladimir Krasnov wrote: Hello Atsushi, I've found a problem in SimpleSlashIterator.MoveNextCore() method. Please see attached sample that reproduces the problem. I've also attached a patch for System.Xml.XPath\Iterator.cs that fixes the problem, please review. Krasnov Vladimir ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RE: External entity resolution
Hi Eno, Yep, you are right, we have more problems here: if someone retrieves the Entity object using DOM, it will be never resolved... So the direction looks good, but there is more work to do. May be we will consider to continue it at a later stage. Regards, Konstantin Triger -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 4:22 PM To: Konstantin Triger Cc: mono-devel-list@lists.ximian.com Subject: Re: External entity resolution Hi Kosta, I think the idea that entity declaration does not have to resolve the actual entity until it is referenced is nice to do. But the patch breaks several tests with NullReferenceException. Can you please run make run-test in System.XML and hopefully in System.XML/Test/System.Xml/standalone_tests? Andrew made a pretty useful NUnit integration there. Thanks, Atsushi Eno Konstantin Triger wrote: Hello Eno, We fail to load the following xml: !DOCTYPE doc [ !ENTITY e PUBLIC ;[EMAIL PROTECTED] 100.xml !ELEMENT doc (#PCDATA) ] doc/doc The reason is that we try to set the entity content when it's declared and not when it's referenced. The attached patch fixes the issue. BTW, do we need to resolve it before it's referenced? I guess no... So the LiteralEntityValue should be empty and we need to create a XmlReader based on SystemId and read the data when requested... Regards, Konstantin Triger ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] HSSA!
On Tue, 2005-11-22 at 00:47 +, Mike Hearn wrote:
On Fri, 18 Nov 2005 22:36:38 +0100, Massimiliano Mantione wrote:
+#define CHECK_HEAP_STATE_LENGTH(__hssa,__bb) do {\
+ int __i = 0;\
+ MonoHssaHeapAddress *__ca =
(__hssa)-addresses_with_known_value;\
+ MonoHssaHeapAddress *__slow_ca = __ca;\
+ while (__ca != NULL) {\
I'm no expert for sure, but why use these huge macro-functions instead
of regular always inlined functions, eg
static __attribute__((always_inline)) check_heap_state_length ...
Does Mono have to be buildable with compilers that don't support that?
Nice catch :-)
IIRC there's the possibility to compile Mono with the MS compiler
on Windows, and I'm not sure about other compilers/platforms.
Anyway, this particular macro (CHECK_HEAP_STATE_LENGTH) is huge,
but it is only used if DEBUG_HSSA is true.
It started small, and grew up during a hard debugging session :-)
Since when DEBUG_HSSA is true performance is not important (and
the computations performed in the macro kill performance anyway!),
it could just be turned into a proper static function, with the
whole function definition put inside an #if (DEBUG_HSSA) to make
it disappear in the normal case.
I'll likely do this, it's nicer than a monster macro ;-)
Ciao,
Massi
.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SWF, gtk#, OSX, Linux, Win32, GUI's thougths?
I would just like to get some thoughts and clarifications about a few things. 1) It says SWF at end of month.. and then months of testing.. when will it likely debut in the standard distribution (dowload page) , and not be a cvs only? 2) It is mentioned how SWF will work on Win32, OSX and linux, is it possible that the release that has SWF will for sure have SWF working on all three Win32/Linux/OSX, with OSX not needing X11 support .. or may it be the case that it could come out, at fisrt, not supporting OSX? 3) No IP flames intended here (just assume there might be an issue) ... Having been around Mono now for 2+ years, I have seen much written about the licensing and IP issues. Let just assume for this question that there is a possibly a MS IP issue that could come along for SWF in the future. I would really rather use GTK# for win32/linux/OSX x-platform dev. (call it personal choice) but as we know gtk# for native OSX (no X11 deps.) is no where is sight. So this (above) got me thinking - We know a certain portion of people on/in the Mono project are MS people (which is great, Mono needs that), and the MS people are of course going to want SWF for their GUI a lot of the time? But is it not true that many others would want gtk#? and in fact from what I see in the demo pages, gtk# IS very popular. So I find it odd that gtk# support for native OSX is still perhaps completely out of sight, yet we could be close to having SWF for native OSX now? and there are possibly some IP issue with SWF on linux/OSX. So the end result of my thinking is .. is there not a disproportionate amount of time being spent on SWF on native OSX than gtk# on native OSX? maybe the answer is - that i am one of about 5 people that care about using gtk# on native OSX :( Or perhaps SWF for native OSX came very easy? and gtk# for native OSX is very hard to implement? -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SWF, gtk#, OSX, Linux, Win32, GUI's thougths?
I think OSX support for GTK just went into cvs recently. - Original Message - From: ted leslie [EMAIL PROTECTED] Date: Tuesday, November 22, 2005 3:04 pm Subject: [Mono-dev] SWF, gtk#, OSX, Linux, Win32, GUI's thougths? I would just like to get some thoughts and clarifications about a few things. 1) It says SWF at end of month.. and then months of testing.. when will it likely debut in the standard distribution (dowload page) , and not be a cvs only? 2) It is mentioned how SWF will work on Win32, OSX and linux, is it possible that the release that has SWF will for sure have SWF working on all three Win32/Linux/OSX, with OSX not needing X11 support .. or may it be the case that it could come out, at fisrt, not supporting OSX? 3) No IP flames intended here (just assume there might be an issue) ... Having been around Mono now for 2+ years, I have seen much written about the licensing and IP issues. Let just assume for this question that there is a possibly a MS IP issue that could come along for SWF in the future. I would really rather use GTK# for win32/linux/OSX x-platform dev. (call it personal choice) but as we know gtk# for native OSX (no X11 deps.) is no where is sight. So this (above) got me thinking - We know a certain portion of people on/in the Mono project are MS people (which is great, Mono needs that), and the MS people are of course going to want SWF for their GUI a lot of the time? But is it not true that many others would want gtk#? and in fact from what I see in the demo pages, gtk# IS very popular. So I find it odd that gtk# support for native OSX is still perhaps completely out of sight, yet we could be close to having SWF for native OSX now? and there are possibly some IP issue with SWF on linux/OSX. So the end result of my thinking is .. is there not a disproportionate amount of time being spent on SWF on native OSX than gtk# on native OSX? maybe the answer is - that i am one of about 5 people that care about using gtk# on native OSX :( Or perhaps SWF for native OSX came very easy? and gtk# for native OSX is very hard to implement? -tl ___ 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] AppDomain and web app
On Mon, 2005-11-21 at 22:54 -0600, Carlos Solorzano wrote: Considering the two appdomains are on the same process, do we still need tcp or http remoting? I know there are ways to pass stuff back and fwd between appdomains whenever you create the second domain however I do not know where asp.net creates the new domain, nor do I seem to have access to that information. Google for 'ApplicationHost' and click I'm feeling lucky. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono on IRIX
Has anyone been able to get Mono running under IRIX? Is it even possible? Thanks, --b ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SWF, gtk#, OSX, Linux, Win32, GUI's thougths?
On Tue, 22 Nov 2005 15:15:17 -0600 CODY RUSSELL [EMAIL PROTECTED] wrote: I think OSX support for GTK just went into cvs recently. with no need for X11? can anyone confirm this? -tl - Original Message - From: ted leslie [EMAIL PROTECTED] Date: Tuesday, November 22, 2005 3:04 pm Subject: [Mono-dev] SWF, gtk#, OSX, Linux, Win32, GUI's thougths? I would just like to get some thoughts and clarifications about a few things. 1) It says SWF at end of month.. and then months of testing.. when will it likely debut in the standard distribution (dowload page) , and not be a cvs only? 2) It is mentioned how SWF will work on Win32, OSX and linux, is it possible that the release that has SWF will for sure have SWF working on all three Win32/Linux/OSX, with OSX not needing X11 support .. or may it be the case that it could come out, at fisrt, not supporting OSX? 3) No IP flames intended here (just assume there might be an issue) ... Having been around Mono now for 2+ years, I have seen much written about the licensing and IP issues. Let just assume for this question that there is a possibly a MS IP issue that could come along for SWF in the future. I would really rather use GTK# for win32/linux/OSX x-platform dev. (call it personal choice) but as we know gtk# for native OSX (no X11 deps.) is no where is sight. So this (above) got me thinking - We know a certain portion of people on/in the Mono project are MS people (which is great, Mono needs that), and the MS people are of course going to want SWF for their GUI a lot of the time? But is it not true that many others would want gtk#? and in fact from what I see in the demo pages, gtk# IS very popular. So I find it odd that gtk# support for native OSX is still perhaps completely out of sight, yet we could be close to having SWF for native OSX now? and there are possibly some IP issue with SWF on linux/OSX. So the end result of my thinking is .. is there not a disproportionate amount of time being spent on SWF on native OSX than gtk# on native OSX? maybe the answer is - that i am one of about 5 people that care about using gtk# on native OSX :( Or perhaps SWF for native OSX came very easy? and gtk# for native OSX is very hard to implement? -tl ___ 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
Re: [Mono-dev] Mono's handling of Structs
At 08:40 PM 22/11/2005 -0800, Bill Six wrote: [snip] Is this a bug in the mono compiler? Should it automatically know that a declaration of a struct implies calling the default constructor? [snip] Structs do not have default constructors. As members of classes, variables of value types get initialized to whatever interpretation all bits 0 has -- equivalent to memset(mystruct, 0, sizeof(mystruct)); in C/C++. As local variables, the individual members of structs are (or should be) considered independently for initialized-ness, but the struct as a whole cannot be used (e.g. passed as a parameter or assigned elsewhere) until all of those members have been written to. As with any other local variable, in the absence of an initializer, the value is undefined prior to assignment, and it is an error to try to use it. To summarize, within code, Point pt; allocates the memory for pt, but does not initialize it in any way. Point pt = new Point(); sets all members of pt to 0 or null, depending on the data type. Outside of code, as a class member, Point pt; gets initialized to zeroes as part of the class instance initialization, and not because of anything special tied to the value type Point. Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
