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 <patchinko@gmail.com> wrote:

+1

On Tue, 7 Aug 2018 at 09:02 Tim Mackinnon <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