- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

by Alistair Grant

Hi Guille, On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote: > I don't think so... Build number only works from the CI. This means > that if you build your image in your machine you'll have no build > number and then this piece of code will not work neither. Thus maybe > we need to find a separate solution for it? P.S. Shouldn't the highestUpdate still be set as described below? This is an image that presumably came from the CI (http://files.pharo.org/image/70/latest.zip) Thanks, Alistair > On 8/22/17, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Everyone, > > > > I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit), > > but am getting an error while loading OSsubprocess. > > > > The error occurs in FFISharedPool class>>initialize: > > > > > > initialize > > self flag: #removeIt. > > "This IF will be eliminated soon...only here temporary" > > (SystemVersion current highestUpdate >= 50558) > > ifTrue: [ > > SessionManager default registerToolClassNamed: self name > > ] > > ifFalse: [ > > Smalltalk addToStartUpList: self. > > ] > > > > > > because #highestUpdate is nil. > > > > > > The top of the stack is: > > > > UndefinedObject(Object)>>doesNotUnderstand: #'>=' > > FFISharedPool class>>initialize > > MCMethodDefinition>>postloadOver: > > [ :each | each postloadOver: (self obsoletionFor: each) ] in > > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each postloadOver: > > (self obsoletionFor: ...etc... > > > > > > Based on the method above, it looks like highestUpdate used to be set > > based on the image number, and has presumably broken during the move to > > Pharo 7 and git. > > > > Earlier Pharo 7 images had it set to 0, which doesn't sound right. > > > > Since a build number was recently introduced (fogbugz 20321), should the > > highestUpdate be set to 70000+buildNumber? > > > > E.g. this image has an identifier of: > > > > Pharo 7.0 > > Build information: > > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6 > > > > So highestUpdate would be 70056. > > > > > > Thanks! > > Alistair > > > > > > > -- > > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Aug. 22, 2017

Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

by Alistair Grant

On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote: > I don't think so... Build number only works from the CI. This means > that if you build your image in your machine you'll have no build > number and then this piece of code will not work neither. Thus maybe > we need to find a separate solution for it? Good point. I guess that #registerToolClassNamed: was introduced around image #50558 and didn't exist in earlier versions, so the test could be replaced with: SessionManager default respondsTo: #registerToolClassNamed: I'll see if I can download an older Pharo 5 VM and image and check (pre 50558). Thanks, Alistair > On 8/22/17, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Everyone, > > > > I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit), > > but am getting an error while loading OSsubprocess. > > > > The error occurs in FFISharedPool class>>initialize: > > > > > > initialize > > self flag: #removeIt. > > "This IF will be eliminated soon...only here temporary" > > (SystemVersion current highestUpdate >= 50558) > > ifTrue: [ > > SessionManager default registerToolClassNamed: self name > > ] > > ifFalse: [ > > Smalltalk addToStartUpList: self. > > ] > > > > > > because #highestUpdate is nil. > > > > > > The top of the stack is: > > > > UndefinedObject(Object)>>doesNotUnderstand: #'>=' > > FFISharedPool class>>initialize > > MCMethodDefinition>>postloadOver: > > [ :each | each postloadOver: (self obsoletionFor: each) ] in > > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each postloadOver: > > (self obsoletionFor: ...etc... > > > > > > Based on the method above, it looks like highestUpdate used to be set > > based on the image number, and has presumably broken during the move to > > Pharo 7 and git. > > > > Earlier Pharo 7 images had it set to 0, which doesn't sound right. > > > > Since a build number was recently introduced (fogbugz 20321), should the > > highestUpdate be set to 70000+buildNumber? > > > > E.g. this image has an identifier of: > > > > Pharo 7.0 > > Build information: > > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6 > > > > So highestUpdate would be 70056. > > > > > > Thanks! > > Alistair > > > > > > > -- > > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Aug. 22, 2017

Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

by Guillermo Polito

I don't think so... Build number only works from the CI. This means that if you build your image in your machine you'll have no build number and then this piece of code will not work neither. Thus maybe we need to find a separate solution for it? On 8/22/17, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Everyone, > > I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit), > but am getting an error while loading OSsubprocess. > > The error occurs in FFISharedPool class>>initialize: > > > initialize > self flag: #removeIt. > "This IF will be eliminated soon...only here temporary" > (SystemVersion current highestUpdate >= 50558) > ifTrue: [ > SessionManager default registerToolClassNamed: self name > ] > ifFalse: [ > Smalltalk addToStartUpList: self. > ] > > > because #highestUpdate is nil. > > > The top of the stack is: > > UndefinedObject(Object)>>doesNotUnderstand: #'>=' > FFISharedPool class>>initialize > MCMethodDefinition>>postloadOver: > [ :each | each postloadOver: (self obsoletionFor: each) ] in > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each postloadOver: > (self obsoletionFor: ...etc... > > > Based on the method above, it looks like highestUpdate used to be set > based on the image number, and has presumably broken during the move to > Pharo 7 and git. > > Earlier Pharo 7 images had it set to 0, which doesn't sound right. > > Since a build number was recently introduced (fogbugz 20321), should the > highestUpdate be set to 70000+buildNumber? > > E.g. this image has an identifier of: > > Pharo 7.0 > Build information: > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6 > > So highestUpdate would be 70056. > > > Thanks! > Alistair > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 22, 2017

Re: [Pharo-dev] [ Pharo 70 ] Build 52 to 54

by Guillermo Polito

Hi Marcus, Please, do not relaunch the build if there is a test failure. That simply does not fix the problem, it just adds noise. There are two problems: 1) we have some sporadic test failures (sometimes network, sometimes some mutex or delay issues). They do not happen all the time and that's why sometimes there is one or two failing tests. We should detect these tests and fix them to be more robust >> Note, is there some brave soul that would like to take action here? 2) sometimes the vm crashes while running the tests. We should detect the bug and fix it. >> Note, is there some brave soul that would like to take action here? Now, if we are integrating a fix, this means that the PR was **already validated as green**. That means that the integrated commit can be bootstrapped and tested (and all tests are green). Moreover, running the tests after integration (and its build color) does not change the integration in itself: the commit was already merged and pushed into the main branch, so even if it fails always, it's too late. So, relaunching the build does not really change anything (besides the impression we may have about the build). A complementary solution (that should go together with fixing the tests) is to add a retry policy while running tests in the CI. >> Note, is there some brave soul that would like to take action here? Guille, on holidays from the phone. On 8/22/17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > [ Pharo 70 ] Build 52 PR 205 > index-inst-var-should-move-from-Slot-to-IndexedSlot > https://github.com/pharo-project/pharo/pull/205 > https://pharo.fogbugz.com/f/cases/20191 > > Build 53: failed, redone as 54 > > [ Pharo 70 ] Build 54 PR 193 Integrate WebBrowser-Core package to be able to > open a browser on a URL > https://pharo.fogbugz.com/f/cases/20304 > https://github.com/pharo-project/pharo/pull/193 > > Build 55: failed, redone as 56 (I do not like to use this build numberâ¦ > with builds failing, we will always get the > question âand what was in build XX?). > > [ Pharo 70 ] Build 56 PR 174 > 20260-FastTable-not-support-cell-morphs-with-stepping-animation #174 > https://github.com/pharo-project/pharo/pull/174 > https://pharo.fogbugz.com/f/cases/20260/ > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 22, 2017

SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

by Alistair Grant

Hi Everyone, I'm attempting to update to the latest Pharo7 image (918efe2, 32 bit), but am getting an error while loading OSsubprocess. The error occurs in FFISharedPool class>>initialize: initialize self flag: #removeIt. "This IF will be eliminated soon...only here temporary" (SystemVersion current highestUpdate >= 50558) ifTrue: [ SessionManager default registerToolClassNamed: self name ] ifFalse: [ Smalltalk addToStartUpList: self. ] because #highestUpdate is nil. The top of the stack is: UndefinedObject(Object)>>doesNotUnderstand: #'>=' FFISharedPool class>>initialize MCMethodDefinition>>postloadOver: [ :each | each postloadOver: (self obsoletionFor: each) ] in MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each postloadOver: (self obsoletionFor: ...etc... Based on the method above, it looks like highestUpdate used to be set based on the image number, and has presumably broken during the move to Pharo 7 and git. Earlier Pharo 7 images had it set to 0, which doesn't sound right. Since a build number was recently introduced (fogbugz 20321), should the highestUpdate be set to 70000+buildNumber? E.g. this image has an identifier of: Pharo 7.0 Build information: alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6 So highestUpdate would be 70056. Thanks! Alistair

Aug. 22, 2017

[ Pharo 70 ] Build 52 to 54

by Marcus Denker

[ Pharo 70 ] Build 52 PR 205 index-inst-var-should-move-from-Slot-to-IndexedSlot https://github.com/pharo-project/pharo/pull/205 https://pharo.fogbugz.com/f/cases/20191 Build 53: failed, redone as 54 [ Pharo 70 ] Build 54 PR 193 Integrate WebBrowser-Core package to be able to open a browser on a URL https://pharo.fogbugz.com/f/cases/20304 https://github.com/pharo-project/pharo/pull/193 Build 55: failed, redone as 56 (I do not like to use this build numberâ¦ with builds failing, we will always get the question âand what was in build XX?). [ Pharo 70 ] Build 56 PR 174 20260-FastTable-not-support-cell-morphs-with-stepping-animation #174 https://github.com/pharo-project/pharo/pull/174 https://pharo.fogbugz.com/f/cases/20260/

Aug. 22, 2017

Re: [Pharo-dev] TechTalk Dates for the rest of 2017

by Marcus Denker

> On 22 Aug 2017, at 13:02, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>> I'm not sure Pharo tech talk is the good place but would love to see such a presentation. >>> >> Why not? I am sure Alex will have some code in there.. " programming, from scratch, a small artificial intelligenceâ >> if done with Pharo would be a very nice thing todo for the tech talk. > > Yes, that is the plan. It could be a very practical lecture, with a lot of coding (but not many lines of code). > I added it for October 17th: https://association.pharo.org/event-2642664 Marcus

Aug. 22, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Marcus Denker

> On 18 Aug 2017, at 09:56, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> What I think would have been good is to list all the updates that where done between >> releasing 6.0 and 6.1 *as part of the changelog* of 6.1 (even though they were already >> in the image that you got a minute before Pharo6.1 was released, as they where released as >> hot fixes before). >> > > The changelog of things done between releasing 6.0 and the release of 6.1: > I added a link to the complete changeling to http://pharo.org/news/pharo6.1-released <http://pharo.org/news/pharo6.1-released> Marcus

Aug. 22, 2017

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

by Stephane Ducasse

Thanks Alistair. On Thu, Aug 17, 2017 at 5:50 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Thu, Aug 17, 2017 at 05:08:40PM +0200, Stephane Ducasse wrote: >> I do not know but I imagine that I added basenameWithoutExtension because >> I found the name much much clearer. I would have never guessed that >> base is the basename without the extension. >> >> Stef > > Thanks for the clarification. Although #base isn't the name without the > extension, it is the portion of the name up to the first extension > delimiter (for names with a single extension delimiter the two will of > course be the same, but for names with multiple extension delimiters > they will be different). > > In that case, assuming no one else comes up with additional > information, I would argue that the issue should be closed (rejected), > and Michael should change his code to use #basenameWithoutExtension > instead of #base. > > It would be nice to improve the comments in the code - I'll add it to my > list. :-) > > > Cheers, > Alistair > > >> On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > Hi All, >> > >> > I've just taken a look at issue 19609 FileReference>>base should be >> > before last separator and wonder whether it is a correct interpretation >> > of the original intentions. >> > >> > The original author of the issue, Michael, seems to feel that >> > FileReferene>>base and FileReference>>basenameWithoutExtension are the >> > same. >> > >> > My reading of the comments is that they perform a different function, >> > i.e.: >> > >> > >> > '/a/b/c.d.e' asFileReference base. "c" >> > '/a/b/c.d.e' asFileReference basenameWithoutExtension. "c.d" >> > >> > >> > are both the expected values, i.e.: >> > >> > - #base answers the name up to the first extensionDelimiter. >> > - #basenameWithoutExtension answers the name without what is typically >> > considered the file extension (the bit after the last >> > extensionDelimiter). >> > >> > Not shown above, but: >> > >> > - #basename answers the entire filename, i.e. "c.d.e". >> > >> > >> > Does anyone know the history of these methods? >> > >> > >> > Cheers, >> > Alistair >> > >> >

Aug. 22, 2017

Re: [Pharo-dev] Launcher Opening Tiny Windows

by Stephane Ducasse

Yes I experienced this problem too. I have the impression that during the build the size of the window are messed up. Stef On Sun, Aug 20, 2017 at 2:44 AM, Tim Mackinnon <tim(a)testit.works> wrote: > It's a known problem for any image that was saved in headless mode (not just launcher) - we should find a way to resolve this. > > Tim > > Sent from my iPhone > >> On 20 Aug 2017, at 00:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Check out this screenshot. >> <http://forum.world.st/file/n4962615/Screenshot_2017-08-19_19.png> >> >> The red arrow points to an open "window" of a newly created Pharo 6.0 based >> image, minimized to the point of barely being visible. Clicking on it makes >> a title bar somewhat more visible, the edges of which can then be dragged as >> any other window. >> >> Anyone else seeing this? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Launcher-Opening-Tiny-Windows-tp4962615.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

Aug. 22, 2017