July 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Working with timezones

by Esteban A. Maringolo

So I searched around and ended at http://www.w3.org/TR/timezone Now I can picture the kind of issues you might have to deal with when using timezones. It gets scary. Also I learnt that timezone and time offset are not synonyms. Anyhow this is too much to add to my app without giving it proper thinking. So let's KISS. Regards, El jul 10, 2014 7:43 PM, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: > > On 10 Jul 2014, at 23:26, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > What is the best way to work across timezones? > > > > Today my app assumes a global, shared, timezone for data input, storage, > etc. > > I want to make this configurable, and for that purpose I > > > > For what I read and thought about, I understand that the best way to > > avoid any complication is to store and transfer (between > > client/server) everything in UTC, and use timezone offset only to > > convert to/from in order to display the Date and Time. > > > > Does anybody have a good article regarding working across timezones? > > Any tip or suggestion for its use with PostgreSQL and GLORP? > > > > Thanks in advance. > > > > Esteban A. Maringolo > > > > ps: And I guess I now understand the purpose of ZTimestamp :) > > ;-) > > Not only that, there is also ZTimezone with support for the Olsen timezone > database. > > Note that going from local time to UTC and vice versa depends not just on > the TZ but also on the timestamp itself (DST transitions), with possible > gaps and doubles (turn the clock forward/backward), making durations across > the DST transition weird ;-) > > Furthermore, a date (or start/end of a day) is also TZ dependent (Saturday > starts earlier/later for me than for you). For example, 'notify me if > something happens on Monday' is trickier than it would seem. > > Even though Norbert is right that you can use/mix any/all timezones, the > only way to remain sane, IMHO, is to store everything in UTC and only > convert to local TZ when presenting (this can be really on the client like > you suggest or in Seaside or reporting code on the server). You will also > need more the just a global setting, you need this per session ! > > Anyway, this is how we do it. > > Sven > > >

July 11, 2014

Re: [Pharo-users] Working with timezones

by Esteban A. Maringolo

2014-07-10 19:42 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> ps: And I guess I now understand the purpose of ZTimestamp :) > > ;-) > > Not only that, there is also ZTimezone with support for the Olsen timezone database. > > Note that going from local time to UTC and vice versa depends not just on the TZ but also on the timestamp itself (DST transitions), with possible gaps and doubles (turn the clock forward/backward), making durations across the DST transition weird ;-) Can you expand this? DST can be a complication too, but how to deal with that with current tools/libraries? > Furthermore, a date (or start/end of a day) is also TZ dependent (Saturday starts earlier/later for me than for you). For example, 'notify me if something happens on Monday' is trickier than it would seem. I agree. Such calculations should always use a TZ for the client, even when the client is an agent/service, maybe impersonating the real user. > Even though Norbert is right that you can use/mix any/all timezones, the only way to remain sane, IMHO, is to store everything in UTC and only convert to local TZ when presenting (this can be really on the client like you suggest or in Seaside or reporting code on the server). Seems to be the "most recommended way" of dealing with TZ interactions. > You will also need more the just a global setting, you need this per session ! Sure. Well... I guess I'll have to add ZTimestamp to the supported column types of GLORP tables. If you already have something for Postgres (other than casting TimeStamp or DateAndTime), I'll really appreciate it. Regards! Esteban A. Maringolo

July 10, 2014

Re: [Pharo-users] Working with timezones

by Sven Van Caekenberghe

On 10 Jul 2014, at 23:26, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > What is the best way to work across timezones? > > Today my app assumes a global, shared, timezone for data input, storage, etc. > I want to make this configurable, and for that purpose I > > For what I read and thought about, I understand that the best way to > avoid any complication is to store and transfer (between > client/server) everything in UTC, and use timezone offset only to > convert to/from in order to display the Date and Time. > > Does anybody have a good article regarding working across timezones? > Any tip or suggestion for its use with PostgreSQL and GLORP? > > Thanks in advance. > > Esteban A. Maringolo > > ps: And I guess I now understand the purpose of ZTimestamp :) ;-) Not only that, there is also ZTimezone with support for the Olsen timezone database. Note that going from local time to UTC and vice versa depends not just on the TZ but also on the timestamp itself (DST transitions), with possible gaps and doubles (turn the clock forward/backward), making durations across the DST transition weird ;-) Furthermore, a date (or start/end of a day) is also TZ dependent (Saturday starts earlier/later for me than for you). For example, 'notify me if something happens on Monday' is trickier than it would seem. Even though Norbert is right that you can use/mix any/all timezones, the only way to remain sane, IMHO, is to store everything in UTC and only convert to local TZ when presenting (this can be really on the client like you suggest or in Seaside or reporting code on the server). You will also need more the just a global setting, you need this per session ! Anyway, this is how we do it. Sven

July 10, 2014

Re: [Pharo-users] Working with timezones

by Norbert Hartl

Am 10.07.2014 um 23:26 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > What is the best way to work across timezones? > > Today my app assumes a global, shared, timezone for data input, storage, etc. > I want to make this configurable, and for that purpose I > > For what I read and thought about, I understand that the best way to > avoid any complication is to store and transfer (between > client/server) everything in UTC, and use timezone offset only to > convert to/from in order to display the Date and Time. > > Does anybody have a good article regarding working across timezones? > Any tip or suggestion for its use with PostgreSQL and GLORP? I think the only purpose is to have a reference point that is common. It doesn't matter if you transfer dates and times in UTC. That is what the offset is for. You can get the local time from a client but you store it in UTC (which will do the calculation of the offset). If you have a interface to a client you just deliver a correct offset but UTC is good thing here. The proper display of timezones is the duty of the client. If you produce web pages you need to get the timezone information from the user or in a web environment you do that locally with javascript. Hope that helps anyhow, Norbert

July 10, 2014

Working with timezones

by Esteban A. Maringolo

What is the best way to work across timezones? Today my app assumes a global, shared, timezone for data input, storage, etc. I want to make this configurable, and for that purpose I For what I read and thought about, I understand that the best way to avoid any complication is to store and transfer (between client/server) everything in UTC, and use timezone offset only to convert to/from in order to display the Date and Time. Does anybody have a good article regarding working across timezones? Any tip or suggestion for its use with PostgreSQL and GLORP? Thanks in advance. Esteban A. Maringolo ps: And I guess I now understand the purpose of ZTimestamp :)

July 10, 2014

Re: [Pharo-users] FFI Basic

by ClÃ©ment Bera

Well the method with the code you give was compiled without any problem in my image (Pharo #30851 with FFI loaded with configuration browser as explained in the other thread). Perhaps this is related to your bug in the other thread where you were (probably) missing a package ? 2014-07-10 18:15 GMT+02:00 Annick Fron <info(a)afceurope.com>: > > Hi, > > I made another attempt , a very basic one on window : trying to use the > abs method in the standard lib. > > abs: aNumber > > <apicall: int 'abs' (int) module: 'c:\windows\system32\msvcr100.dll'> > self externalCallFailed > > I get the error âcannot return the given typeâ. > > But now if I use long as argument and long as return it works. > > Annick >

July 10, 2014

Re: [Pharo-users] MNU: RBParser>>ExternalFunctionDeclaration

by ClÃ©ment Bera

2014-07-10 17:58 GMT+02:00 Annick Fron <info(a)afceurope.com>: > Hi, > > I have made simple trials using the StandardLib. > I get this error : > RBParser does not understand externalFunctionDeclaration. > I might be missing something â¦ > Yes, you are missing a package named "AST FFI Pharo 3 compatibility". externalFunctionDeclaration is implemented in RBExplicitVariableParser (subclass of RBParser) as a method extension of this package. The simplest solution is when you open a fresh pharo 3 image, you open the configuration browser (world menu >> tools >> configuration browser) then you click on FFI then install stable version. It loads automatically all what's needed to have FFI working. > > Annick > > Le 9 juil. 2014 Ã 17:20, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > yes, FFI does not handle ** arguments. > I always replace it by ulong instead (it is the same, after all) > > Esteban > > On 09 Jul 2014, at 17:17, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > This bug happen both with the old and new compiler. > > The error tells you that the number of arguments of your smalltalk method > does not match the number of argument of the C method you want to call (but > it seemsthe number of arguments is correct). > > This works fine: > > <apicall: int 'gst_init_check' (int char* int) module: ' > libgstreamer1.0-0.so'> > ^self externalCallFailed > > This works fine too: > > <apicall: int 'gst_init_check' (int* char* int*) module: ' > libgstreamer1.0-0.so'> > ^self externalCallFailed > > So it seems the bug comes from the parser missparsing ** . I am not > familiar with C enough to help, I don't know what means ** (Is it a pointer > pointing to a pointer pointing to the actual data ?). > > Perhaps someone who knows how to use FFI can give a better answer. > > Esteban ? Guille ? > > > 2014-07-09 16:39 GMT+02:00 Annick Fron <info(a)afceurope.com>: > >> Hi, >> I am trying to use FFI on linux with pharo 3 using version 31 of FFI. >> I have written the following method : >> <apicall: int 'gst_init_check' (int* char** int*) module: ' >> libgstreamer1.0-0.so'> >> >> ^self externalCallFailed >> >> ==== >> >> but when accepting it I get a syntax error Â« matching number of >> arguments Â» >> Annick Fron >> > > > >

July 10, 2014

FFI Basic

by Annick Fron

Hi, I made another attempt , a very basic one on window : trying to use the abs method in the standard lib. abs: aNumber <apicall: int 'abs' (int) module: 'c:\windows\system32\msvcr100.dll'> self externalCallFailed I get the error âcannot return the given typeâ. But now if I use long as argument and long as return it works. Annick

July 10, 2014

MNU: RBParser>>ExternalFunctionDeclaration

by Annick Fron

Hi, I have made simple trials using the StandardLib. I get this error : RBParser does not understand externalFunctionDeclaration. I might be missing something â¦ Annick Le 9 juil. 2014 Ã 17:20, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > yes, FFI does not handle ** arguments. > I always replace it by ulong instead (it is the same, after all) > > Esteban > > On 09 Jul 2014, at 17:17, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, >> >> This bug happen both with the old and new compiler. >> >> The error tells you that the number of arguments of your smalltalk method does not match the number of argument of the C method you want to call (but it seemsthe number of arguments is correct). >> >> This works fine: >> >> <apicall: int 'gst_init_check' (int char* int) module: 'libgstreamer1.0-0.so'> >> ^self externalCallFailed >> >> This works fine too: >> >> <apicall: int 'gst_init_check' (int* char* int*) module: 'libgstreamer1.0-0.so'> >> ^self externalCallFailed >> >> So it seems the bug comes from the parser missparsing ** . I am not familiar with C enough to help, I don't know what means ** (Is it a pointer pointing to a pointer pointing to the actual data ?). >> >> Perhaps someone who knows how to use FFI can give a better answer. >> >> Esteban ? Guille ? >> >> >> 2014-07-09 16:39 GMT+02:00 Annick Fron <info(a)afceurope.com>: >> Hi, >> >> >> >> I am trying to use FFI on linux with pharo 3 using version 31 of FFI. >> >> I have written the following method : >> <apicall: int 'gst_init_check' (int* char** int*) module: 'libgstreamer1.0-0.so'> >> >> ^self externalCallFailed >> >> >> ==== >> >> but when accepting it I get a syntax error Â« matching number of arguments Â» >> Annick Fron >> >

July 10, 2014

Re: [Pharo-users] How pragma works to create menu?

by Goubier Thierry

Hi Mark, you can override the standard menu by creating the text view with on:text:accept:readSelection:menu: and pass a menu building selector as the last argument. But you may not be able to recover the default menu that way (I didn't try, but maybe this is possible). In the menu building selector, you can add items to the menu just the way you want it; you can also contextualise it (based on what is selected in the message list, for example). Side note: to sort of get what you're doing, I got rid of the message browser a while ago and replaced it with a system browser scoped by a set of methods... no more special "message list" gui, just the normal system browser gui with all power (code navigation, refactorings, smart suggestions, contextualized menus, etc...). Thierry Le 10/07/2014 17:27, Mark Rizun a Ã©crit : > Maybe someone knows, how can I implement a context menu for > MessageBrowser that would pop-up not on itemsList pane, but on > sourceCode pane. Plus, I want it to use the standart one(I mean > smalltalkEditorMenu), and to have additional features. > > Mark > > > 2014-07-10 16:28 GMT+02:00 Mark Rizun <mrizun(a)gmail.com > <mailto:mrizun@gmail.com>>: > > Ok, thanks) > > > 2014-07-10 16:21 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>>: > > 2014-07-10 15:45 GMT+02:00 Mark Rizun <mrizun(a)gmail.com > <mailto:mrizun@gmail.com>>: > > In the NautilusRefactoring class we have a method on a class > side: > > sourceCodeRefactoringMenu: aBuilder > <nautilusGlobalSourceCodeMenu> > | target | > target := aBuilder model. > target selectedClass ifNotNil: [:selectedClass | > selectedClass > sourceCodeRefactoring: aBuilder ] > > I'd like to understand how this line works: target := > aBuilder model. I > mean, how aBuilder initializes a model? > Because, if you change the pragma from > <nautilusGlobalSourceCodeMenu> to > another one, you will get another result using this > particular line. > > Mark > > > aBuilder is constructed from a PragmaMenuBuilder, this > PragmaMenubuilder calls all methods with > pragma <nautilusGlobalSourceCodeMenu>. > > The model is initializes in for example, in AbstractNautilusUI > classMenuBuilder. > > > Nicolai > > > > > > -- > View this message in context: > http://forum.world.st/How-pragma-works-to-create-menu-tp4767409.html > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 10, 2014