Re: spam: suspected: Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch
If you want please feel free to do so. Atsushi Eno Eyal Alaluf wrote: Hi, Atsushi. O.K. Let's use the TARGET_JVM then. Shouldn't we ad some kind of FIXME or MonoTODO in this case? I'd like to still keep track of this issue and get rid of the '#if TARGET_JVM' when Mono and Grasshopper behave the same. Eyal. On Wed, 8 Jun 2005, Atsushi Eno wrote: Date: Wed, 08 Jun 2005 18:00:35 +0900 From: Atsushi Eno <[EMAIL PROTECTED]> To: Eyal Alaluf <[EMAIL PROTECTED]> Cc: Andrew Skiba <[EMAIL PROTECTED]>, mono-devel mailing list Subject: Re: spam: suspected: Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch It will result in the same if we forget the existence itself ;-) Anyways the switch is simple and there are not so many places that TARGET_JVM is used. Andrew: I think there was a similar problem in XmlConvert.cs. Thanks, Atsushi Eno Eyal Alaluf wrote: Maybe we should use a new define here, something like "ROUNDTRIP_BUG_FIXED"? We could define it in the JVM configuration and when it is fixed in Mono it would be easier to locate and fix in the code. Eyal. On Wed, 8 Jun 2005, Andrew Skiba wrote: Date: Wed, 08 Jun 2005 11:07:42 +0300 From: Andrew Skiba <[EMAIL PROTECTED]> To: Atsushi Eno <[EMAIL PROTECTED]> Cc: mono-devel mailing list Subject: spam: suspected: Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch Hi, Eno. I want to commit TARGET_JVM for roundtrip bug. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Please review the catalog patch
Hi Eno. I see that upgrading to v4 of the testsuite is not smooth, so I will not waste my time on this anymore. Please try the applied patch, and if it's OK, then I'm done with this testsuite. Andrew. Index: ChangeLog === --- ChangeLog (revision 45578) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2004-06-09 Andrew Skiba <[EMAIL PROTECTED]> + + * Makefile, catalog-fixed.diff : Patch the fixed catalog to correct things + I could not fix with sed script + 2005-06-06 Andrew Skiba <[EMAIL PROTECTED]> * xslttest.cs : change messages Index: Makefile === --- Makefile(revision 45578) +++ Makefile(working copy) @@ -68,9 +68,14 @@ .cs.exe : $(CSCOMPILE) $< -$(FIXED_CATALOG) : $(CATALOG) catalog.sed +catalog-fixed : $(FIXED_CATALOG) + +$(FIXED_CATALOG) : $(CATALOG) catalog.sed catalog.diff sed -f catalog.sed $(CATALOG) > $(FIXED_CATALOG) + patch -p0 $(FIXED_CATALOG) < catalog-fixed.diff +catalog : $(CATALOG) + $(CATALOG) : $(TEST_ARCHIVE) unzip -un $(TEST_ARCHIVE) touch $(CATALOG) Index: catalog-fixed.diff === --- catalog-fixed.diff (revision 0) +++ catalog-fixed.diff (revision 0) @@ -0,0 +1,104 @@ +--- testsuite/TESTS/catalog-fixed.xml 2005-06-09 10:29:51.941937800 +0300 catalog-fixed.xml 2005-06-09 10:11:58.629437800 +0300 +@@ -17155,14 +17155,14 @@ + string11.out + + +- ++ + string + Test of 'concat()' + + +-string09.xml +-string09.xsl +-string09.out ++string12.xml ++string12.xsl ++string12.out + + + +@@ -17277,58 +17277,58 @@ + string30.out + + +- ++ + string + + +-.xml +-.xsl +-.out ++string31.xml ++string31.xsl ++string31.out + + +- ++ + string + + +-.xml +-.xsl +-.out ++string32.xml ++string32.xsl ++string32.out + + +- ++ + string + + +-.xml +-.xsl +-.out ++string33.xml ++string33.xsl ++string33.out + + +- ++ + string + + +-.xml +-.xsl +-.out ++string34.xml ++string34.xsl ++string34.out + + +- ++ + string + + +-.xml +-.xsl +-.out ++string35.xml ++string35.xsl ++string35.out + + +- ++ + string + + +-.xml +-.xsl +-.out ++string36.xml ++string36.xsl ++string36.out + + + ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Please review the catalog patch
Hi Andrew, +- +-string09.xml +-string09.xsl +-string09.out Was there anything wrong with string09 testcase? Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: spam: suspected: Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch
Atsushi Eno wrote: Andrew: I think there was a similar problem in XmlConvert.cs. Eno, I see once the fix was in XmlConvert, but now the flow for this testcase does not pass there. Do you think I have to fix both places anyway? Thanks, Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.SessionState - patch (code synchronization between Mono and Mainsoft)
I agree, good shot Ben!
Attached updated patch.
Thank you,
Ilya.
Ben Maurer wrote:
On Wed, 2005-06-08 at 13:17 +0300, Ilya Kharmatsky wrote:
InProc = 1,
StateServer = 2,
SQLServer = 3
+#if TARGET_J2EE
+ ,J2ee = 4
+#endif
It's probably a bad idea to add such a low enumeration value, as msft
could add a value here.
-- Ben
Index: ChangeLog
===
--- ChangeLog (revision 45568)
+++ ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2005-06-08 Ilya Kharmatsky
+
+* SessionStateMode.cs: Added TARGET_J2EE directive in order
+to provide in J2EE configuration additional mode - J2EE
+* SessionStateModule.cs: Added TARGET_JVM directives in order
+to resolve unsupported in Ghrasshopper "static variables" issue
+(When static variable are stored in general place, instead of
+storing such variables per AppDomain).
+
2005-05-27 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
* RemoteStateServer.cs:
Index: SessionStateMode.cs
===
--- SessionStateMode.cs (revision 45568)
+++ SessionStateMode.cs (working copy)
@@ -35,6 +35,9 @@
InProc = 1,
StateServer = 2,
SQLServer = 3
+#if TARGET_J2EE
+ ,J2ee = 4
+#endif
}
}
Index: SessionStateModule.cs
===
--- SessionStateModule.cs (revision 45568)
+++ SessionStateModule.cs (working copy)
@@ -42,8 +42,27 @@
internal static readonly string CookieName = "ASPSESSION";
internal static readonly string HeaderName =
"AspFilterSessionId";
+#if !TARGET_J2EE
static SessionConfig config;
static Type handlerType;
+#else
+ static private SessionConfig config {
+ get {
+ return
(SessionConfig)AppDomain.CurrentDomain.GetData("SessionStateModule.config");
+ }
+ set {
+
AppDomain.CurrentDomain.SetData("SessionStateModule.config", value);
+ }
+ }
+ static private Type handlerType {
+ get {
+ return
(Type)AppDomain.CurrentDomain.GetData("SessionStateModule.handlerType");
+ }
+ set {
+
AppDomain.CurrentDomain.SetData("SessionStateModule.handlerType", value);
+ }
+ }
+#endif
ISessionHandler handler;
bool sessionForStaticFiles;
@@ -197,8 +216,10 @@
internal void OnEnd ()
{
+#if !TARGET_J2EE
if (End != null)
End (this, EventArgs.Empty);
+#endif
}
public event EventHandler Start;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.SessionState - patch (code synchronization between Mono and Mainsoft)
Sorry I've sent the old diff - here is a new one - the value changed to
'1024'.
Ilya Kharmatsky wrote:
I agree, good shot Ben!
Attached updated patch.
Thank you,
Ilya.
Ben Maurer wrote:
On Wed, 2005-06-08 at 13:17 +0300, Ilya Kharmatsky wrote:
InProc = 1,
StateServer = 2,
SQLServer = 3
+#if TARGET_J2EE
+ ,J2ee = 4
+#endif
It's probably a bad idea to add such a low enumeration value, as msft
could add a value here.
-- Ben
Index: ChangeLog
===
--- ChangeLog (revision 45568)
+++ ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2005-06-08 Ilya Kharmatsky
+
+* SessionStateMode.cs: Added TARGET_J2EE directive in order
+to provide in J2EE configuration additional mode - J2EE
+* SessionStateModule.cs: Added TARGET_JVM directives in order
+to resolve unsupported in Ghrasshopper "static variables" issue
+(When static variable are stored in general place, instead of
+storing such variables per AppDomain).
+
2005-05-27 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
* RemoteStateServer.cs:
Index: SessionStateMode.cs
===
--- SessionStateMode.cs (revision 45568)
+++ SessionStateMode.cs (working copy)
@@ -35,6 +35,9 @@
InProc = 1,
StateServer = 2,
SQLServer = 3
+#if TARGET_J2EE
+ ,J2ee = 1024
+#endif
}
}
Index: SessionStateModule.cs
===
--- SessionStateModule.cs (revision 45568)
+++ SessionStateModule.cs (working copy)
@@ -42,8 +42,27 @@
internal static readonly string CookieName = "ASPSESSION";
internal static readonly string HeaderName =
"AspFilterSessionId";
+#if !TARGET_J2EE
static SessionConfig config;
static Type handlerType;
+#else
+ static private SessionConfig config {
+ get {
+ return
(SessionConfig)AppDomain.CurrentDomain.GetData("SessionStateModule.config");
+ }
+ set {
+
AppDomain.CurrentDomain.SetData("SessionStateModule.config", value);
+ }
+ }
+ static private Type handlerType {
+ get {
+ return
(Type)AppDomain.CurrentDomain.GetData("SessionStateModule.handlerType");
+ }
+ set {
+
AppDomain.CurrentDomain.SetData("SessionStateModule.handlerType", value);
+ }
+ }
+#endif
ISessionHandler handler;
bool sessionForStaticFiles;
@@ -197,8 +216,10 @@
internal void OnEnd ()
{
+#if !TARGET_J2EE
if (End != null)
End (this, EventArgs.Empty);
+#endif
}
public event EventHandler Start;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] AOT + Embedding = ?
It doesn't look like the embedding runtime is looking for AOT files. When I run mono from the command line I get "Mono-INFO: AOT loaded/failed to load AOT module" messages, but I don't get these when I run the application embedding mono, just messages talking about loading the normal bytecode assemblies. Is there something I can do to get the embedded runtime to look for AOT files? Cheers, Jim. --- Zoltan Varga <[EMAIL PROTECTED]> wrote: > Hi, > > Try running mono with the MONO_LOG_LEVEL env > variable set to 'debug'. > That will show whenever the runtime is able to find > the AOT compiled assemblies > /methods. > > Zoltan > > On 6/8/05, Jim Purbrick <[EMAIL PROTECTED]> > wrote: > > Hi all, > > > > Is there a way to use AOT compilation when > embedding > > mono (or find out if AOT compiled assemblies are > being > > used)? I'm getting a performance hiccup the first > time > > I run methods, which I assume is down to JIT > > compilation, so want to try using AOT compiled > > assemblies to see if that solves the problem. I'm > AOT > > compiling the assemblies and the AOT output is > > available in the same directory as the bytecode > > assemblies, but I'm still getting a performance > > hiccups. > > > > Cheers, > > > > Jim. > > > > > > > > > ___ > > How much free photo storage do you get? Store your > holiday > > snaps for FREE with Yahoo! Photos > http://uk.photos.yahoo.com > > ___ > > 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 > ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] 2 year old working code breaks?
Hello All, I woke this morning to find my code that runs itself in a loop and processes commands as it’s given them. I found it offline, which normally wouldn’t bother me, until I tried to restart it. It goes through its normal sequence before coming to its looped state of wait, and a second or two later the console just says Killed, and it drops back to the shell. Here are the last lines from mono –v Method System.Configuration.ConfigurationData:Load (string) emitted at 0xb55c40e8 to 0xb55c4265 [spider.exe] Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess) emitted at 0xb55c4268 to 0xb55c42e7 [spider.exe] Method System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess) emitted at 0xb55c42e8 to 0xb55c434b [spider.exe] Method System.Xml.XmlTextReader:.ctor (System.IO.Stream) emitted at 0xb55c4350 to 0xb55c4391 [spider.exe] Method (wrapper remoting-invoke-with-check) System.Xml.XmlStreamReader:.ctor (System.IO.Stream) emitted at 0xb55c4398 to 0xb55c43fa [spider.exe] Method System.Xml.XmlStreamReader:.ctor (System.IO.Stream) emitted at 0xb55c4400 to 0xb55c4441 [spider.exe] Method (wrapper remoting-invoke-with-check) System.Xml.XmlInputStream:.ctor (System.IO.Stream) emitted at 0xb55c4448 to 0xb55c44aa [spider.exe] Method (wrapper runtime-invoke) System.Object:runtime_invoke_void (object,intptr,intptr,intptr) emitted at 0xb55c44b0 to 0xb55c451f [spider.exe] Method System.Xml.XmlInputStream:.cctor () emitted at 0xb55c4520 to 0xb55c455c [spider.exe] Method System.Xml.XmlException:.ctor (string) emitted at 0xb55c4560 to 0xb55c4573 [spider.exe] Method System.Xml.XmlInputStream:.ctor (System.IO.Stream) emitted at 0xb55c4578 to 0xb55c459a [spider.exe] Method (wrapper remoting-invoke-with-check) System.Xml.XmlInputStream:Initialize (System.IO.Stream) emitted at 0xb55c45a0 to 0xb55c4602 [spider.exe] Method System.Xml.XmlInputStream:Initialize (System.IO.Stream) emitted at 0xb55c4608 to 0xb55c4b8f [spider.exe] Method (wrapper remoting-invoke-with-check) System.IO.FileStream:RefillBuffer () emitted at 0xb55c4b90 to 0xb55c4bea [spider.exe] Method System.IO.FileStream:RKilled The code seems to run fine if I copy it back to my win32 machine, so I’m not exactly sure what to make of it, and of course my last copy of these code source is extremely out dated, and I’m not sure where my good copies went in the move. Has anyone seen/know how to fix this? Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] AOT + Embedding = ?
Hi, This is due to a problem in out embedding interface. It is now tracked as: http://bugzilla.ximian.com/show_bug.cgi?id=75194 Zoltan On 6/9/05, Jim Purbrick <[EMAIL PROTECTED]> wrote: > It doesn't look like the embedding runtime is looking > for AOT files. When I run mono from the command line I > get "Mono-INFO: AOT loaded/failed to load AOT module" > messages, but I don't get these when I run the > application embedding mono, just messages talking > about loading the normal bytecode assemblies. Is there > something I can do to get the embedded runtime to look > for AOT files? > > Cheers, > > Jim. > > --- Zoltan Varga <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > Try running mono with the MONO_LOG_LEVEL env > > variable set to 'debug'. > > That will show whenever the runtime is able to find > > the AOT compiled assemblies > > /methods. > > > > Zoltan > > > > On 6/8/05, Jim Purbrick <[EMAIL PROTECTED]> > > wrote: > > > Hi all, > > > > > > Is there a way to use AOT compilation when > > embedding > > > mono (or find out if AOT compiled assemblies are > > being > > > used)? I'm getting a performance hiccup the first > > time > > > I run methods, which I assume is down to JIT > > > compilation, so want to try using AOT compiled > > > assemblies to see if that solves the problem. I'm > > AOT > > > compiling the assemblies and the AOT output is > > > available in the same directory as the bytecode > > > assemblies, but I'm still getting a performance > > > hiccups. > > > > > > Cheers, > > > > > > Jim. > > > > > > > > > > > > > > > ___ > > > How much free photo storage do you get? Store your > > holiday > > > snaps for FREE with Yahoo! Photos > > http://uk.photos.yahoo.com > > > ___ > > > 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 > > > > > > > > > ___ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > voicemail http://uk.messenger.yahoo.com > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] 2 year old working code breaks?
Hello All, I woke this morning to find my code that runs itself in a loop and processes commands as it's given them. I found it offline, which normally wouldn't bother me, until I tried to restart it. It goes through its normal sequence before coming to its looped state of wait, and a second or two later the console just says Killed, and it drops back to the shell. Here are the last lines from mono –v Method System.Configuration.ConfigurationData:Load (string) emitted at 0xb55c40e8 to 0xb55c4265 [spider.exe] Method (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess) emitted at 0xb55c4268 to 0xb55c42e7 [spider.exe] Method System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess) emitted at 0xb55c42e8 to 0xb55c434b [spider.exe] Method System.Xml.XmlTextReader:.ctor (System.IO.Stream) emitted at 0xb55c4350 to 0xb55c4391 [spider.exe] Method (wrapper remoting-invoke-with-check) System.Xml.XmlStreamReader:.ctor (System.IO.Stream) emitted at 0xb55c4398 to 0xb55c43fa [spider.exe] Method System.Xml.XmlStreamReader:.ctor (System.IO.Stream) emitted at 0xb55c4400 to 0xb55c4441 [spider.exe] Method (wrapper remoting-invoke-with-check) System.Xml.XmlInputStream:.ctor (System.IO.Stream) emitted at 0xb55c4448 to 0xb55c44aa [spider.exe] Method (wrapper runtime-invoke) System.Object:runtime_invoke_void (object,intptr,intptr,intptr) emitted at 0xb55c44b0 to 0xb55c451f [spider.exe] Method System.Xml.XmlInputStream:.cctor () emitted at 0xb55c4520 to 0xb55c455c [spider.exe] Method System.Xml.XmlException:.ctor (string) emitted at 0xb55c4560 to 0xb55c4573 [spider.exe] Method System.Xml.XmlInputStream:.ctor (System.IO.Stream) emitted at 0xb55c4578 to 0xb55c459a [spider.exe] Method (wrapper remoting-invoke-with-check) System.Xml.XmlInputStream:Initialize (System.IO.Stream) emitted at 0xb55c45a0 to 0xb55c4602 [spider.exe] Method System.Xml.XmlInputStream:Initialize (System.IO.Stream) emitted at 0xb55c4608 to 0xb55c4b8f [spider.exe] Method (wrapper remoting-invoke-with-check) System.IO.FileStream:RefillBuffer () emitted at 0xb55c4b90 to 0xb55c4bea [spider.exe] Method System.IO.FileStream:RKilled The code seems to run fine if I copy it back to my win32 machine, so I'm not exactly sure what to make of it, and of course my last copy of these code source is extremely out dated, and I'm not sure where my good copies went in the move. Has anyone seen/know how to fix this? (it doesn't seem to do this when I run the code as root, but only as a normal user) Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Contributing Mainsoft System.Web test suite
Hi Gonzalo, Vladimir has finished the prototype of the System.Web test suite engine. The same framework will be used to generate the expected xml (html) results and to verify them. We have 2 problematic components that I need your help with: = 1. The SGMLReader XHTML component = 1.a. Has a serious bug which is reproducible in Mainsoft and in mono. The bug: Only one attribute from each tag (that has more than one attributes) processed to the output. 1.b The license does not look promising. We need to decide on an alternative component. I should remind that we previously used the COM version "tidy" (which is just a wrapper on-top of tidy library) and it was pretty immature. I will assign Vladimir to check the htmlagilitypack which contains no license. Maybe we should mail the author [EMAIL PROTECTED] ? http://blogs.msdn.com/smourier/archive/2003/06/04/8265.aspx = 2. The XMLDiff component. = The Microsoft XMLDiffPath component seems to work as expected on GH and on mono. If we will have license (or functional) problems we can always replace it (maybe with XMLUnit). Any progress with Atsushi on having our own XMLDiff? Rafi SDE/T Team Leader -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RafaelMizrahi Sent: Saturday, June 04, 2005 10:30 AM To: [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Subject: RE: [Mono-devel-list] Contributing Mainsoft System.Web test suite Hi Gonzalo, > Mono.WebServer Remember that Mainsoft does not use Mono.WebServer, we use Tomcat or other Application Server, and I prefer that we will choose components that both of us will use. > Don't we need a POST too I rather postpone this to a secondary phase. > We need to lobby Atsushi Atsushi can own the XMLDiff/XMLAssert component. If we want to get things started: * Our tests already written in VB, is this a problem ? * You can start creating the NUnit helper classes. * I will start writing a small "Expected Results Generator" (xml files) * I will do some cleanups in our web tests helper classes. So we can put them in SVN. Rafi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gonzalo Paniagua Javier Sent: Friday, June 03, 2005 2:29 PM To: mono-devel-list@lists.ximian.com Subject: RE: [Mono-devel-list] Contributing Mainsoft System.Web test suite On Fri, 2005-06-03 at 12:55 +0300, RafaelMizrahi wrote: > Hi Gonzalo, > Using NUnit as the harness and the tests as a web application, is indeed one > of the options. Moreover, to avoid the need for running xsp externally, we could just use Mono.WebServer. > > The NUnit (acting as a System.Net client), need to have the following > components: > > * GET a web page (use System.NET) Don't we need a POST too? For example, sometimes we might want to emulate a button pressed... > * Extract the elements which participate in the test (we used DIV with ID > starting with a known prefix (for example TESTxxx)). You don't need the > whole BODY. > * XHTML in order to transform the HTML into a well formed XML. (we used > SGMLReader) > * Customized Clean the XML. To remove elements which can fail the test. For > example, ID attributes that are generated by the server, that can be > different on every GET. > * XMLDiff the result with an expected result generated previously using IIS. > We used Microsoft XMLDiffPatch. We can evaluate the XMLUnit project, and/or > create some sort of XMLAssert. We need to lobby Atsushi and get a tool similar to that one that works with mono }:-). -Gonzalo ___ 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] using GLX with C#
Hi, I've made a sublayer that embed several Mono in several pthread to run C# SPMD program over NUMA. I 've not made yet the communication lib (I just use pipe now to communicate between different Mono). To illustrate my work I need a scientific computation program (I have it) and a graphic porgram... that's where is the pb... I know TAO framework, which is good, but I can't use GLUT to draw openGL primitives from different threads, I need GLX to get rendering context and device context to allow my several Mono (which are in different pthread) draw openGL in a same window. So my question is, is there anybody knows how to use GLX functions in a C# program ??? Thanks a lot, Pierre. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] using GLX with C#
Pierre, I (and others) have made the same request on the mono windows forms mailing list. No answers so far. I started to look into it, but haven't had time lately. If I figure anything out, I'll post it. - Jonathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Brunet Sent: Thursday, June 09, 2005 10:54 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-devel-list] using GLX with C# Hi, I've made a sublayer that embed several Mono in several pthread to run C# SPMD program over NUMA. I 've not made yet the communication lib (I just use pipe now to communicate between different Mono). To illustrate my work I need a scientific computation program (I have it) and a graphic porgram... that's where is the pb... I know TAO framework, which is good, but I can't use GLUT to draw openGL primitives from different threads, I need GLX to get rendering context and device context to allow my several Mono (which are in different pthread) draw openGL in a same window. So my question is, is there anybody knows how to use GLX functions in a C# program ??? Thanks a lot, Pierre. ___ 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-devel-list] [PATCH] TypeBuilder.GetMethod and other updates for .NET 2.0 beta2 API
Dnia środa, 8 czerwca 2005 22:40, Martin Baulig napisał:
> Hello,
>
> I'll commit it tomorrow morning.
>
> Don't worry, we're waiting with the release to get a few more of my
> fixes in, so this'll definitely go in :-)
>
Sorry you had problems merging this patch. It was created against 45614.
Seems like Zoltan was faster in adding some of the similar API:
http://galactus.ximian.com/pipermail/mono-patches/2005-June/059635.html
in 45626
I'm attaching the new patch, against 45700. Hope the will be no more problems
(there are still some more 2.0 API additions there, so more conflicts are
possible).
--
Kamil Skalski
http://nazgul.omega.pl
Index: class/corlib/System/Type.cs
===
--- class/corlib/System/Type.cs (wersja 45700)
+++ class/corlib/System/Type.cs (kopia robocza)
@@ -760,6 +760,22 @@
return GetMethodImpl (name, bindingAttr, binder, callConvention, types, modifiers);
}
+ internal virtual MethodInfo GetMethod (MethodInfo fromNoninstanciated)
+{
+ throw new System.InvalidOperationException ("can only be called in generic type");
+}
+
+ internal virtual ConstructorInfo GetConstructor (ConstructorInfo fromNoninstanciated)
+{
+ throw new System.InvalidOperationException ("can only be called in generic type");
+}
+
+ internal virtual FieldInfo GetField (FieldInfo fromNoninstanciated)
+{
+ throw new System.InvalidOperationException ("can only be called in generic type");
+}
+
+
public MethodInfo[] GetMethods ()
{
return GetMethods (DefaultBindingFlags);
@@ -1110,6 +1126,11 @@
return res;
}
+public Type MakeGenericType (Type[] types)
+{
+ return BindGenericParameters (types);
+}
+
public abstract bool IsGenericParameter {
get;
}
Index: class/corlib/System/ChangeLog
===
--- class/corlib/System/ChangeLog (wersja 45700)
+++ class/corlib/System/ChangeLog (kopia robocza)
@@ -1,3 +1,9 @@
+2005-06-09 Kamil Skalski <[EMAIL PROTECTED]>
+ * Type.cs: Add MakeGenericType method form .NET 2.0 beta 2 API
+
+ * Type.cs MonoType.cs: Add internal virtual Get{Method,Constructor,Field}
+ for obtaining instanciated *Info objects from non-instanciated counterparts
+
2005-06-09 Zoltan Varga <[EMAIL PROTECTED]>
* ModuleHandle RuntimeMethodHandle.cs RuntimeTypeHandle.cs RuntimeFieldHandle.cs RuntimeArgumentHandle.cs: Add missing 2.0 attributes.
Index: class/corlib/System/MonoType.cs
===
--- class/corlib/System/MonoType.cs (wersja 45700)
+++ class/corlib/System/MonoType.cs (kopia robocza)
@@ -224,6 +224,31 @@
}
[MethodImplAttribute(MethodImplOptions.InternalCall)]
+ extern MethodInfo GetCorrespondingInflatedMethod (IntPtr generic);
+
+ [MethodImplAttribute(MethodImplOptions.InternalCall)]
+ extern ConstructorInfo GetCorrespondingInflatedConstructor (IntPtr generic);
+
+ [MethodImplAttribute(MethodImplOptions.InternalCall)]
+ extern FieldInfo GetCorrespondingInflatedField (IntPtr generic);
+
+
+ internal override MethodInfo GetMethod (MethodInfo fromNoninstanciated)
+{
+return GetCorrespondingInflatedMethod (fromNoninstanciated.MethodHandle.Value);
+}
+
+ internal override ConstructorInfo GetConstructor (ConstructorInfo fromNoninstanciated)
+ {
+return GetCorrespondingInflatedConstructor (fromNoninstanciated.MethodHandle.Value);
+ }
+
+ internal override FieldInfo GetField (FieldInfo fromNoninstanciated)
+ {
+return GetCorrespondingInflatedField (fromNoninstanciated.FieldHandle.Value);
+ }
+
+ [MethodImplAttribute(MethodImplOptions.InternalCall)]
public extern override Type GetNestedType (string name, BindingFlags bindingAttr);
[MethodImplAttribute(MethodImplOptions.InternalCall)]
Index: class/corlib/System.Reflection.Emit/FieldBuilder.cs
===
--- class/corlib/System.Reflection.Emit/FieldBuilder.cs (wersja 45700)
+++ class/corlib/System.Reflection.Emit/FieldBuilder.cs (kopia robocza)
@@ -80,7 +80,7 @@
public override RuntimeFieldHandle FieldHandle {
get {
-throw CreateNotSupportedException ();
+return handle;
}
}
Index: class/corlib/System.Reflection.Emit/ChangeLog
===
--- class/corlib/System.Reflection.Emit/ChangeLog (wersja 45700)
+++ class/corlib/System.Reflection.Emit/ChangeLog (kopia robocza)
@@ -1,3 +1,11 @@
+2005-06-09 Kamil Skalski <[EMAIL PROTECTED]>
+ * ConstructorBuilder.cs FieldBuilders.cs MethodBuilder.cs: Return
+ RuntimeHandles when requested
+
+ * TypeBuilder.cs: Add static Get{Method,Constructor,Field} methods
+ from .NET 2.0 beta 2 API for obta
[Mono-devel-list] Analysis of W3C regressions
Hello.
I started to analyze the list of regressions that are found with W3C
testsuite. They are listed in fixme.lst file in svn.
I found that undoing revision 41840 fixes 20 regressions from the list
(although breaks one test).
I attach here the patch that you can apply to the latest System.XML to
fix those 20 regressions. Please notice, it's not my patch, it's just a
revert of a part of revision 41840. I made it so it's easy to verify
these results.
Before the patch there are 0 regressions, and 10 fixes, after the
attached patch there is 1 regressions and 30 fixes.
Please tell me what you think.
Cheers,
Andrew.
Index: System.Xml/DTDValidatingReader.cs
===
--- System.Xml/DTDValidatingReader.cs (revision 45697)
+++ System.Xml/DTDValidatingReader.cs (working copy)
@@ -114,7 +114,7 @@
bool isSignificantWhitespace;
bool isWhitespace;
bool isText;
- bool dontResetTextType;
+ bool nextMaybeSignificantWhitespace;
// This field is used to get properties and to raise events.
XmlValidatingReader validatingReader;
@@ -370,7 +370,7 @@
isWhitespace = false;
isSignificantWhitespace = false;
isText = false;
- dontResetTextType = false;
+nextMaybeSignificantWhitespace = false;
bool b = ReadContent () || currentTextValue != null;
if (!b && this.missingIDReferences.Count > 0) {
@@ -432,6 +432,7 @@
return false;
}
+bool dontResetTextType = false;
DTDElementDeclaration elem = null;
switch (reader.NodeType) {
@@ -574,7 +575,7 @@
constructingTextValue = null;
return true;
}
- break;
+goto case XmlNodeType.Text;
case XmlNodeType.SignificantWhitespace:
if (!isText)
isSignificantWhitespace = true;
@@ -604,9 +605,19 @@
}
break;
case XmlNodeType.Whitespace:
+if (nextMaybeSignificantWhitespace) {
+currentTextValue = reader.Value;
+nextMaybeSignificantWhitespace = false;
+goto case
XmlNodeType.SignificantWhitespace;
+}
if (!isText && !isSignificantWhitespace)
isWhitespace = true;
- goto case XmlNodeType.Text;
+if (entityReaderStack.Count > 0 &&
validatingReader.EntityHandling == EntityHandling.ExpandEntities) {
+constructingTextValue += reader.Value;
+return ReadContent ();
+}
+ValidateWhitespaceNode ();
+break;
case XmlNodeType.EntityReference:
if (validatingReader.EntityHandling ==
EntityHandling.ExpandEntities) {
ResolveEntity ();
@@ -614,9 +625,6 @@
}
break;
}
- if (isWhitespace)
- ValidateWhitespaceNode ();
- currentTextValue = constructingTextValue;
constructingTextValue = null;
MoveToElement ();
return true;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [GENERICS] a problem with binding generic types
Hello,
During making Nemerle work with Mono generics, I've stumbled across
something that seems to be a bug in Mono runtime.
Inside:
mono_reflection_bind_generic_parameters (MonoReflectionType *type,
int type_argc, MonoType **types)
there is a call:
the_parent = mono_reflection_bind_generic_parameters (parent,
type_argc, types);
Which doesn't seem right. That is if you have a class:
class Foo : Bar { }
then you call mono_reflection_bind_generic_parameters(Foo, 1, [A]),
but mono_reflection_bind_generic_parameters(Bar, 1, [A]) is not right
because there is not enough type parameters.
I may be wrong -- it may be bug somewhere else in my code, I just want to
make sure about it.
--
Michal Moskal,
http://nemerle.org/~malekith/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.Mail - patch (code synchronization between Mono and Mainsoft)
Hi Ilya,
It's worth to wrap the
"java.net.InetAddress address = java.net.InetAddress.getLocalHost();"
with an appropriate try/catch/throw, otherwise a Java exception would be
thrown to the user.
Regards,
Konstantin Triger
Ilya Kharmatsky wrote:
Please review the patch.
Thanks,
Ilya.
Index: ChangeLog
===
--- ChangeLog (revision 45568)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2005-06-08 Ilya Kharmatsky
+
+* SmtpMail.cs: Added TARGET_JVM directive in Send method,
+where we will use in J2EE configuration the "native" java
+support for obtaining the network address of localhost.
+
2005-04-20 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
* SmtpClient.cs:
Index: SmtpMail.cs
===
--- SmtpMail.cs (revision 45614)
+++ SmtpMail.cs (working copy)
@@ -64,7 +64,17 @@
// access to properties and to add some functionality
MailMessageWrapper messageWrapper = new
MailMessageWrapper( message );
+#if TARGET_JVM
+ string currentSmtpServer = smtpServer;
+ if (currentSmtpServer == "localhost")
+ {
+ java.net.InetAddress address =
java.net.InetAddress.getLocalHost();
+ currentSmtpServer = address.getHostAddress();
+ }
+ SmtpClient smtp = new SmtpClient (currentSmtpServer);
+#else
SmtpClient smtp = new SmtpClient (smtpServer);
+#endif
smtp.Send (messageWrapper);
___
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] [Patch] Images loaded with Reflection Only Assemblies
Hey,
Currently, when loading a reflection only assembly, and then a normal
assembly is also loaded, they share their images, which of course is not
correct.
With the attached patch separated images are loaded.
Carlos.
Index: appdomain.c
===
--- appdomain.c (revisión: 45717)
+++ appdomain.c (copia de trabajo)
@@ -907,7 +907,7 @@
MonoDomain *domain = ad->data;
MonoImageOpenStatus status;
guint32 raw_assembly_len = mono_array_length (raw_assembly);
- MonoImage *image = mono_image_open_from_data (mono_array_addr (raw_assembly, gchar, 0), raw_assembly_len, TRUE, NULL);
+ MonoImage *image = mono_image_open_from_data_full (mono_array_addr (raw_assembly, gchar, 0), raw_assembly_len, TRUE, NULL, refonly);
if (raw_symbol_store)
mono_raise_exception (mono_get_exception_not_implemented ("LoadAssemblyRaw: Raw Symbol Store not Implemented"));
Index: assembly.c
===
--- assembly.c (revisión: 45717)
+++ assembly.c (copia de trabajo)
@@ -787,7 +787,7 @@
* returns NULL
*/
static MonoImage *
-mono_assembly_open_from_bundle (const char *filename, MonoImageOpenStatus *status)
+mono_assembly_open_from_bundle (const char *filename, MonoImageOpenStatus *status, gboolean refonly)
{
int i;
char *name = g_path_get_basename (filename);
@@ -800,7 +800,7 @@
EnterCriticalSection (&assemblies_mutex);
for (i = 0; !image && bundles [i]; ++i) {
if (strcmp (bundles [i]->name, name) == 0) {
- image = mono_image_open_from_data ((char*)bundles [i]->data, bundles [i]->size, FALSE, status);
+ image = mono_image_open_from_data_full ((char*)bundles [i]->data, bundles [i]->size, FALSE, status, refonly);
break;
}
}
@@ -814,18 +814,18 @@
}
static MonoImage*
-do_mono_assembly_open (const char *filename, MonoImageOpenStatus *status)
+do_mono_assembly_open (const char *filename, MonoImageOpenStatus *status, gboolean refonly)
{
MonoImage *image = NULL;
if (bundles != NULL){
- image = mono_assembly_open_from_bundle (filename, status);
+ image = mono_assembly_open_from_bundle (filename, status, refonly);
if (image != NULL)
return image;
}
EnterCriticalSection (&assemblies_mutex);
- image = mono_image_open (filename, status);
+ image = mono_image_open_full (filename, status, refonly);
LeaveCriticalSection (&assemblies_mutex);
return image;
@@ -876,7 +876,7 @@
mono_trace (G_LOG_LEVEL_INFO, MONO_TRACE_ASSEMBLY,
"Assembly Loader probing location: '%s'.", filename);
- image = do_mono_assembly_open (fname, status);
+ image = do_mono_assembly_open (fname, status, refonly);
if (!image){
*status = MONO_IMAGE_ERROR_ERRNO;
Index: image.c
===
--- image.c (revisión: 45717)
+++ image.c (copia de trabajo)
@@ -34,6 +34,8 @@
*/
static GHashTable *loaded_images_hash;
static GHashTable *loaded_images_guid_hash;
+static GHashTable *loaded_images_refonly_hash;
+static GHashTable *loaded_images_refonly_guid_hash;
static CRITICAL_SECTION images_mutex;
@@ -131,6 +133,8 @@
loaded_images_hash = g_hash_table_new (g_str_hash, g_str_equal);
loaded_images_guid_hash = g_hash_table_new (g_str_hash, g_str_equal);
+ loaded_images_refonly_hash = g_hash_table_new (g_str_hash, g_str_equal);
+ loaded_images_refonly_guid_hash = g_hash_table_new (g_str_hash, g_str_equal);
}
/**
@@ -466,7 +470,7 @@
mono_metadata_decode_row (t, i, cols, MONO_MODULEREF_SIZE);
name = mono_metadata_string_heap (image, cols [MONO_MODULEREF_NAME]);
module_ref = g_build_filename (base_dir, name, NULL);
- image->modules [i] = mono_image_open (module_ref, status);
+ image->modules [i] = mono_image_open_full (module_ref, status, refonly, image->refonly);
if (image->modules [i]) {
/* g_print ("loaded module %s from %s (%p)\n", module_ref, image->name, image->assembly); */
}
@@ -551,11 +555,21 @@
}
static void
-build_guid_table (void)
+register_guid_refonly (gpointer key, gpointer value, gpointer user_data)
{
- g_hash_table_foreach (loaded_images_hash, register_guid, NULL);
+ MonoImage *image = (MonoImage*)value;
+
+ if (!g_hash_table_lookup (loaded_images_refonly_guid_hash, image))
+ g_hash_table_insert (loaded_images_refonly_guid_hash, image->guid, image);
}
+static void
+build_guid_table (gboolean refonly)
+{
+ GHashTable *loaded_images = refonly ? loaded_images_refonly_hash : loaded_images_hash;
+ g_hash_table_foreach (loaded_images, refonly ? register_guid_refonly : register_guid, NULL);
+}
+
void
mono_image_init (MonoImage *image)
{
@@ -761,7 +775,7 @@
static MonoImage *
do_mono_image_open (const char *fname, MonoImageOpenStatus *status,
- gboolean care_about_cli)
+ gboolean care_about_cli, gboolean refonly)
{
MonoCLIImageInfo *iinfo;
MonoImage *image;
@@ -788,39 +802,56 @@
iinfo = g_new0 (MonoCLIImageInfo, 1);
image->image_info = iinfo;
image->name = canonicalize_p
Re: [Mono-devel-list] System.Web/System.Web.Mail - patch (code synchronization between Mono and Mainsoft)
In this case there is no "appropriate" throw. May
be I'm wrong, but
in .Net code there is no exception in this method.
Konstantin Triger wrote:
Hi Ilya,
It's worth to wrap the
"java.net.InetAddress address = java.net.InetAddress.getLocalHost();"
with an appropriate try/catch/throw, otherwise a Java exception would
be thrown to the user.
Regards,
Konstantin Triger
Ilya Kharmatsky wrote:
Please review the patch.
Thanks,
Ilya.
Index: ChangeLog
===
--- ChangeLog (revision 45568)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2005-06-08 Ilya Kharmatsky
+
+ * SmtpMail.cs: Added TARGET_JVM directive in Send method,
+ where we will use in J2EE configuration the "native" java
+ support for obtaining the network address of localhost.
+ 2005-04-20 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
* SmtpClient.cs:
Index: SmtpMail.cs
===
--- SmtpMail.cs (revision 45614)
+++ SmtpMail.cs (working copy)
@@ -64,7 +64,17 @@
// access to properties and to add some functionality
MailMessageWrapper messageWrapper = new MailMessageWrapper(
message );
+#if TARGET_JVM
+ string currentSmtpServer = smtpServer;
+ if (currentSmtpServer == "localhost")
+ {
+ java.net.InetAddress address =
java.net.InetAddress.getLocalHost();
+ currentSmtpServer = address.getHostAddress();
+ }
+ SmtpClient smtp = new SmtpClient (currentSmtpServer);
+#else
SmtpClient smtp = new SmtpClient (smtpServer);
+#endif
smtp.Send (messageWrapper);
___
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-devel-list] System.Web/System.Web - patch (code synchronization between Mono and Mainsoft)
On Wed, 2005-06-08 at 13:11 +0300, Ilya Kharmatsky wrote: > Hi, All! > > Please review updated version of patch. The patch is fine. As long as the new code is inside TARGET_JVM, feel free to commit all the patches you want. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.Mail - patch (code synchronization between Mono and Mainsoft)
On Fri, 2005-06-10 at 00:31 +0300, Ilya Kharmatsky wrote: > In this case there is no "appropriate" throw. May be I'm wrong, but > in .Net code there is no exception in this method. Commit, commit. I'm fine with all these patches that are for synchronizing mainsoft and mono libraries, as the new code is inside #if/#endif. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.UI - patch (code synchronization between Mono and Mainsoft)
On Wed, 2005-06-08 at 14:11 +0300, Ilya Kharmatsky wrote: > Please review the patch. > > BTW, in HtmlTextWriter.cs we changed internal structs (e.g. > RenderStyle) to be the classes > and not structs - this in order to resolve heavy performance problem > in our implementation > of initialization of arrays of structs. May be the better idea is to > change also original mono > code - since in this case we can avoid additional "splitting" of code > between standard and > J2EE configuration. I think impact of this won't be too high - from > perspective of memory > consumption and performance. RenderAttribute, TagInformation and RenderStyle might be ok as classes. As you say, this is no big deal. Feel free to make those classes if nothing breaks. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.UI - patch (code synchronization between Mono and Mainsoft)
On Thu, 2005-06-09 at 19:05 -0400, Gonzalo Paniagua Javier wrote: > On Wed, 2005-06-08 at 14:11 +0300, Ilya Kharmatsky wrote: > > Please review the patch. > > > > BTW, in HtmlTextWriter.cs we changed internal structs (e.g. > > RenderStyle) to be the classes > > and not structs - this in order to resolve heavy performance problem > > in our implementation > > of initialization of arrays of structs. May be the better idea is to > > change also original mono > > code - since in this case we can avoid additional "splitting" of code > > between standard and > > J2EE configuration. I think impact of this won't be too high - from > > perspective of memory > > consumption and performance. > > RenderAttribute, TagInformation and RenderStyle might be ok as classes. > As you say, this is no big deal. Feel free to make those classes if > nothing breaks. What exactly do you guys do when initing an array of structs that is so slow? In this case, chances are, performance won't suffer that much. It does make our GC do more work than it needs to (and it is already pretty heavy on stuff). However, there are cases where using arrays of structs will give us a large benefit in C#. So it would make sense to figure out what is happening, rather than to shove it under the rug. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [MonoBURG] Patch proposal.
(This message was originally sent to Miguel de Icaza) As you may remember, the LRDE (http://www.lrde.epita.fr) planed to use monoburg for its Tiger Compiler (http://tiger.lrde.epita.fr). As we have some specific needs, we modified it a little bit. Clément Vasseur and Benoit Perrot told me that you're interested in using our patches in the Mono project. The work is now advanced and I was wondering if you're still interested in our modifications. Our part of the ChangeLog is attached. Please note that we kept a full back compatibility. We plan to make further changes in monoburg. Regards, 2005-06-09 Michael Cadilhac <[EMAIL PROTECTED]> * monoburg.c: Make the `usage' message more verbose. 2005-06-09 Michael Cadilhac <[EMAIL PROTECTED]> * monoburg.c: Add a `-n' option to precise the top #define used in the generated header. 2005-06-09 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y, * monoburg.c, * monoburg.h: Rename "warn_cpp" function to "warn_cxx". 2005-06-09 Michael Cadilhac <[EMAIL PROTECTED]> * monoburg.c: Output MB_TERM* and MB_NTERM* in enums `MBTerms' and `MBNTerms'. 2005-06-09 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y: Do not output "#line" directives when reading rules. 2005-06-09 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y: Search through `include_dirs' paths for file to include. * monoburg.h, * monoburg.c: Add a `-I' option to precise include directories. 2005-06-09 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y: Add `#line' directives output on `%include', CODE and in `yyparsetail'. * monoburg.c: Add `#line' directives output just before the call to `yyparse'. 2005-06-04 Michael Cadilhac <[EMAIL PROTECTED]> * config.h.in: New. * configure.ac: Output PACKAGE infos in config.h. * monoburg.c: Add `-v' and `--version' options. * Makefile.am: Fix distribution and cleaning rules. * monoburg.h: Include `config.h'. 2005-06-04 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y: Add a `%include' directive which includes files verbatim. Syntax is: %include filename without double quote or anything. This directive could be used anywhere. * parser.y (yyerror): Enhanceverbosity on error message accordingly. * monoburg.h: Add the info about included file storage. * monoburg.c: Update accordingly use of `inputfd'. 2005-06-04 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y: Add a `%namespace' directive which makes monoburg output functions in a namespace. This directive could produce nested namespaces. Syntax is: %namespace namespace1_name %namespace namespace2_name without double quote or anything. This directive can only be used in the `rule' part of the burg file. The user is warned that the code produced will only be compilable with a C++ compiler. * parser.y (yylex): Remove a warning when comparing a `sizeof' with an int. * monoburg.c, * monoburg.h: Add `%namespace' handling. 2005-06-04 Michael Cadilhac <[EMAIL PROTECTED]> * monoburg.c: Add a `--with-references' option which makes monoburg to produce `mono_burg_emit_*' functions that takes tree as a `MBTREE&'. The user is warned that the code produced will only be compilable with a C++ compiler. * monoburg.c (emit_emmitter_func): Add fake use of arguments of `emit' functions produced to avoid `unused parameter' warning when compiling output. 2005-06-04 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y: Add an optional `;' at the end of an empty rule, in the style of yacc(1). 2005-06-04 Michael Cadilhac <[EMAIL PROTECTED]> * monoburg.c: Add a `--without-exported-symbols' option which makes monoburg avoid defining external symbols as much as possible. Remove the weaker `--without-debug-tables'. 2005-06-04 Michael Cadilhac <[EMAIL PROTECTED]> * parser.y: Update according to mono-project repository. * monoburg.vcproj: New. Add according to mono-project repository. 2005-05-26 Sebastien Pouliot <[EMAIL PROTECTED]> * monoburg.vcproj: Project file for monobug. 2005-01-18 Zoltan Varga <[EMAIL PROTECTED]> * monoburg.y (yyparsetail): Handle the case when the burg file does not end with an empty line. 2004-11-07 Benoit Perrot <[EMAIL PROTECTED]> * monoburg.c (emit_header): Extract includes emission. 2004-11-07 Benoit Perrot <[EMAIL PROTECTED]> * monoburg.c (emit_state): Do not forward define MBState type. 2004-11-07
