You requested some numbers because wanted to know the real impact. I sent it
to the list a long ago but I did not receive any response.
Please review the benchmark results and tell me whether this overhead is
worth or is too much.
Kornél
- Original Message -
Sent: Thursday, June 23, 200
I posted this message a long ago. Please review the benchmark results and
tell me whether this overhead is worth or is too much.
Kornél
- Original Message -
From: Miguel de Icaza
From: Ben Maurer
I want to know the real impact (we have the tools, it should take a few
minutes at most
From: Miguel de Icaza
From: Ben Maurer
I want to know the real impact (we have the tools, it should take a few
minutes at most to find out the numbers).
The best way for Kornel to do that (just as an FYI since he has probably
never used the tools) is to run:
mono --stats foo.exe
mono --prof
On Thu, 2005-06-23 at 12:16 -0400, Miguel de Icaza wrote:
> Hello,
>
> > > Also, to apply this kind of patch that will affect everything, I would
> > > like to know in advance the memory footprint (running mono --profile
> > > before/after should tell us this) and how much extra code is JITed at
>
Hello,
> > Also, to apply this kind of patch that will affect everything, I would
> > like to know in advance the memory footprint (running mono --profile
> > before/after should tell us this) and how much extra code is JITed at
> > startup (how much slower this becomes for a sample program).
>
>
Hi all,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Jonathan Pryor
>
> There are four solutions:
>
> - Make `resources' `volatile', which disables any caching the
> processor might do. This effectively makes reads & writes
>
On Thu, 2005-06-23 at 11:18 +0200, Kornél Pál wrote:
> private static ResourceManager GetResourceManager ()
> {
> if (resources == null)
> lock (resourcesLock) {
>if (resources == null)
> resources = new GetTextResourceManager (typeof (Locale).Assembly.GetName
> ().Name, typeof (Locale).
From: Miguel de Icaza
The patch only has one bug as it stands today: it uses a double check
lock, which is race prone:
if (x == null){
lock (...){
if (x == null){
x = Allocate ();
}
}
}
The actual code:
private static ResourceManager GetResourceManager ()
{
if (resources == null)
lock (resourc
On Thu, 2005-06-23 at 00:45 -0400, Miguel de Icaza wrote:
> Also, to apply this kind of patch that will affect everything, I would
> like to know in advance the memory footprint (running mono --profile
> before/after should tell us this) and how much extra code is JITed at
> startup (how much slowe
Hello,
> So please tell me whether you want:
> - drop this patch
> - drop localization at all
> - or approve this patch
The patch only has one bug as it stands today: it uses a double check
lock, which is race prone:
if (x == null){
lock (...){
if
Altough I modified the patch several times it's on the list for 2 weeks.
It does exaclty what you want. Furthermore the current Locale.cs does no
localization at all.
I think this patch was commented enough to can be decided what to do.
So please tell me whether you want:
- drop this patch
- dr
personally don't want to
translate Mono to a bunch of languages.:) But I want to provide an
infrastructure that makes Mono able to be translated.
I attached my latest diff file (the same as in 2005-06-16 11:52 - Re:
[Mono-devel-list] [PATCH] Reworked unified Locale classes). Please have a
lo
First of all lets say this is obviously just my personal optionion:
In the case you want to drop ResourceManager I have the following two
questions:
Why are we working on Mono if we think that it unsuitable for it's own
needs
as well?
I always try to do as much things as possible natively in
Except the case we want to drop the idea of using ResourceManager at all I
think my patch should be reviewed and then committed.
In the case you want to drop ResourceManager I have the following two
questions:
Why are we working on Mono if we think that it unsuitable for it's own needs
as well?
W
From: Ben Maurer
Benchmarks really don't matter here I think. The *only* reason people
would use the Locale class is when an exception gets thrown and we need
to get the error message. Since an exception is 1) exceptional and 2)
already slow, not too much harm in slowing it down more :-).
OK.:)
On Thu, 2005-06-16 at 11:04 -0600, Peter Dennis Bartok wrote:
> >Benchmarks really don't matter here I think. The *only* reason people
> >would use the Locale class is when an exception gets thrown and we need
> >to get the error message. Since an exception is 1) exceptional and 2)
> >already slow,
>Benchmarks really don't matter here I think. The *only* reason people
>would use the Locale class is when an exception gets thrown and we need
>to get the error message. Since an exception is 1) exceptional and 2)
>already slow, not too much harm in slowing it down more :-).
Ben, you are not corre
On Thu, 2005-06-16 at 11:52 +0200, Kornél Pál wrote:
> Hi,
>
> >> Try using [ThreadStatic], it's a bit cleaner.
> >
> > It examined the documentation and it's really cleaner and may be faster as
> > well.
>
> In fact a global lock can be used as well because ResourceManager is thread
> safe and l
Hi,
Try using [ThreadStatic], it's a bit cleaner.
It examined the documentation and it's really cleaner and may be faster as
well.
In fact a global lock can be used as well because ResourceManager is thread
safe and locks itself so this will not degrade performance. In this case no
thread st
private static readonly LocalDataStoreSlot getTextLock =
Thread.AllocateDataSlot ();
Try using [ThreadStatic], it's a bit cleaner.
It examined the documentation and it's really cleaner and may be faster as
well.
I attached a new diff file.
Kornél
Locale.diff
Description: Binary data
__
Try using [ThreadStatic], it's a bit cleaner.
I will examine the documentation regarding this attribute because I did not
know it.
Note that this is required only by corlib to prevent infinite recursion
because Locale.cs uses itself in fact. Normally recursion should not happen
but if something
From: <[EMAIL PROTECTED]>
in MCS we have:
Maybe that would work.
This does not work in VS.NET. Files has to be in the directory or
subdirectories of the project.
For the record, that is not correct; the grandparent is right...
You are right.:) I did not know this before t
On Wed, 2005-06-15 at 21:25 +0200, Kornél Pál wrote:
> private static readonly LocalDataStoreSlot getTextLock =
> Thread.AllocateDataSlot ();
Try using [ThreadStatic], it's a bit cleaner.
After that, we have to look at how much extra code this brings on
startup. Give me a day or two for this (sor
>> in MCS we have:
>>
>>>RelPath = "CryptoConvert.cs"
>>Link =
>> "..\class\corlib\Mono.Security.Cryptography\CryptoConvert.cs"
>>SubType = "Code"
>>BuildAction = "Compile"
>>/>
>>
>> May
From: Ben Maurer
I saw it on the command line, but is it safe to assume that INSIDE_CORLIB
is
allways defined when mscorlib.dll is compiled and INSIDE_CORLIB is never
defined when any other assemblies are compiles?
Yes.
OK, thanks.
Seems to be good.
It was a good decission to leave Locale.c
Hello,
> So I think none of these issues are critical.
None are critical, but there is no compelling reason to use something
different.
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/m
On Wed, 2005-06-15 at 10:21 +0200, Kornél Pál wrote:
> > From: Ben Maurer
>
> > INSIDE_CORLIB is defined :-). You could always look at the commands make
> > runs...
>
> I saw it on the command line, but is it safe to assume that INSIDE_CORLIB is
> allways defined when mscorlib.dll is compiled and
I know little about makefiles and I don't understand what should be
modified
in the makefile.
It doesn't matter, for now. The Makefile will be useful only for
creating the tarball. So, if you check it in, I can take care of the
Makefile part.
An Nth variation was checked in by Ben.
Then, a
I know that gettext () is widely spreaded on Linux but this does not have
to
mean that it is the best solution and the Class Library has it's own
infrastructure for globalization using identifier based resources and
culture based resource files.
I have yet to be convinced that there are any bene
From: Ben Maurer
INSIDE_CORLIB is defined :-). You could always look at the commands make
runs...
I saw it on the command line, but is it safe to assume that INSIDE_CORLIB is
allways defined when mscorlib.dll is compiled and INSIDE_CORLIB is never
defined when any other assemblies are compile
Hi,
Kornél Pál <[EMAIL PROTECTED]> writes:
>> Not much to do, actually :-) Just create a directory class/common and
>> put in a makefile that just distributes the files under its purview.
>
> I know little about makefiles and I don't understand what should be modified
> in the makefile.
It does
Hello,
> I know that gettext () is widely spreaded on Linux but this does not have to
> mean that it is the best solution and the Class Library has it's own
> infrastructure for globalization using identifier based resources and
> culture based resource files.
I have yet to be convinced that ther
On Tue, 2005-06-14 at 19:45 -0600, Peter Dennis Bartok wrote:
> Moving Locale.cs and MonoTODO.cs into a common area will break standalone
> VS.Net projects. Several of the MWF contributors as well as Jordi and I use
> those. I would like to keep MWF self-contained.
Since when has vs.net had issu
t;Kornél Pál" <[EMAIL PROTECTED]>
Cc:
Date: Tuesday, 14 June, 2005 18:50
Subject: Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
>On Mon, 2005-06-13 at 13:14 +0200, Kornél Pál wrote:
>> >> What about a pacth that adds a common Locale.cs copy, modifi
On Mon, 2005-06-13 at 13:14 +0200, Kornél Pál wrote:
> >> What about a pacth that adds a common Locale.cs copy, modifies sources
> >> files
> >> and removes unused Locale.cs files?
> > ...
> > That's exactly what I suggested :-). I think that is the first step.
>
> This patch has to be easy to rev
Le Lundi 13 Juin 2005 15:41, vous avez écrit :
> > >Since this week end,
> >>
> >>I experienced some problems with code charset in ASP.NET pages.
> >>My locales are french :
> >>LANG="fr_FR"
> >>LANGUAGE="fr_FR"
> >>LC_ALL="fr_FR"
> >
> > Is this problem connected to this patch? Or does it occur wi
>Since this week end,
I experienced some problems with code charset in ASP.NET pages.
My locales are french :
LANG="fr_FR"
LANGUAGE="fr_FR"
LC_ALL="fr_FR"
Is this problem connected to this patch? Or does it occur without this
patch
as well?
I know you have written:
This code worked a week ag
Since this week end,
I experienced some problems with code charset in ASP.NET pages.
My locales are french :
LANG="fr_FR"
LANGUAGE="fr_FR"
LC_ALL="fr_FR"
Is this problem connected to this patch? Or does it occur without this patch
as well?
Kornél
___
Since this week end,
I experienced some problems with code charset in ASP.NET pages.
My locales are french :
LANG="fr_FR"
LANGUAGE="fr_FR"
LC_ALL="fr_FR"
I've attached an example of a page made with VS.NET 2003 with a single Label
with an ID : "Début"
It seems like mono doesn't like utf8 characte
Since this week end,
I experienced some problems with code charset in ASP.NET pages.
My locales are french :
LANG="fr_FR"
LANGUAGE="fr_FR"
LC_ALL="fr_FR"
I've attached an example of a page made with VS.NET 2003 with a single Label
with an ID : "Début"
It seems like mono doesn't like utf8 characte
What about a pacth that adds a common Locale.cs copy, modifies sources
files
and removes unused Locale.cs files?
...
That's exactly what I suggested :-). I think that is the first step.
This patch has to be easy to review.
I added the common Locale.cs and I modified the .sources files in all of
Not much to do, actually :-) Just create a directory class/common and
put in a makefile that just distributes the files under its purview.
I know little about makefiles and I don't understand what should be modified
in the makefile.
Then, add a line
../common/MonoTODO.cs
to whichever *.sourc
Hi,
Ben Maurer <[EMAIL PROTECTED]> writes:
> It'd be nice to modify the build system to reduce copy+paste reuse. This
> also happens for, eg MonoTODO.
Not much to do, actually :-) Just create a directory class/common and
put in a makefile that just distributes the files under its purview.
Then
On Sat, 2005-06-11 at 19:54 +0200, Kornél Pál wrote:
> > As I mentioned to you on private email, there is a very big point to
> > doing this. By removing the duplicated code today, your patches tomorrow
> > will be easier for us to read.
> >
> > I'm not suggesting that the Locale.cs today should be
On Sat, 2005-06-11 at 19:04 +0200, Kornél Pál wrote:
> > I think you forgot to svn add the new file.
>
> You are right I forgot it.:) The diff file was simply too large to notice
> the missing file.:) I attached a new diff file.
>
> > I think a good place to start is to check in the common Locale
As I mentioned to you on private email, there is a very big point to
doing this. By removing the duplicated code today, your patches tomorrow
will be easier for us to read.
I'm not suggesting that the Locale.cs today should be what we use
forever. I am suggesting: lets first get one Locale.cs whi
Correction to my previous message:
I'm sure only about 2-3 of the 39 patches to remove unnecessary Locale.cs
files were reviewed at all.
Kornél
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/m
As I mentioned to you on private email, there is a very big point to
doing this. By removing the duplicated code today, your patches tomorrow
will be easier for us to read.
Ok. But the problem is that about 90% of my diff file is just about removing
unnecessary Locale.cs files.:)
And if I were f
On Sat, 2005-06-11 at 12:08 +0200, Kornél Pál wrote:
> I attached a new patch with some modifications in code (most important is
> that CorlibResourceManager is removed and it's functionality is moved to the
> Locale.cs of corlib).
>
> It's other advantage is that I moved the Locale.cs files into
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 ev
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
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 t
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
53 matches
Mail list logo
