May 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Is there a tonel:// format for repos?

by Esteban Lorenzano

hi Tim, you cannot use vm âIâ (for Itimer) with iceberg. This timer will kill the SSH sockets. you need the âthreadedâ VM (which is the default, for obvious reasons :P). cheers, Esteban > On 15 May 2018, at 12:18, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Guillermo - so here are the actual log files and the .st Iâm running with build.sh (its a normal pharo command line execution). Its running on Ubuntu 17.10, with Pharo 6.1 64 bit. > > I got Pharo like this: > > VM_STRATEGY="vmI61"; > curl http://get.pharo.org/64/$VM_STRATEGY <http://get.pharo.org/64/$VM_STRATEGY> | bash; > curl get.pharo.org/64/61 <http://get.pharo.org/64/61> | bash; > > The error at the top of the log is: > LGit_GIT_ERROR: SSL error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init > 15 May 2018 3:01:38.976377 am > > And a few lines down you see it has translated the github:// url (in the baseline package) to https but then it seems to failâ¦ although is that https translation correct? I have also tried specifying https repos in the baseline myself (but you canât easily control the baselines it in turn refers to) but that didnât work either. > > LGitRepository>>clone:options:to: > Receiver: a LGitRepository (<not initialized>) > Arguments and temporary variables: > aString: 'https://github.com/ba-st/Willow-Bootstrap.git <https://github.com/ba-st/Willow-Bootstrap.git>' > cloneOptions: a LGitCloneOptions () > aFileReference: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap > Receiver's instance variables: > handle: @ 16r00000000 > repositoryPath: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap > isOpen: nil > workingDirectory: nil > > > > I was successfully doing something like this months ago with PharoLambda - but I suspect if I rerun that pipeline it may also fail like this. > > Tim > > > > <PharoDebug.log> > <loadProject.st> > <LoadProject.log> > <build.sh> > <BaselineOfPagerDuty.class.st> > > >> On 15 May 2018, at 09:36, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >> Hi - Iâll extract the log files when Iâm at my desk >> I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet). >> >> Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04). >> >> Tim >> >> The initial error is: >> >> Starting Load Script... >>> Configure Load caches... >>> Loading Projects... >> >> Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> >> Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> >> Loading baseline of BaselineOfPagerDuty... >> ...RETRY->BaselineOfWillowBootstrap >> ...RETRY->BaselineOfWillowBootstrap >> gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found'...ignoring >> ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st <http://loadproject.st/>' >> Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source <https://github.com/github/ba-st/Willow-Bootstrap:v8/source> ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found' >> MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: >> [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | >> cachedReference := nil. >> packageSpec >> searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" >> cachedReference := self >> resolvePackageSpec: packageSpec >> cachedGofer: self loaderPolicy cacheGofer. >> (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) >> ifTrue: [ cachedReference name = packageSpec file >> ifTrue: >> [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. >> references := self >> retryingResolvePackageSpecReferences: packageSpec >> gofer: gofer. "look up mcz file" >> nearestReference := references last >> asMetacelloCachingResolvedReference. >> (cachedReference ~~ nil >> and: [ cachedReference name = nearestReference name ]) >> ifTrue: [ "latest reference in repository matches cachedReference ... " >> ^ self >> >> >> Sent from my iPhone >> >>> On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Also, are you in Pharo6 or 7? >> >> >

May 15, 2018

How does iceberg handle caching of packages with different versions?

by Tim Mackinnon

Hi - while Iâve been trying to troubleshoot my tonel build woes - I noticed something that might be a potential problem with baselines not loading the correctly specified version. I was having no luck with GitHub:/repo references (see other thread on this), eg: spec baseline: 'WillowBootstrap' with: [ spec repository: 'github://ba-st/Willow-Bootstrap:v8/source'; loads: #('Deployment') ]; import: 'WillowBootstrap'. So I tried using https equivalents like this: spec baseline: 'WillowBootstrap' with: [ spec repository: 'https://github.com/ba-st/Willow-Bootstrap/tree/v8.0.2/source'; loads: #('Deployment') ]; import: 'WillowBootstrap'. But then I wasnât sure if the newer version of the repository was what I was supposed to use and so I altered my spec to use /v8 (not v8.0.2) spec baseline: 'WillowBootstrap' with: [ spec repository: 'https://github.com/ba-st/Willow-Bootstrap/tree/v8/source'; loads: #('Deployment') ]; import: 'WillowBootstrap'. However when I was looking at the log files of errors, I noticed that when I downgraded my spec to v8 and reran my CI on a fresh image the error message still referenced v8.0.2 . As this was a run on my CI (which is preserving the pharo-cache directory between runs) this looked a lot to me like Iceberg/Metacello is not taking into account version numbers or repo urls when loading things from the file cache? When I blew away the pharo-cache and reran it - it then correctly showed me errors referencing v8 again. Is this a known problem? Tim

May 15, 2018

Re: [Pharo-users] Is there a tonel:// format for repos?

by Tim Mackinnon

Hi Guillermo - so here are the actual log files and the .st Iâm running with build.sh (its a normal pharo command line execution). Its running on Ubuntu 17.10, with Pharo 6.1 64 bit. I got Pharo like this: VM_STRATEGY="vmI61"; curl http://get.pharo.org/64/$VM_STRATEGY | bash; curl get.pharo.org/64/61 | bash; The error at the top of the log is: LGit_GIT_ERROR: SSL error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init 15 May 2018 3:01:38.976377 am And a few lines down you see it has translated the github:// url (in the baseline package) to https but then it seems to failâ¦ although is that https translation correct? I have also tried specifying https repos in the baseline myself (but you canât easily control the baselines it in turn refers to) but that didnât work either. LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'https://github.com/ba-st/Willow-Bootstrap.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap isOpen: nil workingDirectory: nil I was successfully doing something like this months ago with PharoLambda - but I suspect if I rerun that pipeline it may also fail like this. Tim > On 15 May 2018, at 09:36, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - Iâll extract the log files when Iâm at my desk > I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet). > > Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04). > > Tim > > The initial error is: > > Starting Load Script... >> Configure Load caches... >> Loading Projects... > > Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src > Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src > Loading baseline of BaselineOfPagerDuty... > ...RETRY->BaselineOfWillowBootstrap > ...RETRY->BaselineOfWillowBootstrap > gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found'...ignoring > ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st' > Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found' > MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | > cachedReference := nil. > packageSpec > searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" > cachedReference := self > resolvePackageSpec: packageSpec > cachedGofer: self loaderPolicy cacheGofer. > (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) > ifTrue: [ cachedReference name = packageSpec file > ifTrue: > [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. > references := self > retryingResolvePackageSpecReferences: packageSpec > gofer: gofer. "look up mcz file" > nearestReference := references last > asMetacelloCachingResolvedReference. > (cachedReference ~~ nil > and: [ cachedReference name = nearestReference name ]) > ifTrue: [ "latest reference in repository matches cachedReference ... " > ^ self > > > Sent from my iPhone > >> On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Also, are you in Pharo6 or 7? > >

May 15, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Tim Mackinnon

Thanks Fabio - it sounds like Sean already has figured something out - but I havenât fully grokâd how it hangs together. From your description, it sounds like you expect SmalltalkCI to be like a submodule of your project - and you can then invoke it from your normal projects build script? However peeking at what Sean pointed at - it seemed like he expected you to intermingle your project with the SmalltalkCI one - so Iâm not really clear on how he uses it. It sounds like all the right pieces are there - just not quite sure what the concept is - particularly given that Gitlab Pipelines already is a CI with the concept of jobs - just not Smalltalk ones. At its best - how does SmalltalkCI function - I never quite understood the pipeline when checked years ago. Tim > On 15 May 2018, at 09:09, Fabio Niephaus <lists(a)fniephaus.com> wrote: > > Hi Tim, > > It should be relatively straightforward to use smalltalkCI on Gitlab CI. > All you have to take care of is to ensure the Linux container has all Pharo dependencies [1] installed correctly. If you append smalltalkCI's `bin` directory to your $PATH, you can simply call `smalltalkci -s Pharo-6.0` in your project's root directory to test against Pharo-6.0. > > Hope this helps. And if you work out a simple and generic way of using smalltalkCI on Gitlab, please feel free to open a PR against smalltalkCI and contribute a template :) > > Best, > Fabio > > [1] https://github.com/travis-ci/travis-build/blob/51ebd738f537a82874b03cb964ec… <https://github.com/travis-ci/travis-build/blob/51ebd738f537a82874b03cb964ec…> > > On Tue, May 15, 2018 at 12:40 AM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Sean - thanks for mentioning that - I tried it ages ago and didnât get on well with it on Travs. But I donât understand how it works on Gitlab - and the project readme.md seems to assume you understand how its approaching the problem (which possibly has changed over the years). > > Looking at your url - how is that running a project that you have in a different repo? Is there some web hook that causes it to then trigger a build cycle? I can see you edited a BaselineOfGitLabCI and added a BabyPhexample <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/commit/d59ba3788aa86bde…> - which seems a bit inside out to me - but Iâm hanging in there (so do you add other projects in this same file?). > > I also donât understand the pipeline model - there seems to be just one pipeline (and gitlab has great pipeline support)? > > And then - when it all builds successfully - how does it deploy (hence my pipeline question). > > Iâm lost - but curious, as maybe I can save time on what Iâm doing (writing more apps vs pissing around with missing infrastructure). > > Tim > >> On 14 May 2018, at 22:38, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >> >> Tim Mackinnon wrote >>> may take another look at SmalltalkCI - the trouble is, I really donât like >>> Travisâ¦ I quite like the model of Gitlabâs one stop shop >> >> I use SmalltalkCI on Gitlab >> (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci>) >> >> >> >> ----- >> Cheers, >> Sean > >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> >>

May 15, 2018

Re: [Pharo-users] Is there a tonel:// format for repos?

by Tim Mackinnon

Hi - Iâll extract the log files when Iâm at my desk I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet). Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04). Tim The initial error is: Starting Load Script... > Configure Load caches... > Loading Projects... Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loading baseline of BaselineOfPagerDuty... ...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found'...ignoring ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found' MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | cachedReference := nil. packageSpec searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer. (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) ifTrue: [ cachedReference name = packageSpec file ifTrue: [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer. "look up mcz file" nearestReference := references last asMetacelloCachingResolvedReference. (cachedReference ~~ nil and: [ cachedReference name = nearestReference name ]) ifTrue: [ "latest reference in repository matches cachedReference ... " ^ self Sent from my iPhone > On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Also, are you in Pharo6 or 7?

May 15, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Fabio Niephaus

Hi Tim, It should be relatively straightforward to use smalltalkCI on Gitlab CI. All you have to take care of is to ensure the Linux container has all Pharo dependencies [1] installed correctly. If you append smalltalkCI's `bin` directory to your $PATH, you can simply call `smalltalkci -s Pharo-6.0` in your project's root directory to test against Pharo-6.0. Hope this helps. And if you work out a simple and generic way of using smalltalkCI on Gitlab, please feel free to open a PR against smalltalkCI and contribute a template :) Best, Fabio [1] https://github.com/travis-ci/travis-build/blob/51ebd738f537a82874b03cb964ec… On Tue, May 15, 2018 at 12:40 AM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Sean - thanks for mentioning that - I tried it ages ago and didnât get > on well with it on Travs. But I donât understand how it works on Gitlab - > and the project readme.md seems to assume you understand how its > approaching the problem (which possibly has changed over the years). > > Looking at your url - how is that running a project that you have in a > different repo? Is there some web hook that causes it to then trigger a > build cycle? I can see you edited a BaselineOfGitLabCI and added a > BabyPhexample > <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/commit/d59ba3788aa86bde…> - > which seems a bit inside out to me - but Iâm hanging in there (so do you > add other projects in this same file?). > > I also donât understand the pipeline model - there seems to be just one > pipeline (and gitlab has great pipeline support)? > > And then - when it all builds successfully - how does it deploy (hence my > pipeline question). > > Iâm lost - but curious, as maybe I can save time on what Iâm doing > (writing more apps vs pissing around with missing infrastructure). > > Tim > > On 14 May 2018, at 22:38, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote > > may take another look at SmalltalkCI - the trouble is, I really donât like > Travisâ¦ I quite like the model of Gitlabâs one stop shop > > > I use SmalltalkCI on Gitlab > (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci) > > > > ----- > Cheers, > Sean > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 15, 2018

Re: [Pharo-users] Pharo70 session start and silent failures

by Guillermo Polito

https://pharo.fogbugz.com/f/cases/21907/Freezes-on-startup On Tue, May 15, 2018 at 9:29 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Thanks, I'll open an issue and check it. > > On Tue, May 15, 2018 at 8:35 AM, Holger Freyther <holger(a)freyther.de> > wrote: > >> >> >> > On 14. May 2018, at 17:39, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > >> >> > >> > Can you give me more details about how to reproduce it? >> >> 1.) Load MCZ into image (ignore the missing dependency) >> >> http://smalltalkhub.com/mc/osmocom/Core/main/OsmoCore-Holger >> HansPeterFreyther.43.mcz >> >> >> 2.) Save image >> >> => Image is now "frozen" (with "save and quit" it would be broken for >> good) >> >> >> > You're loading a baseline as a startup action? As a startup script? >> >> >> I start and stop processes and Denis has pointed out to have had issues >> with it as well. >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > 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 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

May 15, 2018

Re: [Pharo-users] Pharo70 session start and silent failures

by Guillermo Polito

Thanks, I'll open an issue and check it. On Tue, May 15, 2018 at 8:35 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > > On 14. May 2018, at 17:39, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > > > > Can you give me more details about how to reproduce it? > > 1.) Load MCZ into image (ignore the missing dependency) > > http://smalltalkhub.com/mc/osmocom/Core/main/OsmoCore- > HolgerHansPeterFreyther.43.mcz > > > 2.) Save image > > => Image is now "frozen" (with "save and quit" it would be broken for good) > > > > You're loading a baseline as a startup action? As a startup script? > > > I start and stop processes and Denis has pointed out to have had issues > with it as well. > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

May 15, 2018

Re: [Pharo-users] Pharo70 session start and silent failures

by Holger Freyther

> On 14. May 2018, at 17:39, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > Can you give me more details about how to reproduce it? 1.) Load MCZ into image (ignore the missing dependency) http://smalltalkhub.com/mc/osmocom/Core/main/OsmoCore-HolgerHansPeterFreyth… 2.) Save image => Image is now "frozen" (with "save and quit" it would be broken for good) > You're loading a baseline as a startup action? As a startup script? I start and stop processes and Denis has pointed out to have had issues with it as well.

May 15, 2018

Re: [Pharo-users] Is there a tonel:// format for repos?

by Guillermo Polito

Also, are you in Pharo6 or 7?

May 15, 2018