Re: [Mono-list] detecting mono or microsoft compiler with preprocessor
On Fri, 2004-12-03 at 17:44 +0100, Fabien Meghazi wrote: > Hi all, > > Is there a #define preprocessor definition that would allow to use > "if" "else" preprocessor statements for conditionnal compiling for > mono and microsoft compiler ? As Peter Bartok said, there is, but you should probably try to avoid using that fact. You can compile an assembly with MCS and run it on the Microsoft runtime, or vice versa, so which compiler is being used doesn't really tell you about the runtime. And even if it did, it's preferable to have your assembly be runtime-agnostic. (Although of course sometimes this isn't possible.) Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problem with make dist
Hi Neale, On Mon, 2004-09-13 at 12:20, [EMAIL PROTECTED] wrote: > make[2]: Entering directory `/home/usanefe/Mono/mono/runtime/net_1_1' > make[2]: *** No rule to make target `Accessibility.dll.mdb', needed by `distdir'. > Stop. > make[2]: Leaving directory `/home/usanefe/Mono/mono/runtime/net_1_1' > make[1]: *** [distdir] Error 1 > make[1]: Leaving directory `/home/usanefe/Mono/mono/runtime' > make: *** [distdir] Error 1 Make wants the file Accessibility.dll.mdb to exist, but it doesn't know how to generate it. It looks like you need to expand the rule on line 85 to apply to more targets. Try changing it to $(EXTRA_DIST): test -f $(top_srcdir)/../mcs/class/lib/default/$@ Then you'll get the .mdb files symlinked into the tree as well as the DLL's. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] runtime/Makefile.am
No big deal, but you have two entries for wsdl2.exe.mdb. Peter On Mon, 2004-09-13 at 11:06, [EMAIL PROTECTED] wrote: > Hi, > I had problems building mono cleanly owing to missing items in runtime/Makefile.am. > The following patch fixes things. Before I commit I wanted to run it by the group... > > --- Makefile.am 9 Sep 2004 20:29:55 - 1.83 > +++ Makefile.am 13 Sep 2004 13:53:23 - > @@ -97,10 +97,17 @@ > cilc.exe.mdb)d=tools/cilc ;; \ > xsd.exe) d=tools/mono-xsd ;; \ > xsd.exe.mdb) d=tools/mono-xsd ;; \ > wsdl.exe)d=tools/wsdl ;; \ > wsdl.exe.mdb)d=tools/wsdl ;; \ > + wsdl2.exe) d=tools/wsdl ;; \ > + wsdl2.exe.mdb) d=tools/wsdl ;; \ > + mono-find-provides.exe) d=tools/mono-rpm-helpers/mono-find-provides ;; \ > + mono-find-provides.exe.mdb) d=tools/mono-rpm-helpers/mono-find-provides ;; \ > + mono-find-requires.exe) d=tools/mono-rpm-helpers/mono-find-requires ;; \ > + mono-find-requires.exe.mdb) d=tools/mono-rpm-helpers/mono-find-requires ;; \ > + wsdl2.exe.mdb)d=tools/wsdl ;; \ > genxs.exe) d=tools/genxs ;; \ > genxs.exe.mdb) d=tools/genxs ;; \ > al.exe) d=tools/al ;; \ > al.exe.mdb) d=tools/al ;; \ > disco.exe) d=tools/disco ;; \ > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] glade signal connections
On Mon, 2004-08-30 at 23:23, Rob Brown-Bayliss wrote: > how would I do this in C#? eg, of a user clicks on a line in a list > view have a class that handles the list view events... Do you just mean that you want to manually connect to a signal? Gtk# wraps signals as events and you can treat them pretty much as you would any other event: Gtk.Window window = whatever (); window.DestroyEvent += new DestroyEventHandler (myfunction); Or am I not understanding your question? Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] monodoc bails, says can't find browser.exe
On Mon, 2004-08-30 at 16:41, billg wrote: > You're right. I added it with gacutil. Monodoc launches, but > immediately crashes with an unhandled exception error. Sigh... It seems > to be upset at gtkhtml. I'm using libgtkhtml-3.1 I built from source > at ftp.gnome.org. Is that the appropriate version? My gtkhtml-sharp.dll wants libgtkhtml-3.0 instead. (I found this out by looking at the entry in /usr/lib/mono/gac/gtkhtml-sharp/[mess]gtkhtml-sharp.dll.config). I don't know if 3.0 is binary-compatible with 3.1 -- I guess you can try editing the file and seeing if it breaks or not. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Detecting the calling assembly
On Mon, 2004-08-30 at 16:17, Matthew Metnetsky wrote: > Is there a way to find out what assembly is calling a type's method? System.Reflection.Assembly.GetCallingAssembly () :-) Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] popt
On Thu, 2004-08-26 at 23:36, Marcus wrote: > I'm not sure if Mono.GetOptions is compiled by default. If you're building > from source, you can do a "make" in Mono.GetOptions directory. The resulting > assembly to be installed is Mono.GetOptions.dll. Yes, it is, there's probably just a problem with a /r: flag or a using declaration or something. Look at /mcs/mbas/driver.cs for an example of how to use GetOptions, and make sure there's a /r:Mono.GetOptions.dll. Also see /mcs/mbas/AssemblyInfo.cs; there are assembly-level custom attributes that GetOptions uses to generate your help text. I find GetOptions to be very convenient, so I'd encourage using it. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Using qt#
Fooling with MONO_PATH is one way to get this to work, but I think the preferred solution is to give the /r: option a full path name. That is, mcs /r:/usr/local/lib/Qt.dll or whatever. This is, for example, what the gtk-sharp pkgconfig files do. This method means path problems don't come up and multiple versions of the same library are handled sanely. Peter On Wed, 2004-07-07 at 21:28, Marcus wrote: > By the way, you might get more help on the Qt# mailing list, although obvious > I read both. > > Does Qt.dll exist in /usr/local/lib? Is your version of Mono configured to > look in /usr/local/lib or just /usr/lib? If Mono is installed in the /usr > prefix, I'm not sure whether it will look in /usr/local/lib by default. You > can use the MONO_PATH to set where the runtime looks for libs. See the mono > manpage. > > Marcus > > > On Wednesday 07 July 2004 5:59 pm, Paul wrote: > > Hi, > > > > I've compiled qt# from sourceforge and installed it into /usr/local/lib. > > How do I link it to source code? > > > > mcs -r: Qt just gives that Qt can't be found. > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] dash in file name - won't compile
On Wed, 2004-05-19 at 22:20, Fred Blaise wrote:
> If I however rename the class and file to not have the '-', it works:
The class name is the issue. You'll note that the MCS error is pointing
you at line 6 of your file -- this is probably something like:
class gget-sharp {
Anyway, dashes are not legal in identifiers in C# (same rules as in C
apply, more or less.)
Peter
--
Peter Williams [EMAIL PROTECTED]
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] GNU Readline style input for mono
On Tue, 2004-05-18 at 21:24, David Mitchell wrote: > Is there currently any easy way to have readline style input in a .Net > console application under mono? So things like being able to press the > up key to recall history and inline editing. > > Thanks I believe the mono debugger (CVS module debugger) has a binding to readline. Note that the debugger itself is basically experimental, but the readline binding should be ok. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Re: [Mono-docs-list] Mono 1.0 quickly approaching.
On Tue, 2004-04-27 at 18:12, Dan wrote: > Miguel, > > My mistake, I saw this on the bottom of the > http://www.go-mono.com/classlib-doc.html page: The terminology is a little confusing: the documentation viewing program, monodoc, is called the "browser" for short. That's what the statement is referring to, not a web browser. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SIGILL in I18N on OSX
On Wed, 2004-03-24 at 14:57, Robert Shade wrote: > No > > rob Ok, have you tried changing the definition of RUNTIME in build/config-default.make? Strange that the config.make change doesn't cut it; maybe that needs RUNTIME := mint to get it to stick. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SIGILL in I18N on OSX
On Wed, 2004-03-24 at 11:29, Robert Shade wrote: > I have not been able to figure out how to change $(RUNTIME) to resolve > to mint, thus the change. Putting RUNTIME = mint in build/config.make doesn't work? Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
On Tue, 2004-03-02 at 16:58, Andy Satori wrote: > The problem with the second is that as far as I can tell, it would > require XCode projects to build the framework, and all the associated > dylibs. creating that project is going to be time consuming, and it > will require updating to be kept in sync with the ./configure & make > process. Can you explain why this is? I'm not at all familiar with OS X development, but you can accomplish a lot with makefile mojo ... Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Docs as plain HTML
On Thu, 2004-02-12 at 16:51, John Luke wrote: > Assuming you were asking this because you can't/don't want to use > monodoc. It would be insanely easy for someone to write a small SWF (or > any other toolkit) frontend for monodoc using monodoc.dll. Perhaps when > the mono SWF implementation begins working again someone could do that > as a test. Also, you could use the XSL files (ex. > monodoc/browser/mono-ecma.xsl) to transform all the XML files to HTML > with a script. Well, *if* monodoc.exe is an option, there's some way to get it to spit out HTML -- see the 'mod' shell script that it installs (which is sort of like 'man' for monodoc pages.) Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] A Build Profiles Issue
Hi Pablo, On Wed, 2004-01-07 at 00:44, Pablo Fischer wrote: > And then I build it with > > $ make PROFILE=debian > > And obvious, it stops, why? don't know.. but I found that if I export > every variable it start compiling some libs but then it stops again > giving me an error that It can not find corlib.dll (and corlib is in the > mono path!). > > Also, I was looking the other profiles and any of them export their > variables. Have you tried adding 'export' statements to your profile? export MONO_PATH export PATH export BOOTSTRAP_MCS That causes make to set the variable for sub-makes and set it in the environment, which is what you need for the PATH variables. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Enviroment Variables
Hi, On Mon, 2004-01-05 at 17:06, Pablo Fischer wrote: > Hi! > > A few days ago I asked how to compile mcs-0.28 with a different mcs.exe > version, and hopefully I got answers :). > > Now, I have another problem, one thing is to tell the mcs.exe and the > other is to tell where the libmono lib (version .28) is. > > So, somebody knows all the enviroment variables that use MCS?. (Sorry for not responding earlier, my email was down.) Maybe LD_LIBRARY_PATH is all you need? Or MONO_PATH ... I don't have a good sense of of what you're trying to achieve, but those are places to start. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Debugger Problem
On Sat, 2004-01-03 at 16:27, Nathanael Obermayer wrote: > Hello, > > i'm trying to install the mono-debugger. > Unfortunately the new version (0.5) doesn't include the gui-version (why?), > so i tried to install the 0.4 version. > > On "make" i get this error: I'm pretty sure that the gui version of the debugger was disabled because it is not up-to-date with the newest Gtk# releases. The debugger is very unstable and still not finished; I would not plan on being able to use the GUI any time soon. (Of course, the more help Martin gets, the faster it goes ... :-) Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Compiling mcs with other C# Compiler
On Sat, 2004-01-03 at 02:37, Pablo Fischer wrote: > Hi! > > I have a problem. I have officially mono and mcs compiled with the > lastest CVS version (Friday 2nd), however, I'd like to compile other mcs > and mono versions (.28), so, how can I compile mcs (.28) with another > mcs.exe?. The MCS build system uses two variables that will be of interest to you: BOOTSTRAP_MCS, which is used to compile the new mcs and corlib, and MCS, which is used to compile the rest of the libraries. MCS is in turn defined in terms of INTERNAL_MCS, which is the mcs.exe compiled while building the class libraries. Anyway, all you should need to do is set those variables and you should be good to go. You may also need to set the RUNTIME variable if you want to use a specific version of the mono runtime. $ make MCS=/path/to/my/mcs.exe BOOTSTRAP_MCS=/path/to/my/mcs.exe You might make a build profile out of that setup by creating a make fragment in mcs/build/profiles/myprofile.make that sets the variables that you need; then you can just do $ make PROFILE=myprofile Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] ModMono.dll error
Hi, On Thu, 2003-12-04 at 20:21, Augusto Silva wrote: > Unhandled Exception: System.NullReferenceException: A > null value was found where an object instance was > required > in (unmanaged) /usr/local/lib/libmono.so.0 > [0x40077e75] > in (unmanaged) /usr/local/lib/libmono.so.0 > [0x40077fe9] > in (unmanaged) /usr/local/lib/libmono.so.0 > [0x40078d03] > in (unmanaged) > /usr/local/lib/libmono.so.0(mono_reflection_create_runtime_class+0x165) > [0x4007949d] > in <0x003de> Your mono installation is messed up: your corlib.dll and runtime are out of sync. You make sure that you are using the latest runtime and then download and install a recent monolite or monocharge from www.go-mono.com/daily/ Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Delegate compilation error
On Tue, 2003-11-25 at 15:05, Alejandro Sánchez wrote: > With daily binary package mono-0.28.99.20031125.tar.gz ... > delegate void ButtonClickedEventHandler (object o, > ButtonClickedEventArgs); I think you need to give the parameter a name here. Eg delegate void ButtonClickedEventHandler (object o, ButtonClickedEventArgs args); Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Announce: mID3 0.7.1 (Goes to Eleven)
Hi everyone, I've written a little application based on Gtk# / Mono that edits ID3 tags in MP3 files [1]. The TODO list is quite long, but the basic functionality is there, and I find it quite useful (seeing as Rhythmbox doesn't yet support tag editing). You can download it from: http://www.newton.cx/~peter/software/mid3-0.7.1.tar.gz Note that by default, mID3 strips all kinds of tags except for ID3v2 tags. If for some reason you want to keep other kinds of tags (presumably ID3v1, but there are other formats), DO NOT USE mID3. mID3 requires version 3.8 of id3lib, an id3 editing library available at: http://id3lib.sourceforge.net I recommend getting as recent a version as possible, as I know at least some older versions have a bug that generates corrupt ID3v2 tags. You will also need to edit your Mono configuration file to get the runtime to find the id3lib library. See the file INSTALL in the tarball for instructions. Feel free to send me mail if you have any questions. Share and enjoy, Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Tools and Utilities
On Mon, 2003-10-13 at 13:39, A Rafael D Teixeira wrote:
> Just to be complete (I don't like it myself), there is the Microsoft way:
> build each target to different directories (the dreaded /bin/debug and
> /bin/release couple)
Well, this is similar to the automake idea of building with $(srcdir)
and $(builddir) ... I think it's a nice system, except it's such a
hassle to get working.
Anyway, the real problem is that program.exe depends on the
configuration variable ${debug} but NAnt doesn't have a convenient
mechanism for expressing that.
Peter
--
Peter Williams [EMAIL PROTECTED]
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Tools and Utilities
ou can > see at a glance what files you're getting and from where. Yeah, dist is always tricky, but if you have a program that uses source files a.cs and b.cs, you almost surely want to dist them, and you probably don't want to have to remember to modify your dist list every time you add a new file. Here Jaroslaw's named filesets might be pretty useful, but then if you have built source files you need to remember to exclude those files, and so on... I think the ideal system would be to automatically distribute all the leaf nodes on the dependency graph. > hmm - I've used other build tools - cons ( http://www.dsmit.com/cons/) > which do use MD5 sums. With large source trees there was a significant > time taken to calculate which files need re-building. This could just > have been a feature of cons and not of using MD5 sums - I'm not > necessarily defending NAnt on this point. I haven't really tried this myself but I could see MD5 sums being time-consuming. I guess what really makes this useful is that it opens up the possibility of having a target that isn't a file -- which then lets you solve the issue of "not rebuilding when you change the debug flag". The problem is that your program has a dependency on the debug flag, but since it's not a file you can't really express it. As Jaroslaw mentioned, you can make a stamp file and go from there, but if you had 25 boolean build options the amount of boilerplate code would get obnoxious. > as Jaraslaw metioned - config info is stored in a config file. However > elements of the configuration can be overridden on a per build file basis. What I was getting at was the above: the results of the build really do depend on the configuration variables, but they're not quite first-class , so you get something like the debug rebuild problem. > I'd like to hear more of your thoughts in this regard. Be sure to post > here when you get your project off the ground. I'll forward an email with a summary of what I've done. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Tools and Utilities
On Mon, 2003-10-13 at 00:54, Ian MacLean wrote: > I'd like to hear a more detailed breakdown of you're issues with NAnt. > We always trying to improve the codebase and doing that requires > listening to peoples issues. However > 'I don't like the xml syntax' and 'it doesn't seem to have been > *designed*' don't really give us too much to go on. There's two reasons for my vagueness: as I said, I have only briefly looked at some NAnt build files and the documentation on the website, so my practical understanding of nant is definitely poor. Second, I get the feeling that my objections to it are more philosophical than on specific choices. I've never heard that nant is buggy or anything, I just feel that it doesn't really go as far as it could. I'll try to explain what I mean: * Using XML to express the build rules is, IMO, too heavyweight. I can see how it's easy to parse and gives an easy mechanism for interfacing with tasks, but writing a build file is like programming in any other language; it's better to have the common bits easy and the rare bits hard than everything somewhere in an awkward medium. * The replacement of shell commands with tasks is important, of course, but the commands still seem on the low-level side of things: copy file, delete file, compile to this file; what happens if I'm compiling foo.so on Linux and foo.dll on Windows? * I haven't seen indications that it's particularly aware of recursion. * It looks like you can implement tasks in user assemblies but I don't see a framework for distributing them sanely (which I believe to be very important: aclocal, anyone?) * Similarly, it doesn't look like you can define tasks in the XML itself. * You still have to write your own clean rules and dist rules. Surely the tool, knowing the targets and all the rules used to build them, could figure this out by itself? * Still using file modtimes, not MD5 sums, as criteria for rebuilding. Not the end of the world, but if you change a comment in a C file and have to relink your executable as a result, it can be a drag. * Judging from idea of build properties, configuration state is still kept outside of the build tool. NAnt seems to improve on the implementation of make while still working within the same basic framework. My opinion is that there's a lot to be gained from really rethinking what it means to "build" something and structuring the process a lot more. To try to articulate that idea a bit more, here's a quote from the NAnt webpage that struck me: Important: Some tasks like the compiler tasks will only execute if the date stamp of the generated file is older than the source files. If you compile HelloWorld project in debug mode and then try to compile it again in non-debug mode without first cleaning nothing will happen because NAnt will think the project does not need rebuilding. Why isn't NAnt able to figure that out? It's a build tool, it should specialize in being smart in situations like this. Problems like this are why make sucks, but it doesn't seem that NAnt improves the situation. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono Tools and Utilities
On Sun, 2003-10-12 at 17:10, Todd Berman wrote: > For long term development use it seems like it would make sense to > attempt to move Peter's vision from his head, to our hard drives. That > or fix NAnt up for mono use. > > 1, 4 and 5 all are quick fixes, not long term solutions. Eh, I think I have a good idea and there's some code, but there's a lot of work to be done. I guess just using the same make magic would be the thing to do for the time being. If anyone gets to writing a really compelling build tool, switching to it should be easy. So if the current build system is ugly but works, there's not much reason to switch from it. I'd really discourage using NAnt though -- I'm not too familiar with it, but I find the XML syntax awful and, well, it doesn't seem to have been *designed*. I don't want to rag on nant too much because of my limited understanding of it, but I think if we're going to switch to a "next generation" build system we'd want to explore our options. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Tools and Utilities
Hi Jon, On Sun, 2003-10-12 at 10:59, Jonathan Pryor wrote: > So I would also propose the following: > > 1. Move mcs/build into a new CVS repository, "build" > 2. Use the CVS aliasing functionality [1] to insert the "build" > CVS repository into the "mcs" and "mono-tools" repositories. > This would allow the build system to be located in one > location, and all users would receive updates > simultaneously. As the guy who wrote most of the build system, I'm not sure if this is the best idea, although the build system is so low-maintenance that I don't think moving it would be a huge problem. My reasons are: * A lot of the build system is about supporting *complex* cross-platform compilations: of corlib, with large source trees, with interdependent libraries, etc. I suspect mono-tools' needs would be simpler, and could probably be met with a much smaller set of Makefile code * Trying to implement a nontrivial build with make is just so much more of a hassle than it should be. On the other hand, I think nant has many bad design decisions, and although I have an (IMHO) awesome idea and basic framework for a C# build tool, I (of course) have ~0 free time to work on it. * This is relatively minor, but if more projects start using the build/ files, then they *will* become high maintenance, and if people are going to spend time on a build system, I'd much rather it be on implementing a better one, rather than working within the confines of pure make. Anyway, if you want to alias the build/ stuff, I'm not against it, I'm just not totally encouraging it. My feeling is it might be easiest and sanest just to bolt into autoconf/automake as best you can. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono LDAP Status
Hi Ben, On Fri, 2003-09-19 at 00:12, Ben Maurer wrote: > We use CVS (Cuncurent Versioning System), a common Open Source > versioning program, to allow multiple people to work on something at the > same time. It is just like inside Novell, except your coworker might > live on the other side of the world ;-). Well, I think Brady's point is that if you're not coordinating very closely, it's hard for even two people to work on the same module of code at the same time. I think the usual open source approach could be described as "both people work on it and use whatever works first"... either that or be prepared to spend a lot of time on IRC. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] assemblies path
On Sat, 2003-09-13 at 07:23, Kris Luyten wrote: > Hi, > > how can I replace: > === > public const string GTK_ASSEMBLY= "/usr/local/lib/gtk-sharp.dll"; > public const string SYSTEM_ASSEMBLY = "/usr/local/lib/System.dll"; > ... > m_gtkAssembly = Assembly.LoadFrom(GTK_ASSEMBLY); > m_systemAssembly = Assembly.LoadFrom(SYSTEM_ASSEMBLY); > === I believe Assembly.LoadFrom always expects a filename, so gtk-sharp.dll is treated as ./gtk-sharp.dll and nothing else. Use Assembly.Load (). Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono 0.26 has been released
On Fri, 2003-08-15 at 04:33, Ole Hyldahl Hansen wrote: > cd mono-0.24 > ./configure --prefix=/usr/local/dikunix > make > make install prefix=/usr/local/dikunix/work/mono/linux This shouldn't have ever worked, but there is a way to do this. Use: make install DESTDIR=/usr/local/dikunix/work/mono/linux Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Newbie help?
On Sun, 2003-08-10 at 23:16, Thomas Leavitt wrote: > ... hey, if this isn't the appropriate place for an experienced sysadmin who > has RTFM to ask probably ignorant questions, where do I do that? Are you running Windows and Cygwin? If so, you need to set up your PATH environment so that csc.exe (the MS C# compiler) can be found... I think it's somewhere in C:\WINNT\Microsoft.NET. If you're on a unixy machine ... well, the build system thinks you're on Windows. It checks for the make variable $(OS) = Windows_NT so that should only happen for a really messed up configuration. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Daily Mono snapshots now available
On Sat, 2003-07-26 at 01:41, Jaroslaw Kowalski wrote: > As far as I remember, you also need: > > Mono.CSharp.Debugger.dll > > so that mcs can generate debug symbols. > > Jarek All of the above should be included, if Duncan is using the 'make monocharge-lite' target, at least. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Building mono/mcs
Hi John, On Mon, 2003-07-21 at 18:55, John BouAntoun wrote: > .. > a) Does the new build system make the old README files invalid now (or > at least change some of them)? We have been trying to keep them accurate. mcs/INSTALL.txt and mcs/build/README.* are good, I know; I think mcs/README.building needs updating. > > b) Would it be possible to make 1 penultimate building instructions > file that is constantly kept up to date. (I would be quite happy to > organise this into a fluently read English document if someone could > provide me with all the relevant instructions and caveats in the right > order). Yeah, things are pretty disorganized right now. My personal inclination would be to work with INSTALL.txt and just change README.building to be "See INSTALL.txt" The main problem is that the documentation addresses two different major problems: 1) How to build MCS -- this has now gotten fairly simple 2) How to keep the runtime and MCS in sync -- this is still hard. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Trouble building from CVS
On Thu, 2003-07-17 at 17:27, Krautbauer, Bruce wrote: > Sorry... somehow the message was truncated. The error I'm getting when > installing on the new 'clean' system is: > > make[2]: Entering directory `/root/mono/mcs/class/I18N' > make[3]: Entering directory `/root/mono/mcs/class/I18N/Common' > MONO_PATH="../../../class/lib:$MONO_PATH" mono ../../../mcs/mcs.exe > /r:corlib.dll -g /nowarn:1595 /nowarn:0169 /nowarn:0109 /nowarn:0067 > /nowarn:0649 /nowarn:0679 /noconfig /target:library > /out:../../../class/lib/I18N.dll @I18N.dll.sources > > ** (../../../mcs/mcs.exe:7725): WARNING **: Could not find assembly > System > cannot open assembly ../../../mcs/mcs.exe Hm, assuming you could compile mcs/mcs.exe, you should be able to compile the next libraries. Maybe try "make PROFILE=atomic" and see if that builds sucessfully. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Extra characters in Console.Write output
On Sat, 2003-07-12 at 12:02, Richard Thombs wrote:
> I'm seeing extra characters at the beginning of Console.Write output in
> RedHat 9. A simple Console.WriteLine("Hello, World!\n") gives three
> extra byes at the beginning of the output: ef, bb, bf before printing
> the 'H' of Hello.
>
> Any ideas? The monodis has the correct string in it.
>
> Thanks,
>
> Stony.
This is Red Hat 9 (probably) using UTF8 on its console; the bytes are
some kind of UTF8 endianness markers I think. I don't think it's
possible to get rid of them in a nice way, but if you do
LC_ALL=C mono myexe.exe
they shouldn't show up.
Peter
--
Peter Williams [EMAIL PROTECTED]
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] emacs modes
On Sat, 2003-06-21 at 20:39, Havoc Pennington wrote: > Hi, > > Neither Emacs mode linked in the tutorial works for me, they both > puke with lisp errors. > > I have emacs-21.2-33 from Red Hat Linux 9, which doesn't seem all that > obscure. Do the modes work for anyone else with this version of Emacs? > I use csharp-mode.el from http://davh.dk/script/. It's much simpler than the other ones I tried and Just Worked on RH9 for me. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: monodocs problem
Hi Stuart, On Sat, 2003-06-14 at 10:06, Stuart Jansen wrote: > Shortly after responding, I tried firing up monodoc and it failed to > start. I'd recently installed the XD2 rpms for Evolution 1.4 and that > proved to be the culprit. After > > ln -s /usr/lib/libgtkhtml-3.0.so.2 /usr/lib/libgtkhtml-3.0.so Just a call to /sbin/ldconfig should make that link; I had a problem because mono's config file was mapping gtkhtml-3-0 to libgtkhtml-3.0.so.1, not .so.2. I'm not sure why the .so version is included; I changed it manually and things work fine. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] monodoc.xml entry patch
Hi, On Thu, 2003-06-12 at 13:05, Johannes Roith wrote: > add new entry in monodoc.xml for handbook > > Index: monodoc.xml > === > RCS file: /cvs/public/monodoc/browser/monodoc.xml,v > retrieving revision 1.4 > diff -u -r1.4 monodoc.xml > --- monodoc.xml 17 Apr 2003 19:48:28 - 1.4 > +++ monodoc.xml 12 Jun 2003 17:14:02 - > @@ -2,5 +2,6 @@ > > > > + > > I guess I'm a little bit late in commenting, but shouldn't there be a way to achieve this so that the Handbook node doesn't show up if you don't have the handbook installed? I'm not quite clear on the distinction between monodoc.xml and the sources/ stuff, but I'd think the latter way of installing documentation would be preferable, because you can easily add and remove stuff on a per-package level. (Like the way that distros moved from inetd.conf to xinetd.d/) Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mentoring new developers with Mono
Hi Robert, On Tue, 2003-06-03 at 17:41, Robert Scott Horning wrote: > What I'm proposing is possibly the formation of a mentoring > group/mailing list where no question is asked too often and seemingly > stupid questions can be asked. I also think that some baby steps need > to made before wading in and doing some significant development. If you > can think of some other ways this can be done (including working on the > Wiki), I'd like to step in. I also know that with open source projects > sometimes some leadership needs to be had, and I'm willing to take on > this task if necessary. Of course, this will be the blind leading the > blind, but I'm willing to do that. > GNOME, where a lot of Mono programmers come from, has a similar list called [EMAIL PROTECTED] I've never been involved with it, so I can't say how successful it is, but that would be a place to look for ideas or experience. That being said, I think one of the pluses of working in C# is that it's pretty easy to just start writing code and make something that works, especially with the current state of the class libraries. Still, from the number of people that post 'I want to help out' messages, it looks like we can do better. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Preview: xine-sharp, c# bindings for the xinemedia player library.
On Tue, 2003-05-27 at 11:22, Rich Wareham wrote: > And finally, finally, here is a URL: > http://charon.ucam.org/~rjw57/pub_files/xine-sharp-0.1.tar.bz2 That's pretty neat; it took me maybe 30 seconds to build and I can play the DOOM III trailer :-) And we saw ESD# a few days ago... looks like C# wrappers are just too darn easy to write. Probably not a bad thing. Peter -- Peter Williams [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: More help needed with XSLT.
Hi Miguel, On Mon, 2003-02-17 at 20:29, Miguel de Icaza wrote: > Hello! > > I am using the first attached XSLT in the Mono documentation > browser, but it is not handling a couple of entries:... This should do the trick, I think. Peter -- Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power http://www.w3.org/1999/XSL/Transform";> ( Prueba de mono .
Re: [Mono-list] About "Page is loading."
On Wed, 2003-02-12 at 00:35, [EMAIL PROTECTED] wrote:
> Hello,
>
> Can anybody tell me what is the mail with the subject "Page is loading"?
> I received that and I saw that it is a "¿virus?" (really it is an exe
> file encapsulated inside an audio file)...
It's an Outlook virus of some kind. There are many possible places it
could have come from (forged return address...) so I don't think Miguel
is secretly using a compromised Windows machine or anything. Just delete
it.
Cheers,
Peter
--
Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED]
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Re: OS/X build error for glib-2.0
On Sun, 2003-02-09 at 22:49, Nick Drochak wrote:
> Right now that is crashing on linux, but it did work about a week+ ago.
>
I just had an inspiration as to how to track this down and fix it. The
attached patch makes NUnit 2 work for me. Yay.
Peter
--
Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED]
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power
Index: nunit20/framework/ChangeLog
===
RCS file: /cvs/public/mcs/nunit20/framework/ChangeLog,v
retrieving revision 1.2
diff -u -r1.2 ChangeLog
--- nunit20/framework/ChangeLog 10 Jan 2003 02:12:25 - 1.2
+++ nunit20/framework/ChangeLog 10 Feb 2003 06:16:14 -
@@ -1,3 +1,7 @@
+2003-02-10 Peter Williams <[EMAIL PROTECTED]>
+
+ * TestCaseBuilder.cs: The array cast didn't seem to work, so save it until
+ a little later.
2003-01-10 Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
Index: nunit20/framework/TestCaseBuilder.cs
===
RCS file: /cvs/public/mcs/nunit20/framework/TestCaseBuilder.cs,v
retrieving revision 1.1
diff -u -r1.1 TestCaseBuilder.cs
--- nunit20/framework/TestCaseBuilder.cs 9 Dec 2002 14:39:22 - 1.1
+++ nunit20/framework/TestCaseBuilder.cs 10 Feb 2003 06:16:14 -
@@ -157,10 +157,11 @@
private static string GetIgnoreReason(MethodInfo methodToCheck)
{
Type ignoreMethodAttribute = typeof(NUnit.Framework.IgnoreAttribute);
- NUnit.Framework.IgnoreAttribute[] attributes = (NUnit.Framework.IgnoreAttribute[])methodToCheck.GetCustomAttributes(ignoreMethodAttribute, false);
+ object[] attributes = methodToCheck.GetCustomAttributes(ignoreMethodAttribute, false);
string result = "no reason";
+
if(attributes.Length > 0)
-result = attributes[0].Reason;
+result = ((NUnit.Framework.IgnoreAttribute) attributes[0]).Reason;
return result;
}
RE: [Mono-list] type-reflector
On Sun, 2003-02-02 at 12:31, Jonathan Pryor wrote: > I took a look into this, and it doesn't quite do what I want. > > What I want is a combination between normal CVS modules and CVS > ampersand modules. What I want to be able to do is something like this: > > $ cvs co mono-tools > $ ls > debuggertype-reflector > $ touch Makefile > $ cvs add Makefile > > In other words, I want to have a CVS module which contains other CVS > modules, much like ampersand modules, but with the ability to add > additional files to the module, such as a top-level Makefile and > configure script. This sounds a lot like how the macros/ directory used to be included in GNOME CVS directories... you could checkout GNOME's CVSROOT/modules and see how it was done there, but if I recall correctly it would be: mono-tools mono-tools &debugger &type-reflector HTH, Peter -- Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED] "[Ninjas] are cool; and by cool, I mean totally sweet." -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] A documentation coverage tool
On Wed, 2003-01-29 at 20:29, Peter Williams wrote:
> Hi Duncan et al,
Ok, I sort of ran with this and wrote a tool to compare the ECMA
documentation file for a class and compare it against the master.xml
file. Again, it almost surely has some issues, but I thought it was
really nifty.
Peter
--
Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED]
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power
// Author: Peter Williams <[EMAIL PROTECTED]>
using System;
using System.Text;
using System.Text.RegularExpressions;
using System.Collections;
using System.IO;
using System.Xml;
//
// Known bugs:
//
// * Implementations of interface functions might
// be handled wrong. The doc file records
// the name as something like
//
//
//
// but the master XML file only has
//
//
//
// So there isn't enough info to tie the two together. Well, maybe we could chop
// off everything before the last period? Seems risky.
//
// * Probably there are more bugs when the XML isn't in the expected format.
// I must admit that XmlTextReader is not winning my heart.
//
namespace MonoDoc {
public enum MemberType {
Class,
Interface,
Struct,
Delegate,
Enum,
Constructor,
Field,
Prop,
Method,
Operator,
Event
};
public enum DocType {
Unknown,
Docs,
NoDocs
};
public class Member {
public MemberType type;
public DocTypedocs;
public string name;
public string return_type; // or type of self if property
public string[] param_names;
public string[] param_types;
private int param_size;
private void AddParam (string name, string type)
{
if (param_size == 0) {
param_names = new string[2];
param_types = new string[2];
} else if (param_size == param_names.Length) {
string[] new_names = new string [param_size * 2];
string[] new_types = new string [param_size * 2];
param_names.CopyTo (new_names, 0);
param_types.CopyTo (new_types, 0);
param_names = new_names;
param_types = new_types;
}
param_names[param_size] = name;
param_types[param_size] = type;
param_size++;
}
private void EnumFromMaster (XmlTextReader r)
{
int depth = r.Depth;
while (r.Read () && r.Depth > depth) {
if (r.Name == "field" && r["name"] != "")
AddParam (r["name"], null);
}
}
private void ParamsFromMaster (XmlTextReader r)
{
string name = r["name"];
string args = r["argnames"];
if (args == "")
return;
string[] namelist = Regex.Split (args, ", ");
string types = Regex.Match (name,
"[^(]*\\(([^)]*)\\)").Groups[1].Value;
string[] typelist = Regex.Split (types, ", ");
for (int i = 0; i < namelist.Length; i++)
AddParam (namelist[i], typelist[i]);
}
private void TypeFromDoc (XmlTextReader r)
{
// this probably needs robustification
r.Read();
string t = r.Value;
switch (t) {
case "Class":
case "Interface":
case "Structure":
throw new Exception (String.Format ("Can't handle a nested {0}
yet", t));
case "Delegate":
type = MemberType.Delegate;
break;
case "Enumeration":
type = MemberType.Enum;
break;
case "Constructor":
type = MemberType.Constructor;
break;
case "Field":
type = MemberType.Field;
break;
case "Property":
type = MemberType.Prop;
break;
case "Method":
type = MemberType.Method;
break;
// This doesn't happen
// case "Operator":
// type = MemberType.Operator;
// break;
[Mono-list] A documentation coverage tool
Hi Duncan et al,
In the hopes of getting a better understanding of how monodoc works, I
wrote a little tool that generates a report of how well an assembly is
documented, based on comparing its master XML file to the XML
documentation files on disk. It's not too bright and definitely could
use some love, but it seems to be doing the trick at the moment.
Thanks,
Peter
--
Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED]
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power
using System;
using System.Text;
using System.Collections;
using System.IO;
using System.Xml;
namespace MonoDoc {
class CoverageReport {
string topdir;
string[] args;
int classes;
Hashtable trans;
Hashtable sizes;
// this gets called once for each class listed in the
// master XML file for the assembly
void DoReport (XmlTextReader r, string ns, string name)
{
// otherwise the enumerator gets messed up as we
// are manipulating the table while iterating over it.
object[] keys_copy = new object[trans.Keys.Count];
trans.Keys.CopyTo (keys_copy, 0);
foreach (string lang in keys_copy) {
string lpath = Path.Combine (topdir, lang);
string nspath = Path.Combine (lpath, ns);
string namepath = Path.Combine (nspath, name + ".xml");
FileInfo fi = new FileInfo (namepath);
if (!fi.Exists)
Append (lang, namepath);
}
classes++;
}
// I feel like there has to be a better way to do this...
void Append (string key, string val)
{
int sz = (int) sizes[key];
string[] old = (string[]) trans[key];
int len = old.Length;
if (len == sz) {
string[] new_data = new string[len * 2];
Array.Copy (old, new_data, len);
trans[key] = new_data;
}
((string[]) trans[key])[sz] = val;
sizes[key] = sz + 1;
}
void Go ()
{
if (args.Length != 1) {
Usage ();
Environment.Exit (1);
}
string file = args[0];
// list the languages we're going to be looking for
Console.Write ("Looking for translations to: ");
topdir = Path.GetDirectoryName (file);
DirectoryInfo di = new DirectoryInfo (topdir);
foreach (DirectoryInfo a in di.GetDirectories()) {
if (a.Name != "CVS") {
Console.Write ("{0} ", a.Name);
// This feels really lame. Is there
// no better way?
trans[a.Name] = new string[1];
sizes[a.Name] = 0;
}
}
Console.WriteLine();
Console.WriteLine();
// Now parse the master file to find out what classes
// are actually there.
Console.Write ("Parsing {0} ... ", file);
try {
MasterParser mp = new MasterParser (file);
mp.Process (new MasterParser.ClassCallback (DoReport));
} catch (Exception e) {
Console.WriteLine ("Error trying to process {0}: {1}",
file, e.Message);
}
Console.WriteLine ("ok");
// now print what's missing
foreach (string lang in trans.Keys) {
Console.WriteLine();
string[] missing = (string[]) trans[lang];
Console.WriteLine ("{0}: coverage is {1} / {2} = {3:F2}%",
lang, classes - missing.Length, classes,
(float) (classes - missing.Length) * 100.0 / classes );
Console.WriteLine ("{0}: missing files are:", lang);
for (int i = 0; i < (int) sizes[lang]; i++)
Console.WriteLine (" {0}", missing[i]);
}
}
///
// Housekeeping
void Usage ()
{
Console.WriteLine ("CoverageReport.exe [path to master xml file]");
}
CoverageReport (string
