RE: [Mono-dev] Variant patch
Here is the previous patch plus an incremented corlib, ChangeLog entries, and a series of tests for both BSTR and VARIANT marshalling on windows. Thanks, Jonathan -Original Message- From: [EMAIL PROTECTED] on behalf of Zoltan Varga Sent: Fri 6/2/2006 8:12 PM To: Jonathan S. Chambers Cc: mono-devel-list@lists.ximian.com Subject:Re: [Mono-dev] Variant patch Hey, The patch looks fine. Some tests would be useful, tough. Also, you should increase the corlib version number in System/Environment.cs and in metadata/appdomain.c because of the new Variant class. Zoltan On 6/2/06, Jonathan S. Chambers <[EMAIL PROTECTED]> wrote: > > > > > Here is a patch to add Variant support to mono for basic types. This works > for pinvoke and implements two Variant methods in the Marshal class. I > didn't #ifdef anything for windows since I'm not using any windows specific > calls; let me know if I should. Please review. > > > > Thanks, > > > > Jonathan S. Chambers > > Software Development Engineer > > ANSYS, Inc. > > Phone: 724.514.3682 > > Fax: 724.514.3114 > > E-mail: [EMAIL PROTECTED] > > > > ___ > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > > ___ > 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 variant2.diff Description: variant2.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Problem with System.Reflection.Emit
Hi. I am trying to improve performance by using System.Reflection.Emit. Here is what I do: - I have a class (let's call it vector). It has a 1D array of double for holding the data. - The Vector class has operators (+, -, etc.). In the overloaded operators, I build the _expression_ tree. I am trying to emulate _expression_ template trick. - To copy the result of calculation to the destination Vector, I define a function Assign(). - The function Assign() will emit the opcodes based on _expression_ that is passed. It only emit the opcodes when it's executed for the first time. The next time, it just execute the opcode.The pseudo code of Assign() looks like this: void Assign(_expression_ pex){ if (the opcodes don't exist) { Emit opcodes for _expression_ pex. } execute the emitted opcodes} The main program
looks like this: Vector v1 = new Vector(300); // create vector with 300 elementsVector v2 = new Vector(300); // create vector with 300 elementsVector v3 = new Vector(300); // create vector with 300 elementsVector v4 = new Vector(300); // create vector with 300 elementsVector v5 = new Vector(300); // create vector with 300 elementsVector v6 = new Vector(300); // create vector with 300 elementsVector result = new Vector(300); // create vector with 300 elements result.Assign(v1 + v2 - v3 + v4 - v5 + v6); // copy the result. To find out the performance, I execute Assign() 10 times and measure the execution time. for(int i = 0; i < 10; i++) result.Assign(v1 + v2 - v3 + v4 - v5 + v6); To compare the speed, I also define another function Assign2() and execute it also 10 times.
Here is the implementation: void Assign2(Vector v1, Vector v2, Vector v3, Vector v4, Vector v5, Vector v6){ for(int i = 0; i < m_size; i++) { m_data[i] = v1.m_data[i]+v2.m_data[i]-v3.m_data[i]+v4.m_data[i]-v5.m_data[i]+v6.m_data[i]; }} I expect Assign (using Reflection.Emit) to outperform Assign2 because Assign() basically unrolls the loop. But I am very surprised to find out that Assign2 is almost 3 times faster than Assign(). I tried this in on mono 1.1.13.8 How can this happen? I thought Reflection.Emit is superior.Am I doing something wrong? Does it have something to do with memory or cache or Can someone help me? The opcodes that I emitted is pretty much the same as the opcodes in Assign2 because I monodis Assign2() and then
basically "copy" the opcodes to Assign() I don't mind to go down to opcodes level as long as I can get the performance. But the result has been dissapointing so far. Thank you for your attention. Rusmin __Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Fedora Core 5 rpms now available for Monodevelop
Hi, http://www.all-the-johnsons.co.uk/mono/rpms.html With the exception of ikvm and monodoc, the rest are awaiting authorisation to be included into Fedora Extras. They are not currently part of FE and all reports of problems should be sent directly to me. The site contains the latest builds for both x86 and x86_64 architectures. The src rpms and spec files are all available from http://www.knox.net.nz/~nodoid (except ikvm and monodoc which can be found in the FE area of the fedora core ftp site). If you use the spec files and build on anything other than an x86 or x86_64 bit system and want the rpms hosting, please let me know. Instructions: 1. Download the lot 2. su 3a (if you have never installed them before) rpm -ihv *.rpm 3b (if you have a previous version in there) rpm -Uhv *.rpm Currently there is a bug in the version of gtk shipped with both FC5 and rawhide. This prevents monodevelop from running currently. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu hüpfen signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for HttpRequest.cs
On Mon, 2006-06-05 at 17:01 +0200, Juraj Skripsky wrote: > Hi, > > Did anyone had a chance to look at the patches? Is there anything I can > do the speed up the process? > http://lists.ximian.com/pipermail/mono-devel-list/2006-May/018667.html Somehow I didn't get that email. In the patch for HttpUtility: - return ParseQueryString (query, Encoding.UTF8); + return ParseQueryString (query, Encoding.Default); MS documentation explicitly mentions UTF8 as the encoding used for ParseQueryString (string). Please add a comment that refers to the test that proves the documentations is wrong. Feel free to commit the three patches after that. Thanks. -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 for HttpRequest.cs
Hi, Did anyone had a chance to look at the patches? Is there anything I can do the speed up the process? http://lists.ximian.com/pipermail/mono-devel-list/2006-May/018667.html And there's a bug I've filed almost 4 months ago, including an "naive" patch. Did anyone look at it? http://bugzilla.ximian.com/show_bug.cgi?id=77769 - Juraj ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono frustration
Hi, > 178901 - gtksourceview-sharp > 178904 - monodevelop > 189092 - boo > 189093 - mono-debugger > 193957 - nant 194054 - monodoc -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization strategies for compatibility.
>> > Now in .NET 1.1 SP-N I noticed that they introduced some changes. >> > Some classes now implemented some new interfaces that were not present >> > in .NET 1.1. My question is: what is the justification to add new >> > implemented interfaces to classes, >> >> No idea. >> > > Big fixes is one possible reason. (IIRC System.Threading.WaitHandle > neglected to implement IDisposable initially. It does in 2.0 and now > maybe in 1.1 SP-N.) System.Threading.WaitHandle implements IDisposable at least since MS.NET 1.0 RTM. Sorry, remembered incorrectly. .NET Compact Framework 1.0 was where IDisposable was left off WaitHandle. Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization strategies for compatibility.
> In general I agree, but ISerializable is a bit of a special case due > to remoting. It is unlkiely but conceivable that somewhere in remoting > plumbing (in Mono or another tool) somebody might "if(x is > ISerializable)...". There is no such code in remoting, and even if it was I don't see how it could be a problem. Objects serialized with field serialization or with the ISerializable interface have the same binary format. > > It might be worth considering an IMonoSerializable interface? > > Mike > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono frustration
Hi, > > I've just been trying to install the monodevelop IDE and associated > > utilities for FC5 as per your excellent instructions on the mono-develop > > mailing list. > Yes - I'm moving job, so have moved the packages. I will be putting up > fresh builds tonight via my home website - there are plenty of fixes, > including one which sorts out the chomping of the mime encodings! I've uploaded the 64 bit versions of the rpms - the 32 bit versions will be around later today. http://www.all-the-johnsons.co.uk/mono/rpms.html Please remember, other than ikvm, all of these packages have not been yet added to the official Fedora Extras yum repository. If you find a problem, you can file bugs by going to the following bugs at bugzilla.redhat.com 178901 - gtksourceview-sharp 178904 - monodevelop 189092 - boo 189093 - mono-debugger 193957 - nant monodoc seems to have vanished currently! TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization strategies for compatibility.
El dl 05 de 06 del 2006 a les 00:42 -0400, en/na Miguel de Icaza va escriure: (snip) > Since this stuff is genuinely useful, I was considering whether we > could make our 1.1 implementation support it, but to avoid exposing a > non-existent 1.1 type, we could do a name-based attribute lookup on the > methods and if we find that there is such an attribute, we could perform > the same tasks that 2.0 does. This means that 1.1 assemblies could get > the 2.0 "hooks" by including their own copy of the attribute. The only > issue here is whether this would not have a negative performance > impact. > > The second issue is: how do we cope with deserialization in the > future without having to change our internals extensively? And I think > that if we extend the serialization framework we can do this. > > We could introduce some *extra* attributes that are specific to > Mono, and that are applied to the type. If such attribute is found, it > would instruct the deserializer to not perform the manual > deserialization/serialization, but instead use an ISerializable-like > approach on that given class, this would give us the control we need. One problem of using Mono-specific hooks (or using 2.0 hooks in 1.1) is that we can't force custom formatters to use those hooks, so we can't guarantee that formatters other than BinaryFormatter or SoapFormatter would be able to deserialize Color objects. We can implement this logic in ObjectManager, which has a high probability of being used by custom formatters, but it use is not mandatory. > > Now in .NET 1.1 SP-N I noticed that they introduced some changes. > Some classes now implemented some new interfaces that were not present > in .NET 1.1. My question is: what is the justification to add new > implemented interfaces to classes, and could we get away by just > sprinkling "ISerializable" on our classes, or would that be considered a > massive breach of API compatibility? The API would be different, but I don't see how this change could break existing code. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C APIs for signatures
Hello Fulvio, On Sun, 2006-06-04 at 23:10 +0200, Fulvio Satta wrote: > Hi, this is my first post in this ml. Welcome! > I want to know the APIs (for embedding mono) for discover the autenticode > sign > of a PE, if exists. Not quite sure what you want exactly. Do you want to embed Mono into your application and verify (not sign) authenticode signature ? or you may want to sign PE files using the Mono runtime ? Anyway Mono support(*) signing PE files using authenticode by supplying the same tools as Microsoft (makecert, cert2spc, signcode, chktrust). The biggest difference is that all Mono tools are fully managed (and can run on the MS runtime too). (*) What Mono doesn't currently support (but some people did it) is signing CAB files (which aren't PE files). -- 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
Re: [Mono-dev] Serialization strategies for compatibility.
> Now in .NET 1.1 SP-N I noticed that they introduced some changes. > Some classes now implemented some new interfaces that were not present > in .NET 1.1. My question is: what is the justification to add new > implemented interfaces to classes, No idea. Big fixes is one possible reason. (IIRC System.Threading.WaitHandle neglected to implement IDisposable initially. It does in 2.0 and now maybe in 1.1 SP-N.) System.Threading.WaitHandle implements IDisposable at least since MS.NET 1.0 RTM. Some System.Runtime.InteropServices interfaces prefixed with _ were added in MS.NET 1.1 SP1 for more proper COM interop support. Another exapmle is System.Web.HttpResponse.TransmitFile method that was added to MS.NET 1.0 and MS.NET 1.1 by a hotfix and later Service Packs include it: http://support.microsoft.com/kb/823409/en-us Regarding such post-RTM API changes I suggest to implement the API of the latest MS.NET Service Packs available because this is what people usually use and Microsoft probable evaluated the drawbacks of such changes and the should be fully backward compatible. Kornél ___ 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.Web.HttpApplication.InitOnce
> Don't commit. It's a hack that fixes the problem for you, but > we don't know why that happens. > That happens because HttpContext.Current is set in HttpRuntime.RealProcessRequest, and when HttpApplication.Start runs in a different thread, HttpContext.Current is null. I explained it in more details here: http://bugzilla.ximian.com/show_bug.cgi?id=78583 To reproduce the bug cd to System.Web/Test/standalone/hosting/test1 and make run-test. Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization strategies for compatibility.
> Now in .NET 1.1 SP-N I noticed that they introduced some changes. > Some classes now implemented some new interfaces that were not present > in .NET 1.1. My question is: what is the justification to add new > implemented interfaces to classes, No idea. Big fixes is one possible reason. (IIRC System.Threading.WaitHandle neglected to implement IDisposable initially. It does in 2.0 and now maybe in 1.1 SP-N.) > and could we get away by just > sprinkling "ISerializable" on our classes, or would that be considered a > massive breach of API compatibility? It's only a breach of API compatibility if people find out about it. :-) That is, if people know the class implements a given interface, they may rely on that fact, which would hinder portability to .NET. ... So just sprinkling ISerializable everywhere may be acceptable, as long as it's not documented. In general I agree, but ISerializable is a bit of a special case due to remoting. It is unlkiely but conceivable that somewhere in remoting plumbing (in Mono or another tool) somebody might "if(x is ISerializable)...". It might be worth considering an IMonoSerializable interface? Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: Serialization strategies for compatibility.
Hi,
These particular hooks would allow us to implement a fast "Color",
for instance, we can use the [OnDeserialized] attribute and compute the
ARGB values as soon as the type has been de-serialized, avoiding
completely the ugly test that we currently have in place.
Now, there are two problems:
* It is only available in 2.0.
I've implemented 2.0 serialization a couple of days ago. It still
needs some unit tests and a complete interoperatibility test.
I'll finish them by the end of the week, if I'll not discover
that the reflective approach of calling the new hooks is
too slow ... (see below).
* The new hooks do not cope well with differently-named fields.
Indeed, it's a bit clumsy:
[NonSerialized] type monoFieldName;
type msnetFieldName;
[OnSerializing]
void Serialize (StreamingContext context)
{
msnetFieldName = monoFieldName;
}
[OnDeserialized]
void Deserialize (StreamingContext context)
{
monoFieldName = msnetFieldName;
}
Since this stuff is genuinely useful, I was considering whether we
could make our 1.1 implementation support it, but to avoid exposing a
non-existent 1.1 type, we could do a name-based attribute lookup on the
methods and if we find that there is such an attribute, we could perform
the same tasks that 2.0 does. This means that 1.1 assemblies could get
the 2.0 "hooks" by including their own copy of the attribute. The only
issue here is whether this would not have a negative performance
impact.
The additional performance loss can be neglected, because it's probably
bad enough already:
// 2.0
foreach (MethodInfo mi in type.GetMethods (...)) {
if (params match StreamingContext)
methodInfo.GetCustomAttributes (
typeof (OnDeserializedAttribute))
cache the MethodInfo
}
vs.
// 1.0
foreach (MethodInfo mi in type.GetMethods (...)) {
if (params match StreamingContext)
foreach (Attribute a in mi.GetCustomAttributes ()) {
if (a.FullName.EndsWith (".OnDeserializedAttribute")) ...
cache the MethodInfo
}
which must be done only once per type.
I guess a code generator will be necessary to optimize this.
The second issue is: how do we cope with deserialization in the
future without having to change our internals extensively? And I think
that if we extend the serialization framework we can do this.
We could introduce some *extra* attributes that are specific to
Mono, and that are applied to the type. If such attribute is found, it
would instruct the deserializer to not perform the manual
deserialization/serialization, but instead use an ISerializable-like
approach on that given class, this would give us the control we need.
Now in .NET 1.1 SP-N I noticed that they introduced some changes.
Some classes now implemented some new interfaces that were not present
in .NET 1.1. My question is: what is the justification to add new
implemented interfaces to classes, and could we get away by just
sprinkling "ISerializable" on our classes, or would that be considered a
massive breach of API compatibility?
I'd go for an extra attribute that could be attached on
the type (like [Serialized]), and that expects the same
semantics like ISerializable (method GetObjectData and
.ctor(SerializationInfo, StreamingContext)).
My concern with those solutions is: how do they fit
in the CAS? Are there some hidden security implications?
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono frustration
On Sun, 2006-06-04 at 10:02 +0100, Martin Paul Goodrich wrote: > Hi Paul, > > I've just been trying to install the monodevelop IDE and associated > utilities for FC5 as per your excellent instructions on the mono-develop > mailing list. > > However, it seems that the links based upon > http://www.smmp.salford.ac.uk/packages have all been discontinued; have > they been located elsewhere? Yes - I'm moving job, so have moved the packages. I will be putting up fresh builds tonight via my home website - there are plenty of fixes, including one which sorts out the chomping of the mime encodings! http://www.all-the-johnsons.co.uk/mono/rpms.html (or it may be .shtml - can't remember!) The good news is that MD is almost in, ikvm is already in FE which means just boo and gtksourceview-sharp need approval - progress is slow, but it is moving. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization strategies for compatibility.
On Mon, 2006-06-05 at 00:42 -0400, Miguel de Icaza wrote:
> Now in .NET 1.1 SP-N I noticed that they introduced some changes.
> Some classes now implemented some new interfaces that were not present
> in .NET 1.1. My question is: what is the justification to add new
> implemented interfaces to classes,
No idea.
> and could we get away by just
> sprinkling "ISerializable" on our classes, or would that be considered a
> massive breach of API compatibility?
It's only a breach of API compatibility if people find out about it. :-)
That is, if people know the class implements a given interface, they may
rely on that fact, which would hinder portability to .NET.
Further, there are three ways people would find out what interfaces a
type implements:
- Documentation
- Reflection
- Reading Mono's Sources
Since Documentation follows .NET's types, no one would determine the new
interfaces only by reading the documentation, which leaves Reflection &
Mono's sources.
Microsoft has frequently said to treat Reflection with a grain of salt
(newly added members may cause exceptions to be generated in the future
due to newly created ambiguities, etc.), so it could be ignored.
And anyone reading the sources gets whatever they deserve. :-)
So just sprinkling ISerializable everywhere may be acceptable, as long
as it's not documented.
Alternatively, if Reflection is an important scenario, we'd need a way
to "hide" the interface from being returned by Reflection, which could
be done via an internal attribute:
[HideFromReflection (typeof(ISerializable))]
class Color : ISerializable { /* ... */ }
though this path may lead to madness as well.
Another shot against caring about Reflection is that Reflection will
return internal interfaces & attributes, so your approach of defining
additional internal attributes would still result in them being returned
by Reflection, thus (in principal) breaking "absolute compatibility
with .NET" (as types would be presented which aren't under .NET).
End result: I'd suggest just sprinkling ISerializable where needed and
_not_ documenting it. It's an implementation detail, and not
significantly worse than the alternatives.
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cecil.FlowAnalysis and exception handler blocks
Hey Russel, On Jun 4, 2006, at 8:50 PM, Russell Morris wrote: I'm interested in knowing if anyone out there is currently working in this area of Cecil, and would have anything to add to this analysis. I'm working on it. It should land soon in SVN. Jb 3 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] NHibernate + DynamicProxies + Mono trouble
Hello ! I'm working with NHibernate for my application. I have some trouble but step by step I'm able to find solution (Thanks to google). The last one was a problem of compatibility between Mono and DynamicProxies (from castle project). All info are here : http://support.castleproject.org/jira/browse/DYNPROXY-21. Now : I've this exception which seems coming from the mscorlib on mono ? ** (/donnees/Documents/Projets/MonoDevelop/NHibernate_Exemple/SourceCode/OrderSystem/OrderSystem.UI/bin/Debug/OrderSystem.UI.exe:10433): WARNING **: Missing member Equals in type OpCode, assembly /donnees/Applications/Dev/Mono/mono-1.1.13.4/lib/mono/1.0/mscorlib.dll Unhandled Exception: NHibernate.LazyInitializationException: Failed to lazily initialize a collection ---> NHibernate.HibernateException: Creating a proxy instance failed ---> System.MissingMethodException: Method not found: 'System.Reflection.Emit.OpCode.Equals'. in <0x0> But when I look in the methods ... I find it ... ANy idea ? Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono frustration
Hi Paul, I've just been trying to install the monodevelop IDE and associated utilities for FC5 as per your excellent instructions on the mono-develop mailing list. However, it seems that the links based upon http://www.smmp.salford.ac.uk/packages have all been discontinued; have they been located elsewhere? I have to say that I'm a little disappointed that the FC5 release team are taking so long to release the monodevelop package as an RPM for install on FC5. I would have thought that with the current world focus on C#/.NET it would assume a higher priority than it currently is. Anyway, any help you could give would be gratefully acknowledged. Best regards, Martin Goodrich ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
