Re: [Mono-dev] New Mono.Data.Sqlite problems with UTF8 conversion on Windows
On Sat, 2 Jun 2007 18:27:30 +0200, Kamil Skalski [EMAIL PROTECTED] scribbled: Hello! Hello Kamil, I was trying to use the new implementation of Sqlite provider available now on mono, but I had several problems with it... First of all it failed to perform BindParameters properly when I tried to use named parameters. After some debugging it appeared that the names of parameters are improperly read from data returned by sqlite native function. The problem was the usage of Marshal.PtrToStrAuto in SQLiteConvert.cs function, which didn't properly decode strings on Windows system. I patched the implementation with the way it is done in old Mono.Data.SqliteClient - the implementation isn't very elegant, since it adds usage of unsafe pointer, but it worked well in the old implementation. If anybody knows a better way to convert unmanaged utf8 strings into managed string, without adding dependency on other libraries, then we could do this better. I've applied your patch to svn, revision 78615. Thanks. The second problem I encounter with new implementation is that it seems to deadlock when there are two threads using the same data-base... I use separate connections for each thread, but it looks like when I perform data-modify operations from both, it locks totally (concurrent reads seems to be ok). If anyone has some suggestions, please let me know. For now I will stick with old implementation. Could you file a bug with a simple test case and assign it to [EMAIL PROTECTED] Thanks. best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Log4net RemotingAppender is not working with mono
with the RemotingAppender you could log to a centralized remoting server... It fails with : Cannot create channel sink to connect to URL it works with MS.NET 1.1 http://bugzilla.ximian.com/show_bug.cgi?id=81811 If you take a look at : http://www.nabble.com/-jira--Created:-(LOG4NET-114)-Unit-tests-only-support-.NET-1.0-t3255315.html log4net didn't pass the tests with mono especially with remotingappender, it could be great to fix this issue, because log4net is widely used in the .NET world! Thanks Hubert FONGARNAND ___ Ce message et les éventuels documents joints peuvent contenir des informations confidentielles. Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono'runtime
Hello, I still prefer the environment variable approach. Are there any serious disadvantages? Here are some additional thoughts: And I still think that we will use a hardcoded value for the interpreter. - If it isn't going to work to have the code inside CreateProcess, then if it is implemented using an environment variable, the code for detecting CLR binaries can be 100% managed. The only downside is that the logic for determining the full path to the binary then needs to be duplicated, but it needs to be duplicated anyway if the implementation can't be inside CreateProcess, and if this is done in managed code, it can take advantage of things like Path.GetFullName(). I think we can keep the code inside CreateProcess, - Tools can be written to compare behaviour and/or performance of .NET applications across different runtimes. For instance, on UNIX, code aware of the behaviour could select between mono and DotGNU by setting the environment variable. Tools to do that can much more easily specify the runtime to use by calling the specific interpreter instead of depending on yet another obscure environment variable that if we are remotely lucky will be documented. Ie, Process.Start (mono program.exe) and Process.Start (clix program.exe) much easier than setting the environment and then calling program.exe Similarly, on Windows, code could select between mono and the MS .NET framework by clearing and re-setting the environment variable. Also, on any platform, performance comparisons could be easily done in an automated fashion between different versions of mono installed side-by-side. This is arguably the only possible use for this setup and am not convinced that supporting the extra feature/bloat is worth it. Shall I rework the patch to do the check directly inside System.Diagnostics.Process.Start? I think your current patch is fine, I only ask you for either: * Sign a copyright assignment form, so we can get the code in the runtime. * License the patch under the MIT X11 code, so we are allowed to relicense it. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PATCH: Make Process.Start() use the same 'mono' runtime
On Mon, 2007-06-04 at 17:31 -0400, Miguel de Icaza wrote: I rather not use the environment variable, for one computing the actual program name might not be easy. I rather just hard code it to `mono' and it would be up to the user to set the path name appropriately. At least in Debian, the mono executable is not called mono. It's cli: http://pkg-mono.alioth.debian.org/cli-policy/ They have both, cli i think is a symlink, Thats correct, cli is a symlink which points to the best/preferred installed CLI runtime like mono. Also the cli symlink is only used for applications that are known to run on any CLI runtime (that's about none to helloworld.exe) if they dont do that, its not our fault, and they should provide a patch just like they patch the rest. Do you believe I am insane and rename mono binaries? *cough* -- Regards, Mirco 'meebey' Bauer PGP-Key: http://keyserver.noreply.org/pks/lookup?op=getsearch=0xEEF946C8 -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d s-:+ a-- C++ UL$ P L++$+++$ E- W+++$ N o? K- w++! O M- V? PS PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G++ e h! r-++ y? --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# Burstsort for Mono
Sounds really interesting, I would not mind to give it a shot unless someone else more experienced wants to do it. On 5 Jun 2007, at 22:12, Cetin Sert wrote: Hi... Could someone write a burstsort implementation for Mono? http:// www.sf.net/projects/burstsort, http://goanna.cs.rmit.edu.au/~jz/ fulltext/alenex03.pdf, http://www.cs.mu.oz.au/~rsinha/papers/ SinhaRingZobel-2006.pdf Cetin Sert INF 521, 4-6-2 69120 Heidelberg Germany http://tenkatext.sourceforge.net/contact ___ 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
Re: [Mono-dev] C# Burstsort for Mono
Thanks for your interest. I would love to be of some help if I could but I am not all that experienced myself. I'll nevertheless try to come up with something and let you know if it turns out to be usable. Cetin Sert INF 521, 4-6-2 69120 Heidelberg Germany http://tenkatext.sourceforge.net/contact From: Manuel de la Pena [mailto:[EMAIL PROTECTED] Sent: Dienstag, 5. Juni 2007 23:30 To: Cetin Sert Cc: Mono-devel-list Subject: Re: [Mono-dev] C# Burstsort for Mono Sounds really interesting, I would not mind to give it a shot unless someone else more experienced wants to do it. On 5 Jun 2007, at 22:12, Cetin Sert wrote: Hi... Could someone write a burstsort implementation for Mono? http://www.sf.net/projects/burstsort, http://goanna.cs.rmit.edu.au/~jz/fulltext/alenex03.pdf http://goanna.cs.rmit.edu.au/~jz/fulltext/alenex03.pdf, http://www.cs.mu.oz.au/~rsinha/papers/SinhaRingZobel-2006.pdf Cetin Sert INF 521, 4-6-2 69120 Heidelberg Germany http://tenkatext.sourceforge.net/contact ___ 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
