> On 9 Aug 2018, at 08:20, Tim Mackinnon <tim@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 <patchi...@gmail.com
> <mailto:patchi...@gmail.com>> wrote:
>
>> +1
>>
>> On Tue, 7 Aug 2018 at 09:02 Tim Mackinnon <tim@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
