Squeak Foundation Board 2007 Candidates

stephane ducasse wrote:
>> In short: What impresses me about the Java solution is not that it's
>> flawless - what impresses me is that it works, that people actually
>> use it to deploy code and this code actually works in the way intended.
>
> But do you think that VW, VA code does not work once deployed? I would
> like to understand why Jar are better than parcels for example.

Here are some "simple" issues: How do Parcels deal with conflicting
modifications to base classes? Say, one that says "Object>>isCommon
^true" and one that says "Object>>isCommon ^false"? (Java simply doesn't
allow modifications to base classes which, really, isn't such a bad
thing from the point of view of modularity)

Another one: Which assurances do parcels give in terms of security? As
far as I know there is no bytecode verifier, parcel have full access to
the entire Smalltalk namespace (covered by ClassLoaders in Java), there
are no limitations in terms of what operations a parcel can perform (nil
become: true; Java had a good set of fixes in this area to get it right
and not to leak ambient authority) and I don't think VW even knows what
a sandbox is.

A third one: Which namespace are parcels loaded into? Can two different
versions of parcels be loaded side-by-side? How (if at all) do they
affect each other? Etc.

> May be I should post to VW to see what are the problem with deployed
> code in VW.
> A parcel in VW has dev and depl prerequisites and it seems to work too.

Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with projects
and change sets and it seems to work, too. Sorta. Kinda. :-)

Cheers,
   - Andreas

>>> In short: What impresses me about the Java solution is not that it's
>>> flawless - what impresses me is that it works, that people actually
>>> use it to deploy code and this code actually works in the way intended.

Kind of JARs in Smalltalk? Pleeeeeease, please, please, please don't do that, no! *scream*

I've done Java in my main job since 1996 till last year from very small projects up to very large
applications. And we allways have been fighting with JARs. They are a kind of a DLL hell, but only
for the Java environment. Especially if you integrate different open source and commercial
frameworks. They all use other frameworks, but almost every time in a different version. So you're
fighting with the order inside your CLASSPATH every day and sometime have no way to resolve the
conflicts. *sigh*

.NET has version numbers in their assemblies. So you can deploy the same assembly in different
versions in the same system. But still own installed applications are depending on those external
assemblies. That often leads to problems too.

What I really like when working with VisualWorks is, that I integrate the right parcels into my
image, most time without version conflicts. And if there's one detected through my tests I can fix
it inside my image. This image is then deployed en bloc, well tested and not relying on the admin
to configure the libs the right way.

mue

--
**
** Frank Mueller / Oldenburg / Germany
**
** http://frank.mweb.de
**

On 1 mars 07, at 10:22, Andreas Raab wrote:

yes but you cannot have extra behavior and subclass does not solve  
the problem. I can show a lot of problems where not having
class extension can be killing you.

I think so. In fact in VW3.0 there were a hidden namespace just to be  
able to have atomic unloading.

How is the Thinglab rework going? What needs to be done to get it
running? How about in 3.8?

Cheers,

Alan

-------------

At 11:32 PM 2/28/2007, Matthew Fulmer wrote:

The problems with MI are basically the same as manual memory management:  
(a) to easy to shoot yourself and anyone near you and (b) hinders
composability/encapsulation.

The problem is, if you have multiple inheritance then from now on people
probably need to know what classes any class they inherit from inherit from
themselves, since you may be introducing the same base classes from
different hierarchies points.

There are ways to deal with it of course, but for me it is a red flag that
maybe I am walking down the wrong road when I see such things.  Especially
when an "interfaces with default implementations" seems to work so well.


_________________________________________________________________
With tax season right around the corner, make sure to follow these few
simple tips.
http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline

Matthew Fulmer wrote: There is a newer constraint solver package called *Cassovary, that
Joshua Gargus ported to Squeak.
I have a changeset I can digg up if you are interested.

Karl
*

Andreas Raab <[hidden email]> writes:

Wasn't there a big collections refactoring done with traits?  I have
been meaning to dig it up and read through it, but have never found
the time.

Here's one use of them, though, that I use all the time in Scala's
variation on traits.  You can make Squeak's Magnitude be a trait
instead of an abstract class.  That is, given a < method, which is
abstract in Magnitude, you can have Magnitude define all the other
methods for you.

Or closer to your heart, Andreas, how would you like to have a
Rectangular trait for all those #left, #right, #topLeft, etc. methods?
It would require a #rectangle method, which for Rectangle is "yourself"
and for Morph is "bounds".  Then all these helper methods
would get defined for you by the trait.

This usage of traits may be small one by one, but they are enough to
convince me thre are some very nice uses of traits that are not
available in Smalltalk.  What they do is take a thin interface and
widen it to a rich interface.  They let you *define* classes using the
thin interface, and *use* them with the rich interface.

Anyway, I don't know anything about the Squeak version.  My day jobs
have kept me too busy to look into Squeak's traits as I would like to.
However, I can vouch for the feature, just based on the above
examples.


-Lex

Lex Spoon wrote:
> Wasn't there a big collections refactoring done with traits?  I have
> been meaning to dig it up and read through it, but have never found
> the time.

This was one of the academic exercises I was referring to, see here:

http://citeseer.ist.psu.edu/581397.html

Also, its main focus was on squeezing entropy out of the system (i.e.,
eliminate code duplication) not necessarily improvements in design (the
paper claims some but I'm pretty sure that *any* serious bit of
refactoring of a 20 year old class hierarchy could improve a few things ;-)

> Here's one use of them, though, that I use all the time in Scala's
> variation on traits.  You can make Squeak's Magnitude be a trait
> instead of an abstract class.  That is, given a < method, which is
> abstract in Magnitude, you can have Magnitude define all the other
> methods for you.

How interesting. Does Scala use traits extensively?

> Or closer to your heart, Andreas, how would you like to have a
> Rectangular trait for all those #left, #right, #topLeft, etc. methods?
> It would require a #rectangle method, which for Rectangle is "yourself"
> and for Morph is "bounds".  Then all these helper methods
> would get defined for you by the trait.

Did I mention toy examples before? ;-) Yes, that is one of those.
Unfortunately, in real code I only ever have that problem in about a
single base class so it's usually not worth creating an extra entity
(trait). In addition, I have found that I prefer to carefully choose
which parts of the interface to expose and which ones not - Players in
Tweak expose a partial set of rectangle operations, a partial set of
collection operations but not both to the full extent simply because
that would be crazy overload. Where I need the full interface I prefer
aspects so that if you really really need #squishedWithin: you say
"player bounds squishedWithin: aRectangle" instead. Which gives you the
advantage of providing a useful, filtered interface as the default
without eliminating access to the full interface. And finally, the
rectangle interface is very stable and hardly ever changes so evolution
of interfaces isn't really an issue either.

> This usage of traits may be small one by one, but they are enough to
> convince me thre are some very nice uses of traits that are not
> available in Smalltalk.  What they do is take a thin interface and
> widen it to a rich interface.  They let you *define* classes using the
> thin interface, and *use* them with the rich interface.

So where are these uses? Can you point me to any in real applications?

> Anyway, I don't know anything about the Squeak version.  My day jobs
> have kept me too busy to look into Squeak's traits as I would like to.
> However, I can vouch for the feature, just based on the above
> examples.

Well, I'm still on the lookout trying to find a really convincing
example of use for traits. If you can point me to one (e.g., point me to
actual code in an actually running system) I'd really appreciate it.

Cheers,
   - Andreas

On 01 Mar 2007, at 1 March/10:22, Andreas Raab wrote:

Last one wins.

Not that the fact that the Java does not allow modifications to  
baseclasses (nor even subclassing in most cases), causes us all kinds  
of problems.

>
> Another one: Which assurances do parcels give in terms of security?  
> As far as I know there is no bytecode verifier, parcel have full  
> access to the entire Smalltalk namespace (covered by ClassLoaders  
> in Java), there are no limitations in terms of what operations a  
> parcel can perform (nil become: true; Java had a good set of fixes  
> in this area to get it right and not to leak ambient authority) and  
> I don't think VW even knows what a sandbox is.

Security is the one and only advantage of JARs, I fully agree.

>
> A third one: Which namespace are parcels loaded into? Can two  
> different versions of parcels be loaded side-by-side? How (if at  
> all) do they affect each other? Etc.

A temporary one because the load is atomic and can be reverted. Once  
the load succeeds the code is put in the image. Parcels work pretty  
well for code deployment. See the paper Eliot and I wrote for ESUG a  
couple of years ago (it is on my webpage).


>
>> May be I should post to VW to see what are the problem with  
>> deployed code in VW.
>> A parcel in VW has dev and depl prerequisites and it seems to work  
>> too.
>
> Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with  
> projects and change sets and it seems to work, too. Sorta. Kinda. :-)

rofl :-)

>
> Cheers,
>   - Andreas
>
>

Note that JAR files are not really what I would call a module  
mechanism; I am currently fighting them in the context of a not-quite-
trivial application with lots of dependencies and boy, I wish that  
they would be somewhat more robust. Dependency management, version  
management and is simply not handled. Let alone proper packaging with  
'open classes' or 'class extensions' (so that you cannot even  
properly deploy a visitor pattern independently from the hierarchy it  
works on, actually the key of that pattern). Or another one of my  
favourites, which was properly handled in the Envy system btw,  
conditional loading of modules/code. No such luck :-(

The people at Eclipse had to work around all of this; all the plug-in  
stuff of Eclipse is done via their own mechanism built on top of Java  
such that they actually can deploy plug-ins a bit easier. And even  
then it is not possible to unload (!!!!!) any code, and the result is  
a difficult beast with XML config files that interact with the JARs  
things etc. Ugly, ugly, ugly.

I haven't looked at it in any detail, but if you want to look at  
module mechanisms from mainstream languages that are being used I  
would look at the one in C#. At least you have major and minor  
version numbers ;-) Anybody had a look at that ?

On 01 Mar 2007, at 1 March/10:22, Andreas Raab wrote:

2007/3/5, Roel Wuyts <[hidden email]>:
At ESUG 2006 James Robertson said he doesn't use Parcels for code
deployment because they are just not reliable (of course he doesn't
use store either). He uses change sets (or .st files, I don't remember
exactly) instead.

Philippe

Umm, I must have been misunderstood.  I use Store for both Silt (my
blog server) and BottomFeeder - see the public repository for the
long history of both products.

I use parcels as my deployment mechanism for both Silt and
BottomFeeder.  For the blog server, I have the application server
load from parcels each time it starts (thus giving me a
deterministic, reproducible startup procedure).  I use parcels to
build the BottomFeeder application, and have parcels as the update
mechanism - i.e., you can check for updates in the app, and it will
download parcels and load them at runtime (and at startup the next
time it runs).

I'm not sure where this impression comes ffrom, but it's not the case.

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Sorry. I must either have misunderstood you or remember incorrectly.

Philippe

2007/3/6, James Robertson <[hidden email]>: