[Mono-devel-list] Contribution to MSBuild
Hi, i am a dotnet developer and would like to make a contribution to Mono by getting involved in the development of the MSBuild Compilation tool for 1.2 . please let me know if anyone else is working on this (or is willing to) and we can collaborate. thanks and regards, Anirudh-- Tomorrow's what i am waiting for, but i can wait a little more - Calvin, Scientific Progress Goes 'Boink'
Re: [Mono-devel-list] Contribution to MSBuild
Anirudh Chandrakant wrote: Hi, i am a dotnet developer and would like to make a contribution to Mono by getting involved in the development of the MSBuild Compilation tool for 1.2 . please let me know if anyone else is working on this (or is willing to) and we can collaborate. thanks and regards, Anirudh -- Tomorrow's what i am waiting for, but i can wait a little more - Calvin, Scientific Progress Goes 'Boink' On the MonoDevelop repository there's an MSBuild tree.. looks fairly preliminary and empty. You'd have to engineer your own makefiles [I suggest using Premake, so Monodevelop, SharpDevelop, Visual Studio, and GNU make files can be automatically generated... it's fairly simple once you figure it out + there's lots of docs]. -- Thomas Harning Jr. ___ 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] r43792 - in trunk/mcs/build: . profiles
Hey, On Mon, 2005-05-02 at 12:17 +0530, Raja R Harinath wrote: Ben Maurer [EMAIL PROTECTED] [EMAIL PROTECTED] writes: 2005-04-29 Ben Maurer [EMAIL PROTECTED] * profiles/basic.make: The test for mcs was broken on jails where we got a warning due to /proc not being mounted. Remove hackish wc usage. ??? Why remove a working test that caught an actual problem? What's wrong with adding a 'mount /proc' to the jail setup script? We are not worried about running untrusted code inside the jail. Because anything could create extra text. Say I wanted to run make with MONO_LOG_LEVEl set? Maybe I am running with some light weight profiler? My test made sure the exit status of mono was correct (at least, I am pretty sure it does) -- this is what really matters. If mcs can run and create a binary that returns a 0 exit status, things are probably working OK. Also, something inside mono seems to like having /proc mounted -- that's why the warning. So, why not fix that instead? I want to keep the rpm build scripts simple. If I keep on adding hack after hack, the scripts are going to become a mess. Its much cleaner to make the build system a bit more flexible so that it does not need customization on the user's part to build. -- Ben ___ 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 mimic MS.Net remoting name mangling
I put together a little patch to improve Mono-MS.Net remoting
compatibility. Basically, MS.Net mangles the names of private
inherited fields for SOAP-serialized objects. I've opened a bug
(#74760) to track the issue...
http://bugs.ximian.com/show_bug.cgi?id=74760
Please see it for a more detailed description of the issue.
Attached here is the patch (also with the bug report). Does it look
reasonable?
Because it looked like it belongs in the same place, I also added
support for the SoapFieldAttribute.XmlFieldName in the serializer.
(The attribute was implemented, but the SOAP serialization stuff
didn't use it.) Of course, that's still only a very partial
implementation of the SoapFieldAttribute stuff.
I wasn't sure where to put the name mangling routine because both
SoapReader and SoapWriter need to use it. So I just picked one and
went with it.
--
Luke Ravitch [EMAIL PROTECTED] Telephone: 310-864-7478
Software Engr., Advanced Software Sys. | One Hornet Way, MS 9M52/W6
Northrop Grumman Integrated Systems | El Segundo, CA 90245-23804
Index:
mcs/class/System.Runtime.Serialization.Formatters.Soap/System.Runtime.Serialization.Formatters.Soap/SoapWriter.cs
===
---
mcs/class/System.Runtime.Serialization.Formatters.Soap/System.Runtime.Serialization.Formatters.Soap/SoapWriter.cs
(revision 43735)
+++
mcs/class/System.Runtime.Serialization.Formatters.Soap/System.Runtime.Serialization.Formatters.Soap/SoapWriter.cs
(working copy)
@@ -391,6 +391,8 @@
// bool specifyEncoding = false;
// if(objectData[i] != null)
// specifyEncoding =
(objectData[i].GetType() != fieldInfo.FieldType);
+
+ string name = SoapReader.GetFieldName
(fieldInfo, currentType);
_xmlWriter.WriteStartElement(fieldInfo.Name);
SerializeComponent(
objectData[i],
Index:
mcs/class/System.Runtime.Serialization.Formatters.Soap/System.Runtime.Serialization.Formatters.Soap/SoapReader.cs
===
---
mcs/class/System.Runtime.Serialization.Formatters.Soap/System.Runtime.Serialization.Formatters.Soap/SoapReader.cs
(revision 43735)
+++
mcs/class/System.Runtime.Serialization.Formatters.Soap/System.Runtime.Serialization.Formatters.Soap/SoapReader.cs
(working copy)
@@ -729,7 +729,39 @@
indices);
}
}
-
+
+ // MS.Net uses _x002B_ in serialization to delimit base class
from field name for
+ // private inherited fields (see GetFieldName below). Any
instances of _x002B_
+ // in the original field name are escaped with _x005F_, as
are any prior instances
+ // of _x005F_. This function performs that escaping.
+
+ static private string EscapeName (string s)
+ {
+ return (s.Replace (_x005F_, _x005F_x005F_)).Replace
(_x002B_, _x005F_x002B_);
+ }
+
+ static public string GetFieldName (FieldInfo info, Type type)
+ {
+ string name;
+ Type attr_t = typeof (SoapFieldAttribute);
+ SoapFieldAttribute soapAttr =
Attribute.GetCustomAttribute (info, attr_t) as SoapFieldAttribute;
+
+ if ((soapAttr != null) (soapAttr.XmlElementName !=
null)) {
+ name = EscapeName (soapAttr.XmlElementName);
+ } else {
+ name = EscapeName (info.Name);
+ // To maintain compatibility with MS.Net, we
need to mangle the names
+ // of any private inherited members that don't
have XmlElementName set
+ // in a SoapFieldAttribute. MS.Net prepends
the base class name to
+ // the field name, using _x002B_ as a
delimiter.
+ if (info.IsPrivate (info.DeclaringType !=
type)) {
+ name = EscapeName
(info.DeclaringType.Name) + _x002B_ + name;
+ }
+ }
+
+ return name;
+ }
+
TypeMetadata GetTypeMetadata (Type type)
{
TypeMetadata tm = _fieldIndices[type] as TypeMetadata;
@@ -738,10 +770,14 @@
tm = new TypeMetadata ();
tm.MemberInfos =
FormatterServices.GetSerializableMembers (type, _context);
- tm.Indices = new
Re: [Mono-devel-list] Patch to mimic MS.Net remoting name mangling
This bug needs a more generic solution. Field names should be encoded using XmlConvert.EncodeLocalName, since there may be other characters in the name that are not valid in xml names. For inherited fields, the serialized name should be className+fieldName. The binary serializer already write serialized fields in this way, but the class name is not being added in the soap serializer (notice that + will be encoded to _002B_ by XmlConvert.EncodeLocalName). On dl, 2005-05-02 at 12:17 -0700, Luke Ravitch wrote: I put together a little patch to improve Mono-MS.Net remoting compatibility. Basically, MS.Net mangles the names of private inherited fields for SOAP-serialized objects. I've opened a bug (#74760) to track the issue... http://bugs.ximian.com/show_bug.cgi?id=74760 Please see it for a more detailed description of the issue. Attached here is the patch (also with the bug report). Does it look reasonable? Because it looked like it belongs in the same place, I also added support for the SoapFieldAttribute.XmlFieldName in the serializer. (The attribute was implemented, but the SOAP serialization stuff didn't use it.) Of course, that's still only a very partial implementation of the SoapFieldAttribute stuff. I wasn't sure where to put the name mangling routine because both SoapReader and SoapWriter need to use it. So I just picked one and went with it. ___ 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] Fix for stack walk
Hello,
My last patch wasn't ok as it was still possible for some data to be
collected. So the new code allocates a MonoArray with a base value and
double the array size if it runs out of space.
After some gnumeric-fu, the default array length for the stack has been
set to 6 - but this is likely to change in the future (i.e. once more
permissions checks are present in corlib).
New patch is attached.
Thanks
On Wed, 2005-04-27 at 08:56 -0400, Sebastien Pouliot wrote:
Hello,
This patch fix a bug where a security stack frame could be collected
before it's intended time. The frames are now allocated (without the GC)
until we know on many there are, then copied (i.e. reallocated with the
GC), kept in a MonoArray and returned to managed code.
The MonoAppDomain information has also been added to the structure. This
will allow some limited (bug #74411) appdomain-cas-fu (i.e. sandbox).
--
Sebastien Pouliot [EMAIL PROTECTED]
blog: http://pages.infinit.net/ctech/poupou.html
Index: mini-exceptions.c
===
--- mini-exceptions.c (revision 43886)
+++ mini-exceptions.c (working copy)
@@ -447,9 +447,26 @@
typedef struct {
guint32 skips;
- GList *stack;
+ MonoArray *stack;
+ guint32 count;
+ guint32 maximum;
} MonoSecurityStack;
+static void
+grow_array (MonoSecurityStack *stack)
+{
+ MonoDomain *domain = mono_domain_get ();
+ guint32 newsize = (stack-maximum 1);
+ MonoArray *newstack = mono_array_new (domain, mono_defaults.runtimesecurityframe_class, newsize);
+ int i;
+ for (i=0; i stack-maximum; i++) {
+ gpointer frame = mono_array_get (stack-stack, gpointer, i);
+ mono_array_set (newstack, gpointer, i, frame);
+ }
+ stack-maximum = newsize;
+ stack-stack = newstack;
+}
+
static gboolean
callback_get_stack_frames_security_info (MonoDomain *domain, MonoContext *ctx, MonoJitInfo *ji, gpointer data)
{
@@ -469,7 +486,10 @@
return FALSE;
}
- ss-stack = g_list_prepend (ss-stack, mono_declsec_create_frame (domain, ji));
+ if (ss-count == ss-maximum)
+ grow_array (ss);
+
+ mono_array_set (ss-stack, gpointer, ss-count++, mono_declsec_create_frame (domain, ji));
/* continue down the stack */
return FALSE;
@@ -510,7 +530,6 @@
MonoJitTlsData *jit_tls = TlsGetValue (mono_jit_tls_id);
MonoSecurityStack ss;
MonoContext ctx;
- MonoArray *stack;
#ifdef _MSC_VER
/* seems that MSC doesn't like having __asm in macros */
@@ -524,14 +543,12 @@
#endif
ss.skips = skip;
- ss.stack = NULL;
+ ss.count = 0;
+ ss.maximum = MONO_CAS_INITIAL_STACK_SIZE;
+ ss.stack = mono_array_new (domain, mono_defaults.runtimesecurityframe_class, ss.maximum);
mono_walk_stack (domain, jit_tls, ctx, callback_get_stack_frames_security_info, (gpointer)ss);
-
- stack = glist_to_array (ss.stack, mono_defaults.runtimesecurityframe_class);
- if (ss.stack)
- g_list_free (ss.stack);
-
- return stack;
+ /* g_warning (STACK RESULT: %d out of %d, ss.count, ss.maximum); */
+ return ss.stack;
}
#ifndef CUSTOM_EXCEPTION_HANDLING
Index: declsec.c
===
--- declsec.c (revision 43886)
+++ declsec.c (working copy)
@@ -71,6 +71,7 @@
}
frame-method = mono_method_get_object (domain, jinfo-method, NULL);
+ frame-domain = domain-domain;
/* stack modifiers on methods have priority on (i.e. replaces) modifiers on class */
Index: declsec.h
===
--- declsec.h (revision 43886)
+++ declsec.h (working copy)
@@ -27,10 +27,13 @@
#define MONO_SECMAN_FLAG_GET_VALUE(x) (x 0x1)
#define MONO_SECMAN_FLAG_SET_VALUE(x,y) do { x = ((y) ? 0x3 : 0x2); } while (0)
+#define MONO_CAS_INITIAL_STACK_SIZE 6
+
/* keep in synch with RuntimeSecurityFrame in /mcs/class/corlib/System.Security/SecurityFrame.cs */
typedef struct {
MonoObject obj;
+ MonoAppDomain *domain;
MonoReflectionMethod *method;
MonoDeclSecurityEntry assert;
MonoDeclSecurityEntry deny;
[Mono-devel-list] contribute to VM Runtime project
Hi All,I would like to contribute to the Mono project, and have had a look at theMono Taskson the web-site.I would like to work on the "Implement support for a generational GC" in the Runtime and JIT area or "Add support for COM and/or XPCOM and/or ORBit" or "System.Data updates" in the Class Libraries area.. Would someone be able to provide some guidance on the current state of the project and where to begin?Thank you,SorinRojea
[Mono-devel-list] The XML serializer apparently is buggy
Hi all, I have discovered a strange bug in Mono. I have a number of webservices written in PHP and clients written in .NET and Mono. All clients in .NET works but none of the clients in Mono does - the result is always null. The strange thing happens if I run the mono compiled code under .NET - then all the clients work! Because including the code in this feed would generate an enormous amount of text I have not done so but would happily provide all code for clients and server if so requested. Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xD3C9A00E mir datanom net http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE501F51C mir miras org http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- I souport publik edukashun. signature.asc Description: This is a digitally signed message part
Re: [Mono-devel-list] The XML serializer apparently is buggy
Hi, On dt, 2005-05-03 at 01:11 +0200, Michael Rasmussen wrote: Hi all, I have discovered a strange bug in Mono. I have a number of webservices written in PHP and clients written in .NET and Mono. All clients in .NET works but none of the clients in Mono does - the result is always null. Which mono version are you using? A bug about web services returning null was fixed some time ago. If you are using the latest 1.1.x mono release, please file a bug report in bugzilla.ximian.com, and attach the wsdl document of one of the services that fails. The strange thing happens if I run the mono compiled code under .NET - then all the clients work! This is not strange. It means that there is a bug in the mono libraries. Because including the code in this feed would generate an enormous amount of text I have not done so but would happily provide all code for clients and server if so requested. The wsdl document should be enough for now. Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xD3C9A00E mir datanom net http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE501F51C mir miras org http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- I souport publik edukashun. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] The XML serializer apparently is buggy
tir, 03 05 2005 kl. 01:45 +0200, skrev Lluis Sanchez: Which mono version are you using? A bug about web services returning null was fixed some time ago. If you are using the latest 1.1.x mono release, please file a bug report in bugzilla.ximian.com, and attach the wsdl document of one of the services that fails. It is version 1.1.4 The wsdl document should be enough for now. It has been filed. Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xD3C9A00E mir datanom net http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE501F51C mir miras org http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- Han Solo: Watch your mouth, kid, or you're gonna find yourself floating home. signature.asc Description: This is a digitally signed message part
Re: [Mono-devel-list] Contribution to MSBuild
I have looked at that documentation. That documentation appears to be automatically generated by reflection on the MSBuild assemblies. There is no human-written documentation that elaborates on how things work and fit together. On Tuesday 03 May 2005 12:10 am, Anirudh Chandrakant wrote: Hi marcus, i am not very familiar with MSBuild as yet... but have decided to look into it asap. Regarding documentation of microsoft.build.* namespaces... you might want to have a look at the vs2005 documentation at http://msdn2.microsoft.com/library/ms123457(en-us,vs.80).aspx hope that helps... let me know if you are interested in pursuing this further, we can work out something... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Fwd: Re: [Mono-list] Problem with System.Web.UI/TemplateControl method]
Hello,
I see that ParseControl method from
mcs/class/System.Web/System.Web.UI/TemplateControl.cs
is not yet implemented,
( Control ctrl = Page.ParseControl(asp:button ...); )
anybody can say me what is the state of this method or when will be
implemented ??
Is there any alternative for create Controls from a string ??
Thanks , and sorry for my bad english !!
i think this may be work fine
please, post any suggestion
public class Form : System.Web.UI.UserControl {
protected Panel pnlContainer;
private string xmlFile=;
private string xslFile=/Common/Xslt/Forms/Default.xsl;
static Logger logger =
LogManager.GetLogger(FormControl.Form);
public string XmlFileName {
set {
this.xmlFile=value;
}
get {
return this.xmlFile;
}
}
public string XslFileName {
set {
this.xslFile=value;
}
get {
return this.xslFile;
}
}
public void Page_Load(object sender, System.EventArgs e)
{
string XmlSystemFileName = Server.MapPath(xmlFile);
string XslSystemFileName =
Server.MapPath(xslFile);
XPathDocument XmlDoc = new
XPathDocument(XmlSystemFileName);
XslTransform XslProc = new XslTransform();
XsltArgumentList XsltArgs = new
XsltArgumentList();
XsltArgs.AddParam(pageid, , pag1);
StringBuilder sb = new StringBuilder();
StringWriter sw = new StringWriter(sb);
XslProc.Load(XslSystemFileName);
XslProc.Transform(XmlDoc, XsltArgs, sw,null);
String result=
sb.ToString().Replace(lt;,).Replace(gt;,);
sw.Close();
byte [] bytesbuffer =
Encoding.ASCII.GetBytes(result);
MemoryStream memStream = new MemoryStream(bytesbuffer);
this.ParseControl(memStream);
}
private void ParseControl(Stream doc) {
XmlDocument myXmlDocument = new XmlDocument();
try {
myXmlDocument.Load(doc);
ParseTree(myXmlDocument.DocumentElement);
}
catch (Exception e) {
logger.Debug(# FormControl.Form.ParseControl ERROR :
{0},e.Message);
Console.WriteLine(# ERROR : + e.Message);
}
}
private void ParseTree(XmlNode node) {
Control ctrl;
if (node != null) {
if (node.HasChildNodes == true) {
if(node.Name.StartsWith(asp:)) {
ctrl=this.BuildControl(node);
}
else {
ctrl = new Literal();
String strCtrl = +node.Name;
if (XmlNodeType.Element == node.NodeType){
XmlNamedNodeMap map =
node.Attributes;
foreach (XmlNode attrNode in map){
strCtrl+= +attrNode.Name+=
\+attrNode.Value+\;
}
}
strCtrl+= +node.Value;
((Literal)ctrl).Text=strCtrl;
pnlContainer.Controls.Add(ctrl);
XmlNode nodeChild =
node.FirstChild;
while (nodeChild != null){
ParseTree(nodeChild);
nodeChild = nodeChild.NextSibling;
}
ctrl = new Literal();
((Literal)ctrl).Text=/+node.Name + ;
}
pnlContainer.Controls.Add(ctrl);
}
[Mono-list] errors running monodoc browser via xsp
I've managed to compile and install libgdiplus, mono, gtk-sharp, monodoc, and xsp from the source tarballs (on Ubuntu 5.04). Hey, perhaps I can get away from Windows some day soon! I can run monodoc (gtk# version) just fine, also can run the xsp test pages ok. However, when I try to run the xsp version of monodoc I get a compilation error can not find assembly 'monodoc' I have run ldconfig as su after installing monodoc. Is there something else I'm supposed to do to tell xsp where to find the Monodoc.dll (which does exist in the gac folder that now exists in /usr/local/lib/mono/gac/monodoc/1.0.0__blahblahblah) a little later... I tried adding a link to Monodoc.dll in the bin folder of the xsp text application and a link to the /usr/local/lib/monodoc folder in the root folder of the xsp test application. That got rid of the can not find assembly message but then I got an Object reference not set to an instance of an object error. I have a feeling adding the links isn't the way I'm supposed to solve this problem. I'd appreciate any suggestions. Michael Bradley This message was sent using IMP, the Internet Messaging Program. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problems with updater.exe
Just the latest 3 questions... monodocer.exe replicates more or less what monodoc.exe does (except assembling and browsing), so which one should I use? Can I generate XML skeletons with monodoc.exe and then process them with monodocs2html.exe? Why doesn't monodocer.exe generate the summary node for classes? Thanks, j3d. On Thu, 2005-04-28 at 10:54 -0400, Joshua Tauberer wrote: Giuseppe Greco wrote: I'm trying to build some documentation with updater.exe (shipped with monodoc)... but no way: Hi, Giuseppe. See: http://lists.ximian.com/archives/public/mono-list/2005-April/026691.html -- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)79 602 99 27 email: [EMAIL PROTECTED] web:www.agamura.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problems with updater.exe
Giuseppe Greco wrote: monodocer.exe replicates more or less what monodoc.exe does (except assembling and browsing), so which one should I use? Monodocer synchronizes XML files with an assembly, adding and removing XML files and nodes as needed so that there is a place to document everything in the assembly. (That's what updater.exe did, but monodoc.exe doesn't do that.) Can I generate XML skeletons with monodoc.exe and then process them with monodocs2html.exe? You can generate XML skeletons with monodocer. Just point the -path argument to an empty directory. Why doesn't monodocer.exe generate the summary node for classes? It should be -- - Joshua Tauberer http://taubz.for.net ** Nothing Unreal Exists ** ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Nemerle 0.3.1 released
The 0.3.1 version of Nemerle has hit our server. This is a bugfix release
to the 0.3.0 released 3 days ago.
The usual blurb about what is Nemerle can be found at:
http://nemerle.org/
The changelog is in the blog:
http://nemerle.org/blog/archive/2005/May-02.html
as well as at the end of this email.
Have fun!
0.3.1, May 2 2005
This version is a quick fix for issues reported with the 0.3.0 release.
Bugfixes:
* The MSI package now have the proper version of cs2n.
* The issues with loading external enums based on the long type
are be fixed now.
* Emacs mode should no longer hang on comment edition (#434).
* There are quite a few language fixes in the documentation, thanks to
Andy Burns and other nameless documentation updaters.
There is a single nice feature that sneaked into this release, it is
now possible to match inside the foreach loop directly (#436), that is:
foreach (op in ops) { | Op.A = ... | Op.B = ... }
will now work as:
foreach (op in ops) { match (op) { | Op.A = ... | Op.B = ... } }
--
Michal Moskal,
http://nemerle.org/~malekith/
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problems with updater.exe
On Mon, 2005-05-02 at 16:03 -0400, Joshua Tauberer wrote: Giuseppe Greco wrote: monodocer.exe replicates more or less what monodoc.exe does (except assembling and browsing), so which one should I use? Monodocer synchronizes XML files with an assembly, adding and removing XML files and nodes as needed so that there is a place to document everything in the assembly. (That's what updater.exe did, but monodoc.exe doesn't do that.) Yes, I know, but the following command should do what updater.exe did... isn't it? monodoc --update myapp.exe -o doc/sdk Can I generate XML skeletons with monodoc.exe and then process them with monodocs2html.exe? You can generate XML skeletons with monodocer. Just point the -path argument to an empty directory. Why doesn't monodocer.exe generate the summary node for classes? It should be I'm sorry... it does! I haven't seen that the summary node for the class is placed at the end of the file. Thanks a lot, j3d. -- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)79 602 99 27 email: [EMAIL PROTECTED] web:www.agamura.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mac OS X 10.4 and Mono
Hi, Just like to share that Mono 1.1.6 build successfully on Mac OS X 10.4 (Tiger) regards, - Jonel Rienton http://homepage.mac.com/jrienton Software Developer, *nix Advocate ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] MCS build problem
I am getting a problem building with MCS (from SVN) this same build used to work just fine. Does anyone have any ideas? mcs -g --unsafe -L bin/Debug -out:Nii.JSON.dll -t:library -d:LINUX;DEBUG;TRACE; -r:System,System.Data,System.Xml ../../AssemblyIn fo.cs ../../JSONArray.cs ../../JSONFacade.cs ../../JSONObject.cs ../../JSONTokener.cs ../../JSONUtils.cs ../../Types.cs ** (/usr/lib/mono/1.0/mcs.exe:5306): CRITICAL **: _wapi_shm_file_open: shared file [bin/Debug/.wapi/shared_data-gateway-5-0] open erro r: No such file or directory ** (/usr/lib/mono/1.0/mcs.exe:5306): CRITICAL **: _wapi_shm_attach: shared file [bin/Debug/.wapi/shared_data-gateway-5-0] open error ** ERROR **: file handles.c: line 123 (shared_init): assertion failed: (_wapi_shared_layout != NULL) aborting... Thanks Ralph ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MCS build problem
A recent 1.1.7 patch required that the wapi file be upgraded to version 5, but it looks like the shared directory has no permissions for the mono process to open a new wapi file. Set write perms on the wapi dir (bin/Debug/.wapi) for long enough to allow mono to open it's new shmfile. BillOn 5/3/05, Ralph Mason [EMAIL PROTECTED] wrote: I am getting a problem building with MCS (from SVN) this same build usedto work just fine.Does anyone have any ideas?mcs-g --unsafe -L bin/Debug -out:Nii.JSON.dll -t:library-d:LINUX;DEBUG;TRACE; -r:System, System.Data,System.Xml ../../AssemblyInfo.cs ../../JSONArray.cs ../../JSONFacade.cs ../../JSONObject.cs../../JSONTokener.cs ../../JSONUtils.cs ../../Types.cs** (/usr/lib/mono/1.0/mcs.exe:5306): CRITICAL **: _wapi_shm_file_open: shared file [bin/Debug/.wapi/shared_data-gateway-5-0] open error: No such file or directory** (/usr/lib/mono/1.0/mcs.exe:5306): CRITICAL **: _wapi_shm_attach:shared file [bin/Debug/.wapi/shared_data-gateway-5-0] open error ** ERROR **: file handles.c: line 123 (shared_init): assertion failed:(_wapi_shared_layout != NULL)aborting...ThanksRalph___Mono-list maillist- Mono-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MCS build problem
Thanks Bill, Problem is : There is no .wapi dir, I already tried creating one, but still no good gave it 777 and still no good. Tried touching to create that file it's looking for. Still nothing. Any other suggestions are very welcome :-) Ralph A recent 1.1.7 patch required that the wapi file be upgraded to version 5, but it looks like the shared directory has no permissions for the mono process to open a new wapi file. Set write perms on the wapi dir (bin/Debug/.wapi) for long enough to allow mono to open it's new shmfile. Bill On 5/3/05, *Ralph Mason* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I am getting a problem building with MCS (from SVN) this same build used to work just fine. Does anyone have any ideas? mcs -g --unsafe -L bin/Debug -out:Nii.JSON.dll -t:library -d:LINUX;DEBUG;TRACE; -r:System, System.Data,System.Xml ../../AssemblyIn fo.cs ../../JSONArray.cs ../../JSONFacade.cs ../../JSONObject.cs ../../JSONTokener.cs ../../JSONUtils.cs ../../Types.cs ** (/usr/lib/mono/1.0/mcs.exe:5306): CRITICAL **: _wapi_shm_file_open: shared file [bin/Debug/.wapi/shared_data-gateway-5-0] open erro r: No such file or directory ** (/usr/lib/mono/1.0/mcs.exe:5306): CRITICAL **: _wapi_shm_attach: shared file [bin/Debug/.wapi/shared_data-gateway-5-0] open error ** ERROR **: file handles.c: line 123 (shared_init): assertion failed: (_wapi_shared_layout != NULL) aborting... Thanks Ralph ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
