'Undefined' Issue with numberLists

Bug Reports
#1

Something’s not working the way it seems like it should.

I’m working on a larger presentation, had a problem, and have cut it down to show the issue.

The length of a number list in a graph object is returning ‘undefined’ but it should have some value at all times.

Here’s the link to the activity:

Explanation:
Running the activity displays the values of the lengths of two number lists. List A is empty [ ] and correctly shows zero. List B is either an aggregate of input values, set when a value has been submitted; otherwise it is set to List A. Instead of showing zero initially the value ‘undefined’ is returned for the length of B. Once a value has been submitted, the length is correctly given as ‘one’.

#2

Thanks for the report!

The numberList sink was built before the calculator supported zero length lists, so you should see undefined there.

That may be something we could look into updating but may not because the change could break existing activities.

We usually set our dummy lists to one element - or match the length, depending on the specific case. Happy to help you find a way to work around this issue with you.

#3

Thanks Jay, I’ve already worked out a way around this, and can avoid it in future now that I know about it. It feels like something that would be useful to highlight in the documentation?

#4

I think I just ran into this issue trying to sink a sketch point list:
numberList(x_{y1}): this.sketch.xValuesAt(1)
In my graph I can deal with x_{y1} having a length of 0 correctly, but how can I deal with it being set to undefined by the CL?

#5

We typically handle undefined list by creating a default list in the graph and setting the numberList to that source when stroke count is 0.

#6

Update!

Empty and undefined lists will now show up in the calculator as empty lists!

#7

Sorry Jay, that’s a bit too cryptic for me! Can you say a bit more? Do you mean ‘now’ rather than ‘not’? …certainly my bug report code is now fine.

#8

Yes, my mistake. It’s been corrected

#9

Many thanks for the change. It feels like the right call. Checking through the presentation that started this, I did find different behaviour but it was because a previously hidden error was now visible!..so no complaints from me!!