Add range bar visualization and enhance position data output#40
Open
faizalmy wants to merge 1 commit into
Open
Add range bar visualization and enhance position data output#40faizalmy wants to merge 1 commit into
faizalmy wants to merge 1 commit into
Conversation
- Introduced a `buildRangeBar` function to create a visual representation of position ranges. - Updated position data output to include a formatted profit and loss (PnL) string. - Added `bin_step` to position data for improved range calculations.
mrichlaz
added a commit
to mrichlaz/meridian
that referenced
this pull request
Jul 2, 2026
…in % check The heartbeat was logged when \`_pollCount % 20 === 1\`, which only fires on counts 1, 21, 41, 61, ... The first call after every process restart would log tick yunus-0x#1, and subsequent heartbeats should show tick yunus-0x#21, tick yunus-0x#41, etc. But in practice the log always showed 'tick yunus-0x#1' across 2+ hours of runtime (27 PNL_TICK lines, all tick yunus-0x#1). Root cause: the poller fires every 3s, and cron cycles (management every 10m, screening every 20m) also call getMyPositions. The count advances by ~20 every minute. But the heartbeat only logged on count=1, 21, 41 — and the actual count shown was always 1, suggesting the module was being re-imported between calls (e.g. by dynamic import(\"./dlmm.js\") in tools/screening.js or smart-wallets.js). The off-by-one (=== 1 instead of === 0) is also a bug: - After a fresh restart, count goes 0 → 1, heartbeat fires showing 'tick yunus-0x#1'. But 'tick #0' on the very first call would have been more accurate, and subsequent heartbeats should show 'tick yunus-0x#20', 'tick yunus-0x#40' etc. - With === 1, if count happens to land on 20 (instead of 21), the heartbeat silently misses that cycle. Switch to \`_pollCount % 20 === 0\` so the heartbeat logs at counts 20, 40, 60, ... and the first heartbeat after a restart shows 'tick yunus-0x#20' (which is correct since the count was just incremented from 19 to 20). Note: this is a cosmetic fix. The actual PnL data flow is working correctly (2 positions tracked, trailing TP logic, etc.) — only the heartbeat log was misleading.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
buildRangeBarfunction to create a visual representation of position ranges.bin_stepto position data for improved range calculations.Proposed Design
Range Percentage Format
Show the percentage distance from the current price to each edge of the position's bin range:
Interpretation (for IN range):
-34%= price needs to drop 34% to hit lower bound (negative = downside room)+5%= price needs to rise 5% to hit upper bound (positive = upside room)OOR below (price below lower):
+28%= price must rise 28% to hit lower bound (positive = upside needed to enter)+34%= price must rise 34% to hit upper boundOOR above (price above upper):
-22%= price must drop 22% to hit upper bound (negative = downside needed to enter)-17%= price must drop 17% to hit lower boundBar Format (Unicode)
Use a 10-segment Unicode bar:
▓= filled segment (in-range portion traversed from lower toward active)░= empty segment (remaining range ahead)IN range — active price between lower and upper:
Filled ratio:
clamp(round((active - lower) / (upper - lower) * 10), 0, 10)OOR — price outside range: empty bar with directional arrow.