Re: [Mono-dev] Removing Obsolete Code from Mono 2.8
On Mon, 01 Mar 2010 21:36:06 -0500 Miguel de Icaza mig...@novell.com wrote: Hello, [snip] There are many different versions of the SQLite provider. However, Mono has a couple of different versions: Mono.Data.SqliteClient which is 1.1 only. It will not work with NET_2_0 profile unless someone fixes it. Mono.Data.Sqlite - the 2.0 parts - is based on System.Data.Sqlite. Agreed, this is a good time to drop the old provider. Marek, how far did we deviate from the upstream code? And can we do a We renamed the namespace from System.Data.SQLite to Mono.Data.Sqlite, all the classes were renamed by changing the SQLite prefix to Sqlite (for compatibility with older SQLite provider we had), added some connection string compatibility code (some 40 lines of code) and that's basically it. code refresh without breaking the API? Yes. I can drop the old provider if someone tells me which one it is. The old one is Mono.Data.SqliteClient marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing Obsolete Code from Mono 2.8
Hello, With the upcoming release of Mono 2.8 we are dropping the 1.0 profile as developers moved a long time ago to the generics-based 2.0 profile and because it is maintenance burden for us. In addition to this, I would like to stop distributing some libraries that were either never completed and are not being actively maintained. We could move these libraries to a separate module if people would like to maintain them or keep distributing them. Here is what I have in mind: * Drop Microsoft.JScript and `mjs' We should drop Microsoft.Vsa as well then. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Hello Kornél, Don't make compiler generated classes sealed by default. What is benefit of not doing that? This is also related to the same class because that was explicitly removing the sealed modifier to enable the static modifier. Although currently only a single compiler generated class benefits from both of these modifications I don't see any drawbacks and in my opinion the changes result in a more properly designed compiler generated class infrastructure. I am not sure what does more properly designed compiler generated class infrastructure mean but removing sealed from other generated classes it's not. The fix should be to add a new overload to avoid clearing the sealed flag. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Hi Marek, Although currently only a single compiler generated class benefits from both of these modifications I don't see any drawbacks and in my opinion the changes result in a more properly designed compiler generated class infrastructure. I am not sure what does more properly designed compiler generated class infrastructure mean but removing sealed from other generated classes it's not. The fix should be to add a new overload to avoid clearing the sealed flag. Since the constructor accepts a Modifiers mod parameter adding another (for example bool) parameter that would affect the Modifiers parameter sounds too complicated to me. On more properly designed I mean that I belive that a class being comipler generated doesn't imply that it also has to be sealed, furthermore it also can be either sealed or static, and there is no need for enforcing any of them because the constructor accepts Modifiers. (Similarly it does not enforce any visibility flags either.) In my opinion adding Modifiers.COMPILER_GENERATED on the other hand is the expected behavior. CompilerGeneratedClass currently has three child classes: AnonymousMethodStorey: Currently relies on Modifiers.SEALED being added by the base class constructor and modified to pass Modifiers.SEALED to the base constructor in the patch. AnonymousTypeClass: Already passes Modifiers.SEALED to the base constructor. DynamicExpressionStatement.StaticDataClass: Passes Modifiers.STATIC to the base constructor and without the patch has to remove Modifiers.SEALED in its constructor body Kornel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to configure Mono 2.6 which can support .Net4.0
I could be wrong, but I think this is a compilation flag, ie: when you build Mono from sources. Unless building Mono from sources doesn't bother you, if I were you, I'd be lazy and patiently wait for Mono 2.8. ShankarH wrote: HI, I am new to Mono studio. I have mono 2.6 installed and want to use .net 4.0 features in mono.. Got to know that , have to enable below flag, --with-profile4=yes Where should i set this flag..? Do i need to run any command to use .Net 4.0 feature..? How to make sure whether .net 4.0 features suport in mono 2.6..? Can anybody help me with this.. Thx, Shankar -- View this message in context: http://n4.nabble.com/How-to-configure-Mono-2-6-which-can-support-Net4-0-tp1574804p1574842.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing Obsolete Code from Mono 2.8
A brief look into gnome git for f-spot and banshee, I found that: - f-spot may still use the old Mono.Data.SqliteClient - banshee has its own copy of Mono.Data.Sqlite Not sure what other apps that may depend on Mono.Data.SqliteClient. --- On Tue, 3/2/10, Marek Habersack gren...@twistedcode.net wrote: From: Marek Habersack gren...@twistedcode.net Subject: Re: [Mono-dev] Removing Obsolete Code from Mono 2.8 To: mono-devel-list@lists.ximian.com Date: Tuesday, March 2, 2010, 3:25 AM On Mon, 01 Mar 2010 21:36:06 -0500 Miguel de Icaza mig...@novell.com wrote: Hello, [snip] There are many different versions of the SQLite provider. However, Mono has a couple of different versions: Mono.Data.SqliteClient which is 1.1 only. It will not work with NET_2_0 profile unless someone fixes it. Mono.Data.Sqlite - the 2.0 parts - is based on System.Data.Sqlite. Agreed, this is a good time to drop the old provider. Marek, how far did we deviate from the upstream code? And can we do a We renamed the namespace from System.Data.SQLite to Mono.Data.Sqlite, all the classes were renamed by changing the SQLite prefix to Sqlite (for compatibility with older SQLite provider we had), added some connection string compatibility code (some 40 lines of code) and that's basically it. code refresh without breaking the API? Yes. I can drop the old provider if someone tells me which one it is. The old one is Mono.Data.SqliteClient marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Using Mono Assemblies under terms of LGPL
Hi All, We are looking at using one of the assemblies from the Mono release under the terms of the LGPL license in a commercial closed source application. My understanding is that this is allowed as long as we do not modify the compiled assembly in any way. The issue that we face is that this assembly is not signed and we need to be able to place the assembly in the GAC of Microsoft Windows systems. What is the recommended way to handle this situation? In particular we are interested in the GNU.Gettext.dll assembly. I know this is technically not part of Mono, but Mono seems to be the only source of a compiled version of this library and Gettext itself is also LGPL. Thanks, Jacques ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Equivalent to LockFileEx on Linux
Is there an equivalent to LockFileEx on Linux? What would it be? How would you lock a file that will work on .net on windows and mono on linux and mono on windows and mono on mac os x, etc? I would like this info so all DllImport attributes can be removed from csharp-sqlite to make it fully managed. Some people would like to use it in medium-trust and Silverlight/Moonlight. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing Obsolete Code from Mono 2.8
Hello, * Drop Microsoft.JScript and `mjs' We should drop Microsoft.Vsa as well then. Done as well. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using Mono Assemblies under terms of LGPL
On Tue, 2010-03-02 at 12:21 -0500, Jacques Beaurain wrote: ... The issue that we face is that this assembly is not signed and we need to be able to place the assembly in the GAC of Microsoft Windows systems. What is the recommended way to handle this situation? In particular we are interested in the GNU.Gettext.dll assembly. Er, what? I don't see this assembly in my GAC (both the distro-provided and my trunk installation), nor do I see a GNU.Gettext.dll assembly in my source tree. Where are you seeing this assembly? To answer the original question, the answer is: don't. For the love of all that is good and holy, don't strong-name an assembly that isn't strong-named and install it into the GAC. Strong-naming is an indication that the API won't change in an incompatible manner, possibly ever. Upstream likely won't even know you did this, will eventually break API, and cause all manner of pain. (Case in point: Mono has two separate copies of SharpZipLib because they changed their API in an incompatible manner. I don't know who strong-named it -- i.e. was it it Mono being bad, or were they screwing things up -- but it's not a good situation to be in.) YOU have sources and a compiler toolchain. If you need a strong-named assembly, fold it into your own assemblies and strong name *those*, so that responsibility for maintaining API compatibility is clear. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent to LockFileEx on Linux
On Tue, 2010-03-02 at 12:29 -0800, Daniel Morgan wrote: Is there an equivalent to LockFileEx on Linux? What would it be? No. There's flock(2) and fcntl(2), but these are advisory in nature only. (Meaning that any other process with access rights to the file can come along, ignore the advisory lock, and change the file underneath you.) In managed code, there's System.IO.FileStream.Lock(long, long) and System.IO.FileStream.Unlock(long, long), but these use fcntl(2)'s F_SETLK functionality. Mandatory locking (according to fcntl(2)) requires that the file system opt-in (via the '-o mand' option to mount(8)) AND enabled on the file by disabling group execute permission and enabling the set-group-ID permission bit. None of my systems have '-o mand' specified, and I doubt that very many systems do. How would you lock a file that will work on .net on windows and mono on linux and mono on windows and mono on mac os x, etc? You don't. Bwa-ha-ha-ha-ha. Sorry. Related question: why do you need this? Linux and Unix seem to get along just fine without system-wide mandatory locking... Perhaps as an alternative you should read/write to a temporary file, flush the file, then rename the file (assuming file renames are atomic, which is *usually* the case). You might lose data if two processes attempt to overwrite the same file at the same time, but at least your DB will be consistent and not corrupted... - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent to LockFileEx on Linux
On Tue, Mar 2, 2010 at 4:28 PM, Jonathan Pryor jonpr...@vt.edu wrote: On Tue, 2010-03-02 at 12:29 -0800, Daniel Morgan wrote: Is there an equivalent to LockFileEx on Linux? What would it be? No. There's flock(2) and fcntl(2), but these are advisory in nature only. (Meaning that any other process with access rights to the file can come along, ignore the advisory lock, and change the file underneath you.) Probably the question needs to be rephrased a little. sqlite itself obviously works fine on Linux, so clearly Linux has the kind of locking that is needed in order to make sqlite work... even if it's in Linux. Whether silverlight/moonlight expose such things (without DllImport) is another question. Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent to LockFileEx on Linux
On Tue, 2010-03-02 at 21:03 -0500, Avery Pennarun wrote: Probably the question needs to be rephrased a little. sqlite itself obviously works fine on Linux, so clearly Linux has the kind of locking that is needed in order to make sqlite work... Yes, work. There's a difference between working and working. Specifically, if you peruse the C source for SQLite [0], you'll find sqlite-3.6.22/src/os_unix.c has a long diatribe about the evils of advisory locking (lines 591-694, starting with POSIX advisory locks are broken by design), and SQLite work[s] around the problem (line 615) by manag[ing] file locks internally. In short, SQLite (1) uses advisory file locking (as FileStream.Lock() provides under Mono), then (2) requires that all SQLite users actually use libsqlite.so (otherwise they won't use the internal management). So if someone re-implements SQLite (or just cat(1)'s the file), they won't go through SQLites lock management, and they'll be none the wiser. (Likewise nothing stops someone from overwriting the file with garbage.) In summary, SQLite uses advisory file locking (because it has to), then has a ton of code to work around all of the shortcomings of advisory file locking (UTSL). For those reimplementing SQLite in managed code, there are ~3 solutions to the file locking issue: 1. Ignore the problem entirely. Especially for Silverlight, your SQLite DB should be a per-program resource, so nothing else should be mucking with it anyway (unless someone runs your SL app from multiple different browsers concurrently). 2. Use FileStream.Lock()/FileStream.Unlock() and ignore the downsides of advisory locks. This works if you only care about supporting programs that pay attention to advisory file locks (like other programs written in managed code). Pro: Simple, and still supports the multiple SL apps instances scenario. Con: Other programs can screw things up (if you care). 3. Reimplement SQLites internal handle management. Pro: You properly interoperate with SQLite. Con: You need to track SQLite; if they change their algorithm, you need to change yours. There's still no perfect solution, though. I'd suggest (1) or (2) for simplicity reasons. - Jon [0] http://www.sqlite.org/sqlite-3.6.22.tar.gz ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Equivalent to LockFileEx on Linux
On Tue, Mar 2, 2010 at 9:54 PM, Jonathan Pryor jonpr...@vt.edu wrote: In short, SQLite (1) uses advisory file locking (as FileStream.Lock() provides under Mono), then (2) requires that all SQLite users actually use libsqlite.so (otherwise they won't use the internal management). Well, I'm guessing the developer of libsqlite.so was not expecting there to be other conflicting implementations of sqlite that would all be accessing the same database. So if the managed sqlite clone is supposed to be 100% interoperable with the real sqlite (which I doubt it very important), it needs to do exactly the same kind of locking, ie. your solution #3. Otherwise, it needs to do its own locking however it likes, your solution #1 or #2. So I suppose I'm agreeing with your facts, but not your opinions... I'm not sure what's so ugly about this solution. So if someone re-implements SQLite (or just cat(1)'s the file), they won't go through SQLites lock management, and they'll be none the wiser. As it (arguably of course) should be. People writing backup software on Unix are much happier people than people writing backup software on Windows. And as a user, I'd prefer to have multiple possibly-slightly-corrupted backups of my MS Exchange server or virtual machine disks instead of the terrible surprise upon restoring of finding out there were no backups (because mandatory locks rejected me). Mandatory locking isn't nearly as great as it sounds. Have fun, Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
