Hi Folks,
Package developers want their work to run on various Squeak versions and variants, without needing rewrite. Same for app developers.
Base image builders want to be free of the need to provide backwards compatibility.
This is what I suggest: A package assumes it can use a set of apis of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions should be made explicit, in the form of tests. So, for example, for collections, some package developer might require the "Common Collection API tests" to pass. Then, if his package fails to run, let's say in Cuis, he would run the tests for the apis he needs. If some test fails, he could say "Cuis developers, you're not supporting api XXX", end expect them to fix the issue. But if no test fails, he needs to either modify his code so it doesn't use not-standarized apis, or he could negotiate with (all) base image developers the addition of a new api or use case to the test suite and the base images.
Building these suites is quite some work, mostly to be done by package developers. But it can easily point out responsibilities and duties. It frees package developers of needing to have a deep knowledge of various base images. And it frees base image developers from needing to know details about an unbounded set of external packages. Besides, it puts popular packages that everybody wants to support on equal footing with less-known packages. It also lets base image developers say "we support Common APIs xxx, yyy, zzz, etc.".
All what I say about base images could also apply to packages that offer services to other packages: There could also be test suites to specify their services, and allow users to switch versions of the packages they use knowing what to expect.
What do you think?
Cheers, Juan Vuletich
This is kind of what Seaside's Grease platform is starting to provide, so obviously I think it's a good approach. Grease documents "standard" APIs that we expect on all platforms via unit tests. Each platform is then required to ensure the tests pass, either by fixing their base image, or by adding extensions to their Grease package.
If Seaside doesn't work and all the Grease tests pass, either we need to change Seaside, or add a test to Grease. We've now begun using Grease as the basis for Pier, Magritte, and MC2, so the hope is that it might become generally useful to other projects that want to write code that runs across platforms (we're not just talking Squeak forks here though; this includes VW, VASt, GemStone, Gnu, etc). That's a lofty goal, though, and we're taking a pragmatic, step by step approach.
Julian
On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Folks,
Package developers want their work to run on various Squeak versions and variants, without needing rewrite. Same for app developers.
Base image builders want to be free of the need to provide backwards compatibility.
This is what I suggest: A package assumes it can use a set of apis of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions should be made explicit, in the form of tests. So, for example, for collections, some package developer might require the "Common Collection API tests" to pass. Then, if his package fails to run, let's say in Cuis, he would run the tests for the apis he needs. If some test fails, he could say "Cuis developers, you're not supporting api XXX", end expect them to fix the issue. But if no test fails, he needs to either modify his code so it doesn't use not-standarized apis, or he could negotiate with (all) base image developers the addition of a new api or use case to the test suite and the base images.
Building these suites is quite some work, mostly to be done by package developers. But it can easily point out responsibilities and duties. It frees package developers of needing to have a deep knowledge of various base images. And it frees base image developers from needing to know details about an unbounded set of external packages. Besides, it puts popular packages that everybody wants to support on equal footing with less-known packages. It also lets base image developers say "we support Common APIs xxx, yyy, zzz, etc.".
All what I say about base images could also apply to packages that offer services to other packages: There could also be test suites to specify their services, and allow users to switch versions of the packages they use knowing what to expect.
What do you think?
Cheers, Juan Vuletich
Great! So, it is not a new idea. Let me suggest all the package developers to adopt Grease and help develop it! I'll be really happy to give support for Grease in Cuis.
Cheers, Juan Vuletich
Julian Fitzell wrote:
This is kind of what Seaside's Grease platform is starting to provide, so obviously I think it's a good approach. Grease documents "standard" APIs that we expect on all platforms via unit tests. Each platform is then required to ensure the tests pass, either by fixing their base image, or by adding extensions to their Grease package.
If Seaside doesn't work and all the Grease tests pass, either we need to change Seaside, or add a test to Grease. We've now begun using Grease as the basis for Pier, Magritte, and MC2, so the hope is that it might become generally useful to other projects that want to write code that runs across platforms (we're not just talking Squeak forks here though; this includes VW, VASt, GemStone, Gnu, etc). That's a lofty goal, though, and we're taking a pragmatic, step by step approach.
Julian
On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Folks,
Package developers want their work to run on various Squeak versions and variants, without needing rewrite. Same for app developers.
Base image builders want to be free of the need to provide backwards compatibility.
This is what I suggest: A package assumes it can use a set of apis of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions should be made explicit, in the form of tests. So, for example, for collections, some package developer might require the "Common Collection API tests" to pass. Then, if his package fails to run, let's say in Cuis, he would run the tests for the apis he needs. If some test fails, he could say "Cuis developers, you're not supporting api XXX", end expect them to fix the issue. But if no test fails, he needs to either modify his code so it doesn't use not-standarized apis, or he could negotiate with (all) base image developers the addition of a new api or use case to the test suite and the base images.
Building these suites is quite some work, mostly to be done by package developers. But it can easily point out responsibilities and duties. It frees package developers of needing to have a deep knowledge of various base images. And it frees base image developers from needing to know details about an unbounded set of external packages. Besides, it puts popular packages that everybody wants to support on equal footing with less-known packages. It also lets base image developers say "we support Common APIs xxx, yyy, zzz, etc.".
All what I say about base images could also apply to packages that offer services to other packages: There could also be test suites to specify their services, and allow users to switch versions of the packages they use knowing what to expect.
What do you think?
Cheers, Juan Vuletich
Heh, I don't know if all developers will find it appropriate for their needs yet; it's obviously providing primarily the stuff that Seaside needs but we're certainly hopeful it will become helpful to others over time. I'm going through an exercise with all the platforms at the moment to extend the defined protocol a bit. Getting agreement on stuff is a slow process... :)
I've said a couple of times I need to write a blog post about Grease's goals... I'll try to do that this week.
Currently Squeak is pretty much using the Grease implementation defined for Pharo, though that may become less practical over time. You could try loading Grease-Core, Grease-Pharo-Core, and Grease-Tests-Core into Cuis and see how much passes. :)
Julian
On Tue, Jan 26, 2010 at 6:44 AM, Juan Vuletich juan@jvuletich.org wrote:
Great! So, it is not a new idea. Let me suggest all the package developers to adopt Grease and help develop it! I'll be really happy to give support for Grease in Cuis.
Cheers, Juan Vuletich
Julian Fitzell wrote:
This is kind of what Seaside's Grease platform is starting to provide, so obviously I think it's a good approach. Grease documents "standard" APIs that we expect on all platforms via unit tests. Each platform is then required to ensure the tests pass, either by fixing their base image, or by adding extensions to their Grease package.
If Seaside doesn't work and all the Grease tests pass, either we need to change Seaside, or add a test to Grease. We've now begun using Grease as the basis for Pier, Magritte, and MC2, so the hope is that it might become generally useful to other projects that want to write code that runs across platforms (we're not just talking Squeak forks here though; this includes VW, VASt, GemStone, Gnu, etc). That's a lofty goal, though, and we're taking a pragmatic, step by step approach.
Julian
On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Folks,
Package developers want their work to run on various Squeak versions and variants, without needing rewrite. Same for app developers.
Base image builders want to be free of the need to provide backwards compatibility.
This is what I suggest: A package assumes it can use a set of apis of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions should be made explicit, in the form of tests. So, for example, for collections, some package developer might require the "Common Collection API tests" to pass. Then, if his package fails to run, let's say in Cuis, he would run the tests for the apis he needs. If some test fails, he could say "Cuis developers, you're not supporting api XXX", end expect them to fix the issue. But if no test fails, he needs to either modify his code so it doesn't use not-standarized apis, or he could negotiate with (all) base image developers the addition of a new api or use case to the test suite and the base images.
Building these suites is quite some work, mostly to be done by package developers. But it can easily point out responsibilities and duties. It frees package developers of needing to have a deep knowledge of various base images. And it frees base image developers from needing to know details about an unbounded set of external packages. Besides, it puts popular packages that everybody wants to support on equal footing with less-known packages. It also lets base image developers say "we support Common APIs xxx, yyy, zzz, etc.".
All what I say about base images could also apply to packages that offer services to other packages: There could also be test suites to specify their services, and allow users to switch versions of the packages they use knowing what to expect.
What do you think?
Cheers, Juan Vuletich
It's green in latest trunk.
I have some suggestions like
convertToSmalltalkNewlines: aString ^aString withSqueakLineEnding
It works in Pharo1.0 and should be much faster in Pharo1.1. It also work in trunk. Did not check Cuis, but the method is stamped from 2004, so I presume it should be compatible backward enough.
Where should I post such remarks?
Nicolas
2010/1/26 Julian Fitzell jfitzell@gmail.com:
Heh, I don't know if all developers will find it appropriate for their needs yet; it's obviously providing primarily the stuff that Seaside needs but we're certainly hopeful it will become helpful to others over time. I'm going through an exercise with all the platforms at the moment to extend the defined protocol a bit. Getting agreement on stuff is a slow process... :)
I've said a couple of times I need to write a blog post about Grease's goals... I'll try to do that this week.
Currently Squeak is pretty much using the Grease implementation defined for Pharo, though that may become less practical over time. You could try loading Grease-Core, Grease-Pharo-Core, and Grease-Tests-Core into Cuis and see how much passes. :)
Julian
On Tue, Jan 26, 2010 at 6:44 AM, Juan Vuletich juan@jvuletich.org wrote:
Great! So, it is not a new idea. Let me suggest all the package developers to adopt Grease and help develop it! I'll be really happy to give support for Grease in Cuis.
Cheers, Juan Vuletich
Julian Fitzell wrote:
This is kind of what Seaside's Grease platform is starting to provide, so obviously I think it's a good approach. Grease documents "standard" APIs that we expect on all platforms via unit tests. Each platform is then required to ensure the tests pass, either by fixing their base image, or by adding extensions to their Grease package.
If Seaside doesn't work and all the Grease tests pass, either we need to change Seaside, or add a test to Grease. We've now begun using Grease as the basis for Pier, Magritte, and MC2, so the hope is that it might become generally useful to other projects that want to write code that runs across platforms (we're not just talking Squeak forks here though; this includes VW, VASt, GemStone, Gnu, etc). That's a lofty goal, though, and we're taking a pragmatic, step by step approach.
Julian
On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Folks,
Package developers want their work to run on various Squeak versions and variants, without needing rewrite. Same for app developers.
Base image builders want to be free of the need to provide backwards compatibility.
This is what I suggest: A package assumes it can use a set of apis of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions should be made explicit, in the form of tests. So, for example, for collections, some package developer might require the "Common Collection API tests" to pass. Then, if his package fails to run, let's say in Cuis, he would run the tests for the apis he needs. If some test fails, he could say "Cuis developers, you're not supporting api XXX", end expect them to fix the issue. But if no test fails, he needs to either modify his code so it doesn't use not-standarized apis, or he could negotiate with (all) base image developers the addition of a new api or use case to the test suite and the base images.
Building these suites is quite some work, mostly to be done by package developers. But it can easily point out responsibilities and duties. It frees package developers of needing to have a deep knowledge of various base images. And it frees base image developers from needing to know details about an unbounded set of external packages. Besides, it puts popular packages that everybody wants to support on equal footing with less-known packages. It also lets base image developers say "we support Common APIs xxx, yyy, zzz, etc.".
All what I say about base images could also apply to packages that offer services to other packages: There could also be test suites to specify their services, and allow users to switch versions of the packages they use knowing what to expect.
What do you think?
Cheers, Juan Vuletich
I guess to seaside-dev is as good a place as any... since Grease is used by Seaside, all the port maintainers are on there...
Julian
On Tue, Jan 26, 2010 at 12:39 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
It's green in latest trunk.
I have some suggestions like
convertToSmalltalkNewlines: aString ^aString withSqueakLineEnding
It works in Pharo1.0 and should be much faster in Pharo1.1. It also work in trunk. Did not check Cuis, but the method is stamped from 2004, so I presume it should be compatible backward enough.
Where should I post such remarks?
Nicolas
2010/1/26 Julian Fitzell jfitzell@gmail.com:
Heh, I don't know if all developers will find it appropriate for their needs yet; it's obviously providing primarily the stuff that Seaside needs but we're certainly hopeful it will become helpful to others over time. I'm going through an exercise with all the platforms at the moment to extend the defined protocol a bit. Getting agreement on stuff is a slow process... :)
I've said a couple of times I need to write a blog post about Grease's goals... I'll try to do that this week.
Currently Squeak is pretty much using the Grease implementation defined for Pharo, though that may become less practical over time. You could try loading Grease-Core, Grease-Pharo-Core, and Grease-Tests-Core into Cuis and see how much passes. :)
Julian
On Tue, Jan 26, 2010 at 6:44 AM, Juan Vuletich juan@jvuletich.org wrote:
Great! So, it is not a new idea. Let me suggest all the package developers to adopt Grease and help develop it! I'll be really happy to give support for Grease in Cuis.
Cheers, Juan Vuletich
Julian Fitzell wrote:
This is kind of what Seaside's Grease platform is starting to provide, so obviously I think it's a good approach. Grease documents "standard" APIs that we expect on all platforms via unit tests. Each platform is then required to ensure the tests pass, either by fixing their base image, or by adding extensions to their Grease package.
If Seaside doesn't work and all the Grease tests pass, either we need to change Seaside, or add a test to Grease. We've now begun using Grease as the basis for Pier, Magritte, and MC2, so the hope is that it might become generally useful to other projects that want to write code that runs across platforms (we're not just talking Squeak forks here though; this includes VW, VASt, GemStone, Gnu, etc). That's a lofty goal, though, and we're taking a pragmatic, step by step approach.
Julian
On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich juan@jvuletich.org wrote:
Hi Folks,
Package developers want their work to run on various Squeak versions and variants, without needing rewrite. Same for app developers.
Base image builders want to be free of the need to provide backwards compatibility.
This is what I suggest: A package assumes it can use a set of apis of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions should be made explicit, in the form of tests. So, for example, for collections, some package developer might require the "Common Collection API tests" to pass. Then, if his package fails to run, let's say in Cuis, he would run the tests for the apis he needs. If some test fails, he could say "Cuis developers, you're not supporting api XXX", end expect them to fix the issue. But if no test fails, he needs to either modify his code so it doesn't use not-standarized apis, or he could negotiate with (all) base image developers the addition of a new api or use case to the test suite and the base images.
Building these suites is quite some work, mostly to be done by package developers. But it can easily point out responsibilities and duties. It frees package developers of needing to have a deep knowledge of various base images. And it frees base image developers from needing to know details about an unbounded set of external packages. Besides, it puts popular packages that everybody wants to support on equal footing with less-known packages. It also lets base image developers say "we support Common APIs xxx, yyy, zzz, etc.".
All what I say about base images could also apply to packages that offer services to other packages: There could also be test suites to specify their services, and allow users to switch versions of the packages they use knowing what to expect.
What do you think?
Cheers, Juan Vuletich
squeak-dev@lists.squeakfoundation.org
-
Juan Vuletich -
Julian Fitzell -
Nicolas Cellier