openalgo-script 0.7.2 → 0.8.1

package/CHANGELOG.md

@@ -7,6 +7,107 @@ nothing, fails the build before it can become permanent.
 
 ---
 
+## 0.8.1
+
+Two fixes and a documentation correction. No compiled-format change: the format
+stays 1.1, and every shipped example compiles to the same bytes as with 0.8.0.
+
+The chart adapter now reads an alert's message at the bar the chart judged. From
+its version 2.6.0 the chart library can run a study on a transformed chart over
+the bars the host feeds rather than over the elements it draws, and it reads the
+study's columns onto those elements, each at the bar the element was completed
+on. The alert's condition is a column and was read at the right bar. Its message
+was not: the adapter read it at the element's position in the underlying run,
+so on a transform that is not one element per bar (Renko, range bars, line
+break, point and figure, Kagi) a notification could carry another bar's text or
+fall back to the alert's title. The calculation now returns one more column,
+`openscript:bar`, holding each row's bar index in the run, and the message is
+read at the bar that column names. The column is written only for a study that
+declares an alert. On every other chart, including every chart library before
+2.6.0, a study left on the chart's own bars and a transform that keeps one
+element per bar, the column is the row's own index and nothing a study draws or
+announces changes. A host that lists the keys of the values table sees the new
+key beside the `openscript:alert:` ones.
+
+`req.timeframe` and `req.symbol` now read a mode written positionally. The mode
+is the third argument of `req.timeframe` and the fifth of `req.symbol`, and it
+was recognised only after `mode =`. A positional mode was accepted and ignored,
+so `req.timeframe("1D", close, "lookahead")` ran as `"confirmed"`, carried no
+OS8005 and was not marked as repainting, and a positional `"developing"` ran
+confirmed too. A script that wrote its mode positionally now runs in the mode it
+wrote, so its values change, and a positional `"lookahead"` now carries OS8005
+and the repaint mark. A positional mode that is not written out as one of the
+three words, one taken from an input for instance, is refused with OS3003, as a
+labelled one already was. The mode is settled by the compiler, so a program
+compiled by 0.8.0 and stored keeps the mode it was compiled with in either
+engine: recompile a stored program whose source writes a mode positionally. The
+new conformance case `req/positional-mode` pins it, and both engines agree on
+all 108 cases they run.
+
+The documentation said a `"1D"` higher timeframe read folds by the session. It
+folds by the civil date in the instrument's timezone, as `compiled-program.md`
+2.16.2 specifies and both engines have always done. For a session that stays
+inside one date the two are the same; an evening session that runs past
+midnight is split at midnight, and its bars after midnight join the next date's
+bucket. The pages on sessions, timeframes and higher timeframes, and the cause
+of OS6015, now say so. No behaviour changes.
+
+The Python engine's code is unchanged. The chart adapter ships only in the npm
+package, and the mode fix is in the compiler. The Python package moves to 0.8.1
+because the two packages carry one version and ship as one release. Upgrade both
+together.
+
+## 0.8.0
+
+The chart adapter now draws two things it used to refuse, on a chart that can
+draw them. A band whose colour the script computes per bar is shaded bar by bar,
+and a study that declares more than one grid gets every grid, each in the corner
+its own `position` names. Both need hooks the chart library added in its version
+2.5.4, and a chart ignores a hook it does not know, so the adapter is told which
+chart it is drawing on: a host passes the library's exported `VERSION` string as
+the new `chartVersion` option, `descriptorFor(program, { chartVersion: VERSION })`.
+
+A host that passes nothing draws exactly what it drew with 0.7.2, and such a
+study is still refused before any bar runs with OS6024. So is one on a chart
+older than 2.5.4, on a prerelease of 2.5.4, or on a version string that cannot
+be read, and the refusal now ends by saying which version the host stated. On no
+chart version is either thing drawn in part or dropped in silence.
+
+How a computed band colour is drawn. Each bar is shaded in the colour the script
+computed there for the side the band is on, and the side is decided the way the
+chart decides it, the first plot at or above the second, so the colour always
+belongs to the run the chart draws that bar in. An absent colour leaves the bar
+unshaded, as `docs/visuals/fills.md` has always taught. A side the script did
+not compute keeps the colour it declared. `opacity` dims a computed colour
+exactly as it dims a constant one, and the twelve percent fade of a band with no
+colour of its own does not apply to a band whose colour is computed.
+
+How several grids are drawn. Each grid reaches the chart under its declaration's
+key, which does not change between recomputes, so the chart keeps a grid rather
+than building it again on every tick. The single `table` hook still carries the
+first grid, for a chart without the list. Two grids pinned to the same corner are
+drawn one over the other, so give each grid its own `position`.
+
+For a host that type checks the descriptor: `ChartFill` gains an optional
+`colorBy`, `ChartDescriptor` an optional `tables`, and `ChartFillContext` and
+`ChartTableSpec` are new exports. The one line assignment to the chart library's
+own descriptor type was compiled against that library's types at 2.5.1 and at
+2.5.5, and a study with two grids and a computed band was drawn end to end on
+2.5.5.
+
+The Python engine is unchanged. It never had either limit: its fills channel
+already publishes each band's colours bar by bar, and its table channel already
+serves every declared grid in declaration order. The chart adapter ships only in
+the npm package. The Python package moves to 0.8.0 because the two packages carry
+one version and ship as one release, and upgrading it changes nothing.
+
+No compiled-format change, no language change, and no computed value moves:
+every shipped example builds the same descriptor and the same columns as 0.7.2
+when no chart version is stated. Still not decided: a band that computes one
+side's colour and names none for the other draws that side in the chart's own
+default colour, as a band with one constant side always has; whether such a side
+should be unshaded is recorded as open in decision 75.
+
 ## 0.7.2
 
 Running totals in both engines now survive one overflowing bar. `pvt` added its