Forked up

Can't compile
Error is:
/usr/bin/ld: /tmp/ccTXDxRz.o:(.bss+0x0): multiple definition ofcont'; /tmp/ccVCvmG7.o:(.bss+0x0): first defined here
/usr/bin/ld: /tmp/ccnq4NrH.o:(.bss+0x0): multiple definition of cont'; /tmp/ccVCvmG7.o:(.bss+0x0): first defined here
Go back to last working commit and build from there
Also would be nice to have some meson or Makefile

Probably solved, will commit and push soon


[Doc] Delete Extra TOC Text from 'Coding Standard' Page

While reading the documentation, I noticed extra text at the bottom of the Table of Contents on the Coding Standard page:

The last two lines of text, 'Code Style' and 'Language features', are unnecessary and should be removed.
I couldn't locate the problem in the code as I am not familiar with it. Therefore, I created this issue to request assistance in rectifying the problem.

Fixed in 1b9e11ed5eaa2e4a9210813b6510210cb9eb481e


[SPARK-38586][INFRA] Trigger notifying workflow in branch-3.3 and other future branches

What changes were proposed in this pull request?
This PR fixes Notify test workflow workflow to be triggered against PRs.
In fact, we don't need to check if the branch is master since the event triggers the workflow that's found in the commit SHA.
Why are the changes needed?
To link builds to the CI status in PRs.
Does this PR introduce any user-facing change?
No, dev-only.
How was this patch tested?
Will be checked after it gets merged - it's pretty straightforward.

I filed a separate JIRA because it has to be backported to branch-3.3.
cc @dongjoon-hyun @Yikun @MaxGekk FYI

Merged to master and branch-3.3.


[DRAFT] Load vector data directly from the memory segment

[ This PR is draft - not ready to be merged. It is intended to help facilitate a discussion ]
This PR enhances the vector similarity functions so that they can access the underlying memory directly, rather than first copying to a primitive array within the Java heap.
I added a number of overloads to VectorSimilarityFunction, to allow the retrieval of the vector data to be pushed down. This way, the actual retrieval can be pushed into the provider implementation. This feels right, to me.
RandomAccessVectorValues encapsulates and provides access to the underlying vector data. I added the ability to retrieve the backing IndexInput here, so that it's possible to bypass the accessor that does the copy. This is not great, but maybe ok, especially if we could restrict access?
I updated MemorySegmentIndexInput to support retrieval of the backing segment for a given position. That way the vector provider can access this directly. This kinda feels ok, it makes the vector provider and memory segment index input more close in nature, without imposing incubating APIs into the index implementation that is using preview APIs.
There are now a couple of extra variants of the distance calculation functions, but they are largely a cut'n'paste of sections of each other. We might not need them all, but that kinda depends on which are more performance sensitive than others.
Currently only float dot product has been updated, so as to first determine the potential performance benefits as well as the approach.
Outstanding work and areas for improvement:

Figure out something better than exposing IndexInput in RandomAccessVectorValues
Binary and other distance calculations
Evaluate perf impact with macro benchmarks ( only micro done so far )
There are a couple of hacks to get the benchmark running - remove these
..

relates #12482

Some benchmark results.
Mac M2, 128 bit
INFO: Java vector incubator API enabled; uses preferredBitSize=128
...
Benchmark                                     (size)   Mode  Cnt   Score   Error   Units
VectorUtilBenchmark.floatDotProductVector       1024  thrpt    5   6.568 ± 0.189  ops/us
VectorUtilBenchmark.floatDotProductVectorMS1    1024  thrpt    5   8.823 ± 0.157  ops/us
VectorUtilBenchmark.floatDotProductVectorMS2    1024  thrpt    5  12.561 ± 0.298  ops/us

Rocket Lake, AVX 512
INFO: Java vector incubator API enabled; uses preferredBitSize=512
...
Benchmark                                     (size)   Mode  Cnt   Score   Error   Units
VectorUtilBenchmark.floatDotProductVector       1024  thrpt    5   9.911 ± 0.004  ops/us
VectorUtilBenchmark.floatDotProductVectorMS1    1024  thrpt    5  10.081 ± 0.004  ops/us
VectorUtilBenchmark.floatDotProductVectorMS2    1024  thrpt    5  14.162 ± 0.020  ops/us

Thanks for investigating this! Can we just fix vector code to take MemorySegment and wrap array code?
I don't think we should add yet another factor to multiply the number of vector impls, there are already too many (encoding * function * cpu).
Stuff using IndexInput can be slow and wrap arrays with MemorySegment. IMO we should deprecate IndexInput for lucene 10.

as far as performance in practice, what kind of alignment is necessary such that it is reasonable for mmap'd files? Please, let it not be 64 bytes alignment for avx-512, that's too wasteful.

@rmuir  If I understand your comment correctly. I unaligned the vector data in the mmap file, in the benchmark. The results are similar enough to the aligned, maybe a little less when the alignment is terrible! see b02b79b
Rocket Lake, AVX 512
INFO: Java vector incubator API enabled; uses preferredBitSize=512
...
VectorUtilBenchmark.floatDotProductVector       1024  thrpt    5   9.994 ± 0.002  ops/us
VectorUtilBenchmark.floatDotProductVectorMS1    1024  thrpt    5  11.171 ± 0.007  ops/us
VectorUtilBenchmark.floatDotProductVectorMS2    1024  thrpt    5  13.159 ± 0.017  ops/us

Mac M2, 128 bit
INFO: Java vector incubator API enabled; uses preferredBitSize=128
...
VectorUtilBenchmark.floatDotProductVector       1024  thrpt    5   5.242 ± 0.025  ops/us
VectorUtilBenchmark.floatDotProductVectorMS1    1024  thrpt    5   7.928 ± 0.155  ops/us
VectorUtilBenchmark.floatDotProductVectorMS2    1024  thrpt    5  12.546 ± 0.077  ops/us

Thanks for investigating this! Can we just fix vector code to take MemorySegment and wrap array code?

Yes, that is a good idea. I'll do it and see how poorly is performs.  If we do this, then we still need handle the case where a vector spans across more than one segment ( well, it should only ever span at most two ). We can just copy the bytes into a float[] for this and get a memory segment view over it - this will happen so infrequently.

I don't think we should add yet another factor to multiply the number of vector impls, there are already too many (encoding * function * cpu).

Agreed.

Stuff using IndexInput can be slow and wrap arrays with MemorySegment. IMO we should deprecate IndexInput for lucene 10.

I'm not sure how this work work, but I accept the sentiment. And I think I see/agree where you are going longer term with this ( and Java 22 ).

Well... as simple wrapping of float[] into MemorySegment is not going to work out, the Vector API does not like it due to alignment constraints (which seems overly pedantic since it can operate fine when accessing a float[] directly! )
FloatVector fromMemorySegment(...)

throws IllegalArgumentException - if the memory segment is a heap segment that is not backed by a byte[] array.

This approach would of course work fine for the binary computations, since they are byte[] backed.
The current approach has three variants:

dotProduct(float[] a, float[] b)
dotProduct(float[] a, RandomAccessVectorValues<float[]> b, int bOffset)
dotProduct(RandomAccessVectorValues<float[]> a, int aOffset, RandomAccessVectorValues<float[]> b, int bOffset)

.. no.1 is used as a fallback when we span segments.
I suspect that no.1 and no.2 are not as perf sensitive as no.3?  In fact, we could try to trace the float[] back to where it originates, maybe read and store it as bytes but access it as a float.
Maybe there are other ways to invert things? I'll need to sleep on it!!

Well... as simple wrapping of float[] into MemorySegment is not going to work out, the Vector API does not like it due to alignment constraints (which seems overly pedantic since it can operate fine when accessing a float[] directly! )

But all float[] on the heap are just like any other heap object and aligned to 8 bytes or something?
$ java -XX:+PrintFlagsFinal -version | grep -i align
     bool AlignVector                              = false                                  {C2 product} {default}
     intx InteriorEntryAlignment                   = 16                                  {C2 pd product} {default}
     intx NumberOfLoopInstrToAlign                 = 4                                      {C2 product} {default}
      int ObjectAlignmentInBytes                   = 8                              {product lp64_product} {default}
     intx OptoLoopAlignment                        = 16                                     {pd product} {default}
     bool UseUnalignedLoadStores                   = true                                 {ARCH product} {default}

Hi,
I was also thinking about this but came to a bit different setup. My problem here is that it is directly linking the code in the Java 20+ code to each other and adding instanceof checks.
My idea was to have a new method on IndexInput, returning a ByteBuffer slice on RandomAccessInput for the vector that can be passed and also handled in a typesafe way without hacking "shortcut" paths between the various components removing abstractions which were introduced to separate IO from Lucene logic.
I am out of office the next week, I'd like to participate in the discussion; we should not rush anything.

I am out of office the next week, I'd like to participate in the discussion; we should not rush anything.

Take your time. Your input and ideas are very much welcome. We will continue to iterate here and try out different things, but ultimately will not finalize until you have had time to spend on it.

Well... as simple wrapping of float[] into MemorySegment is not going to work out, the Vector API does not like it due to alignment constraints (which seems overly pedantic since it can operate fine when accessing a float[] directly! )

But all float[] on the heap are just like any other heap object and aligned to 8 bytes or something?
....

It's just a leftover API restriction that will be removed in a future JDK version, see
https://mail.openjdk.org/pipermail/panama-dev/2023-October/020106.html
https://bugs.openjdk.org/browse/JDK-8318678
The upshot is that we cannot easily wrap these float[]'s now.  But that may not be strictly necessary if we move to a different approach, as suggested by Uwe.

For what it's worth, the changes currently in this PR do not perform generally well, since we can have a mix of how we represent the underlying vector values, and where they come from.  I agree with Uwe, it will be much more flexible if we consistently represent the values as ByteBuffer everywhere - that way they can on or off heap, represent float or byte values, etc, and can have a MemorySegment view in the Panama vector implementation.

I've not been able to spend all that much time on this this week, but here's my current thinking.
The abstractions in the PR are currently not great (as discussed above), but putting that aside for now since we can get a sense of the potential real performance impact from this approach as it is - so I did some performance experiments other than micro jmh.
It seems that this change improves the merge performance of vector data in segments by about 10% - not great, I was hoping for better. Is it worth proceeding with or maybe looking elsewhere? I'm not sure.   Here's how I determine the 10% - by just hacking on KnnGraphTester from luceneUtil so that it creates an index with more than one segment when ingesting 100k+ vectors with dimensions of 768, then timing the forceMerge. This is a very rough experiment, but shows that the potential gain is much less than I expected.  Caution - I could have goofed up several things, from the actual implementation to the experiment merge.


Register additional modules plugins bpmn.modeler.additionalModules in C8

Is your feature request related to a problem? Please describe.
Currently we do not pick up bpmn.modeler.additionalModules registered plugins in the C8 bpmn diagram editor, hence making plugins impossible to use there. We want to replicate the functionality here, this key should from now on be used to register plugins which aren't specific to c7 or c8.
Describe the solution you'd like
The c8 functionality for this should match that of c7.
Describe alternatives you've considered
We've considered to split up c7 and c8 registration keys, which we will do in a further issue to allow targeting of specific bpmn versions, however this would break existing plugin registration which isn't ideal. Hence we'll keep this functionality for compatibility reasons.

I guess this will resolve this issue as well: https://github.com/camunda/camunda-modeler/issues/2284
We should inform in the other issue once it's fixed, I think some people will be excited 🙂

Thanks for linking this :D


Unicode Technical Report URL Change

https://www.unicode.org/Public/emoji/latest/emoji-data.txt is not available anymore --> 404
new URL should be https://www.unicode.org/Public/UCD/latest/ucd/emoji/emoji-data.txt

Thank you! It has been updated.


Setting Font Size is mixed size?

If you start to type and the drop down shows up, the characters that are set to 20 change to something smaller as you type.  Is this a feature that can be disabled?

Fixed in the last 1.2.1 release. Thanks for reporting.


time:24 format parsing error

package main

import (
	"fmt"
	"time"
)

func main() {
	t1, _ := time.Parse("2006-01-02 15:04:05", "2016-01-02 23:00:00")
	t2, _ := time.Parse("2006-01-02 15:04:05", "2016-01-02 24:00:00")
	fmt.Println(t1)
	fmt.Println(t2)
}

/*
outputs:
2016-01-02 23:00:00 +0000 UTC
0001-01-01 00:00:00 +0000 UTC

I think it should be like this:

var d = new Date("Sat, 12 Mar 2016 24:00:00 GMT ")
document.write (d.toUTCString())

//ouputs : Sun, 13 Mar 2016 00:00:00 GMT
*/

You ignored the error returned the from the 2nd time.Parse call.
The error says "parsing time "2016-01-02 24:00:00": hour out of range"

I know that is out of range, but usually we have such input 24:00:00

This isn't a bug in Go. Let's move this to https://golang.org/wiki/Questions


Real time Node merge index throws NPE after adding Metrics

@michaelschiff  @gianm
Druid version  0.8.2
Segment Granularity: HOUR
My problem is very similar with this closed issue #145,
Around 40 minutes after an hour, I added a longSum metric and restarted the node.
when merging index,will throw NPE
java.lang.NullPointerException
   at io.druid.query.aggregation.LongSumAggregator.combineValues(LongSumAggregator.java:39) ~[druid-processing-0.8.2.jar:0.8.2]
   at io.druid.query.aggregation.LongSumAggregatorFactory.combine(LongSumAggregatorFactory.java:78) ~[druid-processing-0.8.2.jar:0.8.2]
   at io.druid.segment.IndexMerger$RowboatMergeFunction.apply(IndexMerger.java:1260) ~[druid-processing-0.8.2.jar:0.8.2]
   at io.druid.segment.IndexMerger$RowboatMergeFunction.apply(IndexMerger.java:1236) ~[druid-processing-0.8.2.jar:0.8.2]
   at io.druid.collections.CombiningIterator.next(CombiningIterator.java:78) ~[druid-common-0.8.2.jar:0.8.2]
   at io.druid.segment.IndexMerger.makeIndexFiles(IndexMerger.java:747) ~[druid-processing-0.8.2.jar:0.8.2]
   at io.druid.segment.IndexMerger.merge(IndexMerger.java:351) ~[druid-processing-0.8.2.jar:0.8.2]
   at io.druid.segment.IndexMerger.mergeQueryableIndex(IndexMerger.java:227) ~[druid-processing-0.8.2.jar:0.8.2]
   at io.druid.segment.IndexMerger.mergeQueryableIndex(IndexMerger.java:216) ~[druid-processing-0.8.2.jar:0.8.2]

So I think this issue hasn't been resolved.
look into the following code of IndexMerger line number from 657 to 688.
 boats.add(
          new MMappedIndexRowIterable(
              Iterables.transform(
                  indexes.get(i).getRows(),
                  new Function<Rowboat, Rowboat>()
                  {
                    @Override
                    public Rowboat apply(@Nullable Rowboat input)
                    {
                      int[][] newDims = new int[mergedDimensions.size()][];
                      int j = 0;
                      for (int[] dim : input.getDims()) {
                        newDims[dimLookup[j]] = dim;
                        j++;
                      }

                      Object[] newMetrics = new Object[mergedMetrics.size()];
                      j = 0;
                      for (Object met : input.getMetrics()) {
                        newMetrics[metricLookup[j]] = met;
                        j++;
                      }

                      return new Rowboat(
                          input.getTimestamp(),
                          newDims,
                          newMetrics,
                          input.getRowNum()
                      );
                    }
                  }
              )

Build newMetrics base on the metric of  input row. the previous indexes don't have new addition metric, So in the newMetrics,the value of new addition metric is null
  for (Object met : input.getMetrics()) {
      newMetrics[metricLookup[j]] = met;
      j++;
  }

modify the code of LongSumAggregator ,first check for not null,it work well.
 static long combineValues(Object lhs, Object rhs) {
	if(lhs == null){
		lhs = 0L;
	}
	if(rhs == null){
		rhs = 0L;
	}
    return ((Number) lhs).longValue() + ((Number) rhs).longValue();
  }

I found  that pull requst #2257 can solve NPE when adding metric.
But I add following unit test on Build 0.9.1-rc1,still throw NPE
@Test
  public void testAddMetrics() throws IOException
  {
    IncrementalIndex index1 = IncrementalIndexTest.createIndex(new AggregatorFactory[]{
        new LongSumAggregatorFactory("A", "A")
    });
    closer.closeLater(index1);
    long timestamp  = System.currentTimeMillis();
    index1.add(
            new MapBasedInputRow(
                timestamp,
                Arrays.asList("dim1", "dim2"),
                ImmutableMap.<String, Object>of("dim1", "1", "dim2", "2","A",5)
            )
        );

    IncrementalIndex index2 = IncrementalIndexTest.createIndex(new AggregatorFactory[]{
        new LongSumAggregatorFactory("A", "A"),
        new LongSumAggregatorFactory("C", "C")
    });

    index2.add(
            new MapBasedInputRow(
                timestamp,
                Arrays.asList("dim1", "dim2"),
                ImmutableMap.<String, Object>of("dim1", "1", "dim2", "2","A",5,"C",6)
            )
    );

    closer.closeLater(index2);

    Interval interval = new Interval(0, new DateTime().getMillis());
    RoaringBitmapFactory factory = new RoaringBitmapFactory();
    ArrayList<IndexableAdapter> toMerge = Lists.<IndexableAdapter>newArrayList(
        new IncrementalIndexAdapter(interval, index1, factory),
        new IncrementalIndexAdapter(interval, index2, factory)

    );

    final File tmpDirMerged = temporaryFolder.newFolder();

    File merged = INDEX_MERGER.merge(
        toMerge,
        new AggregatorFactory[]{
            new LongSumAggregatorFactory("A", "A"),
            new LongSumAggregatorFactory("C", "C")
        },
        tmpDirMerged,
        indexSpec
    );
    final QueryableIndexStorageAdapter adapter = new QueryableIndexStorageAdapter(closer.closeLater(INDEX_IO.loadIndex(merged)));
    Assert.assertEquals(ImmutableSet.of("A","C"), ImmutableSet.copyOf(adapter.getAvailableMetrics()));

  }

can reproduce NPE

@Hailei @gianm Yep, I was able to reproduce as well, and think you are correct about what is going on.
I looked at #175 (which closes #145) and didn't actually see anything that addressed this issue. #2257 fixes a different case, so it would seem this bug is still present.
I think instead of checking for null in the Aggregator we can modify RowboatMergeFunction.apply
`      Object[] metrics = new Object[metricAggs.length];
Object[] lhsMetrics = lhs.getMetrics();
Object[] rhsMetrics = rhs.getMetrics();
  for (int i = 0; i < metrics.length; ++i) {
      Object lhsMetric = lhsMetrics[i];
      Object rhsMetric = rhsMetrics[i];
      if (lhsMetric == null) {
          metrics[i] = rhsMetric;
      } else if (rhsMetric == null) {
          metrics[i] = lhsMetric;
      } else {
          metrics[i] = metricAggs[i].combine(lhsMetric, rhsMetric);
      }
  }`

This avoids having to modify every aggregator type.

for (int i = 0; i < metrics.length; ++i) {
      Object lhsMetric = lhsMetrics[i];
      Object rhsMetric = rhsMetrics[i];
      if (lhsMetric == null) {
          metrics[i] = rhsMetric;
      } else if (rhsMetric == null) {
          metrics[i] = lhsMetric;
      } else {
          metrics[i] = metricAggs[i].combine(lhsMetric, rhsMetric);
      }
  }

@michaelschiff  I think it's the robust way to solve this issue

@Hailei, what would happen if both lhsMetric and rhsMetric == null?

@binlijin I think  that both lhsMetric and rhsMetric == null  is impossible. In most case,only one of them is null.

@binlijin @Hailei I have been able to reproduce the case where lhsMetric and rhsMetric == null in unit tests. I am not sure whether or not it would happen in practice, but it's definitely possible.
In this case, the value of metrics[i] is set to null. The unit tests still passes, but I could imagine potential funkiness at query time.

I think it good to handle all case.

@binlijin @Hailei I agree. To me the most correct thing to do in the case where rhsMetric and lhsMetric == null would be to supply a zero-value. However since the metrics are not typed at this point, this becomes trickier to do in RowboatMergeFunction.apply.  I would like to confirm whether or not a null metric value for this index is a valid solution. @gianm @drcrallen any thoughts?

@michaelschiff @binlijin @gianm @drcrallen
I have checked the code that is related to LongSum DoubleSum and HyperUnique Complex metrics(e.g HyperUnique)
I think all of these have checked for null.Both LongSum and DoubleSum ,if the value of metrics is null ,it will be converted to 0 int the process of build index.
But not sure all complex like this.
LongMetricColumnSerializer
 @Override
  public void serialize(Object obj) throws IOException
  {
    long val = (obj == null) ? 0 : ((Number) obj).longValue();
    writer.add(val);
  }

HyperUniquesBufferAggregator
 @Override
  public void aggregate(ByteBuffer buf, int position)
  {
    HyperLogLogCollector collector = (HyperLogLogCollector) selector.get();

    if (collector == null) {
      return;
    }

    HyperLogLogCollector.makeCollector(
        (ByteBuffer) buf.duplicate().position(position).limit(
            position
            + HyperLogLogCollector.getLatestNumBytesForDenseStorage()
        )
    ).fold(collector);
  }

HyperUniquesSerde
    @Override
      public byte[] toBytes(HyperLogLogCollector collector)
      {
        if (collector == null) {
          return new byte[]{};
        }
        ByteBuffer val = collector.toByteBuffer();
        byte[] retVal = new byte[val.remaining()];
        val.asReadOnlyBuffer().get(retVal);
        return retVal;
      }

@Hailei thats good news, in this case I think setting metrics[i] = null would be a valid solution.

@Hailei @fjy everyone good to close this?

Thanks  @michaelschiff


python39Packages.tensorflow-datasets build failure on x86_64-linux as of eb1f0837

Issue description
Build of python39Packages.tensorflow-datasets failed on x86_64-linux as of eb1f0837a05b77e4e771ae9c687af47391df2981. This is currently breaking python39Packages.tensorflow-datasets.
error: builder for '/nix/store/q0i66d87j1v36nkiz90zrrbwzlxgvdaj-python3.9-tensorflow-datasets-4.6.0.drv' failed with exit code 1;
       last 10 log lines:
       >
       > -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
       > =========================== short test summary info ============================
       > FAILED tensorflow_datasets/structured/ble_wind_field/ble_wind_field_test.py::BLEWindFieldTest::test_download_and_prepare_as_dataset
       > FAILED tensorflow_datasets/rlds/locomotion/locomotion_test.py::AntTest::test_download_and_prepare_as_dataset
       > FAILED tensorflow_datasets/rlds/locomotion/locomotion_test.py::Walker2dTest::test_download_and_prepare_as_dataset
       > FAILED tensorflow_datasets/rlds/locomotion/locomotion_test.py::HopperTest::test_download_and_prepare_as_dataset
       > FAILED tensorflow_datasets/rlds/locomotion/locomotion_test.py::HalfCheetahTest::test_download_and_prepare_as_dataset
       > FAILED tensorflow_datasets/rlds/locomotion/locomotion_test.py::HumanoidTest::test_download_and_prepare_as_dataset
       > ===== 6 failed, 2586 passed, 558 skipped, 4 warnings in 2010.93s (0:33:30) =====
       For full logs, run 'nix log /nix/store/q0i66d87j1v36nkiz90zrrbwzlxgvdaj-python3.9-tensorflow-datasets-4.6.0.drv'.

full build log
python39Packages.tensorflow-datasets maintainers cc: @ndl
python39Packages.tensorflow-datasets maintainers cc: @ndl
Other cc: n/a
Steps to reproduce

Checkout nixpkgs at commit eb1f0837a05b77e4e771ae9c687af47391df2981
Run nix-build -A python39Packages.tensorflow-datasets

Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.0-1019-azure, Ubuntu, 20.04.5 LTS (Focal Fossa), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.0`
 - nixpkgs: `/nix/store/ivn6xjm5pgcv5bkblwabm244y1z710ms-source`

Misc.
This issue was automatically generated by nixpkgs-upkeep.

CI workflow that created this issue.
Internal tags:<PHONE_NUMBER>885863138 -5901974656458221928

dup of https://github.com/NixOS/nixpkgs/issues/189057


Applicant - "My applications" page not translated

Description
"mes applications" page currently has English text... should have french
Required for Completion
Add/remove others as necessary for this specific task.

[ ] Run Lighthouse (Chrome Dev Tools)
[ ] Run WAVE Evaluation
[ ] Browser Compatibility Check
[ ] Update Translation Spreadsheet
[ ] Does this affect configuration? (If so discuss with team)
[ ] Create pull request to dev
[ ] Address issues found during peer review
[ ] Have someone else accept pull request into dev

Completed and merged


task: specify node version to reduce conflicts

This project relies on a specific node version(s), but doesn't specify it anywhere - causing conflicts when contributors with older versions installed set up the env.

I've never needed to do this in a project before. Which versions won't it work on? Is there a way to find that information?
__
  Summary: :question: I have a question

Ok, I think this is something I need more time to look into as it's not something I'm familiar with and don't want to cause more problems than necessary. I don't have node version manager because I'm using windows and it's not available on windows. I don't want to lock myself out of my own project next time I update node/npm. I also want this project to be something that is easy for beginners to open source to contribute to and I worry that adding extra requirements like this would be offputting. I know that such requirements have put me off contributing to projects in the past.

Hi folks. I agree with Emma that this kind of dependency and version hell is driving people away from contributing to the project. Nontheless I dare to add a few questions to this. If you consider them as too far from the topic, please ignore them and proceed. I am a newbie and I just forked and cloned this repo in wich I'm very interested. The following is concerning me and I am already on Stackoverflow to find out what it actually means for me.

I use Node v16.17.0 and npm v8.19.1. After running npm install i receive the following output. I'm only concerned about the boldened part in this message:

$ npm install
npm WARN deprecated<EMAIL_ADDRESS>Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-resolve#deprecated
npm WARN deprecated<EMAIL_ADDRESS>This SVGO version is no longer supported. Upgrade to v2.x.x.
<EMAIL_ADDRESS>prepare
husky install
husky - Git hooks installed
added 1489 packages, and audited 1490 packages in 23s
212 packages are looking for funding
run npm fund for details
7 high severity vulnerabilities
To address issues that do not require attention, run:
npm audit fix
To address all issues (including breaking changes), run:
npm audit fix --force
Run npm audit for details.
npm notice
npm notice New minor version of npm available! 8.15.0 -> 8.19.1
npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.19.1
npm notice Run npm install -g<EMAIL_ADDRESS>to update!
npm notice

I then thought to try the npm audit fix command to fix the issues without braking changes so I left the --force switch alone. This was the output after this command:

$ npm audit fix
changed 1 package, and audited 1490 packages in 18s
212 packages are looking for funding
run npm fund for details
npm audit report
nth-check  <2.0.1
Severity: high
Inefficient Regular Expression Complexity in nth-check - https://github.com/advisories/GHSA-rp65-9cf3-cjxr
fix available via npm audit fix --force
Will install<EMAIL_ADDRESS>which is a breaking change
node_modules/svgo/node_modules/nth-check
css-select  <=3.1.0
Depends on vulnerable versions of nth-check
node_modules/svgo/node_modules/css-select
svgo  1.0.0 - 1.3.2
Depends on vulnerable versions of css-select
node_modules/svgo
@svgr/plugin-svgo  <=5.5.0
Depends on vulnerable versions of svgo
node_modules/@svgr/plugin-svgo
@svgr/webpack  4.0.0 - 5.5.0
Depends on vulnerable versions of @svgr/plugin-svgo
node_modules/@svgr/webpack
react-scripts  >=2.1.4
Depends on vulnerable versions of @svgr/webpack
node_modules/react-scripts
6 high severity vulnerabilities
To address all issues (including breaking changes), run:
npm audit fix --force

There are still 6 high severe vulnerabilities in the dependencies left, but I won't use npm audit fix --force at this point. On Stackoverflow I was advised to user npm ci too. I executed this command and the result was the same as when using npm audit fix.

$ npm ci
npm WARN deprecated<EMAIL_ADDRESS>Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-resolve#deprecated
npm WARN deprecated<EMAIL_ADDRESS>This SVGO version is no longer supported. Upgrade to v2.x.x.
<EMAIL_ADDRESS>prepare
husky install
husky - Git hooks installed
added 1489 packages, and audited 1490 packages in 47s
212 packages are looking for funding
run npm fund for details
6 high severity vulnerabilities
To address all issues (including breaking changes), run:
npm audit fix --force
Run npm audit for details.

As mentioned before, this is only informational. I will use the project as it is now. After checking out to a new branch Development i ran npm start. This was the output i got:

$ npm start
<EMAIL_ADDRESS>start
react-scripts start
(node:6140) [DEP_WEBPACK_DEV_SERVER_ON_AFTER_SETUP_MIDDLEWARE] DeprecationWarning: 'onAfterSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.
(Use node --trace-deprecation ... to show where the warning was created)
(node:6140) [DEP_WEBPACK_DEV_SERVER_ON_BEFORE_SETUP_MIDDLEWARE] DeprecationWarning: 'onBeforeSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.
Starting the development server...
Compiled successfully!
You can now view color-palette-combos in the browser.
Local:            http://localhost:3000
On Your Network:  http://<IP_ADDRESS>:3000
Note that the development build is not optimized.
To create a production build, use npm run build.
webpack compiled successfully

The application is running smoothly on localhost:3000. Good enough for me to dig in the code. I only though I will post this here, because it might influence your decision of merging @colemars PR.
Have a good time.
Greetings Markus

Thanks for the extra information @MarkusEicher I really need to learn more about what this all means myself 😬

Hi Emma.
Sorry, if my comment was a little too extensive. 😜 I didn't want stirring it up or build confusion. The reason I commented this PR is, that Node.js has a system to track project dependencies which will be part of the project and tracked by Git. In my fork these dependencies may vary from the ones in someone others, depending on the version of Node.js in use. I do not already understand this matter enough, but it bothers me that in these dependencies there seem to be high severity vulnerabilities. If I now remove or mitigate them, then these will be reflected in my repo and occasionally be merged in the production branch. This might lead to problems for other contributors or users. This is not a problem of the code of this solution, but seems to be a thing to consider for all solutions using a certain version of Node.js. Sorry, I can't explain it better at this point. Don't worry too much about it. I will try to figure out what it's all about this issue, because I plan to learn and use Node.js for my projects too. If I find something helpful I will communicate it. Sorry for the flood, I promise to reduce the spam. 😎

Oh no, don't worry about that. I'm really glad for your comment and all the details. It helps me to know what to focus on and improve too!


Unable to randomize choices with randomize=true

Describe the bug
Choices cannot be randomized with the parameter randomize=true.
To Reproduce
survey

type
name
label
parameters

select_one numbers
num
Number
randomize=true

choices

list_name
name
label

numbers
1
One

numbers
2
Two

numbers
3
Three

numbers
4
Four

numbers
5
Five

Result:

Expected behavior
Same behaviour as Collect: choices are randomized.

Additional context
Report in KoBo community forum: https://community.kobotoolbox.org/t/seed-and-randomize-whats-that-preventing-to-deploy-my-form/4739/12

You’re running the latest version with https://github.com/enketo/enketo-core/pull/822?

Aha, we're not — still on 2.8.1 👌


Bug: Percy uploads should complete before “finalizing”

Looks like we have a Percy race condition which started recently and has caused a few flaky workflow runs
The problem
Percy CLI is "finalizing" a build early when more uploads are yet to complete (also reported by others):

https://github.com/percy/cli/discussions/1137

[percy:client] Finalizing build XXXXXXXX... (0ms)
[percy:cli] Error: Finalizing build XXXXXXXX failed: cannot finalize before all snapshot resources are uploaded. This is likely a client error, please make sure that content for all SHAs in 'missing-resources' from the snapshot response are uploaded before calling finalize.

The solution

Add the Percy --parallel flag so the door stays open for more uploads
Run the Percy build:finalize command when we know we're (really) complete

Potential related changes:

https://github.com/alphagov/govuk-frontend/pull/2993
https://github.com/alphagov/govuk-frontend/pull/3002
https://github.com/alphagov/govuk-frontend/pull/3020
https://github.com/alphagov/govuk-frontend/pull/3031

We may have also revealed this issue after adding Send Percy screenshots in batches 93cde6f in:

https://github.com/alphagov/govuk-frontend/pull/3009

This looks good to me.
It doesn't look like v1.16 changes anything, but worth merging #3039 before this one, just to see if something sorted itself?

Yeah, that's sensible
It'll be wise to either merge the --parallel flag anyway or, yep, hold off this PR entirely until we see the issue again

Going to close this one as (brilliantly) we've not seen any issues since recent fixes


Add RSS Support to Blog

Before submitting the PR:

[ ] Does your PR reference an issue? If not, please chat to the team on Discord or GitHub before submission.
[ ] Did you update and run tests before submission using npm run test?
[ ] Does your branch follow our naming convention? If not, please amend the branch name using branch -m new-branch-name
[ ] Did you update documentation related to your new feature or changes?

What does your PR address?
Please briefly describe your changes here.
Tips

Tap "convert to draft" to indicate this is work in progress.
Link to an issue using the verbiage Fixes #XX
Linked issues will auto-close when the PR is merged.

@luke-hagar-sp Here's the changes.
In the blog list page import the toast store and type:
import { toastStore, type ToastSettings } from '@skeletonlabs/skeleton';

Then add the following function to the bottom of the script tag:
function copyRSSToClipboard(): void {
    navigator.clipboard.writeText('https://www.skeleton.dev/blog/rss/');
    const t: ToastSettings = { message: 'RSS feed copied to clipboard.' };
    toastStore.trigger(t);
}

Finally, add the following to the start of the template, within the .page-container:

The Skeleton Blog

Keep up with the latest news, tutorials, and releases for Skeleton.

	<svg
		on:click={copyRSSToClipboard}
		on:keypress
		class="w-6 aspect-square cursor-pointer"
		xmlns="http://www.w3.org/2000/svg"
		xmlns:xlink="http://www.w3.org/1999/xlink"
		viewBox="0 0 455.731 455.731"
	>
		<g>
			<rect x="0" y="0" style="fill:#F78422;" width="455.731" height="455.731" />
			<g>
				<path
					style="fill:#FFFFFF;"
					d="M296.208,159.16C234.445,97.397,152.266,63.382,64.81,63.382v64.348
		c70.268,0,136.288,27.321,185.898,76.931c49.609,49.61,76.931,115.63,76.931,185.898h64.348
		C391.986,303.103,357.971,220.923,296.208,159.16z"
				/>
				<path
					style="fill:#FFFFFF;"
					d="M64.143,172.273v64.348c84.881,0,153.938,69.056,153.938,153.939h64.348
		C282.429,270.196,184.507,172.273,64.143,172.273z"
				/>
				<circle style="fill:#FFFFFF;" cx="109.833" cy="346.26" r="46.088" />
			</g>
		</g>
	</svg>

I've attached a screenshot if it helps:


Added Enemy AI

Types of changes
What types of changes does your code introduce to Appium?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description
Added Enemy AI, enemy will follow and be able to attack player and also take damage from player.
Will follow player when player reach certain distance and enemy will attack when reached to player at certain distance.
Checklist
Put an x in the boxes that apply.
You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[X] The code compiles and has no errors.
[ ] I have extended the README if necessary
[ ] All added code complies with the set guidelines.
[ ] I have added necessary documentation (if appropriate) to all added code.
[ ] Any dependent changes have been merged and published in downstream modules
[X] I have pulled the latest master into this branch to avoid merge conflicts.
[ ] I have created new issues for any new bugs that were caused by this pull request.

New bugs in this PR
Please describe new bugs that have occured in this pull request, also link the issues of said bugs.
Fixed bugs by this PR
If any, please link the issues of fixed bugs. If none, type "None"

@MadCoderr Could you double check the Checklist? If the code doesn't compile (which i assume it doesn't as the check isn't crossed) i won't merge any code as this would break the master branch
Also please do add documentation wherever possible to ensure everyone else is able to read your code


Please,add support for hiding unknown tags

Markwon version: 4.6.2

HtmlPlugin parses all tags.
Please, add support to parse and show only those tags that are predefined in INLINE_TAGS or BLOCK_TAGS or VOID_TAGS.

Hello @hakobyan1221 ,
would you say you need to parse only standard HTML tags and keep the rest untouched? It is not something that could be done easily. But it seems you might have better results by escaping non-standard HTML tags instead

Can you,please, tell how it's possible to skip non-standard HTML tags?That would help me also

For example, you could have a list of allowed tags. Then, before sending your markdown to the parser you could process it to substitute the < character to the <. This way HtmlParser won't be involved and your input for unlisted tags would be the same

For example, you could have a list of allowed tags. Then, before sending your markdown to the parser you could process it to substitute the < character to the <. This way HtmlParser won't be involved and your input for unlisted tags would be the same

But in that case all html tag won't be processed by parser

Yes, this is why you would need to process only non-supported tags. And ignore tags that should still be sent to the parser


"message": "Unknown operation named "undefined"."

I'm testing / debugging resolvers using GraphiQL. At times, seemingly prompted by restarting the backend app, I'll start getting responses like this:
{
  "errors": [
    {
      "message": "Unknown operation named \"undefined\"."
    }
  ]
}

Restarting the app or refreshing the GraphiQL page do not fix the error. However, cutting the query and pasting it back into the query window seems to resolve the issue.
Thanks.

Thanks for submitting the report, @shongololo. However, I think we might need a more concrete repro recipe. I know this might be hard, if the issue is intermittent; do you see it on every backend restart? Can you provide a little more detail about what versions you are running and how?

Even i facing this issue while calling mutations on my sample project.
Sharing few details :-
Mutation Query
mutation{
 toggleTodo(input:{
  id:"0"
}){
  todo{
    id
  }
}
}

Schema.js
const GraphQLChangeTodoStatusMutation = mutationWithClientMutationId({
  name : 'ToggleTodoStatus',
  description : 'Toggle status of todo',
  inputFields : {
    id: { type: new GraphQLNonNull(GraphQLID) },
  },
   outputFields: {
     todo: {
      type: todoType,
      resolve: ({localTodoId}) => getTodo(localTodoId),
    },
  },
  mutateAndGetPayload: ({id}) => {
   const localTodoId = fromGlobalId(id).id;
   toggleTodo(localTodoId);
   return {localTodoId};
 },
})

const Mutation = new GraphQLObjectType({
  name: 'Mutation',
  fields : {
    toggleTodo: GraphQLChangeTodoStatusMutation
  }
})

const Schema = new GraphQLSchema({
  query  : queryType,
  mutation : Mutation
})

Mock data
class Todo {}

let nextTodoId = 0

const todosById = []

addTodo('First task',false)
addTodo('Second task',false)

function addTodo(text,complete){
  const todo = new Todo()
  todo.complete = complete
  todo.id = `${nextTodoId++}`;
  todo.text = text;
  todosById.push(todo)
  return todo.id
}

function getTodos(){
  return todosById
}

function getTodo(id){
  return todosById[id]
}

function toggleTodo(id){
    todosById.map(function(todo,index){
    if(todo.id === id ){
    todo.complete = !todo.complete
    }
  })
}

module.exports = {
  Todo,
  addTodo,
  getTodos,
  toggleTodo
}

This happens when GraphiQL is trying to figure out which operation under the operationName it wants to run, as the query editor supports having multiple query contexts and running each query by specifying which one.
Are there some steps we can follow to reproduce the issue?

I'm not exactly sure what the root issue is, but I think this is due to saving state between runs. localStorage coerces everything to a String before saving it, so setting undefined results in getting "undefined".

I still hit this issue when using unnamed queries/mutations/subscriptions. The issue arises when entering a query, like:
mutation {
  someMutation(input: {
    clientMutationId: ""
  }) {
    clientMutationId
  }
}

If one enters this query, and executes it - everything works as intended. From here, a second reload will yield the error. If doing the exact same query but naming the operation, like this:
mutation MyMutation {
  someMutation(input: {
    clientMutationId: ""
  }) {
    clientMutationId
  }
}

Then no error occours.

Just confirming that I'm having the same problem @kastermester mentioned here. It's pretty annoying and really easy to reproduce, you just need to: run a unnamed mutation, refresh the page and run it again. I'm using the graphiql that graphql-server-express renders, which seems to be at 0.10.2.

I run into this from time to time as well. @leebyron is definitely correct that the string "undefined" is getting serialized in both localStorage and the search params:

My suspicion is that the latter (the search param) is the real culprit here, as simply deleting it resolves the issue, even though undefined remains in localStorage.

I have the same problem, how long would it take to fix this on your side? Are you working on it?

This is weird - after v0.10.0 release that includes the fix for the race condition in updating operationName and the queryFacts fix, this issue should have gone away. Basically I don't understand how (and cannot reproduce) the query without operationName can update the URL with "&operationName=undefined" - this code in example/index.html should guard from such a case.
I can reproduce this issue when I explicitly put &operationName=undefined in the address bar. I can put in a preventive fix not to update the URL when operationName === null, but it feels wrong since either I'm missing something here or something funky is going on.
@Durisvk @mairatma @kastermester Were you guys able to repro this issue from the example app in GraphiQL? Is there a different setup for you guys?

this code in example/index.html should guard from such a case.

@asiandrummer You need to propagate this change to express-graphql and other servers.
For example, see this: https://github.com/graphql/express-graphql/blob/master/src/renderGraphiQL.js#L86-L89

Just confirming that in my case this happens through express-graphql as well. Maybe it's just a matter of updating something there.

Got it - closing this issue here, opening/fixing in express-graphql. Thanks everyone.

I have the same issue here and I am not using express-graphql... I use hapi server and apollo-server for graphql...

@Durisvk Doesn't apollo-server use express-graphql to expose GraphiQL (asking since I haven't tried using apollo-server)

@asiandrummer That's the implementation detail I didn't study so I don't know, but I think they are using Hapi for GraphiQL since I am registering it as a plugin for Hapi like this:
server.register([{
        register: apolloHapi,
            options: {
                path: '/graphql',
                apolloOptions: (req) => {
                    const identity = options.safeGuard.authenticate(req);
                    return {
                        context: { identity },
                        pretty: true,
                        schema: graphqlConfig(options).executableSchema,
                    };
                },
            },
        },
        {
            register: graphiqlHapi,
            options: {
                path: '/graphiql',
                graphiqlOptions: {
                    endpointURL: '/graphql',
                },
            },
        },
    ]);

@Durisvk apollo-graphql doesn't use express-graphql, but it copies how GraphiQL can be rendered as a module.

Hello, same issue using this tutorial http://docs.graphene-python.org/projects/sqlalchemy/en/latest/tutorial/

@apoberez Any solution you found? I'm facing the same issue while following tutorial at http://docs.graphene-python.org/projects/django/en/latest/tutorial-plain/#getting-relations

Just hitting F5 reproduces this error.
For now, workaround is Ctrl+A, Ctrl+X, Ctrl+V and query runs normal.

For graphene-python users who can afford monkey-patching the python lib for development process, there is a simple solution:
in the file graphql/execution/utils.py at the beginning of init func of a class ExecutionContext you can paste something like
if operation_name == 'undefined':
    operation_name = None

This is happening to me too. Indeed, cutting and pasting the query fixes it! I'm using graphene-python with flask-graphql. GraphiQL is built in to flask-graphql.

seems your implementation might be running an outdated version of GraphiQL. can you confirm which version you are using? Do you have any more information about your particular implementation?

I am using Flask-GraphQL==2.0.1. By the source it seems they embed GraphiQL version 0.11.11.

@Hubro ah ok I see, yeah it's lockewd. I can open a PR to upgrade and improve the implementation a bit, but that would be up to the maintianer, unless pip allows you to install from my fork. I'd love to make sure flask users have an up-to-date implementation!

@acao I just opened an issue about it now... :P
https://github.com/graphql-python/flask-graphql/issues/75
A pull request would be neat!


Documentation omitting brackets

Plugin version: 0.4.1
When showing the function declaration (golang in this case) in the documentation, brackets seem to be omitted.
Actual: func(format domain.Format) mapstringdomain.Category
Expected: func(format domain.Format) map[string]domain.Category

Thank you for an awesome plugin 🚀
Configuration:
return {
	"saghen/blink.cmp",
	lazy = false,
	dependencies = "rafamadriz/friendly-snippets",
	version = "v0.*",
	config = function()
		local opts = {
			highlight = {
				use_nvim_cmp_as_default = true,
			},
			nerd_font_variant = "normal",
			accept = { auto_brackets = { enabled = true } },
			keymap = {
				show = "<C-n>",
				hide = "<C-e>",
				accept = "<C-y>",
				select_prev = { "<C-p>" },
				select_next = { "<C-n>" },

				scroll_documentation_up = "<C-b>",
				scroll_documentation_down = "<C-f>",

				snippet_forward = "<Tab>",
				snippet_backward = "<S-Tab>",
			},
			windows = {
				autocomplete = {
					border = "rounded",
				},
				documentation = {
					border = "rounded",
					auto_show = true,
				},
			},
		}

		require("blink.cmp").setup(opts)
	end,
}

This is still an issue in 0.5.0 I'm afraid, at least partially. When showing the documentation before accepting (or adding parentheses) the issue still remains, while accepting, or adding parentheses, it shows up correctly. Not anything urgent, but I just thought that I'd let you know.
The images below shows what I mean.

That commit hasn't been released yet, you might want to try on main

Oh, I'm sorry, I thought that it was included in the release, sorry for not checking that first.

I am facing this issue in 0.5.1
Here is the python snippet


Test runner seems to miss a certain category of static error

The following test contains an error:
class A {}

class B implements A, A {
//                   ^^
// [analyzer] unspecified
// [cfe] unspecified
}

Running the analyzer against this succeeds:
leafp-macbookpro:sdk leafp$ python tools/test.py -n analyzer-asserts-strong-mac tests/language/test_runner_issue_test.dart
Test configuration:
    analyzer-asserts-strong-mac(architecture: x64, compiler: dart2analyzer, mode: release, runtime: none, system: mac, nnbd: strong, enable-asserts, use-sdk)
Suites tested: language
[00:03 | 100% | +    1 | -    0]

=== All 1 test passed ===

Running the cfe against this fails:
leafp-macbookpro:sdk leafp$ python tools/test.py -n cfe-strong-mac tests/language/test_runner_issue_test.dart
Test configuration:
    cfe-strong-mac(architecture: x64, compiler: fasta, mode: release, runtime: none, system: mac, nnbd: strong)
Suites tested: language

FAILED: fasta-none release_x64 language/test_runner_issue_test
Expected: Pass
Actual: MissingCompileTimeError

--- Command "fasta" (took 05.000380s):
(cd /Users/leafp/src/dart-repo/sdk/ ; DART_CONFIGURATION=ReleaseX64 ./xcodebuild/ReleaseX64/dart ./pkg/front_end/tool/_fasta/compile.dart --verify --skip-platform-verification -o ./xcodebuild/ReleaseX64/generated_compilations/cfe-strong-mac/tests_language_test_runner_issue_test/out.dill --platform ./xcodebuild/ReleaseX64/vm_platform_strong.dill --nnbd-strong --packages=./.packages ./tests/language/test_runner_issue_test.dart )

static error failures:
- Missing expected unspecified error at line 3, column 22, length 2.

--- Re-run this test:
python tools/test.py -n cfe-strong-mac language/test_runner_issue_test
[00:05 | 100% | +    0 | -    1]

=== 0 tests passed, 1 failed ===

However, running the reproduction command above directly does in fact exhibit the correct error:
leafp-macbookpro:sdk leafp$ ./xcodebuild/ReleaseX64/dart ./pkg/front_end/tool/_fasta/compile.dart --verify --skip-platform-verification -o ./xcodebuild/ReleaseX64/generated_compilations/cfe-strong-mac/tests_language_test_runner_issue_test/out.dill --platform ./xcodebuild/ReleaseX64/vm_platform_strong.dill --nnbd-strong --packages=./.packages ./tests/language/test_runner_issue_test.dart
tests/language/test_runner_issue_test.dart: Error: 'A' can only be implemented once.
Try removing 1 of the occurrences.

Running the test runner in verbose mode shows that the error is reported there as well:
leafp-macbookpro:sdk leafp$ python tools/test.py -n cfe-strong-mac --verbose tests/language/test_runner_issue_test.dart
Test configuration:
    cfe-strong-mac(architecture: x64, compiler: fasta, mode: release, runtime: none, system: mac, nnbd: strong)
Suites tested: language
Running "fasta" command: (cd /Users/leafp/src/dart-repo/sdk/ ; DART_CONFIGURATION=ReleaseX64 ./xcodebuild/ReleaseX64/dart ./pkg/front_end/tool/_fasta/compile.dart --verify --skip-platform-verification -o ./xcodebuild/ReleaseX64/generated_compilations/cfe-strong-mac/tests_language_test_runner_issue_test/out.dill --platform ./xcodebuild/ReleaseX64/vm_platform_strong.dill --nnbd-strong --packages=./.packages ./tests/language/test_runner_issue_test.dart )

FAILED: fasta-none release_x64 language/test_runner_issue_test
Expected: Pass
Actual: MissingCompileTimeError

--- Command "fasta" (took 06.000007s):
(cd /Users/leafp/src/dart-repo/sdk/ ; DART_CONFIGURATION=ReleaseX64 ./xcodebuild/ReleaseX64/dart ./pkg/front_end/tool/_fasta/compile.dart --verify --skip-platform-verification -o ./xcodebuild/ReleaseX64/generated_compilations/cfe-strong-mac/tests_language_test_runner_issue_test/out.dill --platform ./xcodebuild/ReleaseX64/vm_platform_strong.dill --nnbd-strong --packages=./.packages ./tests/language/test_runner_issue_test.dart )

static error failures:
- Missing expected unspecified error at line 3, column 22, length 2.

exit code:
1

stdout:
tests/language/test_runner_issue_test.dart: Error: 'A' can only be implemented once.
Try removing 1 of the occurrences.

--- Re-run this test:
python tools/test.py -n cfe-strong-mac language/test_runner_issue_test
Done fasta-none release_x64 language/test_runner_issue_test: fail

=== 0 tests passed, 1 failed ===

I'm not sure if this is an error with the test runner static error parsing or with the way that the CFE is reporting the error, but tentatively assigning this to area-test.  Note that this is causing a spurious failure in these tests as seen here.
cc @munificent @johnniwinther

See also https://github.com/dart-lang/sdk/issues/45626

After https://github.com/dart-lang/sdk/commit/025bcc486d67027ea503563ad7b232095fa42f4f has landed, the error location is reported in the CFE, and the test run above succeeds for the CFE as well.

Closing because I think the test runner and CFE are playing nice together now.


Feature Request: A way to check for error on a command in orgInit.sh

Currently, if we have an error in a command then, most often, it will continue to try and run other commands which may also fail. We don't want to whitelist repos to allow users to use bash commands to check for errors.
If there can be a mechanism to see if previous command has failed and gracefully exit out of our script (maybe with a message) then that'll go a long way.
I tried to use BYOO in one of our orgs. The very first commands failed because community is not setup yet it continued to try and run other commands.
http://hosted-scratch.herokuapp.com/byoo?template=https://github.com/forcedotcom/WorkDotCom-Partners&email=required

I agree that sucks.  The counterargument:
sometimes things fail, and it's useful to be able to go into the org and debug why (bulk load jobs, permissions stuff, etc).  Or you open it and do a failed step rather than delete and start over.
We could make a environment variable to let the deployer's owner control the behavior...it'd be that plus a little change in the lines/commonBuild stuff.  Then you could decide what's the lesser evil.
The other approach would be to make fail=>bail the default behavior and add an optional parameter on the deploy request for &forcecontinue=true or something like that.
Thoughts?   Happy to get a PR around this.

@mshanemc
I think there is some confusion.
My previous experience was that if a command failed then execution will stop. But when I tried above, the script continued to run all the commands even though the first one failed.
I don't want it to continue on as you suggested with &forcecontinue=true. I want it to stop if a command fails. In almost all use cases we have, if a command fails then we want it to stop. Especially for BYOO where, for example, if a package install fails then we don't want to push the data as it will fail anyways
In addition, if there was a way to know about an error and display a custom message that could indicate possible issues then the user will know what to look for (even if it may not be that error but we can try and guess).


ChatSecure doesn't get closed

I'm using the last version on F-Droid (RC3) and, when I push "Close and shutdown" it get crashed and reboot itself (the app, not the phone)

Thanks! We've fixed this and will push out RC4 shortly.


[Event Request] Need add event to Codeunit "Purch.-Post" function CalcDeferralAmounts

Add, please event OnAfterInsertTempDeferralHeader to function CalcDeferralAmounts
    local procedure CalcDeferralAmounts(PurchHeader: Record "Purchase Header"; PurchLine: Record "Purchase Line"; OriginalDeferralAmount: Decimal)
var
    DeferralHeader: Record "Deferral Header";
    DeferralLine: Record "Deferral Line";
    CurrExchRate: Record "Currency Exchange Rate";
    TotalAmountLCY: Decimal;
    TotalAmount: Decimal;
    TotalDeferralCount: Integer;
    DeferralCount: Integer;
    UseDate: Date;
begin
    // Populate temp and calculate the LCY amounts for posting
    if PurchHeader."Posting Date" = 0D then
        UseDate := WorkDate
    else
        UseDate := PurchHeader."Posting Date";

    if DeferralHeader.Get(
         "Deferral Document Type"::Purchase, '', '', PurchLine."Document Type", PurchLine."Document No.", PurchLine."Line No.")
    then begin
        TempDeferralHeader := DeferralHeader;
        if PurchLine.Quantity <> PurchLine."Qty. to Invoice" then
            TempDeferralHeader."Amount to Defer" :=
              Round(TempDeferralHeader."Amount to Defer" *
                PurchLine.GetDeferralAmount / OriginalDeferralAmount, Currency."Amount Rounding Precision");
        TempDeferralHeader."Amount to Defer (LCY)" :=
          Round(
            CurrExchRate.ExchangeAmtFCYToLCY(
              UseDate, PurchHeader."Currency Code",
              TempDeferralHeader."Amount to Defer", PurchHeader."Currency Factor"));
        TempDeferralHeader.Insert();

        OnAfterInsertTempDeferralHeader(TempDeferralHeader, DeferralHeader, PurchHeader);

        with DeferralLine do begin
            DeferralUtilities.FilterDeferralLines(
              DeferralLine, DeferralHeader."Deferral Doc. Type".AsInteger(),
              DeferralHeader."Gen. Jnl. Template Name", DeferralHeader."Gen. Jnl. Batch Name",
              PurchLine."Document Type".AsInteger(), PurchLine."Document No.", PurchLine."Line No.");
            if FindSet then begin
                TotalDeferralCount := Count;
                repeat
                    TempDeferralLine.Init();
                    TempDeferralLine := DeferralLine;
                    DeferralCount := DeferralCount + 1;

                    if DeferralCount = TotalDeferralCount then begin
                        TempDeferralLine.Amount := TempDeferralHeader."Amount to Defer" - TotalAmount;
                        TempDeferralLine."Amount (LCY)" := TempDeferralHeader."Amount to Defer (LCY)" - TotalAmountLCY;
                    end else begin
                        if PurchLine.Quantity <> PurchLine."Qty. to Invoice" then
                            TempDeferralLine.Amount :=
                              Round(TempDeferralLine.Amount *
                                PurchLine.GetDeferralAmount / OriginalDeferralAmount, Currency."Amount Rounding Precision");

                        TempDeferralLine."Amount (LCY)" :=
                          Round(
                            CurrExchRate.ExchangeAmtFCYToLCY(
                              UseDate, PurchHeader."Currency Code",
                              TempDeferralLine.Amount, PurchHeader."Currency Factor"));
                        TotalAmount := TotalAmount + TempDeferralLine.Amount;
                        TotalAmountLCY := TotalAmountLCY + TempDeferralLine."Amount (LCY)";
                    end;
                    OnBeforeTempDeferralLineInsert(TempDeferralLine, DeferralLine, PurchLine, DeferralCount, TotalDeferralCount);
                    TempDeferralLine.Insert();
                until Next() = 0;
            end;
        end;
    end;
end;

Event:
[IntegrationEvent(false, false)]
local procedure OnAfterInsertTempDeferralHeader(var TempDeferralHeader: Record "Deferral Header"; DeferralHeader: Record "Deferral Header"; PurchHeader: Record "Purchase Header")
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Ability to restrict exposure via media source integration

Requesting configuration to reduce Frigate media source integration exposure to support camera privacy in a multi-user situation.
(even if it's all or nothing)
Discussion
The Frigate web ui does not currently provide user access controls, but .... it is possible to layer on access controls using a combination of proxy auth and/or firewall rules.
On the other hand, the Frigate integration exposes cameras and clips in a beautiful manner in the Home Assistant media browser, but it is impossible to control access to the Home Assistant media browser: When installed, all Home Assistant users have easy, unrestricted access to all cameras.
Naturally disabling the media_source integration seems like it would be a solution, but this doesn't appear to be possible. Even when removing default_config: from configuration.yaml and intentionally leaving out media_source: , HA 2022.2 may load the media_source integration anyway. This behavior is explained by the docs:

(the media_source) integration is configured automatically through default_config or if another integration implements a media source.

Bottom line is that Home Assistant 2022.2 does not provide the ability to disable the media browser, media source integrations, or limit access based on user id or user admin status.
Recommendations

Time permitting, recommend updating the frigate-hass-integration README that says,

Media Browsing
You will also need media_source enabled in your Home Assistant configuration for the Media Browser to appear.

Alternatives
For the benefit of all developers, the most ideal solution would be a universal Home Assistant method to control media browser integrations by administratively enabling/disabling media sources in the core ui, and/or a universal Home Assistant capability to restrict media sources by user or user type.
media_source is under active development, and recent Home Assistant media source integration enhancements result in a couple empty source icons in my setup. An example is a 'Nest' card that navigates to an empty page in my setup because there are only thermostats connected to my account and no media sources.
It may be an appropriate time to introduce a code change to Home Assistant itself.
Workarounds ineffective
For normal users, the media browser menu item can be hidden from plain sight an using a kiosk-mode HACS frontend integration - this is not an effective access control however. Even when using kiosk-mode ui modifications, the side nav menu briefly appears long enough for the media browser menu item to be activated after a couple of quick-handed attempts.

Are you asking to make it possible to disable the media browser entirely? It's not clear what you are asking.

Yes, sorry I'm intentionally being nonprescriptive, some of your design choices are exceedingly good so I'm trying to leave the solution open ended for your thoughts on the solution
One of the options is to have a configuration option to disable the media browser integration entirely. Not my favorite solution to the problem, but it would be an easy solution to the larger problem of uncontrolled camera access from the home assistant user interface.

One of the options is to have a configuration option to disable the media browser integration entirely. Not my favorite solution to the problem, but it would be an easy solution to the larger problem of uncontrolled camera access from the home assistant user interface.

Yes, either that or someone passionate on the feature need takes the request upstream and get it implemented in HA itself which would be a better overall solution (I'm a little surprised there isn't a way to do this).

I know there are others who would like to disable the media browser entirely, and I wouldn't mind taking this request upstream with a feature or pull request to ha core, but I'm not familiar enough with the media source integration to do that rn tbh

Fixed by @NickM-27 -- thanks Nick!

this change paired with a new haproxy rule, and frigate is offline to guest tablets, along with home assistant's cameras in the media browser
i love you man


Two captures on for a single draw to screen frame

Description
I have an application written in Java using LWJGL and GLFW. The render selected is opengl (I have a vulkan renderer which has no issues). The application renders to two frame buffers (3d and UI, both have a render buffer attached for depth) and then takes the textures and renders to default frame buffer (screen). So there are 3 frame buffers in use. I am using render doc to try and debug a uniform buffer issue so nothing actually draws at the moment because the matrixBuffer which has the mvp matrix is full of 0 data.

Describe what you see actually happening.

When starting my opengl application using renderdoc and setting the number of captures to 3, I am seeing renderdoc capture 2 captures when the application renders the first frame (the data is initialised before the frame is initially called). One after the GLFW window is created and one when I actually swap buffers and render something to the screen. The next capture happens after I trigger a new screen render to happen after moving the camera. Below is the log file generated by render doc for the first three captures. I added a pause after the window create code to prove the first capture came from there.
Log     - Got remote handshake: java [20196]
Log     - Used API: OpenGL (Not presenting & supported)
Log     - Used API: OpenGL (Presenting & supported)
31/10/2019 05:21:02.919 [DEBUG] [org.darkyellow.application.lwjgl.LwjglWindow.<init>()] Creating GLFW window via GLFW.glfwCreateWindow(800, 600, , null,null);
Log     - Got a new capture: 0 (frame 0) (time<PHONE_NUMBER>) 8227 byte thumbnail
31/10/2019 05:21:04.920 [DEBUG] [org.darkyellow.application.lwjgl.LwjglWindow.<init>()] Slept 2 seconds
31/10/2019 05:21:04.941 [INFO ] [org.darkyellow.application.lwjgl.LwjglWindow.<init>()] Monitor [293][165] Resolution[1920][1080]
31/10/2019 05:21:05.001 [DEBUG] [org.darkyellow.viewer.Viewer.initialise()] Initialisng application : entry point
31/10/2019 05:21:05.494 [DEBUG] [org.darkyellow.viewer.Viewer$1.run()] Initialise Engine
31/10/2019 05:21:05.498 [DEBUG] [org.darkyellow.viewer.Viewer$1.run()] Building render objects
31/10/2019 05:21:05.541 [DEBUG] [org.darkyellow.viewer.Viewer$1.run()] Finished building render objects
31/10/2019 05:21:05.541 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlScreenRenderPass.initialise()] *************** Initialise screen frame buffer
31/10/2019 05:21:05.541 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlRenderPass.initialise()] ************* Initialising FRAME BUFFER[Canvas3d Pass][0]
31/10/2019 05:21:05.556 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlRenderPass.initialise()] ************* Initialising FRAME BUFFER[Canvas UI Pass][0]
31/10/2019 05:21:05.591 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlRenderPass.render()] ************* Rendering FRAME BUFFER[Canvas3d Pass][2]
31/10/2019 05:21:05.601 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlRenderPass.render()] ************* Rendering FRAME BUFFER[Canvas UI Pass][3]
31/10/2019 05:21:05.602 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlScreenRenderPass.lambda$render$3()] *************** Rending to Screen frame buffer
Log     - Got a new capture: 1 (frame 1) (time<PHONE_NUMBER>) 8227 byte thumbnail
31/10/2019 05:21:06.999 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlRenderPass.render()] ************* Rendering FRAME BUFFER[Canvas3d Pass][2]
31/10/2019 05:21:07.007 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlRenderPass.render()] ************* Rendering FRAME BUFFER[Canvas UI Pass][3]
31/10/2019 05:21:07.009 [DEBUG] [org.darkyellow.application.lwjgl.opengl.pass.GlScreenRenderPass.lambda$render$3()] *************** Rending to Screen frame buffer
Log     - Got a new capture: 2 (frame 2) (time<PHONE_NUMBER>) 8227 byte thumbnail

The first capture causes a segmentation fault in renderdoc, the second capture correctly describes the 3d frame buffer as a color pass (although it has a depth render buffer attached too), but the ui frame buffer is not under any pass in renderdoc (its orphoned). For the 3rd capture both the 3d and ui come under a single depth pass label in renderdoc (so not labelled a color pass this time) but the render to screen pass is correctly labelled as a color pass.

Describe what you'd expect to see instead.

I am expecting to see a single capture on the first frame because there is a single call to swap buffers and 2 more captures captured after two render commands are executed via a camera move.
Repro steps
I can't share the application it self as its too complicated but I can share the 3 captures of an example run. I can also share the GLFW config used for creating the window. I can share specific bits of code if required
Captures -
java_2019.10.31_19.31.25_frame0.rdc.gz
java_2019.10.31_19.31.25_frame1.rdc.gz
java_2019.10.31_19.31.25_frame2.rdc.gz
Config -
GLFW.glfwWindowHint(GLFW.GLFW_RESIZABLE, GL_FALSE);
GLFW.glfwWindowHint(GLFW.GLFW_DECORATED, GL_TRUE);
GLFW.glfwWindowHint(GLFW.GLFW_VISIBLE, GL_FALSE);
GLFW.glfwWindowHint(GLFW.GLFW_RED_BITS, value);
GLFW.glfwWindowHint(GLFW.GLFW_GREEN_BITS, value);
GLFW.glfwWindowHint(GLFW.GLFW_BLUE_BITS, value);
GLFW.glfwWindowHint(GLFW.GLFW_OPENGL_PROFILE, GLFW.GLFW_OPENGL_CORE_PROFILE);
GLFW.glfwWindowHint(GLFW.GLFW_CLIENT_API, GLFW.GLFW_OPENGL_API);
GLFW.glfwWindowHint(GLFW.GLFW_CONTEXT_VERSION_MAJOR, 4);
GLFW.glfwWindowHint(GLFW.GLFW_CONTEXT_VERSION_MINOR, 5);

Environment
The RenderDoc version you are using (including the date or commit hash for nightly builds)

RenderDoc version: v1.4 packaged with apt
Operating System: Ubuntu 19.10 (happens on 19.04 too)
API: Opengl (vulkan works fine)

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.1
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

If you need any more information I will try and provide

Thank you for providing more information, I'll look into this tomorrow.
Can you please explain though why you have still not used the provided issue template? It is there for a reason, both to provide structure and organisation, as well as to make it easy for me to see that you have provided the required information.

Hi, re the format, sorry I thought I had followed the instructions this time. I entered the details as described below using the headings provided there.
https://github.com/baldurk/renderdoc/blob/v1.x/docs/CONTRIBUTING/Filing-Issues-Bugs.md
I have used the exact format as provided in the new comment so hopefully it is in the right format now.

The content of the report is fine but I wanted to know why you hadn't used the template in case there's something about the workflow I can improve, since it's new. I'll try to make it more clear that the template must be used, the documentation you linked explains what each section should include.

I only found one minor bug here, that in the frame0 capture the backbuffer size is 0x0 and that leads to creating an invalid texture. It seems that on intel mesa this causes a crash where other drivers report the error and survive. That commit fixes the behaviour so RenderDoc will ensure the texture is at least 1x1.
Other than that as far as I can tell, what is happening makes sense. You said:

[I start] my opengl application using renderdoc and setting the number of captures to 3

Which isn't entirely clear but going by the filenames it sounds like you're queueing a capture of 3 frames, starting from frame 0. Frame 0 begins when you create your first real context and ends at the first present, which looks to happen internally in glfw and produces the 0x0 empty frame. Then the next two frames are captured.
The reason that frame2.rdc is broken is a bug in v1.4 which has since been fixed as far as I'm aware. GL is a messy and ugly API, and many (most?) functions can be used for both one-time initialisation as well as regular state-setting/update, depending on how the application uses them. As an example with a VAO glEnableVertexAttribArray and glVertexAttribPointer could be called once at init time to set up the VAO, or they could be called per-drawcall with a single VAO to constantly update the parameters. In v1.4 there was a bug where if these calls were made only once but were recorded as part of a captured frame, they wouldn't then properly be recorded as 'initialisation' for subsequent frames. That's what has happened here, the calls have been captured in frame1.rdc and thus are missing for frame2.rdc leading to bad replay.
This bug was fixed in v1.5 which was released about a month ago, so if you you update to the most recent version of RenderDoc it should no longer produce bad captures or crash. Also unless you have a strong reason to capture the initialisation frames I would suggest using RenderDoc normally and capturing frames after your program has started.

I will grab the nightly build tomorrow to confirm the capture doesn't seg fault in frame 0
For the other issue with frame 2 I installed v1.5 manually and ran a similar test and it looked the same. Will look again in the nightly build tomorrow
BTW 1.5 seems doesn't render as well as 1.4 for me, I have a hidpi monitor which I run in a lower than max resolution and the app doesn't fit on the screen (the app window is larger than the monitor and I can't make it smaller so that it can fit). When running at the native resolution is looks different to 1.4 scale wise too.

FYI here's the mesa bug I reported.
If you're still seeing the missing FBO/VAO set up in frame 2 with v1.5 then I'll need more information on how to reproduce that. Unfortunately the capture itself alone is too late to know why the problem occurred.
Nothing changed between v1.4 and v1.5 in terms of DPI handling, that's all handled by Qt. When you say you installed it manually I guess that you mean that you ran the binary build from renderdoc.org, are you sure that it's actually a difference between v1.4 and v1.5, and not a difference between the apt package built for your distribution and the binary build built by me?

Re the DPI, It is most likely is to do with the packaging, especially after you have said nothing changed between 1.4 and 1.5, but wanted to raise just in case it wasn't

Quick update, can confirm the fix for mesa bug works in the nightly, renderdoc no longer crashes when opening a capture with 0x0 back buffer
Also 1.5 does actually fix the pass  being labelled as a depth pass rather than a color pass. I had made a mistake in my testing ( I wasn't testing the same setup). Thanks for all your help


[BUG] A JavaScript error occurred in the main process after select saving path.

Squirrel-Shortcut.log

Thanks for reporting. The only piece of code that contacts external servers in this app is to check for updates at initialization.
I know how to improve it.
Does the application crash (does it exit)? Or does it continue to work after that?

Thanks for reporting. The only piece of code that contacts external servers in this app is to check for updates at initialization.
I know how to improve it.
Does the application crash (does it exit)? Or does it continue to work after that?

It doesn't crash, and it keeps error every time app starting and other action.

Alright. I should release a fix later today or early tomorrow.

@HumanMus1c please test if v0.10.4 fixes your issue.

@HumanMus1c please test if v0.10.4 fixes your issue.

Thank you for your effort and this error has fixed on v0.10.5.


Flake8 rule 'E901' reported an invalid point

Flake8 reported an invalid point for the rule E901, with the messge SyntaxError: EOL while scanning string literal.
import gb_functions

Debug information:
Atom version: 1.16.0
Flake8 version: 2.5.5 (pep8: 1.5.7, mccabe: 0.2.1, ProxyChecker: 0.0.1, hacking.core: 0.0.1, pyflakes: 0.8.1, flake8-docstrings: 1.1.0, pydocstyle: 2.0.0) CPython 3.6.1 on Windows

Please update your flake8 version (pip install -U flake8). This particular error should be fixed in flake8>=3.2.1.

Closing due to a lack of response, if you are still having issues after updating flake8 please provide code to reproduce this!


Make remaining objc test jobs to pass on MacOS monterey

Make remaining objC jobs compatible with kokoro monterey workers and prepare for boringssl upgrade.
The changes here are taken from https://github.com/grpc/grpc/pull/32357, but they should be merged in a separate PR
(we need the changes to be able to upgrade to monterey anyway and there's no reason to make the boringssl upgrade PR more complicated by bundling more fixes into it).
I've checked that the grpc_basictests_objc_examples and grpc_ios_binary_size are green if switched to monterey.
Unfortunately it's hard to make grpc_basictests_objc_examples pass on both monterey and mojave, so I suggest merging this PR at the same time as CL to upgrade the kokoro jobs to monterey.

that way both PR and continuous runs will remain green
older branches would need a backport anyway

CC @HannahShiSFB

The CL to switch remaining objC jobs to monterey is here: https://critique.corp.google.com/cl/512999186

LGTM, Thanks Jan @jtattermusch

Adhoc runs on macos monterey(both green)
iOS binary size:
https://source.cloud.google.com/results/invocations/def82992-25c5-4274-ba3c-1fac19726387
ObjC examples:
https://source.cloud.google.com/results/invocations/5239887c-308d-498b-ae4b-700aac2f3ede

The ObjC swiftsample is failing in presubmit since the PR job is still running on macos mojave  (cl/512999186 will switch it to monterey).
https://source.cloud.google.com/results/invocations/fca57f00-17d3-4105-ab1c-74ca8509d289/targets


Mark Deleted Tables must be clear on the behaviour

Affected module
Ingestion Framework
Describe the bug
When running an ingestion workflow with the Mark Deleted Tables option enabled, it deletes all the tables not present in the source. But when a filter in the table name is set, it deletes all the tables that have been filtered out.
To Reproduce

Ingest data source
Edit ingestion with Mark delete table enabled and with a table filter.
Tables filtered out will be deleted.

Expected behavior
It depends on what we want to do here:

Remove only tables when they have been deleted in the data source, regardless of the table filter applied.
Determine what will be deleted when Mark Deleted Tables is enabled. For example, will the filter be considered?

Version:

OpenMetadata version: 0.13.2

Additional question
In addition, @pmbrull, should we remove the schemas when Mark All Deleted Tables instead of leaving the schemas empty?

we could clean up the schema, yes


Introduce Microwasm.

TBD

progress: 90% done for translation, 0% for direct interpreter

progress: 100% done for translation/compilation, 20% for direct interpreter

progress: 100% done for translation/compilation, 100% for direct interpreter
now debugging the implementation and the followings tests are not yet passed by the interpreter:
align.wast.wast
float_exprs.wast
labels.wast
left-to-right.wast
memory.wast
start.wast

6 cases in  float_exprs.wast are the only things to burn! 🔥

Passed all the spec tests!

I pulled some text from your PR desc into a RATIONALE.md. This will help as we make modifications, to have a place to store important "why"s

@codefromthecrypt thanks for the review on this massive PR :D


#4 Add Travis configuration file

@sladomic @AdrianoCelentano @adrygll2 @Alin-GFR @schaemik
Can you do a code review of this commit?

Yes, thank you
On Sep 22, 2016 11:45 AM, "Jo Grimstad"<EMAIL_ADDRESS>wrote:

@sladomic https://github.com/sladomic @AdrianoCelentano
https://github.com/AdrianoCelentano @adrygll2
https://github.com/adrygll2 @Alin-GFR https://github.com/Alin-GFR
@schaemik https://github.com/schaemik
Can you do a code review of this commit?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/literacyapp-org/literacyapp-analytics/pull/5#issuecomment-248856598,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASkKv1xT6f7964CoTZ0yGP_L3DH-BK58ks5qsk4ngaJpZM4KDs6_
.