[pharo-project/pharo-core] dd006c: 40336
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: dd006cefd42a50c221e5dbd395bbbd7788aeafee https://github.com/pharo-project/pharo-core/commit/dd006cefd42a50c221e5dbd39... Author: Jenkins Build Server <board@pharo-project.org> Date: 2014-10-28 (Tue, 28 Oct 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script336.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40336.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClassDescription.class/instance/organization updating/notifyOfRecategorizedSelector_from_to_.st Log Message: ----------- 40336 14337 Removing a trait usage raises an exception (2nd attempt) https://pharo.fogbugz.com/f/cases/14337 http://files.pharo.org/image/40/40336.zip
Thanks esteban! I'm unstuck :) On 28/10/14 07:41, GitHub wrote:
40336 14337 Removing a trait usage raises an exception (2nd attempt) https://pharo.fogbugz.com/f/cases/14337
Oh yeah! Maybe now the Fuel tests will be back to green :)
On 28.10.2014, at 20:23, stepharo <stepharo@free.fr> wrote:
Thanks esteban! I'm unstuck :)
On 28/10/14 07:41, GitHub wrote:
40336 14337 Removing a trait usage raises an exception (2nd attempt) https://pharo.fogbugz.com/f/cases/14337
I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possible⦠Should I open an issue? Cheers, Max
On 28.10.2014, at 20:42, Max Leske <maxleske@gmail.com> wrote:
Oh yeah! Maybe now the Fuel tests will be back to green :)
On 28.10.2014, at 20:23, stepharo <stepharo@free.fr> wrote:
Thanks esteban! I'm unstuck :)
On 28/10/14 07:41, GitHub wrote:
40336 14337 Removing a trait usage raises an exception (2nd attempt) https://pharo.fogbugz.com/f/cases/14337
Good question :). I do not know I would say that having the package Unpackaged would be better than nil On 28/10/14 16:26, Max Leske wrote:
I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possible⦠Should I open an issue?
Cheers, Max
On 28.10.2014, at 20:42, Max Leske <maxleske@gmail.com> wrote:
Oh yeah! Maybe now the Fuel tests will be back to green :)
On 28.10.2014, at 20:23, stepharo <stepharo@free.fr> wrote:
Thanks esteban! I'm unstuck :)
On 28/10/14 07:41, GitHub wrote:
40336 14337 Removing a trait usage raises an exception (2nd attempt) https://pharo.fogbugz.com/f/cases/14337
On 29.10.2014, at 01:17, stepharo <stepharo@free.fr> wrote:
Good question :). I do not know I would say that having the package Unpackaged would be better than nil
So maybe the bug is that it should not be allowed to pass nil as category?
On 28/10/14 16:26, Max Leske wrote:
I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possible⦠Should I open an issue?
Cheers, Max
On 28.10.2014, at 20:42, Max Leske <maxleske@gmail.com> wrote:
Oh yeah! Maybe now the Fuel tests will be back to green :)
On 28.10.2014, at 20:23, stepharo <stepharo@free.fr> wrote:
Thanks esteban! I'm unstuck :)
On 28/10/14 07:41, GitHub wrote:
40336 14337 Removing a trait usage raises an exception (2nd attempt) https://pharo.fogbugz.com/f/cases/14337
On Wednesday, Oct 29, 2014 at 8:18 am, Max Leske <maxleske@gmail.com>, wrote:
On 29.10.2014, at 01:17, stepharo wrote:
Good question :).
I do not know I would say that having the package Unpackaged would be better than nil  @free.fr>
So maybe the bug is that it should not be allowed to pass nil as category? @free.fr> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ. (there is now code in a package Generated-code-non-existing-package that is of that kind, but the problem is that this package is always dirty of code gets generated).  https://pharo.fogbugz.com/f/cases/14097/generated-code-non-existing-package-... Would be nice if someone would implement a solution for this.
On 28/10/14 16:26, Max Leske wrote:
I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possible⦠Should I open an issue?
Cheers,
Max
On 28.10.2014, at 20:42, Max Leske wrote:
Oh yeah! Maybe now the Fuel tests will be back to green :)
On 28.10.2014, at 20:23, stepharo wrote:
Thanks esteban!
I'm unstuck :)
On 28/10/14 07:41, GitHub wrote:
40336
14337 Removing a trait usage raises an exception (2nd attempt)
@free.fr>@gmail.com>@free.fr>
On 29.10.2014, at 08:22, Marcus Denker <marcus.denker@gmail.com> wrote:
On Wednesday, Oct 29, 2014 at 8:18 am, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>, wrote:
On 29.10.2014, at 01:17, stepharo wrote:
Good question :).
I do not know I would say that having the package Unpackaged would be better than nil @free.fr>
So maybe the bug is that it should not be allowed to pass nil as category?
@free.fr> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ.
Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now?
(there is now code in a package Generated-code-non-existing-package that is of that kind, but the problem is that this package is always dirty of code gets generated).
https://pharo.fogbugz.com/f/cases/14097/generated-code-non-existing-package-...
Would be nice if someone would implement a solution for this.
For libgit2 I simply sublassed NB and put the auto-generated methods into the protocols I choose. Of course thatâs not a general solution.
On 28/10/14 16:26, Max Leske wrote:
I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? Itâs not cool to create a trait in category nil but since itâs possible⦠Should I open an issue?
Cheers,
Max
On 28.10.2014, at 20:42, Max Leske wrote:
Oh yeah! Maybe now the Fuel tests will be back to green :)
On 28.10.2014, at 20:23, stepharo wrote:
Thanks esteban!
I'm unstuck :)
On 28/10/14 07:41, GitHub wrote:
40336
14337 Removing a trait usage raises an exception (2nd attempt)
@free.fr>@gmail.com>@free.fr>
@free.fr <http://free.fr/>> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ.
Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now?
People would emmediatly report bugs that there is unpackaged code. We need to concept of âthis is ok that there is no packageâ. Marcus
On 29.10.2014, at 09:45, Marcus Denker <marcus.denker@inria.fr> wrote:
@free.fr <http://free.fr/>> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ.
Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now?
People would emmediatly report bugs that there is unpackaged code.
True.
We need to concept of âthis is ok that there is no packageâ.
But we donât have that right now. And the problem with nil as category remains. How about replacing a nil category with âUnpackagedâ implicitly for the time being? It would at least âfixâ one problem. Max
Marcus
On 29 Oct 2014, at 09:54, Max Leske <maxleske@gmail.com> wrote:
On 29.10.2014, at 09:45, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
@free.fr <http://free.fr/>> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ.
Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now?
People would emmediatly report bugs that there is unpackaged code.
True.
We need to concept of âthis is ok that there is no packageâ.
But we donât have that right now. And the problem with nil as category remains. How about replacing a nil category with âUnpackagedâ implicitly for the time being? It would at least âfixâ one problem.
Ok. Marcus
On 29.10.2014, at 10:00, Marcus Denker <marcus.denker@inria.fr> wrote:
On 29 Oct 2014, at 09:54, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 29.10.2014, at 09:45, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
@free.fr <http://free.fr/>> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ.
Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now?
People would emmediatly report bugs that there is unpackaged code.
True.
We need to concept of âthis is ok that there is no packageâ.
But we donât have that right now. And the problem with nil as category remains. How about replacing a nil category with âUnpackagedâ implicitly for the time being? It would at least âfixâ one problem.
Ok.
Marcus
Issue with slice: https://pharo.fogbugz.com/f/cases/14371/Traits-should-not-be-allowed-to-have... <https://pharo.fogbugz.com/f/cases/14371/Traits-should-not-be-allowed-to-have...> Cheers, Max
2014-10-29 9:30 GMT+01:00 Max Leske <maxleske@gmail.com>:
On 29.10.2014, at 08:22, Marcus Denker <marcus.denker@gmail.com> wrote:
On Wednesday, Oct 29, 2014 at 8:18 am, Max Leske <maxleske@gmail.com>, wrote:
On 29.10.2014, at 01:17, stepharo wrote:
Good question :).
I do not know I would say that having the package Unpackaged would be better than nil @free.fr>
So maybe the bug is that it should not be allowed to pass nil as category?
@free.fr>
We need the concept of "this is code that is automatically generated, it is not part of any package and this is meant to be like that".
Nautilus (or RPackage?) does provide the 'Unpackaged' category. Wouldn't that be "good enough" for now?
RPackage :) Thierry
(there is now code in a package Generated-code-non-existing-package that is of that kind, but the problem is that this package is always dirty of code gets generated).
https://pharo.fogbugz.com/f/cases/14097/generated-code-non-existing-package-...
Would be nice if someone would implement a solution for this.
For libgit2 I simply sublassed NB and put the auto-generated methods into the protocols I choose. Of course that's not a general solution.
On 28/10/14 16:26, Max Leske wrote:
I just fixed a couple of Fuel tests that failed because it is possible to create a trait with the category set to nil. When creating a new trait with the same name this results in an exception being signaled. Should we consider this a bug? It's not cool to create a trait in category nil but since it's possible... Should I open an issue?
Cheers,
Max
On 28.10.2014, at 20:42, Max Leske wrote:
Oh yeah! Maybe now the Fuel tests will be back to green :)
On 28.10.2014, at 20:23, stepharo wrote:
Thanks esteban!
I'm unstuck :)
On 28/10/14 07:41, GitHub wrote:
40336
14337 Removing a trait usage raises an exception (2nd attempt)
@free.fr>@gmail.com>@free.fr>
participants (6)
-
GitHub -
Marcus Denker -
Marcus Denker -
Max Leske -
stepharo -
Thierry Goubier