Squeak-dev August 2007

squeak-dev@lists.squeakfoundation.org

132 participants
163 discussions

Re: pipe
by David Mitchell 27 Aug '07

27 Aug '07

I like the :> and the double semi (and I also like Bert's asPipe). On 8/26/07, Alan Lovejoy <squeak-dev.sourcery(a)forum-mail.net> wrote: > So far, the three pipe operators I like best are "_|", "::" and ":>". I > would prefer to use a leading character for the operator's token that > can't be the beginning of a valid message. Either "_" or ":" satisfy > that constraint quite nicely. > > | oneWeekAgo | > oneWeekAgo := Timepoint today - 7 days. > db getBlogPosts > :: filter: [ :blogPost | blogPost date < oneWeekAgo] > :: filter: [ :blogPost | db coolPosts includes: item )] > :: collectMails > :: do: [ :mail | "Happy to announce ..."] > > | oneWeekAgo | > oneWeekAgo := Timepoint today - 7 days. > db getBlogPosts > :> filter: [ :blogPost | blogPost date < oneWeekAgo] > :> filter: [ :blogPost | db coolPosts includes: item )] > :> collectMails > :> do: [ :mail | "Happy to announce ..."] > > | oneWeekAgo | > oneWeekAgo := Timepoint today - 7 days. > db getBlogPosts > _| filter: [ :blogPost | blogPost date < oneWeekAgo] > _| filter: [ :blogPost | db coolPosts includes: item )] > _| collectMails > _| do: [ :mail | "Happy to announce ..."] > > >

6 5

Re: calling for side-effects was: [Re: pipe]
by Igor Stasenko 27 Aug '07

27 Aug '07

On 27/08/07, Fabio Filasieno <fabio.filasieno(a)gmail.com> wrote: > > > On Aug 27, 2007, at 1:29 AM, Igor Stasenko wrote: > > Cascade is useful. It allows me to write code like that: > ogl > glTexParameteri: GLTexture2d with: GLTextureMinFilter > with: GLLinear; > glTexParameteri: GLTexture2d with: GLTextureMagFilter with: GLLinear; > glTexParameteri: GLTexture2d with: GLTextureWrapS with: GLClamp; > glTexParameteri: GLTexture2d with: GLTextureWrapT with: GLClamp; > glPixelMapfv: GLPixelMapIToA with: 2 with: (FloatArray with: 0.0 with: > 1.0). > > But at the same time it stinks because you don't using the evaluation > result of previously sent message, you simply drop it. And from this > point i feel that something wrong with such design. Why computer needs > to waste cycles to evaluate result of message when its simply not used > at the end? > > For side effects ! :-) Well, i thought that i'm putting my considerations not for reading obvious things in answer. > > In contrast , a pipe does not drops evaluation result, but reuses it > in expression that follows. From this point i like it more than > cascade. > > Same with period '.' > Each time you placing a period in code, you telling compiler to drop > the evaluated result of your expression. > Can it be considered as good from computational point of view? Of > course its not. You forcing a computer to waste the cycles just for > nothing. > > > Same here for side effects. > Same as above. > > Same with implicit return self from a method. I see a good reasons why > i don't want return anything from a method, because it returns nothing > useful or meaningful, and never used for continue evaluation in other > expressions. > > And i think that maybe from computational point of view, it might be > useful to indicate if we need to return result from a method or don't. > So, all messages which chained in cascade expressions can be sent with > flag 'drop result=true' and same for messages which is the last before > period '.'. In other words we can have two forms of 'send' operation > (bytecode): Send with return and send without return. > I think this can save us from wasting a processor cycles just for nothing. > I know that such semantics belongs mainly to compiler, not language > itself, but i just want to point out, how language design influences > the implementation, and how good or bad it can turn out at the end. > > > > This is a very old question on purity and side-effect that seems to have > reached a certain kind of agreement with Monads. > Lots of papers treat this issue. Some suggested Effects Typing, some > Continuations, then the Haskell guys figured > out that with type classes they could create a polymorphic monadic bind and > did the trick. > > But I think that what you say doesn't apply to Smalltalk because it's > dynamically typed. > How would you know at compile time if a method does side-effects .... > What if a method called in a cascade does side effects , but the cascade > itself seems pure ? > Maybe, if you read more carefully, you'll find that i propose how to deal with that without loss of any language features. > I think it's complex stuff... > > Haskell does the "markings" (excuse the name) you talk about with monads > and anything "not marked" doesn't do any sideffects, it's pure. > By adding graph manipulation (reducing & updating) at runtime they evaluate > functions "by name" > and than by updating the runtime graph they avoid re-computation. > > In haskell basically every expression is in a [ ... ] (well sort of they use > graph manipulation) > And it's sent the message value only if needed. And when the the value it's > returned the block gets > removed and it's updated with the value... so no more need to evaluate it, > if you need it again. > It's a powerful optimization ! Too bad that to get that you need to but > Everything in a [ ... ] > (strictness analysis fixes that a bit). > > But the price to pay is high in my opinion ... > functional becomes beautiful, but imperative stuff is a bit too hard ( not > syntactically because of the 1 ton of syntax sugar) > > > -- Best regards, Igor Stasenko AKA sig.

1 0

Re: pipe
by Jason Johnson 27 Aug '07

27 Aug '07

Why not the $ operator? ! looks funny in the places it would be used but $ has a president already. The only issue would be that Haskell programmers might get confused when they see it. In Haskell the application is right to left, in Smalltalk it is left to right. But not a big problem I would say. On 8/25/07, Alan Lovejoy <squeak-dev.sourcery(a)forum-mail.net> wrote: > Since the selector #'|' is already taken for other purposes, why not use > #'!' instead (exclamation point instead of the bar)? > > >

3 3

First post here ... few days on Squeak ... some questions ....
by Fabio Filasieno 27 Aug '07

27 Aug '07

II'm new at Smalltalk and I have a few questions. """Why smalltalk has no operator for piping ?"""" obj collect: [ :x | …] | filter: [:x | …] | select: [:x | …] ? but has the `;` (cascade operator)? I don’t care to send messages to the reciever of the previous message, because I return self when no return value is important; for instance …. point x: 10 | y: 20 | z: 30 x returns self, y returns self, z returns self -> which is the updated point. works exactly as: point x:10; y:20 ; z:30. But you lose PIPES !!!!! Can somebody elaborate on this ? There might be cases where I'm returning a value and I wish to discard it and then send again to the previous receiver ... but I really don't like to loose the pipe for that ... since I can do that returning self. With Smalltalk ... we've got a homoiconic language and the system written in it self, a consistent language in everything, even the if- then-else that everybody else still don't get right; we've got the most wonderful programming experience of all, even better that Ruby/ Python etc ... but why on earth we have the "cascade operator" instead of the PIPE ????? What I'm I missing ? I need the `|` to avoid parenthesis, and weird hacks ... Fabio

10 25

XDR for Squeak
by Elod Kironsky 27 Aug '07

27 Aug '07

Hi! I wonder if there is any package in Squeak that would en/de-code standard C types to a byte-array, as the RFC 1014 - XDR: eXtrenal Data Representation standard does. I'm currently working on a client program to Player/Stage and it would save me a lot of work, as the communication is done via TCP packages. I know ByteArray can do byte, short, long and even double, but is it XDR compatible? Also, is there an equivalent of the C function gettimeofday(), that would return me a double, or something, that I can put into a ByteArray with doubleAt:put:bigEndian:? Cheers, Elod

2 2

pipe operator
by Ralph Boland 27 Aug '07

27 Aug '07

I like the idea of a pipe operator just like I like the ';' operator. They are both (and independently) useful. However, I object to using the '|' symbol for this. (How about using '::' or ':-:' instead?) I think the '|' operator should be used to plug output streams into input streams just as it is used between processes in linux shells. To use such an operator we first we need objects that (in the most general case) read data from an input stream, process the stream, and then output the result to an output stream. Let b1, b2, b3 be three such objects, 'in' be an input stream, and 'out' be an output stream. Then we could write: b1 < in; > out. to have b1 read its input from 'in' and put its result into 'out'. Note that 'b1 < in' cannot generate any output since b1 does not yet know where to send it. After the '; > out.' b1 can process its input and put its output into 'out'. Now we can write: b1 < in; | b2 | b3 > out. which has b1 read its input from 'in', process its input, and send its output to b2, b2 process its input (the output of b1) and send its output to b3, and b3 process its input (the output of b2) and put its output into 'out'. To have this work well there would need to be objects called pipes that do most of the data moving between b1, b2, b3. Thus the method '|' would look something like: | b pipe := Pipe output: b. self > pipe. Perhaps things would not work exactly as I have described but you get the idea. Suggestions as to better syntax welcome. Notes: 1) No change to Squeak or any other version of Smalltalk is needed. (unless we want cleaner syntax); we only need to implement this feature. Anybody want to write a pipes package? Given how useful pipes are in linux shells, it surprises me that a pipes package hasn't been written before. 2) Some collection classes could be made to act like streams with regard to pipes; we just need to implement the necessary methods. 3) Class Pipe could have subclasses each of which would have different internal implementations for efficiency reasons. Ralph Boland

1 0

Re: pipe
by Benoit St-Jean 27 Aug '07

27 Aug '07

Oh Vassili! Simple, effective and elegant as usual... Have an ice-cold beer! :) ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ----- Original Message ---- From: Vassili Bykov <smalltalkbigot(a)gmail.com> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Sent: Sunday, August 26, 2007 8:35:07 PM Subject: Re: pipe Looking back at the number of messages in this thread, I figured I'd contribute a straw man implementation instead of adding to the polemics. The operator used for piping is :>, i.e. (1 to: 10) select: [:x | x odd] :> collect: [:x | x factorial] which doesn't conflict with any syntactically valid messages, is reasonably suggestive and easy to type as both characters are shifted and are close to each other. Most importantly, it looks like a smiley thus improving user-friendliness. Of course, it's quite easy to change the Scanner to recognize pretty much anything else as the #pipe token. Cheers, --Vassili

1 0

Towards multi-head/multi-window VM
by Igor Stasenko 26 Aug '07

26 Aug '07

Hello all, I'm curious, is there any efforts towards making squeak VM be independant from single main window and be able to start with no/single/multiple desktops? I know, that this will require of rethinking a current I/O model which used by morphic (like using single global Display) and using single synchronized event pipeline. Also, i would like to know, is this generally good idea to detach responsibility of supporting any display surfaces from core VM functionality and to pass it under control of code written in image. -- Best regards, Igor Stasenko AKA sig.

7 9

pipe
by leves＠elte.hu 26 Aug '07

26 Aug '07

> Fabio's proposal: > > make the ";" cascade operator send the message not the the previous > receiver but to the object returned by the previous message send. This would break most code with cascades, like: o add: 1; add: 2; yourself. Pipes might be useful in some cases, so one can add the following message to Object: pipe: aBlock | catcher pipedObject | catcher := MessageCatcher new privAccumulator: OrderedCollection new. aBlock value: catcher. pipedObject := self. catcher privAccumulator do: [ :each | pipedObject := each sendTo: pipedObject ]. ^pipedObject Then simply use ; as a pipe like: 1 pipe: [ :mock | mock + 3; - 2; asFloat; * 2; asString; , ' foo'; , ' or bar'; first: 10 ]

4 3

Smagick for win32
by Levente Uzonyi 26 Aug '07

26 Aug '07

Hi! I've created a monticello package which makes it possible to use Smagick under win32. It fixes a few bugs and uses ProcessWrapper for external process execution instead of OSProcess. How to install it: 1. Install ImageMagick (I have ImageMagick-6.3.5-Q8 and ImageMagick-6.3.5-Q16) 2. Install Smagick-SR.33 3. Install latest ProcessWrapper-Core from http://squeaksource.com/ProcessWrapper.html When you're asked if you want to download the missing plugin, say yes. 4. Install latest VB-Regex from http://www.squeaksource.com/Regex.html (geometry tests will fail without it) 5. Install Smagick-Win32 (attached to this mail) During the installation a folder selector will show up. Select the folder which contains your ImageMagick installation. 6. Open TestRunner and run the Smagick-Tests. SmagickTest >> #testEnhancedEnvironment should fail with ImageMagick-6.3.5, because of missing filetype support. SmagickImagingTest >> #testLogoDrawing probably has a bug, because it tries to send #draw: to a SmagickConvert object which doesn't implement #file, which is used by #draw:, so this should fail too. All other tests should pass. Cheers, Levente

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
17
Older →

Jump to page: