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

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Ben Coman

On 7 August 2018 at 20:01, Tim Mackinnon <tim(a)testit.works> wrote: > Hi guys - Iâve been hammering on the exercism project to get pharo shining > over thereâ¦ its been a good side distraction (there is lots of energy in > that community to) and its made me really push my use of Iceberg & git as > well as learn some fo the newish file reference stuff (still getting good > at that - but like the approach), > > Anyway - Iâve got an Alpha working, and users can pull down a zero conf > pharo image and eval a little script that will get them up and running > (which is pretty slick). > > So the story then goes - Exercism is trying to simulate TDD and help you > learn a new language (aka Pharo or Go or Python etc). To this end, theyâve > got an active community building up little test exercises with suites of > tests that new users can run to help them learn the syntax/essence of the > language track theyâve signed up to. You run the tests, develop your > solution and then submit it to a community to get feedback and then > progress. > > Pretty standard - we can play in this pond too - and it turns out that > Tonel actually makes it pretty easy to submit readable solutions that will > fit on their website. YAY. > > The trouble is - when you pull down a new exercise - I use the TonelReader > to pull the code into your image - and I thought it would be cute to just > pull in the TestCase so that users can simulate the full TDD cycle - where > you can create things in the debuggerâ¦ this is where it all began right? > > So you hit a clanger when you do this - and in a way its a bit of a legacy > thing weâve carried around (and possibly should fix better). When Tonel > reads in the TesCase, it normally will reference a class this isnât there > (Iâve deliberately left the solution out). It does the right thing and put > a nil placeholder in the code so that it can read it in. For the purpose of Exercism, I think its reasonable for any class referenced by the TestCase to be loaded as an empty stub. Its not really giving the too much of a head start. If they miss seeing the magic of interactively auto-creating a class, oh well, there is plenty of other magic to show them. And if a solution needs a second class, then they might be exposed to it then. KISS. cheers -ben

Aug. 9, 2018

Re: [Pharo-users] [ANN] Magritte moved to github

by Ben Coman

Hi Sean, On 9 August 2018 at 03:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > NorbertHartl wrote > > https://github.com/magritte-metamodel/magritte > > I'm trying to get my fork [1] back in sync with the upstream now that > you've > ported the code there. > > Conceptually, I'd like to replay the changes in my Magritte fork on top the > last commit that is content-equivalent between the two. After some digging, > this appears to be the upstream's commit `51f648b`, which is equivalent to > the fork's `47df0a5` (both titled "[FIX]: Respect action shortcuts if > specified. Otherwise, default to tâ¦") > > This is the process I've followed so far. Feedback appreciated. > 1. I created an "original_master" branch to preserve the fork's original > history. Maybe this is not necessary long-term? 2. I created a "new_master" branch to merge both histories, based off > upstream/master > 3. I reverted that branch to the shared base commit, `51f648b` > 4. I started a `cherry-pick 47df0a5..eedd386`. A few SO threads said this > is the best way, but cautioned that the commits will have different SHA's i.e., > A..D will become A'..D'. Maybe this is a good thing if we want to preserve > the original history as well (although do we, see #1 above)? OTOH, issues > that referenced commits will now point to old_master, and not masterâ¦ > > On step #4, I've run into merge hell due to metadata. I guess I committed > at > that time with metadata and upstream is metadata-less. How do I dig myself > out without manually approving each file for potentially hundreds of > commits?! > An interesting challenge. I've had a go at it and got it as far as I can without knowing Magritte. I think the remaining conflicts are legitimate and need manual intervention. > > Thanks > > 1. https://github.com/seandenigris/Magritte3 TLDR; You can see the result here... https://github.com/magritte-metamodel/magritte/network Here we go, clone upstream, add your repo as a remote, and check which commits are in which branches. $ git clone git@github.com:magritte-metamodel/magritte.git $ git remote add sean git@github.com:seandenigris/Magritte3.git $ git fetch sean $ git log --grep='Respect action shortcuts' ==>51f648b... $ git log --remotes=sean --grep='Respect action shortcuts' ==>47df0a5... $ git checkout 51f648b -b target $ ls ==> README.md source/ $ git checkout 47df0a5 -b cleanup $ ls ==> README.md respository/ So each branch storing the files in two different directories, I don't see how anything can be automatically merged or even cherry picked like this. To get an idea of the problem need both folders to exist at the same time... $ cp -r repository .. $ git checkout newform $ diff -qr source/ ../repository/ | grep differ | head ==>Files source/Magritte-ContactManager.package/CMAddress.class/properties.json and ../repository/Magritte-ContactManager.package/CMAddress.class/properties.json differ The difference here is the order of fields and the curly brace on its own line, To cleanup of these file... $ find ../repository/ -name "properties.json" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep differ | head indicates cleanup for .filetree files... $ find ../repository/ -name ".filetree" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep differ | head now has no output. good. no conflicting files, but what other meta-files need to be cleaned up... $ diff -qr source/ ../repository/ | grep "Only in ../repository/" $ find ../repository/ -name "methodProperties.json" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep "Only in ../repository/" $ find ../repository/ -name "version" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep "Only in ../repository/" now has no output, so lets double check new stuff only remains in target... $ diff -qr source/ ../repository/ only shows "Only in source/" items which we will keep. So get our cleanup into a commit... $ git checkout cleanup $ rm -r repository $ cp -r ../repository . $ git add -A $ git commit -m "Removed meta data to match upstream" $ mv repository source $ git add -A $ git commit -m "Renamed source folder to match upstream" On github, I forked the repo then added it here as a remote $ git remote add ben git@github.com:bencoman/magritte.git $ git push ben cleanup $ git branch cleanupmerge $ git checkout cleanupmerge $ git merge target and since that was successful... $ git push ben cleanupmerge Now here https://github.com/bencoman/magritte/network it shows there are 66 commits in your 'master' added after 47df0a5, which is where I branched 'cleanup' from. I am guessing the way to go is to first rebase those onto the 'cleanup' commit, then merge that result into 'cleanupmerge' commit. The trouble is, that while the files moved to 'source' folder and meta-files deleted in 'cleanup' should carry through, any newly introduced files will reintroduced the 'repository' directory and associated meta-files. For example... $ git checkout -b rest-rebase sean/master $ git rebase cleanup rest-rebase $ git status ==> Changes to be committed: new file: repository/Magritte-Model.package/Collection.extension/instance/maAllOptionsFor..st new file: repository/Magritte-Model.package/Collection.extension/instance/maSelectMatching..st new file: repository/Magritte-Model.package/MADynamicOptions.class/README.md new file: repository/Magritte-Model.package/MADynamicOptions.class/class/block..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/block..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/block.st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/includes..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/maAllOptionsFor..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/maSelectMatching..st new file: repository/Magritte-Model.package/MADynamicOptions.class/methodProperties.json new file: repository/Magritte-Model.package/MADynamicOptions.class/properties.json modified: source/Magritte-Model.MetaGUI.package/MAOptionDescription.class/instance/allOptions.st Unmerged paths: deleted by us: repository/Magritte-Model.package/Collection.extension/methodProperties.json deleted by us: repository/Magritte-Model.package/MAOptionDescription.class/methodProperties.json deleted by us: repository/Magritte-Model.package/monticello.meta/version The 'modified: source...' line is a positive sign, showing that previous 'cleanup' changes are tracking forward for existing files. All the other lines refer to new files, confirmed by counting them... $ find repository/ -type f | wc -l ==> 14 So for each individual commit is rebased, we need to do the same cleaning steps as above. After some experimentation I came up with this script... $ vi /tmp/clean find repository/ -name "properties.json" -print -exec rm {} \; find repository/ -name ".filetree" -print -exec rm {} \; find repository/ -name "methodProperties.json" -print -exec rm {} \; find repository/ -name "version" -print -exec rm {} \; cd repository cp -r . ../source/ cd .. rm -r repository git reset # ignore files auto-staged by rebase. i.e. make git status empty git add -A git status # show us what we'll be committing I'm still in the middle of the rebase, so now alternate doing the following two lines until the rebase is completed... $ sh /tmp/clean $ rebase --continue I could tell when it was finished when the output matched your current 'master' HEAD. > Applying: Added builders to Magritte-Seaside, so components are builded > Applying: [Enh]: Add `#fieldDescription` and also `git branch` indicated I was back on the... * rest-rebase branch rather than in the middle of rebasing. Now committing & pushing (since I like github graphical network view https://github.com/bencoman/magritte/network) $ git commit -m "Finished rest-rebase" $ git push ben rest-rebase And merge this into 'cleanupmerge' and then merge with the upstream 'master' (creating a new branch only to help the flow be visible on github insights) $ git branch rest-merge $ git checkout rest-merge $ git merge cleanupmerge which looks good. But... $ git merge master throws up some conflicts. However these look legitimate. e.g. diff -r master-source/Magritte-Model.MetaGUI.package/MADescription.class/instance/descriptionLabel.st rest-rebase-source/Magritte-Model.MetaGUI.package/MADescription.class/instance/descriptionLabel.st 8c8 < default: self class defaultLabel; --- > default: self defaultLabel; I don't know how to get `git diff` to do what I want, so.... $ cp -r source ../rest-merge-source $ git checkout master $ cp -r source ../master-source $ cd .. $ diff -qr master-source/ rest-rebase-source/ | grep "differ" | wc -l ==> 44 $ diff -qr master-source/ rest-rebase-source/ | grep "Only in rest-rebase" | grep "\.st" | wc -l ==>58 $ diff -qr master-source/ rest-rebase-source/ | grep "Only in rest-rebase" | grep -v "\.st" | wc -l ==> 22 $ diff -qr master-source/ rest-rebase-source/ | grep "Only in master-source" | grep -v "\.st" | wc -l ==> 465 Whoops. I notice that 'master' has a lot of 'properties.json' files and I killed all the ones in 'rest-rebase'. Was I bit over-zealous there? Anyway, perhaps you can take it from there. To pull my updates. $ git remote add ben git@github.com:bencoman/magritte.git $ git fetch ben $ git checkout -b rest-rebase ben/rest-rebase HTH, cheers -ben

Aug. 9, 2018

Why is there no #assert:notEquals: or #shouldnt:equal: or #deny:equals: method?

by Tim Mackinnon

Iâm trying to write more exercism tests and Iâm baffled why there isnât the inverse equivalent of #assert:equals: which shows a useful test response where you can easily see whatâs going on. #assert:equals: is very nice, showing you a diff browser - I kind of expect the opposite to be there, but it all looks like a bit of mess with assert vs should and deny vs shouldnât -did we change tact somewhere over the years and not deprecate stuff? Tim

Aug. 9, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Tim Mackinnon

Guys - youâre awesome! It really shows why our environment is so powerful and why more people need to think this way! For back porting - you donât need to, as for exercism we are loading a script anyway, so I can load in some code until weâre ready for 7.0 I do agree that infinite debuggers is a pressing problem too (and sorry to distract on that one). Still - we want to present our best face when we go live on exercism - and the pharo features list I copied from Pharo.org (slightly tweaked) drove me to live up to the Hugh standards we set ourselves. Iâll definitely try out what youâve all proposed - I figured if was all possible . Tim Sent from my iPhone > On 9 Aug 2018, at 11:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 9 Aug 2018, at 10:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Hi Marcus, >> >> Is it wise to backport things that may break things like this? > maybe not, but it just took 5 minutes as it is very simple > >> I'd prefer to put the energy on backporting the workaround to avoid the infinite debuggers... >> > > Yes. > >>> On Thu, Aug 9, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>>> >>>>> 2) when coding - if you want reference a missing class, why donât we let you? TonelReader seems to do it, why canât the editor? (This probably applies to variables as well - show them broken, let me fix it when I choose. The iVar case is a little rarer - although I hate the way we prompt fix, prompt fix instead of doing it in one go - itâs very old fashioned) >>>>> >>>> >>>> This is fixed in Pharo7: we added a menu entry âleave undeclaredâ as the first option: >>>> <leave undeclared.png> >>>>> Does anyone have tips on solving these? It spoils the exercism experience that I thought we could convey, so Iâd like to at least fix #1 in 6.1 if I can. >>>>> >>>> >>>> I will back port the fix for 2) to Pharo6 and will do a quick prototype for 1) >>>> >>> >>> https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U… >>> >>> Marcus >>> >> >> >> -- >> >> 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 >> >> Web: http://guillep.github.io >> Phone: +33 06 52 70 66 13 >

Aug. 9, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Norbert Hartl

> Am 08.08.2018 um 14:12 schrieb Herbert VojÄÃk <herby(a)mailbox.sk>: > > > > Damien Pollet wrote on 8. 8. 2018 13:53: >> First of all, quick stupid question: I'm currently loading my code with gitlocal://./src <gitlocal://./src> as the repository URL (my workflow starts in a terminal rather than in a Pharo image) >> Should I just remove the /src part, now that my repo has the project metadata? >> Also, are more features planned for the .project file? E.g. what about storing a default selection for Calypso and the Test Runner in there? >> On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> <mailto:norbert@hartl.name <mailto:norbert@hartl.name>>> wrote: >> - I donât think there can be a âstandard wayâ of defining source >> directory. And I donât think that a tool should enforce this >> however. I keep frontend and backend code in some repositories >> together so the source is in my case in backend/source. What does it >> mean for users not using the âstandardâ name? >> Sure there can. Look at any ruby or maven project, they all have strong conventions for organizing projects and standard config files for deviating from those conventions. >> I would have preferred if Iceberg picked one convention (arbitrarily) in the absence of a .project file instead of forcing its explicit presence. IMHO the choice of default directory per se (be it ./, ./src, ./source or whatever) matters less than the fact that there is a convention in place. >> - I donât see why there needs to be a 1:1 relationship between a >> repository and working copy in pharo. It is like this at the moment >> already but the .project file manifests this. So it should not be >> supported to have more source dirs in one git repo? It might be not >> a good idea that the client has to write the source dir but it opens >> the possibility that there can be more than one. >> I see your point here, but by using separate source directories you're sort of creating a hydra projectâ¦ What I mean here is that the source directories are separate, but their histories are tangled. If you want separate source dirs it kinda means that you want separate change histories, doesn't it? What if the same class has diverging definitions in separate directories (I wonder what maven does in that caseâ¦)? > > There are monorepos. Some people / companies love them. > One of these companies we know for good. It is google. Google has one (!) repositoryf for all their software. And that is the point I want to stretch here. One repo with one project and a standard source directory is too theoretical and too narrow in thoughts. Today there is no possibility to reliably make one product out of multiple repos. Git submodule and git subtree are not even close to something reliable and usable. Descriptions like metacello are language centric. So what is the most secure way of defining a single product? It is the mono repo. That is the main reason I have my sources in backend/source because there is a javascript frontend in the same repo because I want to have one reliable source that defines my product and I can be sure that the backend and frontend are always the ones that match. I donât think it is a good idea if we once leave the island to embrace something like git just to make git islandish a little later. Just to be very clear. We are talking about two files: .project and .properties. I have nothing against .properties because we have multiple formats possible so making it explicit is a good idea. But .project makes every repo a single source repo. If we enforce .properties files why do we not scan the repo for directories containing this file? If none is found we cannot know (or we add looking at some default locations). If multiple directory are found I can add that to iceberg as a real project out of the combination for repository-source directory. This way I could have multiple projects out of one repo. And with the possibility of having multiple source directories it is obvious that the path still needs to be added to a url in metacello. Unless there is one of this directories marked to be the default which would be loaded if no directory is given. This way the default directory would be the one selected if only one is there. So you can have multiple projects in one repo and if this is only one per project the directory can be automatically resolved. Use case kept. Norbert >> On the other hand, separate source directories would be helpful to work with git-subrepo and similar toolsâ¦ >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet <http://people.untyped.org/damien.pollet>

Aug. 9, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Marcus Denker

> On 9 Aug 2018, at 10:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Marcus, > > Is it wise to backport things that may break things like this? maybe not, but it just took 5 minutes as it is very simple > I'd prefer to put the energy on backporting the workaround to avoid the infinite debuggers... > Yes. > On Thu, Aug 9, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >>> 2) when coding - if you want reference a missing class, why donât we let you? TonelReader seems to do it, why canât the editor? (This probably applies to variables as well - show them broken, let me fix it when I choose. The iVar case is a little rarer - although I hate the way we prompt fix, prompt fix instead of doing it in one go - itâs very old fashioned) >>> >> >> This is fixed in Pharo7: we added a menu entry âleave undeclaredâ as the first option: >> <leave undeclared.png> >>> Does anyone have tips on solving these? It spoils the exercism experience that I thought we could convey, so Iâd like to at least fix #1 in 6.1 if I can. >>> >> >> I will back port the fix for 2) to Pharo6 and will do a quick prototype for 1) >> > > https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U… <https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U…> > > Marcus > > > > -- > > 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

Aug. 9, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Guillermo Polito

Hi Marcus, Is it wise to backport things that may break things like this? I'd prefer to put the energy on backporting the workaround to avoid the infinite debuggers... On Thu, Aug 9, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 2) when coding - if you want reference a missing class, why donât we let > you? TonelReader seems to do it, why canât the editor? (This probably > applies to variables as well - show them broken, let me fix it when I > choose. The iVar case is a little rarer - although I hate the way we prompt > fix, prompt fix instead of doing it in one go - itâs very old fashioned) > > > This is fixed in Pharo7: we added a menu entry âleave undeclaredâ as the > first option: > <leave undeclared.png> > > Does anyone have tips on solving these? It spoils the exercism experience > that I thought we could convey, so Iâd like to at least fix #1 in 6.1 if I > can. > > > I will back port the fix for 2) to Pharo6 and will do a quick prototype > for 1) > > > > https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U… > > Marcus > > -- 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

Aug. 9, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Marcus Denker

> >> 2) when coding - if you want reference a missing class, why donât we let you? TonelReader seems to do it, why canât the editor? (This probably applies to variables as well - show them broken, let me fix it when I choose. The iVar case is a little rarer - although I hate the way we prompt fix, prompt fix instead of doing it in one go - itâs very old fashioned) >> > > This is fixed in Pharo7: we added a menu entry âleave undeclaredâ as the first option: > <leave undeclared.png> >> Does anyone have tips on solving these? It spoils the exercism experience that I thought we could convey, so Iâd like to at least fix #1 in 6.1 if I can. >> > > I will back port the fix for 2) to Pharo6 and will do a quick prototype for 1) > https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U… <https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U…> Marcus

Aug. 9, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Marcus Denker

> On 9 Aug 2018, at 10:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >>> 2) when coding - if you want reference a missing class, why donât we let you? TonelReader seems to do it, why canât the editor? (This probably applies to variables as well - show them broken, let me fix it when I choose. The iVar case is a little rarer - although I hate the way we prompt fix, prompt fix instead of doing it in one go - itâs very old fashioned) >>> >> > > > An alternative could be to not show the menu at all. Instead just compile (I like the ideas that âeverything can be compiled and runâ). > > Just compile the Undeclared and instead of breaking the flow, we should add a menu to the editor to do the âdefine Classâ âDefine Traitââ¦ > (with the gutter icons, we can provide a menu easily). > > I will make a small demo for that, too. > ah, and this fits well with the idea to show at runtime a dialog for fixing a Undeclared: The âfix toolâ would be the editor itself. It shows the menu in the gutter for the user to define a class, or the possibility to just edit and compile the method. Marcus

Aug. 9, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Marcus Denker

> > >> 2) when coding - if you want reference a missing class, why donât we let you? TonelReader seems to do it, why canât the editor? (This probably applies to variables as well - show them broken, let me fix it when I choose. The iVar case is a little rarer - although I hate the way we prompt fix, prompt fix instead of doing it in one go - itâs very old fashioned) >> > An alternative could be to not show the menu at all. Instead just compile (I like the ideas that âeverything can be compiled and runâ). Just compile the Undeclared and instead of breaking the flow, we should add a menu to the editor to do the âdefine Classâ âDefine Traitââ¦ (with the gutter icons, we can provide a menu easily). I will make a small demo for that, too. Marcus

Aug. 9, 2018