[Mono-devel-list] Java and Mono
Hi all ! I continue my trip in the Mono's land, and now, I try to compile a Java program with ikvmc to obtain a .exe file wich I want to run over Mono. But it doesn't work... 1 ) javac test.java 2 ) ikvmc test.class -r:IKVM.GNU.Classpath.dll (the dll is in the current rep) 3 ) mono test.exe ** (test.exe:31690): WARNING **: The following assembly referenced from /cea/dsku/store/home1/gpocre/brunet/TEST/test.exe could not be loaded: Assembly: IKVM.Runtime(assemblyref_index=0) Version:0.14.0.1 Public Key: 13235d27fcbfff58 The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/cea/dsku/store/home1/gpocre/brunet/TEST/). It seems like Mono coulldn't find IKVM.GNU.Classpath.dll... Thanks for reply ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Monoupdater script updated
Hi, Just a heads up to say I've updated my mono-compiling page and uploaded version 0.9b of my updater script. http://www.all-the-johnsons.co.uk/mono/mono-compiling.html At the bottom, you'll notice some ideas I have for the updater which will include packaging builds. My problem is that I don't know how debian, osx or win32 would do this. rpm is rpm is rpm (as long as you have the correct spec file!), so FC, Mandriva, Slackware, SuSE and many other distros are covered. If anyone can point me to some howtos for .deb, osx and win32, I'd appreciate it - that way, the script really can be a one-stop process. TTFN Paul (at work and somewhat bored!) -- He's not the Messiah, he's a very naughty boy - Life of Brian, Monty Python ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Sponsoring Mono bugfixes
Excellent thanks Dean! On 6/3/05, Dean Brettle [EMAIL PROTECTED] wrote: On Fri, 2005-06-03 at 12:00 +0200, Luke Venediger wrote: Hi All, What does the community think of the idea of sponsoring developers to fix Mono bugs? FYI, I believe you can already do this via: http://www.opensourcexperts.com/bountylist.html In fact, there is already a Mono-related bounty. --Dean ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Get Firefox Browser! Reclaim the web. http://getfirefox.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Sponsoring Mono bugfixes
On Fri, 2005-06-03 at 12:00 +0200, Luke Venediger wrote: What does the community think of the idea of sponsoring developers to fix Mono bugs? For example, you might be developing for the mono runtime and there is a bug that is preventing you from going any further with your project. You could offer, say, $20 to the first person that fixes the bug. The size of the ransom could depend on the size of the bug. Hello, I think it's better to use bounties as a reward for doing good work (for instance implementing a super-cool killer-feature) rather than as a motivation for doing boring work. IMHO paying someone money to fix a boring bug has the inherent danger that people won't fix such bugs anymore, but wait until someone sets a bounty on them. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Sponsoring Mono bugfixes
On Fri, 2005-06-03 at 20:27 +0200, Martin Baulig wrote: On Fri, 2005-06-03 at 12:00 +0200, Luke Venediger wrote: What does the community think of the idea of sponsoring developers to fix Mono bugs? For example, you might be developing for the mono runtime and there is a bug that is preventing you from going any further with your project. You could offer, say, $20 to the first person that fixes the bug. The size of the ransom could depend on the size of the bug. Hello, I think it's better to use bounties as a reward for doing good work (for instance implementing a super-cool killer-feature) rather than as a motivation for doing boring work. IMHO paying someone money to fix a boring bug has the inherent danger that people won't fix such bugs anymore, but wait until someone sets a bounty on them. While I don't agree with bounties on specific bugs, I also don't agree with what you are saying at all. No one fixes a boring bug for free anyway today. There are 2 types of people fixing them 1) People who need the fix. 2) People who are payed (by Novell, Mainsoft, whoever) to fix them. This would add a third set of contributors fixing boring bugs, people being payed by bounties. I highly doubt as well, that any bounty would ever be significant enough to actually make money on. Unless you think making 20$ for the 4 or 5 hours that a easy bug would take to fix (time to write the patch, get it reviewed, get it into the codebase) is 'good money'. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] HasShutdownStarted race?
Finalizers are run by one thread, so once you are in one, no new objets will get finalized behind your back. However, I'm not sure if the spec promises that at all. No, no such promise in the spec. In fact, some MS people are talking about using more than one GC thread in future releases, and that would be perfectly compliant with the spec. OTOH, HasShutdownStarted probably *could* change in the middle of the method. But it won't matter. I think it does matter, at least in some cases. In my situation, I have finalizers that need to access other objects during finalization. Normally, that's no problem: when one of those objects gets collected, the finalizer works just fine. Except during shutdown, once System.Environment.Exit() has been called. Because objects can be finalized in any order during shutdown, the finalizer now can no longer safely call into other objects and has to avoid doing that, hence the test for HasShutdownStarted. But, if the condition can change halfway through the execution of a finalizer, that's not very useful. And, because the GC runs asynchronously to the rest of the program, I cannot guarantee that I won't call Exit() while the GC is in the middle of some finalizer. As long as there is only one GC thread, not a problem: even if the condition changes halfway through the execution of a finalizer, that finalizer will still successfully complete, and then HasShutdownStarted becomes true for all the remaining finalizers. But, with multiple GC threads, that's no longer the case. What worries me is that the documentation makes no guarantee as to when the condition can change. And, if I rely on HasShutdownStarted as suggested by MS, it seems I run the risk of my code breaking on a future .NET (or Mono) version. Cheers, Michi. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Sponsoring Mono bugfixes
On Fri, 2005-06-03 at 14:40 -0700, Todd Berman wrote: While I don't agree with bounties on specific bugs, I also don't agree with what you are saying at all. No one fixes a boring bug for free anyway today. There are 2 types of people fixing them 1) People who need the fix. 2) People who are payed (by Novell, Mainsoft, whoever) to fix them. 3) Non paid contributors who fix bugs (I have fallen under this category in the past, as have you) I highly doubt as well, that any bounty would ever be significant enough to actually make money on. Unless you think making 20$ for the 4 or 5 hours that a easy bug would take to fix (time to write the patch, get it reviewed, get it into the codebase) is 'good money'. Well, if you already have a job (or are a student, etc), this is just icing on the cake: maybe you can get an ipod after 10 bug fixes or something. Nobody is suggesting that you can make a carer out of bounties. Even if priced well, its not reliable income etc. On another note: if there are bugs in bugzilla that are simple enough that $100 would make somebody look into them, its probably a bad sign: we should be killing more low hanging fruit. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] HasShutdownStarted race?
On Sat, 2005-06-04 at 07:46 +1000, Michi Henning wrote: Finalizers are run by one thread, so once you are in one, no new objets will get finalized behind your back. However, I'm not sure if the spec promises that at all. No, no such promise in the spec. In fact, some MS people are talking about using more than one GC thread in future releases, and that would be perfectly compliant with the spec. Are they talking about a parallel gc (I think they already have one of those) or parallel finalization? Anyways, if they change this, you wouldn't be the only one affected. If you need more info, best to ask them. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
