Re: [Mono-dev] LINQ Standard Query Operators for Mono
On Mon, 2005-12-12 at 11:35 +0900, Atsushi Eno wrote: Hi, Alejandro Serrano wrote: Hi, I'm currently working on implementing the LINQ Standard Query Operators (http://msdn.microsoft.com/netframework/future/linq) from the latest Microsoft bits. I'm not working,however, on DLinq, XLinq or any other parts from this idea. Although it's not in an even pre-release stage, I think this classes in System.Query could help everyone using .NET or Mono. I'm currently using the Nemerle programming language, and I would like to post the code to anywhere in Mono, so it can be included or used by the entire community. Which is the best place to do that? Oh, interesting. Mono would be the best place and we need System.Query implementation (at least in the future). Please post your code here (this ML) so that everyone can try and someone can review for the commit. One issue (if I understood the original email fully) is that the implementation is in Nemerle. Correct me if I am wrong, but a C# implementation is more or less required for inclusion in Mono. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Right MCS in Path, Configure Gets Wrong MCS
On Wed, 2005-09-21 at 20:18 -0500, Stephen Quattlebaum wrote: I asked this question on the list a few weeks ago but no response. Maybe a different set of eyes happen across it this time. -- I'm trying to build gtk-sharp from SVN. I have a stable mono installation in /usr, but I also have a bleeding-edge installation at /home/stephen/bin/mono-svn. I want to use the mcs found there (/home/stephen/bin/mono-svn/bin/mcs) b/c I plan to install gtk-sharp there, and the 'stable' compiler in /usr is much older. I have my PATH set up for my user account so that the newer mono is the one that should be seen. I.e., `which mcs` returns the expected /home/stephen/bin/mono-svn/bin/mcs. When I run ./bootstrap-2.4 --prefix=/home/stephen/bin/mono-svn/, however, I get the following summary after configure runs: Configuration summary * Installation prefix = /home/stephen/bin/mono-svn/ * C# compiler: /usr/bin/mcs My best guess is to make sure that your PKG_CONFIG_PATH contains /home/stephen/bin/mono-svn/lib/pkgconfig/ as I believe gtk# checks for mcs using the location of the mono.pc, but I could be wrong. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Completion refactoring?
Alex, this list is entirely inappropriate for this discussion. If you would like to discuss this, please *subscribe* and send an email to the monodevelop-list, not this one. This list is for mono development, not monodevelop. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-docs-list] [PATCH] Monodoc Gecko support improved
On Sat, 2005-07-30 at 02:08 +0200, Mario Sopena wrote: Hey everybody, after being stucked for a couple of days because of a stupid error that I made, I've finally added some improvements to the gecko patch. * Gecko support is now only built when gecko-sharp is present (GeckoHtmlRender.dll). Gecko-sharp is not a requirement now. I am curious how this works. My copy of gecko# is 0.6, and it is built against gtk# 2.0, this prevents it from being used to built monodoc. So this check here doesn't work. Is the plan to move monodoc to gtk# 2.0, or to stick with the gecko# version that is built against gtk# 1.0 (Which I think is 0.5, I believe 0.6 has always built against 2.0). --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-docs-list] [PATCH] Monodoc Gecko support improved
On Sat, 2005-07-30 at 02:36 +0200, Mario Sopena wrote: Hola, On 7/30/05, Todd Berman [EMAIL PROTECTED] wrote: I am curious how this works. My copy of gecko# is 0.6, and it is built against gtk# 2.0, this prevents it from being used to built monodoc. So this check here doesn't work. Where did you get this gecko# 0.6? Because the one in SVN is gecko#2 which requires gtk#2 and the gecko# 0.6 from tarballs require gtk# 1.0. AFAIK, gecko# should be built for gtk#1.0 and gecko#2 for gtk#2. Ah, maybe my version is before the pc file was version bumped. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-docs-list] [PATCH] Monodoc Gecko support improved
On Fri, 2005-07-29 at 18:23 -0700, Todd Berman wrote: On Sat, 2005-07-30 at 02:36 +0200, Mario Sopena wrote: Hola, On 7/30/05, Todd Berman [EMAIL PROTECTED] wrote: I am curious how this works. My copy of gecko# is 0.6, and it is built against gtk# 2.0, this prevents it from being used to built monodoc. So this check here doesn't work. Where did you get this gecko# 0.6? Because the one in SVN is gecko#2 which requires gtk#2 and the gecko# 0.6 from tarballs require gtk# 1.0. AFAIK, gecko# should be built for gtk#1.0 and gecko#2 for gtk#2. Ah, maybe my version is before the pc file was version bumped. Actually. I found the issue. The issue was I had both the gecko-sharp.pc and gecko-sharp-2.0.pc. And since the gecko-sharp.pc was version 0.6, and points to the gecko-sharp.dll built against 2.0 (because they both point to /usr/lib/mono/gecko-sharp/gecko-sharp.dll, which is a symlink in my case the to 2.0 version). It was 'finding' gecko-sharp 0.6. --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] Getting mono-tools to compile
On Sun, 2005-07-24 at 21:09 +0100, Paul wrote: Hi, I've downloading gtk-sharp from /trunk/sources on anon svn. Have I got it right that if I run the ./bootstrap file (and then make; make install) it should generate the code which correctly creates the /usr/lib/pkgconfig/gtk-sharp.pc file and the ./bootstrap-2.4 generates the gtk-sharp-2.pc file? If that is the case, there is a problem on my system as then normal bootstrap is not generating the gtk-sharp.pc file. gtk# from svn is gtk-sharp-2.0, not gtk-sharp-1.0. You need to find the latest tarball from gtk-sharp 1.0.x and install that. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: Re:[Mono-devel-list] Unable to build mono-tools
On Sun, 2005-07-24 at 07:57 +0900, 황윤성 wrote: ln -s /usr/lib/pkgconfig/gtk-sharp-2.0.pc /usr/lib/pkgconfig/gtk-sharp.pc mbuild need gtk-sharp.pc But gtk-sharp-svn have gtk-sharp-2.0.pc That is the worst possible thing you could do. gtk-sharp and gtk-sharp-2.0 are different things. If you need gtk-sharp, you need to install a copy of gtk-sharp-1.0.x, not symlink a pc file. --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] gtk ComboBox questions...
On Sun, 2005-07-24 at 15:20 +1000, John BouAntoun wrote: That brings up a good point. Not sure if this is still the case, but why in today's day and age (of C# and other great managed languages) is someone using IterNChildrend() (a strangely named function) to return a property that would be most obviously named Count (as with most other collections)? I am not sure that makes sense given how TreeModel works. A TreeIter has no traceable association with its model. At least none that you can access via public API. And a TreeModel.Count property makes no sense in a true Tree context, as you rarely (if ever) care about the # of nodes in the tree, and are usually more interested in the # of children under a specific node. Which is exactly what IterNChildren is for. --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] Re: development of monodevelop: why? :P
On Wed, 2005-07-13 at 22:17 +0300, KCorax wrote: I believe that java is friendly to us because of ikvm's existance. Eclipse is based on java therefore it could be hosted over mono runtime. On the other hand I understand that for the makers of mono its good to have an ide written in c#. btw: monodevelop is far better than improve's eclipse plugin. Now we *are* getting off-topic. Non important answers should be sent to me and I shall set a local forward to those who have displayed interest in this. OOC, why is this conversation not on the monodevelop-list, where emails pertaining to MonoDevelop should be? I would be happy to answer and discuss these questions and issues with people, but only on the appropriate list. So, to anyone who sent an email to this thread, and would like some form of answer, please repost your questions to the monodevelop-list. --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] Guidelines: Application Deployment; Feedback requested.
On Sun, 2005-06-26 at 21:41 -0400, Ben Maurer wrote: On Sun, 2005-06-26 at 20:47 -0400, Miguel de Icaza wrote: Some other things that might be worth talking about: * Storing application settings (how to use S.Environment to get a location for preferences. Having both global and per user prefs) I guess the options are using SpecialFolder.CommonApplicationData/APPNAME or some path relative to the location of the .dll for shared preferences. I'm not sure which we want to recommend (SpecialFolder is less relocatable, while using the path to the .dll is sorta weird having having settings in /usr/lib). I would hope *no one* would put their library in /usr/lib. For MonoDevelop we use /usr/lib/monodevelop and we store default preferences and other data in /usr/lib/monodevelop/data/ --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] Object Browser / Reflector in Mono
On Sun, 2005-06-12 at 16:23 -0400, Paul Betts wrote: Wow I wasn't quite awake when I wrote that Email; I meant I wanted to integrate it with MonoDevelop, not SharpDevelop. Paul I believe JB Evain is working on something that uses Mono.Cecil that we would want to integrate with MonoDevelop. I believe the end goal is that it will have the features of .net's ildasm. --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] System.Diagnostic.Process and /dev/tty
I would look at interfacing through libgpgme instead of via the commandline. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] -langversion defaults
Hey, I think for the 1.1.x series, we need to make mcs assume a -langversion:ISO-1 default. This would be really helpful for people building applications that should work with .net 1.1. It seems (maybe I am wrong) that if you are building a .net 1.1 app, you use mcs, and if you are building a .net 2.0 app, you use gmcs. Maybe that isn't the end goal, but it certainly seems to be the current way of doing things. Enforcing -langversion:ISO-1 as a default would go a long way to help solving some of those issues. --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] 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
