Hi Richard, there isn’t an easy way to communicate with Exercism users (I’m arranging an email to be sent) but essentially just apply this upgrade
https://github.com/exercism/pharo-smalltalk/blob/master/docs/UPGRADE.md Sent from my iPhone Sent from my iPhone > On 20 May 2019, at 04:20, Richard O'Keefe <rao...@gmail.com> wrote: > > This is not an answer to your question, but it is an observation by someone > who was trying all > the exercises. As a user, it was just working. Then suddenly, there was a > change. Instead of > a new exercise popping up underneath Exercism, it would appear as > Exercise@Foobar. No big > deal. What *is* a big deal is that the "submit" menu item disappeared, and > the only way I > have found to submit a solution is > - File Out the class > - Use the command line to download the exercise > - Move the filed out class to the exercise directly > - exercism submit Foobar.st > I had been quite impressed with how smoothly everything went in the UI before. > > >> On Mon, 20 May 2019 at 09:57, Tim Mackinnon <tim@testit.works> wrote: >> I’m wondering if others might spot a better way of handling this - but with >> Exercism, I’ve got 100 exercises to manage. An Exercise is a TestCase and 1 >> or more solution classes (normally 1, but sometimes several). I had >> initially used Tags to manage this, there was an ExercismExercise package, >> and then a tag for each exercise. This was quite neat and tidy - however its >> flawed as it doesn’t allow extension methods on the tags (they live on the >> parent package - which is problematic as in use, the exercises are loaded >> one by one from tonel files as the student progresses), it also does let you >> critique an individual exercise… so essentially they aren’t sub-projects and >> I was recommended to promote them to proper Packages. >> >> This was all quite trivial to support with tags but now I have to grapple >> with the BaselineOf for my project (to manage all these exercises in >> development mode - where you want to load them all, run all their tests, and >> add to them etc). >> >> As each exercise depends on an ExercismTestCase - I have a single pre-req >> for each one, and then, in development mode, I have to load all 100 of them. >> The best I came up with was the following - but its a hell of a lot more >> complicated than the previous tag solution where effectively the owning >> package let me do this once (and membership of that package automatically >> gave a tag this pre-req and containment behaviour). >> >> So instead I have to do the following (and I’m left wondering if I’m missing >> some easier way). The bold bits are where I’ve tried to do something to try >> and workaround this - its the array of packageNames that is a bit >> distasteful to me, and it feels a lot like I have to express the same >> information twice - one in the iceberg window to add all these packages, and >> then again in the method of names, to set the identical pre-req on each of >> them… I find in this respect, I’m missing Envy developer here? >> >> Anyone have some better suggestions? Or do we need to try and make the tools >> better? >> >> Tim >> >> baseline: spec >> <baseline> >> >> spec >> for: #common >> do: [ >> self setUpExercisesFor: spec. >> spec >> package: 'ExercismPharo70'; "Pharo >> override/patch methods" >> package: 'ExercismTools' >> with: [ spec requires: >> #('ExercismPharo70') ]; >> >> package: 'ExercismTests' >> with: [ spec requires: >> #('ExercismTools' 'ExercismMocking'), >> self exerciseTestPackageNames ]; >> >> package: 'ExercismSystemTests' >> with: [ spec requires: >> #('ExercismTests') ]; >> >> >> package: 'ExercismDev' >> with: [ spec requires: #( >> 'OSProcess' "For shelling out >> to configlet" >> 'Ring2' "For mentoring support >> of shadow browsing" >> 'ExercismTools' ), >> self exercisePackageNames, >> #('Exercism' >> >> 'ExercismTests' >> 'ExercismSystemTests')]; >> >> group: 'default' >> with: #('ExercismTools' >> 'Exercise@Welcome'); >> >> group: 'dev' >> with: #('ExercismDev’)]. >> >> setUpExercisesFor: spec >> self class exercisePackageNames, self class exerciseTestPackageNames >> do: >> [ :name | spec package: name with: [ spec requires: >> #('ExercismTools') ] ]. >> >> exercisePackageNames >> "Answer the list of exercise package names (as we don't yet have proper >> projects)" >> >> ^ #('Exercise@Acronym' 'Exercise@Allergies' 'Exercise@Anagram' >> 'Exercise@ArmstrongNumbers' 'Exercise@AtbashCipher' 'Exercise@Binary' >> 'Exercise@Bowling' 'Exercise@Clock' 'Exercise@CollatzConjecture' >> 'Exercise@Darts' 'Exercise@Diamond' 'Exercise@Die' 'Exercise@Etl' >> 'Exercise@Forth' 'Exercise@GradeSchool' 'Exercise@Grains' 'Exercise@Hamming' >> 'Exercise@HelloWorld' 'Exercise@HighScores' 'Exercise@IsbnVerifier' >> 'Exercise@Isogram' 'Exercise@Leap' 'Exercise@Luhn' >> 'Exercise@MatchingBrackets' 'Exercise@Pangram' 'Exercise@Proverb' >> 'Exercise@Raindrops' 'Exercise@ResistorColorDuo' 'Exercise@ReverseString' >> 'Exercise@RobotSimulator' 'Exercise@RomanNumerals' >> 'Exercise@SecretHandshake' 'Exercise@Sieve' 'Exercise@SpaceAge' >> 'Exercise@SumOfMultiples' 'Exercise@Tournament' 'Exercise@TwelveDays' >> 'Exercise@TwoFer' 'Exercise@Welcome' 'Exercise@WordCount')
