v2.1.6#287
Closed
singaraiona wants to merge 6 commits into
Closed
Conversation
The GitHub Pages deploy (.github/workflows/pages.yml) installs docs deps from requirements-docs.txt and uses it as the setup-python pip cache key, but commit 2cb1441 ("chore") deleted the file. The deploy has failed at the setup-python step ever since ("No file matched to [requirements-docs.txt or **/pyproject.toml]") — the latest dev→master merge just surfaced it. Restore the file with mkdocs-material (which bundles mkdocs, pymdown-extensions, and the material emoji extensions used in mkdocs.yml). The previously listed mkdocs-redirects is intentionally omitted — mkdocs.yml documents that plugin as disabled (only `search` is active).
requirements-docs.txt is CI-only; at repo root it's clutter, and it can't live under docs/ (that's mkdocs docs_dir, so it would be published into the site verbatim). Move it next to the workflow that consumes it and update pages.yml's path trigger, pip cache key, and install step accordingly.
`within` worked as a standalone vector op but the DAG WHERE compiler
rejected it (`compile_expr_dag` is a whitelist and it was never wired),
so `(select {... where: (within col [lo hi])})` errored with
"WHERE predicate not supported by DAG compiler" while `in` was accepted.
Lower `(within col [lo hi])` to `(and (>= col lo) (<= col hi))`, reusing
the existing comparison constructors. The range bounds are extracted from
the constant range vector via ray_at_fn (preserving DATE/TIME/I32 element
type) and wrapped as const-atom nodes. Because it compiles to plain
comparison opcodes, `within` now inherits range-index rowsel, partition
pruning, null handling, type promotion and the selection-aware AND-chain
path for free.
Parity with `in`: the range must be a compile-time-constant 2-element
vector (same literal-operand constraint OP_IN's set has); a non-const or
wrong-length range falls back to the eval-level builtin.
Closes #284
`.ipc.open` had no way to bound a connect. The blocking connect() ignores
SO_RCVTIMEO/SO_SNDTIMEO, so a dead or packet-filtered peer would hang for
the OS default (often minutes) with no user control.
Make `.ipc.open` variadic with an optional trailing timeout (milliseconds):
(.ipc.open "host:port")
(.ipc.open "host:port" 2000)
The timeout bounds both the TCP connect and the handshake I/O:
- ray_sock_connect now drives a non-blocking connect + poll(POLLOUT) when
a positive timeout is given, restoring blocking mode for the handshake;
on timeout it sets errno=ETIMEDOUT (added ray_sock_set_blocking helper).
- ray_ipc_connect takes a timeout_ms, defaulting to the long-standing 5s
budget when none is supplied, and maps a connect timeout to a new -5
return code so .ipc.open reports "connection timed out" distinctly from
"connection refused".
ray_hopen_fn is now a vary builtin validating arity (rank), timeout type
(type) and sign (domain). Updated the public/internal prototypes, the
.repl.connect wrapper, the C unit tests pinning the signature, and the
IPC docs.
Closes #286
A server-side function returning (first v) / (last v) over IPC never replied — the client blocked forever (issue #285). Root cause: first/last (and sum/min/max/avg) over an I64/F64 vector build a deferred-DAG *lazy* result via AGG_VEC_VIA_DAG → ray_lazy_wrap. In eval_payload_core, STR payloads go through ray_eval_str (which materializes) but expression-list payloads go through ray_eval, which returns the lazy object verbatim. ray_serde_size(lazy) is <= 0, and send_response did `if (ser_size <= 0) return;` — silently sending nothing, leaving the client waiting on a reply that never came. Fixes, both in src/core/ipc.c: - eval_payload_core now materializes a lazy result (ray_lazy_materialize) before it reaches the wire — covers both server send paths. - send_response substitutes a serializable error instead of dropping an unserializable reply, so any future non-serializable value surfaces as a clean client-side error rather than a silent infinite hang. Regression test test/rfl/system/ipc_first_last.rfl covers first/last (and sum/min/max) returned via expression-list payloads and via a server-side lambda, exactly as reported. Closes #285
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
1 participant
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.
No description provided.