March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Running tests on 2.0 and first impression

by stephane ducasse

> > > Maybe renaming the instance variables to reflect their UTC nature would help, but there is a difference between internal representation and external behaviour - if it is documented that seems OK to me. > > The #midnight example probably needs an extra normalisation of the internal representation, which would indeed shift it to what you would expect. > > Constructive criticism is always welcome, but these changes to DateAndTime were made many months ago - with great effort. Yes, there is still work to be done, and although it is maybe logical, it is a bit dissappointing to hear it right after a release. We were expecting that :) and this is why we drop the idea of a release candidate :). We will produce a summer edition and probably a batch of fixes for 2.0. once they accumulate :). Stef

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by stephane ducasse

Hello nicolas I know what you think about seeing code changes. So what can we do to improve it. I'm in favor to send diff to the mailing-lists especially since SmalltalkHub will support the charge now. Stef > > Totally agree, but for this specific bug I think that the process can > be improved by increased code reviews. > The fact that a negative seconds inst var and a julianDayNumber inst > var different from julianDayNumber message was chosen indicates that > current implementation is a quick hack, a workaround for solving some > problems, but clearly not a long term solution. IMO it creates as many > problems as it solves. > Diff has been added lately, and it is a real progress for reviewing > code, but the effort to participate is still a bit high. More eyes, > more reviews... > > The fact that bug only show up around midnight is true only for > Europeans which have small offsets from UTC, I guess the probability > of bug shall increase in California or Japan. > > Nicolas > >> >> >> >

March 20, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Andrei Vasile Chis

Hi Sven, I'll will al these tomorrow when I get back to the office. Cheers, Andrei On Wed, Mar 20, 2013 at 7:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Andrei, > > On 20 Mar 2013, at 19:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > One difference that I see is related to the content-length in the > response. > > There is none, which is OK when there is a connection close, but it > shows in the Smalltalk trace, which is weird. > > > > And for the same file, > /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz, > Smalltalk reports a length of 3451B (probably after your proceeded from the > exception), while curl reports size_download=3307, when I try from here, I > also get 3451 bytes, > > To make absolutely sure the curl call actually works, could you please try > this: > > $ curl > http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… -H "Accept-Encoding: gzip" | gunzip > foo.mcz > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 100 3307 0 3307 0 0 13558 0 --:--:-- --:--:-- --:--:-- 16131 > > $ file foo.mcz > foo.mcz: Zip archive data, at least v2.0 to extract > > $ ls -l foo.mcz > -rw-r--r-- 1 sven staff 3451 Mar 20 19:38 foo.mcz > > $ unzip -l foo.mcz > Archive: foo.mcz > Length Date Time Name > -------- ---- ---- ---- > 18 03-27-11 02:22 package > 188 03-27-11 02:22 version > 8588 03-27-11 02:22 snapshot/source.st > 9014 03-27-11 02:22 snapshot.bin > -------- ------- > 17808 4 files > > Thanks, > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Sven Van Caekenberghe

On 20 Mar 2013, at 19:40, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2013/3/20 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> On 20 Mar 2013, at 14:01, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> On Mar 20, 2013, at 1:20 PM, Camillo Bruni wrote: >>> >>>>> Totally agree, but for this specific bug I think that the process can >>>>> be improved by increased code reviews. >>>>> The fact that a negative seconds inst var and a julianDayNumber inst >>>>> var different from julianDayNumber message was chosen indicates that >>>>> current implementation is a quick hack, a workaround for solving some >>>>> problems, but clearly not a long term solution. IMO it creates as many >>>>> problems as it solves. >>>> >>>> That is a totally different discussion and most probably the tests are >>>> wrong, as with most of the date and time stuff from squeak. The dimensions >>>> of this mess are hard to grasp, but using a reference point expressed in >>>> local time is a very bad thing. So we changed that and all internal >>>> representations of DateAndTime are in UTC. All external representations >>>> of DateAndTime are in local time. >>>> >>>> That implies that whatever you inspect and see is in UTC, negative >>>> offsets make perfectly sense if your time-zone lags behind UTC. I wish >>>> I had time to fully clear up the mess, and add all basic accessors for >>>> utc. >>>> >>> Nicolas wasn't talking of offset. >>> >>> When I (in Norwegian timezone) do >>> DateAndTime midnight >>> >>> I get an instance with instvars: >>> seconds -3600 >>> offset: 1 hour duration. >>> >>> If it were indeed supposed to return local time instvar, I would expect an instance with >>> julianDayNumber one less, and seconds 23 *3600. >>> >>> Cheers, >>> Henry >> >> >> Maybe renaming the instance variables to reflect their UTC nature would help, but there is a difference between internal representation and external behaviour - if it is documented that seems OK to me. >> > > I don't adhere. Don't waste time documenting a bad feature, if these > are two different things just use to different names. > >> The #midnight example probably needs an extra normalisation of the internal representation, which would indeed shift it to what you would expect. >> >> Constructive criticism is always welcome, but these changes to DateAndTime were made many months ago - with great effort. Yes, there is still work to be done, and although it is maybe logical, it is a bit dissappointing to hear it right after a release. >> >> Pharo is a continuous improvement process. >> >> Sven >> > > Yes, sorry, my participation to the process dropped. > You must not count on it, it's only a little part of my own free time. > It's free, but not reliable. > My little contribution logically comes after the release mainly for > these reasons > 1) my previous attempts to catch up with 2.0 were abandonned because > deep changes were going on, a bit too much instability for too little > time > 2) the buzz convinced me to try again on a more stabilized image > > The failing tests amazed me a little because we now have CI to perform > this kind of dumb job. > > Last thing, continuous improvment certainly, but I'm not comfortable > with the process. > More than often it is necessary to download a fresh image which is > fine for a bot but is a barrier for me. > Probably because my stuff is just a blob of hacks, proof of concepts > or unfinished experiments, and I don't invest time into producing > re-installable artifacts. > It happens that I publish revisited stuff that is one or two years > old, so I don't like to throw too soon. > And I want to keep those hacks alive, not to bury them into a dead > fileOut or mcz. > My own view of continuous is closer to the smooth updates of Squeak trunk. > > I'd like to contribute more, and I hope you will retain the positive > part, because most certainly I will mainly report the things I don't > like ;) We absolutely value your contributions, of any kind, Nicolas, I think you know that. Keep them coming. And yes, of course, it is entirely up to you how you spend your free time. Regards, Sven > cheers > > Nicolas > >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >

March 20, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Sven Van Caekenberghe

Andrei, On 20 Mar 2013, at 19:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > One difference that I see is related to the content-length in the response. > There is none, which is OK when there is a connection close, but it shows in the Smalltalk trace, which is weird. > > And for the same file, /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz, Smalltalk reports a length of 3451B (probably after your proceeded from the exception), while curl reports size_download=3307, when I try from here, I also get 3451 bytes, To make absolutely sure the curl call actually works, could you please try this: $ curl http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… -H "Accept-Encoding: gzip" | gunzip > foo.mcz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3307 0 3307 0 0 13558 0 --:--:-- --:--:-- --:--:-- 16131 $ file foo.mcz foo.mcz: Zip archive data, at least v2.0 to extract $ ls -l foo.mcz -rw-r--r-- 1 sven staff 3451 Mar 20 19:38 foo.mcz $ unzip -l foo.mcz Archive: foo.mcz Length Date Time Name -------- ---- ---- ---- 18 03-27-11 02:22 package 188 03-27-11 02:22 version 8588 03-27-11 02:22 snapshot/source.st 9014 03-27-11 02:22 snapshot.bin -------- ------- 17808 4 files Thanks, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Nicolas Cellier

2013/3/20 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 20 Mar 2013, at 14:01, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> On Mar 20, 2013, at 1:20 PM, Camillo Bruni wrote: >> >>>> Totally agree, but for this specific bug I think that the process can >>>> be improved by increased code reviews. >>>> The fact that a negative seconds inst var and a julianDayNumber inst >>>> var different from julianDayNumber message was chosen indicates that >>>> current implementation is a quick hack, a workaround for solving some >>>> problems, but clearly not a long term solution. IMO it creates as many >>>> problems as it solves. >>> >>> That is a totally different discussion and most probably the tests are >>> wrong, as with most of the date and time stuff from squeak. The dimensions >>> of this mess are hard to grasp, but using a reference point expressed in >>> local time is a very bad thing. So we changed that and all internal >>> representations of DateAndTime are in UTC. All external representations >>> of DateAndTime are in local time. >>> >>> That implies that whatever you inspect and see is in UTC, negative >>> offsets make perfectly sense if your time-zone lags behind UTC. I wish >>> I had time to fully clear up the mess, and add all basic accessors for >>> utc. >>> >> Nicolas wasn't talking of offset. >> >> When I (in Norwegian timezone) do >> DateAndTime midnight >> >> I get an instance with instvars: >> seconds -3600 >> offset: 1 hour duration. >> >> If it were indeed supposed to return local time instvar, I would expect an instance with >> julianDayNumber one less, and seconds 23 *3600. >> >> Cheers, >> Henry > > > Maybe renaming the instance variables to reflect their UTC nature would help, but there is a difference between internal representation and external behaviour - if it is documented that seems OK to me. > I don't adhere. Don't waste time documenting a bad feature, if these are two different things just use to different names. > The #midnight example probably needs an extra normalisation of the internal representation, which would indeed shift it to what you would expect. > > Constructive criticism is always welcome, but these changes to DateAndTime were made many months ago - with great effort. Yes, there is still work to be done, and although it is maybe logical, it is a bit dissappointing to hear it right after a release. > > Pharo is a continuous improvement process. > > Sven > Yes, sorry, my participation to the process dropped. You must not count on it, it's only a little part of my own free time. It's free, but not reliable. My little contribution logically comes after the release mainly for these reasons 1) my previous attempts to catch up with 2.0 were abandonned because deep changes were going on, a bit too much instability for too little time 2) the buzz convinced me to try again on a more stabilized image The failing tests amazed me a little because we now have CI to perform this kind of dumb job. Last thing, continuous improvment certainly, but I'm not comfortable with the process. More than often it is necessary to download a fresh image which is fine for a bot but is a barrier for me. Probably because my stuff is just a blob of hacks, proof of concepts or unfinished experiments, and I don't invest time into producing re-installable artifacts. It happens that I publish revisited stuff that is one or two years old, so I don't like to throw too soon. And I want to keep those hacks alive, not to bury them into a dead fileOut or mcz. My own view of continuous is closer to the smooth updates of Squeak trunk. I'd like to contribute more, and I hope you will retain the positive part, because most certainly I will mainly report the things I don't like ;) cheers Nicolas > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 20, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Sven Van Caekenberghe

Hi Andrei, I can see that you are using a transparent proxy based on Squid. Indeed, the response is HTTP 1.0 which logically implies a connection close. One difference that I see is related to the content-length in the response. There is none, which is OK when there is a connection close, but it shows in the Smalltalk trace, which is weird. And for the same file, /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz, Smalltalk reports a length of 3451B (probably after your proceeded from the exception), while curl reports size_download=3307, when I try from here, I also get 3451 bytes, Although unibe.ch is closer than Argentina, I am not on your network. You could try to put a breakpoint in ZnEntityReader>>#readEntity and see a bit what happens. We have to find out why readFrom: readStream usingType: contentType andLength: nil does not happen. Sven On 20 Mar 2013, at 17:48, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Sven, > > Bellow is the output of I got from #logToTranscript and by running curl with -v with http1.1 and with http1.0. > Just from the zinc output I could figure out if the get request is http1.1 or http1.0 > > Let me know if you need any other data. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > Output from Smalltalk: > > 2013-03-20 17:24:54 660707 I Wrote a ZnRequest(GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz) > 2013-03-20 17:24:54 660707 D Sent headers > User-Agent: Zinc HTTP Components 1.0 > Accept-Encoding: gzip > Connection: close > Host: www.smalltalkhub.com > Accept: */* > > 2013-03-20 17:24:54 660707 D ConnectionClosed: Connection closed while waiting for data. retrying > 2013-03-20 17:24:55 660707 I Wrote a ZnRequest(GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz) > 2013-03-20 17:24:55 660707 D Sent headers > User-Agent: Zinc HTTP Components 1.0 > Accept-Encoding: gzip > Connection: close > Host: www.smalltalkhub.com > Accept: */* > > 2013-03-20 17:24:55 660707 D ConnectionClosed: Connection closed while waiting for data. retrying > 2013-03-20 17:24:56 660707 I Wrote a ZnRequest(GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz) > 2013-03-20 17:24:56 660707 D Sent headers > User-Agent: Zinc HTTP Components 1.0 > Accept-Encoding: gzip > Connection: close > Host: www.smalltalkhub.com > Accept: */* > > 2013-03-20 17:24:58 660707 I Read a ZnResponse(200 OK application/x-monticello 3451B) > 2013-03-20 17:24:58 660707 D Received headers > Content-Encoding: gzip > Content-Length: 3451 > Server: KomHttpServer/7.1.3 (unix) > Connection: close > Content-Type: application/x-monticello > X-Cache: HIT from proxy.unibe.ch > Date: Wed, 20 Mar 2013 16:24:54 GMT > Via: 1.0 bifor.unibe.ch (squid) > Age: 3 > Vary: Accept-Encoding > > 2013-03-20 17:24:58 660707 T GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz 200 3451B 4090ms > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > curl with http1.1 > command: curl http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… -H "Accept-Encoding: gzip" --write-out "size_download=%{size_download}\n" --output /dev/null -v > output: > > * About to connect() to www.smalltalkhub.com port 80 (#0) > * Trying 88.190.31.116... > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* connected > * Connected to www.smalltalkhub.com (88.190.31.116) port 80 (#0) > > GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz HTTP/1.1 > > User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 > > Host: www.smalltalkhub.com > > Accept: */* > > Accept-Encoding: gzip > > > * HTTP 1.0, assume close after body > < HTTP/1.0 200 OK > < Date: Wed, 20 Mar 2013 16:41:16 GMT > < Server: KomHttpServer/7.1.3 (unix) > < Content-Type: application/x-monticello > < Vary: Accept-Encoding > < Content-Encoding: gzip > < X-Cache: MISS from proxy.unibe.ch > < Via: 1.0 bifor.unibe.ch (squid) > < Connection: close > < > { [data not shown] > 100 3307 0 3307 0 0 17741 0 --:--:-- --:--:-- --:--:-- 17972 > * Closing connection #0 > size_download=3307 > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > curl with http1.0 > command: curl http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… --http1.0 -H "Accept-Encoding: gzip" --write-out "size_download=%{size_download}\n" --output /dev/null -v > output: > > * About to connect() to www.smalltalkhub.com port 80 (#0) > * Trying 88.190.31.116... > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* connected > * Connected to www.smalltalkhub.com (88.190.31.116) port 80 (#0) > > GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz HTTP/1.0 > > User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 > > Host: www.smalltalkhub.com > > Accept: */* > > Accept-Encoding: gzip > > > * HTTP 1.0, assume close after body > < HTTP/1.0 200 OK > < Date: Wed, 20 Mar 2013 16:41:16 GMT > < Server: KomHttpServer/7.1.3 (unix) > < Content-Type: application/x-monticello > < Vary: Accept-Encoding > < Content-Encoding: gzip > < Age: 34 > < X-Cache: HIT from proxy.unibe.ch > < Via: 1.0 bifor.unibe.ch (squid) > < Connection: close > < > { [data not shown] > 100 3307 0 3307 0 0 1040k 0 --:--:-- --:--:-- --:--:-- 3229k > * Closing connection #0 > size_download=3307 > >

March 20, 2013

Re: [Pharo-project] Penelope update

by Nicolas Cellier

2013/3/20 Nicolas Petton <petton.nicolas(a)gmail.com>: > That's the name of the issue ;) > > > Cheers, > Nico > > A bulb just lighted up ;) so it's more for bots than for me Nicolas > On Mar 20, 2013, at 6:40 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> for me, page http://bugs.pharo.org/issues/name/10004 displays >> >> SmalltalkImage current reportCPUandRAM > DNU >> >> Nicolas >> >> 2013/3/20 Nicolas Petton <petton.nicolas(a)gmail.com>: >>> Hi! >>> >>> We updated Penelope with the following fixes/improvements: >>> >>> - User registration fix >>> - User email validation fix >>> - Better urls with the case id handling (ex: http://bugs.pharo.org/issues/id/10004) >>> - REST case get by id (ex: http://bugs.pharo.org/issues/name/10004) >>> >>> >>> Cheers, >>> Nico & Ben >> > > -- > Nicolas Petton > http://www.nicolas-petton.fr > >

March 20, 2013

Re: [Pharo-project] Penelope update

by Nicolas Petton

The official 2.0 VM of course ;) On Mar 20, 2013, at 6:41 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > awesome! :) > > BTW on which VM are you running it? > > On 2013-03-20, at 18:37, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: >> Hi! >> >> We updated Penelope with the following fixes/improvements: >> >> - User registration fix >> - User email validation fix >> - Better urls with the case id handling (ex: http://bugs.pharo.org/issues/id/10004) >> - REST case get by id (ex: http://bugs.pharo.org/issues/name/10004) >> >> >> Cheers, >> Nico & Ben > > -- Nicolas Petton http://www.nicolas-petton.fr

March 20, 2013

Re: [Pharo-project] Penelope update

by Nicolas Petton

That's the name of the issue ;) Cheers, Nico On Mar 20, 2013, at 6:40 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > for me, page http://bugs.pharo.org/issues/name/10004 displays > > SmalltalkImage current reportCPUandRAM > DNU > > Nicolas > > 2013/3/20 Nicolas Petton <petton.nicolas(a)gmail.com>: >> Hi! >> >> We updated Penelope with the following fixes/improvements: >> >> - User registration fix >> - User email validation fix >> - Better urls with the case id handling (ex: http://bugs.pharo.org/issues/id/10004) >> - REST case get by id (ex: http://bugs.pharo.org/issues/name/10004) >> >> >> Cheers, >> Nico & Ben > -- Nicolas Petton http://www.nicolas-petton.fr

March 20, 2013