[TW5] new plugin: tobibeer/eval

[Tobias Beer]

Hi everyone,

I hereby release the new eval plugin (or tobibeer/eval) which provides an eval filter and an eval widget ...the latter working similar to the calc widget in mklauber/math.js, however leveraging a "plug-and-play" library model (and then some).

The eval plugin was born out of my desire (and Jeremy's suggestion) to overcome the constraints of let filter, (henceforth abandoned,) which started out with similar aspirations, allowing to compute and compare with tidbits, however, somewhat at the wrong end of the stick.

If you prefer to learn by example, take a look at the examples.

The repo and the commented, non-minified source code is at:

https://github.com/tobibeer/tw5-eval

Although quite neatly designed, thoroughly tested and refactored, I have flagged this release as BETA so as to invite you to test it, and also to indicate that — architecturally speaking — things might nevertheless still change, perhaps. With or without further modifications, I intend to take it out of BETA in, say, a couple of weeks.

Eval is capable of evaluating expressions leveraging different libraries, for now supporting:

• math.js
• you need to separately install tobibeer/math.js which contains nothing but math.js itself
• and avails it at $:/lib/math.js
• should you already use mklauber/math.js, eval will load the math.js version it ships with
• so there's no need to install tobibeer/math.js
• js
• allows to evaluate native javascript
• needs to be specifically enabled, see configuration
• in other words, you don't even need any math.js if...
• you are confident to do your math in nothing but js
• wish to trim those resource requirements

The eval filter provides the following capabilities:

• a main expression to be evaluated, obviously ...being the operand
• you can specify more expressions, predefined or custom variables, and options, all in the operand
• separate different operand declarations via backslash (\), defined as name:value e.g...
• an init value — initializing the value before taking off to evaluate the main expression against each input title
• a final expression — a final computation after the main expression had been evaluated against the last input title
• the value and title run-time variables — automatically set for each input title, for use in the main or final expression
• a format option — to have math.js nicely format your output value
  
• a lib option — to specify for each filter instance which library to use in order to evaluate the given expression(s)
• custom variables — any name that is not a predefined variable or option
• to help make your main or final expression more readable
• the suffix — to define what to return
• no suffix: returns just the final value
• output mode suffixes, prefixed $, use one at a time, returning...
• $ — those input titles where value is truthy
• $all — all input titles if the value is truthy for any input title
• $val — a list of values, one for each input title
• $expr — a list of expressions, one for each input title
• $eq — a list of equations, one for each input title => great for debugging

Both text references as well as wikitext-variables can be used freely in the operand and are substituted in any expression or variable. (Note: custom variables are only evaluated on init, not during iterations. They shall also not reference each other).

Ok, so... hope to see you give it a test-ride and let me know what you think, what things may not work (as expected) but also which work just about right. ;-)

~

For loading libraries, the eval plugin does some neat dependency resolving, the gist of which I hope will eventually find its way into the core, in one form or another. That way, we don't ship and install things like vis or math.js or any other library with any plugins that build on them. Nor does plugin A require plugin B, just to not duplicate a given library. For math.js, for example, there barely any needs for a plugin to depend on a given version of math.js. But even that can be catered for with some minor amends as to version handling / dedicated library versions resolved in just about the same way as eval does right now.

Best wishes,

Tobias.

[Tobias Beer]

Hi there,

just published a new release 0.6.8 BETA of tobibeer/eval,

fixing console errors shown if a configured math.js library could not be loaded.

http://tobibeer.github.io/tw5-plugins/#eval

Best wishes,

Tobias.

[Tobias Beer]

Hello again,

I added a new default variable with version 0.6.9 called count

which simply avails the current count of input titles to the expression.

[Mr. Man]

Hi Tobias.

Is It possible to using this plugin to make conditional statement like if {{!!foo}} >80 then print A. I am try to make gradebook using TW5. Thank you.

[Hegart Dmishiv]

Hi Tobias, I'm looking for an answer to the same question as Mr. Mal above is. Here's my use case.

I have tiddlers tagged  Phone Number , which contain the fields: countrycode, areacode, exchangecode, phonenumber, type, purpose, owner. The first four of those contain numeric values only. The type* field contains values such as Landline, Mobile, Freephone. I have a ViewTemplate which formats and displays the fields as a proper phone number, such as:

+<$view field="countrycode"/>-<$view field="areacode"/>-<$view field="exchangecode"/>-<$view field="phonenumber"/>

The problem is, I recycle the same fields regardless of whether a Phone Number is a landline, mobile, or freephone number, all of which have slightly different formats, particularly the freephone ones. I want to be able to somehow evaluate the value of the type field, and format the output accordingly. For instance, a freephone number should be formatted as:

0-800-<$view field="exchangecode"/>-<$view field="phonenumber"/>

Is there some way of doing this using your eval[ ] filter plugin, or any other way of doing it?

* Yes, I know that type is a reserved fieldname in TiddlyWiki. I'm still coming up with a replacement field name. Any suggestions gratefully accepted. This is for my {{DesignWrite}} semester project, TiddlyCRM.

Hegart.