These are chat archives for juttle/juttle

Jan 2016
David Majda
Jan 04 2016 13:42
Just to clarify the reduce field referencing behavior discussed above: The currently implemented behavior is no coercion except in identifiers used as reducer arguments, which are coerced to fields. This means:
reduce a = b is an error because b is not defined
reduce a = count(b) is OK because b now refers to a field in reduced points
reduce a = count(b + b) is an error because b does not refer to a field anymore (not a direct reducer argument, merely an expression whose value is used as a reducer argument)
All this is valid only if b is not some other identifier in scope (a const for example), in which case b would refer to it instead.
David Majda
Jan 04 2016 13:48
Now, this is the behavior "as implemented". And I happen to think this needs some adjustment :-)
David Majda
Jan 04 2016 13:57
The reducer argument coercion is an ugly special case, which the implementing code event admits. I think we should get rid of it or un-special-case it somehow but I don't know how yet. Note this is tied to the fact that reducer instantiation and invocation are currently mangled together. (There was some internal discussion about splitting them months ago, but it never lead to anything concrete.)
Another adjustment is that I think reduce a = b should just work with b being a reference to a (possibly missing) field b. This is what put does. I don't know why the two do things differently; the only reason I could think of is that it could be confusing if some field references in the expression (those in reducer args) refer to fields in reduced points while others to fields in the created point.
David Majda
Jan 04 2016 14:27
OK, filed #92 and #93 to capture these issues.
Henri DF
Jan 04 2016 18:55
uh, s/langauge/language/ in the juttle project description
Daria Mehra
Jan 04 2016 18:55
Mark Stemm
Jan 04 2016 21:33
Copying from slack: @dmehra brings up a question in juttle/juttle-gmail-adapter#9. I had assumed that live just meant a -to in the future that may or may not be :forever:, so that’s how i implemented it for the gmail adapter. Do other adapters do it this way as well?
Rodney Lopes Gomes
Jan 04 2016 23:49
very strange failure on master: @demmer any idea on how exactly join would emit an out of order mark ? @bkutil you may also be interested in this one.