>You misunderstood: embedding the data as a resource in the assemblies is
>not a better solution. The best way is to add an icall:
OK, thanks for the clarification. I really didn't understand you.:) I
believe you that this is faster.:)
Kornél
___
Mon
On 10/13/06 Kornél Pál wrote:
> >I maintain that having the option to store it either embedded in the
> >binary or in data files is better than the proposal to use assembly
> >resources or your proposal of having only external files (which makes
> >it harder to support mkbundle).
>
> I just was th
>The only difference in your proposal is how to store the data.
>I maintain that having the option to store it either embedded in the
>binary or in data files is better than the proposal to use assembly
>resources or your proposal of having only external files (which makes
>it harder to support mkb
On 10/12/06 Kornél Pál wrote:
> Currently I have little time for Mono but I have some ideas about getting
> rid of I18N assemblies:
[...]
> What about these ideas?
The only difference in your proposal is how to store the data.
I maintain that having the option to store it either embedded in the
b
> You failed to read my mail where I explain that my icall solution allows
> adding/removing support for encodings by simply adding/removing data
> files in $prefix/lib/mono/encodings/. The option to include the data
> inside the binary must be always there to support mkbundle or some
> embedded
>
On 10/11/06 Andreas Nahr wrote:
> Well this was my first thought also to do it this way. However
> internal-calls reduce the maintainability of the code, because you have to
> manually ensure it stays in synch and it makes using corelib much harder for
> other projects. So I tried to search for
Andreas Nahr wrote:
> public byte GetByte (char char)
> {
> return table[char];
> }
> Also this would obviously be (much) faster than the current solution (I
> don't know how Atsushi got to the point that this would be slower than
> current code).
How small is the table abov
> On 10/09/06 Andreas Nahr wrote:
>> Current situation:
>> I18N is located in multiple separate assemblies that contain encoding
>> classes that are autogenerated. The single-byte encodings (my current
>> focus) use a potentially big CASE-Structure to compute the output.
>>
>> Problems:
> [...]
>>
On 10/09/06 Andreas Nahr wrote:
> Current situation:
> I18N is located in multiple separate assemblies that contain encoding
> classes that are autogenerated. The single-byte encodings (my current
> focus) use a potentially big CASE-Structure to compute the output.
>
> Problems:
[...]
> Consider
Hi,
Your details would bring good clarification :-)
To my understanding mono assemblies (and hence(?) their embedded
resources) are mmaped when they are loaded. That's what Andreas also
knows, and that's why he is afraid the case if such external resources
that I put on the table are not mmaped
Atsushi Eno wrote:
> I quite don't understand why you speak about the _existence_
> of mmaped external resource loader.
Forgive me for jumping in, but I think he's talking about it because it could
be
a big help without actually wasting a lot of memory/process time.
Now, *is* there a memory-map
Andreas Nahr wrote:
> And I wrote quite extensively in the original post why this is something
> that we definatelly wouldn't want to have.
s:/we/I/;
> Why would embedding them into corelib be a waste of resources? As far as I
> found out this approach should use the minimum amount of resources
Additionally:
If the 10MB are too large there could be the option to split the tables into
a lower and upper table (the middle range is unused by single-byte
encodings) reducing the table size to about 12-16kb.
I don't think its worth it though because in 99% of the cases this just
means tradin
> To not let our thoughts go wrong way: the reason why existing
> I18N.*.dll consist of a bunch of IL code and very few static data
> is just because those conversion tables are just made into a bunch
> of switch-cases.
And I wrote quite extensively in the original post why this is something
that
To not let our thoughts go wrong way: the reason why existing
I18N.*.dll consist of a bunch of IL code and very few static data
is just because those conversion tables are just made into a bunch
of switch-cases.
The encoding conversion tables definitely do not have to reside in
mscorlib.dll. It is
Hi,
Hello,
* Creating the binary data should be simple when generating from a .Net
VM.
Would it be allowed to gernerate directly from MS.Net? From Portable.Net?
(obviously from Mono is no problem, but would not allow to ADD data)
I did not understand this question at all.
Well the questio
Hello,
> * Creating the binary data should be simple when generating from a .Net VM.
> Would it be allowed to gernerate directly from MS.Net? From Portable.Net?
> (obviously from Mono is no problem, but would not allow to ADD data)
I did not understand this question at all.
> * Size of a memma
Hi *,
I've been looking into this topic for quite some time now. However my
knowledge (especially of the internals of the VM) is potentially not enough,
so please correct me if I make wrong statements or assumptions:
Current situation:
I18N is located in multiple separate assemblies that cont
18 matches
Mail list logo
