April 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sean P. DeNigris

Alistair Grant wrote > I think using UTC would just move the problem by an hour. I'm not sure I understand. How so? I thought UTC is a constant reference point unaffected by UTC (https://stackoverflow.com/a/5495816/424245) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

Re: [Pharo-dev] Did magritte change? Magritte-Morph-SeasnDeNigris.95 is not found

by Sean P. DeNigris

Stephane Ducasse-3 wrote > I will create one There is https://github.com/magritte-metamodel/magritte which I forked from. I wonder if we can make that canonical. It would be easy for me to sync my changes back and from the README, it appears that most other Smalltalk load Magritte from elsewhere. Regarding Sqeak, there are the mcz repos, and IFAICT Squeak has not shown much interest in git, so we're probably safe there. Either way, please coordinate with me because the StHub repo is waaaay behind my forkâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

[Pharo 7.0-dev] Build #758: 21682-DropListPresenter-ignores-disable-before-it-is-built

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #758 was: FAILURE. The Pull Request #1185 was integrated: "21682-DropListPresenter-ignores-disable-before-it-is-built" Pull request url: https://github.com/pharo-project/pharo/pull/1185 Issue Url: https://pharo.fogbugz.com/f/cases/21682 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 9, 2018

Re: [Pharo-dev] [ANN] New Pharo 6.1 version

by Esteban Lorenzano

> On 8 Apr 2018, at 20:25, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Great job, Esteban! well, is more like the great job of Martin, I just did the integration. But thanks is his name ;) cheers! Esteban > > Doru > >> On Apr 5, 2018, at 3:00 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> https://pharo.fogbugz.com/f/cases/20944/Integrate-Epicea-8-2-8-in-Ph6-1 >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > >

April 9, 2018

Re: [Pharo-dev] [ANN] New Pharo 6.1 version

by Esteban Lorenzano

hi, > On 8 Apr 2018, at 14:13, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > But why it's not a 6.2 version? It would be more clear since this is continuation of version 6 with new changes. How one would revert to original 6.1 if this new version isn't working for him? > > In the same way as any previous image version... e.g. > > Pharo 6 is actually Pharo 60508 and lower, > Pharo 6.1 is Pharo 60509-60539, > and Pharo 6.2 is Pharo 60540+ > (give or take couple of versions, don't remember the precise boundaries) > > and you can download any specific image version you want https://files.pharo.org/image/60/ <https://files.pharo.org/image/60/> > > (it is a bit confusing, but Pharo 6 is not yet using git and the existing infrastructure is not keen on minor releases) yes, it is like this. to produce a 6.2 would be kind of a pain (as it was already 6.1 and it still causes confusion :P) we are working to have better numbering starting on Pharo 7 (and the bootstrapped process). cheers, Esteban > > Peter

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Alistair Grant

Hi Sean, On 8 April 2018 at 15:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I was bitten by this very annoying bug again. As most of us probably know due > to the steady stream of confused ML posts in the past, the bug in summary is > that we have an incomplete timezone implementation that doesn't properly > take into account historical DST changes. This flares up without warning > especially when DST toggles. I created a wiki page to document the > situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco > > Here's an example blowup: at 11:59pm before DST changes, eval aDate := > '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: > '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" offsets > render equal dates unequal depending on when the objects were created. > > The more I think about it, the more I think that we should just assume UTC > for all Date[AndTime]s that don't explicitly specify an offset, rather than > pretend to set an offset which is only sometimes correct. More advanced > users can use one of the available libraries to get full timezone support. > What do you think? I think using UTC would just move the problem by an hour. As Sven says, the real issue is Date as a timespan vs Date as a d/m/y. What you're doing here is comparing timespans, and one timespan has been moved by 1 hour due to the start of DST. If you did: '1/1/1901' asDate equals: aDate Then everything would be fine. Cheers, Alistair

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 9 Apr 2018, at 08:51, Max Leske <maxleske(a)gmail.com> wrote: > > Hi Sean, > On 8 April 2018 at 15:33:11, Sean P. DeNigris (sean(a)clipperadams.com) wrote: > >> I was bitten by this very annoying bug again. As most of us probably know due >> to the steady stream of confused ML posts in the past, the bug in summary is >> that we have an incomplete timezone implementation that doesn't properly >> take into account historical DST changes. This flares up without warning >> especially when DST toggles. I created a wiki page to document the >> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >> >> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" offsets >> render equal dates unequal depending on when the objects were created. >> >> The more I think about it, the more I think that we should just assume UTC >> for all Date[AndTime]s that don't explicitly specify an offset, rather than >> pretend to set an offset which is only sometimes correct. More advanced >> users can use one of the available libraries to get full timezone support. >> What do you think? > I first wanted to fully agree with you but then I had to think back on the times I've had to fight timestamp bugs when working with Pharo and relational databases. A database will make its own assumptions about the offset. From the PostgreSQL documentation (https://www.postgresql.org/docs/9.1/static/datatype-datetime.html) > > "For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter, and is converted to UTC using the offset for the timezone zone." > > Assuming UTC is probably just as wrong as assuming the local time zone. Maybe the problem is more about the interface of DateAndTime, where you don't really have to care about the time zone offset until it bites you. If the interface would force you to specify the time zone, then you'd be aware from the beginning that it's something to take into account. Right now, a Date is defined as a timespan of 1 day starting from a precise point in time (a DateAndTime with an offset). The fact that it is more advanced is hidden behind a simpler (too simple) API. I think most people think of a Date as a AbstractJulianDate with three components: year/month/day that they want to interpret in there own way (in there own timezone). I would not call that an UTCDate, although that would be one interpretation of the abstraction. I don't think there is an easy/universal solution. > Cheers, > > Max > >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>

April 9, 2018

[Pharo 7.0-dev] Build #757: 21681-expandMacrosWith-shouldnt-truncate-strings

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #757 was: SUCCESS. The Pull Request #1184 was integrated: "21681-expandMacrosWith-shouldnt-truncate-strings" Pull request url: https://github.com/pharo-project/pharo/pull/1184 Issue Url: https://pharo.fogbugz.com/f/cases/21681 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Max Leske

Hi Sean, On 8 April 2018 at 15:33:11, Sean P. DeNigris (sean(a)clipperadams.com) wrote: I was bitten by this very annoying bug again. As most of us probably know due to the steady stream of confused ML posts in the past, the bug in summary is that we have an incomplete timezone implementation that doesn't properly take into account historical DST changes. This flares up without warning especially when DST toggles. I created a wiki page to document the situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco Here's an example blowup: at 11:59pm before DST changes, eval aDate := '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" offsets render equal dates unequal depending on when the objects were created. The more I think about it, the more I think that we should just assume UTC for all Date[AndTime]s that don't explicitly specify an offset, rather than pretend to set an offset which is only sometimes correct. More advanced users can use one of the available libraries to get full timezone support. What do you think? I first wanted to fully agree with you but then I had to think back on the times I've had to fight timestamp bugs when working with Pharo and relational databases. A database will make its own assumptions about the offset. From the PostgreSQL documentation ( https://www.postgresql.org/docs/9.1/static/datatype-datetime.html) "For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter, and is converted to UTC using the offset for the timezone zone." Assuming UTC is probably just as wrong as assuming the local time zone. Maybe the problem is more about the interface of DateAndTime, where you don't really have to care about the time zone offset until it bites you. If the interface would force you to specify the time zone, then you'd be aware from the beginning that it's something to take into account. Cheers, Max ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

Re: [Pharo-dev] call for help: answer on HN :)

by Thierry Goubier

2018-04-09 2:18 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Even if he is a troll, he pointed out many things that aren't given > priority because we're building "next great stuff" and with the limited > resource you either stop to world to fix what's already made or you move > forward. > > And IMO it is true that the next great stuff is being built, a better > paradigm, moldability, and whatnot, but that means that, for a while, > tools, and the image itself won't be "rock solid", and since most things > are not backportable or maintained (there are no resources to have LTS > versions), it is hard to define what's the minimum rock-solid core on > which to build upon. I wonder if some things could be solved by taking a slightly different path... - Non rock solid base could be cared for by debugging that allways work - Not threaded image could be solved by "image sharing between processes" - Multiple host windows would mean forking the image Imagine a world where: - The smalltalk debugger can remote debug via gdb(*) a locked image (or one where you have crashed the world because you played with core graphics stuff)... - The smalltalk debugger can inject new code into a remote image via gdb again (**). - Two images can easily share objects with almost zero overhead(***) - One image can easily keeps its code in sync with another one (object duplication between images) I know of TelePharo, and, after looking at the underlying implementation, it's not good enough. The core undebuggability of the platform is not solved (at all). The undebuggability of the platform is a significant barrier. I worked on the SmaCC GT debugger because my students were regularly locking their images with it (usually something as simple as stepping over the end of the computation) so I've added many, many guards, to try to protect from that; I know think a strong limitation of exploring new debug modes is mainly linked to the ease of locking your image with it. Regards, Thierry (*) gdb over serial talking to a boot eeprom equivalent, mapped with a remapping of step to smalltalk instructions (like in a true debugger) (**) So that, from that smalltalk over gdb debugger, you can fix, compile and proceed (***) And so, no story of running a "determine the right object graph with more smalltalk code... ", that is too slow > E.g. The infinite walkback error pointed in this screenshot > https://i.imgur.com/7jiKIhd.png still chases me from time to time, and I > remember having reported it a long time ago, and it was considered fixed. > > So I wouldn't feed the troll, but I woudln't kill the messenger either. > > Regards, > > > On 07/04/2018 14:26, Dimitris Chloupis wrote: >> yeah the guy (martin whatever) is a troll, if I remember correctly its >> the same dude we had on the reddit forum for Smalltalk that has been >> attacking Pharo with pure lies. He is a typical troll that blows off >> steam by annoying other people. I am with Stef with this one, the only >> way to win against a troll is silence. I had a very recent experience >> where the person in charge underestimated a troll, he overflown the >> mailing list with negative, many people took the bait and tried to have >> a civilized discussions with him, he drag it one for month until people >> started abandoning the community and the community essentially died. >> >> I adviced them not to feed the troll but as in many other cases, people >> dont even listen. >> >> Pharo is far from perfect, but this is not a logical discussion , its >> pure troll tactic. Do not underestimate the power of a troll, it is more >> powerful than you can imagine and feed on politeness and rationality. >> >> Don't feed the troll. >> >> On Sat, Apr 7, 2018 at 8:13 PM phil(a)highoctane.be >> <mailto:phil@highoctane.be> <phil(a)highoctane.be >> <mailto:phil@highoctane.be>> wrote: >> >> interruptible.. yes! >> >> On Sat, Apr 7, 2018, 19:10 Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Alex, >> >> Le 07/04/2018 Ã 17:48, Aliaksei Syrel a Ã©crit : >> > Hi >> > >> > Here is a link to a report about their experience with Pharo: >> > https://gitlab.fit.cvut.cz/taibrmar/sokoban-using-bloc >> > >> > There definitely exist things that should be improved. It is a >> pity when >> > tiny âminorâ issues leave such an unpleasant aftertaste. >> >> Some of them are, sadly, quite unacceptable, IMHO. >> >> I would really dream of a stable, correctly interruptible (i.e. >> a Cmd-. >> that really works), limited Pharo core. That would help >> development so >> significantly and allow more experiments. >> >> I solve that by making stuff that distance itself as much as >> possible >> from a lot of the Pharo stuff that evolves far too much, far too >> fast to >> be relied upon (widgets, graphics, editors), and I'm looking >> forward to >> building a limited(*) image with just and only the things I rely on. >> >> One of the thing I need is a CI that triggers both on my code >> releases >> and any Pharo update (including the stable ones) since even stable >> releases may change core APIs. >> >> > Anyway, there are lovers and haters of every language. >> >> That I can agree with :) >> >> > Some people even >> > give dislikes to videos on YouTube that show how veterinarians >> heal cats... >> > >> > All the best >> > Alex >> >> Regards, >> >> Thierry >> >> (*) I did try with the minimal image, and the tools are clearly >> limiting. >> >> > On Sat, 7 Apr 2018 at 17:27, Stephane Ducasse >> <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com> >> > <mailto:stepharo.self@gmail.com >> <mailto:stepharo.self@gmail.com>>> wrote: >> > >> > I tend to not care about people pissing on me via a >> pseudo. This is >> > too easy and too microscopic to have any value. >> > Thanks Philippe, Luke and Ben because you use your real names. >> > >> > On Thu, Apr 5, 2018 at 2:07 PM, Esteban Lorenzano >> > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> >> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: >> > > Hi, >> > > >> > > yesterday someone posted an article on HN about the >> Pharo MOOC >> > and there has >> > > been some negative posts there. >> > > I would like to call people who can have the time to >> answer there >> > and help >> > > to explain better and also contribute to contest that FUD >> > someones (we know >> > > who they areâ¦ sames as always) are spreading. >> > > >> > > here the link : >> https://news.ycombinator.com/item?id=16754872 >> > > >> > > (this is not loosing time, people searching for Pharo >> will likely >> > see this >> > > kind of messagesâ¦ at least we need to offer our point >> of view) >> > > >> > > cheers! >> > > Esteban >> > >> > -- >> > Cheers, >> > Alex >> >> > > -- > Esteban A. Maringolo >

April 9, 2018