- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML

by Esteban Maringolo

On Thu, Jan 2, 2020 at 3:47 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote > > Iâm getting the impression that ffi is getting very easy these days and > > maybe we should use it more to focus on âotherâ things... This said, many > > of our nastiest bugs... > > That said, as you pointed out, bugs seem to be > more severe and difficult to diagnose, so we'll see how it goes as FFI use > becomes more and more common... It seems to have played very well for the Python folks. It should work even better for Pharo. :) Esteban A. Maringolo

Jan. 2, 2020

Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML

by Sean P. DeNigris

Tim Mackinnon wrote > Iâm getting the impression that ffi is getting very easy these days and > maybe we should use it more to focus on âotherâ things... This said, many > of our nastiest bugs... While I dream of a world where everything is in-image as pure Smalltalk, given the reality of limited manpower, I think of outside library use as a way to "cheat" and get a lot more from that limited engineering resource. I look forward to the mythical day where "everything's done" and we can come back around and replace some of these with Smalltalk, but then of course we'll own the maintenance. That said, as you pointed out, bugs seem to be more severe and difficult to diagnose, so we'll see how it goes as FFI use becomes more and more common... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 2, 2020

Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML

by Tim Mackinnon

That makes sense - Iâm getting the impression that ffi is getting very easy these days and maybe we should use it more to focus on âotherâ things. It does complicate deployment a bit - but if youâre server/cloud based then thatâs less of an issue anyway . This said, many of our nastiest bugs seem to centre around ffi a c based libraries - but maybe using them more will tease this out. Tim Sent from my iPhone > On 2 Jan 2020, at 01:27, Pierce Ng <pierce(a)samadhiweb.com> wrote: > >> On Wed, Jan 01, 2020 at 02:35:03PM +0100, Tim Mackinnon wrote: >> Iâm curious why you chose to use ffi for this one in particular as it >> would seem to be quite straightforward to do it all in native >> Smalltalk (not to down play your integration in any way of course). >> Was performance a big thing? Or was it simply relying on others to >> keep it up to date? > > I wanted something that works out of the box. I did not want to > implement MD parsing myself. > > Also I saw hoedown's wiki page on bindings and thought I'd put Smalltalk > on the map there. > > https://github.com/hoedown/hoedown/wiki/Bindings > > Pierce > >

Jan. 2, 2020

Re: [Pharo-users] why is masses not found?

by Ben Coman

On Fri, 3 Jan 2020 at 00:41, Roelof Wobben <r.wobben(a)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.c… 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.c… > ) > 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.c… > ) > > Well done. > cheers -ben > > > > > > On Thu, 2 Jan 2020 at 23:37, Roelof Wobben via Pharo-users < > pharo-users(a)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.c… >> >> 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. >> > >

Jan. 2, 2020

Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML

by Sean P. DeNigris

Pierce Ng-3 wrote > Also I saw hoedown's wiki page on bindings and thought I'd put Smalltalk > on the map there. Great! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 2, 2020

Re: [Pharo-users] why is masses not found?

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > I made some changes. Is this better or are there still some code > smells. I don't have time for an in-depth review, but I skimmed it and it seems better. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 2, 2020

Re: [Pharo-users] why is masses not found?

by Roelof Wobben

Jan. 2, 2020

Re: [Pharo-users] why is masses not found?

by 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.c… ) 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.c… ) Well done. cheers -ben On Thu, 2 Jan 2020 at 23:37, Roelof Wobben via Pharo-users < pharo-users(a)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.c… > > 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. >

Jan. 2, 2020

Re: [Pharo-users] why is masses not found?

by Roelof Wobben

Jan. 2, 2020

Re: [Pharo-users] [ANN] Phoedown - Markdown to HTML

by Pierce Ng

On Wed, Jan 01, 2020 at 02:35:03PM +0100, Tim Mackinnon wrote: > Iâm curious why you chose to use ffi for this one in particular as it > would seem to be quite straightforward to do it all in native > Smalltalk (not to down play your integration in any way of course). > Was performance a big thing? Or was it simply relying on others to > keep it up to date? I wanted something that works out of the box. I did not want to implement MD parsing myself. Also I saw hoedown's wiki page on bindings and thought I'd put Smalltalk on the map there. https://github.com/hoedown/hoedown/wiki/Bindings Pierce

Jan. 2, 2020