Re: [Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Hello, As an example, the generics compiler has been developed on a separate directory for almost a year, and we have to integrate patches every day. The anonymous method code lived only on my hard drive as a copy of the repository for six months, and I had to go through the same problems. Ok. But integrating that is a pain (I assume that's manual). Well, if it's the same case at many places, I would also live with it... :-( Actually, it is rather simple if you happen to keep your code under revision control instead of making a full fork. By keeping it under revision control, you can `svn update' and you will get a couple of conflicts every once in a while. It is not like the parser changes a lot, so most of the time it will be easy. If you are having problems merging the code I can assure you that it is because you are not using cvs/svn to assist you. I do not like the idea of checking work-in-progress code to the compiler, because that code tends to be bit rot if the work is not completed. Ok. Agree... Hooh! Going by the examples of generics and anonymous methods, I'd let mcsdoc evolve separately and once done report back with final code. Excellent. Miguel. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
On Thu, 2004-11-04 at 12:17 -0600, William E. Kempf wrote: I've installed mod_mono and required packages on Gentoo, using the Gentoo ebuilds. I've got everything configured correctly, AFAIK. Here's my 70_mod_mono.conf file. IfDefine MONO IfModule !mod_mono.c LoadModule mono_module extramodules/mod_mono.so /IfModule IfModule mod_mime.c AddHandler mono .aspx .ashx .asmx .ascx .asax .config .ascx /IfModule MonoUnixSocket /tmp/mod_mono_server MonoRunXSP True # Uncomment this block to enable the xsp samples IfModule mod_alias.c Alias /mono /usr/share/doc/xsp/test /IfModule MonoApplications /mono:/usr/share/doc/xsp/test Directory /usr/share/doc/xsp/test SetHandler mono IfModule mod_access.c Order allow,deny Allow from all /IfModule IfModule mod_dir.c DirectoryIndex index.aspx /IfModule /Directory /IfDefine Attempts to connect to /mono returns Service Temporarily Unavailable. The apache error_log only contains a line [error] Failed connecting. No such file or directory. Checking ps gives: $ ps aux | grep mod-mono-server.exe apache 14969 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14970 0.0 1.3 17080 3080 ?Ss 16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14971 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14972 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14973 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop wekempf 15193 0.0 0.2 1432 524 pts/3R+ 16:11 0:00 grep mod-mono-server.exe I tried to run mod-mono-server.exe manually, and received an error indicating it couldn't create /home/httpd/.wapi. Not surprising, since /home/httpd doesn't exist. To further test, I created this directory, and I was then able to start mod-mono-server.exe manually, and pages then display. Stopping this process, killing all other mod-mono-server.exe processes and restarting apache results in my still not being able to access any ASPX pages. No /tmp/mod_mono_server file is created. I'm at the end of my diagnosing capabilities. Why does mod_mono_server.exe appear to start 5 times, but no /tmp/mod_mono_server file is created and ASPX pages can't display? Is that a MPM worker apache? -Gonzalo ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Hi, Ok. Agree to it. But can I assume that you'd be doing this in cs-tokenizer.cs? If so, don't worry... I'll take care of it for my needs. :-) Yes. Am not sure how you can take care of those C# specific doc comments though (unless you rule all kind of the documentation way). Please clarify; do you actually have working functionality? If not, why do you need to commit your changes to CVS before you finish the actual document generation functionality? Ok... the status right now is that my tool cannot generate comments as of now. It can read comments (by patching cs-parser.jay, cs-tokenizer.cs, decl.cs etc), understand some of them but cannot generate HTML files right now. Two parts to it: One the changes needed in mcs to expose raw-comments. Second, generating documentation (HTML, chm or blah). The changes that I made to mcs belonged to mcs-1.1 (.Net 1.1) and now C# language itself has changed a lot with partial classes etc. It gave me a tough time patching new mcs-2.0 for my mcsdoc. Tomorrow, I may have another mcs-3.0 and all that pain. So, I just needed raw doc/comments. Ok, thanks I understood the development situation. I still cannot understand why your patch must be checked in right now. Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
I've installed mod_mono and required packages on Gentoo, using the Gentoo ebuilds. I've got everything configured correctly, AFAIK. Here's my 70_mod_mono.conf file. IfDefine MONO IfModule !mod_mono.c LoadModule mono_module extramodules/mod_mono.so /IfModule IfModule mod_mime.c AddHandler mono .aspx .ashx .asmx .ascx .asax .config .ascx /IfModule MonoUnixSocket /tmp/mod_mono_server MonoRunXSP True # Uncomment this block to enable the xsp samples IfModule mod_alias.c Alias /mono /usr/share/doc/xsp/test /IfModule MonoApplications /mono:/usr/share/doc/xsp/test Directory /usr/share/doc/xsp/test SetHandler mono IfModule mod_access.c Order allow,deny Allow from all /IfModule IfModule mod_dir.c DirectoryIndex index.aspx /IfModule /Directory /IfDefine Attempts to connect to /mono returns Service Temporarily Unavailable. The apache error_log only contains a line [error] Failed connecting. No such file or directory. Checking ps gives: $ ps aux | grep mod-mono-server.exe apache 14969 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14970 0.0 1.3 17080 3080 ?Ss 16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14971 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14972 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop apache 14973 0.0 3.5 37748 7844 ?S16:04 0:00 /usr/bin/mono /usr/bin/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop wekempf 15193 0.0 0.2 1432 524 pts/3R+ 16:11 0:00 grep mod-mono-server.exe I tried to run mod-mono-server.exe manually, and received an error indicating it couldn't create /home/httpd/.wapi. Not surprising, since /home/httpd doesn't exist. To further test, I created this directory, and I was then able to start mod-mono-server.exe manually, and pages then display. Stopping this process, killing all other mod-mono-server.exe processes and restarting apache results in my still not being able to access any ASPX pages. No /tmp/mod_mono_server file is created. I'm at the end of my diagnosing capabilities. Why does mod_mono_server.exe appear to start 5 times, but no /tmp/mod_mono_server file is created and ASPX pages can't display? -- William E. Kempf ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Mhm, then I misunderstood. You just missed your whole patch for what you really need (in fact that is what I was afraid of). Please provide all what you should put to require mcs hackers to review the patches. It is not a good idea to put patches step by step, without obvious purpose. If it is being reverted later when the purpose turned out that we should not have in mcs codebase, it will be just waste of time. If you are going to create another tool, then you should keep your changes on those mcs sources in your local mcs copy, so that other mcs hackers don't have to be bothered about whatever they never use. Atsushi Eno Gaurav Vaish wrote: Ok, I think I understood what you are going to do. Ahh! Finally, I make a breakthrough. ;-) So what you need is, to have public members that are accessible from your own tool 'mcsdoc', which 1)references to mcs.exe as an assembly and 2)runs its Main() entrypoint and 3)get results that Hmm.. I never thought of accessing it as an assembly. But yeah.. now I think that may be a good idea. Thanks buddy! Otherwise, you must need more patches to get it working (to get documentation output). At least there should be patch for driver.cs that handles your documentation support. Yes. I have code change for driver.cs also. Only that I never wanted to push it to driver.cs in mcs as it would use MCSDoc. If you look at driver.cs in the cvs, it has some changes. -- Cheers, Gaurav http://csdoc.sf.net -- ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Just a cralification; I don't mean that your project is waste of time. I was just worried that mcs hackers might have to spend their time unnecessarrily. Sorry if it sounds like nasty intemptation. Atsushi Eno Please provide all what you should put to require mcs hackers to review the patches. It is not a good idea to put patches step by step, without obvious purpose. If it is being reverted later when the purpose turned out that we should not have in mcs codebase, it will be just waste of time. If you are going to create another tool, then you should keep your changes on those mcs sources in your local mcs copy, so that other mcs hackers don't have to be bothered about whatever they never use. Atsushi Eno Gaurav Vaish wrote: Ok, I think I understood what you are going to do. Ahh! Finally, I make a breakthrough. ;-) So what you need is, to have public members that are accessible from your own tool 'mcsdoc', which 1)references to mcs.exe as an assembly and 2)runs its Main() entrypoint and 3)get results that Hmm.. I never thought of accessing it as an assembly. But yeah.. now I think that may be a good idea. Thanks buddy! Otherwise, you must need more patches to get it working (to get documentation output). At least there should be patch for driver.cs that handles your documentation support. Yes. I have code change for driver.cs also. Only that I never wanted to push it to driver.cs in mcs as it would use MCSDoc. If you look at driver.cs in the cvs, it has some changes. -- Cheers, Gaurav http://csdoc.sf.net -- ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-hackers-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-hackers-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Hi, I decided to delay /doc patch for a while (it will be likely two weeks or so in my current estimate) - To wait possible/actual problems raised by recent changes (anonymous methods, System.dll breakage, build changes) - To *complete* the patch to avoid another large /doc patch - To clarify what Gaurav want and need to incorporate to mcs and what is the same, differences, and conflicts in our patches (yes, it conflicts; at least there is MemberCore.Documentation in different types.) Actually I've finished /** ... */ handling (heading '*') and most of CS1587 warning (incorrect doc comment detection). The large remaining task is 'cref' verification (and code simplification). I've put the patch here: http://primates.ximian.com/~atsushi/mcs-doc-patches/mcs-doc-20041102.diff and will post to the list when I finished cref handling. Gaurav Vaish wrote: Mhm, I cannot understand what you meant. What is (and should not be?) discarded? My patch handles usual /** ... */ comments as well as those comments. Well, you can only understand /** * summaryThis is ok/summary */ but not this. It will complain... /** * Raw text is not ok. */ No, it understands such markup (maybe you mean, comments without tags?). Having XmlElement does not matter here. It is just a cosmetic matter that we could just hold string and a few fields instead of XmlElement. When it comes to that you're just using the common markup to csc /doc, why just not pipeline to ndoc(-console) or whatever? Because they will not understand extended tags. My idea is to the built the infrastructure like that of Doclet and Taglet, hence I cannot simply pipeline. Do you intend to create another tool like javadoc? Well, such extensions should not be done with /doc switch. It should be available in different switch name, for example /docx. That's what mcsdoc is. But for that to happen, I should be able to get the raw comment, not XMLElement. Am not sure /mcsdoc is good name which sounds like it is the MCS documentation format without common understanding. So what is the documentation format? (javadoc?) How does your patch fill your need? Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
- To clarify what Gaurav want and need to incorporate to mcs
and what is the same, differences, and conflicts in our
patches (yes, it conflicts; at least there is
MemberCore.Documentation in different types.)
cs-parser.jay
c.Documentation = CreateMemberComment (F: + MakeName (c.MemberName));
and
XmlElement CreateMemberComment (string fullyQualifiedName) { ... }
The difference is here. I don't want XMLElement at all. I want:
c.Documentation = xml_comment_buffer; // or xml_comment_buffer.ToString()
Why do I need raw-string? Probably, I can't explain this right
now, but it will be more clear if you directly look at the javadoc
tool / implementation of xdoclet.
I've put the patch here:
http://primates.ximian.com/~atsushi/mcs-doc-patches/mcs-doc-20041102.diff
and will post to the list when I finished cref handling.
decl.cs
public XmlElement Documentation;
My patches had:
public string Documentation;
No, it understands such markup (maybe you mean, comments without
tags?). Having XmlElement does not matter here. It is just a
cosmetic matter that we could just hold string and a few fields
instead of XmlElement.
Oh ok then. I didn't go much deep into the code that means. ;-)
Do you intend to create another tool like javadoc?
Precisely. No /doc or /mcsdoc switch. But like you have
javac, java and javadoc, I intend to have mcs, mono and
mcsdoc.
Am not sure /mcsdoc is good name which sounds like it is the MCS
documentation format without common understanding. So what is
the documentation format? (javadoc?) How does your patch fill
your need?
The patch feeds my NDoclet-Engine (ah, that's not a formal name).
Basic infra (in very infancy) is at:
http://cvs.sourceforge.net/viewcvs.py/csdoc/csdoc/src/mcsdoc/MCSDoc/
Most of the code is what I moved from
csdoc/src/csdoc/MCSDoc to csdoc/src/mcsdoc/MCSDoc and former
code is around a year old.
The idea, as I said, is not just a documentation tool but a
documentation engine. And as such, I need the raw-comment.
Still not clear? Hooh! I'll have to improve my English it seems :((
:-)
Atsushi Eno
Happy Hacking,
Gaurav Vaish
http://csdoc.sf.net
-
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Hello, Do you intend to create another tool like javadoc? Precisely. No /doc or /mcsdoc switch. But like you have javac, java and javadoc, I intend to have mcs, mono and mcsdoc. Ok, I think I understood what you are going to do. So what you need is, to have public members that are accessible from your own tool 'mcsdoc', which 1)references to mcs.exe as an assembly and 2)runs its Main() entrypoint and 3)get results that contains Documentation, right? The code in your patch looks actually not necessary for mcs itself. Otherwise, you must need more patches to get it working (to get documentation output). At least there should be patch for driver.cs that handles your documentation support. Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Hello, The patch feeds my NDoclet-Engine (ah, that's not a formal name). Basic infra (in very infancy) is at: http://cvs.sourceforge.net/viewcvs.py/csdoc/csdoc/src/mcsdoc/MCSDoc/ Most of the code is what I moved from csdoc/src/csdoc/MCSDoc to csdoc/src/mcsdoc/MCSDoc and former code is around a year old. The idea, as I said, is not just a documentation tool but a documentation engine. And as such, I need the raw-comment. Still not clear? Hooh! I'll have to improve my English it seems :(( So is this a different file format? In general, I do not think that having documentation inlined in the source code is a good idea, I have outlined that in the past, and that is why we are using a separate set of documents in Monodoc. But in this world of imperfections we need to support all of that source code that has been produced with inline documentation with the Microsoft format. I would love if we could transform those C# docs into ECMA XML docs for one. Are you planning a new format? My bat sense is that this might not be a great idea. miguel. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Ok, I think I understood what you are going to do. Ahh! Finally, I make a breakthrough. ;-) So what you need is, to have public members that are accessible from your own tool 'mcsdoc', which 1)references to mcs.exe as an assembly and 2)runs its Main() entrypoint and 3)get results that Hmm.. I never thought of accessing it as an assembly. But yeah.. now I think that may be a good idea. Thanks buddy! Otherwise, you must need more patches to get it working (to get documentation output). At least there should be patch for driver.cs that handles your documentation support. Yes. I have code change for driver.cs also. Only that I never wanted to push it to driver.cs in mcs as it would use MCSDoc. If you look at driver.cs in the cvs, it has some changes. -- Cheers, Gaurav http://csdoc.sf.net -- ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Hi Gaurav, Hmm, I thought you're trying to create totally different documentation feature ;-) I've been posting my patch to mono-devel-list: http://archive.neotonic.com/archive/mono-devel-list/messages/8531?noheader=1 Actually my patch does handle /** ... */ style documentation. I mean, it still does not handle some special formatting such as /** * * Those asterisk characters are handled as nothing. * */ /doc patch TODO items are: - handle those special tokenization described above - need to warn documentation on incorrect locations - having raw strings rather than XmlElement (learned from your patch ;-) It would also improve the code tip that Marek suggested But currently I think those improvements might not be so trivial, so I was stopping this feature right now as it is. Thanks, Atsushi Eno Gaurav Vaish wrote: Oh! I haven't seen Atsushi's patches. Can I have a look at them? Atsushi, It will not make a difference at all provided I am able to get the following: 1. Raw Documentation: You wrote that you handle XmlElement and the stuff. It is somehow possible to get the raw comment? 2. All comments, be it /// or /** style. Ok.. it won't matter if you collect just /// comments. Adding support for /** will not be much task because I will need updation in only cs-tokenizer.cs Can you let me know where can I find your patch / diff's? If there's any help / support, that I need I'd let you know. :-) Happy Hacking, Gaurav http://csdoc.sf.net http://gallery.mastergaurav.org - On Sat, 30 Oct 2004 12:45:45 -0400, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello Gaurav, Here's the latest diff. Rest is same as in previous patch. However, in this I have a change in the definition of enum_declaration in cs-parser.jay: We are very close to integrate Atushi's patches, as we have been working to get his patches to a mature state for the past five months. What is different between your code and Atsushi's? Miguel ___ Mono-hackers-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-hackers-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Hi Atushi, http://archive.neotonic.com/archive/mono-devel-list/messages/8531?noheader=1 Thanks for the pointer. I see that you do handle /**/, setting docAppend = true and then probably that would invoke consuming. I am not sure, but probably, unless you have: /** * summaryThis would be handled/summary */ it would be discarded. Actually my patch does handle /** ... */ style documentation. I mean, it still does not handle some special formatting such as Check my comments above. - handle those special tokenization described above Ok. Let me know if I can be of any help. - having raw strings rather than XmlElement (learned from your patch ;-) It would also improve the code tip that Marek suggested Well, that's what I am exactly looking for. My way of handling the documentation would be to gather the comments as raw elements, and register any warnings only in the end. (I safely assume that it may suck! ;-) But the philosophy behind the whole is that mcsdoc does not compile. Nor does it give only xml but full html/chm etc. But yes.. that's in advanced times. It's still in infancy. But currently I think those improvements might not be so trivial, so I was stopping this feature right now as it is. Well, not exactly. Although it may not be trivial, but it's also not tough. The only issue is that you've already started with the XML-only stylo. :-D My aim with mcsdoc is not to just get xml-style docs but the javadoc-@ stylos also. :-) I remember, I wrote in one of my mails a year back, they are cheaper. Do we strike a deal somewhere? :-) Happy Hacking, Gaurav http://csdoc.sf.net http://gallery.mastergaurav.org - ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Gaurav Vaish wrote: Hi Atushi, http://archive.neotonic.com/archive/mono-devel-list/messages/8531?noheader=1 Thanks for the pointer. I see that you do handle /**/, setting docAppend = true and then probably that would invoke consuming. I am not sure, but probably, unless you have: /** * summaryThis would be handled/summary */ it would be discarded. Mhm, I cannot understand what you meant. What is (and should not be?) discarded? My patch handles usual /** ... */ comments as well as those comments. - having raw strings rather than XmlElement (learned from your patch ;-) It would also improve the code tip that Marek suggested Well, that's what I am exactly looking for. My way of handling the documentation would be to gather the comments as raw elements, and register any warnings only in the end. (I safely assume that it may suck! ;-) Actually why I prefered XmlElement instead of raw string was to handle warnings embedded into the XML documentation. Having just a raw string in MemberCore is not sufficient. But the philosophy behind the whole is that mcsdoc does not compile. Nor does it give only xml but full html/chm etc. But yes.. that's in advanced times. It's still in infancy. When it comes to that you're just using the common markup to csc /doc, why just not pipeline to ndoc(-console) or whatever? My aim with mcsdoc is not to just get xml-style docs but the javadoc-@ stylos also. :-) I remember, I wrote in one of my mails a year back, they are cheaper. Well, such extensions should not be done with /doc switch. It should be available in different switch name, for example /docx. Atsushi Eno ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Mono-hackers-list] Re: Patch for mcs
Mhm, I cannot understand what you meant. What is (and should not be?) discarded? My patch handles usual /** ... */ comments as well as those comments. Well, you can only understand /** * summaryThis is ok/summary */ but not this. It will complain... /** * Raw text is not ok. */ Actually why I prefered XmlElement instead of raw string was to handle warnings embedded into the XML documentation. Having just a raw string in MemberCore is not sufficient. Right. You point is well taken. Mine is just an extension. When it comes to that you're just using the common markup to csc /doc, why just not pipeline to ndoc(-console) or whatever? Because they will not understand extended tags. My idea is to the built the infrastructure like that of Doclet and Taglet, hence I cannot simply pipeline. Well, such extensions should not be done with /doc switch. It should be available in different switch name, for example /docx. That's what mcsdoc is. But for that to happen, I should be able to get the raw comment, not XMLElement. I hope that explains my bits. -- Happy Hacking, Gaurav http://csdoc.sf.net ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
