[Mono-list] HTML Mockup for Class Lib Todo's

[Richard Thombs]

Hey Nick,

Now I see what CorCompare is up to I'm beginning to see the tricky parts! I
agree we need a tool that will build a composite XML file from an enhanced
CorCompare that would determine what is missing (and what is extra?) in the
Mono Corlib and merge that with more detailed class status information from
the todo generator and with some supplemental data about the maintainer etc.

Thinking about the todo generator - it must be possible to organise the
directory structure and naming conventions of the tests so that we can
automagically determine whether or not there are at least _some_ tests for a
given class. Could we go (or have we already gone) further and arrange that
the tests deposit some kind of standardised pass/fail mark file so that we
can figure out whether the implementation has passed the tests? Is this
similar to what Duncan's up to?

Also, who or what is the definitive source of module maintainer information?
I've only been reading the Mono list for a few days, but it's clear that all
sorts of extra useful libraries are popping up. How will we avoid namespace
collisions? Do we need an ICANN for Mono? ;-)

Best wishes,

Stony.

----- Original Message -----
From: "Nick Drochak" <ndrochak@gol.com>
To: "'Richard Thombs'" <mono@stony.org>; <mono-list@ximian.com>
Sent: Sunday, February 10, 2002 4:07 PM
Subject: RE: [Mono-list] HTML Mockup for Class Lib Todo's


> > I'll gladly put some time into providing a few formats along
> > the lines of what Nick suggests, but after having looked into
> > the problem a bit unless there's some cunning XSLT features I
> > don't know about, I can't see how we could achieve the
> > overall 'System' is 75% complete summary without reorganizing
> > the XML file to provide a more hierarchical structure.
> > Being new, I don't know how class.xml is maintained or who
> > should I talk to about this.
>
> Richard,
>
> Thanks for the offer.  It would be a big help!
>
> Actually, I wasn't referring to the current class.xml on the download
> page.  There will be a new .XML file generated by a as-yet-to-be-written
> tool that Duncan is working on. Well, I think he's working on it :)
>
> The tool would be an extension of mcs/tools/CorCompare.  Currently
> CorCompare only outputs missing class names.  It should be extended to
> provide all the information that your XSLT would need, indeed including
> the "% complete" numbers.  I shudder every time I think I need to do
> some math in XSLT :)
>
> So, something like this (I'm just typing it, so it's probably not going
> to be well-formed :)
>
> <assemblies>
>   <assembly name="corlib" missing="1753" todo="2312" complete="8">
>     <namespaces>
>       <namespace name="System" missing="267" todo="453" complete="21">
>         <classes>
>           <class name="System.Byte" status="missing" />
>           <class name="System.Array" status="todo" missing="5" todo="6"
> complete="45">
>             <methods>
>               <method name="ToString" status="todo" note="this is the
> note from MonoTODO" />
>               <method name="Equals" status="missing" />
>             </methods>
>             <properties>
>               <property name="Count" status="todo" note="another note"
> />
>             </properties>
>           </class>
>         </classes>
>       </namespace>
>   </namespaces>
>   </assembly>
> </assemblies>
>
> In a class, "todo" and "missing" refer to the number of
> methods/properties with a [MonoTODO] attribute or totally
> un-implemented, respectively. For namespace and assembly, they refer to
> the number of classes that have todo or missing elements. That's
> probably enough information for now for the drill-down.
>
> Let me know what you think.  If we can settle on the structure of the
> XML, then development of the XSLT and the ToDoGenerator itself can
> proceed in parallel.
>
> Regards,
> Nick D.
>
>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>