jrf 0.1.9 → 0.1.11

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: e826b340d1d48d7e8cdd3de9b619e5b019f1b568794d0d306b4001f93b5478b8
-  data.tar.gz: 061102212643ccfd8654c31e3c8b7e48b6f1bc0131dcac77badb0295a7074d84
+  metadata.gz: edaeb729eecf63449c68fce92740acb8221885ff28a5ed26fe7bea32eb0a9bfa
+  data.tar.gz: 30364ac5e6eee46506da8c4d3ff2d8a05f12cd91b2b5cd248a12e612ea333891
 SHA512:
-  metadata.gz: '09883c9cd3ba7f52190df336553cfd45156a90f400a4b87099a86c7e753dab2e07dbe73cfea1c45fb37ca88cb06ebee7f15e286988c0ec42fe526599d897b355'
-  data.tar.gz: 5d8d0cc2d749c647a3587d2cf8659876a55e8fe8a41e38a9183ad3551b6cca2f16f99ba7c806aebbe0f82afcd5b2c4e026f81fb781f338a6898d4d807f15c347
+  metadata.gz: 22e73015ffb398d376c3636f8a9e324c01bd56ae5dc1170b39a8ad5c600c10273fadec1de5385706798e3aff19449b446744e608f1437ca73113871c33aa9b1b
+  data.tar.gz: 4c803ad64d65d6ae1d671426c2e81a4741ebcebd66ca4fb288574336e0a1088b8be2aa78f4235213ffc5794c92877410c88cbce7dae1f88bfb6369f6f37e3970

data/jrf.gemspec

@@ -17,5 +17,5 @@ Gem::Specification.new do |spec|
   spec.executables = ["jrf"]
   spec.add_dependency "oj", ">= 3.16"
 
-  spec.files = Dir.glob("{exe,lib,test}/*") + Dir.glob("lib/**/*") + %w[DESIGN.txt jrf.gemspec Gemfile Rakefile]
+  spec.files = Dir.glob("{exe,lib,test}/*") + Dir.glob("lib/**/*") + %w[DESIGN.txt jrf.gemspec Gemfile Rakefile].select { |path| File.file?(path) }
 end

data/lib/jrf/cli.rb

@@ -17,6 +17,8 @@ module Jrf
         -v, --verbose  print parsed stage expressions
         --lax          allow multiline JSON texts; split inputs by whitespace (also detects JSON-SEQ RS 0x1e)
         -p, --pretty   pretty-print JSON output instead of compact NDJSON
+        -r, --require LIBRARY
+                       require LIBRARY before evaluating stages
         --no-jit       do not enable YJIT, even when supported by the Ruby runtime
         --atomic-write-bytes N
                        group short outputs into atomic writes of up to N bytes
@@ -43,6 +45,7 @@ module Jrf
       lax = false
       pretty = false
       jit = true
+      required_libraries = []
       atomic_write_bytes = Runner::DEFAULT_OUTPUT_BUFFER_LIMIT
       begin
         parser = OptionParser.new do |opts|
@@ -50,6 +53,7 @@ module Jrf
           opts.on("-v", "--verbose", "print parsed stage expressions") { verbose = true }
           opts.on("--lax", "allow multiline JSON texts; split inputs by whitespace (also detects JSON-SEQ RS 0x1e)") { lax = true }
           opts.on("-p", "--pretty", "pretty-print JSON output instead of compact NDJSON") { pretty = true }
+          opts.on("-r", "--require LIBRARY", "require LIBRARY before evaluating stages") { |library| required_libraries << library }
           opts.on("--no-jit", "do not enable YJIT, even when supported by the Ruby runtime") { jit = false }
           opts.on("--atomic-write-bytes N", Integer, "group short outputs into atomic writes of up to N bytes") do |value|
             if value.positive?
@@ -82,6 +86,7 @@ module Jrf
 
       expression = argv.shift
       enable_yjit if jit
+      required_libraries.each { |library| require library }
 
       inputs = Enumerator.new do |y|
         if argv.empty?

data/lib/jrf/row_context.rb

@@ -173,13 +173,13 @@ module Jrf
     def map(&block)
       raise ArgumentError, "map requires a block" unless block
 
-      @__jrf_current_stage.step_map(:map, @obj, &block)
+      @__jrf_current_stage.step_map(:map, current_input, &block)
     end
 
     def map_values(&block)
       raise ArgumentError, "map_values requires a block" unless block
 
-      @__jrf_current_stage.step_map(:map_values, @obj, &block)
+      @__jrf_current_stage.step_map(:map_values, current_input, &block)
     end
 
     def group_by(key, &block)

data/lib/jrf/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Jrf
-  VERSION = "0.1.9"
+  VERSION = "0.1.11"
 end

data/test/jrf_test.rb

@@ -145,6 +145,7 @@ assert_includes(stdout, "usage: jrf [options] 'STAGE >> STAGE >> ...'")
 assert_includes(stdout, "JSON filter with the power and speed of Ruby.")
 assert_includes(stdout, "--lax")
 assert_includes(stdout, "--pretty")
+assert_includes(stdout, "--require LIBRARY")
 assert_includes(stdout, "--no-jit")
 assert_includes(stdout, "-V")
 assert_includes(stdout, "--version")
@@ -203,6 +204,19 @@ stdout, stderr, status = Open3.capture3("./exe/jrf", "--atomic-write-bytes", "0"
 assert_failure(status, "atomic write bytes rejects zero")
 assert_includes(stderr, "--atomic-write-bytes requires a positive integer")
 
+Dir.mktmpdir do |dir|
+  helper = File.join(dir, "helpers.rb")
+  File.write(helper, <<~RUBY)
+    def double(value)
+      value * 2
+    end
+  RUBY
+
+  stdout, stderr, status = Open3.capture3("./exe/jrf", "-r", helper, 'double(_["hello"])', stdin_data: input_hello)
+  assert_success(status, stderr, "require helper option")
+  assert_equal(%w[246 912], lines(stdout), "require helper option output")
+end
+
 if defined?(RubyVM::YJIT) && RubyVM::YJIT.respond_to?(:enabled?)
   yjit_probe = "{\"probe\":1}\n"
 
@@ -833,6 +847,14 @@ stdout, stderr, status = run_jrf('_["values"] >> map { |x| x + 1 } >> map { |x|
 assert_success(status, stderr, "chained map transforms")
 assert_equal(['[20,110,1010]', '[30,210,2010]', '[40,310,3010]'], lines(stdout), "chained map transforms output")
 
+stdout, stderr, status = run_jrf('map { map { |y| [ sum(y[0]), sum(y[1]) ] } }', "[[[1,2]]]\n[[[3,4]]]\n")
+assert_success(status, stderr, "nested map reducer binds to current target")
+assert_equal(['[[[4,6]]]'], lines(stdout), "nested map reducer output")
+
+stdout, stderr, status = run_jrf('map_values { |obj| map_values { |v| sum(v) } }', "{\"a\":{\"x\":1,\"y\":2},\"b\":{\"x\":10,\"y\":20}}\n{\"a\":{\"x\":3,\"y\":4},\"b\":{\"x\":30,\"y\":40}}\n")
+assert_success(status, stderr, "nested map_values reducer binds to current target")
+assert_equal(['{"a":{"x":4,"y":6},"b":{"x":40,"y":60}}'], lines(stdout), "nested map_values reducer output")
+
 input_gb = <<~NDJSON
   {"status":200,"path":"/a","latency":10}
   {"status":404,"path":"/b","latency":50}
@@ -930,10 +952,18 @@ assert_equal([[2, 3], [4, 5]], j.call([[1, 2], [3, 4]]), "library map transform"
 j = Jrf.new(proc { map { |x| sum(x) } })
 assert_equal([[4, 6]], j.call([[1, 2], [3, 4]]), "library map reduce")
 
+# nested map reduce binds to current target
+j = Jrf.new(proc { map { map { |y| [sum(y[0]), sum(y[1])] } } })
+assert_equal([[[[4, 6]]]], j.call([[[[1, 2]]], [[[3, 4]]]]), "library nested map reduce")
+
 # map_values transform
 j = Jrf.new(proc { map_values { |v| v * 10 } })
 assert_equal([{"a" => 10, "b" => 20}], j.call([{"a" => 1, "b" => 2}]), "library map_values transform")
 
+# nested map_values reduce binds to current target
+j = Jrf.new(proc { map_values { |obj| map_values { |v| sum(v) } } })
+assert_equal([{"a" => {"x" => 4, "y" => 6}, "b" => {"x" => 40, "y" => 60}}], j.call([{"a" => {"x" => 1, "y" => 2}, "b" => {"x" => 10, "y" => 20}}, {"a" => {"x" => 3, "y" => 4}, "b" => {"x" => 30, "y" => 40}}]), "library nested map_values reduce")
+
 # map hash transform
 j = Jrf.new(proc { map { |k, v| "#{k}=#{v}" } })
 assert_equal([["a=1", "b=2"]], j.call([{"a" => 1, "b" => 2}]), "library map hash transform")

metadata

@@ -1,13 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: jrf
 version: !ruby/object:Gem::Version
-  version: 0.1.9
+  version: 0.1.11
 platform: ruby
 authors:
 - kazuho
+autorequire: 
 bindir: exe
 cert_chain: []
-date: 1980-01-02 00:00:00.000000000 Z
+date: 2026-03-12 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: oj
@@ -33,7 +34,6 @@ executables:
 extensions: []
 extra_rdoc_files: []
 files:
-- DESIGN.txt
 - Gemfile
 - Rakefile
 - exe/jrf
@@ -49,9 +49,11 @@ files:
 - lib/jrf/stage.rb
 - lib/jrf/version.rb
 - test/jrf_test.rb
+homepage: 
 licenses:
 - MIT
 metadata: {}
+post_install_message: 
 rdoc_options: []
 require_paths:
 - lib
@@ -66,7 +68,8 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 4.0.3
+rubygems_version: 3.0.3.1
+signing_key: 
 specification_version: 4
 summary: JSON filter with the power and speed of Ruby
 test_files: []

data/DESIGN.txt

@@ -1,455 +0,0 @@
-NAME
-    jr - a small, lightweight NDJSON transformer with Ruby-like expressions
-
-OVERVIEW
-    jr is a command-line tool for transforming NDJSON using Ruby-like
-    expressions.
-
-    It is intentionally not a jq-compatible general-purpose JSON language.
-    Its value comes from a much narrower scope and from being implementable
-    in a very simple way.
-
-    The goal is to support expressions like:
-
-        jr '["foo"]'
-        jr 'select(/abc/.match(["aaa"])) >> ["foo"]'
-        jr '["items"] >> flat'
-        jr 'sum(["foo"])'
-        jr 'select(["x"] > 10) >> ["foo"] >> sum(["bar"])'
-
-    That is:
-
-    *   extract a value from each JSON line
-
-    *   filter lines by a predicate
-
-    *   flatten arrays into multiple output lines
-
-    *   aggregate values, such as summing them
-
-    This document is not just a user-facing description. It is a design
-    constraint document for implementors. The point is to preserve the
-    simplicity we agreed on, so that jr does not drift into a heavy
-    implementation.
-
-DESIGN PRINCIPLE
-    jr must be implemented in a way that keeps the runtime model extremely
-    simple.
-
-    The implementation must not drift into:
-
-    *   AST construction and optimization
-
-    *   wrapping child objects in DSL wrapper objects
-
-    *   a large generic streaming-stage framework
-
-    *   per-line allocation of many intermediate DSL objects
-
-    *   jq-like general stream semantics
-
-    Instead, jr should be implemented under the following constraints.
-
-CORE MODEL
-  Input model
-    Input is NDJSON.
-
-    Each line is parsed as one JSON value.
-
-    The primary execution model is line-by-line processing.
-
-    A simple conceptual loop is sufficient:
-
-        ARGF.each_line do |line|
-            row = JSON.parse(line)
-            ...
-        end
-
-  Evaluation context
-    Expressions are evaluated with the current row bound as "self".
-
-    That means the basic field access syntax is:
-
-        ["foo"]
-        ["foo"]["bar"]
-
-    No "_" or "_." prefix is required.
-
-  Root-only DSL
-    The DSL exists only at the root context.
-
-    This is a mandatory design rule.
-
-    The expression context object only needs to represent the current row.
-    Child values are not wrapped.
-
-  Return value of "[]"
-    "["foo"]" returns the underlying Ruby value directly.
-
-    That means:
-
-    *   Hash values remain Hash
-
-    *   Array values remain Array
-
-    *   String values remain String
-
-    *   Numeric values remain Numeric
-
-    *   "nil" remains "nil"
-
-    This is critical.
-
-    For example:
-
-        ["foo"]["bar"]
-
-    must work simply because "["foo"]" returned a normal Ruby "Hash", and
-    the next "["bar"]" is just Ruby's normal "Hash#[]".
-
-    Child wrappers must not exist.
-
-  Reuse of the root context
-    The root row context must be reused across all input lines.
-
-    A minimal model is:
-
-        class RowContext
-            def initialize(obj = nil)
-                @obj = obj
-            end
-
-            def reset(obj)
-                @obj = obj
-                self
-            end
-
-            def [](key)
-                @obj[key]
-            end
-        end
-
-    The per-line execution model should be conceptually as simple as:
-
-        ctx.reset(row)
-        ctx.instance_eval(expr_source)
-
-    The implementation should not allocate a new root DSL object for every
-    line.
-
-PIPELINE SYNTAX
-    Multiple stages are connected using top-level ">>".
-
-    Example:
-
-        jr 'select(["x"] > 10) >> ["foo"] >> sum(["bar"])'
-
-    This ">>" is not Ruby's shift operator in the execution model.
-
-    Instead, jr splits the top-level source string on top-level occurrences
-    of ">>" before evaluating the individual stage expressions as Ruby.
-
-    So the above is treated internally as three stages:
-
-        select(["x"] > 10)
-        ["foo"]
-        sum(["bar"])
-
-    This design choice is intentional and important.
-
-    It allows jr to have pipeline syntax without requiring a
-    delayed-expression DSL, operator overloading, or AST construction.
-
-  Consequence of reserving top-level ">>"
-    At top level, ">>" belongs to jr.
-
-    If users need Ruby's actual ">>" operator inside a stage expression,
-    they must use an alternative spelling such as "send(:">, ...)>, or some
-    other escape/alternative mechanism chosen by the implementation.
-
-    That tradeoff is acceptable because the primary value of jr is
-    simplicity.
-
-STAGE KINDS
-    Each pipeline segment is interpreted according to a small set of
-    explicit rules.
-
-    The stage kinds are:
-
-    *   "select(...)" - filter stage
-
-    *   plain expression - extract stage
-
-    *   "flat" - flatten stage
-
-    *   "sum(...)" - reduce/aggregate stage
-
-    These roles must remain separate. Their responsibilities must not be
-    mixed.
-
-  Filter stage
-    "select(...)" denotes a filter stage.
-
-    Examples:
-
-        select(["x"] > 10)
-        select(/abc/.match(["aaa"]))
-
-    A filter stage decides whether the current value passes to the next
-    stage.
-
-    It should not also act as an extractor.
-
-  Extract stage
-    Any stage expression that is not one of the explicit special forms is an
-    extract stage.
-
-    Examples:
-
-        ["foo"]
-        ["foo"]["bar"]
-        ["items"]
-
-    An extract stage computes a value from the current input and passes it
-    forward.
-
-    It should not also act as flattening or aggregation.
-
-  Flat stage
-    "flat" is a stage with no argument.
-
-    Example:
-
-        ["items"] >> flat
-
-    It means that the result of the previous stage should be expanded into
-    multiple output lines.
-
-    Without "flat", an array is emitted as one JSON array value.
-
-    With "flat", each element is emitted separately.
-
-    "flat" must not also be used as a filter or aggregator.
-
-  Reduce stage
-    "sum(...)" denotes an aggregate stage.
-
-    Examples:
-
-        sum(["foo"])
-        sum(["foo"]["bar"])
-
-    A reduce stage consumes values across all matching rows and emits one
-    final value at the end.
-
-    For the first implementation, "sum(...)" is sufficient as the only
-    required aggregate.
-
-IMPLEMENTATION DISCIPLINE
-    This section is the most important part of the document.
-
-    The implementation should stay close to the following simple execution
-    shapes.
-
-  Filter + extract only
-    Conceptually:
-
-        ctx = RowContext.new
-
-        ARGF.each_line do |line|
-            row = JSON.parse(line)
-            ctx.reset(row)
-
-            next unless ctx.instance_eval(filter_src)
-            out = ctx.instance_eval(extract_src)
-
-            emit(out)
-        end
-
-    This is the target level of simplicity.
-
-  Filter + extract + flat
-    Conceptually:
-
-        ctx = RowContext.new
-
-        ARGF.each_line do |line|
-            row = JSON.parse(line)
-            ctx.reset(row)
-
-            next unless ctx.instance_eval(filter_src)
-            out = ctx.instance_eval(extract_src)
-
-            if flat
-                out.each { |v| emit(v) }
-            else
-                emit(out)
-            end
-        end
-
-    Again, this is intentionally simple.
-
-  Filter + extract + sum
-    Conceptually:
-
-        ctx = RowContext.new
-        acc = 0
-
-        ARGF.each_line do |line|
-            row = JSON.parse(line)
-            ctx.reset(row)
-
-            next unless ctx.instance_eval(filter_src)
-            value = ctx.instance_eval(extract_src)
-
-            acc += value
-        end
-
-        emit(acc)
-
-    This is the intended model.
-
-    The implementation must not introduce a heavyweight generic framework
-    unless a clear need arises later.
-
-  Meaning of "sum(...)"
-    "sum(expr)" should be treated as syntactic sugar for:
-
-    *   evaluate "expr" for each matching input row
-
-    *   add the result to an accumulator
-
-    *   emit the accumulator once, at the end
-
-    The important thing is not the internal abstraction but preserving the
-    simple runtime shape.
-
-REQUIRED CONSTRAINTS
-    An implementation that follows this design must satisfy all of the
-    following.
-
-  1. NDJSON only
-    The initial implementation targets NDJSON line-by-line processing.
-
-    General stream semantics are out of scope.
-
-  2. Current row is "self"
-    Expressions run with the current row context bound as "self".
-
-  3. "["foo"]" is the primary field access syntax
-    This is the only required syntax for the first implementation.
-
-    Bareword sugar such as "foo" or dotted syntax such as "_.foo" is out of
-    scope.
-
-  4. "[]" returns raw Ruby values
-    No child wrapper objects are allowed.
-
-  5. Only one root context object is reused
-    A fresh DSL context object per row is not allowed.
-
-    The current row object inside the root context should simply be
-    replaced.
-
-  6. Pipeline parsing happens before Ruby evaluation
-    Top-level ">>" is split by jr itself before stage evaluation.
-
-    The implementation does not need to make ">>" work as a Ruby operator.
-
-  7. Stage responsibilities must stay separate
-    *   "select(...)" filters
-
-    *   plain expressions extract
-
-    *   "flat" flattens
-
-    *   "sum(...)" aggregates
-
-    Do not overload one stage kind with multiple semantics.
-
-  8. No "nil means skip" rule in extract
-    Skipping rows belongs to filtering.
-
-    Extract stages return values.
-
-    Do not make extract return-value conventions more complicated than
-    necessary.
-
-  9. No child DSL wrappers
-    This is worth repeating.
-
-    If a child value is a Hash, then further indexing is just normal Ruby
-    indexing. If a child value is an Array, then array access is just normal
-    Ruby array access.
-
-  10. Avoid heavyweight abstraction
-    Do not introduce any of the following in the first implementation unless
-    they are absolutely necessary:
-
-    *   AST nodes
-
-    *   delayed expression objects
-
-    *   generic stage graphs
-
-    *   EOF-marker-based general reducer pipelines
-
-    *   jq-style multi-valued stream semantics
-
-    *   child wrapper chains
-
-WHAT IS EXPLICITLY OUT OF SCOPE FOR NOW
-    The following are intentionally deferred.
-
-    *   jq compatibility
-
-    *   bareword field access such as "foo"
-
-    *   dotted field access such as "_.foo"
-
-    *   child wrappers
-
-    *   general reducer framework
-
-    *   EOF-marker stage propagation
-
-    *   general delayed-expression DSL
-
-    *   AST optimization
-
-    *   complicated "nil" output rules
-
-    *   advanced aggregate families beyond the initial "sum(...)"
-
-SUMMARY
-    jr is valuable only if it stays small and simple.
-
-    That means the implementation should follow these core rules:
-
-    *   NDJSON input, processed line by line
-
-    *   current row bound as "self"
-
-    *   field access through "["foo"]"
-
-    *   "[]" returns raw Ruby values
-
-    *   no child wrappers
-
-    *   one reusable root context object
-
-    *   top-level pipeline split on ">>"
-
-    *   "select(...)" for filter
-
-    *   plain expressions for extract
-
-    *   "flat" for flattening
-
-    *   "sum(...)" for aggregation
-
-    *   simple loops instead of heavyweight framework
-
-    If an implementation stops looking this simple, it has probably drifted
-    away from the intended design.
-