docs: V2 design discussion document added

@JohelEGP, @chiphogg, @rbrugo, @yasamoka, @hofbi, @kwikius, @mikeford1, @oschonrock, @RalphSteinhagen, @i-ky, and everyone else interested in the subject (sorry for not adding you here explicitly).
I am in the middle of a major library redesign, and there are many important decisions to be made. I would love to hear your feedback. Please feel free to provide comments on any line in the document pushed in this PR or add some additional discussion in this or other threads.
You can find the rationale and some design description here: https://github.com/train-it-eu/conf-slides/blob/master/2022.09 - CppCon/mp-units v2 - new features discussion.pdf.
The current state of the implementation (really messy and preliminary) can be found in #391.
Thanks a lot in advance! 😃

The single file is better read from here: https://github.com/mpusz/units/blob/v2_discussion/docs/v2_design.md.

Would the following be true:
auto d = 5.0 * si::power[W];
auto f = 5.0f * si::power[W];

static_assert(std::is_same_v<decltype(d), quantity<reference<isq::power_dim, si::watt>{}, double>>);
static_assert(std::is_same_v<decltype(f), quantity<reference<isq::power_dim, si::watt>{}, float>>);

Yes. Most of the changes are unrelated to the handling of the number type. It's mostly about the other factor of "quantity = number × reference".

Hi @kwikius 😄
Thanks a lot for reviewing and giving feedback on the new design. I am working on some changes right now that will make the document here a bit outdated. The main change is related to our try (with @JohelEGP) to model most or even all quantities in the ISO 80000. I will try to update the V2 design document here with the recent design changes and more info tomorrow.

My only concern( which I expressed before) is the necessary use of all those very short names polutting global namespace.

Unit symbols in the new design are hidden in the subnamespace that you have to explicitly use in order to have access to them. Without it, a user has access only to the full names of base units. User-defined literals have a lot of issues (https://mpusz.github.io/units/framework/quantities.html#summary). Hopefully, tomorrow, when I post the updated V2 design overview, things should be clearer and easier to understand.

I look forward to reading the updates.
Just on the point about downside of UDL's  https://mpusz.github.io/units/framework/quantities.html#udls-vs-quantity-references
Regarding item 3 in the section entiled UDLs vs Quantity References ( Poor control over the representation types as UDLs return only std::int64_t or long double)
There is an alternative way to define UDLs so that the representation type is deduced from the actual numeric value.
I chose this option for pqs. (You could argue with the quality of the implementation in the link, but hopefully you get the principle)
https://github.com/kwikius/pqs/blob/master/src/include/pqs/bits/meta/literal_value.hpp#L134
The algorithm parses the string representing the numeric constant and decides if it is an integer or a floating point type. For each type, it then returns the smallest type capable of holding the representation. The rep type of the returned quantity is then of course deduced from the numeric value of the literal.
This works particularly well for example with some stm32 ( microcontroller) which only have hardware arithmetic operations for float not double. In case you really want a double, just add some trailing zeros after the decimal point https://github.com/kwikius/pqs/blob/master/src/include/pqs/bits/meta/literal_value.hpp#L143.

That's attractive. I had forgotten due to the difficulty of having to reproduce the literal processing done by the compiler. There are many input formats (https://en.cppreference.com/w/cpp/language/user_literal). Reflection would make this a breeze.

I just pushed the updated V2 design document.

For traits or properties such as are available in the quantity_spec class, I was taught to prefer free functions/ metafunctions  over members, since they are more general, so  e.g  get_dimension(p) over p.dimension.  This allows to provide specialisations/overloads for quantity,named dimension, quantity_spec and other entities which might have some properties of a quantity,.
for example:
get_dimension(std::chrono::minutes{}); // "might" return isq::dim_time
get_dimension(1.0);  // "might" return isq::dim_undef or even isq::dim_one

In general, I agree that it is a good habit for customization points. But in this case, it is not a trait or any other kind of customization point. Users should not provide specialization of it for custom types. It is just an aggregate storing some properties (the same as reference or ratio that stores num and den).

In case we decide that such customization points are needed, we can always add them as standalone functions.


Add Evaluation Status and Submission Availability Codes and Descriptions to Test Summary Endpoints

Ensure that the following fields are included in the following endpoints.
Fields

evalStatusCode
evalStatusCodeDescription
submissionAvailabilityCode
submissionAvailabilityCodeDescription

Endpoints

/qa-certification-mgmt/workspace/locations/{locId}/test-summary/{id}
/qa-certification-mgmt/workspace/locations/{locId}/test-summary
/qa-certification-mgmt/locations/{locId}/test-summary/{id}
/qa-certification-mgmt/locations/{locId}/test-summary

Needs acceptance criteria.

Partially verified in dev.

Verified: /qa-certification-mgmt/locations/{locId}/test-summary

locId: 6

Verified: /qa-certification-mgmt/locations/{locId}/test-summary/{id}

locId: 6
id: TWCORNEL5-1ECF76CEA8234C78900C03F6DD4B9FED

Pending: /qa-certification-mgmt/workspace/locations/{locId}/test-summary

Pending: /qa-certification-mgmt/workspace/locations/{locId}/test-summary/{id}


WIP: AESNI based DRBG CTR

Current DRBG CTR rand performs each block by block, changing that to use AESNI based multi block CTR operation gives better performance on rand generation.This inturn helps in improving some of the ECDSA curves (P224, P256) sign operation which invokes random nonce generation.
Improvement in performance measured using speed app are listed below

Operations
Base Perf
Perf with Changes

16 bytes rand gen
2 MB/s
17 MB/s

64 bytes rand gen
9 MB/s
71 MB/s

256 bytes rand gen
28 MB/s
271 MB/s

1024 bytes rand gen
52 MB/s
888 MB/s

P224 sign
2346 op/s
2441 op/s

P224 verify
2858 op/s
2942 op/s

P256 sign
27487 op/s
32717 op/s

P256 verify
10422 op/s
10492 op/s

P384 sign
927 op/s
938 op/s

P384 verify
1242 op/s
1219 op/s

P521 sign
394 op/s
394 op/s

P521 verify
553 op/s
551 op/s

This performance is measured on a ubuntu 18.04 x86_64 PC.

Why doesn't the existing CTR implementation use AESNI anyway? It should be using the fastest available implementation for the platform.
Adding a separate AESNI DRBG variant seems like completely the wrong approach to me.

I tried to do the same optimization (use platform specific aes-ctr support instead of platform specific plain aes) for all platforms long time ago: https://github.com/openssl/openssl/pull/4530
It was rejected back then and the PR stalled since then, for the reasons, check my PR.

It seems to me that the DRBG code should use the EVP interface and not call low level implementation functions. If EVP isn't performing as well as it could we should look at why that is and see what we can do to improve it.

If EVP isn't performing as well as it could we should look at why that is and see what we can do to improve it.

Its not an EVP vs low level thing.
Its using AES-CTR vs (simple/blockwise) AES. There are platforms which have dedicated support for the former.
If the opinion has changed in the meantime, I would suggest doing it for all platforms, as in my original proposal.

Why doesn't the existing CTR implementation use AESNI anyway? It should be using the fastest available implementation for the platform.

Existing DRBG CTR creates cipher context of ECB type and random generator calls aesni_ecb_encrypt for every block, instead of aesni_ctr32_encrypt_blocks.

Adding a separate AESNI DRBG variant seems like completely the wrong approach to me.

Correct, Currently I added as separate DRBG method mainly to compare the differences. Need to make it as one.

Existing DRBG CTR creates cipher context of ECB type and random generator calls aesni_ecb_encrypt for every block, instead of aesni_ctr32_encrypt_blocks.

So this seems to be the cause of the problem. I see we are doing this:
https://github.com/openssl/openssl/blob/93863030867ad0331bf7f199f8a266ad99ee4cf2/crypto/rand/drbg_ctr.c#L375-L391
If those EVP_CIPHER_fetch calls were changed to fetch AES-*-*CTR instead, and the drbg_ctr implementation modified to use those rather than trying to manage the ctr operation itself then it should automatically gain the performance benefits of an optimised implementation (where one exists for the platform).
I wonder why ECB is being used here? Is there some limitation of the EVP interface that prevents us using the AES-*-CTR EVP implementations here for this use case?

If those EVP_CIPHER_fetch calls were changed to fetch AES-*-CTR

Along with this, can we change block wise call in drbg_ctr_generate() to multi block call ?
But we are currently passing CTR counter as input block in every call, that we will not be able to do easily. I feel mainly for this we would have used ECB instead of CTR cipher.

I wonder why ECB is being used here? Is there some limitation of the EVP interface that prevents us using the AES-*-CTR EVP implementations here for this use case?

No, you simpley need plain AES operations to implement the DRBG. Even with the CTR optimization you will still need some to do a single block AES encryption at times.

Along with this, can we change block wise call in drbg_ctr_generate() to multi block call ?

Well, we can't change the arguments to that function very easily (because it implements a public function in RAND_DRBG_METHOD). But we can change its implementation anyway we see fit. If it makes sense to do multi-blocks in one go then I see no reason not to. Are there any downsides?

But we are currently passing CTR counter as input block in every call, that we will not be able to do easily. I feel mainly for this we would have used ECB instead of CTR cipher.

Maybe I'm just not understanding what you're saying, or I'm not familiar enough with the drbg implementation. Surely if we swap to use a CTR cipher we don't need to pass the ctr with every call? That's all managed internally to the implementation of the cipher.

No, you simply need plain AES operations to implement the DRBG.

Why is this?

Even with the CTR optimization you will still need to do a single block AES encryption at times.

Again why?

Well, look at all DRBG operations except generate e.g., update. I mean one could always implement a single AES encryption using CTR by using input as IV and encrypt a 0 buffer instead ... but that would just be weird.

I wonder why ECB is being used here?

It's because the counter mode used by the DRBG is not provided by
the EVP interface. It is not CTR32. Using ECB and implementing the
correct counter in the DRBG was the easiest thing to do.

It's because the counter mode used by the DRBG is not provided by
the EVP interface. It is not CTR32. Using ECB and implementing the
correct counter in the DRBG was the easiest thing to do.

Ah ok. That makes sense. Why are we using a non-standard counter? Is that because of the NIST standard? Would it make it in anyway less secure to use the standard counter? If not, I could see us implementing a non-nist-drbg-ctr as well as the standard drbg-ctr....but still using EVP to fetch the ciphers (without using the low level interface). I could also see us teaching the low level implementations about the alternative counter variant...either as a completely new mode, or as some kind of ctrl/param of the existing one.

Yes, it's required by the NIST standard.
I assume that if we use a different counter, the amount of data we
can generate with it becomes lower. We already use a lower limit
than allowed by NIST before we reseed. So my guess is that it's safe
to use a different counter.

It's because the counter mode used by the DRBG is not provided by
the EVP interface. It is not CTR32. Using ECB and implementing the
correct counter in the DRBG was the easiest thing to do.

Ah ok. That makes sense. Why are we using a non-standard counter? Is that because of the NIST standard? Would it make it in anyway less secure to use the standard counter? If not, I could see us implementing a non-nist-drbg-ctr as well as the standard drbg-ctr....but still using EVP to fetch the ciphers (without using the low level interface). I could also see us teaching the low level implementations about the alternative counter variant...either as a completely new mode, or as some kind of ctrl/param of the existing one.

Some more historical background: The original FIPS 2.0 DRBG implemented the AES-CTR mode strictly following the NIST SP800 90A reference implementation and using the low level AES functions (see fips_drbg_ctr.c).
When it was reported in

Issue #5559 - Lack of performances compared to 1.1.0

that the CTR-DRBG performed badly, the implementation was changed blockwise from AES to EVP by @kroeckx, leaving the counting scheme untouched.

PR #5580 DRBG: Use the EVP layer to do AES encryption  (merged to dbdcc04f27db70ac71748eb595ce23c9733afbe7)

It would have been nicer (and faster) to use @p-steuer's approach

#4530 - aes ctr_drbg: use all platform specific aes support

but it turned out that the counting in the DRBG was done slightly differently from the standard AES-CTR way. The incompatible implementations of the counter mode turned a problem too difficult to solve for the late 1.1.1 beta (commit dbdcc04f27db70ac71748eb595ce23c9733afbe7 went into OpenSSL_1_1_1-pre4).
I actually believe that initially the NIST SP800 90A reference implementation was not mandatory, it was meant to be an example. So in theory, it could be possible to change the DRBG counting scheme and have it FIPS approved.
However, in practice everybody followed the reference implementation literally and many of the the CAVS and KAT test vectors probably rely on it and would break if we change the counting. And that would make FIPS evaluation of the DRBG much more complicated if not impractical.

Good summary.

I actually believe that initially the NIST SP800 90A reference implementation was not mandatory, it was meant to be an example. So in theory, it could be possible to change the DRBG counting scheme and have it FIPS approved.

Yes.

All DRBG mechanisms and algorithms are described in this document in pseudocode, which is intended to explain functionality. The pseudocode is not intended to constrain real-world implementations.

[Chapter 9, NIST SP 800-90A Rev. 1]

However, in practice everybody followed the reference implementation literally and many of the the CAVS and KAT test vectors probably rely on it and would break if we change the counting.

No. All NIST KAT vectors were originally part of my PR. Actually that was the only part of my PR that got merged.

Well, if you think it can be done, go ahead with #4530 :-)

My proposal would have been behavorial equivalent to an outside observer, just some counter in the internal state would have been kept at +1 or -1 (dont remember) compared to the reference implmentation.

In hindsight it might be that I did not fully understand this part of your pull request at that time. I thought you were effectively changing the counting scheme. If the output is exactly the same (i.e. the CAVS tests succed) and only the internal representation slightly different, I don't see why it could'nt be FIPS approved. In fact it should be if it increases performance significantly. Even a backport to 1.1.1 as performance enhancement would be an option.

One could even easily work around the counter thing by doing a decrement after the aes-ctr operation (which is unusual, but would keep internal state in sync with pseudo code).
The major blocker at that time was that it didnt use EVP though.
Im looking into it again right now.

The major blocker at that time was that it didnt use EVP though.

I still consider EVP to be a requirement. But we can add ctrls/params/special modes to make it do what we want.

@raja-ashok thank you for your contribution nevertheless, even though we decided to take a different path.


Explicit call to Save() does nothing when AutoSave is set to false

In current implementation explicitly calling Save() from OpenXmlPackage does nothing when AutoSave option is set to false.
It's because Save() calls SavePartContents() which checks if AutoSave is enabled.
This makes sense when SavePartContents() is called from Dispose() method, because we shouldn't save automatically during disposal when this flag is set to false, but shouldn't explicit call to Save() actually save package regardless of AutoSave state?

Thanks for reporting this!

@twsouthwick What exactly is Save() supposed to do? I mean only saving the document (with autosave enabled) produces a corrupted package. Is there any way to save the document without having to close it?

@encrypt0r  This seems like it would be a different issue (corruption versus a no-op). Can you open an issue with a repro?

@twsouthwick actually after more testing it doesn't save at all (AutoSave enabled). The corruption was due to some other reasons. I have setup a repo That shows the problem. After calling Workbook.Save() and SpreadsheetDocument.Save() the stream is still empty. Have I missed something?

@encrypt0r I'll take a look. Can you open a new issue for this?

@encrypt0r This has been enabled in the latest CI build available here: https://dotnet.myget.org/gallery/open-xml-sdk. You'll want to upgrade to at least 2.7.3-vnext0051


Enables dependant variable substitution

Resolves https://github.com/microsoft/vscode/issues/80219
Adds 1 new behavior for variable substitution in launch.json:

Each variable substitution is available to be used in subsequent substitution

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: scabana sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Tests pending approval of the feature/changes.

Tests pending approval of the feature/changes.

Well, a test was added.

Closed based on comment in issue


TypeScript: add Props type to component constructor

What problem does this feature solve?
It would be useful if we can infer Props type from component (ExtendedVue).
For example, we can write type safe wrapper of CreateElement with it (or improve interface of CreateElement directly).
function renderComponent<Props>(
        h: CreateElement,
        component: ExtendedVue<Vue, {}, {}, {}, Props>,
        data: VNodeData & { props: Partial<Props> },
        children?: VNodeChildren): VNode {
  return h(component, data, children);
}

const MyComponent = Vue.extend({
  props: { foo: String },
  render(h) { return h("div", this.foo) };
});

const Parent = Vue.extend({
  render(h) {
    return renderComponent(h, MyComponent, { props: { foo: 0 } }); // error: type of property 'foo' are imcompatible
  }
});

What does the proposed API look like?
Now, ExtendedVue<Vue, {}, {}, {}, { foo: string }> and ExtendedVue<Vue, {}, {}, { foo: string }, {}> generate same type.
This means we can't determine Props type from ExtendedVue object.
I think, easiest (and most reasonable) way to achieve this is adding types to $props and $data
- export type CombinedVueInstance<Instance extends Vue, Data, Methods, Computed, Props> = Instance & Data & Methods & Computed & Props;
+ export type CombinedVueInstance<Instance extends Vue, Data, Methods, Computed, Props> = Instance & Data & Methods & Computed & Props & { $data: Data, $props: Props };

Actually we can do better here. By changing Vue to a generic type constructor (with default), we can encode Vue.extend to return a constructor with $props and $data typed. Plus, typed JSX will be enabled.
But this will make our complex typing file more complicated. Let's first make Vue2.5 stable and wait for more feedback.
If you like this idea, please vote by emoji!

Sounds nice.
Above all, it would be very nice if vue supports typed JSX by default.
(I have a small library to add types to component for typed JSX. AAMOF, this issue comes from it.)
BTW, current typing loses the information about each props are required or optional, which is necessary for typed JSX.

current typing loses the information about each props are required or optional

Fairly I don't think we can make a typing for current API, at least current TS' type system does not support it.
Example

I have been using library mentioned, I think first step we can do is make all props optional when using TSX with Partial, unless passing a declared interface.
It will then be an enhancement when TS does support it. I think we should also create a TS issue to make awareness of this requirement linking back to this issue.
Agree to mature TS layer and then move forward with typing to include use cases like this. I do believe we should support typed TSX out of the box with props inferred.
Unfortunately but ultimately great Vue API also has more custom attributes to TSX such as scoped slots and events that we need to cater for. So interfaces will still be required as far as I can see. However where possible we should reduce the needed typing especially where duplication occurs, such as prop definitions.

How about an approach like below ?

(It works, but type definitions will become more complicated ...)

@wonderful-panda we could form requiredProps from props object no?

@blake-newman
It may be impossible to obtain requiredProps from props at compile time.
In above example, type of repuiredProps is ("foo"|"bar")[]

Yes sorry forgot about that

Hello,
What's the current state of this issue?
I'm taking a look on these really old GFI tickets.
I can try to help, just need some details about how to proceed.
Thanks in advance.


Shift + scroll wheel zoom

It would be nice if holding the Shift key while scrollwheel-zooming would multiply the zoom delta by 3.
Rationale is that I'm very used to shift-scrolling in text editors, and I expect that shift-scrolling would do the same as scrolling, but faster.

Hmm, never seen that behaviour in any editors I've used — is this common? I don't mind adding this to Leaflet though, in addition to the already added shift-click on zoom buttons or shift+keypress +/-.

I'd wait until #3523 gets merged in order to tackle this down. No need to worry about a minor feature such as this.


defaultProps and object destructuring defaults are treated differently

https://flow.org/try/#0PTAEAEDMBsHsHcBQBLAtgB1gJwC6gEoCmAhgMZ6RayqgDkWJ5tA3IoqdMQM5egCCoQgA8chAHYATXkTI4AdAGFqmMeJwAeAN6hIsWAC5QXHFmRiA5qAC+APlCbEASGPEcyUqAmFIxAK7QcAAUqdF4AXntEUGjQR10DOgAjYixaABoo2KtWJwZJQiwACgBKSOjHRwYcXywxUBwAC2QuOXQQlvjWRytEHsRIXzFyZFg6gCFC7XjQCNpk1OtDKb1DY1MLa1KHcqqaus7etgGht1HQABVCYxKy2N3a0ELM8vUJZAA3G0yKx3UBYC+MSBsXUY1AAPBYAKVCw31+wDenyijmKrD6-UGwzOl2MACYbts7oRqg8nkDfojAbEKn9wVTgSCwfEwgAieYsumQ0BiWCCLAwuHqBEfQEotFAA
Basically, defaultProps is properly interpreted (or not?) by Flow, and then if you define a property with a default value, you don't have to mark it as optional, because a value will always be present.
Object destructuring, on the other hand, will ask you to mark the property as optional even if you assign a default value to it

Just want to note that you can write your code like this

Yes that's an alternative, but since I already use object destructuring it makes much sense to use the default values feature of it.

I think there's a difference:
for React.Component when you type Props you describe a type of a this.props, not of an interface. So flow calculates the type of an interface of the component using this information and defaultProps.
for a function, when you type a function parameter, you type function's interface in first place.
From my point of view, it would be better to change the way how we work with components and to start type their interface instead of props - but I'm not sure it can be reached in practice.

Came here to +1! It doesn’t seem quite right that I can’t use Object destructuring default values as an alternative to defaultProps. I expect the following to run without errors:
type Props = {
  value: boolean
}

function Thing({value = true}: Props) {
  return
The value is {value ? 'true' : 'false'}!

}

function App() {
  return (

      <Thing value={false} />
      <Thing />

  )
}

This currently fails with Flow 0.96.1: Test case.
And passes when using defaultProps: Test case.

@daneden My understanding is defaultProps and default parameters are handled differently by Flow, which makes sense after all. While defaultProps should be marked as required since Flow will do it's $Diff thing, default parameter should be marked as optional. Flow will understand there's a default and don't require you to define check those params.

Expected behavior


DON-885 – permit <biggive-campaign-card/> having no figures or progress bar

LGTM. I've suggested what I think is a slight simplification in https://github.com/thebiggive/components/commit/20b63e8e52f9722a8e5198591f3864312fb8edbc but you can take it or leave it.

LGTM. I've suggested what I think is a slight simplification in 20b63e8 but you can take it or leave it.

Thanks @bdsl. I think that as the nesting in the markup is the same and the short-circuit version adds a fn, I slightly prefer this way. Don't feel hugely strongly either way though.


Fix KeyError Introduced in https://github.com/grpc/grpc/pull/25871

Fixes the following error:
+ python3 grpc/tools/run_tests/run_xds_tests.py --test_case=all,path_matching,header_matching,circuit_breaking,timeout,fault_injection --project_id=grpc-testing --project_num=830293263384 --source_image=projects/grpc-testing/global/images/xds-test-server-4 --path_to_server_binary=/java_server/grpc-java/interop-testing/build/install/grpc-interop-testing/bin/xds-test-server --gcp_suffix=1617668358 --verbose '--client_cmd=grpc-go/interop/xds/client/client       --server=xds:///{server_uri}       --stats_port={stats_port}       --qps={qps}       {fail_on_failed_rpc}       {rpcs_to_send}       {metadata_to_send}'
Traceback (most recent call last):
  File "grpc/tools/run_tests/run_xds_tests.py", line 53, in <module>
    original_grpc_trace = os.environ.pop('GRPC_TRACE')
  File "/usr/lib/python3.4/_collections_abc.py", line 546, in pop
    value = self[key]
  File "/usr/lib/python3.4/os.py", line 633, in __getitem__
    raise KeyError(key) from None
KeyError: 'GRPC_TRACE'

I'll do a manual run of one of the failing jobs before merging.

@menghanl How does the core repo get pulled in for the run_xds_tests.py script. The Kokoro job I'm looking at only has configuration for the grpc-go repo. I don't see how I can do a manual run of this. In fact, it's only repos besides this one that are failing, so it seems difficult to test in general.

There's probably no easy way to trigger a go build.
The only way would be to ssh to a VM, and manually run it.

I'm fairly confident that this will fix the issue. Let's go forward with this and we can just do a revert if the off chance that there any problems.


[sycltest] Implement the framework test for the SYCL/oneAPI backend

Implementation the sycltest test of the host and device framework for the SYCL/oneAPI backend,
based on the cudatest program, summarily translated by DPCT, fixed and reworked.
Known limitations:

caching of device and host memory, queues (streams) and events has been removed
there is no explicit support for device selection, so left to be driven by environment variables
not all oneAPI backends are working

@makortel here is first draft of the sycltest program.
We have more work to do, but this version already compiles and runs on the "host" device and on the Intel gen9 integrated GPUs OpenCL backend.
And, the performance is likely horrible for the moment...

@lauracappelli @Viola27 FYI

With the latest commit the test runs on all reasonable backends:
 SYCL_DEVICE_ALLOWLIST='DeviceName:{{.*CPU.*}}|DeviceName:{{.*Gen9.*}}' ./sycltest --maxEvents 10 --numberOfThreads 1 --numberOfStreams 3
Found 3 SYCL devices:
  - Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
  - Intel(R) Gen9 HD Graphics NEO
  - SYCL host device

Processing 10 events, of which 3 concurrently, with 1 threads.
TestProducer  Event 1 stream 0 ES int 42 FED 1200 size 2152
EDM stream 0 offload to Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
TestProducer  Event 2 stream 2 ES int 42 FED 1200 size 2456
EDM stream 2 offload to SYCL host device
TestProducer2::acquire Event 2 stream 2 array 0x7fe8a805da80
TestProducer3 Event 2 stream 2
TestProducer  Event 3 stream 1 ES int 42 FED 1200 size 2040
EDM stream 1 offload to Intel(R) Gen9 HD Graphics NEO
TestProducer2::acquire Event 1 stream 0 array 0x17ed5180
TestProducer3 Event 1 stream 0
TestProducer2::produce Event 2 stream 2
TestProducer  Event 4 stream 2 ES int 42 FED 1200 size 2224
EDM stream 2 offload to SYCL host device
TestProducer2::acquire Event 3 stream 1 array 0x7fe8a84b6000
TestProducer3 Event 3 stream 1
TestProducer2::produce Event 1 stream 0
TestProducer2::acquire Event 4 stream 2 array 0x18936d00
TestProducer3 Event 4 stream 2
TestProducer2::produce Event 4 stream 2
TestProducer  Event 5 stream 2 ES int 42 FED 1200 size 1864
EDM stream 2 offload to SYCL host device
TestProducer  Event 6 stream 0 ES int 42 FED 1200 size 1936
EDM stream 0 offload to Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
TestProducer2::acquire Event 5 stream 2 array 0x18936d00
TestProducer3 Event 5 stream 2
TestProducer2::produce Event 3 stream 1
TestProducer  Event 7 stream 1 ES int 42 FED 1200 size 2024
EDM stream 1 offload to Intel(R) Gen9 HD Graphics NEO
TestProducer2::acquire Event 6 stream 0 array 0x7fe8a866a800
TestProducer3 Event 6 stream 0
TestProducer2::produce Event 5 stream 2
TestProducer  Event 8 stream 2 ES int 42 FED 1200 size 1976
EDM stream 2 offload to SYCL host device
TestProducer2::acquire Event 7 stream 1 array 0x18994000
TestProducer3 Event 7 stream 1
TestProducer2::acquire Event 8 stream 2 array 0x7fe8a87a7180
TestProducer2::produce Event 6 stream 0
TestProducer3 Event 8 stream 2
TestProducer2::produce Event 7 stream 1
TestProducer  Event 9 stream 1 ES int 42 FED 1200 size 2320
EDM stream 1 offload to Intel(R) Gen9 HD Graphics NEO
TestProducer  Event 10 stream 0 ES int 42 FED 1200 size 3080
EDM stream 0 offload to Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
TestProducer2::acquire Event 9 stream 1 array 0x7fe8a8108000
TestProducer3 Event 9 stream 1
TestProducer2::produce Event 9 stream 1
TestProducer2::produce Event 8 stream 2
TestProducer3 Event 10 stream 0
TestProducer2::acquire Event 10 stream 0 array 0x19575000
TestProducer2::produce Event 10 stream 0
TestProducer2::endJob processed 10 events
Processed 10 events in 9.827208e+00 seconds, throughput 1.01758 events/s.

With the latest commit the test runs on all reasonable backends:

Very nice. Now I would just have to figure out a way to test it myself :)

I'm thinking to being ready to merge this PR as it is (@fwyzard tell me if you think otherwise). Even addressing the testing discussion in https://github.com/cms-patatrack/pixeltrack-standalone/pull/102#discussion_r498563352 would have the implication that make test (as make all already does now) would require both nvcc and SYCL compiler. I'd like to be able to have some simple way to build and test the part that requires only nvcc, and that would require some further reorganization of Makefile targets, that could be best done after this PR.

Yes, I think we can merge this as-is, and work on improving things in future PRs.


Additional empty line after pipeline via string collect -N

Input: APP_VERSION="v$(jq -r \'.version\'  ./package.json)-local"
Translated: set APP_VERSION 'v'(jq -r \'.version\' ./package.json | string collect -N; or echo)'-local'
Output:
v1.x.x
-local

Expected: v1.x.x-local
string collect -N emit one more empty line, this can be removed with awk NF, for example: set APP_VERSION 'v'(jq -r '.version' ./package.json | string collect -N | awk NF; or echo)'-local'

I think the -N flag is not needed.

Yes, remove -N will work, if you don't need it for specific reason


Add functions to set and get camera framerate

These changes are, for the most part, taken from https://github.com/blackjack/webcam/pull/32 (the branch originating the mentioned PR is no longer available).

Looks good. Thanks you!


Construct and implement generalized FFFT

I don't see a reason not to implement an FFFT that works for any number of modes (not just powers of 2). Has anyone considered this? I think the T-count would also be much better than using Givens rotations.

The task here is to perform the transformation in Eq. (11) of https://arxiv.org/pdf/0804.1888.pdf. The right boxed part of Figure 1 shows the structure of the circuit when the number of modes is a power of 2. As you can see, it's possible to perform this case with depth n log n and linear connectivity, where n is the total number of modes. The circuit structure is exactly the same as the classical Cooley-Tukey algorithm. I think the relation with the Cooley-Tukey circuit is a bit clearer in Figure 1 of https://arxiv.org/pdf/1310.7605.pdf, although that figure doesn't show how to do it with linear connectivity. The term "FFFT" comes from https://arxiv.org/pdf/1706.00023.pdf, which also contains some useful information.
As I said above, I believe it's possible to get it to work for numbers other than power of 2. The idea is that the FFFT on n = n1 * n2 modes can be done by performing two smaller FFFT's of sizes n1 and n2. I think the first step is to work out what the circuit for this decomposition looks like. If it works out, then implement the recursive structure of the circuit. The base case should be handled in a general way, i.e., perhaps by defining a "prime number FFFT gate" which we can later define custom decompositions for.
The discussion so far is just on the 1-d FFFT. This is clearly the first step. We can worry about the 2-d and 3-d versions later.
I think the function signature for the 1-d FFFT should just be ffft(qubits: Sequence[cirq.QubitId])

Here is a short note I wrote on the operation of rotating together fermionic modes under the JWT. It might be useful for understanding what's going on.
givens_rotations.pdf


complicated reducer

after reducing boilerplate, now the algorithm is hard to read.

made algorithm simpler, closing issue


resolve-march-native: use gcc-unwrapped for detection

Description of changes
The wrapper that is used with the nixos gcc, does remove --march=native, before handing over to gcc which means that the detection is not useable out of the box and a user has to manually override the programs gcc with its --gcc argument to an unwrapped gcc or one can set NIX_ENFORCE_NO_NATIVE, but thats also not the easiest solution to find.
This patch does propagate the unwrapped gcc which prints out the actual result without any customizations.
That should improve the UX for the application on nixos quite a bit.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 278964 run on x86_64-linux 1

2 packages built:

resolve-march-native
resolve-march-native.dist


Error 404

Create a new component called *Error.
Make this component show every time the user enters any other route that does not exist.

Done. #50


Python Simple ITK Resample and Convert DICOM to Common Image Formats

Hi everyone,
I'm trying to use this example code (https://simpleitk.readthedocs.io/en/master/link_DicomConvert_docs.html)  for reading and manipulating a sequence of Dicom images which I stored into a folder on my computer. I can't understand how or where to add my folder path in order to get python to run this code for my images.
Can anyone help me?
Thanks in advance

Hello @charlotte10170,
To understand what parameters the program is expecting run (will print all options):
python DicomConvert.py -h

To run with minimal settings, input directory name is "input/" convert to "png" format:
python DicomConvert.py input/ png

The program uses the argparse module to parse the commandline.


[WIP] Integrate PRs with Appetize

Looking at integrating branch builds with https://appetize.io/ so we can try the features built on a branch without pulling code locally. We might want to run scripted journeys against this system in the near future too.
Crucially once deployed to Appetize, we need to comment back into a PR or set a build status with a link for easy PR review and testing.
Pre-flight check-list
Before raising a pull request

[ ] Documentation
[ ] Unit tests

Pre-merge check-list

[ ] Tester approved

I've almost got this working and reporting back with a build status and link. Parked it briefly to take a break and build some UI, which I think would be more helpful right now because people can start building on top of UI scaffolding.

I think this is great and just want to ask if we think this will be suficient for merging approval/testing? Or should I look further at adding deploys to hockeyapp by suffixing the branch or sha to the binary ID so that it's plausible for people to hunt for the build in hockeyapp or have them sent to a Slack channel. Or should we have master be our 'qa' branch and then have release branches? Just trying to picture what the flow would look like for an individual feature.

Well this will be useful, but a physical device will always be good for testing. Do you think we'll be able to do that with hockey app? Because if we can slugify the branch name and allow people to install any version of the app they like from hockeyapp that would be incredible.

With the branch builds and automated testing we have now I don't think we really need this anymore. Going to close the PR for now.


[FLINK-23201][streaming] Calculate the alignment time only for the last checkpoint

…th monotony of time

What is the purpose of the change
The broken scenarios:
org.apache.flink.streaming.runtime.io.checkpointing.CheckpointBarrierHandler#markAlignmentEnd(long) is called with default value of startOfAlignmentTimestamp which is Long.MIN_VALUE. It means that markAlignmentEnd is called before markAlignmentStart. It can happen in the following situation:
A --
    |---> C
B --

A successfully checkpoints id = 1 = sends barrier = 1
B takes longer to take a checkpoint
we trigger checkpoint id = 2
A again checkpoints id = 2 successfully, sends barrier = 2, it does not send cancel = 1, cause it succeeded
B sends cancel id = 1, because it was pending
C receives barrier = 2 from A first, then cancel id = 1 from B

The second scenario:

C receives the first barrier = 1
C receives the first barrier = 2
C receives the last barrier = 1 (it sees the wrong start time)
C receives the last barrier = 2 (it sees nothing because the previous barrier reset the data)

Brief change log

Reset alignment time only when we don't wait for the last barriers

Verifying this change
The check was added which only check the existed invariant so only regression test needed.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@flinkbot run azure


bug: compaction schedule loop can be stuck when there is compactor failure

Describe the bug
As titled.
Currently we use "total assigned task num across all compactors" and "total max concurrent task num across all compactors" to resume compaction: https://github.com/risingwavelabs/risingwave/blob/2e33fefd2aa8ccee681e4d3cd050ca483aabaae4/src/meta/src/hummock/manager/mod.rs#L1360
This can be problematic when there is a compactor failure since the assigned task may not be cleared immediately when the compactor is removed from the schedule policy.
Assume per compactor assigned task limit is N

Time
Compactor
Number of Assigned Task
CompactionSchedulePolicy::max_concurrent_task_num = (# of compactor) * N
Notes

T1
C1 up
N
N

T2
C1 paused
N
0
Compactor is removed from the policy but the assigned task state is not cleared

T3
C1 paused, C2 up
N + N
N
N more tasks are assigned to C2

T4
C1 paused, C2 up
N + N - x
N
There are x tasks finished by C2

T5
C1 removed, C2 up
N - x
N
If x ≠ 0, we may miss try_resume_compaction

The schedule loop will be blocked since T3 and will not be unblocked if x>0.
To Reproduce
No response
Expected behavior
No response
Additional context
No response

cc @Li0k @Gun9niR @wcy-fdu

So as long as the compactors of other CNs complete some tasks while some paused task has not being cleaned up,  this problem may be caused?

I think the solution is to take paused compactors into consideration when calculating max_concurrent_task_num.

I think the solution is to take paused compactors into consideration when calculating max_concurrent_task_num.

Currently we just add a timeout check for all paused compactor, after timeout it will be removed, and get_idle_compactor  can work normally, so that the left side N-x can raise up instead of getting stuck.

When I wrote https://github.com/risingwavelabs/risingwave/blob/2e33fefd2aa8ccee681e4d3cd050ca483aabaae4/src/meta/src/hummock/manager/mod.rs#L1360
the assumption is all ended tasks (canceled, finished, etc) will go through HummockManager::report_compact_task. When a compactor is removed, we use Compaction::cancel_assigned_tasks_for_context_id to cancel all tasks assigned to the removed compactor, so in T4 -> T5, compaction scheduler is not notified.

quick fix

https://github.com/risingwavelabs/risingwave/pull/10163

Fixed by #10162 and #10163.


Microbitv2 blogpost

Import, format, adjust images, etc. for the micro:bit V2 blogpost.
See if you like the name of the blogpost path and the size of the GIF. Both can change if you want.
Closes #7646

We should also call out the set touch mode block in Pins

By default, the logo is set to capacitive touch and the edge connector pins to resistive touch, but the set touch mode block enables you to change the default mode.

Can we capitalise the V in the post filename? microbitv2.md > microbitV2.md

Otherwise LGTM. Thanks @ganicke @Jaqster  👍


It shows deleted on the editor.But not.

VSCode Version: 1.13.0 insider
OS Version: Win 8.1

Steps to Reproduce:

Just try to delete any folder through the VS Code editor. It shows nicely removed.
But when I go to the physical location it's there. In other words not deleted from the physical location.
I open the VS code as an Admin.

Please see if you can find any logged output that could help us find the source of the issue:

run code --verbose from the command line and attach the output
in Code select Help | Toggle Developer Tools and select the Console
attach any output you see in the Console you can find

Thanks!


Support mix of concrete inheritance and pydantic mixin

Is your feature request related to a problem? Please describe.
When defining an ormar.Model and inheriting from both an abstract ormar.Model and a mixin (pydantic in my case), two problems arise:

The resulting model is abstract by default, see #876 (couldn't edit the issue sufficiently so I decided to reference it here)
Two database tables are generated (e.g. "nation" and "nations"), both with the mixin fields missing.

Describe the solution you'd like
Modifications to the inheritance design so that the resulting model is working and non-abstract.
Describe alternatives you've considered
Using abstract ormar.Model instead of pydantic BaseModel for the Create, Read and Update classes (if I understood everything correctly, I have to use ormar Fields anyway and the validation should still work). I don't know how much parsing/validation overhead I am adding with this though.
EDIT: just tried it and it does not work since an abstract ormar.Model can of course not be instantiated and thus not used for validation :man_facepalming:
UPDATE: I must have made some kind of mistake; I can only recreate one of my findings on second try: the mixin fields don't appear in the final tables. I've updated the issue accordingly.

Sadly I haven't been able to fully understand how both these mechanisms of inheriting work in ormar, otherwise I would attempt to fix it myself..

Update: just discovered that if your mixin model doesn't inherit from any parent model (or at least not from a pydantic BaseModel), the combination actually works. Makes sense that there's interference if one considers how much pydantic stuff is already fused into ormar.Model. I updated the title to reflect this.
Some gripes I have:

It seems to be neither documented nor tested that a combination of ("vanilla") mixin and concrete inheritance is possible, even though this might be a useful application.
I still can't reuse my pydantic CRUD models.

After studying the process for a bit, I am now fairly certain of what happens and what has to be done to support the desired behaviour :

In ormar.models.metaclass.extract_from_parents_definition(), a check happens whether the given base class has potential fields to copy to the new model.
Said check assumes that the fields would be immediately visible in base_class.dict, not nested in the "fields" key as they are in pydantic BaseModels
Therefore no fields to add are found and the resulting model doesn't get them
One would have to check if the base_class in question is a subclass of pydantic.BaseModel and then extract the fields in a different manner, probably by calling base_class.__fields__

The last point is what I'm now trying to do but tbh it requires some deeper knowledge of how BaseModels, ormar.Models and classes in general work in order not to make mistakes and I must admit that I do not have that knowledge quite yet. Will continue my work tomorrow

Problem: pydantic automatically converts ormar Fields to pydantic Fields upon model creation, so the added information in ormar Fields is lost if I am not mistaken. That would mean my desired behaviour could only be achieved by hacky solutions, something I'd like to avoid. Maybe I'll just go the other way round and start with the model with all the fields (table model) and generate the CRUD models from it using get_pydantic(exclude={fields_i_dont_need_here}).


performance on double solid lines prediction

after training on a new small dataset , there is a bad performance on  double solid lines, what do you think of this phenomenon? is it due to the influence of  anchor generation?

Please see #36 .


Right click menu doesn't close

When right clicking, an options window opens but cannot be closed through the top bar.
Another right click closes it but this isn't "normal" behavior one would expect....IMO: add a close option :)

when the options window is opened, to cloe it, you can either :

right click
press Esc key
click on the option icon at the top

isn't it sufficient ?

isn't it sufficient ?

not for people who aren't used to it. people might get confused.

i'll think about it
Note that README.md is describing (or will describe...) what can be done

btw, do you prefer a"close" button at the bottom (left or right) or a icon (a 'X' icon for example) to close the setting window ?

btw, do you prefer a"close" button at the bottom (left or right) or a icon (a 'X' icon for example) to close the setting window ?

I think simply adhering to the standard used by the DE will do.
In this (E) case I'd go for a top right, in the top bar.

note that it's not really a window. I'll add an 'X' at the top right, then

note that it's not really a window. I'll add an 'X' at the top right, then

Consider this issue closed IMO.

something like that : https://ibb.co/Wykhpyj ?

now it's in git, closing


incompatibility between zeroHashes and custom hash function

In case you want to provide custom hash function behavior can be quite unexpected.
It happens because zeroHashes is global variable that is initialized by default with sha256:
https://github.com/ferranbt/fastssz/blob/f43e88e3e05ffc6f01540c312653d471a10d2ff2/hasher.go#L39

Hi, what is your use case for a custom hash function?

Hi! I want to use poseidon hash instead of sha256


rip collects and tries to build packages explicitly against the users requirements

Environment: Linux Python 3.11
Command: cargo r -- apache-airflow[all]==2.8.1 apache-beam>=2.47
Error:
2024-01-25T19:59:26.200863Z ERROR rattler_installs_packages::index::package_database: Error from source distributions 'apache-beam-2.42.0.zip' skipped:
 could not build wheel: <string>:28: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
Traceback (most recent call last):
  File "/tmp/.tmpo1wZW0/build_frontend.py", line 124, in <module>
    get_requires_for_build_wheel(backend, work_dir)
  File "/tmp/.tmpo1wZW0/build_frontend.py", line 58, in get_requires_for_build_wheel
    result = f()
             ^^^
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/setuptools/build_meta.py", line 325, in get_requires_for_build_wheel
    return self._get_build_requires(config_settings, requirements=['wheel'])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/setuptools/build_meta.py", line 295, in _get_build_requires
    self.run_setup()
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/setuptools/build_meta.py", line 480, in run_setup
    super(_BuildMetaLegacyBackend, self).run_setup(setup_script=setup_script)
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/setuptools/build_meta.py", line 311, in run_setup
    exec(code, locals())
  File "<string>", line 99, in <module>
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 528, in get_distribution
    dist = get_provider(dist)
           ^^^^^^^^^^^^^^^^^^
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 400, in get_provider
    return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 968, in require
    needed = self.resolve(parse_requirements(requirements))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 829, in resolve
    dist = self._resolve_dist(
           ^^^^^^^^^^^^^^^^^^^
  File "/tmp/.tmpo1wZW0/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 870, in _resolve_dist
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pip' distribution was not found and is required by the application

thread 'main' panicked at 'assertion failed: self.decision_tracker.assigned_value(solvable_id) == Some(true)', /home/damian/.cargo/git/checkouts/resolvo-09a21884be70392c/7c1fa14/src/solver/mod.rs:219:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected Behavior: rip should not have even collected apache-beam 2.42.0 as the requirement explicitrly stated apache-beam>=2.47
If this was collected because it was an sdist build requirement (I don't think so? But it's hard to tell from the logs), then I think rip must provide a way to constrain build requirements.

That is interesting, because I agree it should not even consider these versions. Also, the assertion is a bug as well.

@tdejager even with your output it tries a version of apache-beam that conflicts with the second spec though.

Yeah I know, I just want to know it the assertion is gone ;)

I'll have a look if I can create a reproducer in Resolvo.

This is a user error 🤦♂ . The following installs fine:
cargo r -- "apache-airflow[all]==2.8.1" "apache-beam>=2.47"

The following:
cargo r -- apache-airflow[all]==2.8.1 apache-beam>=2.47

Attepts to install apache-airflow[all]==2.8.1 apache-beam and create a file called "=2.47".
The fact that the latter fails to install is better covered by https://github.com/prefix-dev/rip/issues/174

That is interesting, because I agree it should not even consider these versions. Also, the assertion is a bug as well.

Also, I retested on main and am no longer getting this assertion error.

Great! The funny thing was I thought: "Oh does that work without quotes" 🤦 😄


Feature Request - include date in logfile name

Hi Romanitho
Thanks for your amazing work!
We'd like to centrally collect the installation logs from Winget-AutoUpdate to investigate failed installations. Therefore it would be more comfortable to create a log file per day, and grab that log file each day with a scheduled task / some other way.
What about a -DateInLogfileName Switch, which would be checked in Start-Init.ps1 for example as following?:
$date = $(Get-Date -UFormat "%d-%m-%Y")
Script:LogFile = "$LogPath\$date-updates.log"
Kind regards,
Dom

Hi
Thanks 😊
It is more confortable for me to have all under one log file to be honest. As this is something I don't check everyday, I can open one log file and have a look on previous runs at once.
I was thinking about a feature that can centralize install errors. (Sending an email with computer name and failed updates to an IT mailbox for instance).
But create a daily log can be easy to purge as well. We need to think about that 😅

We're planning to use a combination of Winget-AutoUpdate and Winget-Install to manage all commonly used App Installations and Updates :) we're designing our own reporting functions by analyzing the Winget-AutoUpdate Logfile - for now - but we'd sure appreciate any form of central logging, if you ever implement it ;).
Thanks for your work! Kind regards,
Dom

We are also looking for a central logging solution. We need to think about it, but for now, no clue :)


do not hide API ID

This pull requests logs API ID (vid) parameter in order to simplify troubleshooting of common authentication and access issues.
VERACODE_API_ID in example workflows main.yml and policyscan.yml are moved from secrets to variables.
Required Information
====================
appname: swiewiora/veracode-uploadandscan-action
createprofile: false
filepath: binaries_to_upload/*.jar
version:<PHONE_NUMBER>
vid: ceabac4a1736896a699eb5537ab658af
vkey: ***

...
java -jar VeracodeJavaAPI.jar \
        -filepath binaries_to_upload/*.jar \
        -version "5467649408" \
        -action "uploadandscan" \
        -appname "swiewiora/veracode-uploadandscan-action" \
        -vid "ceabac4a1736896a699eb5537ab658af" \
        -vkey "***" \
        -createsandbox="true" \
        -sandboxname "Github - refs/heads/fix/vid" \
        -scantimeout "15" \
        -autoscan "true" \
        -criticality "VeryHigh" \
        -createprofile "false" \

the API ID is the first part of the users credentials, I would not suggest to display them at all. At least not in any automated way. Maybe for debugging that is interesting to see, but I would always choose credentials to be a secret.


Remove non-ascii characters from internal code comments

In Deno we now require 7-bit ascii for our internal code. When TypeScript builds, some of these characters end up in the build output. It seems like there weren't that many instances of non-ascii characters in TypeScript's comments so is it ok to remove them? It makes my life a little easier and makes the code a bit more consistent.
I only did a search for the characters that ended up in the build output in the "src" directory and nothing else.

This seems okay, but, why is it a requirement for Deno? Can you exempt vendored code? How can we make sure to not regress? What if we add special characters to document something?

How can we make sure to not regress?

Don't worry about it on your side. Our code just fails to build and it's easy to workaround. Only about 4 of these comments actually ended up in the output so I think it's really rare.

What if we add special characters to document something?

At that point I'll just add something to transform them.

Why is it a requirement for Deno? Can you exempt vendored code?

No, it allows us to use v8 external one-byte strings which drastically reduces our snapshot size. Once one of these characters ends up in the output then it goes to utf-16.

No, it allows us to use v8 external one-byte strings which drastically reduces our snapshot size. Once one of these characters ends up in the code then it goes to utf-16.

That's super interesting!


Option to remove some vars from session file

I see that there's an option to save additional vars startify_session_savevars. Would it be possible to add an option to remove some vars from the session file?
This would solve a pretty big problem for me. I use a plugin that sets winminheight and winminwidth values and session files contain every time the line set winheight=1 winwidth=1 that triggers a warning during the loading phase. So having an option to remove it would be awesome.
Anyway thank you so much for this plugin, really love it!

git pull && git checkout session-remove-lines
vimrc:
let g:startify_session_remove_lines = ['winheight', 'winwidth']

Can you try if this works for you?

Anyway thank you so much for this plugin, really love it!

I'm glad to hear that!

Thank you for getting back to me and implementing it so fast!
It works perfectly, I just had to change the option in vimrc to:
let g:startify_session_remove_lines = ['set winheight=1 winwidth=1']

since as you said  both winwidth and winheight appear multiple times, and that line is the only one causing problems to me.
Again, many thanks for your hard work, it's really appreciated!

Okay, I merged it into master and added a helptag for it.
Thanks for the feedback! :-)


Refactor worker execute task process

Purpose of the pull request
Refactor the task execution process in worker
Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

Codecov Report

Merging #11540 (7fd77dd) into dev (c322367) will decrease coverage by 0.06%.
The diff coverage is 14.19%.

@@             Coverage Diff              @@
##                dev   #11540      +/-   ##
============================================
- Coverage     39.66%   39.60%   -0.07%
- Complexity     4695     4700       +5
============================================
  Files           993      999       +6
  Lines         37692    37759      +67
  Branches       4198     4213      +15
============================================
+ Hits          14950    14953       +3
- Misses        21173    21208      +35
- Partials       1569     1598      +29

Impacted Files
Coverage Δ

...lphinscheduler/service/task/TaskPluginManager.java
3.33% <ø> (ø)

...dolphinscheduler/plugin/task/api/AbstractTask.java
0.00% <ø> (ø)

...hinscheduler/plugin/task/api/AbstractYarnTask.java
0.00% <0.00%> (ø)

...scheduler/plugin/task/api/k8s/AbstractK8sTask.java
0.00% <ø> (ø)

...phinscheduler/plugin/task/chunjun/ChunJunTask.java
0.00% <0.00%> (ø)

.../dolphinscheduler/plugin/task/datax/DataxTask.java
0.00% <0.00%> (ø)

...ache/dolphinscheduler/plugin/task/dvc/DvcTask.java
72.58% <0.00%> (ø)

...phinscheduler/plugin/task/emr/EmrAddStepsTask.java
64.51% <0.00%> (-3.29%)
:arrow_down:

...lphinscheduler/plugin/task/emr/EmrJobFlowTask.java
77.77% <0.00%> (-4.58%)
:arrow_down:

...he/dolphinscheduler/plugin/task/http/HttpTask.java
80.73% <0.00%> (ø)

... and 44 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

SonarCloud Quality Gate failed.
  10 Bugs   0 Vulnerabilities   0 Security Hotspots   13 Code Smells
 26.3% Coverage  0.4% Duplication

Please check the sonar result.

@caishunfeng The sonar bug has been resolved, please review again.


cut command error in macos

cut: illegal option -- -
usage: cut -b list [-n] [file ...]
cut -c list [file ...]
cut -f list [-s] [-d delim] [file ...]

run julia error in macos: exec format error: julia

It's not macos compatible, feel free to implement it. Other options are:

you can use one of the forks which do implement a macos version.
you can use asdf with the Julia plugin, which should solve your problem.

I'm not working with julia anymore, so keep this project up to date is not on my priorities right now. But if you feel you can fix it, feel free to send a patch!

FYI https://github.com/Roger-luo/IonCLI.jl
e.g
ion install julia 1.5
ion install julia 1.4
ion activate 1.5
ion activate 1.4


👨💻 Manage code colors

Code colors natively are red but in dark mode I think is very hard to see for a long time.

I think that we can have better and readable text with this yellow. It is code yellow from slack dark mode.

Hi Charles, I appreciate your effort to create a better experience for all of us. One of our focuses was maintaining most of the intranet's features as we built this dark mode. In so doing we maintained some colors and only changed the shade for some colors when necessary.
We honestly appreciate your effort so badly but realized that the requested changes would require us to change not just the code elements but others as well to ensure there are consistent colors across the intranet. (see the photos below)
We suggest the following changes:

maintain the value for the variable --col-acc-400
introduce only one new variable --col-code-color (just as you did) with this value #e55039.

Proposed changes from you:

Our humble request to you:

I hope to hear from you at your convenience. Thanks, Charles! 🙏🧑💻

Okay I understand your purpose. It is a good point. We can go with. it.

You can make the changes as I suggested, commit those changes update your PR, we'll review them and merge your changes 🙏

Hi,
Changed requested have been done.


Sum All Odd Fibonacci Numbers

Challenge Name
https://www.freecodecamp.com/challenges/sum-all-odd-fibonacci-numbers
Issue Description
Using the parameter "num" being passed into the function in a for loop causes a crash. Even when assigning the passed parameter to a separate variable and using it in the for loop crashed the program. Example, var newNum = num; for(i = 0; i < newNum; i++) -> crash as well as for(i = 0; i < num; i++) -> crash.
Browser Information

Browser Name, Version:  Chrome, latest version
Operating System: Windows 7
Mobile, Desktop, or Tablet:  Desktop

Your Code
function sumFibs(num) {
var fibArr = [];
var newNum = num;
for(i = 0; i < newNum; i++)
{
fibArr.push(1);
}
return fibArr;
}
sumFibs(4);

I tested your code out and I think the issue is that your code is creating a for loop that will run 4,000,000 times when the third test case is called.  If you were to put a conditional in your code before the loop the browser no longer crashes in my tests.  Below is your example function with an added conditional to keep the third test case from running the loop.
function sumFibs(num) {     var fibArr = [];     var newNum = num;     if (num > 1000) {       return;     }     for(i = 0; i < newNum; i++) {       fibArr.push(1);     }     return fibArr;   }   sumFibs(4);
I hope this helps.

Fibonacci Numbers grow very fast.
@JH108  is right. You need to do some semantic checking for that. Check out the following code :
`
function sumFibs(num) {
var fibs = [1,1];
var sum = 0;
var index = 0;
for(index = 2; index < num; ++index)
fibs.push(fibs[index-1]+fibs[index-2]);
for(index = 0; fibs[index] <= num; ++index)
if(fibs[index]%2 !== 0)
sum += fibs[index];
return sum;
}
`

You can add "?run=disabled" at the end of the link.
For Example: https://www.freecodecamp.org/challenges/sum-all-odd-fibonacci-numbers?run=disabled
and then reset your code.
Note: You won't be able to run your code unless your remove disabled portion from the url(preferably done after resetting the code).
@BerkeleyTrue @erictleung I think it's safe to close this issue.

@ananaymital thanks! Closing as not an issue with the site. @thomaswtx please take a look at the ?run=disabled advice above. Happy coding!


Use CSS modules

Not sure why this isn't the default

I think this was a mis-informed decision on my part when initially creating this package. I was under the impression that CSS Modules were a runtime dependency, and thus needed to be included on every project, regardless of whether the project uses CSS Modules. If this is not the case, let's update!

With the new Vite setup it will take care of bundling for us.
The consuming apps will still import the styles like they do now but we'll get scoped styles!


Bug fixes and visual tweaks

Fixed splash only device alignment
Updated firmware download doc link
Replaced android logo for developer section
Resolved issues #224 and #225

Nice


template url support

Hi,
We have a use-case to use CloudFormation templates stored in S3 buckets.  I have added a feature in so that the template passed in the cfn can be a s3 uri instead of a file path.
Cheers

Published to npm as 1.5.0


Cannot specify custom refSpec to fetch

In our use case, we need to clone a repo at a SHA, not the head of a branch.
This seems to be supported as of git 2.5.0+
And is analogous to:
git fetch --depth=1 git@github.com:git/git.git 95ec6b1b3393eb6e26da40c565520a8db9796e9f:refs/remotes/origin/branch

However, within the remote.Fetch() method, you get the advertised references here and compute their intersection here.
Which means for a refspec like<PHONE_NUMBER>34s019827b3d401928:refs/remotes/origin/foo, which happens to not be the head of a branch, there will be no req.Wants specified, and so nothing will be fetched.

I'd be willing to do some legwork here to get this into a PR,  but some pointers would be appreciated.
I got as far as setting the req.Wants to the SHA that I'm looking for ... but I still get a 'its already updated' error.

BTW ... I'm not able to get the 'raw' git fetch ... command doing what I'd expect either. I'm basically just doing git init and git remote add origin https://github.com/git/git.git then the
$git fetch --depth 1 origin 0bfd9d2efe08df63a501038b70f5b58d44a707da:refs/remotes/origin/next
error: no such remote ref 0bfd9d2efe08df63a501038b70f5b58d44a707da```

Maybe github doesn't advertise all SHAs? Maybe I'm just doing something silly? Can someone else get this working w the vanilla git client?


Add JoolBiomes (fixed KerbalStuffBot submission)

Closes #2998

Why are we hardcoding a name and abstract when what's scraped from KS seems fine?

The name coming from KS is the same as the identifier (no space), and the abstract contains an incomplete sentence, and isn't what shows up in the KS description.

The name coming from KS is the same as the identifier (no space)

That's because it's the proper name of the mod:  JoolBiomes. It's the name listed in KerbalStuff, it's the name of the folder, it's the name on the KSP forum thread, and it's the name listed in Squad's "Modding Monday" (thread)[http://forum.kerbalspaceprogram.com/index.php?/topic/131680-modding-monday-joolbiomes/]. Let's not change the name of the mod.

the abstract contains an incomplete sentence

The one written by the author/scraped from KS is Add biomes (with science defs) to Jool.  Includes the Great Green Spot.. Perhaps not the most eloquently written 2 sentences ever but it's a mod abstract, not prose.

isn't what shows up in the KS description

Abstract and description are 2 different things on KS entirely. For example abstract is mandatory, that's why even blank KS pages will have an abstract when scraped by netkan.

Ok, I see your point. Will resist the urge to editorialise in future.

Per forum thread, author will be setting up a github repo.
http://forum.kerbalspaceprogram.com/index.php?/topic/131274-105-joolbiomes-v10-add-biomes-and-great-green-spot-to-jool/

@politas the mod got uploaded so spacedock: http://spacedock.info/mod/26/JoolBiomes
You can use the new $kref for it


Add git amend commit to Command Palette

//fyi @joaomoreno

We always suggest to run Undo Last Commit and then Commit again instead, it's more explicit.

Every user is different you can't make option standard but we must make a lot of options to do thing and let the user choose this is standard of any programming language ... #let_user_choose @joaomoreno

Feel free to write an extension that provides that command.

Do we really need to construct the whole (sometimes complicated) commit and write commit message (sometimes long and elaborate) just to fix a typo?

Atom 1.18 beta just introduced a proper Git panel similar to the one present in VSCode. This panel provides a simple Amend checkbox beside commit button, as shown in the picture below:

IMHO, it's a really simple thing (from the UI point of view, at least) to be included in VSCode Git panel, and a more simple solution than "undo last commit & re-commit" flow.


Avoid multiline comment.

Brief summary of changes
GCC doesn't like multi-line comments, so I got rid of using \ in a comment.
I ran into this while building a Docker container for the Moco paper.
CHANGELOG.md (choose one)

[x] no need to update because...minor

This change is

🙏


[create-svelte-ux]  - [postcss] Cannot find module 'culori/require'

When using create-svelte-ux, there appears to be some error with the tailwind config tailwind.cjs / the module culori. This error appears after starting the dev server, without changing the code:
[plugin:vite:css] [postcss] Cannot find module 'culori/require'
Require stack:
- /home/projects/zzmibpamy.github/node_modules/svelte-ux/dist/plugins/tailwind.cjs
/home/projects/zzmibpamy.github/node_modules/svelte-ux/dist/components/Icon.svelte

Honestly no idea what causes this issue.

Try: Stackblitz Codesandbox SvelteLab

I will have a look asap, it seems strange yes 👀.

Hey @mtfwvi , sorry about that.  culori is used in the theme PR and I thought I had properly isolated it using the next tag, but appears to be getting picked up here.  My guess is the latest version in the package.json of the template is grabbing the next version.

Actually I see now... it appears when I published the last few next versions manually (npm publish) I accidently pushed them to latest and not next.

As a workaround, you should be able to manually change your svelte-ux version to ^0.57.1 in your package.json.  I'll work on fixing the published latest today as well.  Sorry about that.

OK, latest should be fixed.


hmr: vue sfc update not using pug extractor

EDIT: See latest comment with tracing in second comment.
I can put together a minimal repro later unless this is expected?
(Refresh fixes the issue -- my stack is loosely based off vite/packages/playground/ssr-vue)

Okay after doing some traces it looks like the pug extractor is not actually running when the SFC is changed so it doesn't find the proper token.
// vite.config.js
...
    Unocss({
      presets: [
        UnoPresetIcons(),
      ],
      extractors: [
        extractorPug(),
        extractorSplit,
      ],
    }),
...

On .vue file update, generate does not see pug extracted tokens (just split)

So I'm not familiar enough with @vitejs/plugin-vue but it looks like (pug) extract should also handle .vue?vue&type=template&lang.js somehow -- but it doesn't know that the template has lang pug at that point.

I don't have a repo to play with, tried to fix it on 3d308a8717850f33957225850877cdac24eeb370, can you verify if it works for you? Thanks

It just emits the raw pug (template section of the sfc) so i'm not sure this will work because regexVueTemplate looks for <template lang="pug"> but let me try...

Also there might be something wrong with the npm publishing? built @unocss/extractor-pug @ 0.6.2 doesn't have the changes?

test % npm init -y
Wrote to /private/tmp/test/package.json:

{
  "name": "test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

tj@tjk-mbp test %
tj@tjk-mbp test % ls
package.json
tj@tjk-mbp test % npm install --save<EMAIL_ADDRESS>npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.

+<EMAIL_ADDRESS>added 1 package from 1 contributor and audited 1 package in 0.873s

1 package is looking for funding
  run `npm fund` for details

found 0 vulnerabilities

tj@tjk-mbp test % ls
node_modules      package-lock.json package.json
tj@tjk-mbp test % cat package.json
{
  "name": "test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@unocss/extractor-pug": "^0.6.2"
  }
}
tj@tjk-mbp test % cat<EMAIL_ADDRESS>"use strict";Object.defineProperty(exports, "__esModule", {value: true});// src/index.ts
var regexVueTemplate = /<template.*?lang=['"]pug['"][^>]*?>\n([\s\S]*?\n)<\/template>/gm;
function extractorPug() {
  async function compile(code, id) {
    const Pug = await Promise.resolve().then(() => require("pug"));
    try {
      return Pug.compile(code, { filename: id })();
    } catch (e) {
    }
  }
  return {
    name: "pug",
    order: -1,
    async extract(ctx) {
      var _a, _b, _c;
      if ((_b = ctx.id) == null ? void 0 : _b.match(/\.vue$/)) {

Oh you have a syntax error I believe in that patch!

Pug support is very needed. I'm not skilled enough to contribute code, but I hope @tjk can figure it out soon. Thank you for the struggle!

Amazing!! I was starting on this patch... but taking it real slow. Thank you @antfu

@antfu Thank you for supporting pug! There seems to be one last issue: I'm using unocss just for css icons and they display fine at the DEV stage, but are absent in the BUILD bundle... I think it's related to pug too.
Here's my repo with the problem https://github.com/DeFUCC/project-app


Repo size is 172MB

Rundeck repo is 172MB with ~9500 commits. I'm guessing it's the history from prior to the split from the monolithic cookbook repo and/or the binary files.
$ curl --silent https://api.github.com/repos/sous-chefs/rundeck |  jq '.size / 1024'
172.017578125
$ curl --silent https://api.github.com/repos/sous-chefs/apache2 |  jq '.size / 1024'
1.6142578125

Related: #38, #37
@damacus

we can run BFG again and pull out the winrm jar that is included in the files section.

Binaries removed and cookbook_file calls replaced with remote_file.  Repo size is down to 25M.


Adds verify boilerplate

Signed-off-by: JoshVanL<EMAIL_ADDRESS>/assign
/hold
Adds boilerplate header verification.

Seems like a few files now have duplicate copyright headers... 😬

/close


fix: ran swiflint --fix to fix some warnings

NOTE: Review this PR ONLY when #632 is merged!
This PR is the result of running swiftlint Tests/ --fix && swiftlint Sources/ --fix.

There's ENS failing on remote test somewhat. I'll rerun them and try to check the reason of that to marge it and prepare fix if any


Release v0.2.0

Release
Release v0.2.0
Checklist

[x] Update metadata & clusterctl-settings
[x] Update docs, (compatibility table, usage etc) .
[x] create Tag.
[x] update the created draft release to include (BREAKING Changes, Important Notes).
[x] Publish the release.
[ ] OPTIONAL: create release branch.

https://github.com/ionos-cloud/cluster-api-provider-proxmox/releases/tag/v0.2.0


Speedup Upgrade logic

Codecov Report

Merging #477 (e11f3e5) into main (de82d34) will decrease coverage by 0.00%.
The diff coverage is 84.61%.

:exclamation: Current head e11f3e5 differs from pull request most recent head e801d01. Consider uploading reports for the commit e801d01 to get more accurate results

@@            Coverage Diff             @@
##             main     #477      +/-   ##
==========================================
- Coverage   20.05%   20.04%   -0.01%
==========================================
  Files         163      163
  Lines       23319    23329      +10
==========================================
+ Hits         4676     4677       +1
- Misses      17884    17894      +10
+ Partials      759      758       -1

Impacted Files
Coverage Δ

x/lockup/keeper/legacy.go
58.33% <84.61%> (-4.94%)
:arrow_down:

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 de82d34...e801d01. Read the comment docs.


[KARAF-6580] Provide Spring Security 5.3.x feature

A fix is required on spring-security-config 5.2.x bundle. See SM-4285 for detail. I will tackle this.

Another fix is required: see SM-4349

retest this please

retest this please


Where do the Lua Scripts be put in?

Are you trying to code on Source Code (Haxe) or on the Downloaded Build (Lua)?
Source Code
Show an screenshot/video of your problem.
I want to use the Example Lua Scripts in the wiki, Where do they be put in when I use them?

The song chart folder

In the song chart folder

@Collabvmisgood Any other things need to be done? I put it in that folder, but it doesn't work.

@zwl1619 I hope that you know it but you need to name it: "script.lua"


Add SegRwLock : a segment RwLock Type

Add a new RwLock type as SegRwLock which separate the cache line for Read state and Write state in RwLock to solve the cache-line false sharing problem in RwLock in multi threads scenarios.
Since the 'Data' protected by RwLock shares the same cache-line with lock state. When lock state changes the whole cache-line need update which is not necessary for 'Data' in Read lock, and cause unnecessary cache-line update. SegRwLock put Read state in one cache-line and Write state and 'Data' in the other cache-line, to avoid the false sharing between Read state and 'Data'.

It's not clear to me what use case this is trying to solve. The most common use case for RwLock is to have many readers but few writers. Your implementation does not help with this case since all the readers are still thrashing read_state.
Have you considered a different implementation using a sharded RwLock? The basic idea is to have an array of [CachePadded<RawRwLock>; N] and assign readers to one of the locks depending on its thread ID. This is optimized for read performance: writers will need to acquire a write lock on all the locks in the array before being able to grant write access.

Original RwLock memory layout likes this:
pub struct RwLock<R, T: ?Sized> {
    raw: RawRwLock,
    data: UnsafeCell<T>,
}

raw and data share the same cache-line. In multi read locks, raw change will cause false sharing with data since the data doesn't change in read, only the read state changes. SegRwLock separate read cache-line and write + data cache-line, which memory layout looks like:
pub struct SegRwLock<R, T: ?Sized> {
    read: ReadLock,
    padded: <CachePadded>
    write: WriteLock,
    data: UnsafeCell<T>,
}

One matter need to care is that repr(align(n)) doesn't work inside the struct.


chore(version): bump to 2.3.0

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Steven Le Roux seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


[Snyk] Upgrade html-snapshots from 4.4.1 to 4.5.0

Snyk has created this PR to upgrade html-snapshots from 4.4.1 to 4.5.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.

The recommended version was released on 5 days ago.

Release notes

Package name: html-snapshots

4.5.0 -<EMAIL_ADDRESS>

4.4.1 -<EMAIL_ADDRESS>

    from html-snapshots GitHub release notes

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

coverage: 99.245%. remained the same
when pulling 6db93dddbf9423210b036cd1acba7b37d64badce on snyk-upgrade-9f23f3613ac1f41540694b7c3581a312
into 00488f1e01eee9d4e4feea45bfab50c9f805aa63 on master.


use int array to avoid cast

Types of change(s)

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Trivial change (affects only documentation or cleanup)

Checklist

[ ] Tested this change with a run of GEOSgcm
[ ] Ran the Unit Tests (make tests)

Description
Just  a temporary  branch for comparison
Related Issue

@tclune This is my attempt to work around intel bug. It avoids the cast from calss(*) to integer. But somehow it still fails at the same point as before

it is merged to #2732


helm install/upgrade sometimes return timeout when secret not found

Output of helm version:
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:23:26Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.13-eks-2ba888", GitCommit:"2ba888155c7f8093a1bc06e3336333fbdb27b3da", GitTreeState:"clean", BuildDate:"2020-07-17T18:48:53Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
EKS
there is a inconsistency behavior when install a chart or upgrade a release if a secret is missing: sometime helm report the error like secret 'xx' is not found, while sometime, it just wait for a long time and then report timed out waiting for the condition. if i execute kubectl get event, i'll see a secret not found error.
My question is like why do i get timeout when the error is already happened? shouldn't it just return the error and stop waiting? is there any way to force helm exit and print the error?
Any help will be appreciated!

@isaactl This sounds like a sporadic network issue with your cluster. Helm talks directly to the Kubernetes API service like kubectl. There is no other magic in between.
Not sure why this would be happening like this especially if you are running helm and kubectl from the same system. Have you ever had any issue with the kubectl command?

@hickeyma thanks for the info!
no, i didn't had any issue before with kubectl. but as you said, it could be a random issue. i'll dig more on possible network issue

after few times of testing, it looks like the issue is related to the flag --atomic.
if i remove this flag, helm will install and exit without error in few seconds. same behavior as kubectl
while adding this flag, i'll get lots of logs from wait.go until timeout
client.go:108: [debug] creating 2 resource(s)
wait.go:53: [debug] beginning wait for 2 resources with timeout of 1m0s
wait.go:225: [debug] Deployment is not ready: default/xxxx. 0 out of 1 expected pods are ready
wait.go:225: [debug] Deployment is not ready: default/xxxx. 0 out of 1 expected pods are ready
wait.go:225: [debug] Deployment is not ready: default/xxxx. 0 out of 1 expected pods are ready
....

still it looks to me, helm is not aware of the secret not found error in this run, but keep waiting for pod status to be ready. but in some run, it gives the secret not found error immediately.

@isaactl Thanks for investigating this further and proving more info. I wonder is this related to #8675?

in my case, i don't have issue to do the rollback.

@isaactl were you able to determine the cause of this issue?


Feature request: split up glfm_platform_ios.c

This file contains GLFMAppDelegate and GLFMViewController, amongst other things.
Having this all in one files makes it harder to navigate to one of these things (e.g. "quick open" then typing GLFMAppDelegate doesn't work).
It also makes tracking source control changes to one of these classes more tricky (e.g. I can't easily just see changes to GLFMViewController).

The file will get split up at some point (trying to be more like GLFW) but not anytime soon. It's not too complicated of a file at the moment (less than 900 lines). I'll leave the issue open, but it's not a high priority.
Which IDE are you using? Quick open works in Xcode. Does your IDE pick up the #pragma mark lines?

I'm mainly using AppCode, where the quick open shortcut doesn't pick up on a class inside a file with a non-matching name.

I'm also interested in getting this to work with React Native. So, use RN for the general UI but GLFM for OpenGL visualisations. In this case I wouldn't want GLFM to create and manage AppDelegate but would instead want to use GLFMViewController. It feels like splitting out the functionality into different files would be a step towards allowing this perhaps?

@WebSeed - That's doable, I created issue #11 for that.
I believe this is currently possible in the Android version (starting a GLFM-based Activity from another Activity) but have not tested.


[BUG] selectSheetsByIndex(1)->load($file)->store() always saves first sheet

Package version, Laravel version
Package version: 2.1.8
Laravel version: 5.3.28
Expected behaviour
Should save the second sheet.
Actual behaviour
Always saves the first first sheet, not the second.
Exception stack trace
N/A
Steps to reproduce the behaviour
Excel::selectSheetsByIndex(1)->load($file)->store('csv', storage_path('excel/exports'));
~Will save first sheet, not the second.
If I use
Excel::selectSheets('The Sheets Name')->load($file)->store('csv', storage_path('excel/exports'));
It works as expected.

First sheet has index 0 I think (like php array's)

Did. . . did you even read it? lol.

Sorry misread (you have to forgive me I have to read through 100's of issues :) ).
selectSheets is a PHPExcel method and indeed works for writing.
selectSheetsByIndex is not (it's a custom) and originally only meant for reading the file. The writing is therefor not influenced by that.
Can you try selectSheets(1) ? Not sure if PHPExcel supports it, but you might be able to pass the sheet index in that method actually.


refactor: saml artifact cleanup

:white_check_mark: Build TheIdServer 7.2.3-feat-saml2p1-0053 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/257efa60af by @)

:x: Build TheIdServer 7.2.3-feat-saml2p1-0055 failed (commit https://github.com/Aguafrommars/TheIdServer/commit/7545a990df by @)

:white_check_mark: Build TheIdServer 7.2.3-feat-saml2p.1+55.build.3086 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/7545a990df by @)


Polyline onPress event support

I am trying to implement google maps directions using polylines. For multiple routes it would be better if  onPress event on a polyline can be detected
<MapView.Polyline
              key={index}
              coordinates={coordinates}
              strokeWidth={5}
              strokeColor={index == this.state.selectedRoute ? "#00f0f0" :"#808080"}
              onPress={() => this.setState({selectedRoute: index})}
            />

Required Behavior: state value changes to selected polyline route index
Observed Behavior: No state change observed/ No event detected

OnPolylineClickListener is not implemented yet  in this library  you can customize it  & add OnPolylineClickListener  if your google-play-service is 8.4.+

I have the same issues.
I don't know how to implement it on google map in iOS

@toanhosss @arvindkkore  onPress event still not supported ?

I am trying to implement google maps directions using polylines. For multiple routes it would be better if onPress event on a polyline can be detected
<MapView.Polyline
              key={index}
              coordinates={coordinates}
              strokeWidth={5}
              strokeColor={index == this.state.selectedRoute ? "#00f0f0" :"#808080"}
              onPress={() => this.setState({selectedRoute: index})}
            />

Required Behavior: state value changes to selected polyline route index
Observed Behavior: No state change observed/ No event detected

You need to set tappable prop to true

@TechSaq thank you so much!! :)


[cmake] Add option for up-core-api root directory

When building up-cpp, the up-core-api should be installed too, but as same root level.
This PR gives the option to use up-core-api from another path. It's useful in case up-core-api is install via a package manager and is not copied to the same place.
Plus, when up-core-api is not found, the project should stop. So, the CMake FATAL_ERROR stops the execution as an error message.

Thank you @uilianries !


CBOR: Basic Support for Tags

Introduces basic support for CBOR tags.
Basic means that no semantic checks are performed yet, so you freely use reserved tags (e.g. serialize a cornucopia of fruit and other produce using tags reserved for dates, URIs, MIME messages, negative bignums and so forth) and no error will be thrown.

New annotations ValueTags and KeyTags to specify tags for keys and values, respectively

Tags can be nested freely as specified in the annotations
By default, tags will be validated upon deserialization. If no annotations are present on a property, validation is omitted. Behaviour can be customized (see below).
By default, tags will be written as annotated.  Behaviour can be customized (see below).

Introduces the following configuration parameters  to the Cbor class (names are self-explanatory):

writeKeyTags
writeValueTags
verifyKeyTags
verifyValueTags

This is the first PR in a series of planned enhancements, but we still consider it valuable on its own (as it also affects #1560).
In the long run, we plan to support semantically correct serialization for all reserved CBOR tags. This includes separate contributions to koltinx.datetime and the native support for self-describing CBOR. The latter of which is planned to enable the deserialization of CBOR structures, while also enabling access to the original underlying raw byte-string. This is a crucial features for conveniently working with (i.e. verifying) signed data. (Which, in turn, is a requirement for a 100% pure Kotlin multiplatform COSE implementation.) Hence, we want to use this opportunity to also collect early feedback from those who are more familiar with kotlinx.serialization than we are.

submitting to upstream


Will this nhost SDK work seamlessly with Hasura Backend Plus?

Is this for both nhost and hasura backend plus?
I'm unable to get the storage_example to work with hasura backend plus and I don't see any docs or explanation of how things work.  any help appreciate

Closed to quickly.
Would you mind describing the problems you're seeing?


Update compilerplugin, scalapb-runtime, ... to 0.11.7

Updates

com.thesamet.scalapb:compilerplugin
com.thesamet.scalapb:scalapb-runtime
com.thesamet.scalapb:scalapb-runtime-grpc

from 0.11.3 to 0.11.7.
GitHub Release Notes - Changelog - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.thesamet.scalapb" } ]

labels: library-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #87.


TIME_FLOOR documentation is incomplete

TIME_FLOOR documentation is incomplete
Affected Version
Version: 0.21.
Description
Consider the "stock" Wikipedia data source and stock Docker Druid cluster. The TIME_FLOOR function (and documentation) exhibit a number of problems.
My goal is to round the __time column to one hour, eventually to n hours (or minutes, etc.)
Periods in Documentation Should Be Quoted
The documentation describes the period argument as:

Period can be any ISO8601 period, like P3M (quarters) or PT12H (half-days).

Note that the period examples are unquoted. By contrast, DATE_TRUNC says:

Unit can be 'milliseconds', 'second', 'minute', 'hour', 'day', 'week', 'month', 'quarter', 'year', 'decade', 'century', or 'millennium'.

That is, the examples are quoted. Proposed change:

Period can be any ISO8601 period, like P3M (quarters) or PT12H (half-days).

Role of Origin is Unclear
The documentation states the function signature is:

TIME_FLOOR(<timestamp_expr>, <period>, [<origin>, [<timezone>]])

Experimentation show that the <origin> must be a timestamp, yet the documentation does not give the type. In fact, this is a general flaw not just in Druid, but many SQL references: the argument is given as a type or an explanation, when the user really needs both:
TIME_FLOOR(<time: timestamp>, <period: varchar>, <origin: timestamp>, <timezone: string>)
That said, the documentation provides no explanation of the meaning or purpose of the origin. If we're supposed to know (because, say, this is a standard Postgres function), then perhaps provide a link to the "official" description. Else, please describe the origin argument.
Role of Time Zone is Unclear
The documentation states:

Rounds down a timestamp, returning it as a new timestamp. ... The time zone, if provided, should be a time zone name like "America/Los_Angeles" or offset like "-08:00". This function is similar to CEIL but is more flexible.

There is no description of what role the timezone plays. Here is one interpretation:

The input and output values are UTC-based time zones. The timestamp is converted to the given timezone when computing periods of a day or greater: the local timezone determines when midnight occurs.

There is also the origin, so the above may be wrong.
It might be worth adding an example, since time conversions are quite confusing.
Suppose I have a PST time of 2012-08-12T17:00:00 -08:00. Convert this to UTC and get 2012-08-12T01:00:00Z in the data. Give TIME_FLOOR a time zone of -08:00 and we get our PST time back. We use P1D to truncate this to 2012-08-12T17:00:00 -08:00. Now, convert it back to UTC and we get 2012-08-11T16:00:00Z.
Thus, though we've rounded to one day in the local time zone, the hours will be non-zero for the UTC time zone (unless the local time zone is UTC.)

I assume you wanted PT1H instead of P1H. The query should work with PT1H. But, we should improve our error handling to show something meaningful instead of unknown exception.

@jihoonson, thanks for pointing out my error. I've updated the description to be just a documentation request.
Error handling in Java is a struggle for all projects. But, yes, a good "invalid period string" error would probably have set me straight.

I was just looking for information about this undocumented origin parameter.  I know it's a ticket to update documentation, but what does this origin parameter mean or do?

I came across this page also looking for the documentation for origin and timezone in the TIME_FLOOR.
The druid native query documentation covers some similar terminology in the Query Granularities section:

Time zone is optional (defaults to UTC). Origin is optional (defaults to 1970-01-01T00:00:00 in the given time zone).

I suspect (haven't confirmed) these definitions could be true for the TIME_FLOOR params.


[Feature Request] Reverse Normalize

Useful when visualizing the exact input to the network (for example after random crop).
Just a reverse of normalize, I can raise a PR if you want to incorporate this.

I am sorry, but I didn't quite understand why is there a requirement of this feature? Could you please elaborate?

I'm not sure useful this would be in general, it seems like it would be used only for debug purposes. I'd lean against adding it, if this is the only use case - especially as its quite easy for users to implement when and if they need it.

Sure, Thanks!