From mbd at dbc.dk Thu Nov 1 03:23:13 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Thu, 1 Nov 2007 08:23:13 +0100 Subject: [Mono-dev] MonoSummit: Planning the Sessions In-Reply-To: <1193844788.32235.135.camel@erandi.dom> References: <1193844788.32235.135.camel@erandi.dom> Message-ID: <200711010823.13754.mbd@dbc.dk> onsdag 31 Oktober 2007 skrev Miguel de Icaza: > We are working on a schedule now, thanks for the feedback on the topics > you want discussed. Hi Miguel. For those of us that need to book flights, a rough outline of the _time_ would be great, e.g. "We start every day at 9, stop at 16, friday we stop at 15", or something like that... Would be much appreciated, even if the actualy schedule is not finished. ASAP or before :-) Regards, Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From apenwarr at gmail.com Thu Nov 1 08:56:01 2007 From: apenwarr at gmail.com (Avery Pennarun) Date: Thu, 1 Nov 2007 08:56:01 -0400 Subject: [Mono-dev] Mono version numbering In-Reply-To: References: <9D5C53A7-2194-42B5-AC7B-8D8A62E02601@web.de> <32541b130710311138g765bad66r38910be1be0eae00@mail.gmail.com> <1193861190.7329.18.camel@redbull.qnetp.net> <32541b130710311314u4ec2c13dx961b5fb6bb9ed17f@mail.gmail.com> Message-ID: <32541b130711010556k3bd0a09cpcbe596164c5b497e@mail.gmail.com> On 31/10/2007, Euan MacInnes wrote: > This is also better for more lightweight environments and applications, i.e. > casual games and Windows CE devices which have download/space restrictions, > and I'd rather not get into custom forks of the mono build to cope with > those scenarios, where download sizes are limited to 5Mb to 10Mb, so a 50Mb > download with 120Mb installation isn't practical, yet small independent > companies that make these games won't want to get into having to provide > custom builds of Mono to do it. Speaking completely selfishly, this would be great for me. We're working on a cross-platform C# app and oddly, the hardest part of the installation is ensuring that *Microsoft's* .net is installed properly. If we could just bundle a micro-mono for Windows into our distribution, we wouldn't have to worry about testing on two platforms (mono and MS .net) and the installation package would be smaller and faster. I'm not really impressed with most of the .net runtime (winforms, streams, buffers, sockets, etc): none of them work they way I'd like them to work, so I'm forced to reimplement a lot of it for my project anyway. But C# and the CLR are great fun. Thus the ability to get a minimal C# operating environment would be a really nice option. That said, I'm not sure it's an option that serves the majority of mono users, and removing libraries from a custom distribution is not really rocket science anyway, so I don't really expect anyone to do this for me :) > .NET 3.0 itself comes in at a nice 5Mb installation size, > however backwards compatibility with the bulk of the market (Windows 95/98) > has been dropped. If I recall, the .net 3.0 package requires 2.0 to already be installed. It's just some updated libraries. So that 5 megs is *on top* of the 2.0 size. Have fun, Avery From equistango at gmail.com Thu Nov 1 15:03:12 2007 From: equistango at gmail.com (Ernesto) Date: Thu, 01 Nov 2007 16:03:12 -0300 Subject: [Mono-dev] Mono version numbering In-Reply-To: References: <9D5C53A7-2194-42B5-AC7B-8D8A62E02601@web.de> <32541b130710311138g765bad66r38910be1be0eae00@mail.gmail.com> <1193861190.7329.18.camel@redbull.qnetp.net> <32541b130710311314u4ec2c13dx961b5fb6bb9ed17f@mail.gmail.com> Message-ID: <472A22F0.9020305@gmail.com> Euan MacInnes wrote: > I would suggest that, rather than one version, Mono should split up > it's packages differently. I have to agree. If we are talking about a "on size fits all" Mono distribution, no version number can be too descriptive. My guess is that numbering Mono as either 1.x or 2.x will not solve the full problem. If it's labeled "Mono 2.0", people may end up thinking they need Mono 1.x to run .NET 1.1 apps (just like they think they need Mono 2.x to run .NET 2.0 apps). Or they might try to install Mono 1.x and 2.x simultaneously, just like .NET (we are always talking about those who don't want to read further than the version number, remember). This is: either split up Mono runtime into versions 1, 2, etc. or don't pay too much attention to version numbers. I'd like to see the runtime split up, but I guess that's out of the question right now. So in the "don't pay too much attention" model, I like Marek's proposal (to call it 1.8 when it's "almost 2.0" and 2.0 when it's really 2.0). Regards, Ernesto > > The main reason for this is simple marketing. Mono needs more .NET > activity, the way to do that is to make it easier for "outsiders" to > more quickly grasp where it's at. To this end, my suggestion here is > to separate out a few things: Firstly, Mono comes as a "kitchen sink" > 1.2.5 option at the moment, which confuses the issue, makes it > unrelatable. The C# implementation is closer to 3.0, yet WinForms > (part of .NET, not C# itself) isn't quite 2.0 yet, so ideally what > .NET people will grasp faster is: > > Mono Frameworks: > > Mono.C# 3.0 (includes C# 1.0, 1.1 and 2.0, or not, preferably not, see > later) > Mono.VB 2.0 > Mono.Boo > Mono.NET 1.1 (Contains Mono.ASP 1.1, Mono.DB 1.1, also installable > separately) > Mono.NET 2.0 (Contains Mono.ASP 2.0, Mono.WinForms 1.9.3, Mono.DB 2.0 > also installable separately) > Mono.DB 2.0 (Contains Mono.Oracle, Mono.MySql, Mono.Firebird, etc.. etc..) > Mono 1.2.5 Developer Package (Contains Nunit, Debug, Developer Tools, > Help documentation) > Mono 1.2.5 Hardcore Package (Contains the source code, build files etc...) > > Then have the sources available separately for those that need it. > It's a basic renaming, more or less, of what's there already for > Linux, except splitting the mono_core up into more bite-sized, > manageable chunks, and then grouping some existing packages together > for those that want to try it, i.e. the Mono.NET one, and then, > especially on Windows, downloading and installing those missing ones > if they ever get used, rather than an uber-installer. My app's in C#, > my users will never need Boo or J# or VB, or ASP. > > When there are incremental patches as well, the core package header > can increase as well, i.e. Mono.NET 2.0.1 for example, to indicate > that one of the constituent packages increased. > > This is also better for more lightweight environments and > applications, i.e. casual games and Windows CE devices which have > download/space restrictions, and I'd rather not get into custom forks > of the mono build to cope with those scenarios, where download sizes > are limited to 5Mb to 10Mb, so a 50Mb download with 120Mb installation > isn't practical, yet small independent companies that make these games > won't want to get into having to provide custom builds of Mono to do > it. The issue here isn't space on the PC, it's the space on the web > portals that sell casual games, and the portal's bandwidth costs, that > are the commercial issues. Generally, their preference is for 10Mb to > 20Mb max download size. > > The other reason for doing this route is one of the big barriers to > adoption for games on .NET 2.0 is the size of the .NET 2.0 > installation, at 22Mb, it's 14Mb too big, so by making Mono split into > smaller more manageable installation chunks, we're also making it a > more viable alternative to .NET on Windows as well as Linux/MacOSX for > low space/small size scenarios. .NET 3.0 itself comes in at a nice 5Mb > installation size, however backwards compatibility with the bulk of > the market (Windows 95/98) has been dropped. > From twiest at novell.com Thu Nov 1 16:17:03 2007 From: twiest at novell.com (Thomas Wiest) Date: Thu, 01 Nov 2007 14:17:03 -0600 Subject: [Mono-dev] Mono version numbering In-Reply-To: <472A22F0.9020305@gmail.com> References: <9D5C53A7-2194-42B5-AC7B-8D8A62E02601@web.de> <32541b130710311138g765bad66r38910be1be0eae00@mail.gmail.com> <1193861190.7329.18.camel@redbull.qnetp.net> <32541b130710311314u4ec2c13dx961b5fb6bb9ed17f@mail.gmail.com> <472A22F0.9020305@gmail.com> Message-ID: <472A343F.1030401@novell.com> Ernesto wrote: > Euan MacInnes wrote: > >> I would suggest that, rather than one version, Mono should split up >> it's packages differently. >> > > I have to agree. If we are talking about a "on size fits all" Mono > distribution, no version number can be too descriptive. > Exactly, so maybe we eliminate the confusion entirely and use a version number that has nothing to do with .Net. It seems to me that the whole problem that we are having is that we keep trying to imply our status with our version number, and people keep inferring wrong (as with Miguel's example of the guy asking when asp.net 2.0 would be done). Why don't we stop trying to imply our status through our version number? If we had a completely different numbering scheme, this wouldn't happen. For instance, we could do something like Ubuntu where we take the Year.Month.0 of the release. So, 1.2.6 would most likely be 7.11.0. 7.11.0 doesn't make any sense to a .Net person. Therefore they will have to go read the release notes and other documentation to find out exactly what is in this version. Bug fix only releases could be 7.11.1, .2, etc. The other nice thing about this is since Miguel started working on Mono in 2000, it would be a close approximation of how many years have been put into the release (and how mature the project is). If the version is going to imply anything, it should imply the maturity. :) Even if we decided to have individual version for each component, we should still have a version number that encompasses the whole. Just my thoughts, Thomas From charlie at nunit.com Thu Nov 1 17:22:59 2007 From: charlie at nunit.com (Charlie Poole) Date: Thu, 1 Nov 2007 14:22:59 -0700 Subject: [Mono-dev] MonoSummit: Planning the Sessions In-Reply-To: <1193408627.24461.91.camel@erandi.dom> Message-ID: <005d01c81ccd$617f8680$6501a8c0@FERRARI> Hi Miguel, > Am looking for ideas for topics that developers would be > interested > in hearing about at the Mono Summit. I've been hanging on to this note while I tried to figure out if I could swing the trip. As of this morning, I'm happy to say I'm coming! My interests are around the following areas - at least :-) 1) Testing frameworks - NUnit of course, but others as well. 2) I'd like to gain some insights into best practices of cross-platform development, particularly desktop gui. 3) I'm hoping to find some time to work together with folks who have ideas about the next version of NUnit (3.0) particularly in terms of how it could use Mono.Addins as a base for it's extension architeture. 4) Lots of free time to share ideas on topics that I won't think of until I'm there. Charlie From gert.driesen at telenet.be Thu Nov 1 17:48:51 2007 From: gert.driesen at telenet.be (Gert Driesen) Date: Thu, 1 Nov 2007 22:48:51 +0100 Subject: [Mono-dev] [PATCH] New tests for Regular expressions In-Reply-To: Message-ID: <20071101214859.55BA52300BB@adicia.telenet-ops.be> Arina, Test case 44 in RegexResultTests is failing on MS (but passing on Mono). Can you look into this? Thanks, Gert _____ From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Arina Itkes Sent: zondag 28 oktober 2007 19:28 To: mono-devel-list at lists.ximian.com Subject: [Mono-dev] [PATCH] New tests for Regular expressions I added new tests for regular expressions. Part of them is not working. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071101/d1ee7768/attachment.html From miguel at novell.com Thu Nov 1 19:45:46 2007 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 01 Nov 2007 19:45:46 -0400 Subject: [Mono-dev] Mono version numbering In-Reply-To: References: Message-ID: <1193960746.5391.62.camel@erandi.boston.ximian.com> Hello, > I tried out the tool and aside from some typical path issues, the app > ran great. Kudos to the WinForms developers! Is there any way to get > MoMA to do some Cecil magic and fix path issues? 2 Points for > evaluate, but you really get extra credit for remediate! I guess we get the two points already. Check out our awesome support for this: http://www.mono-project.com/IOMap This takes care of it without having to change anything. Miguel. > From miguel at novell.com Thu Nov 1 19:49:18 2007 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 01 Nov 2007 19:49:18 -0400 Subject: [Mono-dev] Mono version numbering In-Reply-To: <32541b130710311314u4ec2c13dx961b5fb6bb9ed17f@mail.gmail.com> References: <9D5C53A7-2194-42B5-AC7B-8D8A62E02601@web.de> <32541b130710311138g765bad66r38910be1be0eae00@mail.gmail.com> <1193861190.7329.18.camel@redbull.qnetp.net> <32541b130710311314u4ec2c13dx961b5fb6bb9ed17f@mail.gmail.com> Message-ID: <1193960958.5391.66.camel@erandi.boston.ximian.com> > This is definitely not the case. For example, a simple test program > compiled with mcs (v1) in Ubuntu 6.06 will work with the mcs-compiled > nunit, but crashes when the same program is compiled with gmcs (v2). > It's possible that this was fixed in a later version of mono. The explanation is very simple, the source of the problem is that you can only load one version of mscorlib and the startup program determines which mscorlib is loaded. In the case of nunit, if you run say "nunit-console" that will load the 1.0 runtime, and if that later tries to load an assembly that was compiled with 2.0 it will load it, but it will later fail when the assembly tries to reference 2.0 features. That is why some commands have the "2" suffix (in this case, nunit-console2) because they trigger loading the 2.0 mscorlib (these include: al2 ilasm2 mkbundle2 mono-api-info2 monop2 mono-service2 nunit-console2 resgen2 wsdl2) Miguel From miguel at novell.com Thu Nov 1 19:51:39 2007 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 01 Nov 2007 19:51:39 -0400 Subject: [Mono-dev] Mono version numbering In-Reply-To: <32541b130711010556k3bd0a09cpcbe596164c5b497e@mail.gmail.com> References: <9D5C53A7-2194-42B5-AC7B-8D8A62E02601@web.de> <32541b130710311138g765bad66r38910be1be0eae00@mail.gmail.com> <1193861190.7329.18.camel@redbull.qnetp.net> <32541b130710311314u4ec2c13dx961b5fb6bb9ed17f@mail.gmail.com> <32541b130711010556k3bd0a09cpcbe596164c5b497e@mail.gmail.com> Message-ID: <1193961099.5391.69.camel@erandi.boston.ximian.com> > Speaking completely selfishly, this would be great for me. We're > working on a cross-platform C# app and oddly, the hardest part of the > installation is ensuring that *Microsoft's* .net is installed > properly. If we could just bundle a micro-mono for Windows into our > distribution, we wouldn't have to worry about testing on two platforms > (mono and MS .net) and the installation package would be smaller and > faster. You can already do this. People like Unity (makes of unity3d.com) distribute Mono with a tiny runtime, mscorlib.dll and little else. You can ship as much (or as little) as you want. There are some mandatory files that you must include (like machine.config or libmono.dll/libmono.so) but other than that, there are no strong dependencies. You can use the Debian packages as an indicator of how granular you can go; Those packages have already been pretty well tested in terms of the split they offer. From miguel at novell.com Thu Nov 1 19:53:30 2007 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 01 Nov 2007 19:53:30 -0400 Subject: [Mono-dev] Mono version numbering In-Reply-To: References: Message-ID: <1193961210.5391.72.camel@erandi.boston.ximian.com> > I think the only way to minimise confusion in the developer population > that does not keep up-to-date with the details of development on Mono > is to let at least the major version track full .NET compatibility. > That is, do not move to v2.x.x until at least .NET 2.0 can be fully > supported, do not move to v3.x.x until at least .NET 3.0 can be fully > supported and maybe even do not move to v3.5.x until .NET 3.5 is > supported. This does not solve the confusion that we have today which is that developers assume that until we have Mono X.Y we wont support version X, which is not the case. From kumpera at gmail.com Thu Nov 1 19:55:54 2007 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Thu, 1 Nov 2007 21:55:54 -0200 Subject: [Mono-dev] Status Report Message-ID: <8cca42d80711011655t4fbbdc0ck7303379a7b2b1a86@mail.gmail.com> This week: -Commited a patch for #335131 -Converted Mareks test into a regression test for #335131, creating it was harder than I thought. -Worked on #323747, got I patch sent to Paolo that fixes all soft-float issues. -Friday is celebration of death holiday Next week: -Fix more soft-float cases. -Bugfixing for 1.2.6 Cheers, Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071101/4935a23c/attachment.html From charlie at nunit.com Fri Nov 2 00:02:05 2007 From: charlie at nunit.com (Charlie Poole) Date: Thu, 1 Nov 2007 21:02:05 -0700 Subject: [Mono-dev] Mono version numbering In-Reply-To: <1193960958.5391.66.camel@erandi.boston.ximian.com> Message-ID: <00a501c81d05$222cc320$6501a8c0@FERRARI> Hi Miguel, > In the case of nunit, if you run say "nunit-console" that > will load the 1.0 runtime, and if that later tries to load an > assembly that was compiled with 2.0 it will load it, but it > will later fail when the assembly tries to reference 2.0 features. FWIW, the next NUnit won't work that way. It will run under 2.0 but offer the option to run tests in a separate process under 1.0. Charlie From davem at davemloft.net Fri Nov 2 00:49:41 2007 From: davem at davemloft.net (David Miller) Date: Thu, 01 Nov 2007 21:49:41 -0700 (PDT) Subject: [Mono-dev] [PATCH]: Fix abort when generating sparc V9 code Message-ID: <20071101.214941.98469084.davem@davemloft.net> In current SVN the testsuite gives an abort on sparc because the JIT generates a branch whose relocation cannot fit. It's a branch to an exception stub, so the branch is to the end of the code generation area where the exception handler stubs are placed. The V9 branch can only handle signed 19-bit offsets, and in this case the code area is so big that the displacement to the exception area is too large to fit into the relocation. For these cases we only need the 32-bit icc condition codes. So we can expand the range of offsets that can be handled by using the pre-v9 branches in this case. This gives us a signed 22-bit offset to work with. This is not even sub-optimal for v9 chips because v9 chips use a default prediction of not-taken for pre-v9 branches, and since exceptions are "exceptional"... While working on this patch I noticed a NULL pointer assertion in the exception handler stub emitter that was after the first dereference of that pointer, making it useless. Please apply, thanks. 2007-11-01 David S. Miller * mini-sparc.c (EMIT_COND_SYSTEM_EXCEPTION_GENERAL): Even if sparcv9, use non-v9 branch if using sparc_icc_short. (mono_arch_emit_exceptions): Move NULL pointer assertion before first dereference. Index: mono/mini/mini-sparc.c =================================================================== --- mono/mini/mini-sparc.c (revision 88629) +++ mono/mini/mini-sparc.c (working copy) @@ -1387,7 +1387,7 @@ if (ins->flags & MONO_INST_BRLABEL) { \ #define EMIT_COND_SYSTEM_EXCEPTION_GENERAL(ins,cond,sexc_name,filldelay,icc) do { \ mono_add_patch_info (cfg, (guint8*)(code) - (cfg)->native_code, \ MONO_PATCH_INFO_EXC, sexc_name); \ - if (sparcv9) { \ + if (sparcv9 && ((icc) != sparc_icc_short)) { \ sparc_branchp (code, 0, (cond), (icc), 0, 0); \ } \ else { \ @@ -4207,8 +4207,8 @@ mono_arch_emit_exceptions (MonoCompile * sparc_patch ((guint32*)(cfg->native_code + patch_info->ip.i), code); exc_class = mono_class_from_name (mono_defaults.corlib, "System", patch_info->data.name); - type_idx = exc_class->type_token - MONO_TOKEN_TYPE_DEF; g_assert (exc_class); + type_idx = exc_class->type_token - MONO_TOKEN_TYPE_DEF; throw_ip = patch_info->ip.i; /* Find a throw sequence for the same exception class */ From denisraytek at yahoo.com Fri Nov 2 01:18:20 2007 From: denisraytek at yahoo.com (Dennis Hayes) Date: Thu, 1 Nov 2007 22:18:20 -0700 (PDT) Subject: [Mono-dev] VMWear player for Mono development In-Reply-To: Message-ID: <955542.15988.qm@web39609.mail.mud.yahoo.com> The current VMWear player is one of the greatest things Mono has to boost exploration of Mono. I love it. In fact I love it so much, I want another! What about a VMWear player setup with Mono source and SVN so one could just fire it up, update the source from svn and start contributing? Thanks, Dennis __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071101/fce823d3/attachment.html From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Fri Nov 2 05:04:33 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Fri, 02 Nov 2007 10:04:33 +0100 Subject: [Mono-dev] Mono version numbering In-Reply-To: <472A343F.1030401@novell.com> References: <9D5C53A7-2194-42B5-AC7B-8D8A62E02601@web.de> <32541b130710311138g765bad66r38910be1be0eae00@mail.gmail.com> <1193861190.7329.18.camel@redbull.qnetp.net> <32541b130710311314u4ec2c13dx961b5fb6bb9ed17f@mail.gmail.com> <472A22F0.9020305@gmail.com> <472A343F.1030401@novell.com> Message-ID: <472AE821.40405@gmail.com> Thomas Wiest escribi?: > Ernesto wrote: >> Euan MacInnes wrote: >> >>> I would suggest that, rather than one version, Mono should split up >>> it's packages differently. >>> >> I have to agree. If we are talking about a "on size fits all" Mono >> distribution, no version number can be too descriptive. >> > Exactly, so maybe we eliminate the confusion entirely and use a version > number that has nothing to do with .Net. > > It seems to me that the whole problem that we are having is that we keep > trying to imply our status with our version number, and people keep > inferring wrong (as with Miguel's example of the guy asking when asp.net > 2.0 would be done). Why don't we stop trying to imply our status through > our version number? > > If we had a completely different numbering scheme, this wouldn't happen. > For instance, we could do something like Ubuntu where we take the > Year.Month.0 of the release. So, 1.2.6 would most likely be 7.11.0. > > 7.11.0 doesn't make any sense to a .Net person. Therefore they will have > to go read the release notes and other documentation to find out exactly > what is in this version. Bug fix only releases could be 7.11.1, .2, etc. > > The other nice thing about this is since Miguel started working on Mono > in 2000, it would be a close approximation of how many years have been > put into the release (and how mature the project is). If the version is > going to imply anything, it should imply the maturity. :) > > Even if we decided to have individual version for each component, we > should still have a version number that encompasses the whole. Hey! I think that solution rocks! Mono global version number could have something like 7.11.2, and each specific component could have a version number that matches the progress of it to target .NET features. For example: Mono 7.11.2 released! It contains: - WinForms 1.8 - ADO.NET 1.9 - Olive 0.8 (which includes .NET 3.0 specific stuff): * WCF (80% complete) * WCS (40% complete) - LINQ 0.7 (.NET 3.5 stuff) Regards, Andr?s [ knocte ] -- From js at hotfeet.ch Fri Nov 2 05:51:17 2007 From: js at hotfeet.ch (Juraj Skripsky) Date: Fri, 02 Nov 2007 10:51:17 +0100 Subject: [Mono-dev] [Patch] Regression in AssemblyResourceLoader.GetResourceUrl Message-ID: <1193997077.3378.3.camel@leonardo.hotfeet.ch> Hi Marek, The attached patch fixes a regression introduced with your last change to AssemblyResourceLoader.cs. As the assembly name is encrypted via EncryptAssemblyResource, we mustn't UrlEncode it anymore. May I commit? - Juraj -------------- next part -------------- A non-text attachment was scrubbed... Name: WebResHandler.patch Type: text/x-patch Size: 677 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071102/dab561f8/attachment.bin From grendello at gmail.com Fri Nov 2 05:59:59 2007 From: grendello at gmail.com (Marek Habersack) Date: Fri, 2 Nov 2007 10:59:59 +0100 Subject: [Mono-dev] [Patch] Regression in AssemblyResourceLoader.GetResourceUrl In-Reply-To: <1193997077.3378.3.camel@leonardo.hotfeet.ch> References: <1193997077.3378.3.camel@leonardo.hotfeet.ch> Message-ID: <20071102105959.1316f70e@gmail.com> On Fri, 02 Nov 2007 10:51:17 +0100, Juraj Skripsky scribbled: > Hi Marek, Hey Juraj, > > The attached patch fixes a regression introduced with your last change > to AssemblyResourceLoader.cs. > > As the assembly name is encrypted via EncryptAssemblyResource, we > mustn't UrlEncode it anymore. > > May I commit? Please do, thanks! best regards, marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071102/10c47173/attachment.bin From Brock.Reeve at ni.com Fri Nov 2 10:39:01 2007 From: Brock.Reeve at ni.com (Brock Reeve) Date: Fri, 2 Nov 2007 09:39:01 -0500 Subject: [Mono-dev] MonoSummit: Planning the Sessions In-Reply-To: <84776a970710310903s748f3198y39eddf23c2b1f3c4@mail.gmail.com> Message-ID: I like the idea of having a debugging session. I am a VS.NET brat and am struggling with the best way to debug (hunt down issues) and learn some of the Mono framework. I have created VS.NET solutions for System.Drawing and System.Windows.Forms so I could browse the source with VS.NET which helps. My current way is to build on Windows, copy the assemblies and use Console.Writeline to debug and learn stacks. Let's just say this is not ideal. So the session could be titled something like "Debugging Mono for VS.NET brats". Some ideas for a debugging session: - What tools/processes do Mono developers use to develop? - What is the easiest way for VS.NET developers to debug the framework? - What is the process for submitting code changes (patch files)? I also would like to see a session on the dependencies and the way modules are organized. For example, what the mono framework libraries call into and their dependencies. What parts are unmanged and which parts are managed etc. Here is some examples (the dependencies are things I have read and learned from buildling and might not be totally correct): - Class libraries -> [glib-2.0] - [gthread-2.0] - [libgc] - Moon -> [ffmpeg] - [GTK -> GDK] - [ALSA] - System.Drawing -> [libgdiplus -> Cairo (statically linked into libgdiplus)] Brock "Petit Eric" Sent by: mono-devel-list-bounces at lists.ximian.com 10/31/2007 10:03 AM To "Miguel de Icaza" cc monodevelop-list , mono-devel-list at lists.ximian.com Subject Re: [Mono-dev] MonoSummit: Planning the Sessions Dam Gmail, it doesn't includ the list by defaut when answering 2007/10/31, Petit Eric : > At this time there is a way/method/howto for have a simalar debuging > tool as MS in MD, to folow own code step by step, pas throug and so on > directly in MD IDE/RAD, during execution of the program ? > > 2007/10/31, Miguel de Icaza : > > > > > I would be happy to hear about debugging applications with mono, the state of > > > the debugger, etc. > > > > > > Also, in relation to this, debugging mono itself: when you _really_ think what > > > you observe is not a bug in your program, how to go about checking mono > > > against the C# standard, MS implementation, whatever. > > > > Great suggestion; > > > > We will add a "Debugging with MDB" tutorial, and we probably will have a > > Tips and Trick BOF session. > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071102/f5d81a08/attachment.html From miguel at novell.com Fri Nov 2 11:14:22 2007 From: miguel at novell.com (Miguel de Icaza) Date: Fri, 02 Nov 2007 11:14:22 -0400 Subject: [Mono-dev] VMWear player for Mono development In-Reply-To: <955542.15988.qm@web39609.mail.mud.yahoo.com> References: <955542.15988.qm@web39609.mail.mud.yahoo.com> Message-ID: <1194016462.6475.40.camel@erandi.boston.ximian.com> > The current VMWear player is one of the greatest things Mono has to > boost exploration of Mono. I love it. In fact I love it so much, I > want another! > > What about a VMWear player setup with Mono source and SVN so one could > just fire it up, update the source from svn and start contributing? That is a very nice idea; We are going to update this with a new OpenSUSE 10.3 installation as well. > From Eric.Engler at zcsterling.com Fri Nov 2 11:15:38 2007 From: Eric.Engler at zcsterling.com (Engler, Eric) Date: Fri, 2 Nov 2007 11:15:38 -0400 Subject: [Mono-dev] Mono version numbering In-Reply-To: Message-ID: <6FE5B54E82FD4B4A93CD0D8730986CBBB58E0C@ATLEXCV01.zcs.corp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > If we could just bundle a micro-mono for Windows into our > distribution, we wouldn't have to worry about testing on two > platforms (mono and MS .net) and the installation package > would be smaller and faster. Is mkbundle an option? It can pack the essential libs together in one executable. http://www.mono-project.com/Guide:Running_Mono_Applications Eric NOTICE: The information contained in this electronic mail transmission is intended by the sender for the sole use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. Please do not copy it or use it for any purposes, or disclose its contents to any other person. To do so could violate state and Federal privacy laws. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected. Thank you for your cooperation. -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.2 Charset: us-ascii wsBVAwUBRys/GshfyUs+le7yAQg19gf/UtE+WsODqmFfkF3dnSrPRKqc8zRWVXa/ eDAZuSNsOMkP4JGN9QJ40NneRiQrFy66oP9oBNCcPCBfAi4tR80oPQTJ4Vjsz4ZM LuA0Cl/UEmoAcGTCsTBdihDepk3nX/yxYhs+9c5+FPe4q4ql+cA+WUW6S5M4URSu q9udjs/JoQDKrprQLiFxGS4c7KnWlgMpeN/x8Cpsz3si+3jNK4/ARElCgC+i41xB vJOxp+Yu+86wv7SUz+9ABJeKDG3wbxBlsbc6qE0ZGFtQ5LhGQbOUjyh7WyddYfju GOc/wU7srLd068+TOtCSnngjVh+uuHrE6XXMl7jt7Yz3HJyQYZrPXw== =UkFz -----END PGP SIGNATURE----- From vargaz at gmail.com Fri Nov 2 11:36:02 2007 From: vargaz at gmail.com (Zoltan Varga) Date: Fri, 2 Nov 2007 16:36:02 +0100 Subject: [Mono-dev] [PATCH]: Fix abort when generating sparc V9 code In-Reply-To: <20071101.214941.98469084.davem@davemloft.net> References: <20071101.214941.98469084.davem@davemloft.net> Message-ID: <295e750a0711020836i3bb153d1mff95f187440ff1dc@mail.gmail.com> Hi, This is now in SVN. thanks Zoltan On 11/2/07, David Miller wrote: > > In current SVN the testsuite gives an abort on sparc because the JIT > generates a branch whose relocation cannot fit. > > It's a branch to an exception stub, so the branch is to the end of the > code generation area where the exception handler stubs are placed. > > The V9 branch can only handle signed 19-bit offsets, and in this > case the code area is so big that the displacement to the exception > area is too large to fit into the relocation. > > For these cases we only need the 32-bit icc condition codes. So we > can expand the range of offsets that can be handled by using the > pre-v9 branches in this case. This gives us a signed 22-bit offset to > work with. > > This is not even sub-optimal for v9 chips because v9 chips use a > default prediction of not-taken for pre-v9 branches, and since > exceptions are "exceptional"... > > While working on this patch I noticed a NULL pointer assertion in the > exception handler stub emitter that was after the first dereference of > that pointer, making it useless. > > Please apply, thanks. > > 2007-11-01 David S. Miller > > * mini-sparc.c (EMIT_COND_SYSTEM_EXCEPTION_GENERAL): Even if > sparcv9, use non-v9 branch if using sparc_icc_short. > (mono_arch_emit_exceptions): Move NULL pointer assertion before > first dereference. > > Index: mono/mini/mini-sparc.c > =================================================================== > --- mono/mini/mini-sparc.c (revision 88629) > +++ mono/mini/mini-sparc.c (working copy) > @@ -1387,7 +1387,7 @@ if (ins->flags & MONO_INST_BRLABEL) { \ > #define EMIT_COND_SYSTEM_EXCEPTION_GENERAL(ins,cond,sexc_name,filldelay,icc) do { \ > mono_add_patch_info (cfg, (guint8*)(code) - (cfg)->native_code, \ > MONO_PATCH_INFO_EXC, sexc_name); \ > - if (sparcv9) { \ > + if (sparcv9 && ((icc) != sparc_icc_short)) { \ > sparc_branchp (code, 0, (cond), (icc), 0, 0); \ > } \ > else { \ > @@ -4207,8 +4207,8 @@ mono_arch_emit_exceptions (MonoCompile * > sparc_patch ((guint32*)(cfg->native_code + patch_info->ip.i), code); > > exc_class = mono_class_from_name (mono_defaults.corlib, "System", patch_info->data.name); > - type_idx = exc_class->type_token - MONO_TOKEN_TYPE_DEF; > g_assert (exc_class); > + type_idx = exc_class->type_token - MONO_TOKEN_TYPE_DEF; > throw_ip = patch_info->ip.i; > > /* Find a throw sequence for the same exception class */ > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From apenwarr at gmail.com Fri Nov 2 11:58:44 2007 From: apenwarr at gmail.com (Avery Pennarun) Date: Fri, 2 Nov 2007 11:58:44 -0400 Subject: [Mono-dev] Mono version numbering In-Reply-To: <6FE5B54E82FD4B4A93CD0D8730986CBBB58E0C@ATLEXCV01.zcs.corp> References: <6FE5B54E82FD4B4A93CD0D8730986CBBB58E0C@ATLEXCV01.zcs.corp> Message-ID: <32541b130711020858g57387e2aibfe7235a005bcbca@mail.gmail.com> On 02/11/2007, Engler, Eric wrote: > > If we could just bundle a micro-mono for Windows into our > > distribution, we wouldn't have to worry about testing on two > > platforms (mono and MS .net) and the installation package > > would be smaller and faster. > > Is mkbundle an option? It can pack the essential libs together in one > executable. > > http://www.mono-project.com/Guide:Running_Mono_Applications Thanks to the several people who have mentioned this - there seems to be a trend with mono working better than expected and having features I wanted before I realized that I need them. Now the world just needs some time to find out. :) Have fun, Avery From miguel at novell.com Sat Nov 3 13:42:05 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 03 Nov 2007 13:42:05 -0400 Subject: [Mono-dev] Fwd: [MonoDevelop] Cs-ObexFtp devel In-Reply-To: <84776a970710310816i551cbd85jb31d4b28a191b848@mail.gmail.com> References: <84776a970710300217n23902d42x4e443050751ddd5c@mail.gmail.com> <84776a970710300218v4fd158b9oe6767ff608bef3a8@mail.gmail.com> <84776a970710301125h56614d86o79d9897d68b5261f@mail.gmail.com> <84776a970710301127o5e042dd9i4e61851c3a510893@mail.gmail.com> <84776a970710310609w11058b5dpfa5755e6f645f40b@mail.gmail.com> <1193843406.4429.15.camel@portador.site> <84776a970710310814q68575a62r419b3f9f2f9a2409@mail.gmail.com> <84776a970710310816i551cbd85jb31d4b28a191b848@mail.gmail.com> Message-ID: <1194111725.4233.22.camel@erandi.boston.ximian.com> Hello, > thank's luis i do it, but i already asked to me the question, because > it's more to add it in a MonoDevelop package solution to be sur the > end user have the corect version of mono RT, as y say in my first > post, if you take exemple of my prog Cs-obexftp, with the curent > official release of Mono RT it doesn't work for few bug or not > implemented function i already submit to Mono Bug, so each time a end > user download it it put it to trash, the script i write should be > really great if it was include in the Solution packager of MD. > But oki i post it too at Mono list, the more can do the less The Mono API that your program uses will be available in the upcoming Mono 1.2.6 (it was implemented a couple of months ago, but it did not make it to the 1.2.5 release). Miguel From miguel at ximian.com Sat Nov 3 14:59:19 2007 From: miguel at ximian.com (Miguel de Icaza) Date: Sat, 03 Nov 2007 14:59:19 -0400 Subject: [Mono-dev] Mono Bugs Days. Message-ID: <1194116359.4233.42.camel@erandi.boston.ximian.com> On Monday and Tuesday (November 5th and 6th) we want to spend some time triaging, prioritizing and applying easy fixes to Mono from Bugzilla. We will be on irc.gnome.org on the channel #monobugday on Monday and Tuesday going over various Mono components. Our entry point is: www.mono-project.com/Bugs There is a lot of low-hanging fruit that could be easily fixed in Mono, bugs that are invalid, bugs that are missing information, bugs that needs owners, bugs that need confirmation and patches that have been waiting on the bug tracking system to be applied. I have zero experience running a bug day and am not sure quite how to run this on Monday, if you have some experience, feel free to drop by, or send your comments. From olivier.duff at gmail.com Sat Nov 3 16:29:53 2007 From: olivier.duff at gmail.com (olivier dufour) Date: Sat, 3 Nov 2007 21:29:53 +0100 Subject: [Mono-dev] JScript in moonlight Message-ID: Hi all, I just mail the list to report a bit about JScript compiler for moonlight: So, I have switch to Linux and done my first commit from Linux today. yeahaaa!! It has taken time to find and know all tools under Linux ( monodevelop, esvn, bash, ...). I have commit the monodevelop solution file in olive/Class/Microsoft.JScript.Compiler/Runtime. I have used IronRuby Microsoft.Scripting.dll to synchronize with the last development of Microsoft. So, It will be faster and easier to fit to new MS.JScript structure when they will release a new version of silverlight . JavaScript compiler is still in development and if anyone want to help on it it is welcome ;) Cheers, Olivier Dufour -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071103/aac204a0/attachment.html From miguel at novell.com Sat Nov 3 18:17:40 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 03 Nov 2007 18:17:40 -0400 Subject: [Mono-dev] Win64 Patch II In-Reply-To: <17c2d80b0710310620m40dbbe71t7abaf0ad0e49888c@mail.gmail.com> References: <17c2d80b0710310620m40dbbe71t7abaf0ad0e49888c@mail.gmail.com> Message-ID: <1194128260.4233.54.camel@erandi.boston.ximian.com> The eglib changes are OK to go into SVN. From davem at davemloft.net Sat Nov 3 18:46:27 2007 From: davem at davemloft.net (David Miller) Date: Sat, 03 Nov 2007 15:46:27 -0700 (PDT) Subject: [Mono-dev] [PATCH]: Fix abort when generating sparc V9 code In-Reply-To: <295e750a0711020836i3bb153d1mff95f187440ff1dc@mail.gmail.com> References: <20071101.214941.98469084.davem@davemloft.net> <295e750a0711020836i3bb153d1mff95f187440ff1dc@mail.gmail.com> Message-ID: <20071103.154627.261766138.davem@davemloft.net> From: "Zoltan Varga" Date: Fri, 2 Nov 2007 16:36:02 +0100 > This is now in SVN. Thanks Zoltan. I have some MONO Sparc changes I've been working on to improve code generation. For example, I've copied the idea from the PPC et al. ports to have a lowering pass right before register allocation to improve handling of out-of-range immediate fields so that the code emitter can be more simple and only consider the cases where the immediate fields fit. And as a result the sparc JIT now supports indexing loads and stores. This work is done and the testsuite has no regressions for sparc 32-bit, I'll be testing 64-bit soon. I'm also going to add more cases to the peephole pass on Sparc. For example, there are a lot of simple things not caught like transforming: sethi %hi(foo), %reg2 ! OP_ICONST or %reg2, %lo(foo), %reg2 ld [%reg2 + 0], %dest_reg ! OP_LOAD_MEMBASE into: sethi %hi(foo), %reg2 ! OP_ICONST ld [%reg2 + %lo(foo)], %dest_reg ! OP_LOAD_MEMBASE This will require first lowering the "sethi + or" into seperate operations (OP_ICONST, OP_OR_IMM) and then looking for this "OP_OR_IMM, OP_{LOAD,STORE}_*" pattern. OP_LOADU4_MEM could be decomposed similarly. Next, I have a design in my head and plans for branch delay slot filling. At the very least it should be able to fill branch delay slots using instructions from the same basic block. Ie. simple cases like transforming: add %reg, 1, %reg bcond label nop into: bcond label add %reg, 1, %reg For example. This lack of delay slot filling (and the fact that the branches are all marked as "annuling" which pessimizes performance on all pre-Niagara UltraSparc chips) kills us in things like bench.exe on Sparc currently. Also, I cooked up a simple Sparc disassembler which I've integrated into mono-sparc.c that I'm using to make this work less back-breaking than it currently is. In an ideal world, MONO could link to libopcodes from binutils so that we wouldn't have to do that ugly "dump into asm file, run objdump on the thing, catch the output" hack it currently does. But I don't see that happening any time soon. :-) With either a libopcodes or by hand assembler, we could stylize the assembler output, annotating it with MONO CIL opcodes and basic block information in order to ease the debugging burdon. Perhaps for the time being we can have some standard interfaces and some $(cpu)-dis.c source files? What the current code can do is try to call the new disassembler interface, and if it returns an error, it continues on to do the "invoke objdump on foo.s file" thing. Anyways, just to let folks know what work I have coming down the pipeline in the not too distant future. Take care. From davem at davemloft.net Sat Nov 3 19:15:20 2007 From: davem at davemloft.net (David Miller) Date: Sat, 03 Nov 2007 16:15:20 -0700 (PDT) Subject: [Mono-dev] [PATCH]: Use sparc 'sethi' in more cases. Message-ID: <20071103.161520.70274733.davem@davemloft.net> The Sparc code generator is too strict in it's tests for when just a 'sethi' can be used to load a constant. 'sethi' loads the top 22-bits of a 32-bit register with the given constant value. This patch corrects the test, so that we use 1 instruction instead of 2 more often. 2007-11-03 David S. Miller * sparc/sparc-codegen.h (sparc_set32, sparc_set): A plain sethi can be used if the constant value only has the top 22 bits set. Index: mono/arch/sparc/sparc-codegen.h =================================================================== --- mono/arch/sparc/sparc-codegen.h (revision 88629) +++ mono/arch/sparc/sparc-codegen.h (working copy) @@ -855,7 +855,7 @@ typedef struct { do { \ if ((val) == 0) \ sparc_clr_reg((ins),(reg)); \ - else if (((guint32)(val) & 0x1fff) == 0) \ + else if (((guint32)(val) & 0x3ff) == 0) \ sparc_sethi((ins),(guint32)(val),(reg)); \ else if (((gint32)(val) >= -4096) && ((gint32)(val) <= 4095)) \ sparc_or_imm((ins),FALSE,sparc_g0,(gint32)(val),(reg)); \ @@ -883,7 +883,8 @@ typedef struct { else if ((val >= -4096) && ((val) <= 4095)) \ sparc_or_imm((ins),FALSE,sparc_g0,bottom_word,(reg)); \ else if ((val >= 0) && (val <= 4294967295L)) { \ - sparc_sethi((ins),bottom_word,(reg)); \ + sparc_sethi((ins),bottom_word,(reg)); \ + if (bottom_word & 0x3ff) \ sparc_or_imm((ins),FALSE,(reg),bottom_word&0x3ff,(reg)); \ } \ else if ((val >= 0) && (val <= (1L << 44) - 1)) { \ @@ -913,7 +914,7 @@ typedef struct { do { \ if ((val) == 0) \ sparc_clr_reg((ins),(reg)); \ - else if (((guint32)(val) & 0x1fff) == 0) \ + else if (((guint32)(val) & 0x3ff) == 0) \ sparc_sethi((ins),(guint32)(val),(reg)); \ else if (((gint32)(val) >= -4096) && ((gint32)(val) <= 4095)) \ sparc_or_imm((ins),FALSE,sparc_g0,(gint32)(val),(reg)); \ From davem at davemloft.net Sat Nov 3 19:21:16 2007 From: davem at davemloft.net (David Miller) Date: Sat, 03 Nov 2007 16:21:16 -0700 (PDT) Subject: [Mono-dev] [PATCH]: Improve sparc I-cache flushing under Linux. Message-ID: <20071103.162116.117196277.davem@davemloft.net> On every UltraSPARC chip, it is sufficient to only flush every 32-byte cache line. As a future enhancement, if Niagara cpus are detected we can only perform one flush instruction. On Niagara the flush address is completely ignored and the flush is only needed to synchronize the cpu pipeline with previous stores. I left the Solaris code as it is, calling sync_instruction_memory(). However, disassembling a test program shows that Solaris does not optimize it properly and flushes every 8 bytes like the old code here did. I think it would be safe to have the Solaris case use the same code as Linux so that both sides would get the performance improvement. 2007-11-03 David S. Miller * mini-sparc.c (mono_arch_flush_icache): Make more efficient under Linux. We only need to flush every 32-byte cache line. Index: mono/mini/mini-sparc.c =================================================================== --- mono/mini/mini-sparc.c (revision 88629) +++ mono/mini/mini-sparc.c (working copy) @@ -293,18 +293,28 @@ mono_arch_flush_icache (guint8 *code, gi /* Hopefully this is optimized based on the actual CPU */ sync_instruction_memory (code, size); #else - guint64 *p = (guint64*)code; - guint64 *end = (guint64*)(code + ((size + 8) /8)); - - /* - * FIXME: Flushing code in dword chunks in _slow_. + gulong start = (gulong) code; + gulong end = start + size; + gulong align; + + /* Sparcv9 chips only need flushes on 32 byte + * cacheline boundaries. + * + * Sparcv8 needs a flush every 8 bytes. */ - while (p < end) + align = (sparcv9 ? 32 : 8); + + start &= ~(align - 1); + end = (end + (align - 1)) & ~(align - 1); + + while (start < end) { #ifdef __GNUC__ - __asm__ __volatile__ ("iflush %0"::"r"(p++)); + __asm__ __volatile__ ("iflush %0"::"r"(start)); #else - flushi (p ++); + flushi (start); #endif + start += align; + } #endif } From miguel at ximian.com Sun Nov 4 00:18:43 2007 From: miguel at ximian.com (Miguel de Icaza) Date: Sun, 04 Nov 2007 00:18:43 -0400 Subject: [Mono-dev] Sample program templates, augmenting programs. Message-ID: <1194149923.4233.99.camel@erandi.boston.ximian.com> Hello, I have been thinking on ways of reducing the learning curve for those using Mono in Linux. IDEs typically have features to create projects based on a template, so you can get a console project, a web project, a GUI project and so on setup for you. But if you do not have an IDE, most of the time you have to roll these things on your own. For console applications that is not much of a problem, and it is not much of a problem even for simple desktop applications; But complex applications or applications that depend on special files are not as easy to type from memory. We recently introduced a new command "mconfig" that can help managing a Web.config file (this is used in ASP.NET sites). This allows for example an existing ASP.NET application to gain AJAX functionality by running: $ mconfig af -t=web AJAX This creates a Web.config (or modifies an existing one) to add the proper "magic" to the file to support AJAX.NET. It is a pluggable system so we can add more features and more targets so developers can add/remove features to their software as they go. But it seems like there is room for growth here, we could take things a few steps ahead and have a template system that would allow developers to create templates and lookup new templates from a centralized repository from the command line. This is similar in spirit to Ruby on Rails where you have commands that can setup your project, update pieces of your project and so on. We could have an mtemplate command to create all kinds of different project templates: mtemplate -kind=web:asp:simple ConferenceRegistration mtemplate -lang:ironpython -kind:gtksharp PointOfSale I was thinking about this today as I realized that we do not really have templates for Silverlight applications today on Mono/MonoDevelop. Which is not terrible, but it would be nice if I could quickly create projects without having to update my IDE to get new templates for particular apps. Miguel From andreas.faerber at web.de Sun Nov 4 03:26:12 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 4 Nov 2007 09:26:12 +0100 Subject: [Mono-dev] Win64 Patch II In-Reply-To: <1194128260.4233.54.camel@erandi.boston.ximian.com> References: <17c2d80b0710310620m40dbbe71t7abaf0ad0e49888c@mail.gmail.com> <1194128260.4233.54.camel@erandi.boston.ximian.com> Message-ID: Am 03.11.2007 um 23:17 schrieb Miguel de Icaza: > The eglib changes are OK to go into SVN. Looks okay to me, too. Do you have SVN access yourself, Jonathan? It was the second okay by Miguel already. Andreas From davem at davemloft.net Sun Nov 4 03:34:28 2007 From: davem at davemloft.net (David Miller) Date: Sun, 04 Nov 2007 01:34:28 -0700 (PDT) Subject: [Mono-dev] thread race during code generation Message-ID: <20071104.013428.267396613.davem@davemloft.net> Sometimes a thread abort is missed while running the nunit tests, specifically when running the following under mcs/class/corlib/: MONO_REGISTRY_PATH="/home/davem/.mono/registry" MONO_PATH="../../class/lib/default::$MONO_PATH" /home/davem/src/MONO/mono/runtime/mono-wrapper --debug ../../class/lib/default/nunit-console.exe /exclude:NotWorking,ValueAdd,CAS,InetAccess /output:TestResult-default.log /xml:TestResult-default.xml corlib_test_default.dll Here is a trace of what happens, I think the troublesome case that triggers this are the cases exercising class C2Test in mcs/class/corlib/Test/System.Threading/ThreadTest.cs After all the tests run the threading layer spits out an error because it cannot abort a thread referencing the domain-corlib_test_default.dll domain: -------------------- Tests run: 6368, Failures: 14, Not run: 37, Time: 235.439826 seconds ABORTING THREAD 4123343760 BECAUSE IT REFERENCES DOMAIN domain-corlib_test_default.dll. DEBUG: Sending signal 35 to TID 4123343760 DEBUG: pthread_kill() returns 0 DEBUG: TID 4123343760 receiving signal. DEBUG: IP(0xf7e2365c) ji=(nil) ABORTING THREAD 4117756816 BECAUSE IT REFERENCES DOMAIN domain-corlib_test_default.dll. DEBUG: exc((nil)) Waiting for 2 TIDs ABORTING THREAD 4117756816 BECAUSE IT REFERENCES DOMAIN domain-corlib_test_default.dll. Waiting for 1 TIDs ABORTING THREAD 4117756816 BECAUSE IT REFERENCES DOMAIN domain-corlib_test_default.dll. Waiting for 1 TIDs ... ** (../../class/lib/default/nunit-console.exe:30276): WARNING **: Aborting of threads in domain domain-corlib_test_default.dll timed out. -------------------- Earlier in the run we initially tried to kill this seemingly stuc thread 4117756816: -------------------- DEBUG: Sending signal 35 to TID 4117756816 DEBUG: pthread_kill() returns 0 DEBUG: TID 4117756816 receiving signal. DEBUG: IP(0x13b234) ji=(nil) DEBUG: exc((nil)) -------------------- That IP program counter is in the JIT optimizer, specifically in mono_aliasing_get_affected_variables_for_inst_traversing_code() I am pretty sure it is compiling C2Test.TestMethod() and then jumping to it. Since the signal arrives while the thread is not executing the managed code yet, the signal is basically ignored. At this point the event is lost because the thread state already has the ThreadState_AbortRequested bit set, therefore subsequent abort attempts will skip trying to resend the signal. So, it will loop there forever in C2Test.TestMethod(). With this information, I hope it should be pretty easy for someone to fix this bug. :-) From arinai at mainsoft.com Sun Nov 4 06:51:36 2007 From: arinai at mainsoft.com (Arina Itkes) Date: Sun, 4 Nov 2007 03:51:36 -0800 Subject: [Mono-dev] [PATCH] New tests for Regular expressions In-Reply-To: <20071101214859.55BA52300BB@adicia.telenet-ops.be> Message-ID: Hi Gert, I looked the test case 44 and saw that I have mistaken in the expected result. Now it fixed and committed with revision 88816. But this test is not passing on Mono both in previous version and now. (Now it is passing on MS) Also I saw that you added the Category "NotDotNet" for some not working tests in the file RegexMatchTests.cs. I checked they all are passing on MS. Can you check it again? Thank you. Arina. ________________________________ From: Gert Driesen [mailto:gert.driesen at telenet.be] Sent: Thursday, November 01, 2007 11:49 PM To: Arina Itkes; mono-devel-list at lists.ximian.com Subject: RE: [Mono-dev] [PATCH] New tests for Regular expressions Arina, Test case 44 in RegexResultTests is failing on MS (but passing on Mono). Can you look into this? Thanks, Gert ________________________________ From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Arina Itkes Sent: zondag 28 oktober 2007 19:28 To: mono-devel-list at lists.ximian.com Subject: [Mono-dev] [PATCH] New tests for Regular expressions I added new tests for regular expressions. Part of them is not working. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071104/b390361a/attachment.html From sanxiyn at gmail.com Sun Nov 4 08:10:17 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 4 Nov 2007 22:10:17 +0900 Subject: [Mono-dev] Size of Microsoft.Scripting.dll Message-ID: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com> I thought this statistics may be of interest to you. Size of Microsoft.Scripting.dll in IronPython 2.0 Alpha 2, 3, 4, 5, as included in the binary release and compiled by Mono 1.2.5 and Mono SVN r88800. =========== ====== ====== ====== ======= Compiler 2.0a2 2.0a3 2.0a4 2.0a5 Binary 836960 857440 906592 959512 Mono 1.2.5 870400 892928 943104 1004032 Mono r88800 869376 891904 942592 1003008 =========== ====== ====== ====== ======= Some observations can be made. 1. In all cases, its size is less than 1 MB. 2. It is getting bigger every release. Alpha 5 is about 15% bigger than Alpha 2. 3. Binaries compiled by Microsoft compiler is about 4% smaller than those by Mono. 4. Differences between Mono 1.2.5 and SVN (soon to be 1.2.6) are negligible. -- Seo Sanghyeon From marek.safar at seznam.cz Sun Nov 4 09:31:59 2007 From: marek.safar at seznam.cz (Marek Safar) Date: Sun, 04 Nov 2007 14:31:59 +0000 Subject: [Mono-dev] Size of Microsoft.Scripting.dll In-Reply-To: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com> References: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com> Message-ID: <472DD7DF.3060306@seznam.cz> Hello, > I thought this statistics may be of interest to you. > > Size of Microsoft.Scripting.dll in IronPython 2.0 Alpha 2, 3, 4, 5, as > included in the binary release and compiled by Mono 1.2.5 and Mono SVN > r88800. > > =========== ====== ====== ====== ======= > Compiler 2.0a2 2.0a3 2.0a4 2.0a5 > Binary 836960 857440 906592 959512 > Mono 1.2.5 870400 892928 943104 1004032 > Mono r88800 869376 891904 942592 1003008 > =========== ====== ====== ====== ======= > > Some observations can be made. > > 1. In all cases, its size is less than 1 MB. > 2. It is getting bigger every release. Alpha 5 is about 15% bigger than Alpha 2. > 3. Binaries compiled by Microsoft compiler is about 4% smaller than > those by Mono. > 4% is really small difference. Is binary compiled with /o+ switch ? Marek From joncham at gmail.com Sun Nov 4 11:49:57 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Sun, 4 Nov 2007 12:49:57 -0400 Subject: [Mono-dev] Win64 Patch II In-Reply-To: References: <17c2d80b0710310620m40dbbe71t7abaf0ad0e49888c@mail.gmail.com> <1194128260.4233.54.camel@erandi.boston.ximian.com> Message-ID: <17c2d80b0711040849t53d04fb4l8ed7a9b07e0c5ba5@mail.gmail.com> I committed the eglib part. The mono and libgc parts need reviewed/approved. Thanks, Joanthan On 11/4/07, Andreas F?rber wrote: > > > Am 03.11.2007 um 23:17 schrieb Miguel de Icaza: > > > The eglib changes are OK to go into SVN. > > Looks okay to me, too. > > Do you have SVN access yourself, Jonathan? It was the second okay by > Miguel already. > > Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071104/37bbf50b/attachment.html From kornelpal at gmail.com Sun Nov 4 12:41:30 2007 From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=) Date: Sun, 4 Nov 2007 18:41:30 +0100 Subject: [Mono-dev] Win64 Patch II References: <17c2d80b0710310620m40dbbe71t7abaf0ad0e49888c@mail.gmail.com><1194128260.4233.54.camel@erandi.boston.ximian.com> <17c2d80b0711040849t53d04fb4l8ed7a9b07e0c5ba5@mail.gmail.com> Message-ID: <005001c81f09$f0a3ea20$0100a8c0@kornelpal.hu> Hi, g_path_is_absolute should handle both \ and / as path separator. This is handled by glib. Note that paths starting with \\ (double backslash) are rooted UNC paths. This isn't handled by glib either but may cause problems if it's ignored. libgc/include/private/gcconfig.h: +# if defined(__LP64__) || defined(_WIN64) +# define X86_64 +# else +# define I386 +# endif _WIN64 is defined for IA64 as well so I think x64 should not be assumed based on _WIN64. MS VC++ defines _M_IA64 and _M_X64 respectively that I think should be checked in addition to _WIN64. None of the above are critical problems but care should be taken to eliminate future problems. Korn?l ----- Original Message ----- From: "Jonathan Chambers" To: "Andreas F?rber" Cc: "Miguel de Icaza" ; "mono-devel" Sent: Sunday, November 04, 2007 5:49 PM Subject: Re: [Mono-dev] Win64 Patch II I committed the eglib part. The mono and libgc parts need reviewed/approved. Thanks, Joanthan On 11/4/07, Andreas F?rber wrote: > > > Am 03.11.2007 um 23:17 schrieb Miguel de Icaza: > > > The eglib changes are OK to go into SVN. > > Looks okay to me, too. > > Do you have SVN access yourself, Jonathan? It was the second okay by > Miguel already. > > Andreas > -------------------------------------------------------------------------------- > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From sanxiyn at gmail.com Sun Nov 4 18:09:23 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 5 Nov 2007 08:09:23 +0900 Subject: [Mono-dev] Size of Microsoft.Scripting.dll In-Reply-To: <472DD7DF.3060306@seznam.cz> References: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com> <472DD7DF.3060306@seznam.cz> Message-ID: <5b0248170711041509x435b25basaa595e7b3f62ff7a@mail.gmail.com> 2007/11/4, Marek Safar : > 4% is really small difference. Is binary compiled with /o+ switch ? I believe /o is on by default in mcs. -- Seo Sanghyeon From MichaelMattess at rauland.com.au Sun Nov 4 21:41:36 2007 From: MichaelMattess at rauland.com.au (Michael Mattess) Date: Mon, 5 Nov 2007 13:41:36 +1100 Subject: [Mono-dev] Patch for System.IO.Ports.SerialPort ReadLine function Message-ID: <087F05C91CEDCC4EA78E531C6C4E33529BF275@morpheus.Rauland.local> Hi This morning I have put together a little patch for the System.IO.Ports.SerialPort ReadLine function so that it uses the NewLine property value rather than '\n' to identify the end of a line (see bug #321988). Below is my replacement ReadLine() function. I could add some code to more efficiently handle the specific (and common) case where NewLine is a single character. Bus since this is serial coms I doubt that this code will be a performance bottle neck and the general implementation should be ok. Also I noticed that the NewLine property can be assigned an empty string, which throws an exception in MS.Net (see bug #339012). I have tested this function by itself with some standalone unit tests, by removing the call to stream.Read and replacing it with a call to a mocked up read function. -------------------------------------------------------------- public string ReadLine (){ CheckOpen(); List bytes_read = new List(); byte[] buff = new byte[1]; int new_line_offset = 0; while(true) { int n = stream.Read(buff, 0, 1); if(n == -1) { break; } bytes_read.Add(buff[0]); if(bytes_read.Count >= new_line.Length) { bool isNewLine = true; //check if we have read a NewLine string. for(int i = 0; i < new_line.Length; i++) { if(bytes_read[new_line_offset + i] != new_line[i]) { isNewLine = false; break; } } if(isNewLine) { //Remove the NewLine string from the read line. bytes_read.RemoveRange(new_line_offset, new_line.Length); break; } new_line_offset++; } } Regards, Michael Mattess -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071105/8a565250/attachment.html From MichaelMattess at rauland.com.au Sun Nov 4 23:59:59 2007 From: MichaelMattess at rauland.com.au (Michael Mattess) Date: Mon, 5 Nov 2007 15:59:59 +1100 Subject: [Mono-dev] Patch for System.IO.Ports.SerialPort ReadLine function Message-ID: <087F05C91CEDCC4EA78E531C6C4E33529BF2A7@morpheus.Rauland.local> Hi In my last email I managed to not copy-paste the last line of the function so there is the complete function: public string ReadLine (){ CheckOpen(); List bytes_read = new List(); byte[] buff = new byte[1]; int new_line_offset = 0; while(true) { //int n = stream.Read(buff, 0, 1); int n = FackeRead(buff); if(n == -1) { break; } bytes_read.Add(buff[0]); if(bytes_read.Count >= new_line.Length) { bool isNewLine = true; //check if we have read a NewLine string. for(int i = 0; i < new_line.Length; i++) { if(bytes_read[new_line_offset + i] != new_line[i]) { isNewLine = false; break; } } if(isNewLine) { //Remove the NewLine string from the read line. bytes_read.RemoveRange(new_line_offset, new_line.Length); break; } new_line_offset++; } } return new String(encoding.GetChars(bytes_read.ToArray())); } Regards, Michael Mattess -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071105/7b6d8af9/attachment.html From marek.safar at seznam.cz Mon Nov 5 04:02:02 2007 From: marek.safar at seznam.cz (Marek Safar) Date: Mon, 05 Nov 2007 09:02:02 +0000 Subject: [Mono-dev] Size of Microsoft.Scripting.dll In-Reply-To: <5b0248170711041509x435b25basaa595e7b3f62ff7a@mail.gmail.com> References: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com> <472DD7DF.3060306@seznam.cz> <5b0248170711041509x435b25basaa595e7b3f62ff7a@mail.gmail.com> Message-ID: <472EDC0A.1000007@seznam.cz> Hello, > 2007/11/4, Marek Safar : > >> 4% is really small difference. Is binary compiled with /o+ switch ? >> > > I believe /o is on by default in mcs. > Yes, it is but not for csc. Marek From kornelpal at gmail.com Mon Nov 5 06:16:28 2007 From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=) Date: Mon, 5 Nov 2007 12:16:28 +0100 Subject: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows Message-ID: <003801c81f9d$61a774b0$0100a8c0@kornelpal.hu> Hi, HAVE_GETPROCESSID depends on WINVER that is not set, so HAVE_GETPROCESSID is never defined on Windows. This means that GetProcessId never gets called on Windows and process ID is allways 0. This patch adds run-time detection for GetProcessId on Windows. Note that only Windows XP SP1 and above have GetProcessId API while Windows 2000 and above have deprecated NtQueryInformationProcess API that can be used for the same purpose. Please review and approve this patch. Korn?l -------------- next part -------------- A non-text attachment was scrubbed... Name: win_pid.diff Type: application/octet-stream Size: 3285 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071105/ba316c3a/attachment.obj From robertj at gmx.net Mon Nov 5 07:03:54 2007 From: robertj at gmx.net (Robert Jordan) Date: Mon, 05 Nov 2007 13:03:54 +0100 Subject: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows In-Reply-To: <003801c81f9d$61a774b0$0100a8c0@kornelpal.hu> References: <003801c81f9d$61a774b0$0100a8c0@kornelpal.hu> Message-ID: Hi Korn?l, Korn?l P?l wrote: > HAVE_GETPROCESSID depends on WINVER that is not set, so > HAVE_GETPROCESSID is > never defined on Windows. This means that GetProcessId never gets called on > Windows and process ID is allways 0. > > This patch adds run-time detection for GetProcessId on Windows. > > Note that only Windows XP SP1 and above have GetProcessId API while Windows > 2000 and above have deprecated NtQueryInformationProcess API that can be > used for the same purpose. > > Please review and approve this patch. it's not acceptable to depend on the DDK headers. I wonder why do you need them in the first place, since the required defines are also provided by SDK's winternl.h. Robert From kornelpal at gmail.com Mon Nov 5 07:24:37 2007 From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=) Date: Mon, 5 Nov 2007 13:24:37 +0100 Subject: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows References: <003801c81f9d$61a774b0$0100a8c0@kornelpal.hu> Message-ID: <001301c81fa6$d5cea120$0100a8c0@kornelpal.hu> Hi, I intalled the latest cygwin available and it has no winternl.h (or any equivalent header). On the other hand it has the DDK headers bundled. A possible solution is to use winternl.h with MS VC++ and the DDK headers with cygwin. What about that? Korn?l ----- Original Message ----- From: "Robert Jordan" To: Sent: Monday, November 05, 2007 1:03 PM Subject: Re: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows Hi Korn?l, Korn?l P?l wrote: > HAVE_GETPROCESSID depends on WINVER that is not set, so > HAVE_GETPROCESSID is > never defined on Windows. This means that GetProcessId never gets called > on > Windows and process ID is allways 0. > > This patch adds run-time detection for GetProcessId on Windows. > > Note that only Windows XP SP1 and above have GetProcessId API while > Windows > 2000 and above have deprecated NtQueryInformationProcess API that can be > used for the same purpose. > > Please review and approve this patch. it's not acceptable to depend on the DDK headers. I wonder why do you need them in the first place, since the required defines are also provided by SDK's winternl.h. Robert _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From pablosantosluac at terra.es Mon Nov 5 07:59:58 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Mon, 5 Nov 2007 13:59:58 +0100 Subject: [Mono-dev] Mono Bugs Days. References: <1194116359.4233.42.camel@erandi.boston.ximian.com> Message-ID: <0fe801c81fab$c5947a50$d301a8c0@beardtongue> Hi there! I'd like to know whether bug 82550 (fixed on SVN changeset 84714) will be integrated into mono 1.2.6. AFAIK it is still wrong in latest 1.2.5 It is a compiler problem so it would be nice to get it in the next one. pablo ----- Original Message ----- From: "Miguel de Icaza" To: "mono-devel-list" Sent: Saturday, November 03, 2007 7:59 PM Subject: [Mono-dev] Mono Bugs Days. > On Monday and Tuesday (November 5th and 6th) we want to > spend some time triaging, prioritizing and applying easy fixes > to Mono from Bugzilla. > > We will be on irc.gnome.org on the channel #monobugday on > Monday and Tuesday going over various Mono components. > > Our entry point is: > > www.mono-project.com/Bugs > > There is a lot of low-hanging fruit that could be easily > fixed in Mono, bugs that are invalid, bugs that are missing > information, bugs that needs owners, bugs that need > confirmation and patches that have been waiting on the bug > tracking system to be applied. > > I have zero experience running a bug day and am not sure > quite how to run this on Monday, if you have some experience, > feel free to drop by, or send your comments. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From robertj at gmx.net Mon Nov 5 08:03:48 2007 From: robertj at gmx.net (Robert Jordan) Date: Mon, 05 Nov 2007 14:03:48 +0100 Subject: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows In-Reply-To: <001301c81fa6$d5cea120$0100a8c0@kornelpal.hu> References: <003801c81f9d$61a774b0$0100a8c0@kornelpal.hu> <001301c81fa6$d5cea120$0100a8c0@kornelpal.hu> Message-ID: Hi Korn?l, Korn?l P?l wrote: > Hi, > > I intalled the latest cygwin available and it has no winternl.h (or any > equivalent header). On the other hand it has the DDK headers bundled. > > A possible solution is to use winternl.h with MS VC++ and the DDK headers > with cygwin. What about that? this would be OK. Robert > > Korn?l > > ----- Original Message ----- > From: "Robert Jordan" > To: > Sent: Monday, November 05, 2007 1:03 PM > Subject: Re: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows > > > Hi Korn?l, > > Korn?l P?l wrote: >> HAVE_GETPROCESSID depends on WINVER that is not set, so >> HAVE_GETPROCESSID is >> never defined on Windows. This means that GetProcessId never gets called >> on >> Windows and process ID is allways 0. >> >> This patch adds run-time detection for GetProcessId on Windows. >> >> Note that only Windows XP SP1 and above have GetProcessId API while >> Windows >> 2000 and above have deprecated NtQueryInformationProcess API that can be >> used for the same purpose. >> >> Please review and approve this patch. > > it's not acceptable to depend on the DDK headers. I wonder > why do you need them in the first place, since the required > defines are also provided by SDK's winternl.h. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From atsushi at ximian.com Mon Nov 5 08:18:02 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Mon, 05 Nov 2007 22:18:02 +0900 Subject: [Mono-dev] Mono Bugs Days. In-Reply-To: <0fe801c81fab$c5947a50$d301a8c0@beardtongue> References: <1194116359.4233.42.camel@erandi.boston.ximian.com> <0fe801c81fab$c5947a50$d301a8c0@beardtongue> Message-ID: <472F180A.3040405@ximian.com> 1.2.6 is not branched yet, so it will be included in newer versions. In general *please* post your individual bug stuff not under things like this thread (or branching announcement etc.) but on each bug report page (bugzilla) so that others do not have to be bothered by off topic. Thanks. Atsushi Eno pablosantosluac wrote: > Hi there! > > I'd like to know whether bug 82550 (fixed on SVN changeset 84714) will be > integrated into mono 1.2.6. > > AFAIK it is still wrong in latest 1.2.5 > > It is a compiler problem so it would be nice to get it in the next one. > > pablo > > ----- Original Message ----- > From: "Miguel de Icaza" > To: "mono-devel-list" > Sent: Saturday, November 03, 2007 7:59 PM > Subject: [Mono-dev] Mono Bugs Days. > > >> On Monday and Tuesday (November 5th and 6th) we want to >> spend some time triaging, prioritizing and applying easy fixes >> to Mono from Bugzilla. >> >> We will be on irc.gnome.org on the channel #monobugday on >> Monday and Tuesday going over various Mono components. >> >> Our entry point is: >> >> www.mono-project.com/Bugs >> >> There is a lot of low-hanging fruit that could be easily >> fixed in Mono, bugs that are invalid, bugs that are missing >> information, bugs that needs owners, bugs that need >> confirmation and patches that have been waiting on the bug >> tracking system to be applied. >> >> I have zero experience running a bug day and am not sure >> quite how to run this on Monday, if you have some experience, >> feel free to drop by, or send your comments. >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From jb at nurv.fr Mon Nov 5 08:49:51 2007 From: jb at nurv.fr (Jb Evain) Date: Mon, 5 Nov 2007 14:49:51 +0100 Subject: [Mono-dev] Size of Microsoft.Scripting.dll In-Reply-To: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com> References: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com> Message-ID: <69f7d8470711050549h479dbc5fgd597312024ccf008@mail.gmail.com> Hey Seo, On 11/4/07, Sanghyeon Seo wrote: > 3. Binaries compiled by Microsoft compiler is about 4% smaller than > those by Mono. Could you try to compile it with a Mono built with the patch attached to 320009 to see if we can nibble a few more percent? Thanks, -- Jb Evain From buhochileno at gmail.com Mon Nov 5 09:18:01 2007 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Mon, 05 Nov 2007 11:18:01 -0300 Subject: [Mono-dev] dbus-sharp example crash Message-ID: <472F2619.80404@gmail.com> Hi: I try the EchoClient and EchoServer examples to begin my work on dbus-sharp and the program works, but after I recive the message fron the object on the server, the client crash with: Reply: Hello world! Stacktrace: Native stacktrace: /usr/local/bin/mono [0x816a59f] /usr/local/bin/mono [0x807c0b1] [0x4ff440] Debug info from gdb: ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= what can I check??, I use dbus-sharp 0.6 + mono 1.2.5.99 fron anon svn sources. I also have some confusion about this dbus-sharp: Is dbus-sharp and ndesk-dbus the same?, the ndesk-dbus refers to they implementation also as dbus-sharp but have diferent names, assemblyes, etc..if they are diferent, are compatible? Is posible at this state interact with dbus-sharp process and C/dbus process?. In advance, thank you very much. Mauricio. From miguel at novell.com Mon Nov 5 09:47:43 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 05 Nov 2007 09:47:43 -0500 Subject: [Mono-dev] Patch for System.IO.Ports.SerialPort ReadLine function In-Reply-To: <087F05C91CEDCC4EA78E531C6C4E33529BF2A7@morpheus.Rauland.local> References: <087F05C91CEDCC4EA78E531C6C4E33529BF2A7@morpheus.Rauland.local> Message-ID: <1194274063.4935.66.camel@erandi.boston.ximian.com> Hello Michael, As suggested by Alp in the bug (321988), I wrote a state-driven version of the ReadLine routine for serial ports. It should be more efficient. Would you mind testing it? public string ReadLine () { CheckOpen (); List bytes_read = new List(); byte [] buff = new byte [1]; int nl_state = 0; int nl_final = new_line.Length; while (true){ int n = stream.Read (buff, 0, 1); if (n == -1) break; if (buff [0] == new_line [nl_state]){ if (++nl_state == nl_final) break; } else nl_state = 0; bytes_read.Add (buff [0]); } return new String (encoding.GetChars (bytes_read.ToArray ())); } } From mhorsley at vqlive.com Mon Nov 5 09:05:22 2007 From: mhorsley at vqlive.com (Mike Horsley) Date: Mon, 5 Nov 2007 14:05:22 -0000 Subject: [Mono-dev] mono summit session planning Message-ID: <002501c81fb4$e8c24800$4c02a8c0@niad.co.uk> We are working to migrate our native windows based server application to mono running on Linux. We already use mono on Linux (SUSE 10.x) for our monitoring systems. The following would really help accelerate our transition: Debugging - how to debug on Linux with breakpoints using c#? If this requires building mono from source, what compilation flags need setting? Apache - how to configure Apache to run mono? Mono and Ajax.net? Will a .net 2.0 Ajax.net application port execute under mono? I have registered and will be attending the summit (hotels and air tickets booked). Will I get confirmation that my registration has been received? Regards Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071105/283094e1/attachment.html From miguel at novell.com Mon Nov 5 10:06:26 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 05 Nov 2007 10:06:26 -0500 Subject: [Mono-dev] Patch for System.IO.Ports.SerialPort ReadLine function In-Reply-To: <087F05C91CEDCC4EA78E531C6C4E33529BF275@morpheus.Rauland.local> References: <087F05C91CEDCC4EA78E531C6C4E33529BF275@morpheus.Rauland.local> Message-ID: <1194275186.4935.70.camel@erandi.boston.ximian.com> Hello, My ReadLine routine is broken, it did not append data that was only partially part of the ReadLine. While I was fixing it, I noticed that we already have a routine that did this correctly (ReadTo). So am going to just change the code to be: ReadTo (new_line). Miguel. From kornelpal at gmail.com Mon Nov 5 10:07:54 2007 From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=) Date: Mon, 5 Nov 2007 16:07:54 +0100 Subject: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows References: <003801c81f9d$61a774b0$0100a8c0@kornelpal.hu> <001301c81fa6$d5cea120$0100a8c0@kornelpal.hu> Message-ID: <004001c81fbd$a602a3d0$0100a8c0@kornelpal.hu> Hi, An updated version of the patch is attached. Please review this one as well. Korn?l ----- Original Message ----- From: "Robert Jordan" To: Sent: Monday, November 05, 2007 2:03 PM Subject: Re: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for Windows Hi Korn?l, Korn?l P?l wrote: > Hi, > > I intalled the latest cygwin available and it has no winternl.h (or any > equivalent header). On the other hand it has the DDK headers bundled. > > A possible solution is to use winternl.h with MS VC++ and the DDK headers > with cygwin. What about that? this would be OK. Robert > > Korn?l > > ----- Original Message ----- > From: "Robert Jordan" > To: > Sent: Monday, November 05, 2007 1:03 PM > Subject: Re: [Mono-dev] [PATCH] ShellExecuteEx ProcessId support for > Windows > > > Hi Korn?l, > > Korn?l P?l wrote: >> HAVE_GETPROCESSID depends on WINVER that is not set, so >> HAVE_GETPROCESSID is >> never defined on Windows. This means that GetProcessId never gets called >> on >> Windows and process ID is allways 0. >> >> This patch adds run-time detection for GetProcessId on Windows. >> >> Note that only Windows XP SP1 and above have GetProcessId API while >> Windows >> 2000 and above have deprecated NtQueryInformationProcess API that can be >> used for the same purpose. >> >> Please review and approve this patch. > > it's not acceptable to depend on the DDK headers. I wonder > why do you need them in the first place, since the required > defines are also provided by SDK's winternl.h. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: win_pid2.diff Type: application/octet-stream Size: 3478 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071105/347da029/attachment.obj From miguel at novell.com Mon Nov 5 11:02:45 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 05 Nov 2007 11:02:45 -0500 Subject: [Mono-dev] mono summit session planning In-Reply-To: <002501c81fb4$e8c24800$4c02a8c0@niad.co.uk> References: <002501c81fb4$e8c24800$4c02a8c0@niad.co.uk> Message-ID: <1194278565.4935.81.camel@erandi.boston.ximian.com> > Debugging ? how to debug on Linux with breakpoints using c#? We will have a session on this. > Apache ? how to configure Apache to run mono? Ah, this is a new idea. Do you have some specific questions that are not addressed by our mod_mono page on the web site? > Mono and Ajax.net? Will a .net 2.0 Ajax.net application port execute > under mono? Yes, it will. Starting with Mono 1.2.6 (or SVN if you are willing to do that) we support ASP.NET AJAX out of the box. Miguel. > From miguel at novell.com Mon Nov 5 11:09:38 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 05 Nov 2007 11:09:38 -0500 Subject: [Mono-dev] On the debugger. In-Reply-To: <002501c81fb4$e8c24800$4c02a8c0@niad.co.uk> References: <002501c81fb4$e8c24800$4c02a8c0@niad.co.uk> Message-ID: <1194278978.4935.90.camel@erandi.boston.ximian.com> > Debugging ? how to debug on Linux with breakpoints using c#? > > If this requires building mono from source, what compilation flags > need setting? The story of the debugger is a bit complicated. A year ago we decided that we would aim for a "1.0" release that had a number of features. You can see the plan here: http://www.mono-project.com/Debugger#Plan The UI of the debugger was based on casual use of the debugger as we did not really have anyone using it on a day-to-day basis. So we kind of added things as we thought they were needed. The debugger did not have users in part because it was not very stable, so debugging was usually harder with the debugger than without it. So feedback on improving it was slow. Some bits became very hard to support, and we did not even know about them last year when we wrote the plan: support for AppDomains (needed for ASP.NET) and generics turned out to require support in the debugger to have the same method JITed multiple times (in AppDomains, because you can have the same method JITed once per AppDomain and with generics, because each instantiation would be different). This turned out to be a large chunk of work. But there were many other examples of problems that we have ran into in the last year that have slowed down the debugger release. To complicate things, the debugger was never really released in sync with the runtime, which meant that the debugger for the better part of the year only worked if you had SVN releases of Mono. The in the last two months some important work to reduce memory usage in generic cases caused a big restructuring in Mono to happen (all of this will be in 1.2.6). The memory savings are very significant (and very important as apps start to use more and mono generics), but this required a new batch of changes to the debugger. So our goal to have a debugger that worked against 1.2.5 could not really be realized. We are now hoping that the upcoming 1.2.6 will work for the first time with a released debugger and start getting feedback on it. At this point most of the features that we need for what should be considered a 1.0 are done (AppDomains and generic debugging support) so we should be closer to have a working debugger. miguel. From mhorsley at vqlive.com Mon Nov 5 11:34:12 2007 From: mhorsley at vqlive.com (Mike Horsley) Date: Mon, 5 Nov 2007 16:34:12 -0000 Subject: [Mono-dev] mono summit session planning In-Reply-To: <1194278565.4935.81.camel@erandi.boston.ximian.com> Message-ID: <006801c81fc9$b327d9c0$4c02a8c0@niad.co.uk> > Apache - how to configure Apache to run mono? Ah, this is a new idea. Do you have some specific questions that are not addressed by our mod_mono page on the web site? >> The issue we face is being time-challenged. I haven't tried the notes on Apache because I've read up on Apache and have become a little daunted by the prospect. What I want to avoid is loosing many hours struggling over this. If it was part of a session, we could run through it and probably have it covered in 10 minutes. As I see it, the one of the key values of attending the summit is to accelerate our transition to Linux/mono and reduce the risk of transition. If I could walk away on Friday evening with all the knowledge to enable that, it would be an excellent return on the 3 days. Another related Apache issue is security/reliability. What should we be considering when moving our app from IIS to Apache? Mike -----Original Message----- From: Miguel de Icaza [mailto:miguel at novell.com] Sent: 05 November 2007 16:03 To: Mike Horsley Cc: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] mono summit session planning > Debugging - how to debug on Linux with breakpoints using c#? We will have a session on this. > Apache - how to configure Apache to run mono? Ah, this is a new idea. Do you have some specific questions that are not addressed by our mod_mono page on the web site? > Mono and Ajax.net? Will a .net 2.0 Ajax.net application port execute > under mono? Yes, it will. Starting with Mono 1.2.6 (or SVN if you are willing to do that) we support ASP.NET AJAX out of the box. Miguel. > From jnmiller at cryptofreak.org Mon Nov 5 14:52:16 2007 From: jnmiller at cryptofreak.org (Jay Miller) Date: Mon, 5 Nov 2007 12:52:16 -0700 Subject: [Mono-dev] mod_mono and supplementary groups Message-ID: <33f0a7e60711051152v74fede9ei2b9986dc285561b@mail.gmail.com> I'm confused about how mod_mono works with supplementary groups. I have Apache running as apache.apache, with the apache user a member of the 'safe' group: $ groups apache apache : apache safe I also have a directory with 'safe' ownership: $ ls -dl /var/log/safe drwxrwxr-x 2 root safe 4.0K Nov 5 12:04 /var/log/safe The following PHP script is able to write to that directory: However, the following ASP script is not: <%@ Page Language="C#" Debug="true" %> <% using (System.IO.File.CreateText("/var/log/safe/arr.asp")) { } %> Interestingly, these two scripts return different values when they call getgroups(). The PHP script "correctly" returns the apache and safe groups. The ASP script returns apache for its effective uid/gid, but getgroups() returns groups 0,1,2,3,4,6,10 - all of *root's* supplementary groups! Hopefully someone can provide some quick insight to my problem here and, ideally, a workaround - thank you in advance for your help! -- Jay Miller PGP Fingerprint | 5f7adbbe bfc60727 96dca94c 616d5080 09e3e846 From contact at i-nz.net Mon Nov 5 18:01:49 2007 From: contact at i-nz.net (Ivan N. Zlatev) Date: Mon, 5 Nov 2007 23:01:49 +0000 Subject: [Mono-dev] 1.2.6 Release Notes Message-ID: <3db1ec7f0711051501h604ef668xc1791d2e4e497e98@mail.gmail.com> My notes as follows. System.Windows.Forms * SplitContainer now supports FixedPanel layouting. System.Design Initial implementation of the .Net 1.1 and .Net 2.0 Design-Time framework. Includes: * Hosting: DesignSurface, DesignSurfaceManager, etc. * CodeDom Serialization/Deserialization: CodeDomSerializer, CodeDomSerializerBase, DesignerSerializationManager, etc * Core WinForms Designers Stack: ComponentDesigner, ControlDesigner, ScrollableControlDesigner, ParentControlDesigner, DocumentDesigner, etc. P.S: I am starting a new thread because the original got polluted. -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy." From MichaelMattess at rauland.com.au Mon Nov 5 20:56:55 2007 From: MichaelMattess at rauland.com.au (Michael Mattess) Date: Tue, 6 Nov 2007 12:56:55 +1100 Subject: [Mono-dev] Patch for System.IO.Ports.SerialPort ReadLinefunction References: <087F05C91CEDCC4EA78E531C6C4E33529BF275@morpheus.Rauland.local> <1194275186.4935.70.camel@erandi.boston.ximian.com> Message-ID: <087F05C91CEDCC4EA78E531C6C4E33526BF6DA@morpheus.Rauland.local> Hello Miguel, Yes using the ReadTo function does make the most sense as it is a special case of the operation. I had a look at the ReadTo function and I think it is broken. It assumes that it is in the initial state (IE current is 0) when it encounters the beginning of the string it is reading to. So if we are reading to "ababZ" and the input is "abababZfoo" it will read past the "ababZ". It was because of this that I put the 'state-driven' approach into the too hard / too complex basket when I wrote my initial function. But thinking about it further the ReadTo function could be extended to keep multiple states (ie a list of 'current' offsets). One for each time a potential beginning of the string we are looking for is encountered. I have attached a file with such an extended ReadTo function. Let me know your thought. Regards Michael ________________________________ From: Miguel de Icaza [mailto:miguel at novell.com] Sent: Tue 06.11.2007 02:06 To: Michael Mattess Cc: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] Patch for System.IO.Ports.SerialPort ReadLinefunction Hello, My ReadLine routine is broken, it did not append data that was only partially part of the ReadLine. While I was fixing it, I noticed that we already have a routine that did this correctly (ReadTo). So am going to just change the code to be: ReadTo (new_line). Miguel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/b8e46c4f/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ReadToFunction.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/b8e46c4f/attachment.txt From sloncho at gmail.com Mon Nov 5 21:18:00 2007 From: sloncho at gmail.com (Sunny) Date: Mon, 5 Nov 2007 20:18:00 -0600 Subject: [Mono-dev] Bug in System.Net.ServicePointManager. The runtime does not honor DefaultConnectionLimit. Message-ID: The mono runtime does not honor DefaultConnectionLimit, nor the machine.config file setting "maxconnections". It always open only 2 simultaneous connections to a host. Detailed explanations with test code are posted in the bug report: Cheers -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap. From psmaas at opera.com Tue Nov 6 03:17:30 2007 From: psmaas at opera.com (Patricia Aas) Date: Tue, 06 Nov 2007 09:17:30 +0100 Subject: [Mono-dev] Moonlight in Opera on UNIX Message-ID: Hi, I work on plugins on UNIX in Opera, and I've been trying to compile up Moonlight to see if it has any issues in Opera, but it is not easy - so if someone could give me some tips I'd greatly appreciate it :) I'm on Ubunty Feisty if that helps. Patricia -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From schoendorfer.m at gmail.com Tue Nov 6 03:45:44 2007 From: schoendorfer.m at gmail.com (=?ISO-8859-1?Q?Michael_Sch=F6ndorfer?=) Date: Tue, 6 Nov 2007 09:45:44 +0100 Subject: [Mono-dev] Moonlight in Opera on UNIX In-Reply-To: References: Message-ID: <9af7f65c0711060045v39fa1ef5j45d1471ba7152f13@mail.gmail.com> Hi, some time ago i started a Thread on the mono-olive group because I had troubles installing Moonlight on Ubuntu 7.04, too. ( http://groups.google.com/group/mono-olive/browse_thread/thread/a8a35fa2485e362b ) I got this howto, which worked fine for me: http://groups.google.com/group/mono-olive/msg/34a446ebd5c54d8e regards, Michael 2007/11/6, Patricia Aas : > > Hi, > > I work on plugins on UNIX in Opera, and I've been trying to compile up > Moonlight to see if it has any issues in Opera, but it is not easy - so if > someone could give me some tips I'd greatly appreciate it :) I'm on Ubunty > Feisty if that helps. > > Patricia > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/69d57afa/attachment.html From psmaas at opera.com Tue Nov 6 04:23:11 2007 From: psmaas at opera.com (Patricia Aas) Date: Tue, 06 Nov 2007 10:23:11 +0100 Subject: [Mono-dev] Moonlight in Opera on UNIX In-Reply-To: <9af7f65c0711060045v39fa1ef5j45d1471ba7152f13@mail.gmail.com> References: <9af7f65c0711060045v39fa1ef5j45d1471ba7152f13@mail.gmail.com> Message-ID: Thank you Michael, I'll give that a whirl then :) Patricia On Tue, 06 Nov 2007 09:45:44 +0100, Michael Sch?ndorfer wrote: > Hi, > > some time ago i started a Thread on the mono-olive group because I had > troubles installing Moonlight on Ubuntu 7.04, too. ( > http://groups.google.com/group/mono-olive/browse_thread/thread/a8a35fa2485e362b > ) > > I got this howto, which worked fine for me: > http://groups.google.com/group/mono-olive/msg/34a446ebd5c54d8e > > > regards, > Michael > > 2007/11/6, Patricia Aas : >> >> Hi, >> >> I work on plugins on UNIX in Opera, and I've been trying to compile up >> Moonlight to see if it has any issues in Opera, but it is not easy - so >> if >> someone could give me some tips I'd greatly appreciate it :) I'm on >> Ubunty >> Feisty if that helps. >> >> Patricia >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From adar.wesley at gmail.com Tue Nov 6 04:42:43 2007 From: adar.wesley at gmail.com (Adar Wesley) Date: Tue, 6 Nov 2007 11:42:43 +0200 Subject: [Mono-dev] Patch for System.IO.Ports.SerialPort ReadLinefunction In-Reply-To: <087F05C91CEDCC4EA78E531C6C4E33526BF6DA@morpheus.Rauland.local> References: <087F05C91CEDCC4EA78E531C6C4E33529BF275@morpheus.Rauland.local> <1194275186.4935.70.camel@erandi.boston.ximian.com> <087F05C91CEDCC4EA78E531C6C4E33526BF6DA@morpheus.Rauland.local> Message-ID: Hi, I don't know if it is relevant for your particular situation, but your discussion about keeping track of multiple possible matches reminded me of something I read a long time ago. Check out the AGREP alrorithm for matching multiple patterns concurrently. In particular it has an efficient implementation of keeping track of multiple possible matches. Just google for AGREP algorithm, or check out here: http://webglimpse.net/pubs/TR94-17.pdf Hope this helps, and sorry if it's not relevant. --- Adar Wesley On 11/6/07, Michael Mattess wrote: > > Hello Miguel, > > > > Yes using the ReadTo function does make the most sense as it is a special > case of the operation. > > > > I had a look at the ReadTo function and I think it is broken. It assumes > that it is in the initial state (IE current is 0) when it encounters the > beginning of the string it is reading to. So if we are reading to "ababZ" > and the input is "abababZfoo" it will read past the "ababZ". > > > > It was because of this that I put the 'state-driven' approach into the too > hard / too complex basket when I wrote my initial function. But thinking > about it further the ReadTo function could be extended to keep multiple > states (ie a list of 'current' offsets). One for each time a potential > beginning of the string we are looking for is encountered. I > have attached a file with such an extended ReadTo function. > > > > Let me know your thought. > > > > Regards > > Michael > > > > > > ------------------------------ > *From:* Miguel de Icaza [mailto:miguel at novell.com] > *Sent:* Tue 06.11.2007 02:06 > *To:* Michael Mattess > *Cc:* mono-devel-list at lists.ximian.com > *Subject:* Re: [Mono-dev] Patch for System.IO.Ports.SerialPortReadLinefunction > > > > Hello, > > My ReadLine routine is broken, it did not append data that was only > partially part of the ReadLine. While I was fixing it, I noticed that > we already have a routine that did this correctly (ReadTo). > > So am going to just change the code to be: > > ReadTo (new_line). > > Miguel. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > -- --- Adar Wesley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/97034e5d/attachment.html From safknw at gmail.com Tue Nov 6 06:11:48 2007 From: safknw at gmail.com (Sharique uddin Ahmed Farooqui) Date: Tue, 6 Nov 2007 16:41:48 +0530 Subject: [Mono-dev] 64-bit installer Message-ID: <4da6cf8d0711060311x33cedf42oe6a1287a60eb93f2@mail.gmail.com> Hi, Now 64 bit system are become norms, more linux users are moving 64-bit version of their distro. I think we should hav 64-bit installer now. -- Sharique uddin Ahmed Farooqui (C++/C# Developer, IT Consultant) A revolution is about to begin. A world is about to change. And you and me are "the initiator". From kornelpal at gmail.com Tue Nov 6 06:35:19 2007 From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=) Date: Tue, 6 Nov 2007 12:35:19 +0100 Subject: [Mono-dev] [PATCH] Faster char based memset for String constructor Message-ID: <00ab01c82069$206e3ed0$ae6126c3@kornelpal.hu> Hi, This new implementation is based on memset rather than simply using a single for loop. Please review and approve the patch. Korn?l -------------- next part -------------- A non-text attachment was scrubbed... Name: str.diff Type: application/octet-stream Size: 1266 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/dc207969/attachment.obj From Jerry_van_Leeuwen at nemmco.com.au Thu Nov 1 20:41:01 2007 From: Jerry_van_Leeuwen at nemmco.com.au (Jerry van Leeuwen) Date: Fri, 2 Nov 2007 10:41:01 +1000 Subject: [Mono-dev] Mono version numbering In-Reply-To: <1193961210.5391.72.camel@erandi.boston.ximian.com> Message-ID: Unfortunately both kinds of confusion cannot be avoided through a single version number. The only way to express a "feel" that Mono 1.x is getting very close to complete .NET 2.0 compatibility (where it is not already) would be to number Mono as 1.8.x / 1.9.x as it gets really close to feature complete. Whichever way you choose to solve the version numbering issue I think it would be really good idea if the front page of Mono maintained a brief summary table of the most recent 2 maybe 3 versions of Mono that indicates for each which version of .NET it is closest to fully supporting, and which also indicates the main features it adds or lacks relative to that version, imaginary example: Mono 1.8.x = .NET 2.0 + xxx (3.5) - yyy (2.0) - zzz (1.1) Mono 1.9.x = .NET 2.0 + xxx (3.5) + qqq (3.5) - yyy (2.0) ... Mono 2.0.0 = .NET 2.0 + xxx (3.5) ... etc. but no longer any "-" on any 2.0 feature That'd give developers a quick browse to www.go-mono.com to find out the "detail" of version compatibility. > I think the only way to minimise confusion in the developer population > that does not keep up-to-date with the details of development on Mono > is to let at least the major version track full .NET compatibility. > That is, do not move to v2.x.x until at least .NET 2.0 can be fully > supported, do not move to v3.x.x until at least .NET 3.0 can be fully > supported and maybe even do not move to v3.5.x until .NET 3.5 is > supported. This does not solve the confusion that we have today which is that developers assume that until we have Mono X.Y we wont support version X, which is not the case. ------------------------------------------ This e-mail is confidential. If you are not the intended recipient, any use, disclosure or copying of this document is unauthorised and prohibited. If you have received this document in error, please delete the email and notify me by return email or by phoning the NEMMCO Helpdesk on 1300 300 295. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071102/946a0572/attachment.html From thng at ntnpsphere.net Sat Nov 3 13:38:14 2007 From: thng at ntnpsphere.net (Thanh NGUYEN) Date: Sat, 03 Nov 2007 18:38:14 +0100 Subject: [Mono-dev] Error compiling mono 1.2.5 Message-ID: <472CB206.8030707@ntnpsphere.net> Dear all, I'm trying to compile mono 1.2.5 but not successfully. I got this error : > make[3]: entrant dans le r?pertoire ? > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler ? > /bin/bash ../../libtool --tag=CC --mode=link i486-linux-gnu-gcc -Wall > -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall > -Wunused -Wmissing-prototypes -Wmissing-declarations > -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs > -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings > -mno-tls-direct-seg-refs -Wl,-z,defs -o libmono-profiler-cov.la > -rpath /usr/lib mono-cov.lo ../../mono/mini/libmono.la -ldl -lpthread -lm > libtool: link: warning: > `/usr/lib/gcc/i486-linux-gnu/4.1.3/../../..//libgthread-2.0.la' seems > to be moved > libtool: link: warning: > `/usr/lib/gcc/i486-linux-gnu/4.1.3/../../..//libglib-2.0.la' seems to > be moved > i486-linux-gnu-gcc -shared .libs/mono-cov.o -Wl,--rpath > -Wl,/home/u/Softs/Mono/build-deb/mono-1.2.5/mono/mini/.libs > ../../mono/mini/.libs/libmono.so > -L/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../ -ldl -lpthread -lm > -mno-tls-direct-seg-refs -Wl,-z -Wl,defs -Wl,-soname > -Wl,libmono-profiler-cov.so.0 -o .libs/libmono-profiler-cov.so.0.0.0 > .libs/mono-cov.o: In function `mono_profiler_startup': > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:127: > undefined reference to `g_malloc0' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:128: > undefined reference to `g_hash_table_new' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:138: > undefined reference to `g_strdup' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:131: > undefined reference to `g_strdup' > .libs/mono-cov.o: In function `cov_method_enter': > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:113: > undefined reference to `g_hash_table_insert' > .libs/mono-cov.o: In function `cov_shutdown': > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:98: > undefined reference to `g_hash_table_lookup' > .libs/mono-cov.o: In function `check_partial_coverage': > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:58: > undefined reference to `g_print' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:59: > undefined reference to `g_free' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:61: > undefined reference to `g_print' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:62: > undefined reference to `g_free' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:64: > undefined reference to `g_list_free' > .libs/mono-cov.o: In function `cov_shutdown': > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:80: > undefined reference to `g_print' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:104: > undefined reference to `g_print' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:105: > undefined reference to `g_free' > .libs/mono-cov.o: In function `coverage_callback': > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:42: > undefined reference to `g_strdup_printf' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:47: > undefined reference to `g_list_append' > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler/mono-cov.c:45: > undefined reference to `g_strdup_printf' > collect2: ld returned 1 exit status > make[3]: *** [libmono-profiler-cov.la] Erreur 1 > make[3]: quittant le r?pertoire ? > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono/profiler ? > make[2]: *** [all-recursive] Erreur 1 > make[2]: quittant le r?pertoire ? > /home/u/Softs/Mono/build-deb/mono-1.2.5/mono ? > make[1]: *** [all-recursive] Erreur 1 > make[1]: quittant le r?pertoire ? > /home/u/Softs/Mono/build-deb/mono-1.2.5 ? > make: *** [all] Erreur 2 I have these following packages installed on my system (Ubuntu Gusty) : ii libglib2.0-0 2.14.1-1ubuntu1 The GLib library of C routines ii libglib2.0-dev 2.14.1-1ubuntu1 Development files for the GLib library ii libgtk2.0-0 2.12.0-1ubuntu3 The GTK+ graphical user interface library ii libgtk2.0-bin 2.12.0-1ubuntu3 The programs for the GTK+ graphical user interface library ii libgtk2.0-common 2.12.0-1ubuntu3 Common files for the GTK+ graphical user interface library ii libgtk2.0-dev 2.12.0-1ubuntu3 Development files for the GTK+ library Anyone can tell me how to solve this issue please ? Thank for your helps. Regards, NT From mhenriquezs at terra.cl Sat Nov 3 22:04:38 2007 From: mhenriquezs at terra.cl (Mauricio Henriquez) Date: Sat, 03 Nov 2007 23:04:38 -0300 Subject: [Mono-dev] dbus C# Message-ID: <472D28B6.3020106@terra.cl> Hi to all: I want to write some "central message" proxi for a number of apps and I think that dbus is the correct choice, so my question is if you know a specific mail list dedicated to the dbus + c# technics or is correct to make related question here on this list? thanks Mauricio From brando.fouts at gmail.com Tue Nov 6 01:13:17 2007 From: brando.fouts at gmail.com (Brandon Fouts) Date: Mon, 5 Nov 2007 22:13:17 -0800 Subject: [Mono-dev] Mono versions Message-ID: <609b18560711052213u34b220dcla637d2a0fb46692d@mail.gmail.com> I think you simply need to have a detailed table that shows the details of these compatibilities with .NET (seems even MS has to use this type of solution as MS version numbering isn't intuitive either) And someone to write in details what it all means to developers - like what you do in your blogs. I'm guessing ISVs look for help deciding when to "upgrade" their Mono projects?? Well, probably better to listen to actual developer thoughts and ideas, just an outsiders view. thanks for all the hard work, good luck, (I sure like SLED and openSUSE much better than Vista - who won't? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= www.psnug.org Puget Sound Network Users Group Building Technical Skills Through Teamwork And Education Helping members realize Open Standards and investigate Open Source. Don't just create cross platform networks, make them work better. _____________________ PSNUG dues $35 per year 20th anniversary coffee mug that you can pickup at any meeting - no we don't ship. pay at monthly meeting or send checks payable to: PSNUG PSNUG c/o Brandon Fouts 9549a Olympus Beach Rd NE Bainbridge Island, WA 98110 ==-==-==-==-==-==-==-==-==-==-==-==-==-== From stephane at delcroix.org Tue Nov 6 07:30:38 2007 From: stephane at delcroix.org (Stephane Delcroix) Date: Tue, 06 Nov 2007 13:30:38 +0100 Subject: [Mono-dev] dbus C# In-Reply-To: <472D28B6.3020106@terra.cl> References: <472D28B6.3020106@terra.cl> Message-ID: <1194352238.5132.41.camel@wally> no mailing list, but the #managed-dbus channel on irc.gimp.org s On Sat, 2007-11-03 at 23:04 -0300, Mauricio Henriquez wrote: > Hi to all: > > I want to write some "central message" proxi for a number of apps and I > think that dbus is the correct choice, so my question is if you know a > specific mail list dedicated to the dbus + c# technics or is correct to > make related question here on this list? > > thanks > > Mauricio > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From psmaas at opera.com Tue Nov 6 07:29:04 2007 From: psmaas at opera.com (Patricia Aas) Date: Tue, 06 Nov 2007 13:29:04 +0100 Subject: [Mono-dev] Moonlight in Opera on UNIX In-Reply-To: References: <9af7f65c0711060045v39fa1ef5j45d1471ba7152f13@mail.gmail.com> Message-ID: Hi all, the install is still going (following the instructions mentioned below), but where is this patch: "Download patch found at www.mono-project.com/Moonlight to mono/mono" I didn't see any that stood out. Patricia On Tue, 06 Nov 2007 10:23:11 +0100, Patricia Aas wrote: > Thank you Michael, > > I'll give that a whirl then :) > > Patricia > > On Tue, 06 Nov 2007 09:45:44 +0100, Michael Sch?ndorfer > wrote: > >> Hi, >> >> some time ago i started a Thread on the mono-olive group because I had >> troubles installing Moonlight on Ubuntu 7.04, too. ( >> http://groups.google.com/group/mono-olive/browse_thread/thread/a8a35fa2485e362b >> ) >> >> I got this howto, which worked fine for me: >> http://groups.google.com/group/mono-olive/msg/34a446ebd5c54d8e >> >> >> regards, >> Michael >> >> 2007/11/6, Patricia Aas : >>> >>> Hi, >>> >>> I work on plugins on UNIX in Opera, and I've been trying to compile up >>> Moonlight to see if it has any issues in Opera, but it is not easy - so >>> if >>> someone could give me some tips I'd greatly appreciate it :) I'm on >>> Ubunty >>> Feisty if that helps. >>> >>> Patricia >>> >>> -- >>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> > > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From csri_1986 at yahoo.com Tue Nov 6 07:52:53 2007 From: csri_1986 at yahoo.com (Srikanth M R) Date: Tue, 6 Nov 2007 04:52:53 -0800 (PST) Subject: [Mono-dev] [Patch] Bug 324856 cleared Message-ID: <961509.70799.qm@web50710.mail.re2.yahoo.com> Hello Everyone, I have patched bug324856 (https://bugzilla.novell.com/show_bug.cgi?id=324856). I would like a review. This is my first-time-patching. Pardon any newbie-ness. Srikanth. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/151d959f/attachment.html From rolflists at ya.com Tue Nov 6 07:46:36 2007 From: rolflists at ya.com (Rolf Bjarne Kvinge) Date: Tue, 6 Nov 2007 13:46:36 +0100 Subject: [Mono-dev] Moonlight in Opera on UNIX In-Reply-To: References: <9af7f65c0711060045v39fa1ef5j45d1471ba7152f13@mail.gmail.com> Message-ID: <00c401c82073$119ae1b0$34d0a510$@com> > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- > bounces at lists.ximian.com] On Behalf Of Patricia Aas > Sent: martes, 06 de noviembre de 2007 13:29 > To: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Moonlight in Opera on UNIX > > Hi all, > > the install is still going (following the instructions mentioned > below), but where is this patch: > > "Download patch found at www.mono-project.com/Moonlight to mono/mono" > > I didn't see any that stood out. > That patch is no longer necessary (as of last week). Rolf > Patricia > > On Tue, 06 Nov 2007 10:23:11 +0100, Patricia Aas > wrote: > > > Thank you Michael, > > > > I'll give that a whirl then :) > > > > Patricia > > > > On Tue, 06 Nov 2007 09:45:44 +0100, Michael Sch?ndorfer > > wrote: > > > >> Hi, > >> > >> some time ago i started a Thread on the mono-olive group because I > >> had troubles installing Moonlight on Ubuntu 7.04, too. ( > >> http://groups.google.com/group/mono- > olive/browse_thread/thread/a8a35f > >> a2485e362b > >> ) > >> > >> I got this howto, which worked fine for me: > >> http://groups.google.com/group/mono-olive/msg/34a446ebd5c54d8e > >> > >> > >> regards, > >> Michael > >> > >> 2007/11/6, Patricia Aas : > >>> > >>> Hi, > >>> > >>> I work on plugins on UNIX in Opera, and I've been trying to compile > >>> up Moonlight to see if it has any issues in Opera, but it is not > >>> easy - so if someone could give me some tips I'd greatly appreciate > >>> it :) I'm on Ubunty Feisty if that helps. > >>> > >>> Patricia > >>> > >>> -- > >>> Using Opera's revolutionary e-mail client: > >>> http://www.opera.com/mail/ > >>> _______________________________________________ > >>> Mono-devel-list mailing list > >>> Mono-devel-list at lists.ximian.com > >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >>> > > > > > > > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From monoman at gmail.com Tue Nov 6 08:04:01 2007 From: monoman at gmail.com (Rafael Teixeira) Date: Tue, 6 Nov 2007 11:04:01 -0200 Subject: [Mono-dev] mod_mono and supplementary groups In-Reply-To: <33f0a7e60711051152v74fede9ei2b9986dc285561b@mail.gmail.com> References: <33f0a7e60711051152v74fede9ei2b9986dc285561b@mail.gmail.com> Message-ID: Mod_Mono calls a process running Mono runtime, probably the process user is set to what Apache tells, but groups may not being set correctly. Just some thoughts on it. On 11/5/07, Jay Miller wrote: > I'm confused about how mod_mono works with supplementary groups. I > have Apache running as apache.apache, with the apache user a member of > the 'safe' group: > > $ groups apache > apache : apache safe > > I also have a directory with 'safe' ownership: > > $ ls -dl /var/log/safe > drwxrwxr-x 2 root safe 4.0K Nov 5 12:04 /var/log/safe > > The following PHP script is able to write to that directory: > > > > However, the following ASP script is not: > > <%@ Page Language="C#" Debug="true" %> > <% using (System.IO.File.CreateText("/var/log/safe/arr.asp")) { } %> > > Interestingly, these two scripts return different values when they > call getgroups(). The PHP script "correctly" returns the apache and > safe groups. The ASP script returns apache for its effective uid/gid, > but getgroups() returns groups 0,1,2,3,4,6,10 - all of *root's* > supplementary groups! > > Hopefully someone can provide some quick insight to my problem here > and, ideally, a workaround - thank you in advance for your help! > > -- > Jay Miller > PGP Fingerprint | 5f7adbbe bfc60727 96dca94c 616d5080 09e3e846 > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Rafael "Monoman" Teixeira --------------------------------------- "I myself am made entirely of flaws, stitched together with good intentions." Augusten Burroughs From psmaas at opera.com Tue Nov 6 09:07:26 2007 From: psmaas at opera.com (Patricia Aas) Date: Tue, 06 Nov 2007 15:07:26 +0100 Subject: [Mono-dev] Moonlight in Opera on UNIX In-Reply-To: <00c401c82073$119ae1b0$34d0a510$@com> References: <9af7f65c0711060045v39fa1ef5j45d1471ba7152f13@mail.gmail.com> <00c401c82073$119ae1b0$34d0a510$@com> Message-ID: Hi Rolf, attching a perl script of what I am doing - note I am not a perl programmer so it is pretty much what was in the howto. I seem to still get errors though (doing make in mono): make[5]: Entering directory `/home/psmaas/Plugins/Moonlight/mono/mcs' Corlib not in sync with this runtime: expected corlib version 60, found 54. Loaded from: /usr/lib/mono/1.0/mscorlib.dll Download a newer corlib or a newer runtime at http://www.go-mono.com/daily. make[6]: *** [build/deps/basic-profile-check.exe] Error 1 *** The compiler 'mcs' doesn't appear to be usable. *** You need a C# compiler installed to build MCS (make sure mcs works from the command line) *** Read INSTALL.txt for information on how to bootstrap a Mono installation. Any hints would be greatly appreciated. Patricia On Tue, 06 Nov 2007 13:46:36 +0100, Rolf Bjarne Kvinge wrote: >> -----Original Message----- >> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- >> bounces at lists.ximian.com] On Behalf Of Patricia Aas >> Sent: martes, 06 de noviembre de 2007 13:29 >> To: mono-devel-list at lists.ximian.com >> Subject: Re: [Mono-dev] Moonlight in Opera on UNIX >> >> Hi all, >> >> the install is still going (following the instructions mentioned >> below), but where is this patch: >> >> "Download patch found at www.mono-project.com/Moonlight to mono/mono" >> >> I didn't see any that stood out. >> > > That patch is no longer necessary (as of last week). > > Rolf > >> Patricia >> >> On Tue, 06 Nov 2007 10:23:11 +0100, Patricia Aas >> wrote: >> >> > Thank you Michael, >> > >> > I'll give that a whirl then :) >> > >> > Patricia >> > >> > On Tue, 06 Nov 2007 09:45:44 +0100, Michael Sch?ndorfer >> > wrote: >> > >> >> Hi, >> >> >> >> some time ago i started a Thread on the mono-olive group because I >> >> had troubles installing Moonlight on Ubuntu 7.04, too. ( >> >> http://groups.google.com/group/mono- >> olive/browse_thread/thread/a8a35f >> >> a2485e362b >> >> ) >> >> >> >> I got this howto, which worked fine for me: >> >> http://groups.google.com/group/mono-olive/msg/34a446ebd5c54d8e >> >> >> >> >> >> regards, >> >> Michael >> >> >> >> 2007/11/6, Patricia Aas : >> >>> >> >>> Hi, >> >>> >> >>> I work on plugins on UNIX in Opera, and I've been trying to compile >> >>> up Moonlight to see if it has any issues in Opera, but it is not >> >>> easy - so if someone could give me some tips I'd greatly appreciate >> >>> it :) I'm on Ubunty Feisty if that helps. >> >>> >> >>> Patricia >> >>> >> >>> -- >> >>> Using Opera's revolutionary e-mail client: >> >>> http://www.opera.com/mail/ >> >>> _______________________________________________ >> >>> Mono-devel-list mailing list >> >>> Mono-devel-list at lists.ximian.com >> >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >>> >> > >> > >> > >> >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -------------- next part -------------- A non-text attachment was scrubbed... Name: install_Moonlight.pl Type: application/octet-stream Size: 2867 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/82397623/attachment.obj From miguel at novell.com Tue Nov 6 11:11:44 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 06 Nov 2007 11:11:44 -0500 Subject: [Mono-dev] Moonlight in Opera on UNIX In-Reply-To: References: <9af7f65c0711060045v39fa1ef5j45d1471ba7152f13@mail.gmail.com> Message-ID: <1194365504.4068.23.camel@erandi.boston.ximian.com> > the install is still going (following the instructions mentioned below), > but where is this patch: > > "Download patch found at www.mono-project.com/Moonlight to mono/mono" > > I didn't see any that stood out. The patch is no longer needed if you are using the SVN build of Mono. Miguel From vgiszpenc at dsci.com Tue Nov 6 13:49:49 2007 From: vgiszpenc at dsci.com (Vladimir Giszpenc) Date: Tue, 6 Nov 2007 13:49:49 -0500 Subject: [Mono-dev] VMWear player for Mono development References: <955542.15988.qm@web39609.mail.mud.yahoo.com> <1194016462.6475.40.camel@erandi.boston.ximian.com> Message-ID: Hi Miguel, I would love to see a Xen DomU guest image as well. I realize that VMWare has a free offering, but it is not open source. Xen's hypervisor was built into Microsoft's Virtualization server. It is part of OpenSuse and the new Linux kernel has a lot of it baked in. Mono should run on a better VM player i.e. Xen running with Dom0 host such as OpenSuse, Fedora, Gentoo, etc. I realize that there is a documentation effort, but I strongly believe that increasing the Xen community can do nothing but good for Mono. Xen is much more efficient with memory and it would be a nice fit for the Novell/FOSS marketing machine. > bounces at lists.ximian.com] On Behalf Of Miguel de Icaza > > The current VMWear player is one of the greatest things Mono has to > > boost exploration of Mono. I love it. In fact I love it so much, I > > want another! > > > > What about a VMWear player setup with Mono source and SVN so one could > > just fire it up, update the source from svn and start contributing? > > That is a very nice idea; We are going to update this with a new > OpenSUSE 10.3 installation as well. Thanks, Vlad -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3329 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071106/49f04ed7/attachment.bin From miguel at novell.com Tue Nov 6 14:38:18 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 06 Nov 2007 14:38:18 -0500 Subject: [Mono-dev] VMWear player for Mono development In-Reply-To: References: <955542.15988.qm@web39609.mail.mud.yahoo.com> <1194016462.6475.40.camel@erandi.boston.ximian.com> Message-ID: <1194377898.4068.66.camel@erandi.boston.ximian.com> > Mono should run on a better VM player i.e. Xen running with Dom0 host such > as OpenSuse, Fedora, Gentoo, etc. I realize that there is a documentation > effort, but I strongly believe that increasing the Xen community can do > nothing but good for Mono. Xen is much more efficient with memory and it > would be a nice fit for the Novell/FOSS marketing machine. Well, if you have a Linux distro, the need for the VM player is really minimized. The VM player audience is mostly Windows/Mac developers. Miguel. From monkey at jpobst.com Tue Nov 6 16:55:47 2007 From: monkey at jpobst.com (Jonathan Pobst) Date: Tue, 06 Nov 2007 15:55:47 -0600 Subject: [Mono-dev] MonoSummit: Planning the Sessions In-Reply-To: References: Message-ID: <4730E2E3.1080309@jpobst.com> Hey Brock! Us VS.Net brats are looking at what we can present to help out our fellow brats. I work pretty much exclusively in VS2005 and completely understand the advantage of staying with tools you already k