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.
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 4/27/06, stéphane ducasse ducasse@iam.unibe.ch 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...
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 ].
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
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
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
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 and classvar are cool. I like the < :)
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.cs.tcd.ie/Alexandre.Bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 andreas.raab@gmx.de:
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
On 5/17/06, Lord ZealoN lordzealon@gmail.com wrote:
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?
Ruby doesn't either, and it has rake... I use it to build LaTeX documents for instance. I'd like to use smalltalk to automate out-of-smalltalk stuff, and to call smalltalk code from the command line as simply as I can call whatever script.
On 17 mai 06, at 09:13, Andreas Raab wrote:
And yes, VW holds the all-time low in the signal to noise ratio of class definitions ;-)
if you meant that this is a pretty ugly way to define classes with lot of stuff getting in your way. I agree and close my eyes each time I program a class in VW....Hence my bugs :)
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?
To "define" a class nothing is required (you must write "source" code in a piece of paper/aTextFile). If you want to create an object (like a class) you need to DO something, ... e.g. send a message.
Working with OOLanguages, only definition is possible (an required), because execution is not allowed when you are "there"; a computer/machive will do the work later in time (evading object creation if possible :-( ). It is like writing a letter to God, talking about ideal objects...
Working IN smalltalk, computation/production is a side effect of a working environment. When you are in the environment, you must do(evaluate) actions and create classes/species (if it is possible at the moment of evaluation). It is like working in real world.
The "doIt" instead of "defineIt" has important implications in systems development/creation. Is is not a good/bad idea; it is a requirement to send messages. It is possible becasue the receiver is near your fingers and at the same time. Building open systems (instead of closed/ideal systems) let you lower the risks of working declarativelly.
hope this help, Ale.
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?
I believe Stef was talking about:
Package MyNewPackage
vs.
Package declarePackage: #MyNewPackage
Both are plain Smalltalk expressions. But the intention behind the first one is not to send the message MyNewPackage to the object Package.
cheers, Alexandre
On 17 mai 06, at 00:34, 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?
I meant a message that is not defined yet to create a pacakage
Package ColoredPointPackage would not be known when you are defining it. Sorry for the confusion.
Stef
Colin
On May 17, 2006, at 8:19 AM, stéphane ducasse wrote:
I meant a message that is not defined yet to create a pacakage
Package ColoredPointPackage would not be known when you are defining it. Sorry for the confusion.
Oh, I see. Yeah. That's just a bit too clever for my taste as well.
Colin
Le Mardi 16 Mai 2006 17:06, stéphane ducasse a écrit :
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 and classvar are cool. I like the < :)
Note that it's funny that a super-class is not super-ior
Nicolas
On 16 mai 06, at 21:25, nicolas cellier wrote:
Le Mardi 16 Mai 2006 17:06, stéphane ducasse a écrit :
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 and classvar are cool. I like the < :)
Note that it's funny that a super-class is not super-ior
indeed I was thinking about UML <| graphical relationship but may be having > is better :)
Nicolas
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:
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 ^ ]
Rake is using blocks, just with an alternative syntax.
task :target => [:dep1, :dep2] do # do stuff end
On 4/26/06, stéphane ducasse ducasse@iam.unibe.ch 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 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/26/06, stéphane ducasse ducasse@iam.unibe.ch 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
squeak-dev@lists.squeakfoundation.org