Compilations
Maciej Piechotka
supply it in the direct form which has several disadvantages:
- First time it starts it takes some time to run
- It requires the compilator
I'll try to use hoe (may be in a branch for 0.0.6.1) but if someone
known better tool - please feel free to post (or why hoe is not a good
idea).
Regards
Piotr Sarnacki
with some other libs?
As far as I know jruby users number is growing among merb and
datamapper users so I think that keeping it pure ruby would be best.
Would it be hard to get rid of those C lines?
> < 1KViewDownload
Maciej Piechotka
> Could you list those reasons? Is it used for speed or compatibility
> with some other libs?
>
It is in order to use POSIX locales. There is no ruby mechanism of doing
it so we have to use C interface. Please refer to the Fork providers for
details or simply ask here.
> As far as I know jruby users number is growing among merb and
> datamapper users so I think that keeping it pure ruby would be best.
> Would it be hard to get rid of those C lines?
>
No exactly - as the code is platform-specific. The JRuby-specific code
will be as soon as someone implement it.
Also in the near future the more generic solution (CLDR) will be
developed but I not aware (especially a priori) how it will affect the
performance. If it would not have a great influence we may consider
cleaning the code.
Regards
Alexander Coles
I don't know a better tool just at the moment, but if we can find a
better way, other than infecting the gem with 'hoe' (which I have a
personal aversion to), lets try to find it!
Alex
Alexander Coles
> On Sat, 2008-11-22 at 10:49 -0800, Piotr Sarnacki wrote:
>> Could you list those reasons? Is it used for speed or compatibility
>> with some other libs?
>>
>
> It is in order to use POSIX locales. There is no ruby mechanism of
> doing
> it so we have to use C interface. Please refer to the Fork providers
> for
> details or simply ask here.
>
>> As far as I know jruby users number is growing among merb and
>> datamapper users so I think that keeping it pure ruby would be best.
>> Would it be hard to get rid of those C lines?
>>
>
> No exactly - as the code is platform-specific. The JRuby-specific code
> will be as soon as someone implement it.
With regards to JRuby, Java has pretty comprehensive support for
locales built-in - in the form of the java.util.Locale and related
classes. So, for JRuby, its been my intention to provide a wrapper
around that built-in Java functionality.
See ticket #33: http://trac.ikonoklastik.com/merb_global/ticket/33
Alex
Maciej Piechotka
Well. No C code is in the message providers - and with the exception of
Gettext providers should be relativly cross-platform.
The additional problem with Java is that we would need to transform a
POSIX- and Ruby- oriented date strings "%B %Y" into "MMMM yyyy".
Regards
PS. I read JD of ResouceBounde. Is it needs one class per locale? How
does it affects DDOS?
Alexander Coles
On Nov 23, 2008, at 5:27 PM, Maciej Piechotka wrote:
> On Sun, 2008-11-23 at 17:01 +0100, Alexander Coles wrote:
>>
>> With regards to JRuby, Java has pretty comprehensive support for
>> locales built-in - in the form of the java.util.Locale and related
>> classes. So, for JRuby, its been my intention to provide a wrapper
>> around that built-in Java functionality.
>>
>> See ticket #33: http://trac.ikonoklastik.com/merb_global/ticket/33
>>
>> Alex
>
> Well. No C code is in the message providers - and with the exception
> of
> Gettext providers should be relativly cross-platform.
I have no issues with all of the message providers being cross-
platform except
- gettext - MRI-only (possibly 1.9/Rubinius in the future)
- ResourceBundles - JRuby-only.
I'll try to make sure this is clear in the documentation!
> The additional problem with Java is that we would need to transform a
> POSIX- and Ruby- oriented date strings "%B %Y" into "MMMM yyyy".
I am not completely clear on this point. Is this what you're looking
for?
http://java.sun.com/j2se/1.5.0/docs/api/java/text/MessageFormat.html
> Regards
>
> PS. I read JD of ResouceBounde. Is it needs one class per locale? How
> does it affects DDOS?
The following may be useful for an overview of the Java APIs involved
in internationalizing applications.
http://www.webdevelopersjournal.com/articles/internationalizing_servlets.html
With regards to DDOS
- a Locale object very simply stores language and country codes -- but
no behaviour information. Other classes deal with behaviour.
- the loading of ResourceBundles should not obviously not take place
for each request, but instead on application load, and stored in the
appropriate collection - a java.util.HashMap would allow for
concurrent access.
Alex
Maciej Piechotka
>
> On Nov 23, 2008, at 5:27 PM, Maciej Piechotka wrote:
>
> > On Sun, 2008-11-23 at 17:01 +0100, Alexander Coles wrote:
> >>
> >> With regards to JRuby, Java has pretty comprehensive support for
> >> locales built-in - in the form of the java.util.Locale and related
> >> classes. So, for JRuby, its been my intention to provide a wrapper
> >> around that built-in Java functionality.
> >>
> >> See ticket #33: http://trac.ikonoklastik.com/merb_global/ticket/33
> >>
> >> Alex
> >
> > Well. No C code is in the message providers - and with the exception
> > of
> > Gettext providers should be relativly cross-platform.
>
> I have no issues with all of the message providers being cross-
> platform except
> - gettext - MRI-only (possibly 1.9/Rubinius in the future)
In long time we can add compatible level. But not now.
> - ResourceBundles - JRuby-only.
>
> I'll try to make sure this is clear in the documentation!
>
> > The additional problem with Java is that we would need to transform a
> > POSIX- and Ruby- oriented date strings "%B %Y" into "MMMM yyyy".
>
> I am not completely clear on this point. Is this what you're looking
> for?
> http://java.sun.com/j2se/1.5.0/docs/api/java/text/MessageFormat.html
>
I'm not sure. I looked into:
http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html
Please note that currently we provide much more powerful localization
then short/medium/long format.
> > Regards
> >
> > PS. I read JD of ResouceBounde. Is it needs one class per locale? How
> > does it affects DDOS?
>
>
> The following may be useful for an overview of the Java APIs involved
> in internationalizing applications.
> http://www.webdevelopersjournal.com/articles/internationalizing_servlets.html
>
> With regards to DDOS
> - a Locale object very simply stores language and country codes -- but
> no behaviour information. Other classes deal with behaviour.
> - the loading of ResourceBundles should not obviously not take place
> for each request, but instead on application load, and stored in the
> appropriate collection - a java.util.HashMap would allow for
> concurrent access.
>
> Alex
>
>
I meant missed hits. I've seen it uses ClassLoader.
Rehards
Piotr Sarnacki
Could these lib help to avoid compilation in merb global?
> > With regards to DDOS
> > - a Locale object very simply stores language and country codes -- but
> > no behaviour information. Other classes deal with behaviour.
> > - the loading of ResourceBundles should not obviously not take place
> > for each request, but instead on application load, and stored in the
> > appropriate collection - a java.util.HashMap would allow for
> > concurrent access.
>
> > Alex
>
> I meant missed hits. I've seen it uses ClassLoader.
>
> Rehards
>
> < 1KViewDownload
Maciej Piechotka
> Have you seen FFI? http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html
>
No.
> Could these lib help to avoid compilation in merb global?
>
Yes. And I believe it is in nicer way.
Regards