Critical change to compiler, needs testing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Critical change to compiler, needs testing

Guillermo Polito
Hi guys,

In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy.

To solve this, we are integrating this in several steps:

- Integrate a copy of the encoders that are not subclass of ParseNode
     Already integrated, with no real side effects on the system.

- Make the system use the new encoders
    This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^.
    We need help in testing this.
    I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :)

- A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk.

Guille
Reply | Threaded
Open this post in threaded view
|

Re: Critical change to compiler, needs testing

Blondeau Vincent

Hi Guille,

 

I loaded your slice in the last Moose image, and it not possible to browse any source code through nautilus…

 

Maybe you should take a look?

 

Cheers,

Vincent

 

De : Pharo-dev [mailto:[hidden email]] De la part de Guillermo Polito
Envoyé : mardi 18 août 2015 11:13
À : Discusses Development of Pharo; Clément Bera
Objet : [Pharo-dev] Critical change to compiler, needs testing

 

Hi guys,

 

In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy.

 

To solve this, we are integrating this in several steps:

 

- Integrate a copy of the encoders that are not subclass of ParseNode

     Already integrated, with no real side effects on the system.

 

- Make the system use the new encoders

    This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^.

    We need help in testing this.

    I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :)

 

- A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk.

 

Guille




Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

PharoDebug.log (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Critical change to compiler, needs testing

Guillermo Polito
That moose image is based on the latest Pharo??? :) Because to me it looks like you don't have the OpalEncoder classes from slice 16199.

The order of loading is the following if on versions of pharo that are not latest 5.0:

- load slice 16199
- load slice 16250
- execute postload: CompiledMethod initialize

I tried that in moose 6.0, based on Pharo5.0 update: #50241 and It works fine.

El mar., 18 de ago. de 2015 a la(s) 11:32 a. m., Blondeau Vincent <[hidden email]> escribió:

Hi Guille,

 

I loaded your slice in the last Moose image, and it not possible to browse any source code through nautilus…

 

Maybe you should take a look?

 

Cheers,

Vincent

 

De : Pharo-dev [mailto:[hidden email]] De la part de Guillermo Polito
Envoyé : mardi 18 août 2015 11:13
À : Discusses Development of Pharo; Clément Bera
Objet : [Pharo-dev] Critical change to compiler, needs testing

 

Hi guys,

 

In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy.

 

To solve this, we are integrating this in several steps:

 

- Integrate a copy of the encoders that are not subclass of ParseNode

     Already integrated, with no real side effects on the system.

 

- Make the system use the new encoders

    This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^.

    We need help in testing this.

    I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :)

 

- A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk.

 

Guille




Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Reply | Threaded
Open this post in threaded view
|

Re: Critical change to compiler, needs testing

Blondeau Vincent

You right, I forget to load the first slice..

 

But I did not find errors by running some tests on the Moose Image.

 

Cheers,

Vincent

 

 

De : Pharo-dev [mailto:[hidden email]] De la part de Guillermo Polito
Envoyé : mardi 18 août 2015 11:49
À : Pharo Development List; Clément Bera
Objet : Re: [Pharo-dev] Critical change to compiler, needs testing

 

That moose image is based on the latest Pharo??? :) Because to me it looks like you don't have the OpalEncoder classes from slice 16199.

 

The order of loading is the following if on versions of pharo that are not latest 5.0:

 

- load slice 16199

- load slice 16250

- execute postload: CompiledMethod initialize

 

I tried that in moose 6.0, based on Pharo5.0 update: #50241 and It works fine.

 

El mar., 18 de ago. de 2015 a la(s) 11:32 a. m., Blondeau Vincent <[hidden email]> escribió:

Hi Guille,

 

I loaded your slice in the last Moose image, and it not possible to browse any source code through nautilus…

 

Maybe you should take a look?

 

Cheers,

Vincent

 

De : Pharo-dev [mailto:[hidden email]] De la part de Guillermo Polito
Envoyé : mardi 18 août 2015 11:13
À : Discusses Development of Pharo; Clément Bera
Objet : [Pharo-dev] Critical change to compiler, needs testing

 

Hi guys,

 

In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy.

 

To solve this, we are integrating this in several steps:

 

- Integrate a copy of the encoders that are not subclass of ParseNode

     Already integrated, with no real side effects on the system.

 

- Make the system use the new encoders

    This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^.

    We need help in testing this.

    I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :)

 

- A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk.

 

Guille

 



Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.




Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Reply | Threaded
Open this post in threaded view
|

Re: Critical change to compiler, needs testing

Marcus Denker-4
In reply to this post by Guillermo Polito
Hi,

One thing we definitely need to do is to commit the Change first to the Opal repository. 

This will trigger a build and in a second step this:


This recompiled the whole image and then runs all tests. It is broken right now due to timeout, but that is from the >500 failing dictionary tests, I think.
So the build now in progress should be green again (I hope).

Marcus

On 18 Aug 2015, at 11:12, Guillermo Polito <[hidden email]> wrote:

Hi guys,

In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy.

To solve this, we are integrating this in several steps:

- Integrate a copy of the encoders that are not subclass of ParseNode
     Already integrated, with no real side effects on the system.

- Make the system use the new encoders
    This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^.
    We need help in testing this.
    I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :)

- A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk.

Guille