Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

2010-03-02 Thread Marek Habersack
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

2010-03-02 Thread Marek Safar
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.

2010-03-02 Thread Marek Safar
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.

2010-03-02 Thread Kornél Pál
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

2010-03-02 Thread Stifu

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

2010-03-02 Thread Daniel Morgan
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

2010-03-02 Thread Jacques Beaurain
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

2010-03-02 Thread Daniel Morgan
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

2010-03-02 Thread Miguel de Icaza
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

2010-03-02 Thread Jonathan Pryor
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

2010-03-02 Thread Jonathan Pryor
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

2010-03-02 Thread Avery Pennarun
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

2010-03-02 Thread Jonathan Pryor
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

2010-03-02 Thread Avery Pennarun
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