Re: About pushBack:

SqueakSource has newer versions.  For example: http://
www.squeaksource.com/OSProcess/OSProcess-dtl.36.mcz

How do you intend to use OSProcess?  Unix sockets or pipes would be  
more efficient than a TCP socket (although it hardly matters for text  
chat messages).  But then you have to have a different solution for  
Windows.  It seems like more trouble than necessary.

Josh


On Aug 4, 2007, at 5:03 PM, Lawson English wrote:

Joshua Gargus wrote:
> SqueakSource has newer versions.  For example:
> http://www.squeaksource.com/OSProcess/OSProcess-dtl.36.mcz
How do I get that into squeak? It doesnt seem to appear in the
Montecello browser, and I'm not sure how to load it from the download.

>
> How do you intend to use OSProcess?  Unix sockets or pipes would be
> more efficient than a TCP socket (although it hardly matters for text
> chat messages).  But then you have to have a different solution for
> Windows.  It seems like more trouble than necessary.


I might be. The sample source code I have from IBM just uses pies for
Linux. I'd like a generic solution to something that should be trivial,
but right now, I'd settle for a proof of concept working on any platform.

Not that appears likely at the moment.

On Aug 4, 2007, at 5:37 PM, Lawson English wrote:

> Joshua Gargus wrote:
>> SqueakSource has newer versions.  For example: http://
>> www.squeaksource.com/OSProcess/OSProcess-dtl.36.mcz
> How do I get that into squeak? It doesnt seem to appear in the  
> Montecello browser,

Do you have the OSProcess repository in Monticello's list of  
repositories?  You should have an entry like 'http://squeaksource.com/ 
OSProcess'.  If not, you must add it.

> and I'm not sure how to load it from the download.

There is a 'load' option when a .mcz file is selected in a Squeak  
'file list'.

Josh

Joshua Gargus wrote: Thanks,  got it to load. Stil lnot sure the best way to proceedd though.
Windows requires one to use sockets for Interapplication communication?

On Aug 4, 2007, at 5:03 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.

The 3.8.18beta1U mac carbon VM in the 3.9 distribution folder now has  
the OSProcess plugin included.
You just need the latest smalltalk software to use. The instructions  
should tell you "hopefully" how to quickly test it to see if it works  
for you.


--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

John M McIntosh wrote: Thanks very much.

Hi

I myself had problems to install CommandShell via UniverseBrowser.  
What I did to get it working on my Powerbook was:

I take the latest squeak-dev image, then install OSProcess via  
UniverseBrowser, then download

http://wiki.squeak.org/squeak/uploads/1914/CommandShellV3-0-5-dtl.sar

and install it via FileList (load)

open a workspace and do Alt-p on

OSProcess thisOSProcess waitForCommandOutput: '/bin/ls'

Everything okay?
Enno

On 8/4/07, Andreas Raab <[hidden email]> wrote:

Oh, and I forgot to mention:

I don't personally see traits as something that comes up that often.  99% of the time inheritance, or some OO pattern gives the best solution.  But in that 1% something like a trait is the correct solution and not having it shows up a design wart.

Personally the thing that stuck out to me in my travels through the Squeak image was just the Magnitude class.  I personally think that should just be a trait.  In fact I would see at least equality and comparability as separate traits.  By having it be a class causes certain design warts [1] imo.

[1]  In the case where a class should really inherit somewhere else you either have to inherit from Magnitude and duplicate the other code, inherit from the correct class and duplicate the Magnitude code or change the highest class in your hierarchy to inherit from Magnitude instead of Object.  These solutions are all code smell imo.

Jason Johnson a écrit :
Very true.
Try to extend algebra with matrices, vector space, or symbolic
computation, and you will see that simple inheritance makes it hard to
avoid duplications.
This makes me think of axiom which has a separate hierarchy for
inheriting mathematical properties...

Nicolas

Jason Johnson wrote:
> I don't personally see traits as something that comes up that often.  
> 99% of the time inheritance, or some OO pattern gives the best
> solution.  But in that 1% something like a trait is the correct solution
> and not having it shows up a design wart.

I completely agree with this statement. And in return I *urge* you to
look at actual code and stand corrected ;-) Let's take an example:

Here is what the base class hierarchy in Nile looks like:

AbstractCollectionStream
   ReadableCollectionStream
     ByteReader
     StringReader
   WritableCollectionStream
     ByteWriter
     StringWriter
     ReadWriteCollectionStream

Except from the -somewhat arbitrary- distinction between byte and string
reader it's pretty standard and looks (if you replace
AbstractCollectionStream with PositionableStream) fairly similar to what
we have today:

PositionableStream
   ReadStream
   WriteStream
     ReadWriteStream

But now, let's look at how it works. Here is how the Nile class library
looks when we add the traits (written as <trait>):

AbstractCollectionStream
   ReadableCollectionStream <ReadableCollectionStream - position,
setPosition, collection, setCollection:>
     ByteReader <ByteReading - next, nextInto:, next:>
     StringReader <CharacterReading>
   WritableCollectionStream <NSTWriteableCollectionStream - position,
setPosition:, collection, setCollection:>
     ByteWriter <ByteWriting - nextPut:, nextPutAll:>
     StringWriter <CharacterWriting - nextPut:>
     ReadWriteCollectionStream <ReadableCollectionStream - size,
collection, setCollection:, position, setPosition:>

and the traits hierarchy itself is here:

<ByteReading>
<ByteWriting>
<CharacterReading>
<CharacterWriting>
<CollectionStream>
        <PositionableStream>
<GettableStream>
        <Stream>
<PositionableStream>
        <Stream>
<PuttableStream>
        <Stream>
<ReadableCollectionStream>
        <GettableStream @ basicBack -> back>
        <CollectionStream>
<Stream>
<WriteableCollectionStream>
        <PuttableStream>
        <CollectionStream>

Now let's start counting: Instead of a single inheritance hierarchy with
8 entities (classes) that I need to know about I have 19 entities (8
classes, 11 traits) in an MI hierarchy. In addition we have nested
traits (so you'll have to know the other inheritance branches fairly
well), renames (ReadableCollectionStream) and exclusions (6 out of 8
classes have exclusions) complicating the structure even further. A more
realistic complexity measure (counting the number of occurrences of the
various entities) ends up with about 4x the complexity of the traits
version (which is certainly what it feels like).

So why would this be advantageous to a single inheritance hierarchy?

I'm pretty sure someone will come back and say "but wait! isn't the idea
that *other* clients will use those traits and in return will be simpler
and better and easier?" So let's look at this too:

I'll be looking at the Files hierarchy in Nile for the sole purpose that
it is the only comparable piece that has counter parts in Squeak today
and Squeak's files are certainly messy enough that they need a good
makeover. So here is the hierarchy for files in Nile (again without the
traits):

AbstractFileStream
   AbstractBinaryStream
     ReadFileBinaryStream
     WriteFileBinaryStream
     ReadWriteFileBinaryStream
   AbstractTextStream
     ReadFileTextStream
     WriteFileTextStream
     ReadWriteFileTextStream

The structure is ... shall we say unusual and (I think) heavily
influenced by the desire to create permutations of existing traits
instead of applying other OO design principles. And here is the version
with traits information included:

AbstractFileStream
   AbstractBinaryStream
     ReadFileBinaryStream <ReadFileStream - fileName, bufferType,
getFileID, setFileID: setFileName> <ByteReading>
     WriteFileBinaryStream <WriteFileStream - fileName, bufferType,
getFileID, setFileID: setFileName> <ByteWriting>
     ReadWriteFileBinaryStream <ReadFileStream - fileName, bufferType,
getFileID, setFileID: setFileName> <WriteFileStream - fileName,
bufferType, getFileID, setFileID: setFileName> <ByteWriting>
   AbstractTextStream
     ReadFileTextStream <ReadFileStream - fuleName, bufferType,
getFileID, setFileID: setFileName> <CharacterReading>
     WriteFileTextStream <WriteFileStream - fileName, bufferType,
getFileID, setFileID: setFileName> <CharacterWriting>
     ReadWriteFileTextStream <ReadFileStream - fileName, bufferType,
getFileID, setFileID: setFileName> <WriteFileStream - fileName,
bufferType, getFileID, setFileID: setFileName> <ByteWriting>

<FileStream>
   <PositionableStream - isBinary>
<ReadFileStream>
   <GettableStream - close, isBinary, isClosed>
   <FileStream>
<WriteFileStream>
   <PuttableStream - close, isBinary, isClosed>
   <FileStream>

The amount of added complexity is mindboggling to me, and other than
AbstractFileStream being a subclass of Object there doesn't seem to be
*any* advantage of using traits. The disadvantages however, like the
explosion in the number of entities are very real (I think anyone who
has tried to understand the Squeak 3.9 and later meta class hierarchy
will agree).

So ultimately, I agree with your statement. There may be *some* uses for
traits, but those are few and far inbetween (and, realistically
speaking, nobody has found one yet). In the cases that we have seen so
far, traits are simply used as MI with all the same problems that MI
has. Nile certainly shows the symptoms (added complexity, conflicts)
that we've come to recognize as the hallmark of MI systems.

Cheers,
   - Andreas

John M McIntosh wrote:
Hmmm. For some reason, the version with 3.8.18beta specified doesnt'
quite work. A different folder, labled Squeak3.9-final-7067, seemed to
work better, but it may have just be "cleaner" than the other one when I
started testing.

Now that I know that it works (I can even do a few simple shell commands
from the shell window, whee), I have ot figure out how to use it. Are
they any existing examples I might look at for implementing I/O via pipes?

Thanks.

On Sun, Aug 05, 2007 at 07:33:01PM -0700, Lawson English wrote:
Look at the class side methods in PipeableOSProcess. There are a number
of examples there, and many of the methods have examples in the method
comments. A PipeableOSProcess is a proxy for an external OS process that
has its stdin/stdout/stderr pipes connected and accessible from Squeak.

You can also create instances of OSPipe if you want to work with pipes
directly, but pay attention to blocking versus non-blocking pipes, as
you can hang up your Squeak VM by reading a blocking pipe that has no
data available.

Dave

David T. Lewis wrote:
Thanks for the pointers to the examples. Unfortunately, none of them
seem to work. They all return either a message that the Accessor cannot
access the system. I'm no doubt missing something.

On 8/6/07, Andreas Raab <[hidden email]> wrote:P.S.

Just to give something concrete, here is basically what Haskell has for the Eq (equality) type class:

class Eq
  x == y = ! (x != y)
  x != y = ! ( x == y)

So what this is saying is that objects that are of type Eq have the == and != functions.  It also provides default implementations for this, but notice: these implementations are defined from each other.  No, this wont compile.  But what this will do is allow you to just define the function that is easiest and the other definition will be correct then.

So in this case you can't just declare your new type as Eq and everything works (though you can say it derives from it, but that's something different).  You still have to define at least one function and I think most if not all the Type classes behave like this.

On Aug 6, 2007, at 9:28 AM, Lawson English wrote:

>
> Thanks for the pointers to the examples. Unfortunately, none of  
> them seem to work. They all return either a message that the  
> Accessor cannot access the system. I'm no doubt missing something.


You should first confirm your copy of Squeak 3.8.18beta1U.app  
Resources folder contains UnixOSProcessPlugin.bundle
In checking the copy of the on my ftp site does contain that.

If I do

  UnixOSProcessAccessor basicNew primGetSession

I get back magic bits.


Also check   SmalltalkImage current listLoadedModules  which shows  
for me

'UnixOSProcessPlugin 11 October 2006 (e)'

I believe I just loaded OSProcess (4.3) on SqueakMap

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

John M McIntosh wrote: Thanks very much. I just discovred I had an obsolete version of
SqueakMap, so I had to install THAT before I could see other recent updates.