Re: About pushBack:

stéphane ducasse wrote:
Yes, but...
On a SocketStream we can't position the cursor, once the characters are
read they are no longer in the stream as there is no underlying
collection. The buffer doesn't count, as the content can be replaced at
any time during read or write.

> Do you know if the method pushBack on the XMLTokenizer is ever used?

It's used when parsing and resolving entity definitions.

Michael

2007/8/2, Michael Rueger <[hidden email]>:
So? I don't understand your answer. In Squeak 3.8, 3.9 and 3.10, there
is no other implementor of #pushBack nor is there any sender but
XMLTokeniser.


> > Do you know if the method pushBack on the XMLTokenizer is ever used?
>
> It's used when parsing and resolving entity definitions.

Can you put a 'self halt' on XMLTokeniser>>pushBack: and see if this
method is ever called? I can't find any sender.

--
Damien Cassou

Damien Cassou wrote:

> So? I don't understand your answer. In Squeak 3.8, 3.9 and 3.10, there
> is no other implementor of #pushBack nor is there any sender but
> XMLTokeniser.

Well, if you actually had cared to look you'll would have seen that it
was in 3.8, but Goran's SocketStream which came in in 3.8.1 and 3.9 it
is missing.

>>> Do you know if the method pushBack on the XMLTokenizer is ever used?
>> It's used when parsing and resolving entity definitions.
>
> Can you put a 'self halt' on XMLTokeniser>>pushBack: and see if this
> method is ever called? I can't find any sender.

There are three senders of pushBack: in XMLTokeniser.

And I sincerely hope that you are not cleaning up the Stream hierarchy
in a way so that the rest of the community has then to struggle to make
their stuff work again with the shiny new cleaned up hierarchy.

I'm not exactly bored right now...


Michael

On 2 août 07, at 15:37, stéphane ducasse wrote:

2007/8/2, Michael Rueger <[hidden email]>:
> Damien Cassou wrote:
>
> > So? I don't understand your answer. In Squeak 3.8, 3.9 and 3.10, there
> > is no other implementor of #pushBack nor is there any sender but
> > XMLTokeniser.
>
> Well, if you actually had cared to look you'll would have seen that it
> was in 3.8, but Goran's SocketStream which came in in 3.8.1 and 3.9 it
> is missing.


Ok, right. I tried on 3.8.1.


> >>> Do you know if the method pushBack on the XMLTokenizer is ever used?
> >> It's used when parsing and resolving entity definitions.
> >
> > Can you put a 'self halt' on XMLTokeniser>>pushBack: and see if this
> > method is ever called? I can't find any sender.
>
> There are three senders of pushBack: in XMLTokeniser.

Can you tell us which ones? I just found one and it does not seem to
send #pushBack: to XMLTokeniser but to Stream.

> And I sincerely hope that you are not cleaning up the Stream hierarchy
> in a way so that the rest of the community has then to struggle to make
> their stuff work again with the shiny new cleaned up hierarchy.

If this was the case, do you think we will bother asking the mailing
list? What we are doing is:

- implementing a completely new Stream hierarchy which can work along
with the current one. It's named Nile and there has been some
announcements on this list about it.
- implementing a lot of unit tests for the current Squeak hierarchy and Nile.
- slowly studying all of the methods of the Stream hierarchy to find
which one are useful, which one are buggy...
- writing fixes to improve the current hierarchy (see the 3.10 mailing
list archive and bugs.squeak.org for all the report I did on that
hierarchy).

Stéphane and I are working hard to improve the current hierarchy and
make Nile something worth to use.


--
Damien Cassou

Mike frankly I'm sad that you can say that
        - given that I know you
        - that the state of the stream hierarchy is so shitty and bad (I do  
not count the number of instance variables that are not used
        the overriding breaking behavior of some subclasses.....)
        - given that we always pay attention not to break code (but that  
indeed something we fixed broken behavior)
        - given that we are writing from scratch with test driven a new  
hierarchy.

> And I sincerely hope that you are not cleaning up the Stream  
> hierarchy in a way so that the rest of the community has then to  
> struggle to make their stuff work again with the shiny new cleaned  
> up hierarchy.

So even you can say this kind of shit to young guys willing to make  
squeak a better place to code, so I'm really sad.
But I know in the future I should really create another Squeak like  
everybody else and do not really care.

> I'm not exactly bored right now...
>
>
> Michael

Stef

stephane ducasse wrote:
> Mike frankly I'm sad that you can say that
>     - given that I know you
>     - that the state of the stream hierarchy is so shitty and bad (I do
> not count the number of instance variables that are not used
>     the overriding breaking behavior of some subclasses.....)
>     - given that we always pay attention not to break code (but that
> indeed something we fixed broken behavior)
>     - given that we are writing from scratch with test driven a new
> hierarchy.

My (over)reaction probably was that way because I don't like the way
Nile is designed at all...

But that's just my personal opinion and it wasn't my intention to doubt
the effort you are putting into it.


Michael

2007/8/2, Michael Rueger <[hidden email]>:
> My (over)reaction probably was that way because I don't like the way
> Nile is designed at all...


What don't you like? If I have no feedback, I can't improve and learn.


> But that's just my personal opinion and it wasn't my intention to doubt
> the effort you are putting into it.

Ok.

Even if finally we find that Nile must not replace the current
hierarchy, we will have improve Squeak a lot. I've written hundreds of
tests and they are now included in 3.10.

--
Damien Cassou

Damien Cassou wrote:
> 2007/8/2, Michael Rueger <[hidden email]>:
>> My (over)reaction probably was that way because I don't like the way
>> Nile is designed at all...
>
>
> What don't you like? If I have no feedback, I can't improve and learn.

Unfortunately I don't have any time at all to provide extensive feedback.

I'm known (others would say notorious ;-) ) for being an extreme
minimalist and Nile's structure just seems overly complicated to me.

But, I often don't like my own designs, just to put that statement into
perspective ;-)

> hierarchy, we will have improve Squeak a lot. I've written hundreds of
> tests and they are now included in 3.10.

Yes, and I appreciate this effort!

michael

2007/8/2, Michael Rueger <[hidden email]>:
> Damien Cassou wrote:
> > What don't you like? If I have no feedback, I can't improve and learn.
>
> Unfortunately I don't have any time at all to provide extensive feedback.
>
> I'm known (others would say notorious ;-) ) for being an extreme
> minimalist and Nile's structure just seems overly complicated to me.


We would also want to throw away most of the code.

--
Damien Cassou

Mike

if you have 5 min can you answer this one ;)

Damien Cassou wrote:
> What don't you like? If I have no feedback, I can't improve and learn.

One of the things that I personally don't like is that you seem to be
repeating the same conceptual mistakes of the original library. For
example, what is the *conceptual* difference between an
NSReadableCollectionStream and an NSWriteableCollectionStream and an
NSReadWriteCollectionStream? These seem arbitrary (and not very helpful)
distinctions that would be better modeled by having a single
NSCollectionStream which -if that is really necessary- has an attribute
controlling whether it's going to be used read-only or not.

If I were to rewrite streams I'd actually start at a different point.
Not by making these micro-distinctions about readability and writability
(which seem to make up most of the traits in the version that I looked
at) but rather define three basic types of streams:
* Internal streams: Which are collections+cursor, providing the full
collection interface to streams (which is hugely useful).
* External streams: Which are modeling I/O (so they are potentially
infinite sources, can block, are often asynchronous etc)
* Translating streams: Which are streams that perform operations on
other streams (CRLF conversions, compression, decompression)

If you were to structure a stream library along these lines I think
you'll find that most of the uses for traits would go away because
besides the core protocol (which would appear in class Stream) there is
actually very little duplication of responsibilities in there.

Cheers,
   - Andreas

Thanks andreas
This is indeed interesting.

In fact we follow the ansi decomposition and forced ourselves to be  
backward compatible to avoid that people
complain as usual and bash us about wanting to break things and so  
on. But may be this was a mistake.

Now in the process we got a really good test suite for streams and we  
could rethink the traits recomposition.
We should give some thoughts about your suggestions but thanks for  
having say that

Stef

On 3 août 07, at 00:37, Andreas Raab wrote:

2007/8/3, Andreas Raab <[hidden email]>:

Thank you very much, I really appreciate that kind of feedback. And,
without much more thinkning, I agree with you: we don't really need
that distinction; it complicates things and this is not really useful.
I will try and let the list know. However, we will break backward
compatibility.

Do you suggest that we only need  ReadWriteCollectionStream (which we
have already)?

> If I were to rewrite streams I'd actually start at a different point.
> Not by making these micro-distinctions about readability and writability
> (which seem to make up most of the traits in the version that I looked
> at)


There are 3 main traits:

- one for reading elements sequentially (you just have #next, #peek
and derived methods like #do: #next:...)
- one for writing elements (you just have #nextPut: and derived methods)
- one for positioning in the stream (#position: #position...)

We chose this decomposition because it was the way ANSI defines
Streams and to keep compatibility with the current stream hierarchy.


> but rather define three basic types of streams:
> * Internal streams: Which are collections+cursor, providing the full
> collection interface to streams (which is hugely useful).


this is done but we could do better. For example, we have #do: and
#select:, but other enumerating messages are missing. And #select:
returns a new stream, not a collection. Is this what you are thinking
about?


> * External streams: Which are modeling I/O (so they are potentially
> infinite sources, can block, are often asynchronous etc)


we already modeled File streams. It's incomplete however.


> * Translating streams: Which are streams that perform operations on
> other streams (CRLF conversions, compression, decompression)


This is done. Filters can be created easily.


> If you were to structure a stream library along these lines I think
> you'll find that most of the uses for traits would go away because
> besides the core protocol (which would appear in class Stream) there is
> actually very little duplication of responsibilities in there.

I do not agree. We will see what I can do and will discuss about this
later if you want. But, yes it's possible to avoid duplication,
writing all the methods in the Stream class.

When you have a read-only stream (as with audio/video streams for
example) you really don't want the writing protocol I think. In this
case, you prefer using only the traits that make sense for your class.

--
Damien Cassou

Damien Cassou wrote:
>> If you were to structure a stream library along these lines I think
>> you'll find that most of the uses for traits would go away because
>> besides the core protocol (which would appear in class Stream) there is
>> actually very little duplication of responsibilities in there.
>
> I do not agree. We will see what I can do and will discuss about this
> later if you want. But, yes it's possible to avoid duplication,
> writing all the methods in the Stream class.

I understand that you can't possibly consider writing such a library
without using traits ;-) But to be blunt, since traits are a form of MI,
all the same methods of designing orthogonal systems apply that have for
the last thirty years, and I'm pretty sure it's not only possible but
actually (just as always with SI vs. MI) easier to understand.

Cheers,
   - Andreas

To be blunt back (but intending no disrespect of course, as I respect your code and conversational contributions a great deal), aren't you showing a bit of bias here?  I see that you have a great dislike for MI and believe me, I share it with you.  However you do see Java interfaces as a separate entity, no?

To me this is what Traits are, not a method of MI.  And this is something missing we see in every "OO-ish" system.  Ruby and Strongtalk (at least) made "mixins" to deal with it.  Self went with something that looks like full-blown MI, etc., etc.  What we seem to want in OO systems is basically a formalization of the protocols.  Not just a textual category I can put the methods in, something first class.  I can learn about an object by looking at the "interfaces", "traits" or "type classes" (which ever you prefer) it supports via runtime reflection.  I know you can ask the classes what methods are in what categories but that isn't a guarantee; the classifications are pure convention.

Now, for sure people can abuse traits just as people abuse MI and even SI (look at half the Java hierarchies out there).  In my first experience with Haskell type classes I abused them horribly to create effectively a class hierarchy.  But misuse can indicate a faulty abstraction ( e.g. MI IMO), or that we simply need better training with it.

In the case of Nile here, I have not personally seen the code and it may indeed be overly complex.  But to get to a correct, intuitive stream system how would you deal with the fact that some streams are, by nature read-only and even write-only?  Surely not by a "isReadOnly" variable switch?

Your concept of "Fixed Size", "Variable/Infinite Size" and "Transforming" is solid.  But I think such a setup would be benefited with traits to make the first class distinction between "read", "write" or "read-write".

NOTE:  Having said all this, my statements only stand for "state-less" traits.  IMO "stateful" traits are exactly MI and therefor I am not a fan. :)

Jason Johnson wrote:
> To be blunt back (but intending no disrespect of course, as I respect
> your code and conversational contributions a great deal), aren't you
> showing a bit of bias here?  I see that you have a great dislike for MI
> and believe me, I share it with you.  However you do see Java interfaces
> as a separate entity, no?

Yes. But the main reason is that Java interfaces a) implicitly encourage
minimal interfaces (since you can't provide an implementation there is
no reason to add anything but the minimal set of methods that need to be
supported) and b) that they describe only the "what" (interface) not the
"how" (implementation).

Contrast this with traits (or MI in general) where larger interfaces are
implicitly encouraged (adding utility methods or "refactoring" the
interface which ultimately leads to a *worse* interface which is much
larger than it needs to be and that you can't get rid of since it's
needed by the implementation) and the need to traverse a multitude of
hierarchies to understand where some implementation comes from plus the
need to disambiguate by renaming and you end up in a nice spaghetti bowl.

The ultimate problem with traits (MI) isn't state - it's that it drops
the idea of encapsulation (objects staying individual entities) and
simply merge the implementation into a common name space. That this
isn't a great idea is known as far back as C's #include statement.

Indeed. Having interfaces to describe what is expected of a particular
responsibility is a very, very good idea. Sharing the implementations
via MI-like mechanisms is not. Note however, that for example mixins
preserve the encapsulation of objects in much stronger ways than traits
by not merging the name spaces but rather constructing a unified
inheritance chain. From my POV this is advantageous to what traits do.

> In the case of Nile here, I have not personally seen the code and it may
> indeed be overly complex.  But to get to a correct, intuitive stream
> system how would you deal with the fact that some streams are, by nature
> read-only and even write-only?  Surely not by a "isReadOnly" variable
> switch?

Why not? I haven't seen very many streams which "by their nature" would
be read-only or write-only. There are no such streams in Squeak for
example; there are only those that have been made arbitrarily read-only
(ReadStream) or that have attributes describing their readability state
(FileStream). But even if there were, it is not clear to me that it is
advantageous for a client to receive a MessageNotUnderstood instead of a
ReadOnlyStream error. Since Squeak isn't statically typed, there is not
much of an advantage here.

Cheers,
   - Andreas

Hi. I'm trying to create a simple chat connection between Croquet and
Second Life, and it seems the most safe way to do this (to avoid leaking
private IM into a Croquet island) is to simply let Squeak display the
text i/o outside of Croquet.

So... how do I send a message to squeak and pass one back out of squeak?

This seems a fundamental thing to do, but I'm not sure how to start..

Thanks.


Lawson English.

One suggestion is to create a network connection using sockets.  
Another is to use files.  For example, Second Life might write chat  
messages to a directory that Squeak would periodically check to see  
if new messages have arrived.  It might be easiest to put each  
message into it's own file.

Josh


On Aug 4, 2007, at 12:49 PM, Lawson English wrote:

Thanks. I found something named OSProcess, but from the documentation, I
can't tell if it i s actualy workign on a Mac, or on any other OS for
that matter. Nor can I figure out how to download it if need be since
the latest version is listed as 4.2.2 while the SqueakMap Package Loader
only lists 4.0.1, which won't load anyway due to some kind of error.




Joshua Gargus wrote: