QUESTION: Is anybody using zeroconf with Pharo 2.0?
Esteban Lorenzano writes:
that⦠is someone using it?
I think the pharo-users mailing list is more appropriate -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Damien, I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip). Dale On 3/13/15 5:04 AM, Damien Cassou wrote:
Esteban Lorenzano writes:
that⦠is someone using it? I think the pharo-users mailing list is more appropriate
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
I do not think that this is a good idea: we are not building a Museum. For example, we improve the core libraries. It will make something like Metacello *very* complex to be compatible over so many versions back. In the end, people who have this philosophy start to even request âto make this easierâ, and then tell us to stop changing. Make your live easier and do *not* support old versions! Everything gets easier and the world will be a happier place. Marcus
I still have production code (GemTools) that runs today in Pharo 1.1 ... I assume that others also have production code running in older versions of Pharo and Squeak and GemStone so I make sure that Metacello continues to work on those platforms ... Not everyone has the luxury of having the time to port their entire production catalog to the latest version of Pharo ... I don't demand that zeroconf support Pharo1.2 as long as there is a way that I can keep downloading Pharo1.2 ... but if you don't intend to support all releases of Pharo on zeroconf, then I will simply start using the alternate long term method in my scripts because I certainly don't want to have to change scripts that are working perfectly fine, because you've decided to drop support for a particular version.... Dale On 3/22/15 11:46 PM, Marcus Denker wrote:
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
I do not think that this is a good idea: we are not building a Museum. For example, we improve the core libraries. It will make something like Metacello *very* complex to be compatible over so many versions back. In the end, people who have this philosophy start to even request âto make this easierâ, and then tell us to stop changing.
Make your live easier and do *not* support old versions! Everything gets easier and the world will be a happier place.
Marcus
On 23 Mar 2015, at 17:16, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
I still have production code (GemTools) that runs today in Pharo 1.1 ...
I assume that others also have production code running in older versions of Pharo and Squeak and GemStone so I make sure that Metacello continues to work on those platforms ...
Not everyone has the luxury of having the time to port their entire production catalog to the latest version of Pharo ...
I don't demand that zeroconf support Pharo1.2 as long as there is a way that I can keep downloading Pharo1.2 ... but if you don't intend to support all releases of Pharo on zeroconf, then I will simply start using the alternate long term method in my scripts because I certainly don't want to have to change scripts that are working perfectly fine, because you've decided to drop support for a particular versionâ¦.
Even Microsoft does not support ever old version of Windows. How can we? Wouldnât it get indefinitely expensive? Marcus
Did I ask for support? I asked to be able to continue to be able to continue to download older versions of Pharo. If you say no, then you say no. If you intend to cutoff the downloads for older versions of Pharo, then I would ask that you give me a couple of months warning. If you say no, then you say no. The original question was ... "Is anyone using zerconf for Pharo2.0" and I answered your question... I'm not sure that it costs you anything (other than goodwill) by allowing folks to download older versions of Pharo ... Supporting older versions of Pharo is another kettle of fish ... Dale On 3/23/15 9:20 AM, Marcus Denker wrote:
On 23 Mar 2015, at 17:16, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
I still have production code (GemTools) that runs today in Pharo 1.1 ...
I assume that others also have production code running in older versions of Pharo and Squeak and GemStone so I make sure that Metacello continues to work on those platforms ...
Not everyone has the luxury of having the time to port their entire production catalog to the latest version of Pharo ...
I don't demand that zeroconf support Pharo1.2 as long as there is a way that I can keep downloading Pharo1.2 ... but if you don't intend to support all releases of Pharo on zeroconf, then I will simply start using the alternate long term method in my scripts because I certainly don't want to have to change scripts that are working perfectly fine, because you've decided to drop support for a particular versionâ¦.
Even Microsoft does not support ever old version of Windows. How can we? Wouldnât it get indefinitely expensive?
Marcus
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated. I want to deprecate zeroconf for, at least, all pharo < 2.0. why? because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3⦠and starting next month V4. I want to remove at least one of those sources. Also⦠the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VM⦠What to do with those scripts? maybe deprecate the âvmâ part, and replace it for: /vm1 /vm2 /vm3 /vm4 /vmN ⦠and /vm downloading the latest stable (/vm4, next month) but then⦠what to do with the /30+vm /40+vm scripts? yes⦠they *could* realise link is talking to âconvenient vmâ so it would download /vm3 and /vm4⦠but Iâm describing the problem, who grows exponentially. Keeping âforever compatibilityâ is not good. It does not work. It does not scale. Esteban
Dale
On 3/13/15 5:04 AM, Damien Cassou wrote:
Esteban Lorenzano writes:
that⦠is someone using it? I think the pharo-users mailing list is more appropriate
On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated.
I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judge⦠:) ). But I donât need the zero conf scripts for those.
I want to deprecate zeroconf for, at least, all pharo < 2.0.
why? because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3⦠and starting next month V4. I want to remove at least one of those sources.
Also⦠the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VMâ¦
What to do with those scripts?
maybe deprecate the âvmâ part, and replace it for:
/vm1 /vm2 /vm3 /vm4 /vmN
⦠and /vm downloading the latest stable (/vm4, next month)
but then⦠what to do with the
/30+vm /40+vm
scripts? yes⦠they *could* realise link is talking to âconvenient vmâ so it would download /vm3 and /vm4⦠but Iâm describing the problem, who grows exponentially. Keeping âforever compatibilityâ is not good. It does not work. It does not scale.
Esteban
Dale
On 3/13/15 5:04 AM, Damien Cassou wrote:
Esteban Lorenzano writes:
that⦠is someone using it? I think the pharo-users mailing list is more appropriate
Hi, On Mon, Mar 23, 2015 at 9:16 AM, Max Leske <maxleske@gmail.com> wrote:
On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 22 Mar 2015, at 22:56, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 ( https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated.
I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judge⦠:) ).
I do not judge. I pity :)) Doru But I donât need the zero conf scripts for those.
I want to deprecate zeroconf for, at least, all pharo < 2.0.
why? because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3⦠and starting next month V4. I want to remove at least one of those sources.
Also⦠the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VMâ¦
What to do with those scripts?
maybe deprecate the âvmâ part, and replace it for:
/vm1 /vm2 /vm3 /vm4 /vmN
⦠and /vm downloading the latest stable (/vm4, next month)
but then⦠what to do with the
/30+vm /40+vm
scripts? yes⦠they *could* realise link is talking to âconvenient vmâ so it would download /vm3 and /vm4⦠but Iâm describing the problem, who grows exponentially. Keeping âforever compatibilityâ is not good. It does not work. It does not scale.
Esteban
Dale
On 3/13/15 5:04 AM, Damien Cassou wrote:
Esteban Lorenzano writes:
that⦠is someone using it? I think the pharo-users mailing list is more appropriate
-- www.tudorgirba.com "Every thing has its own flow"
On 23 Mar 2015, at 09:17, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Mon, Mar 23, 2015 at 9:16 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip <https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip>).
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated.
I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judge⦠:) ).
I do not judge. I pity :))
It is ok to use them, but people should not expect that packages and framework will be updated. (and this even defeats the purpose: people use old version *becasue they do not want change*. If we update stuff under their feet (Zinc, Metacelloâ¦) this will lead to exactly what they do not want. We should consider old version to be frozen, *including* the frameworks and tools. Marcus
On 23 Mar 2015, at 09:24, Marcus Denker <marcus.denker@inria.fr> wrote:
On 23 Mar 2015, at 09:17, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Mon, Mar 23, 2015 at 9:16 AM, Max Leske <maxleske@gmail.com> wrote:
On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated.
I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judge⦠:) ).
I do not judge. I pity :))
It is ok to use them, but people should not expect that packages and framework will be updated. (and this even defeats the purpose: people use old version *becasue they do not want change*.
If we update stuff under their feet (Zinc, Metacelloâ¦) this will lead to exactly what they do not want.
We should consider old version to be frozen, *including* the frameworks and tools.
Marcus
I agree. It is of course up to each developer to decide how far back they want to support their code. But indeed, the reason to stay with an old(er) version is because you do not want change. Sven
Marcus, Frozen and downloadable is absolutely fair and not unexpected ... It would be convenient if zeroconf continued to work for the frozen products, but if that isn't practical for you then I can live with that...as long as I can continue to download for testing of Metacello on travis:) Dale On 3/23/15 1:24 AM, Marcus Denker wrote:
On 23 Mar 2015, at 09:17, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
On Mon, Mar 23, 2015 at 9:16 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
> On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: > > >> On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> Damien, >> >> I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip). > > why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) > this âforever backward compatibilityâ ends up being really complicated.
I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judge⦠:) ).
I do not judge. I pity :))
It is ok to use them, but people should not expect that packages and framework will be updated. (and this even defeats the purpose: people use old version *becasue they do not want change*.
If we update stuff under their feet (Zinc, Metacelloâ¦) this will lead to exactly what they do not want.
We should consider old version to be frozen, *including* the frameworks and tools.
Marcus
I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine. I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing ... Dale On 3/23/15 1:16 AM, Max Leske wrote:
On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip). why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated. I am actually, Pharo1.1.1, Pharo1.3 and Pharo1.4 (donât judge⦠:) ). But I donât need the zero conf scripts for those.
I want to deprecate zeroconf for, at least, all pharo < 2.0.
why? because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3⦠and starting next month V4. I want to remove at least one of those sources.
Also⦠the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VMâ¦
What to do with those scripts?
maybe deprecate the âvmâ part, and replace it for:
/vm1 /vm2 /vm3 /vm4 /vmN
⦠and /vm downloading the latest stable (/vm4, next month)
but then⦠what to do with the
/30+vm /40+vm
scripts? yes⦠they *could* realise link is talking to âconvenient vmâ so it would download /vm3 and /vm4⦠but Iâm describing the problem, who grows exponentially. Keeping âforever compatibilityâ is not good. It does not work. It does not scale.
Esteban
Dale
On 3/13/15 5:04 AM, Damien Cassou wrote:
Esteban Lorenzano writes:
that⦠is someone using it? I think the pharo-users mailing list is more appropriate
On 23 Mar 2015, at 17:38, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine.
I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing â¦
Download will be available eternally: http://files.pharo.org/image/ <http://files.pharo.org/image/> http://files.pharo.org/vm/ <http://files.pharo.org/vm/> Marcus
On 23 Mar 2015, at 17:43, Marcus Denker <marcus.denker@inria.fr> wrote:
On 23 Mar 2015, at 17:38, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
I don't need zeroconf for my Pharo1.1 app, either. Alternate download methods would be fine.
I continue to support Metacello on all of the older versions of Pharo and I do use zeroconf there, but if there is an alternate download mechanism then I can use that for testing â¦
Download will be available eternally:
http://files.pharo.org/image/ <http://files.pharo.org/image/> http://files.pharo.org/vm/ <http://files.pharo.org/vm/>
The thing is that get.pharo.org <http://get.pharo.org/> is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org <http://get.pharo.org/> for 1.4, people expect it to work. And we will have to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that. Just downloads is a different thing: this is an archive, use it at your own risk. Marcus
Marcus, This makes perfect sense to me ... If zeroconf is only used for the supported versions of Pharo that is perfectly fair ... When a version goes off of zeroconf support it would be convenient if one could find the appropriate "eternal download urls" for the image/vm otherwise how would I know? Keep in mind, that I use zeroconf to download for travis-based tests and I don't have a physical disk to look at ... and it is possible that I won't know that a particular version has gone off of zeroncof support until my build fails ... so it would be _convenient_ to be able to lookup the image/vm combo that I need to use... Dale
The thing is that get.pharo.org <http://get.pharo.org> is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org <http://get.pharo.org> for 1.4, people expect it to work. And we will have to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that.
Just downloads is a different thing: this is an archive, use it at your own risk.
Marcus
Yes⦠I was asking to see how can we proceed, because we cannot continue distributing as now. In the course of the conversation I found a solution that will please everyone⦠and will allow us to keep giving also zeroconf scripts without needing to download source versions for all (which was, in fact, the problem I was trying to fix). It will require some file reorganisation and the concept of âblessed vmâ: a version we will distribute with the image version (it will be a vm for pharo1, one for pharo2, etc⦠each one with their sources⦠And yes⦠that means a bit more work to configure if you have multiple image-versions⦠but in the long way is the only way we can ensure how an image and a vm works together :) So, no need to continue arguing :) cheers, Esteban
On 23 Mar 2015, at 18:12, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Marcus,
This makes perfect sense to me ... If zeroconf is only used for the supported versions of Pharo that is perfectly fair ...
When a version goes off of zeroconf support it would be convenient if one could find the appropriate "eternal download urls" for the image/vm otherwise how would I know?
Keep in mind, that I use zeroconf to download for travis-based tests and I don't have a physical disk to look at ... and it is possible that I won't know that a particular version has gone off of zeroncof support until my build fails ... so it would be _convenient_ to be able to lookup the image/vm combo that I need to use...
Dale
The thing is that get.pharo.org <http://get.pharo.org/> is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org <http://get.pharo.org/> for 1.4, people expect it to work. And we will have to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that.
Just downloads is a different thing: this is an archive, use it at your own risk.
Marcus
well⦠after sending this mail I stayed thinking and I think something like this is precisely what I have to do :) so I will do an important change to zeroconf to ensure newer versions do not screw with older ones. cheers, Esteban
On 23 Mar 2015, at 09:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Damien,
I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip).
why? I do not think anyone is using Pharo < 2.0 (and not even 2.0, with the exception of some legacy apps) this âforever backward compatibilityâ ends up being really complicated.
I want to deprecate zeroconf for, at least, all pharo < 2.0.
why? because the scripts right now downloads one unique vm for all images. Which means download of sources V1, V2, V3⦠and starting next month V4. I want to remove at least one of those sources.
Also⦠the upcoming spur VM will add another level of complexity to zeroconf scripts (because is everything goes smooth, Pharo5 will dispatch with spur, without backward compatibility). So it will be another V5 + the different VMâ¦
What to do with those scripts?
maybe deprecate the âvmâ part, and replace it for:
/vm1 /vm2 /vm3 /vm4 /vmN
⦠and /vm downloading the latest stable (/vm4, next month)
but then⦠what to do with the
/30+vm /40+vm
scripts? yes⦠they *could* realise link is talking to âconvenient vmâ so it would download /vm3 and /vm4⦠but Iâm describing the problem, who grows exponentially. Keeping âforever compatibilityâ is not good. It does not work. It does not scale.
Esteban
Dale
On 3/13/15 5:04 AM, Damien Cassou wrote:
Esteban Lorenzano writes:
that⦠is someone using it? I think the pharo-users mailing list is more appropriate
Why do you start fun discussion when I'm not connected :). I like the idea of the distinction between archive and supported. I like archives :)
participants (8)
-
Dale Henrichs -
Damien Cassou -
Esteban Lorenzano -
Marcus Denker -
Max Leske -
stepharo -
Sven Van Caekenberghe -
Tudor Girba