Sake = Rake for Smalltalk?

hi all

I wanted to know if one of you was working on something similar than  
rake in ruby: a makefile/ant like
framework. Using blocks :) so it seems better.

Stef

At Mercap we has been working on a "Batch Model". Our first intention
was making "scripts" to do continuous integration. (using VAST)

After a while, that was totally unnecessary (and uncomfortable too).

Yes, you could automate all the process of packaging, but is not
necessary to do a framework like makefiles for that, just modeling
some objects of the SCM domain... that in Squeak for example, are
missing: like modules, etc :P.

Anyway I think that would be nice to make something to run St scripts
from the command line... just to attract users from Python/Perl/(put
your classic text file scripting language here) to Squeak.

Cheers,
Diego F.

Rake is using blocks, just with an alternative syntax.

task :target => [:dep1, :dep2] do
    # do stuff
end

On 4/26/06, stéphane ducasse <[hidden email]> wrote:
> hi all
>
> I wanted to know if one of you was working on something similar than
> rake in ruby: a makefile/ant like
> framework. Using blocks :) so it seems better.
>
> Stef
>
>

On 26 avr. 06, at 22:54, Diego Fernandez wrote:

> At Mercap we has been working on a "Batch Model". Our first intention
> was making "scripts" to do continuous integration. (using VAST)
>
> After a while, that was totally unnecessary (and uncomfortable too).
>
> Yes, you could automate all the process of packaging, but is not
> necessary to do a framework like makefiles for that, just modeling
> some objects of the SCM domain... that in Squeak for example, are
> missing: like modules, etc :P.

:)
But we have MC and MC2 coming.

> Anyway I think that would be nice to make something to run St scripts
> from the command line... just to attract users from Python/Perl/(put
> your classic text file scripting language here) to Squeak.

exactly and also me when I have to write some script shells, and I  
would prefer to write
some sqrit-shell :)

KernelPackage
        import: Point.

Package declare: 'ColoredPointPackage'.

Point < ColoredPpoint
        variables: 'x y' ;
        classvar: 'Foo'
       
ColoredPoint>>foo: zork
        <category: 'foobar'>
        <author: 'sd' date: '24/06/2006'>
         [ ljkljl
                ^
          ]





>
> Cheers,
> Diego F.
>
>

On 27 avr. 06, at 05:47, Wilkes Joiner wrote:

> Rake is using blocks, just with an alternative syntax.
>
> task :target => [:dep1, :dep2] do
>     # do stuff
> end

I know this is why I ask if someone was working on a squeak version :)

On 4/27/06, stéphane ducasse <[hidden email]> wrote:
> > Anyway I think that would be nice to make something to run St scripts
> > from the command line... just to attract users from Python/Perl/(put
> > your classic text file scripting language here) to Squeak.
>
> exactly and also me when I have to write some script shells, and I
> would prefer to write
> some sqrit-shell :)

> ColoredPoint>>foo: zork
>         <category: 'foobar'>
>         <author: 'sd' date: '24/06/2006'>

I'd like to unify method bodies and blocks:

ColoredPoint >> [ foo:aFoo bar:aBar |
    self doStuff.
]

This way, >> is really a message with a block argument, and one could do:

aBlock := [ foo:aFoo bar:aBar | self blah ].
aBlock foo:42 bar:51.
Maybe #foo:bar: should just be an alias for #value:value in this
precise instance of Block, instead of defining a new method in Block.

The current syntax ("anonymous" blocks) could still be allowed as
syntactic shortcut:
aBlock := [ :x :y | self blah ].
being synonymous for:
aBlock := [ value:x value:y | self blah ].


Also, what should self be in the context of a script ?  In a (VW)
workspace it's an undefined object...

--
 Damien Pollet
 type less, do more

> KernelPackage
> import: Point.
>
> Package declare: 'ColoredPointPackage'.

Why not instead:
Package ColoredPointPackage; import: Point from: #System

It is plain Smalltalk, and is less verbose.


> Point < ColoredPpoint
> variables: 'x y' ;
> classvar: 'Foo'

I would prefer:
Point subclass: #ColoredPoint
   var: 'x y'; classvar: 'Foo'.

var/classvar is more homogeneous than variables/classvar

>
> ColoredPoint>>foo: zork
> <category: 'foobar'>
> <author: 'sd' date: '24/06/2006'>
>         [ ljkljl
> ^
>         ]

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Few months ago, I worked on a scripting languages, here is a snippet:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
package Kernel

rootclass Obj;

Obj { yourself ^ self }
Obj { ==  other <primitive: 110> }
Obj { ~~  other ^ (self == other) ifTrue: [false] ifTrue:[true] }
Obj {  =  other ^ self == other }
Obj { ~=  other ^ (self = other) == false}

Obj {isNil ^ false}
Obj {isNotNil ^ true}
Obj {isBoolean ^false}
Obj {isCollection ^false}
Obj {isClass ^false}
Obj {isSymbol ^false}
Obj {isInteger ^false}
Obj {perform: aSymbol <primitive: 83>}

Obj class {new ^ self basicNew}
Obj class {basicNew <primitive: 70>}
Obj class {isClass ^true}

class Boolean extends Obj;
Boolean {isBoolean ^ true}

class False extends Boolean;
False { ifTrue: block ^ self }
False { ifFalse: block ^ block value }
False { ifTrue: trueBlock ifFalse: falseBlock  ^ falseBlock value }
False { ifFalse: falseBlock ifTrue: trueBlock  ^ falseBlock value }
False { enot  ^ True new }
False { eor: other ^ other value}
False { eand: other ^ False new}

class True extends Boolean;
True { eifTrue: block  ^ block value }
True { eifFalse: block ^ self }
True { enot ^ False new }
True { eor: other ^ True new }
True { eand: other ^ other value }

end
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Any comments are welcomed

Cheers,
Alexandre


Am Apr 27, 2006 um 8:37 AM schrieb stéphane ducasse:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 16 mai 06, at 00:34, Alexandre Bergel wrote:

>
>> KernelPackage
>> import: Point.
>>
>> Package declare: 'ColoredPointPackage'.
>
> Why not instead:
> Package ColoredPointPackage; import: Point from: #System

because I tried to be as close as possible to the message passing syntax

Var and classvar are cool.
I like the <  :)

>> Why not instead:
>> Package ColoredPointPackage; import: Point from: #System
>
> because I tried to be as close as possible to the message passing  
> syntax

Yes, I know, but
Package ColoredPointPackage; import: Point from: #System

is fully Smalltalk compliant.
ColoredPointPackage is in that case a message sent to the object  
Package.

There was a similar trick used in Squeak 3.3.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Le Mardi 16 Mai 2006 17:06, stéphane ducasse a écrit :
Note that it's funny that a super-class is not super-ior

Nicolas

Quite neat! even if I dislike the |

> Also, what should self be in the context of a script ?  In a (VW)
> workspace it's an undefined object...

Nothing

Le Mardi 16 Mai 2006 21:35, stéphane ducasse a écrit :
> > The current syntax ("anonymous" blocks) could still be allowed as
> > syntactic shortcut:
> > aBlock := [ :x :y | self blah ].
> > being synonymous for:
> > aBlock := [ value:x value:y | self blah ].
>
> Quite neat! even if I dislike the |

Nice to make things explicit.
But a clever mind might think of writing

    aBlock := [x: xInteger y: yInteger  xInteger blah: yInteger ].

and believe he/she can evaluate with:

    aBlock x: 1 y: 0.

Nicolas

>
> Yes, I know, but
> Package ColoredPointPackage; import: Point from: #System
>
> is fully Smalltalk compliant.
> ColoredPointPackage is in that case a message sent to the object  
> Package.
>
> There was a similar trick used in Squeak 3.3.

Yes I know I thought about it too but I never liked the idea that  
sending a message would create
a method or a class. May be I'm too old fashioned :)

Stef

On 16 mai 06, at 21:25, nicolas cellier wrote:

indeed I was thinking about UML <| graphical relationship
but may be having > is better :)

>
> Nicolas
>
>
>

>
>     aBlock := [x: xInteger y: yInteger  xInteger blah: yInteger ].
>
> and believe he/she can evaluate with:
>
>     aBlock x: 1 y: 0.

yes indeed so this is why I prefered

Point>>foo: arg
        [

        ]

because it was also more looking
        {
       
        }
oriented :)

stef

On May 16, 2006, at 4:38 PM, stéphane ducasse wrote:

> Yes I know I thought about it too but I never liked the idea that  
> sending a message would create
> a method or a class. May be I'm too old fashioned :)

Is there another way to do it?

Colin

Colin Putney wrote:

>
> On May 16, 2006, at 4:38 PM, stéphane ducasse wrote:
>
>> Yes I know I thought about it too but I never liked the idea that  
>> sending a message would create
>> a method or a class. May be I'm too old fashioned :)
>
>
> Is there another way to do it?

Of course not - under the hood everything in Smalltalk is done by
sending messages to objects.
IMO the question is whether the source code snippet for defining a class
should have the syntactic form of a message send, or something else.
Personally, I like it as it is, but we already have a discrepancy in the
browser (and in file-outs):
When we define methods, we don't write
SomeClass compile: 'method source' classified: 'protocol'
because that would be pretty clumsy.

Now for class definitions, I don't see how all the alternative
approaches of defining classes give a real advantage over the
traditional message send expression.
VisualWorks introduced a new set of selectors to accomodate namespaces,
but it's still a valid expression.

Cheers,
Hans-Martin

Hans-Martin Mosner wrote:
> When we define methods, we don't write
> SomeClass compile: 'method source' classified: 'protocol'
> because that would be pretty clumsy.
>
> Now for class definitions, I don't see how all the alternative
> approaches of defining classes give a real advantage over the
> traditional message send expression.

Isn't there a certain contradiction between "pretty clumsy" on the one
hand and "no real advantage" on the other? If you need to understand
some code, being non-clumsy is a real advantage to me and having less
clumsy class definitions would certainly help in understanding code
faster and better. And yes, VW holds the all-time low in the signal to
noise ratio of class definitions ;-)

Cheers,
   - Andreas

I haven't read all the mails but, why we would need something like a
makefile?. I think squeak don't need it. Squeak don't have a
edit-compile cycle, True?

2006/5/17, Andreas Raab <[hidden email]>:

--

::Mi blog::
http://blog.lordzealon.com