Hi,
I've implement support for compiled regular expressions in profile 1.x
using dynamic assemblies.
I also have cleaned up the code by removing GetEvalMethod and
CreateEvalMethod methods and moving their functionality to
GetMachineFactory.
I also modified the signature of EmitEvalMethodBo
Hi,
Because of the restrictions of 1.x I modified visibility so I also would
like to set skipVisibility = false in DynamicMethod constructor (not
included in the patch) to avoid 1.x only bugs because of this.
Kornél
Kornél Pál wrote:
> Hi,
>
> I've implement support for compiled regular expre
I think a better approach instead of using dynamic assemblies is to use
dynamic methods on 1.0 as well.
They can be exposed as internal stuff from mscorlib to System and most of
the work will replacing the generic
stuff.
2009/4/2 Kornél Pál
> Hi,
>
> Because of the restrictions of 1.x I modified
Hi,
The runtime has support for generic types in profile 1.0 as well,
OnDeserializedAttribute could also be used, just like new case
insensitive and culture invariant string operations/comparison, static
classes could be supported by profile 1.0 C# compiler because no runtime
support is neede
I think that using public fields instead of private ones costs no work.
Parts of this patch related to dynamic assemblies are just a few lines
that is complete and needs no maintenace. I didn't have to change a
single character in the code generator so the part that really needs
maintenance is n
2009/4/3 Kornél Pál
> I think that using public fields instead of private ones costs no work.
> Parts of this patch related to dynamic assemblies are just a few lines that
> is complete and needs no maintenace. I didn't have to change a single
> character in the code generator so the part that re
Hello,
> I've implement support for compiled regular expressions in profile 1.x
> using dynamic assemblies.
I am curious: how important is 1.0 for you, and why are you using 1.0
instead of 2.0?
We are having a discussion about dropping support for 1.0 from Mono to
make our lives easier and I am
Hi,
I don't really use profile 1.0. On MS.NET you can expect not to have 2.0
installed but since Mono has support for 1.0 and 2.0 at once there is no
need to stick to 1.0.
Over the time resisting generics is more and more difficult.:)
The only reason I've implemented that piece of code was tha
Hello,
Thanks for your comments on the 1.0 profile:
> I believe however that having a stripped down runtime and (partial)
> class library without generics support could be useful in embedded
> scenarios. For example there are routers running Linux with 8 MB RAM and
> 2 MB flash. (I'm not s
> Agreed, but I am not sure that we can serve too many masters at the
> same
> time. Maintaining the 1.0 profile comes at a high cost in terms of
> QA,
> keeping two code paths, making our code harder to read, making it
> harder
> to debug, forcing us to have more tests and so on.
>
> We are
Hello,
> On the iPhone using the 1.0 profile is extremely important to cut
> down on the dll size for mscorlib and friends. Mono already has a big
> payload when using fullAOT and using 2.0 would make it worse. At the
> same time we would like to get features like SGEN GC and other
> optim
On Tue, Apr 7, 2009 at 2:33 PM, Miguel de Icaza wrote:
> Hello,
>
> > On the iPhone using the 1.0 profile is extremely important to cut
> > down on the dll size for mscorlib and friends. Mono already has a big
> > payload when using fullAOT and using 2.0 would make it worse. At the
> > same time
2009/4/7 Aras Pranckevicius
> > The sizes of the mscorlib assemblies are as follows:
> > 1.0 2.0M
> > 2.0 2.5M
> > Silverlight 2.1M
>
> Assembly sizes is one thing (we don't care about those that much on
> iPhone).
>
> Right now with 1.0 profile on the iPhone we have t
> The sizes of the mscorlib assemblies are as follows:
> 1.0 2.0M
> 2.0 2.5M
> Silverlight 2.1M
Assembly sizes is one thing (we don't care about those that much on iPhone).
The "real deal" is how large is fully AOT'ed version. 2.0/Silverlight
profiles do not support fu
Hi,
Can you give us a breakdown of the size of the many files produced
by mono?
Like sizes of the runtime, assemblies after linking/stripping and
AOT'd binaries.
I can't get exact numbers for profile 2.0 because it doesn't work with
mono-2-0 AOT, so best what I can do is to extrapolat
On Wed, Apr 8, 2009 at 11:50 AM, Mantas Puida wrote:
> Hi,
>
>
> Embedding something into AOT'd image (mean linked into main app binary)
> makes everything worse in respect to binary size and maybe memory footprint.
> Maybe I'm missing something in your idea?
>
>
Yes, the idea is to embed more da
>> Embedding something into AOT'd image (mean linked into main app binary)
>> makes everything worse in respect to binary size and maybe memory footprint.
>> Maybe I'm missing something in your idea?
>
> Yes, the idea is to embed more data from the assembly into the AOT image and
> strip/eliminate
2009/4/8 Aras Pranckevicius
> >> Embedding something into AOT'd image (mean linked into main app binary)
> >> makes everything worse in respect to binary size and maybe memory
> footprint.
> >> Maybe I'm missing something in your idea?
> >
> > Yes, the idea is to embed more data from the assembly
Hi,
The new JIT in mono 2.4 generates better/smaller code. Here are some
numbers:
1.0 mscorlib produced by mono 2.0: 3724380
1.0 mscorlib produced by mono 2.4: 3364076
2.0 mscorlib produced by mono SVN HEAD: 4255364
Obviously the mscorlib 2.0 stuff still needs some work, but the 1.0 number
is
19 matches
Mail list logo
