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 Guillermo Polito

Hi Tim, I can only tell you that I agree with you ^^. Last year we worked with Stef and Luc on the idea of undefined classes ( https://hal.archives-ouvertes.fr/hal-01585305/document) The code is available in smalltalkhub if I remember well (check the links in the paper). We did not integrate it because all the changes in Pharo were already a lot (new contribution process, moving to Git, new CI, and lots of other changes). It also means that it would require some more iterations, because we used it to download big and old projects, but never really tested it for TDD :) But if you would like, it's there to give it a try Guille On Thu, Aug 9, 2018 at 8:21 AM Tim Mackinnon <tim(a)testit.works> wrote: > Feenk re-imagining aside (which I will pursue with them), it seems like > our current tools can support this better right? > > I see two issues: > > 1) if we encounter a not present class can we fix the debugger to offer > something like we do for a missing method so itâs less obtuse? > > 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) > > 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. > > Tim > > Sent from my iPhone > > On 9 Aug 2018, at 01:44, Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com> > wrote: > > +1 > > On Tue, 7 Aug 2018 at 09:02 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. >> >> HOWEVER - when you run your test and hit that nil class placeholder we do >> a very bad job of dealing with this in the debugger. And if you think about >> it - we also do a bad job when typing in code too - we essentially insist >> that declare a class then and there - unlike a selector which can happily >> be late bound. >> >> So back to my TDD example - user gets a debugger with a nil class error - >> the create button is actually not helpful for you as it only creates >> methods. So our âlive in the debuggerâ mantra is a bit less obvious here. >> What you had to do is make a change to the source (like a space) so that >> you can reserve the method - which then causes you to get the âcreate class >> promptâ. So we have the ability - just donât expose it very well - however >> now you have a missing method - but again its not so obvious that you have >> to resume your debugger (it hasnât resumed when you created the class) - >> and then you will get another error for the missing method that the create >> button will now resolve. >> >> This feels very clunky to me - and makes me feel like Iâm mis-selling >> smalltalk where we have a bullet point about âAmazing for debuggingâ¦â. >> >> This feels fixable though right? Iâm wondering about thoughts though >> before jumping inâ¦ >> >> Tim >> >> p.s. - weâre building some exercises for exercism and getting that >> process streamlined so hopefully many more people can help - and maybe we >> can augment the great learning courses/videos/books that we already have. >> >> >> >> -- > Sent from the past > > -- 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

> On 9 Aug 2018, at 08:20, Tim Mackinnon <tim(a)testit.works> wrote: > > Feenk re-imagining aside (which I will pursue with them), it seems like our current tools can support this better right? > > I see two issues: > > 1) if we encounter a not present class can we fix the debugger to offer something like we do for a missing method so itâs less obtuse? > Right now we compile an âUndeclaredâ variable: a bining #name -> nil that lives in the Undeclareds dictionary. The result is that this variable is nil when read. This seems a good behaviour for non-interactive use, but not the right thing when doing development. In Pharo, these bindings are actually now not just Associations, but there is a class Hierarchy. The object describing the global binding is actually a UndeclaredVariable. You can see that like this: compile this with a non-existing âMyClassâ (see below, Pharo7 can do it even in interactive mode): test ^MyClass. then (TT>>#test) literals first class Now: the compiler actually asks that object to generate the code for the read. If you look at class UndeclaredVariable, it looks like this: emitValue: methodBuilder methodBuilder pushLiteralVariable: self So we could do an experiment: couldnât we generate code here that actually starts an interaction? Similar to the one (see below) that we do when the user tries to compile a method with an Undeclared in the first place (see below). > 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: > 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) > Tim > > Sent from my iPhone > > On 9 Aug 2018, at 01:44, Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com <mailto:patchinko@gmail.com>> wrote: > >> +1 >> >> On Tue, 7 Aug 2018 at 09:02 Tim Mackinnon <tim(a)testit.works <mailto:tim@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. >> >> HOWEVER - when you run your test and hit that nil class placeholder we do a very bad job of dealing with this in the debugger. And if you think about it - we also do a bad job when typing in code too - we essentially insist that declare a class then and there - unlike a selector which can happily be late bound. >> >> So back to my TDD example - user gets a debugger with a nil class error - the create button is actually not helpful for you as it only creates methods. So our âlive in the debuggerâ mantra is a bit less obvious here. What you had to do is make a change to the source (like a space) so that you can reserve the method - which then causes you to get the âcreate class promptâ. So we have the ability - just donât expose it very well - however now you have a missing method - but again its not so obvious that you have to resume your debugger (it hasnât resumed when you created the class) - and then you will get another error for the missing method that the create button will now resolve. >> >> This feels very clunky to me - and makes me feel like Iâm mis-selling smalltalk where we have a bullet point about âAmazing for debuggingâ¦â. >> >> This feels fixable though right? Iâm wondering about thoughts though before jumping inâ¦ >> >> Tim >> >> p.s. - weâre building some exercises for exercism and getting that process streamlined so hopefully many more people can help - and maybe we can augment the great learning courses/videos/books that we already have. >> >> >> >> -- >> Sent from the past

Aug. 9, 2018

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

by Tim Mackinnon

Feenk re-imagining aside (which I will pursue with them), it seems like our current tools can support this better right? I see two issues: 1) if we encounter a not present class can we fix the debugger to offer something like we do for a missing method so itâs less obtuse? 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) 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. Tim Sent from my iPhone > On 9 Aug 2018, at 01:44, Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com> wrote: > > +1 > >> On Tue, 7 Aug 2018 at 09:02 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. >> >> HOWEVER - when you run your test and hit that nil class placeholder we do a very bad job of dealing with this in the debugger. And if you think about it - we also do a bad job when typing in code too - we essentially insist that declare a class then and there - unlike a selector which can happily be late bound. >> >> So back to my TDD example - user gets a debugger with a nil class error - the create button is actually not helpful for you as it only creates methods. So our âlive in the debuggerâ mantra is a bit less obvious here. What you had to do is make a change to the source (like a space) so that you can reserve the method - which then causes you to get the âcreate class promptâ. So we have the ability - just donât expose it very well - however now you have a missing method - but again its not so obvious that you have to resume your debugger (it hasnât resumed when you created the class) - and then you will get another error for the missing method that the create button will now resolve. >> >> This feels very clunky to me - and makes me feel like Iâm mis-selling smalltalk where we have a bullet point about âAmazing for debuggingâ¦â. >> >> This feels fixable though right? Iâm wondering about thoughts though before jumping inâ¦ >> >> Tim >> >> p.s. - weâre building some exercises for exercism and getting that process streamlined so hopefully many more people can help - and maybe we can augment the great learning courses/videos/books that we already have. >> >> >> > -- > Sent from the past

Aug. 9, 2018

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

by Francisco Ortiz PeÃ±aloza

+1 On Tue, 7 Aug 2018 at 09:02 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. > > HOWEVER - when you run your test and hit that nil class placeholder we do > a very bad job of dealing with this in the debugger. And if you think about > it - we also do a bad job when typing in code too - we essentially insist > that declare a class then and there - unlike a selector which can happily > be late bound. > > So back to my TDD example - user gets a debugger with a nil class error - > the create button is actually not helpful for you as it only creates > methods. So our âlive in the debuggerâ mantra is a bit less obvious here. > What you had to do is make a change to the source (like a space) so that > you can reserve the method - which then causes you to get the âcreate class > promptâ. So we have the ability - just donât expose it very well - however > now you have a missing method - but again its not so obvious that you have > to resume your debugger (it hasnât resumed when you created the class) - > and then you will get another error for the missing method that the create > button will now resolve. > > This feels very clunky to me - and makes me feel like Iâm mis-selling > smalltalk where we have a bullet point about âAmazing for debuggingâ¦â. > > This feels fixable though right? Iâm wondering about thoughts though > before jumping inâ¦ > > Tim > > p.s. - weâre building some exercises for exercism and getting that process > streamlined so hopefully many more people can help - and maybe we can > augment the great learning courses/videos/books that we already have. > > > > -- Sent from the past

Aug. 8, 2018

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

by Cyril Ferlicot D.

Le 08/08/2018 Ã 18:46, Norbert Hartl a Ã©critÂ : > I moved magritte code today from smalltalkhub to github. I also changed the dependencies of magritte for grease and seaside to be the github repositories and not smalltalkhub. > > Please let us work on github for magritte and update smalltalkhub when necessary. > > Hope you like it! Travis build has also been added. > > Norbert > > Hi Norbert, Thank you. It is great if with this repo we can archive an official magritte repository! Especially if we can get Sean enhancements. -- Cyril Ferlicot https://ferlicot.fr

Aug. 8, 2018

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

by Sean P. DeNigris

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?! Thanks 1. https://github.com/seandenigris/Magritte3 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 8, 2018

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

by Norbert Hartl

Forgot a link to the repo https://github.com/magritte-metamodel/magritte <https://github.com/magritte-metamodel/magritte> > Am 08.08.2018 um 18:46 schrieb Norbert Hartl <norbert(a)hartl.name>: > > I moved magritte code today from smalltalkhub to github. I also changed the dependencies of magritte for grease and seaside to be the github repositories and not smalltalkhub. > > Please let us work on github for magritte and update smalltalkhub when necessary. > > Hope you like it! Travis build has also been added. > > Norbert > >

Aug. 8, 2018

[ANN] Magritte moved to github

by Norbert Hartl

I moved magritte code today from smalltalkhub to github. I also changed the dependencies of magritte for grease and seaside to be the github repositories and not smalltalkhub. Please let us work on github for magritte and update smalltalkhub when necessary. Hope you like it! Travis build has also been added. Norbert

Aug. 8, 2018

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

by Herbert VojÄÃk

Damien Pollet wrote on 8. 8. 2018 13:53: > First of all, quick stupid question: I'm currently loading my code with > 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>> 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. > 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

Aug. 8, 2018

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

by Herbert VojÄÃk

Norbert Hartl wrote on 8. 8. 2018 10:27: > > >> Am 07.08.2018 um 16:00 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >> >> Hi, >> >> I'll write down some of the reasons of the project's design, like that I can afterwards copy paste it in the wiki :). >> >> First, this design did not came up from an egg. We worked on it for about two months. And it is thought to be backwards compatible and manage lots of metacello particularities. It may have things that are perfectible, sure, so let's discuss it. >> >> One of the main problems we saw in metacello, and that Iceberg inherited, was the "source subdirectory" thing. This source directory had to be specified in the CLIENT, meaning that every time we clone a repository we should know by heart the directory chose by its developer. Moreover, we lack a standard way to do it, so everybody does as he feels (root directory, src, source, repository, mc....). >> >> This has some bad consequences: >> - once a repository is referenced by some other project, it is more complicated to change its source directory. Imagine that tomorrow we set as standard that all git repos should have the code in src. Then voyage should change. And all its clients too. >> - Making a typo in the code subdirectory means sometimes super ugly errors from metacello that are difficult to debug and understand (e.g., "Cannot resolve BaselineOfMetacello WTF") >> >> Moreover, there was another problem that people started stumbling on: the fact that iceberg got confused sometimes thinking that an empty project was in filetree (to keep backwards compatibility with projects without a .properties). >> >> So we decided that for this release we wanted to revert a bit that situation. Think object: let's put the meta-data used to interpret a project's structure inside the project itself. >> The idea is that: >> >> - each project should contain both a .project and a .properties file. The first can contain arbitrary project meta-data (such as the source directory). The second contains the cypress properties, which are needed to correctly interpret the code inside the source directory. >> - a project without a .project file is an old project and cannot be interpreted, because we don't know the source directory >> - a project without a .properties file is an old project and is by default transformed in a project with a #filetree properties file >> - an old project cloned from iceberg detects the missing .project file and gives the user the opportunity to declare it (and then commit it explicitly) >> - an old project cloned and loaded from a Metacello expression defining a source directory will honnor the source directory defined in the Metacello expression (for backwards compatibility, and we have ~500 tests about this). >> >> # About defaults values / forcing the user to define a project >> >> First, notice that even when the repositories you load are just marked as "dirty". >> This is because in memory we add a project to your repository. >> But you're not forced to commit it. >> Actually, you can still load packages and baselines from that repository without committing. >> >> This is in line with Iceberg's "explicitness". We try to not do any destructive operation without asking the user first (that's why we have several preview windows for pushing, pulling, checkout, merge..., and why contrastingly with monticello we show the committed changes on the commit window...). So, instead of transparently "adding the file" we have decided to modify the project in memory and let the user the responsibility to commit that file. >> >> If there's a drawback, is that the repository is marked as dirty. Which is a bit noisy, yes, but still I think it's not so bad compared with the previous drawbacks. >> To solve this, we could have some default values, yes, and only mark it as dirty if the project does not follow the default value. >> This could work, but right now all projects use different names for their source directories. >> So the question is, what would be a good default? I'd like to use 'src' since this is short, well known and less alien (all these in the sense that we do not lose anything and we have a lot to gain by using it). >> However, not much repositories use 'src' so it will still produce a lot of "noise"... >> >> But still! Committing that file is a one-time operation. Once people fix their repositories adding the project meta-data, you will not see them dirty anymore. So we can see this as a transition noise too... >> >> Of course, new ideas are welcome. I'll let Pablo and Esteban add their points of view on this too. >> > I think I can see what is the rationale behind it but Iâm not sure this can be the way to go: > > - 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? > - 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. Sacrificing very old project (ones not having .properties anywhere) there's a way where you search in the working tree to find all dirs with .properties and treating them as (parallel) source roots. > - My mode of working is to have an eye on dirty repositories because that shows what the impact of your work is. If I have a lot of dirty repositories in my repository list it does not feel good and I donât want that. Especially for projects I donât have write access to. How can I change this? Iâm not sure that assuming everyone will add these files is a likely one. In Amber I had similar problem with local.amd.json metadata file. As it wasn't feasible to think other projects like jquery add one just for Amber to be happy, I allowed to specify "foreign" metadata as well - so I can add jquery.amd.json to "inject" metadata to foreign project if it doesn't have its own. So, yes, there can be .project.Foreign-Name or something in the root of your project. As a "transitional" solution until Foreign-Name maintainers add their own .project, which then takes precedence. And Foreign-Name's packages / repos won't be dirty (only yours, and only once). > Norbert Herby

Aug. 8, 2018