Re: [Pharo-dev] [squeak-dev] Squeak and Tonel
Hi All, Hi Torsten, Hi Jakob, On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote:
Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code. This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors. I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance". So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista. I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI. Here's the kind of crap people like Ducasse throw at me: "Eliot At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. " I am so over this crap. _,,,^..^,,,_ best, Eliot
Hi eliot What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list. And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version. If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely. About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ,
This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves.
and considering leaving VMMaker altogether.
If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation. I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us.
The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap.
This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints. I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle). Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people. I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time. PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure. Stef
_,,,^..^,,,_ best, Eliot
BTW Eliot, I just discovered by accident emails you sent me last week there are full on insults . I will not forward them in this mailing-list because it does not help. This is not the first that you do that to me. The first time I went over them and supported Clément to work with you. Now I will not consider your mails anymore. Sorry but you cannot talk publicly about collaboration and privately insult people that way. Now if you believe that I do pharo about ego then you do not understand anything :) And I will not try to convince you otherwise. This is my last email sent to you. Stef
On 17 Feb 2019, at 21:59, ducasse <stepharo@netcourrier.com> wrote:
Hi eliot
What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list.
And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version.
If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely.
About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ,
This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves.
and considering leaving VMMaker altogether.
If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation.
I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us.
The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap.
This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints.
I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle).
Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people.
I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time.
PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure.
Stef
_,,,^..^,,,_ best, Eliot
On Sun, Feb 17, 2019 at 1:22 PM ducasse <stepharo@netcourrier.com> wrote:
BTW Eliot, I just discovered by accident emails you sent me last week there are full on insults . I will not forward them in this mailing-list because it does not help. This is not the first that you do that to me. The first time I went over them and supported Clément to work with you. Now I will not consider your mails anymore.
Sorry but you cannot talk publicly about collaboration and privately insult people that way.
Now if you believe that I do pharo about ego then you do not understand anything :) And I will not try to convince you otherwise. This is my last email sent to you.
Thank god for that.
Stef
On 17 Feb 2019, at 21:59, ducasse <stepharo@netcourrier.com> wrote:
Hi eliot
What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list.
And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version.
If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely.
About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ,
This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves.
and considering leaving VMMaker altogether.
If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation.
I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us.
The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap.
This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints.
I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle).
Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people.
I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time.
PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure.
Stef
_,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
On Sun, Feb 17, 2019 at 1:00 PM ducasse <stepharo@netcourrier.com> wrote:
Hi eliot
What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list.
What is common is that I discuss technical matters (difficulties in using Tonel/git, architectural issues with developing the VM) and organizational issues (Estebans' unhelpful response regarding an option in Tonel) and you immediately personalize, do not bring up a single technical issue, and then make grand pronouncements like :this is the last email I'll send you". Laughable and sad.
And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version.
If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely.
About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ,
This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves.
and considering leaving VMMaker altogether.
If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation.
I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us.
The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap.
This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints.
I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle).
Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people.
I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time.
PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure.
Stef
_,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Eliot Contrary to you I do not wish your death. So can you respect me? Stef
On 17 Feb 2019, at 22:30, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Sun, Feb 17, 2019 at 1:00 PM ducasse <stepharo@netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: Hi eliot
What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list.
What is common is that I discuss technical matters (difficulties in using Tonel/git, architectural issues with developing the VM) and organizational issues (Estebans' unhelpful response regarding an option in Tonel) and you immediately personalize, do not bring up a single technical issue, and then make grand pronouncements like :this is the last email I'll send you". Laughable and sad.
And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version.
If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely.
About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ,
This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves.
and considering leaving VMMaker altogether.
If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation.
I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us.
The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap.
This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints.
I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle).
Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people.
I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time.
PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure.
Stef
_,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France
Stephane, On Sun, Feb 17, 2019 at 1:33 PM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Eliot
Contrary to you I do not wish your death.
"Drop dead" does not mean I want you dead. It is English for "Dégagé".
So can you respect me?
No. I do not. I've got to the end of my attempt to deal with your destructive relationships. I am merely one in a long line including Camillo, Cl ément, and others. One reason I can't respe3ct you is that you are not a man of your word. You sent an email 23 minutes ago that proudly declared "This is my last email sent to you.". Well done for keeping your word for 23 minutes. What's your record?
Stef
On 17 Feb 2019, at 22:30, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Sun, Feb 17, 2019 at 1:00 PM ducasse <stepharo@netcourrier.com> wrote:
Hi eliot
What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list.
What is common is that I discuss technical matters (difficulties in using Tonel/git, architectural issues with developing the VM) and organizational issues (Estebans' unhelpful response regarding an option in Tonel) and you immediately personalize, do not bring up a single technical issue, and then make grand pronouncements like :this is the last email I'll send you". Laughable and sad.
And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version.
If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely.
About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ,
This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves.
and considering leaving VMMaker altogether.
If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation.
I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us.
The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap.
This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints.
I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle).
Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people.
I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time.
PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure.
Stef
_,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France
-- _,,,^..^,,,_ best, Eliot
Gentlemen, I am really sad to read through this animosity. Please, letâs go back to technical discussions. Tudor
On Feb 17, 2019, at 10:46 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Stephane,
On Sun, Feb 17, 2019 at 1:33 PM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Eliot
Contrary to you I do not wish your death.
"Drop dead" does not mean I want you dead. It is English for "Dégagé".
So can you respect me?
No. I do not. I've got to the end of my attempt to deal with your destructive relationships. I am merely one in a long line including Camillo, Cl ément, and others.
One reason I can't respe3ct you is that you are not a man of your word. You sent an email 23 minutes ago that proudly declared "This is my last email sent to you.". Well done for keeping your word for 23 minutes. What's your record?
Stef
On 17 Feb 2019, at 22:30, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Sun, Feb 17, 2019 at 1:00 PM ducasse <stepharo@netcourrier.com> wrote: Hi eliot
What is common in your thread is that we always look like the super emotional, or bad guys. You never ask yourselves why Esteban left the VM mailing-list.
What is common is that I discuss technical matters (difficulties in using Tonel/git, architectural issues with developing the VM) and organizational issues (Estebans' unhelpful response regarding an option in Tonel) and you immediately personalize, do not bring up a single technical issue, and then make grand pronouncements like :this is the last email I'll send you". Laughable and sad.
And I do not see why you cannot fork Tonel to produce your own version. Git is about distributed projects. People do that all the time. You can take Tonel and hack it to death without having your hacks pushed back into Pharo and this is perfectly ok for us. So Esteban has the right to say no and you have the right to hack your own version.
If you want to have some support for porting Scorch/Sista to github and loading you should ask but asking it more nicely.
About the simulation of the UI, if you do not talk to us we cannot pay attention. I do not see why we cannot keep a package with the image level UI for the simulator. Now again you are talking about collaboration but you do not talk to us and you do not listen to us so do not expect that people are willing to spend their free time to help.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or elseâ,
This is fun to ask Pharo not to grow up to use modern technology to manage source code under the premisses that Squeak cannot or will not. This is so funny how you state it. I will not comment more than that. People around are adults and they will be able to judge by themselves.
and considering leaving VMMaker altogether.
If you leave VMMaker, let us know because we will port it to Github and make it work in Pharo. Esteban did it several times in the past. At least this will have the benefit to clarify the situation.
I think that this is good that you tell us that you do not want to cooperate with us. This will have at least the impact to kick our ass and pay attention to us.
The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap.
This is not a crap. I can restate what I said. Because of responsibility of a research team and creating a future for students. You know Iâm not alone, I have quite some responsibility towards PhD students of my group and yes I cannot make them fail by construction (or produce unadequate results) just by imposing them to use a system with far too many constraints.
I will not ask them to work on the openSmalltalk vm directly because this is not their responsibilities to have to jump over newspeak ifdef and others. A job of a PhD is to be able to brainstorm and create new ideas. Look at Stefan Marr (He is working on SOM or Truffle).
Now you can think that Iâm an asshole, arrogant, or I do not know pick what you want. ***I do not care***. I do not have Diva syndrome I have responsibilities towards people.
I was discussing with some truffle experts and they told me that this is can be complex. I believe it. I would like to avoid pypy for obvious reasons. So what we will probably do for their PhD is to see if we can use a light version of opensmalltalk. I do not want to ask them to jump over many things that are totally useless for them all the time.
PS: personnally I do not get why VMMaker would be the only project on earth that cannot be managed using git and Pharo. But for us the future is Git and we will continue to build on this infrastructure.
Stef
_,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France
-- _,,,^..^,,,_ best, Eliot
-- www.feenk.com "The coherence of a trip is given by the clearness of the goal."
Hi Eliot, You raise a few technical concerns related to VMMaker that seem addressable: 1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries. 2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be. But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration. The code is here: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository. The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic. I see two benefits for doing this: 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful. Cheers, Doru
On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- www.feenk.com âSoftware has no shape. Actually, it has no one shape. It has many."
Hi Tudor, Retrieving author and timestamp from git history is doable. The question is whether it will be still possible to contribute thru MC or not. If it is metadataless MC, there's no point, it's unusable. I think that the minimal metadata we have to maintain is the last MC ancestor. This can be done by convention thru a .last_mc_ancestor file. Of course, there will be conflicts, but easy to (automatically) solve. That could also lie in commit message, but is somehow a bit more fragile... it would mean scanning thru ancestry for getting such information. By symmetry, merged agit sha should be in mc commit, either a specific file in mcz, or commit message. Also note that vmmaker history as proposed in opensmalltalk pr was broken (no respect of branch topology). Maybe retry with Squot? https://github.com/hpi-swa/Squot There is still a problem of synching commits of other packages (cog, various plugins ...), and if nobody is working on it, we are condemned to a mediocre solution. IMO, a broken history has not much interest. The question is whether it is possible to come to acceptable compromise? Le lun. 18 févr. 2019 à 07:33, Tudor Girba <tudor@tudorgirba.com> a écrit :
Hi Eliot,
You raise a few technical concerns related to VMMaker that seem addressable:
1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries.
2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be.
But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration.
The code is here: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository.
The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic.
I see two benefits for doing this: 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful.
Cheers, Doru
On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- www.feenk.com
âSoftware has no shape. Actually, it has no one shape. It has many."
Hi Nicolas,
On Feb 18, 2019, at 3:12 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Tudor, Retrieving author and timestamp from git history is doable. The question is whether it will be still possible to contribute thru MC or not. If it is metadataless MC, there's no point, it's unusable. I think that the minimal metadata we have to maintain is the last MC ancestor. This can be done by convention thru a .last_mc_ancestor file. Of course, there will be conflicts, but easy to (automatically) solve. That could also lie in commit message, but is somehow a bit more fragile... it would mean scanning thru ancestry for getting such information. By symmetry, merged agit sha should be in mc commit, either a specific file in mcz, or commit message.
That sounds intriguing and interesting at the same time. However, I do not have a qualified enough opinion on this matter.
Also note that vmmaker history as proposed in opensmalltalk pr was broken (no respect of branch topology). Maybe retry with Squot? https://github.com/hpi-swa/Squot There is still a problem of synching commits of other packages (cog, various plugins ...), and if nobody is working on it, we are condemned to a mediocre solution. IMO, a broken history has not much interest.
We know it was broken, and thank you for pointing it out. We went through multiple iterations, and we think the latest one should be better. Please take a look and let us know if you still find issues: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
The question is whether it is possible to come to acceptable compromise?
As I wrote in the reply to Eliot, I believe the main point at this moment is not Git, but getting the VMMaker code to run in Pharo. I think we should start there, and see if we can produce an alternative environment that provides value. Cheers, Doru
Le lun. 18 févr. 2019 à 07:33, Tudor Girba <tudor@tudorgirba.com> a écrit :
Hi Eliot,
You raise a few technical concerns related to VMMaker that seem addressable:
1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries.
2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be.
But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration.
The code is here: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository.
The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic.
I see two benefits for doing this: 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful.
Cheers, Doru
On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- www.feenk.com
âSoftware has no shape. Actually, it has no one shape. It has many."
-- www.feenk.com âHow do you feenk today?"
Doru, On Sun, Feb 17, 2019 at 10:33 PM Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Eliot,
You raise a few technical concerns related to VMMaker that seem addressable:
1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries.
2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be.
But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration.
The code is here: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository.
The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic.
I see two benefits for doing this: 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful.
All this is great work. But I cannot use it until I can also function in Squeak. I know you want me to move to Pharo, but I am not convinced that it is a safe place for me to land. I have voiced my concerns before (stability, moving away from support I need (e.g. Pharo dropping read./write file streams is the latest example). Let me simply restate that "t6he devil you know is better than the devil you don't", and that I know I am productive with VMMaker in Squeak, but I *do not* know that I can be productive in Pharo (in fact, I have lots of experience of the contrary). So I will not move to Pharo any time soon and so, until there is a solution to git/tonel/squeak integration I cannot join the unified repository, must as I would like to. I'm sorry for the frustration this causes other. I am radical in some things, but deeply conservative in others. And my ability to be productive is obviously foundational.
Cheers, Doru
On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- www.feenk.com
âSoftware has no shape. Actually, it has no one shape. It has many."
-- _,,,^..^,,,_ best, Eliot
Hi Eliot, Please, let me clarify the current direction: I am not trying to get you to Pharo at this point. I only want to reach a point where the VMMaker code runs in Pharo. This will allow us to bootstrap an environment that can later be evaluated. Having the sources in Git is secondary at this point. With the current infrastructure, we get those sources in Git while preserving the history from the Squeaksource repo automatically. The code will be loadable from either Git or Squeaksource, but the commit repository is still the Squeaksource one. So, nothing would change from the workflow of the current committers. What we gain with the Git repository is a test ground and an easier ability to load the code in Pharo, all at no extra cost and without affecting your flow. Let me emphasize this again: the Git support should not be the main issue at this point. Now we would only need to get the code to run in Pharo. For this, we would need to introduce a few support methods. One key method that Andrei and I would like to propose, and that we used before in other porting projects, is: Object>>vmMakerForSqueak: aBlockToBeExecutedOnlyInSqueak forPharo: aBlockToBeExecutedOnlyInPharo Andrei will propose a commit in VMMaker Inbox this week. What do you say? Cheers, Doru
On Feb 18, 2019, at 7:55 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Doru,
On Sun, Feb 17, 2019 at 10:33 PM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Eliot,
You raise a few technical concerns related to VMMaker that seem addressable:
1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries.
2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be.
But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration.
The code is here: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository.
The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic.
I see two benefits for doing this: 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful.
All this is great work. But I cannot use it until I can also function in Squeak. I know you want me to move to Pharo, but I am not convinced that it is a safe place for me to land. I have voiced my concerns before (stability, moving away from support I need (e.g. Pharo dropping read./write file streams is the latest example). Let me simply restate that "t6he devil you know is better than the devil you don't", and that I know I am productive with VMMaker in Squeak, but I *do not* know that I can be productive in Pharo (in fact, I have lots of experience of the contrary). So I will not move to Pharo any time soon and so, until there is a solution to git/tonel/squeak integration I cannot join the unified repository, must as I would like to.
I'm sorry for the frustration this causes other. I am radical in some things, but deeply conservative in others. And my ability to be productive is obviously foundational.
Cheers, Doru
On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- www.feenk.com
âSoftware has no shape. Actually, it has no one shape. It has many."
-- _,,,^..^,,,_ best, Eliot
-- www.feenk.com "Sometimes the best solution is not the best solution."
Hi Doru, On Mon, Feb 18, 2019 at 8:14 PM Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Eliot,
Please, let me clarify the current direction: I am not trying to get you to Pharo at this point. I only want to reach a point where the VMMaker code runs in Pharo. This will allow us to bootstrap an environment that can later be evaluated.
Having the sources in Git is secondary at this point. With the current infrastructure, we get those sources in Git while preserving the history from the Squeaksource repo automatically. The code will be loadable from either Git or Squeaksource, but the commit repository is still the Squeaksource one. So, nothing would change from the workflow of the current committers. What we gain with the Git repository is a test ground and an easier ability to load the code in Pharo, all at no extra cost and without affecting your flow.
Let me emphasize this again: the Git support should not be the main issue at this point. Now we would only need to get the code to run in Pharo. For this, we would need to introduce a few support methods. One key method that Andrei and I would like to propose, and that we used before in other porting projects, is: Object>>vmMakerForSqueak: aBlockToBeExecutedOnlyInSqueak forPharo: aBlockToBeExecutedOnlyInPharo
I am doing things on a case-by-case basis. Currently I use classNamed:, e.g. (Smalltalk classNamed: #FileSystem) ifNotNil: [:fileSystem| fileSystem disk delimiter asInteger] ifNil: [FileDirectory pathNameDelimiter asInteger] (Smalltalk classNamed: #CurrentReadOnlySourceFiles) ifNil: syncAction ifNotNil: [:crosf| crosf cacheDuring: syncAction] (Smalltalk classNamed: #Project) ifNotNil: [:project| Project uiProcess] "Squeak" ifNil: [UIManager default uiProcess] "Pharo" ((Smalltalk classNamed: #FillInTheBlankMorph) ifNotNil: "Squeak" [:fITBM| fITBM request: 'Input please!' initialAnswer: '' centerAt: ActiveHand cursorPoint inWorld: ActiveWorld onCancelReturn: nil acceptOnCR: true] ifNil: "Pharo; onCancelReturn: nil is the default here" [UIManager default request: 'Input please!' initialAnswer: '']). this at least allows Squeak to migrate to FileSystem without having to rewrite. Using the above I was already able to get most of VMMaker working in Pharo6. Things broke for Pharo7, which indicates that the vmMakerForSqueak:forPharo: approach has vulnerabilities.
Andrei will propose a commit in VMMaker Inbox this week.
What do you say?
Cheers, Doru
On Feb 18, 2019, at 7:55 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Doru,
On Sun, Feb 17, 2019 at 10:33 PM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Eliot,
You raise a few technical concerns related to VMMaker that seem addressable:
1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries.
2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be.
But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration.
The code is here: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository.
The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic.
I see two benefits for doing this: 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful.
All this is great work. But I cannot use it until I can also function in Squeak. I know you want me to move to Pharo, but I am not convinced that it is a safe place for me to land. I have voiced my concerns before (stability, moving away from support I need (e.g. Pharo dropping read./write file streams is the latest example). Let me simply restate that "t6he devil you know is better than the devil you don't", and that I know I am productive with VMMaker in Squeak, but I *do not* know that I can be productive in Pharo (in fact, I have lots of experience of the contrary). So I will not move to Pharo any time soon and so, until there is a solution to git/tonel/squeak integration I cannot join the unified repository, must as I would like to.
I'm sorry for the frustration this causes other. I am radical in some things, but deeply conservative in others. And my ability to be productive is obviously foundational.
Cheers, Doru
On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- www.feenk.com
âSoftware has no shape. Actually, it has no one shape. It has many."
-- _,,,^..^,,,_ best, Eliot
-- www.feenk.com
"Sometimes the best solution is not the best solution."
-- _,,,^..^,,,_ best, Eliot
Hi, I have seen that code, and the issue I wanted to address is to have the decision about which dialect a piece of code is ran on in one single place. This should make it easier to find statically. Indeed, this will not necessarily be guaranteed to work when moving from one version of Pharo to another. But, that problem can be addressed by tracing releases in a reproducible fashion. And in the VMMaker case, the scenario is about a development environment not a production system. So, it should be reasonable to point developers to a working configuration that pairs the Pharo/Squeak version and the VMMaker version. What do you think? Cheers, Doru
On Feb 20, 2019, at 4:39 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Mon, Feb 18, 2019 at 8:14 PM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Eliot,
Please, let me clarify the current direction: I am not trying to get you to Pharo at this point. I only want to reach a point where the VMMaker code runs in Pharo. This will allow us to bootstrap an environment that can later be evaluated.
Having the sources in Git is secondary at this point. With the current infrastructure, we get those sources in Git while preserving the history from the Squeaksource repo automatically. The code will be loadable from either Git or Squeaksource, but the commit repository is still the Squeaksource one. So, nothing would change from the workflow of the current committers. What we gain with the Git repository is a test ground and an easier ability to load the code in Pharo, all at no extra cost and without affecting your flow.
Let me emphasize this again: the Git support should not be the main issue at this point. Now we would only need to get the code to run in Pharo. For this, we would need to introduce a few support methods. One key method that Andrei and I would like to propose, and that we used before in other porting projects, is: Object>>vmMakerForSqueak: aBlockToBeExecutedOnlyInSqueak forPharo: aBlockToBeExecutedOnlyInPharo
I am doing things on a case-by-case basis. Currently I use classNamed:, e.g.
(Smalltalk classNamed: #FileSystem) ifNotNil: [:fileSystem| fileSystem disk delimiter asInteger] ifNil: [FileDirectory pathNameDelimiter asInteger]
(Smalltalk classNamed: #CurrentReadOnlySourceFiles) ifNil: syncAction ifNotNil: [:crosf| crosf cacheDuring: syncAction]
(Smalltalk classNamed: #Project) ifNotNil: [:project| Project uiProcess] "Squeak" ifNil: [UIManager default uiProcess] "Pharo"
((Smalltalk classNamed: #FillInTheBlankMorph) ifNotNil: "Squeak" [:fITBM| fITBM request: 'Input please!' initialAnswer: '' centerAt: ActiveHand cursorPoint inWorld: ActiveWorld onCancelReturn: nil acceptOnCR: true] ifNil: "Pharo; onCancelReturn: nil is the default here" [UIManager default request: 'Input please!' initialAnswer: '']).
this at least allows Squeak to migrate to FileSystem without having to rewrite. Using the above I was already able to get most of VMMaker working in Pharo6. Things broke for Pharo7, which indicates that the vmMakerForSqueak:forPharo: approach has vulnerabilities.
Andrei will propose a commit in VMMaker Inbox this week.
What do you say?
Cheers, Doru
On Feb 18, 2019, at 7:55 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Doru,
On Sun, Feb 17, 2019 at 10:33 PM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Eliot,
You raise a few technical concerns related to VMMaker that seem addressable:
1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think itâs not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries.
2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be.
But, letâs take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration.
The code is here: https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository.
The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic.
I see two benefits for doing this: 1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute. 2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful.
All this is great work. But I cannot use it until I can also function in Squeak. I know you want me to move to Pharo, but I am not convinced that it is a safe place for me to land. I have voiced my concerns before (stability, moving away from support I need (e.g. Pharo dropping read./write file streams is the latest example). Let me simply restate that "t6he devil you know is better than the devil you don't", and that I know I am productive with VMMaker in Squeak, but I *do not* know that I can be productive in Pharo (in fact, I have lots of experience of the contrary). So I will not move to Pharo any time soon and so, until there is a solution to git/tonel/squeak integration I cannot join the unified repository, must as I would like to.
I'm sorry for the frustration this causes other. I am radical in some things, but deeply conservative in others. And my ability to be productive is obviously foundational.
Cheers, Doru
On Feb 17, 2019, at 9:27 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- www.feenk.com
âSoftware has no shape. Actually, it has no one shape. It has many."
-- _,,,^..^,,,_ best, Eliot
-- www.feenk.com
"Sometimes the best solution is not the best solution."
-- _,,,^..^,,,_ best, Eliot
-- www.feenk.com "Beauty is where we see it."
On Wed, Feb 20, 2019 at 09:23:55AM +0100, Tudor Girba wrote:
Hi,
I have seen that code, and the issue I wanted to address is to have the decision about which dialect a piece of code is ran on in one single place. This should make it easier to find statically.
Indeed, this will not necessarily be guaranteed to work when moving from one version of Pharo to another. But, that problem can be addressed by tracing releases in a reproducible fashion. And in the VMMaker case, the scenario is about a development environment not a production system. So, it should be reasonable to point developers to a working configuration that pairs the Pharo/Squeak version and the VMMaker version.
What do you think?
Cheers, Doru
Hi Doru and Eliiot, The approach that I have been using to address this in OSProcess is to put the compatibility methods in one place, in the 'compatibility' category in class OSProcess. This allows support for the different file system interfaces in Cuis, Pharo and Squeak. For example, one of the compatibility methods is: OSProcess class>>directoryExists: path "Answer true if a directory of the given name exists. The given name may be either a full path name or a local directory within this directory." ^ self useFileMan ifTrue: [((Smalltalk at: #DirectoryEntry) perform: #withPathName: with: path) exists] ifFalse: [self useFileSystem ifTrue: [ (path perform: #asFileReference) exists ] ifFalse: [ (Smalltalk at: #FileDirectory) default directoryExists: path ]] And the tests for Cuis/Pharo/Squeak are in these two methods: OSProcess class>>useFileSystem "If true use FileSystem, otherwise use traditional FileDirectory. See senders for methods with file system dependencies." ^ Smalltalk hasClassNamed: #FileReference OSProcess class>>useFileMan "If true use FileMan for directory and file access. See senders for methods with file system dependencies." ^ Smalltalk hasClassNamed: #FileIOAccessor This is ugly but it does work, and I been able to maintain OSProcess and CommandShell for the Squeak diaspora over a number of years in this manner. It also means that I do not need to worry if Squeak moves to FileMan(*) or FileSystem at some point in the future. I don't think that VMMaker should have a hard dependency on OSProcess, but as a practical matter you probably have OSProcess loaded in the VM development image anyway, so you could try using these methods directly and see how ugly things get. HTH, Dave * Personally I like the FileMan approach in Cuis best, but that is another topic entirely ;-)
Hi, Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate.
On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstanceâ.
This is textually my answer (even with the English errors): ⦠âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git. Thing is, putting timestamps it will generate conflicts massively when there is no reason to it. So, we drop it⦠and we add support for the equivalent using the tool we use (iceberg gives you not just the author that modified last the method but all of them, along the history). I hope is an understandable reason?â And then in other mail of same thread I suggested an approach viable for squeak: "Now, what Iâm sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :) We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using. In the middle, there was/is gitfiletree. (I think I suggested you to look at it to adapt it for tonel and squeak). Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. â Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. Since they need the blame support, they could use OSProcess and external git for it. Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). And Pharo can read that format but it will ignore all extensions. Now, another problem is to WRITE: Pharo would write those packages in âpharo formatâ and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to âhonourâ that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled. Anyway, as you can see my answer was not ânot under any circumstancesâ. Was âno, because is not convenientâ. Esteban
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
Esteban, On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate.
On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote:
Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstanceâ.
This is textually my answer (even with the English errors): ⦠âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git.
Thing is, putting timestamps it will generate conflicts massively when there is no reason to it.
How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed. I see no problem with this. I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though. There was a time when you, Esteban, were contributing to VMMaker.oscog from Pharo and often there would be many changes where just the timestamp had changed. SO the problem seems to be not with timestamps but with mismanagement of them. So, we drop it⦠and we add support for the equivalent using the tool we
use (iceberg gives you not just the author that modified last the method but all of them, along the history).
Who is we? I ask from a different perspective. I ask not too have Pharo use it but to allow Squeak to use it so that I can have timestamps for Squerask and still use Tonel. But still "âAnyway the answer will be no :)". So, your first statement is false. If things are correct there will *not* be massive generation of conflicts when there is no reason. Second, I am not asking you to change Tonel in Pharo. i am only asking you to allow Tonel to support timestamps in systems that want to use it.
I hope is an understandable reason?â
And then in other mail of same thread I suggested an approach viable for squeak:
"Now, what Iâm sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :)
We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using.
In the middle, there was/is gitfiletree. (I think I suggested you to look at it to adapt it for tonel and squeak).
Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. â
Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. Since they need the blame support, they could use OSProcess and external git for it.
Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). And Pharo can read that format but it will ignore all extensions. Now, another problem is to WRITE: Pharo would write those packages in âpharo formatâ and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to âhonourâ that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled.
Anyway, as you can see my answer was not ânot under any circumstancesâ. Was âno, because is not convenientâ.
It was still no. And my request was clear. I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps. This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.
Esteban
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
On Tue, 19 Feb 2019 at 01:34, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Esteban,
On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate.
On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote:
Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstanceâ.
This is textually my answer (even with the English errors): ⦠âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git.
Thing is, putting timestamps it will generate conflicts massively when there is no reason to it.
How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed. I see no problem with this.
This is a case of the difference between theory and practice :)
I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though.
When I heard of this timestamp conflict problem I began with the same belief to do some digging (and you know how I dig deep into things) with git-only command line experiments and ended up finding its really true. I'll try to remember some examples. cheers -ben
Still thatâs not the point. Not having an agreement is very different that the behaviour you described about me (and that to justify your own actions). You presented my opposition as it would have been âjust becauseâ and I presented you my arguments. Even more, I *was* trying to find a solution. I can be right or wrong, but Iâm not an idiot trying to be more than I am. Honestly, discussing with you many times feels like it is âmy way or the highwayâ, and itâs hard to follow you :( Esteban
On 18 Feb 2019, at 18:34, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Esteban,
On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,
Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate.
On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstanceâ.
This is textually my answer (even with the English errors): ⦠âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git.
Thing is, putting timestamps it will generate conflicts massively when there is no reason to it.
How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed. I see no problem with this.
I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though. There was a time when you, Esteban, were contributing to VMMaker.oscog from Pharo and often there would be many changes where just the timestamp had changed. SO the problem seems to be not with timestamps but with mismanagement of them.
So, we drop it⦠and we add support for the equivalent using the tool we use (iceberg gives you not just the author that modified last the method but all of them, along the history).
Who is we? I ask from a different perspective. I ask not too have Pharo use it but to allow Squeak to use it so that I can have timestamps for Squerask and still use Tonel. But still "âAnyway the answer will be no :)".
So, your first statement is false. If things are correct there will *not* be massive generation of conflicts when there is no reason. Second, I am not asking you to change Tonel in Pharo. i am only asking you to allow Tonel to support timestamps in systems that want to use it.
I hope is an understandable reason?â
And then in other mail of same thread I suggested an approach viable for squeak:
"Now, what Iâm sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :)
We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using.
In the middle, there was/is gitfiletree. (I think I suggested you to look at it to adapt it for tonel and squeak).
Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. â
Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. Since they need the blame support, they could use OSProcess and external git for it.
Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). And Pharo can read that format but it will ignore all extensions. Now, another problem is to WRITE: Pharo would write those packages in âpharo formatâ and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to âhonourâ that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled.
Anyway, as you can see my answer was not ânot under any circumstancesâ. Was âno, because is not convenientâ.
It was still no. And my request was clear. I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps. This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.
Esteban
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Esteban, On Mon, Feb 18, 2019 at 10:37 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Still thatâs not the point. Not having an agreement is very different that the behaviour you described about me (and that to justify your own actions). You presented my opposition as it would have been âjust becauseâ and I presented you my arguments. Even more, I *was* trying to find a solution. I can be right or wrong, but Iâm not an idiot trying to be more than I am. Honestly, discussing with you many times feels like it is âmy way or the highwayâ, and itâs hard to follow you :(
I am not trying to force my way. I am trying to find a way that works for me. I asked you to support an option in Tonel. I did not ask you8 to change they way Pharo uses Tonel. You can choose to read my request as some kind of threat, or you can choose to read it as a straightforward request. I am not trying to get you to follow me. I am frustrated at being mistrusted. I have not asked you to follow me. I have tried to work with you. But you don't trust me. I have done everything I can in the VM (let's ignore source code control and building for now) to support Pharo. I have done *nothing* to interfere with Pharo's use of the VM in the code base itself. have I? Point to actions I have taken, code I have written to try and harm you. We now have a situation where we support differences in the code base (FilePlugin API, command line argument parsing, version printing) that extend *those I put in at the beginning to support differences* (such as plugins.ext and plugins.int to allow builders to configure the VM as they choose). Where have I tried to block Pharo? But you left vm-dev. You decided to stop communicating. And now you continue to describe a straight-forward request to allow an optional behavior in Tonel with a flat refusal, plus some BS about me trying to insist that you follow me. I don't understand Esteban. You and I do not communicate. I feel that you top not want to work with me, that you dislike and distrust me. I cannot work with you. I have tried for years and we are still in difference and disagreement.
Esteban
On 18 Feb 2019, at 18:34, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Esteban,
On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate.
On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote:
Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstanceâ.
This is textually my answer (even with the English errors): ⦠âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git.
Thing is, putting timestamps it will generate conflicts massively when there is no reason to it.
How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed. I see no problem with this.
I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though. There was a time when you, Esteban, were contributing to VMMaker.oscog from Pharo and often there would be many changes where just the timestamp had changed. SO the problem seems to be not with timestamps but with mismanagement of them.
So, we drop it⦠and we add support for the equivalent using the tool we
use (iceberg gives you not just the author that modified last the method but all of them, along the history).
Who is we? I ask from a different perspective. I ask not too have Pharo use it but to allow Squeak to use it so that I can have timestamps for Squerask and still use Tonel. But still "âAnyway the answer will be no :)".
So, your first statement is false. If things are correct there will *not* be massive generation of conflicts when there is no reason. Second, I am not asking you to change Tonel in Pharo. i am only asking you to allow Tonel to support timestamps in systems that want to use it.
I hope is an understandable reason?â
And then in other mail of same thread I suggested an approach viable for squeak:
"Now, what Iâm sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :)
We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using.
In the middle, there was/is gitfiletree. (I think I suggested you to look at it to adapt it for tonel and squeak).
Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. â
Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. Since they need the blame support, they could use OSProcess and external git for it.
Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). And Pharo can read that format but it will ignore all extensions. Now, another problem is to WRITE: Pharo would write those packages in âpharo formatâ and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to âhonourâ that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled.
Anyway, as you can see my answer was not ânot under any circumstancesâ. Was âno, because is not convenientâ.
It was still no. And my request was clear. I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps. This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.
Esteban
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Fair enough. I should not have step in this discussion. Esteban
On 18 Feb 2019, at 19:48, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Esteban,
On Mon, Feb 18, 2019 at 10:37 AM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Still thatâs not the point. Not having an agreement is very different that the behaviour you described about me (and that to justify your own actions). You presented my opposition as it would have been âjust becauseâ and I presented you my arguments. Even more, I *was* trying to find a solution. I can be right or wrong, but Iâm not an idiot trying to be more than I am. Honestly, discussing with you many times feels like it is âmy way or the highwayâ, and itâs hard to follow you :(
I am not trying to force my way. I am trying to find a way that works for me. I asked you to support an option in Tonel. I did not ask you8 to change they way Pharo uses Tonel. You can choose to read my request as some kind of threat, or you can choose to read it as a straightforward request. I am not trying to get you to follow me.
I am frustrated at being mistrusted. I have not asked you to follow me. I have tried to work with you. But you don't trust me.
I have done everything I can in the VM (let's ignore source code control and building for now) to support Pharo. I have done *nothing* to interfere with Pharo's use of the VM in the code base itself. have I? Point to actions I have taken, code I have written to try and harm you.
We now have a situation where we support differences in the code base (FilePlugin API, command line argument parsing, version printing) that extend *those I put in at the beginning to support differences* (such as plugins.ext and plugins.int <http://plugins.int/> to allow builders to configure the VM as they choose). Where have I tried to block Pharo?
But you left vm-dev. You decided to stop communicating. And now you continue to describe a straight-forward request to allow an optional behavior in Tonel with a flat refusal, plus some BS about me trying to insist that you follow me.
I don't understand Esteban. You and I do not communicate. I feel that you top not want to work with me, that you dislike and distrust me. I cannot work with you. I have tried for years and we are still in difference and disagreement.
Esteban
On 18 Feb 2019, at 18:34, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Esteban,
On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,
Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate.
On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>> wrote: Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstanceâ.
This is textually my answer (even with the English errors): ⦠âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git.
Thing is, putting timestamps it will generate conflicts massively when there is no reason to it.
How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed. I see no problem with this.
I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though. There was a time when you, Esteban, were contributing to VMMaker.oscog from Pharo and often there would be many changes where just the timestamp had changed. SO the problem seems to be not with timestamps but with mismanagement of them.
So, we drop it⦠and we add support for the equivalent using the tool we use (iceberg gives you not just the author that modified last the method but all of them, along the history).
Who is we? I ask from a different perspective. I ask not too have Pharo use it but to allow Squeak to use it so that I can have timestamps for Squerask and still use Tonel. But still "âAnyway the answer will be no :)".
So, your first statement is false. If things are correct there will *not* be massive generation of conflicts when there is no reason. Second, I am not asking you to change Tonel in Pharo. i am only asking you to allow Tonel to support timestamps in systems that want to use it.
I hope is an understandable reason?â
And then in other mail of same thread I suggested an approach viable for squeak:
"Now, what Iâm sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :)
We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using.
In the middle, there was/is gitfiletree. (I think I suggested you to look at it to adapt it for tonel and squeak).
Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. â
Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. Since they need the blame support, they could use OSProcess and external git for it.
Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). And Pharo can read that format but it will ignore all extensions. Now, another problem is to WRITE: Pharo would write those packages in âpharo formatâ and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to âhonourâ that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled.
Anyway, as you can see my answer was not ânot under any circumstancesâ. Was âno, because is not convenientâ.
It was still no. And my request was clear. I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps. This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.
Esteban
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
On Mon, Feb 18, 2019 at 11:02 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Fair enough. I should not have step in this discussion.
Again, your response is to withdraw and not to engage. I am trying too be honest about my feelings and about the issues. Why don't you try and do the same? Why do you always try and withdraw? Why do you top post emotionally and run away from a real problem that affects both of us? I do not understand this pattern Esteban. I am not trying to hurt you.
Esteban
On 18 Feb 2019, at 19:48, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Esteban,
On Mon, Feb 18, 2019 at 10:37 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Still thatâs not the point. Not having an agreement is very different that the behaviour you described about me (and that to justify your own actions). You presented my opposition as it would have been âjust becauseâ and I presented you my arguments. Even more, I *was* trying to find a solution. I can be right or wrong, but Iâm not an idiot trying to be more than I am. Honestly, discussing with you many times feels like it is âmy way or the highwayâ, and itâs hard to follow you :(
I am not trying to force my way. I am trying to find a way that works for me. I asked you to support an option in Tonel. I did not ask you8 to change they way Pharo uses Tonel. You can choose to read my request as some kind of threat, or you can choose to read it as a straightforward request. I am not trying to get you to follow me.
I am frustrated at being mistrusted. I have not asked you to follow me. I have tried to work with you. But you don't trust me.
I have done everything I can in the VM (let's ignore source code control and building for now) to support Pharo. I have done *nothing* to interfere with Pharo's use of the VM in the code base itself. have I? Point to actions I have taken, code I have written to try and harm you.
We now have a situation where we support differences in the code base (FilePlugin API, command line argument parsing, version printing) that extend *those I put in at the beginning to support differences* (such as plugins.ext and plugins.int to allow builders to configure the VM as they choose). Where have I tried to block Pharo?
But you left vm-dev. You decided to stop communicating. And now you continue to describe a straight-forward request to allow an optional behavior in Tonel with a flat refusal, plus some BS about me trying to insist that you follow me.
I don't understand Esteban. You and I do not communicate. I feel that you top not want to work with me, that you dislike and distrust me. I cannot work with you. I have tried for years and we are still in difference and disagreement.
Esteban
On 18 Feb 2019, at 18:34, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Esteban,
On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Iâm so not wanting to be part of this discussion, but here I am. Just because it was mentioned my name in a way I consider inaccurate.
On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All, Hi Torsten, Hi Jakob,
On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares@gmx.de> wrote:
Hi,
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) to Tonel format [3].
So I wonder about adoption of Tonel in Squeak land.
Any status/comments?
Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstanceâ.
This is textually my answer (even with the English errors): ⦠âAnyway the answer will be no :) This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git.
Thing is, putting timestamps it will generate conflicts massively when there is no reason to it.
How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed. I see no problem with this.
I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though. There was a time when you, Esteban, were contributing to VMMaker.oscog from Pharo and often there would be many changes where just the timestamp had changed. SO the problem seems to be not with timestamps but with mismanagement of them.
So, we drop it⦠and we add support for the equivalent using the tool we
use (iceberg gives you not just the author that modified last the method but all of them, along the history).
Who is we? I ask from a different perspective. I ask not too have Pharo use it but to allow Squeak to use it so that I can have timestamps for Squerask and still use Tonel. But still "âAnyway the answer will be no :)".
So, your first statement is false. If things are correct there will *not* be massive generation of conflicts when there is no reason. Second, I am not asking you to change Tonel in Pharo. i am only asking you to allow Tonel to support timestamps in systems that want to use it.
I hope is an understandable reason?â
And then in other mail of same thread I suggested an approach viable for squeak:
"Now, what Iâm sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :)
We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using.
In the middle, there was/is gitfiletree. (I think I suggested you to look at it to adapt it for tonel and squeak).
Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. â
Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. Since they need the blame support, they could use OSProcess and external git for it.
Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). And Pharo can read that format but it will ignore all extensions. Now, another problem is to WRITE: Pharo would write those packages in âpharo formatâ and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to âhonourâ that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled.
Anyway, as you can see my answer was not ânot under any circumstancesâ. Was âno, because is not convenientâ.
It was still no. And my request was clear. I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps. This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.
Esteban
So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
Here's the kind of crap people like Ducasse throw at me:
"Eliot
At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the âopenâ smalltalk VM. "
I am so over this crap. _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
participants (8)
-
Ben Coman -
David T. Lewis -
ducasse -
Eliot Miranda -
Esteban Lorenzano -
Nicolas Cellier -
Stéphane Ducasse -
Tudor Girba