[Pharo-project] pharo VM names
We should really decide on this: https://code.google.com/p/pharo/issues/detail?id=7423 I guess that would simplify the choice for newcomers significantly!
Hi, 1) CI builds names is not the same than app names. 2) The "official" pharo vm (the NB Cog JIT), should be named just "Pharo", because that is what users will see in his dock bar. 3) The stack VM is not a debug vm is just a VM who uses a stack-to-register approach. I would call it PharoS or something that simple. 4) RizelVM is not a regularly distributed VM, so it should not be in pharo, but in pharo-contribution 5) PLEASE, STOP MARKING ISSUES THAT CAN WAIT AS 2.0!!!! We are just 2 weeks of release. Stop adding new tasks. No matter if you think is important. Unless it will block us to release, IT IS NOT. Thanks, Esteban On Feb 5, 2013, at 4:08 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
We should really decide on this: https://code.google.com/p/pharo/issues/detail?id=7423
I guess that would simplify the choice for newcomers significantly!
On 2013-02-05, at 16:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
1) CI builds names is not the same than app names.
I am talking about the artifact names if that wasn't clear.
2) The "official" pharo vm (the NB Cog JIT), should be named just "Pharo", because that is what users will see in his dock bar. 3) The stack VM is not a debug vm is just a VM who uses a stack-to-register approach. I would call it PharoS or something that simple.
think about the user perspective? why would I even bother taking this VM? There is one that is fast, and another one that is what? less stable?
4) RizelVM is not a regularly distributed VM, so it should not be in pharo, but in pharo-contribution yes, definitely.
5) PLEASE, STOP MARKING ISSUES THAT CAN WAIT AS 2.0!!!! We are just 2 weeks of release. Stop adding new tasks. No matter if you think is important. Unless it will block us to release, IT IS NOT.
I associated this with Pharo2.0 ... I guess wrongly.. I provide fixes that can be included NOW => I have to mark them 2.0 otherwise nobody will ever ever look at it. => did you ever touch the monkey? You didn't, so unless that is fixed and it checks 3.0 tags as well, I can't help myself but putting it on 2.0
yeah, and translated to dirty spanish... well, I don't even want to think about :P On Feb 5, 2013, at 9:04 PM, Francisco Garau <francisco.garau@gmail.com> wrote:
On 5 Feb 2013, at 15:34, Camillo Bruni
=> did you ever touch the monkey?
Sorry for the basic question, but what (or who) is this monkey?
- Francisco
On 2013-02-05, at 21:04, Francisco Garau <francisco.garau@gmail.com> wrote:
On 5 Feb 2013, at 15:34, Camillo Bruni
=> did you ever touch the monkey?
Sorry for the basic question, but what (or who) is this monkey?
the monkey is our primate friend https://ci.inria.fr/pharo/job/Pharo-2.0-Issue-Tracker/ the checks and validates pending issues.
Camillo the stackVM can be important as a fallback So we can have Pharo and PharoS (as slow and stack) On Feb 5, 2013, at 4:34 PM, Camillo Bruni wrote:
On 2013-02-05, at 16:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
1) CI builds names is not the same than app names.
I am talking about the artifact names if that wasn't clear.
2) The "official" pharo vm (the NB Cog JIT), should be named just "Pharo", because that is what users will see in his dock bar. 3) The stack VM is not a debug vm is just a VM who uses a stack-to-register approach. I would call it PharoS or something that simple.
think about the user perspective? why would I even bother taking this VM? There is one that is fast, and another one that is what? less stable?
4) RizelVM is not a regularly distributed VM, so it should not be in pharo, but in pharo-contribution yes, definitely.
5) PLEASE, STOP MARKING ISSUES THAT CAN WAIT AS 2.0!!!! We are just 2 weeks of release. Stop adding new tasks. No matter if you think is important. Unless it will block us to release, IT IS NOT.
I associated this with Pharo2.0 ... I guess wrongly..
I provide fixes that can be included NOW => I have to mark them 2.0 otherwise nobody will ever ever look at it. => did you ever touch the monkey? You didn't, so unless that is fixed and it checks 3.0 tags as well, I can't help myself but putting it on 2.0
I there is going to be a suffix for the VM, I would name them PharoJIT and PharoStack. So both have suffixes, otherwise Pharo"S" sounds like it has something else the "clean" Pharo doesn't. Just my view on naming things. Regards, Esteban A. Maringolo 2013/2/5 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Camillo
the stackVM can be important as a fallback So we can have Pharo and PharoS (as slow and stack)
No, I disagree... expose as names elements of the architecture is a bad choice. bad marketing to choose ugly names, just for the sake of our techie guys (my self included :P) the unique official VM for pharo will be called Pharo, and it will be a Cog VM with our additions. we also will provide another supplementary VM (the StackVM, with a suffix, to accomplish 2 thins: make clear that is not the official, and provide information about why is there). It will be there because is more portable and more stable (for now, we hope to have same stability with the cog soon). We don't need two suffixes, just one, because the official vm is just one. Esteban On Tue, Feb 5, 2013 at 10:26 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
I there is going to be a suffix for the VM, I would name them PharoJIT and PharoStack. So both have suffixes, otherwise Pharo"S" sounds like it has something else the "clean" Pharo doesn't.
Just my view on naming things.
Regards,
Esteban A. Maringolo
2013/2/5 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Camillo
the stackVM can be important as a fallback So we can have Pharo and PharoS (as slow and stack)
Hello, RizelVM is a simple extension of StackVM. It has few more primitives than StackVM. This primitives aid us to counting the number of sent messages. The number of sent messages is related to the averages execution time over multiple executions. For more information about counting messages you can see this paper http://bergel.eu/download/papers/Berg11c-compteur.pdf RizelVM highly depend on stackVM, while stackVM does not work in the new jenkins infraestructure, RizelVM wont work either. Can someone check what is going on with StackVM? Regards, Juan Pablo 2013/2/5 Clément Bera <bera.clement@gmail.com>
2013/2/5 Denis Kudriashov <dionisiydk@gmail.com> 2013/2/5 Esteban Lorenzano <estebanlm@gmail.com>
RizelVM
What is RizelVM?
Correct me if I am wrong, but Rizel VM is a VM that permits to benchmark. It was done by a student and worked nicely but it is not maintained any more.
-- Saludos, Juan Pablo
On Tue, Feb 5, 2013 at 7:24 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
Hi,
1) CI builds names is not the same than app names. 2) The "official" pharo vm (the NB Cog JIT), should be named just "Pharo", because that is what users will see in his dock bar. 3) The stack VM is not a debug vm is just a VM who uses a stack-to-register approach. I would call it PharoS or something that simple.
No. The StackVM is a VM that optimizes interpreted execution by mapping contexts to stack frames and lazily instantiating contexts, but is still a pure interpreter. The Cog VM is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts, /and/ by compiling methods used more than once to machine-code and implementing a number of send optimization schemes in that machine-code. 4) RizelVM is not a regularly distributed VM, so it should not be in pharo,
but in pharo-contribution 5) PLEASE, STOP MARKING ISSUES THAT CAN WAIT AS 2.0!!!! We are just 2 weeks of release. Stop adding new tasks. No matter if you think is important. Unless it will block us to release, IT IS NOT.
Thanks, Esteban
On Feb 5, 2013, at 4:08 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
We should really decide on this: https://code.google.com/p/pharo/issues/detail?id=7423
I guess that would simplify the choice for newcomers significantly!
-- best, Eliot
On Feb 5, 2013, at 9:15 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
No. The StackVM is a VM that optimizes interpreted execution by mapping contexts to stack frames and lazily instantiating contexts, but is still a pure interpreter. The Cog VM is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts, /and/ by compiling methods used more than once to machine-code and implementing a number of send optimization schemes in that machine-code.
ok :)
On 05/02/13 21:15, Eliot Miranda wrote:
No. The StackVM is a VM that optimizes interpreted execution by mapping contexts to stack frames and lazily instantiating contexts, but is still a pure interpreter. The Cog VM is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts, /and/ by compiling methods used more than once to machine-code and implementing a number of send optimization schemes in that machine-code.
This could be added in the Jenkins job description!
doing that right now! On 2013-02-05, at 22:08, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
On 05/02/13 21:15, Eliot Miranda wrote:
No. The StackVM is a VM that optimizes interpreted execution by mapping contexts to stack frames and lazily instantiating contexts, but is still a pure interpreter. The Cog VM is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts, /and/ by compiling methods used more than once to machine-code and implementing a number of send optimization schemes in that machine-code.
This could be added in the Jenkins job description!
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/ On 2013-02-05, at 22:09, Camillo Bruni <camillobruni@gmail.com> wrote:
doing that right now!
On 2013-02-05, at 22:08, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
On 05/02/13 21:15, Eliot Miranda wrote:
No. The StackVM is a VM that optimizes interpreted execution by mapping contexts to stack frames and lazily instantiating contexts, but is still a pure interpreter. The Cog VM is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts, /and/ by compiling methods used more than once to machine-code and implementing a number of send optimization schemes in that machine-code.
This could be added in the Jenkins job description!
On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/
"The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code." => "The Pharo VM (also known as the Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code." please.
On 2013-02-05, at 22:09, Camillo Bruni <camillobruni@gmail.com> wrote:
doing that right now!
On 2013-02-05, at 22:08, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
On 05/02/13 21:15, Eliot Miranda wrote:
No. The StackVM is a VM that optimizes interpreted execution by
mapping
contexts to stack frames and lazily instantiating contexts, but is still a pure interpreter. The Cog VM is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts, /and/ by compiling methods used more than once to machine-code and implementing a number of send optimization schemes in that machine-code.
This could be added in the Jenkins job description!
-- best, Eliot
yes, it is not "formerly known", it is just a branding for cog vm. Esteban On Tue, Feb 5, 2013 at 10:15 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/
"The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code." => "The Pharo VM (also known as the Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code."
please.
On 2013-02-05, at 22:09, Camillo Bruni <camillobruni@gmail.com> wrote:
doing that right now!
On 2013-02-05, at 22:08, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
On 05/02/13 21:15, Eliot Miranda wrote:
No. The StackVM is a VM that optimizes interpreted execution by
mapping
contexts to stack frames and lazily instantiating contexts, but is still a pure interpreter. The Cog VM is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts, /and/ by compiling methods used more than once to machine-code and implementing a number of send optimization schemes in that machine-code.
This could be added in the Jenkins job description!
-- best, Eliot
On 2013-02-05, at 22:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/
"The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code." => "The Pharo VM (also known as the Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code."
nope it is NOT the cog VM, your branch doesn't have a set of changes we made, notably to the file plugins, furthermore we ship by default with the native boost plugin. so to be fully correct I have to say *former*.
On Tue, Feb 5, 2013 at 1:21 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2013-02-05, at 22:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni <camillobruni@gmail.com wrote:
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/
"The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code." => "The Pharo VM (also known as the Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code."
nope it is NOT the cog VM, your branch doesn't have a set of changes we made, notably to the file plugins, furthermore we ship by default with the native boost plugin.
so to be fully correct I have to say *former*.
No. Cog is an architecture, a JIT plus an Interpreter, not a specific VM. StackVM is an architecture. Interpreter VM is an architecture. You could clarify by saying "The Pharo VM (a derivative of the Cog VM) ..." or "The Pharo VM (a version of the Cog VM) ..." -- best, Eliot
On 5 February 2013 22:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Feb 5, 2013 at 1:21 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-02-05, at 22:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/
"The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code." => "The Pharo VM (also known as the Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code."
nope it is NOT the cog VM, your branch doesn't have a set of changes we made, notably to the file plugins, furthermore we ship by default with the native boost plugin.
so to be fully correct I have to say *former*.
No. Cog is an architecture, a JIT plus an Interpreter, not a specific VM. StackVM is an architecture. Interpreter VM is an architecture. You could clarify by saying
"The Pharo VM (a derivative of the Cog VM) ..."
or "The Pharo VM (a version of the Cog VM) ..."
i agree, "formely" is not good choice of word, granted that we are regularly merging with your code base and exchange improvements & fixes.
-- best, Eliot
-- Best regards, Igor Stasenko.
On Tue, Feb 5, 2013 at 2:24 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 5 February 2013 22:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Feb 5, 2013 at 1:21 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-02-05, at 22:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/
"The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code
and
implements a number of send optimization schemes in that machine-code." => "The Pharo VM (also known as the Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code."
nope it is NOT the cog VM, your branch doesn't have a set of changes we made, notably to the file plugins, furthermore we ship by default with the native boost plugin.
so to be fully correct I have to say *former*.
No. Cog is an architecture, a JIT plus an Interpreter, not a specific VM. StackVM is an architecture. Interpreter VM is an architecture. You could clarify by saying
"The Pharo VM (a derivative of the Cog VM) ..."
or "The Pharo VM (a version of the Cog VM) ..."
i agree, "formely" is not good choice of word, granted that we are regularly merging with your code base and exchange improvements & fixes.
thank you Igor. I agree. PharoVM is a version of Cog. I'm not claiming that Cog is the PharoVM, but the PharoVM is substantially, and architecturally, a Cog VM.
-- best, Eliot
-- Best regards, Igor Stasenko.
-- best, Eliot
On Tue, Feb 05, 2013 at 01:15:47PM -0800, Eliot Miranda wrote:
On Tue, Feb 5, 2013 at 1:12 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
done: https://ci.inria.fr/pharo/view/VM/job/StackVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM/
"The Pharo VM (former Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code." => "The Pharo VM (also known as the Cog VM) is a VM that optimizes execution by mapping contexts to stack frames and lazily instantiating contexts. It further jits/compiles methods used more than once to machine-code and implements a number of send optimization schemes in that machine-code."
please.
+1 Please be careful with words. Branding is a nice idea but the words matter and intellectual integrity is important. An artist in any medium will acknowledge his or her sources and inspirations. One who does not do this is no artist and no engineer. Dave
participants (12)
-
Camillo Bruni -
Clément Bera -
David T. Lewis -
Denis Kudriashov -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
Francisco Garau -
Francois Stephany -
Igor Stasenko -
Juan Pablo Sandoval Alcocer -
Stéphane Ducasse