ice v2 data race

Started seeing a bunch of races detected now as well:
WARNING: DATA RACE
Read at 0x00c0000be298 by goroutine 14:
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredOffsets()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:46 +0x208
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredMetaAndUnCompressed()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:22 +0x64
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:197 +0xca
  github.com/blugelabs/ice/v2.mergeStoredAndRemapSegment()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:724 +0x36b
  github.com/blugelabs/ice/v2.mergeStoredAndRemap()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:674 +0xa07
  github.com/blugelabs/ice/v2.mergeToWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:130 +0x204
  github.com/blugelabs/ice/v2.mergeSegmentBasesWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:96 +0x157
  github.com/blugelabs/ice/v2.merge()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:85 +0x1d1
  github.com/blugelabs/ice/v2.(*Merger).WriteTo()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:48 +0x190
  github.com/blugelabs/bluge/index.(*FileSystemDirectory).Persist()
      /home/runner/work/bluge/bluge/index/directory_fs.go:125 +0x2d4
  github.com/blugelabs/bluge/index.(*Writer).merge()
      /home/runner/work/bluge/bluge/index/merge.go:368 +0x224
  github.com/blugelabs/bluge/index.(*Writer).executeMergeTask()
      /home/runner/work/bluge/bluge/index/merge.go:144 +0x86a
  github.com/blugelabs/bluge/index.(*Writer).planMergeAtSnapshot()
      /home/runner/work/bluge/bluge/index/merge.go:118 +0x474
  github.com/blugelabs/bluge/index.(*Writer).mergerLoop()
      /home/runner/work/bluge/bluge/index/merge.go:56 +0x4c4

Previous write at 0x00c0000be298 by goroutine 26:
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredOffsets()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:47 +0x30e
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredMetaAndUnCompressed()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:22 +0x64
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:197 +0xca
  github.com/blugelabs/ice/v2.(*Segment).VisitStoredFields()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:190 +0x104
  github.com/blugelabs/bluge/index.(*segmentSnapshot).VisitDocument()
      /home/runner/work/bluge/bluge/index/segment.go:61 +0x3d4
  github.com/blugelabs/bluge/index.(*Snapshot).VisitStoredFields()
      /home/runner/work/bluge/bluge/index/snapshot.go:307 +0x2a7
  github.com/blugelabs/bluge/search.(*DocumentMatch).VisitStoredFields()
      /home/runner/work/bluge/bluge/search/search.go:134 +0x38e
  github.com/blugelabs/bluge/test.collectHits()
      /home/runner/work/bluge/bluge/test/integration_test.go:46 +0x2ae
  github.com/blugelabs/bluge/test.TestIntegration.func1()
      /home/runner/work/bluge/bluge/test/integration_test.go:150 +0x364
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 14 (running) created at:
  github.com/blugelabs/bluge/index.OpenWriter()
      /home/runner/work/bluge/bluge/index/writer.go:131 +0xf8d
  github.com/blugelabs/bluge.OpenWriter()
      /home/runner/work/bluge/bluge/writer.go:36 +0x137
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:127 +0x784
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 26 (finished) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1168 +0x5bb
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:141 +0x207
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202
==================
==================
WARNING: DATA RACE
Write at 0x00c0007b8000 by goroutine 14:
  runtime.slicecopy()
      /opt/hostedtoolcache/go/1.15.15/x64/src/runtime/slice.go:246 +0x0
  github.com/klauspost/compress/zstd.(*blockDec).decodeCompressed()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:494 +0x207
  github.com/klauspost/compress/zstd.(*blockDec).decodeBuf()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:262 +0x98e
  github.com/klauspost/compress/zstd.(*frameDec).runDecoder()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/framedec.go:351 +0x22a
  github.com/klauspost/compress/zstd.(*Decoder).DecodeAll()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/decoder.go:378 +0x368
  github.com/blugelabs/ice/v2.ZSTDDecompress()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/zstd.go:44 +0xce
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredOffsets()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:47 +0x2bc
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredMetaAndUnCompressed()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:22 +0x64
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:197 +0xca
  github.com/blugelabs/ice/v2.mergeStoredAndRemapSegment()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:724 +0x36b
  github.com/blugelabs/ice/v2.mergeStoredAndRemap()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:674 +0xa07
  github.com/blugelabs/ice/v2.mergeToWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:130 +0x204
  github.com/blugelabs/ice/v2.mergeSegmentBasesWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:96 +0x157
  github.com/blugelabs/ice/v2.merge()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:85 +0x1d1
  github.com/blugelabs/ice/v2.(*Merger).WriteTo()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:48 +0x190
  github.com/blugelabs/bluge/index.(*FileSystemDirectory).Persist()
      /home/runner/work/bluge/bluge/index/directory_fs.go:125 +0x2d4
  github.com/blugelabs/bluge/index.(*Writer).merge()
      /home/runner/work/bluge/bluge/index/merge.go:368 +0x224
  github.com/blugelabs/bluge/index.(*Writer).executeMergeTask()
      /home/runner/work/bluge/bluge/index/merge.go:144 +0x86a
  github.com/blugelabs/bluge/index.(*Writer).planMergeAtSnapshot()
      /home/runner/work/bluge/bluge/index/merge.go:118 +0x474
  github.com/blugelabs/bluge/index.(*Writer).mergerLoop()
      /home/runner/work/bluge/bluge/index/merge.go:56 +0x4c4

Previous read at 0x00c0007b8007 by goroutine 26:
  bytes.(*Reader).ReadByte()
      /opt/hostedtoolcache/go/1.15.15/x64/src/bytes/reader.go:72 +0xe9
  encoding/binary.ReadUvarint()
      /opt/hostedtoolcache/go/1.15.15/x64/src/encoding/binary/varint.go:110 +0x92
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:217 +0x324
  github.com/blugelabs/ice/v2.(*Segment).VisitStoredFields()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:190 +0x104
  github.com/blugelabs/bluge/index.(*segmentSnapshot).VisitDocument()
      /home/runner/work/bluge/bluge/index/segment.go:61 +0x3d4
  github.com/blugelabs/bluge/index.(*Snapshot).VisitStoredFields()
      /home/runner/work/bluge/bluge/index/snapshot.go:307 +0x2a7
  github.com/blugelabs/bluge/search.(*DocumentMatch).VisitStoredFields()
      /home/runner/work/bluge/bluge/search/search.go:134 +0x38e
  github.com/blugelabs/bluge/test.collectHits()
      /home/runner/work/bluge/bluge/test/integration_test.go:46 +0x2ae
  github.com/blugelabs/bluge/test.TestIntegration.func1()
      /home/runner/work/bluge/bluge/test/integration_test.go:150 +0x364
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 14 (running) created at:
  github.com/blugelabs/bluge/index.OpenWriter()
      /home/runner/work/bluge/bluge/index/writer.go:131 +0xf8d
  github.com/blugelabs/bluge.OpenWriter()
      /home/runner/work/bluge/bluge/writer.go:36 +0x137
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:127 +0x784
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 26 (finished) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1168 +0x5bb
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:141 +0x207
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202
==================
==================
WARNING: DATA RACE
Write at 0x00c0007b8010 by goroutine 14:
  runtime.slicecopy()
      /opt/hostedtoolcache/go/1.15.15/x64/src/runtime/slice.go:246 +0x0
  github.com/klauspost/compress/zstd.(*blockDec).decodeCompressed()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:494 +0x207
  github.com/klauspost/compress/zstd.(*blockDec).decodeBuf()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:262 +0x98e
  github.com/klauspost/compress/zstd.(*frameDec).runDecoder()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/framedec.go:351 +0x22a
  github.com/klauspost/compress/zstd.(*Decoder).DecodeAll()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/decoder.go:378 +0x368
  github.com/blugelabs/ice/v2.ZSTDDecompress()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/zstd.go:44 +0xce
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredOffsets()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:47 +0x2bc
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredMetaAndUnCompressed()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:22 +0x64
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:197 +0xca
  github.com/blugelabs/ice/v2.mergeStoredAndRemapSegment()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:724 +0x36b
  github.com/blugelabs/ice/v2.mergeStoredAndRemap()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:674 +0xa07
  github.com/blugelabs/ice/v2.mergeToWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:130 +0x204
  github.com/blugelabs/ice/v2.mergeSegmentBasesWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:96 +0x157
  github.com/blugelabs/ice/v2.merge()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:85 +0x1d1
  github.com/blugelabs/ice/v2.(*Merger).WriteTo()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:48 +0x190
  github.com/blugelabs/bluge/index.(*FileSystemDirectory).Persist()
      /home/runner/work/bluge/bluge/index/directory_fs.go:125 +0x2d4
  github.com/blugelabs/bluge/index.(*Writer).merge()
      /home/runner/work/bluge/bluge/index/merge.go:368 +0x224
  github.com/blugelabs/bluge/index.(*Writer).executeMergeTask()
      /home/runner/work/bluge/bluge/index/merge.go:144 +0x86a
  github.com/blugelabs/bluge/index.(*Writer).planMergeAtSnapshot()
      /home/runner/work/bluge/bluge/index/merge.go:118 +0x474
  github.com/blugelabs/bluge/index.(*Writer).mergerLoop()
      /home/runner/work/bluge/bluge/index/merge.go:56 +0x4c4

Previous write at 0x00c0007b8010 by goroutine 26:
  runtime.slicecopy()
      /opt/hostedtoolcache/go/1.15.15/x64/src/runtime/slice.go:246 +0x0
  github.com/klauspost/compress/zstd.(*blockDec).decodeCompressed()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:494 +0x207
  github.com/klauspost/compress/zstd.(*blockDec).decodeBuf()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:262 +0x98e
  github.com/klauspost/compress/zstd.(*frameDec).runDecoder()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/framedec.go:351 +0x22a
  github.com/klauspost/compress/zstd.(*Decoder).DecodeAll()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/decoder.go:378 +0x368
  github.com/blugelabs/ice/v2.ZSTDDecompress()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/zstd.go:44 +0xce
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredOffsets()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:47 +0x2bc
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredMetaAndUnCompressed()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:22 +0x64
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:197 +0xca
  github.com/blugelabs/ice/v2.(*Segment).VisitStoredFields()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:190 +0x104
  github.com/blugelabs/bluge/index.(*segmentSnapshot).VisitDocument()
      /home/runner/work/bluge/bluge/index/segment.go:61 +0x3d4
  github.com/blugelabs/bluge/index.(*Snapshot).VisitStoredFields()
      /home/runner/work/bluge/bluge/index/snapshot.go:307 +0x2a7
  github.com/blugelabs/bluge/search.(*DocumentMatch).VisitStoredFields()
      /home/runner/work/bluge/bluge/search/search.go:134 +0x38e
  github.com/blugelabs/bluge/test.collectHits()
      /home/runner/work/bluge/bluge/test/integration_test.go:46 +0x2ae
  github.com/blugelabs/bluge/test.TestIntegration.func1()
      /home/runner/work/bluge/bluge/test/integration_test.go:150 +0x364
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 14 (running) created at:
  github.com/blugelabs/bluge/index.OpenWriter()
      /home/runner/work/bluge/bluge/index/writer.go:131 +0xf8d
  github.com/blugelabs/bluge.OpenWriter()
      /home/runner/work/bluge/bluge/writer.go:36 +0x137
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:127 +0x784
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 26 (finished) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1168 +0x5bb
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:141 +0x207
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202
==================
==================
WARNING: DATA RACE
Write at 0x00c0007b8020 by goroutine 14:
  runtime.slicecopy()
      /opt/hostedtoolcache/go/1.15.15/x64/src/runtime/slice.go:246 +0x0
  github.com/klauspost/compress/zstd.(*blockDec).decodeCompressed()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:494 +0x207
  github.com/klauspost/compress/zstd.(*blockDec).decodeBuf()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:262 +0x98e
  github.com/klauspost/compress/zstd.(*frameDec).runDecoder()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/framedec.go:351 +0x22a
  github.com/klauspost/compress/zstd.(*Decoder).DecodeAll()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/decoder.go:378 +0x368
  github.com/blugelabs/ice/v2.ZSTDDecompress()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/zstd.go:44 +0xce
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredOffsets()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:47 +0x2bc
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredMetaAndUnCompressed()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:22 +0x64
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:197 +0xca
  github.com/blugelabs/ice/v2.mergeStoredAndRemapSegment()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:724 +0x36b
  github.com/blugelabs/ice/v2.mergeStoredAndRemap()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:674 +0xa07
  github.com/blugelabs/ice/v2.mergeToWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:130 +0x204
  github.com/blugelabs/ice/v2.mergeSegmentBasesWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:96 +0x157
  github.com/blugelabs/ice/v2.merge()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:85 +0x1d1
  github.com/blugelabs/ice/v2.(*Merger).WriteTo()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:48 +0x190
  github.com/blugelabs/bluge/index.(*FileSystemDirectory).Persist()
      /home/runner/work/bluge/bluge/index/directory_fs.go:125 +0x2d4
  github.com/blugelabs/bluge/index.(*Writer).merge()
      /home/runner/work/bluge/bluge/index/merge.go:368 +0x224
  github.com/blugelabs/bluge/index.(*Writer).executeMergeTask()
      /home/runner/work/bluge/bluge/index/merge.go:144 +0x86a
  github.com/blugelabs/bluge/index.(*Writer).planMergeAtSnapshot()
      /home/runner/work/bluge/bluge/index/merge.go:118 +0x474
  github.com/blugelabs/bluge/index.(*Writer).mergerLoop()
      /home/runner/work/bluge/bluge/index/merge.go:56 +0x4c4

Previous read at 0x00c0007b8026 by goroutine 26:
  runtime.slicecopy()
      /opt/hostedtoolcache/go/1.15.15/x64/src/runtime/slice.go:246 +0x0
  github.com/blugelabs/bluge/test.collectHits.func1()
      /home/runner/work/bluge/bluge/test/integration_test.go:48 +0xb8
  github.com/blugelabs/bluge/index.(*Snapshot).VisitStoredFields.func1()
      /home/runner/work/bluge/bluge/index/snapshot.go:308 +0x72
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:223 +0x242
  github.com/blugelabs/ice/v2.(*Segment).VisitStoredFields()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:190 +0x104
  github.com/blugelabs/bluge/index.(*segmentSnapshot).VisitDocument()
      /home/runner/work/bluge/bluge/index/segment.go:61 +0x3d4
  github.com/blugelabs/bluge/index.(*Snapshot).VisitStoredFields()
      /home/runner/work/bluge/bluge/index/snapshot.go:307 +0x2a7
  github.com/blugelabs/bluge/search.(*DocumentMatch).VisitStoredFields()
      /home/runner/work/bluge/bluge/search/search.go:134 +0x38e
  github.com/blugelabs/bluge/test.collectHits()
      /home/runner/work/bluge/bluge/test/integration_test.go:46 +0x2ae
  github.com/blugelabs/bluge/test.TestIntegration.func1()
      /home/runner/work/bluge/bluge/test/integration_test.go:150 +0x364
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 14 (running) created at:
  github.com/blugelabs/bluge/index.OpenWriter()
      /home/runner/work/bluge/bluge/index/writer.go:131 +0xf8d
  github.com/blugelabs/bluge.OpenWriter()
      /home/runner/work/bluge/bluge/writer.go:36 +0x137
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:127 +0x784
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 26 (finished) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1168 +0x5bb
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:141 +0x207
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202
==================
==================
WARNING: DATA RACE
Write at 0x00c0007b8030 by goroutine 14:
  runtime.slicecopy()
      /opt/hostedtoolcache/go/1.15.15/x64/src/runtime/slice.go:246 +0x0
  github.com/klauspost/compress/zstd.(*blockDec).decodeCompressed()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:494 +0x207
  github.com/klauspost/compress/zstd.(*blockDec).decodeBuf()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/blockdec.go:262 +0x98e
  github.com/klauspost/compress/zstd.(*frameDec).runDecoder()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/framedec.go:351 +0x22a
  github.com/klauspost/compress/zstd.(*Decoder).DecodeAll()
      /home/runner/go/pkg/mod/github.com/klauspost/compress@v1.15.2/zstd/decoder.go:378 +0x368
  github.com/blugelabs/ice/v2.ZSTDDecompress()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/zstd.go:44 +0xce
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredOffsets()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:47 +0x2bc
  github.com/blugelabs/ice/v2.(*Segment).getDocStoredMetaAndUnCompressed()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/read.go:22 +0x64
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:197 +0xca
  github.com/blugelabs/ice/v2.mergeStoredAndRemapSegment()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:724 +0x36b
  github.com/blugelabs/ice/v2.mergeStoredAndRemap()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:674 +0xa07
  github.com/blugelabs/ice/v2.mergeToWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:130 +0x204
  github.com/blugelabs/ice/v2.mergeSegmentBasesWriter()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:96 +0x157
  github.com/blugelabs/ice/v2.merge()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:85 +0x1d1
  github.com/blugelabs/ice/v2.(*Merger).WriteTo()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/merge.go:48 +0x190
  github.com/blugelabs/bluge/index.(*FileSystemDirectory).Persist()
      /home/runner/work/bluge/bluge/index/directory_fs.go:125 +0x2d4
  github.com/blugelabs/bluge/index.(*Writer).merge()
      /home/runner/work/bluge/bluge/index/merge.go:368 +0x224
  github.com/blugelabs/bluge/index.(*Writer).executeMergeTask()
      /home/runner/work/bluge/bluge/index/merge.go:144 +0x86a
  github.com/blugelabs/bluge/index.(*Writer).planMergeAtSnapshot()
      /home/runner/work/bluge/bluge/index/merge.go:118 +0x474
  github.com/blugelabs/bluge/index.(*Writer).mergerLoop()
      /home/runner/work/bluge/bluge/index/merge.go:56 +0x4c4

Previous read at 0x00c0007b8033 by goroutine 26:
  bytes.(*Reader).ReadByte()
      /opt/hostedtoolcache/go/1.15.15/x64/src/bytes/reader.go:72 +0xe9
  encoding/binary.ReadUvarint()
      /opt/hostedtoolcache/go/1.15.15/x64/src/encoding/binary/varint.go:110 +0x92
  github.com/blugelabs/ice/v2.(*Segment).visitDocument()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:213 +0x2e5
  github.com/blugelabs/ice/v2.(*Segment).VisitStoredFields()
      /home/runner/go/pkg/mod/github.com/blugelabs/ice/v2@v2.0.1/segment.go:190 +0x104
  github.com/blugelabs/bluge/index.(*segmentSnapshot).VisitDocument()
      /home/runner/work/bluge/bluge/index/segment.go:61 +0x3d4
  github.com/blugelabs/bluge/index.(*Snapshot).VisitStoredFields()
      /home/runner/work/bluge/bluge/index/snapshot.go:307 +0x2a7
  github.com/blugelabs/bluge/search.(*DocumentMatch).VisitStoredFields()
      /home/runner/work/bluge/bluge/search/search.go:134 +0x38e
  github.com/blugelabs/bluge/test.collectHits()
      /home/runner/work/bluge/bluge/test/integration_test.go:46 +0x2ae
  github.com/blugelabs/bluge/test.TestIntegration.func1()
      /home/runner/work/bluge/bluge/test/integration_test.go:150 +0x364
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 14 (running) created at:
  github.com/blugelabs/bluge/index.OpenWriter()
      /home/runner/work/bluge/bluge/index/writer.go:131 +0xf8d
  github.com/blugelabs/bluge.OpenWriter()
      /home/runner/work/bluge/bluge/writer.go:36 +0x137
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:127 +0x784
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202

Goroutine 26 (finished) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1168 +0x5bb
  github.com/blugelabs/bluge/test.TestIntegration()
      /home/runner/work/bluge/bluge/test/integration_test.go:141 +0x207
  testing.tRunner()
      /opt/hostedtoolcache/go/1.15.15/x64/src/testing/testing.go:1123 +0x202
==================
--- FAIL: TestIntegration (3.05s)
Error:     integration_test.go:117: testdir: /tmp/bluge-integration-test-basic405355639
    --- FAIL: TestIntegration/basic-test_numeric_range,_upper_and_lower_bounds (0.00s)
Error:         testing.go:1038: race detected during execution of test
Error:     integration_test.go:117: testdir: /tmp/bluge-integration-test-sort966111594
Error:     integration_test.go:117: testdir: /tmp/bluge-integration-test-fosdem554906049
Error:     integration_test.go:117: testdir: /tmp/bluge-integration-test-geo813274668
Error:     integration_test.go:117: testdir: /tmp/bluge-integration-test-phrase008033179
Error:     integration_test.go:117: testdir: /tmp/bluge-integration-test-aggregations042487358
Error:     testing.go:1038: race detected during execution of test
FAIL
FAIL	github.com/blugelabs/bluge/test	3.118s
FAIL
Error: Process completed with exit code 1.

@hengfeiyang I think the issue is that Segments are shared, so when you mutate storedFieldChunkUncompressed we have potential data races:
https://github.com/blugelabs/ice/blob/d830a812e60591ce0955fdeabd483f0ebf537ebd/read.go#L46-L47
If we must do it this way, you'll have to protect access to it with a mutex, like the fieldFSTs:
https://github.com/blugelabs/ice/blob/master/segment.go#L52-L53
Alternatively I wonder, can't we arrange this so that we decompress once, and then just reuse it?  I'm not sure exactly how that code looks to be safe from races, but it doesn't make sense that we'd ever intentionally decompress the same compressed bytes again right?

Seems like there are 2 choices:

uncompress at open (wasteful if never match documents in this segment), but can avoid a lock.
uncompress on first use, needs a lock (possibly too much overhead, because we always need to load _id for matches)

Oh I see, it's actually a bigger problem.  You only uncompress one chunk at a time, so the contents of that buffer actually changes depending on what documents you try to access.
In that case I think we can't cache/reuse the buffer inside the segment.  They are intended to be heavily shared (you could have a hundred queries all hitting that segment at one time), so I don't think it makes sense to share that buffer and coordinate access with a lock.
And that makes it seem like the current API isn't going to work very well with the stored docs compressed in chunks.  I believe that was the reason we compressed docs individually in the past, even though it results in much lower compression.  So, I think if you want to go with this storage format, you should also propose an API to access it efficiently.

I prototyped one idea here: https://github.com/blugelabs/ice/pull/15  But I don't love it.

You implement plan 1.
I think plan 2 will be better, it doesn't need cache all uncompressed data at open, a RWMutex will be better. even though we need to load _id, but we don't need visit all documents at query time.


Don't put OUTDATED translations at the end

Motivation

Why do you want this feature? Ex: I'm always frustrated when [...]

Putting OUTDATED translations at the end results in messy hard-to-read git diffs.
For example, see https://github.com/adil192/saber/commit/eed1be52641f3f69c04689ac903404c4ff2fe9e8. Only two strings were actually changed, but it's very hard to see that just from looking at the diff:

Developer Experience

How should devs use this new feature? Ex: There should be a new parameter called [...]

There should be no change in usage

I cannot reproduce this. It replaces entries in place and skips not existent keys on my examples

skips not existent keys

Are you referring to missing keys or (OUTDATED) keys?

The outdated keys

Hmmm... maybe it only affects yaml?

Turns out it's not the OUTDATED flag that's the problem.
Running e.g. dart run slang edit add fr greetings.hello "Bonjour" always puts the new translation at the end rather than in the order of the base locale.


i added my program about BruteForceDivideConquer

please accept my pull request

You know this counts as only 1 PR

You know this counts as only 1 PR

yes it's okay sir please agree to my pull request to join this hacktoberfest event

ok

Do give a star to my repo.

thank you sir for your repo I have given a star

thank you


Navigation of PR previews not working

The link that is posted on a PR is just working for the index page, if you try to navigate to any other page, a leading slash before the PR number breaks it all (~XXX)
Steps to reproduce:

Go to https://widgetbook.docs.page/widgetbook~1275 (from this comment).

Try to navigate to any page.

Notice the slash in the URL:
# Expected
https://widgetbook.docs.page/widgetbook~1275/guides/quick-start

# Actual (has slash between widgetbook and PR number)
https://widgetbook.docs.page/widgetbook/~1275/guides/quick-start

This is fixed - custom domains are working again and there was some URL building logic which needed modifying to correct this scenario. Thanks for flagging!


First Release - 2.0.0.dev2

This is the first release of Alpyca, so it is guaranteed to have 'issues'.  This list is where you can file issues and suggest patches.
Please don't ask programming questions here. Instead post to the ASCOM Driver and Application Development Support Forum.  Thanks.

Hi @BobDenny ! I've been following the alpaca+python movement for a bit since I want to implement the use of python for a remote survey observatory soon. I'd recommend using a release tag to mark the release to avoid having an unnecessary open issue. (I hope to be able to contribute as well!)
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

The first (-devx) versions are pre-releases. I am about to release the first real version 2.0.1rc1 and it will be listed here as a release.  Thank you!!


Added graphql-sse in Subscriptions docs

Added graphql-sse in Subscriptions docs

Hey @FlymeDllVa - mind opening this against the next branch? the API for subscription support changes pretty drastically but you should be able to adapt what you have pretty easily. Lemme know if you need any guidance


Policy may apply to pod without any labels (DoesNotExist operator).

It fixes test_match_expressions from https://wwwin-github.cisco.com/CPSG/k8s-systest/pull/85

Coverage increased (+0.09%) to 76.54% when pulling 12546ba52ed93601745b8171b32f32ab513a794f on milanlenco:master into d62fabb3082c22e8094e6a85831399fb1683df51 on contiv:master.


Possible crash with node.js v16.13.1+

Ref: https://github.com/lvgl/lv_font_conv/issues/68
Font: OPPOSans_OS_Medium.zip
Seems node.js v16.13.1 introduced regression/restriction, causing convertor crash. Or wasm build outdated too much.
node -v
# => v16.13.1

git clone git@github.com:lvgl/lv_font_conv.git
cd lv_font_conv
npm i

./lv_font_conv.js --font OPPOSans_OS_Medium.ttf -r 0x20-0x2c63 --size 32 --format bin --bpp 4 --no-compress -o sans32.font
#RangeError: Maximum call stack size exceeded
#    at Math.max (<anonymous>)
#    at new Font (/home/vitaly/Загрузки/lv_font_conv/lib/font/font.js:38:27)
#    at Object.write_images [as bin] (/home/vitaly/Загрузки/lv_font_conv/lib/writers/bin.js:12:16)
#    at convert (/home/vitaly/Загрузки/lv_font_conv/lib/convert.js:25:35)
#    at async Object.module.exports.run (/home/vitaly/Загрузки/lv_font_conv/lib/cli.js:300:15)

Temporary workaround
Install node.js v16.13.0

Ref: #68
Font: OPPOSans_OS_Medium.zip
Seems node.js v16.13.1 introduced regression/restriction, causing convertor crash. Or wasm build outdated too much.
node -v
# => v16.13.1

git clone git@github.com:lvgl/lv_font_conv.git
cd lv_font_conv
npm i

./lv_font_conv.js --font OPPOSans_OS_Medium.ttf -r 0x20-0x2c63 --size 32 --format bin --bpp 4 --no-compress -o sans32.font
#RangeError: Maximum call stack size exceeded
#    at Math.max (<anonymous>)
#    at new Font (/home/vitaly/Загрузки/lv_font_conv/lib/font/font.js:38:27)
#    at Object.write_images [as bin] (/home/vitaly/Загрузки/lv_font_conv/lib/writers/bin.js:12:16)
#    at convert (/home/vitaly/Загрузки/lv_font_conv/lib/convert.js:25:35)
#    at async Object.module.exports.run (/home/vitaly/Загрузки/lv_font_conv/lib/cli.js:300:15)

Temporary workaround
Install node.js v16.13.0

node.js v16.13.0 is the same problem.

Thank you for info. v16.3.0 works in my case (Ubuntu).
Try latest v14 then, as workaround.

Thank you for info. v16.3.0 works in my case (Ubuntu).
Try latest v14 then, as workaround.

node.js v14 is the same problem.

Thank you for help with localizing problem. I will continue investigation in nearest days. First, we will update wasm build with new compiler, and then will recheck again.

Excuse me, how is it going?

Very busy at this moment. But i marked this bug with high priority, will take a look at the begining of next week.

Hello,how is it going?

Still very busy, sorry. We rolled out very big software update on production site, and still fixing a lot of urgent issues.

I've updated emcc, freetype and did fresh rebuild (see commits). Seems problem is specific to your concrete file only. Other fonts work without problems.
In any case - open/save font via FontForge before reporting problem.
Attached font after FF, seems to work.
OPPOSans_OS_Medium_1.4.ttf.zip
.


"Downer" doesn't work on hacker news

For example, go to https://news.ycombinator.com/item?id=35640002 and say "downer", and it scrolls down crazy far. This is the only site I've seen this behaviour so far.

I see, there's an issue with the way I calculate the viewport dimensions. I need to fix that. Probably the same reason scrolling is sometimes janky in slack. Thanks for the issue, I'll fix it soon


up do date device list

I think the device list is probably a bit outdated unfortunately. E.g. I can't find a newer iPhone than v6 or Samsung Galaxy S10/20 etc.
Also an iPad Pro 10.5" or 12.9" would be great to have.
Could you add that?
Best thanks for your work and the otherwise super extension! :-)

I second this!


Chrome support

As a Chrome user, I want to be able to run "de Joa" on Chrome.
This includes all Chrome.
Reaching from Chrome to extension.

It says it is completed but why can't I find it on the webstore? https://chrome.google.com/webstore/search/joa


How to render GitLab's  "!reference [some, rule]" line with ytt

Hello,
I am struggling with the ytt and advanced use of GitLab's  child-parent pipelines.
I want to use !reference tag feature in the child pipeline, that will be generated by the ytt.
Let's go into the playground - https://carvel.dev/ytt/#example:example-plain-yaml:
When I define the following simple YAML file:
rules:
  some_rule:
    - if: "$CI_COMMIT_TAG"

some_node:
  - !reference [rules, some_rule]

The ytt ignores the !reference and renders the expression behind it as an array:
rules:
  some_rule:
  - if: $CI_COMMIT_TAG
some_node:
- - rules
  - some_rule

Now, how can I achieve that ytt will render the following yaml file:
rules:
  some_rule:
  - if: $CI_COMMIT_TAG
some_node:
- !reference [rules, some_rule]

?
I have tried following but all yields unsatisfactory results:
- !!reference [rules, some_rule]   # no change
- \!reference [rules, some_rule]   # - \!reference [rules, some_rule] -> invalid syntax for GitLab CI
- #@ "!reference [rules, some_rule]"  #  - '!reference [rules, some_rule]'  -> not wanted - it is a string and not a !reference node
- "!reference [rules, some_rule]"        #   - '!reference [rules, some_rule]'  -> not wanted - it is a string and not a !reference node

Is even what I want achievable with ytt?
This simple example doesn't contain anything to the ytt, since it would be irrelevant to this example, but I can post my it if needed.
Thanks for the help.
Regards,
Andrej

After reading the YAML specification for tags, I understand that:

!reference is denoting a special tag created by GitLab (https://gitlab.com/gitlab-org/gitlab/-/issues/266173)
since ytt is rendering it and doesn't know anything about types, it is just ignoring it and displaying it as an array

I am thinking about the two following workarounds directly with ytt:

Turn off ytt for a single line, e.g.

some_node:
- !reference [rules, some_rule] #@ some_command_to_say_keep_this_line_unattached

Have a function, that can return a string without quotation marks:

some_node:
- #@ return_str_without_quots("!reference [rules, some_rule]")

Or is there another way how to achieve my goal with ytt?
I am now running sed  to remove these single quotes, but that is a really hacky solution.

Hello @astaruch.
TL;DR. ytt does not (currently) emit tags in its output.
Yeah, that there is a YAML tag... as you noted, it's parsed and processed by ytt as such. This is because ytt operates from within the YAML structure. In fact, first step — before any processing occurs — ytt delegates parsing the YAML to the de facto standard Go YAML parser.
On the output side, ytt currently does not include tag information when handing off to the same YAML library to marshal the result.
...
In case you're not tied to the !reference mechanism, I believe you can achieve the same re-use if the referenced/referencing fragments were part of your ytt templating...
From https://gitlab.com/gitlab-org/gitlab/-/issues/266173:
# Content of setup.yml
.setup:
  script:
    - echo creating environment1
    - echo creating environment2

# Content of teardown.yml
.teardown:
  script:
    - echo deleting environment1
    - echo deleting environment2

# .gitlab-ci.yml
include:
    local: setup.yml
    local: teardown.yml

test:
  script:
    - !reference [.setup, script] # or any other name that would allow us to "include in this context some other value"
    - echo running my own command
    - !reference [.teardown, script]

You could extract those fragments and included them in ytt as a .lib.yaml file:
#! Content of helpers.lib.yaml
---
#@ def setup():
- echo creating environment1
- echo creating environment2
#@ end
---
#@ def teardown():
- echo deleting environment1
- echo deleting environment2
#@ end

#! .gitlab-ci.yml
#@ load("@ytt:template", "template")
#@ load("helpers.lib.yaml", "setup", "teardown")

test:
  script:
    - #@ template.replace(setup())
    - echo running my own command
    - #@ template.replace(teardown())

(in ytt playground)
Any reason that might not work for your situation?

It's been a minute. Closing for now. @astaruch, if you'd still like support with this issue, feel free to comment on it, we'll get notified. 👍🏻

I ended up using sed too.  To simplify the process and tell YTT not to quote the value, write it as \! reference [...].  Then the cleanup is easier to read--sed -i 's/\\!reference/!reference/g'  FILE_NAME.


require CUDA 11.7+

Quokka requires CUDA 11.7 or newer to avoid compiler bugs that exist in all previous versions of CUDA. This prevents users from encountering these bugs by checking the CUDA version during the CMake configure step.

/azp run


odap dummy implementation

Just want to know how cactus resolve this issue
How to reproduce:

Build the project
npx tap --timeout=600 packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts
Show error message:

packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2> node:internal/process/esm_loader:74
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>     internalBinding('errors').triggerUncaughtException(
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>                               ^
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2> TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /Users/jasonwang/cactusodap/packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>     at new NodeError (node:internal/errors:329:5)
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>     at Loader.defaultGetFormat [as _getFormat] (node:internal/modules/esm/get_format:71:15)
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>     at Loader.getFormat (node:internal/modules/esm/loader:102:42)
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>     at Loader.getModuleJob (node:internal/modules/esm/loader:231:31)
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>     at async Loader.import (node:internal/modules/esm/loader:165:17)
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>     at async Object.loadESM (node:internal/process/esm_loader:68:5) {
packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts 2>   code: 'ERR_UNKNOWN_FILE_EXTENSION'

@petermetz

@jscode017 Should work if you add the --ts flag
npx tap --ts --timeout=600 packages/cactus-odap/src/test/typescript/integrate/odap/transfer-initiation-test.ts

Our documentation needs to be updated because this was a breaking change in the tap test runner recently.

@jscode017 Also note: It's okay to just send a link to a branch of yours, no need to go through the hassle of opening a PR at the same time unless you actually want to open a PR

@jscode017 Also note: It's okay to just send a link to a branch of yours, no need to go through the hassle of opening a PR at the same time unless you actually want to open a PR

Sure, would do it next time. Thanks for the help.


Show full VIN in dashboards when no car-name set at all

          Hi everyone,

I had previously opened this pull request, for cases of unnamed vehicles

https://github.com/teslamate-org/teslamate/pull/4198

Looks like the behavior changed in this pull request
From:

To:

In my opinion, displaying a bunch of numbers with no context isn't too great.
Would you be opposed if I opened a new pull request to change back the case of unnamed vehicles to VIN $full_vin?
In summary:

Uniquely named vehicles: $Name
Duplicate named vehicles: $Name - $Last_six_of_vin
Unnamed vehicles: VIN $Full_vin

c.c. @swiffer , @JakobLichterfeld , @edgararroyo
Originally posted by @arcastro in https://github.com/teslamate-org/teslamate/issues/4230#issuecomment-2453862453

Thank you both @swiffer  and @JakobLichterfeld 👍👍


smart contract testing

Discussion

Some input on how to test plutus contracts using a ContractModel. That is, use a QuickCheck model to automatically generate test cases for your plutus contract.

https://plutus-apps.readthedocs.io/en/latest/plutus/tutorials/contract-testing.html
https://plutus-apps.readthedocs.io/en/latest/plutus/tutorials/contract-models.html

Note that you do not necessary need to use the contract monad in plutus-apps, even though the tutorials do use this for their testing approach. Just ping Quviq if you want to get automatic test case generation in a different setting.

Sujeetha, R, and C. A. S Deiva Preetha. “A Literature Survey on Smart Contract Testing and Analysis for Smart Contract Based Blockchain Application Development.” In 2021 2nd International Conference on Smart Electronics and Communication (ICOSEC), 378–85. Trichy, India: IEEE, 2021. https://doi.org/10.1109/ICOSEC51865.2021.9591750.

init

Plutus comes with a library for testing contracts using QuickCheck.

https://github.com/aleeusgr/plutus-tests


Tickets blinking when cursor is on top of multiple tickets.

Mikä selain ?

I'm not sure if this is related to some z-index shenanigans? Maybe the ticket we bring forth doesn't have it's z-index set as high as it should be.

closed now
Client versio	v1.2.118
API versio	v0.4.42
IMG versio	v0.1.10


Support for UTF8 characters when creating wildcard query

Released on v6.22.8 🚀
BTW your PR is on master branch so I decided to copy paste the changes on 6.0 branch. Thanks!


MetSys restart failed on basically clean project

I just went to the asset store and downloaded the latest version into my barebone project, which consists of nothing but a Player with FSM and a tilemap.
I am using Godot 4.2.1 and I do not see how I can have naming conflicts.

What errors appear in MetroidvaniaSystem.gd?

When I try to set the checkmark in the Project Settings > Plugins tab, it will automatically close the IDE, reopen it and show the error popup from my original post.

I just tried installing in an empty project and it works after restart. I excluded the SampleProject though.
Try removing .godot folder maybe.

So it was unrelated to MetSys.
When you install or create an addon, the addons folder is created automatically. It's better to use that than to create it yourself.


No location reported for type error in patterns

The following (erroneous) code
splitAt : Int -> [a] -> ([a],[a])
splitAt cnt lst =
    if cnt > 0 then (case cnt of
                    [] -> ([], [])
                    hd::tl -> (let (before, after) = splitAt (cnt-1) tl
                               in (hd::before, after)))
               else ([], lst)

Yields this type error
gideon@glitch:/tmp$ elm test.elm
[1 of 1] Compiling Main                ( test.elm )
Type error:
Something weird is happening with this value:

        []

   Expected Type: comparable
     Actual Type: [a]

Type error:
Something weird is happening with this value:

        hd :: tl

   Expected Type: comparable
     Actual Type: [a]

No location is reported at al.

Looks like it took longer than expected :) I am working on a revamp of error reporting, so here is the new message:
-- TYPE ERROR --------------------------------------------------------- hats.elm

This expression is triggering a type mismatch.

5|
6|         [] -> ([], [])
7|          ^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    comparable

and this type:

    List a


string: deduplicate comparison logic between string and string_view

Fixes #36.

What do you think of implementing the spaceship operator?

IIRC that needs the standard comparison result types which we don't have in
cxxshim yet (I think they are a part of some PR though).
On Sun, Oct 30, 2022, 07:08 Arsenović Arsen @.***>
wrote:

What do you think of implementing the spaceship operator?
—
Reply to this email directly, view it on GitHub
https://github.com/managarm/frigg/pull/53#issuecomment-1296127152, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AL7W6N7P24SGOFJKQZDA47TWFX7DPANCNFSM6AAAAAARR7QMBQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Using return values in @media condition

Maybe I misuse the plugin somehow, but I get the following problem.
My code:
// 1. variable used in function
@foo: 11px;

// 2. function
.function-bar() {
    return: 42 * @foo;
}

// 3. variable that uses function (just for more readability)
@qux: (1px + bar());

// 4. media (@qux value can be copied here directly to media condition as well)
@media (min-width: (@qux)) {

    .baz {
        less: rulez;
    }
}

Expected CSS result:
@media (min-width: 912px) {
  .qux {
    less: rulez;
  }
}

Actual result:
OperationError: Operation on an invalid type in /path/to/myfile.less on line 13, column 28:
12 // 4. media (@qux value can be copied here directly to media condition as well)
13 @media (min-width: (@qux)) {
14

UPD. Adding parethensis inside function helps.
Anyway, is that a bug of some kind, or I should close the issue?

It's related to #1480. This should be fixed in Less itself, but let's keep it open here as well for reference (and as a reminder).

Closing as fixed in v3.x Less branch,


The front page should show the Fcrepo server version

Currently it show properties like
fedora: repositoryJcrRepositoryVersion
    4.2.0.Final

It would be nice for it to show a version for fcrepo too.

@jcoyne the version and build number of Fedora can currently be found on the front page:
http://locahost:8080/fcrepo

(notice, this is on the context, such as "/fcrepo", not on "/fcrepo/rest")


Split spatial data

Resolves #111, Split county & state boundary datasets into coarse and fine resolutions
We start by loading and displaying a low-res set of state boundaries. Then we jump right to loading county boundaries to support interaction. Then when you zoom in, we load and display high-res county and state boundaries.
This should speed up the initial page load time because we're loading smaller files to begin with.
We could play more with the specifics, but for now I think I have something adequate, which is:

when zooming in, only the state boundaries (nationally) and the county boundaries specific to the focal state are updated. This leaves some funniness where state boundaries and county boundaries of adjacent states are mismatched, but that issue should go away once we incorporate @lindsaycarr 's open PR (https://github.com/USGS-VIZLAB/water-use-15/pull/129).
Then if you pan to an adjacent state, that state's county borders are updated on the fly. I think all that is sensible and efficient.
When you zoom back out, we revert to coarse-resolution borders. This may not be the best option. The data is loaded and cached the first time you zoom in, so it's not that we're wasting time loading the data again next time you zoom it, but it does take some processing power each time we switch the county and state boundary DOM elements between low and high resolution. We could experiment with keeping the high-resolution data applied forever once it's loaded; we'd just want to look at how that affects interaction speed at the national scale.

We could also consider ONLY doing lo-res on mobile, even when zoomed in. The counties are sorta blocky with the current settings (simplify=I(1e-6), quantize=I(1e6) in preprocess.yaml, line 51), but mobile screens are small.

OK @lindsaycarr , I think we're there! I also just ran the preprocessing step again to push the revised/renamed files to SB so others can use them

Oh...except the conflicts, which I thought I just resolved...

now it's ready


Import Findings

Uploading findings in a CSV would be a great option for this tool, We can put a sample CSV, which can be used as a format to upload new findings.
Hopefully we can do this promptly

@mukabhai
Hi, in Upload Findings you can upload previous CSV exports from other reports.

I hope this will cover your needs.
Thanks

@mukabhai
Hi, in Upload Findings you can upload previous CSV exports from other reports.

I hope this will cover your needs.
Thanks


Docs: How do plugins work?

Looking at the existing docs around the plugins it is not exactly clear what to do with the sample plugins. Where do I put them? How do I get them to work with the Docker image?
Some enhancements to the docs would be greatly appreciated.

Hey @kylelaverty, thank you for bringing this up.
Currently the plugins have to be installed in the virtual environment that the app uses. For running this in docker, you would have to build your own docker image with the specific environment.
To make this a little easier to implement for a plugin user, a volume could be mounted in the container e.g. into /plugins and the entrypoint.sh would run pip install . each directory in the mounted folder ...
I will look into that tonight.

Hey,
Thanks for the quick response. I guess I had incorrectly thought there was a specific folder to create and the wiki would scan for it and load what was there but given the use of pip this explanation makes a lot of sense.

With the change to the entrypoint.sh the docker image will kind of do what you expected. This should make it much more approachable to develop or use plugins.
This improvement will we included in the next release. Thanks for bringing this up!

With the v2.4.3 the docker image installs plugins from either /plugins or /app-data/plugins. The examples in docs/plugin_examples provide a docker-compose.yaml as demo.


removing define module name as it isn't needed and breaks aliasing

This breaks the ability to do the following.
// config.js
requirejs.config({
    paths: {
        'mymodule-highlightjs': '/path/to/highlightjs'
    }
});

// file.js
define(['mymodule-highlightjs'], function(highlightjs){
    //...
});

Removing the named define fixes this.

The explicit name was added because of #853 and this pull request will most likely break use of almond angular agian. It's probably best to use the defined module name or modify the file locally.

I have forked this so I can use my solution. Such is the ugliness of module loaders today.

One thing to consider here is that you are in essence preferring Almond.js over require.js. Granted, this is a specific use case of require.js and most scenarios that use require.js don't need this, so they aren't broken. That said, ideally, in your module detection code block you could detect if using almond.js and if so, include the define module name; otherwise, omit it. I am not blocked here as I have the fork I can use with bower, but that offloads the maintenance to myself, and others, if they also encounter this problem.

I got around this (finally), and while it's seems to be settled, there's one thing I want to clear up. One reason for having a separate building infrastructure is to keep the actual source free of decisions like this.
I found the point where this environment detecting code was added in 3ed3be7 but I don't remember the discussion leading to that. Looking at it all afresh I think it should be possible to move the header into the build tool, restore a separate target for AMD and control adding an explicit define name with a parameter. It seems to be more consistent with how other build targets are handled.
@sourrust: what do you think about it?

Looking into it, it seems that anonymous modules is the way to go. And I found that require.js has a tool that will name the modules for you, it is something like this:

Okay. Seems to be the least complicated thing to do, as it keeps it out of our code.


Inquiry on Extending Sigma Profile Range and Calculating Ionic States

Hello,
I'm working with the cCOSMO module and would like to extend the sigma profile range to enable the calculation of ionic states, particularly anions. However, with the current settings, I'm unable to successfully perform these calculations.
Could you provide guidance on how to extend the range and enable ionic state calculations? Are there any additional settings or modifications required to calculate ionic states like anions?
Thank you.

It is technically possibly to modify the code to allow for other charge density ranges, but such a change would touch a lot of the code because the sizes of the arrays are hard-coded in a number of places. I think it would be fine to make them dynamic almost everywhere, so in principle I don't see a reason why, with a bit of work, it wouldn't be possible to expand the range. Unfortunately I am not in a position to do that work currently, but would be happy to review a pull request.

Thank you very much for your response and insights.
I’m still quite new to programming and trying to better understand how the cCOSMO module is structured. To clarify my next steps, could you kindly confirm whether the sigma profile range settings are defined within the cCOSMO.cp39-win_amd64.pyd file? I'm not sure if modifications to this compiled file are necessary or if they can be done within the accessible parts of the code.
I greatly appreciate your guidance and any advice you can provide. I’ll do my best to contribute based on your suggestions.
Thank you again for your time and support.


Support LaTeX/BibTeX in deep TabNine

I have no idea how hard it is to add the support for them, but I would love to see the support for LaTeX/BibTeX in deep TabNine.
Deep TabNine is a very awesome project! Thank you for providing it to us.

Use https://texlab.netlify.com/#download as Language Server Protocol?

close as duplication of #144


Use "Max Elemental Damage" ability if there is no one applied to the line .

This would greatly raise dps!

Already implemented https://github.com/SteamDatabase/steamSummerMinigame/pull/115
You can close this issue.


Concurrent/Parallel user sharing

Description
This PR adds a sample API test for concurrent user sharing.
For now this test adds only a single share of resource to 5 of the existing user concurrently.
Related Issue:
https://github.com/owncloud/QA/issues/828

Some Findings regarding the implementation of Concurrent user sharing:

Currently concurrent sharing is done only for 5 users. It would have been good if we have more users to share concurrently. i am unable to find the request to create user through cs3api or also the available client for as says it is unimplemented
Also we need each sharee information to share. So to get the information of the created user we need to find each user information.

Not very urgent thing to do right now. Can be done later. So moving to backlog.

Since we cannot create more users with the cs3api. The main objective of this PR or issue was to include more users as much as possible and prepare the concurrency of the share for the created users. So concurrent sharing with only few users does not seem valid. May be we can achieve the thing with API tests in the ocis itself. So closing this PR.


Supporting Complex Selectors for Transclusion in Components

I'm submitting a ...

[x] feature request

I have been writing code using AngularJs 1.5.5 components. Please see below Plunker:
Components With Transclusion
I have a <user> component which can either contain <add-action> or <update-action> components. Only one of them will be included at any time. Now I want to transclude these components in main <user> component at the same transclusion slot.
I can't make any of them as default because there might be a case like view only page where none of them are shown. Both the sub-components are going to contain different buttons.
Problem is I have to use full name of the sub-component like either addAction OR updateAction.
what I want is something like a CSS selector which can select any of them. e.g $=action which will select any element present and having name ending with word "action". Is it possible at all? I have not included actual code but have included sample to demonstrate.

I'm not sure about custom CSS selectors (we would have to use querySelectorAll I guess, which might be possible now that IE8 is out, but could be slow).
Off the top of my head, the easiest solution would be allowing arrays of elements as values of the transclude object. E.g.:
// DDO
{
  ...
  template:
    '
' +
      '...' +
      '

' +
    '
'
  transclude: {
    action: ['addAction', 'updateAction']
  }
}

WDYT, @petebacondarwin ?
--
BTW, you can currently achieve something similar, using ngIf and a little boilerplate: Demo

@gkalpak I did that and for my case ng-if is not really required as only one element will be included at all times. However would really like to do this more declaratively using the api itself. Also what if i have more than couple of actions and such multiple slots. It will be more complex I suppose.

@gkalpak for an array solution I suppose optional notation "?" can be supported as well

Supporting ? with arrays would be a little tricky. It might be easier to use a comma-separated string.


deduplicate daemon start and wait logic

All daemons had some variant of the same few lines. This moves the
code into a single new utils crate.
While it should already simplify the current code, further extensions
that touch all daemons also become easier (socket activation,
sd_notify, ...).
No functional changes intended.
Link: https://linaro.atlassian.net/browse/ORKO-32
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:

[x] All commits in this PR are signed (with git commit -s), and the commit
message has max 60 characters for the summary and max 75 characters for each
description line.
[x] All added/changed functionality has a corresponding unit/integration
test.
[x] All added/changed public-facing functionality has entries in the "Upcoming
Release" section of CHANGELOG.md (if no such section exists, please create one).
[x] Any newly added unsafe code is properly documented.

This is an RFC, is this an OK thing to do?
Open Questions / TODOs

Is introducing a new crate for this desirable? Or should we attempt to move it somewhere else?
[ ] Populate metadata of new crate
[ ] sort new dependency properly...

Changelog

Dropped RFC
Minor cleanups

Would it make more sense for these items to be in vhost-user-backend instead?

Maybe? These simplifications are pretty opinionated though... My feeling was that a vhost-user-backend suitable solution would need to be a bit more generic (de-hardcode the error messages). Also, I plan to add things like socket activation here. Not sure how well suited those would be for vhost-user-backend.
So maybe this is a simpler way for us to try these abstractions and maybe eventually move them to vhost-user-backend if they work out? If there already is a clear desire to have them in vhost-user-backend, then I am happy to put in the work to move it there. Happy to hear opinions!

Would it make more sense for these items to be in vhost-user-backend instead?

Maybe? These simplifications are pretty opinionated though...

I kind of agree with @epilys here. The usage of the APIs provided by vhost-user-backend is a bit complicated and is a lot of code that is redundant across crates. And this isn't just about the crates present in vhost-device workspace but other crates too which depend on vhost-user-backend, like virtiofsd. I suggest we get something common merged in vhost-user-backend for this.
@jiangliu ?

I am also working on systemd socket activation support (just posted as draft at https://github.com/rust-vmm/vhost-device/pull/365). For that a separate utils crate would also be useful. Or would socket activation also be interesting to have within vhost-user-backend?

I am also working on systemd socket activation support (just posted as draft at #365). For that a separate utils crate would also be useful. Or would socket activation also be interesting to have within vhost-user-backend?

Since Listener is implemented by vhost crate, it may suit well to add support right there.

ACK. Will try to direct my patches there then. Will close this once I got patches posted against vhost-user-backend.

Posted upstream PR at https://github.com/rust-vmm/vhost/pull/173.


miner does not see intel opencl device

"ethminer --list-devices" does not show my opencl-enabled intel sandy bridge apu. opencl libs installed by this tutorial:
https://software.intel.com/en-us/forums/opencl/topic/390630
platform: linux mint 17.3 x64
clinfo tool says:
Number of platforms:				 1
Platform Profile:				 FULL_PROFILE
Platform Version:				 OpenCL 1.2 LINUX
Platform Name:				 Intel(R) OpenCL
Platform Vendor:				 Intel(R) Corporation
Platform Extensions:				 cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_fp64
Platform Name:				 Intel(R) OpenCL
Number of devices:				 1
Device Type:					 CL_DEVICE_TYPE_CPU
Device ID:					 32902
Max compute units:				 4
Max work items dimensions:			 3
Max work items[0]:				 8192
Max work items[1]:				 8192
Max work items[2]:				 8192
Max work group size:				 8192
Preferred vector width char:			 1
Preferred vector width short:			 1
Preferred vector width int:			 1
Preferred vector width long:			 1
Preferred vector width float:			 1
Preferred vector width double:		 1
Native vector width char:			 16
Native vector width short:			 8
Native vector width int:			 4
Native vector width long:			 2
Native vector width float:			 8
Native vector width double:			 4
Max clock frequency:				 2500Mhz
Address bits:					 64
Max memory allocation:<PHONE_NUMBER>
Image support:				 Yes
Max number of images read arguments:		 480
Max number of images write arguments:		 480
Max image 2D width:				 16384
Max image 2D height:				 16384
Max image 3D width:				 2048
Max image 3D height:				 2048
Max image 3D depth:				 2048
Max samplers within kernel:			 480
Max size of kernel argument:			 3840
Alignment (bits) of base address:		 1024
Minimum alignment (bytes) for any datatype:	 128
Single precision floating point capability
Denorms:					 Yes
Quiet NaNs:					 Yes
Round to nearest even:			 Yes
Round to zero:				 No
Round to +ve and infinity:			 No
IEEE754-2008 fused multiply-add:		 No
Cache type:					 Read/Write
Cache line size:				 64
Cache size:					 262144
Global memory size:<PHONE_NUMBER>6
Constant buffer size:				 131072
Max number of constant args:			 480
Local memory type:				 Global
Local memory size:				 32768
Error correction support:			 0
Unified memory for Host and Device:		 1
Profiling timer resolution:			 1
Device endianess:				 Little
Available:					 Yes
Compiler available:				 Yes
Execution capabilities:
Execute OpenCL kernels:			 Yes
Execute native function:			 Yes
Queue properties:
Out-of-Order:				 Yes
Profiling :					 Yes
Platform ID:					 0x1bc0780
Name:						        Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
Vendor:					 Intel(R) Corporation
Device OpenCL C version:			 OpenCL C 1.2
Driver version:				 <IP_ADDRESS>
Profile:					 FULL_PROFILE
Version:					 OpenCL 1.2 (Build 43)
Extensions:					 cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_fp64

There's a cmd line flag --allow-opencl-cpu 1. This should enable it, altough I've never tried. You will likely run into memory allocation issues. That may be solved using a kernel where the DAG emmeory is split across multiple chunks. Let me know if you need code for that.

Just as you said, I've got a segfault trying to mine with --allow-opencl-cpu turned on.

Let me know if you need code for that.

Yes, please. I'm certainly want to give it a try.

As I mentioned in the other thread, the code seems to have already passed the main DAG memory allocation part. So in theory you shouldn't have to use chunks. Intel CPUs don't get this far. I'd just run a debugger to see where the segfault comes from. I can hand you the chunks code, but if it isn't a problem, better not use chunks (worse performance).

Let's continue here https://github.com/Genoil/cpp-ethereum/issues/44


Cohere example

PR Review Summary 🔍
This PR adds a new example for using Cohere's Command R+ model with LlamaCloud document parsing. It includes async and sync Python scripts for API interactions, along with necessary configuration files. The implementation seems straightforward, but there are a few areas that could be improved for better error handling, security, and maintainability.
⚡ Logical Error Analysis

Error handling in cohere.py is inconsistent. The try-except block catches exceptions but doesn't return the error message for all cases.
In cohere-async.py, the client.aclose() in the finally block may raise an exception if client is not defined, potentially masking other errors.
Both scripts hardcode the LlamaCloud job ID, which limits flexibility and reusability.
The scripts don't validate or sanitize user input (inputs["question"]), which could lead to unexpected behavior or security issues.

🧪 Test Coverage Analysis

No tests are included for the new functionality, which is critical for ensuring the API integrations work as expected.
Consider adding unit tests for error handling, API response parsing, and edge cases like missing environment variables.

🔒 Security Analysis

API keys are retrieved from environment variables, which is good practice, but there's no fallback or error handling if they're missing.
The hardcoded LlamaCloud job ID in the API URL could potentially expose sensitive information if the ID is meant to be kept private.

PR Review Summary 🔍
This PR adds a new example for using Cohere's Command R+ model with LlamaCloud document parsing. It includes async and sync Python scripts for API interactions, along with necessary configuration files. The implementation seems straightforward, but there are a few areas that could be improved for better error handling, security, and maintainability.

⚡ Logical Error Analysis

Error handling in cohere.py is inconsistent. The try-except block catches exceptions but doesn't return the error message for all cases.
In cohere-async.py, the client.aclose() in the finally block may raise an exception if client is not defined, potentially masking other errors.
Both scripts hardcode the LlamaCloud job ID, which limits flexibility and reusability.
The scripts don't validate or sanitize user input (inputs["question"]), which could lead to unexpected behavior or security issues.

🧪 Test Coverage Analysis

No tests are included for the new functionality, which is critical for ensuring the API integrations work as expected.
Consider adding unit tests for error handling, API response parsing, and edge cases like missing environment variables.

🔒 Security Analysis

API keys are retrieved from environment variables, which is good practice, but there's no fallback or error handling if they're missing.
The hardcoded LlamaCloud job ID in the API URL could potentially expose sensitive information if the ID is meant to be kept private.

PR Review Summary 🔍
This PR adds a new example for using Cohere's Command R+ model with LlamaCloud document parsing. It includes async and sync Python scripts for API interactions, along with necessary configuration files. The implementation seems straightforward, but there are a few areas that could be improved for better error handling, security, and maintainability.

⚡ Logical Error Analysis

Inconsistent Error Handling: Error handling in cohere.py is inconsistent. The try-except block catches exceptions but doesn't return the error message for all cases.
Exception Handling in finally Block: In cohere-async.py, the client.aclose() in the finally block may raise an exception if client is not defined, potentially masking other errors.
Hardcoded Job ID: Both scripts hardcode the LlamaCloud job ID, which limits flexibility and reusability.
Input Validation: The scripts don't validate or sanitize user input (inputs["question"]), which could lead to unexpected behavior or security issues.

🧪 Test Coverage Analysis

Lack of Tests: No tests are included for the new functionality, which is critical for ensuring the API integrations work as expected.
Recommended Tests: Consider adding unit tests for error handling, API response parsing, and edge cases like missing environment variables.

🔒 Security Analysis

Environment Variable Handling: API keys are retrieved from environment variables, which is good practice, but there's no fallback or error handling if they're missing.
Exposure of Sensitive Information: The hardcoded LlamaCloud job ID in the API URL could potentially expose sensitive information if the ID is meant to be kept private.


Add wrapper for clip_if() and children_if()

@jradha11 This looks good. You might have missed a few Composable types like Stack. Could you please check if you've covered all of them?
Also, I would add a check in the tests for the size equality of the reference and result Lists.

@KarthikRIyer
Nice point about the test. I will check for length too in the equality cases.
Also, I will be adding the remaining composable types - Item, Composition, Transition, and Stack.

Looks good!

@reinecke @KarthikRIyer
I had an observation regarding CI check. In the last test that I added testChildrenIfComposableEquality in CompositionTest.java ( commit: b00d62d) , I got an exception: UnsupportedOperationException: method not implemented for this class as the verbose output ( that was because range_of_all_children was not implemented in composition.cpp). But still, there was no build error in spite of the exception in tests. I am attaching the screenshot of the verbose output.

error output

successful build

I think we need to look into why CI didn't fail.

Yikes! Good catch!

@KarthikRIyer
Added dispatch table to remove the conditional statements. Please review!
Also I have removed childrenIf tests for Composition as the method has not been implemented. Should we keep the childrenIf wrapper too?

@jradha11  Yes, we should keep the children if wrapper. Classes that inherit from composition should inherit that method too. If you've wrapped all the methods please mark all the eachChild and eachClip methods as deprecated with the @Deprecated annotation.
I'll take a proper look at the commits in a day or two.

@jradha11 Yes, we should keep the children if wrapper. Classes that inherit from composition should inherit that method too. If you've wrapped all the methods please mark all the eachChild and eachClip methods as deprecated with the @deprecated annotation.
I'll take a proper look at the commits in a day or two.

Added the @deprecated annotation.

Could you also remove this plugin from the build.gradle file? We do not publish to bintray.
dependencies {
        classpath 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.+'
    }

Looks good.
Tiny suggestion:
JNIEXPORT jobjectArray JNICALL Java_io_opentimeline_opentimelineio_SerializableCollection_clipIfNative
        (JNIEnv *env, jobject thisObj, jobject searchRangeTimeRange, jboolean shallowSearch)

I would rename searchRangeTimeRange to searchRangeTimeRangeOptional everywhere, including the utility function. It'll be very clear that the value is an optional and cannot be used directly as a timerange.

will do the change

I think we're pretty much there! One question, I saw tests for:
// Make sure we find expected clips within range
track.childrenIf(Composable.class, Optional.of(search_range), false);

and:
// Make sure null throws NullPointerException
track.childrenIf(Composable.class, null, false);

But I think we were missing:
// Make sure full time range is traversed
track.childrenIf(Composable.class, Optional.empty(), false);

oh yes! I must have missed this edge case. Will add them too!

Hey @reinecke @KarthikRIyer ,
I have updated tests with the trimmed and full-time range. But, I was not able to do the same for SerialisableCollectionTest. I am not getting how to filter it. Could you please review and help me out here?

Oh wow, good catch. I just checked the python implementation and it doesn't seem to have a test for this case.
Looking at the implementation, I think it is designed to:

ignore search range for direct children
apply search range for child compositions if shallow_search is false

So, with shallow_search as true, I think search_range has no impact on the results of  children_if for SerializableCollection. With shallow_search set false, I think it returns all the children of the SerializableCollection and uses type-based behavior for the children it recurses into.
Does that make sense?
Since this test is for language bindings, I don't think it needs to be too rigorous around the behavior of c++ implementation, we just want our testing to verify all the parameters are being passed into the underlying implementation correctly.

@reinecke
Okay! Let me work around the shallow_search criteria to see if filtering works. Apart from that, is there anything that is left in this PR?

@jradha11 I think what @reinecke means is that if shallow_search = true, search_range is ignored.
If shallow_search = false, it will take search_range into consideration only for Compositions (like Track) inside the SerializableCollection. Track organises objects temporally (one after another). So I think a search_range for it makes sense. Since a Stack organise objects spatially (one over another), but it can contain tracks, search_range makes sense for it too. But a SerializableCollection is just a collection with no specific rules. So unless it has other compositions, a search_range doesn't mean anything.
So you could create a Track with 4 clips, add it to your SerializableCollection and check if clipIf works.
@reinecke please correct me if I'm wrong.

@KarthikRIyer @reinecke I have made the changes. I'd love if you could review! :)

Looks Good! Thanks for seeing this through!


Selenium timeout exception

Hi, I am getting the following error when trying to replicate the scraper. Do you knwo how can I fix it? Thanks!
(base) jdtorres@SIE-C02G50GLML86 Google-Maps-Scraper-master % /Users/jdtorres/opt/anaconda3/bin/python /Users/jdtorres/Downloads/Google-Map
s-Scraper-master/MainScraper.py
/Users/jdtorres/Downloads/Google-Maps-Scraper-master/MainScraper.py:21: DeprecationWarning: executable_path has been deprecated, please pass in a Service object
driver = webdriver.Chrome(ChromeDriverManager().install())
['bar', 'cinema', 'office']
total number of points to check:175
Traceback (most recent call last):
File "/Users/jdtorres/Downloads/Google-Maps-Scraper-master/MainScraper.py", line 183, in
new_places = searchForPlace(url, typeOfPlace)
File "/Users/jdtorres/Downloads/Google-Maps-Scraper-master/MainScraper.py", line 72, in searchForPlace
clickAcceptAllButton()
File "/Users/jdtorres/Downloads/Google-Maps-Scraper-master/MainScraper.py", line 101, in clickAcceptAllButton
button = wait.until(EC.visibility_of_element_located((By.XPATH, button_path)))
File "/Users/jdtorres/opt/anaconda3/lib/python3.8/site-packages/selenium/webdriver/support/wait.py", line 95, in until
raise TimeoutException(message, screen, stacktrace)
selenium.common.exceptions.TimeoutException: Message:
Stacktrace:
0   chromedriver                        0x000000010d740598 chromedriver + 4973976
1   chromedriver                        0x000000010d737913 chromedriver + 4938003
2   chromedriver                        0x000000010d2f4cd6 chromedriver + 470230
3   chromedriver                        0x000000010d3382ff chromedriver + 746239
4   chromedriver                        0x000000010d338591 chromedriver + 746897
5   chromedriver                        0x000000010d37a384 chromedriver + 1016708
6   chromedriver                        0x000000010d35c9ed chromedriver + 895469
7   chromedriver                        0x000000010d377856 chromedriver + 1005654
8   chromedriver                        0x000000010d35c793 chromedriver + 894867
9   chromedriver                        0x000000010d32a21f chromedriver + 688671
10  chromedriver                        0x000000010d32b56e chromedriver + 693614
11  chromedriver                        0x000000010d6fabb7 chromedriver + 4688823
12  chromedriver                        0x000000010d6ffa51 chromedriver + 4708945
13  chromedriver                        0x000000010d70640f chromedriver + 4736015
14  chromedriver                        0x000000010d70091a chromedriver + 4712730
15  chromedriver                        0x000000010d6d387c chromedriver + 4528252
16  chromedriver                        0x000000010d71ff28 chromedriver + 4841256
17  chromedriver                        0x000000010d7200a7 chromedriver + 4841639
18  chromedriver                        0x000000010d73128f chromedriver + 4911759
19  libsystem_pthread.dylib             0x00007ff816b111d3 _pthread_start + 125
20  libsystem_pthread.dylib             0x00007ff816b0cbd3 thread_start + 15

Hi @jdtorres96
I have checked your issue and updated the code to solve it. I changed the way the scrolling of the menu is performed. Here is the new code:
def scrollDownLeftMenuOnGoogleMaps(counter, waitingTime):
    """
    This function is responsible for scrolling down the menu visible at the left.
    It is used while searching for places at Google Maps. It allows seeing more places relevant for the search value.

    :param counter: number of scrolls down
    :param waitingTime: waiting time until next scroll (new results are loaded)
    """
    menu_xpath = '/html/body/div[3]/div[9]/div[9]/div/div/div[1]/div[2]/div/div[1]/div/div/div[2]/div[1]/div[3]/div'
    if check_exists_by_xpath(menu_xpath):
        for i in range(counter):
            # wait until element is located
            wait = WebDriverWait(driver, waitingTime)
            menu_left = wait.until(EC.visibility_of_element_located((By.XPATH, menu_xpath)))

            # perform scrolling down
            scroll_origin = ScrollOrigin.from_element(menu_left)
            ActionChains(driver).scroll_from_origin(scroll_origin, 0, 500).perform()

Please let me know if everything works correctly so I can close this issue. Happy coding!

Hi @KrzysztofNazar01, thanks so much for your help! I've tried the new code but am still getting the same problem. I wonder if it has to do with some google chrome configuration. Also, I am running this in a Mac


Release 📦

📦 Release Pull Request
📝 Release Notes

The following Pull Request will carry out a release with the following adaptations:

Fix by standardising manifest.json

🚧 Pre-Release Checklist

[ ]  ~All tests passed successfully.~
[x]  Code follows coding standards.
[x]  Documentation is up-to-date.
[x]  Dependencies are correctly updated.
[ ]  ~Continuous Integration (CI) pipelines passed.~

:tada: This PR is included in version 1.2.3 :tada:
The release is available on:

v1.2.3
GitHub release

Your semantic-release bot :package::rocket:


Connection-level callbacks

It would be very useful to have callbacks on the connection level when we successfully connect and when we have disconnected (possibly due to an error). This could be used to more intelligently due retries when we are offline.

onConnected
onDisconnected
onClose
I believe that is what you wanted.


Gulp module not found unless Gulp is installed globally

I want to be able to run gulp from local node_modules, so I don't have to install gulp globally on every build agent. Any tips?

The error I get is: Gulp module not found. Please install Gulp in the node module path 'C:\Users\MyUser\AppData\Roaming\npm

Nevermind, fixed it by adding:
<LocalNodeModulePath>$(SolutionDir)node_modules/.bin</LocalNodeModulePath>

Feel free to close this :)

Where did you add the  to the visual studio solution file?

@bkraider the line must be added to your web project's .csproj-file, not the solution file. To be honest, I do not remember any more details; it is almost three years ago, these days I use webpack instead of gulp :)


[docs] "codestyle" comment typo fix

for consistency with other descriptions

Sorry, but I don't understand the purpose of this PR - it seems to simple add a line-break (which isn't currently supported in the style descriptions IIRC).

line-break wasn't intended, just reverted that. The purpose of the PR is just a quick fix for display text formatted as code that should've been formatted as code but currently isn't.

I don't understand the purpose of this PR

@mbrookes I believe it's the following:

Ah, thanks both, I didn't spot the back-ticks in the PR, may bad. (My excuse is that it was late! 😪 😄).
I guess you could add an eslint-disable-next-line before it


Add an environment variable which specifies directories to look for imported files

The import.rs module would should be extended to look for an environment variable (maybe GLUON_PATH?) and use that for import lookup as well.

I'd like to contribute something to your project, this issue seems easy enough. Do you have a particular way you might like to see this implemented?
I'm a beginner at Rust, so please let me know if this is way off base
https://github.com/leshow/gluon/blob/master/src/import.rs#L104

Thanks for the interest!
I'm wondering if it would be possible to pass the path down from a higher level - ie. closer to the entrypoint. That way we can push the global state out to the edge of the code, making things more testable. Just an idea!

Feel free to open a WIP PR, referencing this issue - that way we can talk over there.

I think it may be, as @bjz says that the addition of GLUON_PATH should be a bit higher up to keep the creation of an Import pure. I am thinking that it could be added in new_vm which serves to create a vm initialized with a sane set of defaults.
Also see https://github.com/Marwes/gluon/blob/9058c253c23358cdfc249e88c5789bd3b4f6e98c/tests/vm.rs#L39-L42 for how to retrieve and add a new path.

awesome! I'll make some changes and open a PR

Closed by #79

@leshow In the future, if you put 'Closes #N' of 'Fixes #N' in the PR description, the corresponding issue will be auto-closed. :)


Create and setup workflow for CI/CD for nachet-frontend

A workflow for CI/CD will be added to a .github/workflows folder
workflow will :

build
push
use npm

PR #63


[1.0.2] '$' is undefined when 'created' is being called

See http://dzhioev.net:8080/dollar_in_created.html, which is slightly modified example from primer.
On Chrome 42.0.2311.153 (Official Build) (64-bit) I get

Uncaught TypeError: Cannot read property 'name' of undefined

in dollar_in_created.html:25.

The callback here should be ready.  As noted, at created time the nodes are not yet marshaled.


KAFKA-7772: Adjust log levels of classes in Connect via JMX

Consolidating ways to adjust log levels in AK. This change provides a common way to modify log levels of running Kafka brokers and Kafka Connect workers via a JMX interface.
Signed-off-by: Arjun Satish<EMAIL_ADDRESS>More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@rhauch @mageshn can you give this a first pass? thanks a lot!

Regarding my previous comment:

After testing this locally and comparing to the old version, I find that this now exposes all Kafka Java classes' log levels.
Previously, the Scala implementation would not let you get/set Java classes' log levels.
e.g kafka.server.FetchManager

I tested again and found this to be incorrect. First of all, kafka.server.FetchManager is not a Java class, it's scala. We always seemed to have exposed the Java class loggers

@stanislavkozlovski thanks for the test! Yeah, I don't think that should happen. I tried to retain the existing behavior as much as possible. One big difference is using effective log level and removing newLogger [1] from the old code (I don't think we should create loggers if they don't exist). The new code only allows you to set/get log levels of existing loggers.
[1] https://github.com/apache/kafka/pull/6069/files#diff-ce366937756affa54fe2b50feff24f23L49

closed in favor of https://github.com/apache/kafka/pull/7403


Added a useful resource

Hey, I've added a useful learning resource, I think this will best add to your content and give your readers a more diverse understanding of the topic. I hope you will like this. Thank you.

Thanks for adding.


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v2.6.24 to before v4.9.292",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=faf0b2e5afe7dae072d2715763c7f992b612b628",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=91ba94d3f7afca195b224f77a72044fbde1389ce"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "faf0b2e5afe7dae072d2715763c7f992b612b628",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "91ba94d3f7afca195b224f77a72044fbde1389ce",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v4.9.292 by commit 91ba94d3f7afca195b224f77a72044fbde1389ce, it was introduced in version v2.6.24 by commit faf0b2e5afe7dae072d2715763c7f992b612b628. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2021-1002376


Request not using CURLOPT_POSTFIELDS have content-length set to 0

I don't know if this is a normal behaviour but if I send a large body (a file > 1MB) the CURLOPT_POSTFIELDS option is not used but the CURLOPT_READFUNCTION instead and in the createHeaders method the content-length header is set to 0.
Doing this, my server doest not reveive data, all is empty.
So 2 possible scenario :

my server is not well configured and does not deal correctly with the request received
the content-length should be set with the body size if present.

If I set the content-length header with the body, my server receive all the data and have an expected behaviour, I put this for my test :
if ('content-length' === $header) {
                $values = [0];
                if (array_key_exists(CURLOPT_POSTFIELDS, $options)) {
                    $values = [strlen($options[CURLOPT_POSTFIELDS])];
                } else {
                    $body = $request->getBody();
                    $bodySize = $body->getSize();
                    if ($bodySize > 0) {
                        $values = [(string) $bodySize];
                    }
                }
            }

but maybe the CURLOPT_INFILESIZE is a better option

i remember there was something about having to use the content length plugin: http://docs.php-http.org/en/latest/plugins/content-length.html
we use curl quite minimal by purpose to avoid problems when switching from one to another client. but in this case i somehow assume that the guzzle6 adapter will end up doing the content lenght, so maybe this is too strict?

Oh I use the ContentLength plugin and if I remove it all work perfectly... this is annoying because I use this plugin everywhere.

So here is my scenario :

I use a MultipartStream to upload files to an API
I use the ContentLength plugin to not manage this header, the plugin does it for me
the plugin set the content-length plugin with the  good value
the curl client looks if the  content-length header is set and if yes, it tries to override it with the CURLOPT_POSTFIELDS length value which is not used in my case, so it set it to 0.

It look likes a bug from Curl, as guzzle is handling this by removing the header, look at : https://github.com/guzzle/guzzle/blob/9f75c64ba74ea0523821d6679df97e7db023fc80/src/Handler/CurlFactory.php#L263

Thanks @joelwurtz should I do the same and open a PR ? Is it normal to not have a content-length header

This is an error caused by e3ae04c6146b0f45072648f25a328af5d20f3285.

Hm… Can not reproduce this at my local machine. @lunika, can you run this script (changing URL if needed):
<?php

$ch = curl_init();

$options = [
    CURLOPT_URL => 'http://localhost/',
    CURLOPT_CUSTOMREQUEST => 'POST',
    CURLOPT_UPLOAD => true,
    CURLOPT_INFILESIZE => 16,
    CURLOPT_READFUNCTION => function () {
        static $done = 0;
        return $done++ ? '' : str_repeat('x', 16);
    }
];

curl_setopt_array($ch, $options);
curl_exec($ch);
curl_close($ch);

and dump request headers, for example with tcpdump like this:
tcpdump -i lo -A tcp dst port 80

My headers:
POST / HTTP/1.1
Host: localhost
Accept: */*
Content-Length: 16
Expect: 100-continue

The real problem is here https://github.com/php-http/curl-client/blob/master/src/Client.php#L327-L331
If you already have the content-length header, you set it to 0 because CURLOPT_POSTFIELDS is not used with a large body.
You can reproduce it with the tests, replace HttpClientTestCase::testSendLargeFile method by this one :
/**
     * Test sending large files.
     */
    public function testSendLargeFile()
    {
        $filename = $this->createTempFile();
        $fd = fopen($filename, 'a');
        $buffer = str_repeat('x', 1024);
        for ($i = 0; $i < 2048; $i++) {
            fwrite($fd, $buffer);
        }
        fclose($fd);
        $body = $this->createFileStream($filename);

        $request = self::$messageFactory->createRequest(
            'POST',
            PHPUnitUtility::getUri(),
            ['content-length' => 42],
            $body
        );

        $response = $this->httpAdapter->sendRequest($request);
        $this->assertResponse(
            $response,
            [
                'body' => 'Ok',
            ]
        );

        $request = $this->getRequest();
        self::assertArrayHasKey('CONTENT_LENGTH', $request['SERVER']);
        self::assertEquals($body->getSize(), $request['SERVER']['CONTENT_LENGTH']);
    }

Your test will fail now.
A solution can be to remove the content-length header like in guzzle6 or to the the right content-length depending the scerio you are with something like this in createHeaders method :
            if ('content-length' === $header) {
                switch (true) {
                    case array_key_exists(CURLOPT_POSTFIELDS, $options):
                        $values = [strlen($options[CURLOPT_POSTFIELDS])];
                        break;
                    case array_key_exists(CURLOPT_INFILESIZE, $options):
                        $values = [$options[CURLOPT_INFILESIZE]];
                        break;
                    default:
                        $values = [0];
                        break;
                }
            }

Doing this the previous test is now green

OK, I'll see this tomorrow.

any news ? How can I help you ? Both solutions (removing the header or recompute it) work well, which one would you like to pick ?

Sorry for the delay, @lunika. I had trouble with the hard drive and I lost all the files. Fortunately I have a backup. I've already reinstalled OS and now restoring files. I hope to continue with curl-client in a few days.

Check current master.

I tested it this morning, it works. Do you know why travis is failing ? Did you plan to release a bugfix soon ?

Did you plan to release a bugfix soon ?

I hope so.

Version 1.6.2 released.

Thank you 👍


Minor fixes to Docker stuff

@raimon49 thanks for this AWESOME project!
I use it in CI for a few projects where I want to be really careful about unwanted licenses like GPL sneaking into my dependency tree.
Because I use pip-licenses so much, I wanted to come into the project today and spend some time learning how the internals work.
I really like the Docker setup you have, and hope you'll consider this PR that makes two small changes to it.

Docker supports the use of ARG for storing (basically) environment variables that are only used at build time. I recommend centralizing the path /opt/piplicenses (which is manually copied in multiple places) in an ARG to improve the readability of your Dockerfile and reduce the risk of copy-paste errors if contributors add to it in the future
While running through the Docker example in the README, I found that the outputs have changed slightly thanks to newer versions of Werkzeug being published

@jameslamb Thank you for the good suggestions!