[Mono-winforms-list] Month Calendar and NumericUpDown Control
Hey guys, I saw a commit that said NumericUpDown was implemented so I wired it into MonthCalendar (which should now be considered feature complete). Along the way I discovered what I think are bugs in NumericUpDown. If NumericUpDown is not actually complete yet then feel free to ignore these points: - Setting the Value property for the numeric up down control while it's not visible results in that value not being set. I believe the flow is this: Set .Visible = false Set .Minimum .Value now has .Minimum as it's value Set .Value; .Value calls one of the updateedit method which inturn uses a parseedit method which for some reason reads the minimum value as the current text and so .Value gets reset to parsed minimum value. - It's not responding to Readonly property correctly (.ReadOnly = true means up/down buttons work but not text editing. - It seems to render buttons on windows for me, but not on linux - It doesn't seem to be handling the key press events (this may be an issue with the way I'm using it though). There was something else about the way MonthCalendar render's on linux but I can't remember it now. Will send that through when I remember. Regards, JBA ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Important ResourceManager notes
I suggest to have our ResourceManager be smarter than MS's one, and first search non-neutral resources in the main assembly and just try the sattelite ones if not found. That way we are compatible with VS.NET projects generated assembly-sets but can accomodate a basic set of localizations in just one assembly, what would be nicer to compile and package/distribute. Or maybe the order should be reversed to allow for updated localizations being distributed as sattellites and override the basic internal set. Opinions are welcome. :) On 6/10/05, Kornél Pál [EMAIL PROTECTED] wrote: Hi, I am about post an extenive ResourceManager patch. I am still working on the test unit to make discover the correct behaviour of ResourceManager and prevent regressions. There were a lot of differences between Mono and .NET Framework implementation. The most important that will break Managed.Windows.Forms is that neutral resources has to be read from the main assembly any other resources has to be read from the appropriate satellite assembly. System.Windows.Forms.dll contains all the cultures of resources in the main assembly and only the neutral resources will be available in ResourceManager after the patch. Note that this change does not effect GetManifestResourceStream but it should not be used with localizable resources. (Managed.Windows.Forms is not using GetManifestResourceStream for localization) Kornél ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Rafael Monoman Teixeira --- I'm trying to become a Rosh Gadol before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Important ResourceManager notes
How unfortunate... :( On 6/10/05, Matthijs ter Woord (meddochat) [EMAIL PROTECTED] wrote: Mono build assemblies won't be usable localized on ms.net. - Original Message - From: Rafael Teixeira [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-winforms-list@lists.ximian.com Sent: Friday, June 10, 2005 7:34 PM Subject: Re: [Mono-winforms-list] Important ResourceManager notes I suggest to have our ResourceManager be smarter than MS's one, and first search non-neutral resources in the main assembly and just try the sattelite ones if not found. That way we are compatible with VS.NET projects generated assembly-sets but can accomodate a basic set of localizations in just one assembly, what would be nicer to compile and package/distribute. Or maybe the order should be reversed to allow for updated localizations being distributed as sattellites and override the basic internal set. Opinions are welcome. :) On 6/10/05, Kornél Pál [EMAIL PROTECTED] wrote: Hi, I am about post an extenive ResourceManager patch. I am still working on the test unit to make discover the correct behaviour of ResourceManager and prevent regressions. There were a lot of differences between Mono and .NET Framework implementation. The most important that will break Managed.Windows.Forms is that neutral resources has to be read from the main assembly any other resources has to be read from the appropriate satellite assembly. System.Windows.Forms.dll contains all the cultures of resources in the main assembly and only the neutral resources will be available in ResourceManager after the patch. Note that this change does not effect GetManifestResourceStream but it should not be used with localizable resources. (Managed.Windows.Forms is not using GetManifestResourceStream for localization) Kornél ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Rafael Monoman Teixeira --- I'm trying to become a Rosh Gadol before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Rafael Monoman Teixeira --- I'm trying to become a Rosh Gadol before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Important ResourceManager notes
We have a test app in winforms/messagebox, that switches to the german locale, to test reading non-neutral resources. When I run that with our System.Windows.Froms.dll, but with Microsoft's runtime, it does read the non-neutral locale. Doesn't that contradict the statement that MS does not support it? Cheers, Peter -Original Message- From: Rafael Teixeira [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-winforms-list@lists.ximian.com Date: 10 June, 2005 11:34 Subject: Re: [Mono-winforms-list] Important ResourceManager notes I suggest to have our ResourceManager be smarter than MS's one, and first search non-neutral resources in the main assembly and just try the sattelite ones if not found. That way we are compatible with VS.NET projects generated assembly-sets but can accomodate a basic set of localizations in just one assembly, what would be nicer to compile and package/distribute. Or maybe the order should be reversed to allow for updated localizations being distributed as sattellites and override the basic internal set. Opinions are welcome. :) On 6/10/05, Kornél Pál [EMAIL PROTECTED] wrote: Hi, I am about post an extenive ResourceManager patch. I am still working on the test unit to make discover the correct behaviour of ResourceManager and prevent regressions. There were a lot of differences between Mono and .NET Framework implementation. The most important that will break Managed.Windows.Forms is that neutral resources has to be read from the main assembly any other resources has to be read from the appropriate satellite assembly. System.Windows.Forms.dll contains all the cultures of resources in the main assembly and only the neutral resources will be available in ResourceManager after the patch. Note that this change does not effect GetManifestResourceStream but it should not be used with localizable resources. (Managed.Windows.Forms is not using GetManifestResourceStream for localization) Kornél ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Rafael Monoman Teixeira --- I'm trying to become a Rosh Gadol before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Important ResourceManager notes
We have a test app in winforms/messagebox, that switches to the german locale, to test reading non-neutral resources. When I run that with our System.Windows.Froms.dll, but with Microsoft's runtime, it does read the non-neutral locale. Doesn't that contradict the statement that MS does not support it? Cheers, Peter -Original Message- From: Kornl Pl [EMAIL PROTECTED] To: mono-winforms-list@lists.ximian.com Date: 10 June, 2005 00:14 Subject: [Mono-winforms-list] Important ResourceManager notes Hi, I am about post an extenive ResourceManager patch. I am still working on the test unit to make discover the correct behaviour of ResourceManager and prevent regressions. There were a lot of differences between Mono and .NET Framework implementation. The most important that will break Managed.Windows.Forms is that neutral resources has to be read from the main assembly any other resources has to be read from the appropriate satellite assembly. System.Windows.Forms.dll contains all the cultures of resources in the main assembly and only the neutral resources will be available in ResourceManager after the patch. Note that this change does not effect GetManifestResourceStream but it should not be used with localizable resources. (Managed.Windows.Forms is not using GetManifestResourceStream for localization) Kornl ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Important ResourceManager notes
I mean that when I compile the Mono System.Windows.Forms.dll sources with VS.Net, linking in the neutral as well as the EN and DE resources into the assembly (not satellite or whatever, just the regular dll that also contains all the code), and I use the resulting DLL with the winforms/messagebox application, I get localized buttons, so it is obviously reading the non-neutral, localized resources from the main assembly. Peter -Original Message- From: Kornl Pl [EMAIL PROTECTED] To: mono-winforms-list@lists.ximian.com; Peter Dennis Bartok [EMAIL PROTECTED] Date: 10 June, 2005 12:29 Subject: Re: [Mono-winforms-list] Important ResourceManager notes Can you then explain why I get localized resources out of the main assembly when runnin on MS? Run the winforms/messagebox testcase, with the Mono SWF dll and the MS runtime. (1) Do you mean that when you compile it on MS.NET localized resources won't be added to the main assembly? (2) Or just that localized resources cannot be loaded with ResourceManager from the main assembly on MS.NET runtime? If you mean case (2) I already have answered the question: It reads neutral resources only from the main assembly and reads localized resources only from the appropriate satellite assembly. If you mean case (1) please let me know because it would be a very strange difference. As I can remember this behaviour is documented somewhere in .NET Framework SDK but not in the reference of ResourceManager. Kornl -Original Message- From: Kornl Pl [EMAIL PROTECTED] To: Peter Dennis Bartok [EMAIL PROTECTED]; mono-winforms-list@lists.ximian.com Date: 10 June, 2005 12:02 Subject: Re: [Mono-winforms-list] Important ResourceManager notes We have a test app in winforms/messagebox, that switches to the german locale, to test reading non-neutral resources. When I run that with our System.Windows.Froms.dll, but with Microsoft's runtime, it does read the non-neutral locale. Doesn't that contradict the statement that MS does not support it? ..NET Framework does the same I want to implement (in fact I already implemented it but I don't want to send a patch until I finish reworking the whole ResourceManager to be MS.NET compatible). It reads neutral resources only from the main assembly and reads localized resources only from the appropriate satellite assembly. This is a very big difference. Kornl -Original Message- From: Kornl Pl [EMAIL PROTECTED] To: mono-winforms-list@lists.ximian.com Date: 10 June, 2005 00:14 Subject: [Mono-winforms-list] Important ResourceManager notes Hi, I am about post an extenive ResourceManager patch. I am still working on the test unit to make discover the correct behaviour of ResourceManager and prevent regressions. There were a lot of differences between Mono and .NET Framework implementation. The most important that will break Managed.Windows.Forms is that neutral resources has to be read from the main assembly any other resources has to be read from the appropriate satellite assembly. System.Windows.Forms.dll contains all the cultures of resources in the main assembly and only the neutral resources will be available in ResourceManager after the patch. Note that this change does not effect GetManifestResourceStream but it should not be used with localizable resources. (Managed.Windows.Forms is not using GetManifestResourceStream for localization) Kornl ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Important ResourceManager notes
Kornel, You are correct. I had not noticed that VS.Net does in fact create the subdirs with satellite assemblies. Our (potential) problem then becomes that we need to make sure that our gac supports satellite assemblies, and that we can teach our build system to produce those (at least for MWF where we have more than one) Cheers, Peter -Original Message- From: Kornl Pl [EMAIL PROTECTED] To: mono-winforms-list@lists.ximian.com; Peter Dennis Bartok [EMAIL PROTECTED]; Rafael Teixeira [EMAIL PROTECTED] Date: 10 June, 2005 14:37 Subject: Re: [Mono-winforms-list] Important ResourceManager notes From: Rafael Teixeira Kornel you are not understanting Peter words. It says Managed.Windows.Forms RUNS in german in MS.NET!!! Here is several hours later and I was too tired to understand.:)) But now I understand what you mean.:) From: Peter Dennis Bartok I mean that when I compile the Mono System.Windows.Forms.dll sources with VS.Net, linking in the neutral as well as the EN and DE resources into the assembly (not satellite or whatever, just the regular dll that also contains all the code), and I use the resulting DLL with the winforms/messagebox application, I get localized buttons, so it is obviously reading the non-neutral, localized resources from the main assembly. You are right that you will be able to use both English and German resources when you compile it using Visual Studio .NET but it's because VS.NET is smart enough to create satellite assemblies automatically for each culture. Try the attached project. Compile it using VS.NET. You will get the result in bin\... and there will be a hu directory with the satellite assembly. You can examine the exe with ildasm to see that there is only the neutral resuorce, no Hungarian. Then compile it using build.bat (I included this exe variant in the zip precompiled). It will create the exe in the directory of sources. There will be no satellite assemblies and it will contain the Hungarian resources as well. You can examine it using ildasm. Neutral resource contains a single resource named CultureName with the value neutral. Hungarian resource contains a single resource named CultureName with the value hu. InternalGetResourceSet falls back to neutral (in fact parent) resources if you haven't got the appropriate satellite assembly and GetString falls back to neutral (in fact parent) resources if you have the appropriate satellite resource but it does not contain the requested string. You can examine the output of the exe. Kornl ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-devel-list] Re: [GENERICS] a problem with binding generic types
On 6/9/05, Michal Moskal [EMAIL PROTECTED] wrote:
Hello,
During making Nemerle work with Mono generics, I've stumbled across
something that seems to be a bug in Mono runtime.
Inside:
mono_reflection_bind_generic_parameters (MonoReflectionType *type,
int type_argc, MonoType **types)
there is a call:
the_parent = mono_reflection_bind_generic_parameters (parent,
type_argc, types);
Which doesn't seem right. That is if you have a class:
class FooA : Bar int, A { }
then you call mono_reflection_bind_generic_parameters(Foo, 1, [A]),
but mono_reflection_bind_generic_parameters(Bar, 1, [A]) is not right
because there is not enough type parameters.
I may be wrong -- it may be bug somewhere else in my code, I just want to
make sure about it.
I was :-)
The second call is something like:
mono_reflection_bind_generic_parameters(Barint,A, 1, [A])
--
Michal Moskal,
http://nemerle.org/~malekith/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Debugging Asp.Net Web Apps on Linux
I'm probably not doing it right either, but the way I do it is a simple Log file built using a StringBuilder so you can see where it breaks... As far as I know there is a debugger being worked on at the mo but it isnt advanced enough to step through - maybe Im completely wrong though ;) Martin On 6/8/05, Michael Wu [EMAIL PROTECTED] wrote: Hi, I wanted to know how people are debugging asp.net web apps on Linux. I'm currently using VisualStudio to build/debug/test on Windows. Then, I copy the web app folder to Linux and run it from xsp. I've been getting by using log4net to log to a text file, but now I need to step through code on Linux. Is anybody doing this? Any instructions, tips, and ideas would be appreciated. Thanks, mw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Martin Hinks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] TypeBuilder.GetMethod and other updates for .NET 2.0 beta2 API
On Thu, 2005-06-09 at 17:43 +0200, Kamil Skalski wrote: Sorry you had problems merging this patch. It was created against 45614. Seems like Zoltan was faster in adding some of the similar API: http://galactus.ximian.com/pipermail/mono-patches/2005-June/059635.html in 45626 Hello, just committed the new version of the patch. Sorry about yesterday's breakage, I was in a very bad mood and also didn't have any time to test it before committing. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [PATCH] ResourceManager - minor fix
Hi, MissingManifestResourceException should not be thrown in InternalGetResourceSet when (tryParents == false). This patch is required by my unified Locale classes. Kornl ResourceManager.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] NUnit test policy
Hey everyone, I think its high time for a reminder about the NUnit testing policy. At all times, the NUnit tests in the following libraries will pass on svn head: * corlib * Commons.Xml.Relaxng * Cscompmgd * Microsoft.JScript * Mono.Posix * Mono.Security * System.Configuration.Install * System.Runtime.Remoting * System.Runtime.Serialization.Formatters.Soap * System.Web * System.Web.Services (this is from centum_tests in mcs/Makefile). On SVN, we've had quite a few regressions in the nunit tests recently, especially in the corlib area. Most of these seem to not be actual code regressions (mis-modifications of the test suite mostly). However, false alarms cause just as much pain. It is extremely important that *before* checking in a patch to svn in one of these modules -- especially corlib -- you run the test suite on your machine. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
It'd be nice to modify the build system to reduce copy+paste reuse. This also happens for, eg MonoTODO. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-winforms-list] Important ResourceManager notes
We have a test app in winforms/messagebox, that switches to the german locale, to test reading non-neutral resources. When I run that with our System.Windows.Froms.dll, but with Microsoft's runtime, it does read the non-neutral locale. Doesn't that contradict the statement that MS does not support it? Cheers, Peter -Original Message- From: Kornl Pl [EMAIL PROTECTED] To: mono-winforms-list@lists.ximian.com Date: 10 June, 2005 00:14 Subject: [Mono-winforms-list] Important ResourceManager notes Hi, I am about post an extenive ResourceManager patch. I am still working on the test unit to make discover the correct behaviour of ResourceManager and prevent regressions. There were a lot of differences between Mono and .NET Framework implementation. The most important that will break Managed.Windows.Forms is that neutral resources has to be read from the main assembly any other resources has to be read from the appropriate satellite assembly. System.Windows.Forms.dll contains all the cultures of resources in the main assembly and only the neutral resources will be available in ResourceManager after the patch. Note that this change does not effect GetManifestResourceStream but it should not be used with localizable resources. (Managed.Windows.Forms is not using GetManifestResourceStream for localization) Kornl ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] -langversion defaults
Hey, I think for the 1.1.x series, we need to make mcs assume a -langversion:ISO-1 default. This would be really helpful for people building applications that should work with .net 1.1. It seems (maybe I am wrong) that if you are building a .net 1.1 app, you use mcs, and if you are building a .net 2.0 app, you use gmcs. Maybe that isn't the end goal, but it certainly seems to be the current way of doing things. Enforcing -langversion:ISO-1 as a default would go a long way to help solving some of those issues. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] -langversion defaults
Also mcs allows things that csc 1.1 doesn't allow as shorter delegate instatiation. I also vote to have -langversion:ISO-1 for all 1.1 builds with mcs. On 6/10/05, Todd Berman [EMAIL PROTECTED] wrote: Hey, I think for the 1.1.x series, we need to make mcs assume a -langversion:ISO-1 default. This would be really helpful for people building applications that should work with .net 1.1. It seems (maybe I am wrong) that if you are building a .net 1.1 app, you use mcs, and if you are building a .net 2.0 app, you use gmcs. Maybe that isn't the end goal, but it certainly seems to be the current way of doing things. Enforcing -langversion:ISO-1 as a default would go a long way to help solving some of those issues. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I'm trying to become a Rosh Gadol before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
From: Rafael Teixeira We could just have this pair of sources mcs/class/all/Assembly/Locale.cs mcs/class/all/Assembly/MonoTODO.cs and have it added in the makefile along with the .sources list for each compiling. Just keep those global things to a minimum, as it will duplicate cil-bytecode on every assembly, but that is at-least in the System.*/Microsoft.* family a necessity not to expose an incompatible dependency. Refining it a bit... For the Mono.*/Commons/* families of assemblies we could put those two source, in a ? Mono.Core.dll ? that is referenced by all of them. Thoughts? I think this is little overhead in bytes so we can compile them into all of the assemblies. Modifying makefile to use a single copy is a good thing. If someone is morefamiliar with makefiles than me please implement this. Kornél On 6/10/05, Kornél Pál [EMAIL PROTECTED] wrote: It'd be nice to modify the build system to reduce copy+paste reuse. This also happens for, eg MonoTODO. My only problem is I don't know these Linux build utilities at all and the most complex thing I can do is to add a new file to the .sources files.:) Is there some good documentation or guide to them? I even don't know how much build targets are there in Mono build system and I did not found an explanation. Is it documented somewhere? Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I'm trying to become a Rosh Gadol before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ 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-devel-list] System.Web/System.Web.UI - patch (code synchronization between Mono and Mainsoft)
Hi, All! Rafael's guess is correct. Since Java doesn't support structs at all - we are forced to use classes instead of all ValueTypes. In case of struct array initialization - our converter (which converts MSIL = Java bytecode) generates "hidden" helper functions which initialize each element of array before first usage of such array. Ilya. Rafael Teixeira wrote: I maybe due to the fact that Java, doesn't have value objects other than the basic crowd (int, long, double, float...), and to be able to have the value semantics GH has to create lots of imuttable/cloneable/value-comparable objects... Just guessing... On 6/9/05, Ben Maurer [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 19:05 -0400, Gonzalo Paniagua Javier wrote: On Wed, 2005-06-08 at 14:11 +0300, Ilya Kharmatsky wrote: Please review the patch. BTW, in HtmlTextWriter.cs we changed internal structs (e.g. RenderStyle) to be the classes and not structs - this in order to resolve heavy performance problem in our implementation of initialization of arrays of structs. May be the better idea is to change also original mono code - since in this case we can avoid additional "splitting" of code between standard and J2EE configuration. I think impact of this won't be too high - from perspective of memory consumption and performance. RenderAttribute, TagInformation and RenderStyle might be ok as classes. As you say, this is no big deal. Feel free to make those classes if nothing breaks. What exactly do you guys do when initing an array of structs that is so slow? In this case, chances are, performance won't suffer that much. It does make our GC do more work than it needs to (and it is already pretty heavy on stuff). However, there are cases where using arrays of structs will give us a large benefit in C#. So it would make sense to figure out what is happening, rather than to shove it under the rug. -- Ben ___ 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-devel-list] System.Web/System.Web.UI - patch (code synchronization between Mono and Mainsoft)
On Sat, 2005-06-11 at 00:50 +0300, Ilya Kharmatsky wrote:
Hi, All!
Rafael's guess is correct. Since Java doesn't support structs at all -
we are forced to
use classes instead of all ValueTypes. In case of struct array
initialization - our converter
(which converts MSIL = Java bytecode) generates hidden helper
functions
which initialize each element of array before first usage of such
array.
What if you split up such arrays. IE:
struct X {
int a; int b; int c;
}
X [] foo;
Turns into:
int foo_A [];
int foo_B [];
int foo_C [];
The optimization of handling structs should take place in the .net -
java converter, not in our source code.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.UI - patch (code synchronization between Mono and Mainsoft)
What if you split up such arrays. IE:
struct X {
int a; int b; int c;
}
X [] foo;
Turns into:
int foo_A [];
int foo_B [];
int foo_C [];
It is complicated task in perspective of our conveter - if it will use
you suggestion, it should
remember the context of each foo_X array (in order for example to call
proper functions etc.)
The optimization of handling structs should take place in the .net -
java converter, not in our source code.
And if usage of structs in specific place in our source code is
optional? I'm talking about specific
case. This is not general proposal for optimization in every place,
where arrays of structs are used!
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Web/System.Web.UI - patch (code synchronization between Mono and Mainsoft)
On Sat, 2005-06-11 at 01:46 +0300, Ilya Kharmatsky wrote:
What if you split up such arrays. IE:
struct X {
int a; int b; int c;
}
X [] foo;
Turns into:
int foo_A [];
int foo_B [];
int foo_C [];
It is complicated task in perspective of our conveter - if it will use
you suggestion, it should
remember the context of each foo_X array (in order for example to call
proper functions etc.)
Ugh, yeah, that would be ugly.
Easier way to do it: when you init the array, create all the objects:
so you say:
MyStructType [] x = new MyStructType [10]
for (...)
x [i] = new MyStructType ();
The optimization of handling structs should take place in the .net -
java converter, not in our source code.
And if usage of structs in specific place in our source code is
optional? I'm talking about specific
case. This is not general proposal for optimization in every place,
where arrays of structs are used!
Do you have benchmarks showing that this affects stuff by more than
(say) 5% per request? This doesn't look like a perf critical area
really.
Even if code is in what is effectively #if 0, it has a cost. It makes
our code harder to read, means that people must think about more code
paths, and most importantly, increases the chances that a patch will
cause a regression in your runtime.
BTW, doesn't this show up with Hashtable, which also uses an array of
structs?
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] StackTraces - remove some localization
On Fri, 2005-06-10 at 15:47 +0200, Kornl Pl wrote: Hi, First of all .NET Framework does not localize these stack trace outputs. Furthermore Exception.StackTrace is used by the runtime to print stack trace when there is an error. As the localization framework (Locale, ResourceManager, ResourceSet, ...) it self can throw exceptions no exception Writing to the console can also throw an exception so... should we not print the exception? ;-) will be displayed when exception occurs in these classes when used to localize the texts of stack traces that are representing exceptions caused by them. This does not cause infinite loop, but no stack trace will be displayed when the runtime terminates because of an unhandled exception. GetTexts that I leaved in these classes can be used safely and these texts are localized by .NET Framework as well. Note that I discovered this weaknes while workin on new unified Locale classes for the whole class library. And they cannot be used until this patch is applied. So I was 2 hours out and there was a debate on changing the I18N rules? Quite some time ago, it was decided to be that way. If we're changing that I'd like some debate action here. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] dealing with csproj files with mono
Try MonoDevelop for Linux or SharpDevelop for Windows - both can import Visual Studio.NET Project files and then compile it via a simple menu option. Martin On 6/8/05, Gaudet Michael-MGAU01 [EMAIL PROTECTED] wrote: Hello! I am trying to get around with mono, and I would like to figure out if it exists some tools to deal with VisualStudio.net projects dependencies with mono. I heard about prj2make which converts, if I understood, vcproj files to makefiles for mono, but does it deals with the project dependencies? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Martin Hinks ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Need help getting Mono working on Windows
Have you tried with just a simple Hello World test? Try mono --help Should work however with mono HelloWorld.exe If that doesnt work, post back with more info Martin On 6/8/05, Nicholas Ulle [EMAIL PROTECTED] wrote: I'm trying to set up Mono on Windows XP Home SP1, but I can't seem to get it to work. The install runs okay, and mcs works (either using the Mono command prompt or the windows command prompt with the bin added to PATH), but I can't run any compiled applications (tried double-clicking them, tried mono filename with the Mono command prompt). The error I get is The application failed to initialize properly (0xc135). Click on OK to terminate the application. I tried reinstalling, and installed it so that there are no spaces in the filepath (e.g. F:\Programs\Mono\). I also checked the MD5 of the installer, it is not corrupted. This really has me stumped. Thanks, N. Ulle ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Martin Hinks -- Martin Hinks ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] P/Invoke, Mono, .NET and Windows XP funny platform
Your fundamental problem is that you're targeting Windows XP. Ha ha only serious. (A colloquialism for that's funny, but I'm serious too...) The slightly longer explanation is here: http://www.mono-project.com/Interop_with_Native_Libraries#Windows_DLL_Search_Path The real explanation is that Win32 is broken when it comes to supporting multiple different versions of the same library. Absolutely, fundamentally, *broken*. More to the point, it doesn't support this AT ALL -- you can only have ONE version of any given library in use at any point in time. Win32 has three issues you're running into: 1. No built-in versioning support for libraries, as noted above. Which is to say, if you load C:\Windows\System32\OLE32.dll, you can't say that you want version 1 or version 2 of that library, you get whichever version is at C:\Windows\System32\OLE32.dll. 2. This doesn't mean you can't have multiple different versions installed. It just means that each different version needs to reside in a different directory, which leaves you the option of (a) always specifying a full (or relative) directory for your library, or (b) accepting the default path and placing your library into an appropriate location. So if you didn't like Microsoft's OLE32.DLL, you could place a copy into your application's directory, and *that* one would get loaded. Alas, this means you can have the scenario you're describing, where both mono and your app bundle glib. This is unfortunate, because of issue (3). 3. Win32 doesn't keep track of the full path name to a library. It only remembers the basename of the library. Translation: If you LoadLibrary() C:\mono\glib.dll, Win32 will know that it's loaded glib.dll. If you then LoadLibrary() C:\yourapp\glib.dll, Win32 will hand you back a handle to C:\mono\glib.dll, because they both share the same basename (glib.dll) -- C:\yourapp\glib.dll is NOT loaded. Win32 doesn't operate on full paths. This is a feature (in certain contexts, anyway -- it's what allows you to provide your own version of OLE32.dll, or any other system library, and have it be used). So, to answer your questions... On Thu, 2005-06-09 at 19:23 +0200, Francis Brosnan Blzquez wrote: * Any application which p/invokes libraries that are also provided by mono must compile its native dll versions against the mono dll or it is posible to compile these ones against, for example, a glib not provided by the mono installer? Is it possible? Yes. But to use your version of glib and not mono's version, you'd need to alter the library search order for mono to ensure it loads your version of glib and not mono's. This probably is bad, because it will effect every application started with mono, and your glib might not be compatible with mono's glib, which would (likely) kill mono instantly. So it's possible, but it's not advisable. :-) Plus, it'll use extra disk space, so it would be nicer to use mono's glib anyway... Alternatively, name your glib.dll with a different basename, e.g. af- arch-glib.dll, and rebuild all your libraries against this basename. * What happens if the mono runtime detects a P/Invoke over a library A.dll which depends on B.dll and then another P/Invoke over the library C.dll which depends on B'.dll knowing that B.dll and B'.dll are the same library but not the same file? Mono isn't in control of library loading, Win32 is. (Mono uses GLib's g_module API, which in turn uses LoadLibrary().) So, what would Win32 do? It would load A.dll (as found through the normal DLL search path), would look for and load B.dll (ditto), and when C.dll was loaded it would see that B.dll was already loaded, and not load a new one, so C.dll would get the *first* B.dll that was ever loaded. In short, don't do that. :-) (I'm not entirely sure why this works for you on Linux either, unless you depend on a different version of glib than mono does, in which case you'd bring in a different .so-name. However, given that Linux/ELF doesn't require a symbol to come from a given library, and instead matches a symbol reference to ANY MATCHING SYMBOL within the address space, I fail to see how, if B.so.2 is already loaded, when C.so.1 is loaded and brings in B.so.3, you could ensure that C.so.1 actually uses the functions in B.so.3 and not B.so.2, since the dynamic linker should find the B.so.2 symbols first... Madness, I say. :-) - Jon ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] ParseExact functionality
I'm having a problem converting an ldap date string into a C# DateTime under mono. The function I'm using is: DateTime.ParseExact(20050707132527Z, MMddHHmmss\\Z, System.Globalization.DateTimeFormatInfo.CurrentInfo); Under mono, this throws an Invalid Format exception, but it works fine under Microsoft .NET. Same thing using System.Globalization.DateTimeFormatInfo.InvariantInfo Thx... HH ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] P/Invoke, Mono, .NET and Windows XP funny platform
Jonathan Pryor wrote: Your fundamental problem is that you're targeting Windows XP. The real explanation is that Win32 is broken when it comes to supporting multiple different versions of the same library. Absolutely, fundamentally, *broken*. More to the point, it doesn't support this AT ALL -- you can only have ONE version of any given library in use at any point in time. I don't know if this is relevant to the discussion but, AFAIK, since WinXP there is support for versioning libraries. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/isolated_applications_and_side_by_side_assemblies_start_page.asp Regards, Jeroen ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Compiling From SVN
I got the libiculatest and libiculatest-dev from dselect (apt-get). I'm having the same problems. Are these the wrong packages or do I need to point autogen.sh to the correct lib location? Thanks. -Abe On 6/10/05, Paul [EMAIL PROTECTED] wrote: Hi, Running autogen.sh in /mono gives me: mono/mini/Makefile.am:86: variable `ICU_LIBS' not defined Grab a copy of ICU (and ICU devel) from the IBM website. TTFN Paul -- Space, it says, is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big space really is. I mean, you may think it's a long way down the road to the chemists, but that's just *peanuts* compared to space, listen - Hitch Hikers Guide to the Galaxy BodyID:82042174.2.n.logpart (stored separately) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Authentication with mono
On Fri, 2005-06-10 at 13:41 -0400, Harry Holt wrote: Are you trying to authenticate against Ldap? If so, you can use the LdapCsharp library from novellforge: http://forge.novell.com/modules/xfmod/project/?ldapcsharp This is good now if I can find something that would do the same with Samba that would be great. -- George Farris [EMAIL PROTECTED] Malaspina University-College ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Compiling From SVN
Hi, I got the libiculatest and libiculatest-dev from dselect (apt-get). I'm having the same problems. Are these the wrong packages or do I need to point autogen.sh to the correct lib location? They should just be picked up (assuming umbutu installs in the correct place that is). Try compiling from source and installing in /usr and see if that helps. TTFN Paul -- Space, it says, is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big space really is. I mean, you may think it's a long way down the road to the chemists, but that's just *peanuts* compared to space, listen - Hitch Hikers Guide to the Galaxy signature.asc Description: This is a digitally signed message part ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Reporting Engine
On Wed, 2005-05-25 at 08:12 -0400, Farzad Battiwalla wrote: Does anyone know of a good reporting engine for Mono ? - I'm looking for something similar to Jasper Reports for Java, but on Dot Net. I'd also like it to be cross-platform, however, running on Linux is more important. You may be able to use Jasper Reports itself, by compiling it with IKVMc into CLI assemblies (beware, it may get very very big) Never tried but it sure merits being experimented... :) -- Rafael Monoman Teixeira Mono Hacker since 16 Jul 2001 - http://www.mono-project.com/ Mono Brasil Founding Member - http://monobrasil.softwarelivre.org/ Simios Proud Member - http://www.simios.org/ English Blog: http://monoblog.blogspot.com/ Brazilian Portuguese Blog: http://www.simios.org/blog/monoman ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Deployment question
Steve, this is supposed to be exactly that: a program called mkbundle is included to assist with combining the runtime into the executable. Unfortunately, I have never gotten this to work on Windows or Linux with even a simple hello world command line program. I'll try and see if there are any updates in the changelog. If there are, I will post them. J At 05:16 PM 6/6/2005 +0200, you wrote: Hello, Is there any method for deploying just the mono runtime (mono or mint) and an application on a target machine? Essentially, just enough of mono to run the application, but not so much that it's a huge installation. I am interested in doing this on both Macintosh and Windows machines. -- Steve. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.7 - Release Date: 6/10/2005 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
