[squeak-dev] Cross fork compatibility of packages: A proposal

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Jan 26 20:39:55 UTC 2010


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 at 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 at 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 at 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
>>>>
>>>>
>>>>
>>
>>
>>
>
>



More information about the Squeak-dev mailing list