gmane.comp.lang.smalltalk.vwnc

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-18T10:53:13

Hi Joerg!


Yes, there is - namely by hand. Let's consider the following example:


It can be written the classic way:


Which creates two intermediate collections. Again, we can avoid them:


But now we have to think in terms of #inject:into and craft the behavior of
#select: and #collect: into the block by hand.
This style is harder to read, especially for more complex conditions and  
mappings.


This idea uses specific block combinators (#&, #||, #,) for the different  
types of enumeration messages. Besides implementing the BlockCollection  
class, you extend BlockClosure with those new messages.
Furthermore, you have to modify each implementor for each of the  
enumeration methods #collect:, select: and so on. This approach does not  
seem to be composable or easy to extend. Moreover, it doesn't give you the  
other benefits I've sketched before. (And it does not simplify the example  
above.)

Did you gave reducers already a try?

Kind regards,
Steffen

Re: Reducers in Smalltalk

Joerg Beekmann, DeepCove Labs — 2013-05-17T18:54:10


There is already a way to compose the blocks used by select:/collect: etc. and avoid intermediate collections. For example in the case of 
test1 = [:i| I odd].
test2 := [:i| (i\\3) = 0].
((0 to: 100) select: test1) select: test2 

Does indeed iterate over the collection twice. But:

(0 to: 100) select: [:i| (test1 value: i) and: [test2 value: i]]

Only iterates over it once with the two tests composed.

If you want nicer syntax you could create a BlockCollection class with ways to compose blocks. For example:
aBlockCollection := (test1 & test2) || test3.

Then modify select: to take a block collection so you can write (1 to: 100) select: aBlockCollection.

Extensions to support block collections for collect could also be written say:
aBlockCollection := map1, map2, map3.
Then (1 to: 100) collect: aBlockCollection would give you the result of feeding the output of each block into the next.

Joerg
-----Original Message-----
From: vwnc-bounces< at >cs.uiuc.edu [mailto:vwnc-bounces< at >cs.uiuc.edu] On Behalf Of Steffen

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-17T17:06:03

Dear Micheal,

I'll try to only indicate some answers, since I am not too familiar with  
Xtreams. I only used parts of it, e.g., the neat PEG package. Please keep  
in mind that Xtreams is an extensive library, whereas Reducers is in an  
early stage and neither complete nor optimized. For example, so far the  
only way to write to a collection/drain is to accumulate with  
#reduce:init:,  e.g.,


* Composition
You already mentioned this.

* Performance
Reducer objects do nothing more than transforming a reducing function  
(block, symbol). The reduction with the transformed function is done by  
the underlying source (~terminal). Thus, apart from the one-time  
transformation, there is no overhead.
This property may give a performance edge over the classical enumeration  
operations and Xtreams. First simple tests look promising to accomplish  
this. However, the tests were not extensive and hardly representative.

* Parallelism
Since most operations, e.g map and filter, do not assume any order or  
repres

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Randy Coulman — 2013-05-15T14:07:07

OK, I understand what you're looking for.  I could think of a couple of
interpretations.

You basically have two options:

1. You can make a complete double of the class like this:

classDouble := DoubleAgent of: MyClass class.
classDouble stub: #myMethod return: 42.
result := suspectObject doStuffWithClass: classDouble.

If this is a common use case, then I should think about adding some kind of
convenience protocol to handle it.

2. You can use an in-place double on the original class like this:

classDouble := MyClass classSideDouble.
classDouble stub: #myMethod return: 42.
result := suspectObject doStuffWithClass: classDouble.


I see the tradeoffs between the two as follows:

 * The complete double will not respond to any other messages than those
you stub or mock; the in-place double will retain its original behavior for
any methods that you don't mention.

* The complete double has to be injected into the object under test; the
in-place double does not.

* The complete double will not impact any other

Re: Reducers in Smalltalk

Michael Lucas-Smith — 2013-05-15T13:17:55

Apart from the composition, what advantage does this give me over Xtreams. Xtreams is not just read, it's also capable of write and it backs up to IO with a streaming API. Some kinds of streams are also positionable, which is another bonus.

Cheers,
Michael

On 15/05/2013, at 10:37 PM, Steffen Märcker <merkste< at >web.de> wrote:

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-15T12:37:14

I've just pushed a new version that improves the API a little bit:

- added Collection>>reducer to support more smalltalkish style:
   ((1 to: 10) reducer filter: #odd) map: #squared
- composition style:
   squares := (Reducer map: #squared).
   odds := (Reducer filter: #odd).
   squared <> odds from: (1 to: 10)

Regards,
Steffen

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Steffen Märcker — 2013-05-15T09:25:19

Say, we have MyClass that defines myMethod on the class side, e.g.


The code to be tested is given that class in some way and uses it, say


Can I stub myMethod with DoubleAgents? Maybe similar to


Regards, Steffen



Am 14.05.2013, 20:11 Uhr, schrieb Randy Coulman <rcoulman< at >gmail.com>:

Re: indexedType: #illegal

2013-05-14T20:48:27

I find that syntax highlighting helps me a lot with these types of errors (assuming you're coloring different variable types differently). Even if you happen to override a variable with a temp variable, it will be highlighted differently.

"Vincent Lesbros"<lesbros< at >gmail.com> wrote:

Re: Reducers in Smalltalk - template clean blocks

Paul Baumann — 2013-05-14T18:34:08

You mentioned CollectionViews. I use generated blocks in that code. When client code asks GS for information then a clean query block is created to gather that information for each item in the collection being enumerated. The block allows context to be passed as arguments into it so that it remains clean while still being able to resolve anything that is needed. The savings is that the context object need only be created once for all the items being enumerated and that the code being performed each time is as efficient as the compiler can create.


Yeah, that would be slow.


Yes, and you've hinted at the solution that can be used when blocks have little to change. You can use a clean block as a template for creating other clean blocks. You copy the clean block and replace an easily recognized literal with the with a different selector to execute. It avoids having to compile a block every time. This kind of tuning varies by Smalltalk dialect (if that is a concern). I've done things like this a couple times.

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Randy Coulman — 2013-05-14T18:11:14

What do you mean by "mocking a class"?  Can you give me an example?

Thanks,
Randy


On Tue, May 14, 2013 at 10:12 AM, Steffen Märcker <merkste< at >web.de> wrote:

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Steffen Märcker — 2013-05-14T17:12:32

Hi Randy,

thanks for the explanation. DoubleAgents appear really interesting to me.  
I think I'll give it a try soon. Maybe for the reducers stuff or while  
reworking the SimpleXO / SimpleXPath tests. The latter uses sMock up to  
now.

Do DAs support mocking a class, too? How would you do that?


Nice.


Mmh, for me sMock works well with only one testing framework loaded. One  
can safely ignore the error message on load. Though, it would be nice to  
load the proper test class automagically, dependent on the loaded  
framework.

Regards, Steffen

Re: Reducers in Smalltalk (errata)

Steffen Märcker — 2013-05-14T17:12:33

Two minor points.

1. Reducer class>>filter:from: should be:

2. You can write short
for

Regards,
Steffen

Re: indexedType: #illegal

Vincent Lesbros — 2013-05-14T17:04:48

Thanks,

In fact, in one of the class method, I set the "format" variable that
I wanted to use as a temporary variable,
(but, with the use of letting the browser declare automatically the
temporary variables, I did not see that the "format" variable was
allredy used).

I'll remember, allways declare manually temporary variables.


2013/5/9 Dennis Smith <dennis< at >cherniaksoftware.com>:

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-14T14:10:08

Dear Paul,

thank you very much for your comprehensive response and the link to  
CollectionViews.


I scented this issue. Probably it's due to three reasons:

1. Uncommon Selectors

Although I find #map:, #filter etc. easy to read, they differ from the  
common language of #collect:, #select and so on. I choose them to indicate  
their slightly different semantics. Namely, the do not produce a new  
collection and work on keyed collections as well. However the selectors  
are not carved in stone; I am open to any ideas.

2. Decoupled Implementation

The protocol is implemented in Reducers and interfaces to collections only  
via #reduce:init:. Thus, we have


instead of


To make Reducers easy to extend, I decided not to extend Collection  
itself. Since, you just have to implement a new transformer class in order  
to support a new reduction operation (e.g. concatenate) on all  
implementors of #reduce:init:. You may add a convenience method to  
Reducer, but that's optional. For example:


How do you feel

Re: Reducers in Smalltalk

Paul Baumann — 2013-05-13T19:52:56

I've done a lot of work with optimizing enumerations. I've done every kind of optimization that you hope to grow Reducers into. I find "Reducers" to be difficult to read so I'm likely missing some of what makes Reducers great. I'm going try to explain Reducers in my own words and let you reply with how it really works. My goal is to show you a few opportunities that you might not have thought of yet.

I see the "Reducer" examples you've given as somewhat similar to an Enumeration pattern as you might read from the GOF "Design Patterns" book. The Reducer is a model that controls how an enumeration is to proceed from where it currently is. It is a more sophisticated form of a Stream enumerating a collection of objects.  A Stream has a position and rules for repositioning within a collection. A Stream also has a different protocol than a collection does, and is an interactive enumerator that does not need to create a results collection. The Reducer appears to be more like a Promise of results that are queried f

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-13T10:57:39

I put some typos in the naturals reduction. Better is:

Naturals>>reduce: function init: x
    | result n |
    result := x.
    n := -1.
    [n := n+1.
    result := function value: result value: n.] repeat

Am 13.05.2013, 12:01 Uhr, schrieb Steffen Märcker <merkste< at >web.de>:

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-13T10:01:06

Thanks for your response.


They're fine, just different. But obviously I didn't make the points  
clear. A second attempt with five advantages.

1) No intermediate collections
Consider the example of chained collection operations:


The calls of #select: and #collect: create two intermediate collections.  
This wastes memory, since they are discarded immediately. In contrast:


The reducers wrap collections (reducibles). They do not create a new  
collection but transform the reducing block (symbol) when #reduce:init: is  
called. Eventually, the source collection is asked to reduce itself with  
the transformed block in just one step. Thus, no intermediate collections  
are generated.

2) Laziness enables handling of infinite collections
Consider some infinite collecition, e.g., the natural numbers. Assume an  
implementation similar to:


With reducers you can operate on the first five numbers:


operate on all but the first 5 numbers:


or multiply the first five squared prime numbers:


3) Curried and c

Re: Reducers in Smalltalk

Michael Lucas-Smith — 2013-05-13T08:43:54

Karsten has a point - and if you need to lazily apply filters over a potentially very large virtual collection, there is also Xtreams:

streamingReducer := (((1 to: 10**6) reading selecting: #odd) collecting: #squared) injecting: 0 into: [:sum :each | sum + each].
result := streamingReducer rest.

Cheers,
Michael

On 13/05/2013, at 6:17 PM, Karsten Kusche <karsten< at >heeg.de> wrote:


_______________________________________________
vwnc mailing list
vwnc< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Re: Reducers in Smalltalk

Karsten Kusche — 2013-05-13T08:17:48

just out of curiosity: what's so bad about select and inject?


why not just say  

((1 to: 10**6) select:#odd) inject: 0 into: [:sum :each | sum + each].



here it's like:

((col select:#odd) collect:#squared) inject: 0 into:[:sum :each | sum + each].

Maybe i'm missing something here, but the Collection class already implements most of the Reducer stuff.

Kind Regards
Karsten

Re: ScrollWrapper>>setOrigin: inappropriately sends "self repairDamages"

2013-05-10T11:32:04

Well If I make this change I find myself with an empty plugable adapter and a black screen ?
 
< at >+Maarten,
 



I can also confirm that removing the       call to repairDamages resolved a problem in our app.

 With the invocation of repairDamages, the layout of the       subcanvases was messed up. The widgets were painted twice over       each other with two different layouts for two different window       extents. This effect was new after our port from 7.6 to 7.9.1.

 As soon as we changed the setOrigin: method in ScrollWrapper as       Terry proposed, the layout was fine again.

 Is there an AR for 7.10 for this issue?

 Thomas


 Am 08.03.2013 20:49, schrieb Terry Raymond:

It appears that in VW 7.9 #setOrigin: was           modified to send “self repairDamages”.
Well, under some situations when you           maximize the window it is not properly displayed.
 
Also, repair damages occurs immediately.           Generally speaking, this is not a good way
to update the display. An event that causes

Re: ScrollWrapper>>setOrigin: inappropriately sends "self repairDamages"

Thomas Brodt — 2013-05-10T09:16:15

I can also confirm that removing the call to repairDamages resolved a 
problem in our app.

With the invocation of repairDamages, the layout of the subcanvases was 
messed up. The widgets were painted twice over each other with two 
different layouts for two different window extents. This effect was new 
after our port from 7.6 to 7.9.1.

As soon as we changed the setOrigin: method in ScrollWrapper as Terry 
proposed, the layout was fine again.

Is there an AR for 7.10 for this issue?

Thomas


Am 08.03.2013 20:49, schrieb Terry Raymond:

_______________________________________________
vwnc mailing list
vwnc< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc