Hi Roelof, I presume its working since you only asked for code smells. It looks pretty good to me with methods generally being small and doing one thing.
The way your class-side-method "IntComputer class >> solution" just creates an instance and sends #process is good. I'm a little curious that it doesn't return a value. #process returns a value but nothing is done with it. I guess the test-frame doesn't require it. The way zero-index ram access is encapsulated by #at: and #at:put: is good. Possible cleanup, #in and #in: don't seem required since variable "in" is used directly in the rest of the code, which is fine. The hardcoded #masses return value is fine, except it makes the "masses" class variable redundant. Your various #processXXX methods are succinct and consume the stream neatly. However its curious your #processData and #processData: methods have identical code, since the latter has an argument that is then not used. So your code is working a bit by accident. At line 59 ( https://github.com/rwobben/intComputer/blob/master/AOC%202019/IntComputer.class.st#L59 ) its just lucky that the "self ram" you pass there to #processData: is the same as the "ram" variable referenced on line 82 ( https://github.com/rwobben/intComputer/blob/master/AOC%202019/IntComputer.class.st#L82 ) Well done. cheers -ben On Thu, 2 Jan 2020 at 23:37, Roelof Wobben via Pharo-users < pharo-users@lists.pharo.org> wrote: > Op 1-1-2020 om 17:27 schreef Roelof Wobben via Pharo-users: > > Hello, > > I made some changes. Is this better or are there still some code smells. > Code : > https://github.com/rwobben/intComputer/blob/master/AOC%202019/IntComputer.class.st > > if so, can someone help me to solve the code smells. > > Here is the challenge I try to solve : > > On the way to your gravity assist > <https://en.wikipedia.org/wiki/Gravity_assist> around the Moon, your ship > computer beeps angrily about a "1202 program alarm > <https://www.hq.nasa.gov/alsj/a11/a11.landing.html#1023832>". On the > radio, an Elf is already explaining how to handle the situation: "Don't > worry, that's perfectly norma--" The ship computer bursts into flames > <https://en.wikipedia.org/wiki/Halt_and_Catch_Fire>. > > You notify the Elves that the computer's magic smoke > <https://en.wikipedia.org/wiki/Magic_smoke> seems to have escaped. "That > computer ran *Intcode* programs like the gravity assist program it was > working on; surely there are enough spare parts up there to build a new > Intcode computer!" > > An Intcode program is a list of integers > <https://en.wikipedia.org/wiki/Integer> separated by commas (like > 1,0,0,3,99). To run one, start by looking at the first integer (called > position 0). Here, you will find an *opcode* - either 1, 2, or 99. The > opcode indicates what to do; for example, 99 means that the program is > finished and should immediately halt. Encountering an unknown opcode means > something went wrong. > > Opcode 1 *adds* together numbers read from two positions and stores the > result in a third position. The three integers *immediately after* the > opcode tell you these three positions - the first two indicate the > *positions* from which you should read the input values, and the third > indicates the *position* at which the output should be stored. > > For example, if your Intcode computer encounters 1,10,20,30, it should > read the values at positions 10 and 20, add those values, and then > overwrite the value at position 30 with their sum. > > Opcode 2 works exactly like opcode 1, except it *multiplies* the two > inputs instead of adding them. Again, the three integers after the opcode > indicate *where* the inputs and outputs are, not their values. > > Once you're done processing an opcode, *move to the next one* by stepping > forward 4 positions. > > For example, suppose you have the following program: > > 1,9,10,3,2,3,11,0,99,30,40,50 > > For the purposes of illustration, here is the same program split into > multiple lines: > > 1,9,10,3, > 2,3,11,0, > 99, > 30,40,50 > > The first four integers, 1,9,10,3, are at positions 0, 1, 2, and 3. > Together, they represent the first opcode (1, addition), the positions of > the two inputs (9 and 10), and the position of the output (3). To handle > this opcode, you first need to get the values at the input positions: > position 9 contains 30, and position 10 contains 40. *Add* these numbers > together to get 70. Then, store this value at the output position; here, > the output position (3) is *at* position 3, so it overwrites itself. > Afterward, the program looks like this: > > 1,9,10,*70*, > 2,3,11,0, > 99, > 30,40,50 > > Step forward 4 positions to reach the next opcode, 2. This opcode works > just like the previous, but it multiplies instead of adding. The inputs are > at positions 3 and 11; these positions contain 70 and 50 respectively. > Multiplying these produces 3500; this is stored at position 0: > > *3500*,9,10,70, > 2,3,11,0, > 99, > 30,40,50 > > Stepping forward 4 more positions arrives at opcode 99, halting the > program. >
