v1.10.0

Install: pip install pineforge-codegen==1.10.0

Pairs with engine v1.10.0.

1.10.0

Fixed

• Prevent 32-bit narrowing in the checked integer-parameter forms (#285, #322).
• Preserve time-input values in the checked changed-input, unchanged-var and copied-input forms, while preserving the directly used ordinary unchanged date filter (#321, #322).
• Prevent an extra reversing lot on the same tick after strategy.close when calc_on_order_fills = true and pyramiding = 1 (#708, #727).
• Fill a stop-limit entry on the closing tick with process_orders_on_close = true when its stop is reached and its limit is executable at that close (#725, #707).
• Render Boolean-to-string conversions as true or false, and preserve Boolean inputs read through history (#319, #315).
• Compile the reported single-line-body and string-array na() forms (#290, #281).
• Allow a same-ID market entry after strategy.close when an earlier same-ID limit entry on that bar was not reached (#723, #727).
• Align request.security bar-index values for supported requested-timeframe grids, including 300-, 420- and 600-minute requests on a 60-minute chart (#722, #727).
• Correct time_close for session-bound feeds when the caller omits the symbol session and timezone (#720, #727).
• Evaluate the selected request.security timeframe on each bar for a known finite set of alternatives, including computed strings and local aliases (#316).
• For supported per-bar requests, preserve independent persistent state for each requested timeframe, including a referenced persistent counter declared outside the request (#314).
• str.format_time preserves quoted spans, renders a single unquoted Z as a numeric UTC offset, and safely sizes long formatted results (#712).
• Long stop-limit orders fill when observed tick input reaches an executable fractional limit on the chart's price grid, including affected limits such as 99.99 on a 0.01 grid (#721, #715).
• Preserve a fractional division used directly as a loop start, and count supported floating-step loops using TradingView's measured end rule (#317).
• Preserve fractional quotient reassignments in supported integer-initialized variables, including supported function-local return values (#318).
• Supported statically endless counted loops at chart scope stop with a located runtime error when their result is used; the measured unused form is omitted (#317).
• Accept math.pow keyword arguments, int/float/bool/string named-argument labels, constant-colour input defaults and supported operator-line continuations (#317).

Engine and tooling updates

• Native-live modules built with an earlier version are still accepted and use the standard report path (no live accumulator) until they are rebuilt.
• Renamed the borrowed-array row type from FeedBar to FeedBarRow, avoiding clashes with client-defined FeedBar types (#717).
• Serialized provider fetches per source repository in ci_verify, preventing concurrent verification workers from racing on the same repository (#717).
• Added container-level quota supervision for run-json jobs (#717).
• Updated public documentation and comments with plain language, synthetic examples and neutral wording (#712, #717).

Changed run-failure codes

Consumers that validate diagnostic argument values need to accept these additions in the minor release:

• outputs_limit: args.reason gains too_many_series. This code also covers a series-capacity limit reached at declaration.
• scratch_capacity_exceeded: args.resource gains cohort_ids_total and cohort_orders_live.

Known issues

Direction restrictions and percentage limits in strategy.risk calls

Known issues: strategy.risk.allow_entry_in() can ignore a non-literal positional direction, admitting excluded-direction entries; strategy.risk.max_drawdown() and strategy.risk.max_intraday_loss() can apply a percentage limit as an amount when its type is supplied with type = or through a variable. Pass literal direction and percentage-type constants positionally (details and workarounds). Fixed in the next release.

Known issue: some argument forms in v1.10.0 silently change timeframe queries, trade-index reads, history depth, time formatting or percentage risk limits. Use the traced positional forms or a literal history depth (details and workarounds). Affected forms: none found in our corpus in the checked snapshot.

Array aliases and copied slices

Some valid array scripts compile but produce values different from TradingView:

• An array alias kept past its source array's lifetime produced 2.0 where TradingView produced 3.
• A copy of an array slice that still shares elements produced 2.0 where TradingView produced 1.

In each checked example, none of the 26 bars matched TradingView.

Changed time inputs

A non-var variable initialized from input.time() and changed later keeps accumulating the changes instead of restarting from its input on each bar. The width checks for this shape compare only the first bar; per-bar restart remains a separate defect (#322).

Indicators start cold at the backtest start

App backtests, HPO, hosted MCP and offline npm runs currently start the engine at the user's first bar, with no earlier history. A TradingView chart normally includes earlier bars, so its indicators are already warm. Indicators that depend on history can therefore differ during the first part of a run.

One measured example, not a general bound: on one ETH 15-minute script with 192 trades, TradingView had 288 bars of history before the selected start. EMA values differed for about the first 73 fifteen-minute bars (36 half-hour samples) and RSI for about the first 172 bars (86 samples); window indicators such as SMA and highest had no values for about the first 11 bars (5 samples). Loading those same 288 earlier bars made all 192 rows equal on every field. These counts are not a warm-up guarantee for other scripts or settings.

Separate comparisons against references that start at the range start found two extra early trades for an EMA-crossover strategy and differences in the first four MACD quantities. The trade impact of those strategies against a normal chart with longer history has not yet been measured.

This long-standing behavior is confirmed in 1.8.0, 1.9.1 and 1.10.0. Compiler note PF-W1505 has said “ta.ema initial warmup is approximated” since 1.0, without quantifying the difference.

Loading history before the selected start addresses the cold start; the existing selected-window pre-roll is an opt-in for this. It matched TradingView in the 192-row example above. No broader workaround has yet been verified against TradingView. For references that themselves start at the range start, an upcoming release is planned to add a run option to declare the series origin. This does not make a cold-start reference equivalent to a chart with earlier history.

For App backtests, the start-of-run difference will be fixed when the App loads history before the selected start (planned; no date yet).

On a daylight-saving change day, a requested intraday bar of a symbol with no trading session in a daylight-saving timezone may use the other side's offset for instants before the change; this is not yet measured against TradingView.

Some request.security calls inside helper methods, or with a payload that reads a helper-local value, translate but fail to compile; a fix is in progress.

The following public issues remain open. Each link carries the reported scope and status for the next release.

Component / issue	Open issue	Status
engine #718	Requested timeframes that are not multiples of the chart timeframe can produce values that differ from TradingView.	Fix planned for the next release (1.10.1)
engine #716	Symbols without a lot size remain gridless. 1.10.0 supplies a quantity step for library callers that set only the minimum order size; an explicit quantity step takes precedence.	Fix planned for the next release (1.10.1)
engine #694	Five order and request.security behaviours that differ from TradingView: exits placed with the entry, per-entry tick exits, trade size sign, lookahead_on	Fix planned for the next release (1.10.1)
engine #664	Reported trailing-stop scoreboard grading tolerance.	Fix planned for the next release (1.10.1)
engine #621	Resting-order reads grow quadratically past the resident book cap	Fix planned for the next release (1.10.1)
engine #452	Backtest time grows quadratically with the number of distinct entry ids (~200× on 700k bars)	Fix planned for the next release (1.10.1)
codegen #311	A negative [] offset computed from inputs returns na instead of stopping the script	Fix planned for the next release (1.10.1)
codegen #310	A request.security timeframe chosen by a chart series value is computed once, not on every bar	Fix planned for the next release (1.10.1)
codegen #301	A missing integer value assigned to a float variable becomes -2147483648 instead of na	Fix planned for the next release (1.10.1)
codegen #295	Valid v6 forms that are refused, emit C++ that does not compile, or fail when an input is set	Fix planned for the next release (1.10.1)
codegen #294	Four valid request.security forms refused: lookahead from a variable, '' timeframe, [] on a requested value in a nested request, an uncalled wrapper	Fix planned for the next release (1.10.1)
codegen #293	timestamp(dateString) refuses a full month name such as '01 February 2024 00:00'	Fix planned for the next release (1.10.1)
codegen #292	Strategy command arguments lowered to fixed values: strategy.order() without qty, a switch qty from an int input, allow_entry_in() from an input	Fix planned for the next release (1.10.1)
codegen #291	Five valid v6 scripts that translate and run with wrong values and no diagnostic	Fix planned for the next release (1.10.1)
codegen #287	request.security: a helper-history value passed to a function or a ternary still fails with PF-E3011 (follow-up to #229)	Fix planned for the next release (1.10.1)
codegen #286	Order functions accept unknown named arguments, including the removed when, and drop them	Fix planned for the next release (1.10.1)