August 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Igor Stasenko

On 31 August 2012 18:00, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 31 August 2012 16:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 31 August 2012 08:10, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 31 August 2012 05:04, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>> Frank, >>>> >>>> I'll try to get the Pharo-2.0 build for builderCI working soon ... >>> >>> I _think_ it'll be as simple as figuring out how to say "open this >>> file, creating it first if necessary" in FileSystem-speak. I realise >>> you've not done Metacello+Pharo2 yet, and asked on list hoping that >>> one of the FS folk would pipe up with something :) >>> >> >> 'asdasd' asFileReference writeStreamDo: [:s | >> s nextPutAll: 'baz' ] > > But for reading? My debug output's here: > > http://travis-ci.org/#!/frankshearar/Control/jobs/2288671 > reading non-existent file? you know, you can always test if file exists before trying to open it. ref := 'asdasd' asFileReference. (ref exists and: [ ref isFile and: [ ref isReadable ]]) ifTrue: [ ref readStream ....] i never used FS before.. so to post the code above, i vent to system browser, and read some method names in FileReference class. This is something what you can do by yourself, isn't? :) > and the relevant code (I think) is > > transcriptStream := ((Smalltalk at: #FileSystem) workingDirectory > / transcriptFileName) readStream > so, why you don't just wrap this thing with exception handler? [ transcriptStream := ((Smalltalk at: #FileSystem) workingDirectory / transcriptFileName) readStream ] on: Error do: [ aha... somethign wrong with that file ] this will prevent image from bailing out to OS. :) > where transcriptFileName = 'TravisTranscript.txt'. > > The "old style" file handling works, and says this: > > transcriptStream := fileDirectoryClass default newFileNamed: > transcriptFileName > > frank > >>> frank >>> >>>> Dale >>>> >>>> ----- Original Message ----- >>>> | From: "Frank Shearar" <frank.shearar(a)gmail.com> >>>> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>> | Cc: "Dale Henrichs" <dhenrich(a)vmware.com> >>>> | Sent: Thursday, August 30, 2012 1:52:37 PM >>>> | Subject: Pharo 2.0 + Travis = ? >>>> | >>>> | Hi Dale, >>>> | >>>> | I'm getting a build failure against Pharo 2.0 [1] with the error >>>> | "FileDoesNotExist: >>>> | /home/travis/dalehenrich-builderCI-cd2facd/builds/travisCI/TravisTranscript.txt". >>>> | >>>> | I think that's because the before.st says "transcriptStream := >>>> | ((Smalltalk at: #FileSystem) workingDirectory / transcriptFileName) >>>> | readStream ]" and that file doesn't exist. >>>> | >>>> | Is there a convenient way of saying "please open a readStream on this >>>> | file and, if it's not there, make one" ? >>>> | >>>> | (If one semi-replicates the build, by opening a Pharo 2.0 image, >>>> | manually loading the ConfigurationOfControl, and running >>>> | "ConfigurationOfControl loadDevelopment", one will see Control >>>> | 1.1.dev >>>> | running with a green light for Pharo 2.0!) >>>> | >>>> | frank >>>> | >>>> | [1] http://travis-ci.org/#!/frankshearar/Control/jobs/2282004 >>>> | >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Frank Shearar

On 31 August 2012 16:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 31 August 2012 08:10, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 31 August 2012 05:04, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>> Frank, >>> >>> I'll try to get the Pharo-2.0 build for builderCI working soon ... >> >> I _think_ it'll be as simple as figuring out how to say "open this >> file, creating it first if necessary" in FileSystem-speak. I realise >> you've not done Metacello+Pharo2 yet, and asked on list hoping that >> one of the FS folk would pipe up with something :) >> > > 'asdasd' asFileReference writeStreamDo: [:s | > s nextPutAll: 'baz' ] But for reading? My debug output's here: http://travis-ci.org/#!/frankshearar/Control/jobs/2288671 and the relevant code (I think) is transcriptStream := ((Smalltalk at: #FileSystem) workingDirectory / transcriptFileName) readStream where transcriptFileName = 'TravisTranscript.txt'. The "old style" file handling works, and says this: transcriptStream := fileDirectoryClass default newFileNamed: transcriptFileName frank >> frank >> >>> Dale >>> >>> ----- Original Message ----- >>> | From: "Frank Shearar" <frank.shearar(a)gmail.com> >>> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> | Cc: "Dale Henrichs" <dhenrich(a)vmware.com> >>> | Sent: Thursday, August 30, 2012 1:52:37 PM >>> | Subject: Pharo 2.0 + Travis = ? >>> | >>> | Hi Dale, >>> | >>> | I'm getting a build failure against Pharo 2.0 [1] with the error >>> | "FileDoesNotExist: >>> | /home/travis/dalehenrich-builderCI-cd2facd/builds/travisCI/TravisTranscript.txt". >>> | >>> | I think that's because the before.st says "transcriptStream := >>> | ((Smalltalk at: #FileSystem) workingDirectory / transcriptFileName) >>> | readStream ]" and that file doesn't exist. >>> | >>> | Is there a convenient way of saying "please open a readStream on this >>> | file and, if it's not there, make one" ? >>> | >>> | (If one semi-replicates the build, by opening a Pharo 2.0 image, >>> | manually loading the ConfigurationOfControl, and running >>> | "ConfigurationOfControl loadDevelopment", one will see Control >>> | 1.1.dev >>> | running with a green light for Pharo 2.0!) >>> | >>> | frank >>> | >>> | [1] http://travis-ci.org/#!/frankshearar/Control/jobs/2282004 >>> | >> > > > > -- > Best regards, > Igor Stasenko. >

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Igor Stasenko

On 31 August 2012 08:10, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 31 August 2012 05:04, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> Frank, >> >> I'll try to get the Pharo-2.0 build for builderCI working soon ... > > I _think_ it'll be as simple as figuring out how to say "open this > file, creating it first if necessary" in FileSystem-speak. I realise > you've not done Metacello+Pharo2 yet, and asked on list hoping that > one of the FS folk would pipe up with something :) > 'asdasd' asFileReference writeStreamDo: [:s | s nextPutAll: 'baz' ] > frank > >> Dale >> >> ----- Original Message ----- >> | From: "Frank Shearar" <frank.shearar(a)gmail.com> >> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> | Cc: "Dale Henrichs" <dhenrich(a)vmware.com> >> | Sent: Thursday, August 30, 2012 1:52:37 PM >> | Subject: Pharo 2.0 + Travis = ? >> | >> | Hi Dale, >> | >> | I'm getting a build failure against Pharo 2.0 [1] with the error >> | "FileDoesNotExist: >> | /home/travis/dalehenrich-builderCI-cd2facd/builds/travisCI/TravisTranscript.txt". >> | >> | I think that's because the before.st says "transcriptStream := >> | ((Smalltalk at: #FileSystem) workingDirectory / transcriptFileName) >> | readStream ]" and that file doesn't exist. >> | >> | Is there a convenient way of saying "please open a readStream on this >> | file and, if it's not there, make one" ? >> | >> | (If one semi-replicates the build, by opening a Pharo 2.0 image, >> | manually loading the ConfigurationOfControl, and running >> | "ConfigurationOfControl loadDevelopment", one will see Control >> | 1.1.dev >> | running with a green light for Pharo 2.0!) >> | >> | frank >> | >> | [1] http://travis-ci.org/#!/frankshearar/Control/jobs/2282004 >> | > -- Best regards, Igor Stasenko.

Aug. 31, 2012

Re: [Pharo-project] What happens with Warning when running in headless image (2.0)?

by Igor Stasenko

On 31 August 2012 15:24, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> wrote: > Hi Igor. > > Here, in a linux box, I guess that this warning occurs and raise the > NonInteractiveUIManager exception, and is showed in stdout when I run in > headless mode. > you'd better wait for Camillo's reply then. Because originally, i wrote that code , so it was ignoring warnings. Then Camillo is added some steroids to it, so an image(s) became far more friendly to consoles, including headless mode. > > 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> >> >> in headless mode all warnings are suppressed (so they don't interfere). >> i'm not sure if it prints something on stdout.. >> it could be that it simply ignored and continues running the stuff. >> >> On 31 August 2012 14:11, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> >> wrote: >> > Hello. >> > >> > I install Seaside in a Pharo 1.4 summer image. Then I run it in headless >> > from console and I go to the /status app, and a "MessageNotUnderstood: >> > >> > NonInteractiveUIManager>>openDebuggerOn:context:label:contents:fullView:" >> > exception occurs and the vm close. >> > >> > Then I run this image in gui and an "Deprecation: The method >> > SmalltalkImage>>isRunningCog has been deprecated." dialog box are >> > raised. I >> > evaluate Deprecation raiseWarning: false but no take effect, the dialog >> > is >> > raised anyway. >> > >> > Maybe another is correct way to disable raise deprecation? >> > >> > 2012/8/31 Camillo Bruni <camillobruni(a)gmail.com> >> >> >> >> if run from the command line you should get a decent error message... >> >> >> >> what kind of error do you get? >> >> >> >> BTW: just show me the code and I'll fix it :P >> >> >> >> On 2012-08-31, at 07:24, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> >> >> >> > I'm running a headless pharo2.0 from a script and the vm disappears >> >> > without a trace (no pharodebug.log info etc.) ... when I run the >> >> > script in a >> >> > gui, I see that a warning dialog box is popping up, so perhaps this >> >> > is the >> >> > source of the issue? ... or perhaps it's something else? >> >> > >> >> > Dale >> >> > >> >> >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Aug. 31, 2012

Re: [Pharo-project] Pharo summer is 14557 or 14457?

by Esteban Lorenzano

oops! I will fix it :P thanks, Esteban On Aug 31, 2012, at 4:40 PM, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> wrote: > Hi. > > I download Pharo-1.4-14557-OneClick.zip (named Pharo Summer in Pharo website), but this image in "System -> About..." dialog is showing Latest update: #14457. But in CI lastest is 1.4 #14459. Maybe it is a typo in zip file name? > > Another little type, in Linux script of Pharo-1.3-13328-OneClick.zip, exec "$BASE/pharo" should be exec "$BASE/CogVM". > > Regards.

Aug. 31, 2012

Re: [Pharo-project] Pharo summer is 14557 or 14457?

by Bernardo Ezequiel Contreras

please, take some time and submit an issue. http://code.google.com/p/pharo/issues/list thanks On Fri, Aug 31, 2012 at 11:40 AM, GastÃ³n Dall' Oglio < gaston.dalloglio(a)gmail.com> wrote: > Hi. > > I download Pharo-1.4-14557-OneClick.zip (named Pharo Summer in Pharo > website), but this image in "System -> About..." dialog is showing Latest > update: #14457. But in CI lastest is 1.4 #14459. Maybe it is a typo in zip > file name? > > Another little type, in Linux script of Pharo-1.3-13328-OneClick.zip, exec > "$BASE/pharo" should be exec "$BASE/CogVM". > > Regards. > -- Bernardo E.C.

Aug. 31, 2012

[Pharo-project] Pharo summer is 14557 or 14457?

by GastÃ³n Dall' Oglio

Hi. I download Pharo-1.4-14557-OneClick.zip (named Pharo Summer in Pharo website), but this image in "System -> About..." dialog is showing Latest update: #14457. But in CI lastest is 1.4 #14459. Maybe it is a typo in zip file name? Another little type, in Linux script of Pharo-1.3-13328-OneClick.zip, exec "$BASE/pharo" should be exec "$BASE/CogVM". Regards.

Aug. 31, 2012

Re: [Pharo-project] ZnClient>>beOneShot

by Sebastian Sastre

yeah I understad the idea and sounds good. I'm sending you in private some screenshots of the debugger... sebastian o/ On Aug 30, 2012, at 5:04 PM, Sven Van Caekenberghe wrote: > Sebastian, > > It would be helpful to know which version of Pharo and Zinc HTTP Components you are using. > > That being said, there is not much special about #beOneShot. ZnClient always does HTTP 1.1 which means it defaults to keeping connections open and handling multiple request/response cycles over it, each side should be ready to handle unexpected closing. What #beOneShot does, is setting 'Connection: close' in the request, which tells the server that it does _not_ intend to send more than one request and will not read more than one response. This is standard behavior. > > I understand that you cannot provide a reproduceable situation, but I need more information if you expect me to help you. Maybe you can send a stacktrace with sensitive information filtered out. What you can also do is inspect both the request and response instance variable of the ZnClient object right after the failure. Since you only get it with one service, it will be related to that service. > > I have no other reports of problems in this area (and ZnClient is used daily in all Pharo 1.3, 1.4 and 2.0 images), but maybe you hit some border case that can help improve the code. > > Sven > > On 30 Aug 2012, at 16:53, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Hi there, >> >> I've started using Zinc in more projects and it's doing well. >> >> Except for one thing :) >> >> Using the http client, I've found exceptions happening when receiving the answer after the request. >> >> I remember one related to someone sending #contents and failing due to entity being nil instead of the expected something stream related (see ZnClient>>contents). >> >> I also found that not using #beOneShot helps. >> >> If I make #beOneShot a no-op by commenting "self optionAt: #oneShot put: true" everything works as expected. >> >> That makes #beOneShot suspicious about making the client to close the connection before getting the contents of the data answered in the stream. It seems to be closing the connection without reading the answer the server sent. >> >> I don't know of more cases but this of course *had* to happen when using Merchant* to talk to my gateway to process credit card payments so you can have an idea how frustrating this is. >> >> With the workaround things are okay so far but I'm a little worried about this bug because it seems that beOneShot is the default for everything http client in Pharo and it is going to be needed a lot. >> >> Let me know how I can be of further help to get this fixed >> >> sebastian >> >> o/ >> >> *Merchant is available in squeak source and yeah, I know, I should move it to ss3 but maybe I'm waiting for smalltalkhub > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Aug. 31, 2012

Re: [Pharo-project] What happens with Warning when running in headless image (2.0)?

by GastÃ³n Dall' Oglio

Somebody send recently similar mail to pharo-user list "[Pharo-users] HowTo not show a Debugger when calling deprecated methods in 1.4?" 2012/8/31 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > Hi Igor. > > Here, in a linux box, I guess that this warning occurs and raise the > NonInteractiveUIManager exception, and is showed in stdout when I run in > headless mode. > > > 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> > >> in headless mode all warnings are suppressed (so they don't interfere). >> i'm not sure if it prints something on stdout.. >> it could be that it simply ignored and continues running the stuff. >> >> On 31 August 2012 14:11, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> >> wrote: >> > Hello. >> > >> > I install Seaside in a Pharo 1.4 summer image. Then I run it in headless >> > from console and I go to the /status app, and a "MessageNotUnderstood: >> > >> NonInteractiveUIManager>>openDebuggerOn:context:label:contents:fullView:" >> > exception occurs and the vm close. >> > >> > Then I run this image in gui and an "Deprecation: The method >> > SmalltalkImage>>isRunningCog has been deprecated." dialog box are >> raised. I >> > evaluate Deprecation raiseWarning: false but no take effect, the dialog >> is >> > raised anyway. >> > >> > Maybe another is correct way to disable raise deprecation? >> > >> > 2012/8/31 Camillo Bruni <camillobruni(a)gmail.com> >> >> >> >> if run from the command line you should get a decent error message... >> >> >> >> what kind of error do you get? >> >> >> >> BTW: just show me the code and I'll fix it :P >> >> >> >> On 2012-08-31, at 07:24, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> >> >> >> > I'm running a headless pharo2.0 from a script and the vm disappears >> >> > without a trace (no pharodebug.log info etc.) ... when I run the >> script in a >> >> > gui, I see that a warning dialog box is popping up, so perhaps this >> is the >> >> > source of the issue? ... or perhaps it's something else? >> >> > >> >> > Dale >> >> > >> >> >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

Aug. 31, 2012

Re: [Pharo-project] What happens with Warning when running in headless image (2.0)?

by GastÃ³n Dall' Oglio

Hi Igor. Here, in a linux box, I guess that this warning occurs and raise the NonInteractiveUIManager exception, and is showed in stdout when I run in headless mode. 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> > in headless mode all warnings are suppressed (so they don't interfere). > i'm not sure if it prints something on stdout.. > it could be that it simply ignored and continues running the stuff. > > On 31 August 2012 14:11, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > wrote: > > Hello. > > > > I install Seaside in a Pharo 1.4 summer image. Then I run it in headless > > from console and I go to the /status app, and a "MessageNotUnderstood: > > NonInteractiveUIManager>>openDebuggerOn:context:label:contents:fullView:" > > exception occurs and the vm close. > > > > Then I run this image in gui and an "Deprecation: The method > > SmalltalkImage>>isRunningCog has been deprecated." dialog box are > raised. I > > evaluate Deprecation raiseWarning: false but no take effect, the dialog > is > > raised anyway. > > > > Maybe another is correct way to disable raise deprecation? > > > > 2012/8/31 Camillo Bruni <camillobruni(a)gmail.com> > >> > >> if run from the command line you should get a decent error message... > >> > >> what kind of error do you get? > >> > >> BTW: just show me the code and I'll fix it :P > >> > >> On 2012-08-31, at 07:24, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> > >> > I'm running a headless pharo2.0 from a script and the vm disappears > >> > without a trace (no pharodebug.log info etc.) ... when I run the > script in a > >> > gui, I see that a warning dialog box is popping up, so perhaps this > is the > >> > source of the issue? ... or perhaps it's something else? > >> > > >> > Dale > >> > > >> > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 31, 2012