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

Julian Fitzell jfitzell at gmail.com
Wed Jan 27 07:12:24 UTC 2010


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