Hi everyone! Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter. Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta- <https://github.com/Uko/QualityAssistant#quality-assistant-beta->. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects. Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code. Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues Have a nice week! Uko
this is so good. what about integrate it to Pharo? cheers, Esteban
On 22 Apr 2015, at 08:58, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone!
Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter.
Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta- <https://github.com/Uko/QualityAssistant#quality-assistant-beta->. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects.
Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code.
Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues <https://github.com/Uko/QualityAssistant/issues>
Have a nice week! Uko
<critics.jpg>
I am definitely interested in it. Let me know what I should do for this. I havenât got a lot of feedback from users, but I fixed problems reported by my group and Alex Bergel. The remaining reported issues are quite minor and related to how SmallLint works. Changes to SmallLint will arrive later after I figure out what the rules are about and what is the way to improve them. Cheers, Uko
On 22 Apr 2015, at 12:23, Esteban Lorenzano <estebanlm@gmail.com> wrote:
this is so good. what about integrate it to Pharo?
cheers, Esteban
On 22 Apr 2015, at 08:58, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
Hi everyone!
Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter.
Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta- <https://github.com/Uko/QualityAssistant#quality-assistant-beta->. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects.
Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code.
Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues <https://github.com/Uko/QualityAssistant/issues>
Have a nice week! Uko
<critics.jpg>
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason. Stef
cheers, Esteban
On 22 Apr 2015, at 08:58, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
Hi everyone!
Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter.
Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta-. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects.
Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code.
Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues
Have a nice week! Uko
<critics.jpg>
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use. We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double? If we do not make the Pharo that is downloaded to be that was is used, we will have that again. I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step. Marcus
Two things: One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it. Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now. So to me it simply means that we are not serious and convinced about modularity. But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this. Stef Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) makes the system less modular. Especially if the price we pay for that is a system where good tools are available, but nobody uses them.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
You always directly go and argue by âI am now sadâ purely emotional level. This is not good. Marcus
Le 23/4/15 09:05, Marcus Denker a écrit :
I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) makes the system less modular. Then why the dependency Browser was not integrated? Why roassal for drawing dependencies and other aspects of the system? Because dependency browser as well as roassal are really useful, well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process. In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool. Strange for scientific people no? I think that we should have a building process that load tools. We will not be able to put everything in the image: Did you look at the dependencies between RB, nautilus, history, EyeInspector? I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours fixing configurations that nobody use or look at. But you see this period is ***over***.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
You always directly go and argue by âI am now sadâ purely emotional level. This is not good. Read what you want to read. But my energy in neither cheap nor infinite anymore. This is not a feeling but just a mere fact.
Marcus
I totally agree with Stef that we should be able to do a rock solid setup of what tools we want to use in our everyday image. But on the other hand we have to design what Pharo is. Because we can even go Ruby style and say that debugger is not a part of the main system, but I see that our strength is to provide people with ultimate tools for development (although we cannot put everything inside). And I think that dependency browser is important and I will continue to convince people that quality of code is important and that we should use quality tools in our daily work. Maybe now QualityAssistant is not mature enough, but at some point it will be :). Cheers. Uko P.S. at the moment we are loosing competition to JetBrains tools because they give you live feedback about code critics.
On 23 Apr 2015, at 09:04, stepharo <stepharo@free.fr> wrote:
Le 23/4/15 09:05, Marcus Denker a écrit :
I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) makes the system less modular. Then why the dependency Browser was not integrated? Why roassal for drawing dependencies and other aspects of the system? Because dependency browser as well as roassal are really useful, well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process. In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool. Strange for scientific people no? I think that we should have a building process that load tools. We will not be able to put everything in the image: Did you look at the dependencies between RB, nautilus, history, EyeInspector? I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours fixing configurations that nobody use or look at. But you see this period is ***over***.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
You always directly go and argue by âI am now sadâ purely emotional level. This is not good. Read what you want to read. But my energy in neither cheap nor infinite anymore. This is not a feeling but just a mere fact.
Marcus
I understand the point of marcus but still it is unclear why certain tools should be in and not others. Now I would prefer that we have a process that 1 := take a miniimage AND load the tools check that we can unload them (just to check) and only then declare pharo := 1. Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread) Read the Pharo vision paper. Stef Le 23/4/15 10:53, Yuriy Tymchuk a écrit :
I totally agree with Stef that we should be able to do a rock solid setup of what tools we want to use in our everyday image.
But on the other hand we have to design what Pharo is. Because we can even go Ruby style and say that debugger is not a part of the main system, but I see that our strength is to provide people with ultimate tools for development (although we cannot put everything inside). And I think that dependency browser is important and I will continue to convince people that quality of code is important and that we should use quality tools in our daily work. Maybe now QualityAssistant is not mature enough, but at some point it will be :).
Cheers. Uko
P.S. at the moment we are loosing competition to JetBrains tools because they give you live feedback about code critics.
On 23 Apr 2015, at 09:04, stepharo <stepharo@free.fr> wrote:
Le 23/4/15 09:05, Marcus Denker a écrit :
I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) makes the system less modular. Then why the dependency Browser was not integrated? Why roassal for drawing dependencies and other aspects of the system? Because dependency browser as well as roassal are really useful, well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process. In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool. Strange for scientific people no? I think that we should have a building process that load tools. We will not be able to put everything in the image: Did you look at the dependencies between RB, nautilus, history, EyeInspector? I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours fixing configurations that nobody use or look at. But you see this period is ***over***.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
You always directly go and argue by âI am now sadâ purely emotional level. This is not good. Read what you want to read. But my energy in neither cheap nor infinite anymore. This is not a feeling but just a mere fact.
Marcus
On 24 Apr 2015, at 8:41 , stepharo <stepharo@free.fr> wrote:
I understand the point of marcus but still it is unclear why certain tools should be in and not others. Now I would prefer that we have a process that
1 := take a miniimage AND load the tools check that we can unload them (just to check) and only then declare
pharo := 1.
Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread) Read the Pharo vision paper.
Stef
The problem with Pharo-Dev in olden days wasn't that no one used the image, but that there was no good process for pushing required updates to "external" packages, so it was more convenient to just develop in the Core image, and leave the other packages for their maintainers to update at the end of a cycle. I don't think the best answer is to pull more and more packages into the Pharo "Core" repository and effectively do double versioning, as seems to be the trend lately... Why not require write access to repositories of external projects that are included in a Pharo-Dev image? Then you can have the Pharo team responsible for a (currently) #Pharo5 symbolic version in the Configuration. Then, when merging slices, push updates to external repos as appropriate (updating #Pharo5 version in Conf), and build new Dev image from a list of such approved Configurations. Lets the external developer do improvements against a static version, and merge with latest non-release when appropriate without leaving the comfort of a single repository. Cheers, Henry
The problem with Pharo-Dev in olden days wasn't that no one used the image, but that there was no good process for pushing required updates to "external" packages, so it was more convenient to just develop in the Core image, and leave the other packages for their maintainers to update at the end of a cycle. I don't think the best answer is to pull more and more packages into the Pharo "Core" repository and effectively do double versioning, as seems to be the trend lately... It is not really the case, because the external projects are autonomous. Why not require write access to repositories of external projects that are included in a Pharo-Dev image? Then you can have the Pharo team responsible for a (currently) #Pharo5 symbolic version in the Configuration. It could be the trick. But people will have to merge our changes. Then, when merging slices, push updates to external repos as appropriate (updating #Pharo5 version in Conf), and build new Dev image from a list of such approved Configurations. Lets the external developer do improvements against a static version, and merge with latest non-release when appropriate without leaving the comfort of a single repository. So we have when we integrate from a project a given version and when we push to the project a symbolic version but it can lead to some mess, no? Cheers, Henry
On 24 Apr 2015, at 08:41, stepharo <stepharo@free.fr> wrote:
I understand the point of marcus but still it is unclear why certain tools should be in and not others. Now I would prefer that we have a process that
1 := take a miniimage AND load the tools check that we can unload them (just to check) and only then declare
pharo := 1.
Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread) Read the Pharo vision paper.
we will have it. Iâm slowly (very slowly) working on that.
Stef
Le 23/4/15 10:53, Yuriy Tymchuk a écrit :
I totally agree with Stef that we should be able to do a rock solid setup of what tools we want to use in our everyday image.
But on the other hand we have to design what Pharo is. Because we can even go Ruby style and say that debugger is not a part of the main system, but I see that our strength is to provide people with ultimate tools for development (although we cannot put everything inside). And I think that dependency browser is important and I will continue to convince people that quality of code is important and that we should use quality tools in our daily work. Maybe now QualityAssistant is not mature enough, but at some point it will be :).
Cheers. Uko
P.S. at the moment we are loosing competition to JetBrains tools because they give you live feedback about code critics.
On 23 Apr 2015, at 09:04, stepharo <stepharo@free.fr> wrote:
Le 23/4/15 09:05, Marcus Denker a écrit :
I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) makes the system less modular. Then why the dependency Browser was not integrated? Why roassal for drawing dependencies and other aspects of the system? Because dependency browser as well as roassal are really useful, well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process. In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool. Strange for scientific people no? I think that we should have a building process that load tools. We will not be able to put everything in the image: Did you look at the dependencies between RB, nautilus, history, EyeInspector? I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours fixing configurations that nobody use or look at. But you see this period is ***over***.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
You always directly go and argue by âI am now sadâ purely emotional level. This is not good. Read what you want to read. But my energy in neither cheap nor infinite anymore. This is not a feeling but just a mere fact.
Marcus
Can someone explain to me what is the difference between "loading a tool" and "put something in the image" ? I thought we all agree that the atomic image should shrink as far as it can and everything should be loaded on top. If that is the case we can also agree that we don't want to release the atomic image because it isn't useful. So we need to have a discussion about what is supposed to be _in the release image_ anyway meaning what are the tools in the release configuration that get loaded by the CI to produce a releasable image. Taken that into account and the different preferences of people we could have developer released images. It means that one person takes the responsibility of managing a configuration that loads his preferred tools and setup. This can be published on a dedicated page of pharo.org <http://pharo.org/>. In the best case there would appear images for web, visualization, database stuff, science stuff etc. So everyone can express what is pharo for him/her. Norbert
Am 23.04.2015 um 09:04 schrieb stepharo <stepharo@free.fr>:
Le 23/4/15 09:05, Marcus Denker a écrit :
I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) makes the system less modular. Then why the dependency Browser was not integrated? Why roassal for drawing dependencies and other aspects of the system? Because dependency browser as well as roassal are really useful, well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process. In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool. Strange for scientific people no? I think that we should have a building process that load tools. We will not be able to put everything in the image: Did you look at the dependencies between RB, nautilus, history, EyeInspector? I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours fixing configurations that nobody use or look at. But you see this period is ***over***.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
You always directly go and argue by âI am now sadâ purely emotional level. This is not good. Read what you want to read. But my energy in neither cheap nor infinite anymore. This is not a feeling but just a mere fact.
Marcus
Stef, where is "the tool"? Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@free.fr>:
Two things:
One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it.
Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
Stef
Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
Hi Cyril, Your problem is caused because abstract methods should be marked with "subclassResponsibility" and not "shouldBeImplemented". - shouldBeImplemented means "this is a method I did not implement yet, I should replace *this* method with another implementation" - subclassResponsibility means "my subclasses should implement a method with this same selector" The tools recognize the first as a normal "concrete" method and the second as an abstract method. El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl < norbert@hartl.name> escribió:
Stef,
where is "the tool"?
Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@free.fr>:
Two things:
One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it.
Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
Stef
Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
Oh, ok ! Thank you Guillermo ! On 23 April 2015 at 11:58, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi Cyril,
Your problem is caused because abstract methods should be marked with "subclassResponsibility" and not "shouldBeImplemented".
- shouldBeImplemented means "this is a method I did not implement yet, I should replace *this* method with another implementation" - subclassResponsibility means "my subclasses should implement a method with this same selector"
The tools recognize the first as a normal "concrete" method and the second as an abstract method.
El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl <norbert@hartl.name> escribió:
Stef,
where is "the tool"?
Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@free.fr>:
Two things:
One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it.
Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
Stef
Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
-- Cheers Cyril Ferlicot
I changed that but i still have the warning from quality assistant. On 23 April 2015 at 12:44, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
Oh, ok ! Thank you Guillermo !
On 23 April 2015 at 11:58, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi Cyril,
Your problem is caused because abstract methods should be marked with "subclassResponsibility" and not "shouldBeImplemented".
- shouldBeImplemented means "this is a method I did not implement yet, I should replace *this* method with another implementation" - subclassResponsibility means "my subclasses should implement a method with this same selector"
The tools recognize the first as a normal "concrete" method and the second as an abstract method.
El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl <norbert@hartl.name> escribió:
Stef,
where is "the tool"?
Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@free.fr>:
Two things:
One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it.
Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
Stef
Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
-- Cheers Cyril Ferlicot
-- Cheers Cyril Ferlicot
Hi Cyril, Iâve checked the problem. It could be indeed easier if the rule pointed to it :). So you have PRFileInclusion>>replace: and it is identical (not taking empty lines into account) to PRTransformer>>replace:. So the rule is correct. You override a method with an identical method. Uko
On 23 Apr 2015, at 12:48, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
I changed that but i still have the warning from quality assistant.
On 23 April 2015 at 12:44, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
Oh, ok ! Thank you Guillermo !
On 23 April 2015 at 11:58, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi Cyril,
Your problem is caused because abstract methods should be marked with "subclassResponsibility" and not "shouldBeImplemented".
- shouldBeImplemented means "this is a method I did not implement yet, I should replace *this* method with another implementation" - subclassResponsibility means "my subclasses should implement a method with this same selector"
The tools recognize the first as a normal "concrete" method and the second as an abstract method.
El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl <norbert@hartl.name> escribió:
Stef,
where is "the tool"?
Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@free.fr>:
Two things:
One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it.
Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
Stef
Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
-- Cheers Cyril Ferlicot
-- Cheers Cyril Ferlicot
It is the configurationBrowser (but an old configuration) DependencyAnalyser (guillermo I thought that I fixed the text: deprecation but apparently not) or in PharoExtras MCHttpRepository location: 'http://www.smalltalkhub.com/mc/PharoExtras/Tool-DependencyAnalyser/main' user: '' password: '' Le 23/4/15 11:14, Norbert Hartl a écrit :
Stef,
where is "the tool"?
Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@free.fr>:
Two things:
One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it.
Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
Stef
Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
El vie., 24 de abr. de 2015 a la(s) 8:31 a. m., stepharo <stepharo@free.fr> escribió:
It is the configurationBrowser (but an old configuration) DependencyAnalyser (guillermo I thought that I fixed the text: deprecation but apparently not) or in PharoExtras
Hey! It is fixed :) ! (just downloaded it 2 secs ago...) How did you load it? I did in latest pharo4 Configuration Browser > DependencyAnalizer > install stable
MCHttpRepository location: 'http://www.smalltalkhub.com/mc/PharoExtras/Tool-DependencyAnalyser/main' user: '' password: ''
Le 23/4/15 11:14, Norbert Hartl a écrit :
Stef,
where is "the tool"?
Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@free.fr>:
Two things:
One: We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. if this tool would be in the image, everybody could check that there are bad dependencies in his code (and there are many around in nearly anybody's code). No we prefer that me, pavel, and guille run it and fight with this instead of making sure that when you commit we get some feedback like: "oh strange that this package is bound with this one". This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it.
Two: Our process is not great to manage external packages and we will add more. Sure it sounds like the right things to do, especially now.
So to me it simply means that we are not serious and convinced about modularity.
But this is great, I'm reconsidering what I will do in Pharo so you give me good indication that I should not continue the way I was thinking. And no need to think that I'm emotional I'm not. I'm thinking about why hell I'm doing all this.
Stef
Le 22/4/15 21:27, Marcus Denker a écrit :
On 22 Apr 2015, at 20:22, stepharo <stepharo@free.fr> wrote:
Le 22/4/15 13:23, Esteban Lorenzano a écrit :
this is so good. what about integrate it to Pharo? No. People should start to think modular. No more external tools loaded by default. Better invest in "add a startup preference" functionality in the configurationBrowser.
Why we do not integrate the excellent tool of baptiste that would show to people when they are creating package mess? Because of the same reason.
But the Pharo that we download should be the Pharo we use.
We tried the other back in Pharo1.0: Do you remember how we fixed with lots care all details, but then, everyone was using a different image, and all the details there where not fixed and all work was done double?
If we do not make the Pharo that is downloaded to be that was is used, we will have that again.
I donât want everything in the image, but what everyone is supposed to be using should be there without needing an additional step.
Marcus
Hi, I only took a brief look, but I think that reaching the no-input-required situation is a major step forward. Nice job. Keep it up. Cheers, Doru On Wed, Apr 22, 2015 at 8:58 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone!
Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter.
Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta-. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects.
Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code.
Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues
Have a nice week! Uko
-- www.tudorgirba.com "Every thing has its own flow"
Hola, It looks like a really cool tool! I just added it to my LRP development image and I plan on using it full time. I am always interested in writing cleaner code. So expect comments from me :-) Actually I already have one: For one class I got the critic âReferences an abstract classâ and 'Subclass responsibility not definedâ. Excellent that you found it, but now I have to go through all the methods of the class to see where the first critic comes from, and through all methods of all leaf classes for the second one. :-( :-( :-( Thatâs a lot of work for me to rescue some information which apparently the tool already knows. Please add more information on where the issue is on these kinds of errors, so I can fix them more easily ... Thanks and keep up the good work!
On Apr 22, 2015, at 03:58, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone!
Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter.
Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta- <https://github.com/Uko/QualityAssistant#quality-assistant-beta->. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects.
Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code.
Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues <https://github.com/Uko/QualityAssistant/issues>
Have a nice week! Uko
<critics.jpg> _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Some weird behavior in quality assistant. Have a look at this method: duplicateVar: aVarName self show: 'Var: ', aVarName, ' redefinition ignored'. This raises the issue: âUse cascaded nextPutAll:âs instead of #, in nextPutAll:â It also pops up the automatic rewrite icon, so I clicked on it to see how it would transform the code. Result: duplicateVar: aVarName self show: 'Var: ' , aVarName; show: ' redefinition ignored' Needless to say, thatâs not a behavior preserving transformation.
On Apr 22, 2015, at 03:58, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues <https://github.com/Uko/QualityAssistant/issues>
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
participants (10)
-
Cyril Ferlicot -
Esteban Lorenzano -
Guillermo Polito -
Henrik Johansen -
Johan Fabry -
Marcus Denker -
Norbert Hartl -
stepharo -
Tudor Girba -
Yuriy Tymchuk