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

Re: [Pharo-users] Smalltalk CI on Gitlab

by Tim Mackinnon

Hi Sean - it certainly sounds like its worth a poke. Have you written anything else up about it - or is this the âuser manualâ for now? Presumable a lot of the below could go in the readme.md for the project itself. So to get started with it - is the intent that you fork it so you can customise the settings? OR do you make it a submodule of your existing project so that you can access the scripts? As you want to trigger something when you checkin your smalltalk code - is it a trigger in that project that kicks off a separate SmalltalkCIGL project to then do its stuff, or do you just just include it in your current project so you can reference these scripts? This is the bit Iâm not understanding? Reading below - am I understanding that when you get your pipeline trigger, you use GitLabCIConfiguration to write out some config that you can then get SmalltalkCI to interpret with the assets that you have? Iâl have to go back and look again. Tim > On 15 May 2018, at 14:25, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote >> But I donât understand how it works on Gitlab > > The gitlab-smalltalk-ci project performs three roles: > 1. The glue which connects Gitlab and smalltalkCI. As a bonus, it does all > the necessary in-container work to setup SSH for private Gitlab projects, so > you'd just have to create/enable the deploy key in the Gitlab web UI. > 2. A Pharo library to create/modify CI artifacts like configuration files. > This let's you write Smalltalk like this `GitLabCIConfiguration new > smalltalkImageTemplateFor: 'Pharo-6.1'` instead of being forced to remember > and write: > ```yaml > .pharo61_template: &pharo61 > variables: > SMALLTALK_IMAGE: "Pharo-6.1" > ``` > 3. An example to adapt for your own project, since it eats its own dog food > and is handling its own CI. > > Also, note that the initial setup is simplified from smalltalkCI because it > uses a Docker image preloaded with all the Pharo dependencies. > > 1. First, you would create a `.gitlab-ci.yml`. I'm guessing you already know > that it is the equivalent to Travis' `.travis.yml`, which is the main hook > that the CI system picks up to run whatever you tell it to. If you read it, > you will see that it's main job is to install the glue scripts and run the > downloaded scripts/build.sh. The bottom ~half is the workaround for matrix > builds (for Pharo 6 & 7) in GitlabCI, which are not directly supported. > 2. Next, create a `.smalltalk.ston`. This is the main config hook for > smalltalkCI. I added some links to the docs in the README. > > That's really it I think. All this has been tested extensively with real > projects, but only on Pharo 6/7 and Ubuntu 32 bit. PRs welcome and feel free > to ask more questions! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

May 15, 2018

Re: [Pharo-users] Spec on Moose 6.0 error: MessageNotUnderstood: ToolDockingBarMorph>>popUpOwner

by Arturo Zambrano

Thanks! It is weird, it only happens with second level menus (in a toolbar)... I will take a look to check if I'm doing something different. cheers art On Tue, May 15, 2018 at 9:59 AM, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi Arturo, > > It doesn't happen to my anymore. See the code in Grafoscopio for > GrafoscopioDockingBar to see the code for the working solution. > > Cheers, > > Offray > > On 11/05/18 16:21, Arturo Zambrano wrote: > > Hi Offray > I have the same problem(Pharo 6.1), it only happens while opening > submenus. did you find a solution? > > thanks > > On Sat, Nov 21, 2015 at 2:49 PM, Offray Vladimir Luna CÃ¡rdenas < > offray(a)riseup.net> wrote: > >> Hi, >> >> I'm getting this error while trying to prototype some interface with Spec >> on Moose 6.0: >> >> MessageNotUnderstood: ToolDockingBarMorph>>popUpOwner >> >> it happens anytime that I'm using displaying a MenuModel and I go to the >> menu items. I imagine that the menu item is complaining about a lacking pop >> up message. How can I solve this? >> >> Thanks, >> >> Offray >> >> > >

May 15, 2018

Re: [Pharo-users] How to add item to world menu

by Alexandre Bergel

Hi! I wrote an help some times ago. It is part of Pharo: Cheers, Alexandre > On May 13, 2018, at 12:23 PM, chrismihaylyk <chrismihaylyk(a)gmail.com> wrote: > > Hi! > > I need to add an item to world menu. I know how to add it manually by > running some method. > But I need this item to be added automatically into world menu just along > installing (loading) package code from smalltalkhub. > > Can anyone help me, please? =) > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

May 15, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Sean P. DeNigris

Tim Mackinnon wrote > But I donât understand how it works on Gitlab The gitlab-smalltalk-ci project performs three roles: 1. The glue which connects Gitlab and smalltalkCI. As a bonus, it does all the necessary in-container work to setup SSH for private Gitlab projects, so you'd just have to create/enable the deploy key in the Gitlab web UI. 2. A Pharo library to create/modify CI artifacts like configuration files. This let's you write Smalltalk like this `GitLabCIConfiguration new smalltalkImageTemplateFor: 'Pharo-6.1'` instead of being forced to remember and write: ```yaml .pharo61_template: &pharo61 variables: SMALLTALK_IMAGE: "Pharo-6.1" ``` 3. An example to adapt for your own project, since it eats its own dog food and is handling its own CI. Also, note that the initial setup is simplified from smalltalkCI because it uses a Docker image preloaded with all the Pharo dependencies. 1. First, you would create a `.gitlab-ci.yml`. I'm guessing you already know that it is the equivalent to Travis' `.travis.yml`, which is the main hook that the CI system picks up to run whatever you tell it to. If you read it, you will see that it's main job is to install the glue scripts and run the downloaded scripts/build.sh. The bottom ~half is the workaround for matrix builds (for Pharo 6 & 7) in GitlabCI, which are not directly supported. 2. Next, create a `.smalltalk.ston`. This is the main config hook for smalltalkCI. I added some links to the docs in the README. That's really it I think. All this has been tested extensively with real projects, but only on Pharo 6/7 and Ubuntu 32 bit. PRs welcome and feel free to ask more questions! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 15, 2018

Re: [Pharo-users] Spec on Moose 6.0 error: MessageNotUnderstood: ToolDockingBarMorph>>popUpOwner

by Offray Vladimir Luna CÃ¡rdenas

Hi Arturo, It doesn't happen to my anymore. See the code in Grafoscopio for GrafoscopioDockingBar to see the code for the working solution. Cheers, Offray On 11/05/18 16:21, Arturo Zambrano wrote: > Hi Offray > Â I have the same problem(Pharo 6.1), it only happens while opening > submenus. did you find a solution? > > thanks > > On Sat, Nov 21, 2015 at 2:49 PM, Offray Vladimir Luna CÃ¡rdenas > <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: > > Hi, > > I'm getting this error while trying to prototype some interface > with Spec on Moose 6.0: > > MessageNotUnderstood: ToolDockingBarMorph>>popUpOwner > > it happens anytime that I'm using displaying a MenuModel and I go > to the menu items. I imagine that the menu item is complaining > about a lacking pop up message. How can I solve this? > > Thanks, > > Offray > >

May 15, 2018

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

by Sean P. DeNigris

EstebanLM wrote > you cannot use vm âIâ (for Itimer) with iceberg. I was guessing VM as well, or 64 bit, because those were the obvious differences between my setup and yours. The only part I found hard at all on Gitlab was loading other private projects from Gitlab, which require a bit of infrastructure with SSH keys and secret variables (let me know if you ever run into this!). ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 15, 2018

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

by Cyril Ferlicot D.

Le 15/05/2018 Ã 14:45, Esteban Lorenzano a Ã©critÂ : > you can safely ignore that warning in most cases (in fact, I was > thinking on removing it and replace for a small log or even nothing). > It would be great! Most of the time it just makes noise in the CI logs :( There is a PR to remove this warning in the VM repo (https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/144) But there is no review. It dates from July 2017. > cheers, > Esteban > > -- Cyril Ferlicot https://ferlicot.fr

May 15, 2018

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

by Esteban Lorenzano

you can safely ignore that warning in most cases (in fact, I was thinking on removing it and replace for a small log or even nothing). cheers, Esteban > On 15 May 2018, at 14:42, Tim Mackinnon <tim(a)testit.works> wrote: > > Ah - well that would be one problem then - I was using that to avoid that warning message you get as I didnât think I had privileges to do what it said - however it seems it would be better to have a proper docker container to run my CI builds in, and so I can probably solve it that way (the iTimer VM was something I picked up from PharoLambda - as you really canât control that environment at all - but it doesnât run Iceberg). > > Iâll make that correction and try again. > > Thanks, > > Tim > >> On 15 May 2018, at 12:28, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> 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 <mailto:tim@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 <http://loadproject.st/>> >>> <LoadProject.log> >>> <build.sh> >>> <BaselineOfPagerDuty.class.st <http://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

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

by Tim Mackinnon

Ah - well that would be one problem then - I was using that to avoid that warning message you get as I didnât think I had privileges to do what it said - however it seems it would be better to have a proper docker container to run my CI builds in, and so I can probably solve it that way (the iTimer VM was something I picked up from PharoLambda - as you really canât control that environment at all - but it doesnât run Iceberg). Iâll make that correction and try again. Thanks, Tim > On 15 May 2018, at 12:28, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > 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 <mailto:tim@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 <http://loadproject.st/>> >> <LoadProject.log> >> <build.sh> >> <BaselineOfPagerDuty.class.st <http://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

Re: [Pharo-users] How does iceberg handle caching of packages with different versions?

by Herbert VojÄÃk

Tim Mackinnon wrote: > 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'; Did this actually work? Seems strange to me, as AFAICT 'https://...' urls are represented as mcz ones, not git ones. > 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