[Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images. r. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts New Pharo: http://pharo-project.org/download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
On Wed, May 27, 2009 at 11:53 AM, Ramiro Diaz Trepat <ramiro.diaz.trepat@jpmorgan.com> wrote:
Is OCompletion integrated in this version? Â In the previous version it had stopped suggesting.
It should work. If that's not the case please tell Romain Robbes about it.
Do you know if Seaside 2.9 works with the new Pharo / closures ?
It should work. Please report any problem on Pharo or Seaside mailing lists. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
Yes we should really have beta testers. Sorry for the bugs but knowing them is the only way to kill them. Stef On May 27, 2009, at 12:04 PM, Damien Cassou wrote:
On Wed, May 27, 2009 at 11:53 AM, Ramiro Diaz Trepat <ramiro.diaz.trepat@jpmorgan.com> wrote:
Is OCompletion integrated in this version? In the previous version it had stopped suggesting.
It should work. If that's not the case please tell Romain Robbes about it.
Do you know if Seaside 2.9 works with the new Pharo / closures ?
It should work. Please report any problem on Pharo or Seaside mailing lists.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Ramiro, In which version was OCompletion not working for you? Romain On May 27, 2009, at 11:53 AM, Ramiro Diaz Trepat wrote:
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images.
r.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
In the latest version before the one Damien published today. It was not working neither on the workspace nor on OmbiBrowser, although the underlining showed while typing. I can try the new image image when I get home tonight, and if you can't reproduce it, may be I can send you my image somehow. Cheers r. -----Original Message----- From: Romain Robbes [mailto:romain.robbes@lu.unisi.ch] Sent: 27 May 2009 12:32 To: Pharo-project@lists.gforge.inria.fr Development; Ramiro Diaz Trepat Subject: Re: [Pharo-project] New Pharo based on core 10318 with antialiased fonts Hi Ramiro, In which version was OCompletion not working for you? Romain On May 27, 2009, at 11:53 AM, Ramiro Diaz Trepat wrote:
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images.
r.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
Hi Romain I didnt take time to notice you, but ECompletionOmniBrowser is missing in the Pharo distrib, hence it does not work at all in OB unless you install it. On 27 mai 09, at 13:31, Romain Robbes wrote:
Hi Ramiro,
In which version was OCompletion not working for you?
Romain
On May 27, 2009, at 11:53 AM, Ramiro Diaz Trepat wrote:
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images.
r.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
Oh ok. Indeed I noticed it works in the workspace, but not in OB. How can we fix this? Just by including ECompletionOmniBrowser in the distribution? Romain On May 27, 2009, at 2:24 PM, Simon Denier wrote:
Hi Romain
I didnt take time to notice you, but ECompletionOmniBrowser is missing in the Pharo distrib, hence it does not work at all in OB unless you install it.
On 27 mai 09, at 13:31, Romain Robbes wrote:
Hi Ramiro,
In which version was OCompletion not working for you?
Romain
On May 27, 2009, at 11:53 AM, Ramiro Diaz Trepat wrote:
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images.
r.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
On 27 mai 09, at 14:49, Romain Robbes wrote:
Oh ok. Indeed I noticed it works in the workspace, but not in OB. How can we fix this? Just by including ECompletionOmniBrowser in the distribution?
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick. Also It didnt work in the workspace in the previous Pharo, but now it seems ok. Finally another bug has disappeared: duplication/shift of beginning characters when completing directly (from 'aVar', I would get 'aaVariable' when pressing tab if the first choice is ok - that was annoying)
Romain
On May 27, 2009, at 2:24 PM, Simon Denier wrote:
Hi Romain
I didnt take time to notice you, but ECompletionOmniBrowser is missing in the Pharo distrib, hence it does not work at all in OB unless you install it.
On 27 mai 09, at 13:31, Romain Robbes wrote:
Hi Ramiro,
In which version was OCompletion not working for you?
Romain
On May 27, 2009, at 11:53 AM, Ramiro Diaz Trepat wrote:
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images.
r.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
On May 27, 2009, at 3:37 PM, Simon Denier wrote:
On 27 mai 09, at 14:49, Romain Robbes wrote:
Oh ok. Indeed I noticed it works in the workspace, but not in OB. How can we fix this? Just by including ECompletionOmniBrowser in the distribution?
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick. Also It didnt work in the workspace in the previous Pharo, but now it seems ok. Finally another bug has disappeared: duplication/shift of beginning characters when completing directly (from 'aVar', I would get 'aaVariable' when pressing tab if the first choice is ok - that was annoying)
When did that one last disappear? It was supposed to be gone for a long time ... Romain
Romain
On May 27, 2009, at 2:24 PM, Simon Denier wrote:
Hi Romain
I didnt take time to notice you, but ECompletionOmniBrowser is missing in the Pharo distrib, hence it does not work at all in OB unless you install it.
On 27 mai 09, at 13:31, Romain Robbes wrote:
Hi Ramiro,
In which version was OCompletion not working for you?
Romain
On May 27, 2009, at 11:53 AM, Ramiro Diaz Trepat wrote:
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images.
r.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
On 27 mai 09, at 15:42, Romain Robbes wrote:
On May 27, 2009, at 3:37 PM, Simon Denier wrote:
On 27 mai 09, at 14:49, Romain Robbes wrote:
Oh ok. Indeed I noticed it works in the workspace, but not in OB. How can we fix this? Just by including ECompletionOmniBrowser in the distribution?
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick. Also It didnt work in the workspace in the previous Pharo, but now it seems ok. Finally another bug has disappeared: duplication/shift of beginning characters when completing directly (from 'aVar', I would get 'aaVariable' when pressing tab if the first choice is ok - that was annoying)
When did that one last disappear? It was supposed to be gone for a long time ...
I have the bug in 10309. Maybe related to Sensor fixes.
Romain
Romain
On May 27, 2009, at 2:24 PM, Simon Denier wrote:
Hi Romain
I didnt take time to notice you, but ECompletionOmniBrowser is missing in the Pharo distrib, hence it does not work at all in OB unless you install it.
On 27 mai 09, at 13:31, Romain Robbes wrote:
Hi Ramiro,
In which version was OCompletion not working for you?
Romain
On May 27, 2009, at 11:53 AM, Ramiro Diaz Trepat wrote:
Hi Damien, A couple of trivial questions Is OCompletion integrated in this version? In the previous version it had stopped suggesting. Do you know if Seaside 2.9 works with the new Pharo / closures ? Cheers, and thanks for all this great dev images.
r.
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Damien Cassou Sent: 27 May 2009 10:50 To: Pharo Development Subject: [Pharo-project] New Pharo based on core 10318 with antialiased fonts
New Pharo: http://pharo-project.org/download
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr> wrote:
Yes, installing ECompletionOmniBrowser  before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html) I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas On Wed, May 27, 2009 at 12:59 PM, Damien Cassou <damien.cassou@gmail.com>wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr> wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Nicolas, Could you open an issue in the tracker? This would significantly decrease the risk that the bug gets forgotten. Thanks, Adrian On May 27, 2009, at 20:05 , Nicolas Chillo wrote:
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html) I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas
On Wed, May 27, 2009 at 12:59 PM, Damien Cassou <damien.cassou@gmail.com
wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr> wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ready. http://code.google.com/p/pharo/issues/detail?id=849 Nicolas On Wed, May 27, 2009 at 4:10 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Hi Nicolas,
Could you open an issue in the tracker? This would significantly decrease the risk that the bug gets forgotten.
Thanks, Adrian
On May 27, 2009, at 20:05 , Nicolas Chillo wrote:
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html)
I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas
On Wed, May 27, 2009 at 12:59 PM, Damien Cassou <damien.cassou@gmail.com
wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr> wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks. No let's hope some OB maintainer picks it up... Adrian On May 27, 2009, at 21:17 , Nicolas Chillo wrote:
Ready. http://code.google.com/p/pharo/issues/detail?id=849
Nicolas
On Wed, May 27, 2009 at 4:10 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Hi Nicolas,
Could you open an issue in the tracker? This would significantly decrease the risk that the bug gets forgotten.
Thanks, Adrian
On May 27, 2009, at 20:05 , Nicolas Chillo wrote:
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html)
I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas
On Wed, May 27, 2009 at 12:59 PM, Damien Cassou <damien.cassou@gmail.com
wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr
wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What we could do is to upload both quick workaround (the one Nico did for the debugger) and the one of creating the method isClassNode which returns false. Obviously this is temporal till the real fix arrives. The ticket won't be closed. Then we add a comment in the ticket that says "to reproduce this, remove isClassNode method and do a right click on the code ....". I think this will help Pharo users. Cheers, On Wed, May 27, 2009 at 6:36 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Thanks. No let's hope some OB maintainer picks it up...
Adrian
On May 27, 2009, at 21:17 , Nicolas Chillo wrote:
Ready. http://code.google.com/p/pharo/issues/detail?id=849
Nicolas
On Wed, May 27, 2009 at 4:10 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Hi Nicolas,
Could you open an issue in the tracker? This would significantly decrease the risk that the bug gets forgotten.
Thanks, Adrian
On May 27, 2009, at 20:05 , Nicolas Chillo wrote:
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html)
I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas
On Wed, May 27, 2009 at 12:59 PM, Damien Cassou < damien.cassou@gmail.com
wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr
wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Upload where? The OB tools are not part of Pharo-core, so we cannot patch it there. Hence this really needs to go to the OB repository from which Damien creates Pharo images. I don't know much about OB and who maintains it, so could somebody tell us what the right way to get patches integrated is? Cheers, Adrian On May 27, 2009, at 22:17 , Mariano Martinez Peck wrote:
What we could do is to upload both quick workaround (the one Nico did for the debugger) and the one of creating the method isClassNode which returns false. Obviously this is temporal till the real fix arrives. The ticket won't be closed.
Then we add a comment in the ticket that says "to reproduce this, remove isClassNode method and do a right click on the code ....".
I think this will help Pharo users.
Cheers,
On Wed, May 27, 2009 at 6:36 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Thanks. No let's hope some OB maintainer picks it up...
Adrian
On May 27, 2009, at 21:17 , Nicolas Chillo wrote:
Ready. http://code.google.com/p/pharo/issues/detail?id=849
Nicolas
On Wed, May 27, 2009 at 4:10 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Hi Nicolas,
Could you open an issue in the tracker? This would significantly decrease the risk that the bug gets forgotten.
Thanks, Adrian
On May 27, 2009, at 20:05 , Nicolas Chillo wrote:
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html)
I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas
On Wed, May 27, 2009 at 12:59 PM, Damien Cassou < damien.cassou@gmail.com
wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr
wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, May 27, 2009 at 7:32 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Upload where? The OB tools are not part of Pharo-core,
Sorry. You are totally right.
so we cannot patch it there. Hence this really needs to go to the OB repository from which Damien creates Pharo images. I don't know much about OB and who maintains it, so could somebody tell us what the right way to get patches integrated is?
Cheers, Adrian
On May 27, 2009, at 22:17 , Mariano Martinez Peck wrote:
What we could do is to upload both quick workaround (the one Nico did for the debugger) and the one of creating the method isClassNode which returns false. Obviously this is temporal till the real fix arrives. The ticket won't be closed.
Then we add a comment in the ticket that says "to reproduce this, remove isClassNode method and do a right click on the code ....".
I think this will help Pharo users.
Cheers,
On Wed, May 27, 2009 at 6:36 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Thanks. No let's hope some OB maintainer picks it up...
Adrian
On May 27, 2009, at 21:17 , Nicolas Chillo wrote:
Ready. http://code.google.com/p/pharo/issues/detail?id=849
Nicolas
On Wed, May 27, 2009 at 4:10 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Hi Nicolas,
Could you open an issue in the tracker? This would significantly decrease the risk that the bug gets forgotten.
Thanks, Adrian
On May 27, 2009, at 20:05 , Nicolas Chillo wrote:
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html)
I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas
On Wed, May 27, 2009 at 12:59 PM, Damien Cassou < damien.cassou@gmail.com
wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier < Simon.Denier@inria.fr
wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, May 27, 2009 at 10:32 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Upload where?
source.wiresong.ca/ob is world-writeable -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html) I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work
Yes I used the dev version in a lecture and we could get the menu working :) Stef
It does fix the problem, but I handled it on my side. What I did is to test for it when OCompletion is installed so that I can install ECompletionOmniBrowser as needed. Hence you should not need to update the script. I also removed the questionable way I was checking for OB before. Cheers, Romain On May 27, 2009, at 5:59 PM, Damien Cassou wrote:
On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier@inria.fr> wrote:
Yes, installing ECompletionOmniBrowser before OCompletion should do the trick.
Could you please check Romain and tell me so that I can update the script?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
First let me say, I love OCompletion, first time I've found completion in Smalltalk actually helpful! Here's a few things I found a bit of though: - Font for OCompletion inherits ECompletion's behaviour of being hardcoded (O(X)MenuMorph class >>messageFont/titleFont), would it be possible to change them to one of the settable font-preferences? (Balloon-help font f.ex.) - Suggestions do not seem to be case-sensitive, even if you use uppercase in your writing. (writing f.ex. Ope lists open) - Words you've fully written are still included in suggestion list. (f.ex. open) - If a new character excludes items in the suggestion list, they are removed, but entries not in the OCompletion cache (but in the extended list) are not added to suggestions. - Type in enough characters to make the cached suggetions empty, and the extended list becomes unavailiable... - If I select to write out the entire message name (say openMenuFor: ), then hit space, the entry is not added to top of OCompletion suggestions for "open". - Two above aren't very annoying, but as far as I can tell, combined they mean the only way to add new items to the OCompletion cache is if you select it from the extended list. Cheers, Henry
Performance of UI seems poor after 832 integration. http://code.google.com/p/pharo/issues/detail?id=832 Regards, Gary
Thanks for reporting. Henrik? I could rollback the changes. Stef On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, That would be nice for a temporary measure at least, because the performance really has suffered. Assuming you roll back, would it be enough to update my 10303 image? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, May 27, 2009 12:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Thanks for reporting. Henrik? I could rollback the changes. Stef On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On May 27, 2009, at 8:03 PM, Schwab,Wilhelm K wrote:
Stef,
That would be nice for a temporary measure at least, because the performance really has suffered. Assuming you roll back, would it be enough to update my 10303 image?
To rollback I will just issue a new update. sorry for the problem one my machine I did not notice it. Stef
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Wednesday, May 27, 2009 12:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference... I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant> Cheers, Henry On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic! Cheers, Henry On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Henry, I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Wednesday, May 27, 2009 5:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic! Cheers, Henry On 27.05.2009 23:54, Henrik Sperre Johansen wrote: Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference... I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant> Cheers, Henry On 27.05.2009 19:44, Stéphane Ducasse wrote: Thanks for reporting. Henrik? I could rollback the changes. Stef On May 27, 2009, at 6:25 PM, Gary Chambers wrote: Performance of UI seems poor after 832 integration. http://code.google.com/p/pharo/issues/detail?id=832 Regards, Gary _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ________________________________ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do). Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something? Cheers, Henry Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
can you send me the st for the reverting? Stef On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail. Cheers, Henry Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'! !Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front" | drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! ! !LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front" |drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! ! !PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch." | drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! ! !TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle." super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
Yes thanks for checking. I would really like that we understand the problem On my machine I noticed no slowdown. Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Having tried it both ways, the rollback is "a must." There is probably an argument that the updated image dos a little better with it than does my 10303 image, but both benefit when the rollback is applied. As I said early, give me about a month, and I will happily wire up something slow to help test this. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Thursday, May 28, 2009 4:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Yes thanks for checking. I would really like that we understand the problem On my machine I noticed no slowdown. Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------- ----- *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proje ct
------------------------------------------------------------------ ------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
------------------------------------------------------------------- -----
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
BTW, Just a hunch, I suspect the sensor fixes might be the thing that helps in the updated image. Not only is typing slow pre-rollback, but the older image seems to be losing keystrokes. Does that make sense? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Thursday, May 28, 2009 8:35 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Having tried it both ways, the rollback is "a must." There is probably an argument that the updated image dos a little better with it than does my 10303 image, but both benefit when the rollback is applied. As I said early, give me about a month, and I will happily wire up something slow to help test this. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Thursday, May 28, 2009 4:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Yes thanks for checking. I would really like that we understand the problem On my machine I noticed no slowdown. Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------- ----- *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proje ct
------------------------------------------------------------------ ------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
------------------------------------------------------------------- -----
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What is the status of that rollback? Because if pahro get slower we should roll back Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I did some testing. During a minute of dragging/resizing windows (Class Browser, with 7-8 other windows in the background), the extra intersect happened approximately 6000 times. A small intersect speed test: a := Rectangle origin: 1@1 corner: 10@100. b := Rectangle origin: 3@0 corner: 5 @ 50. [1000000 timesRepeat:[ a intersect: b]] durationToRun 0:00:00:00.992 So, about 6 ms overhead added over the course of a minute... Unless somehow there are Morphs which ends up redrawing MORE with a consistently SMALLER damage rect, I think it'd be wise to look elsewhere for any slowdowns experienced... Cheers, Henry Stéphane Ducasse skrev:
What is the status of that rollback? Because if pahro get slower we should roll back
Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I was curious about the difference between sending duratinToRun and selecting an expression and doing "tally it", and the later presented a DNU, even attempting to tally "1 + 1" -----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Henrik Johansen Enviado el: Viernes, 12 de Junio de 2009 09:11 a.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] Issue 832 I did some testing. During a minute of dragging/resizing windows (Class Browser, with 7-8 other windows in the background), the extra intersect happened approximately 6000 times. A small intersect speed test: a := Rectangle origin: 1@1 corner: 10@100. b := Rectangle origin: 3@0 corner: 5 @ 50. [1000000 timesRepeat:[ a intersect: b]] durationToRun 0:00:00:00.992 So, about 6 ms overhead added over the course of a minute... Unless somehow there are Morphs which ends up redrawing MORE with a consistently SMALLER damage rect, I think it'd be wise to look elsewhere for any slowdowns experienced... Cheers, Henry Stéphane Ducasse skrev:
What is the status of that rollback? Because if pahro get slower we should roll back
Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
---------------------------------------------------------------------- -- *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
---------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
---------------------------------------------------------------------- --
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.524 / Virus Database: 270.12.11/2089 - Release Date: 30/04/2009 05:53 p.m.
I proposed a fix in PharoInbox. Something changed apparently in the way a compiled method may be evaluated programatically. Issue #883 Alexandre On 12 Jun 2009, at 17:29, Carlos Crosetti wrote:
I was curious about the difference between sending duratinToRun and selecting an expression and doing "tally it", and the later presented a DNU, even attempting to tally "1 + 1"
-----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Henrik Johansen Enviado el: Viernes, 12 de Junio de 2009 09:11 a.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] Issue 832
I did some testing.
During a minute of dragging/resizing windows (Class Browser, with 7-8 other windows in the background), the extra intersect happened approximately 6000 times.
A small intersect speed test: a := Rectangle origin: 1@1 corner: 10@100. b := Rectangle origin: 3@0 corner: 5 @ 50. [1000000 timesRepeat:[ a intersect: b]] durationToRun 0:00:00:00.992
So, about 6 ms overhead added over the course of a minute...
Unless somehow there are Morphs which ends up redrawing MORE with a consistently SMALLER damage rect, I think it'd be wise to look elsewhere for any slowdowns experienced...
Cheers, Henry
Stéphane Ducasse skrev:
What is the status of that rollback? Because if pahro get slower we should roll back
Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
---------------------------------------------------------------------- -- *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
---------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
---------------------------------------------------------------------- --
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.524 / Virus Database: 270.12.11/2089 - Release Date: 30/04/2009 05:53 p.m.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
The only thing which has been reported: "Having tried it both ways, the rollback is "a must." There is probably an argument that the updated image dos a little better with it than does my 10303 image, but both benefit when the rollback is applied. Bill" I see no way to reproduce the slowdown (which I don't experience) from that information. Care to share some more on exactly what version you are running when noticing/not noticing slowdowns + process that eliminated slowdown for you? Gary, got any feedback? There has been no feedback (that I've noticed) about my experience that simply saving the image would eliminate the slowdown experienced after a System... -> Software Update. Cheers, Henry Stéphane Ducasse skrev:
What is the status of that rollback? Because if pahro get slower we should roll back
Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Henry, I can try by finding when I posted the comment and looking at images from around that time. How fast do you type? When I am _really_ on, I burst at well over 100 words per minute, which might be asking a bit much from syntax highlighting, etc. But 70 wpm is probably not all that unusual - are you saying the Pharo can keep up with that? My experience is that it falls behind and almost certainly loses keystrokes. How long does it take you to open a browser? How long does it take to recompile a class to change its category? I have to say that Pharo is currently too slow for comfort in those areas for my taste. From things I have seen posted here, I suspect OB is central to a lot of it, and should perhaps be reconsidered as the toolset of choice. One post in particular pointed the finger of blame at OB's design in handling (IIRC) packages, suggested a performance enhancing design change, and as quickly ruled out making it for fear of losing backward compatibility with Squeak. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen@veloxit.no] Sent: Friday, June 12, 2009 8:29 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 feedback The only thing which has been reported: "Having tried it both ways, the rollback is "a must." There is probably an argument that the updated image dos a little better with it than does my 10303 image, but both benefit when the rollback is applied. Bill" I see no way to reproduce the slowdown (which I don't experience) from that information. Care to share some more on exactly what version you are running when noticing/not noticing slowdowns + process that eliminated slowdown for you? Gary, got any feedback? There has been no feedback (that I've noticed) about my experience that simply saving the image would eliminate the slowdown experienced after a System... -> Software Update. Cheers, Henry Stéphane Ducasse skrev:
What is the status of that rollback? Because if pahro get slower we should roll back
Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail.
Cheers, Henry
Stéphane Ducasse skrev:
can you send me the st for the reverting?
Stef
On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'!
!Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front"
|drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch."
| drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! !
!TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle."
super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
To clarify after some more mucking about: After updating 309 to 319, there's noticeable . Save that image though, and the slowdown goes away... With 309 and 318 dev images side by side, I really can't notice any performance difference. Henrik Johansen skrev:
It's strange though, for me dragging is just as slow reverting the changes I made in a 319 image... And filing in the .st in a 309 image, I notice no slow downs. (309 upgraded to 319 I do).
Are we sure nothing else causes this, perhaps changes related to events/polling frequency or something?
Cheers, Henry
Schwab,Wilhelm K skrev:
Henry,
I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this.
Bill
------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Henrik Sperre Johansen *Sent:* Wednesday, May 27, 2009 5:07 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Issue 832
Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic!
Cheers, Henry
On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference...
I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant>
Cheers, Henry
On 27.05.2009 19:44, Stéphane Ducasse wrote:
Thanks for reporting. Henrik? I could rollback the changes.
Stef
On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
Performance of UI seems poor after 832 integration.
http://code.google.com/p/pharo/issues/detail?id=832
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Henrik, Thanks for the feedback, I really appreciate it, and I will look in the issues you mentioned. Indeed inserting selectors from the extended list is a way to update the cache. The most important one however is that all the selectors contained in a method are added to the cache when it is compiled. For the case sensitivity, I was thinking the preference in ecompletion itself was enough (I myself prefer not to have it). This is also related to the non-handling of class names at the moment, which I intend to fix. Cheers, Romain On May 27, 2009, at 5:23 PM, Henrik Johansen wrote:
First let me say, I love OCompletion, first time I've found completion in Smalltalk actually helpful! Here's a few things I found a bit of though: - Font for OCompletion inherits ECompletion's behaviour of being hardcoded (O(X)MenuMorph class >>messageFont/titleFont), would it be possible to change them to one of the settable font-preferences? (Balloon-help font f.ex.) - Suggestions do not seem to be case-sensitive, even if you use uppercase in your writing. (writing f.ex. Ope lists open) - Words you've fully written are still included in suggestion list. (f.ex. open) - If a new character excludes items in the suggestion list, they are removed, but entries not in the OCompletion cache (but in the extended list) are not added to suggestions. - Type in enough characters to make the cached suggetions empty, and the extended list becomes unavailiable... - If I select to write out the entire message name (say openMenuFor: ), then hit space, the entry is not added to top of OCompletion suggestions for "open". - Two above aren't very annoying, but as far as I can tell, combined they mean the only way to add new items to the OCompletion cache is if you select it from the extended list.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
participants (14)
-
Adrian Lienhard -
Alexandre Bergel -
Carlos Crosetti -
Damien Cassou -
Gary Chambers -
Henrik Johansen -
Henrik Sperre Johansen
-
Mariano Martinez Peck -
Nicolas Chillo -
Ramiro Diaz Trepat -
Romain Robbes -
Schwab,Wilhelm K -
Simon Denier -
Stéphane Ducasse