[Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols
Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens. We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed to be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse. I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image. Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers. I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :( I don't know the best solution for this. I will only give an idea I have, but I would really like to hear you ideas and do something with this. 1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built. 2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea. 3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click. In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar. What do you think ? Cheers Mariano ---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414@gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project@lists.gforge.inria.fr NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2 Class browser used (if applicable): OR2PackageBrowser. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method navigation: an O2DefaultEdgeNavigation isDropEdge: nil ... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev-... Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I agree.! Now what I suggest is that we do not release a pharo-dev image without having tested it.
Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens.
I agree.
We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed to be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse.
:)
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers.
I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :(
yes
1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built.
2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea.
This is a good idea.
3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click.
Let us give a try. Now we should fix the current one.
In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar.
What do you think ?
Sounds cool.
Cheers
Mariano
---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414@gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project@lists.gforge.inria.fr
NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan
VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2
Class browser used (if applicable): OR2PackageBrowser.
OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray
O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method
navigation: an O2DefaultEdgeNavigation isDropEdge: nil
... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev-... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ 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 have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
This is what I am telling for years already. I don't know how other people think about this, but to me it feels very embarrassing to have to advertise my own way of building images over and over again? Here is it again: I am using the scripts <http://code.google.com/p/pharo/wiki/ImageBuildScripts> to get from a Pharo 1.0rc1 a fast and stable development and deployment image. The image loads a well tested and fast OB, a working and well tested refactoring engine, working syntax highlighting, working code completion, and several other tools I use daily and that I cannot work without. I am not telling it is bug free, but with my personal workflow I can use it without getting interrupted by bugs all the time. And when I encounter a bug, I fix it. I don't think that somebody can build a stable distribution without using it 12 hours daily. Have a look at PharoCore, it is only rock solid because Stef is using it all day long to integrate fixes. Have a look at Squeak Trunk, it only sees improvement because Andreas is using it all day long. Have a look at Debian, Gentoo, ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Yes lukas now damien was nice to build the images because I could not do them. But damien is doing Java daily. And you do not like the package browser and we need it :). So I do not know what to do. - first we should add simple trait creation to the OB - now frankly I do not know how we could manage moose without the package browser. Stef On Dec 30, 2009, at 7:16 PM, Lukas Renggli wrote:
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
This is what I am telling for years already. I don't know how other people think about this, but to me it feels very embarrassing to have to advertise my own way of building images over and over again?
Here is it again: I am using the scripts <http://code.google.com/p/pharo/wiki/ImageBuildScripts> to get from a Pharo 1.0rc1 a fast and stable development and deployment image. The image loads a well tested and fast OB, a working and well tested refactoring engine, working syntax highlighting, working code completion, and several other tools I use daily and that I cannot work without. I am not telling it is bug free, but with my personal workflow I can use it without getting interrupted by bugs all the time. And when I encounter a bug, I fix it.
I don't think that somebody can build a stable distribution without using it 12 hours daily. Have a look at PharoCore, it is only rock solid because Stef is using it all day long to integrate fixes. Have a look at Squeak Trunk, it only sees improvement because Andreas is using it all day long. Have a look at Debian, Gentoo, ...
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks Lukas to be agree. I like your scripts, but the problem is that you use your own forked repository to get an stable version. I would love to have THAT, but in the original repositories. Examples: omnibrowser, unsorted, etc. Do you know how we can fix this ? On Wed, Dec 30, 2009 at 7:25 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Yes lukas now damien was nice to build the images because I could not do them. But damien is doing Java daily.
Of course this is not Damien fault. Everybody here do as much as possible.
And you do not like the package browser and we need it :).
So I do not know what to do. - first we should add simple trait creation to the OB - now frankly I do not know how we could manage moose without the package browser.
Yes, most of the problems in a dev image are related usually with the system browser :(
Stef
On Dec 30, 2009, at 7:16 PM, Lukas Renggli wrote:
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
This is what I am telling for years already. I don't know how other people think about this, but to me it feels very embarrassing to have to advertise my own way of building images over and over again?
Here is it again: I am using the scripts <http://code.google.com/p/pharo/wiki/ImageBuildScripts> to get from a Pharo 1.0rc1 a fast and stable development and deployment image. The image loads a well tested and fast OB, a working and well tested refactoring engine, working syntax highlighting, working code completion, and several other tools I use daily and that I cannot work without. I am not telling it is bug free, but with my personal workflow I can use it without getting interrupted by bugs all the time. And when I encounter a bug, I fix it.
I don't think that somebody can build a stable distribution without using it 12 hours daily. Have a look at PharoCore, it is only rock solid because Stef is using it all day long to integrate fixes. Have a look at Squeak Trunk, it only sees improvement because Andreas is using it all day long. Have a look at Debian, Gentoo, ...
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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 Lukas to be agree. I like your scripts, but the problem is that you use your own forked repository to get an stable version. I would love to have THAT, but in the original repositories. Examples: omnibrowser, unsorted, etc. Do you know how we can fix this ?
Well, if you want to do a stable distribution you need to fork, even if you just copy the versions to a separate repository. We learned this with Seaside 3.0alpha1 the hard way. Servers disappear, repositories disappear, versions get deleted, versions get renamed or replaced. When we release a Seaside version we always copy all the dependencies to a single place that we control, e.g. <http://builder.seaside.st/distributions/004-Seaside3.0.0-a5/>. Forking is not something bad. Fork early and fork often. Forking is good. Monticello is excellent at merging. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Thanks Lukas to be agree. I like your scripts, but the problem is that you use your own forked repository to get an stable version. I would love to have THAT, but in the original repositories. Examples: omnibrowser, unsorted, etc. Do you know how we can fix this ?
Well, if you want to do a stable distribution you need to fork, even if you just copy the versions to a separate repository.
We learned this with Seaside 3.0alpha1 the hard way. Servers disappear, repositories disappear, versions get deleted, versions get renamed or replaced. When we release a Seaside version we always copy all the dependencies to a single place that we control, e.g. <http://builder.seaside.st/distributions/004-Seaside3.0.0-a5/>.
oh yes we did the same with squeak3.9 and for pharo. Stef
In addition to providing a nice service of building the images, Damien is really just the messenger. We can either have the latest and greatest of whatever various parties produce, or we can have an acceptance process and/or our own forks of packages that are known to be stable. Even with controls in place, we probably should have some type of testing period. One relatively easy way to accomplish that would be to show both the most recent dev and web builds and "last month's" versions on the download page. Anything we can do to prevent recurring bugs (the class/method node tests, anything that brings automated builds to a halt, etc.) will make it easier on people to test the latest images. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Wednesday, December 30, 2009 1:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Thanks Lukas to be agree. I like your scripts, but the problem is that you use your own forked repository to get an stable version. I would love to have THAT, but in the original repositories. Examples: omnibrowser, unsorted, etc. Do you know how we can fix this ? On Wed, Dec 30, 2009 at 7:25 PM, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Yes lukas now damien was nice to build the images because I could not do them. But damien is doing Java daily. Of course this is not Damien fault. Everybody here do as much as possible. And you do not like the package browser and we need it :). So I do not know what to do. - first we should add simple trait creation to the OB - now frankly I do not know how we could manage moose without the package browser. Yes, most of the problems in a dev image are related usually with the system browser :( Stef On Dec 30, 2009, at 7:16 PM, Lukas Renggli wrote:
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
This is what I am telling for years already. I don't know how other people think about this, but to me it feels very embarrassing to have to advertise my own way of building images over and over again?
Here is it again: I am using the scripts <http://code.google.com/p/pharo/wiki/ImageBuildScripts> to get from a Pharo 1.0rc1 a fast and stable development and deployment image. The image loads a well tested and fast OB, a working and well tested refactoring engine, working syntax highlighting, working code completion, and several other tools I use daily and that I cannot work without. I am not telling it is bug free, but with my personal workflow I can use it without getting interrupted by bugs all the time. And when I encounter a bug, I fix it.
I don't think that somebody can build a stable distribution without using it 12 hours daily. Have a look at PharoCore, it is only rock solid because Stef is using it all day long to integrate fixes. Have a look at Squeak Trunk, it only sees improvement because Andreas is using it all day long. Have a look at Debian, Gentoo, ...
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
Yes lukas now damien was nice to build the images because I could not do them. But damien is doing Java daily.
Yes, I know. This is definitely not the fault of Damien, he is doing an excellent job in integrating, merging and fixing the obvious bugs. The problem is that nobody that uses the image 12 hours daily is taking responsibility.
So I do not know what to do. Â Â Â Â - first we should add simple trait creation to the OB Â Â Â Â - now frankly I do not know how we could manage moose without the package browser.
Then somebody that uses OB and Traits daily should commit on that. I am not a trait user, so I can't help here. The same for the package browser: I am pretty happy with OB, the package browser of OB-Refactory, and Gofer to manage the 75 Seaside packages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Yes we should find somebody. I will ask around. Stef On Dec 30, 2009, at 8:05 PM, Lukas Renggli wrote:
Yes lukas now damien was nice to build the images because I could not do them. But damien is doing Java daily.
Yes, I know. This is definitely not the fault of Damien, he is doing an excellent job in integrating, merging and fixing the obvious bugs. The problem is that nobody that uses the image 12 hours daily is taking responsibility.
So I do not know what to do. - first we should add simple trait creation to the OB - now frankly I do not know how we could manage moose without the package browser.
Then somebody that uses OB and Traits daily should commit on that. I am not a trait user, so I can't help here. The same for the package browser: I am pretty happy with OB, the package browser of OB-Refactory, and Gofer to manage the 75 Seaside packages.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas Renggli <renggli@...> writes:
Then somebody that uses OB and Traits daily should commit on that. I am not a trait user, so I can't help here. The same for the package browser: I am pretty happy with OB, the package browser of OB-Refactory, and Gofer to manage the 75 Seaside packages.
+1 yellow browsers are awesome to work with packages! NB: when you halo-copy-paste the menu items to open your most used packages to the background and rename them to the package name, then you even get a 1-click way to open your yellow browsers. I work one hour a day with one trait :) will do my best to report all bugs I find. There is not much, and most of them can be fixed by adding #superclass, #isVariable and #parseTreeFor to TraitBehavior. See my fix for issue 1666 Other than OP, I find the 1.0 dev image rather stable (mebbe OP is speaking of 1.1 dev image ???). The one thing one has to do to get a stable dev image is to *revert* the loaded OB-Refactory package to the loaded version such that O2 clutter is reverted to the right OB methods. Mebbe changing the load order when creating the dev image might help to avoid that issue. Else I am totally happy with the dev image. --AA
On Thu, Dec 31, 2009 at 1:19 AM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
Lukas Renggli <renggli@...> writes:
Then somebody that uses OB and Traits daily should commit on that. I am not a trait user, so I can't help here. The same for the package browser: I am pretty happy with OB, the package browser of OB-Refactory, and Gofer to manage the 75 Seaside packages.
+1 yellow browsers are awesome to work with packages!
NB: when you halo-copy-paste the menu items to open your most used packages to the background and rename them to the package name, then you even get a 1-click way to open your yellow browsers.
I work one hour a day with one trait :) will do my best to report all bugs I find. There is not much, and most of them can be fixed by adding #superclass, #isVariable and #parseTreeFor to TraitBehavior. See my fix for issue 1666
Other than OP, I find the 1.0 dev image rather stable (mebbe OP is speaking of 1.1 dev image ???).
What's OP ? Depending which version are you talking about. 10496 seems to be very stable for me. I have been using it 12 hours a day for the last 20 days and no problem except the double copy paste. With 10502 I cannot even click on a class neither in the code panel. Look the opened issues: http://code.google.com/p/pharo/issues/detail?id=1182 http://code.google.com/p/pharo/issues/detail?id=1724 http://code.google.com/p/pharo/issues/detail?id=1721
The one thing one has to do to get a stable dev image is to *revert* the loaded OB-Refactory package to the loaded version such that O2 clutter is reverted to the right OB methods. Mebbe changing the load order when creating the dev image might help to avoid that issue.
Adrian, would you mind explaining a bit more in details this problem ? Thank you very much. Mariano
Else I am totally happy with the dev image.
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck <marianopeck@...> writes:
What's OP?
Original Poster
With 10502 I cannot even click on a class neither in the code panel.
I use 10502 and I observe no such bugs (using OB, not O2 though).
The one thing one has to do to get a stable dev image is to *revert* [..]
Adrian, would you mind explaining a bit more in details this problem ?
Open a fresh image and execute Gofer it wiresong: 'ob'; package: 'OB-Refactory'; revert this will revert all conflicting package extensions of O2 back to those of OB so that you can work with both the green and the yellow browser of OB. --AA
On Thu, Dec 31, 2009 at 1:54 AM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
Mariano Martinez Peck <marianopeck@...> writes:
What's OP?
Original Poster
With 10502 I cannot even click on a class neither in the code panel.
I use 10502 and I observe no such bugs (using OB, not O2 though).
mmm are you sure about 1182 ??? And this is not a "simple" bug, YOU CANNOT EVEN DO a right click. I can reproduce it in OB.
The one thing one has to do to get a stable dev image is to *revert* [..]
Adrian, would you mind explaining a bit more in details this problem ?
Open a fresh image and execute
Gofer it wiresong: 'ob'; package: 'OB-Refactory'; revert
this will revert all conflicting package extensions of O2 back to those of OB so that you can work with both the green and the yellow browser of OB.
Ok, thanks Adrian. I think we should fix this. I till try it. I would like to hear the opinion of David of Lukas about doing this in the script we use to build images. Cheers Mariano --AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I highly agree also !! Its related to Pharo for Professional Development<http://lists.gforge.inria.fr/pipermail/pharo-project/2009-December/017583.html>thread I started 2 weeks ago. It basically says the same. My gut feeling is still that stability should be the number one focus. Its great to innovate, but innovation must not harm stability. For me stability is keeping regression bugs to a minimum. To test the stability of the GUI/Morphic parts of Pharo, I started to create a little project: http://www.squeaksource.com/MorphicsRecordNPlay/. This can record mouse events and replay them afterwards. My idea was to take this as a sort of automated integration testing of Pharo. You can then record all kinds of stuff: opening a browser, clicking on a class, try every option out, ... . I've also attempted to automatically convert these recordings into sunit test cases so they can be automatically replayed, but I stumbled upon following limitation : Long method can not be compiled using #compile: aString<http://lists.gforge.inria.fr/pipermail/pharo-project/2009-December/017730.ht...>. Havent looked into it further yet. Any ideas here how these can be replayed? Kind Regards, Bart 2009/12/30 Mariano Martinez Peck <marianopeck@gmail.com>
Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens. We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed to be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse.
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers.
I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :(
I don't know the best solution for this. I will only give an idea I have, but I would really like to hear you ideas and do something with this.
1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built.
2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea.
3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click.
In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar.
What do you think ?
Cheers
Mariano
---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414@gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project@lists.gforge.inria.fr
NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan
VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2
Class browser used (if applicable): OR2PackageBrowser.
OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray
O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method
navigation: an O2DefaultEdgeNavigation isDropEdge: nil
... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev-... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ 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
-- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill
Bart in Morphic may be this is not broken in 3.9 there was a recordMorph that recorded the mouse location and that could be replied after. I read the code long time ago and forgot but may. I remember that on VisualAge there was a tool to capture and replay UI tests. So I would be really interested to see how far you can go with your idea. On Dec 30, 2009, at 8:50 PM, Bart Gauquie wrote:
I highly agree also !!
Its related to Pharo for Professional Development thread I started 2 weeks ago. It basically says the same. My gut feeling is still that stability should be the number one focus. Its great to innovate, but innovation must not harm stability.
For me stability is keeping regression bugs to a minimum. To test the stability of the GUI/Morphic parts of Pharo, I started to create a little project: http://www.squeaksource.com/MorphicsRecordNPlay/. This can record mouse events and replay them afterwards. My idea was to take this as a sort of automated integration testing of Pharo. You can then record all kinds of stuff: opening a browser, clicking on a class, try every option out, ... . I've also attempted to automatically convert these recordings into sunit test cases so they can be automatically replayed, but I stumbled upon following limitation : Long method can not be compiled using #compile: aString. Havent looked into it further yet. Any ideas here how these can be replayed?
Kind Regards,
Bart
2009/12/30 Mariano Martinez Peck <marianopeck@gmail.com> Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens. We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed to be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse.
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers.
I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :(
I don't know the best solution for this. I will only give an idea I have, but I would really like to hear you ideas and do something with this.
1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built.
2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea.
3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click.
In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar.
What do you think ?
Cheers
Mariano
---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414@gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project@lists.gforge.inria.fr
NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan
VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2
Class browser used (if applicable): OR2PackageBrowser.
OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray
O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method
navigation: an O2DefaultEdgeNavigation isDropEdge: nil
... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev-... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ 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
-- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The main problem is that we are not integrating enough. Please, take 5 minutes and see this example: Open http://source.wiresong.ca/ob In pharo1.0-10502-rc1dev09.12.2 the version loaded is OB-Standard-DamienCassou.438 which actually loads the OB-Standard-lr.434. I really don't understand why this. Is this a hack to our script to build dev images ??? Why we need to push up again a version ? Moreover, what happened with OB-Standard-DavidRoethlisberger.437 ? I was not integratd (if I understood correctly). So, the issue 1373 may be alive again. And what about the fix of OB-Standard-DavidRoethlisberger.434 ? and OB-Standard-dr.433 432 431 430 ... what happens with all those commits ? They don't seem to be merged. Is there a reason for this ? I am reading ok the commits ? Thanks Mariano On Wed, Dec 30, 2009 at 9:34 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Bart in Morphic may be this is not broken in 3.9 there was a recordMorph that recorded the mouse location and that could be replied after. I read the code long time ago and forgot but may.
I remember that on VisualAge there was a tool to capture and replay UI tests. So I would be really interested to see how far you can go with your idea.
On Dec 30, 2009, at 8:50 PM, Bart Gauquie wrote:
I highly agree also !!
Its related to Pharo for Professional Development thread I started 2 weeks ago. It basically says the same. My gut feeling is still that stability should be the number one focus. Its great to innovate, but innovation must not harm stability.
For me stability is keeping regression bugs to a minimum. To test the stability of the GUI/Morphic parts of Pharo, I started to create a little project: http://www.squeaksource.com/MorphicsRecordNPlay/. This can record mouse events and replay them afterwards. My idea was to take this as a sort of automated integration testing of Pharo. You can then record all kinds of stuff: opening a browser, clicking on a class, try every option out, ... . I've also attempted to automatically convert these recordings into sunit test cases so they can be automatically replayed, but I stumbled upon following limitation : Long method can not be compiled using #compile: aString. Havent looked into it further yet. Any ideas here how these can be replayed?
Kind Regards,
Bart
2009/12/30 Mariano Martinez Peck <marianopeck@gmail.com> Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens. We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed to be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse.
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers.
I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :(
I don't know the best solution for this. I will only give an idea I have, but I would really like to hear you ideas and do something with this.
1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built.
2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea.
3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click.
In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar.
What do you think ?
Cheers
Mariano
---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414@gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project@lists.gforge.inria.fr
NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan
VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2
Class browser used (if applicable): OR2PackageBrowser.
OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray
O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method
navigation: an O2DefaultEdgeNavigation isDropEdge: nil
... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev-... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ 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
-- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill _______________________________________________ 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
Em 30/12/2009 17:50, Bart Gauquie < bart.gauquie@gmail.com > escreveu:
I highly agree also !! Its related to Pharo for Professional Development thread I started 2 weeks ago. It basically says the same. My gut feeling is still that stability should be the number one focus. Its great to innovate, but innovation must not harm stability. For me stability is keeping regression bugs to a minimum. To test the stability of the GUI/Morphic parts of Pharo, I started to create a little project: http://www.squeaksource.com/MorphicsRecordNPlay/.
This can record mouse events and replay them afterwards. My idea was to take this as a sort of automated integration testing of Pharo.
You can then record all kinds of stuff: opening a browser, clicking on a class, try every option out, ... . I've also attempted to automatically convert these recordings into sunit test cases so they can be automatically replayed, but I stumbled upon following limitation: Long method can not be compiled using #compile: aString. Haven't looked into it further yet. Any ideas here how these can be replayed?
Bart, Can't you store the events in a collection and run them iterating over the collected events instead of attempting to compile all them at once? -- Cesar Rabak
Mariano Martinez Peck wrote:
Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens. We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed to be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse.
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers.
I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :(
I don't know the best solution for this. I will only give an idea I have, but I would really like to hear you ideas and do something with this.
1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built.
2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea.
3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click.
In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar.
What do you think ?
Cheers
Mariano
---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414@gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project@lists.gforge.inria.fr
NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan
VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2
Class browser used (if applicable): OR2PackageBrowser.
OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class
Mariano Martinez Peck wrote:
... volunteer to be beta tester ?
I volunteer. And being on Linux and a mouse user, I seem to hit a lot of the wrinkles. Mariano Martinez Peck wrote:
I don't know the best solution for this
Mariano, Adrian's fix does indeed seem to fix up this whole area. After running it, I can get right through the menus to run code critics, and right/left/middle clicks don't cause problem. It would seem the image on the download page should be replaced ASAP with one which has had this operation. Adrian Kuhn wrote:
Gofer it wiresong: 'ob'; package: 'OB-Refactory'; revert
this will revert all conflicting package extensions of O2 back to those of OB so that you can work with both the green and the yellow browser of OB.
Mariano, thanks for bringing this into sharp focus. As Bart identified, it's been a real concern that our "shop window" has been broken like this. ...Stan -- View this message in context: http://n2.nabble.com/We-need-to-do-something-seriously-WAS-Fwd-Issue-1721-Re... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Thu, Dec 31, 2009 at 11:32 AM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano Martinez Peck wrote:
Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens. We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed
to
be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse.
I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image.
Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers.
I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :(
I don't know the best solution for this. I will only give an idea I have, but I would really like to hear you ideas and do something with this.
1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built.
2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea.
3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click.
In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar.
What do you think ?
Cheers
Mariano
---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414@gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project@lists.gforge.inria.fr
NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan
VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2
Class browser used (if applicable): OR2PackageBrowser.
OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class
Mariano Martinez Peck wrote:
... volunteer to be beta tester ?
I volunteer. And being on Linux and a mouse user, I seem to hit a lot of the wrinkles.
Ok, perfect. I will open another thread for this then.
Mariano Martinez Peck wrote:
I don't know the best solution for this
Mariano, Adrian's fix does indeed seem to fix up this whole area. After running it, I can get right through the menus to run code critics, and right/left/middle clicks don't cause problem. It would seem the image on the download page should be replaced ASAP with one which has had this operation.
Yes, I am agree. Can someone do this please? I have no idea how to do it neither I have the rights. I just to pick up the latest dev and web image from the website evaluate Gofer it wiresong: 'ob'; package: 'OB-Refactory'; revert save it and upload it again. In addition, we have to take a decision here: 1) Remove O2 from the script until O2 has NO dependencies and overrides in OB and until O2 loads perfectly in a core image without anything about OB. Those who want to use it anyway, can install by their self. 2) Add this piece of hack to our script. Opinions ?
Adrian Kuhn wrote:
Gofer it wiresong: 'ob'; package: 'OB-Refactory'; revert
this will revert all conflicting package extensions of O2 back to those
of
OB so that you can work with both the green and the yellow browser of OB.
Mariano, thanks for bringing this into sharp focus. As Bart identified, it's been a real concern that our "shop window" has been broken like this.
You are welcome. I don't pretend Pharo to be rock solid. But I pretend not to have those errors were you cannot even browse a class or right click on the code. Cheers Mariano
...Stan
-- View this message in context: http://n2.nabble.com/We-need-to-do-something-seriously-WAS-Fwd-Issue-1721-Re... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano May be you can contact david probably on holidays to see how we can make progress? I know that we can publish in david repository so may be a lot of the problems are simple glicth. Having a configuration for O2 would be good. Here is what david wrote to me the 20th. O2 is stored here: http://www.squeaksource.com/EnhancedOB this repo is globally writable. ps: I will get to your other mails soon, I was a bit sick in the last few days and took some days off. David Stef
On Thu, Dec 31, 2009 at 11:54 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Mariano
May be you can contact david probably on holidays to see how we can make progress? I know that we can publish in david repository so may be a lot of the problems are simple glicth. Having a configuration for O2 would be good.
Sorry, I forgot to mention this...I have already contact David 1 o 2 days ago because I already wrote a ConfigurationOfEnhancedOmniBrowser and I had questions about it dependencies. I discovered some problems with them and ask David. He fixed one of this dependencies, but the one from O2-Refactory is still present and maybe we will fix it next week or similar...he doesn't have too much time. What I am not sure, David, can you confirm this ? is if what we talk in our private email a about the O2-Refactory (the problem we still have) is the same problem we are talking here. Because, in my opinion, one thing is just to depend and another thing is to depend and override. If there are overrides, it matters the order and a lot more stuff. That's why I am asking you :) Is it the same? I hope so :) Cheers. Mariano
Here is what david wrote to me the 20th.
O2 is stored here: http://www.squeaksource.com/EnhancedOB
this repo is globally writable.
ps: I will get to your other mails soon, I was a bit sick in the last few days and took some days off.
David
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck wrote:
Mariano, Adrian's fix does indeed seem to fix up this whole area. After running it, I can get right through the menus to run code critics, and right/left/middle clicks don't cause problem. It would seem the image on the download page should be replaced ASAP with one which has had this operation.
Yes, I am agree. Can someone do this please? I have no idea how to do it neither I have the rights.
I just to pick up the latest dev and web image from the website evaluate
Gofer it wiresong: 'ob'; package: 'OB-Refactory'; revert
save it and upload it again.
In addition, we have to take a decision here:
1) Remove O2 from the script until O2 has NO dependencies and overrides in OB and until O2 loads perfectly in a core image without anything about OB. Those who want to use it anyway, can install by their self. 2) Add this piece of hack to our script.
I might have clicked too soon. This seems to reintroduce Issue 1644: BrowserEnvironment(Object)>>doesNotUnderstand: #forPackage: ...Stan -- View this message in context: http://n2.nabble.com/We-need-to-do-something-seriously-WAS-Fwd-Issue-1721-Re... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (8)
-
Adrian Kuhn -
Bart Gauquie -
csrabak＠bol.com.br -
Lukas Renggli -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Stan Shepherd -
Stéphane Ducasse