- Pharo-users - lists.pharo.org

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Marcus Denker

> On 3 May 2018, at 10:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 2 May 2018, at 14:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 26 Apr 2018, at 09:28, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> Hi, >>> >>> It looks you got bit by this issue: >>> >>> https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well… >>> >>> It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo. >>> >> >> It can be fixed by moving the binding to undeclared in #removeFromSystem: >> >> This is done by adding >> >> Undeclared declare: self name asSymbol from: Smalltalk globals. >> >> before the "forgetClass: self logged:" line. >> >> What we need to do in addition: Only do that when the class is referenced. #isUsedClass: does that, but it does integrate over all methods in the system. >> > > I did a PR: > > https://github.com/pharo-project/pharo/pull/1281 > In the end I split the PR in two: #isReferenced first (already in) and now the one liner to put classes that are still referenced into Undeclared: https://github.com/pharo-project/pharo/pull/1374 This just adds self isReferenced ifTrue: [Undeclared declare: self name asSymbol from: Smalltalk globals]. And it seems to workâ¦ Marcus

May 17, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Tim Mackinnon

Hi Sean - I stand corrected, #remoteTypeSelector: doesnât seem to be needed (a case of getting all the other stuff right - and Docker is such a huge help for this). For SmalltalkCI the automatic Test side might win me over. Does it also spot load load failures (like Undeclared class) and do a nice test report? I just spotted Seaside isnât loading cleanly with my RegEx setup - but its crude. This has been very fruitful BTW , thanks Tim Sent from my iPhone Sent from my iPhone > On 16 May 2018, at 19:54, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote >> the use of Iceberg and projects using github:// (which needs them by >> default) causes quite a lot of pain (even if they arenât private repos). >> â¦ >> Iceberg >> enableMetacelloIntegration: true; >> remoteTypeSelector: #httpsUrl. > > This is part of my standard workflow and I didn't experience it as a pain > point. It seems I uploaded my public GH key, but after that it "just > worked". IIRC it seemed to automatically fallback to https when ssh failed, > but it's been a while and I'm not in front of a pipeline. The first message > is needed, especially to use `gitlab://` URLs, but I never used the second. > > > Tim Mackinnon wrote >> the reality is all you are really plugging into Gitlab is: >> â¦loadProject.stâ¦ testProject.st > > I guess you could say that, except smalltalkCI also handles any needed > setup, like Linux 32-bit libs (which I handle with Docker instead). Also, it > saves you from having to construct the .st files in your example because: > - there is a configuration model that allows you to specify the baseline > name, target platforms, etc instead of manually writing load scripts > - smalltalkCI remembers which tests it loaded and runs those automatically, > so by default no extra work is needed to enable testing > > > Tim Mackinnon wrote >> by no means is this a citicismâ¦ > > All good :) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

May 16, 2018

Re: [Pharo-users] Morphic, Canvas, and Drawing Polygon Borders

by Nicolai Hess

Hi Eric, I don't know exactly how Borders (BorderdMorphs) are drawn, but a simple way to create that kind of 1px border with 2px round edges may be using the a borderd morph: BorderedMorph new fillStyle: Color transparent; borderStyle: (RoundedBorder new cornerRadius: 2; width: 1; baseColor: Color red) Combining this with a Complex border to create that button with different colors for left-up/right-bottom edges is maybe more difficult. 2018-05-16 20:48 GMT+02:00 Eric Gade <eric.gade(a)gmail.com>: > I am having some trouble accurately drawing polygons using Morphic and the > various Canvas types. > > My task is to recreate the Mac OS Platinum style buttons, and do be as > pixel-accurate as I can. For the basic button, this involves creating a > rectangle whose corners are always fattened by 2px on each side, no matter > the extent of the underlying morph: > > > â > I can achieve this kind of outline when drawing individual lines one at a > time with a Canvas: > > ```smalltalk > > canvas := FormCanvas extent: 150@30. > > rect := Rectangle point: (0@0) point: (150@30). > > vertices := { > (rect left)@(rect top + 2). > (rect left + 2)@(rect top). > (rect right - 3)@(rect top). > (rect right - 1)@(rect top + 2). > (rect right -1)@(rect bottom - 3). > (rect right - 3)@(rect bottom -1). > (rect left + 2)@(rect bottom - 1). > (rect left)@(rect bottom - 3). > "(rect left)@(rect top + 2)" }. > > canvas > line: (vertices at: 1) to: (vertices at: 2) color: Color black; > line: (vertices at: 2) to: (vertices at: 3) color: Color black; > line: (vertices at: 3) to: (vertices at: 4) color: Color black; > line: (vertices at: 4) to: (vertices at: 5) color: Color black; > line: (vertices at: 5) to: (vertices at: 6) color: Color black; > line: (vertices at: 6) to: (vertices at: 7) color: Color black; > line: (vertices at: 7) to: (vertices at: 8) color: Color black; > line: (vertices at: 8) to: (vertices at: 1) color: Color black. > > canvas form asMorph openInWindow. > > ``` > > Which gives me: > > â > But using the native Polygon drawing features of Canvas yield a different, > and incorrect, result: > > ```smalltalk > > canvas := FormCanvas extent: 150@30. > > rect := Rectangle point: (0@0) point: (150@30). > > vertices := { > (rect left)@(rect top + 2). > (rect left + 2)@(rect top). > (rect right - 3)@(rect top). > (rect right - 1)@(rect top + 2). > (rect right -1)@(rect bottom - 3). > (rect right - 3)@(rect bottom -1). > (rect left + 2)@(rect bottom - 1). > (rect left)@(rect bottom - 3). > "(rect left)@(rect top + 2)" }. > > canvas drawPolygon: vertices fillStyle: Color transparent borderWidth: 1 borderColor: Color black. > > canvas form asMorph openInHand. > > ``` > > > > â > Either this is some kind of limitation in BalloonCanvas/BalloonEngine > (which "becomes" the canvas for polygon draw operations) or I am doing > something terribly wrong. > > Ideally I can trace this shape as a border, since I'll need to trace yet > more additional borders around it (like the "default" button in Platinum, > which has a fat complex border). > > Borders are already kind of complicated, so any help you all can provide > would be much appreciated. > > FYI this same behavior is present in Squeak. > > -- > Eric >

May 16, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Sean P. DeNigris

Tim Mackinnon wrote > the use of Iceberg and projects using github:// (which needs them by > default) causes quite a lot of pain (even if they arenât private repos). > â¦ > Iceberg > enableMetacelloIntegration: true; > remoteTypeSelector: #httpsUrl. This is part of my standard workflow and I didn't experience it as a pain point. It seems I uploaded my public GH key, but after that it "just worked". IIRC it seemed to automatically fallback to https when ssh failed, but it's been a while and I'm not in front of a pipeline. The first message is needed, especially to use `gitlab://` URLs, but I never used the second. Tim Mackinnon wrote > the reality is all you are really plugging into Gitlab is: > â¦loadProject.stâ¦ testProject.st I guess you could say that, except smalltalkCI also handles any needed setup, like Linux 32-bit libs (which I handle with Docker instead). Also, it saves you from having to construct the .st files in your example because: - there is a configuration model that allows you to specify the baseline name, target platforms, etc instead of manually writing load scripts - smalltalkCI remembers which tests it loaded and runs those automatically, so by default no extra work is needed to enable testing Tim Mackinnon wrote > by no means is this a citicismâ¦ All good :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 16, 2018

Morphic, Canvas, and Drawing Polygon Borders

by Eric Gade

I am having some trouble accurately drawing polygons using Morphic and the various Canvas types. My task is to recreate the Mac OS Platinum style buttons, and do be as pixel-accurate as I can. For the basic button, this involves creating a rectangle whose corners are always fattened by 2px on each side, no matter the extent of the underlying morph: â I can achieve this kind of outline when drawing individual lines one at a time with a Canvas: ```smalltalk canvas := FormCanvas extent: 150@30. rect := Rectangle point: (0@0) point: (150@30). vertices := { (rect left)@(rect top + 2). (rect left + 2)@(rect top). (rect right - 3)@(rect top). (rect right - 1)@(rect top + 2). (rect right -1)@(rect bottom - 3). (rect right - 3)@(rect bottom -1). (rect left + 2)@(rect bottom - 1). (rect left)@(rect bottom - 3). "(rect left)@(rect top + 2)" }. canvas line: (vertices at: 1) to: (vertices at: 2) color: Color black; line: (vertices at: 2) to: (vertices at: 3) color: Color black; line: (vertices at: 3) to: (vertices at: 4) color: Color black; line: (vertices at: 4) to: (vertices at: 5) color: Color black; line: (vertices at: 5) to: (vertices at: 6) color: Color black; line: (vertices at: 6) to: (vertices at: 7) color: Color black; line: (vertices at: 7) to: (vertices at: 8) color: Color black; line: (vertices at: 8) to: (vertices at: 1) color: Color black. canvas form asMorph openInWindow. ``` Which gives me: â But using the native Polygon drawing features of Canvas yield a different, and incorrect, result: ```smalltalk canvas := FormCanvas extent: 150@30. rect := Rectangle point: (0@0) point: (150@30). vertices := { (rect left)@(rect top + 2). (rect left + 2)@(rect top). (rect right - 3)@(rect top). (rect right - 1)@(rect top + 2). (rect right -1)@(rect bottom - 3). (rect right - 3)@(rect bottom -1). (rect left + 2)@(rect bottom - 1). (rect left)@(rect bottom - 3). "(rect left)@(rect top + 2)" }. canvas drawPolygon: vertices fillStyle: Color transparent borderWidth: 1 borderColor: Color black. canvas form asMorph openInHand. ``` â Either this is some kind of limitation in BalloonCanvas/BalloonEngine (which "becomes" the canvas for polygon draw operations) or I am doing something terribly wrong. Ideally I can trace this shape as a border, since I'll need to trace yet more additional borders around it (like the "default" button in Platinum, which has a fat complex border). Borders are already kind of complicated, so any help you all can provide would be much appreciated. FYI this same behavior is present in Squeak. -- Eric

May 16, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Tim Mackinnon

Hi Sean/Fabio - Iâm still mulling over which direction to jump. When experimenting with PharoLambda and a minimal image it was all very custom and so I just used GitLab ânativelyâ - and as you have noted - Gitlab has got a lot of built in CI stuff. Now my need has expanded to something a bit more normal - I was a bit caught out that the above didnât just work the same. As its turned out - what has been the hiccup has been not having a good stable Linux image to build on (Iâve now learned Docker to sort that bit out - and really must +++ the need to have some pharo.org <http://pharo.org/> docker containers just sitting there for people to use). The other issue has been what you have said - in a clean build environment you donât have ssh keys normally defined and and the use of Iceberg and projects using github:// (which needs them by default) causes quite a lot of pain (even if they arenât private repos). I mention this as Herby spotted it a while ago as he doesnât use GitHub - however he also spotted a solution that I donât think you are aware of (judging from your gitlab project) - in your preload script add the following: Iceberg enableMetacelloIntegration: true; remoteTypeSelector: #httpsUrl. This was the piece I was missing - and now my project is loading fine (in its fresh docker environment). You of course probably still have Private repos and in that case I think you still need the ssh keys sorted - but for a more general case I donât think its needed. This long path (which has usefully solidified lots of things for me) still leaves me unsure as to whether I personally need SmalltalkCI for simple single vendor projects (as when used in GitLab - its not really doing any CI - it seems more useful for muli-dialect building I think). Maybe you guys might set me straight on thisâ¦ the reality is all you are really plugging into Gitlab is: pharo Pharo.image --no-default-preferences --save --quit st loadProject.st \ "{'$PROJECT_NAME'. '$PROJECT_API_KEY'}" 2>&1 | tee LoadProject.log And if you are also doing some testing a second invocation (ideally in a separate build stage) of: pharo Pharo.image --no-default-preferences --save --quit st testProject.st \ "{'$PROJECT_NAME'. '$PROJECT_API_KEY'}" 2>&1 | tee TestProject.log And with a good docker image it seems pretty straight forward. Possibly there are components in SmalltalkCI that could be extracted - maybe to interpret test results? Or I am wondering if its useful to pump stats into something like DataDog to track image size and test run times etc? Iâm still interested in both your thoughts though - and by no means is this a citicism of SmalltalkCI or Gitlab-Smalltalk-CI - both of which help the community (and me) immensely through providing great examples and knowledgable people in this stuff. Tim > On 16 May 2018, at 02:50, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote >> Have you written anything else up about it - or is this the âuser manualâ >> for now? > > The latter :) It was an itch I scratched because GL offers unlimited private > projects and significant CI build time for free and then shared just in case > others were struggling with the same thing, but I'm happy to answer > questions and add to the docs. > > > Tim Mackinnon wrote >> Presumable a lot of the below could go in the readme.md for the project >> itself. > > Already done! > > > Tim Mackinnon wrote >> So to get started with it > > In your project's root folder, if you copy `.gitlab-ci.yml` verbatim and > modify `.smalltalk.ston` as needed, it should start building your project on > top of Pharo 6 & 7 on 32-bit Ubuntu LTS. The Smalltalk image versions can be > changed to anything accepted by smalltalkCI, and I think to support other > OS'es we'd just need to build alternate Docker images [1]. You would only > need to fork gitlab-smalltalk-ci if you want to modify the internals of the > library itself. If you just want to customize any of the scripts in > ./scripts [2] on a per-project basis, you can just save overridden copies in > ./scripts in your project. The library will not overwrite existing script > files in that location. > > FYI I did not explore deploy steps yet. I was actually waiting to develop > further because the next thing I want is separate build and test steps so > one can immediately know whether the installation or testing failed, and it > seemed that might be added to smalltalkCI in the near future. > > 1. There is also a related library which enables you to generate docker > files from Pharo. See > https://github.com/seandenigris/smalltalkCI/tree/docker/repository/Smalltal… > 2. https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/tree/master/scripts > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

May 16, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Fabio Niephaus

On Wed, May 16, 2018 at 3:34 AM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > fniephaus wrote > > 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. > > > > This is only needed for private repos on GitLab, right? > > Correct. > > > fniephaus wrote > > This library needs to be used manually, right? Or is this somehow part of > > the build process? > > The library is used to generate the artifacts (e.g. config files), which > are > then committed to be picked up by the CI. I assume that's what you meant by > "manually"? > Yes, that's what I meant. Up until now, templates have worked quite well, but I can also see why a library would be helpful at some point. > > > fniephaus wrote > > I think it'd be great if we could somehow merge your additions back into > > smalltalkCI's repo. > > Definitely open to that. I got it "working" for my use cases and then > paused. IIRC I did open a few issues in smalltalkCI related to this and > Docker. > Yes, you did. And I hope I have more time to work on smalltalkCI features soon...the list is getting longer and longer. > > > fniephaus wrote > > I'd love to hear your feedback on the solution I suggested in my previous > > email. Any ideas how to make it better? > > Which one? > This one: https://gist.github.com/fniephaus/b95c4ed15abd8c4305277f51fbe21fee > > > fniephaus wrote > > Have a look at the launcher script for smalltalkCI [1] used in the Docker > > image. > > I will. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 16, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Sean P. DeNigris

Tim Mackinnon wrote > Have you written anything else up about it - or is this the âuser manualâ > for now? The latter :) It was an itch I scratched because GL offers unlimited private projects and significant CI build time for free and then shared just in case others were struggling with the same thing, but I'm happy to answer questions and add to the docs. Tim Mackinnon wrote > Presumable a lot of the below could go in the readme.md for the project > itself. Already done! Tim Mackinnon wrote > So to get started with it In your project's root folder, if you copy `.gitlab-ci.yml` verbatim and modify `.smalltalk.ston` as needed, it should start building your project on top of Pharo 6 & 7 on 32-bit Ubuntu LTS. The Smalltalk image versions can be changed to anything accepted by smalltalkCI, and I think to support other OS'es we'd just need to build alternate Docker images [1]. You would only need to fork gitlab-smalltalk-ci if you want to modify the internals of the library itself. If you just want to customize any of the scripts in ./scripts [2] on a per-project basis, you can just save overridden copies in ./scripts in your project. The library will not overwrite existing script files in that location. FYI I did not explore deploy steps yet. I was actually waiting to develop further because the next thing I want is separate build and test steps so one can immediately know whether the installation or testing failed, and it seemed that might be added to smalltalkCI in the near future. 1. There is also a related library which enables you to generate docker files from Pharo. See https://github.com/seandenigris/smalltalkCI/tree/docker/repository/Smalltal… 2. https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/tree/master/scripts ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 16, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Sean P. DeNigris

fniephaus wrote > 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. > > This is only needed for private repos on GitLab, right? Correct. fniephaus wrote > This library needs to be used manually, right? Or is this somehow part of > the build process? The library is used to generate the artifacts (e.g. config files), which are then committed to be picked up by the CI. I assume that's what you meant by "manually"? fniephaus wrote > I think it'd be great if we could somehow merge your additions back into > smalltalkCI's repo. Definitely open to that. I got it "working" for my use cases and then paused. IIRC I did open a few issues in smalltalkCI related to this and Docker. fniephaus wrote > I'd love to hear your feedback on the solution I suggested in my previous > email. Any ideas how to make it better? Which one? fniephaus wrote > Have a look at the launcher script for smalltalkCI [1] used in the Docker > image. I will. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 16, 2018

Re: [Pharo-users] Smalltalk CI on Gitlab

by Fabio Niephaus

Hi Sean, Sorry, I just saw your response. Questions/comments are inline... On Tue, May 15, 2018 at 3:26 PM 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. > This is only needed for private repos on GitLab, right? > 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" > ``` This library needs to be used manually, right? Or is this somehow part of the build process? > 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! > Sorry for not being very responsive recently, I've been super busy. I think it'd be great if we could somehow merge your additions back into smalltalkCI's repo. It's much easier, especially for users, if everything is in one place. Also, I'd love to hear your feedback on the solution I suggested in my previous email. Any ideas how to make it better? Have a look at the launcher script for smalltalkCI [1] used in the Docker image. I'm sure we could at least add the private repo ssh-agent setup process in there as well. PRs welcome! :) Cheers, Fabio [1] https://github.com/hpi-swa/smalltalkCI/blob/docker/smalltalkci > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 15, 2018