Hi, SortedCollection>>storeOn: seems to have a little problem since it does not store sortBlock and the used super-method (in Collection) uses #add: which uses sortBlock and their default uses #<=, hence if the elements are not comparable via #<=, but need a special sortblock, one gets an error on retrieving that collection. of course i can circumvent that tiny problem by defining #<= or using fuel, but i wonder whether i should report that on the bugtracker? btw perhaps some other collections with instanceVariables which do not define their own #storeOn: (eg Heap) could also have eventually some problems. werner
Werner,
On 30 Nov 2015, at 15:15, Werner Kassens <wkassens@libello.com> wrote:
Hi, SortedCollection>>storeOn: seems to have a little problem since it does not store sortBlock and the used super-method (in Collection) uses #add: which uses sortBlock and their default uses #<=, hence if the elements are not comparable via #<=, but need a special sortblock, one gets an error on retrieving that collection. of course i can circumvent that tiny problem by defining #<= or using fuel, but i wonder whether i should report that on the bugtracker? btw perhaps some other collections with instanceVariables which do not define their own #storeOn: (eg Heap) could also have eventually some problems. werner
I am not so sure the #storeOn: / #readFrom: mechanism is still being maintained. I am not using it in any case, I thought it was mostly broken. I would be surprised if someone is still using it for real. But I might be wrong. In that case there should be a suite of real unit tests that defines and maintains the expected behaviour. And then you would be right, we should fix it. Sven
On Mon, Nov 30, 2015 at 11:23 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Werner,
On 30 Nov 2015, at 15:15, Werner Kassens <wkassens@libello.com> wrote:
Hi, SortedCollection>>storeOn: seems to have a little problem since it does not store sortBlock and the used super-method (in Collection) uses #add: which uses sortBlock and their default uses #<=, hence if the elements are not comparable via #<=, but need a special sortblock, one gets an error on retrieving that collection. of course i can circumvent that tiny problem by defining #<= or using fuel, but i wonder whether i should report that on the bugtracker? btw perhaps some other collections with instanceVariables which do not define their own #storeOn: (eg Heap) could also have eventually some problems. werner
I am not so sure the #storeOn: / #readFrom: mechanism is still being maintained. I am not using it in any case, I thought it was mostly broken. I would be surprised if someone is still using it for real.
But I might be wrong. In that case there should be a suite of real unit tests that defines and maintains the expected behaviour. And then you would be right, we should fix it.
Yes, I have the same feeling. And I hate having such a general protocol like #storeOn: in our kernel objects. Store how? using which serializer? I think if this protocol is still used it should be much clearer. But as Sven said, I am not sure if this is still used and if it does, which code use it, who is the "serializer", etc... -- Mariano http://marianopeck.wordpress.com
Hi Sven, i see, then i'll simply forget it (i asked, because i halfway expected that). thanks for that info. werner On 11/30/2015 03:23 PM, Sven Van Caekenberghe wrote:
I am not so sure the #storeOn: / #readFrom: mechanism is still being maintained. I am not using it in any case, I thought it was mostly broken. I would be surprised if someone is still using it for real.
But I might be wrong. In that case there should be a suite of real unit tests that defines and maintains the expected behaviour. And then you would be right, we should fix it.
Sven
Wait :) Help us :) It would be good to check who is using that and evaluate if we can remove it. Stef Le 30/11/15 15:29, Werner Kassens a écrit :
Hi Sven, i see, then i'll simply forget it (i asked, because i halfway expected that). thanks for that info. werner
On 11/30/2015 03:23 PM, Sven Van Caekenberghe wrote:
I am not so sure the #storeOn: / #readFrom: mechanism is still being maintained. I am not using it in any case, I thought it was mostly broken. I would be surprised if someone is still using it for real.
But I might be wrong. In that case there should be a suite of real unit tests that defines and maintains the expected behaviour. And then you would be right, we should fix it.
Sven
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it.
Thanks Werner! Stef Le 3/12/15 13:00, Werner Kassens a écrit :
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it.
Hi, Thanks for the question. I am at a conference, and I just took this problem to explain someone what code querying can mean :). Here is the result: http://ws.stfx.eu/CCSNJVWX3JKS I think this is how we should document our communication because now we have the tools. Cheers, Doru
On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkassens@libello.com> wrote:
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it.
-- www.tudorgirba.com "Every thing should have the right to be different."
Hi again,
On Dec 9, 2015, at 3:30 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for the question. I am at a conference, and I just took this problem to explain someone what code querying can mean :).
Here is the result: http://ws.stfx.eu/CCSNJVWX3JKS
I just realized that isPharoClass only exists in my image for the moment :) Doru
<storeOn.png>
I think this is how we should document our communication because now we have the tools.
Cheers, Doru
On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkassens@libello.com> wrote:
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it.
-- www.tudorgirba.com
"Every thing should have the right to be different."
-- www.tudorgirba.com "One cannot do more than one can do."
I created an issue with a slice: https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo Cheers, Doru
On Dec 9, 2015, at 3:33 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi again,
On Dec 9, 2015, at 3:30 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for the question. I am at a conference, and I just took this problem to explain someone what code querying can mean :).
Here is the result: http://ws.stfx.eu/CCSNJVWX3JKS
I just realized that isPharoClass only exists in my image for the moment :)
Doru
<storeOn.png>
I think this is how we should document our communication because now we have the tools.
Cheers, Doru
On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkassens@libello.com> wrote:
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it.
-- www.tudorgirba.com
"Every thing should have the right to be different."
-- www.tudorgirba.com
"One cannot do more than one can do."
-- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
hi doru what is isPharoClass? Why do you need it? Stef Le 9/12/15 21:49, Tudor Girba a écrit :
I created an issue with a slice: https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo
Cheers, Doru
On Dec 9, 2015, at 3:33 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi again,
On Dec 9, 2015, at 3:30 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for the question. I am at a conference, and I just took this problem to explain someone what code querying can mean :).
Here is the result: http://ws.stfx.eu/CCSNJVWX3JKS
I just realized that isPharoClass only exists in my image for the moment :)
Doru
<storeOn.png>
I think this is how we should document our communication because now we have the tools.
Cheers, Doru
On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkassens@libello.com> wrote:
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it. -- www.tudorgirba.com
"Every thing should have the right to be different."
-- www.tudorgirba.com
"One cannot do more than one can do." -- www.tudorgirba.com
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Hi, I wanted to have an easy way to distinguish between a class that ships with Pharo and another class that is built on top. Unfortunately, I did not find a good enough heuristic (I used to rely on the repository of the package where the class is defined as being the Pharo one), so this was not added until we find a different solution. This is useful in several situations. The one I am in very often is to use extra tools that are in Moose to analyze Pharo. This was the case below where we needed to get the list of the storeOn: senders more accurately. Cheers, Doru
On Dec 16, 2015, at 10:41 PM, stepharo <stepharo@free.fr> wrote:
hi doru
what is isPharoClass? Why do you need it?
Stef
Le 9/12/15 21:49, Tudor Girba a écrit :
I created an issue with a slice: https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo
Cheers, Doru
On Dec 9, 2015, at 3:33 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi again,
On Dec 9, 2015, at 3:30 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for the question. I am at a conference, and I just took this problem to explain someone what code querying can mean :).
Here is the result: http://ws.stfx.eu/CCSNJVWX3JKS
I just realized that isPharoClass only exists in my image for the moment :)
Doru
<storeOn.png>
I think this is how we should document our communication because now we have the tools.
Cheers, Doru
On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkassens@libello.com> wrote:
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it. -- www.tudorgirba.com
"Every thing should have the right to be different."
-- www.tudorgirba.com
"One cannot do more than one can do." -- www.tudorgirba.com
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
-- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."
How this method is packaged? Because I do not want to have in the core like that especially if it add dependencies to MC Stef Le 16/12/15 22:47, Tudor Girba a écrit :
Hi,
I wanted to have an easy way to distinguish between a class that ships with Pharo and another class that is built on top. Unfortunately, I did not find a good enough heuristic (I used to rely on the repository of the package where the class is defined as being the Pharo one), so this was not added until we find a different solution.
This is useful in several situations. The one I am in very often is to use extra tools that are in Moose to analyze Pharo. This was the case below where we needed to get the list of the storeOn: senders more accurately.
Cheers, Doru
On Dec 16, 2015, at 10:41 PM, stepharo <stepharo@free.fr> wrote:
hi doru
what is isPharoClass? Why do you need it?
Stef
Le 9/12/15 21:49, Tudor Girba a écrit :
I created an issue with a slice: https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo
Cheers, Doru
On Dec 9, 2015, at 3:33 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi again,
On Dec 9, 2015, at 3:30 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for the question. I am at a conference, and I just took this problem to explain someone what code querying can mean :).
Here is the result: http://ws.stfx.eu/CCSNJVWX3JKS
I just realized that isPharoClass only exists in my image for the moment :)
Doru
<storeOn.png>
I think this is how we should document our communication because now we have the tools.
Cheers, Doru
On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkassens@libello.com> wrote:
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote:
It would be good to check who is using that and evaluate if we can remove it. -- www.tudorgirba.com
"Every thing should have the right to be different."
-- www.tudorgirba.com
"One cannot do more than one can do." -- www.tudorgirba.com
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
-- www.tudorgirba.com www.feenk.com
"It's not what we do that matters most, it's how we do it."
Hi, It would certainly not be in Core. I was thinking it to be in Ring. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
On 21 Dec 2015, at 23:03, stepharo <stepharo@free.fr> wrote:
How this method is packaged? Because I do not want to have in the core like that especially if it add dependencies to MC
Stef
Le 16/12/15 22:47, Tudor Girba a écrit :
Hi,
I wanted to have an easy way to distinguish between a class that ships with Pharo and another class that is built on top. Unfortunately, I did not find a good enough heuristic (I used to rely on the repository of the package where the class is defined as being the Pharo one), so this was not added until we find a different solution.
This is useful in several situations. The one I am in very often is to use extra tools that are in Moose to analyze Pharo. This was the case below where we needed to get the list of the storeOn: senders more accurately.
Cheers, Doru
On Dec 16, 2015, at 10:41 PM, stepharo <stepharo@free.fr> wrote:
hi doru
what is isPharoClass? Why do you need it?
Stef
Le 9/12/15 21:49, Tudor Girba a écrit :
I created an issue with a slice: https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo
Cheers, Doru
On Dec 9, 2015, at 3:33 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi again,
On Dec 9, 2015, at 3:30 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for the question. I am at a conference, and I just took this problem to explain someone what code querying can mean :).
Here is the result: http://ws.stfx.eu/CCSNJVWX3JKS I just realized that isPharoClass only exists in my image for the moment :)
Doru
<storeOn.png>
I think this is how we should document our communication because now we have the tools.
Cheers, Doru
On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkassens@libello.com> wrote:
Hi Stephane, there are 89 senders of #storeOn: minus around 30 implementations of #storeOn: minus around 10 tests, also things like the PharoChangesCondenser use it. then there are 26 senders of #storeString (essentially the same functionality implemented via #storeOn:, but returns a string) eg used by the StartupPreferencesLoader. and there are several senders of #store: that are not implementations of #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and is obviously way above my head. werner
On 11/30/2015 09:42 PM, stepharo wrote: It would be good to check who is using that and evaluate if we can remove it. -- www.tudorgirba.com
"Every thing should have the right to be different." -- www.tudorgirba.com
"One cannot do more than one can do." -- www.tudorgirba.com
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." -- www.tudorgirba.com www.feenk.com
"It's not what we do that matters most, it's how we do it."
participants (5)
-
Mariano Martinez Peck -
stepharo -
Sven Van Caekenberghe -
Tudor Girba -
Werner Kassens