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

[Todd Blanchard via Pharo-users]

--- Begin Message ---
+1

> On Jan 2, 2020, at 9:24 PM, Pierce Ng  wrote:
> 
> On Thu, Jan 02, 2020 at 12:56:55PM -0600, Sean P. DeNigris wrote:
>> 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...
> 
> There's a saying about (aspects of) building software which source I
> cannot recall:
> 
>  If it hurts, do it more frequently.
> 
> I believe FFI should be pushed as much as possible to work out bugs and
> develop new capabilities. Looking forward to playing with threaded FFI.
> 
> Pierce
> 


--- End Message ---

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

[Pierce Ng]

On Thu, Jan 02, 2020 at 12:56:55PM -0600, Sean P. DeNigris wrote:
> 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...

There's a saying about (aspects of) building software which source I
cannot recall:

  If it hurts, do it more frequently.

I believe FFI should be pushed as much as possible to work out bugs and
develop new capabilities. Looking forward to playing with threaded FFI.

Pierce

[Pharo-users] Zeroconf on Ubuntu (14) libz.so.1 error

[Eric Gade]

Hi All,

I'm getting an inscrutable error when using the regular zeroconf (curl
https://get.pharo.org | bash) and trying to run the resulting ./pharo
script:

```
ioLoadModule(/home/egade/ui-test-1/ui/test/pharo-vm/lib/pharo/5.0-201901051900/libgit2.so):
  libz.so.1: cannot open shared object file: No such file or directory
ioLoadModule(/home/egade/ui-test-1/ui/test/pharo-vm/lib/pharo/5.0-201901051900/libgit2.so):
  libz.so.1: cannot open shared object file: No such file or directory
tryLoading(/home/egade/ui-test-1/ui/test/pharo-vm/lib/pharo/5.0-201901051900/
libgit2.so/.libs/,libgit2.so):
stat(/home/egade/ui-test-1/ui/test/pharo-vm/lib/pharo/5.0-201901051900/
libgit2.so/.libs/) Not a directory
External module not found
```

This is on an Ubuntu server that is (unfortunately) running 14.04 LTS. For
the time being the version is out of my control.

I have tried something like `apt-get install zlib1g` but the system is
reporting that this is already installed. From this error message I cannot
really tell what the actual problem is and I'm also a little stumped about
how to properly debug it.

Tips in any direction are much appreciated. Thanks!

-- 
Eric

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

[Esteban Maringolo]

On Thu, Jan 2, 2020 at 3:47 PM Sean P. DeNigris  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

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

[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

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

[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  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
> 
> 

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

[Ben Coman]

On Fri, 3 Jan 2020 at 00:41, Roelof Wobben  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
>>  around the Moon, your
>> ship computer beeps angrily about a "1202 program alarm
>> ". 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
>> .
>>
>> You notify the Elves that the computer's 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
>>  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 

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

[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

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

[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

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

[Roelof Wobben via Pharo-users]

--- Begin Message ---

  
  
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 
  
  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.
  
  and of course thanks for the feedback. 
  
  Roelof
  
  
  
  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 
  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 around the Moon, your ship computer
  beeps angrily about a "1202
program alarm". 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.
You notify the Elves that the computer's 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
  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 

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

[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
>  around the Moon, your ship
> computer beeps angrily about a "1202 program alarm
> ". 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
> .
>
> You notify the Elves that the computer's 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
>  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,
> 

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

[Roelof Wobben via Pharo-users]

--- Begin Message ---

  
  
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 around the Moon, your ship computer beeps angrily
  about a "1202
program alarm". 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.
You notify the Elves that the computer's 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
  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.
  


--- End Message ---