Re: [Pharo-users] Understanding the role of the sources file

[Christophe Demarey]

Le 13 janv. 2016 à 10:57, Dimitris Chloupis a écrit :

> I was adding a short description to the UPBE about sources file , I always 
> thought that the sources file is the file that contains the source code of 
> the image because the image file itself stores only the bytecode. 
> 
> However its just came to my attention that the sources file does not contain 
> code that is recently installed in the image.
> 
> So how exactly the sources file works and what it is ? 


If I understood well:
- the sources file has all the source code of the released pharo version (when 
we generate this new source file PharoVXX.sources).
- the changes file has the source code since the release.

smime.p7s
Description: S/MIME cryptographic signature

[Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

I was adding a short description to the UPBE about sources file , I always
thought that the sources file is the file that contains the source code of
the image because the image file itself stores only the bytecode.

However its just came to my attention that the sources file does not
contain code that is recently installed in the image.

So how exactly the sources file works and what it is ?

Re: [Pharo-users] Understanding the role of the sources file

[Sven Van Caekenberghe]

> On 13 Jan 2016, at 10:57, Dimitris Chloupis  wrote:
> 
> I was adding a short description to the UPBE about sources file , I always 
> thought that the sources file is the file that contains the source code of 
> the image because the image file itself stores only the bytecode. 
> 
> However its just came to my attention that the sources file does not contain 
> code that is recently installed in the image.
> 
> So how exactly the sources file works and what it is ? 

The main perspective is from the object point of view: methods are just objects 
like everything else. In order to be executable they know their byte codes 
(which might be JIT compiled on execution, but that is an implementation 
detail) and they know their source code.

Today we would probably just store the source code strings in the image (maybe 
compressed) as memory is pretty cheap. But way back when Smalltalk started, 
that was not the case. So they decided to map the source code out to files.

So method source code is a magic string (RemoteString) that points to some 
position in a file. There are 2 files in use: the sources file and the changes 
file.

The sources file is a kind of snapshot of the source code of all methods at the 
point of release of a major new version. That is why there is a Vxy in their 
name. The source file never changes once created or renewed (a process called 
generating the sources, see PharoSourcesCondenser).

While developing and creating new versions of methods, the new source code is 
appended to another file called the changes file, much like a transaction log. 
This is also a safety mechanism to recover 'lost' changes.

The changes file can contain multiple versions of a method. This can be reduced 
in size using a process called condensing the changes, see 
PharoChangesCondenser.

On a new release, the changes file will be (almost) empty.

HTH,

Sven

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

I mentioned bytecode because I dont want the user to see at some point
bytecode and say "What the hell is that" I want the reader to feel
confident that at least understands the basic in Pharo. Also very brief
explanations about bytecode I have seen in similar python tutorials.
Obviously I dont want to go any deeper than that because the user wont have
to worry about the technical details on a daily basis anyway.

I agree that I could add a bit more on the VM description similar to what
you posted. I am curious though, wont even the interpreter generate machine
code in order to execute the code  or does it use existing machine code
inside the VM binary ?

On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe  wrote:

> Sounds about right.
>
> Now, I would swap 1 and 4, as the image is the most important abstraction.
>
> There is also a bit too much emphasis on (byte|source)code. This is
> already pretty technical (it assume you know what compilation is and so
> on). But I understand it must be explained here, and you did it well.
>
> However, I would start by saying that the image is a snapshot of the
> object world in memory that is effectively a live Pharo system. It contains
> everything that is available and that exists in Pharo. This includes any
> objects that you created yourself, windows, browsers, open debuggers,
> executing processes, all meta objects as well as all representations of
> code.
>
> 
> The fact that there is a sources and changes file is an implementation
> artefact, not something fundamental. There are ideas to change this in the
> future (but you do not have to mention that).
> 
>
> Also, the VM not only executes code, it maintains the object world, which
> includes the ability to load and save it from and to an image. It creates a
> portable (cross platform) abstraction that isolates the image from the
> particular details of the underlying hardware and OS. In that role it
> implements the interface with the outside world. I would mention that
> second part before mentioning the code execution.
>
> The sentence "The purpose of the VM is to take Pharo bytcode that is
> generated each time user accepts a piece of code and convert it to machine
> code in order to be executed." is not 100% correct. It is possible to
> execute the byte code without converting it. This is called interpretation.
> JIT is a faster technique that includes converting (some often used) byte
> code to machine code and caching that.
>
> I hope this helps (it is hard to write a 'definitive explanation' as there
> are some many aspects to this and it depends on the context/audience).
>
> > On 13 Jan 2016, at 12:58, Dimitris Chloupis 
> wrote:
> >
> > So I am correct that the image does not store the source code, and that
> the source code is stored in sources and changes. The only diffirence is
> that the objects have a source variable that points to the right place for
> finding the source code.
> >
> > This is the final text if you find anything incorrect please correct me
> >
> > ---
> >
> > 1. The virtual machine (VM) is the only component that is different for
> each operating system. The purpose of the VM is to take Pharo bytcode that
> is generated each time user accepts a piece of code and convert it to
> machine code in order to be executed. Pharo 4 comes with the Cog VM a very
> fast JIT VM. The VM executable is named:
> >
> > • Pharo.exe for Windows; • pharo for Linux ; and
> >
> > • Pharo for OSX (inside a package also named Pharo.app).
> > The other components below are portable across operating systems, and
> >
> > can be copied and run on any appropriate virtual machine.
> >
> > 2. The sources file contains source code for parts of Pharo that don’t
> change frequently. Sources file is important because the image file format
> stores only the bytecode of live objects and not their source code.
> Typically a new sources file is generated once per major release of Pharo.
> For Pharo 4.0, this file is named PharoV40.sources.
> >
> > 3. The changes file logs of all source code modifications since the
> .sources file was generated. This facilitates a per method history for
> diffs or re- verting.That means that even if you dont manage to save the
> image file on a crash or you just forgot you can recover your changes from
> this file. Each release provides a near empty file named for the release,
> for example Pharo4.0.changes.
> >
> > 4. The image file provides a frozen in time snapshot of a running Pharo
> system. This is the file where the Pharo bytecode is stored and as such its
> a cross platform format. This is the heart of Pharo, containing the live
> state of all objects in the system (including classes and methods, since
> they are objects too). The file is named for the release (like
> Pharo4.0.image).
> >
> > The .image and .changes files provided by a Pharo release are the
> starting point for a live environment that you adapt to your needs.

Re: [Pharo-users] SSL client certificates

[Norbert Hartl]

> Am 13.01.2016 um 13:59 schrieb Sven Van Caekenberghe :
> 
>> 
>> On 13 Jan 2016, at 13:33, Norbert Hartl  wrote:
>> 
>> Sven,
>> 
>>> Am 12.01.2016 um 16:25 schrieb Sven Van Caekenberghe :
>>> 
>>> Given a ZdcSecureSocketStream you can access the #sslSession. In this 
>>> session object you can use #certificateName: to set the path or name of the 
>>> certificate (before you #connect !). That is the general idea.
>>> 
>>> Now, I don't know if this works or not. Be prepared to look in the plugin C 
>>> code! On Linux this will probably work.
>> 
>> I spent some time to figure out how this works. But I don't get it. I don't 
>> know what this copying back and forth of bytes in the SSL handshake is 
>> supposed to do. I just can see that on a second read from the socket the 
>> connection is closed from the remote side. Not much here. 
>> I think it will take too much time for me to figure it out. And I'm afraid I 
>> don't have that many spare cycles.
> 
> Unless you are reimplementing SSL from the ground up, it is not really super 
> important to understand what is happening. The whole idea of using a library 
> like OpenSSL is to delegate all the hard work to it, in particular the 
> handshake.
> 
> The fact that the other end closes most probably means that something is 
> wrong (duh): the client did not behave or act as expected, or it provided 
> some strange/wrong/bogus data.
> 
Yeah, I was able to do a similar analysis of the problem :P It is just very 
hard to figure out what is the bogus part in there. Using the openssl client I 
could verify that the certificate in the file is valid. So no glue what went 
wrong otherwise.

>> We should rethink "software bounties". I don't have the time to fix this but 
>> I'm willing to put some money on the table to have it implemented properly. 
>> There are more people wanting to pay for features implemented. And I'm sure 
>> there are developers that would like to do it when being paid.
> 
> Yeah.
> 
> But to complete this task successfully one has to know about Pharo, about C 
> and about SSL/TLS. A C version directly using the OpenSSL API should be 
> compared to what the SSL Plugin does, that is the only way out. And it would 
> not hurt to rewrite the SSL Plugin itself in a very clean cross platform way 
> using only 1 OS API in C (OpenSSL), not 3 like today, with proper logging and 
> error handling.
> 
Yes, it is not easy. But there are a lot of people capable of doing it I guess. 
Having a decent SSL implementation is absolutely desirable IMHO.

Norbert

>> Norbert
>> 
>>> 
>>> And please let us know how it goes ;-)
>>> 
 On 12 Jan 2016, at 16:05, Norbert Hartl > wrote:
 
 Is there a way to make SSL connections to the outside world using client 
 certificates from pharo?
 
 thanks,
 
 Norbert

Re: [Pharo-users] Understanding the role of the sources file

[Sven Van Caekenberghe]

> On 13 Jan 2016, at 14:22, Dimitris Chloupis  wrote:
> 
> I assume you have never read a an introduction to C++ then :D

I have and they are too complex.

> here is the final addition for the vm
> 
> (Vm) is the only component that is different for each operating system. The 
> main purpose of the VM is to take Pharo bytcode that is generated each time 
> user accepts a piece of code and convert it to machine code in order to be 
> executed, but also to generally handle low level functionality like 
> interpreting code, handling OS events (mouse and keyboard), calling C 
> libraries etc. Pharo 4 comes with the Cog VM a very fast JIT VM. 

You added more technical stuff. I tried to make my point, but you are writing 
it, not me, so I won't continue.

> I think its clear, precise and does not leave much room for confusion. 
> Personally I think its very important for the absolute begineer to have 
> strong foundations of understanding the fundamental of Pharo and not for 
> things to appear magical and "dont touch this". 

Nobody can understand everything at the same time, even experts work on partial 
abstractions while ignoring most other details.

A beginner has to be guided to the most important concepts first. Explaining 
something in a simple way is very hard (and I fail most of the time doing that).

Pharo offers curious minds unlimited opportunity to explore, while staying in 
the same system, but that does not mean everything should be mentioned 
immediately.

> On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe  wrote:
> 
> > On 13 Jan 2016, at 13:42, Dimitris Chloupis  wrote:
> >
> > I mentioned bytecode because I dont want the user to see at some point 
> > bytecode and say "What the hell is that" I want the reader to feel 
> > confident that at least understands the basic in Pharo. Also very brief 
> > explanations about bytecode I have seen in similar python tutorials. 
> > Obviously I dont want to go any deeper than that because the user wont have 
> > to worry about the technical details on a daily basis anyway.
> >
> > I agree that I could add a bit more on the VM description similar to what 
> > you posted. I am curious though, wont even the interpreter generate machine 
> > code in order to execute the code  or does it use existing machine code 
> > inside the VM binary ?
> 
> No, a classic interpreter does not 'generate' machine code, it is just a 
> program that reads and executes bytes codes in a loop, the interpreter 'is' 
> machine code.
> 
> No offence, but you see why I think it is important to not try to use or 
> explain too much complex concepts in the 1st chapter.
> 
> Learning to program is hard. It should first be done abstractly. Think about 
> Scratch. The whole idea of Smalltalk is to create a world of interacting 
> objects. (Even byte code is not a necessary concept at all, for example, in 
> Pharo, you can compile (translate) to AST and execute that, I believe. There 
> are Smalltalk implementations that compile directly to C or JavaScript). 
> Hell, even 'compile' is not necessary, just 'accept'. See ?
> 
> > On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe  wrote:
> > Sounds about right.
> >
> > Now, I would swap 1 and 4, as the image is the most important abstraction.
> >
> > There is also a bit too much emphasis on (byte|source)code. This is already 
> > pretty technical (it assume you know what compilation is and so on). But I 
> > understand it must be explained here, and you did it well.
> >
> > However, I would start by saying that the image is a snapshot of the object 
> > world in memory that is effectively a live Pharo system. It contains 
> > everything that is available and that exists in Pharo. This includes any 
> > objects that you created yourself, windows, browsers, open debuggers, 
> > executing processes, all meta objects as well as all representations of 
> > code.
> >
> > 
> > The fact that there is a sources and changes file is an implementation 
> > artefact, not something fundamental. There are ideas to change this in the 
> > future (but you do not have to mention that).
> > 
> >
> > Also, the VM not only executes code, it maintains the object world, which 
> > includes the ability to load and save it from and to an image. It creates a 
> > portable (cross platform) abstraction that isolates the image from the 
> > particular details of the underlying hardware and OS. In that role it 
> > implements the interface with the outside world. I would mention that 
> > second part before mentioning the code execution.
> >
> > The sentence "The purpose of the VM is to take Pharo bytcode that is 
> > generated each time user accepts a piece of code and convert it to machine 
> > code in order to be executed." is not 100% correct. It is possible to 
> > execute the byte code without converting it. This is called interpretation. 
> > JIT is a faster technique that includes 

Re: [Pharo-users] SSL client certificates

[Sven Van Caekenberghe]

> On 13 Jan 2016, at 13:33, Norbert Hartl  wrote:
> 
> Sven,
> 
>> Am 12.01.2016 um 16:25 schrieb Sven Van Caekenberghe :
>> 
>> Given a ZdcSecureSocketStream you can access the #sslSession. In this 
>> session object you can use #certificateName: to set the path or name of the 
>> certificate (before you #connect !). That is the general idea.
>> 
>> Now, I don't know if this works or not. Be prepared to look in the plugin C 
>> code! On Linux this will probably work.
> 
> I spent some time to figure out how this works. But I don't get it. I don't 
> know what this copying back and forth of bytes in the SSL handshake is 
> supposed to do. I just can see that on a second read from the socket the 
> connection is closed from the remote side. Not much here. 
> I think it will take too much time for me to figure it out. And I'm afraid I 
> don't have that many spare cycles.

Unless you are reimplementing SSL from the ground up, it is not really super 
important to understand what is happening. The whole idea of using a library 
like OpenSSL is to delegate all the hard work to it, in particular the 
handshake.

The fact that the other end closes most probably means that something is wrong 
(duh): the client did not behave or act as expected, or it provided some 
strange/wrong/bogus data.

> We should rethink "software bounties". I don't have the time to fix this but 
> I'm willing to put some money on the table to have it implemented properly. 
> There are more people wanting to pay for features implemented. And I'm sure 
> there are developers that would like to do it when being paid.

Yeah.

But to complete this task successfully one has to know about Pharo, about C and 
about SSL/TLS. A C version directly using the OpenSSL API should be compared to 
what the SSL Plugin does, that is the only way out. And it would not hurt to 
rewrite the SSL Plugin itself in a very clean cross platform way using only 1 
OS API in C (OpenSSL), not 3 like today, with proper logging and error handling.

> Norbert
> 
>> 
>> And please let us know how it goes ;-)
>> 
>>> On 12 Jan 2016, at 16:05, Norbert Hartl  wrote:
>>> 
>>> Is there a way to make SSL connections to the outside world using client 
>>> certificates from pharo?
>>> 
>>> thanks,
>>> 
>>> Norbert
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

I assume you have never read a an introduction to C++ then :D

here is the final addition for the vm

(Vm) is the only component that is different for each operating system. The
main purpose of the VM is to take Pharo bytcode that is generated each time
user accepts a piece of code and convert it to machine code in order to be
executed, but also to generally handle low level functionality like
interpreting code, handling OS events (mouse and keyboard), calling C
libraries etc. Pharo 4 comes with the Cog VM a very fast JIT VM.

I think its clear, precise and does not leave much room for confusion.
Personally I think its very important for the absolute begineer to have
strong foundations of understanding the fundamental of Pharo and not for
things to appear magical and "dont touch this".

On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe  wrote:

>
> > On 13 Jan 2016, at 13:42, Dimitris Chloupis 
> wrote:
> >
> > I mentioned bytecode because I dont want the user to see at some point
> bytecode and say "What the hell is that" I want the reader to feel
> confident that at least understands the basic in Pharo. Also very brief
> explanations about bytecode I have seen in similar python tutorials.
> Obviously I dont want to go any deeper than that because the user wont have
> to worry about the technical details on a daily basis anyway.
> >
> > I agree that I could add a bit more on the VM description similar to
> what you posted. I am curious though, wont even the interpreter generate
> machine code in order to execute the code  or does it use existing machine
> code inside the VM binary ?
>
> No, a classic interpreter does not 'generate' machine code, it is just a
> program that reads and executes bytes codes in a loop, the interpreter 'is'
> machine code.
>
> No offence, but you see why I think it is important to not try to use or
> explain too much complex concepts in the 1st chapter.
>
> Learning to program is hard. It should first be done abstractly. Think
> about Scratch. The whole idea of Smalltalk is to create a world of
> interacting objects. (Even byte code is not a necessary concept at all, for
> example, in Pharo, you can compile (translate) to AST and execute that, I
> believe. There are Smalltalk implementations that compile directly to C or
> JavaScript). Hell, even 'compile' is not necessary, just 'accept'. See ?
>
> > On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe 
> wrote:
> > Sounds about right.
> >
> > Now, I would swap 1 and 4, as the image is the most important
> abstraction.
> >
> > There is also a bit too much emphasis on (byte|source)code. This is
> already pretty technical (it assume you know what compilation is and so
> on). But I understand it must be explained here, and you did it well.
> >
> > However, I would start by saying that the image is a snapshot of the
> object world in memory that is effectively a live Pharo system. It contains
> everything that is available and that exists in Pharo. This includes any
> objects that you created yourself, windows, browsers, open debuggers,
> executing processes, all meta objects as well as all representations of
> code.
> >
> > 
> > The fact that there is a sources and changes file is an implementation
> artefact, not something fundamental. There are ideas to change this in the
> future (but you do not have to mention that).
> > 
> >
> > Also, the VM not only executes code, it maintains the object world,
> which includes the ability to load and save it from and to an image. It
> creates a portable (cross platform) abstraction that isolates the image
> from the particular details of the underlying hardware and OS. In that role
> it implements the interface with the outside world. I would mention that
> second part before mentioning the code execution.
> >
> > The sentence "The purpose of the VM is to take Pharo bytcode that is
> generated each time user accepts a piece of code and convert it to machine
> code in order to be executed." is not 100% correct. It is possible to
> execute the byte code without converting it. This is called interpretation.
> JIT is a faster technique that includes converting (some often used) byte
> code to machine code and caching that.
> >
> > I hope this helps (it is hard to write a 'definitive explanation' as
> there are some many aspects to this and it depends on the context/audience).
> >
> > > On 13 Jan 2016, at 12:58, Dimitris Chloupis 
> wrote:
> > >
> > > So I am correct that the image does not store the source code, and
> that the source code is stored in sources and changes. The only diffirence
> is that the objects have a source variable that points to the right place
> for finding the source code.
> > >
> > > This is the final text if you find anything incorrect please correct me
> > >
> > > ---
> > >
> > > 1. The virtual machine (VM) is the only component that is different
> for each operating system. 

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

Its an open book, if people dont like it , it can always been removed. Just
because I am most active , thats does not make me the boss. But yes I do
disagree that a simple explanation of what the VM really is should be
ommited, because for me that is just plain bad documentation to mention
something and not at least provide a basic explanation of it which was the
case before my additions.

But once again its a free world, you are more than welcomed to contribute
and delete etc. I am making a pass on all chapters but in the end, this is
not an one man work ;)

On Wed, Jan 13, 2016 at 3:35 PM Sven Van Caekenberghe  wrote:

>
> > On 13 Jan 2016, at 14:22, Dimitris Chloupis 
> wrote:
> >
> > I assume you have never read a an introduction to C++ then :D
>
> I have and they are too complex.
>
> > here is the final addition for the vm
> >
> > (Vm) is the only component that is different for each operating system.
> The main purpose of the VM is to take Pharo bytcode that is generated each
> time user accepts a piece of code and convert it to machine code in order
> to be executed, but also to generally handle low level functionality like
> interpreting code, handling OS events (mouse and keyboard), calling C
> libraries etc. Pharo 4 comes with the Cog VM a very fast JIT VM.
>
> You added more technical stuff. I tried to make my point, but you are
> writing it, not me, so I won't continue.
>
> > I think its clear, precise and does not leave much room for confusion.
> Personally I think its very important for the absolute begineer to have
> strong foundations of understanding the fundamental of Pharo and not for
> things to appear magical and "dont touch this".
>
> Nobody can understand everything at the same time, even experts work on
> partial abstractions while ignoring most other details.
>
> A beginner has to be guided to the most important concepts first.
> Explaining something in a simple way is very hard (and I fail most of the
> time doing that).
>
> Pharo offers curious minds unlimited opportunity to explore, while staying
> in the same system, but that does not mean everything should be mentioned
> immediately.
>
> > On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe 
> wrote:
> >
> > > On 13 Jan 2016, at 13:42, Dimitris Chloupis 
> wrote:
> > >
> > > I mentioned bytecode because I dont want the user to see at some point
> bytecode and say "What the hell is that" I want the reader to feel
> confident that at least understands the basic in Pharo. Also very brief
> explanations about bytecode I have seen in similar python tutorials.
> Obviously I dont want to go any deeper than that because the user wont have
> to worry about the technical details on a daily basis anyway.
> > >
> > > I agree that I could add a bit more on the VM description similar to
> what you posted. I am curious though, wont even the interpreter generate
> machine code in order to execute the code  or does it use existing machine
> code inside the VM binary ?
> >
> > No, a classic interpreter does not 'generate' machine code, it is just a
> program that reads and executes bytes codes in a loop, the interpreter 'is'
> machine code.
> >
> > No offence, but you see why I think it is important to not try to use or
> explain too much complex concepts in the 1st chapter.
> >
> > Learning to program is hard. It should first be done abstractly. Think
> about Scratch. The whole idea of Smalltalk is to create a world of
> interacting objects. (Even byte code is not a necessary concept at all, for
> example, in Pharo, you can compile (translate) to AST and execute that, I
> believe. There are Smalltalk implementations that compile directly to C or
> JavaScript). Hell, even 'compile' is not necessary, just 'accept'. See ?
> >
> > > On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe 
> wrote:
> > > Sounds about right.
> > >
> > > Now, I would swap 1 and 4, as the image is the most important
> abstraction.
> > >
> > > There is also a bit too much emphasis on (byte|source)code. This is
> already pretty technical (it assume you know what compilation is and so
> on). But I understand it must be explained here, and you did it well.
> > >
> > > However, I would start by saying that the image is a snapshot of the
> object world in memory that is effectively a live Pharo system. It contains
> everything that is available and that exists in Pharo. This includes any
> objects that you created yourself, windows, browsers, open debuggers,
> executing processes, all meta objects as well as all representations of
> code.
> > >
> > > 
> > > The fact that there is a sources and changes file is an implementation
> artefact, not something fundamental. There are ideas to change this in the
> future (but you do not have to mention that).
> > > 
> > >
> > > Also, the VM not only executes code, it maintains the object world,
> which includes the ability to load and save it 

Re: [Pharo-users] SSL client certificates

[Norbert Hartl]

Sven,

> Am 12.01.2016 um 16:25 schrieb Sven Van Caekenberghe :
> 
> Given a ZdcSecureSocketStream you can access the #sslSession. In this session 
> object you can use #certificateName: to set the path or name of the 
> certificate (before you #connect !). That is the general idea.
> 
> Now, I don't know if this works or not. Be prepared to look in the plugin C 
> code! On Linux this will probably work.

I spent some time to figure out how this works. But I don't get it. I don't 
know what this copying back and forth of bytes in the SSL handshake is supposed 
to do. I just can see that on a second read from the socket the connection is 
closed from the remote side. Not much here. 
I think it will take too much time for me to figure it out. And I'm afraid I 
don't have that many spare cycles.

We should rethink "software bounties". I don't have the time to fix this but 
I'm willing to put some money on the table to have it implemented properly. 
There are more people wanting to pay for features implemented. And I'm sure 
there are developers that would like to do it when being paid.

Norbert
 
> 
> And please let us know how it goes ;-)
> 
>> On 12 Jan 2016, at 16:05, Norbert Hartl  wrote:
>> 
>> Is there a way to make SSL connections to the outside world using client 
>> certificates from pharo?
>> 
>> thanks,
>> 
>> Norbert
>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

So I am correct that the image does not store the source code, and that the
source code is stored in sources and changes. The only diffirence is that
the objects have a source variable that points to the right place for
finding the source code.

This is the final text if you find anything incorrect please correct me

---

1. The virtual machine (VM) is the only component that is different for
each operating system. The purpose of the VM is to take Pharo bytcode that
is generated each time user accepts a piece of code and convert it to
machine code in order to be executed. Pharo 4 comes with the Cog VM a very
fast JIT VM. The VM executable is named:

• Pharo.exe for Windows; • pharo for Linux ; and

• Pharo for OSX (inside a package also named Pharo.app).
The other components below are portable across operating systems, and

can be copied and run on any appropriate virtual machine.

2. The sources file contains source code for parts of Pharo that don’t
change frequently. Sources file is important because the image file format
stores only the bytecode of live objects and not their source code.
Typically a new sources file is generated once per major release of Pharo.
For Pharo 4.0, this file is named PharoV40.sources.

3. The changes file logs of all source code modifications since the .sources
file was generated. This facilitates a per method history for diffs or re-
verting.That means that even if you dont manage to save the image file on a
crash or you just forgot you can recover your changes from this file. Each
release provides a near empty file named for the release, for example
Pharo4.0.changes.

4. The image file provides a frozen in time snapshot of a running Pharo
system. This is the file where the Pharo bytecode is stored and as such its
a cross platform format. This is the heart of Pharo, containing the live
state of all objects in the system (including classes and methods, since
they are objects too). The file is named for the release (like
Pharo4.0.image).

The .image and .changes files provided by a Pharo release are the starting
point for a live environment that you adapt to your needs. Essentially the
image file containes the compiler of the language (not the VM) , the
language parser, the IDE tools, many libraries and acts a bit like a
virtual Operation System that runs on top of a Virtual Machine (VM),
similarly to ISO files.

As you work in Pharo, these files are modified, so you need to make sure
that they are writable. The .image and .changes files are intimately linked
and should always be kept together, with matching base filenames. Never
edit them directly with a text editor, as .images holds your live object
runtime memory, which indexes into the .changes files for the source. It is
a good idea to keep a backup copy of the downloaded .image and .changes files
so you can always start from a fresh image and reload your code. However
the most efficient way for backing up code is to use a version control
system that will provide an easier and powerful way to back up and track
your changes.

The four main component files above can be placed in the same directory,
although it’s also possible to put the Virtual Machine and sources file in
a separate directory where everyone has read-only access to them.

If more than one image file is present in the same directory pharo will
prompt you to choose an image file you want to load.

Do whatever works best for your style of working and your operating system.




On Wed, Jan 13, 2016 at 12:13 PM Sven Van Caekenberghe  wrote:

>
> > On 13 Jan 2016, at 10:57, Dimitris Chloupis 
> wrote:
> >
> > I was adding a short description to the UPBE about sources file , I
> always thought that the sources file is the file that contains the source
> code of the image because the image file itself stores only the bytecode.
> >
> > However its just came to my attention that the sources file does not
> contain code that is recently installed in the image.
> >
> > So how exactly the sources file works and what it is ?
>
> The main perspective is from the object point of view: methods are just
> objects like everything else. In order to be executable they know their
> byte codes (which might be JIT compiled on execution, but that is an
> implementation detail) and they know their source code.
>
> Today we would probably just store the source code strings in the image
> (maybe compressed) as memory is pretty cheap. But way back when Smalltalk
> started, that was not the case. So they decided to map the source code out
> to files.
>
> So method source code is a magic string (RemoteString) that points to some
> position in a file. There are 2 files in use: the sources file and the
> changes file.
>
> The sources file is a kind of snapshot of the source code of all methods
> at the point of release of a major new version. That is why there is a Vxy
> in their name. The source file never changes once created or renewed 

Re: [Pharo-users] Understanding the role of the sources file

[Sven Van Caekenberghe]

> On 13 Jan 2016, at 13:42, Dimitris Chloupis  wrote:
> 
> I mentioned bytecode because I dont want the user to see at some point 
> bytecode and say "What the hell is that" I want the reader to feel confident 
> that at least understands the basic in Pharo. Also very brief explanations 
> about bytecode I have seen in similar python tutorials. Obviously I dont want 
> to go any deeper than that because the user wont have to worry about the 
> technical details on a daily basis anyway. 
> 
> I agree that I could add a bit more on the VM description similar to what you 
> posted. I am curious though, wont even the interpreter generate machine code 
> in order to execute the code  or does it use existing machine code inside the 
> VM binary ? 

No, a classic interpreter does not 'generate' machine code, it is just a 
program that reads and executes bytes codes in a loop, the interpreter 'is' 
machine code.

No offence, but you see why I think it is important to not try to use or 
explain too much complex concepts in the 1st chapter.

Learning to program is hard. It should first be done abstractly. Think about 
Scratch. The whole idea of Smalltalk is to create a world of interacting 
objects. (Even byte code is not a necessary concept at all, for example, in 
Pharo, you can compile (translate) to AST and execute that, I believe. There 
are Smalltalk implementations that compile directly to C or JavaScript). Hell, 
even 'compile' is not necessary, just 'accept'. See ?

> On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe  wrote:
> Sounds about right.
> 
> Now, I would swap 1 and 4, as the image is the most important abstraction.
> 
> There is also a bit too much emphasis on (byte|source)code. This is already 
> pretty technical (it assume you know what compilation is and so on). But I 
> understand it must be explained here, and you did it well.
> 
> However, I would start by saying that the image is a snapshot of the object 
> world in memory that is effectively a live Pharo system. It contains 
> everything that is available and that exists in Pharo. This includes any 
> objects that you created yourself, windows, browsers, open debuggers, 
> executing processes, all meta objects as well as all representations of code.
> 
> 
> The fact that there is a sources and changes file is an implementation 
> artefact, not something fundamental. There are ideas to change this in the 
> future (but you do not have to mention that).
> 
> 
> Also, the VM not only executes code, it maintains the object world, which 
> includes the ability to load and save it from and to an image. It creates a 
> portable (cross platform) abstraction that isolates the image from the 
> particular details of the underlying hardware and OS. In that role it 
> implements the interface with the outside world. I would mention that second 
> part before mentioning the code execution.
> 
> The sentence "The purpose of the VM is to take Pharo bytcode that is 
> generated each time user accepts a piece of code and convert it to machine 
> code in order to be executed." is not 100% correct. It is possible to execute 
> the byte code without converting it. This is called interpretation. JIT is a 
> faster technique that includes converting (some often used) byte code to 
> machine code and caching that.
> 
> I hope this helps (it is hard to write a 'definitive explanation' as there 
> are some many aspects to this and it depends on the context/audience).
> 
> > On 13 Jan 2016, at 12:58, Dimitris Chloupis  wrote:
> >
> > So I am correct that the image does not store the source code, and that the 
> > source code is stored in sources and changes. The only diffirence is that 
> > the objects have a source variable that points to the right place for 
> > finding the source code.
> >
> > This is the final text if you find anything incorrect please correct me
> >
> > ---
> >
> > 1. The virtual machine (VM) is the only component that is different for 
> > each operating system. The purpose of the VM is to take Pharo bytcode that 
> > is generated each time user accepts a piece of code and convert it to 
> > machine code in order to be executed. Pharo 4 comes with the Cog VM a very 
> > fast JIT VM. The VM executable is named:
> >
> > • Pharo.exe for Windows; • pharo for Linux ; and
> >
> > • Pharo for OSX (inside a package also named Pharo.app).
> > The other components below are portable across operating systems, and
> >
> > can be copied and run on any appropriate virtual machine.
> >
> > 2. The sources file contains source code for parts of Pharo that don’t 
> > change frequently. Sources file is important because the image file format 
> > stores only the bytecode of live objects and not their source code. 
> > Typically a new sources file is generated once per major release of Pharo. 
> > For Pharo 4.0, this file is named PharoV40.sources.
> >
> > 3. The changes file logs of 

Re: [Pharo-users] Failling Tests are green if BlockCannotReturn exception

[Sven Van Caekenberghe]

> On 13 Jan 2016, at 18:42, abdelghani ALIDRA  wrote:
> 
> Thank you all for your responses.
> 
> I see your point about returning from a block. Because the return in this 
> example is very explicit. But what if I put (by mistake) a return in a block 
> in a method that is called by the test method (or even in a method that is 
> called by another method that is called by the test method) then I would have 
> no reason to doubt my test was successful whereas it would have failed if it 
> was run till the last assertion.
> 
> My point is, would it not be interesting to report tests that were not run 
> successfully till the end?

An empty test is successful.
A test only fails when an assertion fails.
Assertions must be written explicitly.

Your suggestion is not per se a bad idea, it is just not within the contract of 
SUnit, I think.

> Abdelghani
> 
> 
> De : Sven Van Caekenberghe 
> À : abdelghani ALIDRA ; Any question about pharo is 
> welcome  
> Envoyé le : Mardi 12 janvier 2016 7h35
> Objet : Re: [Pharo-users] Failling Tests are green if BlockCannotReturn 
> exception
> 
> 
> 
> 
> > On 12 Jan 2016, at 00:26, abdelghani ALIDRA  wrote:
> > 
> > Hi,
> > 
> > I observed this unexpected behavior in test classes.
> > In a test class define a method :
> > 
> > testBlock
> >|aBlock|
> >aBlock := [ ^1 ].
> >aBlock value.
> >self assert: false.
> > 
> > Althought the assertion is false at the end of the test, the test is green.
> > Actually, It does not matter what you put after aBlock value, the test 
> > always succedes (I tried to put a self halt, it does not execute)
> 
> The test is 'does an explicit return from a block return from the whole 
> method'. Of course it does. But if it would not, you would arrive at the self 
> assert: false and the test would fail. You see ?
> 
> BTW, this can also be written as self fail - search for the senders of that 
> message for more examples.
> 
> 
> > I tried this both in Pharo 4 and 5 under Windows and MacOS.
> > 
> > Any ideas?
> > 
> > Cheers 
> > Abdelghani
> > 
> > 
> 
> 

Re: [Pharo-users] I am David Allouche, let me introduce myself.

[Dimitris Chloupis]

"I have seen someone in another thread expressing the desire for
namespaces. As a newcomer, I also feel that is something important and
missing. But since one of the goals of Pharo is to produce an environment
that can be understood by a single person, the lack of namespace might
actually be a feature. Namespace are essential for languages like C++,
designed for large projects, produced by large teams, where nobody
understands the whole system. They embody an industrial approach to
programming. In contrast, I have the impression that Smalltalk emphasises
regularity to minimise system size, rather than modularity to manage system
size, and that it embodies a craftsmanship approach."

Pharo contains over 80 methods spread around several thousands classes
and the system has not imploded yet even though we have no namespaces. The
reasoning is simple, Pharo does not need namespaces because its not a
programming language. Namespaces primary role is not organization so much
as prevention of name clashes , this is not a problem for Pharo since it
does not allow name clashes in the first place. Thats is happening in the
enviroment and not language level, if you want to organise your classes you
use packages . Packages also are not part of the language and are also
implemented on enviroment level, though one could argue that language is
also part of the enviroment.

So yes it feelt strange even for not having namespace coming from python
but after coding in pharo for over a year its clear to me that pharo does
not need it and would probably benefit by more sophisticated and specific
implementation when it comes to organisations. But generally speaking we
already have plenty of tools that help you locate classes and methods with
ease, so that is not much of a problem.

Pharo enviroment is far from simple, quite the contrary Smalltalk
implementations were always far more complex than you average language like
C++, the big diffirence is that the enviroment is constructed in such way
to help you deal with complexity. Where modern languages ephasize
simplicity pharo and smalltalk in general invest on better dealing with
complexity , hence why Smalltalk has been very popular in specific very
complex fields like Banking Sector, Shipping etc. C++ is no where as
suitable for complex applications , its popularity merely stems from the
fact that is OS language with immediate access to OS libraries and massive
support.

On Wed, Jan 13, 2016 at 7:30 PM David Allouche  wrote:

> Thank you everyone for the kind responses. I will answer some of the
> questions and suggestions here.
>
> To get faster to the intellectual stimulation, pick a task / project and
> start asking questions. And have fun :).
>
>
> That is good advice, but right now I think I will just explore the system,
> review changes, and wait for the tasks to find me. There are already more
> things I want to do than I will probably every be able to accomplish :-)
>
> I think when people referring to Smalltalk refer to Smalltalk as the
> language or OOP itself, but thats only the tip of the iceberg, Pharo tries
> to stay true to vision of smalltalk creating the virtual enviroment where
> the user can easily create his or her own tools or modifying the existing
> ones, something that I feel no other language out there can emulate because
> they follow a non monolithic approach where there is a deep dichotomy
> between language, libraries and the environment itself. You could say that
> Smalltalk is the anti-Unix architecture , a great example of monolithic
> design that works great in practice yet its easy to modify and extend.
>
>
> The  fact Smalltalk the language cannot be taken in isolation from
> Smalltalk the environment became clear rather early on: reading the UPBE
> and other materials shows that the language itself does almost nothing: it
> cannot even define classes or packages. It is all part of the environment.
>
> I have seen someone in another thread expressing the desire for
> namespaces. As a newcomer, I also feel that is something important and
> missing. But since one of the goals of Pharo is to produce an environment
> that can be understood by a single person, the lack of namespace might
> actually be a feature. Namespace are essential for languages like C++,
> designed for large projects, produced by large teams, where nobody
> understands the whole system. They embody an industrial approach to
> programming. In contrast, I have the impression that Smalltalk emphasises
> regularity to minimise system size, rather than modularity to manage system
> size, and that it embodies a craftsmanship approach.
>
> Since I am just old enough to remember a time where computer systems could
> be understood by a single person, I find it an attractive idea to try and
> produce a modern system with that property.
>
> I can't remember who famous said something like "The only languages
> worth learning are the ones that changes the way you 

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

"I am getting off-topic, but since I have already written what follows, and
I think it is informative, I am leaving it there :-)"

Thats ok my question has been answered by Sven's first reply anyway, some
offtopic wont hurt

"Python is a rather large language, with a large number of quirks that need
to be preserved to provide full compatibility. It is also a language with
advanced introspection, and very dynamic semantics, even more than
Smalltalk in some aspects. And its main implementation (CPython) has very
highly optimised data structures and memory management.

That makes it really difficult to implement correctly and and to improve
performance without slowing down other parts. Before PyPy, Google funded
the Unladen Swallow project, that tried to produce a Python JIT using LLVM,
this project was abandoned. Even PyPy needs to make frequent and expensive
guard tests to ensure that invariants required for JIT are preserved. It
does bring a significant speed boost (2x-10x), but at the expense of slow
startup and increased memory footprint (~2x).

However, it seems clear that the long term future of Python lies in PyPy.
In particular, they have high hopes to solve the lack of multicore support
by implementing software transactional memory in the medium term, until
hardware transactional memory is advanced enough to be usable there."

Well I have watched a couple of talks of Guido (creator of cpython for
those who dont know) on the subject, and I think his overall argument "why
should I give a damn ?"

His line of argument is that Python offers such a great support for
wrapping C libraries that makes a JIT complier not that important. Python
initial missions was to be a scripting language for C/C++ , the fact it
grew to an entity by itself is the side effect of its popularity. However
Guido even lately stresses the idea what Python should remain one of the
best if not the best way to wrap C code. So if you start using and relying
on C code so much a JIT makes less and less sense. For example even cpython
itself over 50% of its code base is coded in C. Cpython developers are
essentially C developers.

Pharo is not on the same boat, Pharo is a self hosting enviroment, that
means that a great deal of code is written in pharo , some of it Slang that
is basically smalltalk that compiles to C and some of the really
performance dependent parts in pure C. Also Pharo libraries are not C
libraries wrapped for Pharo, they are just Pharo libraries. So it is a very
diffirent mentality .

So the reason why CPython has not a JIT VM is that it does really need it,
python coders already rely on performance orientated python libraries( see
numpy) that are written in C to do the heavy lifiting, I dont think a JIT
VM would make much of a difference anyway.

On the other hand you rarely see someone here asking for the Pharo FFI, or
how to make a VM plugin , in 99% of the cases people work on pure pharo
code.

On Wed, Jan 13, 2016 at 8:04 PM David Allouche  wrote:

> On 13 Jan 2016, at 18:14, Dimitris Chloupis  wrote:
>
> Why the Cog VM is mentioned in my documentation is no accident. There is
> another VM that is called Stackless VM or old VM that was the VM before Cog
> that had no JIT and its a VM we still use for platforms that Cog VM does
> not currently run like Raspberry Pi, Android and I think iOS too.
>
>
> "But nowadays, JIT compiling byte-code to machine language are the norm
> rather than the exception, so I do not think it is worth mentioning."
>
> Definitely not the norm Python and Ruby VMs are not JIT, generally
> speaking JIT compilers are rare for Dynamic languages like Pharo. Python
> has PyPy which is a JIT VM but is nowhere as popular as Cpython.
>
>
> You are right. The JIT is worth mentioning there.
>
>
> CPython people try to avoid JIT because it makes VM architecture much more
> complex. At least thats their argument.
>
>
> I am getting off-topic, but since I have already written what follows, and
> I think it is informative, I am leaving it there :-)
>
> Python is a rather large language, with a large number of quirks that need
> to be preserved to provide full compatibility. It is also a language with
> advanced introspection, and very dynamic semantics, even more than
> Smalltalk in some aspects. And its main implementation (CPython) has very
> highly optimised data structures and memory management.
>
> That makes it really difficult to implement correctly and and to improve
> performance without slowing down other parts. Before PyPy, Google funded
> the Unladen Swallow project, that tried to produce a Python JIT using LLVM,
> this project was abandoned. Even PyPy needs to make frequent and expensive
> guard tests to ensure that invariants required for JIT are preserved. It
> does bring a significant speed boost (2x-10x), but at the expense of slow
> startup and increased memory footprint (~2x).
>
> However, it seems clear that the long term future of Python 

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Offray Vladimir Luna Cárdenas]

Hi,

I've reading the code at [1] but I'm still having problems understanding 
the dynamic spec. I have created a small dictionary and populated with 
data, then created the accessors and initializePresenter, 
initializeWidgets and rebuildWithdCodeLayout and rebuildWithTextLayout, 
as you can see on the following snippets, but nothing happens despite 
the debugging Transcript is showing me that the content subwidget has 
the proper model, but is not rebuild in the GUI.


Any help is, as always, very much appreciated.

[1] 
https://github.com/spec-framework/documentation/blob/master/output/book.md#rebuildDynamically


--
DynamicDict>>initializeWidgets

| data |
data := { 'first' -> 'I\"m just text' . 'second' -> 'ProfStef 
openPharoZenWorkspace'} asOrderedDictionary.

list := self newList.
list items: data keys.
content := self newText.
self focusOrder
add: list;
add: content.
--
DynamicDict>>initializePresenter
list whenSelectedItemChanged: [:item |
item = 'first'
ifTrue: [ self rebuildWithTextLayout ].
item = 'second'
ifTrue: [ self rebuildWithCodeLayout ].
]
--
DynamicDict>>rebuildWithCodeLayout
| newLayout |

content := self instantiate: GlamourPresentationModel.
newLayout := SpecLayout composed
newRow: [:row |
row
add: #list right: 0.7;
add: #content left: 0.3];
yourself.
self needRebuild: true.
content needRebuild: true.
Transcript show: 'código + ', self content asString, String cr.
self buildWithSpecLayout: newLayout.
--
DynamicDict>>rebuildWithTextLayout
| newLayout |

content := self newText.
newLayout := SpecLayout composed
newRow: [:row |
row
add: #list right: 0.7;
add: #content left: 0.3];
yourself.
self needRebuild: false.
list needRebuild: false.
content needRebuild: true.
Transcript show: 'texto + ', self content asString, String cr..
self buildWithSpecLayout: newLayout.
--

Cheers,

Offray

On 10/01/16 13:39, Johan Fabry wrote:
Sorry for the lateness and short reply but I’m involved in a bunch of 
other things that are taking almost all of my time ...


From what I understand and what I can see in your code, you want to 
modify a widget when the UI is open. However you never trigger the 
rebuilding of the window. For example, see the Spec docs that I sent, 
where in 9.1 there is code that calls buildWithSpecLayout: .


Actually, I am not sure you need to subclass DynamicComposableModel 
since the number of widgets never changes. You can use a normal 
ComposableModel subclass and use what is detailed in 9.1 to change the 
layout between the two options you want to have (a TextModel or a 
GlamourPresentationModel).


On Jan 8, 2016, at 23:07, Offray Vladimir Luna Cárdenas 
> wrote:


Shouldn't be #right dynamically defined according to the values of 
'item' and be replaced on the m2 layout?




---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   - http://pleiad.cl/~jfabry 
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  - 
 University of Chile

Re: [Pharo-users] I am David Allouche, let me introduce myself.

[Serge Stinckwich]

On Wed, Jan 13, 2016 at 6:29 PM, David Allouche  wrote:
> Thank you everyone for the kind responses. I will answer some of the
> questions and suggestions here.
 ...

> Where are you located ?
>
>
> Paris, France.

Great !
I'm also located in Paris.
Maybe we could have a Pharo user group in the future. I know 5
Pharoers now in Paris ;-)

Regards,
-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-users] I am David Allouche, let me introduce myself.

[Ben Coman]

On Thu, Jan 14, 2016 at 2:12 AM, Dimitris Chloupis
 wrote:
> "I have seen someone in another thread expressing the desire for namespaces.
> As a newcomer, I also feel that is something important and missing. But
> since one of the goals of Pharo is to produce an environment that can be
> understood by a single person, the lack of namespace might actually be a
> feature. Namespace are essential for languages like C++, designed for large
> projects, produced by large teams, where nobody understands the whole
> system. They embody an industrial approach to programming. In contrast, I
> have the impression that Smalltalk emphasises regularity to minimise system
> size, rather than modularity to manage system size, and that it embodies a
> craftsmanship approach."
>
> Pharo contains over 80 methods spread around several thousands classes
> and the system has not imploded yet even though we have no namespaces. The
> reasoning is simple, Pharo does not need namespaces because its not a
> programming language. Namespaces primary role is not organization so much as
> prevention of name clashes , this is not a problem for Pharo since it does
> not allow name clashes in the first place.

Name clashes can still happen between different external libraries.
Effectively we have a poor-mans namespaces with prefixes.  But its
harder to port libraries from other Smalltalks that support
namespaces, limiting our ecosystem.  Not necessarily the main driver,
but worthy of consideration.  Squeak has recently done some namespace
stuff so will be interesting to see their experience.

cheers -ben


> Thats is happening in the
> enviroment and not language level, if you want to organise your classes you
> use packages . Packages also are not part of the language and are also
> implemented on enviroment level, though one could argue that language is
> also part of the enviroment.
>
> So yes it feelt strange even for not having namespace coming from python but
> after coding in pharo for over a year its clear to me that pharo does not
> need it and would probably benefit by more sophisticated and specific
> implementation when it comes to organisations. But generally speaking we
> already have plenty of tools that help you locate classes and methods with
> ease, so that is not much of a problem.
>
> Pharo enviroment is far from simple, quite the contrary Smalltalk
> implementations were always far more complex than you average language like
> C++, the big diffirence is that the enviroment is constructed in such way to
> help you deal with complexity. Where modern languages ephasize simplicity
> pharo and smalltalk in general invest on better dealing with complexity ,
> hence why Smalltalk has been very popular in specific very complex fields
> like Banking Sector, Shipping etc. C++ is no where as suitable for complex
> applications , its popularity merely stems from the fact that is OS language
> with immediate access to OS libraries and massive support.
>
> On Wed, Jan 13, 2016 at 7:30 PM David Allouche  wrote:
>>
>> Thank you everyone for the kind responses. I will answer some of the
>> questions and suggestions here.
>>
>> To get faster to the intellectual stimulation, pick a task / project and
>> start asking questions. And have fun :).
>>
>>
>> That is good advice, but right now I think I will just explore the system,
>> review changes, and wait for the tasks to find me. There are already more
>> things I want to do than I will probably every be able to accomplish :-)
>>
>> I think when people referring to Smalltalk refer to Smalltalk as the
>> language or OOP itself, but thats only the tip of the iceberg, Pharo tries
>> to stay true to vision of smalltalk creating the virtual enviroment where
>> the user can easily create his or her own tools or modifying the existing
>> ones, something that I feel no other language out there can emulate because
>> they follow a non monolithic approach where there is a deep dichotomy
>> between language, libraries and the environment itself. You could say that
>> Smalltalk is the anti-Unix architecture , a great example of monolithic
>> design that works great in practice yet its easy to modify and extend.
>>
>>
>> The  fact Smalltalk the language cannot be taken in isolation from
>> Smalltalk the environment became clear rather early on: reading the UPBE and
>> other materials shows that the language itself does almost nothing: it
>> cannot even define classes or packages. It is all part of the environment.
>>
>> I have seen someone in another thread expressing the desire for
>> namespaces. As a newcomer, I also feel that is something important and
>> missing. But since one of the goals of Pharo is to produce an environment
>> that can be understood by a single person, the lack of namespace might
>> actually be a feature. Namespace are essential for languages like C++,
>> designed for large projects, produced by large teams, where nobody
>> 

Re: [Pharo-users] SSL client certificates

[stepharo]

Excellent idea!!!

We should rethink "software bounties". I don't have the time to fix this but 
I'm willing to put some money on the table to have it implemented properly. There are 
more people wanting to pay for features implemented. And I'm sure there are developers 
that would like to do it when being paid.

PS: norbert I need a new success story :)

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

great explanation Ben thanks for sharing, I agree 100% . ISO files are
popular file formats used by other VMs , like VirtualBOX unlike pharo image
they are not a memory dump but rather a hard disk dump which is later
loaded in memory usually to emulate booting from a DVD or booting a HD drive

https://en.wikipedia.org/wiki/ISO_image

Of course because in the pharo image we store every live object that means
everything the similarity in how both formats are used is very similar way.

On Wed, Jan 13, 2016 at 5:31 PM Ben Coman  wrote:

> Oh! I should have guessed there'd be more alternative suggestions and held
> back.
> Anyway, its done now, so just pick out what you like...
> Now I tend to think of the Image as more than just the .image file, so...
>
> The heart of Pharo is the *Image*.  This holds the live running state
> of a Pharo system. Tools like the IDE, language parser and interactive
> playground run *inside* the Image to write code and create interacting
> objects which comprise your application.  Saving the Image to a
> ".image" file creates a frozen-in-time snapshot of the running system
> state. This can be moved to another system and resumed running as if
> the Image had never stopped.  The Pharo download provides
> /Pharo.image/ file as the starting point for the live environment that
> you adapt to your needs.
>
> The Image runs on a Virtual Machine.  This abstracts away operating
> system and CPU architecture differences to allow the same ".image"
> file (the snapshot of you live system) to open and run on any support
> platform. The VM executable file is a different for each platform:
> * pharo for Linux and Unix
> * Pharo.exe for Windows
> * Pharo for OSX
>
> Your source-code is compiled to byte-code in Image to become part of
> the live system state.  This occurs as soon as a modified method is
> accepted.  Only the modified method is compiled, not the whole source
> code, and the bytecode is immediately runnable.  This facilitates a
> very fast edit-compile-run-debug loop at the root of Pharo's
> productivity.   The VM optimally interprets or just-in-time compiles
> the bytecode as appropriate for best performance.
>
> As an implementation detail carried over from when ram was scarce, the
> source-code is not stored in-Image.  It is spread across two files:
>
> * Sources for parts of Pharo (i.e. the tools) that don’t change
> frequently are stored in the "*.sources" files.   It is generated as a
> static file per major release. Thus for  Pharo 4.0 it is named
> PharoV40.sources, and keeps that name when the image file name
> changes.   The *.sources file is not essential for running the Image,
> but is important because without it, you can't examine and learn from
> the implementation of Pharo's tools (e.g Collections, Graphics
> libraries, IDE and compiler.)
>
> * All source code changes are journal logged to the "*.changes" file.
> This facilitates easy access to per method history for diffs or
> reverting.  Further, if you close or crash your image without saving,
> an in-Image tool can replay your "lost" changes from this file. The
> "*.changes" file is tightly coupled to the "*.image" file because it
> records the source code changes for a particular Image.  The basename
> of these two files must always be the same (e.g. my.image &
> my.changes).  Each release provides a near empty file, for example
> Pharo4.changes to match Pharo4.image.
>
> Typically the VM and .sources files are distributed/stored together,
> since both are static files (per machine per Pharo Release) and both
> can be shared between multiple Images; and the dynamic .image and
> .changes files are distributed/stored together.
>
>
>
>
> > The other components below are portable across operating systems, and
>
>
> The image file provides a frozen in time snapshot of a running Pharo
> > system. This is the file where the Pharo bytecode is stored and as such
> its
> > a cross platform format. This is the heart of Pharo, containing the live
> > state of all objects in the system (including classes and methods, since
> > they are objects too). The file is named for the release (like
> > Pharo4.0.image).
> >
>
>
>
> On Wed, Jan 13, 2016 at 7:58 PM, Dimitris Chloupis
>  wrote:
> > So I am correct that the image does not store the source code, and that
> the
> > source code is stored in sources and changes. The only diffirence is that
> > the objects have a source variable that points to the right place for
> > finding the source code.
> >
> > This is the final text if you find anything incorrect please correct me
> >
> > ---
> >
> > 1. The virtual machine (VM) is the only component that is different for
> each
> > operating system. The purpose of the VM is to take Pharo bytcode that is
> > generated each time user accepts a piece of code and convert it to
> machine
> > code in order to be executed. Pharo 4 comes with the Cog VM a very fast
> JIT
> > VM. The VM 

Re: [Pharo-users] Understanding the role of the sources file

[Sven Van Caekenberghe]

I like Ben's version too. (It helps to be a native English speaker as well ;-)

Please write more, Ben.

> On 13 Jan 2016, at 16:41, Dimitris Chloupis  wrote:
> 
> great explanation Ben thanks for sharing, I agree 100% . ISO files are 
> popular file formats used by other VMs , like VirtualBOX unlike pharo image 
> they are not a memory dump but rather a hard disk dump which is later loaded 
> in memory usually to emulate booting from a DVD or booting a HD drive
> 
> https://en.wikipedia.org/wiki/ISO_image
> 
> Of course because in the pharo image we store every live object that means 
> everything the similarity in how both formats are used is very similar way. 
> 
> On Wed, Jan 13, 2016 at 5:31 PM Ben Coman  wrote:
> Oh! I should have guessed there'd be more alternative suggestions and held 
> back.
> Anyway, its done now, so just pick out what you like...
> Now I tend to think of the Image as more than just the .image file, so...
> 
> The heart of Pharo is the *Image*.  This holds the live running state
> of a Pharo system. Tools like the IDE, language parser and interactive
> playground run *inside* the Image to write code and create interacting
> objects which comprise your application.  Saving the Image to a
> ".image" file creates a frozen-in-time snapshot of the running system
> state. This can be moved to another system and resumed running as if
> the Image had never stopped.  The Pharo download provides
> /Pharo.image/ file as the starting point for the live environment that
> you adapt to your needs.
> 
> The Image runs on a Virtual Machine.  This abstracts away operating
> system and CPU architecture differences to allow the same ".image"
> file (the snapshot of you live system) to open and run on any support
> platform. The VM executable file is a different for each platform:
> * pharo for Linux and Unix
> * Pharo.exe for Windows
> * Pharo for OSX
> 
> Your source-code is compiled to byte-code in Image to become part of
> the live system state.  This occurs as soon as a modified method is
> accepted.  Only the modified method is compiled, not the whole source
> code, and the bytecode is immediately runnable.  This facilitates a
> very fast edit-compile-run-debug loop at the root of Pharo's
> productivity.   The VM optimally interprets or just-in-time compiles
> the bytecode as appropriate for best performance.
> 
> As an implementation detail carried over from when ram was scarce, the
> source-code is not stored in-Image.  It is spread across two files:
> 
> * Sources for parts of Pharo (i.e. the tools) that don’t change
> frequently are stored in the "*.sources" files.   It is generated as a
> static file per major release. Thus for  Pharo 4.0 it is named
> PharoV40.sources, and keeps that name when the image file name
> changes.   The *.sources file is not essential for running the Image,
> but is important because without it, you can't examine and learn from
> the implementation of Pharo's tools (e.g Collections, Graphics
> libraries, IDE and compiler.)
> 
> * All source code changes are journal logged to the "*.changes" file.
> This facilitates easy access to per method history for diffs or
> reverting.  Further, if you close or crash your image without saving,
> an in-Image tool can replay your "lost" changes from this file. The
> "*.changes" file is tightly coupled to the "*.image" file because it
> records the source code changes for a particular Image.  The basename
> of these two files must always be the same (e.g. my.image &
> my.changes).  Each release provides a near empty file, for example
> Pharo4.changes to match Pharo4.image.
> 
> Typically the VM and .sources files are distributed/stored together,
> since both are static files (per machine per Pharo Release) and both
> can be shared between multiple Images; and the dynamic .image and
> .changes files are distributed/stored together.
> 
> 
> 
> 
> > The other components below are portable across operating systems, and
> 
> 
> The image file provides a frozen in time snapshot of a running Pharo
> > system. This is the file where the Pharo bytecode is stored and as such its
> > a cross platform format. This is the heart of Pharo, containing the live
> > state of all objects in the system (including classes and methods, since
> > they are objects too). The file is named for the release (like
> > Pharo4.0.image).
> >
> 
> 
> 
> On Wed, Jan 13, 2016 at 7:58 PM, Dimitris Chloupis
>  wrote:
> > So I am correct that the image does not store the source code, and that the
> > source code is stored in sources and changes. The only diffirence is that
> > the objects have a source variable that points to the right place for
> > finding the source code.
> >
> > This is the final text if you find anything incorrect please correct me
> >
> > ---
> >
> > 1. The virtual machine (VM) is the only component that is different for each
> > operating system. The purpose 

Re: [Pharo-users] Understanding the role of the sources file

[Offray Vladimir Luna Cárdenas]

Yep, I think that Ben's version is even better and more balanced for a 
newbie while informative enough over David's draft.


Cheers,

Offray

On 13/01/16 10:30, Ben Coman wrote:

Oh! I should have guessed there'd be more alternative suggestions and held back.
Anyway, its done now, so just pick out what you like...
Now I tend to think of the Image as more than just the .image file, so...

The heart of Pharo is the *Image*.  This holds the live running state
of a Pharo system. Tools like the IDE, language parser and interactive
playground run *inside* the Image to write code and create interacting
objects which comprise your application.  Saving the Image to a
".image" file creates a frozen-in-time snapshot of the running system
state. This can be moved to another system and resumed running as if
the Image had never stopped.  The Pharo download provides
/Pharo.image/ file as the starting point for the live environment that
you adapt to your needs.

The Image runs on a Virtual Machine.  This abstracts away operating
system and CPU architecture differences to allow the same ".image"
file (the snapshot of you live system) to open and run on any support
platform. The VM executable file is a different for each platform:
* pharo for Linux and Unix
* Pharo.exe for Windows
* Pharo for OSX

Your source-code is compiled to byte-code in Image to become part of
the live system state.  This occurs as soon as a modified method is
accepted.  Only the modified method is compiled, not the whole source
code, and the bytecode is immediately runnable.  This facilitates a
very fast edit-compile-run-debug loop at the root of Pharo's
productivity.   The VM optimally interprets or just-in-time compiles
the bytecode as appropriate for best performance.

As an implementation detail carried over from when ram was scarce, the
source-code is not stored in-Image.  It is spread across two files:

* Sources for parts of Pharo (i.e. the tools) that don’t change
frequently are stored in the "*.sources" files.   It is generated as a
static file per major release. Thus for  Pharo 4.0 it is named
PharoV40.sources, and keeps that name when the image file name
changes.   The *.sources file is not essential for running the Image,
but is important because without it, you can't examine and learn from
the implementation of Pharo's tools (e.g Collections, Graphics
libraries, IDE and compiler.)

* All source code changes are journal logged to the "*.changes" file.
This facilitates easy access to per method history for diffs or
reverting.  Further, if you close or crash your image without saving,
an in-Image tool can replay your "lost" changes from this file. The
"*.changes" file is tightly coupled to the "*.image" file because it
records the source code changes for a particular Image.  The basename
of these two files must always be the same (e.g. my.image &
my.changes).  Each release provides a near empty file, for example
Pharo4.changes to match Pharo4.image.

Typically the VM and .sources files are distributed/stored together,
since both are static files (per machine per Pharo Release) and both
can be shared between multiple Images; and the dynamic .image and
.changes files are distributed/stored together.





The other components below are portable across operating systems, and


The image file provides a frozen in time snapshot of a running Pharo

system. This is the file where the Pharo bytecode is stored and as such its
a cross platform format. This is the heart of Pharo, containing the live
state of all objects in the system (including classes and methods, since
they are objects too). The file is named for the release (like
Pharo4.0.image).




On Wed, Jan 13, 2016 at 7:58 PM, Dimitris Chloupis
 wrote:

So I am correct that the image does not store the source code, and that the
source code is stored in sources and changes. The only diffirence is that
the objects have a source variable that points to the right place for
finding the source code.

This is the final text if you find anything incorrect please correct me

---

1. The virtual machine (VM) is the only component that is different for each
operating system. The purpose of the VM is to take Pharo bytcode that is
generated each time user accepts a piece of code and convert it to machine
code in order to be executed. Pharo 4 comes with the Cog VM a very fast JIT
VM. The VM executable is named:

• Pharo.exe for Windows; • pharo for Linux ; and

• Pharo for OSX (inside a package also named Pharo.app).
The other components below are portable across operating systems, and

can be copied and run on any appropriate virtual machine.

2. The sources file contains source code for parts of Pharo that don’t
change frequently. Sources file is important because the image file format
stores only the bytecode of live objects and not their source code.
Typically a new sources file is generated once per major release of Pharo.
For Pharo 4.0, this file is named 

Re: [Pharo-users] Understanding the role of the sources file

[Offray Vladimir Luna Cárdenas]

Hi,

I like David's proposal. It strikes a good balance between newbie 
friendly and detailed enough foundations (you don't learn Peano's Axioms 
before learning to count).


Cheers,

Offray

On 13/01/16 09:27, David Allouche wrote:

Hey,

Since I just recently figured that stuff out, my perspective might be 
useful.


I do not think it is a good idea to push external VCS too much at this 
point. They are important to collaboration, so they should be 
mentioned, but they add a lot of complexity.


Taking into account the feedback from Sven, and my own ideas, here's 
how I would write it. I hope this helps.


 1. The *virtual machine* (VM) provides the environment where the
Pharo system lives. It is different for each operating system and
hardware architecture, and runs as a machine language executable
in the operating system. It implements the details of managing
memory, executing Pharo byte-code, and communicating with the
world outside of the Pharo system: files, other operating system
process, and the network.
 2. The *image* is the state of all objects in a running Pharo system:
classes, method as source and byte-code, windows, VM processes.
All of those are objects. The virtual machine can load image
files, and save running images back to disk.
 3. The *sources* file is a way to save space by putting the source
code of classes outside of the image. Since an image contains
byte-compiled methods, it can run without its associated sources
files. This file only provides information that useful to the
programmer. It is generated once per major release of Pharo, and
is usually stored in the same directory as the image. Several
images can use the same sources file.
 4. The *changes* file logs all source code changes since the
generation of the sources file. It lets you examine and revert
source code changes. It also serves as a journal so you can
recover changes you made but did not save to the disk image, by
mistake or because of a crash. An image does not need its changes
file to run. Each change file belong to a single image.


NOTE: Some virtual machines run in web browsers, and are Javascript 
programs instead of machine language. They provide the same services 
as other virtual machines, they just treat Javascript as the machine 
language and the browser as the operating system.


The image, sources and changes files are portable across operating 
systems, and can be copied and run on any appropriate virtual machine. 
The format of the sources and changes file is defined by code stored 
in the image, not the VM.


A complete Pharo release contains the following files:

  * An executable virtual machine, named:
  o Pharo.exe for Windows;
  o pharo for Linux;
  o Pharo for OS X (inside a package named Pharo.app).
  * An image, named after the release: Pharo4.0.image
  * A sources file, named after the release: PharoV40.sources.
  * A nearly empty changes file, named after the image: Pharo4.0.changes


They are starting point for a live environment that you adapt to your 
needs. The .image file containes the byte-compiler of the language, 
the language parser, the IDE tools, many libraries and provide a 
virtual operating system that runs on top of a virtual machine.


As you work in Pharo, the .image and .changes files are modified, so 
you need to make sure that they are writable. 
The .image and .changes files are intimately linked and should always 
be kept together, with matching filenames. Never edit them directly 
with a text editor, as .images holds your live object runtime memory, 
which indexes into the .changes files for the source.


It is a good idea to keep a backup copy of the 
downloaded .image and .changes files so you can always start from a 
fresh image and reload your code. But to manage changes on larger 
projects you should also use a version control system that will 
provide more control to record and communicate your changes.


The four main component files above can be placed in the same 
directory, although it’s also possible to put the Virtual Machine and 
sources file in a separate directory where everyone has read-only 
access to them.


If more than one image file is present in the same directory pharo 
will prompt you to choose an image file you want to load.


Do whatever works best for your style of working and your operating 
system.

Re: [Pharo-users] SSL client certificates

[Marcus Denker]

Yes, I will look at existing platforms (started already in christmas holidays, 
will continue).

Marcus

> On 13 Jan 2016, at 16:34, stepharo  wrote:
> 
> Excellent idea!!!
>> We should rethink "software bounties". I don't have the time to fix this but 
>> I'm willing to put some money on the table to have it implemented properly. 
>> There are more people wanting to pay for features implemented. And I'm sure 
>> there are developers that would like to do it when being paid.
> PS: norbert I need a new success story :)
> 

Re: [Pharo-users] Understanding the role of the sources file

[Ben Coman]

On Wed, Jan 13, 2016 at 11:41 PM, Dimitris Chloupis
 wrote:
> great explanation Ben thanks for sharing, I agree 100% .

On Wed, Jan 13, 2016 at 11:46 PM, Sven Van Caekenberghe  wrote:
> I like Ben's version too. (It helps to be a native English speaker as well ;-)
> Please write more, Ben.

Thanks.  But damn, I need to correct my own grammar...
I've _underlined_ updates...

>> On Wed, Jan 13, 2016 at 5:31 PM Ben Coman  wrote:
>> Oh! I should have guessed there'd be more alternative suggestions and held 
>> back.
>> Anyway, its done now, so just pick out what you like...
>> Now I tend to think of the Image as more than just the .image file, so...
>>
>> The heart of Pharo is the *Image*.  This holds the live running state
>> of a Pharo system. Tools like the IDE, language parser and interactive
>> playground run *inside* the Image to _modify_ code and create interacting
>> objects which comprise your application.  Saving the Image to _an_
>> ".image" file creates a frozen-in-time snapshot of the running system
>> state. This can be moved to another system and resumed running as if
>> the Image had never stopped.  The Pharo _Release_ download provides _the_
>> /Pharo.image/ file as the starting point for the live environment that
>> you adapt to your needs.
>>
>> The Image runs on a Virtual Machine.  This abstracts away operating
>> system and CPU architecture differences to allow the same ".image"
>> file (the snapshot of you live system) to open and run on any _supported_
>> platform. The VM executable file is __ different for each platform:
>> * pharo for Linux and Unix
>> * Pharo.exe for Windows
>> * Pharo for OSX
>>
>> Your source-code is compiled to byte-code in Image to become part of
>> the live system state.  This occurs as soon as a modified method is
>> accepted.  Only the modified method is compiled, not the whole _system_ 
>> source
>> __, and the bytecode is immediately runnable.  This facilitates a
>> very fast edit-compile-run-debug loop at the root of Pharo's
>> productivity.   The VM optimally interprets or just-in-time compiles
>> the bytecode as appropriate for best performance.
>>
>> As an implementation detail carried over from when _RAM_ was scarce, the
>> source-code is not stored in-Image.  It is spread across two files:
>>
>> * Sources for parts of Pharo (i.e. the _in-Image_ tools) that don’t change
>> frequently are stored in the "*.sources" _file_.   It is generated as a
>> static file per major release. Thus for  Pharo 4.0 it is named
>> PharoV40.sources, and keeps that name (_while_ the .image file name
>> _can change_).   The *.sources file is not essential for running the Image,
>> but is important because without it, you can't examine and learn from
>> the implementation of Pharo's tools (e.g Collections, Graphics
>> libraries, IDE and compiler.)
>>
>> * All _changes to_ source code __ are journal logged to the "*.changes" file.
>> This facilitates easy access to per method history for diffs or
>> reverting.  Further, if you close or crash your image _before_ saving,
>> an in-Image tool can replay your "lost" changes from this file. The
>> "*.changes" file is tightly coupled to the "*.image" file because it
>> records the source code changes for a particular Image.  The basename
>> of these two files must always _match_  (e.g. my.image &
>> my.changes).  Each release provides a near empty file, for example
>> Pharo4.changes to match Pharo4.image.
>>
>> Typically the VM and .sources files are distributed/stored together,
>> since both are static files (per machine, per Pharo Release) and both
>> can be shared between multiple Images.  _The paired_ dynamic .image and
>> .changes files _are inherently_ distributed/stored together.  _The static 
>> and dynamic pairs can be stored in separate folders._

___






>> > The other components below are portable across operating systems, and
>>
>>
>> The image file provides a frozen in time snapshot of a running Pharo
>> > system. This is the file where the Pharo bytecode is stored and as such its
>> > a cross platform format. This is the heart of Pharo, containing the live
>> > state of all objects in the system (including classes and methods, since
>> > they are objects too). The file is named for the release (like
>> > Pharo4.0.image).
>> >
>>
>>
>>
>> On Wed, Jan 13, 2016 at 7:58 PM, Dimitris Chloupis
>>  wrote:
>> > So I am correct that the image does not store the source code, and that the
>> > source code is stored in sources and changes. The only diffirence is that
>> > the objects have a source variable that points to the right place for
>> > finding the source code.
>> >
>> > This is the final text if you find anything incorrect please correct me
>> >
>> > ---
>> >
>> > 1. The virtual machine (VM) is the only component that is different for 
>> > each
>> > operating system. The purpose of the VM is to 

Re: [Pharo-users] Understanding the role of the sources file

[Ben Coman]

> On Wed, Jan 13, 2016 at 4:58 PM Werner Kassens  wrote:
>>
>> Hi Dimitris,
>> your formulation "...Pharo bytcode...and convert it to machine code..."
>> is insofar irritating to me as "convert it to machine code" would
>> suggest to me that a compiler is at work here. Davids "executing Pharo
>> byte-code" seems more understandable to me here.

On Wed, Jan 13, 2016 at 11:27 PM, Dimitris Chloupis
 wrote:
> Thats correct its a compiler, a byte compiler, it compiles bytecode to
> machine code and it does it while the code executes, this is why its called
> JIT , which has the meaning of Just In Time compilation, meaning that
> machine code is compiled just before the code is executed so several
> optimizations can be applied that would not be known before the execution of
> the code. Similar to JAVA's JIT compiler.
>
> Note here that a compiler is not just something that produces machine code,
> a compiler for example can take one language and compile it to another
> language.

Indeed.  The OpalCompiler takes Smalltalk and produces bytecode.

However I think Sven and Werner were referring that much of Pharo code
is not JITd, but *merely* interpreted (IIUC).  See section "Not so
smart questions" here...
https://clementbera.wordpress.com/2014/01/09/the-sista-chronicles-i-an-introduction-to-adaptive-recompilation/

cheers -ben

>>
>> On 01/13/2016 02:22 PM, Dimitris Chloupis wrote:
>> > I assume you have never read a an introduction to C++ then :D
>> >
>> > here is the final addition for the vm
>> >
>> > (Vm) is the only component that is different for each operating system.
>> > The main purpose of the VM is to take Pharo bytcode that is generated
>> > each time user accepts a piece of code and convert it to machine code in
>> > order to be executed, but also to generally handle low level
>> > functionality like interpreting code, handling OS events (mouse and
>> > keyboard), calling C libraries etc. Pharo 4 comes with the Cog VM a very
>> > fast JIT VM.
>> >
>> > I think its clear, precise and does not leave much room for confusion.
>> > Personally I think its very important for the absolute begineer to have
>> > strong foundations of understanding the fundamental of Pharo and not for
>> > things to appear magical and "dont touch this".
>> >
>> > On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe > > > wrote:
>> >
>> >
>> >  > On 13 Jan 2016, at 13:42, Dimitris Chloupis
>> > > wrote:
>> >  >
>> >  > I mentioned bytecode because I dont want the user to see at some
>> > point bytecode and say "What the hell is that" I want the reader to
>> > feel confident that at least understands the basic in Pharo. Also
>> > very brief explanations about bytecode I have seen in similar python
>> > tutorials. Obviously I dont want to go any deeper than that because
>> > the user wont have to worry about the technical details on a daily
>> > basis anyway.
>> >  >
>> >  > I agree that I could add a bit more on the VM description similar
>> > to what you posted. I am curious though, wont even the interpreter
>> > generate machine code in order to execute the code  or does it use
>> > existing machine code inside the VM binary ?
>> >
>> > No, a classic interpreter does not 'generate' machine code, it is
>> > just a program that reads and executes bytes codes in a loop, the
>> > interpreter 'is' machine code.
>> >
>> > No offence, but you see why I think it is important to not try to
>> > use or explain too much complex concepts in the 1st chapter.
>> >
>> > Learning to program is hard. It should first be done abstractly.
>> > Think about Scratch. The whole idea of Smalltalk is to create a
>> > world of interacting objects. (Even byte code is not a necessary
>> > concept at all, for example, in Pharo, you can compile (translate)
>> > to AST and execute that, I believe. There are Smalltalk
>> > implementations that compile directly to C or JavaScript). Hell,
>> > even 'compile' is not necessary, just 'accept'. See ?
>> >
>> >  > On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe
>> > > wrote:
>> >  > Sounds about right.
>> >  >
>> >  > Now, I would swap 1 and 4, as the image is the most important
>> > abstraction.
>> >  >
>> >  > There is also a bit too much emphasis on (byte|source)code. This
>> > is already pretty technical (it assume you know what compilation is
>> > and so on). But I understand it must be explained here, and you did
>> > it well.
>> >  >
>> >  > However, I would start by saying that the image is a snapshot of
>> > the object world in memory that is effectively a live Pharo system.
>> > It contains everything that is available and that exists in Pharo.
>> > This includes 

Re: [Pharo-users] Understanding the role of the sources file

[Werner Kassens]

Hi Dimitris,
your formulation "...Pharo bytcode...and convert it to machine code..." 
is insofar irritating to me as "convert it to machine code" would 
suggest to me that a compiler is at work here. Davids "executing Pharo 
byte-code" seems more understandable to me here.

werner

On 01/13/2016 02:22 PM, Dimitris Chloupis wrote:

I assume you have never read a an introduction to C++ then :D

here is the final addition for the vm

(Vm) is the only component that is different for each operating system.
The main purpose of the VM is to take Pharo bytcode that is generated
each time user accepts a piece of code and convert it to machine code in
order to be executed, but also to generally handle low level
functionality like interpreting code, handling OS events (mouse and
keyboard), calling C libraries etc. Pharo 4 comes with the Cog VM a very
fast JIT VM.

I think its clear, precise and does not leave much room for confusion.
Personally I think its very important for the absolute begineer to have
strong foundations of understanding the fundamental of Pharo and not for
things to appear magical and "dont touch this".

On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe > wrote:


 > On 13 Jan 2016, at 13:42, Dimitris Chloupis
> wrote:
 >
 > I mentioned bytecode because I dont want the user to see at some
point bytecode and say "What the hell is that" I want the reader to
feel confident that at least understands the basic in Pharo. Also
very brief explanations about bytecode I have seen in similar python
tutorials. Obviously I dont want to go any deeper than that because
the user wont have to worry about the technical details on a daily
basis anyway.
 >
 > I agree that I could add a bit more on the VM description similar
to what you posted. I am curious though, wont even the interpreter
generate machine code in order to execute the code  or does it use
existing machine code inside the VM binary ?

No, a classic interpreter does not 'generate' machine code, it is
just a program that reads and executes bytes codes in a loop, the
interpreter 'is' machine code.

No offence, but you see why I think it is important to not try to
use or explain too much complex concepts in the 1st chapter.

Learning to program is hard. It should first be done abstractly.
Think about Scratch. The whole idea of Smalltalk is to create a
world of interacting objects. (Even byte code is not a necessary
concept at all, for example, in Pharo, you can compile (translate)
to AST and execute that, I believe. There are Smalltalk
implementations that compile directly to C or JavaScript). Hell,
even 'compile' is not necessary, just 'accept'. See ?

 > On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe
> wrote:
 > Sounds about right.
 >
 > Now, I would swap 1 and 4, as the image is the most important
abstraction.
 >
 > There is also a bit too much emphasis on (byte|source)code. This
is already pretty technical (it assume you know what compilation is
and so on). But I understand it must be explained here, and you did
it well.
 >
 > However, I would start by saying that the image is a snapshot of
the object world in memory that is effectively a live Pharo system.
It contains everything that is available and that exists in Pharo.
This includes any objects that you created yourself, windows,
browsers, open debuggers, executing processes, all meta objects as
well as all representations of code.
 >
 > 
 > The fact that there is a sources and changes file is an
implementation artefact, not something fundamental. There are ideas
to change this in the future (but you do not have to mention that).
 > 
 >
 > Also, the VM not only executes code, it maintains the object
world, which includes the ability to load and save it from and to an
image. It creates a portable (cross platform) abstraction that
isolates the image from the particular details of the underlying
hardware and OS. In that role it implements the interface with the
outside world. I would mention that second part before mentioning
the code execution.
 >
 > The sentence "The purpose of the VM is to take Pharo bytcode that
is generated each time user accepts a piece of code and convert it
to machine code in order to be executed." is not 100% correct. It is
possible to execute the byte code without converting it. This is
called interpretation. JIT is a faster technique that includes
converting (some often used) byte code to machine code and caching that.
 >
 > I hope this helps (it is hard to write a 'definitive explanation'
as there are some many aspects to this and it depends on the

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

"The *virtual machine* (VM) provides the environment where the Pharo system
lives. It is different for each operating system and hardware architecture,
and runs as a machine language executable in the operating system. It
implements the details of managing memory, executing Pharo byte-code, and
communicating with the world outside of the Pharo system: files, other
operating system process, and the network."

No the environment is the image, the VM is basically what its names says, a
machine emulated by software. The vast majority of tools, even the language
itself reside on the image. VM is there in order for the code to be able to
execute and to interface with the underlying Operating System. You could
completely modify the VM , for example move it to the JVM and still the
pharo enviroment would be intact.

"Hi Dimitris,
your formulation "...Pharo bytcode...and convert it to machine code..."
is insofar irritating to me as "convert it to machine code" would
suggest to me that a compiler is at work here. Davids "executing Pharo
byte-code" seems more understandable to me here."

Thats correct its a compiler, a byte compiler, it compiles bytecode to
machine code and it does it while the code executes, this is why its called
JIT , which has the meaning of Just In Time compilation, meaning that
machine code is compiled just before the code is executed so several
optimizations can be applied that would not be known before the execution
of the code. Similar to JAVA's JIT compiler.

Note here that a compiler is not just something that produces machine code,
a compiler for example can take one language and compile it to another
language.

On Wed, Jan 13, 2016 at 4:58 PM Werner Kassens  wrote:

> Hi Dimitris,
> your formulation "...Pharo bytcode...and convert it to machine code..."
> is insofar irritating to me as "convert it to machine code" would
> suggest to me that a compiler is at work here. Davids "executing Pharo
> byte-code" seems more understandable to me here.
> werner
>
> On 01/13/2016 02:22 PM, Dimitris Chloupis wrote:
> > I assume you have never read a an introduction to C++ then :D
> >
> > here is the final addition for the vm
> >
> > (Vm) is the only component that is different for each operating system.
> > The main purpose of the VM is to take Pharo bytcode that is generated
> > each time user accepts a piece of code and convert it to machine code in
> > order to be executed, but also to generally handle low level
> > functionality like interpreting code, handling OS events (mouse and
> > keyboard), calling C libraries etc. Pharo 4 comes with the Cog VM a very
> > fast JIT VM.
> >
> > I think its clear, precise and does not leave much room for confusion.
> > Personally I think its very important for the absolute begineer to have
> > strong foundations of understanding the fundamental of Pharo and not for
> > things to appear magical and "dont touch this".
> >
> > On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe  > > wrote:
> >
> >
> >  > On 13 Jan 2016, at 13:42, Dimitris Chloupis
> > > wrote:
> >  >
> >  > I mentioned bytecode because I dont want the user to see at some
> > point bytecode and say "What the hell is that" I want the reader to
> > feel confident that at least understands the basic in Pharo. Also
> > very brief explanations about bytecode I have seen in similar python
> > tutorials. Obviously I dont want to go any deeper than that because
> > the user wont have to worry about the technical details on a daily
> > basis anyway.
> >  >
> >  > I agree that I could add a bit more on the VM description similar
> > to what you posted. I am curious though, wont even the interpreter
> > generate machine code in order to execute the code  or does it use
> > existing machine code inside the VM binary ?
> >
> > No, a classic interpreter does not 'generate' machine code, it is
> > just a program that reads and executes bytes codes in a loop, the
> > interpreter 'is' machine code.
> >
> > No offence, but you see why I think it is important to not try to
> > use or explain too much complex concepts in the 1st chapter.
> >
> > Learning to program is hard. It should first be done abstractly.
> > Think about Scratch. The whole idea of Smalltalk is to create a
> > world of interacting objects. (Even byte code is not a necessary
> > concept at all, for example, in Pharo, you can compile (translate)
> > to AST and execute that, I believe. There are Smalltalk
> > implementations that compile directly to C or JavaScript). Hell,
> > even 'compile' is not necessary, just 'accept'. See ?
> >
> >  > On Wed, Jan 13, 2016 at 2:25 PM Sven Van Caekenberghe
> > > wrote:
> >  > Sounds about right.
> >  >
> >  > Now, I would swap 1 and 4, as 

Re: [Pharo-users] Understanding the role of the sources file

[Ben Coman]

Oh! I should have guessed there'd be more alternative suggestions and held back.
Anyway, its done now, so just pick out what you like...
Now I tend to think of the Image as more than just the .image file, so...

The heart of Pharo is the *Image*.  This holds the live running state
of a Pharo system. Tools like the IDE, language parser and interactive
playground run *inside* the Image to write code and create interacting
objects which comprise your application.  Saving the Image to a
".image" file creates a frozen-in-time snapshot of the running system
state. This can be moved to another system and resumed running as if
the Image had never stopped.  The Pharo download provides
/Pharo.image/ file as the starting point for the live environment that
you adapt to your needs.

The Image runs on a Virtual Machine.  This abstracts away operating
system and CPU architecture differences to allow the same ".image"
file (the snapshot of you live system) to open and run on any support
platform. The VM executable file is a different for each platform:
* pharo for Linux and Unix
* Pharo.exe for Windows
* Pharo for OSX

Your source-code is compiled to byte-code in Image to become part of
the live system state.  This occurs as soon as a modified method is
accepted.  Only the modified method is compiled, not the whole source
code, and the bytecode is immediately runnable.  This facilitates a
very fast edit-compile-run-debug loop at the root of Pharo's
productivity.   The VM optimally interprets or just-in-time compiles
the bytecode as appropriate for best performance.

As an implementation detail carried over from when ram was scarce, the
source-code is not stored in-Image.  It is spread across two files:

* Sources for parts of Pharo (i.e. the tools) that don’t change
frequently are stored in the "*.sources" files.   It is generated as a
static file per major release. Thus for  Pharo 4.0 it is named
PharoV40.sources, and keeps that name when the image file name
changes.   The *.sources file is not essential for running the Image,
but is important because without it, you can't examine and learn from
the implementation of Pharo's tools (e.g Collections, Graphics
libraries, IDE and compiler.)

* All source code changes are journal logged to the "*.changes" file.
This facilitates easy access to per method history for diffs or
reverting.  Further, if you close or crash your image without saving,
an in-Image tool can replay your "lost" changes from this file. The
"*.changes" file is tightly coupled to the "*.image" file because it
records the source code changes for a particular Image.  The basename
of these two files must always be the same (e.g. my.image &
my.changes).  Each release provides a near empty file, for example
Pharo4.changes to match Pharo4.image.

Typically the VM and .sources files are distributed/stored together,
since both are static files (per machine per Pharo Release) and both
can be shared between multiple Images; and the dynamic .image and
.changes files are distributed/stored together.




> The other components below are portable across operating systems, and


The image file provides a frozen in time snapshot of a running Pharo
> system. This is the file where the Pharo bytecode is stored and as such its
> a cross platform format. This is the heart of Pharo, containing the live
> state of all objects in the system (including classes and methods, since
> they are objects too). The file is named for the release (like
> Pharo4.0.image).
>



On Wed, Jan 13, 2016 at 7:58 PM, Dimitris Chloupis
 wrote:
> So I am correct that the image does not store the source code, and that the
> source code is stored in sources and changes. The only diffirence is that
> the objects have a source variable that points to the right place for
> finding the source code.
>
> This is the final text if you find anything incorrect please correct me
>
> ---
>
> 1. The virtual machine (VM) is the only component that is different for each
> operating system. The purpose of the VM is to take Pharo bytcode that is
> generated each time user accepts a piece of code and convert it to machine
> code in order to be executed. Pharo 4 comes with the Cog VM a very fast JIT
> VM. The VM executable is named:
>
> • Pharo.exe for Windows; • pharo for Linux ; and
>
> • Pharo for OSX (inside a package also named Pharo.app).
> The other components below are portable across operating systems, and
>
> can be copied and run on any appropriate virtual machine.
>
> 2. The sources file contains source code for parts of Pharo that don’t
> change frequently. Sources file is important because the image file format
> stores only the bytecode of live objects and not their source code.
> Typically a new sources file is generated once per major release of Pharo.
> For Pharo 4.0, this file is named PharoV40.sources.
>
> 3. The changes file logs of all source code modifications since the .sources
> file was generated. This 

Re: [Pharo-users] Understanding the role of the sources file

[David Allouche]

> On 13 Jan 2016, at 16:27, Dimitris Chloupis  wrote:
> 
> "The virtual machine (VM) provides the environment where the Pharo system 
> lives. It is different for each operating system and hardware architecture, 
> and runs as a machine language executable in the operating system. It 
> implements the details of managing memory, executing Pharo byte-code, and 
> communicating with the world outside of the Pharo system: files, other 
> operating system process, and the network."
> 
> No the environment is the image, the VM is basically what its names says, a 
> machine emulated by software. The vast majority of tools, even the language 
> itself reside on the image. VM is there in order for the code to be able to 
> execute and to interface with the underlying Operating System. You could 
> completely modify the VM , for example move it to the JVM and still the pharo 
> enviroment would be intact. 

That is indeed the idea I tried to convey by "where the Pharo system lives", 
but I see how that can be misunderstood. However, I try to avoid using "big 
words" like "abstraction".

How about this?

"The virtual machine (VM) provides the portable environment to execute Pharo 
images. Its implementation needs to be different for each operating system and 
hardware architecture, as it runs as a machine language executable in the 
operating system. It implements the details of managing memory, executing Pharo 
byte-code, and communicating with the world outside of the Pharo system: files, 
other operating system process, and the network. 


> "Hi Dimitris,
> your formulation "...Pharo bytcode...and convert it to machine code..."
> is insofar irritating to me as "convert it to machine code" would
> suggest to me that a compiler is at work here. Davids "executing Pharo
> byte-code" seems more understandable to me here."
> 
> Thats correct its a compiler, a byte compiler, it compiles bytecode to 
> machine code and it does it while the code executes, this is why its called 
> JIT , which has the meaning of Just In Time compilation, meaning that machine 
> code is compiled just before the code is executed so several optimizations 
> can be applied that would not be known before the execution of the code. 
> Similar to JAVA's JIT compiler. 
> 
> Note here that a compiler is not just something that produces machine code, a 
> compiler for example can take one language and compile it to another 
> language. 

That's technically true. But most readers will probably unconsciously assume 
that a compiler is something that produces machine language. The document 
should be careful to avoid misunderstandings caused by such common assumptions.

As for the JIT, that is totally an implementation detail, and I believe it is 
only worth mentioning if you want to prevent the reader from assuming that 
Pharo is slow because its VM executes byte-code. But nowadays, JIT compiling 
byte-code to machine language are the norm rather than the exception, so I do 
not think it is worth mentioning.


> 
> On Wed, Jan 13, 2016 at 4:58 PM Werner Kassens  > wrote:
> Hi Dimitris,
> your formulation "...Pharo bytcode...and convert it to machine code..."
> is insofar irritating to me as "convert it to machine code" would
> suggest to me that a compiler is at work here. Davids "executing Pharo
> byte-code" seems more understandable to me here.
> werner
> 
> On 01/13/2016 02:22 PM, Dimitris Chloupis wrote:
> > I assume you have never read a an introduction to C++ then :D
> >
> > here is the final addition for the vm
> >
> > (Vm) is the only component that is different for each operating system.
> > The main purpose of the VM is to take Pharo bytcode that is generated
> > each time user accepts a piece of code and convert it to machine code in
> > order to be executed, but also to generally handle low level
> > functionality like interpreting code, handling OS events (mouse and
> > keyboard), calling C libraries etc. Pharo 4 comes with the Cog VM a very
> > fast JIT VM.
> >
> > I think its clear, precise and does not leave much room for confusion.
> > Personally I think its very important for the absolute begineer to have
> > strong foundations of understanding the fundamental of Pharo and not for
> > things to appear magical and "dont touch this".
> >
> > On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe  > 
> > >> wrote:
> >
> >
> >  > On 13 Jan 2016, at 13:42, Dimitris Chloupis
> >  
> > >> wrote:
> >  >
> >  > I mentioned bytecode because I dont want the user to see at some
> > point bytecode and say "What the hell is that" I want the reader to
> > feel confident that at least understands the basic in Pharo. Also
> > very brief explanations about 

Re: [Pharo-users] I am David Allouche, let me introduce myself.

[Serge Stinckwich]

Welcome in the community David !

Where are you located ?

Regards,

On Sun, Jan 10, 2016 at 10:37 PM, David Allouche  wrote:
> Hello folks.
>
> Some people have already seen me on Twitter and Slack, but I believe there
> might be some people on the mailing list that did not see those
> conversations.
>
> As I have done on Slack, I am writing this introduction so people have an
> idea where I come from and what is my business with Pharo.
>
> I am a professional programmer. My current job is tech on a small company I
> run with two associates (by the way, we are hiring a good Python web dev
> with a passion for good code). The product is a SaaS web application for
> recruiters. They call that an Application Tracking System, it is a workflow,
> communication and archival system for job applications and candidates.
>
> I started programming 25 years ago with HyperCard, and since I have at least
> played with Pascal, C, Prograph, asm68k, HP-48 (RPL, Saturn asm), Java,
> bash, C++, LaTeX, XSLT, Delphi, Scheme, elisp, JavaScript.
>
> I have contributed to GNU TeXmacs where I made important contributinos
> during about 2 years, as I completed by training as an software engineer,
> and worked at CNRS in Rennes. Then I got involved in GNU Arch (wrote a
> Python driver), Bazaar (bzr scm) where I worked with the founding team at
> Canonical while working on the version control aspect of launchpad.net.
> After that, I had mostly no contribution to free software, working on
> financial modeling at a bank and then on my current business. I made a
> presentation on SQLAlchemy at PyCon.fr 2015.
>
> I am a fan Design Patterns (GoF) and the Refactoring book. My mentor at
> Canonical (Robert Collins) is heavily influenced by Smalltalk and championed
> XP there. I always had strong interests in software systems design,
> programming language design, typography, and user interface design. I feel
> strongly for the concept of software craftsmanship.
>
> My current job is nice, good pay, lots of independence ; after 6 years
> working on the same project, I need some fresh intellectual stimulation. And
> I was recently impressed by the presentation "Nothing is Something", by
> Sandi Metz, who is heavily influenced by Smalltalk.
>
> http://confreaks.tv/videos/bathruby2015-nothing-is-something
>
> So, I here I came, bumbling my way around the system, looking for
> intellectual stimulation, and for a way to make a positive contribution.
>
> I was very impressed by the nice welcome I have received. And I see there is
> lots of useful work to do here.
>
> So that's where I come from when you see me chipping in the conversation
> here.
>
> Regards.



-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

It does not make as big difference as you think it does. First of all VM is
an executable binary so its already in machine code format or else it would
not run. The difference between the interpreter is that with the
interpreter you already execute machine code without any need to generate
it while JIT generates optimized machine code depending on the usage and
case so it runs much faster than the machine code used by the interpreter
.

The bottom line is the same, machine code execution in both cases. Also
from the link you provided its clear that the only way that codel wont be
compiled to machine code is code that rarely used, code that you execute
once and you forget about which you would not need to run fast anyway.  In
that case yes, the interpreter will be used. However there a ton of code
that needs to run in a reparation of some sort  , whether is drawing the
GUI, examining an even, parsing a file , in most cases you will be using
some kind of loop and in that case JIT will come to compile to machine code
and you will see a very significant boost in speed depending on the case.

But all that are implementations details which I dont want people to deal
with, I only want the reader to have a very general idea what the VM and
why Pharo needs it, I dont care about the specifics.

On Wed, Jan 13, 2016 at 6:26 PM Ben Coman  wrote:

> > On Wed, Jan 13, 2016 at 4:58 PM Werner Kassens 
> wrote:
> >>
> >> Hi Dimitris,
> >> your formulation "...Pharo bytcode...and convert it to machine code..."
> >> is insofar irritating to me as "convert it to machine code" would
> >> suggest to me that a compiler is at work here. Davids "executing Pharo
> >> byte-code" seems more understandable to me here.
>
> On Wed, Jan 13, 2016 at 11:27 PM, Dimitris Chloupis
>  wrote:
> > Thats correct its a compiler, a byte compiler, it compiles bytecode to
> > machine code and it does it while the code executes, this is why its
> called
> > JIT , which has the meaning of Just In Time compilation, meaning that
> > machine code is compiled just before the code is executed so several
> > optimizations can be applied that would not be known before the
> execution of
> > the code. Similar to JAVA's JIT compiler.
> >
> > Note here that a compiler is not just something that produces machine
> code,
> > a compiler for example can take one language and compile it to another
> > language.
>
> Indeed.  The OpalCompiler takes Smalltalk and produces bytecode.
>
> However I think Sven and Werner were referring that much of Pharo code
> is not JITd, but *merely* interpreted (IIUC).  See section "Not so
> smart questions" here...
>
> https://clementbera.wordpress.com/2014/01/09/the-sista-chronicles-i-an-introduction-to-adaptive-recompilation/
>
> cheers -ben
>
> >>
> >> On 01/13/2016 02:22 PM, Dimitris Chloupis wrote:
> >> > I assume you have never read a an introduction to C++ then :D
> >> >
> >> > here is the final addition for the vm
> >> >
> >> > (Vm) is the only component that is different for each operating
> system.
> >> > The main purpose of the VM is to take Pharo bytcode that is generated
> >> > each time user accepts a piece of code and convert it to machine code
> in
> >> > order to be executed, but also to generally handle low level
> >> > functionality like interpreting code, handling OS events (mouse and
> >> > keyboard), calling C libraries etc. Pharo 4 comes with the Cog VM a
> very
> >> > fast JIT VM.
> >> >
> >> > I think its clear, precise and does not leave much room for confusion.
> >> > Personally I think its very important for the absolute begineer to
> have
> >> > strong foundations of understanding the fundamental of Pharo and not
> for
> >> > things to appear magical and "dont touch this".
> >> >
> >> > On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe  >> > > wrote:
> >> >
> >> >
> >> >  > On 13 Jan 2016, at 13:42, Dimitris Chloupis
> >> > > wrote:
> >> >  >
> >> >  > I mentioned bytecode because I dont want the user to see at
> some
> >> > point bytecode and say "What the hell is that" I want the reader
> to
> >> > feel confident that at least understands the basic in Pharo. Also
> >> > very brief explanations about bytecode I have seen in similar
> python
> >> > tutorials. Obviously I dont want to go any deeper than that
> because
> >> > the user wont have to worry about the technical details on a daily
> >> > basis anyway.
> >> >  >
> >> >  > I agree that I could add a bit more on the VM description
> similar
> >> > to what you posted. I am curious though, wont even the interpreter
> >> > generate machine code in order to execute the code  or does it use
> >> > existing machine code inside the VM binary ?
> >> >
> >> > No, a classic interpreter does not 'generate' machine code, it is
> >> > just 

Re: [Pharo-users] Understanding the role of the sources file

[Dimitris Chloupis]

Why the Cog VM is mentioned in my documentation is no accident. There is
another VM that is called Stackless VM or old VM that was the VM before Cog
that had no JIT and its a VM we still use for platforms that Cog VM does
not currently run like Raspberry Pi, Android and I think iOS too.


"But nowadays, JIT compiling byte-code to machine language are the norm
rather than the exception, so I do not think it is worth mentioning."

Definitely not the norm Python and Ruby VMs are not JIT, generally speaking
JIT compilers are rare for Dynamic languages like Pharo. Python has PyPy
which is a JIT VM but is nowhere as popular as Cpython.

CPython people try to avoid JIT because it makes VM architecture much more
complex. At least thats their argument.

Another big advantage of Pharo is that it has luxury to come with a JIT
included and well tested.

The only popular JITs out there are Java's and .NET, dont know if
Javascript V8 use JIT as well, but thats pretty much it. But bytecode is
very popular indeed.
On Wed, Jan 13, 2016 at 6:43 PM David Allouche  wrote:

> On 13 Jan 2016, at 16:27, Dimitris Chloupis  wrote:
>
> "The *virtual machine* (VM) provides the environment where the Pharo
> system lives. It is different for each operating system and hardware
> architecture, and runs as a machine language executable in the operating
> system. It implements the details of managing memory, executing Pharo
> byte-code, and communicating with the world outside of the Pharo system:
> files, other operating system process, and the network."
>
> No the environment is the image, the VM is basically what its names says,
> a machine emulated by software. The vast majority of tools, even the
> language itself reside on the image. VM is there in order for the code to
> be able to execute and to interface with the underlying Operating System.
> You could completely modify the VM , for example move it to the JVM and
> still the pharo enviroment would be intact.
>
>
> That is indeed the idea I tried to convey by "where the Pharo system
> lives", but I see how that can be misunderstood. However, I try to avoid
> using "big words" like "abstraction".
>
> How about this?
>
> "The virtual machine (VM) provides the portable environment to execute
> Pharo images. Its implementation needs to be different for each operating
> system and hardware architecture, as it runs as a machine language
> executable in the operating system. It implements the details of managing
> memory, executing Pharo byte-code, and communicating with the world outside
> of the Pharo system: files, other operating system process, and the
> network.
>
>
> "Hi Dimitris,
> your formulation "...Pharo bytcode...and convert it to machine code..."
> is insofar irritating to me as "convert it to machine code" would
> suggest to me that a compiler is at work here. Davids "executing Pharo
> byte-code" seems more understandable to me here."
>
> Thats correct its a compiler, a byte compiler, it compiles bytecode to
> machine code and it does it while the code executes, this is why its called
> JIT , which has the meaning of Just In Time compilation, meaning that
> machine code is compiled just before the code is executed so several
> optimizations can be applied that would not be known before the execution
> of the code. Similar to JAVA's JIT compiler.
>
> Note here that a compiler is not just something that produces machine
> code, a compiler for example can take one language and compile it to
> another language.
>
>
> That's technically true. But most readers will probably unconsciously
> assume that a compiler is something that produces machine language. The
> document should be careful to avoid misunderstandings caused by such common
> assumptions.
>
> As for the JIT, that is totally an implementation detail, and I believe it
> is only worth mentioning if you want to prevent the reader from assuming
> that Pharo is slow because its VM executes byte-code. But nowadays, JIT
> compiling byte-code to machine language are the norm rather than the
> exception, so I do not think it is worth mentioning.
>
>
>
> On Wed, Jan 13, 2016 at 4:58 PM Werner Kassens 
> wrote:
>
>> Hi Dimitris,
>> your formulation "...Pharo bytcode...and convert it to machine code..."
>> is insofar irritating to me as "convert it to machine code" would
>> suggest to me that a compiler is at work here. Davids "executing Pharo
>> byte-code" seems more understandable to me here.
>> werner
>>
>> On 01/13/2016 02:22 PM, Dimitris Chloupis wrote:
>> > I assume you have never read a an introduction to C++ then :D
>> >
>> > here is the final addition for the vm
>> >
>> > (Vm) is the only component that is different for each operating system.
>> > The main purpose of the VM is to take Pharo bytcode that is generated
>> > each time user accepts a piece of code and convert it to machine code in
>> > order to be executed, but also to generally handle low 

Re: [Pharo-users] I am David Allouche, let me introduce myself.

[David Allouche]

Thank you everyone for the kind responses. I will answer some of the questions 
and suggestions here.

> To get faster to the intellectual stimulation, pick a task / project and 
> start asking questions. And have fun :).

That is good advice, but right now I think I will just explore the system, 
review changes, and wait for the tasks to find me. There are already more 
things I want to do than I will probably every be able to accomplish :-)

> I think when people referring to Smalltalk refer to Smalltalk as the language 
> or OOP itself, but thats only the tip of the iceberg, Pharo tries to stay 
> true to vision of smalltalk creating the virtual enviroment where the user 
> can easily create his or her own tools or modifying the existing ones, 
> something that I feel no other language out there can emulate because they 
> follow a non monolithic approach where there is a deep dichotomy between 
> language, libraries and the environment itself. You could say that Smalltalk 
> is the anti-Unix architecture , a great example of monolithic design that 
> works great in practice yet its easy to modify and extend. 

The  fact Smalltalk the language cannot be taken in isolation from Smalltalk 
the environment became clear rather early on: reading the UPBE and other 
materials shows that the language itself does almost nothing: it cannot even 
define classes or packages. It is all part of the environment.

I have seen someone in another thread expressing the desire for namespaces. As 
a newcomer, I also feel that is something important and missing. But since one 
of the goals of Pharo is to produce an environment that can be understood by a 
single person, the lack of namespace might actually be a feature. Namespace are 
essential for languages like C++, designed for large projects, produced by 
large teams, where nobody understands the whole system. They embody an 
industrial approach to programming. In contrast, I have the impression that 
Smalltalk emphasises regularity to minimise system size, rather than modularity 
to manage system size, and that it embodies a craftsmanship approach.

Since I am just old enough to remember a time where computer systems could be 
understood by a single person, I find it an attractive idea to try and produce 
a modern system with that property.

> I can't remember who famous said something like "The only languages
> worth learning are the ones that changes the way you think about
> programming..."  and I found that with Smalltalk & Pharo.

I am familiar with that idea too. And most good languages provide that.

 One day I will have learn some language from the ML family. I choose Smalltalk 
because it clearly had such a strong influence on the thinking of people who 
have used it, I thought I could learn

> A good way to get your hands dirty is to review fixes submitted by others...
> https://pharo.fogbugz.com/default.asp?pgx=LF=45 
> 
> There are never enough hands there :)  (my own action here fluctuates
> from time to time)

I will try to spend some time reviewing code. That is a good way to get exposed 
to things one does not even know they exist.

> Did you look at Seaside?
> Since you should be able to read french there is  a nice tutorial: tinyBlog. 
> In two days you can build a small web app
> with a mongo back end. 

I have no looked at Seaside yet, I have not even read the corresponding chapter 
in UPBE. But I certainly will, eventually. The web is an essential part of 
society today.

> Where are you located ?

Paris, France.

It did occur to me that the Pharo community does have a unusually large 
fraction of french people. But that is not a factor for me.

Thanks again for all the kind words. I am sure this journey is going to be a 
lot of fun. :-)

Re: [Pharo-users] Failling Tests are green if BlockCannotReturn exception

[abdelghani ALIDRA]

Thank you all for your responses.
I see your point about returning from a block. Because the return in this 
example is very explicit. But what if I put (by mistake) a return in a block in 
a method that is called by the test method (or even in a method that is called 
by another method that is called by the test method) then I would have no 
reason to doubt my test was successful whereas it would have failed if it was 
run till the last assertion.
My point is, would it not be interesting to report tests that were not run 
successfully till the end?
Abdelghani 

  De : Sven Van Caekenberghe 
 À : abdelghani ALIDRA ; Any question about pharo is 
welcome  
 Envoyé le : Mardi 12 janvier 2016 7h35
 Objet : Re: [Pharo-users] Failling Tests are green if BlockCannotReturn 
exception
  



> On 12 Jan 2016, at 00:26, abdelghani ALIDRA  wrote:
> 
> Hi,
> 
> I observed this unexpected behavior in test classes.
> In a test class define a method :
> 
> testBlock
>    |aBlock|
>    aBlock := [ ^1 ].
>    aBlock value.
>    self assert: false.
> 
> Althought the assertion is false at the end of the test, the test is green.
> Actually, It does not matter what you put after aBlock value, the test always 
> succedes (I tried to put a self halt, it does not execute)

The test is 'does an explicit return from a block return from the whole 
method'. Of course it does. But if it would not, you would arrive at the self 
assert: false and the test would fail. You see ?

BTW, this can also be written as self fail - search for the senders of that 
message for more examples.

> I tried this both in Pharo 4 and 5 under Windows and MacOS.
> 
> Any ideas?
> 
> Cheers 
> Abdelghani
> 
> 


  

Re: [Pharo-users] Understanding the role of the sources file

[David Allouche]

> On 13 Jan 2016, at 18:14, Dimitris Chloupis  wrote:
> 
> Why the Cog VM is mentioned in my documentation is no accident. There is 
> another VM that is called Stackless VM or old VM that was the VM before Cog 
> that had no JIT and its a VM we still use for platforms that Cog VM does not 
> currently run like Raspberry Pi, Android and I think iOS too. 
> 
> 
> "But nowadays, JIT compiling byte-code to machine language are the norm 
> rather than the exception, so I do not think it is worth mentioning."
> 
> Definitely not the norm Python and Ruby VMs are not JIT, generally speaking 
> JIT compilers are rare for Dynamic languages like Pharo. Python has PyPy 
> which is a JIT VM but is nowhere as popular as Cpython. 

You are right. The JIT is worth mentioning there.

> 
> CPython people try to avoid JIT because it makes VM architecture much more 
> complex. At least thats their argument. 

I am getting off-topic, but since I have already written what follows, and I 
think it is informative, I am leaving it there :-)

Python is a rather large language, with a large number of quirks that need to 
be preserved to provide full compatibility. It is also a language with advanced 
introspection, and very dynamic semantics, even more than Smalltalk in some 
aspects. And its main implementation (CPython) has very highly optimised data 
structures and memory management.

That makes it really difficult to implement correctly and and to improve 
performance without slowing down other parts. Before PyPy, Google funded the 
Unladen Swallow project, that tried to produce a Python JIT using LLVM, this 
project was abandoned. Even PyPy needs to make frequent and expensive guard 
tests to ensure that invariants required for JIT are preserved. It does bring a 
significant speed boost (2x-10x), but at the expense of slow startup and 
increased memory footprint (~2x).

However, it seems clear that the long term future of Python lies in PyPy. In 
particular, they have high hopes to solve the lack of multicore support by 
implementing software transactional memory in the medium term, until hardware 
transactional memory is advanced enough to be usable there.

> Another big advantage of Pharo is that it has luxury to come with a JIT 
> included and well tested. 

I guess the simplicity of the language makes it relatively easy to produce a 
JIT. This is indeed a very good thing.

> 
> The only popular JITs out there are Java's and .NET, dont know if Javascript 
> V8 use JIT as well, but thats pretty much it. But bytecode is very popular 
> indeed. 

V8 does use JIT. I believe it was the first widely deployed language 
implementation to use a tracing interpreter to JIT a language with latent 
typing. I believe all the other major Javascript implementations have followed 
suite.

This is also the approach used by PyPy. Java and .Net have static typing, so 
they do not require a tracing interpreter to compile to machine code.

> On Wed, Jan 13, 2016 at 6:43 PM David Allouche  > wrote:
>> On 13 Jan 2016, at 16:27, Dimitris Chloupis > > wrote:
>> 
>> "The virtual machine (VM) provides the environment where the Pharo system 
>> lives. It is different for each operating system and hardware architecture, 
>> and runs as a machine language executable in the operating system. It 
>> implements the details of managing memory, executing Pharo byte-code, and 
>> communicating with the world outside of the Pharo system: files, other 
>> operating system process, and the network."
>> 
>> No the environment is the image, the VM is basically what its names says, a 
>> machine emulated by software. The vast majority of tools, even the language 
>> itself reside on the image. VM is there in order for the code to be able to 
>> execute and to interface with the underlying Operating System. You could 
>> completely modify the VM , for example move it to the JVM and still the 
>> pharo enviroment would be intact. 
> 
> That is indeed the idea I tried to convey by "where the Pharo system lives", 
> but I see how that can be misunderstood. However, I try to avoid using "big 
> words" like "abstraction".
> 
> How about this?
> 
> "The virtual machine (VM) provides the portable environment to execute Pharo 
> images. Its implementation needs to be different for each operating system 
> and hardware architecture, as it runs as a machine language executable in the 
> operating system. It implements the details of managing memory, executing 
> Pharo byte-code, and communicating with the world outside of the Pharo 
> system: files, other operating system process, and the network. 
> 
> 
>> "Hi Dimitris,
>> your formulation "...Pharo bytcode...and convert it to machine code..."
>> is insofar irritating to me as "convert it to machine code" would
>> suggest to me that a compiler is at work here. Davids "executing Pharo
>> byte-code"