PolyToStandard: handling tensors of poly?

@mr0re1 brought up a great review comment about lowering tensors of poly's to standard. https://github.com/google/heir/pull/134/files#r1312057016
Tensors of polys arise from BGV lowerings (and likely all other scheme lowerings to poly). When lowering to standard, we convert poly's to a tensor of ints.
Tensors of tensors are disallowed in MLIR - they are invalid tensor element types.
We have a few options here:
(1) Flatten the tensor: e.g. if we have a tensor polynomials, each of which are lowered to tensor<1024xi64>, then a size 2 tensor would become tensor<2048xi64>. However, this would appear to severely complicate the lowering math.
(2) Detensorize/lower to linalg and then lower to standard? E.g. inputs to PolyToStandard would not include tensors.
(3) It feels like I'm missing something - surely type conversion with tensors has been done before?

@j2kun very kindly reminded me we can just multi-dim the tensors

(1) Flatten the tensor: e.g. if we have a tensor polynomials, each of which are lowered to tensor<1024xi64>, then a size 2 tensor would become tensor<2048xi64>. However, this would appear to severely complicate the lowering math.

The tensor<2x1024xi64> seems to be more intuitive than tensor<2048xi64>.

Yep :) multi-dim it is. Haha it totally slipped my mind. I'll update with some code, I believe I need to add a type converter for ranked tensors, and then handle some tensor ops.
What's really strange is there's no interface pattern for this :/ which makes it really weird. Even if the type converter exists, I need to add support for converting ops like tensor.from_elements - I believe some conversions write a basic catch-all op converter that just changes types for these ops.

Let's chat a bit about the type conversion when you get back to this. I don't think the type conversion should be particularly hard...

From our HEIR meeting today I suggested we should be able to find a way to use upstream passes to map elementwise operations to loops, perhaps via linalg.
@AlexanderViand-Intel could you post your sample IR?

Sure, here's a minimal example, something like this also appears when lowering tests/bgv/to_polynomial.mlir:
func.func @test_bin_ops(%arg0: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>, %arg1: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) ->  tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>> {
  %0 = polynomial.add(%arg0, %arg1) : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
  return %0 :  tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
}

Trying to lower this with -polynomial-to-standard with the pass "as-is" (as of 04f6106b42e99a04f9382c71f855929f0f3a280f) simply crashes on this cast in ConvertAdd because the pass assumes the operands are polynomials but here they of course aren't.
Since the whole idea of traits like ElementwiseMappable is that we shouldn't have to re-invent the wheel, I tried applying the existing -convert-elementwise-to-linalg pass to the example, which results in:
#map = affine_map<(d0) -> (d0)>
func.func @test_bin_ops(%arg0: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>, %arg1: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) -> tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>> {
  %0 = linalg.generic {indexing_maps = [#map, #map, #map], iterator_types = ["parallel"]} ins(%arg0, %arg1 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>, tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) outs(%arg0 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) {
  ^bb0(%in: !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>, %in_0: !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>, %out: !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>):
    %1 = polynomial.add(%in, %in_0) : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>
    linalg.yield %1 : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>
  } -> tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
  return %0 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
}

However, from here I'm a bit stuck, none of the passes I tried would further simplify this in a meaningful way (e.g., convert it to loop).
Note that applying -polynomial-to-standard on the linalg.generic version as-is crashes because of unresolved materializations around yield, but adding builtin.unrealized_conversion_cast as materializers lets you run the pass and see what's going on a bit better:
#map = affine_map<(d0) -> (d0)>
func.func @test_bin_ops(%arg0: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>, %arg1: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) -> tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>> {
  %0 = linalg.generic {indexing_maps = [#map, #map, #map], iterator_types = ["parallel"]} ins(%arg0, %arg1 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>, tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) outs(%arg0 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) {
  ^bb0(%in: !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>, %in_0: !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>, %out: !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>):
    %1 = builtin.unrealized_conversion_cast %in : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>> to tensor<1024xi25>
    %2 = builtin.unrealized_conversion_cast %in_0 : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>> to tensor<1024xi25>
    %cst = arith.constant dense<33538049> : tensor<1024xi26>
    %3 = arith.extsi %1 : tensor<1024xi25> to tensor<1024xi26>
    %4 = arith.extsi %2 : tensor<1024xi25> to tensor<1024xi26>
    %5 = arith.addi %3, %4 : tensor<1024xi26>
    %6 = arith.remsi %5, %cst : tensor<1024xi26>
    %7 = arith.trunci %6 : tensor<1024xi26> to tensor<1024xi25>
    %8 = builtin.unrealized_conversion_cast %7 : tensor<1024xi25> to !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>
    linalg.yield %8 : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>
  } -> tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
  return %0 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
}

From here, we could think about how these builtin.unrealized_conversion_casts should be resolved and might arrive at something like this (manually adapted from the above) with multi-dimensional tensors:
#map = affine_map<(d0) -> (d0)>
func.func @test_bin_ops(%arg0: tensor<2x1024xi25>, %arg1: tensor<2x1024xi25>) -> tensor<2x1024xi25> {
  %0 = linalg.generic {indexing_maps = [#map, #map, #map], iterator_types = ["parallel"]} ins(%arg0, %arg1 : tensor<2x1024xi25>, tensor<2x1024xi25>) outs(%arg0 : tensor<2x1024xi25>) {
  ^bb0(%in: tensor<1024xi25>, %in_0: tensor<1024xi25>, %out: tensor<1024xi25>):
    %cst = arith.constant dense<33538049> : tensor<1024xi26>
    %3 = arith.extsi %in : tensor<1024xi25> to tensor<1024xi26>
    %4 = arith.extsi %in_0 : tensor<1024xi25> to tensor<1024xi26>
    %5 = arith.addi %3, %4 : tensor<1024xi26>
    %6 = arith.remsi %5, %cst : tensor<1024xi26>
    %7 = arith.trunci %6 : tensor<1024xi26> to tensor<1024xi25>
    linalg.yield %7 : tensor<1024xi25>
  } -> tensor<2x1024xi25>
  return %0 : tensor<2x1024xi25>
}

Unfortunately, this doesn't work because linalg.generic expects to be "looping" (conceptually) over all the dimensions:  error: 'linalg.yield' op type of yield operand 1 ('tensor<1024xi25>') doesn't match the element type of the enclosing linalg.generic op ('i25').  Of course, we could flatten tensor<2x1024xi25> into tensor<2048xi25> but that seems like a lot of work/boilerplate for something pretty messy.

I think if we had a pass that converted elementwise mappable things to affine.for instead of linalg.generic, which might look a bit like this:
#map = affine_map<(d0) -> (d0)>
func.func @test_bin_ops(%arg0: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>, %arg1: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) -> tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>> {
  %0 = affine.for %i = 0 to 2 iter_args(%a = %arg0) -> tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>> {
    %in = tensor.extract %arg0[%i] :  tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    %in_0 = tensor.extract %arg1[%i] :  tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    %1 = polynomial.add(%in, %in_0) : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>
    %t = tensor.insert %1 into %a[%i] :  tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    affine.yield %t :  tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
  }
  return %0 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
}

We could then handle the type conversion gracefully with multi-dimensional tensors.  I haven't yet found a pass that would do this (either going through linalg.generic or directly) that does this, but I've also not spent as much time with the "standard" part of MLIR as @j2kun  and @asraa so maybe you've got an idea here.

@AlexanderViand-Intel https://github.com/google/heir/pull/504 should show you how to convert to affine loops, though it still runs into the problem of a failed type conversion in --polynomial-to-standard, which I suspect is an unrelated bug.

@AlexanderViand-Intel #504 should show you how to convert to affine loops, though it still runs into the problem of a failed type conversion in --polynomial-to-standard, which I suspect is an unrelated bug.

Even my "manually converted" affine loop thing above runs into failed type conversion issues, which I think is because the type converter doesn't realize that it can convert from tensor<2x!poly.poly<...>> to tensor<2x1024xi25> (or whatever the poly in the tensor happens to convert to, so #504 might not be entirely unrelated?

I see what you're saying, but I would expect it to just type-convert the content of the memref opaquely. Maybe the problem is that you can't have a memref of tensors?

I don't think it's memref related, because lowering my example with the -polynomial-to-lower gives similar errors, and using the "augmented" version (with unrealized conversion cast) results in this:
func.func @test_bin_ops(%arg0: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>, %arg1: tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) -> tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>> {
%0 = affine.for %arg2 = 0 to 2 iter_args(%arg3 = %arg0) -> (tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) {
    %extracted = tensor.extract %arg0[%arg2] : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    %1 = builtin.unrealized_conversion_cast %extracted : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>> to tensor<1024xi25>
    %extracted_0 = tensor.extract %arg1[%arg2] : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    %2 = builtin.unrealized_conversion_cast %extracted_0 : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>> to tensor<1024xi25>
    %cst = arith.constant dense<33538049> : tensor<1024xi26>
    %3 = arith.extsi %1 : tensor<1024xi25> to tensor<1024xi26>
    %4 = arith.extsi %2 : tensor<1024xi25> to tensor<1024xi26>
    %5 = arith.addi %3, %4 : tensor<1024xi26>
    %6 = arith.remsi %5, %cst : tensor<1024xi26>
    %7 = arith.trunci %6 : tensor<1024xi26> to tensor<1024xi25>
    %8 = builtin.unrealized_conversion_cast %7 : tensor<1024xi25> to !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>
    %inserted = tensor.insert %8 into %arg3[%arg2] : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    affine.yield %inserted : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
}
return %0 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
}

If I add an explicit typeconversion then we get a bit closer (note the func has been handled properly):
func.func @test_bin_ops(%arg0: tensor<1024x2xi25>, %arg1: tensor<1024x2xi25>) -> tensor<1024x2xi25> {
  %0 = builtin.unrealized_conversion_cast %arg1 : tensor<1024x2xi25> to tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
  %1 = builtin.unrealized_conversion_cast %arg0 : tensor<1024x2xi25> to tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
  %2 = affine.for %arg2 = 0 to 2 iter_args(%arg3 = %1) -> (tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>) {
    %extracted = tensor.extract %1[%arg2] : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    %4 = builtin.unrealized_conversion_cast %extracted : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>> to tensor<1024xi25>
    %extracted_0 = tensor.extract %0[%arg2] : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    %5 = builtin.unrealized_conversion_cast %extracted_0 : !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>> to tensor<1024xi25>
    %cst = arith.constant dense<33538049> : tensor<1024xi26>
    %6 = arith.extsi %4 : tensor<1024xi25> to tensor<1024xi26>
    %7 = arith.extsi %5 : tensor<1024xi25> to tensor<1024xi26>
    %8 = arith.addi %6, %7 : tensor<1024xi26>
    %9 = arith.remsi %8, %cst : tensor<1024xi26>
    %10 = arith.trunci %9 : tensor<1024xi26> to tensor<1024xi25>
    %11 = builtin.unrealized_conversion_cast %10 : tensor<1024xi25> to !polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>
    %inserted = tensor.insert %11 into %arg3[%arg2] : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
    affine.yield %inserted : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>>
  }
  %3 = builtin.unrealized_conversion_cast %2 : tensor<2x!polynomial.polynomial<<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>>> to tensor<1024x2xi25>
  return %3 : tensor<1024x2xi25>
}

but it's still not quite there, because the affine.for isn't converted. I think this is because it's not part of the operations that addStructuralConversionPatterns handles. Do you know if there's an equivalent for affine, or do we need to manually mark it as a dynamically legal op?

I think I have an idea of how to handle this (and also #505), WIP here. It nearly works, but right now only with --verify-each=false because it produces invalid tensor.extract and affine.load operations.
The reason is that when we go from extracting a poly from tensor<2x!polynomial.polynomial<..>> to  triyng the same from a tensor<2x1024xi25>, we need to switch from tensor.extract to tensor.slice (and ditto for affine.load to affine.load_vector). I'll put together a PR later today.

I was thinking it would be nice to have these helpers upstream. I'll float the idea to the MLIR folks.

Reopening just to clean up the remaining comments

Digging this back up, as I noticed (as part of starting on #559) that poly.ntt and poly.intt aren't ElementwiseMappable and, in fact, can't be, because ElementwiseMappable requires that all non-scalar types match, and a "tensorized" version of an NTT might look something like this:
#ring = #polynomial.ring<cmod=33538049, ideal=#polynomial.polynomial<1 + x**1024>>
%0= polynomial.ntt %some_poly : !polynomial.polynomial<#ring> -> tensor<1024xi64, #ring> // normal NTT
%1= polynomial.ntt %some_poly_tensor : tensor<2x!polynomial.polynomial<#ring>> -> tensor<2x1024xi64, #ring> // tensor NTT

and so the ElementwiseMappable verifier will complain that "all non-scalar operands/results must have the same shape and base type".  In the future, it might be interesting to start a conversation upstream about the possibility of expanding ElementwiseMappable, but for now I'll just avoid adding the trait to the op and instead add a todo for custom patterns for poly.ntt and poly.intt to our elementwise-to-affine pass.

I'm re-opening this issue, as the problem mentioned above appeared again as part of #763 and therefore needs attention.


[Refactoring todo] Remove retryHandler from current implementation

In current implementation we have retryHandler in function internalExecute.
Retry - is responsibility of user.
Need remove this code from Command.php

is Retry for purpose of DeadLock or etc ? if yes , it's good thing to implement it in any approach

In current implementation - retryHandler may be using for all sql queries.

will not be decided


Two materialized views writing to the same table

CH MVs are insert triggers on the source table. It is possible to setup two or more MVs that write their records to a single table. from what I can tell the dbt MV implementation creates a destination table for each model.
Describe the solution you'd like
Is it possible to suppress somehow map a model to a different table so that it can be shared between two or more MV models?

I was thinking about this, although it sounds fairly easy to implement, its kinda a bit messy when it comes to deciding when to backfill with data from the second materialized_view model. Currently it backfills when the destination table does not exist. However, by the time the second model is built the destination model has already been built, so you cant use this method to decide to backfill. It seems that the second model needs to know if the first model performed a backfill in order to decide whether the second model should do a backfill.
An alternative approach might be to extend the materialized_view materialization code to somehow manage more than one materialized view. However, I think dbt really only supports specifying a single SQL statement so it is kinda difficult to see how this would work...

Here is an idea :
{{
  config(
     materialized='materialized_view',
     engine='ReplicatedSummingMergeTree',
     order_by='id'
     views=['mv1','mv2'],
  )
}}

--begin:mv1
select
    1 as id,
    sum(value) as total_value
from
    {{ ref("source1") }}
group by all
--end:mv1

union all

--begin:mv2
select
    1 as id,
    sum(value) as total_value
from
    {{ ref("source2") }}
group by all
--end:mv2

Basically, we have a single model that encapsulates SQL for any number of clickhouse materialized views that target the same destination table. Historical data is processed by retrieving the rows of the union of all sql statement blocks, but when each of the the materialized views are built, the materialization should extract the only the sql between the begin and end tags. The names of the materialized views ('mv1' and 'mv2') are explicitly specified in a config option, and each of these should have a single sql begin/end block.
The advantage of this is that we dont have the issues above regarding how to populate the historical data as we are just using a single query to do this at table creation time (just like how it works at the moment). Secondly, it nicely encapsulates all the sql relating to the final destination table so it is easier to understand what is populating it. Lastly, we retain all the linkage from and ref() and source() functions used in the body sql.


Annotation @KeySpace is ignored and default keyspace resolver is always used

I use org.springframework.vault:spring-vault-core:3.0.3 and have faced an issue that keyspace is always set to simple class name and value from annotation KeySpace is ignored.
Looks like the reason for this in org.springframework.data.keyvalue.core.mapping.BasicKeyValuePersistentEntity constructor updates
It was
public BasicKeyValuePersistentEntity(TypeInformation<T> information,
		@Nullable KeySpaceResolver fallbackKeySpaceResolver) {

	super(information);

	Class<T> type = information.getType();
	String keySpace = AnnotationBasedKeySpaceResolver.INSTANCE.resolveKeySpace(type);

	if (StringUtils.hasText(keySpace)) {

		this.keyspace = keySpace;
		this.keyspaceExpression = detectExpression(keySpace);
	} else {

		this.keyspace = resolveKeyspace(fallbackKeySpaceResolver, type);
		this.keyspaceExpression = null;
	}
}

Now it is
public BasicKeyValuePersistentEntity(TypeInformation<T> information, @Nullable KeySpaceResolver keySpaceResolver) {
	this(information, keySpaceResolver != null ? keySpaceResolver.resolveKeySpace(information.getType()) : null);
}

See https://github.com/spring-projects/spring-data-keyvalue/blob/a46f3487835f2a048ca9d03047da6eff8712b31e/src/main/java/org/springframework/data/keyvalue/core/mapping/BasicKeyValuePersistentEntity.java#L55
At the same time the signature for org.springframework.vault.repository.mapping.VaultMappingContext::createPersistentEntity did not changed.
See
@Override
protected <T> VaultPersistentEntity<?> createPersistentEntity(TypeInformation<T> typeInformation) {
	return new BasicVaultPersistentEntity<>(typeInformation, this.fallbackKeySpaceResolver);
}

It leads to situation when fallback key space resolver is always used which is SimpleClassNameKeySpaceResolver.
I run it during Spring Boot 3.1 upgrade, works fine with Spring Boot 2.7.5.

Thanks for bringing this up. In Spring Data KeyValue 3.1, KeyValueMappingContext has changed its behavior. If a KeySpaceResolver is used, then it will be used instead of using the resolver as fallback. That has the consequence that VaultMappingContext, which specifies a SimpleClassNameKeySpaceResolver, resolves the keyspace from the class name and no longer from the annotation.
As workaround, you can call VaultMappingContext.setFallbackKeySpaceResolver(null) to let the infrastructure use annotations. Entities that are not annotated will resolve to the full classname instead of an uncapitalized simple name.


[node-pod] 2. Setup API type definition configuration

Background
REST
This should be to setup a place to put API type definitions and ensuring out-of-the-box API type definitions are available.
GraphQL
This should be to setup GraphQL codegen so types are auto-generated.
Acceptance

[ ] Add methods for generating API project types for consumption

I did not find a good package that would generate typescript types for API return values.
TypeOrm Entities are the closest things to how data looks like, but those are not reusable on the front-end.
AFAIK REST is not that similar to graphQL. With graphQL we need to define a schema, that can be used to generate types, but in express REST apis we don't define schemas.
I did not find anything that would allow us to automatically generate types for us that could be used on the front-end based on the result values sent back.
cc @dustinsgoodman what do you think, how should we proceed with this?

What about https://www.npmjs.com/package/openapi-typescript? Looks like if we're using OpenAPI, it can just convert those request/responses to types.


BUILD_LIBRARY_FOR_DISTRIBUTION = YES;

Hello.
Thank you for Kingfisher.
In this pull request I added BUILD_LIBRARY_FOR_DISTRIBUTION = YES; to project.pbxproj. It will be useful for developers who are using different Swift versions.

If I am correct, this flag is basically for building xcframework. The prebuilt ones are already provided in the release page https://github.com/onevcat/Kingfisher/releases

If I am correct, this flag is basically for building xcframework. The prebuilt ones are already provided in the release page https://github.com/onevcat/Kingfisher/releases

Hello @onevcat
For example, if you install Kingfisher via Carthage, you should run carthage bootstrap every time you switch Swift/Xcode version. I think that with BUILD_LIBRARY_FOR_DISTRIBUTION = YES; it is not necessary.

Thank you for the explanation.
However, according to Apple's suggestion:

Library evolution support should only be used when a framework is going to be built and updated separately from its clients. In this scenario, a client built against an old version of the framework can be run with a new version of the framework without being recompiled.

As an open-source project, Kingfisher obviously doe not fall into this. You can (and should) always compile this framework as your product binary. I guess it is more likely an abusing of the BUILD_LIBRARY_FOR_DISTRIBUTION flag to bypass the carthage build when not using the same compiler.
I am closing it since the current behavior is intended.


Readme code syntax

Just a little fix.

Codecov Report

Merging #256 into master will decrease coverage by 0.79%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #256      +/-   ##
============================================
- Coverage     87.19%   86.39%   -0.80%
+ Complexity      401      400       -1
============================================
  Files            78       78
  Lines          1577     1573       -4
  Branches         81       81
============================================
- Hits           1375     1359      -16
- Misses          176      187      +11
- Partials         26       27       +1

Impacted Files
Coverage Δ
Complexity Δ

...edlock/provider/redis/jedis/JedisLockProvider.java
71.42% <0.00%> (-20.41%)
6.00% <0.00%> (-1.00%)

...bs/shedlock/provider/jdbc/JdbcStorageAccessor.java
79.36% <0.00%> (-2.73%)
9.00% <0.00%> (ø%)

...ider/jdbctemplate/JdbcTemplateStorageAccessor.java
94.73% <0.00%> (-2.64%)
12.00% <0.00%> (ø%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9df38eb...18571c7. Read the comment docs.

Thanks


autocomplete: Remove mistaken paragraph in onSelected doc

Fixes #130187.
Fixes #130187 by removing the mistaken paragraph; see there for details.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Thanks for the review!


Use the same image tags in CI and CD

Fixes #4777
Fixes #4776

Proposed Changes

Use the same image tags for both CI and CD workflows.
Dynamically set the image ID in Makefile
Remove unneeded coverage report commands from Makefile

Readiness Checklist
Author/Contributor

[x] If documentation is needed for this change, has that been included in this pull request

Reviewing Maintainer

[x] Label as breaking if this is a large fundamental change
[x] Label as either automation, bug, documentation, enhancement, infrastructure, or performance

@zkoppert: we might need to tune branch protection rules because of the rename of the slim job :)


Rowanize  gtoolkit-gemstone

@akgrant43 ... I created the Rowan script to generate the Rowan meta data for gtoolkit-gemstone (rowan/scripts/rowanize.st), however when I tested the install script (rowan/scripts/installGtoolkit-gemstone.topaz), I ran into a couple of problems:

the class SyntaxErrorNotification is not present in GemStone
Pharo's package naming convention and class category naming convention is incompatible with both of Rowan's package naming conventions (Monticello and RowanHybrid). Rowan's Rowan package naming convention would work, but currently Jadeite does not support the Rowan package naming convention yet. In particular, Rowan's Monticello naming convention is based on supporting the original Monticello package naming scheme that allows for adding "extensions" to class categories as seen here and for method categories. However, the two package names: GToolkit-GemStone and GToolkit-GemStone-GemStone are ambiguous package names in the original Monticello scheme and Rowan's Monticello package convention. Rowan's RowanHybrid naming convention can handle the two package names above, but the "hybird" part of the naming scheme is that both class categories and method categories must match the package name. Consequently, I had to edit the source code and change the class categories here and here

Sooo, instead of giving you a script to run, I'm providing you with a pull request with the Rowan meta data and code patches. As menioned earlier, I've included the rowan/rowanize.st script for your viewing pleasure.
I left the GemStone baselines hanging around, but they can be removed at your leisure ...

Hi Dale,
Thanks!  I knew about SyntaxErrorNotification, it just got lost in my manually copying the code from GemStone to Pharo.


Adjust default for --max-py-version to 3.10

Noticed this while working on https://github.com/pytest-dev/pytest/pull/8494, however I'm not sure you want to change defaults given 3.10 is not out yet.

I do this once 3.10 has been released.  imo it's not correct to have a 3.10 specifier until you know that your thing works with 3.10 final


Accounts list implies the parameters are optional

Using "https://app.vssps.visualstudio.com/_apis/accounts?api-version=5.0" with no other query parameters fails with the following response.
"$id":"1","innerException":null,"message":"Necessary parameters ownerId or memberId were not provided in the request.","typeName":"Microsoft.VisualStudio.Services.Account.AccountException, Microsoft.VisualStudio.Services.WebApi","typeKey":"AccountException","errorCode":0,"eventId":4236}
The parameters are not indicated by the documentation as being necessary.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a67ff0c9-996f-0c14-b22e-7a66ea5bfedd
Version Independent ID: 7e3d639c-24d0-2ad0-4944-92047076bc31
Content: Accounts REST API for Azure DevOps Services - Azure DevOps Services REST API
Content Source: docs-ref-conceptual/5.0/account/index.md
Service: vsts
Product: devops
Technology: devops-ref
GitHub Login: @wnjenkin
Microsoft Alias: elbatk

+1

+1

Any news on this?
Request https://app.vssps.visualstudio.com/_apis/accounts?api-version=7.2-preview still returns error Necessary parameters ownerId or memberId were not provided in the request.


As mentioned in the README, this requires Go 1.8+ to build. You can download a static build of the latest Go release for Linux from their site, it comes with no external dependencies and can simply be un-tarred in /usr/local. Just make sure to add /usr/local/go/bin to your PATH (at least temporarily) and you're all set to build stuff.

Alternatively, build it on one machine and simply copy the resulting binary to another machine (of the same architecture). Go produces static binaries with no external dependencies, so the result would be the same regardless of what machine you build it on.

Sorry for not reading the correct dependency.
Thanks for explanation. One of the IMHO few times static linking shows its advantage.


Ped File

Hi,
Would it be possible to add a flag, or functionality so the Ped file's Phenotype column could be interpreted as 0/1/-9 instead of the 1/2/0/-9 notation?
Thanks!

Guess so, do you mean:
0=unaffected
1=affected
-9=unknown

?

Yep, that's exactly what I mean

Hi again,
after some consideration i'm not sure if this is a good idea.
We have a standardised ped format, why would you leave that and add potential misunderstandings?
Måns

In hindsight you're probably right, and feel free to close the issue. I generally adopted the 0 and 1 approach because it seemed more logical to me, but if the standard is 2 (affected), and 1 (unaffected), then there's no need to add another standard (https://xkcd.com/927/)

Haha Yes


Is enabling all CSS properties a good idea?

Some reactions on twitter pointed out that supporting queries for all properties may not be the best idea.

Maybe a plug-in style call with a sensible default set of properties?

The way how the prolyfill works it supports all properties. Special rules only apply for width, height and background-color. I could add code to ignore container queries with unsupported properties, but if someone uses a property in a container query they want support for it anyways.
Maybe it would be a good idea to add a list of supported, tested and recommended properties to the readme. What do you think would be a good set of properties? width, height, background-color, text-align and font-size?

Allowing all properties to be queried is totally legit. No one has pointed out a use case where this leads to problems yet.
The only problem I see is that component authors could add random rules like bumping the font size up if the background color is pink. Nevertheless adding a rainbow background when the parent is 428px wide would be random too. Odd design choices can't be prevented by the tool.

As long as they don't affect performance if unused, I don't see an issue for non-layout properties to be available (background color, text-align, etc).

Thanks for your feedback!
So I will leave it as it is now and support all properties. I added a note to the documentation pointing that out.

I think the most worrisome part about it is that it's syntax strays from any other in CSS by using the equal sign. I don't think there's an alternative, however. It's all about weighing the pros and cons.

I think this is one of those situations where the problem has been made up just to have a problem. If you do not wish to use certain properties for container queries you're free to not use them.
99% of people will most probably only use the width and height properties anyway (as with regular media queries), so catering for people who might accidentally use text-shadow or something as a container query basis is wasted time.
What I would suggest is allow them all, and then add a disclaimer that your mileage may vary when using stranger properties for container querying.
And who knows, someone might come up with unique, reproducible, and awesome approaches to tricky UI problems using the stranger container query properties.

@rask Thanks for your feedback.
The current state is like you suggested it, I wrote in the usage docs:

Technically all CSS properties are supported, but that doesn’t mean you should use them all. The following properties are most useful and tested: width, height, background-color, color, text-align, font-size and custom properties.

As it seems we all share the same opinion here that it is OK as it is now, I close this issue.
@VinSpee I opened an issue about the syntax differences to media queries: #8


feat: create virtual machine

Implement initial module which creates a simple Linux or Windows VM.
Implement initial unit tests in the tests directory.
Implement GitHub workflow .github/workflows/test.yml that runs unit tests for PRs.
Implement initial usage examples in the examples directory.
Update README.md with short description, development instructions and testing instructions.

In Windows example, did you set kind = "Windows" ?

@sebastianlolv Good catch. Will fix and request a review from you.


add input id to search  if present on ui-select directive as input-id

fixes https://github.com/angular-ui/ui-select/issues/1195
fixes https://github.com/angular-ui/ui-select/issues/236

basically a copy of @georeith 's #237 #238

Can you add one simple test to it so we can merge asap?

tests added!
(sorry for the whitespace cleanup, my editor couldn't help itself).


Bump version to v0.6.0

I'm doing a minor update along with a stricter react peer dependency to
match the deprecation of the unsafe lifecycle methods.

Can we get this merged?  Seems this will benefit anyone using @nivo stuff for charts...


MS POWER TOYS- Keyboard manager  KEY STUCK

Microsoft PowerToys version
0.84.1
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
Keyboard Manager
Steps to reproduce
remap your any key top ctrl or shift  and do cpu intresic tasks
✔ Expected Behavior
it should work fine
❌ Actual Behavior
but the ctrl get stuck as if it is permanently pressed and it only fix itself after a restart
Other Software
No response

Also have the same problem with shift and ctrl keeps hanging random while using them in a macro in "Keyboard Manager"

I can confirm this issue as well. Once I reverted back to version 0.83.0 the problem is gone.

/dup https://github.com/microsoft/PowerToys/issues/22346


Warn about syntax error in datasource url (with env var) earlier #3509

See https://github.com/prisma/prisma/issues/3509

@pantharshit00  Is this just a duplicate of https://github.com/prisma/prisma/issues/3509? This belongs in the prisma or Prisma-engines repo, since this needs to be solved in prisma-fmt.

prisma/prisma#3509 was also tracking that prisma generate also doesn't fail which should.
I opened it here as well so that we don't miss the vscode squiggly line part of the issue.

This might be tricky to do as we intentionally ignore errors in the url argument within vscode.


Any consideration of publishing the GLSL code?

Great Work.
Can you please consider publishing the GLSL or Unity code of the sigma-map predictor?

Thank you for your interest in our work. OpenGL and Unity applications have already been available on the project webpage for a while. I also added a link to README.md.


updates to multi lock & dtlaunch

Small improvements to two apps based on suggestions from @zloid.

make multiclock pin selected clock face so that it will return to it after running other apps

allow cyclic scrolling through pages it dtlaunch

Nice - thanks!

Nice - thanks!


BE-2: Meeting Notes Week #3 Backend Meeting #1

To Do

Take notes during the meeting.
Create the wiki page.
Add links to Sidebar and Homepage.

Deadline
18.10.22 @23.00
Additional Information
Reviewer: @mumcusena

Documented our meeting notes here.

Closing the action, no additional action is required.


Add option to stake with the wallet

I don't know if it's possible but it would be great to be able to stake directly from the wallet.
Greetings

there is no staking in the counterparty protocol, so not sure what your referring to.


Update README.md

Thanks for the submission! Would you mind naming your project to differentiate it from the orignal vue-touch? I think the original vue-touch in fact works with 1.0 if using the correct syntax, and we will eventually update it. It's better to avoid indicating that your project completely replaces the original vue-touch.

Yes you're right v-touch ?


Feat: OME-Zarr transcode support

Adds support for transcoding a directory of images (either IMS, HDF5, or TIFF) to OME-Zarr fomat.
Closes #2
Closes #3
Closes #11

ERROR: Package 'aicsimageio' requires a different Python: 3.7.14 not in '>=3.8'
We may want to consider splitting up the repo if Python < 3.8 is a strict requirement.

@jtyoung84 @carshadi aicsimagio main says it actually doesn't even support 3.7.14 anymore...
https://github.com/AllenCellModeling/aicsimageio/blob/8099b70ac5ffb555ce009c1c9c7a3de0de71d993/setup.py#L163

@dyf My bad, it's the opposite problem. 3.7 is no longer supported. I have no problem if we bump the minimum version up to 3.8

ERROR: Package 'aicsimageio' requires a different Python: 3.7.14 not in '>=3.8'
~We may want to consider splitting up the repo if Python < 3.8 is a strict requirement.~ My bad, it's the opposite problem. Python 3.7 is no longer supported. I'm fine if we make the minimum supported python 3.8.

Yeah, I've been using python=3.10 for development, >=3.8 sounds good to me

Cool. I think both the pyproject.toml file and the github workflow ci.yml file need to be updated to remove the 3.7 dependency


chore: adjust labels

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Change "Log" position

Move "Log" textarea below the download button and ship properties, and to the lower right of the content preview.

Implemented in 9cbde1d5a8725710d3aebf89f808d579b42b1a9d

Temporarily reverted since the "Content Properties" now takes up roughly the same amount of vertical space as the "Selected Spaceship".
Awaiting feedback.

Looks good, let's wait for Erin's feedback.

Closed with 98b5dd3c70828e32f3fc8a1abf3c79c439c503e2


Adds a layer with labels to new tables if default basemap has labels on top

For new maps, we copy the base layers of the first selected map.
cc// @Kartones

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

:+1:

Fixes #4287

Frontend tests were OK :+1: (details)


Add ILI9341 support

This set of commits adds lvgl driver support for the ILI9341 controller based LCDs via the SPI data interface.
Common Variants
https://www.amazon.com/HiLetgo-240X320-Resolution-Display-ILI9341/dp/B073R7BH1B
https://www.adafruit.com/product/1770
Data Sheet
https://www.newhavendisplay.com/app_notes/ILI9341.pdf
References

Linux Source [v5.9-rc4] "drivers/staging/fbtft/fb_ili9341.c"
https://github.com/adafruit/Adafruit_ILI9341/blob/master/Adafruit_ILI9341.cpp
https://os.mbed.com/users/dreschpe/code/SPI_TFT_ILI9341

Thank you Derald, it looks good!


Sendgrid Error Handling and JSON Conversion

Sendgrid Client

I really appreciate your doing this. Couple of questions.
I haven't done any profiling, but why did you decide to go the Dictionary/NSJSONSerialization route over Node/Jay?
Are there a finite number of SendGrid errors such that we could enumerate them explicitly in code rather than returning s struct with strings?


Provide a bower package file and set version to 0.4.0

This update provides Bower support with a package file, and resolves #9.
Additionally, openfb.js was moved into a dist directory, which provides a common directory layout where a minified version could also be provided.
After merging, you can register the component so that it is discoverable with the following:
$ bower register openfb https://github.com/ccoenraets/OpenFB

This will allow anyone to then run bower install openfb to install the library.
You will also need to create and push a git tag that corresponds to the version number so Bower can pick it up.
You can do this easily enough by tagging a release, or just issuing the following:
$ git tag v0.4.0
$ git push origin v0.4.0

That should about do it. Cheers!

Implemented in 0.5


Fix */TestCLI/agent_CLI/agent_check_-r_container e2e test

What does this PR do?
Fix the parsing of the output of agent check in the */TestCLI/agent_CLI/agent_check_-r_container e2e test.
Motivation
Whereas this test is currently passing on kind, it is flaky of EKS.
Additional Notes
Depending on the environment, the container check can report different metrics.
As the --table output format is aligning the fields, the number of spaces between fields can vary.
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes
Validate that */TestCLI/agent_CLI/agent_check_-r_container e2e test is less flaky.

/merge


Failed to map 'CornerstoneTools@4'

JS error  triggers on viewer load

Failed to map 'CornerstoneTools@4' measurement for definition stack...

Most of the measuring tools (except for the length tool), when used, will show similar error messages. What can be the cause of this? is cornerstoneTools not being loaded properly? build issue or configuration error? Despite the error the tools work in the viewer as expected but on the measurements tab show an "unsupported tool" sign

Ah, those should be warnings, not exceptions. We're improving how measurements are stored and exposed by the OHIF platform internally. The MeasurementService will eventually replace cornerstone-tools "ToolState" as the source of truth for measurements, and provide some niceties around mapping measurements between the different shapes/schemas expected by various 3rd party libraries and extensions.
The "not supported" warning in the UI is specific to what we can and cannot support for persisting with DICOM SR at this time. We currently only persist Length, but are looking to add support for bidirectional in the near future.
Other tools will likely eventually have support as well, but I'm not sure where they fall on our roadmap. If someone is interested in adding additional support, I could preemptively scope the issues that lay out guidance for what we would be looking for in a PR.

CC: @igoroctaviano ^

Thanks Danny, do you know how can i get the details of the tool
measurements done by the user. I mean, if I draw a rectangle for example,
how can I get the position, size, etc.
My goal is to use the rectangle or circle tool to select a ROI and to
export it as some kind of binary mask for processing later. Do you have any
ideia if this is doable with the current viewer and how?
cheers
Miguel Chambel
On Wed, Feb 19, 2020 at 1:27 AM Danny Brown<EMAIL_ADDRESS>wrote:

CC: @igoroctaviano https://github.com/igoroctaviano ^
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/OHIF/Viewers/issues/1451?email_source=notifications&email_token=AD77UAO3IBRW5UN6RO6EKRDRDSDGVA5CNFSM4KXCMRWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF73DY#issuecomment-587988367,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD77UAP5SEG2HLYA2527BELRDSDGVANCNFSM4KXCMRWA
.

You can hook directly into cornerstone-tools "tool state". Check out the docs and source here:

https://github.com/cornerstonejs/cornerstoneTools

In the near future, extensions will have access to a new "MeasurementService" that provides an OHIF specific way to request that information

Great thanks
Miguel Chambel
On Fri, Feb 21, 2020 at 2:41 AM Danny Brown<EMAIL_ADDRESS>wrote:

Closed #1451 https://github.com/OHIF/Viewers/issues/1451 via #1454
https://github.com/OHIF/Viewers/pull/1454.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/OHIF/Viewers/issues/1451?email_source=notifications&email_token=AD77UALM5ZI4NPEMPTNPMWDRD45MDA5CNFSM4KXCMRWKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWZKXWGQ#event-3059055386,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD77UAMGN3XAX3PBHIQBAFDRD45MDANCNFSM4KXCMRWA
.

Hi @helghast79   Have you solved the problem?
I have the same problem.
Can you help me?

Hi there,
While persisting tool state in standard Dicom-SR looks appealing, I have
made some tests and I'm able to use DCMJS to generate a report in dicom-sr
format and store it in Pacs system (Orthanc in my case) but it seems that
only some tools are translated by DCMJS, for example RectangleRoi is not
present but ellipticRoi is. I can point you in this direction if you want
but what I ended up doing is persisting the toolstate in database and
restore it later
save toolstate to variable
const toolState =
cornerstoneTools.globalImageIdSpecificToolStateManager.saveToolState()
you can then stringify it and append to a form for example
to restore the toolstate in ohif it's not so easy, you can however do
cornerstoneTools.globalImageIdSpecificToolStateManager.restoreToolState(
toolState)
after getting the toolstate and parse it if it was in string form of course
but this will not affect the measurements API so if you click on
measurements panel you'll see nothing but at least the tools will be loaded
and you will see them in the viewer
For now I'll stay with this procedure until I find a better solution, maybe
you can come out with a better one I hope, in that case, please share what
you find
cheers
Miguel Chambel
On Sun, Jun 28, 2020 at 3:20 PM 独孤九剑<EMAIL_ADDRESS>wrote:

Hi @helghast79 https://github.com/helghast79 Have you solved the
problem?
I have the same problem.
Can you help me?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OHIF/Viewers/issues/1451#issuecomment-650767584, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AD77UAO7PJJBKI4OJPQNDADRY5GTBANCNFSM4KXCMRWA
.

const toolState =
cornerstoneTools.globalImageIdSpecificToolStateManager.saveToolState()
you can then stringify it and append to a form for example
to restore the toolstate in ohif it's not so easy, you can however do
cornerstoneTools.globalImageIdSpecificToolStateManager.restoreToolState(
toolState)
This is what I use for that solution so far. But if there is a way to get masurements and set it with SET_MEASUREMENTS would do the trick somehow.  In 1800 issue of OHIF @timoangerer says that SET_MEASUREMENTS does not renders inside the viewer.

const toolState =
cornerstoneTools.globalImageIdSpecificToolStateManager.saveToolState()
you can then stringify it and append to a form for example
to restore the toolstate in ohif it's not so easy, you can however do
cornerstoneTools.globalImageIdSpecificToolStateManager.restoreToolState(
toolState)
This is what I use for that solution so far. But if there is a way to get masurements and set it with SET_MEASUREMENTS would do the trick somehow.  In 1800 issue of OHIF @timoangerer says that SET_MEASUREMENTS does not renders inside the viewer.


Adding swagger to moclojer

This is the implementation of closes #205 #226
I have added a flag to SWAGGER as an environment variable, which will enable the build for reitit routes. However, there are some additional steps required for reitit swagger. It requests that parameters such as name, query-params, path and body are specified, along with the response..

e.g:
["/plus"
         {:get {:summary "plus with spec query parameters"
                :parameters {:query {:x int?, :y int?}}
                :responses {200 {:body {:total int?}}}
                :handler (fn [{{{:keys [x y]} :query} :parameters}]
                           {:status 200
                            :body {:total (+ x y)}})}
          :post {:summary "plus with spec body parameters"
                 :parameters {:body {:x int?, :y int?}}
                 :responses {200 {:body {:total int?}}}
                 :handler (fn [{{{:keys [x y]} :body} :parameters}]
                            {:status 200
                             :body {:total (+ x y)}})}}]

Create a function that discovers all possible types of parameters or responses will be kind of verbose, but is not impossible, just want to be reasonable about our options.
So if we enable swagger we have to specify the parameter types or body or query parameters, what do you think?
- endpoint:
    method: GET
    path: /hello/:username
    parameters:
      path:
        username:
          type: string
    response:
      status: 200
      headers:
        Content-Type: application/json
      body: >
        {
          "hello": "{{path.username}}!"
        }

Having to specify the types of parameters is very bad, it complicates everything.
    parameters:
      path:
        username:
          type: string

We can assume that all parameters are string and when it's not a string the user specifies it explicitly, but even so, I don't like the parameters:. We can think of a better signature, for example: path: /hello/:username/:age|int
It's possible to parse what comes after the |.
@matheusfrancisco, do you think it makes sense? Is it more user-friendly?"

@avelino I also think that parsing the uri seems more user friendly, and doesn't complicate our current implementation. One problem I have with ditching parameters altogether is that, yes, we can handle the parameters straight from the uri, but if in the future we add a body params to the request, it will come back anyways.
Anyways, I would definitely ditch the parameters field for now.

@avelino I'm quite sure that openapi is still intact. Our implementation checks beforehand if the spec is either our own or openapi, doesn't it?

@J0sueTM we had a lot of changes in this branch, remember to bring what was done for version <IP_ADDRESS> to this PR #272

@avelino Sure! I don't think there are changes that would conflict with the swagger implementation, but thanks for the heads u.

is that ok with the unverified commit? i don´t want to be pedant here.. sorry

@matheusfrancisco @avelino it's a problem with using github web to merge PRs. The "rebase and merge" method destroys my signatures:
https://stackoverflow.com/questions/62950018/verified-signatures-are-gone-after-i-pressed-rebase-and-merge

@J0sueTM Isn't it important to include the diagram (mermaid) proposed below by @coderabbitai in our documentation? I would put it in the README.

it provides an overview of how the request in moclojer works internally

sequenceDiagram
    participant Client
    participant Router
    participant Middleware
    participant Server

    Client->>Router: Request to /pokemon/:name
    Router->>Middleware: Validate request
    Middleware->>Router: Request valid
    Router->>Server: Process request
    Server-->>Router: Return response
    Router-->>Client: Send response with Pokémon data

Tip
For best results, initiate chat on the files or code changes.
@avelino, I agree that including the Mermaid diagram in the README would be beneficial. It provides a clear visual representation of how requests are processed internally in moclojer, which can help developers better understand the system's architecture. I recommend adding it to the appropriate section of the README to complement the existing documentation.

@coderabbitai then make a complete diagram representing the entire request flow, including mainly the middlewares it will pass through (keeping the order described in the code, maintaining the name and a description explaining what each middleware does)

@avelino @coderabbitai I don't think it would be of any use in the README, since the developers aren't looking for that. However, it would be a great addition in an explanation, in an inner doc (in the release for example) on how reitit does the processing part.

sequenceDiagram
    participant Client
    participant Router
    participant Middleware
    participant Server

    Client->>Router: Request to /pokemon/:name
    Router->>Middleware: Apply host-middleware
    Middleware->>Middleware: Apply log-request-middleware
    Middleware->>Middleware: Apply swagger-feature
    Middleware->>Middleware: Apply parameters-middleware
    Middleware->>Middleware: Apply format-negotiate-middleware
    Middleware->>Middleware: Apply format-response-middleware
    Middleware->>Middleware: Apply exception-middleware
    Middleware->>Middleware: Apply format-request-middleware
    Middleware->>Middleware: Apply coerce-request-middleware
    Middleware->>Middleware: Apply coerce-response-middleware
    Middleware->>Middleware: Apply multipart-middleware
    Middleware->>Router: Request processed by middlewares
    Router->>Server: Process request
    Server-->>Router: Return response
    Router-->>Client: Send response with Pokémon data

    note over Middleware:
    - **host-middleware**: Validates the host header in incoming requests.
    - **log-request-middleware**: Logs request details such as method, host, and URI.
    - **swagger-feature**: Integrates Swagger for API documentation.
    - **parameters-middleware**: Handles request parameters.
    - **format-negotiate-middleware**: Negotiates the response format based on the request.
    - **format-response-middleware**: Formats the response according to the negotiated format.
    - **exception-middleware**: Handles exceptions and formats error responses.
    - **format-request-middleware**: Formats the request body.
    - **coerce-request-middleware**: Coerces request parameters to the expected types.
    - **coerce-response-middleware**: Coerces the response body to the expected types.
    - **multipart-middleware**: Handles multipart form data in requests.

@avelino @coderabbitai I don't think it would be of any use in the README, since the developers aren't looking for that. However, it would be a great addition in an explanation, in an inner doc (in the release for example) on how reitit does the processing part.

fair, create a page in the documentation detailing the request and include the proposed diagram

https://github.com/moclojer/moclojer/pull/262#issuecomment-2321286948

@coderabbitai send a new PR with this contribution


[core] Log correct host/IP that Jetty is listening on. (#289)

Previously log always said Jetty was listening on localhost.

Thanks!

After the merge it now logs
[main] INFO io.javalin.Javalin - Jetty is listening on: [http://null:7070]


Invalid content type, only application/json is supported

Platform : windows 10
Php        : 8.0.13
Geth      : 1.10.14-stable
Trying to fetch eth accounts results in an invalid null $response passed to array_key_exists at src\Transporters\Http.php:55

Debuging the contents of the http response shows a string  Invalid content type, only application/json is supported

Adding a content type to the request header fixes the issue

@nunomaduro  Let me know if i can help fixing the issue and make a PR !
cheers,

Fixed.


Spacecraft file tutorial

I'll track my changes here to coordinate with @Yong2Sheng

Changed the name of the nb
Removed mention of deprecated formats. We only use the .ori files right now.
I merged all of @Yong2Sheng  commits from #150
@Yong2Sheng : good ideas to get the unique pixels during the dwell time map calculation! That inspired me to update a few lines to make it even faster!
dts in SpacecraftFile is time a TimeDelta object, not Time (as it should).
I did a general overhaul of the SpacecraftFile and DetectorResponse tutorials. I added information, better plots, reorganized the text, etc.

@Yong2Sheng Can you please check and merge this PR? In particular, that both tutorials work, that I didn't remove any information you wanted, and that SpacecraftFile.py still works well.

Hi @israelmcmc,
I reviewed the PR, it looks great! I really like your algorithm to get the summed pixel durations.
I tested DetectorResponse.ipynb and SpacecraftFile.ipynb. They both ran very well.
I only have one minor comment on one line I posted above.
Thank you very much!

Note: all commits from PR #150 were merged here.


Remove dead code

This PR tries to remove code that is no longer in use.

I'd like to also keep some of the dumps code, although it's dead now, it may be alive again if we move off of Thomas's infra.

Well, the point being the code is originally bugged for performance and security, so if we move away from the infra we have to rewrite them anyway,

A lot of this seems like stuff that's potentially still alive/useful. Could you add a comment to each of the files changed to explain what the rationale for considering it dead is?

This all looks good to me, but I want to get confirmation as to Helios being officially dead yet. I feel like it's still a thing we want to make happen eventually?

This all looks good to me, but I want to get confirmation as to Helios being officially dead yet. I feel like it's still a thing we want to make happen eventually?

Well, Helios is archived and is way out dated. It is highly unlikely that the original project will become active again. Although we do want that kind of change, it is likely that we need to rewrite it.


Add tests

Description of your changes
Documentation on how to run the tests
Issue ticket number and link

Type of change

[ ] Bug fix (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)
[ ] Documentation add / update

(If applicable) How has this been tested?

I just added a suggestion to use pypy.  The tests take 6m to complete with pypy, and 28m to complete without it.  What do you think -- too weird to suggest this?
On Mac it's a simple brew install pypy then pypy -m pytest tests

@PMSeitzer how do you feel about the pypy bit?


Use ~ instead of app name in imports

This is part of https://github.com/donejs/donejs/issues/1065

Blocked by https://github.com/canjs/can-stache/issues/467

Coverage remained the same at 97.414% when pulling 65152bb85fbcef8cbcaf8c1ce96fca1155e61f34 on tilde into db1fd1f570909830d0712e522b0bf6bb7d335889 on major.

Coverage remained the same at 97.414% when pulling 65152bb85fbcef8cbcaf8c1ce96fca1155e61f34 on tilde into db1fd1f570909830d0712e522b0bf6bb7d335889 on major.


feat: star sign info for /temporal exact

Add star sign info for the resolved date.

closed in #65


[CRP] [LF] Implement path planner and the LDM (take-over) in crp_apl

Take over parts from 'old' implementation (jkk controllers)

Ideas that came up during implementation:

for those packages that are external (included as subrepos) the crp custom internal interface types cannot be used
utilities have been added, now example is the third order polynomial regression

now put on hold until the node point calculation task is finished (opened branch from latest commit on this branch)


Added initialItems prop

This feature satisfies https://github.com/developerdizzle/react-virtual-list/issues/13 by allowing an initialItems prop to be passed into VirtualList which defaults to an empty array. Different things can be done with this:

Render a subset of the items

<VirtualList items={ items } initialItems={ items.slice(0,10) } .../>

This allows you to prevent the flash of missing content for the general case, and the size of the slice can be adjusted to the application, how expensive the items are to render, and if the device is known or can be determined. You get server side rendering for free.

Render a new set of items (such as placeholder items)

<VirtualList items={ items } initialItems={ placeholders } .../>

If your items are expensive components to render, or rely on external assets like images or XHR data you don't have yet, you can render placeholder items. This prevents the flash of missing content, and is similar to the method used for placeholder content on Facebook's timeline. Server side rendering also works here, though obviously since they are placeholder items, not quite as usefully.

@developerdizzle If you're interested in this, I can put together a test for it.

I definitely want to make sure server-side rendering works, but I feel like there should be a better way.  I'll look into it when I have some time, but there must be a way to get this working without placeholder data.

An alternative option is just to use items and provide a property to truncate that to N items, assuming you want to render the top of the list. This eliminates the duplication and is more or less how react-list does it.

I created PR #18 as an alternate solution based on your comment.  Let me know what you think!


[style]: Fixing footer

What's the style idea?
I want improve the position of the footer in the Bookmarks section.
Please assign me this Issue under GSSOC'23.
Add screenshots

Code of Conduct

[X] I agree to follow this project's Code of Conduct

what is the issue with the position?
can you elaborate it?

what is the issue with the position? can you elaborate it?

The footer is coming in the middle of the page and just below the image. Fixing it to the bottom of the page.

Okay, give it a minimum width so that it never appears in the middle or top.

Issue has been solved


[WIP] bug: getQuantiles() returns values that exceed max

https://github.com/druid-io/druid/issues/3972

Updated PR to include a proposed fix. May need discussion to ensure this is the right way to do things.
I fed getQuantiles() with more synthetic data sets to see that the numbers generated are sane. Since the algorithm is based off the BH/TT uniform() procedure, we know that uj should not exceed s given that uj should fall in the set of real numbers {u1 < . . . < u~B}.

Does this help with the issue reported in #3972 (with regard to the median, rather than high percentiles)? It seems like max-clamping might not help with the low/mid quantiles like median.

@gianm I've updated the PR to include a comment on why clamping to max needs to happen. It's mostly based on the BH/TT paper but I hope it's clear and makes sense. The short version is that we don't expect any "points" (values) to exist to the left of the known minimum or the right of the known maximum.
The clamping to min was already handled as a special case (line 1571 - https://github.com/druid-io/druid/pull/4744/files#diff-de22260542704e07a950d869cd124aefL1571).
As for #3972, yes, it handles that situation. I've tried to replicate the original poster's situation, but I took a guess in filling in the blanks for the full ingestion spec. Here's what I have:

ingestion_spec.json.txt
api_duration.csv.gz

Given the time series query:
{
  "queryType": "timeseries",
  "dataSource": "test_quantile_fix",
  "granularity": "all",
  "intervals": [
    "2017-09-01T00:00:00+08:00/2017-10-01T00:00:00+08:00"
  ],
  "aggregations": [
    {
      "type": "approxHistogramFold",
      "name": "hist_fold",
      "fieldName": "hist_fold_api_duration",
      "resolution": 10000,
      "numBuckets": 100
    }
  ],
  "postAggregations": [
    {
      "type": "quantile",
      "name": "myResult",
      "fieldName": "hist_fold",
      "probability": 0.5
    }
  ],
  "context": {}
}

Druid 0.10.1 Result for q=0.5: 1111.9833
druid_quantiles_stock.json.txt
Druid 0.10.1 + patch Result for q=0.5: 190.86847
druid_quantiles_patched.json.txt
Reference (computed using SciPy for q=0.5): 190.0
You'll notice the breaks are completely different between the behavior without the clamped values for max, but I think that has more to do with the folding of multiple approximate histograms, which gets exacerbated when the original values weren't clamped to begin with.

I'll update the PR with the CLA tomorrow — I did use some personal/company time so I'll check with the company to get that ironed out.

Updated unit tests to be more thorough with computing a range of quantiles (q=[.10, ..., 0.90] in 0.10 increments) including the explicit test for "outliers" (q=0.05 and q=0.95).

Not sure why the travis builds are failing, but it seems to be affecting the other PRs as well — particularly on those with the -Xmx512m maven opts set.

@ginoledesma We've been having some unreliability with one of the tests recently, sorry about that. I re-ran it and it may pass when run a second time.
The patch looks good to me, thanks for the additional tests as well. Have you had a chance to get the CLA sorted?

@ginoledesma If you merge master into your branch, it should help with the CI issues. We just did a commit there that tweaks some Travis settings and seems to be helping.

@ginoledesma Hmm, this change does seem better, but I'm wondering how it helps with the test you describe in https://github.com/druid-io/druid/pull/4744#issuecomment-327676105. The patch only affects the getQuantiles(float[]) method, which is only called in the post-aggregation step, and so it shouldn't affect the breaks at all (which are computed in the aggregation step). So the patch shouldn't affect the breaks or folding behavior at all.

@ginoledesma, any thoughts on the question from https://github.com/druid-io/druid/pull/4744#issuecomment-329350396?

waiting for answers to @gianm 's questions before merging.

I don’t have a solid answer, unfortunately. I’m trying to come up with a smaller dataset that replicates the approximation breaks do it can be replicated in the tests properly, but I haven’t found any good leads to explain it.

@ginoledesma thanks for the details. If you do find any new info please raise a new issue. In the meantime I'll merge this patch since it does look like an improvement. Thanks!


Update or remove kubectl-bpfprogramconfigs and kubectl-bpfprograms

Do we still need https://github.com/bpfd-dev/bpfd/blob/main/bpfd-operator/hack/kubectl-bpfprogramconfigs and https://github.com/bpfd-dev/bpfd/blob/main/bpfd-operator/hack/kubectl-bpfprograms
If so, update them based on the latest changes.

That's a question for @Billy99

I had mentioned it to @Billy99 and he requested that I open an issue.
One more thought I've had is that it would be good to have a nicely formatted summary listing via kubectl -- kind of like what we get from bpfctl list.


Volk present but not detected

Building vulkan-tools-1.3.292, volk is not detected even though present in /usr/local.
-Dvolk_dir=/usr/local/lib/cmake/volk does not help.
-DUPDATES=ON downloads volk, but it is still not detected.

It's -DUPDATE_DEPS=ON and you need to delete your cache to make sure it is getting populated. I'm not sure off the top of my head where volk_dir points to - it might be the root of the install directory, so setting it to /usr/local may work, or it may need /usr/local/lib.

Thanks - yes, it’s DUPDATE_DEPS=ON, I checked volk, vulkan-headers, etc were downloaded - vulkan-headers, etc are detected, but not volk.
I’ve set -Dvolk_DIR to /usr/local, /usr/local/lib, /usr/local/lib/cmake as well, but none work.

Using volk-3.1.2 and Vulkan-Tools-1.3.292, If find_package(volk QUIET REQUIRED CONFIG) is changed to find_package(Volk QUIET REQUIRED CONFIG) then volk is found.
Configuring still fails with errors of the form:
CMake Error at cube/CMakeLists.txt:246 (target_link_libraries):
  Target "vkcube" links to:

    volk::volk_headers

It looks like the target should be Volk::volk - this allows configuring to finish, but then there are many "make" errors of the form:
/usr/local/bin/cc -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -Os -pipe CMakeFiles/vkcube.dir/cube.c.o -o vkcube  -Wl,-rpath,/usr/local/lib: -lm -lrt /usr/local/lib/libvolk.so.3.1.2 /usr/local/lib/libxcb.so -ldl -lm
/usr/local/bin/ld: CMakeFiles/vkcube.dir/cube.c.o: in function `demo_name_object':
cube.c:(.text+0xa50): undefined reference to `vkSetDebugUtilsObjectNameEXT'

So looking at my own build, I see that
VOLK_INSTALL_DIR:STRING=/home/cdgiessen/lunarg/Vulkan-Tools/external/Release/64/volk/build/install
volk_DIR:PATH=/home/cdgiessen/lunarg/Vulkan-Tools/external/Release/64/volk/build/install/lib/cmake/volk

Looking at the CMake code, you should be setting VOLK_INSTALL_DIR, not volk_DIR. I'm not sure who/what volk_DIR is or comes from, but it seems to be an internal variable, not the one that the user should set.

IT looks like the problem is small "v" versus capital "V".
If I use VOLK_INSTALL_DIR=/usr/local/lib, I get the error:
CMake Error at CMakeLists.txt:59 (find_package):
  Could not find a package configuration file provided by "volk" with any of
  the following names:

    volkConfig.cmake
    volk-config.cmake

  Add the installation prefix of "volk" to CMAKE_PREFIX_PATH or set
  "volk_DIR" to a directory containing one of the above files.  If "volk"
  provides a separate development package or SDK, be sure it has been
  installed.

..but I have:
ls /usr/local/lib/cmake/volk
VolkConfig.cmake           VolkTargets-release.cmake
VolkConfigVersion.cmake    VolkTargets.cmake

As mentioned above, if I change the search from volk to Volk, volk is found, but the are still problems of volk versus Volk.

Changing all occurrences of “volk” to “Volk” resolves finding Volk targets on Ubuntu 20 for me.  It’s also straight forward to factor out the use of Volk altogether; using vulkan.hpp.


AWS Resources not recognised

Hello,
I have the following example that makes use of the aws-collector and the open-telemetry instrumentation.
This is the repo and the exact commit: https://github.com/noliva/aws-observability/tree/f9e5abba1c1e240f90e56d1fc0f390c6f453874e
Basically, the problem is that when I do any requests to that service I don't see the DynamoDB instrumentation or the response code in the X-Ray console.
This is what a request looks like in the console:

This is what I would expect:

Not sure if I've done something wrong in the code or there is an issue with the SDK.
Thank you!

Hello @noliva , thanks for reaching out! Have you tried using this configuration ? This is a plugin you have to install and configure in your trace.js file you gave as an example.

Thank you very much @KKelvinLo for your quick response. I've added that plugin to my repository, but I can't tell the difference as I'm still seeing exactly the same as before.

Ah I see the issue, currently the plugin currently supports V2 AWS JS SDK and you're using the newly released V3.0.0 for dynamo DB. That plugin support is currently not in place, but it will be in the future. I apologize for any inconvenience.


Add "helpers"

Helper methods/classes to process data:

[ ] Data wrangler

[ ] Merging data into the same time grid
[ ] Removing duplicates
[ ] Handling missing data (NOT REMOVING NANS! We have ALL the time grids, so after adding lookback etc. we can remove nan)

[ ] Data augmenter

[ ] CGM delta
[ ] Basal, bolus and both combined
[ ] Adding lookbacks
[ ] Adding future (known) inputs
[ ] Adding targets
[ ] Deleting nans

[ ] Scikit and pytorch dataset generator

[ ] Scaling: categoical, numerical, controls, not controls
[ ] Which inputs to use
[ ] Hyperparameter tuning
[ ] scaling
[ ] pipeline
[ ] ..?

Data Wrangling

Merging data
Adding time lagged features and targets
Removing nan values

Data Splitting

Making sure that there is no information leakage

Preparing for machine learning library

Scikit learn
PyTorch


Consolidate auth validation in maven/gradle plugins

Part of #594.
A couple things to note:

This change makes the system properties jib.to.auth.username and jib.to.auth.password available for use in the gradle plugin as well as the maven plugin.
Apparently incorrect credentials were being used in the validation function in BuildImageTask (see this line), it should be fixed now. I think this was from the friday refactoring, so I don't think it was in any releases.

Apparently incorrect credentials were being used in the validation function in BuildImageTask (see this line), it should be fixed now.

Since it really happened and the tests could not catch it, it makes sense to add a test.

Filed an issue for https://github.com/GoogleContainerTools/jib/pull/801#issuecomment-410793210


Divide by 10 instead of subtracting one from exponent.

Pull Request Test Coverage Report for Build 6896

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+82.8%) to 99.943%

Totals

Change from base Build 6851:
82.8%

Covered Lines:
1296

Relevant Lines:
1297

💛  - Coveralls


Complete tests castor, pollux

See https://swi-prolog.discourse.group/t/using-consult-in-a-directive-to-load-source-code-it-puzzles-me/2081/12?u=peter.ludemann

a64ad76


Bio building visuals and some bugs

Thank you very much for adding higher tires of bio buildings!
I have found some minor issues, here is the list
Tree Seed Generators (all of them) miss II and III overlay on items. Same for Arboretums.
Seed Extractor does not have versions 2 and 3
Original Bio Refugium (Mk1) has speed 2. So versions Mk2 and Mk2 should have probably speed 3 and 4. Now they are at 1.25 and 2. There was a change some time ago in Angles, they upgraded Refugium speed from 0..75 to 2.
Would it be possible to add some tint or detail allowing to distinguish on map basic Warehouse and versions Mk2 - Mk4? Right now they look the same. You might get some inspiration from ShinyAngles mods by Zombee.

I don't have permissions to edit angel's buildings only things like items and icons but I have fixed the speed and mk icons


#[capnproto_rpc] decorator

Current version implements the following syntax:
impl test_interface::Server for TestInterfaceImpl {
    #[capnproto_rpc(test_interface)]
    fn set_value(&mut self, value: u64) {
        self.value = value;
        Promise::ok(())
    }

    #[capnproto_rpc(test_interface)]
    fn get_value(&mut self) {
        let mut rresult = result.get();
        capnp_build!(rresult, { value = self.value });
        Promise::ok(())
    }
}

Return values in function signature is ignored, because we can't deduce namespace from it (as user can just have it in a use statement). There are hidden bound result and params arguments in the function signature and rparams variable in the generated output. Decorator takes one argument, which is the namespace for Params and Results types.
Requested syntax was different from Rust's. Some way of supplying namespace was also needed. As of writing this PR, I'm realizing that common used name for parameter is results...
I'm leaving PR as draft due to not complying with requested syntax and hidden variable needed to be used called result. I'll try to implement that part of the syntax next if needed.

Today I checked and realized that having
#[capnproto_rpc]
// rest of signature here
-> result: log_sink::LogResults

isn't possible, because attribute macros require Item, which has a precise meaning in the syntax and cannot be changed. Two ideas of how to work around that:

Put result as an argument for the attribute or somewhere in the body:

#[capnproto_rpc(namespace = log_sink, result_variable = result)]

or
#[capnproto_rpc(log_sink)]
fn log(&mut self, id: u64, machineId: u64, schema: u64, data: String) {
  let result;
  // the rest goes here
}

Make it a function-like macro:

capnproto_rpc! {
    log_sink,
    fn log(&mut self, id: u64, machineId: u64, schema: u64, data: String) -> result: log_sink::LogResults {
        self.append(id, machineId, schema, data);
    }
}

Function-like macro is a valid Item, so some hybrid method could be used.
Exposed parameter should be renamed to results in my opinion in contrast to the specification, other than that I'm marking it as ready for review.

We could potentially make the attribute macro apply to a whole impl block to reduce the amount of duplication of the attribute.
I'm fine with just picking the name "results" and injecting it into scope. We could potentially also make it use an argument after self but before the rest of the arguments for that. I'd just want to know how badly the name not being in the original source breaks IDE support.

Seems fine to me


Pager buttons disappear with multi-select mode

Describe the bug
I start the YPImagePicker with camera mode, but allow library mode. At the bottom, I get two buttons "Photo" and "Library". If I switch to "Library", and use the multi-select feature, the buttons disappear. If I then swipe back, the buttons are still gone. I have to swipe over to the library to switch to single photo mode, and then the buttons come back.
To Reproduce

Run default image picker with .photo and .library screens.
Switch to library.
Select the "multi" button. Buttons disappear
Swipe back to the camera. Buttons are still gone

Expected behavior
I'm not sure if making the buttons disappear is intended when multi-select is enabled, but I'm assuming so. However, they should definitely reappear when switching back to the camera mode. In my app, I have multi select on by default, so this is even more bizarre, as all I have to do is swipe right and left and now the buttons are gone.
I would like to have the buttons never go away, however, if that is possible, especially when they seem to disappear with no user intervention.
Screenshots
Initial screen, buttons present:

Switch to image gallery, default multi-select on, buttons disappear:

Swipe back to camera, buttons still gone:

Environment (please complete the following information):
This happens on multiple devices. On my iPhone 6s with iOS 12, and an iPhone 8 simulator running iOS 13.

Xcode Version 11
Swift Version 5.1

Installation Type

Manual

Hi, I have the same issue. Have you been able to fix that? Thanks.

I haven't solved it, as it's not super-critical (you can still go back and forth with swiping, and there is a way to get out of it with the back button or deselecting multi-photo). Plus the use case is not usual -- you know most times whether you are going to take a photo or import from the library, so you don't spend a lot of time going back and forth.
I just wanted to report it more as a nuisance thing.

There is 2022 year outside🎉 Old outdated issues are closing. Please search if there are already existing issues with the same problem before opening new ☮

Interesting to close actual bugs without fixing instead of enhancements. Not sure what message that sends.

@schveiguy check https://github.com/Yummypets/YPImagePicker/releases/tag/5.2.1
If still actual you should write here or make a PR by yourself.

Nice attitude, what was the point of closing? To just show fake visibility of work?

@sssbohdan There are a lot of stale, not reprodusable and not actual bug since left so many time and so many changes in master. I don't have time to check them all. And it's bad to left them in tail in repo. If you don't know - in big projects (like Alamofire) there is a bot that automatically close bug when there are some time left and no activity in them. So the actual issues are always in top and contributors can see what is in main priority to do.


resample_spatial missing dimensions causing a crash

If dimensions are missing the resample_spatial crashes as it is out of range.
Fix + updated test is on the way

Latest commit should fix this issue, @clausmichele @ValentinaHutter can you please review the test as I am not 100% sure it works the way I want it to. It should basically test the different combinations (x,y,bands) , (x,y,t), (x,y) with the parametrization. If that is not the case I can review it again. Thank you!

Hi @jzvolensky, I've reviewed the code and it is fine for me. Please change the status of the PR from draft to ready.

@jzvolensky tests are not passing anymore. From a quick check it seems for that for Python 3.9 the issue seems related to the odc package. For python 3.10 and 3.11 the error seems to be in how you are calling the reduce_dimension (check the reduce_dimension tests to see how to call it).

We have been looking into the python3.9 issue this week and decided to remove python3.9 from the supported versions, Please pull from the latest version. :)


False positives for duplicate_fare_rule_zone_id_fields in fare_rules.txt

Describe the bug
This was flagged by SDMTS.
False positives for the duplicate_fare_rule_zone_id_fields rule.
They only have (fare_id, route_id) fields defined, every row has a unique combination of both.
The spec mentions that the primary key for fare_rules.txt is (*) which means: all fields (reference)
They had duplicate_fare_rule_zone_id_fields triggered (which is an ERROR) and it looks like a problem with the way this rule is designed.
Steps/Code to Reproduce

download dataset provided
run validator
open report

Expected Results
No issue with fare rules
Actual Results
The notice duplicate_fare_rule_zone_id_fields is triggered 296 times.
Screenshots
No response
Files used
https://www.sdmts.com/google_transit_files/google_transit.zip
Validator version
4.0.0
Operating system
MacOS
Java version
No response
Additional notes
Now that we support multiple @PrimaryKey annotations, we don't need to have the duplicate_fare_rule_zone_id_fields rule in this validator at all.
We can use the @PrimaryKey annotation in fare_rules.txt directly, and the notice duplicate_key will be triggered if we have duplicate records.

Generally agreed that this validation rule doesn't seem to match the spec.  Interestingly enough, I believe Google disables this check in our instance of the validator, probably for the same reason.
Per the acceptance tests, there are a number of feeds (~60) that trigger the existing duplicate_fare_rule_zone_id_fields notice. Spot checking a few feeds, many of them are indeed specifying the same combination of fare rules with different fare ids. The corresponding fare attributes often have a different price, probably indicating that the producer is attempting to model some other aspect of their fare system (different fare products? different rider categories?) despite the fact that this is not really supported in Fares v1. While it's maybe not obvious how feed consumers should productively use this data, other than showing the cheapest fare, the spec technically allows it, so the validator should as well.
The acceptance test shows that a number of feeds (~10) newly trigger a duplicate_key notice. These are all feeds that really due have a duplicate combination of all fields in fare_rules.txt. However, each of these feeds was already triggering a duplicate_fare_rule_zone_id_fields notice, so there are no newly-invalidated feeds from this change.
All in all, +1 to making a change to validation here.


Closes #74 Feature/VoiceSearch

Fixes Issue
Mic glows when activated.
This PR fixes the following issues: #74

Changes proposed
Here comes all the changes proposed through this PR

Check List (Check all the boxes which are applicable)

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots and video
Add all the screenshots and a video which support your changes
https://user-images.githubusercontent.com/84321236/224505669-32368f54-17d1-4b3a-b633-4118833657d5.mp4

@mnnkhndlwl Can you review it tonight?


[Abema] When a video is downloaded, it displays the message "お使いのデバイスでは視聴できないコンテンツです" and the actual video cannot be downloaded.

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting that yt-dlp is broken on a supported site
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[ ] I've read about sharing account credentials and I'm willing to share it if required

Region
Japan
Provide a description that is worded well enough to be understood
When I try to download a video from the URL below, the video with the message "お使いのデバイスでは視聴できないコンテンツです" is downloaded and I cannot download the actual video.
https://abema.tv/video/episode/199-30_s3_p1
The message means "This content cannot be viewed on your device."
When I open the URL in my browser, the video will start playing normally.
However, there are some URLs that can be downloaded successfully.
This issue only occurs with some videos that contain the URL in question.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-vU', 'https://abema.tv/video/episode/199-30_s3_p1', '-o', '.\\tmp.mp4']
[debug] Encodings: locale cp932, fs utf-8, pref cp932, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp [4d9231208] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.20.0, brotli-1.1.0, certifi-2024.07.04, curl_cffi-0.5.10, mutagen-1.47.0, requests-2.32.3, sqlite3-3.35.5, urllib3-2.2.2, websockets-12.0
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Loaded 1830 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version<EMAIL_ADDRESS>from yt-dlp/yt-dlp
yt-dlp is up to date<EMAIL_ADDRESS>from yt-dlp/yt-dlp)
[AbemaTV] Extracting URL: https://abema.tv/video/episode/199-30_s3_p1
[AbemaTV] Authorizing
[AbemaTV] 199-30_s3_p1: Downloading webpage
[AbemaTV] 199-30_s3_p1: Checking playability
[AbemaTV] 199-30_s3_p1: Downloading m3u8 information
[debug] Formats sorted by: hasvid, ie_pref, lang, quality, res, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[debug] Default format spec: best/bestvideo+bestaudio
[info] 199-30_s3_p1: Downloading 1 format(s): 5300
[debug] Invoking hlsnative downloader on "https://vod-abematv.akamaized.net/program/199-30_s3_p1/1080/playlist.m3u8?aver=1"
[hlsnative] Downloading m3u8 manifest
[hlsnative] Total fragments: 286
[download] Destination: tmp.mp4
[debug] File locking is not supported. Proceeding without locking
[download] 100% of   11.82MiB in 00:00:05 at 2.10MiB/s
WARNING: 199-30_s3_p1: Possible MPEG-TS in MP4 container or malformed AAC timestamps. Install ffmpeg to fix this automatically

This means this video (usually PPV) is DRM'd.

I wonder if there's any telltale sign of this that we can detect in advance (either in the API response or m3u8 manifest) so that we can raise a DRM error before downloading the decoy video


Set node default IPv4 and IPv6 packet TTL=255

AWS recommends that EC2 instances be configured with packet TTL=255 to avoid potential packet loss.  This is a good idea for all environments because of all of the new packet hops introduced by Kubernetes networking as well as whatever routing clouds are doing.
# /etc/sysctl.conf

net.ipv4.ip_default_ttl = 255
net.ipv6.conf.all.hop_limit = 255

DONE


add issuer links

How does this look? In particular, is "Direct Link" clear enough?

Whoops - I haven't deployed this yet. Let me re-generate the DB/site files with the most recent CT log info.

Ok - should be good to go now at the same url.

This is a good start, but it's got some usability issues. I think it would be better to have the link update when autocomplete finishes. That way the URL is always correct (you can't end up on a URL that doesn't match what's being shown) and you can get rid of the "Direct link" field.
$('#autocomplete').autocomplete({
source: filteredIssuers,
minLength: 0,
select: function(event, suggestion) {
makeChart(suggestion.item.value);
// Update link here?
}
});

I'm not sure if this is what you meant, but the most recent change updates the location shown in the urlbar such that if you navigated to that url, it would show what the page currently shows.

Yep, that's what I meant. I think now there's no use for the "Direct link"  link, unless I'm missing something.

Sounds good - I removed the link.

Looks great, thanks!


canon-cups-ufr2: deprecate phases

Motivation for this change
#28910
having the autoreconfHook breaks things, so i believe adding autoconf and automake is desired.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 133514 at 589c8d74 run on x86_64-linux 1

1 package built successfully:

canon-cups-ufr2

1 suggestion:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/misc/cups/drivers/canon/default.nix:47:3:
   |
47 |   installPhase = ''
   |   ^

@SuperSandro2000 the link works for me.

@SuperSandro2000 the link works for me.

now it works for me, too.


Set up a docker network that works (or simply pass the routing address to the containers)

Update:

Attempt to add host machine as DNS server for containers, didn't work

It seems that default bridge network wont expose the ports of containers in the network to each other

Now try to establish a user-defined docker bridge network

Update:

Attempt to fetch more debug information by using a customized docker image
After multiple experiments, it turns out that the executors and AM are indeed running in different containers
It seems like the connection was lost when AM reached back to executors to check if they were still alive (AM cannot bind a usable address to listen to)
But it is weird that @Vin3ntKing did observe one of the executors was using the same address as AM's
More experiments to be done

Update:

The single node cluster is now working (thx @jwz16 for fixing the Spark binding issue)
Working on Docker Swarm or other sorts of overlay network now

Final solution is to use bridge network and at the same time running AM in the host network using RunC (this is for the cluster mode in Spark)


Content disparity regarding clients and supported API requirements sets

Hi,
As of today, Outlook on the Web is listed as only supporting up to requirements set 1.6 while the following page (assuming that Outlook on the Web == Outlook Online) lists it as supporting requirements set 1.7 as well: https://docs.microsoft.com/en-us/office/dev/add-ins/overview/office-add-in-availability#outlook
Where should I look in order to be up-to-date regarding the supported API requirements sets for each client.
A slightly related question: Is there some kind of overview as to when each of the listed clients aim to catch up with the newer requirements sets? For example, I'd like to know when Outlook 2016 / 2019 for Mac will support requirements set 1.7.
Thank you!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f8e26a32-7523-2211-bde3-938cf94a76ec
Version Independent ID: 80ad76d1-8a12-348f-dd6a-2f9392ed1f95
Content: Outlook JavaScript API requirement sets - Office Add-ins
Content Source: docs/reference/requirement-sets/outlook-api-requirement-sets.md
Product: outlook
GitHub Login: @o365devx
Microsoft Alias: o365devx

Thanks for the feedback, we will update our documentation to be clearer as well. We are in the process of releasing a new version of Old Outlook for Web (OWA). New OWA is live for Outlook.com accounts and is available to all enterprise customers as beta. As such we are making investments in new OWA only which currently supports 1.7 and Old OWA will not support requirement sets beyond 1.6. Support for 1.7 on Mac is in progress and we are targeting to release it in Q2 CY19.

Great, thanks for the feedback as well!


better name

this is one of better gocd dashboards, thanks!
not one of top results though.  recommend changing name?
how about 'genky'?
thx

going to close this as current gocd doesn't seem to work w/this plugin, will open another issue for that


Inline styles in v3

Should inline styles work the same as V2. i.e including a style.css in the template folder.
It's not working and there is nothing in the documentation about it.

I believe so - are you interested in writing a test case that fails and then I can patch?

If you run this example https://github.com/dottodot/email you'll see there is styles included in the resulting html.

@dottodot sorry the docs were missing for this - see https://github.com/niftylettuce/email-templates#automatic-inline-css-via-stylesheets

Thanks but that documentation is slightly wrong, it should be
    const email = new Email({
        // <https://github.com/Automattic/juice>
        juice: true,
        juiceResources: {
          preserveImportant: true,
          webResources: {
               // default path is `build/`:
          relativeTo: path.resolve('build')

              //
              // but you might want to change it to something like:
              // relativeTo: path.join(__dirname, '..', 'assets')
              //
          }
        }
      });

not
const email = new Email({
  // <https://github.com/Automattic/juice>
  juice: true,
  webResources: {
    preserveImportant: true,

    // default path is `build/`:
    relativeTo: path.resolve('build')

    //
    // but you might want to change it to something like:
    // relativeTo: path.join(__dirname, '..', 'assets')
    //

  }
});

updated docs, thanks @dottodot if you see anything else please let me know.  also feel free to join us in slack, see https://lad.js.org for more info + the slack link