Re: [Mono-dev] monodevelop with debugger can't start
The debugger is not currently supported in MD. El mié, 16-11-2005 a las 20:44 -0800, zhu shi song escribió: Dear lists, I got monodevelop from svn and compiled it with enable-debugger correctly. But when I run it, there are some errors: 2005-11-17 12:44:01,029 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: SharpDevelop Core 2005-11-17 12:44:01,072 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) 2005-11-17 12:44:01,446 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: MonoDevelop NUnit 2005-11-17 12:44:01,447 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) 2005-11-17 12:44:01,507 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: New Editor 2005-11-17 12:44:01,508 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) 2005-11-17 12:44:01,802 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: Java Language Binding 2005-11-17 12:44:01,802 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) --- The error msgbox show details: -- System.ArgumentException: The addin '' v is not installed. in 0x002f7 MonoDevelop.Core.AddIns.AddInService:ResolveLoadDependencies (System.Collections.ArrayList addins, System.Collections.Stack depCheck, System.String id, System.String version) in 0x0012d MonoDevelop.Core.AddIns.AddInService:ResolveLoadDependencies (System.Collections.ArrayList addins, System.Collections.Stack depCheck, System.String id, System.String version) in 0x000a5 MonoDevelop.Core.AddIns.AddInService:PreloadAddin (IProgressMonitor monitor, System.String id) in 0x002b4 MonoDevelop.Core.AddIns.AddInService:PreloadAddins (IProgressMonitor monitor, System.String[] requestedExtensionPoints) in 0x00680 MonoDevelop.Ide.Gui.IdeStartup:Run (System.String[] args) -- who know how to solve the problem? There is no debugger I even can't program. tks zhu __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ___ 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] External entity resolution
Hello Eno, We fail to load the following xml: !DOCTYPE doc [ !ENTITY e PUBLIC ;[EMAIL PROTECTED] 100.xml !ELEMENT doc (#PCDATA) ] doc/doc The reason is that we try to set the entity content when its declared and not when its referenced. The attached patch fixes the issue. BTW, do we need to resolve it before its referenced? I guess no So the LiteralEntityValue should be empty and we need to create a XmlReader based on SystemId and read the data when requested Regards, Konstantin Triger dtd.diff Description: dtd.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Gnome.Vfs Initialization
Hi,
Before we can use Gnome.Vfs APIs to read remote files, do we need to
initialize it? If so which API is used? I didn't find a suitable API in
monodoc. Any help is appreciated.
I executed the following code -
VfsStream sr = new
VfsStream(@smb://server/share/file.txt,FileMode.Open);
//Read a line from remote file
int c;
while ((c = sr.ReadByte()) = 0)
{
Console.Write((char)c);
}
//Close Stream
sr.Close();
and I get the following error -
(UncTest.exe:10655): GLib-CRITICAL **: file ghash.c: line 291
(g_hash_table_insert): assertion `hash_table != NULL' failed
(UncTest.exe:10655): GLib-CRITICAL **: file ghash.c: line 291
(g_hash_table_insert): assertion `hash_table != NULL' failed
(UncTest.exe:10655): GLib-CRITICAL **: file ghash.c: line 254
(g_hash_table_lookup_extended): assertion `hash_table != NULL' failed
(UncTest.exe:10655): GLib-CRITICAL **: file ghash.c: line 291
(g_hash_table_insert): assertion `hash_table != NULL' failed
(UncTest.exe:10655): GLib-CRITICAL **: file ghash.c: line 225
(g_hash_table_lookup): assertion `hash_table != NULL' failed
(UncTest.exe:10655): libgnomevfs-WARNING **: Internal error: the
configuration system was not initialized. Did you call
_gnome_vfs_configuration_init?
(UncTest.exe:10655): GLib-CRITICAL **: file ghash.c: line 225
(g_hash_table_lookup): assertion `hash_table != NULL' failed
(UncTest.exe:10655): libgnomevfs-WARNING **: Internal error: the
configuration system was not initialized. Did you call
_gnome_vfs_configuration_init?
(UncTest.exe:10655): libgnomevfs-CRITICAL **: file
gnome-vfs-cancellable-ops.c: line 176
(gnome_vfs_get_file_info_uri_cancellable): assertion `uri != NULL'
failed
Unhandled Exception: System.IO.FileNotFoundException: Could not find
uri smb://server/share/file.txt.
in 0x0098b Gnome.Vfs.VfsStream:.ctor (System.String text_uri,
FileMode mode, Boolean async)
in 0x00012 Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode
mode)
in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor
(string,System.IO.FileMode)
in 0x000ab UncTest:DoEverything ()
in 0x00024 UncTest:Main (System.String[] args)
Is initialization the issue here?
Thanks,
Roshan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Wishlist for the new IR
I see that work on the new IR will start soon... Here is a list of things that I think it should have. This is just from the top of my head, I didn't re-read all of the HSSA code to see every point in which I would have liked something more, but anyway if we'll have the infrastructure to handle all the issues I present here adding the missing bits will be trivial ;-) Of course these are just wishes, let's discuss them... I just wanted to discuss them before the work starts. *** Declarative opcode metadata For each opcode, these informations should be easily available, also to offline tools that could be used to generate pieces of C code at build time: - Arity: now there's mono_burg_arity, and it is invaluable, but I wish the information were provided offline (and just checked by monoburg or anything that will replace instruction selection). - Possible (i.e. allowed) stack types for arguments and result. I know we'll not have the concept of evaluation stack anymore because the IR will be linear, but the info is still useful in itself applied to input and output virtual registers. Moreover, it should be exactly known which are the input values used in the opcode, and in which MonoInst field they can be found. - It should be clear if the opcode has special side effects (like OP_CALL), or if its *only* effect is read from its argument[s] and write to its destination virtual registers. Moreover, it should be clear if the semantics of the opcode is such that, given identical input values, it will always give the same result. This is really important because certain classes of optimizations can be applied (or not) depending on this. Now in HSSA, SSAPRE, alias analysis, and in practice everything else I rely on giant switch statements, which are *fugly* (and often quite fragile, because there's always some opcode which I don't fully understand so the default case is generally a safe fallback and not an assert this doesn't happen). - It should also be clearly stated in which stage of the JIT each opcode can be legally found. Now we have a general distinction between CEE_* and OP_*, but it is almost meaningless because most CEE_* opcodes are re-used in the IR. If it were for me, I'd also consider a radical change, which would be avoid reusing CEE_* values at all (and of course create all the necessary OP_* values to handle this). Quite often, the semantics of CEE_ opcodes changes subtly between their use in the CIL stream and their use in the IR, and this would give us troubles in keeping the opcode metadata meaningful. Also, consider that mono_method_to_ir is a giant switch anyway, and inside it the benefit of reusing the CEE_* values is so small that I would say it is nonexistent. This would also make things much clearer by default: CEE_* opcodes would be allowed in the CIL stream (plus the CEE_MONO_* additions in the case of wrappers I guess). Inside the IR we'd just have OP_* opcodes, ant their numbers would have *nothing* to do with the CEE_ ones (they would simply restart from zero). Note that in any case we should have declarative knowledge of which OP_* opcodes are allowed in each JIT stage. - Then there are a couple of operations where we lose too much information in our IR: field accesses and method calls. We keep CEE_LDELEMA opcodes, but we lose field access opcodes after mono_method_to_ir. In HSSA I coded around this, but having the information explicit would makes things easier, and also allow more effective alias analysis. And about method calls the issue I have is that it is not possible to relate each OP_OUTARG[_*] opcode (which is an actual argument) to its formal argument. Again, I coded around this but in the future having the information would allow more precise alias analysis (distinction between out and in-out parameters comes to mind, but most of all *global* analysis when doing AOT). Also, sometimes we read vtable values, which are likely to be read-only in practice (or under the right conditions). Now this information is totally lost, in the IR there's just a lot of pointer arithmetic. - I'd also like to see a general rework of the ssa_op and flags MonoInst fields. Quite often they encode information that should be known at build time, or information that belongs to local variables (see below for a discussion on how they should change). And anyway, we should have declarative knowledge of the exact set of flags allowed for each opcode. *** Storage (local variables and virtual registers): - Local variables should not have a MonoInst anymore IMHO (which means that OP_LOCAL and OP_ARG opcodes shuld disappear). The rationale is that in a linear IR it is obvious that the instruction operands are virtual registers and not MonoInst structs, so it's pointless having special MonoInst opcodes to represent locations. This would have the nice side effect of
Re: [Mono-dev] [PATCH] A fastpath dead code elimination
Hi, The general JIT changes in the patch look harmless to me. There is a problem tough: the patch makes tests/marhal2.exe crash when run with -O=all. Zoltan On 11/15/05, Massimiliano Mantione [EMAIL PROTECTED] wrote: The attached patch implements deadce, but without using SSA. Instead, a simple alias analysis pass takes care of understanding when local variables [may] change value, and liveness computation has been modified to use this aliasing info if present. The alias analysis pass has O(n) complexity (n = code size), it is just a linear sweep on the list of instructions. Then, deadce operates one BB at a time, scanning the code linearly and using the liveness bits as start/end conditions (so it is O(n) as well). I positioned the deadce pass just between the liveness computation and the linear scan register allocator, so that: - it can reuse the liveness computation already computed for the linear regalloc, without requiring a new pass, and - it is downstream in the compilation pipeline, so it has the possibility to catch as many dead instructions as possible. The name fastpath deadce comes from Patrik Torstensson :-) He called it like this on IRC because it is on the fast compilation path (the one without SSA). But now, without other technical stuff, some numbers... First of all, the JIT overhead: the time to JIT mscorlib.dll with various compilation options, in seconds (time mono --compile-all): Options -all -all,ssa JIT time 1.05 1.35 Here we see that just computing SSA has a 30% overhead with respect to a compilation with no optimizations at all. Options default ssa deadce ssa,deadce JIT time 1.32 1.55 1.451.6 And here we see that the overhead of fastpath deadce on a default compilation is almost 10%, while ssa deadce has 21% (and note that in practice, since ssa does not work with aliasing, the new fastpath deadce is applied to more methods). So, the JIT overhead is reasonably small. And finally, some lovely benchmark... I tried SciMark, and here are the results: (MFlops, just the composite score) default205.92 -O=ssa,deadce 210.61 -O=deadce 207.50 -O=consprop,copyprop,deadce207.72 -O=consprop,copyprop,deadce,inline 209.82 -O=inline 213.63 -O=deadce,inline 214.52 So, the idea is that fastpath deadce has some effect :-) It is not as effective as ssa deadce, but it is useful anyway and most of all it does not incur the same JIT time overhead. BTW, I spent a *lot* of time trying to be sure that those numbers are accurate. I had to kill evolution, gaim, beagle, the wireless card, and carefully monitor system load otherwise the results were erratic (just of a few percent, but this is what we're looking at). I then executed the benchmark several (10) times for every case and took the *best* score for each (with the idea that it is the one where other things interfered less), and anyway all the best scores were almost identical. A funny thing: these are the results I have on a SciMark.exe compiled with MS .NET 2.0: default: 136.65 -O=consprop,copyprop,deadce: 137.52 As you can see, they are *low*!!! I still have to understand what the 2.0 csc does exactly, but it looks a real disaster for us :-( Watch out this quirk when doing/examining benchmarks! OK, that's all... please approve the patch :-) We can always refine it later... Ciao, Massi ___ 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] A fastpath dead code elimination
On Thu, 2005-11-17 at 13:23 +0100, Zoltan Varga wrote: The general JIT changes in the patch look harmless to me. There is a problem tough: the patch makes tests/marhal2.exe crash when run with -O=all. That looks more SSAPRE than the patch (or, better, it happens if you specify -O=ssapre and disappears otherwise). SSAPRE and fastdce *cannot* happen togather (if SSAPRE is in, then SSA is built, and in the patch the JIT falls back to SSA deadce). Anyway, I still have to fully debug this, but this doesn't seem to involve fastdce here. I'll investigate more... Thanks, Massi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] XSL tranform result without some white spaces
Hello Atsushi, Ive found that your fix in PreserveWhitespace() method in System.Xml\Mono.Xml.Xsl\XslTransformProcessor.cs (rev. 41620) causes some different behavior from .net. Some white spaces are omitted in the transform result. What do you think about it? See attached sample that reproduces the difference. Vladimir Krasnov doc entry name=XML Extensible Markup language details Great stuffs /details /entry entry name=XSLT eXtensible Stylesheet and Transformation language details Great stuffs /details /entry entry name=XPATH X Path Language details Great stuffs /details /entry /doc doc bibrefXML/bibref bibrefXSLT /bibref bibrefXPATH/bibref bibrefXSD/bibref /doc 91834.xsl Description: 91834.xsl Class1.cs Description: Class1.cs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] OpenBSD 3.8 compilation
Hi all, Well, I didn't find any precompiled mono for OpenBSD, so I tried myself... Steps I had to made 1) in support/mph.h #if defined (PLATFORM_WIN32) || !defined (EOVERFLOW) important || instead of because EOVERFLOW is not defined in OpenBSD either! 2) in libgc/include/private/gc_priv.h instead of # define SIG_SUSPEND SIGRTMIN + 6*/ define # define SIG_SUSPEND SIGUSR1 3) define isnormal, that is not defined in OpenBSD in mono/dis/get.c:#define isnormal(a) (finite(a) (a) != 0.0) 4) Packages to install: bison-1.35p1GNU parser generator glib2-2.6.4 general-purpose utility library pkgconfig-0.15.0p0 tool for managing library compile/link flags 5) install both GNU sed and GNU make (you can go with 'included' make until mcs compilation). 6) export CFLAGS=-DGC_PTHREADS 7) ./configure --with-gc=included -with-ikvm-native=no --prefix=/opt/mono-1.1.10 I got an error in ikvm, so I just removed it... 8) compile libgc with normal make... well, I don't know why, but with gmake it doesn't compile the include GC_pthread_create function... and then you get one of those undefined reference errors Then you can get a mini/mono compiled, but when it tries to run mcs.exe... you get GC Warning: GC_get_nprocs() returned -1 and it never exits but never does anything... Ideas? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] OpenBSD 3.8 compilation
Hi, We don't have an OpenBSD port maintanier, so somebody with the neccesary motivation and technical skills need to step up, do the port, and then maintain it. Zoltan On 11/17/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, Well, I didn't find any precompiled mono for OpenBSD, so I tried myself... Steps I had to made 1) in support/mph.h #if defined (PLATFORM_WIN32) || !defined (EOVERFLOW) important || instead of because EOVERFLOW is not defined in OpenBSD either! 2) in libgc/include/private/gc_priv.h instead of # define SIG_SUSPEND SIGRTMIN + 6*/ define # define SIG_SUSPEND SIGUSR1 3) define isnormal, that is not defined in OpenBSD in mono/dis/get.c:#define isnormal(a) (finite(a) (a) != 0.0) 4) Packages to install: bison-1.35p1GNU parser generator glib2-2.6.4 general-purpose utility library pkgconfig-0.15.0p0 tool for managing library compile/link flags 5) install both GNU sed and GNU make (you can go with 'included' make until mcs compilation). 6) export CFLAGS=-DGC_PTHREADS 7) ./configure --with-gc=included -with-ikvm-native=no --prefix=/opt/mono-1.1.10 I got an error in ikvm, so I just removed it... 8) compile libgc with normal make... well, I don't know why, but with gmake it doesn't compile the include GC_pthread_create function... and then you get one of those undefined reference errors Then you can get a mini/mono compiled, but when it tries to run mcs.exe... you get GC Warning: GC_get_nprocs() returned -1 and it never exits but never does anything... Ideas? ___ 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] Mono Error CS2008
About what is related this error at Mono??? When happend and why??? Thnx __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: External entity resolution
Hi Kosta, I think the idea that entity declaration does not have to resolve the actual entity until it is referenced is nice to do. But the patch breaks several tests with NullReferenceException. Can you please run make run-test in System.XML and hopefully in System.XML/Test/System.Xml/standalone_tests? Andrew made a pretty useful NUnit integration there. Thanks, Atsushi Eno Konstantin Triger wrote: Hello Eno, We fail to load the following xml: !DOCTYPE doc [ !ENTITY e PUBLIC ;[EMAIL PROTECTED] 100.xml !ELEMENT doc (#PCDATA) ] doc/doc The reason is that we try to set the entity content when it's declared and not when it's referenced. The attached patch fixes the issue. BTW, do we need to resolve it before it's referenced? I guess no... So the LiteralEntityValue should be empty and we need to create a XmlReader based on SystemId and read the data when requested... Regards, Konstantin Triger ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Error CS2008
Velazquez Angel wrote: About what is related this error at Mono??? When happend and why??? Do you mean this error? $ mcs error CS2008: No files to compile were specified Compilation failed: 1 error(s), 0 warnings This error ocurs if, well, no input file was specified. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Enum serealization proble in System.Xml.Serialization.XmlMapping
It would be much better if you avoid application/octet-stream for your text attachments (it is even unlikely to be read by others). Are you sure that enum default value is always 0 ? Also, it looks like you forgot to create NUnit test for your example case. Cheers, Atsushi Eno Vladimir Krasnov wrote: Hello All, There is a problem in serialization of Enum default value, the value shouldn't be written to the xml. See attached sample that reproduces the problem. Also please approve the patch that fixes the problem. If no one objects I'll commit. Vladimir Krasnov ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: XSL tranform result without some white spaces
Hi, The fix at r41620 should be fine. The problem was in XsltCompiledContext.cs as fixed at r53184 just now. So it should work fine now. Thanks, Atsushi Eno Vladimir Krasnov wrote: Hello Atsushi, I've found that your fix in PreserveWhitespace() method in System.Xml\Mono.Xml.Xsl\XslTransformProcessor.cs (rev. 41620) causes some different behavior from .net. Some white spaces are omitted in the transform result. What do you think about it? See attached sample that reproduces the difference. Vladimir Krasnov ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] COM Interop in Mono
On 11/16/05 Jonathan S. Chambers wrote:
Attached is a diff of some current progress. These changes are all in
place right now, they would of course need moved to an external library.
Thanks for the patch.
I don't think this stuff should be moved to a library, at least not
until it's windows-only. Moving to a module may be needed later if we
support other COM-like systems using the same interface, but that is
likely way off.
Index: metadata/class.c
===
--- metadata/class.c (revision 52794)
+++ metadata/class.c (working copy)
@@ -2682,6 +2682,12 @@
g_assert (class-field.count == 0);
}
+ /* reserve space to store COM object pointer in RCW */
+ if (class-flags TYPE_ATTRIBUTE_IMPORT
!MONO_CLASS_IS_INTERFACE(class)) {
+ class-instance_size += 2 * sizeof (gpointer);
Reserve room just for one pointer.
Index: metadata/object-internals.h
===
--- metadata/object-internals.h (revision 52794)
+++ metadata/object-internals.h (working copy)
@@ -993,6 +993,17 @@
guint32 location;
} MonoManifestResourceInfo;
+
+typedef struct {
+ MonoObject object;
+ MonoString *guid;
+} MonoReflectionGuidAttribute;
+
+typedef struct {
+ MonoObject object;
+ guint16 intType;
+} MonoInterfaceTypeAttribute;
Add also a:
typedef struct {
MonoObject object;
gpointer comptr;
} MonoCOMWrapper;
and always use it instead of doing pointer arithmetric etc.
Index: metadata/marshal.c
===
--- metadata/marshal.c(revision 52794)
+++ metadata/marshal.c(working copy)
@@ -6309,6 +6309,279 @@
mono_mb_emit_byte (mb, CEE_RET);
}
+void
+component_get_object_and_fnc_ptr(MonoObject *this, MonoMethod* method,
gpointer* pObj, gpointer* pFunc)
Most of these functions should be static. If they need to be exported,
they should be in an header file and have the usual mono_ prefix.
+{
+ IUnknown * pUnk = NULL;
+ int ** vtable;
+ int i = 0;
+ int offset = 0;
+ GUID clsid;
+
+ for (i = 0; i method-klass-interface_count; i++)
+ {
The brace needs to go in the previous line, several of these in the
patch.
+ int first;
+ MonoClass* itf = *(method-klass-interfaces+i);
Change to method-klass-interfaces [i];
+
+ first = itf-method.first;
+ if (first = method-slot first+itf-method.count
method-slot)
Needs spaces around operators like +.
+ {
+ static MonoClass *GuidAttribute;
+ static MonoClass *InterfaceTypeAttribute;
+ MonoCustomAttrInfo *cinfo;
+ MonoReflectionGuidAttribute *attr;
+ MonoInterfaceTypeAttribute* itf_attr;
+
+ offset = method-slot - first;
+
+ if (!GuidAttribute)
+ GuidAttribute = mono_class_from_name
(mono_defaults.corlib, System.Runtime.InteropServices, GuidAttribute);
You need GuidAttribute already in two places: please add it to the
mono_defaults struct. Aso, please use lower case variable names.
+ if (!InterfaceTypeAttribute)
+ InterfaceTypeAttribute = mono_class_from_name
(mono_defaults.corlib, System.Runtime.InteropServices,
InterfaceTypeAttribute);
+
+ if (GuidAttribute) {
No need for this check here: if the attribute is not in corlib there are
bigger issues and we'd have the proper code to check it somewhere _once_
instead of at each loop iteration.
+ cinfo = mono_custom_attrs_from_class (itf);
+ if (cinfo) {
+ attr =
(MonoReflectionGuidAttribute*)mono_custom_attrs_get_attr (cinfo,
GuidAttribute);
+ itf_attr =
(MonoInterfaceTypeAttribute*)mono_custom_attrs_get_attr (cinfo,
InterfaceTypeAttribute);
+ if (attr) {
+ LPOLESTR temp;
+ wchar_t buf[50];
+
wsprintf(buf,L{%s},attr-guid-chars);
You're not allowed to access MonoString-chars directly. Use
mono_string_chars(). This code though, should avoid creating the object
and just access the guid data inside the proper cinfo-data.
Of course this code is invariant in the loop, so it should be moved out
of it.
+ CLSIDFromString(buf, clsid);
+
((IUnknown*)*((int*)this+sizeof(MonoObject)))-lpVtbl-QueryInterface(((IUnknown*)*((int*)this+sizeof(MonoObject))),
clsid, pUnk);
this should
Re: [Mono-dev] Enum serealization proble in System.Xml.Serialization.XmlMapping
Oh, I didn't know that enum fields are always initialized as 0.
So your patch is basically to omit the value string instead of
omitting the entire element (or attribute) and it isn't
deserializable anyways (as well as MS.NET), right?
using System;
using System.IO;
using System.Xml.Serialization;
public class Foo
{
public EnumFoo efoo;
public static void Main ()
{
Foo f = new Foo ();
XmlSerializer s = new XmlSerializer (typeof (Foo));
StringWriter sw = new StringWriter ();
s.Serialize (sw, f);
StringReader sr = new StringReader (sw.ToString ());
f = (Foo) s.Deserialize (sr);
Console.WriteLine (f.efoo);
}
}
public enum EnumFoo {
A = 1,
B = 2
}
Cheers,
Atsushi Eno
Vladimir Krasnov wrote:
Hello Atsushi,
What do mean always 0? Is it may be other value if you don't
initialize enum variable?
I'll create test case soon.
Vladimir Krasnov
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 5:34 PM
To: Vladimir Krasnov
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Enum serealization proble in
System.Xml.Serialization.XmlMapping
It would be much better if you avoid application/octet-stream for
your text attachments (it is even unlikely to be read by others).
Are you sure that enum default value is always 0 ?
Also, it looks like you forgot to create NUnit test for your
example case.
Cheers,
Atsushi Eno
Vladimir Krasnov wrote:
Hello All,
There is a problem in serialization of Enum default value, the value
shouldn't be written to the xml.
See attached sample that reproduces the problem.
Also please approve the patch that fixes the problem.
If no one objects I'll commit.
Vladimir Krasnov
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Directions.
Hello, I have just posted a document that details the status of the Mono Development: http://tirania.org/blog//texts/mono-status.html Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] COM Interop in Mono
Hi,
Unless you want to use it on Linux immediately (and of course if it can be
used on Linux), this should be Windows only currently. As such it can be
simply #ifdef'd as windows-only.
Porting COM interop to Linux will need some support functions exported by
Mono to support everiyhing (not all of the listed functions are necessary):
http://msdn.microsoft.com/library/en-us/com/html/36563ef5-1523-4b77-bca9-472c39e04785.asp
http://msdn.microsoft.com/library/en-us/automat/html/4ecb0c1f-4e4d-4e8b-bd55-9ac6568d027b.asp
Kornél
- Original Message -
From: Jonathan S. Chambers [EMAIL PROTECTED]
To: Paolo Molaro [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Thursday, November 17, 2005 5:52 PM
Subject: RE: [Mono-dev] COM Interop in Mono
Well,
Some things are windows only (BSTR marshalling comes to mind),
at least for now. Should that not be included at this point, or should
it be put inside of an #ifdef? On #mono there was some concern about
different levels of support across platforms.
Also, if I leave this inside of mono for now, any advice on
that? Should I stick all my routines at the bottom of the file for
example, or tag them all with a comment, etc.?
Thanks,
Jonathan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paolo
Molaro
Sent: Thursday, November 17, 2005 11:49 AM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] COM Interop in Mono
On 11/16/05 Jonathan S. Chambers wrote:
Attached is a diff of some current progress. These changes are all in
place right now, they would of course need moved to an external
library.
Thanks for the patch.
I don't think this stuff should be moved to a library, at least not
until it's windows-only. Moving to a module may be needed later if we
support other COM-like systems using the same interface, but that is
likely way off.
Index: metadata/class.c
===
--- metadata/class.c (revision 52794)
+++ metadata/class.c (working copy)
@@ -2682,6 +2682,12 @@
g_assert (class-field.count == 0);
}
+ /* reserve space to store COM object pointer in RCW */
+ if (class-flags TYPE_ATTRIBUTE_IMPORT
!MONO_CLASS_IS_INTERFACE(class)) {
+ class-instance_size += 2 * sizeof (gpointer);
Reserve room just for one pointer.
Index: metadata/object-internals.h
===
--- metadata/object-internals.h (revision 52794)
+++ metadata/object-internals.h (working copy)
@@ -993,6 +993,17 @@
guint32 location;
} MonoManifestResourceInfo;
+
+typedef struct {
+ MonoObject object;
+ MonoString *guid;
+} MonoReflectionGuidAttribute;
+
+typedef struct {
+ MonoObject object;
+ guint16 intType;
+} MonoInterfaceTypeAttribute;
Add also a:
typedef struct {
MonoObject object;
gpointer comptr;
} MonoCOMWrapper;
and always use it instead of doing pointer arithmetric etc.
Index: metadata/marshal.c
===
--- metadata/marshal.c (revision 52794)
+++ metadata/marshal.c (working copy)
@@ -6309,6 +6309,279 @@
mono_mb_emit_byte (mb, CEE_RET);
}
+void
+component_get_object_and_fnc_ptr(MonoObject *this, MonoMethod*
method, gpointer* pObj, gpointer* pFunc)
Most of these functions should be static. If they need to be exported,
they should be in an header file and have the usual mono_ prefix.
+{
+ IUnknown * pUnk = NULL;
+ int ** vtable;
+ int i = 0;
+ int offset = 0;
+ GUID clsid;
+
+ for (i = 0; i method-klass-interface_count; i++)
+ {
The brace needs to go in the previous line, several of these in the
patch.
+ int first;
+ MonoClass* itf = *(method-klass-interfaces+i);
Change to method-klass-interfaces [i];
+
+ first = itf-method.first;
+ if (first = method-slot first+itf-method.count
method-slot)
Needs spaces around operators like +.
+ {
+ static MonoClass *GuidAttribute;
+ static MonoClass *InterfaceTypeAttribute;
+ MonoCustomAttrInfo *cinfo;
+ MonoReflectionGuidAttribute *attr;
+ MonoInterfaceTypeAttribute* itf_attr;
+
+ offset = method-slot - first;
+
+ if (!GuidAttribute)
+ GuidAttribute = mono_class_from_name
(mono_defaults.corlib, System.Runtime.InteropServices,
GuidAttribute);
You need GuidAttribute already in two places: please add it to the
mono_defaults struct. Aso, please use lower case variable names.
+ if (!InterfaceTypeAttribute)
+ InterfaceTypeAttribute =
mono_class_from_name (mono_defaults.corlib,
System.Runtime.InteropServices, InterfaceTypeAttribute);
+
+ if (GuidAttribute) {
No need for this check here: if the attribute is not in corlib there are
bigger issues and we'd have the proper code to check it somewhere _once_
instead of at each loop iteration.
+ cinfo = mono_custom_attrs_from_class
(itf);
+ if (cinfo) {
+ attr =
(MonoReflectionGuidAttribute*)mono_custom_attrs_get_attr (cinfo,
GuidAttribute);
+ itf_attr =
(MonoInterfaceTypeAttribute*)mono_custom_attrs_get_attr (cinfo,
[Mono-dev] Problem in HttpResponseStream
In System.Web/HttpResponseStream the ApplyFilter method does'nt flush the filter before closeing it. In 1.1.7 and .NET Framework the filter will be flushed at final flush. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] C#/mono in IE plugin
When i do a google for C# and IE plugin, i find surprizingly litte. Comments like should be doable, or probably not doable are what I see, but no conrcete answers. I have a project that will start out as a app. that would thus make C#/Mono for use on Linux and Win32 a good sol'n. But there is the need to consider making the project web based in the sence of a no-nonsence Win32 IE plugin up the road. The fact I get very little details about a straight out Win32 C#/.Net use in IE/plugin on google is bad enough, so I'd imagine to think of a C#/mono with say gtk+ or windows.forms to be used as a IE plugin (or with very minor porting issue) would be considered impossible? Anyone comment on the doability of this, or when it might become feasiable? I's assume it would be in MS best interest to make this very easy to do (in time)? And then if thats the case what about Mono support for that, and then taking it to Linux as a FireFox plugin? -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gnome.Vfs Initialization
On Thu, 2005-11-17 at 04:48 -0700, Buderya Roshan wrote: Before we can use Gnome.Vfs APIs to read remote files, do we need to initialize it? If so which API is used? I didn't find a suitable API in monodoc. Any help is appreciated. Are you doing a Gtk.Application.Init? That seems to be all that sample/TestVfs does. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Enum serealization proble in System.Xml.Serialization.XmlMapping
Ah, now I understand what you wanted to do (serializing flag enums).
BTW I'm not maintaining XmlSerializer stuff; you should ping Lluis
to get your patches approved ;-)
Atsushi Eno
Vladimir Krasnov wrote:
You are right, but this occurs only on not flaggable enums. I suppose
the reason for this behavior is indeed an illegal state for such enum.
The reason it's supported for flaggable enum is that the zero value
means all flags are off.
Anyway the correct patch would be in file
System.Xml.Serialization\XmlTypeMapping.cs line 670 :
if (enumName.Equals(0) IsFlags)
Would you like to commit it or you prefer I'll do?
Vladimir Krasnov
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 6:54 PM
To: Vladimir Krasnov
Cc: mono-devel mailing list
Subject: Re: [Mono-dev] Enum serealization proble in
System.Xml.Serialization.XmlMapping
Oh, I didn't know that enum fields are always initialized as 0.
So your patch is basically to omit the value string instead of
omitting the entire element (or attribute) and it isn't
deserializable anyways (as well as MS.NET), right?
using System;
using System.IO;
using System.Xml.Serialization;
public class Foo
{
public EnumFoo efoo;
public static void Main ()
{
Foo f = new Foo ();
XmlSerializer s = new XmlSerializer (typeof (Foo));
StringWriter sw = new StringWriter ();
s.Serialize (sw, f);
StringReader sr = new StringReader (sw.ToString ());
f = (Foo) s.Deserialize (sr);
Console.WriteLine (f.efoo);
}
}
public enum EnumFoo {
A = 1,
B = 2
}
Cheers,
Atsushi Eno
Vladimir Krasnov wrote:
Hello Atsushi,
What do mean always 0? Is it may be other value if you don't
initialize enum variable?
I'll create test case soon.
Vladimir Krasnov
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 5:34 PM
To: Vladimir Krasnov
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Enum serealization proble in
System.Xml.Serialization.XmlMapping
It would be much better if you avoid application/octet-stream for
your text attachments (it is even unlikely to be read by others).
Are you sure that enum default value is always 0 ?
Also, it looks like you forgot to create NUnit test for your
example case.
Cheers,
Atsushi Eno
Vladimir Krasnov wrote:
Hello All,
There is a problem in serialization of Enum default value, the value
shouldn't be written to the xml.
See attached sample that reproduces the problem.
Also please approve the patch that fixes the problem.
If no one objects I'll commit.
Vladimir Krasnov
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gnome.Vfs Initialization
2005/11/17, Mike Kestner [EMAIL PROTECTED]: On Thu, 2005-11-17 at 04:48 -0700, Buderya Roshan wrote: Before we can use Gnome.Vfs APIs to read remote files, do we need to initialize it? If so which API is used? I didn't find a suitable API in monodoc. Any help is appreciated. Are you doing a Gtk.Application.Init? That seems to be all that sample/TestVfs does. AFAIK, you should do: Gnome.Vfs.Vfs.Initialize(); on the beginning of your application and: Gnome.Vfs.Vfs.Shutdown(); in the end. Note that the first Vfs is the namespace, while the second is the Class. But I may be wrong. Cya, Felipe. -- Quem excele em empregar a força militar subjulga os exércitos dos outros povos sem travar batalha, toma cidades fortificadas dos outros povos sem as atacar e destrói os estados dos outros povos sem lutas prolongadas. Deve lutar sob o Céu com o propósito primordial da 'preservação'. Desse modo suas armas não se embotarão, e os ganhos poderão ser preservados. Essa é a estratégia para planejar ofensivas. -- Sun Tzu, em A arte da guerra ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Workflow engine for Mono?
I have been looking the latest WinFX bits from Microsoft, and I found the Workflow Foundation very interesting. Is there any workflow engine for Mono at this moment? If not, I think it would be a good idea to start one, even though I think it's better not to base it in Microsoft implementation, but creating a new one from scratch. We could get a designer, and a workflow engine usable from both MS.NET and Mono. I would be interesting on opening such a project, if there is no one like it. Any volunteers? Alejandro __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [MonoDevelop] MonoDevelop crashes under Mono 1.1.10 on FC3
On Mon, 2005-11-14 at 16:39 -0500, Dean Brettle wrote: On Mon, 2005-11-14 at 20:35 +0100, Lluis Sanchez wrote: I think this is fixed in SVN. Cool! Which component was fixed? Monodevelop, gtk-sharp, mono, or mcs? I'm trying to figure out what I should build from SVN. Any word on this? Using Monodeveop and gtk-sharp from SVN didn't fix the problem. I'm happy to open a bug in bugzilla if someone wants to tell me what component to assign it to initially. Thanks, --Dean ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: SPAM-LOW: [Mono-dev] ANN: NUnit 2.2.3 Released
I've now added binary and source zips, which you can get on sourceforge. I have not put out a mono distribution for this release and I won't unless there's a need for one. My thinking is as follows: 1. Many people using mono want the source anyway. 2. Lots of others run mono under windows and may want to use the distribution in both environments. 3. The rest can easily delete the GUI directories, that being the only difference between mono and windows right now. Does that make sense? I'd especially like to hear about the experience people have in integrating the 2.2.3 bits with mono. If someone would like to write some words that could be added to our installation page, that would be really useful. Charlie PS. I hope to have the net/mono 2.0 version out in the next few days. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Poole Sent: Tuesday, November 15, 2005 6:08 AM To: mono-devel-list@lists.ximian.com Subject: SPAM-LOW: [Mono-dev] ANN: NUnit 2.2.3 Released Hi All, I just released NUnit 2.2.3. It has a few new features and a lot of bug fixes. It's compatible with VS2005 and .NET 2.0, but is still built with .NET 1.1 under VS2003. Only the msi file is available right now - others will follow. You can download it at http://nunit.sf.net. The release notes are available at http://nunit.com/testweb/index.php?p=releaseNotesr=2.2.3. Charlie ___ 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] XSP debugging
On Wed, 2005-11-16 at 23:43 +0100, Marek Habersack wrote: On Wed, Nov 16, 2005 at 11:00:05AM -0600, Carlos Solorzano scribbled: Whats the easiest way to do some debugging of XSP, is there a way to turn on logs for XSP? personally I use log4net (catches also Console.Write/WriteLine) with the following config: It would be nice to have this information in the web page. Do you want to add it? If so, and you don't have an account yet, I'll create one for you. 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] XSP Crash on binding empty dataview to MONO
On Wed, 2005-11-16 at 18:16 -0500, Yogendra Thakur wrote: Please see following bug. http://bugzilla.ximian.com/show_bug.cgi?id=76732 If DataGrid control is binded with EmptyDataView and rebinded again it crashes XSP. See attached crash message and test page. Thanks. I'll take care of this bug soon. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem in HttpResponseStream
On Wed, 2005-11-16 at 17:14 +0100, Geir Johan Bergum wrote: In System.Web/HttpResponseStream the ApplyFilter method does'nt flush the filter before closeing it. In 1.1.7 and .NET Framework the filter will be flushed at final flush. Would you please send a simple test case that I can use 'as-is' to reproduce the problem? -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XSP debugging
Gonzalo Paniagua Javier wrote: On Wed, 2005-11-16 at 23:43 +0100, Marek Habersack wrote: On Wed, Nov 16, 2005 at 11:00:05AM -0600, Carlos Solorzano scribbled: Whats the easiest way to do some debugging of XSP, is there a way to turn on logs for XSP? personally I use log4net (catches also Console.Write/WriteLine) with the following config: It would be nice to have this information in the web page. Do you want to add it? If so, and you don't have an account yet, I'll create one for you. Thanks. I'm making a todo list for documentation that needs updating... So far I have the www.mono-project.com/Mod_mono www.mono-project.com/AutoConfiguration www.mono-project.com/AutoHosting Today was just mentioned to update the README / INSTALL files I'd like to do this in the next day or so.. I'm trying to gather as much useful information as possible.. Contributions are welcome. C. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Workflow engine for Mono? (and code generation too :-)
Hi people! I'm working on a open source server, that can be used like a workflow engine, or like a request/response server. Actually, my implementation is in .NET. When I could stabilize the features and implementation strategies, I'll publish the code. I think that it can be easily ported to Mono. I'm working on a open source metamodel/mode/template code generation engine. You can check: http://www.ajlopez.com/ajgenesis Sorry, No documentation yet But it based in dynamic models (you can create any model you want), and a basic-like scripting engine with templates... Actually, in the examples, using NAnt, it can produce Java, PHP, JSP, VB.NET, C#, web services, service layer, stored procedures, create tables for MySql, a simple HelloWorld, or a semi complete ASP.NET solution I'm working on a web interface, to produce an ASP (Application Service Provider) solution for code generation For both project, the difficult part is the implementation of graphical designers: the people love to draw the workflow or the model (like the new DSL Toolkit for VS 2005) Any link on open source designers? TIA Angel Java Lopez (me Tarzan :-) http://www.ajlopez.com/ - Original Message - From: Alejandro Serrano [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Thursday, November 17, 2005 6:00 PM Subject: [Mono-dev] Workflow engine for Mono? I have been looking the latest WinFX bits from Microsoft, and I found the Workflow Foundation very interesting. Is there any workflow engine for Mono at this moment? If not, I think it would be a good idea to start one, even though I think it's better not to base it in Microsoft implementation, but creating a new one from scratch. We could get a designer, and a workflow engine usable from both MS.NET and Mono. I would be interesting on opening such a project, if there is no one like it. Any volunteers? Alejandro ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gnome.Vfs Initialization
Felipe Almeida Lessa [EMAIL PROTECTED] 11/18/05 1:44 AM 2005/11/17, Mike Kestner [EMAIL PROTECTED]: Are you doing a Gtk.Application.Init? That seems to be all that sample/TestVfs does. Iam doing a standalone executable which needs to read/write to remote shares. AFAIK, you should do: Gnome.Vfs.Vfs.Initialize(); on the beginning of your application and: Gnome.Vfs.Vfs.Shutdown(); in the end. Note that the first Vfs is the namespace, while the second is the Class. That works. Thanks a lot. I still have one doubt. When I call Gnome.Vfs.Vfs.Shutdown, Is only my application affected or is the effect global? What I mean to say is that if there are 2 programs using Gnome.Vfs and one of the calls Vfs.Shutdown while the other is stil executing, will the second program be adversly affected? I think not, but wanted to confirm nevertheless. Many thanks, Roshan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] how to improve mono performance
(1) I feel a little disappointed at the comparsion results. I think we should not only prove we can do this but we can do even better. The performance fact is very essential for production applications. I hope the mono community can improve performance of mono largely. Then mono will be depoyed in many real apps. We have spent so much effort on it, we shouldn't let it be reference implementation just for lab. (2) when I use msft's csc to compile compare.cs, then I run under linux+mono. I just got 10% faster than that compiled by mono mcs. So maybe mono's jit is not so good as msft's. tks zhu --- Ben Maurer [EMAIL PROTECTED] wrote: On Wed, 2005-11-16 at 20:30 -0800, zhu shi song wrote: I've got one test example and tested it using linux mono and windows .NET on the same machine. The results showed that the performance of linux mono is much bad than windows .NET. Linux Mono: ArrayList strings test.3311 ms StringBuilder test.4008 ms Integer Floating ADD.15145 ms Exception test.621 ms Reflection and recursion...9421 ms Windows .Net: ArrayList strings test.1109 ms StringBuilder test.1437 ms Integer Floating ADD.2734 ms Exception test.4046 ms Reflection and recursion...5843 ms Machine configuration: RAM: 512M DDR CPU: Intel C4 2.0G OS: Windows 2003 Server .NET 1.1 Framework Fedora Core 4 with mono compiled from svn Now I try to port my aspx web application to linux mono from windows 2003 .net framework. But regarding of performance, I wonder whether it is deserved. Maybe I lack some tips to improve linux mono performance. If someone knows pls help me. Chances are, your web application does not add items to an array, create stringbuilders, add integers, throw exceptions and do reflection anything like the tests you have configured. I would suggest benchmarking a ported application rather than these micro measurements. If you want to do such measurements, I would recommend something more relevant to your application (database accesses? the asp.net pipeline?) That being said, some possible reasons for slowness: ArrayList/StringBuilder: Likely the GC. Floating Point: I think msft may be taking advantage of some special hardware stuff. I highly doubt this is relevant to your application. Exceptions: We super optimized this path :-) Reflection: Not sure, might be worth looking at -- Ben __ 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
Re: [Mono-dev] monodevelop with debugger can't start
I'm sorry for lacking debugger. It's very important for developing apps. tks zhu --- Lluis Sanchez [EMAIL PROTECTED] wrote: The debugger is not currently supported in MD. El mié, 16-11-2005 a las 20:44 -0800, zhu shi song escribió: Dear lists, I got monodevelop from svn and compiled it with enable-debugger correctly. But when I run it, there are some errors: 2005-11-17 12:44:01,029 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: SharpDevelop Core 2005-11-17 12:44:01,072 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) 2005-11-17 12:44:01,446 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: MonoDevelop NUnit 2005-11-17 12:44:01,447 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) 2005-11-17 12:44:01,507 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: New Editor 2005-11-17 12:44:01,508 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) 2005-11-17 12:44:01,802 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - Add-in failed to load: Java Language Binding 2005-11-17 12:44:01,802 [-1208621376] ERROR MonoDevelop.Core.ILoggingService [(null)] - MonoDevelop.Core.AddIns.AddInLoadException: Missing id attribute in 0x00426 MonoDevelop.Core.AddIns.AddIn:Initialize (System.String fileName) in 0x00054 MonoDevelop.Core.AddIns.AddInTreeSingleton:InsertAddIn (System.String addInFile) --- The error msgbox show details: -- System.ArgumentException: The addin '' v is not installed. in 0x002f7 MonoDevelop.Core.AddIns.AddInService:ResolveLoadDependencies (System.Collections.ArrayList addins, System.Collections.Stack depCheck, System.String id, System.String version) in 0x0012d MonoDevelop.Core.AddIns.AddInService:ResolveLoadDependencies (System.Collections.ArrayList addins, System.Collections.Stack depCheck, System.String id, System.String version) in 0x000a5 MonoDevelop.Core.AddIns.AddInService:PreloadAddin (IProgressMonitor monitor, System.String id) in 0x002b4 MonoDevelop.Core.AddIns.AddInService:PreloadAddins (IProgressMonitor monitor, System.String[] requestedExtensionPoints) in 0x00680 MonoDevelop.Ide.Gui.IdeStartup:Run (System.String[] args) -- who know how to solve the problem? There is no debugger I even can't program. tks zhu __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list __ 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
Re: [Mono-dev] how to improve mono performance
zhu shi song wrote: (1) I feel a little disappointed at the comparsion results. I think we should not only prove we can do this but we can do even better. The performance fact is very essential for production applications. I hope the mono community can improve performance of mono largely. Then mono will be depoyed in many real apps. We have spent so much effort on it, we shouldn't let it be reference implementation just for lab. I agree that performance improvements are impressive, but against your expectation mono is already used in practice, including softwares and individual solutions: http://www.mono-project.com/Software http://www.osnews.com/story.php?news_id=10714 (2) when I use msft's csc to compile compare.cs, then I run under linux+mono. I just got 10% faster than that compiled by mono mcs. So maybe mono's jit is not so good as msft's. Wrong assumption. There are three factors in mono to affect on performance: - class libraries - compiler outputs - JIT The most effective optimizations could be done at class libraries (which could be usually done with a few lines of changes on a few critical paths), where many hot users among users turned into hackers and posting several patches here (and there). Actual analysis and thoughts on which affects on performance are welcome (like what Ben wrote). It would be awesome if you try mono --profile (or heap-buddy in our svn repository) to count individual performance, find out where the code is specially slow, and optimize the sources. Even a line of change could result in more than 200% performance boost in some code areas (I often got such hits in DOM/XSLT areas). Atsushi Eno tks zhu --- Ben Maurer [EMAIL PROTECTED] wrote: On Wed, 2005-11-16 at 20:30 -0800, zhu shi song wrote: I've got one test example and tested it using linux mono and windows .NET on the same machine. The results showed that the performance of linux mono is much bad than windows .NET. Linux Mono: ArrayList strings test.3311 ms StringBuilder test.4008 ms Integer Floating ADD.15145 ms Exception test.621 ms Reflection and recursion...9421 ms Windows .Net: ArrayList strings test.1109 ms StringBuilder test.1437 ms Integer Floating ADD.2734 ms Exception test.4046 ms Reflection and recursion...5843 ms Machine configuration: RAM: 512M DDR CPU: Intel C4 2.0G OS: Windows 2003 Server .NET 1.1 Framework Fedora Core 4 with mono compiled from svn Now I try to port my aspx web application to linux mono from windows 2003 .net framework. But regarding of performance, I wonder whether it is deserved. Maybe I lack some tips to improve linux mono performance. If someone knows pls help me. Chances are, your web application does not add items to an array, create stringbuilders, add integers, throw exceptions and do reflection anything like the tests you have configured. I would suggest benchmarking a ported application rather than these micro measurements. If you want to do such measurements, I would recommend something more relevant to your application (database accesses? the asp.net pipeline?) That being said, some possible reasons for slowness: ArrayList/StringBuilder: Likely the GC. Floating Point: I think msft may be taking advantage of some special hardware stuff. I highly doubt this is relevant to your application. Exceptions: We super optimized this path :-) Reflection: Not sure, might be worth looking at -- Ben __ 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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] how to improve mono performance
BTW we have more detailed description on this topic here: http://www.mono-project.com/Performance_Tips Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] how to improve mono performance
I very agree with you. The right direction to improve performance should be from : - class libraries - compiler outputs - JIT I don't think we put emphasis on apps. Because we have the same source, but the running results are so different using linux+mono and msft .net. I insist that performance is the key factor for key applications. For example, we now have one enterprise web query application. Every day between 8:30AM and 12:00AM, it serve about 2 requests. Now we use one P4 2.6G PC Server with 512M DDR running Windows 2003 Server, it works well. If we port it to Linux + Mono, we must upgrade the hardware to meet the same workload. tks zhu --- Atsushi Eno [EMAIL PROTECTED] wrote: zhu shi song wrote: (1) I feel a little disappointed at the comparsion results. I think we should not only prove we can do this but we can do even better. The performance fact is very essential for production applications. I hope the mono community can improve performance of mono largely. Then mono will be depoyed in many real apps. We have spent so much effort on it, we shouldn't let it be reference implementation just for lab. I agree that performance improvements are impressive, but against your expectation mono is already used in practice, including softwares and individual solutions: http://www.mono-project.com/Software http://www.osnews.com/story.php?news_id=10714 (2) when I use msft's csc to compile compare.cs, then I run under linux+mono. I just got 10% faster than that compiled by mono mcs. So maybe mono's jit is not so good as msft's. Wrong assumption. There are three factors in mono to affect on performance: - class libraries - compiler outputs - JIT The most effective optimizations could be done at class libraries (which could be usually done with a few lines of changes on a few critical paths), where many hot users among users turned into hackers and posting several patches here (and there). Actual analysis and thoughts on which affects on performance are welcome (like what Ben wrote). It would be awesome if you try mono --profile (or heap-buddy in our svn repository) to count individual performance, find out where the code is specially slow, and optimize the sources. Even a line of change could result in more than 200% performance boost in some code areas (I often got such hits in DOM/XSLT areas). Atsushi Eno tks zhu --- Ben Maurer [EMAIL PROTECTED] wrote: On Wed, 2005-11-16 at 20:30 -0800, zhu shi song wrote: I've got one test example and tested it using linux mono and windows .NET on the same machine. The results showed that the performance of linux mono is much bad than windows .NET. Linux Mono: ArrayList strings test.3311 ms StringBuilder test.4008 ms Integer Floating ADD.15145 ms Exception test.621 ms Reflection and recursion...9421 ms Windows .Net: ArrayList strings test.1109 ms StringBuilder test.1437 ms Integer Floating ADD.2734 ms Exception test.4046 ms Reflection and recursion...5843 ms Machine configuration: RAM: 512M DDR CPU: Intel C4 2.0G OS: Windows 2003 Server .NET 1.1 Framework Fedora Core 4 with mono compiled from svn Now I try to port my aspx web application to linux mono from windows 2003 .net framework. But regarding of performance, I wonder whether it is deserved. Maybe I lack some tips to improve linux mono performance. If someone knows pls help me. Chances are, your web application does not add items to an array, create stringbuilders, add integers, throw exceptions and do reflection anything like the tests you have configured. I would suggest benchmarking a ported application rather than these micro measurements. If you want to do such measurements, I would recommend something more relevant to your application (database accesses? the asp.net pipeline?) That being said, some possible reasons for slowness: ArrayList/StringBuilder: Likely the GC. Floating Point: I think msft may be taking advantage of some special hardware stuff. I highly doubt this is relevant to your application. Exceptions: We super optimized this path :-) Reflection: Not sure, might be worth looking at -- Ben __ 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 __ Start your day with Yahoo! -
Re: [Mono-dev] how to improve mono performance
From the measurements I've taken, MS .NET is generally 2 to 3 times faster than Mono, both using micro-benchmarks and applications that do real work. I would also point out that your .NET test was on MS, whereas your Mono test was on Linux. Exception-handling on MS is thought to be very slow. So that might explain part of the reason why Mono was so much faster on that component. As for the strings and StringBuilder, in MS, string and StringBuilder share some internal data structures and use a helper class. So their string operations and conversions between string and StringBuilder are very fast. That being said, some possible reasons for slowness: ArrayList/StringBuilder: Likely the GC. Floating Point: I think msft may be taking advantage of some special hardware stuff. I highly doubt this is relevant to your application. Exceptions: We super optimized this path :-) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
