implement calculations



For various cardtypes:

  • basic arithmetic (for starters) on numbers
  • word count


  • Random - returns one card at random from given set (Search or Pointer)

Calculations should be able to use _self to refer to the card the calculation is included on.




Specific use cases:

  • summing water data for each ainability site from its plots



  1. For now the calculations are done with Ruby cards.  Something similar could be done for other languages.
  2. Most ruby cards will be structure cards created by developers, like sum+*right+*content.  So you can do something like "list of numbers+sum" where list of numbers is a search [or a pointer?]
  3. To make the above work, we created a views called "array" that returns an array of results.  So you might get something like [5,6,7,8], and then the ruby card performs the summing.



This is happening in 1.4? Awesome!

yeah, it's basically there now.

  --Ethan McCutchen.....Wed Mar 31 17:38:42 -0700 2010

I'd be (very!) happy to test this, but am completely unsure how. Noticed and took a look at but still clueless. Help?

  --John Abbe.....Tue Apr 13 20:52:56 -0700 2010

I outlined the solution above. test.dwagn may not look right until we get the old rforms and tforms migrated, which should be quick. Just pinged lew about it.

  --Ethan McCutchen.....Wed Apr 14 13:04:30 -0700 2010

Messed around with this a bit; had to learn a little Ruby of course :-). The sum examples i found online resulted in: "Insecure: can't modify instance variable", but then i saw sum+*right+*content, which i don't grok, but i tested summing and it works; see


I pulled off randomness on my own, though! See for a working example, though i can't figure out why doesn't work, via Pointer or Search.


Closed view breaks sometimes — on the random cards, but not on calculation test.


Also, item:link isn't respected.


We're ignoring puts, right? The Ruby card returns the value of the last line of code?


Much more testing to do. But probably this ticket needs renaming to whatever narrow functionality is needed in the immediate future. What is that functionality?

  --John Abbe.....Sun May 02 06:31 -0700 2010

Bigger-picture -- while i think it would be nice to do other languages at some point, i think it would be even nicer to add a calculation cardtype with something a little GUIer so that non-coding Wagneers could have some of this sort of functionality. Make sense? Ticket add calculation cardtype?

  --John Abbe.....Sun May 02 06:08:05 -0700 2010

Note that .to_i was not necessary.

  --John Abbe.....Sun May 02 14:13:11 -0700 2010

Well the problem with the tests is in the ruby, which I'm not ready to jump in and debug - in part because Ruby cards are currently a pretty miserable coding environment. It looks to me like the things you said were working (like the random_test) are not for me. Would probably be easier if you started with cards that had numbers as a value.


The reason we didn't start by adding something more GUI is that we didn't really know how we'd want that to work. The idea at this stage is that we can code up a bunch of broadly useful ruby cards (like sum, average, difference, etc) and then help no-coding wagneers combine them to do what we need. I actually think if we work this out well it might prove really cool for naming lots of moving parts.


It might be that we just use a little GUI plug-in. Or it might be more like a spreadsheet in that the display of numbers (eg financial, financial rounded...) is separated from the calculations, perhaps via settings, and so the logic is in some way more distributed.


As for the use case that we built that for -- it's working. It's doing inventory / availability calculations on ainability.

  --Ethan McCutchen.....Mon May 03 09:37:58 -0700 2010

Closing this now. Not seeing any particular bugs reported. Any new ones should probably go into a new ticket.


There is the idea of a "calculation cardtype", which at this feels more like an idea than a dev ticket, because I don't have much clarity about how it works / looks / fits in. My guess is that we will come around to wanting this, but that it will wait for modules (and be implemented as one).

  --Ethan McCutchen.....Tue Sep 28 13:24:34 -0700 2010