Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

[Colin Alworth]

Thanks Manolo - in the course of his updates, Ahmad went over the patch
file used previously and found the changes to either be already merged
or entirely incompatible - no one objected to simply switching to the
stock version of CLDR, so that's what was done instead.
Goktug did some quick checking internally but didn't find anything right
away, I owe him a more in-depth writeup of what we think will point at
the tool which had been used in the past.
--
  Colin Alworth
  co...@colinalworth.com



On Mon, Dec 17, 2018, at 4:22 PM, Manuel Carrasco Moñino wrote:
> Sorry for the late reply. 
> In theory the process is: google modifies original cldr distribution
> per version, and gives a patch to us, then we run our generator and
> commit modified files.> We don't run any python script, hence 
> TimeZoneConstants.properties
> should have been always provided by google.> I don't remember how that file 
> in my commit was generated, apparently
> we should have some utility file for that, I have checked out to
> previous commit snapshot, patch cldr with goole patch, and run tools
> to generate files, though TimeZoneConstants.properties is not
> generated. It's so long ago that I don't conserve original tree with
> some program I could have utilised for that.  CC-ed J.A. Tamplin, he
> might remember about if there was some parallel utility.> I'll try to 
> investigate further though
> 
> - Manolo
> 
> 
> On Sat, Dec 8, 2018 at 12:50 PM Ahmad Bawaneh
>  wrote:>> I think in the GWT2 context we can just generate 
> a new file with the
>> same old tool with updated data, but in the GWT3 context i think we
>> need to think of another approach.>> few weeks ago i was working on a 
>> JodaTime emulation for GWT, one part
>> of that work was the generation of time zone info, i managed to build
>> a tool to generate them based on JodaTime runtime time zone info
>> provider which instead of creating run time instances i made the code
>> emit source code and it worked, i still think it could be made better
>> by implementing a wrapper instead of changing the code itself, anyway
>> .. the time zones info in joda time was based on iana database, and
>> joda time is a will maintained and regularly updated and reliable, so
>> we can use that as a base for a generator instead if inventing the
>> whole wheel.>> 
>> in my approach i was generating a class per time zone which a factory
>> class to get a time zone by id, but if we still think that the JSON
>> constants is a better approach we still can generate the JSONs from
>> those files.>> 
>> this is just a thought that i had as i was working on emulating
>> joda time.>> 
>> On Friday, December 7, 2018 at 5:17:20 PM UTC+2, Thomas Broyer wrote:>>> We 
>> may want to generate that file using java.time.ZoneId then; WDYT?>>> 
>>> On Friday, December 7, 2018 at 3:55:50 PM UTC+1, Colin Alworth
>>> wrote: I messaged Manolo this morning after seeing this, and in gitter
 where we're talking about this. 
 From some digging in history, an old copy of the properties file
 referenced pytz2011n, which looks like it might be a specific
 release of pytz. The commit message Manolo made had a reference to
 some internal Google python script, which I'm guessing takes that
 pytz library/database (looks like they also just reference iana)
 and makes the .properties file, and updates the interface that
 points at the file. 
 The commits for  previous changes went through google code and were
 imported to git, so I'm not sure we can find much more public
 commentary. 
 --
   Colin Alworth
   co...@colinalworth.com
 
 
 
 On Fri, Dec 7, 2018, at 8:32 AM, Thomas Broyer wrote:
> 
> 
> On Friday, December 7, 2018 at 1:54:09 PM UTC+1, Ahmad Bawaneh
> wrote:>> Anyone know what is generating TimeZoneConstants.properties, 
> it
>> says it is generated from CLDR version 25 .. but i cant find any
>> thing that generates this gile in gwt code nor in gwt-tools code,
>> was it generated externally?> 
> Have you tried pinging Manolo? He's the last one to have updated
> the file, maybe he remembers the details. Either him or John
> Tamplin.> 


> --
> You received this message because you are subscribed to the Google
> Groups "GWT Contributors" group.> To unsubscribe from this group and 
> stop receiving emails from it,
> send an email to google-web-toolkit-
> contributors+unsubscr...@googlegroups.com.> To view this discussion 
> on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/af65bf54-2dbb-4dc0-9833-1064e21b207a%40googlegroups.com[1].>
>  For more options, visit https://groups.google.com/d/optout.
 
>> 


>> --
>>  You received this message because you are subscribed to the Google
>>  Groups "GWT Contributors" group.>>  To unsubscribe from this group and stop 
>> receiving emails from 

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

[Manuel Carrasco Moñino]

Sorry for the late reply.
In theory the process is: google modifies original cldr distribution per
version, and gives a patch to us, then we run our generator and commit
modified files.
We don't run any python script, hence TimeZoneConstants.properties should
have been always provided by google.
I don't remember how that file in my commit was generated, apparently we
should have some utility file for that, I have checked out to previous
commit snapshot, patch cldr with goole patch, and run tools to generate
files, though TimeZoneConstants.properties is not generated. It's so long
ago that I don't conserve original tree with some program I could have
utilised for that.  CC-ed J.A. Tamplin, he might remember about if there
was some parallel utility.
I'll try to investigate further though

- Manolo


On Sat, Dec 8, 2018 at 12:50 PM Ahmad Bawaneh  wrote:

> I think in the GWT2 context we can just generate a new file with the same
> old tool with updated data, but in the GWT3 context i think we need to
> think of another approach.
> few weeks ago i was working on a JodaTime emulation for GWT, one part of
> that work was the generation of time zone info, i managed to build a tool
> to generate them based on JodaTime runtime time zone info provider which
> instead of creating run time instances i made the code emit source code and
> it worked, i still think it could be made better by implementing a wrapper
> instead of changing the code itself, anyway .. the time zones info in joda
> time was based on iana database, and joda time is a will maintained and
> regularly updated and reliable, so we can use that as a base for a
> generator instead if inventing the whole wheel.
>
> in my approach i was generating a class per time zone which a factory
> class to get a time zone by id, but if we still think that the JSON
> constants is a better approach we still can generate the JSONs from those
> files.
>
> this is just a thought that i had as i was working on emulating joda time.
>
> On Friday, December 7, 2018 at 5:17:20 PM UTC+2, Thomas Broyer wrote:
>>
>> We may want to generate that file using java.time.ZoneId then; WDYT?
>>
>> On Friday, December 7, 2018 at 3:55:50 PM UTC+1, Colin Alworth wrote:
>>>
>>> I messaged Manolo this morning after seeing this, and in gitter where
>>> we're talking about this.
>>>
>>> From some digging in history, an old copy of the properties file
>>> referenced pytz2011n, which looks like it might be a specific release of
>>> pytz. The commit message Manolo made had a reference to some internal
>>> Google python script, which I'm guessing takes that pytz library/database
>>> (looks like they also just reference iana) and makes the .properties file,
>>> and updates the interface that points at the file.
>>>
>>> The commits for previous changes went through google code and were
>>> imported to git, so I'm not sure we can find much more public commentary.
>>>
>>> --
>>>   Colin Alworth
>>>   co...@colinalworth.com
>>>
>>>
>>>
>>> On Fri, Dec 7, 2018, at 8:32 AM, Thomas Broyer wrote:
>>>
>>>
>>>
>>> On Friday, December 7, 2018 at 1:54:09 PM UTC+1, Ahmad Bawaneh wrote:
>>>
>>> Anyone know what is generating TimeZoneConstants.properties, it says it
>>> is generated from CLDR version 25 .. but i cant find any thing that
>>> generates this gile in gwt code nor in gwt-tools code, was it generated
>>> externally?
>>>
>>>
>>> Have you tried pinging Manolo? He's the last one to have updated the
>>> file, maybe he remembers the details. Either him or John Tamplin.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/af65bf54-2dbb-4dc0-9833-1064e21b207a%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/e48d1ef7-5f72-4802-8ffa-9358e194f523%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe 

Would a kind soul give me a hint with this error on client side serialization?

[Edson Richter]

I'm receiving the error "this$static[signature][2] is not a function".
I was able to track this error down to the client code:

SerializerBase.java:


native void serialize(SerializationStreamWriter stream, Object instance,
String signature) throws SerializationException /*-{
  this[signature][2](stream, instance);
}-*/;
  }



What does that means? Would GWT tell me which class is offending the rules? 
I have literally 250 classes that would be serialized, and could not find 
the cause.
Also, I'm sure that the client is returning same objects that was send from 
server (client receives the object, set one BigDecimal value, and return 
same objects back to server).

Please, give me an advise!

Regards,

Edson

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: A class cast exception when upgrading from GWT 2.8.0 to 2.8.2 ?

[Ed]

Anybody any idea please? 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.