Repository navigation
input.color metadata says type string, default color.red, but the engine setter wants a packed 0xAARRGGBB integer #231
Description
Summary
For input.color, the input metadata returned by transpile_full reports {"type": "string", "default": "color.red", "supported": true}. Passing that default back through the input setter fails, because the engine expects the packed 0xAARRGGBB integer. A host that round-trips the reported defaults, which is what a parameter sweep does, has to special-case colour inputs.
Versions
pineforge-codegen 1.6.1, pineforge-engine 1.6.1 (693fd9e6)
Reproduction
//@version=6
strategy('Color input')
lineColor = input.color(color.red, 'Line color')
plot(close, color=lineColor)
- Setting
Line colorto the reported default"color.red":PineForge rejected setting 'Line color': expected an integer - Setting it to
4294063685(0xFFF23645, the opaquecolor.redthe engine uses): accepted
Expected
Metadata that round-trips: either type color with the default as the packed integer the setter accepts, or a setter that accepts the reported color.* expression.
Activity
[-]`input.color` metadata says type `string`, default `color.red`, but the engine setter wants a packed integer[/-][+]`input.color` metadata says type `string`, default `color.red`, but the engine setter wants a packed `0xAARRGGBB` integer[/+]letiep97 commentedon Oct 20, 2026
A correction to the issue text, now edited: I called the setter value "packed RGB" and said
16711680(0xFF0000) is accepted. The engine stores colors as0xAARRGGBB(include/pineforge/color.hpp#L7-L13), so 16711680 is red with alpha 0, fully transparent. The value matching the defaultcolor.redis4294063685(0xFFF23645).Still reproduces on main (
aebad8c). A pointer in case it helps: codegen/input.py#L45 reports the color form type asstringand keeps the default as the source textcolor.red, while the getter isget_input_int64(codegen/input.py#L309-L310).input.timealready goes the integer way (form typeint, int64 getter). Reporting color the same way, with the default as the packed constant thatcolor.*already lowers to, would make the metadata round-trip. The alternative is an engine setter that acceptscolor.*names and#RRGGBB/#RRGGBBAA.luisleo526 commentedon Oct 25, 2026
Thank you for the report. Confirmed in the v1.7.0 source: the metadata reports type
stringand defaultcolor.redfor aninput.color, while the input setter expects the packed integer. This is not fixed in v1.7.0. A fix is being written: the metadata will report a color type and the default as the packed 0xAARRGGBB integer the setter accepts, so that the reported defaults round-trip. We expect to open the pull request on 2026-10-26.codegen: input.color metadata reports a color type with a packed inte…
luisleo526 commentedon Oct 25, 2026
Fixed by #251, merged to main: the metadata for an
input.colornow reports a color type and its default as the packed 0xAARRGGBB integer the input setter accepts, so the reported default round-trips. pineforge-hpo already accepts color inputs in that form. It will ship in the next codegen release; I will note the version here when it is published. Thank you for the report.luisleo526 commentedon Oct 25, 2026
Update: this fix ships in the next codegen release, 1.8.0 (paired with the engine; I will confirm here when it is published).
docs: CHANGELOG: the planned 1.8.0 section with migration notes (#257)
letiep97 commentedon Oct 28, 2026
Verified on main (
11b5ca5, with engine 1.6.1): the metadata of theinput.colorin the reproduction now reports typecolorwith default4294063685(0xFFF23645,color.red), and a run with that default succeeds. Thank you for the fix.