Using the Grease compatibility layer? Not yet...

The Grease package coming with Seaside has recently been mentioned on this
list as a possible compatibility layer for cross-dialect projects. As I am
still hoping that I will find the time to port JNIPort to Pharo, I had a
look at it.

Currently, I don't think it would be useful for porting JNIPort to other
Smalltalk dialects. Here are the reasons why I don't think I want to use it
in its current state:

The package Grease-VisualWorks-Core depends on several prerequisites which I
don't want JNIPort to depend on. Among them are: Store-Base, MIME,
Protocols-Common, and even SUnitToo. SUnitToo seems to be superfluous.
Store-Base is needed because of a single dependency on the method
Filename>>contentsOfEntireBinaryFile (why this method is in Store-Base in
the first place escapes me).

MIME is needed because Grease has a method for sending Email. Actually, the
method Net.RFC822Message>>send it used, but it is not implemented in any
package in the prerequisites of Grease. It would be better if such
special-purpose code were part of a separate package, in this case for
cross-dialect networking support.

Protocols-Common is needed for using DecodedStream. Why this class isn't in
the same package as EncodedStream, but in a package for networking support,
isn't clear to me. Anyway, I don't want Protocols-Common as a prerequisite.

To be useful as a compatibility layer, Grease would have to be split into
different packages. And it should have some documentation. It's not too hard
to figure out, but still.

Some classes in Grease seem to be superfluous for a compatibility layer.
What's the motivation for GRInflector, which pluralizes nouns, and
GROrdinalizePrinter, which prints a number as an ordinal number, but which
both only work for English? Both do not have much to do with cross-platform
compatibility (ditto the other GR*Printers).

BTW: Why does Grease exist at all? There is already Sport, which is much
older, has a cleaner structure with independently usable packages, and
provides most of what Grease adresses (except the GR*Printers of course).
Wouldn't it be better to work with Bruce Badger on extending Sport instead
of starting another compatibility layer?

Best regards,
Joachim Geidel


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks for the list. I'll work through it and see if I can't reduce the
number of dependencies for you in the future.

Michael

On 4/24/10 12:28 PM, Joachim Geidel wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 10-04-24 8:28 PM, "Joachim Geidel" <[hidden email]> wrote:
> The Grease package coming with Seaside has recently been mentioned on this
> list as a possible compatibility layer for cross-dialect projects. As I am
> still hoping that I will find the time to port JNIPort to Pharo, I had a
> look at it.
>
> Currently, I don't think it would be useful for porting JNIPort to other
> Smalltalk dialects. Here are the reasons why I don't think I want to use it
> in its current state:

Useful feedback, of course. I'll leave Michael to comment on the VW-specific
issues and answer what I can from your more general list.

> MIME is needed because Grease has a method for sending Email. Actually, the
> method Net.RFC822Message>>send it used, but it is not implemented in any
> package in the prerequisites of Grease. It would be better if such
> special-purpose code were part of a separate package, in this case for
> cross-dialect networking support.

Agreed. I don't believe this method is in Grease in the newest version (I'm
pretty sure we pulled it up into Seaside code for now). Remember that Grease
began as Seaside-specific and we've only relatively recently begun to ensure
it is less so.
 
> To be useful as a compatibility layer, Grease would have to be split into
> different packages. And it should have some documentation. It's not too hard
> to figure out, but still.

It should, of course, be split as it grows. You'll notice (at least in the
Squeak/Pharo version) that code is split into class categories that could be
split into packages if required. Currently, the only thing possibly worth of
splitting is the printer stuff and the overhead of having more packages
makes that split, I think, not currently worthwhile.
 
As for documentation, yes of course that would be good, though the intention
is that (unlike with, say the ANSI standard) the unit tests are the primary
form of documentation.

> Some classes in Grease seem to be superfluous for a compatibility layer.
> What's the motivation for GRInflector, which pluralizes nouns, and
> GROrdinalizePrinter, which prints a number as an ordinal number, but which
> both only work for English? Both do not have much to do with cross-platform
> compatibility (ditto the other GR*Printers).

I personally agree about GRInflector. I have had similar disagreements with
a number of developers on a number of projects over my career. The fact is,
pragmatically, some people find it useful and its presence doesn't really do
any harm (other than the bad taste in your mouth).

The Printer classes, in general, I think are useful. They may not be useful
to you (and as I said above, they are definite candidates for a sub-package
when we get to that size) but they represent a common task that needs to be
done and for which no existing cross-platform API exists. I would love to
see a counterpart set of parsing classes as well.

> BTW: Why does Grease exist at all? There is already Sport, which is much
> older, has a cleaner structure with independently usable packages, and
> provides most of what Grease adresses (except the GR*Printers of course).
> Wouldn't it be better to work with Bruce Badger on extending Sport instead
> of starting another compatibility layer?

Grease came directly out of Seaside's needs, plain and simple. And as the
people who have ported Seaside 3.0 will tell you, it is simple and makes
that job very easy. Having subsequently used it myself to port Magritte and
Pier, I found it worked great for those projects as well. We found it
useful, so we're trying to make sure it remains general enough that others
who find it useful can use it.

If you like Sport better, feel free to use it, of course. When we looked at
Sport for the Seaside project, the approach just didn't feel like a good fit
for us.

Julian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Package “Grease-Namespace” configures the VisualWorks virtual machine
(VM) to use IEEE floating point primitives. Among other changes, this
means that a zero-division does no longer throw an exception. Grease
does this by adding the following post-load-action:

ObjectMemory registerObject: true withEngineFor: 'IEEEFloatingPointPrimitives'

We had to change this back to the default behavior after loading
Seaside. We do a few [] on: Zero do: [] and those would no longer
work.

I am not sure if IEEE floating point primitives is a requirement for
Seaside. So far we have not had any problems with Seaside.

Runar

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 4/26/10 10:57 AM, Runar Jordahl wrote: It's expected by Grease, so I'm sure some of the seaside tests will fail
without it. But it probably doesn't affect the actual runtime of seaside.

Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 24 April 2010 20:28, Joachim Geidel <[hidden email]> wrote:
> BTW: Why does Grease exist at all? There is already Sport, which is much
> older, has a cleaner structure with independently usable packages, and
> provides most of what Grease adresses (except the GR*Printers of course).
> Wouldn't it be better to work with Bruce Badger on extending Sport instead
> of starting another compatibility layer?

Julian is now based in London as am I, and in fact we were both at the
London Smalltalk User Group meeting earlier this week, so perhaps we
can work together to bring Grease and Sport together.   I hope so.   I
think it's worth the effort to make Smalltalk code easily portable
between dialects.

All the best,
    Bruce
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dear Bruce,

Am 29.04.10 23:53 schrieb Bruce Badger:
>> Wouldn't it be better to work with Bruce Badger on extending Sport instead
>> of starting another compatibility layer?
>
> Julian is now based in London as am I, and in fact we were both at the
> London Smalltalk User Group meeting earlier this week, so perhaps we
> can work together to bring Grease and Sport together.   I hope so.   I
> think it's worth the effort to make Smalltalk code easily portable
> between dialects.

This is good news. Bringing the two frameworks together such that they are
either merged or restructured in a way that one complements the other would
be good. Otherwise, it could even happen that the two become incompatible by
implementing the same extension methods to base classes, which would make it
harder to use, e.g., the PostgreSQL interface together with Seaside.

Best regards,
Joachim Geidel


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc