Convincing a harvester (was on SqF list)

Stephane Ducasse ducasse at iam.unibe.ch
Tue May 6 09:46:43 UTC 2003


hi andreas

I agree with you that clean and bug free packages should be loaded in  
the distribution image.
Still they should be unloadeable and we should be able to take a mini  
image and create a big one. I think that this is what the guides have  
in mind.

I think that this is really important that the best package/mandatory  
are loaded because this is frstrutating to have to know (most of the  
time I do not know) that you should load Y and X to get the right  
distribution.

So the next important step is to have a configuration for an image.

Stef



On Tuesday, May 6, 2003, at 12:39 AM, Andreas Raab wrote:

> 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