- Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

Hi Andrei, On 20 Mar 2013, at 17:01, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > Lately I started to get ConnectionClosed errors when loading packages from Smalltalkhub by using Monticello. > It's very likely to just be a problem with my environment, as I'm connecting through a university server, but I > got stuck debugging it. > > Just to see if I can download packages normally I tried two things: > ZnClient new > systemPolicy; > url: 'http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD…'; > beOneShot; > get. > > ZnClient new > systemPolicy; > url: 'http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD…'; > setAcceptEncodingGzip; > beOneShot; > get. > > In the first case it works perfectly. However when I add 'setAcceptEncodingGzip' every time I get: > [ConnectionClosed signal: 'Connection closed while waiting for data.'] in Socket>>waitForDataFor: > but if I proceed from this error I get the right content. Monticello uses "setAcceptEncodingGzip" > so I get the above error. If I remove it, it works ok. > > I've tried this with the Pharo2.0-one-click image on Mac OS (all the compression tests pass). > Doing a request using curl with "Accept-Encoding: gzip,deflate" to the same url works ok. > > Am I missing something obvious? > > Cheers, > Andrei The problem that you mention (problems accessing monticello with gzip compression through some proxies) is a known issue: https://pharo.fogbugz.com/f/cases/6923 https://code.google.com/p/pharo/issues/detail?id=6986 The problem is, that to debug this, one (or I) has (have) to be behind your proxy. The other solution is that you help us. Add #logToTranscript to your Smalltalk code above and open the Transcript to see the HTTP wire protocol. Compare that with curl -v Somewhere there has to be some difference that matters... Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 20, 2013

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

by Andrei Vasile Chis

Hi, Lately I started to get ConnectionClosed errors when loading packages from Smalltalkhub by using Monticello. It's very likely to just be a problem with my environment, as I'm connecting through a university server, but I got stuck debugging it. Just to see if I can download packages normally I tried two things: ZnClient new systemPolicy; url: ' http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… '; beOneShot; get. ZnClient new systemPolicy; url: ' http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… '; setAcceptEncodingGzip; beOneShot; get. In the first case it works perfectly. However when I add 'setAcceptEncodingGzip' every time I get: [ConnectionClosed signal: 'Connection closed while waiting for data.'] in Socket>>waitForDataFor: but if I proceed from this error I get the right content. Monticello uses "setAcceptEncodingGzip" so I get the above error. If I remove it, it works ok. I've tried this with the Pharo2.0-one-click image on Mac OS (all the compression tests pass). Doing a request using curl with "Accept-Encoding: gzip,deflate" to the same url works ok. Am I missing something obvious? Cheers, Andrei

March 20, 2013

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

by Henrik Johansen

On Mar 20, 2013, at 3:05 PM, Henrik Johansen wrote: > > On Mar 20, 2013, at 2:52 PM, Henrik Johansen wrote: > >>> >> Yeah, seems to be in the resolver of the whole family of year:* constructors. >> Attached a fix, as I have no idea how to do the new issue tracking, and couldn't find a tutorial on the website. > >> <DateAndTime class-yearmonthdayhourminutesecondnanoSecondoffset.st> > Scratch that, definitely not my day today :) > > Cheers, > Henry Assuming the instvars are indeed now meant to hold UTC-values, here's some more thorough feedback (related to issues occurring around midnight): - Time initialization uses seconds from primSecondsClock (which returns local time) to set DaysSinceEpoch, with a constructor that expects UTC (in other words, it sets julianDayNumber directly). I couldn't find any accessors in the image, but I think there's new UTC clock primitives available? - todayAtMilliSeconds: / todayAtNanoSeconds: use this cached value without doing any checks, so unless someone calls milliSecondsSinceMidnight (which does the correct checking), they will return false results regardless when clock passes over. Incorrect direct uses of julianDayNumber instvar: - #hasEqualTicks: compares julianDayNumber directly vs other instances julianDayNumber, rather than julianDayNumberUTC. - same for #< Cheers, Henry

March 20, 2013

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

by Miguel Moquillon

Le 20/03/2013 14:36, Esteban Lorenzano a Ã©crit : > which vm, when it freezes, etc. > > a little bit more of info could help on fixing bugs :) In fact it is the VM provided by the Pharo 2.0 one-click distribution. Some info below: $ ./pharo -version 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux plugin path: /home/mmoquillon/Applications/Pharo2.0-one-click.app/Contents/Linux/ [default: /home/mmoquillon/Applications/Pharo2.0-one-click.app/Contents/Linux/] Miguel > > Esteban > > On Mar 20, 2013, at 2:34 PM, Miguel Moquillon <miguel.moquillon(a)gmail.com> wrote: > >> You're lucky, because in my own machine running GNU/Linux Ubuntu 12.04 the tests running in Pharo 2.0 either kills the VM or most of the time freezes the environment, depending on the weather... >> >> Miguel >> >> Le 20/03/2013 00:54, Nicolas Cellier a Ã©crit : >>> First thing, congrats to Pharo community, I observe a good trend. >>> It may seem dumb, but it's great to have pharo executable and pharo icons. >>> Once the image launched, my general feel is good too, though I'm not >>> fan of multiple keys shortcuts. >>> It stressed me to the point that I didn't realize the single key >>> shortcuts were still active in text editor (desperately seeking cmd b+ >>> something... when cmd + shift + N would just browse ivar references). >>> I guess I'll get used to it. >>> Browsing the class Object seems a bit long, I guess there's time >>> wasted scanning the class hierarchy... >>> >>> Of course, there's a few things to polish. >>> First I ran the tests, and here is what I have to say about it >>> - there were two interactions requests, IMO, there shouldn't be any (a >>> pop up for my name, and a menu) >>> - there are some failures (10) and errors (3), is this expected? (see >>> attachment) >>> - more annoyingly, during the test, the progressbar feedback >>> disappeared (sporadically flashing) and the TestRunner feedback too >>> (number of succeded test updates went scarce) >>> >>> When I opened a FileBrowser to browse the filedOut TestRunner report, >>> I typed *.txt as a filter and got a RegexSyntaxError nullable closure, >>> that's surprising. >>> >>> There I stopped exploring the features and inquired a bit about the failures. >>> Most failures are related to DateAndTime. I guess they occured because >>> I was playing with image around midnight with a +01:00 offset. >>> Early debugging let me see some highly questionable code, using >>> negative seconds in internal representation is a recipe for trouble.. >>> Having julianDayNumber the instance variable being different from >>> julianDayNumber the message is also asking for trouble. >>> >>> Well, just wanted to share this first feedback, i think i have lot of >>> things to discover in this image (I guess good things, but you know >>> me, I generally report the bad first). >>> >>> cheers >>> >>> Nicolas >> -- >> L'Intelligence Artificielle n'a aucune chance face Ã la StupiditÃ© Naturelle >> >> > -- L'Intelligence Artificielle n'a aucune chance face Ã la StupiditÃ© Naturelle

March 20, 2013

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

by Henrik Johansen

On Mar 20, 2013, at 2:52 PM, Henrik Johansen wrote: >> > Yeah, seems to be in the resolver of the whole family of year:* constructors. > Attached a fix, as I have no idea how to do the new issue tracking, and couldn't find a tutorial on the website. > <DateAndTime class-yearmonthdayhourminutesecondnanoSecondoffset.st> Scratch that, definitely not my day today :) Cheers, Henry

March 20, 2013

[Pharo-project] plugins with pharo

by jannik laval

I am trying to use the CameraPlugin (coming from Scratch project). It works fine but I have some understanding problems: - when I put the plugin in the plugins directory near the VM (on a Mac OS application), my source code works. - when I put the plugin near the image it does not work. > I tried to load module, using "Smalltalk loadModule: fullNameOfMyModule". This method returns 0, but my source code does not work. With a one click image: - when I put the plugin in the plugins directory near the VM (on a Mac OS application), my source code works. - when I put the plugin near the image it works. Something is strange because the behavior is not the same between one-click and separated image. Another question is how to load external module/plugins in Pharo ? Thanks -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu

March 20, 2013

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

by Henrik Johansen

On Mar 20, 2013, at 2:21 PM, Sven Van Caekenberghe wrote: > > 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. > > The #midnight example probably needs an extra normalisation of the internal representation, which would indeed shift it to what you would expect. > Yeah, seems to be in the resolver of the whole family of year:* constructors. Attached a fix, as I have no idea how to do the new issue tracking, and couldn't find a tutorial on the website. > 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. For those involved on a daily basis, yes. Feedback from others after a major release shouldn't be seen as a source of disappointment. ;) Cheers, Henry

March 20, 2013

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

by Esteban Lorenzano

which vm, when it freezes, etc. a little bit more of info could help on fixing bugs :) Esteban On Mar 20, 2013, at 2:34 PM, Miguel Moquillon <miguel.moquillon(a)gmail.com> wrote: > You're lucky, because in my own machine running GNU/Linux Ubuntu 12.04 the tests running in Pharo 2.0 either kills the VM or most of the time freezes the environment, depending on the weather... > > Miguel > > Le 20/03/2013 00:54, Nicolas Cellier a Ã©crit : >> First thing, congrats to Pharo community, I observe a good trend. >> It may seem dumb, but it's great to have pharo executable and pharo icons. >> Once the image launched, my general feel is good too, though I'm not >> fan of multiple keys shortcuts. >> It stressed me to the point that I didn't realize the single key >> shortcuts were still active in text editor (desperately seeking cmd b+ >> something... when cmd + shift + N would just browse ivar references). >> I guess I'll get used to it. >> Browsing the class Object seems a bit long, I guess there's time >> wasted scanning the class hierarchy... >> >> Of course, there's a few things to polish. >> First I ran the tests, and here is what I have to say about it >> - there were two interactions requests, IMO, there shouldn't be any (a >> pop up for my name, and a menu) >> - there are some failures (10) and errors (3), is this expected? (see >> attachment) >> - more annoyingly, during the test, the progressbar feedback >> disappeared (sporadically flashing) and the TestRunner feedback too >> (number of succeded test updates went scarce) >> >> When I opened a FileBrowser to browse the filedOut TestRunner report, >> I typed *.txt as a filter and got a RegexSyntaxError nullable closure, >> that's surprising. >> >> There I stopped exploring the features and inquired a bit about the failures. >> Most failures are related to DateAndTime. I guess they occured because >> I was playing with image around midnight with a +01:00 offset. >> Early debugging let me see some highly questionable code, using >> negative seconds in internal representation is a recipe for trouble.. >> Having julianDayNumber the instance variable being different from >> julianDayNumber the message is also asking for trouble. >> >> Well, just wanted to share this first feedback, i think i have lot of >> things to discover in this image (I guess good things, but you know >> me, I generally report the bad first). >> >> cheers >> >> Nicolas > > -- > L'Intelligence Artificielle n'a aucune chance face Ã la StupiditÃ© Naturelle > >

March 20, 2013

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

by Miguel Moquillon

You're lucky, because in my own machine running GNU/Linux Ubuntu 12.04 the tests running in Pharo 2.0 either kills the VM or most of the time freezes the environment, depending on the weather... Miguel Le 20/03/2013 00:54, Nicolas Cellier a Ã©crit : > First thing, congrats to Pharo community, I observe a good trend. > It may seem dumb, but it's great to have pharo executable and pharo icons. > Once the image launched, my general feel is good too, though I'm not > fan of multiple keys shortcuts. > It stressed me to the point that I didn't realize the single key > shortcuts were still active in text editor (desperately seeking cmd b+ > something... when cmd + shift + N would just browse ivar references). > I guess I'll get used to it. > Browsing the class Object seems a bit long, I guess there's time > wasted scanning the class hierarchy... > > Of course, there's a few things to polish. > First I ran the tests, and here is what I have to say about it > - there were two interactions requests, IMO, there shouldn't be any (a > pop up for my name, and a menu) > - there are some failures (10) and errors (3), is this expected? (see > attachment) > - more annoyingly, during the test, the progressbar feedback > disappeared (sporadically flashing) and the TestRunner feedback too > (number of succeded test updates went scarce) > > When I opened a FileBrowser to browse the filedOut TestRunner report, > I typed *.txt as a filter and got a RegexSyntaxError nullable closure, > that's surprising. > > There I stopped exploring the features and inquired a bit about the failures. > Most failures are related to DateAndTime. I guess they occured because > I was playing with image around midnight with a +01:00 offset. > Early debugging let me see some highly questionable code, using > negative seconds in internal representation is a recipe for trouble.. > Having julianDayNumber the instance variable being different from > julianDayNumber the message is also asking for trouble. > > Well, just wanted to share this first feedback, i think i have lot of > things to discover in this image (I guess good things, but you know > me, I generally report the bad first). > > cheers > > Nicolas -- L'Intelligence Artificielle n'a aucune chance face Ã la StupiditÃ© Naturelle

March 20, 2013

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

by Camillo Bruni

On 2013-03-20, 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. right, so it looks like DateAndTime>>#year:month:day:hour:minute:second:nanoSecond:offset: does not take the seconds nor the offset into account when calculating the julian day number. I opened a bug entry with an intermediate fix for this: https://pharo.fogbugz.com/default.asp?10069

March 20, 2013