[Jonathan Sandoe]

Hi Jason and Thomas,

I am able to reproduce. Thanks for the additional condition. I will log this as a bug. I also noticed that deleting the last attribute did not remove its collection, which must also be a recent regression.

Thanks for reporting,

Jonathan

[Jonathan Sandoe]

Hello Thomas,

I know this doesn’t sound credible, in the several years that the boundary values have been present in CODAP it never occurred to me to try using a boundary variable outside the boundary lookup context. I am a bit surprised it didn’t break more things. Clearly this is a problem. I will file a bug.

Thank you for reporting this issue, Thomas.

Jonathan

[Jonathan Sandoe]

Hi Thomas,

This is a quirk from our history that I thought had been fixed. (In an earlier iteration of CODAP, all plugins were games. There was an assumption that each plugin contributed exactly on dataset. The earlier version of the API provided no visibility into CODAP state, so the dataset was frozen as long as the plugin existed.) It is a bug. I will log it.

Thank you for reporting this issue.

Jonathan

[Jonathan Sandoe]

Hello Thomas,

What an interesting question! The short answer is that expressions are evaluated as Javascript expressions and this is the behavior in Javascript. Here is a snippet I copied from a node session that confirms this:

> var missing = “”;
undefined
> [missing && false, false && missing, true || missing, missing || true];
[ ”, false, true, true ]

This is consistent with your explanation, just putting it another way.

You have probably also discovered that there are other places where the commutative property of ‘and’ and ‘or’ is not observed:

Although this behavior is consistent with expressions in the Javascript language, it is not consistent with boolean logic and likely to be confusing to students. I will file a bug. The delegation of CODAP’s expression language to Javascript is pretty fundamental to CODAP’s formula engine, so it may take a while to explore the implications elsewhere in CODAP.

Jonathan

[Jonathan Sandoe]

Hi Jason,

I investigated a little farther and I found that, weirdly, creating a Text Component doesn’t work for plain text, but update does. For example, the following message:

{ “action”: “update”, “resource”: “component[name]”, “values”: { “text”: “This is some text” } }

I will log a bug about create/textComponent, but you can create, then immediately update as a workaround.

Jonathan

[Jonathan Sandoe]

Hi Andee, there is currently no month date type, unfortunately. The approach you are using is the best practice currently available. We do understand it is less than ideal.

Jonathan

[Jonathan Sandoe]

Hi Thomas,

The description property in the DataContext can be considered to be decremented. The metadata property includes, as you note, a description property, which is visible in the “info” menu in the Case Table. You can retrieve the metadata through the API. You can create a metadata object when you create a data context through the API. You cannot at this time update it through the API.

Jonathan

[Jonathan Sandoe]

Hi Jason,

Thanks for the bug report and the thorough analysis. I will log the report and we will fix as soon as possible.

Jonathan

[Jonathan Sandoe]

Hi Thomas,

I agree that this is a bug. Thank you for reporting it. I have logged it here: https://www.pivotaltracker.com/story/show/178273084. Your analysis of the problem looks pretty good, too. I hope we will be able to rectify it soon.

Jonathan

[Jonathan Sandoe]

Hi Shriram,

I am not sure I understand your question. The CODAP Plugin Menu lists standard plugins. It doesn’t change as you add new plugins to the CODAP workspace. You may be thinking of the “Tiles” menu on the right-hand side of the CODAP navigation bar. It includes an entry for each component in the CODAP workspace. (Components, in CODAP, are any container elements in the workspace excluding Inspectors and other transient dialogs. They usually have green titlebars on the top.) This menu would get a little confusing if a plugin added several other related components. There is currently no facility for a multilevel “Tiles” menu. That’s not to say there couldn’t be one in the future should the need arise.

Jonathan

[Jonathan Sandoe]

I agree this is a bug.

I have logged the bug. You can follow its progress here: https://www.pivotaltracker.com/story/show/178132550

In the mean time, if I understand what you are trying to do, a simple remedy is to copy the formula when you create the replicated attribute. This will regenerate the values in the new dataset.

[Jonathan Sandoe]

It’s difficult to say what may be going on. The link works for me, also on Chrome. The screenshot is helpful, but I am interested in what may be a little outside this view. In particular, there is a green bar at the top of the CODAP page. Do you know if it had anything in it, or was it a blank green bar? It normally looks something like this:

[Jonathan Sandoe]

The ability to hand-draw regions on a CODAP map would be a nice feature indeed, but, alas, is not supported.

Jonathan

[Jonathan Sandoe]

There is another way to do this, if your browser is Chrome.

1. select the region you want to transfer in Excel.
2. copy is (ctrl-c)
3. in CODAP, create a new dataset: click on the Tables icon and select ‘—new—‘.
4. Select the new table. There will be an Inspector menu on the right. Click on the ruler button and select “Import Case Data from the Clipboard”
5. A dialog will come up asking whether you want to replace or append to the existing dataset. Click on “replace”

Repeat for each table range you want to transfer to CODAP.

Jonathan

[Jonathan Sandoe]

Yes! Its in the “ruler” menu that shows up to the right of the case table when its selected. Click on “Export case data…” and pick “All Tables”. This will make a CSV.

Jonathan

 

 

[Author]

Posts