On Fri, 3 Jan 2020 at 00:41, Roelof Wobben <r.wob...@home.nl> wrote:
> Hello Ben.
>
> That was a error . There schould be a caret for it. Im talking about the
> solution method.
>
> No, I cannot clean the in part because it is used in the process* methods
>
But its not. Your statement would be true if your processXXX methods did...
a := self at: self in next.
but they don't, instead you have...
a := self at: in next.
You never send the #in message, which is fine since "information hiding"
can be useful
to avoid exposing your internal representation that the outside doesn't
need to know about.
(the proof is in the pudding, see if it works after deleting #in and #in:)
The processData: can also be deleted . I think Its a part of a earlier
> try to solve it.
>
> and yes. the ram is the same at both places.
>
> Is there then a better way to pass the stream around.
>
I think its fine how you've done it.
Final thing is to clean up the "class-instance variable" (i.e. class-side
instance variable)
which Sean mentioned. You can see it here...
https://github.com/rwobben/intComputer/blob/master/AOC%202019/IntComputer.class.st#L8-L10
To remove it from the image, in the System Browser while viewing the class
definition, click the "Class" button and you should see it.
cheers -ben
>
> Op 2-1-2020 om 14:27 schreef Ben Coman:
>
> 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.
>>
>
>
