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

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Metacello will be used to identify stable versions of the packages that are known to work and there is an ongoing effort to create Metacello configurations for all of the projects that go into the dev and web images.

So that part of the puzzle is being addressed.

Dale

----- "Mariano Martinez Peck" <[hidden email]> wrote:

| 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
| <[hidden email]
| > 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
| > > [hidden email]
| > >
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >
| >
| > _______________________________________________
| > Pharo-project mailing list
| > [hidden email]
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]>
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: [hidden email]



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-image-e-g-OBClassNode-Object-doesNotUnderstans-tp4233114p4233114.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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.

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]>
> 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 <[hidden email]>
> 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: [hidden email]
>
>
>
> 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-image-e-g-OBClassNode-Object-doesNotUnderstans-tp4233114p4233114.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project