October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] DateAndTime vs TimeStamp

by Henrik Sperre Johansen

On 31.10.2011 13:27, Sven Van Caekenberghe wrote: > Hi, > > I am used to using TimeStamp as my default 'point-in-time' class, although it differs only very slightly from DateAndTime. This was not really a very explicit decision, it just sounded/felt right. Now that I am having some timezone issue to sort out, the way DataAndTime's are printed is more helpful. > > So the question is: why do we have these two, very similar, classes ? Do we need them ? > > I vaguely remember there is a Seaside directive: do not just TimeStamp (maybe only for portability) ? > > In short, what is the rationale behind this situation ? > > Thx, > > Sven > > > > IIRC: TimeStamp predates ANSI, and differs from dialect to dialect. For example, VW Timestamps (different capitalization) are in local time, currently with no way of determining which TimeZone they were created in. DateAndTime is in ANSI. I vaguely recall mails from Cincom engineers stating the standard was unfixably ambiguous, but I can't find where atm... Cheers, Henry

Oct. 31, 2011

Re: [Pharo-project] Windows disappear in saved image on startup

by Larry Kellogg

Well, that doesn't seem to work, using the original Pharo-1.0 image with the latest changes still results in the same bug at startup. Perhaps I will try to build a debug image, or figure out how to reapply all of the changes from the .changes file on top of a 1.3 image and hope I have better luck. Larry -- View this message in context: http://forum.world.st/Windows-disappear-in-saved-image-on-startup-tp3944123… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 31, 2011

Re: [Pharo-project] Windows disappear in saved image on startup

by Larry Kellogg

Thanks Max! Yes, I realized yesterday that everything is contained in the .changes file. I will try to use my latest .changes file with a new image and see if I can get it to open. I'll report my results. Larry -- View this message in context: http://forum.world.st/Windows-disappear-in-saved-image-on-startup-tp3944123… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 31, 2011

Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?

by Lukas Renggli

Last time I tried with the test runner (that uses essentially the same infrastructure) it didn't quite work for me yet. I had some rare random crashes and sometimes coverage results were not entirely correct. It improved with every new version of Cog, so maybe all problems are resolved now? :-) Also we have to check if the method lookup cache are flushed the same way as with the test runner. Could be that the two runners are out of sync. Lukas On 31 October 2011 12:30, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Mon, Oct 31, 2011 at 12:27 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> Cool, so what is your experience? Does it work well with the latest Cog? > > Yes, as far as I can see yes. But it would be cool another guy test it also > because there is no exact way to be sure whether it is working good or not. > I just check the non-covered methods and I analyzed if they are correct not > to be covered or not.... > >> >> I should re-enable the coverage on my images again :-) >> > > Sure, but first give it a try with a normal image with latest cog. If it > works then update your jenkis :) > >> >> Lukas >> >> >> On 31 October 2011 12:22, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > >> >> >> >> You run HDCoverageReport exactly the same way as HDTestReport. >> >> >> >> HDCoverageReport uses exactly the same mechanism as the Test Runner to >> >> figure out the code you want calculate the coverage on. That is, you >> >> have to override #packageNamesUnderTest on the class side of one of >> >> your test classes. >> > >> > Wow....I wasn't aware of that. I always trigger the TestCoverage from >> > the >> > test runner and then I needed to select the package to which it should >> > calculate the coverage... >> > >> >> >> >> I don't know if HDCoverageReport still works, because I stopped using >> >> it when I started with Cog on Jenkins. It definitely works on >> >> traditional VMs. Probably today it works on Cog too. >> > >> > Yes, latest Cog works ok with test coverage, and HDCoverageReport >> > works!! >> > look the attached screenshot >> > >> > Thanks Lukas >> > >> > >> >> >> >> Lukas >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 31, 2011

Re: [Pharo-project] Athens news :)

by Alexandre Bergel

This is cool! There is a real need for it Alexandre Le 31 oct. 2011 Ã 07:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > Hi guys > > I asked igor to do a pre pre pre pre release of athens and then perform regular ones so that you can follow what he is doing > and get excited. Because this is getting along and will open a lot of perspective. > > The idea is that igor is working since september on Athens: a new canvas and a smalltalk backend to support it. > The challenge are: > - how can we get a zoomable vector graphics system? with for examples back end in Cairo/opengl. > - what are the good abstractions to support that? > > Igor is then working on a "simple" text model and canvas so that we can emit instructions for vector graphics > back-ends. > > Stef > >

Oct. 31, 2011

[Pharo-project] DateAndTime vs TimeStamp

by Sven Van Caekenberghe

Hi, I am used to using TimeStamp as my default 'point-in-time' class, although it differs only very slightly from DateAndTime. This was not really a very explicit decision, it just sounded/felt right. Now that I am having some timezone issue to sort out, the way DataAndTime's are printed is more helpful. So the question is: why do we have these two, very similar, classes ? Do we need them ? I vaguely remember there is a Seaside directive: do not just TimeStamp (maybe only for portability) ? In short, what is the rationale behind this situation ? Thx, Sven

Oct. 31, 2011

Re: [Pharo-project] [ANN 1.3] One-Click #13315

by Ben Coman

Oct. 31, 2011

Re: [Pharo-project] Consortium news

by GermÃ¡n Arduino

2011/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > SInce INRIA accepted to pay one engineer around the pharo consortium we > will hire esteban lorenzano for a year. > Congrats Esteban! > We are excited by that! I should do a lot of paper work but this is really > cool. > > For the consortium > - inria law oriented people are designing a "CAML" like consortium > text > - Marcus is setting up mailing-list and we will make public the > names of the companies that are participating. > - We will discuss the prices and modality. > > Stef > > >

Oct. 31, 2011

Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?

by Mariano Martinez Peck

On Mon, Oct 31, 2011 at 12:27 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Cool, so what is your experience? Does it work well with the latest Cog? > Yes, as far as I can see yes. But it would be cool another guy test it also because there is no exact way to be sure whether it is working good or not. I just check the non-covered methods and I analyzed if they are correct not to be covered or not.... > > I should re-enable the coverage on my images again :-) > > Sure, but first give it a try with a normal image with latest cog. If it works then update your jenkis :) > Lukas > > > On 31 October 2011 12:22, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > >> > >> You run HDCoverageReport exactly the same way as HDTestReport. > >> > >> HDCoverageReport uses exactly the same mechanism as the Test Runner to > >> figure out the code you want calculate the coverage on. That is, you > >> have to override #packageNamesUnderTest on the class side of one of > >> your test classes. > > > > Wow....I wasn't aware of that. I always trigger the TestCoverage from the > > test runner and then I needed to select the package to which it should > > calculate the coverage... > > > >> > >> I don't know if HDCoverageReport still works, because I stopped using > >> it when I started with Cog on Jenkins. It definitely works on > >> traditional VMs. Probably today it works on Cog too. > > > > Yes, latest Cog works ok with test coverage, and HDCoverageReport works!! > > look the attached screenshot > > > > Thanks Lukas > > > > > >> > >> Lukas > >> > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

Oct. 31, 2011

Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?

by Lukas Renggli

Cool, so what is your experience? Does it work well with the latest Cog? I should re-enable the coverage on my images again :-) Lukas On 31 October 2011 12:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> You run HDCoverageReport exactly the same way as HDTestReport. >> >> HDCoverageReport uses exactly the same mechanism as the Test Runner to >> figure out the code you want calculate the coverage on. That is, you >> have to override #packageNamesUnderTest on the class side of one of >> your test classes. > > Wow....I wasn't aware of that. I always trigger the TestCoverage from the > test runner and then I needed to select the package to which it should > calculate the coverage... > >> >> I don't know if HDCoverageReport still works, because I stopped using >> it when I started with Cog on Jenkins. It definitely works on >> traditional VMs. Probably today it works on Cog too. > > Yes, latest Cog works ok with test coverage, and HDCoverageReport works!! > look the attached screenshot > > Thanks Lukas > > >> >> Lukas >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 31, 2011