Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pcollect behaves incorrectly with event as input #1047

Closed
telephon opened this issue Mar 4, 2014 · 2 comments
Closed

Pcollect behaves incorrectly with event as input #1047

telephon opened this issue Mar 4, 2014 · 2 comments
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: class library SC class library

Comments

@telephon
Copy link
Member

telephon commented Mar 4, 2014

a = Pcollect({ |event| (aa:9) }, (zz: 4));
x = a.asStream;
x.next(());

Returns:

( 'zz': ( 'aa': 9 ) )

The following throws an error:


a = Pcollect({ |event| event.put(\test, -100) }, (zz: 4));
x = a.asStream;
x.next(());

ERROR: Message 'put' not understood.
RECEIVER:
   Integer 4
ARGS:
   Symbol 'test'
   Integer -100
PATH: /Volumes/data/sc/(this)/devel/devel jitlib/dynamic node proxy/pdef tests.scd
CALL STACK:
    DoesNotUnderstandError:reportError   0x1179a3698
        arg this = <instance of DoesNotUnderstandError>
    Nil:handleError   0x1179a37f8
        arg this = nil
        arg error = <instance of DoesNotUnderstandError>
    Thread:handleError   0x1179a3958
        arg this = <instance of Thread>
        arg error = <instance of DoesNotUnderstandError>
    Object:throw   0x1179a3a08
        arg this = <instance of DoesNotUnderstandError>
    Object:doesNotUnderstand   0x1179a4038
        arg this = 4
        arg selector = 'put'
        arg args = [*2]
    < FunctionDef in Method Dictionary:collect >   0x1179a40e8
        arg key = 'zz'
        arg elem = 4
    Dictionary:keysValuesArrayDo   0x11f2af9b8
        arg this = <instance of Event>
        arg argArray = [*4]
        arg function = <instance of Function>
        var i = 0
        var j = 1
        var key = nil
        var val = nil
        var arraySize = nil
    Dictionary:keysValuesDo   0x1179a4198
        arg this = <instance of Event>
        arg function = <instance of Function>
    Dictionary:collect   0x1179a45b8
        arg this = <instance of Event>
        arg function = <instance of Function>
        var res = <instance of Event>
    < closed FunctionDef >  (no arguments or variables)
    Interpreter:interpretPrintCmdLine   0x11f2af628
        arg this = <instance of Interpreter>
        var res = nil
        var func = <instance of Function>
        var code = "x = a.asStream;"
        var doc = nil
        var ideClass = <instance of Meta_ScIDE>
    Process:interpretPrintCmdLine   0x1179a4d48
        arg this = <instance of Main>
^^ The preceding error dump is for ERROR: Message 'put' not understood.
RECEIVER: 4

@jamshark70
Copy link
Contributor

I see what the problem is. Pcollect's asStream implementation assumes that pattern.asStream will return an instance of Stream or a subclass -- so the subsequent collect would invoke Stream's implementation. But most collections respond to asStream with themselves, and then collect operates on the collection and not (as you expected) on a stream that yields the collection.

Pselect and Preject will have the same problem.

I'm tempted to call it a documentation issue: use collect, select, reject on the pattern and don't use Pcollect directly. Why? A code change to address this would have to depend on polymorphism, but collect is already polymorphic. An extra layer of polymorphism may be redundant.

Or it could be useful, to avoid this "gotcha." If so, we might move asPattern from my quarks into core.

@telephon
Copy link
Member Author

telephon commented Mar 5, 2014

Ah yes, now I see, the problem appears in asStream

asStream {
        ^pattern.asStream.collect(func);
    }

Moving to .collect wouldn't help: you don't want to have polymorphism here. A collection here is an element of a stream, not something to iterate over.

I don't think it is a documentation issue: Events (or other Objects) as pattern inputs should be equivalent to patterns that return events (or other Objects).

Maybe the best fix would be to remove the `asStreamimplementation and rely onembedInStream``.

Btw. there is no processRest in the `asStream`` implementation, I don't know if it would be necessary?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: class library SC class library
Projects
None yet
Development

No branches or pull requests

2 participants