scripting

Límites del sandbox

Presupuestos de CPU y memoria, qué prohíbe la VM bytecode, y cómo optar a ventanas más largas.

Cada script corre dentro de una VM bytecode con presupuestos duros de CPU y memoria, aplicados por evaluación. Un loop desbocado no tira la app.

Screener bajo el sandbox — 200 ms por símbolo, el fan-out se sigue sintiendo instantáneo.

Presupuestos por defecto

| Superficie | CPU por barra | Techo de memoria | |---|---|---| | Indicator (vista previa) | 50 ms | 16 MB | | Alert (por evaluación) | 50 ms | 16 MB | | Screener (por símbolo) | 200 ms | 32 MB | | Drawing | 50 ms | 16 MB | | Strategy (por barra) | 100 ms | 32 MB | | Backtester (corrida completa) | 60 s | 256 MB | | Worker VPS (por evaluación) | 200 ms | 64 MB |

Si se excede un presupuesto, la VM mata la evaluación e informa de un error de violación de sandbox en el editor de scripts. Las evaluaciones posteriores continúan.

Capacidades prohibidas

La VM no tiene acceso a:

El sistema de archivos host.
Sockets de red arbitrarios. Solo built-ins auditadas (p. ej. notify sobre una lista conocida de webhooks) llegan a la red.
Código nativo. Sin FFI.
El reloj del host — los scripts leen timestamps de barra vía bar(N), no Date.now().
Estado de otros scripts. Cada script está aislado.

Cancelación

Un script puede cancelarse a media evaluación:

El usuario cierra el gráfico, edita el script o pulsa el kill switch.
El presupuesto de CPU se agota.
Para el cloud worker: dispara un tope de pérdida diaria o pausa administrativa.

La cancelación es cooperativa — la VM inyecta checkpoints entre operaciones de bytecode, así que un loop infinito apretado termina en ~1 ms desde la señal de cancelación.

Optar a presupuestos más largos

Las cuentas Pro pueden solicitar presupuestos extendidos para scripts específicos vía metadata en el archivo:

// budget: cpu=500ms mem=128mb

La aprobación se revisa automáticamente — el abuso degrada la solicitud.