RE: PositionnableStream>>peekFor: not standard

You know I still think it's wrong and should be implemented the way the
standard says.  Peek should peek regardless of how it is eventually used and
how all of the Smalltalk's implement it.  I can't be the only one that saw
it didn't work as expected and didn't use it because of that.  Notice that
there are few senders of peekFor: and lots of senders of peek even though
many of the senders of peek are really peek fors.  Seems like a me-too
implementation issue.

I'll give you that the uses of peekFor: in the parsers are very cleaver uses
of peekFor:  (ex. negative := peekFor: $-. ) and I do get how and why it's
implemented the way it is but I still won't use it.

I do agree, even though I won't use it, that it should be left the way it is
since it is consistent with all the other Smalltalks.  I wonder how many
other standards are not followed.  Did anyone check #isEmpty on
PositionableStream?

Ron Teitelbaum

> From: Andreas Raab
> Sent: Wednesday, February 28, 2007 5:23 PM
> 
> nicolas cellier wrote:
> > James Foster a écrit :
> >> Actually, in this case I'd suggest that we change the standard! In
> >> each of
> >> the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak,
> >> VisualAge, VisualSmalltalk, VisualWorks) the following returns true:
> >>
> >>     ((ReadStream on: 'abc') peekFor: $a; next) = $b.

Re: Exporting Namespaces

RE: PositionnableStream>>peekFor: not standard

Yes, in this case, change ANSI.

And also have all the Smalltalk implementations add a comment to the
#peekFor: method stating the Smalltalk community has decided the standard is
wrong, and in conflict with established practice.

--Alan

<Nicolas Cellier>
James Foster a écrit :
> Actually, in this case I'd suggest that we change the standard! In
> each of the six Smalltalk dialects I have available (Dolphin,
> GemStone, Squeak, VisualAge, VisualSmalltalk, VisualWorks) the following
returns true:
>
> 	((ReadStream on: 'abc') peekFor: $a; next) = $b.
>
> This makes some sense. If you get back what you expect, why ask for it
> again?
>
> Is there an ANSI errata? If not, could we have a wiki page available
> for such? I have several things to add...
>
> James Foster
>

Totally agree, change ANSI
</Nicolas Cellier>

Re: Java's modules rock? (was Re: election details *PLEASE READ*)

Hi Lex -

Your criticism is well received and understood but unless you have an 
alternative it is also utterly pointless. We can discuss the various 
flaws in the Java module system to death but it doesn't change the fact 
that it is there and it actually works. If you do know of any 
alternatives that allow for scalable and reasonably secure deployment of 
code in effectively unknown environments, I'll happily look at them. If 
they are better than Java, great. It's just ... that so far there are so 
damn few (if any) alternatives.

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.

Cheers,
   - Andreas

Lex Spoon wrote:
> Andreas Raab <andreas.raab <at> gmx.de> writes:
>> J J wrote:
>>> Namespaces ok, but the way they have been done is not always that
>>> great.  Modules are pretty much the same thing, and interfaces?  No.
>>> Traits are much better then interfaces imo.
>> Modules is one area where IMO Java shines. Not necessarily because of
>> the language part but because of the whole ClassLoader/JAR/Applet
>> pipeline (just run Dan's SqueakOnJava in the browser and then think
>> about what must be true to be able to handle that in a reasonably
>> secure fashion).
> 
> Security I'll give you.  That would be great if Squeak could do that.
> Python, incidentally, can do such things with its module system.  We
> could have that too, but having it plus also keeping our existing code
> running is a really hard pair of features.
> 
> Anyway, the rest of Java's modules system I don't like at all.  Let me
> mention two major problems.
> 
> First, it is troublesome to assemble groups of jar's along with their
> dependencies for both compilation and execution.  It takes a while to
> track down all the necessary jar's, and it is hard to debug errors
> having to do with using the wrong version or with jar's that are only
> accessed on some control paths.  To contrast, the ELF loader on Linux
> blows it away.  You compile with -lm and get the math library plus its
> dependencies.  You then run the resulting executable, with no extra
> arguments at all.  Why doesn't Java work like that?  Is C technology
> too advanced?
> 
> 
> Second, linking jar's of different versions gives a lot of spurious
> errors.  Package Universes for Squeak has a big advantage over the
> same thing for Scala in that department.  It is rare for a Scala
> package to remain usable for longer than a couple of months, because
> the packages it links against keep getting changes in the signatures
> and the Java type checker complains.  To contrast, some of the
> packages in the 3.9 stable universe are over a year old.
> 
> It is to the point that Scala users periodically request on the list
> that its version of package univeres use a non-JAR format.  I wish I
> had time to design one, because I think they are right.  JAR is an
> awkward format.
> 
> -Lex
> 
> 
> 
> 
> 

what is the status of the font rendering

Hi

I should say that I'm confused so my question may be idiot.
Here it is: what's the status of the font rendering effort.
Andy if I remember you worked on something and there was some
discussion with sophiers.

Does it make sense to include Rome in the next release and slowly  
migrate to it?

Stef

Re: Java's modules rock? (was Re: election details *PLEASE READ*)

>
> Security I'll give you.  That would be great if Squeak could do that.
> Python, incidentally, can do such things with its module system.

Can you explain more lex?

Stef

Ping ping ping .... to the intention of lex spoon

[sorry] but may be the spam filter of lex is too strong

Hi lex

this is three times that we contact you and we do not get any answer.
The point is to see how we could merge what damien is doing for the  
squeak-dev image
with the universes.

Stef and damien

Re: election details *PLEASE READ*

On Fri, Feb 23, 2007 at 10:35:35PM -0800, Andreas Raab wrote:
> Early on I thought the same way (and this was why we started thinking 
> down that road when Nathanael interned with us). However, in practice it 
> seems like Traits are mostly being used as a thinly veiled version of MI 
> with all the same problems. You have correctly pointed out that Java 
> interfaces are "nothing but abstract virtual base classes in C++" - 
> which coincidentally, was the only way that MI ever worked in C++, which 
> itself has two dozen ways of doing MI wrong and exactly ONE to do it 
> right (abstract virtual base classes). Java choose a stand on that and 
> it worked (which is pretty impressive given that it was the first 
> language that used interface to that extent). Traits seem to reintroduce 
> a number of ways of using MI wrongly (at least that's the feeling that I 
> get when I look at the practical example) and that's why I prefer 
> interfaces.

Forgive me, but I am not familiar with "All the problems
Multiple Inheritance got wrong". I will be testing out how
Multiple Inheritance works in Squeak, since I have made it my
top priority to get ThingLab [1] working in a recent Squeak
system. ThingLab adds multiple inheritance [2] and a constraint
solver to Smalltalk, and both have at least a good theoretical
reason to be there, but I cannot test the implementation yet,
since such a change currently breaks squeak. Multiple
Inheritance has at least a solid theory; I have not had much
experience with an implementation.

[1] http://wiki.squeak.org/squeak/607
    Links to ThingLab papers and code.

[2] http://www.2share.com/thinglab/ThingLab%20-%20Chapter%203.html
    Chapter 3 of the ThingLab paper. Section 2 contains a
    defense of ThingLab's multiple inheritance.

--

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

Re: Java's modules rock? (was Re: election details *PLEASE READ*)

On 1 mars 07, at 06:59, Andreas Raab wrote:

> Hi Lex -
>
> Your criticism is well received and understood but unless you have  
> an alternative it is also utterly pointless. We can discuss the  
> various flaws in the Java module system to death but it doesn't  
> change the fact that it is there and it actually works. If you do  
> know of any alternatives that allow for scalable and reasonably  
> secure deployment of code in effectively unknown environments, I'll  
> happily look at them. If they are better than Java, great. It's  
> just ... that so far there are so damn few (if any) alternatives.
>
> 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.
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.

Stef

Re: PositionnableStream>>peekFor: not standard

I'd guess it was just a nod to the rest of the world.

There are a lot of peeks in a lot of stream implementations out there,
and pretty much all of them leave the result in the stream.

When I see peek in the name of a stream operation,
my hindbrain reads it as non-consuming.

Sometimes there are peeks that alter the stream - operations that
consume everything up to - but not including - a sought-after character.

But the thing you're peeking at is unaffected; that's a very common  
convention
about what the word 'peek'  conveys in the name of a stream operation.

- b

> I can't help but wonder how ANSI ended up with that definition if  
> basically every Smalltalk in existence does it differently. Just  
> one of those "design by committee" decisions? Or perhaps there is a  
> good reason for it that just never made the light of the day?  
> Mostly, the standards committee seemed to have gone with existing  
> notions if there wide agreement on them - peekFor: seems to be one  
> of those cases where the standard went wildly differently and I  
> really wonder why.
>
> Cheers,
>   - Andreas
>