Re: [Mono-dev] Debugger on Windows
Yes i agree, mono debugger IS NOT READY on linux... Example i want to debug a simple app (without thread) (it just use log4net) [EMAIL PROTECTED] ~/Projects/SynchroPassPremium/SendToFT/bin/Debug $ mdb ./SendToFT.exe Mono Debugger (mdb) r Starting program: ./SendToFT.exe Cannot load symbol file `/home/hubert/Projects/SynchroPassPremium/SendToFT/bin/Debug/log4net.dll.mdb': Could not find file /home/hubert/Projects/SynchroPassPremium/SendToFT/bin/Debug/log4net.dll.mdb. EXCEPTION: System.ArgumentException: Cannot compare addresses from different domains AddressDomain (0:) and AddressDomain (0:global) at Mono.Debugger.TargetAddress.check_domains (TargetAddress a, TargetAddress b) [0x0001e] in /home/hubert/mono/debugger/interface/TargetAddress.cs:95 at Mono.Debugger.TargetAddress.op_Equality (TargetAddress a, TargetAddress b) [0x0] in /home/hubert/mono/debugger/interface/TargetAddress.cs:146 at Mono.Debugger.Backends.SingleSteppingEngine.throw_exception (TargetAddress stack, TargetAddress exc, TargetAddress ip) [0x00031] in /home/hubert/mono/debugger/backend/SingleSteppingEngine.cs:920 at Mono.Debugger.Backends.SingleSteppingEngine.ProcessChildEvent (Mono.Debugger.Backends.ChildEvent cevent) [0x000c1] in /home/hubert/mono/debugger/backend/SingleSteppingEngine.cs:252 at Mono.Debugger.Backends.SingleSteppingEngine.ProcessEvent (Int32 status) [0x00295] in /home/hubert/mono/debugger/backend/SingleSteppingEngine.cs:214 at (wrapper remoting-invoke-with-check) Mono.Debugger.Backends.SingleSteppingEngine:ProcessEvent (int) at Mono.Debugger.Backends.ThreadManager.engine_thread_main () [0x000ce] in /home/hubert/mono/debugger/backend/ThreadManager.cs:310 Prout! Le jeudi 10 mai 2007 à 17:38 +0200, pablosantosluac a écrit : Ok, then I misunderstood a message I receive this morning telling something about the debugger being unable to handle a simple app... - Original Message - From: Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Thursday, May 10, 2007 5:28 PM Subject: Re: [Mono-dev] Debugger on Windows pablosantosluac escribió: Hi folks, Well, IMHO what we all DO need is a decent debugger on Linux. If I just had a debugger I would start developing with MonoDevelop today on Linux, and I guess most people would do the same Then we would be all day testing MonoDevelop, the compiler, the debugger and so on and so on... And this IS GOOD for Mono, much better than having some sort of replacement on Windows. By the way porting an app to Linux will take some effort, ok, but what Mono gives is a real opportunity to do it and still develop with C#, the framework and so on... which is great! C# and the entire framework is IMHO the best development platform ever... let's have it on Linux with the only big piece is missing... a debugger!! I agree having it on Windows would help, but please... first on Linux! AFAIK the Debugger is ready on Linux. What is lacking is updating the Debugger Addin for MonoDevelop, which is the target of a SoC2007 project IIRC. Then, I agree that having the debugger on Windows would be important, thus not having to drop the Debugger Addin for an hypothetic MD installer for Windows. Regards, Andrés [ knocte ] ___ 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] Problem with Mono in Fedora 6
[EMAIL PROTECTED] wrote: Hi, I'm still stuck with Mono in Fedora 6. All modules (mono-1.2.3.1, mono-basic-1.2.3.1, libgdiplus-1.2.3, xsp-1.2.3 and mod_mono-1.2.1) were recompile and now I get this in apache error log is this: System.IO.FileNotFoundException: File or assembly name mod-mono-server, Version=1.2.3.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756, or one of its dependencies, was not found. File name: mod-mono-server, Version=1.2.3.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 This could be an access rights problem. Check whether the tree you've installed mono into is readable by the apache user. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with Mono in Fedora 6
Hi Marco (BTW, nice name :-) ), I strongly recommend you to use a Filemon-like utility to check where Apache's looking for mod-mono-server. For me, it seems like Apache's looking in the wrong path. I've tried to search that tool for GNU/Linux, but it seems to be deprecated since some changes where introduced to the kernel. Please, if you find something similar, send it back to the list, it'd be really useful. Regards, 2007/5/11, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi, I'm still stuck with Mono in Fedora 6. All modules (mono-1.2.3.1, mono-basic-1.2.3.1, libgdiplus-1.2.3, xsp-1.2.3 and mod_mono-1.2.1) were recompile and now I get this in apache error log is this: System.IO.FileNotFoundException: File or assembly name mod-mono-server, Version=1.2.3.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756, or one of its dependencies, was not found. File name: mod-mono-server, Version=1.2.3.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 at (wrapper xdomain-invoke) System.AppDomain:CreateInstanceAndUnwrap (string,string) at (wrapper remoting-invoke-with-check) System.AppDomain:CreateInstanceAndUnwrap (string,string) at System.Web.Hosting.ApplicationHost.CreateApplicationHost (System.Type hostType, System.String virtualDir, System.String physicalDir) [0x0] at Mono.WebServer.VPathToHost.CreateHost (Mono.WebServer.ApplicationServer server, Mono.WebServer.WebSource webSource) [0x0] at Mono.WebServer.ApplicationServer.GetApplicationForPath (System.String vhost, Int32 port, System.String path, Boolean defaultToRoot) [0x0] at (wrapper remoting-invoke-with-check) Mono.WebServer.ApplicationServer:GetApplicationForPath (string,int,string,bool) at Mono.WebServer.ModMonoWorker.InnerRun (System.Object state) [0x0] at Mono.WebServer.ModMonoWorker.Run (System.Object state) [0x0] If I type mod-mono-server in the console, it runs with no problem. What is apache looking for? In the console I get: mod-mono-server Enter Listening on: /tmp/mod_mono_server Root directory: /root Hit Return to stop the server. Thanks, Marco Castro ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcos - http://www.youcannoteatbits.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TDS RPC patch
On Fri, 2007-05-11 at 05:35 -0600, A Nagappan wrote: Hi, Base work of this patch was done by Senganal. Previous Mono ADO.NET maintainer. Thanks for reviewing the patch :) Modified Encoding.ASCII.GetBytes to Encoding.UTF8.GetBytes. This patch should work with MS-SQL 2000 server too, if possible please verify it ? IMHO that would not fix the issue, as the locale/encoding differs between Windows/MSSQL installations, I think the default encoding should be used, Encoding.Default.GetBytes(). That would use the default encoding of the operating system then, or does the protocol require UTF-8? I am not familiar with the TDS protocol specification. -- 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] [PATCH] C# 3.0 Feature: Automatic Properties
On 5/11/07, Raja R Harinath [EMAIL PROTECTED] wrote:
Hi,
Scott Peterson [EMAIL PROTECTED] writes:
This patch implements the automatic properties feature of C# 3.0 as
demoed by Anders Hejlsberg at Mix (http://int1.fp.sandpiper.net/
soma/applications/silverlight/v1/videos/DEV04.wmv at 12 minutes, 40
seconds). Please vet!
+Field current_accessor_field;
+ToplevelBlock make_accessor_block (Expression type, bool get)
+{
+ if (current_accessor_field == null) {
+ current_accessor_field = new Field (current_container,
implicit_value_parameter_type,
+ Modifiers.PRIVATE,
CompilerGeneratedClass.MakeName(CompilerGeneratedField),
+ null, Location.Null);
+ current_container.AddField (current_accessor_field);
+ }
Very messy It's an unnecessary global, with wierd behaviour. Why don't
you move this to the rule itself, and make it a local.
Agreed. This whole patch is actually pretty terrible. I'm refactoring it
soon(ish).
+ Parameter value = new Parameter (type, value,
Parameter.Modifier.NONE, null, Location.Null);
+ Parameters parameters = new Parameters (new Parameter [] { value
});
+
+ ToplevelBlock block = new ToplevelBlock (current_block,
parameters, Location.Null);
+ This t = new This (block, Location.Null);
+ MemberAccess ma = new MemberAccess (t,
current_accessor_field.Name);
The get accessor should not have any parameters.
+ if (get) {
+ Return r = new Return (ma, Location.Null);
+ block.AddStatement (r);
+ }
+ else {
On a stylistic note, we prefer the } and the else to be on line:
} else {
Preferably the only two forms of 'else' that we have in the code are:
else
} else {
Use the second form even when one arm of the 'if' has multiple
statements and the other has only a single statement.
- Hari
--
Scott.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Planning: Mono version numbers.
Hello, I agree that the Mono version will never directly tell a user whether a certain API is usable or not. Instead, this information is distributed over the Bugzilla system and multiple Wiki pages, with most interesting Wiki pages being much too hidden. Personally, I usually end up typing the Wiki page names manually because I often can't find an easy way to navigate to them via the website itself. Therefore I think we rather need a better information policy on what's working and what's planned, targeted at .NET developers (as opposed to the core Mono developers). It might prove helpful to actually create a new progress page, linked from the main page, containing a brief status overview for individual components that are or will and will not be available (e.g. a table with colors detailling status of SVN HEAD and the latest release). Such an overview page could then link to the existing class-level status pages (which has more information than a casual user expects) and to all the existing individual pages describing the actual technologies. Today, there's a Plans page, only linking to technology pages, and there's the slides as a snapshot of what was available and planned at that particular point in time. Given that such status information is provided in a convenient and centralized way, Mono could continue with its own versioning scheme and 1.3.x for the next breaking changes instead of having to talk of a distant-sounding upcoming 2.0 version and holding back breaking changes until then. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] Planning: Mono version numbers.
On Fri, 11 May 2007 21:46:07 +0200, Massimiliano Mantione [EMAIL PROTECTED] scribbled: On Fri, 2007-05-11 at 14:13 -0400, Miguel de Icaza wrote: [...] So what we need is to come up with a new release number scheme for the above. Just my 2c, and it might look really gross... Calling versions major.minor, I'd do the following: - Increment major at release C (compacting GC and API changes), especially because of the API changes. - Increment minor for every other release, number assigned with a first come, first served policy between the releases :-) Trying to assign numbers now, before we know what will be ready first, is inappropriate IMHO. Since it's *likely* that A and B will become ready before the rest, this *could* mean: - 1.4 = Mono A - 1.5 = Mono B - 2.0 = Mono C - 2.1 = Mono whatever comes next... But if the order in which things get ready changes, this scheme changes accordingly. It's not that bad, your scheme :). Personally, I like the way the dynamic libraries on *nix are done. They consist of three parts: ABI_VERSION.INTERFACE_VERSION.RELEASE_NUMBER We increase the first if we break the ABI (either the runtime or the class libraries, or introduce any other breaking changes in the toolchain etc.). We increase the second one if we add new class libraries/methods without breaking the ABI. The third is increased every time we do a release that's netiher #1 or #2 above. Of course, it can lead to version numbers like 2.1.12314, but the version part increase rules can be defined a bit differently to what I outlined above. The idea is that each part of the release version should have a real and clearly defined meaning. marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Planning: Mono version numbers.
Hello, We have basically mixed .NET API-matching features, with our own API features, and with runtime changes. In addition, the 3.x work really will come out completely out of sync: 3.5 is a lot simpler and easier to reach than 3.0 is. Just to confuse everyone even more 3.5 will contain Greed Bits and Red Bits. It means that 3.5 will overwrite 2.0 core libraries like mscorlib too. I did quick diff between 3.5 B1 mscorlib and 2.0 RTM mscorlib and what I found is 25 new methods/properties 1 removed method/property 3 warnings (changed attributes, base classes, etc.) Maybe we need something like this: * Mono A: Estimated 3-4 months of work. The core 2.0 done + ASP.NET 2. 2.0 profile (minus Winforms) becomes officially supported. Mono 1.8 * Mono B: Estimated 6-9 months of work. When Windows.Forms 2.0 is complete Mono 2.0 * Mono C: 9+ months. When the Compacting GC is done Make the runtime embedding API changes here. Hopefully will make it into Mono 2.0 * Mono D: 9+ months. When the new IR/optimization framework is ready Mono 2.2 * Mono E: 6-9 months of work. When System.Core and other 3.5 libraries are finished maybe we could even split this up in chunks. Mono 2.5 I am just not sure whether we should include .NET 3.0 into our releases or keep it separate, e.g. Mono Fx 1.0 Release Regards, Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SafeFileHandle marshalling patch
Hello, This patch adds an empty constructor to SafeFileHandle so it can be marshalled as a return value or an out param for pinvokes. If there is an easy and useful test to write for this in addition to the runtime safehandle tests, let me know. Thanks, Jonathan safehandle.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
