June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Protocol selection erratic behaviour

by Marcus Denker

> On 03 Jun 2015, at 12:29, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > > When creating a method in the debugger, > when the select protocol pop up window appears, > sometimes it finds the protocol we want (getter) > and sometimes it doesn't and we have to type it all > and add it as if it was new. > > Is this something normal and my expectations are off? > Or is this a bug? I would say a missing feature: we should hook the automatic categorised there to suggest a possible category. Marcus

June 4, 2015

loading Coral from SmalltalkHub

by Francisco Garau

Hello, I've tried loading Coral by following the below instructions in its website <http://rmod.lille.inria.fr/coral/getting-started.html> but they failed when trying to load Readline. Gofer new url: 'http://ss3.gemstone.com/ss/coral'; package: 'ConfigurationOfCoral'; load. ConfigurationOfCoral loadDevelopment. It seems the project was moved to Smalltalk Hub ( http://smalltalkhub.com/#!/~PharoExtras/Coral/) What expressions should I evaluate in a Pharo5 image to get the latest Coral project loaded. Thanks, Francisco

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Esteban A. Maringolo

2015-06-03 17:57 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 03/06/15 22:21, Esteban A. Maringolo wrote: >> >> 2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: >>> For performance reasons you'll probably often want to map to smallint >>> value objects. >> And lose the date abstraction the database provides me with? It is up >> to the database how to optimize the store of its datatypes. > Uhm, no on the smalltalk side. A DateAndTime is large and slow. A Date is larger in Pharo, it has two objects: aDateAndTime and aDuration. And one the rules that I value the most in the long time is the "Rule of Representation: Fold knowledge into data so program logic can be stupid an robust". Regarding the "Time oriented Databases" book you recommended, it makes a clear distinction about instants and intervals in a whole chapter (Chapter 3), and in all the chapter and implementations of SQL-92 (superseeded by SQL-2011) I couldn't find a single use case nor mention of a Date with a timezone. I think this discussion is depleted, Pharo Date implementation is as it is. Every suggestion is a workaround to a design choice made a lot of time ago. Thanks for your time. Esteban A. Maringolo

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Stephan Eggermont

On 03/06/15 22:21, Esteban A. Maringolo wrote: > 2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: >> For performance reasons you'll probably often want to map to smallint value objects. > > And lose the date abstraction the database provides me with? It is up > to the database how to optimize the store of its datatypes. Uhm, no on the smalltalk side. A DateAndTime is large and slow. Stephan

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Esteban A. Maringolo

2015-06-03 17:20 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 03/06/15 20:15, Esteban A. Maringolo wrote: >> >> I refer Postgres datatypes because I find them to have a good criteria >> based on a huge user base and because is what raised the issue I'm >> dealing with now. > I like the work by Richard Snodgrass. > His "Developing Time-Oriented Database Applications in SQL" is > available here: > http://www.cs.arizona.edu/~rts/publications.html Thank you! Looks very interesting. Esteban

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Esteban A. Maringolo

2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 03-06-15 20:15, Esteban A. Maringolo wrote: >> >> I refer Postgres datatypes because I find them to have a good criteria >> based on a huge user base and because is what raised the issue I'm >> dealing with now. > > > SQL databases are well-known to have ignored the standards for > dealing with times and dates for decades to make it difficult to > switch to a competitor. Sorry, but never heard of this intentional ignorance, particularly coming from PostgreSQL. Nonetheless, I had to deal with stupid issues in Oracle 7i-11g, but that's another story. Regarding standards, I mentioned the ISO 8601 where I haven't seen a case where a plain date comes with a timezone offset. > For performance reasons you'll probably often want to map to smallint value objects. And lose the date abstraction the database provides me with? It is up to the database how to optimize the store of its datatypes. Regards! Esteban A. Maringolo

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Stephan Eggermont

On 03/06/15 20:15, Esteban A. Maringolo wrote: > I refer Postgres datatypes because I find them to have a good criteria > based on a huge user base and because is what raised the issue I'm > dealing with now. I like the work by Richard Snodgrass. His "Developing Time-Oriented Database Applications in SQL" is available here: http://www.cs.arizona.edu/~rts/publications.html Stephan

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Esteban A. Maringolo

2015-06-03 16:13 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> But is unnecesary heretic. Date is a "calendar date", not a point in >> time. "May 3rd" is the same "date" as "May 3rd" whether you are in >> Sydney or Houston. >> ps: ISO 8601 doesn't mention anything about "date" timezones. In fact >> the word "timezone" implies time, not date. > I understand your POV, but you should have read what I originally wrote: the Date that we have now is more than an abstract date, it is an object that can answer to certain messages, like tell you when it starts, ends, whether it contains certain points in time. In order to do that, you have to know in which timezone to interpret it in. It is more than a Date because it is a Timespan, which behaves as an interval (*). But it is "so more" than the expected date, that breaks the expectation of what a Date is for me. > Look, I am not defending the current design, I just try to explain. No need to excuse, I totally understand it. I'm just ranting a little. > And May 3rd, interpreted as a concrete period of time, [from,to], is *NOT* the same in Sydney and Houston. (*) If you consider a date as an interval then it's right, but if you consider it an index of a discrete sequence, then it's wrong to treat it as an interval. In a sequence of integer numbers, you have 1, 2, 3... n, and there is no interval in between. If you store the "date of birth" it doesn't matter if you were born in Sidney, you wont get presents until is that date in Houston :P In my opinion what is wrong is that aDate is-an Interval. But that's how it is. So I'll "deal with it". :) Best regards. -- Esteban.

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Sergio Fedi

> Time is time. No matter "where" it happens. The theory of relativity disagrees

June 3, 2015

Re: [Pharo-users] Reddit example

by Sven Van Caekenberghe

> On 03 Jun 2015, at 20:24, <recursive68(a)gmail.com> <recursive68(a)gmail.com> wrote: > > Thanks for the pointers. I've got it working in Pharo 4 but had to change this method as I was getting a database session connection error. It appears to be losing the Glorp session, so I changed this class method thus: > > RedditDatabaseResource > login>> > "^ DefaultLogin ifNil: [ DefaultLogin := self createLogin ]" > ^ DefaultLogin := self createLogin. Hmm, it has been a while since I wrote this, looked at the code or ran it, but that should work the way it was intended. I even believe there is some auto-reconnect logic in Glorp, but I might be wrong.

June 3, 2015