- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Does ZnHTTPSTests>>#testGetPharoVersion actually run on the CI servers ?

by Esteban Lorenzano

he... yep, Camillo changed it as part of latest ci refactors Esteban On Feb 22, 2013, at 12:13 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > OK, good ;-) > > What about the URL ? > > It is now > > https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… > > it used to be > > https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x… > > Is this call/URL still possible or has it changed ? > > Thx, > > Sven > > On 22 Feb 2013, at 12:07, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> It is failing (only now?) >> >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/lastCompletedBuild/testReport/ >> >> ;) >> >> On 2013-02-22, at 12:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Hi, >>> >>> When testing in #20561 I noticed that ZnHTTPSTests>>#testGetPharoVersion consistently fails for me (Mac OS X, NBCog VM), probably because the URL is wrong - this is a function/regression test on https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… >>> >>> My point is that I don't see that failing on the CI servers, but maybe I looked in the wrong places. >>> >>> The test code does contain a >>> >>> self isNativeSSLPluginPresent ifFalse: [ ^ self ]. >>> >>> so it is possible that the test is skipped. >>> >>> But if that test is skipped, many more are skipped as well, and that would be not-goodâ¢. >>> >>> Sven >>> >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >>> >> >> > >

Feb. 22, 2013

Re: [Pharo-project] Does ZnHTTPSTests>>#testGetPharoVersion actually run on the CI servers ?

by Sven Van Caekenberghe

OK, good ;-) What about the URL ? It is now https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… it used to be https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x… Is this call/URL still possible or has it changed ? Thx, Sven On 22 Feb 2013, at 12:07, Camillo Bruni <camillobruni(a)gmail.com> wrote: > It is failing (only now?) > > https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/lastCompletedBuild/testReport/ > > ;) > > On 2013-02-22, at 12:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> When testing in #20561 I noticed that ZnHTTPSTests>>#testGetPharoVersion consistently fails for me (Mac OS X, NBCog VM), probably because the URL is wrong - this is a function/regression test on https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… >> >> My point is that I don't see that failing on the CI servers, but maybe I looked in the wrong places. >> >> The test code does contain a >> >> self isNativeSSLPluginPresent ifFalse: [ ^ self ]. >> >> so it is possible that the test is skipped. >> >> But if that test is skipped, many more are skipped as well, and that would be not-goodâ¢. >> >> Sven >> >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> > >

Feb. 22, 2013

Re: [Pharo-project] Does ZnHTTPSTests>>#testGetPharoVersion actually run on the CI servers ?

by Camillo Bruni

It is failing (only now?) https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/lastCompletedBuild/testReport/ ;) On 2013-02-22, at 12:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > When testing in #20561 I noticed that ZnHTTPSTests>>#testGetPharoVersion consistently fails for me (Mac OS X, NBCog VM), probably because the URL is wrong - this is a function/regression test on https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… > > My point is that I don't see that failing on the CI servers, but maybe I looked in the wrong places. > > The test code does contain a > > self isNativeSSLPluginPresent ifFalse: [ ^ self ]. > > so it is possible that the test is skipped. > > But if that test is skipped, many more are skipped as well, and that would be not-goodâ¢. > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Feb. 22, 2013

[Pharo-project] Does ZnHTTPSTests>>#testGetPharoVersion actually run on the CI servers ?

by Sven Van Caekenberghe

Hi, When testing in #20561 I noticed that ZnHTTPSTests>>#testGetPharoVersion consistently fails for me (Mac OS X, NBCog VM), probably because the URL is wrong - this is a function/regression test on https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… My point is that I don't see that failing on the CI servers, but maybe I looked in the wrong places. The test code does contain a self isNativeSSLPluginPresent ifFalse: [ ^ self ]. so it is possible that the test is skipped. But if that test is skipped, many more are skipped as well, and that would be not-goodâ¢. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 22, 2013

[Pharo-project] MongoTalk dependency on Grease

by Janko MivÅ¡ek

Hi guys, While loading ConfigurationOfMongoTalk the Grease loaded also RefactoringBrowser, Slime, etc. Does MongoTalk really needs RefactoringBrowser and Sime for its work? Even more, isn't better to achieve MongoTalk portability with less invasive approach like more careful and "least common denominator" coding, etc? Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 22, 2013

Re: [Pharo-project] A matter with Delays

by Igor Stasenko

On 21 February 2013 20:56, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > On Thu, Feb 21, 2013 at 3:28 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Hi. >> >> There is one thing which is IMO an over-engineering artifact: >> - when system goes down (image shutdown), all currently scheduled >> delays are "saved" >> and then when image starting up they are rescheduled again to keep >> waiting what time is left for delay.. > > Right now one says Delay forMilliseconds: n etc. That's clearly a > duration. An API which said Delay until: aTime is different, and > could be added to the current API easily. > yes. Still this won't make #forMilliseconds: protocol less ambiguous. > One good reason for keeping the current behaviour is profiling image > shutdown and startup. The current MessageTally is slightly broken in > this regard but I fixed it at Cadence to profile our start-up > slowness. > > So please consider carefully throwing this behaviour away. I at least > find it quite useful. Can you shed some details? How delay's implementation helps with that? >> >> But the problem is that it does not takes into account the total time >> an image was frozen, and the requirement is quite ambiguous: >> >> - if you put a process on a delay for 5 minutes, then immediately >> save image, and then restart it 10 minutes (or 1 year) after, >> should this delay keep waiting for 4 +x seconds which is left? Or >> should we consider this delay as utterly expired? >> (and as you can see, the answer is different, if we counting time >> using real, physical time, or just image uptime). >> >> And why counting image uptime? Consider use cases, like connection >> timeout.. it is all about >> real time , right here , right now.. will it matter to get socket >> connection timeout error when you restart some image 1 year after? >> Please, give me a scenario, which will illustrate that we cannot live >> without it and should count image uptime for delays, because i can't >> find one. >> >> If not, then to my opinion, and to simplify all logic inside delay >> code, i would go straight and declare following: >> - when new image session starts, all delays, no matter for how long >> they are scheduled to wait are considered expired (and therefore all >> waiting processes >> is automatically resumed). >> >> Because as tried to demonstrate, the meaning of delay which spans over >> multiple image sessions is really fuzzy and i would be really >> surprised to find a code >> which relies on such behavior. >> >> This change will also can be helpful with terminating all processes >> which were put on wait for too long (6304550344559763 milliseconds) by >> mistake or such. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

Feb. 22, 2013

Re: [Pharo-project] Pharo in Debian

by phil＠highoctane.be

Hi, I do not really care about being in the official repositories at this point, but rather be able to add our own to the list of repositories (even by hand) so that we can get apt-get install pharovm and apt-get install pharo20 just do their trick. There is a ton of software requiring addition of their repos so it is a doable route IMV. Then we could think about going into the offical repos. Anyway, I now have a fresh Debian 6 up and running, along with SVN. Next step, get the VM sources, build for linux, get the VM running. Then, package the whole thing. Hopefully doable in beta form for april. Phil 2013/2/22 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 22 Feb 2013, at 10:16, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> Hi Philippe, >> >> On Thu, Feb 21, 2013 at 10:19 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>> I don't have a clue about Debian packaging but as there is already >>> squeak, we may be able to reuse a bit. >> >> >> it would be great if you could have a look at that. > > Yes, that would indeed be super, but it is slightly more complicated than that. > > In order to get your package into the official repositories, you need to follow a lot of rules and processes, and it is quite slow and conservative (months if not years), all to increase quality and stability. I am not sure it matches well with Pharo's development velocity. > > The One-Click, the scripts that Camillo did or just a plain VM download with basic documentation (like a read me ;-) are not that bad. We should make an effort to improve what we have. > > Sven > >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Feb. 22, 2013

Re: [Pharo-project] Pharo in Debian

by Norbert Hartl

Am 22.02.2013 um 10:28 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 22 Feb 2013, at 10:16, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> Hi Philippe, >> >> On Thu, Feb 21, 2013 at 10:19 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>> I don't have a clue about Debian packaging but as there is already >>> squeak, we may be able to reuse a bit. >> >> >> it would be great if you could have a look at that. > > Yes, that would indeed be super, but it is slightly more complicated than that. > > In order to get your package into the official repositories, you need to follow a lot of rules and processes, and it is quite slow and conservative (months if not years), all to increase quality and stability. I am not sure it matches well with Pharo's development velocity. > > The One-Click, the scripts that Camillo did or just a plain VM download with basic documentation (like a read me ;-) are not that bad. We should make an effort to improve what we have. > I don't see much of a reason to go for the official distribution. Debian is very special in that case and the last attempts to do it have shown that the two systems (debian and pharo) are no good match process wise. To the rescue there is launchpad [1] and PPAs (personal package archives). You can open a project in launchpad and make a PPA for your own package. The final installation instructions are somthing like sudo add-apt-repository ppa:LAUNCHPAD-USER/PPA-NAME and then sudo apt-get update sudo apt-get install PACKAGENAME I assume that the ease of installing is the main target and that you can get with PPA. my two cents, Norbert [1] https://launchpad.net/

Feb. 22, 2013

Re: [Pharo-project] About Pharo extras

by phil＠highoctane.be

sweet 2013/2/22 stephane ducasse <stephane.ducasse(a)free.fr>: > done :) > >

Feb. 22, 2013

Re: [Pharo-project] Pharo in Debian

by Sven Van Caekenberghe

On 22 Feb 2013, at 10:16, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi Philippe, > > On Thu, Feb 21, 2013 at 10:19 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> I don't have a clue about Debian packaging but as there is already >> squeak, we may be able to reuse a bit. > > > it would be great if you could have a look at that. Yes, that would indeed be super, but it is slightly more complicated than that. In order to get your package into the official repositories, you need to follow a lot of rules and processes, and it is quite slow and conservative (months if not years), all to increase quality and stability. I am not sure it matches well with Pharo's development velocity. The One-Click, the scripts that Camillo did or just a plain VM download with basic documentation (like a read me ;-) are not that bad. We should make an effort to improve what we have. Sven > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 22, 2013