Convincing a harvester (was on SqF list)

Andreas Raab andreas.raab at gmx.de
Mon May 5 22:39:20 UTC 2003


Daniel,

> Wasn't clear where you intended to post this (you sent a copy to each 
> list), so I'm answering where it fits me :-)

Auto-completion screw-up. It was intended to go to Squeak-Dev but my mailer
had seen that before this I wrote a message to SqF so it moved SqF up to #1
in auto-completion (and I hit the send button too fast once more ;-)

> It's possible us Guides have somehow failed to make this 
> clear, but this is absolutely, positively, a very critical
> kind of post.

I don't think you failed to make this clear. There has always been a general
encouragement about it. But what I think you _have_ failed to do is to
provide concise responses to the proposals. In other words: If someone posts
something there isn't a clear response of what is going to happen about it.
Almost all of the discussions I've seen ended in some more or less vague
statement that essentially said "we'll wait until X and then we'll review
the issue". Which - unless the topic in question was put up onto your table
again - has never happened (or at least I don't recall any such case). It
leaves one with the kind of impression that "nothing happens". Not
surprisingly, this is part of the frustration I read out of Diego's post
(besides some other issues).

> > Funny you should mention this (see my post at SqF list) as 
> > I was just wondering how exactly one does this. 
> Speak up.

Which I did ;-)

> Specifically, address these things -
> - you explain why it improves something that everyone needs (even if
> this was clear the author thinks so, a second opinion sure helps).

Which I did ;-)

> - You say the code is good enough (review, lint, test), or 
> work to make it so

Which I did ;-)

> - You help see a way to integrate it. If it's small, that's usually
> pretty trivial. If it's big SUnit tests will help. If it 
> affects lots of stuff, it might take some thinking.

Which I didn't say explicitly but it's up there so "integrating" it just
means load it ;-)

> > * Network rewrite 
[...]
> I tend to agree. I tested this extensively for mail, and was 
> very happy with how it worked for that. I was expecting Michael
> was going to continue doing the rest of the protocols, or work
> out some division of the territory with Craig and Flow, but I
> guess life intruded. Since it seems (I read some of the code,
> but not all) like a good replacement of
> the current code for the same functionality, it might be best to just
> bring it in in 3.6a, and remove the remains of the previous socket
> implementation in 3.7a. If anything is broken, what people care about
> will be fixed.

My thoughts exactly. Yet, there hasn't been any feedback on what's going to
happen here in ages. My interpretation of the current situation was that the
ball is in your hands (btw, this is Mike's interpretation too) and that
"someone" (aka: the guides/harvesters) group needs to make a decision about
whether to go forward or not on this issue.

> > * TrueType text style
> >   Why: If you have to ask this question you are not using 
> >   Squeak for any media activity. 
> You may find this curious, but actually, I don't. So I have to.

<OT>
Is it by any chance possible that current group of harvesters/guides is
pretty heavy on the system-architecture/networking side and extremely
lightweight on the media side? Any "media person" who has ever tried the TTF
stuff (as in: waded through all the stuff and SqueakMap and found the gold
nugget) would never use anything else for presentations and the like. Really
- this is not "optional" from a media point of view. High-quality font
support is critical. That I even have to say this ...
</OT>

> > If you do, then you don't have to ask. This is not a package
> > - it's a basic requirement for anyone who does media stuff.
> Ok, then let media stuff doers load the package.

Those who have found it in all the stuff at SqueakMap probably have (hint:
look at Diego's look enhancements which used ... guess what).

> We'll eventually also be removing movie playing,
> sound and all that happy crappy into packages that
> will be very easy to load, all at once, for people that 
> want media stuff.

<OT>
I need to warn you about this. I've been thinking for a while now about the
effects of having "everything easily loadable" but nothing actually in a
release image. I strongly believe that the effect of this will be an
arbitrary number of forks within a couple of months. Minimalism is not why
people buy into Squeak - it's because Squeak is a _rich_ environment. At the
point where Squeak itself is an empty shell various people will make up
their own versions and introduce their own idiosynchracies. If any (worse:
more than one) of those is widely accepted it is effectively a fork. If it
isn't, I'd expect that we'll loose a lot of potential users as they would
then see Squeak as "just another development environment" which it really
isn't.
</OT>

> However, if you want to say it makes Squeak
> prettier/nicer for all audiences, I'd be glad to read some
> details/raves :-)

If you really need an "explanation" then you're not the right audience (this
is like explaining to an artist why the kernel cleanup is necessary - it's
about quality, about beauty and if you're not "that kind of person" you
simply won't see it). You won't find any raves either because the quality of
the font support is not as good as "we" (the media Squeakers) would like it
(not Yoshiki's fault btw, but if I had the choice I would prefer the Xft2
quality...). But it is still about ten billion times better than what's in
there right now.

Sigh. Guess I have to find some other harvester to get this point across.
Isn't there any harvester/guide who is a "media person"?

> > * Multilingualization
> First of all, I agree this eventually affects something that should be
> in the base image, and probably care about this more than most, since my
> primary language has zero support in current Squeak. And Yoshiki has
> gone the extra mile and made it an SM package, so theoretically the
> barrier to test it is zero. I don't understand why there's almost no
> feedback, the null hypothesis is that nobody cares enough. In which
> case, I tend to not want it in the image.

I completely, absolutely, and utterly disagree. This is a strategic issue.
The "lack of feedback" as you call it (btw, there _has_ been feedback on
Japanese) for other scripts is mainly due to the fact that currently there
is no easy way to define your own scripts as there are no kernel notions for
how to represent these things.

> I'm not very certain about this, because it seems like it is maybe a
> problem of PR (there not being a cool demo or something), rather than
> lack of goodness/relevance, but I'm no sure bundling it into the image
> is the right way to fix that. Hmm, even as I write this, I get the
> feeling it might be wrong, though I'm not quite sure why.

Because it's a strategic thing. If you want multi-lingualization you need
some core notions about how these things are represented. These _must_ be
present in the base image (if only for being able to leave the option for
other scripts without going through endless hoops). Besides that, particular
scripts (and their support) may be hosted elsewhere but the core notions
have to be there.

> > There are a couple of other packages where I think it would be really
good
> > if they were part of the kernel image but these three I feel mostly
strongly
> > about.
>
> Let us know.

Okay here are a few more:

* URI
 
http://map2.squeakfoundation.org/sm/package/7946486c-aa2a-46ea-b91f-b5f69137
b2b5
  Why: It's a _compliant_ implementation for URIs. If you ever tried to do
anything a bit "out of the ordinary" with the current support you'll find
that they work in 80% of the cases (if that much) but then you need some of
the missing 20% and you're screwed. So if we need network/uri support in the
base image (and I think we do) then I want a compliant and not a half-broken
implementation.

* RegExp
 
http://map2.squeakfoundation.org/sm/package/97d5f313-96bf-462a-b2ea-0cb2f11f
3e97
  Why: It's a basic functionality which is replicated in lots of different
methods (tokenize: findTokens: etc) and which could and should be
represented by RegExp matches. If you ever needed a quick grep for something
(no matter in which context - be that Celeste or something else) it is
definitely worthwhile to have "deep down" RegExp support.

* Closure primitive support
 
http://map2.squeakfoundation.org/sm/package/bc4a6c45-ef9f-4a36-9f1c-25c2debe
7c61
  Why: A few simple primitives which enable the closure compiler to be
usable.

* BMPWriterPlugin
 
http://map2.squeakfoundation.org/sm/package/a2fdba5e-670a-4300-b6ee-cc404e90
976f
  Why: A factor of 100 in bmp writing for exactly one method.

[Note: if there were support on other platforms for it I'd also put the
native font package on this list].

Cheers,
  - Andreas



More information about the Squeak-dev mailing list