Re: [Mono-dev] Ideas for Mono on Windows

[Eyal Alaluf]

Hi, all.

I'd like to chip in our Grasshopper experience with Mono. We found it always 
extremely useful and productive to be able to build the Mono class libraries 
from Visual Studio (in the Grasshopper version).
To me it would seem that the 1.1 profile is much less important then 2.0 and 
above. Also I find that the class libraries have precedence over the runtime - 
so (for instance) any investment in Express C++ should come last. Also, when 
effort wil be invested in building without requiring cygwin installed - I would 
first do it for the class libraries and only afterwards the Mono runtime build.

Eyal.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel de Icaza
Sent: Wednesday, December 10, 2008 2:44 AM
To: Atsushi Eno
Cc: mono-devel
Subject: Re: [Mono-dev] Ideas for Mono on Windows

Hello,

Let us please not use stop energy from preventing this incredibly
important project from moving ahead.

The Mono Build on Visual Studio will not be able to solve every problem
ever, but for that we already have the Cygwin fallback. 

This discussion is about how we can gradually improve things for
developers that are mostly used by Visual Studio developers:

> First of all I'm not aware of any of "concensus on #monodev". Actually
> I find almost no reason to use VS to build our classlibs. The classlib
> build is not much slower on cygwin. The remarkable difference would
> happen only on the runtime build.

This was a consensus reached by those of us that were present at the
time.   

The goal is to make it simpler for contributors that are interested in
Mono to contribute effectively.The reality is that setting up cygwin
is a painful process, and it is not always reliable and requires
contributors to be familiar with the Unix toolchain.

The gist of the discussion in #monodev was to achieve the same level of
ease of use as Google Chrome has: they shipped with Visual Studio
solutions and you can go from source code checkout to running Chrome
following the following steps:

* Open Solution File.
* Hit F5

That is it.A fully working Chrome pops up in your screen after
this. 

So the goal is to come to this exact point: having a fully working Mono,
have an option to run its test suites, build programs against this Mono
and so on from Visual Studio with a single keystroke without requiring
people to learn any Unixisms.

We need to get there one step at a time, baby steps.  First being able
to build a runtime and the class libraries, then we will do the full
profiles, then we can even think about integrating this with our Visual
Studio plugin and so on.

> VS integration has another problem. You cannot really expect VS non-
> express versions installed and then there is no way to run NUnit tests
> (no addins are allowed in Express versions). It can never be a first
> citizen build environment.

For the F5 experience people would need to have Visual Studio
Professional installed as this would build runtime, support libraries
and class libraries.

For express users we could probably partition the problem: runtime built
with Express C++ and class libraries with Express C#.

> As I stated earlier, I don't care much about it as long as cygwin build
> is kept though. The minor issue I am afraid is that those VS users are
> likely to ignore our Coding Guidelines.

They still need to get their patch reviewed, and we can publish a set of
configuration settings for Visual Studio that follow the Mono Coding
Guidelines.   

I know that this is possible for per-user settings, but I am not sure if
there is a way of distributing these. 

Miguel.

> 
> Atsushi Eno
> 
> Jonathan Chambers wrote:
> > Hello,
> > 
> >   I broke down the 'Mono on Windows' topic into two distinct 
> > approaches. I have mainly been working on the second approach as it 
> > seemed to be easier and provide more value.
> > 
> > The first approach is to provide a way to build mono on windows without 
> > cygwin installed. This approach provides uses no MS tools and provides 
> > no VS integration for the class libraries. The runtime would still be 
> > built with MSVC at this point in the plan. It's simply a way for Windows 
> > developers to quickly build mono on windows. It should be much faster 
> > than the current cygwin based build and require let setup.
> > 
> > The second approach (the one I have been working on) was to provide a 
> > 'prepare' tool to generate csproj files for all the class libs. I also 
> > generate a solution containing all the projects. The user can then build 
> > all the mono class libraries (and unit tests) with one click (it's also 
> > per profile 1.1, 2.0, 3.5).
> > 
> > So as for an update to the second approach. I have a rudimentary 
> > Makefile parser and am using it to generate csproj files for the class 
> > libraries. I have run into a few problems/issues:
> > 
> > 1. The conscensus on #monodev was that the build could use the MS 
> > compiler

Re: [Mono-dev] OracleDataReader problem with too many rows

[Eyal Alaluf]

Hi.

Are you using DataSets and DataTables for maintaining the data? Is it
possible that they are the bottle-neck rather than reading the data from
the oracle Database? You may check that easily by simply using a
DataReader and dumping the data directly to a file instead of using
DataTables.
DataSets/Tables are complex data structures and the current
implementation may well have a problem with hosting 100K rows
effectively.

Eyal.

-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of ygozudeli
Sent: Tuesday, December 16, 2008 2:49 PM
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] OracleDataReader problem with too many rows


Dear Mono Developers,

First of all, I'm happy with your project. Thanks for your great
project. 


I'm using Mono(32 bit) on Solaris  server with AMD processors. There is
a
project to dump Oracle rows into HTML file.

I'm Using System.Data.Oracle library, and a stored procedure which
returns
rows via ref cursor.

if the rows are less than 10.000 performance is acceptable.

if the rows are about 100.000(I'm of course separating results to
multiple
html files)
but  performance is decreasing row by row after 10.000 and by 100.000
it's
about to zero.


But I did the same test on .NET and the performance is linear and so
good.

And also, I've made several tests to isolate the problem. It's all about
Reading data

 
Questions:
1. Do you have any suggestion- detailed configuration.. etc?
2. Is there any chance  to use Oracle.DataAccess.Client library on Mono?



-- 
View this message in context:
http://www.nabble.com/OracleDataReader-problem-with-too-many-rows-tp2102
9827p21029827.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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] New Mono API status pages.

[Eyal Alaluf]

Hi, Miguel.

I like the visibility this page provides into how close Mono is to the
target .Net platform in the various configurations.
I am missing two things - I'd like to know how many symbols are in the
.Net assembly (to put things in the right perspective), and for some
reason in my browser (IE 7, white foreground, black background) I see
only the numbers and only the tooltip says what they mean. It looks like
this:
 mscorlib.dll
 47
 20
 9
 494
 419
I'd think that arranging it in a table or giving titles will make this
much more readable and easy to use.

Thanks, Eyal.

-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Miguel de
Icaza
Sent: Friday, April 10, 2009 1:48 AM
To: mono-devel-list
Subject: [Mono-dev] New Mono API status pages.

Hello folks,

We have updated the Mono status pages to be both faster and provide
now two levels of detail:

http://www.go-mono.com/status

The default view mode will remove many of the missing attributes
that do not apply to Mono (for example, DebuggerVisibility attributes or
bits that are not supported in Mono).

The new status pages should be more useful for developers
contributing code to Mono.



___
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] [PATCH] Less sharing between AppDomains

[Eyal Alaluf]

Isn't the thread instance specific to the app-domain? Are there cases where one 
thread instance belongs to several different app-domains?
If not, then it's not necessary to move the NumberFormatter out of the thread 
instance. It was put there to improve performance of the numeric types ToString 
APIs (since it's such a low-level API a thread specific lookup has a real 
impact on the performance).

Eyal.

-Original Message-
From: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Mark Probst
Sent: Friday, April 10, 2009 6:44 PM
To: Paolo Molaro
Cc: mono-devel
Subject: [Mono-dev] [PATCH] Less sharing between AppDomains

Hi,

The first patch moves the NumberFormatter out of Thread.  As it is now, the 
NumberFormatter is shared between AppDomains.

The second patch makes sure that an array obtained in another AppDomain is not 
retained in the calling domain but copied.

Mark
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] New Mono API status pages.

[Eyal Alaluf]

Thanks, it does look a lot better.

-Original Message-
From: Gonzalo Paniagua Javier [mailto:gonzalo.m...@gmail.com] 
Sent: Friday, April 10, 2009 10:31 PM
To: Eyal Alaluf
Cc: Miguel de Icaza; mono-devel-list
Subject: Re: [Mono-dev] New Mono API status pages.

On Fri, 2009-04-10 at 07:44 -0700, Eyal Alaluf wrote:
> Hi, Miguel.
> 
> I like the visibility this page provides into how close Mono is to the
> target .Net platform in the various configurations.
> I am missing two things - I'd like to know how many symbols are in the
> .Net assembly (to put things in the right perspective), and for some
> reason in my browser (IE 7, white foreground, black background) I see
> only the numbers and only the tooltip says what they mean. It looks
like
> this:
>  mscorlib.dll
>  47
>  20
>  9
>  494
>  419
> I'd think that arranging it in a table or giving titles will make this
> much more readable and easy to use.

It should work fine for IE7 now. Thanks.

About the count... We count anything from an enum field to a class as
one item. For example, if there's a property with a get and set missing,
that counts as 3 missing items (property and 2 methods). For the total
count to make sense we would have to display totals per item type
otherwise we would be giving the same 'weight' to a missing enum value
and a missing .ctor...

-Gonzalo


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Less sharing between AppDomains

[Eyal Alaluf]

It would seem to me that if one invokes an object from another
app-domain using the same OS thread, that the current thread should be
switched as well. Otherwise, other problematic scenarios like using an
incorrect culture info, incorrect IPrincipal, etc.

-Original Message-
From: Mark Probst [mailto:mark.pro...@gmail.com] 
Sent: Friday, April 10, 2009 7:47 PM
To: Eyal Alaluf
Cc: Paolo Molaro; mono-devel
Subject: Re: [Mono-dev] [PATCH] Less sharing between AppDomains

On Fri, Apr 10, 2009 at 6:14 PM, Eyal Alaluf  wrote:
> Isn't the thread instance specific to the app-domain?

No.

> Are there cases where one thread instance belongs to several different
app-domains?

A thread instance only belongs to one app-domain, but another
app-domain can be active in that thread.  For example, in thread A,
belonging to app-domain X, a proxy for an object in app-domain Y might
be invoked, and that method might, while Y is active, cause a
NumberFormatter to be put into thread A's instance, which is a bug.

Mark
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Hacking mono to make it more deterministic

[Eyal Alaluf]

Hi, Lucas.

You might consider creating a version of Hashtable and Dictionary with
an iterator that depends on the order on which the elements are
introduced (and not upon the hash value of the elements). This will
introduce some overhead in performance and memory (maintaining a doubly
linked list of nodes) but will give you the determinism you seek.

Eyal.

-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Lucas
Meijer
Sent: Monday, August 24, 2009 4:13 PM
To: 'mono-devel-list'
Subject: [Mono-dev] Hacking mono to make it more deterministic

Hey,

At Unity we have this internal testing system where we

1) play a game, and record all inputs
2) can replay that game, based on the recorded inputs
3) whenever we do a checkin on our sourcecode, we run all games in the 
testing setup against this new unity build, by making screenshots every 
5 seconds, and comparing those to the previous run.

This has proven to be very useful, as it finds regressions in our users 
games that we had not anticipated when committing a certain change to 
the unity codebase.

Currently, not all games are playing back deterministically on a single 
unity build. We don't think we'll ever reach full deterministicality (is

that a word?) for 100% of our games, but the higher we get the number, 
the better we like it.

In order to do this, we mock out things like System.Random, 
DateTime.Now, to return the recorded values.

A frequent case where games fail to run identically is when our users 
iterate over a dictionary which has a custom type as its key. Since the 
dictionary uses GetHashCode() internally, and Object.GetHashCode() is 
based on the memory address of the object, it means that the order in 
which the KeyValuePair's get returned can differ per run.

Naturally our users shouldn't be doing this. But they do, as they don't 
realize that consistent ordering of iterating over a dictionary isn't 
guaranteed. it just works most of the time so most people don't notice.
I didn't realize this myself untill I started investigating this issue
:)

I'm looking for advice on what would be the best solution to this.

So far the best idea I've came up with is to make mono_object_hash just 
return 0. That probably has some severe performance implications, but we

can live with those. I'm hoping this will only make things go a lot 
slower, but wanted to ask this list:

- if I should expect other problems than slowdown
- if you can think of a better/different way to make our users code 
deterministic

Thanks, Lucas
___
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] [PATCH] Fix Roles.IsUserInRole and enhance WebTestFramework

[Eyal Alaluf]

Hi, Tiaan.

It seems to me you'd want to use 'string.IsNullOrEmpty(username)'
instead of '(username != null && username.Length <= 0)'

Eyal.

-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Tiaan
Geldenhuys
Sent: Thursday, February 11, 2010 11:17 AM
To: mono-devel-list@lists.ximian.com
Cc: mhabers...@novell.com
Subject: [Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance
WebTestFramework

The attached patch is a fix for System.Web.Security.Roles.IsUserInRole
to prevent ASP.NET MVC errors like the one shown at the bottom, which
happens when a user hasn't logged on and requests public pages with
sections that are dynamically removed using role-based
access-restrictions.  It now behaves more like .NET that does not throw
an exception.

Writing a test for this fix was a bit of a challenge -- it's no wonder
there is not any working test for the Roles class yet.  :)  To address
this, the MonoTests.SystemWeb.Framework.WebTest class was updated
slightly to make it possible to write self-contained tests for cases
where you might want more control over the resources that are copied to
your hosted web application, such as when creating Web.config files
dynamically.  The test for the current fix also serves as an example of
how this can be done.  If these changes are approved, one can expand on
this for all the other Roles methods.

Please review and commit.

Thank you,
Tiaan.

NOTE: The patch files can be used without changes on both trunk and the
2.6 branch.

---

[System.Web.HttpUnhandledException]: Exception of type
'System.Web.HttpUnhandledException' was thrown.
  at System.Web.UI.Page.ProcessException (System.Exception e) [0x0]
in :0
  at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
[0x0] in :0
  at System.Web.HttpApplication+c__Iterator5.MoveNext ()
[0x0] in :0
  at System.Web.HttpApplication.Tick () [0x0] in :0
[System.Web.HttpUnhandledException]: Exception of type
'System.Web.HttpUnhandledException' was thrown.
  at System.Web.UI.Page.ProcessException (System.Exception e) [0x0]
in :0
  at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
[0x0] in :0
  at System.Web.Mvc.ViewPage.RenderView (System.Web.Mvc.ViewContext
viewContext) [0x0] in :0
  at System.Web.Mvc.WebFormView.RenderViewPage
(System.Web.Mvc.ViewContext context, System.Web.Mvc.ViewPage page)
[0x0] in :0
  at System.Web.Mvc.WebFormView.Render (System.Web.Mvc.ViewContext
viewContext, System.IO.TextWriter writer) [0x0] in :0
  at System.Web.Mvc.ViewResultBase.ExecuteResult
(System.Web.Mvc.ControllerContext context) [0x0] in :0

  at System.Web.Mvc.ControllerActionInvoker.InvokeActionResult
(System.Web.Mvc.ControllerContext controllerContext,
System.Web.Mvc.ActionResult actionResult) [0x0] in :0
  at
System.Web.Mvc.ControllerActionInvoker+c_
_Ano
nStoreyE.<>m__11 () [0x0] in :0
  at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter
(IResultFilter filter, System.Web.Mvc.ResultExecutingContext preContext,
System.Func`1 continuation) [0x0] in :0
[System.ArgumentException]: Username cannot be empty.
  at SomeRoleProvider.IsUserInRole (System.String username,
System.String
roleName) [0x0] in :0
  at System.Web.Security.Roles.IsUserInRole (System.String rolename)
[0x0] in :0
  at ASP.views_shared_site_master.__RenderTree
(System.Web.UI.HtmlTextWriter __output, System.Web.UI.Control
parameterContainer) [0x0] in :0
  at System.Web.UI.Control.RenderChildren (System.Web.UI.HtmlTextWriter
writer) [0x0] in :0
  at System.Web.UI.Control.Render (System.Web.UI.HtmlTextWriter writer)
[0x0] in :0
  at System.Web.UI.Control.RenderControl (System.Web.UI.HtmlTextWriter
writer) [0x0] in :0
  at System.Web.UI.Control.RenderChildren (System.Web.UI.HtmlTextWriter
writer) [0x0] in :0
  at System.Web.UI.Control.Render (System.Web.UI.HtmlTextWriter writer)
[0x0] in :0
  at System.Web.UI.Page.Render (System.Web.UI.HtmlTextWriter writer)
[0x0] in :0
  at System.Web.Mvc.ViewPage.Render (System.Web.UI.HtmlTextWriter
writer) [0x0] in :0
  at System.Web.UI.Control.RenderControl (System.Web.UI.HtmlTextWriter
writer) [0x0] in :0
  at System.Web.UI.Page.RenderPage () [0x0] in :0
  at System.Web.UI.Page.InternalProcessRequest () [0x0] in :0
  at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
[0x0] in :0

===



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-devel-list] merging two assemblies and related problems

[Eyal Alaluf]

Hi, Vladimir.

There is one 5 you didn't try. It's called MBEL 
It's a Java based solution (of al things). It is capable of reading IL
assemblies manipulating them and writing them back. Causing it to merge two
assemblies requires definitely an effort but should be possible.
We use MBEL to generate a stub .Net DLL froma Java jar file and it quite decent
apart from the factv that it consumes tons of memory.

Eyal.

On Fri, 20 May 2005, Vladimir Vukicevic wrote:

> Date: Fri, 20 May 2005 02:36:34 -0700
> From: Vladimir Vukicevic <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [Mono-devel-list] merging two assemblies and related problems
>
> I've brought up this problem in the past, but i'm again trying to find
> a decent solution for this using mono.  The problem is pretty
> straightforward:  I have two assemblies, A.dll and B.dll.  A.dll is
> autogenerated using System.Reflection.Emit; B.dll is compiled from C#
> source.  A.dll needs to access a custom attribute class that's defined
> in B.dll.  So far, here are the approaches that I've tried, and the
> problems I've encountered:
>
> 1) Use ILMerge (http://research.microsoft.com/~mbarnett/ilmerge.aspx).
>  Works great; binary only, Windows only.
>
> 2) Use PERWAPI (http://www.plas.fit.qut.edu.au/perwapi/Default.aspx).
> It seems to work under .NET 1.1 on windows; under mono 1.1.7 I see
> strange bugs (usually an infinite loop as it's trying to write an
> assembly out on anything but the simplest assemblies).  It also balks
> on some mono-generated assemblies, usually finding non-zero values
> where it was expecting to just read zeros.
>
> 3) Use RAIL (http://rail.dei.uc.pt/).  A simple test of
> RAssemblyDef.LoadAssembly("foo.dll").SaveAssembly("bar.dll") results
> in:
> ** ERROR **: file reflection.c: line 835 (method_encode_clauses):
> assertion failed: (ex_info->handlers)
>
> 4) Use monodis on both A.dll and B.dll, massage the output a bit, and
> reassemble with ilasm -- basically remove the extern reference from
> A.dll to B.dll, remove the foreign assembly reference from the custom
> attribute usage in A.dll, and tack on most of B.dll's disassembly to
> the end.  The problem here is that A.dll uses the "calli" instruction,
> and monodis/ilasm can't round-trip the calli signatures... the output
> has: "IL_0008:  calli signature-0x1101", signature-0x1102, and
> so on.  ildasm appropriately balks.
>
> Is there a #5 that I'm missing that I haven't tried?  Out of the above
> problems, fixing monodis/ilasm to round-trip signatures would probably
> be the most straightforward, though that's the least elegant solution.
>  Fixing the assertion failure with RAIL may or may not be difficult; I
> haven't looked into what exactly is happening in much detail.  PERWAPI
> might be making too many assumptions about the PE files it operates
> on, and may be failing  due to .NET-only quirks.
>
> A final last-ditch effort may be to just use S.R.E to generate the
> classes/methods that B.dll provides directly into A.dll.  Maybe I
> could use Cecil to read B.dll and generate appropriate output using
> S.R.E.?
>
> Any ideas would be appreciated.
>
> Thanks,
> - Vladimir
> ___
> 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 for standardizing Mainsoft's ConstraintCollection tests

[Eyal Alaluf]

Hi, all.

The attached patch adds a new test under Test/System.Data -
 ConstraintCollectionTest2.cs
This test is a Mono NUnit standardized version of the tests under
  Test/System.Data.Tests.Mainsoft/System.Data/ConstraintCollection
As part of the patch I copied a couple of utility classes from
Test/System.Data.Tests.Mainsoft/GHUtils into a new test utility dir
called:
  Test/System.Data.Test.Utils
These utilities are used to create populated data tables.
It is our intention to standardize all the tests under
  Test/System.Data.Tests.Mainsoft/System.Data in the same manner.

Any comments are welcome.

Eyal.
Index: Test/System.Data/ConstraintCollectionTest2.cs

===

--- Test/System.Data/ConstraintCollectionTest2.cs   (revision 0)

+++ Test/System.Data/ConstraintCollectionTest2.cs   (revision 0)

@@ -0,0 +1,280 @@

+// Authors:
+//   Rafael Mizrahi   <[EMAIL PROTECTED]>
+//   Erez Lotan   <[EMAIL PROTECTED]>
+//   Oren Gurfinkel   <[EMAIL PROTECTED]>
+//   Ofer Borstein
+// 
+// Copyright (c) 2004 Mainsoft Co.
+// 
+// Permission is hereby granted, free of charge, to any person obtaining
+// a copy of this software and associated documentation files (the
+// "Software"), to deal in the Software without restriction, including
+// without limitation the rights to use, copy, modify, merge, publish,
+// distribute, sublicense, and/or sell copies of the Software, and to
+// permit persons to whom the Software is furnished to do so, subject to
+// the following conditions:
+// 
+// The above copyright notice and this permission notice shall be
+// included in all copies or substantial portions of the Software.
+// 
+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+//
+
+using NUnit.Framework;
+using MonoTests.System.Data.Test.Utils;
+using System;
+using System.Collections;
+using System.ComponentModel;
+using System.Data;
+
+namespace MonoTests.System.Data
+{
+   [TestFixture] public class ConstraintCollectionTest2
+   {
+   private bool CollectionChangedFlag = false;
+
+   [Test] public void CanRemove_ParentForeign()
+   {
+   DataSet ds = DataProvider.CreateForigenConstraint();
+   Assert.AreEqual(false, 
ds.Tables["parent"].Constraints.CanRemove(ds.Tables["parent"].Constraints[0]), 
"CN1");
+   }
+
+   [Test] public void CanRemove_ChildForeign()
+   {
+   DataSet ds = DataProvider.CreateForigenConstraint();
+   Assert.AreEqual(true, 
ds.Tables["child"].Constraints.CanRemove(ds.Tables["child"].Constraints[0]), 
"CN2");
+   }
+
+   [Test] public void CanRemove_ParentAndChildForeign()
+   {
+   DataSet ds = DataProvider.CreateForigenConstraint();
+   //remove the forigen and ask about the unique
+   
ds.Tables["child"].Constraints.Remove(ds.Tables["child"].Constraints[0]);
+   Assert.AreEqual(true, 
ds.Tables["parent"].Constraints.CanRemove(ds.Tables["parent"].Constraints[0]), 
"CN3");
+   }
+
+   // FIXME. This test isn't complete.
+   public void CanRemove_Unique()
+   {
+   DataTable dt = DataProvider.CreateUniqueConstraint();
+   //remove the forigen and ask about the unique
+   dt.Constraints.Remove(dt.Constraints[0]);
+   Assert.AreEqual(true, 
dt.Constraints.CanRemove(dt.Constraints[0]), "CN4");
+   }
+
+   [Test] public void Clear_Foreign()
+   {
+   DataSet ds = DataProvider.CreateForigenConstraint();
+   foreach(DataTable dt in ds.Tables)
+   {
+   dt.Constraints.Clear();
+   }
+   Assert.AreEqual(0, ds.Tables[0].Constraints.Count, 
"CN5");
+   Assert.AreEqual(0, ds.Tables[0].Constraints.Count, 
"CN6");
+
+   }
+
+   [Test] public void Clear_Unique()
+   {
+   DataTable dt = DataProvider.CreateUniqueConstraint();
+   int rowsCount = dt.Rows.Count;
+   dt.Constraints.Clear();
+   DataRow dr = dt.NewRow();
+   dr[0] = 1;
+   dt.Rows.Add(dr);
+   Asse

Re: spam: suspected: Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch

[Eyal Alaluf]

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.

Index: System.Xml.XPath/DefaultContext.cs
===
--- System.Xml.XPath/DefaultContext.cs  (revision 45578)
+++ System.Xml.XPath/DefaultContext.cs  (working copy)
@@ -119,8 +119,11 @@
// Return string in roundtrip format (currently it
// rather breaks things, so we don't use it until
// System.Double gets fixed.)
-// return ((double) d).ToString ("R", 
System.Globalization.NumberFormatInfo.InvariantInfo);
+#if TARGET_JVM
+   return d.ToString ("R", 
System.Globalization.NumberFormatInfo.InvariantInfo);
+#else
return ((double) d).ToString 
(System.Globalization.NumberFormatInfo.InvariantInfo);
+#endif
}
 
public static double ToNumber (object arg)
___
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: spam: suspected: Re: Spam: Re: [Mono-devel-list] minor xslttest makefile patch

[Eyal Alaluf]

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

Re: [Mono-devel-list] Re: valid-sa-100 testcase

[Eyal Alaluf]

Hi, Atsushi.

Just to set things straight. The patch was rejected since it was incomplete
caused regressions and you didn't like the approach. The lack of concrete
test case at the time that motivated the patch prevented us from continuing
the discussion at that time. Now that the lost test was found :-) we are
continuing the discussion.
Now back to the test, how do you propose to fix the issue? What is your
analysis of the issue?
Regarding XmlDocument use, how do you think we should test it? When you changed
xmltest.cs did you have cases where XmlDocument didn't work in Mono but worked
in MS?

Eyal.

On Fri, 17 Jun 2005, Atsushi Eno wrote:


Date: Fri, 17 Jun 2005 21:30:47 +0900
From: Atsushi Eno <[EMAIL PROTECTED]>
To: Andrew Skiba <[EMAIL PROTECTED]>
Cc: mono-devel mailing list 
Subject: [Mono-devel-list] Re: valid-sa-100 testcase

Hi Andrew,

*regarding subj*, I think we should not mix different things:

- Wellformedness in XmlTextReader
- Validity in XmlValidatingReader
- How XmlEntity/XmlEntityReference behaves

Since the standalone test should basically target validity in
XmlReader, the way that patch takes is basically wrong.

(BTW that's why I fixed xmltest.cs in my XML standalone_tests
not to use XmlDocument for testing them, once upon a time.)

Besides the subj, I don't think I have rejected Kosta's patch
just because there is no testcase. I even sent Kosta and Eyal
an example case that the patch makes things inconsistent.
Here I attach it so that anyone can try.

Atsushi Eno

using System;
using System.Xml;

public class Test
{
public static void Main ()
{
string xml = "]>&ent;";
XmlTextReader xtr = new XmlTextReader (xml, 
XmlNodeType.Document, null);
XmlDocument doc = new XmlDocument ();
doc.AppendChild (doc.ReadNode (xtr)); // DTD
xtr.Read ();
XmlEntityReference e = (XmlEntityReference) doc.ReadNode (xtr);
Console.WriteLine (e.ChildNodes.Count);
doc.AppendChild (doc.CreateElement ("foo"));
doc.DocumentElement.AppendChild (e);
Console.WriteLine (e.ChildNodes.Count);
}
}
___
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 for Novell.Directory.Ldap

[Eyal Alaluf]

Hi, Boris.

Can you elaborate a little on the porting issues you solved in this patch?
I see that you disabled SSL support, did I understand well?

Eyal.

On Sun, 19 Jun 2005, Boris Kirzner wrote:


Date: Sun, 19 Jun 2005 15:16:40 +0300
From: Boris Kirzner <[EMAIL PROTECTED]>
To: mono-devel-list@lists.ximian.com
Subject: [Mono-devel-list] Patch for Novell.Directory.Ldap

Hello all,
Attached is a proposed patch for Novell.Directory.Ldap.
The patch adds ifdef to exclude the code not used in TARGET_JVM.

If no one objects, I'll commit.
Boris

--
Boris Kirzner
Mainsoft Corporation
http://www.mainsoft.com


Index: Novell.Directory.Ldap/Connection.cs
===
--- Novell.Directory.Ldap/Connection.cs (revision 45568)
+++ Novell.Directory.Ldap/Connection.cs (working copy)
@@ -34,8 +34,10 @@
 using Novell.Directory.Ldap.Asn1;
 using Novell.Directory.Ldap.Rfc2251;
 using Novell.Directory.Ldap.Utilclass;
+#if !TARGET_JVM
 using Mono.Security.Protocol.Tls;
 using Mono.Security.X509.Extensions;
+#endif
 using Syscert = System.Security.Cryptography.X509Certificates;
 using System.Security.Cryptography;
 using System.Net;
@@ -43,7 +45,9 @@
 using System.Collections;
 using System.IO;
 using System.Text;
+#if !TARGET_JVM
 using Mono.Security.X509;
+#endif
 using System.Text.RegularExpressions;
 using System.Globalization;
 
@@ -682,6 +686,7 @@
{
if ((in_Renamed == null) || (out_Renamed == 
null))
{
+#if !TARGET_JVM
if(Ssl)
{
this.host = host;
@@ -704,10 +709,13 @@
out_Renamed = 
(System.IO.Stream) sslstream;
}
else{
+#endif
socket = new 
System.Net.Sockets.TcpClient(host, port);  
in_Renamed = (System.IO.Stream) 
socket.GetStream();
out_Renamed = 
(System.IO.Stream) socket.GetStream();
+#if !TARGET_JVM
}
+#endif
}
else
{
@@ -1113,7 +1121,7 @@
/* package */
internal void  startTLS()
{
-   
+#if !TARGET_JVM
try
{
waitForReader(null);
@@ -1145,6 +1153,7 @@
throw new LdapException("The host is unknown", 
LdapException.CONNECT_ERROR, null, uhe);
}
return ;
+#endif
}

/*
Index: Novell.Directory.Ldap/LdapConnection.cs
===
--- Novell.Directory.Ldap/LdapConnection.cs (revision 45568)
+++ Novell.Directory.Ldap/LdapConnection.cs (working copy)
@@ -34,7 +34,9 @@
 using Novell.Directory.Ldap.Asn1;
 using Novell.Directory.Ldap.Rfc2251;
 using Novell.Directory.Ldap.Utilclass;
+#if !TARGET_JVM
 using Mono.Security.Protocol.Tls;
+#endif
 using System.Security.Cryptography.X509Certificates;
 
 namespace Novell.Directory.Ldap
Index: Novell.Directory.Ldap/AssemblyInfo.cs
===
--- Novell.Directory.Ldap/AssemblyInfo.cs   (revision 45568)
+++ Novell.Directory.Ldap/AssemblyInfo.cs   (working copy)
@@ -69,6 +69,8 @@
[assembly: AssemblyVersion ("1.0.3300.0")]
 #endif
 
+#if (!TARGET_JVM)
 [assembly: AssemblyDelaySign (true)]
 [assembly: AssemblyKeyFile ("../mono.pub")]
+#endif
 
Index: ChangeLog
===
--- ChangeLog   (revision 45568)
+++ ChangeLog   (working copy)
@@ -1,3 +1,6 @@
+2005-19-06  Boris Kirzner <[EMAIL PROTECTED]>
+   * Novell.Directory.Ldap/AssemblyInfo.cs, 
Novell.Directory.Ldap/Connection.cs, Novell.Directory.Ldap/LdapConnection.cs: 
added ifdef to exclude the code not used in TARGET_JVM.
+
 2005-04-05  Boris Kirzner <[EMAIL PROTECTED]>
* Added Novell.Directory.Ldap.Rfc2251/RfcLdapSuperDN.cs to sources.
 
___
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] Re: valid-sa-100 testcase

[Eyal Alaluf]

Hi, Atsushi.

Would the use of a validating reader around XmlTextReader explain the
difference between the XmlDocument.Load and XmlTextReader?

Eyal.

On Sat, 18 Jun 2005, Atsushi Eno wrote:

> Date: Sat, 18 Jun 2005 01:04:18 +0900
> From: Atsushi Eno <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Cc: Andrew Skiba <[EMAIL PROTECTED]>,
>  mono-devel mailing list 
> Subject: Re: [Mono-devel-list] Re: valid-sa-100 testcase
>
> Hi Eyal,
>
> > Just to set things straight. The patch was rejected since it was incomplete
> > caused regressions and you didn't like the approach. The lack of concrete
> > test case at the time that motivated the patch prevented us from continuing
> > the discussion at that time. Now that the lost test was found :-) we are
> > continuing the discussion.
>
> That is also true to me that I am not motivated for that problem.
> MS.NET is not also doing well on entity processing and I found no
> serious existing solutions, so I just kept away from it.
>
> > Now back to the test, how do you propose to fix the issue? What is your
> > analysis of the issue?
>
> Honestly, entity handling stuff is so minor that even MS.NET does
> not work fine (for example RDF DTD that Joshua posted could not
> be read fine), so am not fixing it soon. But of course I'd
> appreciate if you guys or anyone would fix the problem :-)
>
> > Regarding XmlDocument use, how do you think we should test it?
>  > When you changed xmltest.cs did you have cases where XmlDocument
>  > didn't work in Mono but worked in MS?
>
> I don't remember even whether I was aware of such differences or not.
> I was not always paying attention to MS.NET behavior (since there
> are many tests that .NET does not work fine). There are some cases
> that (at least) XmlTextReader.Read() and XmlDocument.Load() differ
> in rejecting input xml or not e.g. XmlDocument.Load() rejects
> undeclared entities while XmlTextReader does not.
>
> Atsushi Eno
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-devel-list] Re: valid-sa-100 testcase

[Eyal Alaluf]

Hi, Atsushi.

> >> ... There are some cases
> >> that (at least) XmlTextReader.Read() and XmlDocument.Load() differ
> >> in rejecting input xml or not e.g. XmlDocument.Load() rejects
> >> undeclared entities while XmlTextReader does not.
I ment this difference that you have mentioned.

Eyal.

On Mon, 20 Jun 2005, Atsushi Eno wrote:

> Date: Mon, 20 Jun 2005 03:07:44 +0900
> From: Atsushi Eno <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Cc: Andrew Skiba <[EMAIL PROTECTED]>,
>  mono-devel mailing list 
> Subject: Re: [Mono-devel-list] Re: valid-sa-100 testcase
>
> Hi Eyal,
>
> Am not sure if I correctly understand your question (because I have
> no idea how this Q is related to the topic and my answer). But maybe
> I should answer "it depends" on the "difference".
>
> Atsushi Eno
>
> Eyal Alaluf wrote:
> > Hi, Atsushi.
> >
> > Would the use of a validating reader around XmlTextReader explain the
> > difference between the XmlDocument.Load and XmlTextReader?
> >
> > Eyal.
> >
> > On Sat, 18 Jun 2005, Atsushi Eno wrote:
> >
> >> Date: Sat, 18 Jun 2005 01:04:18 +0900
> >> From: Atsushi Eno <[EMAIL PROTECTED]>
> >> To: Eyal Alaluf <[EMAIL PROTECTED]>
> >> Cc: Andrew Skiba <[EMAIL PROTECTED]>,
> >>  mono-devel mailing list 
> >> Subject: Re: [Mono-devel-list] Re: valid-sa-100 testcase
> >>
> >> Hi Eyal,
> >>
> >>> Just to set things straight. The patch was rejected since it was 
> >>> incomplete
> >>> caused regressions and you didn't like the approach. The lack of concrete
> >>> test case at the time that motivated the patch prevented us from 
> >>> continuing
> >>> the discussion at that time. Now that the lost test was found :-) we are
> >>> continuing the discussion.
> >> That is also true to me that I am not motivated for that problem.
> >> MS.NET is not also doing well on entity processing and I found no
> >> serious existing solutions, so I just kept away from it.
> >>
> >>> Now back to the test, how do you propose to fix the issue? What is your
> >>> analysis of the issue?
> >> Honestly, entity handling stuff is so minor that even MS.NET does
> >> not work fine (for example RDF DTD that Joshua posted could not
> >> be read fine), so am not fixing it soon. But of course I'd
> >> appreciate if you guys or anyone would fix the problem :-)
> >>
> >>> Regarding XmlDocument use, how do you think we should test it?
> >>  > When you changed xmltest.cs did you have cases where XmlDocument
> >>  > didn't work in Mono but worked in MS?
> >>
> >> I don't remember even whether I was aware of such differences or not.
> >> I was not always paying attention to MS.NET behavior (since there
> >> are many tests that .NET does not work fine). There are some cases
> >> that (at least) XmlTextReader.Read() and XmlDocument.Load() differ
> >> in rejecting input xml or not e.g. XmlDocument.Load() rejects
> >> undeclared entities while XmlTextReader does not.
> >>
> >> Atsushi Eno
> >>
> >
> >
>
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[mono-devel-list] Patch to standardize Mainsoft DataSet tests

[Eyal Alaluf]

Hi, all.

Attched is a patch (gzipped so it won't be too big) that collects the various 
data set tests from Mainsoft (we
had one test class per method) into one test class.
One issue I'd like to mention is that I used 'MonoTests_System.Data' namespace
instead of 'MonoTests.System.Data' since when using code like:
  System.Text.StringBuilder resultXML = new System.Text.StringBuilder();
I get the following error:
  Test\System.Data\DataSetTest2.cs(350,11): error CS0234: The type or namespace 
name 'Text' does not exist in the class or namespace 'MonoTests.System' (are 
you missing an assembly reference?)
The problem is that the compiler understands 'System' as 'MonoTests.System'.
Trying 'MonoTests.System_Data' didn't work either since it was enough that
once file uses 'MonoTests.System.Data' to cause the error.
I consider removing the full scope usage and adding a 'using' directive as
a workaround, since this problem can happen to any test developer.
Any coments are welcome. I'd like move ahead as soon as possible since I'd like
to standradize the other disconnected tests we contributed.

Eyal.



patch.diff.gz
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-devel-list] Re: [Mono-patches] r46615 - trunk/mcs/class/System.Data/Test/System.Data

[Eyal Alaluf]

Hi, Ben.

Can you send me & Kosta the list of failures you have? I don't recall these
tests below failing and perhaps something does not work well on your side.

Eyal.

On Mon, 27 Jun 2005, Ben Maurer <[EMAIL PROTECTED]> wrote:

> Date: Mon, 27 Jun 2005 18:35:04 -0400 (EDT)
> From: "Ben Maurer <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]>
> To: mono-patches@lists.ximian.com, [EMAIL PROTECTED]
> Subject: [Mono-patches] r46615 -
> trunk/mcs/class/System.Data/Test/System.Data
>
> Author: benm
> Date: 2005-06-27 18:35:03 -0400 (Mon, 27 Jun 2005)
> New Revision: 46615
>
> Modified:
>trunk/mcs/class/System.Data/Test/System.Data/DataSetTest2.cs
> Log:
> more stuff that is somehow failing now
>
> Modified: trunk/mcs/class/System.Data/Test/System.Data/DataSetTest2.cs
> ===
> --- trunk/mcs/class/System.Data/Test/System.Data/DataSetTest2.cs  
> 2005-06-27 22:13:02 UTC (rev 46614)
> +++ trunk/mcs/class/System.Data/Test/System.Data/DataSetTest2.cs  
> 2005-06-27 22:35:03 UTC (rev 46615)
> @@ -669,7 +669,9 @@
>   Assert.AreEqual("attr2", 
> ds.Tables[0].Columns["attr2"].ColumnName, "DS88");
>   }
>
> - [Test] public void InferXmlSchema_inferingTables5()
> + [Test]
> + [Category ("NotWorking")]
> + public void InferXmlSchema_inferingTables5()
>   {
>   //Acroding to the msdn documantaion :
>   
> //ms-help://MS.MSDNQTR.2003FEB.1033/cpguide/html/cpconinferringtables.htm
> @@ -1848,7 +1850,9 @@
>   Assert.AreEqual(0, ds2.Tables[1].Rows.Count , "DS296");
>   }
>
> - [Test] public void ReadXml_Strg()
> + [Test]
> + [Category ("NotWorking")]
> + public void ReadXml_Strg()
>   {
>   string sTempFileName = 
> "tmpDataSet_ReadWriteXml_43894.xml"  ;
>
> @@ -1885,7 +1889,9 @@
>   System.IO.File.Delete(sTempFileName);
>   }
>
> - [Test] public void ReadXml_Strm()
> + [Test]
> + [Category ("NotWorking")]
> + public void ReadXml_Strm()
>   {
>   DataSet ds1 = new DataSet();
>   ds1.Tables.Add(DataProvider.CreateParentDataTable());
> @@ -2119,7 +2125,9 @@
>   
> Assert.AreEqual(m_ds.Tables[toTable].Select(toTestSelect)[0]["Stock_Id"], 
> m_ds.Tables[toCompareTable].Select(toCompareSelect)[0]["Stock_Id"], 
> AssertTag);
>   }
>
> - [Test] public void ReadXml_Strm5()
> + [Test]
> + [Category ("NotWorking")]
> + public void ReadXml_Strm5()
>   {
>   string xmlData;
>   string name;
> @@ -2371,7 +2379,9 @@
>   Assert.AreEqual(3, ds.Tables["c"].Rows.Count, "DS338");
>   }
>
> - [Test] public void ReadXml_ByTextReader()
> + [Test]
> + [Category ("NotWorking")]
> + public void ReadXml_ByTextReader()
>   {
>   DataSet ds1 = new DataSet();
>   ds1.Tables.Add(DataProvider.CreateParentDataTable());
> @@ -2408,7 +2418,9 @@
>   sw.Close();
>   }
>
> - [Test] public void ReadXml_ByXmlReader()
> + [Test]
> + [Category ("NotWorking")]
> + public void ReadXml_ByXmlReader()
>   {
>   DataSet ds1 = new DataSet();
>   ds1.Tables.Add(DataProvider.CreateParentDataTable());
>
> ___
> Mono-patches maillist  -  Mono-patches@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-patches
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-devel-list] Re: [Mono-patches] r46615 - trunk/mcs/class/System.Data/Test/System.Data

[Eyal Alaluf]

Hi, Ben.

I believe that we have an issue to resolve here. I never got this particular
error and I believe that you have a problem on your side. Specifically, I
don't get any failures like that for the following tests:
-   [Category ("NotWorking")]
public void ReadXml_Strg()
-   [Category ("NotWorking")]
public void ReadXml_Strm()
-   [Category ("NotWorking")]
public void ReadXml_ByTextReader()
-   [Category ("NotWorking")]
public void ReadXml_ByXmlReader()

Eyal.

On Tue, 28 Jun 2005, Ben Maurer wrote:

> Date: Tue, 28 Jun 2005 12:34:09 -0400
> From: Ben Maurer <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Cc: Kostantin Triger <[EMAIL PROTECTED]>, mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-devel-list] Re: [Mono-patches] r46615 -
> trunk/mcs/class/System.Data/Test/System.Data
>
> On Tue, 2005-06-28 at 11:16 +0300, Eyal Alaluf wrote:
> > Hi, Ben.
> >
> > Can you send me & Kosta the list of failures you have? I don't recall these
> > tests below failing and perhaps something does not work well on your side.
>
> I mostly got stuff like:
>
> 2) MonoTests_System.Data.DataSetTest2.ReadXml_Strm :
> System.ArgumentOutOfRangeException : 1 is not in a range between 1
> and .
>
> I don't have a complete list here. If you revert the changes I made, you
> can see what is failing.
>
> -- Ben
>
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-devel-list] Re: [Mono-patches] r46615 - trunk/mcs/class/System.Data/Test/System.Data

[Eyal Alaluf]

Hi, Ben.

As I said we have a problem. It works fine for me, I looked at the test and it
does not use 1 as a year (it uses 2000). Something is wrong.
Also, did you commit all the changes? I get a ton of erros about SqlMoney
(which I don't understand at all, the code looks perfectly innocent).
I am using Windows and Cygwin, and you are probably using Linux. The failures
I am getting are:
Failures:
1) MonoTests.System.Data.SqlTypes.SqlBooleanTest.ToSqlMoney : ToSqlMoney method 
does not work correctly
expected:<1.>
 but was:<10001.>
in <0x000e3> MonoTests.System.Data.SqlTypes.SqlBooleanTest:ToSqlMoney ()
in <0x0> 
in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
(object,object[])
in <0x00062> System.Reflection.MonoMethod:Invoke (System.Object obj, 
BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] 
parameters, System.Globalization.CultureInfo culture)

2) MonoTests.System.Data.SqlTypes.SqlBooleanTest.SqlMoneyToSqlBoolean : 
System.OverflowException : Number overflow.
in <0x00050> System.Decimal:s64 (Decimal value)
in <0x00028> System.Decimal:op_Explicit (Decimal val)
in <0x00057> System.Data.SqlTypes.SqlBoolean:op_Explicit (SqlMoney x)
in <0x0005a> MonoTests.System.Data.SqlTypes.SqlBooleanTest:SqlMoneyToSqlBoolean 
()
in <0x0> 
in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
(object,object[])
in <0x00062> System.Reflection.MonoMethod:Invoke (System.Object obj, 
BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] 
parameters, System.Globalization.CultureInfo culture)

and many more similar failures.

Eyal.

On Tue, 28 Jun 2005, Ben Maurer wrote:

> Date: Tue, 28 Jun 2005 12:57:55 -0400
> From: Ben Maurer <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Cc: Kostantin Triger <[EMAIL PROTECTED]>, mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-devel-list] Re: [Mono-patches] r46615 -
> trunk/mcs/class/System.Data/Test/System.Data
>
> On Tue, 2005-06-28 at 19:51 +0300, Eyal Alaluf wrote:
> > Hi, Ben.
> >
> > I believe that we have an issue to resolve here. I never got this particular
> > error and I believe that you have a problem on your side. Specifically, I
> > don't get any failures like that for the following tests:
> > -   [Category ("NotWorking")]
> > public void ReadXml_Strg()
> > -   [Category ("NotWorking")]
> > public void ReadXml_Strm()
> > -   [Category ("NotWorking")]
> > public void ReadXml_ByTextReader()
> > -   [Category ("NotWorking")]
> > public void ReadXml_ByXmlReader()
> >
> [EMAIL PROTECTED] System.Data]$ svn di
> Index: Test/System.Data/DataSetTest2.cs
> ===
> --- Test/System.Data/DataSetTest2.cs(revision 46656)
> +++ Test/System.Data/DataSetTest2.cs(working copy)
> @@ -1851,7 +1851,7 @@
> }
>
> [Test]
> -   [Category ("NotWorking")]
> +   //[Category ("NotWorking")]
> public void ReadXml_Strg()
> {
> string sTempFileName = 
> "tmpDataSet_ReadWriteXml_43894.xml"  ;
> [EMAIL PROTECTED] System.Data]$ make run-test
> ok=:; make run-test-recursive || ok=false; make run-test-local || ok=false; 
> $ok
> make[1]: Entering directory `/home/benm/msvn/mcs/class/System.Data'
> make[1]: Leaving directory `/home/benm/msvn/mcs/class/System.Data'
> make[1]: Entering directory `/home/benm/msvn/mcs/class/System.Data'
> MONO_PATH="../../class/lib/default:$MONO_PATH" 
> /home/benm/msvn/mono/runtime/mono-wrapper  ../../class/lib/default/mcs.exe   
> -d:NET_1_1 -d:ONLY_1_1 -debug /target:library 
> /out:System.Data_test_default.dll /r:../../class/lib/default/System.Data.dll 
> -r:../../class/lib/default/nunit.framework.dll 
> -r:../../class/lib/default/nunit.core.dll 
> -r:../../class/lib/default/nunit.util.dll /nowarn:649 /nowarn:169 /nowarn:219 
> /nowarn:168 /nowarn:1595 /r:mscorlib.dll 
> /r:../../class/lib/default/System.dll /r:System.Xml.dll 
> /r:System.EnterpriseServices.dll /r:Mono.Data.Tds.dll  /nowarn:618 
> @../../build/deps/System.Data_test_default.dll.response
> Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(257) warning 
> CS0162: Unreachable code detected
> Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(265) warning 
> CS0162: Unreachable code detected
> Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(269) warning 
> C

Re: [Mono-devel-list] Windows Build of Mono/Mcs

[Eyal Alaluf]

Hi, all.

I'd like to add that building Mono with csc.exe have weird results. I have 
filed bug
75540 that shows a wierd behaviour of Decimal under cygwin. When compiling with
EXTERNAL_MCS=mcs this does not happen anymore.

Eyal.

On Sat, 16 Jul 2005, Daniel Morgan wrote:

> Date: Sat, 16 Jul 2005 07:16:51 -0400
> From: Daniel Morgan <[EMAIL PROTECTED]>
> To: mono-devel-list 
> Subject: [Mono-devel-list] Windows Build of Mono/Mcs
>
> In mcs/build/platforms/win32.make
>
> Can we change this from:
>
> EXTERNAL_MCS = csc
>
> to the following:
>
> EXTERNAL_MCS = mcs
>
> csc does not work with building Mono on Windows anymore.  You get
> internal compiler errors.  We should just use mcs to build from now on...
>
> I can compile mono/mcs from svn HEAD trunk using the Mono 1.1.8 windows
> installer and cygwin.  As long as I make sure that cygwin does not
> install any glib2, gtk2, pango, atk stuff.  And I set the PATH and
> PKG_CONFIG_PATH environment variables correctly.
>
>
>
>
> ___
> 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] Fix "neutral" sorting in DataView

[Eyal Alaluf]

BTW, it's better to write your tests without inheriting from Assertion (which 
is deprectaed).
You just use the [TestFixture] attribute and go on. For an example see:
  trunk/mcs/class/System.Data/Test/System.Data/DataSetTest2.cs

Eyal.

On Thu, 21 Jul 2005, Marc Haisenko wrote:

> Date: Thu, 21 Jul 2005 17:27:41 +0200
> From: Marc Haisenko <[EMAIL PROTECTED]>
> To: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-devel-list] [PATCH] Fix "neutral" sorting in DataView
>
> On Thursday 21 July 2005 17:18, Atsushi Eno wrote:
> > Hi Marc,
> >
> > > Oh dear... luckily I now managed to write the stuff today. I've wasted
> > > two and a half hours just for that silly test ! Would anyone care to
> > > explain to me why the line
> > > Assert.AreEqual (1, 2, "Foo");
> > > causes mcs to complain "error CS0119: Expression denotes a `method
> > > group', where a `variable', `value' or `type' was expected" ?
> >
> > Because there is both Assert class and Assert method in that scope.
> > Since the test class is derived from Assertion, it guesses "Assert"
> > is NUnit.Framework.Assertion.Assert method, not NUnit.Framework.Assert
> > class.
>
> Aah, thanks a lot :-) But I guess a better error message should be
> displayed here, it'd be better if mcs would complain about ambiguity. I
> didn't had (and still don't have) an idea what a "method group" is supposed
> to mean.
>
> > So if you want to use static Assert methods, you can use alias by
> > using statement, like:
> >
> > using AssertType = NUnit.Framework.Assert;
> >
> > and call AssertType.AreEqual().
> >
> > Atsushi Eno
>
> Thanks for the explanations,
>   Marc
>
> --
> Marc Haisenko
> Systemspezialist
> Webport IT-Services GmbH
> mailto: [EMAIL PROTECTED]
> ___
> 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] Net 1.1 Accessibility patch for System.Web

[Eyal Alaluf]

ctrl = new Table ();

+#if NET_1_1

+   if (Caption.Length != 0)

+   {

+   ((Table) ctrl).CaptionAlign = 
CaptionAlign;

+   ((Table) ctrl).Caption = 
Caption; 

+   }

+#endif

+   }

+   else 

+   ctrl = new WebControl 
(HtmlTextWriterTag.Span);

ctrl.ID = baseControl.ClientID;

ctrl.CopyBaseAttributes (baseControl);

ctrl.ApplyStyle (controlStyle);

@@ -321,10 +357,21 @@

writer.AddAttribute 
(HtmlTextWriterAttribute.Colspan,

 colSpan.ToString 
(NumberFormatInfo.InvariantInfo));

}

+#if NET_1_1

+   if (UseAccessibleHeader)

+   writer.AddAttribute("scope", 
"col", false);

+#endif

itemStyle = user.GetItemStyle 
(ListItemType.Header, -1);

if (itemStyle != null)

itemStyle.AddAttributesToRender 
(writer);

+#if NET_1_1

+   if (UseAccessibleHeader)

+   
writer.RenderBeginTag(HtmlTextWriterTag.Th);

+   else

+   
writer.RenderBeginTag(HtmlTextWriterTag.Td);

+#else

writer.RenderBeginTag 
(HtmlTextWriterTag.Td);

+#endif

}

 

user.RenderItem (ListItemType.Header, -1, this, 
writer);

@@ -404,5 +451,28 @@

if (ctrl != null)

ctrl.RenderEndTag(writer);

}

+

+#if NET_1_1

+

+   public string Caption

+   {

+   get {return caption;}

+   set { caption = value; }

+   }

+

+   public TableCaptionAlign CaptionAlign

+   {

+   get {return captionAlign;}

+   set { captionAlign = value; }

+   }

+

+   

+

+   public bool UseAccessibleHeader

+   {

+   get {return useAccessibleHeader;}

+   set { useAccessibleHeader = value; }

+   }

+#endif

}

 }

Index: ChangeLog

===

--- ChangeLog   (revision 47418)

+++ ChangeLog   (working copy)

@@ -1,3 +1,8 @@

+2005-07-25  Eyal Alaluf <[EMAIL PROTECTED]>
+   * Table.cs Label.cs Image.cs BaseDataList.cs DataList.cs RepeatInfo.cs
+ DataGrid.cs TableCaptionAlign.cs: Accessiblity feature is part of 
NET_1_1
+ service pack fixes. In Mono it was available only under NET_2_0 
config.
+
 2005-07-19  Eyal Alaluf <[EMAIL PROTECTED]>
* Added XmlBuilder.jvm.cs for the TARGET_J2EE configuration.
 
Index: DataGrid.cs

===

--- DataGrid.cs (revision 47365)

+++ DataGrid.cs (working copy)

@@ -944,6 +944,10 @@

 
Table display = (Table) Controls [0];
display.CopyBaseAttributes (this);
+#if NET_1_1
+   display.Caption = Caption;
+   display.CaptionAlign = CaptionAlign;
+#endif
if (ControlStyleCreated) {
display.ApplyStyle (ControlStyle);
} else {
@@ -1182,6 +1186,10 @@

current.Initialize();
}
deployTable = new DataGridTableInternal();
+#if NET_1_1
+   deployTable.Caption = Caption;
+   deployTable.CaptionAlign = CaptionAlign;
+#endif
Controls.Add(deployTable);
deployRows = deployTable.Rows;
 
@@ -1334,7 +1342,17 @@


for(int i = 0; i < columns.Length; i++)
{
+#if NET_1_1
+   if (item.ItemType == ListItemType.Header && 
this.UseAccessibleHeader) 
+   {
+   cCell = new TableHeaderCell();
+   cCell.Attributes["scope"] = "col";
+   }
+  

[Mono-devel-list] Patch for proper cache destruction when HttpRuntime is disposed

[Eyal Alaluf]

Hi, Gonzalo & all.

The attached patch disposes the timer thread when the HttpRuntime goes down. It 
is done only
under TARGET_J2EE for now. My guess is that when the HttpRuntime goes down in 
Mono it goes
down with the app domain and this disposes the thread. But if not (as is the 
case for TARGET_J2EE),
the timer thread will keep the application alive since it keeps referencing the 
cache and
its entries.
Please review and let me know if the patch makes sense in the Mono context as 
well or it
should stay with '#if TARGET_j2EE'.

Eyal.
Index: System.Web/ChangeLog

===

--- System.Web/ChangeLog(revision 47652)

+++ System.Web/ChangeLog(working copy)

@@ -1,3 +1,6 @@

+2005-07-26  Eyal Alalouf  <[EMAIL PROTECTED]>
+   * HttpRuntime.cs: Under TARGET_J2EE dispose the cache as well in 
Dispose.
+
 2005-07-25  Eyal Alalouf  <[EMAIL PROTECTED]>
* HttpContext.cs HttpRuntime.cs HttpApplication.cs: timeout is not 
supported
  in TARGET_J2EE configuration (no Thread.Abort support).
Index: System.Web/HttpRuntime.cs

===

--- System.Web/HttpRuntime.cs   (revision 47652)

+++ System.Web/HttpRuntime.cs   (working copy)

@@ -283,6 +283,9 @@

if (queueManager != null)
queueManager.Dispose (); // Send a 503 to all 
queued requests
queueManager = null;
+#if TARGET_J2EE
+   _cache.Destroy();
+#endif
_cache = null;
HttpApplicationFactory.EndApplication();
}
Index: System.Web.Caching/Cache.cs

===

--- System.Web.Caching/Cache.cs (revision 47365)

+++ System.Web.Caching/Cache.cs (working copy)

@@ -57,6 +57,14 @@

_objExpires = new CacheExpires (this);
}
 
+#if TARGET_J2EE
+   internal void Destroy()
+   {
+   _arrEntries = null;
+   _objExpires.Close();
+   }
+#endif
+
private IDictionaryEnumerator CreateEnumerator () {
Hashtable objTable;
 
Index: System.Web.Caching/CacheExpires.cs

===

--- System.Web.Caching/CacheExpires.cs  (revision 47365)

+++ System.Web.Caching/CacheExpires.cs  (working copy)

@@ -75,6 +75,14 @@

_objTimer = new System.Threading.Timer (new 
System.Threading.TimerCallback (GarbageCleanup), null, 1, 6);

}

 

+#if TARGET_J2EE
+   internal void Close()

+   {

+   _arrBuckets = null;

+   _objTimer.Dispose();

+   }

+#endif
+

/// 

/// Adds a Cache entry to the correct flush bucket.

/// 

Index: System.Web.Caching/ChangeLog

===

--- System.Web.Caching/ChangeLog(revision 47645)

+++ System.Web.Caching/ChangeLog(working copy)

@@ -1,3 +1,6 @@

+2005-07-26 Eyal Alaluf <[EMAIL PROTECTED]>
+* Cache.cs CacheExpires.cs: In TARGET_j2EE dispose the timer thread when 
done.
+
 2005-07-25 Eyal Alaluf <[EMAIL PROTECTED]>
 * ExpiresBuckets.cs: Removed unused field (that if used would lead to
  serious runtime errors).
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-devel-list] Re: Patch for proper cache destruction when HttpRuntime is disposed

[Eyal Alaluf]

Well I guess it won't change much to softly kill the timer since nobody waits 
until it actually
dies and if it does not die quickly enough it will be killed by the app domain 
unloading
anyway.
I am going then to commit with the '#if TARGET_J2EE'.

Eyal.

On Tue, 26 Jul 2005, Gonzalo Paniagua Javier wrote:

> Date: Tue, 26 Jul 2005 10:54:08 -0400
> From: Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Subject: Re: Patch for proper cache destruction when HttpRuntime is
> disposed
>
> On Tue, 2005-07-26 at 17:33 +0300, Eyal Alaluf wrote:
> > Hi, Gonzalo.
> >
> > How is the timer thread killed? In the patch the timer thread is disposed 
> > which is a soft abort
> > (no Thread.Abort called).
> > Does the AppDomain abort the threads? This can result sometimes in complex 
> > race conditions
> > that are difficult to track - this is at least the Java experience. But if 
> > in any case mant
> > threads are aborted when an app domain goes down then it doesn't change 
> > much.
>
> Hehe. That's exactly what's going on in the runtime. The abort sends a
> signal and waits for the code to be in a 'safe' place, but it does not
> always work. And you're right. There's has been a few races and, for
> example, assemblies are not really unloaded by now...
>
> -Gonzalo
>
>
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-devel-list] Implementing HttpResponse.OnCookieAdd

[Eyal Alaluf]

Hi.

The attached patch removes the '#if TARGET_J2EE' in HttpResponse.OnCookieAdd. I 
belive
that the (naive) implementation is not TARGET_J2EE specific and is correct for 
mono as well.
Please review.

Eyal.
Index: System.Web/ChangeLog

===

--- System.Web/ChangeLog(revision 47712)

+++ System.Web/ChangeLog(working copy)

@@ -1,4 +1,7 @@

 2005-07-26  Eyal Alalouf  <[EMAIL PROTECTED]>
+   * HttpResponse.cs: OnCookieAdd should not be TARGET_J2EE specific
+
+2005-07-26  Eyal Alalouf  <[EMAIL PROTECTED]>
* HttpRuntime.cs: Under TARGET_J2EE dispose the cache as well in 
Dispose.
 
 2005-07-26 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
Index: System.Web/HttpResponse.cs

===

--- System.Web/HttpResponse.cs  (revision 47712)

+++ System.Web/HttpResponse.cs  (working copy)

@@ -1059,9 +1055,7 @@

[MonoTODO()]
internal void OnCookieAdd (HttpCookie cookie)
{
-#if TARGET_J2EE//naive implementation
Request.Cookies.Add(cookie);
-#endif
}
 
[MonoTODO("Do we need this?")]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

RE: [Mono-dev] [PATCH] Source list per profile

[Eyal Alaluf]

Hi,  Kornél.

The .jvm.cs are part of the Java build that we are now doing from svn using
make.
The issue is not limited to the .jvm files but also to Mono sources (e.g. in
System.Web) that are not part of the Java build. In System.Web we have about
30 Mono files that we don't compile in the Java build (because we don't
support yet on the fly compilation of .aspx files and CodeDom).
So in our case we have more files that belong to specific profiles or
combinations of profiles.
Personally, the issue here is the number of profiles and their complexity.
The more profiles are used the more useful the proposed change is. If
everyone believes that there are not going to be more profiles then the Java
profile then there is less incentive to change anything - the current
solution of ifdefs is still usable.

Eyal.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kornél Pál
Sent: Tuesday, August 16, 2005 1:08 PM
To: Yaacov Akiba Slama; Zoltan Varga
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] [PATCH] Source list per profile

I think the current soltion is elegant.

Are the .jvm directories used to build the java version using Mono build
system or are they here only as a reference?

If .jvm directories are not used there are only 23 files that are enclosed
in #if NET_2_0 || TARGET_JVM. These files are for 2.0 and java. But if .jvm
is used to build the java version there are much more java specific file.

Kornél

- Original Message -
From: "Yaacov Akiba Slama" <[EMAIL PROTECTED]>
To: "Zoltan Varga" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, August 15, 2005 11:52 AM
Subject: Re: [Mono-dev] [PATCH] Source list per profile


> Zoltan Varga wrote:
>
>>  Hi,
>>
>>   The current solution might not be elegant, but it is simple, and it
>>works just fine.
>>
>>
> Yes. But because of the java profile, a large part of source files need
> to be enclosed by #ifdef.
> The solution Ynon proposed is still quite simple as you can see in the
> files Ynon sent.
>
> What do others think ?
>
> --yas
>
>>So I would vote for keeping it.
>>
>> Zoltan
>>
>>On 8/11/05, Ynon Koralek <[EMAIL PROTECTED]> wrote:
>>
>>
>>>
>>>
>>>
>>>Hello,
>>>
>>>
>>>
>>>When building the libraries, each profile requires different source files
>>>especially with the "java" profile.
>>>
>>>That problem is solved today (for net_2_0) using #ifdef 
>>>enclosing the whole content of files but this solution is not IMHO very
>>>elegant.
>>>
>>>
>>>
>>>The solution we suggest is to use an .xml file which defines which source
>>>files need to be compiled for each profile.
>>>
>>>A new enclosed tool called gensourcelist creates a source file list from
>>>this xml file specific for the profile currently built.
>>>
>>>
>>>
>>>The included patch includes this tool, and the needed modifications of
>>>the
>>>Makefiles in order to build it and use it.
>>>
>>>We included also the xml file needed to replace System.Data.dll.sources
>>>
>>>
>>>
>>>Please comment on the whole mechanism and let us know what you think
>>>about
>>>it.
>>>
>>>
>>>
>>>Ynon
>>>___
>>>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 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] Novell.Directory.Ldap in the Mono tree

[Eyal Alaluf]

Hi, Miguel.

We had asked the same answer before when we had fixes for 
Novell.Directory.Ldap. What
is the official answer? How do we maintain sync with the Novel sources?

Eyal.

On Tue, 23 Aug 2005, JD Conley wrote:

> Date: Tue, 23 Aug 2005 09:14:08 -0700
> From: JD Conley <[EMAIL PROTECTED]>
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] Novell.Directory.Ldap in the Mono tree
>
> I was wondering if there was any synchronization between
> Novell.Directory.Ldap on Novell forge and Mono. I have noticed that the
> trees are currently fairly different. I'm trying to make a decision on
> which to patch, but I don't really know. I am leaning toward patching
> the one on Novell forge since that seems to be the root, but then when,
> if ever, would my fixes show up in the Mono tree? Would I be stuck
> building my own version of Novell.Directory.Ldap for distribution? Is
> there any particular reason why I should modify the one in the Mono tree
> vs. the one in Novell Forge?
>
> -JD
> ___
> 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] Patch for compiling System.Web/HttpResponseStream.cs under TARGET_JVM

[Eyal Alaluf]

Hi, all.

Attached is a patch for compiling HttpResponseStream.cs under TARGET_JVM.
Under TARGET_JVM (Grasshopper) we don't support unsafe code. I therefore made 
the following
changes to minimize the use of unsafe code and maximize the code sharing:
  * I created a managed version of Chunk for the TARGET_JVM configuration.
  * I made ByteBucket a "safe" class
  * I modified start & pos into indices rather then pointers. I am using 
the Chunk
to maintain the buffer.
During that I removed the field 'len' which was never well maintained. 
I replaced
its use with a local variable everywhere.
  * I added Copy methods to Chunk in order to copy data to and from a 
chunk. This limited
the unsafe code usage to Chunk.
  * I removed the ToString method since it was unsafe - an alternative is 
to mark anyway the
ByteBucket class as unsafe. I'd rather it stays safe so we can more 
easily maintain
common code for this class.
Please provide me with your comments, especially since I am modifying here 
common code to
TARGET_JVM and Mono in order to have a minimal code differences between the two.

Eyal.
Index: System.Web/HttpResponseStream.cs

===

--- System.Web/HttpResponseStream.cs(revision 49056)

+++ System.Web/HttpResponseStream.cs(working copy)

@@ -65,6 +65,100 @@

this.response = response;
}

+#if TARGET_JVM
+   class Chunk
+   {
+   public byte[] data;
+   public int size;
+   public const int Length = 32 * 1024;
+   
+   public Chunk Next, Prev;
+
+   public Chunk () 
+   {
+   data = new byte[Length];
+   size = Length;
+   }
+   
+   public void Dispose ()
+   {
+   }
+   
+   public static Chunk Unlink (ref Chunk head, Chunk b)
+   {
+   if (head == b)
+   head = head.Next;
+   if (b.Prev != null)
+   b.Prev.Next = b.Next;
+   if (b.Next != null)
+   b.Next.Prev = b.Prev;
+
+   b.Next = b.Prev = null;
+   return b;
+   }
+   
+   public static Chunk Link (Chunk head, Chunk b)
+   {
+   b.Next = head;
+   if (head != null)
+   head.Prev = b;
+   return b;
+   }
+
+   public static void Copy(byte[] buff, int offset, Chunk 
c, int pos, int len)
+   {
+   Array.Copy(buff, offset, c.data, pos, len);
+   }
+
+   public static void Copy(Chunk c, int pos, byte[] buff, 
int offset, int len)
+   {
+   Array.Copy(c.data, pos, buff, offset, len);
+   }
+   }
+
+   sealed class BufferManager {
+   static Chunk filled;
+   static Chunk empty;
+   
+   // TODO: if cb > chunk size, try to get a larger chunk
+   public static Chunk GetChunk (int cb)
+   {
+   Chunk c;
+   if (empty == null)
+   empty = new Chunk ();
+   
+   c = empty;
+   filled = Chunk.Link (filled, Chunk.Unlink (ref 
empty, c));
+   return c;
+   }
+   
+   public static void DisposeChunk (Chunk c)
+   {
+   empty = Chunk.Link (empty, Chunk.Unlink (ref 
filled, c));
+   }
+   
+   public static void DisposeEmptyChunks ()
+   {
+   for (Chunk c = empty; c != null; c = c.Next)
+   c.Dispose ();
+   empty = null;
+   }
+   
+   
+   public static void PrintState ()
+   {
+   Console.WriteLine ("Filled blocks:");
+   for (Chunk c = filled; c != null; c = c.Next)
+   Console.Wr

[Mono-dev] Patch for compiling System.Wen/httpApplicationFactory.cs under TARGET_J2EE

[Eyal Alaluf]

Hi, all.

The attached diff is a patch compiling for System.Web/HttpApplicationFactory.cs 
under
the TARGET_J2EE (Grasshoper) configuration.
The main portability issue for TARGET_J2EE handled in this patch is the lack of 
support for an
AppDomain specific static fields. In order to resolve this issue we read the 
value
of static fields that have AppDomain specific value explicitly from AppDomain.
Since HttpApplicationFactory code used many static fields, it made less sense 
to define
a property that gets and sets each value from AppDomain. I instead made all 
these fields
into instance fields and defined a static instance - theFactory - that is used 
to access them.
Therefore the patch contains the following changes:
  * Make all static fields of HttpApplicationFactory into instance fields.
  * Define 'theFactory' as a singleton static instance. Define a TARGET_J2EE 
'theFactory'
property to handle the AppDomain specific retrieval.
  * Make (almost) all the private methods of HttpApplicationFactory into 
instance methods.
  * Use 'theFactory' in the static internal & public methods in order to access 
the fields.
  * Use 'theFactory' as the lock where before 'typeof(HttpApplicationFactory)' 
was used.
  * I modified 'FireOnAppStart' to be a private method since nobody used it 
from outside
of HttpApplicationFactory and it is similar to 'FireOnAppEnd' which is 
private.
  * Add a TARGET_J2EE version of getting the app instance since we don't 
support on the
fly compilation of ASPX pages.

Eyal.

Index: System.Web/HttpApplicationFactory.cs

===

--- System.Web/HttpApplicationFactory.cs(revision 49056)

+++ System.Web/HttpApplicationFactory.cs(working copy)

@@ -47,17 +47,39 @@

 namespace System.Web {
class HttpApplicationFactory {
// Initialized in InitType
-   static bool needs_init = true;
-   static Type app_type;
-   static HttpApplicationState app_state;
-   static FileSystemWatcher app_file_watcher;
-   static FileSystemWatcher bin_watcher;
-   static Stack available = new Stack ();
+#if TARGET_J2EE
+   static HttpApplicationFactory theFactory {
+   get
+   {
+   HttpApplicationFactory factory = 
(HttpApplicationFactory)AppDomain.CurrentDomain.GetData("HttpApplicationFactory");
+   if (factory == null) {
+   lock(typeof(HttpApplicationFactory)) {
+   factory = 
(HttpApplicationFactory)AppDomain.CurrentDomain.GetData("HttpApplicationFactory");
+   if (factory == null) {
+   factory = new 
HttpApplicationFactory();
+   
System.Threading.Thread.Sleep(1);
+   
AppDomain.CurrentDomain.SetData("HttpApplicationFactory", factory);
+   }
+   }
+   }
+   return factory;
+   }
+   }
+#else
+   static HttpApplicationFactory theFactory = new 
HttpApplicationFactory();
+#endif
+
+   bool needs_init = true;
+   Type app_type;
+   HttpApplicationState app_state;
+   FileSystemWatcher app_file_watcher;
+   FileSystemWatcher bin_watcher;
+   Stack available = new Stack ();

// Watch this thing out when getting an instance
-   static IHttpHandler custom_application;
+   IHttpHandler custom_application;
 
-   static bool IsEventHandler (MethodInfo m)
+   bool IsEventHandler (MethodInfo m)
{
if (m.ReturnType != typeof (void))
return false;
@@ -77,7 +99,7 @@

return true;
}
 
-   static void AddEvent (MethodInfo method, Hashtable 
appTypeEventHandlers)
+   void AddEvent (MethodInfo method, Hashtable 
appTypeEventHandlers)
{
string name = method.Name.Replace ("_On", "_");
if (appTypeEventHandlers [name] == null) {
@@ -97,7 +119,7 @@

list.Add (method);
}

-   static Hashtable GetApplicationTypeEvents (HttpApplication app)
+   Hashtable GetApplicationTypeEvents (HttpApplication app)
{
Type appType = app.GetType ();
Hashtable appTypeEventHandlers = new Hashtable ();
@@ -115,7 +137,7 @@

   

Re: [Mono-dev] Patch for compiling System.Web/HttpResponseStream.cs under TARGET_JVM

[Eyal Alaluf]

Hi, Ben.

You are correct. It forced me to make the ByteBucket class unsafe for Mono 
config, but
I hope that difference won't matter in the future.

Eyal.

On Tue, 30 Aug 2005, Ben Maurer wrote:

> Date: Tue, 30 Aug 2005 10:45:08 -0400
> From: Ben Maurer <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Patch for compiling
> System.Web/HttpResponseStream.cs under TARGET_JVM
>
> On Mon, 2005-08-29 at 13:00 +0300, Eyal Alaluf wrote:
> > +#else
> > wr.SendResponseFromMemory ((IntPtr)
> > start, len);
> > +#endif
>
> This looks wrong. IntPtr is now an offset from the beginning of the
> chunk, right?
>
> Did you test this on the standard version?
>
> -- Ben
>
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Fixes for Grasshopper compilation

[Eyal Alaluf]

Hi, all.

Attached are fixes to WebCategoryAttribute.cs & WebSysDescriptionAttribute.cs 
that mark
them as "[AttributeUsage(AttributeTargets.All)]". The MS C# compiler refused to 
compile
System.Web otherwise (from within Grasshopper).
The fix seems innocent enough, though. Any comments?

Eyal.
Index: WebCategoryAttribute.cs

===

--- WebCategoryAttribute.cs (revision 49680)

+++ WebCategoryAttribute.cs (working copy)

@@ -29,6 +29,7 @@

 using System.ComponentModel;
 namespace System.Web {
 
+   [AttributeUsage(AttributeTargets.All)]
internal class WebCategoryAttribute : CategoryAttribute {
 
public WebCategoryAttribute (string category) : base (category)
Index: WebSysDescriptionAttribute.cs

===

--- WebSysDescriptionAttribute.cs   (revision 49680)

+++ WebSysDescriptionAttribute.cs   (working copy)

@@ -29,6 +29,7 @@

 using System.ComponentModel;
 namespace System.Web {
 
+   [AttributeUsage(AttributeTargets.All)]
internal class WebSysDescriptionAttribute : DescriptionAttribute {
 
public WebSysDescriptionAttribute (string description) : base 
(description)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Remove partial(ness) from HttpCapabilitiesBase & HttpBrowserCapabilities

[Eyal Alaluf]

Hi, all.

This fix is a part of building System.Web using MS .Net 1.1 C# compiler. I hope 
that there
are no more plans to expand the use of new C# features in System.Web (or 
elsewhere) for stuff
that is .Net 1.1 compatible.
Any further use of partial or yield in 1.1 parts of System.Web will break the 
Grasshopper build.

Eyal.
Index: System.Web/HttpBrowserCapabilities.cs

===

--- System.Web/HttpBrowserCapabilities.cs   (revision 49680)

+++ System.Web/HttpBrowserCapabilities.cs   (working copy)

@@ -36,13 +36,8 @@

 namespace System.Web
 {
//
-   // The real implementation lives in System.Web/BrowserCapabilities.cs
+   // The implementation lives in System.Web/BrowserCapabilities.cs
//
-   public partial class HttpBrowserCapabilities : HttpCapabilitiesBase
-   {
-   public HttpBrowserCapabilities ()
-   {
-   }
-   }
+   // public class HttpBrowserCapabilities : HttpCapabilitiesBase
 }
 
Index: System.Web/BrowserCapabilities.cs

===

--- System.Web/BrowserCapabilities.cs   (revision 49680)

+++ System.Web/BrowserCapabilities.cs   (working copy)

@@ -35,11 +35,11 @@

 
 #if NET_2_0
 namespace System.Web.Configuration {
-   public partial class HttpCapabilitiesBase
+   public class HttpCapabilitiesBase
 #else
 
 namespace System.Web {
-   public partial class HttpBrowserCapabilities : HttpCapabilitiesBase
+   public class HttpBrowserCapabilities : HttpCapabilitiesBase
 #endif
{
const int HaveActiveXControls = 1;
@@ -95,6 +95,10 @@

Version [] clrVersions;
internal string useragent;
 
+   public HttpBrowserCapabilities ()
+   {
+   }
+
public bool ActiveXControls {
get {
if (!Get (HaveActiveXControls)) {
Index: System.Web.Configuration/HttpCapabilitiesBase.cs

===

--- System.Web.Configuration/HttpCapabilitiesBase.cs(revision 49680)

+++ System.Web.Configuration/HttpCapabilitiesBase.cs(working copy)

@@ -35,7 +35,7 @@

// CAS
[AspNetHostingPermission (SecurityAction.LinkDemand, Level = 
AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission (SecurityAction.InheritanceDemand, Level = 
AspNetHostingPermissionLevel.Minimal)]
-   public partial class HttpCapabilitiesBase
+   public class HttpCapabilitiesBase
{
Hashtable capabilities;
 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Fixes for Grasshopper compilation

[Eyal Alaluf]

Hi, all.

I am not sure where the bug is. It happens only with attributes inheriting from
System.ComponentModel.CategoryAttribute, and as far as I can see 
CategoryAttribute has a
default usage attribute.
It could even be an MS bug, or it could (probably) be some difference between 
how
CategoryAttribute is defined in .Net and in Mono.
The attached 'x.cs' does not compile using csc and compiles with mcs. If you 
think it's
a bug I will file it with this sample.

Eyal.

On Thu, 8 Sep 2005, Ben Maurer wrote:

> Date: Thu, 08 Sep 2005 11:15:49 -0400
> From: Ben Maurer <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Fixes for Grasshopper compilation
>
> On Thu, 2005-09-08 at 16:27 +0300, Eyal Alaluf wrote:
> > Hi, all.
> >
> > Attached are fixes to WebCategoryAttribute.cs & 
> > WebSysDescriptionAttribute.cs that mark
> > them as "[AttributeUsage(AttributeTargets.All)]". The MS C# compiler 
> > refused to compile
> > System.Web otherwise (from within Grasshopper).
> > The fix seems innocent enough, though. Any comments?
>
> Is this an mcs bug? If so, can you file it?
>
> -- Ben
>
>
using System;

using System.ComponentModel;



public class MySimpleAttribute : Attribute { }

internal class MySimple2Attribute : MySimpleAttribute { }

internal class MySimple3Attribute : CategoryAttribute { }



[MySimple2()]

[MySimple3()]

public class Test

{

public static void Main()

{

Type t = typeof(CategoryAttribute);

Object[] a = 
t.GetCustomAttributes(typeof(AttributeUsageAttribute), true);

for (int i = 0; i < a.Length; i++) {

AttributeUsageAttribute x = (AttributeUsageAttribute) 
a[i];

Console.WriteLine("{0} {1}", x.ValidOn, x.Inherited);

}

}

}

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch for compiling PagedDataSource in Grasshopper

[Eyal Alaluf]

Hi, all.

The issue handled is the use of yield in PagedDataSource.cs. I rewrote this 
under
#if TARGET_JVM.
I'd rather have one code base for this (removing the use of yield from the Mono 
code).
I don't see any advantage here for having the two codes side by side.
The main thing I am missing is a good test for PagedDataSource.cs to verify 
that a fix without
#if will work well for Mono.

Eyal.Index: System.Web.UI.WebControls/PagedDataSource.cs

===

--- System.Web.UI.WebControls/PagedDataSource.cs(revision 49680)

+++ System.Web.UI.WebControls/PagedDataSource.cs(working copy)

@@ -240,10 +240,81 @@

return String.Empty; // as documented
}
 
+#if TARGET_JVM
+   internal class ListEnum : IEnumerator
+   {
+   int start;
+   int end;
+   int ind;
+   IList list;
+
+   internal ListEnum(IList list, int start, int end)
+   {
+   this.list = list;
+   this.start = start;
+   this.end = end;
+   this.ind = start - 1;
+   }
+
+   public bool MoveNext()
+   {
+   ind++;
+   return (ind < end);
+   }
+
+   public void Reset() { ind = start - 1; }
+   public object Current { get { return list[ind]; }}
+   }
+
private IEnumerator GetListEnum (IList list, int start, int end)
{
if (!AllowPaging)
end = list.Count;
+   return new ListEnum(list, start, end);
+   }
+
+   internal class EnumeratorEnum : IEnumerator
+   {
+   int start;
+   int end;
+   int ind;
+   IEnumerator en;
+   PagedDataSource parent;
+
+   internal EnumeratorEnum(PagedDataSource parent, 
IEnumerator en, int start, int end)
+   {
+   this.parent = parent;
+   this.en = en;
+   this.start = start;
+   this.end = end;
+   this.ind = start - 1;
+   for (int i = 0; i < start; i++)
+   en.MoveNext ();
+   }
+
+   public bool MoveNext()
+   {
+   ind++;
+   return (!parent.allow_paging || ind < end) && 
en.MoveNext ();
+   }
+
+   public void Reset()
+   {
+   throw new NotSupportedException();
+   }
+
+   public object Current { get { return en.Current; }}
+   }
+
+   private IEnumerator GetEnumeratorEnum (IEnumerator e, int 
start, int end)
+   {
+   return new EnumeratorEnum(this, e, start, end);
+   }
+#else
+   private IEnumerator GetListEnum (IList list, int start, int end)
+   {
+   if (!AllowPaging)
+   end = list.Count;
for (int i = start; i < end; i++)
yield return list [i];
}
@@ -255,5 +326,6 @@

for (int i = start; (!allow_paging || i < end) && 
e.MoveNext (); i++)
yield return e.Current;
}
+#endif
}
 }
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch for compiling HttpApplication for Grasshopper (without use of yield)

[Eyal Alaluf]

Hi, Ben & all.

Attached is a patch to rewrite the 'Pipeline' & 'RunHooks' methods without the 
use of yield.
The code is under '#if TARGET_JVM' and is meant for the Grasshopper 
configuration.
Ben & Miguel - would you prefer having this patch as is (including the #if 
TARGET_J2EE) or
is it acceptable that we will share the new code for Mono and remove the use of 
'yield' from
HttpApplication?
Here is a brief description of the changes:
  * RunHooks creates an instance of RunHooksEnumerator.
  * RunHooksEnumerator is rather simple - it goes over the delegate 
invocation list
and processes each delegate (code taken from the original RunHooks).
If the ProcessDelegate returns true the enumerator MoveNext returns and 
the enumerator
Current value will be the app's stop_processing flag.
  * Pipeline creates and instance of PipeLineEnumerator. PipeLineEnumerator is 
more complex.
  * It main logic is to enumerate delegates through the RunHooks enumerator.
  * I took the central parts of Pipeline and broke them into three methods
AllocateHandler, ProcessHandler & ReleaseHandler. When these methods 
return true the
enumerator MoveNext stops and returns true.
  * The scheduler of Pipeline is in FindNextDelegate which has a switch 
that lists
the delegates that the pipeline enumerates by their order.
  * Tick didn't work as is in the TARGET_J2EE model. We don't manage our own 
thread pool for
ASP.Net (the J2EE servlet does this) and I replaced the 'if 
(pipeline.MoveNext ())'
with a 'while (pipeline.MoveNext ())'. I do not understand well enough how 
the Tick
ticks in Mono, especially where I see in Resume that it does not Tick if 
it's still
in the state of 'in_begin'.
Any comments on the class design and correctness of this rewrite are more then 
welcome.
If you can elaborate more about 'Tick' and how it works in Mono it will help me 
to understand
where the TARGET_J2EE behaves differently and find the correct solution for 
this (I see the
use of 'while' as hack).

Eyal.Index: System.Web/HttpApplication.cs

===

--- System.Web/HttpApplication.cs   (revision 49680)

+++ System.Web/HttpApplication.cs   (working copy)

@@ -553,17 +553,33 @@

//
// Ticks the clock: next step on the pipeline.
//
+#if TARGET_J2EE
void Tick ()
{
try {
+   while (pipeline.MoveNext ()){
+   if ((bool)pipeline.Current) {
+   PipelineDone ();
+   break;
+   }
+   }
+   } catch (Exception e) {
+   Console.WriteLine ("Tick caught an exception 
that has not been propagated:\n" + e.GetType().FullName + e.Message + 
e.StackTrace);
+   }
+   }
+#else
+   void Tick ()
+   {
+   try {
if (pipeline.MoveNext ()){
if ((bool)pipeline.Current)
PipelineDone ();
}
} catch (Exception e) {
-   Console.WriteLine ("Tick caught an exception 
that has not been propagated:\n" + e);
+   Console.WriteLine ("Tick caught an exception 
that has not been propagated:\n" + e.GetType().FullName + e.Message + 
e.StackTrace);
}
}
+#endif
 
void Resume ()
{
@@ -602,14 +618,106 @@


Resume ();
}
-   
+
//
// This enumerator yields whether processing must be stopped:
//true:  processing of the pipeline must be stopped
//false: processing of the pipeline must not be stopped
//
+#if TARGET_JVM
+   internal class RunHooksEnumerator : IEnumerable, IEnumerator
+   {
+   Delegate [] delegates;
+   int currentStep = 0;
+   HttpApplication app;
+
+   internal RunHooksEnumerator(HttpApplication app, 
Delegate list)
+   {
+   this.app = app;
+   delegates = list.GetInvocationList ();
+   }
+
+   public virtual IEnumerator GetEnumerator() { return 
this; }
+   public virtual object Current { get{ return 
app.stop_processing; } }
+   public virtual void Reset()
+   {
+ 

[Mono-dev] Compiling System.Web with CSC

[Eyal Alaluf]

Hi, Miguel.

Grasshopper requires the use of Microsoft C# compiler. As mentioned before we
depend upon the pdb file for our debugging support.
In the patches I have sent I have removed the dependency on C# 2.0 features
from System.Web (under #if TARGET_J2EE/JVM). However, if System.Web adds more
dependencies upon c# 2.0 features the amount of #if will increase and make the
code less & less maintainable.

From the changes I have made so far, I can say that the use of 'partial' is

currently minimal. I could remove it easily without a real impact on the
code quality.
The use of enumerators (apart from HttpApplication) is very small and although
it is cute, it is not critical to code quality. It becomes counter productive
when we add the C# 1.0 code side by side with the new enumerator code.

I suggest that we decide together not to increase the dependency on c# 2.0
features in System.Web (1.1 configuration). I believe that it is a simple
and practical approach without many side effects.
What do you think?

Eyal.


-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 24, 2005 9:18 PM
To: Gert Driesen
Cc: 'Ben Maurer'; Eyal Alaluf; mono-devel-list@lists.ximian.com
Subject: RE: [Mono-dev] Re: Patch for compiling HttpApplication
forGrasshopper(without use of yield)

Hello,


That means it has been decided that Mono (at least System.Web) will no



longer build using MS.NET 1.x, right ?


Yes, that is correct.

To compile System.Web you will need Mono's C# compiler, as our C#
compiler can produce 1.x assemblies and still allow you to use C# 2.0
features.

This is going to be used more as we avoid having to maintain our own
GetEnumerator() code and as we use partial classes to cope with the
reorganization that has happened between 1.x and 2.x libraries.

Without partial classes we would have to maintain too much duplicated
code and we do not intend to do that.

Miguel.


a
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Compiling System.Web with CSC

[Eyal Alaluf]

Hi, Miguel.

How easy is this solution and when do you estimate you can implement it?

I believe we will need to add additional non trivial tasks:
  * Integration and testings with our debugger to see that the pdb file indeed
contains all the debug information we require and that all works correctly.
  * Integration of our compiler tools with mcs. Currently, mcs does not work
with the IL code we generate from Java .jar files. I believe that the
issues are mostly in our generator, but it's an additional effort we need
to count.
Only after all of the above is resolved and working we can start to use mcs
for our System.Web build.

Eyal.

On Tue, 27 Sep 2005, Miguel de Icaza wrote:


Date: Tue, 27 Sep 2005 11:50:41 -0400
From: Miguel de Icaza <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: mono-devel-list@lists.ximian.com, Philippe Cohen <[EMAIL PROTECTED]>,
Noam Lampert <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [Mono-dev] Compiling System.Web with CSC

Hello,


I suggest that we decide together not to increase the dependency on c# 2.0
features in System.Web (1.1 configuration). I believe that it is a simple
and practical approach without many side effects.
What do you think?


I think it is a bad idea, specially considering that it means that we
have to write more and debug more code than we otherwise would.

There is an easy solution that I mentioned before which is that we can
add support to mcs to generate pdb files instead.

MCS already uses the API to generate debugging information, the only
difference is that it consumes a Mono-specific API instead of the
cross-platform API.

We did not use the cross-platform API in the past because we did not
have information on how to use it, but now IronPython has code that
shows how to use it.

Miguel.


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Compiling System.Web with CSC

[Eyal Alaluf]

Hi, Miguel.

The option of playing with ilasm/ildasm will mess out completely the debug
information. PDB uses the tokens from the DLL to identify the class, method,
etc. The tokens will be completely messed up by this exercise.
I will look at the output of ildasm to analyze better the .Net 2.0 dependencies
to see if we can come up with some kind of hack for using the CSC 2.0 compiler.

Eyal.

On Tue, 27 Sep 2005, Miguel de Icaza wrote:


Date: Tue, 27 Sep 2005 18:12:03 -0400
From: Miguel de Icaza <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Noam Lampert <[EMAIL PROTECTED]>,
Philippe Cohen <[EMAIL PROTECTED]>, mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Compiling System.Web with CSC

Hello,


I think it is a bad idea, specially considering that it means that we
have to write more and debug more code than we otherwise would.

There is an easy solution that I mentioned before which is that we can
add support to mcs to generate pdb files instead.

MCS already uses the API to generate debugging information, the only
difference is that it consumes a Mono-specific API instead of the
cross-platform API.

We did not use the cross-platform API in the past because we did not
have information on how to use it, but now IronPython has code that
shows how to use it.


Alternatively to upgrading mcs, you can use csc, and then do:

ildasm /out:output file.dll
sed script
ilasm output.il

Where the sed script would remove the couple of new keywords on ildasm
and replace the 2.x references with 1.x references.


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Compiling System.Web with CSC

[Eyal Alaluf]

Hi, all.

We prefer the solution where mcs is generating pdb files. This solution is well 
aligned
with our strategy for the long term. In case the mcs/pdb project is not so 
simple and
easy to implement soon, we need to examine the shorter term solutions.

Checking the approach of using .Net 2.0 compiler, I took a less hacky approach 
where
I analyzed the assembly created by .Net 2.0 compiler (using ildasm) and added 
to our
binary compiler the few new .Net 2.0 opcodes that were used. I will still need 
to see
how to read the PDB files of MS .Net 2.0, but this should be feasible.

Eyal.

On Wed, 28 Sep 2005, Kornél Pál wrote:


Date: Wed, 28 Sep 2005 18:04:59 +0200
From: Kornél Pál <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>, Miguel de Icaza <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], mono-devel-list@lists.ximian.com,
Philippe Cohen <[EMAIL PROTECTED]>, Noam Lampert <[EMAIL PROTECTED]>
Subject: Re: [Mono-dev] Compiling System.Web with CSC

Hi,

MS ildasm is able to extract information from PDB files to IL code. If there
is a PDB file it includes variable names in IL code an with /linenum switch
it will emit line number information as well.

MS ilasm generates a PDB with /debug switch that will contain the names of
local variables and line numbers. And I think all the other usual symbols.

Kornél

- Original Message -
From: "Eyal Alaluf" <[EMAIL PROTECTED]>
To: "Miguel de Icaza" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; ; "Philippe
Cohen" <[EMAIL PROTECTED]>; "Noam Lampert" <[EMAIL PROTECTED]>
Sent: Wednesday, September 28, 2005 5:52 PM
Subject: Re: [Mono-dev] Compiling System.Web with CSC



Hi, Miguel.

The option of playing with ilasm/ildasm will mess out completely the debug
information. PDB uses the tokens from the DLL to identify the class,
method,
etc. The tokens will be completely messed up by this exercise.
I will look at the output of ildasm to analyze better the .Net 2.0
dependencies
to see if we can come up with some kind of hack for using the CSC 2.0
compiler.

Eyal.

On Tue, 27 Sep 2005, Miguel de Icaza wrote:


Date: Tue, 27 Sep 2005 18:12:03 -0400
From: Miguel de Icaza <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Noam Lampert <[EMAIL PROTECTED]>,
Philippe Cohen <[EMAIL PROTECTED]>, 
mono-devel-list@lists.ximian.com

Subject: Re: [Mono-dev] Compiling System.Web with CSC

Hello,


I think it is a bad idea, specially considering that it means that we
have to write more and debug more code than we otherwise would.

There is an easy solution that I mentioned before which is that we can
add support to mcs to generate pdb files instead.

MCS already uses the API to generate debugging information, the only
difference is that it consumes a Mono-specific API instead of the
cross-platform API.

We did not use the cross-platform API in the past because we did not
have information on how to use it, but now IronPython has code that
shows how to use it.


Alternatively to upgrading mcs, you can use csc, and then do:

ildasm /out:output file.dll
sed script
ilasm output.il

Where the sed script would remove the couple of new keywords on ildasm
and replace the 2.x references with 1.x references.


___
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] Compiling System.Web with CSC

[Eyal Alaluf]

I ran the compiler with -nostdlib and gave it reference to .Net 1.1 libraries.
This did the trick.

On Tue, 11 Oct 2005, Ben Maurer wrote:


Date: Tue, 11 Oct 2005 13:52:48 -0400
From: Ben Maurer <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: Kornél Pál <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
Noam Lampert <[EMAIL PROTECTED]>, Miguel de Icaza <[EMAIL PROTECTED]>,
Philippe Cohen <[EMAIL PROTECTED]>, mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Compiling System.Web with CSC

On Tue, 2005-10-11 at 19:34 +0200, Eyal Alaluf wrote:

Hi, all.

We prefer the solution where mcs is generating pdb files. This solution is well 
aligned
with our strategy for the long term. In case the mcs/pdb project is not so 
simple and
easy to implement soon, we need to examine the shorter term solutions.

Checking the approach of using .Net 2.0 compiler, I took a less hacky approach 
where
I analyzed the assembly created by .Net 2.0 compiler (using ildasm) and added 
to our
binary compiler the few new .Net 2.0 opcodes that were used. I will still need 
to see
how to read the PDB files of MS .Net 2.0, but this should be feasible.


How are you guys handling generics in Array? In 2.0, array has methods
like:

public static int IndexOf (T [] array, T value)

Method overloading will redirect calls that before were non-generic to
generic calls in 2.0.

-- Ben

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Compiling System.Web with CSC

[Eyal Alaluf]

I just actually need to check if there is a new version of DIA for .Net 2.0
PDBs. I saw the .Net 1.1 compilers crashing when they had 2.0 pdbs accessible
so I am just not sure about this. But the issue is certainly resolvable.

On Tue, 11 Oct 2005, Kornél Pál wrote:


Date: Tue, 11 Oct 2005 19:49:22 +0200
From: Kornél Pál <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Noam Lampert <[EMAIL PROTECTED]>,
Miguel de Icaza <[EMAIL PROTECTED]>, Philippe Cohen <[EMAIL PROTECTED]>,
mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Compiling System.Web with CSC

Hi,

I think the only solution to read PDB files is to use DIA. If you do so
there is no difference between .NET 1.1. a .NET 2.0 PDB files as you can
read the using the same interfaces methods. In other words your DIA base
code should work with .NET 2.0 PDB files as well.

Or do you use some other solution to read PDB files?

Kornél

- Original Message -
From: "Eyal Alaluf" <[EMAIL PROTECTED]>
To: "Kornél Pál" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Noam Lampert" <[EMAIL PROTECTED]>; "Miguel de
Icaza" <[EMAIL PROTECTED]>; "Philippe Cohen" <[EMAIL PROTECTED]>;

Sent: Tuesday, October 11, 2005 7:34 PM
Subject: Re: [Mono-dev] Compiling System.Web with CSC



Hi, all.

We prefer the solution where mcs is generating pdb files. This solution is
well aligned
with our strategy for the long term. In case the mcs/pdb project is not so
simple and
easy to implement soon, we need to examine the shorter term solutions.

Checking the approach of using .Net 2.0 compiler, I took a less hacky
approach where
I analyzed the assembly created by .Net 2.0 compiler (using ildasm) and
added to our
binary compiler the few new .Net 2.0 opcodes that were used. I will still
need to see
how to read the PDB files of MS .Net 2.0, but this should be feasible.

Eyal.

On Wed, 28 Sep 2005, Kornél Pál wrote:


Date: Wed, 28 Sep 2005 18:04:59 +0200
From: Kornél Pál <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>, Miguel de Icaza 
<[EMAIL PROTECTED]>

Cc: [EMAIL PROTECTED], mono-devel-list@lists.ximian.com,
Philippe Cohen <[EMAIL PROTECTED]>, Noam Lampert
<[EMAIL PROTECTED]>
Subject: Re: [Mono-dev] Compiling System.Web with CSC

Hi,

MS ildasm is able to extract information from PDB files to IL code. If
there
is a PDB file it includes variable names in IL code an with /linenum
switch
it will emit line number information as well.

MS ilasm generates a PDB with /debug switch that will contain the names
of
local variables and line numbers. And I think all the other usual
symbols.

Kornél

- Original Message -
From: "Eyal Alaluf" <[EMAIL PROTECTED]>
To: "Miguel de Icaza" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; ; "Philippe
Cohen" <[EMAIL PROTECTED]>; "Noam Lampert" <[EMAIL PROTECTED]>
Sent: Wednesday, September 28, 2005 5:52 PM
Subject: Re: [Mono-dev] Compiling System.Web with CSC



Hi, Miguel.

The option of playing with ilasm/ildasm will mess out completely the
debug
information. PDB uses the tokens from the DLL to identify the class,
method,
etc. The tokens will be completely messed up by this exercise.
I will look at the output of ildasm to analyze better the .Net 2.0
dependencies
to see if we can come up with some kind of hack for using the CSC 2.0
compiler.

Eyal.

On Tue, 27 Sep 2005, Miguel de Icaza wrote:


Date: Tue, 27 Sep 2005 18:12:03 -0400
From: Miguel de Icaza <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Noam Lampert <[EMAIL PROTECTED]>,
Philippe Cohen <[EMAIL PROTECTED]>,
mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Compiling System.Web with CSC

Hello,

I think it is a bad idea, specially considering that it means that 
we

have to write more and debug more code than we otherwise would.

There is an easy solution that I mentioned before which is that we 
can

add support to mcs to generate pdb files instead.

MCS already uses the API to generate debugging information, the 
only

difference is that it consumes a Mono-specific API instead of the
cross-platform API.

We did not use the cross-platform API in the past because we did 
not
have information on how to use it, but now IronPython has code 
that

shows how to use it.


Alternatively to upgrading mcs, you can use csc, and then do:

ildasm /out:output file.dll
sed script
ilasm output.il

Where the sed script would remove the couple of new keywords on 
ildasm

and replace the 2.x references with 1.x references.


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list







-

Re: [Mono-dev] [Mono-patches] r52427 - trunk/mcs/mbas

[Eyal Alaluf]

Hi, Rafael.

Can you point me to this test case location? It seems like an issue we haven't 
sen before
as well in Grasshoper.

Thanks, Eyal.

On Tue, 1 Nov 2005, Rafael Teixeira wrote:


Date: Tue, 1 Nov 2005 11:55:08 -0200
From: Rafael Teixeira <[EMAIL PROTECTED]>
To: Miguel de Icaza <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
Subject: Re: [Mono-dev] [Mono-patches] r52427 - trunk/mcs/mbas

Well this is what vbc generates either way:

   .locals init (
   valuetype ExpressionLiteralsNothing/MyStructV_0)
   IL_:  ldnull
   IL_0001:  dup
   IL_0002:  brtrue.s IL_0014

   IL_0004:  pop
   IL_0005:  ldtoken ExpressionLiteralsNothing/MyStruct
   IL_000a:  call class [mscorlib]System.Type class
[mscorlib]System.Type::GetTypeFromHandle(valuetype
[mscorlib]System.RuntimeTypeHandle)
   IL_000f:  call object class
[mscorlib]System.Activator::CreateInstance(class
[mscorlib]System.Type)
   IL_0014:  unbox ExpressionLiteralsNothing/MyStruct
   IL_0019:  ldobj ExpressionLiteralsNothing/MyStruct
   IL_001e:  stloc.0

So the struct is "synthesized" from a null (very non-c#) either way
(regarding Option Strict). :)

OK?


On 11/1/05, Rafael Teixeira <[EMAIL PROTECTED]> wrote:

Hi Miguel,

The team is already working on it, but there is a test written by
Ritvik (ExpressionLiteralNothingB.vb) that shows this behaviour is
consistent with what vbc does.

I've told Maverson just to explore further to make sure if this
behaviour is affected by Option Strict On (the default, as in the test
source where the directive is omitted, is Off).

Regards,

On 10/31/05, Miguel de Icaza <[EMAIL PROTECTED]> wrote:

Hello,

The code in that revision for UnboxCast looks suspiciously wrong.
It creates an empty object if child expression leaves a null on the
stack.

Also, it would be convenient if you added a test case that showed
this problem.
--
Miguel de Icaza <[EMAIL PROTECTED]>
Novell, Inc.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list




--
Rafael "Monoman" Teixeira
---
I'm trying to become a "Rosh Gadol" before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!




--
Rafael "Monoman" Teixeira
---
I'm trying to become a "Rosh Gadol" before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!
___
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] [PATCH] don't write stack trace on stackoverflow

[Eyal Alaluf]

Maybe a limited stack - say the last 50 frames, would be better? It defintely
hard to understand a stack overflow without at least part of the stack.

Eyal.

On Fri, 23 Dec 2005, Jb Evain wrote:


Date: Fri, 23 Dec 2005 23:11:20 +0100
From: Jb Evain <[EMAIL PROTECTED]>
To: mono-devel-list 
Subject: [Mono-dev] [PATCH] don't write stack trace on stackoverflow

Hi,

This small patch prevents the stack trace from being printed when a 
stackoverflow happens.

Ok to commit ?

Jb


exception.patch
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Dir.Services - small refactoring

[Eyal Alaluf]

Hi, Kosta.

I have two remarks regarding the change in ObjectArray:
  * You should use the 'Clear' method instead of setting 'this[i] = null'.
  * The original code documents that it is clearing up the original array. It 
even tries
to do this using 'ToSrray()[i] = null'. However, this is a serious bug 
becuase
'ToArray()' always creates a new array each time  and so doing 
'ToArray()[i] = null'
has absolutely no side effects (except on performance :-). I believe that 
you should
verify that fixing this bug has no side effects in System.DirectoryServices 
code.

Eyal.

On Thu, 26 Jan 2006, Konstantin Triger wrote:


Date: Thu, 26 Jan 2006 04:36:52 -0800
From: Konstantin Triger <[EMAIL PROTECTED]>
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] [PATCH] Dir.Services - small refactoring

Hello all,



I made some refactoring reducing number of objects created.

Please review the attached patch before I commit.



Regards,

Konstantin Triger





perf.patch
Description: perf.patch
___
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: [Mono-patches] r56477 - trunk/mcs/class/corlib/System

[Eyal Alaluf]

Hi, Gonzalo.

Wouldn't it make sense to make the Ordinal case inside GetCultureForOption
return InvariantCulture? Returning CurrentCulture means an extra TLS lookup.
Original code:

+   CultureInfo GetCultureForOption (StringComparison comp)
+   {
+   switch (comp) {
+   case StringComparison.InvariantCulture:
+   case StringComparison.InvariantCultureIgnoreCase:
+   return CultureInfo.InvariantCulture;
+   case StringComparison.CurrentCulture:
+   case StringComparison.CurrentCultureIgnoreCase:
+   case StringComparison.Ordinal:
+   case StringComparison.OrdinalIgnoreCase:
+   return CultureInfo.CurrentCulture;

Possible change:

+   CultureInfo GetCultureForOption (StringComparison comp)
+   {
+   switch (comp) {
+   case StringComparison.InvariantCulture:
+   case StringComparison.InvariantCultureIgnoreCase:
+   case StringComparison.Ordinal:
+   case StringComparison.OrdinalIgnoreCase:
+   return CultureInfo.InvariantCulture;
+   case StringComparison.CurrentCulture:
+   case StringComparison.CurrentCultureIgnoreCase:
+   return CultureInfo.CurrentCulture;


Eyal.

On Thu, 2 Feb 2006, Gonzalo Paniagua wrote:


Date: Thu,  2 Feb 2006 11:36:10 -0500 (EST)
From: Gonzalo Paniagua <[EMAIL PROTECTED]>
To: mono-patches@lists.ximian.com, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: [Mono-patches] r56477 - trunk/mcs/class/corlib/System

Author: gonzalo
Date: 2006-02-02 11:36:09 -0500 (Thu, 02 Feb 2006)
New Revision: 56477

Modified:
  trunk/mcs/class/corlib/System/ChangeLog
  trunk/mcs/class/corlib/System/String.cs
Log:
2006-02-02 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>

* String.cs: implement 2.0 StartsWith and EndsWith new overloads. Based
on a patch by Thong Nguyen.



Modified: trunk/mcs/class/corlib/System/ChangeLog
===
--- trunk/mcs/class/corlib/System/ChangeLog 2006-02-02 16:12:47 UTC (rev 
56476)
+++ trunk/mcs/class/corlib/System/ChangeLog 2006-02-02 16:36:09 UTC (rev 
56477)
@@ -1,3 +1,8 @@
+2006-02-02 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
+
+   * String.cs: implement 2.0 StartsWith and EndsWith new overloads. Based
+   on a patch by Thong Nguyen.
+
2006-01-31  Zoltan Varga  <[EMAIL PROTECTED]>

* String.cs: Implement one of the new net 2.0 Split methods.

Modified: trunk/mcs/class/corlib/System/String.cs
===
--- trunk/mcs/class/corlib/System/String.cs 2006-02-02 16:12:47 UTC (rev 
56476)
+++ trunk/mcs/class/corlib/System/String.cs 2006-02-02 16:36:09 UTC (rev 
56477)
@@ -925,6 +925,63 @@
}

#if NET_2_0
+   CompareOptions GetCompareOptions (StringComparison comp)
+   {
+   switch (comp) {
+   case StringComparison.InvariantCulture:
+   case StringComparison.CurrentCulture:
+   return CompareOptions.None;
+   case StringComparison.CurrentCultureIgnoreCase:
+   case StringComparison.InvariantCultureIgnoreCase:
+   return CompareOptions.IgnoreCase;
+   case StringComparison.Ordinal:
+   return CompareOptions.Ordinal;
+   case StringComparison.OrdinalIgnoreCase:
+   return CompareOptions.OrdinalIgnoreCase;
+   default:
+   return 0; // If GetCultureForOption returns 
null, we never call this one.
+   }
+   }
+
+   CultureInfo GetCultureForOption (StringComparison comp)
+   {
+   switch (comp) {
+   case StringComparison.InvariantCulture:
+   case StringComparison.InvariantCultureIgnoreCase:
+   return CultureInfo.InvariantCulture;
+   case StringComparison.CurrentCulture:
+   case StringComparison.CurrentCultureIgnoreCase:
+   case StringComparison.Ordinal:
+   case StringComparison.OrdinalIgnoreCase:
+   return CultureInfo.CurrentCulture;
+   default:
+   return null;
+   }
+   }
+
+   public bool StartsWith (string value, StringComparison 
comparisonType)
+   {
+   CultureInfo cultu

Re: [Mono-dev] [PATCH] MS/Mono incompatibility in System.Web.HttpRequest

[Eyal Alaluf]

Hi, Edward.

Is it not enough to use: "<[a-zA-Z\\!]" as the RegEx instead of "<[a-zA-Z\\!]+"?
It works much faster (since RegEx tries always for the biggest match possible) 
and it
does exactly the same thing.

Eyal.

On Wed, 15 Feb 2006, Edward C. Eisenbrey wrote:


Date: Wed, 15 Feb 2006 13:44:50 -0500
From: Edward C. Eisenbrey <[EMAIL PROTECTED]>
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] [PATCH] MS/Mono incompatibility in System.Web.HttpRequest

Attached is the patch including all the changes mentioned.


-Original Message-
From: Joshua Kugler [mailto:[EMAIL PROTECTED]
Sent: Monday, February 13, 2006 5:12 PM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] MS/Mono incompatibility in
System.Web.HttpRequest

On Monday 13 February 2006 12:49, Luca wrote:

Il Mon, Feb 13, 2006 at 11:20:53AM -0900, Joshua Kugler ha scritto:

On Monday 13 February 2006 11:12, Alex Chudnovsky wrote:

Edward C. Eisenbrey wrote:

using System.Text.RegularExpressions;

static bool CheckString (string val)
{
Regex regex = new Regex("<[a-zA-Z\\!]+");
Match match = regex.Match(val);
return match.Success;
}


Pardon my instrusion, but would it not be better performance wise

to

create static instance of the regexp to avoid doing it every time
CheckString called? Ie:

static Regex regex = new Regex("<[a-zA-Z\\!]+");

static bool CheckString (string val)
{

Match match = regex.Match(val);
return match.Success;
}


Or at least declare it static in the sub (I assume you can do that)?


Well, no :) The "sub" is a method, so the regex object must be a

static

member of the class. Back on the original topic, if that codepath is

realy

performance critical you can even compile the Regex:


Ah! I missed the part about the method being part of a class.  Yes, a
static
class member would probably be best.

j- k-

--
Joshua Kugler PGP Key: http://pgp.mit.edu/
CDE System Administrator ID 0xDB26D7CE
http://distance.uaf.edu/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list





file2.diff
Description: file2.diff
___
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] System.Runtime.Remoting.RemotingConfigurationConfigure Patch

[Eyal Alaluf]

Hi, Jonathan.

 

MonoNotSupported denotes the fact that the API is completely unimplemented. I 
propose that you use MonoLimitation in this case, instead. MonoLimitaion 
denotes the fact that the API is partially implemented. The text is displayed 
by documentation tools (am not sure about NUMA).

 

Eyal.



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Chambers
Sent: 03 May 2007 13:36
To: Andrés G. Aragoneses [ knocte ]
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] System.Runtime.Remoting.RemotingConfigurationConfigure 
Patch

 

Perhaps I should use a more specific MonoTODOAttribute; 
MonoNotSupportedAttribute perhaps?

- Jonathan

On 5/3/07, "Andrés G. Aragoneses [ knocte ]" <[EMAIL PROTECTED]> wrote:

Jonathan Chambers escribió: 
>  Attached is patch to add 2.0 overload of Configure method in
> System.Runtime.Remoting.RemotingConfiguration. This was done the same
> way as System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel .

Shouldn't that MonoTODO be converted into a FIXME? That one is not
giving much information for a potential MoMA user.

Regards,

Andrés  [ knocte ]

--

___ 
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: [Mono-patches] r77337 - inbranches/mainsoft/gh20/mcs/class/System.Web: System.WebSystem.Web.Configuration_2.0

[Eyal Alaluf]

Hi, Igor.

I believe that you still need to lock the configuration when you add an
element to it. Or is it OK for the WebConfigurationHost instance not to
unique under stress (if there is a race to initialize it).

@@ -186,13 +186,8 @@
 
conf = (_Configuration) configurations [path];
if (conf == null) {
-   lock (configurations) {
-   conf = (_Configuration)
configurations [path];
-   if (conf == null) {
conf =
ConfigurationFactory.Create (typeof (WebConfigurationHost), null, path,
site, locationSubPath, server, userName, password);
configurations [path] =
conf;
-   }
-   }
}
return conf;
}

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Igor
Zalmanovich ([EMAIL PROTECTED])
Sent: 14 May 2007 11:56
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [Mono-patches] r77337 -
inbranches/mainsoft/gh20/mcs/class/System.Web:
System.WebSystem.Web.Configuration_2.0

Author: igorz
Date: 2007-05-14 05:56:09 -0400 (Mon, 14 May 2007)
New Revision: 77337

Modified:
 
branches/mainsoft/gh20/mcs/class/System.Web/System.Web.Configuration_2.0
/ChangeLog
 
branches/mainsoft/gh20/mcs/class/System.Web/System.Web.Configuration_2.0
/WebConfigurationManager.cs
   branches/mainsoft/gh20/mcs/class/System.Web/System.Web/ChangeLog
 
branches/mainsoft/gh20/mcs/class/System.Web/System.Web/HttpApplication.c
s
Log:
merged r77335-77336

Modified:
branches/mainsoft/gh20/mcs/class/System.Web/System.Web/ChangeLog
===
--- branches/mainsoft/gh20/mcs/class/System.Web/System.Web/ChangeLog
2007-05-14 09:47:41 UTC (rev 77336)
+++ branches/mainsoft/gh20/mcs/class/System.Web/System.Web/ChangeLog
2007-05-14 09:56:09 UTC (rev 77337)
@@ -1,3 +1,9 @@
+2007-05-14 Igor Zelmanovich <[EMAIL PROTECTED]>
+
+   * HttpApplication.cs:
+   prevent DOS attack: remove configuration from the cache in case 
+   of invalid resource not exists  
+
 2007-05-14  Vladimir Krasnov  <[EMAIL PROTECTED]>
 
* TraceContext.cs: refactoring, cached TraceManager

Modified:
branches/mainsoft/gh20/mcs/class/System.Web/System.Web/HttpApplication.c
s
===
---
branches/mainsoft/gh20/mcs/class/System.Web/System.Web/HttpApplication.c
s   2007-05-14 09:47:41 UTC (rev 77336)
+++
branches/mainsoft/gh20/mcs/class/System.Web/System.Web/HttpApplication.c
s   2007-05-14 09:56:09 UTC (rev 77337)
@@ -145,6 +145,7 @@
 #else
static Exception initialization_exception;
 #endif
+   bool removeConfigurationFromCache;
 #else
HandlerFactoryConfiguration factory_config;
 #endif
@@ -641,6 +642,14 @@
}
}
stop_processing = true;
+#if NET_2_0
+   // we want to remove configuration from the
cache in case of 
+   // invalid resource not exists to prevent DOS
attack.
+   HttpException httpEx = e as HttpException;
+   if (httpEx != null && httpEx.GetHttpCode () ==
404) {
+   removeConfigurationFromCache = true;
+   }
+#endif
}

//
@@ -1096,6 +1105,12 @@
 
void PostDone ()
{
+#if NET_2_0
+   if (removeConfigurationFromCache) {
+
WebConfigurationManager.RemoveConfigurationFromCache (context);
+   removeConfigurationFromCache = false;
+   }
+#endif
Thread th = Thread.CurrentThread;
 #if !TARGET_JVM
if (Thread.CurrentPrincipal != prev_user)

Modified:
branches/mainsoft/gh20/mcs/class/System.Web/System.Web.Configuration_2.0
/ChangeLog
===
---
branches/mainsoft/gh20/mcs/class/System.Web/System.Web.Configuration_2.0
/ChangeLog  2007-05-14 09:47:41 UTC (rev 77336)
+++
branches/mainsoft/gh20/mcs/class/System.Web/System.Web.Configuration_2.0
/ChangeLog  2007-05-14 09:56:09 UTC (rev 77337)
@@ -1,3 +1,9 @@
+2007-05-14  Igor Zelmanovich <[EMAIL PROTECTED]>
+
+   * WebConfigurationManager.cs: 
+   make configurations synchronized.
+   added new internal method RemoveConfigurationFromCache.
+
 2007-04-19  Marek Habersack  <[EMAIL PROTECTED]>
 
* HttpHandlerAction.cs: look up types in all the toplevel

Modified:
branches/mainsoft/gh20/mcs/class/System.Web/System.Web.Configuration_2.0
/WebConfigurationManager.cs

[Mono-dev] : DateTime.Parse patch

[Eyal Alaluf]

Hi, all.

Attached is a patch for the infamous DateTime.Parse method.
The current logic for Parse is to try all the culture date time formats
and then try some special formats in invariant culture.
This solution is not sufficient because it is not very compatible with
MS behavior, it is difficult to maintain and is very inefficient.

The current patch aims to improve all of these issues. The patch defines
two sets of formats 'date' only formats and 'time' only formats.
The Parse method will check all the date formats for a match. If the
date format matches the string beginning it will combine it with all the
time formats. It will check similarly all the time formats and match to
them the date formats.
Only if this fails it will look at all the culture date formats (making
the TrypParse negative flow still very slow). This is done because
additional effort is required to define the culture specific separators.
The result is that many more formats are recognizable by DateTime.Parse
and that it is easier to add formats if necessary.

In different flows the patch improves performance by a factor of 3-5
times on Mono.

Please review and provide feedback since this is a fairly major change
to a really sensitive spot.

Eyal.


DateTime.patch
Description: DateTime.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] : DateTime.Parse patch

[Eyal Alaluf]

My miss. I must have tried to check on .Net without the Japanese culture
setting. I'll fix that.

Thanks, Eyal.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sebastien
Pouliot
Sent: 16 August 2007 14:01
To: Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] : DateTime.Parse patch

Hello Eyal,

Quick questions: 
- Why is there a change to the unit tests ? 
- Is it a bad test (not working on MS) ?

Thanks
Sebastien

On Wed, 2007-08-15 at 07:03 -0700, Eyal Alaluf wrote:
> Index: Test/System/DateTimeTest.cs
> ===
> --- Test/System/DateTimeTest.cs (revision 84140)
> +++ Test/System/DateTimeTest.cs (working copy)
> @@ -1540,7 +1540,7 @@
> Thread.CurrentThread.CurrentCulture = new
> CultureInfo ("ja-JP");
> string y = string.Format ("{0}-{1}-{2} {3}",
> DateTime.Now.Year.ToString (),
> "11", "29", "06:34");
> -   DateTime date = DateTime.ParseExact (y,
> "-MMM-dd hh:mm", null);
> +   DateTime date = DateTime.ParseExact (y,
> "-MM-dd hh:mm", null);
> Assert.AreEqual (DateTime.Now.Year, date.Year,
> "#1");
> Assert.AreEqual (11, date.Month, "#2");
> Assert.AreEqual (29, date.Day, "#3");
> 
-- 
Sebastien Pouliot  <[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: [Mono-dev] : DateTime.Parse patch

[Eyal Alaluf]

Hi, Atsushi.

Thanks to your remark I checked again and saw that MS behaviour is to
decide upon the month day and year order according to the
ShortDatePattern in all cases.
When I wrote the code I thought that '/MM/dd' didn't indicate the
order but I was wrong.
So actually, the switch is not necessary. Instead checking if 'd'
appears before 'M' is enough.
I actually went ahead and modified the
culture.DateTimeFormat.ShortDatePattern and this modification overrode
the decision if 1/10 is Oct 1st or Jan 10th.
This brought up another complication since I didn't consider the order
of the year according to this pattern and if it says '/MM/dd' then
'01/02/03' actually means '2001 Feb 3rd' and 'dd/MM/' would spit
'2003 Feb 1st'.
I am adding the year logic and will prepare next week a new patch.

Eyal.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Atsushi
Eno
Sent: 16 August 2007 05:19
To: Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] : DateTime.Parse patch

Hello,

I like the effort to improve DateTime.Parse(), but I think your
approach is broken. The switch-case that looks at 
DateTimeFormatInfo.CultureID could be problematic especially
when a DateTimeFormatInfo is cloned and then its format strings
are modified (note that there are setters on DateTimeFormatInfo
members).

Atsushi Eno

Eyal Alaluf wrote:
> Hi, all.
> 
> Attached is a patch for the infamous DateTime.Parse method.
> The current logic for Parse is to try all the culture date time
formats
> and then try some special formats in invariant culture.
> This solution is not sufficient because it is not very compatible with
> MS behavior, it is difficult to maintain and is very inefficient.
> 
> The current patch aims to improve all of these issues. The patch
defines
> two sets of formats 'date' only formats and 'time' only formats.
> The Parse method will check all the date formats for a match. If the
> date format matches the string beginning it will combine it with all
the
> time formats. It will check similarly all the time formats and match
to
> them the date formats.
> Only if this fails it will look at all the culture date formats
(making
> the TrypParse negative flow still very slow). This is done because
> additional effort is required to define the culture specific
separators.
> The result is that many more formats are recognizable by
DateTime.Parse
> and that it is easier to add formats if necessary.
> 
> In different flows the patch improves performance by a factor of 3-5
> times on Mono.
> 
> Please review and provide feedback since this is a fairly major change
> to a really sensitive spot.
> 
> Eyal.
> 
> 
>

> 
> ___
> 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] : DateTime.Parse patch

[Eyal Alaluf]

Hi, Atsushi.

The eu-ES locale has a wrong MonthDayPattern. Its '' instead of
' dd'. This is why I added this line.
How do you change the locale data?

The 'valuePos >= ' occurred during development (I think it was some
white space skipping). I'll run a pass at minimizing these checks.

I'll remove the comment about the bug-fix and add a test case for this.

Thanks for the comments, Eyal.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Atsushi
Eno
Sent: 21 August 2007 10:31
To: Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] : DateTime.Parse patch

Hi,

Comments part by part (as you have attached the patch as octet-stream
I cannot simply quote them like others' patches):

+   int dayIndex = dfi.MonthDayPattern.IndexOf('d');
+   int monthIndex =
dfi.MonthDayPattern.IndexOf('M');
+   if (dayIndex == -1)
+   return true; // BUGBUG: Hack for wrong
pattern in Locale eu-ES

I wonder how you needed this line.

+   internal static bool _ParseDateSeparator (string s, int
sPos, 
DateTimeFormatInfo dfi, bool exact, out int num_parsed)

Some of new methods do not have to be accessible as internal.

-   if (s.Length == valuePos)
+   if (valuePos >= s.Length)

(Not limited to this specific change) why did you need this kind
of changes? Is there such a case that cause valuePos could become
bigger than s.Length, or are you ignoring error-prone cases?

-   ZeroPad (result,
dfi.Calendar.GetYear (this), (tokLen == 3 ? 3 : 4));
+   //bug fix:
+   //Unitest:(new DateTime
(1999,5,4)).ToString ("yy") 
should return "001999"
+   ZeroPad (result,
dfi.Calendar.GetYear (this), tokLen);

What do you mean here?

And in general as a whole patch please check our coding styles:
http://www.mono-project.com/Coding_Guidelines
(like foo () instead of foo())

Thanks a lot for the improvements :-)

Atsushi Eno

Eyal Alaluf wrote:
> Attached is a revised patch that takes into consideration the
> ShortDatePattern and MonthDayPattern of the DateTimeFormatInfo and
does
> not have anymore the 'switch' case on the culture ID.
> 
> Your comments are welcome, Eyal.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Eyal
> Alaluf
> Sent: 16 August 2007 14:46
> To: Atsushi Eno
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] : DateTime.Parse patch
> 
> Hi, Atsushi.
> 
> Thanks to your remark I checked again and saw that MS behaviour is to
> decide upon the month day and year order according to the
> ShortDatePattern in all cases.
> When I wrote the code I thought that '/MM/dd' didn't indicate the
> order but I was wrong.
> So actually, the switch is not necessary. Instead checking if 'd'
> appears before 'M' is enough.
> I actually went ahead and modified the
> culture.DateTimeFormat.ShortDatePattern and this modification overrode
> the decision if 1/10 is Oct 1st or Jan 10th.
> This brought up another complication since I didn't consider the order
> of the year according to this pattern and if it says '/MM/dd' then
> '01/02/03' actually means '2001 Feb 3rd' and 'dd/MM/yyyy' would spit
> '2003 Feb 1st'.
> I am adding the year logic and will prepare next week a new patch.
> 
> Eyal.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi
> Eno
> Sent: 16 August 2007 05:19
> To: Eyal Alaluf
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] : DateTime.Parse patch
> 
> Hello,
> 
> I like the effort to improve DateTime.Parse(), but I think your
> approach is broken. The switch-case that looks at 
> DateTimeFormatInfo.CultureID could be problematic especially
> when a DateTimeFormatInfo is cloned and then its format strings
> are modified (note that there are setters on DateTimeFormatInfo
> members).
> 
> Atsushi Eno
> 
> Eyal Alaluf wrote:
>> Hi, all.
>>
>> Attached is a patch for the infamous DateTime.Parse method.
>> The current logic for Parse is to try all the culture date time
> formats
>> and then try some special formats in invariant culture.
>> This solution is not sufficient because it is not very compatible
with
>> MS behavior, it is difficult to maintain and is very inefficient.
>>
>> The 

Re: [Mono-dev] [PATCH] String.Split() broken behavior

[Eyal Alaluf]

Just a small comment:
  ...
  > [ComVisible (false)]
  > -   [MonoDocumentationNote ("optimization")]

  Since the code is not optimized, please don't remove this.
  ...
Please use "[MonoInternalNote ("optimization")]". Since this is not
something one would like to document. It doesn't help the developer
using Mono and will only confuse her.

Thanks, Eyal.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] ToString() performace in Mono revisited

[Eyal Alaluf]

I got complaints that the font color within the table is white so this
is a resent :-)

 

Hi, all.

 

Attached is a redesigned implementation of the NumberFormatter class.
The patch includes a new algorithm for float and double ToString
implementation that improves performance by a factor of 25(!) and upto
440(!!!). The patch includes further improvements to integer ToString as
well as Andreas suggestion of avoiding calling
NumberFormatInfo.CurrentInfo in the case of integer types default
ToString() implementation.

This patch should improve Mono's performance in important use cases such
as web-services where primitive ToString performance is an important
factor.

 

The following is a table showing the improvements for the different
primitive types using the patch. All the results are in milliseconds and
for a run of 10,000,000 iterations with warm-up of 10,000,000 iterations
as well.

 

 

Mono 1.2.6

Patch

Improvement

12345.ToString("G")

10079

7328

1.37

12345L.ToString("G")

13203

7297

1.81

0.12345.ToString("G")

323750

13047

24.8(!)

1.2345E-200.ToString("G")

6376500

14328

445(!!!)

0.12345m.ToString("G")

51078

9875

5.2

12345.ToString()

12406/7781

5687

2.2/1.37

12345L.ToString()

15703/11016

5750

2.7/1.9

 

Note that for Mono 1.2.6 12345.ToString() there are two numbers - the
first is Mono 1.2.6 version (which is slower then 12345.ToString("G")!)
and the second is after applying Andreas suggestion on top of Mono
1.2.6.

 

The following are the results of the new algorithm compared to the old
Mono algorithm and the .Net 2.0 native ToString performance, all three
running on Microsoft .Net 2.0. The results show that the new code
matches and even out-performs .Net ToString implementation.

 

Mono 1.2.6 algorithm

Microsoft .Net 2.0

New Patch algorithm

Improvement over Mono 1.2.6 

Improvement over .Net 2.0

12345.ToString("G")

3700

2291

1827

2.0

1.25

12345L.ToString("G")

4559

2242

1919

2.38

1.17

0.12345.ToString("G")

281090

4006

3897

72.1(!!)

1.03

1.2345E-200.ToString("G")

5686000

4634

4613

1233(!!!)

1.00

0.12345m.ToString("G")

14562

3095

2294

6.3

1.35

12345.ToString()

3900/3002

2344

1313

3.0/2.3

1.79

12345L.ToString()

4684/3823

2245

1383

3.4/2.8

1.62

 

It should be noted that the new code performance improvement are even
more visible on top of .Net.

It should also be noted that .Net runs the same algorithm 4 times faster
then Mono. Since this code is self contained and almost completely
algorithmic - I believe that it may serve as a good practical test case
for improving Mono's JIT.

 

The redesign is composed of three main changes

*   An O(1) arithmetic transformation of a double (composed of sign,
2's exponent and mantissa bits) to sign, long and 10's exponent.

*   Using a character array instead of a string buffer to construct
the string result.

*   Representing the number digits using hexadecimal values. That is
12345 will be represented by 0x12345.

 

The patch passes Mono's unit tests on both 1.1 and 2.0.

 

Please review and provide us with your feedback as soon as possible.

 

Sasha, Roei & Eyal.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] ToString() performace in Mono revisited

[Eyal Alaluf]

Hi, all.

Thanks for the feedback. The amount of used memory is indeed not
appropriate for small devices and is not economic enough.

The 'DblExpTab' is essential in order for the double ToString to be
efficient.
As for the other two arrays they cache a simple arithmetic caclcualtion.

I'll therefore eliminate the '_decHexLen' array and use
  static readonly int[] _decHexDigits = new int [100];
I'll make DblRep into a struct and remove one member out of it (and
slightly improve the double.ToString() perf along the way).
This will change the allocation size to 100 * 4 + 2048 * (3 * 4) = ~25K.

The performance impact is betweek 3-10% overall for simple ToString()
depending on the hardware.

Eyal.

-Original Message-
From: Juraj Skripsky [mailto:[EMAIL PROTECTED] 
Sent: 30 December 2007 19:34
To: Atsushi Eno
Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] ToString() performace in Mono revisited

Hello,

I think the following two arrays account for most of those 300KB:

static readonly int[] _decHexDigits = new int [1];
static readonly int[] _decHexLen = new int [0x1];

The first one consumes almost 40KB, the second one 256KB...

The "DblExpTab" array uses 2048 * 4 = 8KB and its referenced DblRep
objects 2048 * (8 + 4 * 4) = 48KB. This means a total of 56KB. Turning
DblExbTab into a struct would reduce this to 2048 * (4 * 4) = 32KB.

- Juraj


On Mon, 2007-12-31 at 00:19 +0900, Atsushi Eno wrote:
> Hello,
> 
> Kazuki pointed out that the static initialization part of
> NumberFormatter allocates 300KB. It is probably here:
> 
>   public static readonly DblRep[] DblExpTab = new DblRep
[ExponentMax + 1];
> 
> It does not look good.
> 
> Atsushi Eno
> 
> 
> Eyal Alaluf wrote:
> > 
> > 
> > With the attchments zipped to reduce size.
> > 
> >  
> > 
> > * From: * [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] *On Behalf Of
*Eyal Alaluf
> > *Sent:* 27 December 2007 17:28
> > *To:* mono-devel-list@lists.ximian.com
> > *Cc:* Miguel de Icaza
> > *Subject:* [Mono-dev] ToString() performace in Mono revisited
> > 
> >  
> > 
> > I got complaints that the font color within the table is white so
this 
> > is a resent J
> > 
> >  
> > 
> > Hi, all.
> > 
> >  
> > 
> > Attached is a redesigned implementation of the NumberFormatter
class. 
> > The patch includes a new algorithm for float and double ToString 
> > implementation that improves performance by a factor of 25(!) and
upto 
> > 440(!!!). The patch includes further improvements to integer
/ToString/ 
> > as well as Andreas suggestion of avoiding calling 
> > /NumberFormatInfo.CurrentInfo/ in the case of integer types default 
> > /ToString()/ implementation.
> > 
> > This patch should improve Mono's performance in important use cases
such 
> > as web-services where primitive /ToString/ performance is an
important 
> > factor.
> > 
> >  
> > 
> > The following is a table showing the improvements for the different 
> > primitive types using the patch. All the results are in milliseconds
and 
> > for a run of 10,000,000 iterations with warm-up of 10,000,000
iterations 
> > as well.
> > 
> >  
> > 
> >  
> > 
> > 
> > 
> > Mono 1.2.6
> > 
> > 
> > 
> > Patch
> > 
> > 
> > 
> > Improvement
> > 
> > 12345.ToString("G")
> > 
> > 
> > 
> > 10079
> > 
> > 
> > 
> > 7328
> > 
> > 
> > 
> > 1.37
> > 
> > 12345L.ToString("G")
> > 
> > 
> > 
> > 13203
> > 
> > 
> > 
> > 7297
> > 
> > 
> > 
> > 1.81
> > 
> > 0.12345.ToString("G")
> > 
> > 
> > 
> > 323750
> > 
> > 
> > 
> > 13047
> > 
> > 
> > 
> > 24.8(!)
> > 
> > 1.2345E-200.ToString("G")
> > 
> > 
> > 
> > 6376500
> > 
> > 
> > 
> > 14328
> > 
> > 
> > 
> > 445(!!!)
> > 
> > 0.12345m.ToString("G")
> > 
> > 
> > 
> > 51078
> > 
> > 
> > 
> > 9875
> > 
> > 
> > 
> > 5.2
> > 
> > 12345.ToString()
> > 
> > 
> > 
> > 12406/7781
> > 
> > 
> > 
> > 5687
> > 
> > 
> > 
> > 2.2/1.37
> > 
> > 

Re: [Mono-dev] Make use of --desktop and --server VM modes [was Re: ToString() performace in Mono revisited]

[Eyal Alaluf]

My measurements (on a slightly different patch) show a small tradeoff of ~10% 
in performance.
Actually on .Net it's even smaller and varies between 3-5%.

Eyal.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Jordan
Sent: 31 December 2007 15:45
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Make use of --desktop and --server VM modes [was Re: 
ToString() performace in Mono revisited]

Mirco Bauer wrote:
> On Mon, 2007-12-31 at 10:58 +0900, Atsushi Eno wrote:
>> Oops yes ;-)
>>
>> BTW Kazuki cooked patches to reduce those memory usage with little
>> cost:
>>
>> http://kserver.panicode.com/memo/2007/12/30/0
>> (327KB -> 57KB)
> 
> looking at those number like:
> CPU 9.3sec -> 31.5sec
> MEM 389KB -> 32KB
> 
> gives me mixed feelings, it's the typical: use less memory needs more
> CPU scenario.

Then you must be reading Japanese better than I do ;-)
Hint: scroll down to see the real results.

> I still believe we should start optimizing both ends and using the
> --desktop and --server modes we already support but which we are not
> using yet.

This is wrong, at least in the context of this mail. Those switches
will affect JIT compiler optimizations, whereas this mail is
about suboptimal implementation of ToString (). Even a über-JIT
won't be able to turn a suboptimal algorithm into a good one.

Robert

___
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] [SPAM] Re: [SPAM] Re: ToString() performace in Mono revisited

[Eyal Alaluf]

Hi, Andreas.

It does make sense to make the 'DblExpTab' common to all appdomains.
How do you implement such a scheme in Mono? Is it possible to achieve this 
without going out to unsafe code and internal methods?
If the above is complicated, do you think that it makes sense to consider the 
above as a separate task since the array size is now 24K and a scenario with 
1000 domains is a rare scenario?

Thanks, Eyal.

-Original Message-
From: Andreas Nahr [mailto:[EMAIL PROTECTED] 
Sent: 03 January 2008 11:19
To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor'; 
mono-devel-list@lists.ximian.com
Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky'
Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono 
revisited

Sorry that I did not suggest this earlier, but did you look at using a
scheme for embedding the Lookuptables in the runtime like e.g. Char does?

The problem with using static fields is that they are per-domain and always
need to be ("re")initialized.
Assume the following (worst) case:
We have 1000 Appdomains and each appdomain does a single ToString for a
double value.
In that case your implementation will:
* Consume more than 36MB RAM just for the lookup-tables
* Each of the single ToStrings will probably be about 10 times (just
making up a number) slower than now because for every single call you
recreate the entire lookuptable(s)

Moving the (pregenerated) lookuptables into the runtime will:
* Reduce the memory to a *single* instance of the lookuptable for all
Appdomains/Processes
* Potentially reduce memory by using mem-mapping
* Remove *ALL* initialization, which means full speed even with a single
ToString call.
* Nearly no overhead except a single internalcall to retieve the
datapointer(s) 
* No race-conditions, no locking

This way it might even make sense to keep some of the original _decHex
Tables (maybe reduced in array size and do they both need Int32 anyways?).

Greetings
Andreas

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf
Gesendet: Donnerstag, 3. Januar 2008 09:21
An: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com
Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky
Betreff: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono
revisited

Hi, all.

Let me try to clarify a few things:
  1. The "Hex support" is not for hexadecimal formatting but for speeding up
decimal formatting.
  2. Following the reviews about the array size, the _decHexLen' array is
removed and the '_decHexDigits' is reduced to size of 400 bytes.
  3. The third array that is part of the double ToString algorithm is
already defined within a nested class and will be initialized only when a
double/float ToString is invoked.
Attached is a revised version of 'NumberFormatter.cs' that includes these
changes.

Eyal.

-Original Message-
From: Andreas Nahr [mailto:[EMAIL PROTECTED]
Sent: 03 January 2008 03:17
To: 'Prakash Punnoor'; mono-devel-list@lists.ximian.com
Cc: 'Miguel de Icaza'; 'Andreas Nahr'; 'Atsushi Eno'; 'Juraj Skripsky'; Eyal
Alaluf
Subject: AW: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited

> > The array initialization should also be done lazily and not in the 
> > static constructor (should be removed completely because it drags in

> > other static fields that need to be preinitialized, code compiled
and so
on).
> > Especially the Hex support is IMHO completely off bounds. I
> > (personally) rarely see hex output and making EVERYBODY pay for a 
> > hex speedup doesn't seem right. A simple if (array == null) Init ();

> > will be enough. You will pay per-call, but it is relatively cheap.
>
> The only thing that is worth keeping in mind is that if this is a 
> static field, initialization probably needs to be protected by a lock 
> (I say probably, because we *could* ignore the race by carefully 
> making sure that we assign the public array only after it has been 
> initialized, so we would end up with N copies of an array initialized 
> in the worst case, but N-1 will be discarded by the GC).

You can also use the Bill Pugh's trick by using a nested class, so the jit
should lazily initialize it (it works with .net, no idea whether it does
with
mono.)

I don't know whether it would work with mono either but you may get
additional problems having a nested class in a structure ;)

Also there is no need to lock for multithreading. As Miguel wrote we can
simply ignore the race in this situation. Worst case two (or n) Lookuparrays
get created and all except one immediately garbage-collected after their
use.

All you need to have is
void Init () {
int[] temp = new int[x];
doinits()
staticField = temp; // Must not happen before doinits() }

Greetings
Andreas


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Tests failures when running on MS.NET

[Eyal Alaluf]

Hi, Atsushi.

So right now Mono 2.0 behaves like .Net 1.1.
What about making Mono compatible with .Net 2.0? This will make Mono 1.1
behave like .Net 2.0 but since most of the changes are bug fixes and
improvements this should not be a bigger problem then the one we
currently have.

Thanks, Eyal.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Atsushi
Eno
Sent: 09 January 2008 13:50
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Tests failures when running on MS.NET

Those values are different between .NET 2.0 and 1.x.
In mono land they are embedded in our runtime, which does not
differentiate 2.0 and 1.x.
If we have both tables it increases the size of the runtime
almost unnecessarily.

You can't "fix" the tests. You don't pay any attention to the
Mono test results, but if you "fix" them, they will "fail" on mono.

Atsushi Eno

Roei Erez wrote:
> 
> 
> Hi,
> 
> I have noticed that the following CharCategory related tests fails
when 
> running on MS:
> 
>  
> 
> CharCategoryTest.IsDigit
> 
> CharCategoryTest.IsLower
> 
> CharCategoryTest.IsNumber
> 
> CharCategoryTest.IsPunctuation
> 
> CharCategoryTest.IsSeperator
> 
> CharCategoryTest.IsSymbol
> 
> CharCategoryTest.IsUpper
> 
> CharCategoryTest.IsWhiteSpace
> 
>  
> 
> Is there a specific reason for this or can I fix the tests?
> 
>  
> 
> Regards,
> 
> Roei Erez
> 
>  
> 
> 
>

> 
> ___
> 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] [SPAM] Re: [PATCH] ToString() performace in Mono revisited

[Eyal Alaluf]

Hi, Zoltan.

The use of unsafe pointers here is not different then the use of unsafe 
pointers in System.Char.
I did go ahead and moved all the common arrays to be shared - would it matter 
if only the two arrays related to double computing will be unsafe? (The 
'MantissaBitsTable' and 'TensExponentTable' table).
These are the two arrays that take the most memory.
In any case the version that uses managed arrays will be committed as well and 
will be marked by '#ifdef TARGET_JVM' since we use this version anyhow for 
Grasshopper. I don't know if it makes sense for moonlight to have a customized 
version of Mono where these arrays (and other parts such as System.Char) are 
managed, but if it does make sense it will be a no brainer.

Thanks, Eyal. 

-Original Message-
From: Zoltan Varga [mailto:[EMAIL PROTECTED] 
Sent: 10 January 2008 00:09
To: Andreas Nahr
Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono 
revisited


   Hi,

 I like the original version which contained managed arrays better.
The new version might use less memory, but it
contains lots of unsafe code using pointers, and this will become a
problem when we want to do a security audit for
moonlight.

  Zoltan

On Jan 9, 2008 7:45 PM, Andreas Nahr <[EMAIL PROTECTED]> wrote:
> I like the patch a lot and am looking forward to see some final speed
> results.
>
> On the other hand when taking into account the importance and size of the
> patch several people should look over it ;)
>
> Greetings
> Andreas
>
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Im Auftrag
> > von Eyal Alaluf
> > Gesendet: Mittwoch, 9. Januar 2008 10:03
> > An: Miguel de Icaza
> > Cc: mono-devel-list@lists.ximian.com
> > Betreff: [SPAM] Re: [Mono-dev] [PATCH] ToString() performace
>
> > in Mono revisited
> >
> > Hi, Miguel.
> >
> > Can I go ahead and commit this important patch?
> >
> > Thanks, Eyal.
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf
> > Of Eyal Alaluf
> > Sent: 06 January 2008 16:34
> > To: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com
> > Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky
> > Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString()
> > performace inMono revisited
> >
> > Hi, all.
> >
> > I have attached a patch following Andreas suggestions below.
> > Please review, especially the metadata part.
> >
> > I saw once that Mono checks compatibility of Mscorlib with
> > the runtime, is this happenening automatically whenever an
> > internal call is added?
> >
> > BTW, since now the numberFormatter tables become arrays of
> > magic numbers in mono/metadata, is there a place where I
> > should put the program that generates these numbers?
> >
> > Thanks, Eyal.
> >
> > -Original Message-
> > From: Andreas Nahr [mailto:[EMAIL PROTECTED]
> > Sent: 04 January 2008 00:26
> > To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor';
> > mono-devel-list@lists.ximian.com
> > Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky'
> > Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString()
> > performace in Mono revisited
> >
> > > It does make sense to make the 'DblExpTab' common to all appdomains.
> > > How do you implement such a scheme in Mono? Is it possible
> > to achieve
> > > this without going out to unsafe code and internal methods?
> >
> > Afaik to gain all the advantages you need one internal method
> > to return the pointers and unsafe code for accepting the pointer.
> > The scheme is pretty straightforward (compare Char or CultureInfo):
> > Runtime:
> > * Pregenerate the table data
> > * convert to a C constant array
> > * embed that into the runtime (e.g.
> > http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metada
> ta/culture
> > -inf
> > o-tables.h?rev=88796&view=auto)
> > * Create one runtime method to return a pointer to the array
> > Classlib:
> > * Define internalcall to the runtime method
> > * Store the retrieved pointer in a static variable
> > * Use the pointer as you would use the array (syntax is
> > compatible, so no need to change the code)
> > * Get Array-Bounds-Check-Removal for free :)
> >
> > > If the above is complicated, do you think that it makes sense to
> > > cons

Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited

[Eyal Alaluf]

Hi, Miguel.

 

I've committed this patch to the trunk. I have rerun the performance
measurements to get uptodate numbers after the changes made during the
review process. Here are the results:

 

 

Mono 1.2.6

Patch

Improvement

12345.ToString("G")

10079

7250

1.39

12345L.ToString("G")

13203

7292

1.81

0.12345.ToString("G")

323750

13769

23.5(!)

1.2345E-200.ToString("G")

6376500

 

 

0.12345m.ToString("G")

51078

10086

5.1

12345.ToString()

12406/7781

6277

1.98/1.24

12345L.ToString()

15703/11016

5766

2.7/1.9

 

The numbers are fairly similar to the results I've got before (see
below) the review.

Some notes:

*   double.ToString is 5% slower then the previous results - which
is to be expected after the last changes made to reduce the memory
consumption.

*   int.ToString() is slower by 10% then the previous results - this
is actually strange since it is slower then the current long.ToString()
by 10%. This must be some quirk of he Mono JIT (I don't see a similar
performance loss when running the algorithm on MS .Net 2.0 runtime). I
do recommend that someone take a look into this - it should be a good
test case for tuning the JIT.

 

For reference the here are the previous results:

 

 

Mono 1.2.6

Patch

Improvement

12345.ToString("G")

10079

7328

1.37

12345L.ToString("G")

13203

7297

1.81

0.12345.ToString("G")

323750

13047

24.8(!)

1.2345E-200.ToString("G")

6376500

14328

445(!!!)

0.12345m.ToString("G")

51078

9875

5.2

12345.ToString()

12406/7781

5687

2.2/1.37

12345L.ToString()

15703/11016

5750

2.7/1.9

 

Thanks, Eyal.

 

-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED] 
Sent: 10 January 2008 20:39
To: Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited

 

Hello Eyal,

 

> Can I go ahead and commit this important patch?

 

Yes, this is fine with me.

 

I'll discuss with the team if we want to by default use the TARGET_JVM

option by default ourselves or not.   But for now, lets get the patch

in.

 

> Thanks, Eyal.

> 

> -Original Message-

> From: [EMAIL PROTECTED]

> [mailto:[EMAIL PROTECTED] On Behalf Of Eyal

> Alaluf

> Sent: 06 January 2008 16:34

> To: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com

> Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky

> Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace

> inMono revisited

> 

> Hi, all.

> 

> I have attached a patch following Andreas suggestions below. Please

> review, especially the metadata part.

> 

> I saw once that Mono checks compatibility of Mscorlib with the
runtime,

> is this happenening automatically whenever an internal call is added?

> 

> BTW, since now the numberFormatter tables become arrays of magic
numbers

> in mono/metadata, is there a place where I should put the program that

> generates these numbers?

> 

> Thanks, Eyal.

> 

> -Original Message-

> From: Andreas Nahr [mailto:[EMAIL PROTECTED] 

> Sent: 04 January 2008 00:26

> To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor';

> mono-devel-list@lists.ximian.com

> Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky'

> Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in

> Mono revisited

> 

> > It does make sense to make the 'DblExpTab' common to all appdomains.

> > How do you implement such a scheme in Mono? Is it possible to 

> > achieve this without going out to unsafe code and internal methods?

> 

> Afaik to gain all the advantages you need one internal method to
return

> the

> pointers and unsafe code for accepting the pointer.

> The scheme is pretty straightforward (compare Char or CultureInfo):

> Runtime:

> * Pregenerate the table data

> * convert to a C constant array

> * embed that into the runtime (e.g.

>
http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metadata/culture

> -inf

> o-tables.h?rev=88796&view=auto)

> * Create one runtime method to return a pointer to the array

> Classlib:

> * Define internalcall to the runtime method

> * Store the retrieved pointer in a static variable

> * Use the pointer as you would use the array (syntax is compatible, so

> no

> need to change the code)

> * Get Array-Bounds-Check-Removal for free :)

> 

> > If the above is complicated, do you think that it makes sense 

> > to consider the above as a separate task since the array size 

> > is now 24K and a scenario with 1000 domains is a rare scenario?

> 

> Well I personally am much more concerned about the additiona

[Mono-dev] : Merge bug fix for NaN and +/- Infinity ToString("R") into 1.9

[Eyal Alaluf]

Hi, Miguel.

During our testing of the upcoming version of Grasshopper we detected
and fixed a regression in the new NumberFormatter code.
The regression has to do with NaN and +/-Infinity.ToString("R") and I
have committed a fix (including tests) into Mono version "r95428".
Would you like this fix merged into the upcoming 1.9 release?

Eyal.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Further improvements to toStringperformance

[Eyal Alaluf]

Thanks Miguel, I'll commit the patch next week.

-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED] 
Sent: 27 March 2008 17:47
To: Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] [PATCH] Further improvements to
toStringperformance

Hello Eyal,

 I have done a cursory review of this patch, and it looks good to
go.Doing it now, will give it more exposure to people.


On Tue, 2008-03-25 at 06:05 -0700, Eyal Alaluf wrote:
> Hi, Miguel.
> 
> The attached patch contains further improvements to the perf or
ToString
> of primitive types.
> The perf gain is due to two changes
>   1. An instance of NumberFormatter is placed as a member of the
Thread
> class. This allows reuse of the character array within the
NumberFormat
> class and to cache the lookup of the NumberFormatInfo from the current
> culture which turns out to be a costly operation.
>   2. The default ToString of integers has been specialized (because of
> its simplicity).
> The results of these improvements are:
>   10,000,000 * 12345.ToString():From 13.0 Secs to 6.3 Secs
>   10,000,000 * 12345.ToString("G"): From 14.7 Secs to 8.4 Secs
>   10,000,000 * 0.12345.ToString():  From 27.9 Secs to 21.3 Secs
> The results were made on my (a bit outdated) PC but the same
> improvements were seen in newer types of machines.
> I have also added the copyright and license notice.
> 
> Waiting for your approval, Eyal.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] WCF and Mono

[Eyal Alaluf]

Hi, Atsushi.

A few clarifications:
 * The milestones indeed come from olive/status/status.txt and then some
of our own. We will develop this ection further next week.
 * XML Serialization - meaning using System.Xml.Serialization
serializaer (supporting the XmlSerializerFormat attribute.
 * We tried to use NetTcpBinding but it didn't work for us. I can see
that the code is so it's probably a small blocking issue. It'll be great
if you can check that.
 * Using 'we' to mean Grasshopper is what happens when you consolidate
several statuses into one place :-) We will clarify that part and
clarify the Grassshopper specific issues.
 * As for the security status - this is actually from the
olive/status/status.txt where we translated 'done' into supported. It'll
actually be great if you could give better status on this since we still
were not able to check any of this.

Eyal.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Atsushi Eno
Sent: 28 March 2008 08:06
To: Miguel de Icaza; Noam Lampert
Cc: [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] WCF and Mono


Hello,

For "milestones", we might want to rethink about it. The original plan 
was to achieve infocard capability,
which is based on WS-Security and several security stack. Cardspace 
design is still nice, but looks like
the security stack is not in our short milestone at least in Mainsoft 
and I sort of agree to their plan.
Actually it is almost copy of my old olive/status/status.txt, so they 
had better overwrite it with their own :)

Below are mostly for Mainsoft guys --

Instead of "Core Compare" section, we could just put a link to the 
latest olive build status such as
http://mono.ximian.com/monobuild/builds/HEAD/suse-101-i586/olive/99113/f
iles/steps/api-diff/
(I think there should be a convenient direct link to the class status 
page for the latest build; I'll ask Wade
if it is possible).

And the statistics miss other assemblies than System.ServiceModel.dll. 
As above, I wouldn't
recommend adding them on our static wiki page though...

The detailed analysis of the implementation status is *great*, 
especially on what we don't have today :-)
There still seem some points that need correction, and some misleading 
lines I think:

>
>   Serialization
>
> * XML Serialization - not supported
>
I'm not sure what this "XML Serialization" means; is there anything else

than [Net]DataContractSerializer?

>
>   Bindings
>
> * wsHttpBinding not supported. The only working binding is
>   basicHttpBinding.
>
How about TcpTransportBinding? (It is somewhat improved and should be 
sort of working now.)

>
>   Proxy Generator
>
> This generator is a runtime generator for creating the proxy type. 
> Mono has an implementation that uses CodDom, which we can't use. Our 
> solution is probably will be based on Java Dynamic Proxies.
>
Are you talking about ClientProxyGenerator? AFAIR Mono.CodeGeneration is

not based on CodeDom.

(And yes, using "we" as Mainsoft on mono-project wiki is not appropriate
;-)

>
> SecurityBindingElement
>
> Binding Element
>
>   
>
> Description
>
>   
>
> Mono Status
>
>   
>
> Relevant to GH
>
> AsymmetricSecurityBindingElement
>
>   
>
> Supports public key encryption
>
>   
>
> Implemented
>
>   
>
>  
>
> SymmetricSecurityBindingElement
>
>   
>
> Supports shared key encryption
>
>   
>
> Implemented
>
>   
>
>  
>
> TransportSecurityBindingElement
>
>   
>
> Base class of security elements
>
>   
>
> Implemented
>
>   
>
I'm not sure what you means by "Implemented" here - they are WS-Security

stuff that involves several
missing WS-* functionality.

That's all so far. Thanks for the nice status page :-)

Atsushi Eno

Miguel de Icaza wrote:
> Hello folks,
>
> With Mono 2.0 approaching, it is time to start looking at new 
> areas in which Mono will expand.
>
> Noam at Mainsoft has updated the web page for the WCF project in 
> Mono with the information that they had put together at Mainsoft and 
> some of the information that was available as a status report inside 
> our "olive" module.  
>
> If you are interested in WCF, please take a look at our WCF page 
> for details on milestones, goals, tasks and ways in which you can 
> contribute:
>
> http://www.mono-project.com/WCF
>
> Miguel
>

>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Mono Olive - developing 3.0, 3.5 and Silverlight" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this gro

Re: [Mono-dev] Building class libraries in MS Visual Studio?

[Eyal Alaluf]

Hi, Tom.

 

You should probably use 'Mono.System.Web.Services.csproj'.
'System.Web.Services20.sln' is for working with Grasshopper
(http://dev.mainsoft.com).

Since I am using Grasshopper or mono makes I cannot say what kind of
pitfalls you may hit when using 'Mono.System.Web.Services.csproj' (such
as how to install in .Net GAC etc.).

'System.Web.Services.vmwcsproj' is for Grasshopper version 1.0 and is
obsolete . Noam do you think it's time to remove it and its equivalents
in the other namespaces?

 

Eyal.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
Cannon
Sent: Tuesday, May 27, 2008 8:36 PM
To: mono-devel-list
Subject: [Mono-dev] Building class libraries in MS Visual Studio?

 

Hello,

 

I'm attempting to build and debug some of the class libraries using MS
Visual Studio, starting with System.Web.Services.
System.Web.Services20.sln claims to be a VS 2008 file, but none of the
project files will load in the IDE.  Is there some environment setup
that I'm missing?  Some questions that may be related:

 

- What is System.Web.Services.vmwcsproj for?

- In System.Web.Services20.csproj, what is the purpose of $(VMW_HOME)?

 

Thanks,

-Tom

 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-devel-list] Updating Mono to include our Visual MainWin for J2EE specific code

[Eyal Alaluf]

Hi, Miguel.

We are now about ready to start sending code which is specific to our
configuration to the Mono trunc.
The code we will send will be surrounded by '#if J2EE' or '#if !J2EE'. We
will be both making additions to existing files as well as adding new files.
We would probably start with our specific code for System.Xml - we have
relatively fewer changes there.
What is the approach you would like us to adopt? We could post the changes to
the dev-list, or we could commit them directly to svn.
In some particular cases we will post in any case to the dev-list our changes
to have the dev-list review if we can do a better (minimal) change to the code.

Thanks, Eyal.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-devel-list] Updating Mono to include our Visual MainWin for J2EE specific code

[Eyal Alaluf]

Hi, Miguel.

We are actually targeting J2EE as in System.Web where we implement it over J2EE
servlets. We could actually differenciate and use 'TARGET_JVM' for Java related
issues and 'TARGET_J2EE' for J2EE related issues. What do you think?

Eyal.

On Thu, 17 Mar 2005, Miguel de Icaza wrote:

> Date: Thu, 17 Mar 2005 10:49:57 -0500
> From: Miguel de Icaza <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMAIL PROTECTED]>
> Cc: mono-devel-list@lists.ximian.com, Philippe Cohen <[EMAIL PROTECTED]>,
>  Noam Lampert <[EMAIL PROTECTED]>, Rafi Mizrachi <[EMAIL PROTECTED]>,
>  Oved Yavine <[EMAIL PROTECTED]>
> Subject: Re: [Mono-devel-list] Updating Mono to include our Visual
> MainWin   for J2EE specific code
>
> Hello Eyal,
>
> > We are now about ready to start sending code which is specific to our
> > configuration to the Mono trunc.
>
> Great news!
>
> > The code we will send will be surrounded by '#if J2EE' or '#if !J2EE'. We
> > will be both making additions to existing files as well as adding new files.
>
> I have been thinking about this.  I believe that J2EE might be
> confusing;  Maybe it should be called "JVM" or "TARGET_JVM", which is a
> more accurate description of what the patch does.
>
> > We would probably start with our specific code for System.Xml - we have
> > relatively fewer changes there.
>
> Sounds great.
>
> > What is the approach you would like us to adopt? We could post the changes 
> > to
> > the dev-list, or we could commit them directly to svn.
>
> Lets use the same approach that we follow for all the other patches: we
> get the patches into mono-devel-list (for now, it would be good to CC
> the maintainer, in this case Atsushi, as there are some reported
> problems with the lists today, following a server migration).
>
> Then after approval (which we typically time out if nobody objects) we
> get those changes into the repository.
>
> For smaller changes, you can commit directly, but you must be ready to
> answer or fix things if the patch introduces a regression or the
> maintainer would like the code reworked.
>
> It should not take long I think.
>
> best wishes!
> Miguel
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-devel-list] Re: CodeDom in Compiler.cs

[Eyal Alaluf]

Hi, Atsushi.

Regarding CodeDom support - we could support the code generation of C# code
without any big porting problems. Where we are currently limited is in
on-the-fly compilation of the C# code to Java byte-code. Our tool for
converting from .Net assemblies to Java byte code is written in C++ and we need
to be as portable in our runtime environment as Java, so we do not support
compilation on the fly until we will rewrite the converter in Java (or C# :-).

Eyal.

On Fri, 1 Apr 2005, Atsushi Eno wrote:

> Date: Fri, 01 Apr 2005 02:52:16 +0900
> From: Atsushi Eno <[EMAIL PROTECTED]>
> To: Andrew Skiba <[EMAIL PROTECTED]>
> Cc: mono-devel mailing list 
> Subject: [Mono-devel-list] Re: CodeDom in Compiler.cs
>
> Hi Andrew,
>
> Andrew Skiba wrote:
> > Hello, Eno.
> >
> > Is there ary need for using System.CodeDom in Mono.Xml.Xsl/Compiler.cs?
> > If not, let's remove this line, otherwise I'll make an ifdef patch for
> > TARGET_JVM, as we don't support CodeDom.
> >
> > Thank you,
> > Andrew Skiba.
> >
>
> Just a curious, was CodeDom support impossible?
>
> Anyways if you mean Compiler.cs, it looked unnecessary so I just
> removed it. If you mean ScriptCompilerInfo.cs, we can't remove
> the line (it is in use for msxsl:script support), so please post
> a patch for the Java switch you guys want to add.
>
> Cheers,
> Atsushi Eno
> ___
> 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] TARGET_JVM in XslDecimalFormat.cs

[Eyal Alaluf]

Hi, Atsushi.

We indeed have our own project files so we can cleanly have two different files
implementations.
I'd like to suggest the following as a naming convention for our specific
files: XslDecimalFormat.jvm.cs
What do you think?

Eyal.

On Thu, 7 Apr 2005, Atsushi Eno wrote:

> Date: Thu, 07 Apr 2005 00:45:40 +0900
> From: Atsushi Eno <[EMAIL PROTECTED]>
> To: Andrew Skiba <[EMAIL PROTECTED]>
> Cc: mono-devel mailing list 
> Subject: Re: [Mono-devel-list] TARGET_JVM in XslDecimalFormat.cs
>
> Hello,
>
> Andrew Skiba wrote:
> > This class has a trivial implementation on Java (according to XSLT
> > spec). So there is almost no common code here. What is better, to insert
> > the implementation into the same file, or to separate files? The
> > attached patch uses the first method.
>
> The implementation looks totally different one, so let's just have a
> different source. I guess, you guys anyways have different set of
> sources, right? So We can just checkin your source file into
> mcs/class/System.XML/Mono.Xml.Xsl and we can just ignore it while
> you can just ignore existing XslDecimalFormat.cs.
>
> Atsushi Eno
> ___
> 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] more ppc atomic.h cleanups

[Eyal Alaluf]

Hi, all.

Shouldn't the interlocked API's implementation use sync & isync for the memory
barriers?
At least in C++, we have seen many cases where people implemented their own
mutexes using interlocked APIs. Now on multiple CPU system and PPC in
particular a mutex needs to flush the memory barriers so two diferent threads
sharing the same data will be synchronized if they use the mutex properly.

Eyal.

On Wed, 13 Apr 2005, David Waite wrote:

> Date: Wed, 13 Apr 2005 12:31:50 -0600
> From: David Waite <[EMAIL PROTECTED]>
> To: Mono Development List 
> Subject: [Mono-devel-list] more ppc atomic.h cleanups
>
> Attached is a patch that performs cleanups of atomic.h for the ppc 
> architecture:
>
> * InterlockedIncrement, InterlockedDecrement: use one fewer register,
> avoid initialization and remove extra addition/subtraction at the end
> * InterlockedExchange: remove tmp initialization, rename tmp to result
> to be consistant with other methods
>
> -David Waite
>


atomic-ppc-cleanups.diff
Description: Binary data

Re: [mono-devel-list] Followup on System.Data drop (with Index redesign)

[Eyal Alaluf]

Hi, all.

I have just entered into svn a bundle of new tests for System.Data
disconnected imported from Mainsoft tests.
The tests can be run using nunit and currently we have 36 known failures out
of 319 tests.
We will be working on the failures by integrating Mainsoft's changes to
System.Data disconnected mode into svn as outlined by the process described
below.
Our next step is to send to this dev-list a description of the changes we have
made and to have the changes available for all to review.

Eyal.

-- Forwarded message --
Date: Tue, 12 Apr 2005 11:08:36 -0400
From: Miguel de Icaza <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: Sureshkumar T <[EMAIL PROTECTED]>,
 Manjula G H M <[EMAIL PROTECTED]>, borisk <[EMAIL PROTECTED]>,
 Noam Lampert <[EMAIL PROTECTED]>, Philippe Cohen <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED]
Subject: Re: Followup on System.Data drop (with Index redesign)

Hello,

> I'd like to follow-up on System.Data disconnected drop. Committing
> the improvements of this new source code into mono is a high priority for us -
> it is currently our biggest issue for using Mono's trunk latest directly in
> our builds (and not from our own version control system).
> I'd like to agree upon the best method for doing the above and letting the
> dev-list participlate in the process. The process I'd like to define is:
>  * You will do an initial review of the new drop and provide us with
>proposed modifications and raise issues for discussions.
>  * We will commit the new source code under a new branch under Mono's svn so
>everyone will have access to the code and can participate in the 
> discussion.
>  * We will add into this branch our tests and notify the dev-list on the tests
>additions. (We could also add the tests directly to the trunk, what do you
>think?)
>  * We will then provide the dev-list with a high-level description of the
>modifications as well as the branch name so the sources could be viewed.
>We will then discuss the issues you (Suresh) will raise using the dev-list.
>  * We have run already Mono's tests and we found two regressions. Once we
>commit into the branch we will discuss the resolution of these regressions
>over the dev-list (we think that the tests should be modified in this
>case and we definitely would like to discuss this in depth).
>  * Once everyone is satisfied with the status of the branch we will merge it
>into the trunk.
> The reason for the above process is that we made a lot of changes that are
> inter-related because of the redesign of DataColumn indices that affected
> a lot of the System.Data disconnected code.
> Please let me know your opinion about this process and if you'd like to
> define another or modify it.

The team in Bangalore and Atsushi are the developers that have been
involved in System.Data, so they have the last word, but Eyal's plan as
outlined above sounds great.

Since Eyal is talking about a branch, we could get the code into the
branch right away so the review can happen in parallel to these
discussions.

So Eyal's proposal has my OK.

Miguel



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-devel-list] Patch for NullReferencException in System.Web.Caching

[Eyal Alaluf]

Hi.

We have seen recently in several applications that use System.Web.Caching that
they have an occasional NullReferenceException. This was also reported a few
times to the mono-list.
After investigation and creation of a test we found the problem to be related
to use of Sliding-Window expiration in the cache (as opposed to use of
abslute time expiration).
Attached is a stress test and a patch for System.Web.Caching that makes the
test pass.
During the test I found out that the ReaderWriterLock was unstable so I am
attaching a patch for that. I am less sure about the completeness of this
patch (it takes more time and care to fix these type of issues) but using
it I was able to well test the System.Web.Caching fixes. If you will get
an ApplicationException from the ReaderWriter lock complaining that the thread
does not have the lock (read or write) then apply this patch and retry.
The test application gets three arguments:
  
  
  []
For example: 'mono CacheStress 100 10 1'
will run the test using 100 threads and a 10 mills sliding expiration window.
and 'mono CacheStress 100 10'
will run the test using 100 threads and a 10 mills abosolute expiration window.

Eyal.
Index: Test/System.Web.Caching/CacheStress.cs

===

--- Test/System.Web.Caching/CacheStress.cs  (revision 0)

+++ Test/System.Web.Caching/CacheStress.cs  (revision 0)

@@ -0,0 +1,85 @@

+using System;

+using System.Web.Caching;

+using System.Threading;

+

+/// 

+/// Summary description for Class1.

+/// 

+public class CacheStress

+{

+   static int threads = 0;

+   static int KeyStart = 0;

+   static long SlidingWindow = 0;

+   static bool UseAbsoluteTime = false;

+   static int Modulo = 71;

+   static Cache c;

+   static SafeSum Sum = new SafeSum();

+

+   /// 

+   /// The main entry point for the application.

+   /// 

+   static void Main(string[] args)

+   {

+   if (args.Length < 2) {

+   Console.WriteLine("Usage: CacheStress <#threads> 
<#millis> [UseAbsoluteTime]");

+   return;

+   }

+   c = new Cache();

+   threads = System.Int32.Parse(args[0]);

+   SlidingWindow = System.Int64.Parse(args[1]);

+   UseAbsoluteTime = (args.Length > 2);

+   for (int i = 0; i < threads; i++) 

+   {

+   Thread th = new Thread(new ThreadStart(RunCycle));

+   th.Start();

+   }

+   int secs = 10;

+   for (int j = secs; ;j += secs) 

+   {

+   Thread.Sleep(1000 * secs);

+   Console.WriteLine("Executed {0} transactions in {1} 
seconds", Sum.Value, j);

+   }

+   }

+

+   static void RunCycle()

+   {

+   int n = Interlocked.Increment(ref KeyStart);

+   for (int i = 1; ; i++) {

+   try 

+   {

+   string key = "stam" + n;

+   object o2 = c.Get(key);

+   if (o2 == null) 

+   {

+   if (UseAbsoluteTime)

+   c.Insert(key, 1, null, 
DateTime.Now.AddTicks(SlidingWindow), Cache.NoSlidingExpiration);

+   else

+   c.Insert(key, 1, null, 
Cache.NoAbsoluteExpiration, new TimeSpan(SlidingWindow));

+   }

+   n = (n * 2 + i) % Modulo;

+   }

+   catch (Exception e) 

+   {

+   Console.WriteLine("Caught exception " + 
e.GetType().ToString() + ": " + e.Message + e.StackTrace);

+   }

+   if (i == 100) 

+   {

+   Sum.Add(i);

+   i = 0;

+   }

+   }

+   }

+

+   class SafeSum

+   {

+   public SafeSum()

+   {

+   _value = 0;

+   }

+

+   public int Value { get { lock(this) { return _value; } } }

+   public void Add(int i) { lock(this) { _value += i; } }

+

+   private int _value;

+   }

+}

Index: Test/System.Web.Caching/readme.txt

===

--- Test/System.Web.Caching/readme.txt  (revision 0)

+++ Test/System.Web.Caching/readme.txt  (revision 0)

@@ -0,0 +1,10 @@

+The CacheStress.cs test is a standalone test that should be compiled and run
+as a console application.
+In normal mode the test prints every 10 seconds the number of transacti

[Mono-dev] patch for reading assemblies

[Eyal Alaluf]

= t;
+   m_module.TypeReferences.Add (t);
+   }
+
void ReadTypeSpecs ()
{
if (!m_tHeap.HasTable (typeof (TypeSpecTable)))
Index: ChangeLog

===

--- ChangeLog   (revision 59261)

+++ ChangeLog   (working copy)

@@ -1,3 +1,8 @@

+2006-04-09  Eyal Alaluf  <[EMAIL PROTECTED]>
+* Mono.Cecil/ReflectionReader.cs
+   Cannot assume that TypeRefs are ordered is such a way that an outer
+   class index comes always before all its inner classes.
+
 2006-04-06  Jb Evain  <[EMAIL PROTECTED]>
 
* Mono.Cecil/ReflectionWriter.cs
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Template and assignment operator in C#

[Eyal Alaluf]

Hi.

You can do this using interfaces without templates in C#, although you'll 
probably
need to work very hard to avoid the overhead of interface invoking compared to
inlinable non-virtual invokes you can do when interfaces are not involved.
If you define an interface for DoubleVec, your overload of operator+ can create 
an
instance of DoubleVecLazySum, etc.

Possibly, if we use generics and DoubleVecLazySum, 
DoubleVecLazyMul,
etc. are structs(and not classes), you can use generic operators like:
   DoubleVecLazySumm opeartor+(T x, DoubleVec y) { ... }
But in C# since all operators are tied to types you will need to repeat this 
exercise
for every type. E.g. inside the struct DoubleVecLazySumm
   DoubleVecLazySumm > opeartor+(T1 x, 
DoubleVecLazySumm  y) { ... }

Because DoubleVecLazySumm (and its companions) are structs, the 
ExecutionEngine
will instantiate every arithmetic combination and perhaps the JIT will know how 
to
inline it properly. This is probably not the case today, but maybe it's a 
pattern that
can be developed.

Eyal.

On Thu, 27 Apr 2006, Rusmin Susanto wrote:


Date: Thu, 27 Apr 2006 17:20:13 -0700 (PDT)
From: Rusmin Susanto <[EMAIL PROTECTED]>
To: Mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Template and assignment operator in C#

Hi all. I have some questions.

 1. Is there any trick in C# similar to Expression Template in C++ to avoid 
pairwise evaluation?
For example, if we have the following code in C++:

  // DoubleVec is a class that contains a vector of double. This class has 
typical aritmathic operator, + - * /.

   DoubleVec y(1000), a(1000), b(1000), c(1000),d(1000);
   y = (a+b)/(c-d);

 without expression template we will need 4 loops and 3 temporaries DoubleVect 
to process the expression as the operands are processed 2 at a time. With 
expression template trick in C++, we can process the expression in one hit (in 
one loop, no temporaries).

 2. Is template processed at compile time or run time in C#? I know that in C++ 
it's processed at compile time.

 3. I know that in C# the assignment operator '=' for object will copy the 
reference of rhs to the lhs.

How about if we need to define an assignment operator for an object that needs 
to copy the value of member variables (not reference) of rhs to lhs?
How do we tell C# to copy value, not reference?


 Many thanks for your attention.


-
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates 
starting at 1¢/min.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] JaCIL Project

[Eyal Alaluf]

Hi, all.

Just regarding feasibility and practicality - there is already a product 
implementing
this idea.
Not coincidently, the product is implemented by my company (Mainsoft) and is 
called
Grasshopper. You can access our DevZone at 
As the guy who already implemented the conversion from .Net byte code to JBC, I
can tell you that all the managed opcodes of .Net are implemented in our 
converter.
The product implements .Net 1.1 and We are currently working on .Net 2.0 (i.e. 
Generics).
As for performance, it's not a slam dunk but we managed to get comparable 
performance
with .Net on large customer projects (ISV ASP.Net projects of > 100K lines).

Eyal.

On Sun, 21 May 2006, Zac Bowling wrote:


Date: Sun, 21 May 2006 20:03:03 -0500
From: Zac Bowling <[EMAIL PROTECTED]>
To: Almann T. Goo <[EMAIL PROTECTED]>
Cc: Andreas Nahr <[EMAIL PROTECTED]>,
Mono Developers 
Subject: Re: [Mono-dev] JaCIL Project

This might be off the radar but what about translating internal members and 
attribute data?



Zac Bowling <[EMAIL PROTECTED]>
http://www.zacbowling.com/

Almann T. Goo wrote:
On 5/21/06, *Andreas Nahr* <[EMAIL PROTECTED] 
> wrote:


The hard part is likely that CIL has lots of construcs that Java
bytecode does not have. Just to name a few common/important ones:
Generics, Pointers and Pointer arithmetic, unchecked exceptions,
events, delegates, ...


Just a note, from the JVM point of view, all exceptions are unchecked. 
The JVM "has" checked exceptions in the same way that it "has" generics; 
they are represented as meta-data in the class file but actually are not 
used by the JVM itself.  It is only the compiler that deals with this. 
And a lot of exceptions in the Java are unchecked, the whole "Error" and 
"RuntimeException" hierarchy for instance.


How are you planning to solve that problem?


The simple answer is that I'm not--at least not right now.  I am trying to 
keep the scope maintainable and as such have explicitly laid out what 
minimal set of CLI features that I am supporting in my project proposal. 
Now, despite bowing out of implementing such features right now, I have 
given such things considerable thought and I have no doubt that most of 
them can be implemented--it is the cost of implementation that is probably 
the big question.


Let me address you question a little more specifically, it is a good one.

* Generics will be tough, I hate to cop out and type erase like
  Java does, but that could be one implementation option.
* Regarding un-managed pointers, there are ways you can emulate
  this, but because of the JVM programming model, it will come at
  a cost.
  o Others have dealt with this by doing things like paging
with arrays--NestedVM (IVME '04), does this for the memory
model of a MIPS R2000 ISA which it emulates.
  o This is not in my radar yet, because I think it would be a
huge win just to support the verifiable subset of CIL. 
Un-managed pointers are not in this subset.

* Regarding managed pointers, I will likely employ a boxing
  technique to do this.  Managed method pointers could be handled
  by using reflection.
  o These will of course take a performance hit (especially if
reflection is involved), but at least we can have it.
* Delegates are classes with methods from the programming model
  point of view  (there are CLI rules with regard to what can be
  in a delegate's definition, however).
  o With regard to the run-time provided method
implementations in a delegate, one approach could be to
actually emit the implementation of the delegate methods.
* Events and properties are really just meta-data "sugar", there
  are no CIL instructions associated with them specifically and
  they look like methods in the programming model.
* Although you didn't list these, here are a couple of other items.
  o I am actually very concerned with "newslot" methods,
non-virtual instance method calls, and explicit interface
method definition for near term future work.  This will
undoubtedly be a pain to implement; there is a lot of
opportunity to make really inefficient implementations.
  o Tail calls will be another really tough thing to implement
since the JVM programming model does not have native
support for tail recursive calls.  This is probably not a
highly used CLI feature anyhow (Unless you are a Scheme
compiler), so it is not really on my radar at the moment
because there are much larger fish to fry before I wrestle
with that.  A lot of literature on the subject--some kind
of trampolining implementation may be a way to support this.

Here is a link to my proposal--it more clearly defines the 

Re: [Mono-dev] JaCIL Project

[Eyal Alaluf]

We are now in the middle of a rewrite and in this rewrite we are using Cecil 
and ASM
(via IKVM). The version of the converter in the product was written in C++.

On Mon, 22 May 2006, Jb Evain wrote:


Date: Mon, 22 May 2006 10:08:22 +0200
From: Jb Evain <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: Zac Bowling <[EMAIL PROTECTED]>,
Andreas Nahr <[EMAIL PROTECTED]>,
Mono Developers 
Subject: Re: [Mono-dev] JaCIL Project

Hi Eyal,

Are you guys still using Cecil to read the CIL code?

Jb

Eyal Alaluf wrote:

Hi, all.

Just regarding feasibility and practicality - there is already a product 
implementing

this idea.
Not coincidently, the product is implemented by my company (Mainsoft) and 
is called

Grasshopper. You can access our DevZone at <http://dev.mainsoft.com>
As the guy who already implemented the conversion from .Net byte code to 
JBC, I
can tell you that all the managed opcodes of .Net are implemented in our 
converter.
The product implements .Net 1.1 and We are currently working on .Net 2.0 
(i.e. Generics).
As for performance, it's not a slam dunk but we managed to get comparable 
performance
with .Net on large customer projects (ISV ASP.Net projects of > 100K 
lines).


Eyal.

On Sun, 21 May 2006, Zac Bowling wrote:


Date: Sun, 21 May 2006 20:03:03 -0500
From: Zac Bowling <[EMAIL PROTECTED]>
To: Almann T. Goo <[EMAIL PROTECTED]>
Cc: Andreas Nahr <[EMAIL PROTECTED]>,
Mono Developers 
Subject: Re: [Mono-dev] JaCIL Project

This might be off the radar but what about translating internal members 
and attribute data?



Zac Bowling <[EMAIL PROTECTED]>
http://www.zacbowling.com/

Almann T. Goo wrote:
On 5/21/06, *Andreas Nahr* <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


The hard part is likely that CIL has lots of construcs that Java
bytecode does not have. Just to name a few common/important ones:
Generics, Pointers and Pointer arithmetic, unchecked exceptions,
events, delegates, ...


Just a note, from the JVM point of view, all exceptions are unchecked. 
The JVM "has" checked exceptions in the same way that it "has" 
generics; they are represented as meta-data in the class file but 
actually are not used by the JVM itself.  It is only the compiler that 
deals with this. And a lot of exceptions in the Java are unchecked, 
the whole "Error" and "RuntimeException" hierarchy for instance.


How are you planning to solve that problem?


The simple answer is that I'm not--at least not right now.  I am 
trying to keep the scope maintainable and as such have explicitly laid 
out what minimal set of CLI features that I am supporting in my 
project proposal. Now, despite bowing out of implementing such 
features right now, I have given such things considerable thought and 
I have no doubt that most of them can be implemented--it is the cost 
of implementation that is probably the big question.


Let me address you question a little more specifically, it is a good 
one.


* Generics will be tough, I hate to cop out and type erase like
  Java does, but that could be one implementation option.
* Regarding un-managed pointers, there are ways you can emulate
  this, but because of the JVM programming model, it will come at
  a cost.
  o Others have dealt with this by doing things like paging
with arrays--NestedVM (IVME '04), does this for the memory
model of a MIPS R2000 ISA which it emulates.
  o This is not in my radar yet, because I think it would be a
huge win just to support the verifiable subset of CIL. 
Un-managed pointers are not in this subset.

* Regarding managed pointers, I will likely employ a boxing
  technique to do this.  Managed method pointers could be handled
  by using reflection.
  o These will of course take a performance hit (especially if
reflection is involved), but at least we can have it.
* Delegates are classes with methods from the programming model
  point of view  (there are CLI rules with regard to what can be
  in a delegate's definition, however).
  o With regard to the run-time provided method
implementations in a delegate, one approach could be to
actually emit the implementation of the delegate methods.
* Events and properties are really just meta-data "sugar", there
  are no CIL instructions associated with them specifically and
  they look like methods in the programming model.
* Although you didn't list these, here are a couple of other 
items.

  o I am actually very concerned with "newslot" methods,
non-virtual instance method calls, and explicit interface
method definition for near term future work.  This will
undoubtedly be a pain to implement; th

Re: [Mono-dev] Re: Ambiguous matching in method resolution

[Eyal Alaluf]

Hi.

Are the interfaces implemented by the same class? This could explain quite a 
bit, actually.

Eyal.

On Thu, 1 Jun 2006 [EMAIL PROTECTED] wrote:


Date: Thu, 1 Jun 2006 10:33:19 +0200
From: [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com, Robert Jordan <[EMAIL PROTECTED]>
Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution

Well, the funny thing is that the problems I detected are between methods 
in... different interfaces!!



- Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, June 01, 2006 9:33 AM
Subject: [Mono-dev] Re: Ambiguous matching in method resolution



Ympostor wrote:

[EMAIL PROTECTED] escribió:

And more info yet.

The methods that seem to have trouble are the following:

- The server is "publishing" several interfaces under different 
"service names" by remoting.


- There are methods with the same name and different signatures on 
different interfaces.


- These methods are the ones causing trouble (not even overloaded 
methods on the same interface, but methods with the same name on 
different ones)


Just wondering... I have also experimented this exception when using 
Remoting and methods with the same name (overloaded). Have you tested 
the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, the 
objective is to find a small testcase where the behaviour differs from 
one runtime to another.


It looks like this bug:

http://bugzilla.ximian.com/show_bug.cgi?id=77191

Robert

___
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] Re: Ambiguous matching in method resolution

[Eyal Alaluf]

From my experience it's better to reduce the application to a small sample. 
During this effort you may stumble upon extra factors that are part of the bug 
that would be easier to workaround and important for getting the bug fixed.


Eyal.

On Thu, 1 Jun 2006 [EMAIL PROTECTED] wrote:


Date: Thu, 1 Jun 2006 11:45:38 +0200
From: [EMAIL PROTECTED]
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution

Hi,

No, every interface is implemented by a different class.

Do you think is better to rename all the methods or wait for a solution?

pablo

- Original Message ----- From: "Eyal Alaluf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: ; "Robert Jordan" <[EMAIL PROTECTED]>
Sent: Thursday, June 01, 2006 11:37 AM
Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution



Hi.

Are the interfaces implemented by the same class? This could explain quite 
a bit, actually.


Eyal.

On Thu, 1 Jun 2006 [EMAIL PROTECTED] wrote:


Date: Thu, 1 Jun 2006 10:33:19 +0200
From: [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com, Robert Jordan <[EMAIL PROTECTED]>
Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution

Well, the funny thing is that the problems I detected are between 
methods

in... different interfaces!!


- Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, June 01, 2006 9:33 AM
Subject: [Mono-dev] Re: Ambiguous matching in method resolution



Ympostor wrote:

[EMAIL PROTECTED] escribió:

And more info yet.

The methods that seem to have trouble are the following:

- The server is "publishing" several interfaces under different
"service names" by remoting.

- There are methods with the same name and different signatures on
different interfaces.

- These methods are the ones causing trouble (not even overloaded
methods on the same interface, but methods with the same name on
different ones)


Just wondering... I have also experimented this exception when using
Remoting and methods with the same name (overloaded). Have you 
tested
the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, 
the
objective is to find a small testcase where the behaviour differs 
from

one runtime to another.


It looks like this bug:

http://bugzilla.ximian.com/show_bug.cgi?id=77191

Robert

___
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] Cecil bug with Custom Attributes with enum parameters

[Eyal Alaluf]

Hi, JB.

I stumbled upon a critical problem with custom attributes that have enums in 
their
ctor.  For instance:
[System.AttributeUsage(System.AttributeTargets.Class,AllowMultiple=true)]
The problem is as follows -
* Custom attribute signatures aren't self contained. They depend on
  interpreting the parameters of the custom attribute ctor referenced in the
  signature.
* If a parameter is an int32 then 4 bytes in little endian are read, etc.
* If the parameter is an enum - one has to find out the enum underlying type
  and read the value from the Blob according to its underlying type (e.g. 
int).
* Now when the enum comes from another assembly, Cecil only has a 
TypeReference
  to it and actually has no idea that it's an enum and definitely not what
  is the underlying type.
* The code at Mono.Cecil.Signatures/SignatureReader.cs:746 method
  CustomAttrib.Elem ReadElem (byte [] data, BinaryReader br,
  TypeReferenceelemType, ref bool read) says:
default : // enum
read = false;
return elem;
  which means that the custom attribute is not fully processed.
* The result is that we get a CustomAttribute without the values for the 
ctor
  parameters and without the values for the named parameters.

I understand that the main difficulty is that the only way to find the enum's
underlying type is to actually load the enum's assembly (which could be another
assembly then the currently processed assembly).
We are currently doing this for all TypeReferences we encounter. We are using 
Cecil
itself to load the referenced assembly and look for the referenced type. 
Currently
Cecil tries to process each assembly independently of other assemblies and this
goes strongly against this design.

Do you have any plans to resolve this issue? (I assume from the comment in the 
code
that you are familiar with it)
What is the design you are looking for in this case? If you want to have Cecil
loading the Enum we can contribute our Resolver that is Cecil based.

Thanks, Eyal.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters

[Eyal Alaluf]

Hi, JB.

Attached is a patch containing the assembly resolver and its usage to resolve
the actual enum type definition ad the enum underlying type.
Several notes about the patch:
   * The resolver is very simple. It searches for .dll in a
 given search path.
   * It doesn't handle issues that may come to mind like thread safety,
 circular dependencies between assemblies, etc.`
   * Since Cecil does not have a search path defined, I made the resolver
 optional as a public field of AssemblyFactory.
   * I also declared an interface for the resolver that will allow more
 complex and customized implementation.
   * I'd recommend adding the "GetEnumUnderlyingType" as a public service.
 Maybe it makes sense to define an IEnumTypeDfinition and add to it an
 "UnderlyingType" property?

I can propose as an alternative design:
   1. Delay load the custom attributes
   2. Provide a way to resolve all the type references in the assembly.
* Add an "ITypeDefinition TypeDef" property to "ITypeReference".
* After initial load of the assembly, the developer can loop over the
  assembly's type references and set this property to the resolved type.
   3. The custom attribute code will use the new property whenever it has an
  unresolved type reference.
As this design is more complex and not developer friendly, I didn't follow it
through. Its advantage is that it avoids very nicely the issues of locking and
circular dependencies.
I'd welcome your comments.

Eyal.

On Wed, 7 Jun 2006, Jb Evain wrote:


Date: Wed, 07 Jun 2006 19:59:12 +0200
From: Jb Evain <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: Vladislav Spivak <[EMAIL PROTECTED]>, mono-devel-list@lists.ximian.com
Subject: Re: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters

Hi Eyal,


Do you have any plans to resolve this issue? (I assume from the comment
in the code
that you are familiar with it)
What is the design you are looking for in this case? If you want to have
Cecil
loading the Enum we can contribute our Resolver that is Cecil based.


The plan is indeed to load the assembly which contains the type definition. 
If you can contribute your resolver, I'll see how I can integrate it. Then 
I'll add some kind of ForceLoad method if the custom attribute is not 
readable at first try.


Thanks,

Jb

Index: Mono.Cecil/AssemblyResolver.cs

===

--- Mono.Cecil/AssemblyResolver.cs  (revision 0)

+++ Mono.Cecil/AssemblyResolver.cs      (revision 0)

@@ -0,0 +1,76 @@

+//

+// AssemblyResolver.cs

+//

+// Author:

+//   Eyal Alaluf ([EMAIL PROTECTED]), Vladislav Spivak ([EMAIL PROTECTED])

+//

+// (C) 2006 Mainsoft Co.

+//

+// Permission is hereby granted, free of charge, to any person obtaining

+// a copy of this software and associated documentation files (the

+// "Software"), to deal in the Software without restriction, including

+// without limitation the rights to use, copy, modify, merge, publish,

+// distribute, sublicense, and/or sell copies of the Software, and to

+// permit persons to whom the Software is furnished to do so, subject to

+// the following conditions:

+//

+// The above copyright notice and this permission notice shall be

+// included in all copies or substantial portions of the Software.

+//

+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE

+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION

+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION

+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

+//

+

+using System;

+using System.Collections;

+using System.IO;

+

+namespace Mono.Cecil

+{

+   /// 

+   /// Summary description for Resolver.

+   /// 

+   /// 

+

+   public class AssemblyResolver : IAssemblyResolver

+   {

+   private readonly string [] _libpath;

+   private readonly Hashtable _asmdefs = new Hashtable();

+

+   public AssemblyResolver(string libpath)

+   {

+   _libpath = libpath.Split(';');

+   }

+

+   public IAssemblyDefinition GetAssembly(string name)

+   {

+   if (_asmdefs.ContainsKey(name))

+   return (IAssemblyDefinition)_asmdefs[name];

+

+   foreach(string dir in _libpath)

+   {

+   //try dlls first

+   string finalname = null;

+   

Re: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters

[Eyal Alaluf]

Attaching changes to makefiles as well.

Date: Mon, 12 Jun 2006 18:38:30 +0300 (IDT)
From: Eyal Alaluf <[EMAIL PROTECTED]>
To: Jb Evain <[EMAIL PROTECTED]>
Cc: Vladislav Spivak <[EMAIL PROTECTED]>, mono-devel-list@lists.ximian.com
Subject: Re: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters

Hi, JB.

Attached is a patch containing the assembly resolver and its usage to resolve
the actual enum type definition ad the enum underlying type.
Several notes about the patch:
  * The resolver is very simple. It searches for .dll in a
given search path.
  * It doesn't handle issues that may come to mind like thread safety,
circular dependencies between assemblies, etc.`
  * Since Cecil does not have a search path defined, I made the resolver
optional as a public field of AssemblyFactory.
  * I also declared an interface for the resolver that will allow more
complex and customized implementation.
  * I'd recommend adding the "GetEnumUnderlyingType" as a public service.
Maybe it makes sense to define an IEnumTypeDfinition and add to it an
"UnderlyingType" property?

I can propose as an alternative design:
  1. Delay load the custom attributes
  2. Provide a way to resolve all the type references in the assembly.
   * Add an "ITypeDefinition TypeDef" property to "ITypeReference".
   * After initial load of the assembly, the developer can loop over the
 assembly's type references and set this property to the resolved 
type.

  3. The custom attribute code will use the new property whenever it has an
 unresolved type reference.
As this design is more complex and not developer friendly, I didn't follow it
through. Its advantage is that it avoids very nicely the issues of locking
and circular dependencies.
I'd welcome your comments.

Eyal.

On Wed, 7 Jun 2006, Jb Evain wrote:


Date: Wed, 07 Jun 2006 19:59:12 +0200
From: Jb Evain <[EMAIL PROTECTED]>
To: Eyal Alaluf <[EMAIL PROTECTED]>
Cc: Vladislav Spivak <[EMAIL PROTECTED]>, 
mono-devel-list@lists.ximian.com
Subject: Re: [Mono-Dev] Cecil bug with Custom Attributes with enum 
parameters


Hi Eyal,


Do you have any plans to resolve this issue? (I assume from the comment
in the code
that you are familiar with it)
What is the design you are looking for in this case? If you want to have
Cecil
loading the Enum we can contribute our Resolver that is Cecil based.


The plan is indeed to load the assembly which contains the type 
definition. If you can contribute your resolver, I'll see how I can 
integrate it. Then I'll add some kind of ForceLoad method if the custom 
attribute is not readable at first try.


Thanks,

Jb

Index: Mono.Cecil/AssemblyResolver.cs

===

--- Mono.Cecil/AssemblyResolver.cs  (revision 0)

+++ Mono.Cecil/AssemblyResolver.cs  (revision 0)

@@ -0,0 +1,76 @@

+//

+// AssemblyResolver.cs

+//

+// Author:

+//   Eyal Alaluf ([EMAIL PROTECTED]), Vladislav Spivak ([EMAIL PROTECTED])

+//

+// (C) 2006 Mainsoft Co.

+//

+// Permission is hereby granted, free of charge, to any person obtaining

+// a copy of this software and associated documentation files (the

+// "Software"), to deal in the Software without restriction, including

+// without limitation the rights to use, copy, modify, merge, publish,

+// distribute, sublicense, and/or sell copies of the Software, and to

+// permit persons to whom the Software is furnished to do so, subject to

+// the following conditions:

+//

+// The above copyright notice and this permission notice shall be

+// included in all copies or substantial portions of the Software.

+//

+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE

+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION

+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION

+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

+//

+

+using System;

+using System.Collections;

+using System.IO;

+

+namespace Mono.Cecil

+{

+   /// 

+   /// Summary description for Resolver.

+   /// 

+   /// 

+

+   public class AssemblyResolver : IAssemblyResolver

+   {

+   private readonly string [] _libpath;

+   private readonly Hashtable _asmdefs = new Hashtable();

+

+   public AssemblyResolver(string libpath)

+   {

+   _libpath = libpath.Split(';');

+   }

+

+   public IAssemblyDefinition GetAssembly(string name)

+   {

+   if (_asmdefs.C

Re: [Mono-dev] bug and patch for CSharpCodeCompiler.cs

[Eyal Alaluf]

Hi, Andrew.

Did you get any answer for this bug & fix?

Eyal.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Skiba
Sent: 10. júlí 2006 08:40
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] bug and patch for CSharpCodeCompiler.cs

Can someone review the bug report and the patch for
http://bugzilla.ximian.com/show_bug.cgi?id=78731 ?

Thank you.
Andrew.
___
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] [PATCH] System.Net.Sockets.TcpListener 2.0 Updates

[Eyal Alaluf]

Hi, all.

The patch raises one issue for me - shouldn't we define 'NET_1_1' in 'NET_2_0' 
projects?
There are a lot of '#if NET_1_1' scattered around in the code that I'd believe 
behave the same way in the context of 2.0 - they usually refer to functionality 
added in the .Net 1.1 release.

Eyal.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ivan N. Zlatev
Sent: 26. júlí 2006 16:45
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] [PATCH] System.Net.Sockets.TcpListener 2.0 Updates

An updated version of the patch attached. Please review that instead
of the previous one.

On 7/26/06, tcmichals <[EMAIL PROTECTED]> wrote:
> When will this be added to TcpListener?

Whenever someone reviews the patch and, if okay commits it... :|

-- 
Ivan N. Zlatev

Web: http://www.i-nZ.net
GPG Key: http://files.i-nZ.net/i-nZ.asc
"It's all some kind of whacked out conspiracy."
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch for AssemblyNameReference Parse method

[Eyal Alaluf]

Hi, JB.

This is a small fix to the Parse static method of AssemblyNameReference
where the value of PublicToken in the string is allowe to be "null".
Let me know if you have any comments before I commit this patch.

Eyal.Index: Mono.Cecil/AssemblyNameReference.cs

===

--- Mono.Cecil/AssemblyNameReference.cs (revision 66216)

+++ Mono.Cecil/AssemblyNameReference.cs (working copy)

@@ -159,6 +159,9 @@

break;
case "PublicKeyToken":
string pkToken = parts [1];
+   if (pkToken == "null")
+   break;
+
name.PublicKeyToken = new byte 
[pkToken.Length / 2];
for (int j = 0; j < 
name.PublicKeyToken.Length; j++) {
name.PublicKeyToken [j] = 
Byte.Parse (pkToken.Substring (j * 2, 2), NumberStyles.HexNumber);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch to StructureReader.cs

[Eyal Alaluf]

Hi, JB.

In StructureReader.cs under the rare case when the assembly contains more then
1 module the module that is read should also be visited by the StructureReader
otherwise we get exceptions.
The DLL that showed this was either System.EnterpriseServices.dll or one
of the DLLs it uses.
Please let me know if you have any comments before I commit.

Eyal.Index: Mono.Cecil/StructureReader.cs

===

--- Mono.Cecil/StructureReader.cs   (revision 66216)

+++ Mono.Cecil/StructureReader.cs   (working copy)

@@ -232,6 +232,7 @@

modext.Mvid = 
module.Image.MetadataRoot.Streams.GuidHeap [mr.Mvid];
 
modules.Add (modext);
+   modext.Accept(this);
} catch (ReflectionException) {
throw;
} catch (Exception e) {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] MonoTODO attribute usage policy.

[Eyal Alaluf]

Hi, Miguel.

 

We at Mainsoft would like to extend the MonoTODO for documentation
purposes and for the benenfit of tools (like NOMA).

For that end I propose the following change:

  Define - enum MonoTODOCategory { NotSupported, Limitation,
DocumentationNote, Extension, InternalRemark }

  Add a ctor to MonoTODO attribute with the enum as the first param.

This way it will be easy to identify the reason the MonoTODO was added
to the code and use it properly in the documentation or tool.

Any comments are welcome.

 

Eyal.

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Miguel de
Icaza
Sent: 14 November 2006 23:34
To: Ximian Mono List; mono-devel-list@lists.ximian.com
Subject: [Mono-dev] MonoTODO attribute usage policy.

 

Hello,

 

MonoTODO attributes have been used in the past for two purposes: to

warn us about things that must be reviewed (this shows up on the class

status pages) and for comments that a developer would use.

 

Since the Mono Meeting, we discussed using MonoTODOs instead as a

mechanism to provide a textual description that would assist a developer

that might use the API.  So the description should now be only to be

consumed by a user of the API (this is what we actually had documented

in the Wiki).

 

This means that implementation notes like "We should improve X or

Y", do not belong in MonoTODO attributes.  Use "FIXME" strings on the

code, or if the issue is one worth following up with, then file a bug in

Bugzilla.

 

I have updated the 

 

  http://www.mono-project.com/Coding_Guidelines

 

page.

 

Miguel.

___

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] MonoTODO attribute usage policy.

[Eyal Alaluf]

Hi, Miguel.

 

I like the proposal of using different attributes for this purpose.

I am attaching a patch that defines the new attributes.

I am defining MonoDocumentationNote, MonoNotSupported, MonoInternalNote,
MonoLimitation and MonoExtension attributes all inheriting from MonoTODO
attribute.

Any further comments?

 

Eyal.

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Miguel de
Icaza
Sent: 09 December 2006 01:20
To: Charlie Poole
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] MonoTODO attribute usage policy.

 

Hello,

 

> Would one or more separate attributes serve better? Would it be better

> if MonoTODO were called MonoNotSupported and just did one job?

 

That actually makes sense.

 

Why not use different attributes for the different cases instead? 

 

My main problem with using the enumeration is that the enumeration will

likely have a long name:

 

  [MonoTODO (Reason.DocumentationNote, "Bla blah")]

 

While we could have something like 

 

  [MonoDocumentationNote("Dingus")]

 

> In following the discussion, it struck me that the naming of the

> attribute was an open invitation to use it in ways it wasn't intended

> to be used.

>  

> Charlie

> 

> 

> __

> From: [EMAIL PROTECTED]

>     [mailto:[EMAIL PROTECTED] On Behalf Of

> Eyal Alaluf

> Sent: Thursday, December 07, 2006 3:20 AM

> To: Miguel de Icaza; Ximian Mono List;

> mono-devel-list@lists.ximian.com

> Cc: Philippe Cohen; Noam Lampert

> Subject: Re: [Mono-dev] MonoTODO attribute usage policy.

> 

> 

> 

> Hi, Miguel.

> 

>  

> 

> We at Mainsoft would like to extend the MonoTODO for

> documentation purposes and for the benenfit of tools (like

> NOMA).

> 

> For that end I propose the following change:

> 

>   Define - enum MonoTODOCategory { NotSupported, Limitation,

> DocumentationNote, Extension, InternalRemark }

> 

>   Add a ctor to MonoTODO attribute with the enum as the first

> param.

> 

> This way it will be easy to identify the reason the MonoTODO

> was added to the code and use it properly in the documentation

> or tool.

> 

> Any comments are welcome.

> 

>  

> 

> Eyal.

> 

>  

> 

> -Original Message-

> From: [EMAIL PROTECTED]

> [mailto:[EMAIL PROTECTED] On Behalf Of

> Miguel de Icaza

> Sent: 14 November 2006 23:34

> To: Ximian Mono List; mono-devel-list@lists.ximian.com

> Subject: [Mono-dev] MonoTODO attribute usage policy.

> 

>  

> 

> Hello,

> 

>  

> 

> MonoTODO attributes have been used in the past for two

> purposes: to

> 

> warn us about things that must be reviewed (this shows up on

> the class

> 

> status pages) and for comments that a developer would use.

> 

>  

> 

> Since the Mono Meeting, we discussed using MonoTODOs

> instead as a

> 

> mechanism to provide a textual description that would assist a

> developer

> 

> that might use the API.  So the description should now be only

> to be

> 

> consumed by a user of the API (this is what we actually had

> documented

> 

> in the Wiki).

> 

>  

> 

> This means that implementation notes like "We should

> improve X or

> 

> Y", do not belong in MonoTODO attributes.  Use "FIXME" strings

> on the

> 

> code, or if the issue is one worth following up with, then

> file a bug in

> 

> Bugzilla.

> 

>  

> 

> I have updated the 

> 

>  

> 

>   http://www.mono-project.com/Coding_Guidelines

> 

>  

> 

> page.

> 

>  

> 

> Miguel.

> 

> ___

> 

> Mono-devel-list mailing list

> 

> Mon

[Mono-dev] FW: MonoTODO attribute usage policy.

[Eyal Alaluf]

Not at all. A new patch with everything in MonoTODOAttribute.cs is
attached.

-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED] 
Sent: 11 December 2006 18:09
To: Eyal Alaluf
Subject: RE: [Mono-dev] MonoTODO attribute usage policy.

Hello,

> I like the proposal of using different attributes for this purpose.
> 
> I am attaching a patch that defines the new attributes.
> 
> I am defining MonoDocumentationNote, MonoNotSupported,
> MonoInternalNote, MonoLimitation and MonoExtension attributes all
> inheriting from MonoTODO attribute.
> 
> Any further comments?

Would you mind putting them all in the single file that contains
MonoTODO?

Since MonoTODO is not exposed is one of those files we need to keep in
sync across multiple libraries (some are easy, the mcs module), but now
that we have new modules like Olive it will become harder to keep those
in sync.

Miguel.


diff.todo.patch
Description: diff.todo.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] FW: MonoTODO attribute usage policy.

[Eyal Alaluf]

All is committed.
We now have several new attributes:
  MonoDocumentationNote, MonoExtension, MonoInternalNote, MonoLimitation
&
  MonoNotSupported.

Eyal.

-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED] 
Sent: 12 December 2006 21:06
To: Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] FW: MonoTODO attribute usage policy.


> Not at all. A new patch with everything in MonoTODOAttribute.cs is
> attached.

Lovely!   Please commit ;-)

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [Mono-Dev] Small fix for System.Web.UI.HtmlControls.HtmlInputImage.cs

[Eyal Alaluf]

The attached patch uses "PreProcessRelativeReference" on the image "src"
attribute in order to handle relative paths from ASCX user controls.
This is similar to existing code in HtmlImage.cs.
Also maybe "PreProcessRelativeReference" should use ResolveClientUrl
rather then ResolveUrl? HtmlImage and HtmlInputImage generate relative
URLs (at least in 2.0).

Eyal.


HtmlInputImage.diff
Description: HtmlInputImage.diff
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Mono-Dev] Small fix forSystem.Web.UI.HtmlControls.HtmlInputImage.cs

[Eyal Alaluf]

The controls output is an absolute URL when given "http://..."; or even
when given "/WebApplication32/..." and a relative URL when given
"../test1".

-Original Message-
From: Konstantin Triger 
Sent: 12 January 2007 00:48
To: Eyal Alaluf; mono-devel-list@lists.ximian.com
Subject: RE: [Mono-dev] [Mono-Dev] Small fix
forSystem.Web.UI.HtmlControls.HtmlInputImage.cs

Hi Eyal,

> Also maybe "PreProcessRelativeReference" should use ResolveClientUrl
> rather then ResolveUrl?
Can you give it an absolute URL?

Regards,
Konstantin Triger



-Original Message-----
From: [EMAIL PROTECTED] on behalf of Eyal Alaluf
Sent: Thu 11/01/2007 18:47
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] [Mono-Dev] Small fix
forSystem.Web.UI.HtmlControls.HtmlInputImage.cs
 
The attached patch uses "PreProcessRelativeReference" on the image "src"
attribute in order to handle relative paths from ASCX user controls.
This is similar to existing code in HtmlImage.cs.
Also maybe "PreProcessRelativeReference" should use ResolveClientUrl
rather then ResolveUrl? HtmlImage and HtmlInputImage generate relative
URLs (at least in 2.0).

Eyal.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [Mono-Dev]: Modifications to System.Web javascript for J2EE portal support

[Eyal Alaluf]

Hi, Marek and everyone.

 

Attached is a diff to improve support for J2EE portlets for the
TARGET_J2EE configuration. In order to keep the code paths common, most
of the diff is not under '#if TARGET_j2EE'. Therefore I'd like you to
review and approve it before I can commit.

The main issue stems from the fact that portlets in J2EE render HTML
fragments and not the whole page. That is one page can contain several
portlets and therefore several ASP.Net pages. This breaks implicit code
assumptions about uniqueness of global variables. The most important
example is the 'theForm' variable. For Portlet support one cannot assume
that on the client side there is exactly one 'theForm' defined.

The changes common with Mono are:

*An internal property called 'theForm' is added to
System.Web.UI.Page. Its value for TARGET_J2EE will be different for
every portlet.

*We pass the 'theForm' as a parameter to all the JavaScript
functions that use it directly.

a.In cases of callback functions (like functions assigned to
window.onload) we create a function whose name depends upon the portlet
namespace and that passes 'theForm' to the global JavaScript function.

*We save a reference to 'theForm' within the tree view data
(also in details view and grid view data). This allows the JavaScript of
these controls to pass the form to the 'WebForm_DoCallback' function.

 

It is important to note that before this change some key JavaScript
functions were compatible with MS JavaScript functions. After the change
these methods have an extra parameter indicating the form. This means
that if someone used such a function from his JavaScript code then his
code will be broken. 

Do you think that being compatible with MS on JavaScript is an important
feature? Unlike the C# API MS does not document these functions and even
tries to abstract their existence in some of System.Web API (e.g. the
ClientScriptManager class).

 

Your comments are welcome.

 

Eyal.



Portal.jscript.diff
Description: Portal.jscript.diff
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Mono-Dev]: Modifications to System.Web javascript for J2EE portal support

[Eyal Alaluf]

Hi, Marek & all.

Following up on our discussion attached a new patch with minimal changes
to JS API that goes according to the following guide lines
  1. Whenever possible use the ctrl hierarchy to find the form
containing the ctrl
  2. When the method is attached to the form (e.g. 
WebForm_SaveScrollPositionSubmit) use this as the form.
  3. When all else fails append a new parameter to the function. Pass
the form as this param. In the function if the param is not defined use
'theForm'. Thus we still support invoking the function as before.

Any comments are welcome.

Eyal.

-Original Message-
From: Marek Habersack [mailto:[EMAIL PROTECTED] 
Sent: 22 January 2007 20:40
To: Eyal Alaluf
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-Dev]: Modifications to System.Web javascript for J2EE
portal support

On Mon, 22 Jan 2007 09:17:40 -0800, "Eyal Alaluf" <[EMAIL PROTECTED]>
scribbled:

> Hi, Marek and everyone.
Hello Eyal,

> Attached is a diff to improve support for J2EE portlets for the
> TARGET_J2EE configuration. In order to keep the code paths common,
most
> of the diff is not under '#if TARGET_j2EE'. Therefore I'd like you to
> review and approve it before I can commit.
> 
> The main issue stems from the fact that portlets in J2EE render HTML
> fragments and not the whole page. That is one page can contain several
> portlets and therefore several ASP.Net pages. This breaks implicit
code
> assumptions about uniqueness of global variables. The most important
> example is the 'theForm' variable. For Portlet support one cannot
assume
> that on the client side there is exactly one 'theForm' defined.
> 
> The changes common with Mono are:
> 
> *An internal property called 'theForm' is added to
> System.Web.UI.Page. Its value for TARGET_J2EE will be different for
> every portlet.
This is fine

> *We pass the 'theForm' as a parameter to all the JavaScript
> functions that use it directly.
> 
> a.In cases of callback functions (like functions assigned to
> window.onload) we create a function whose name depends upon the
portlet
> namespace and that passes 'theForm' to the global JavaScript function.
> 
> *We save a reference to 'theForm' within the tree view data
> (also in details view and grid view data). This allows the JavaScript
of
> these controls to pass the form to the 'WebForm_DoCallback' function.
> 
> It is important to note that before this change some key JavaScript
> functions were compatible with MS JavaScript functions. After the
change
> these methods have an extra parameter indicating the form. This means
> that if someone used such a function from his JavaScript code then his
> code will be broken. 
> 
> Do you think that being compatible with MS on JavaScript is an
important
> feature? Unlike the C# API MS does not document these functions and
even
> tries to abstract their existence in some of System.Web API (e.g. the
> ClientScriptManager class).
As for the above changes I personally would prefer that the JavaScript
code
remains compatible with MS as far as possible, even though the
documentation
doesn't exist for their JS API. The reason for this is that they may
start
documenting their JS API (the sign of this is the ajax.asp.net stuff,
which
does include documented JS API which, I imagine, would have to be
modified in
the above way when mono includes the implementation of MS AJAX). I think
there
is another way to work around the theForm problem in JS. I'm assuming
that
every portlet has its own identifier of some sort and that this
identifier
could be used to index a table of theForms from within the JS functions
that
need to access it. The array can be generated conditionally for
TARGET_J2EE
from C# code and its existence checked for inside the JS functions (you
could
also add a hidden field with a value specifying that the JS is running
under
mono compiled for TARGET_J2EE. That way all the J2EE specific changes
would be
hidden from the "public" API and the possible future compatibility would
be
preserved.

best regards,

marek


Portal.jscript.diff
Description: Portal.jscript.diff
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch to enable callbacks for Portlets

[Eyal Alaluf]

Hi, Marek & all.

Attached is a patch to enable TARGET_J2EE portlets to use HTTP
callbacks. The patch has two minor changes to the code common with Mono:
  1.  The callback used 'document.URL' as the URL for posting the
callback to. I modified that to use a 'serverURL' field that is added to
the 'theForm'. This is because for J2EE portlets 'document.URL' points
to the J2EE portal page and not to the specific portlet within it.
  2.  WebForm_ClientCallback is using the 'theForm' to access the value
of the '__EVENTVALIDATION' hidden field. Since for portlets 'theForm'
does not exist I passing the right form as a param to
'WebForm_ClientCallback'.
Your comments are welcome.

Eyal.


Portal.Callback.diff
Description: Portal.Callback.diff
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Control.UniqueID Please review

[Eyal Alaluf]

Hi, Adar.

 

You need also to change WebForm_GetFormFromCtrl  in
'resources/webform.js' where we transform in JavaScript a UniqueID to a
ClientID.

 

Eyal.

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adar
Wesley
Sent: 29 January 2007 16:19
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Control.UniqueID Please review

 

Hi All,

 

Please find attached a patch that fixes the implementation of
'Control.UniqueID' to

use Control.IdSeparator and therefore be compatible with MS.NET 2.0.

 

This change also required updating some of the tests that were using the
UniqueID

or ClientID as strings.

 

Since this is such a low level API in System.Web, I am submitting it
here for review

before committing.

 

Please let me know if you see any problem with this implementation or if
I can commit.

 

Thanks,

 

---

Adar Wesley

Mainsoft

 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] System.Web.UI: Patch to enable ASP.Net callbacks for Portlets

[Eyal Alaluf]

Just renaming the title since it didn't indicate the well the
System.Web.UI context.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eyal
Alaluf
Sent: 01 February 2007 18:02
To: Marek Habersack; mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Patch to enable callbacks for Portlets

Hi, Marek & all.

Attached is a patch to enable TARGET_J2EE portlets to use HTTP
callbacks. The patch has two minor changes to the code common with Mono:
  1.  The callback used 'document.URL' as the URL for posting the
callback to. I modified that to use a 'serverURL' field that is added to
the 'theForm'. This is because for J2EE portlets 'document.URL' points
to the J2EE portal page and not to the specific portlet within it.
  2.  WebForm_ClientCallback is using the 'theForm' to access the value
of the '__EVENTVALIDATION' hidden field. Since for portlets 'theForm'
does not exist I passing the right form as a param to
'WebForm_ClientCallback'.
Your comments are welcome.

Eyal.


Portal.Callback.diff
Description: Portal.Callback.diff
___
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] AJAX.NET

[Eyal Alaluf]

Hi, Kosta.

This is off-topic but can you send a patch that replaces the MonoTODO in 
"System.Web.Configuration_2.0/WebConfigurationManager.cs" with MonoLimitation 
(or MonoNotSupported)?

Eyal.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Konstantin Triger
Sent: 07 February 2007 16:45
To: "C. Bergström"
Cc: Miguel de Icaza; Mono Development List
Subject: Re: [Mono-dev] AJAX.NET

Hi Christopher,

First I don't need an xsp for unit testing. For unit testing we use nunit with 
several helper classes enabling us to host Sys.Web to simulate its lifecylce. 
See NunitWeb category in the tests for  examples.  

But if for debugging the mono System.Web in windows environment, I have several 
changes both to sys.web and xsp to get it working (attached).
Currently they are in 'raw' form, good for my machine only. If there is a 
public interest, I can complete and commit them under some define.

Miguel, what do you think?

Regards,
Konstantin Triger

From: "C. Bergström" [mailto:[EMAIL PROTECTED] 
Sent: Saturday, February 03, 2007 7:45 PM
To: Konstantin Triger
Subject: Re: [Mono-dev] AJAX.NET

Konstantin Triger wrote: 
Hello Matthew,

As an alternative, you may consider using Windows box without sygwin to write 
both the tests and implementation for the System.Web.XXX assemblies. This 
greatly simplifies development since you don't need to copy your tests or even 
leave the VS environment (if you like it, of cause).

In case of System.Web.Extensions no setup is required since it sits on top of 
System.Web. For the System.Web development, we (Mainsoft) also use this 
technique, but it little bit trickier. We have several local changes for xsp 
and 
mono System.Web to 'detach' them from the rest mono runtime and run them as a 
console application, again using VS as a development environment. Contact me if 
you need some guide to have this working.

Regarding the tests, the biggest problem is that a huge piece of functionality 
requires context or even postback/callback request. Thus 'usual' nunit tests 
cannot test it. To deal with this problem we developed a nunit based framework 
which hosts the System.Web and provides the required functionality. Look for 
tests marked with "NunitWeb" category under System.Web/Test folder to see 
examples. Using it is not trivial, so post your questions :).

We also plan to contribute to the AJAX.NET development, but this effort is not 
scheduled yet. I believe it will start before the end of the Spring. So I will 
be happy if you will share your design or anything you like; we will assist you 
as much as we can.
  

I do quite do bit of local hackery to try to get such things to work and would 
greatly appreciate it if you have a guide on what you've done to XSP to ease 
unit testing.  Between distractions I've gotten cruise control running under 
Mono, but haven't had a chance to throughly test and finish my setup.

You wouldn't happen to work out of the Bucuresti Mainsoft office would you?

Thanks
-- 


Christopher Bergström
[EMAIL PROTECTED]

US +1 206.279.5000
UK +44 20.709.68810
Main +1 888 NetSyncro

CONFIDENTIAL COMMUNICATION: The information contained in this transmission is 
confidential and is intended only for the use of the entity or individual to 
whom it is addressed. If the reader of this message is not the intended 
recipient, you are hereby notified that any use, disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of this 
communication is strictly prohibited. If you have received this transmission in 
error, please immediately notify us of the error in a reply to the sender.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch: Using MonoLimtation and MonoNotSupported to tag DirectorySecurity as unsupported

[Eyal Alaluf]

Hi, Miguel & all.

Attached is a simple patch that uses the 'MonoLimitaion' and
'MonoNotSupported' attributes for tagging the unsupported
DirectorySecurity feature and APIs.
The patch uses 'MonoLimitation' when the method is partially implemented
(e.g. 'DirectoryInfo.Create (DirectorySecurity directorySecurity)' that
will create the file if 'directorySecurity' is null).
The patch uses 'MonoNotSupoorted' for APIs that have no flow that is
implemented (e.g. 'DirectoryInfo.GetAccessControl()').
Please let me know if the above makes sense and what are the
recommendations for the message string passed to the attributes ctors.

Eyal.



System.IO.diff
Description: System.IO.diff
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [Mono-Dev] CharCategoryTest not working on .Net 2.0

[Eyal Alaluf]

Hi, Atsushi.

We are running the Mono Nunit tests for Mscorlib using Grasshopper.
During this cycle we noticed that the CharCategory test is not working
on .Net 2.0.
Actually the only tests that do pass on /Net 2.0 are 'IsSurrogate' &
'IsControl'.
I see that the tests depend on data obtained from .Net. The APIs and
data have been updated as part of .Net 2.0.
What is the best course of action? Can you update the dump data, or
should we and Mono simply ignore this test under 2.0?

Thanks, Eyal.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] System.Collections.Specialized.NameValueCollection patch

[Eyal Alaluf]

Hi, Ilya.

The fix in the CopyTo is incoreect. It disallows copying to object[] or
IConvertible[] etc.

Eyal.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ilya
Kharmatsky
Sent: 17 April 2007 12:29
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] System.Collections.Specialized.NameValueCollection
patch

Hi,
Please approve attached patch which fix proper exception handling in 
CopyTo method and constructors which get another instance of 
NameValueCollection.
The patch contains also the respective test cases.

Ilya.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list