Add rpmlint check before building SRPM

Because that way we and user can have some error information before actual build - e.g. here would make sense: in copr it fails with   | warning: Macro expanded in comment on line 21: %{version}.tar.gz this error would be seen before triggered copr build.
We could also add the possibility to disable it in copr job metadata.

I tried to run rpmlint on various spec files I have locally (try https://github.com/ycollet/fedora-spec) and see some Errors:

E: hardcoded-library-path in %{_prefix}/lib/...
E: specfile-error error: query of specfile systemd.spec failed, can't parse
E: specfile-error warning: extra tokens at the end of %endif directive in line 55:  %endif # python2 pkg
E: specfile-error
E: specfile-error warning: bogus date in %changelog:
E: specfile-error warning: Macro expanded in comment on line 2: %global debug_package %{nil}

They, from my perspective, have no impact on whether the build will succeed or fail, so we should NOT block the build when seeing them.
So, It might be nice to have rpmlint and others as a separate check.
But I don't agree with having it as a pre-step of building SRPM - if it means that the SRPM build would not start in case the rpmlint spits some error.

We still wanna do this but we just need to scope it properly.


No logs saved when hosted in am iOS Network Extension

Checklist

[x] I have read and understood the CONTRIBUTING guide
[x] I have read the Documentation
[x] I have searched for a similar issue in the project and found none

Describe the bug
I've added CocoaLumberjack (CLJ from now on) to my project using CocoaPods. The project has a Network Extension (appex) in which I'm trying to log. Unfortunately nothing is logged. I've even used the recommended #define LOG_ASYNC_ENABLED NO flag to write the logs synchronously as described in the documentation. Anyone have any idea why it is not logging. I've had no issues with CLJ in the main app. Thank you.
To Reproduce
Steps to reproduce the behavior:

Create an app and add network extension. (https://developer.apple.com/documentation/networkextension?language=objc)
Add CLJ as a pod and install the pod. Initialise a  DDFileLogger as per the documentation.
Log using any of the DDLog commands for example DDLogInfo or DDLogError
If you try to load the files there are none being returned. Note that I have used a DDLogFileManager and initialised it with a custom directory pointing to the app group shared location (this works well when logging from the main app)

Expected behavior
Should show any logged messages in the loaded file.
Environment info

Info
Value

Platform Name
iOS

Platform Version
16.4.1 (a)

CocoaLumberjack Version
3.8.0

Integration Method
cocoapods

Xcode Version
Xcode 14.3

Repro rate
all the time (100%)

Hmm, not sure what's going on here. Logging from extensions usually works. I've used it in various extensions like WidgetKit and Notification Extensions.
Resource usage is always a critical point with them, though. I've no experience with network extensions and their limitations, but I could imagine them being quite restrictive.
Have you tried manually creating files from the extension in the app group storage? Does this work? Are other loggers like OSLogger working? - if that's even possible to debug given that extensions and debugging can be quite a ride.

While it is possible to write to local storage (in the app group folder) in some specific extensions in iOS (widget extension, safari extension etc) this isn't true to all the different kinds of extensions. Some extensions don't allow writing (and allow read only access to local storage) by design.
Two examples for extensions in iOS that allow read only access to local storage:
Networking extension - Content Filter Provider (read only access allowed in the filter data provider, read/write access allowed in the filter control provider).
SMS and MMS Message Filtering - Read only access.

@avivil thanks for the explanation!

Hi @ffried apologies for the late reply. Terribly busy. I've managed to create the files in the app group folder through on the network extension. Unfortunately nothing is being logged anyway. The Network Extension I'm using is the PacketTunnelProvider. OSLogger works without any issues.

@lukaspechar Hmm, interesting. Still could be a restriction of these extensions. E.g. only being allowed to create files, but not constantly update them.
Either way, you can try to debug it by checking the logs for errors logged by DDFileLogger (e.g. https://github.com/CocoaLumberjack/CocoaLumberjack/blob/master/Sources/CocoaLumberjack/DDFileLogger.m#L1356).
Also, you can set breakpoints in these methods. If you reach them, you might be able to find out what happens. If not, it could be an issue with the CocoaLumberjack setup (which I doubt if OSLogger works).

Thanks for your reply. I'll give that a go. A little busy at the moment but as soon as I have some time I'll try debug it and update the ticket with any findings. Thanks all for your suggestions.

Hi @ffried, apologies for the very very late reply. I've finally had a moment to look into this. I've debugged through the file you suggested, everything points to the logs being successfully saved. So I peeked at the actual file naming logic and that's where I noticed a separate file is being created for each bundle! The logs were actually being saved but to a different file. I've since overridden the newLogFileName and isLogFile functions as per the comments in the source and now use a single file for both the targets - i.e. the app and the network extension and save it to the app group folder on the disk.
Thanks for the help. Turns out the problem was PEBKAC

@lukaspechar Ah, that makes sense. Thanks for the feedback here! Recent versions of CocoaLumberjack have file locking, so your setup should work fine.

If I were to keep the logs separate, as they are by default, how can I retrieve the filenames of the network extension from within the app? I guess I'd need to override the sortedLogFilePaths array to return file paths for all the targets, at the moment it returns only the current target files.

I usually just used a subfolder for logs and then iterated the files in there (or compressed the whole subfolder)...


Create example k8 for a target setup

This will need editing before it works but it gives you an idea of what you need

Could we remove the configmap (to simplify it) and add the secret?

@daniel-ac-martin I kinda felt like the config map did simplify it vs using more secrets. It makes it quite transparent what's getting set no?
I could just inline them i guess?

Yeah I was thinking of just inlining. Different places will have different ways of using k8s so I wanted to just present the simplest thing.

And the only secret I was thinking of was the one that you refer to, db-creds.

@daniel-ac-martin cool will update

@daniel-ac-martin updated


Raise an error when CUDA has been initialized before MultiprocessParallelUpdater is initialized

This PR resolves #4709.

@kmaehashi Thanks for the comment, I updated the code.

I fixed the test failure. Could you please take a look? #4726

Hi, FYI, I commented on https://github.com/chainer/chainer/issues/4709

Thanks for looking into this! Unfortunately, we'll need to be able to avoid all such cases where execution hangs, and using the MultiProcessParallelUpdater is just a way to reproduce this. My understanding is you're still working on a more universal solution.
Thanks again!

@kmaehashi Thanks, I merged #4726. Could you take a look into this PR again?
Jenkins, test this please

LGTM!


Add orders queThis PR adds a new Azure Storage queue for processing orders, and updates the website configuration to include the storage account and queue information.ue and associated configuration

No, storage queues must have lowercase names.


Refactor code

This PR refactors the code base so we have a good foundation to address other issues.
The goal is not to affect or change any functionality. Just refactor and rewrite to make succinct where possible.
Fixes #21

Merging after approval from @dgmets


ui/DriveStats: small changes

read 'IsMetric' in one place.
call updateStats on doc changed

Is this ready?

yes.forgot to open it

Thanks, but I don't think the drive stats will be around much longer. We're thinking of putting something else there.


bug: "Resource not found" error when deleting multiple posts with the same TSGhostAdminAPI instance

Provide environment information
  System:
    OS: macOS 14.3.1
    CPU: (10) arm64 Apple M2 Pro
    Memory: 139.72 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.14.0 - /usr/local/bin/node
    npm: 9.3.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 121.0.6167.184
    Edge: 120.0.2210.133
    Safari: 17.3.1
  npmPackages:
    @ts-ghost/admin-api: ^4.0.1 => 4.0.1
    typescript: ^5.3.2 => 5.3.2

Describe the bug
When deleting multiple posts using the same instance of TSGhostAdminAPI, the first one will succeed, but the second and later ones will fail.
The error message:
{
    "type": "NotFoundError",
    "message": "Resource not found",
    "context": null
  }

Target Ghost Blog version
v5.79
To reproduce

Create two posts
Then delete them one after the other, using the same TSGhostAdminAPI instance and its API .posts.delete()
Result: the first request will succeed, while the second one will fail with the error above

Additional information

The error message is a little misleading. The post is actually there. If the post is indeed not there, the error message would be:

{
    "type": "NotFoundError",
    "message": "Resource not found error, cannot delete post.",
    "context": "Post not found."
  }

If the TSGhostAdminAPI instance is created every time before invoking the .posts.delete() API, then the deletions would succeed. So there is a bug somewhere in the client-side SDK, per my understanding.

👨👧👦 Contributing

[ ] 🙋♂ Yes, I'd be down to file a PR fixing this bug!

Thank you so much for reporting this! I fixed it in the linked PR and will publish a new version of the packages in the next 30mintues.


after specified API's serializers using format,the api.type requests are not found

if i specified the API's serializers using format:
format :json

the api will return 404 not found when called using api.type,such as:
/task/testcase.json

I found this issue in version 0.10.1 and it's ok in previous version

By previous version you mean 0.9.0, right?
This was introduced deliberately in https://github.com/intridea/grape/pull/809. We've discussed undoing that, I would still merge a PR.

I also meet this problem after upgrading Grape,  #809  is a break change and big problem for me.
Before upgrading, I specified the API format:
format :json

I can access API by api and api.format_type
e.g.
/account/login

or
/account/login.json

After upgrading,  /account/login.json will return 404 not found. If remove "format :json", only  /account/login.json can be used.
access /account/login directly will return
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<error>
<message>cannot convert String to xml</message>
</error>

But, out client use both /account/login and /account/login.json to access our API before.

You should be able to restore the old behavior by ensuring you have more than one format "supported", so after format :json add another content-type  via content_type :foo, 'foo/bar'. Let us know if that works. I am still looking for a PR for this.

The culprit is here.

This has been reverted via https://github.com/intridea/grape/pull/1001, please test.


[Refator](point query) change LookupConnectionCache policy to number

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


extend .eggignore with a particular syntax

Is your feature request related to a problem? If so, please describe.
While working on a particular project, I almost published my keyfile to nest.land :fearful:
I had forgot to setup my .eggignore like my .gitignore
Describe the solution you'd like
A new, easy to implement syntax for .eggignore
extends .gitignore

./other/files/to/ignore

Describe alternatives you've considered
Copy paste my gitignore to eggignore

It's a very good idea, it avoids making duplicates.
I was wondering about this feature, if neither the files field, nor the ignore field nor the .eggignore file exist, would it be a good idea to take the values of the .gitignore file as a last resort?
This would only be the case if the configuration really doesn't specify any files.
And if .gitignore doesn't exist then eggs issues an error as usual
Translated with www.DeepL.com/Translator (free version)

I think that it would be beneficial to use a .gitignore if nothing else is present, but the user should specifically state that it should be used instead. Perhaps this could be a command line argument?
We want to avoid any opportunities for something to go wrong because of a misunderstanding on how to use the platform. Explicitly stating that a user wants to use a gitignore would be a way to prevent any unintended operations.

Sounds good
Then with the current system and this new syntax, it could look like --ignore="extends .gitignore"

If I'm understanding correctly, you may not even need the extends. Perhaps a user could just pass in the location of the .gitignore?

It's a bit more complicated than that
Let's consider the following .eggignore file:
.vscode/
nestkey.json

It is equivalent to the following command:
eggs publish --ignore .vscode/ nestkey.json

The arguments of --ignore are in fact the lines that an .eggignore file could contain
So let's consider another file:
extends .gitignore
extends ./dir/file

It is equivalent to the following command:
eggs publish --ignore "extends .gitignore" "extends ./dir/file"

I think it's pretty consistent, but you have to tell me if it's not.
I'd prefer to add the keyword extends to the ignore language than to add a parameter to the eggs publish


error: redefinition of ‘uint16_t datasketches::compute_seed_hash(uint64_t)’

When the file contains the following two kinds of sketches, it will report error: redefinition of ‘uint16_t datasketches::compute_seed_hash(uint64_t)’
#include <theta_sketch.hpp>
#include <cpc_sketch.hpp>

Test Case:
https://github.com/chufucun/datasketches-cpp/blob/test/theta/test/multi_sketch_test.cpp
====================[ Build | theta_test | Debug ]==============================
/home/impdev/Impala/toolchain/toolchain-packages-gcc7.5.0/cmake-3.14.3/bin/cmake --build /home/impdev/datasketches-cpp/cmake-build-debug --target theta_test -- -j 9
[ 22%] Built target common_test
Scanning dependencies of target theta_test
[ 33%] Building CXX object theta/test/CMakeFiles/theta_test.dir/multi_sketch_test.cpp.o
In file included from /home/impdev/datasketches-cpp/cpc/include/cpc_compressor_impl.hpp:28:0,
                 from /home/impdev/datasketches-cpp/cpc/include/cpc_compressor.hpp:145,
                 from /home/impdev/datasketches-cpp/cpc/include/cpc_sketch.hpp:30,
                 from /home/impdev/datasketches-cpp/theta/test/multi_sketch_test.cpp:25:
/home/impdev/datasketches-cpp/cpc/include/cpc_util.hpp: In function ‘uint16_t datasketches::compute_seed_hash(uint64_t)’:
/home/impdev/datasketches-cpp/cpc/include/cpc_util.hpp:27:24: error: redefinition of ‘uint16_t datasketches::compute_seed_hash(uint64_t)’
 static inline uint16_t compute_seed_hash(uint64_t seed) {
                        ^~~~~~~~~~~~~~~~~
In file included from /home/impdev/datasketches-cpp/theta/include/theta_sketch.hpp:23:0,
                 from /home/impdev/datasketches-cpp/theta/test/multi_sketch_test.cpp:24:
/home/impdev/datasketches-cpp/theta/include/theta_update_sketch_base.hpp:188:24: note: ‘uint16_t datasketches::compute_seed_hash(uint64_t)’ previously defined here
 static inline uint16_t compute_seed_hash(uint64_t seed) {
                        ^~~~~~~~~~~~~~~~~
gmake[3]: *** [theta/test/CMakeFiles/theta_test.dir/multi_sketch_test.cpp.o] Error 1
gmake[2]: *** [theta/test/CMakeFiles/theta_test.dir/all] Error 2
gmake[1]: *** [theta/test/CMakeFiles/theta_test.dir/rule] Error 2
gmake: *** [theta_test] Error 2

Test Case: https://github.com/chufucun/datasketches-cpp/commit/6effa9b07e88f4cc1a80f9ffaaa16b324b76843b

I have a potential fix, but I need a review before I can merge. I think the most likely reviewer is busy for a few days, so it might be a few days.
It's important to have other projects depend on official releases, but I think we're about ready for another one so good to catch things like this. Thanks!


New feature: Deleting the old .pth files when training

Hi, I found that there was no funtion to delete the existing .pth files, which made the training process require a lot of space. So it would be very helpful if you can add a function to deleting the previous .pth files when training. Thanks!

Hi, I found that there was no funtion to delete the existing .pth files, which made the training process require a lot of space. So it would be very helpful if you can add a function to deleting the previous .pth files when training. Thanks!

Yes, I am planning on making a function that keeps the top k best checkpoints based on Mel loss metric.

Great, thank you!

Solved in #62


Added in segmentation and segmented output for array elements

This essentially solves the "sequence regex" problem.
There is some more to do here - we can add some thresholding for the bounded region matches, but it's a good start.

@kvg I think it's ready for another look.

Great!  Will look now.

Nice, this appears to correct most of the issues.
I think there's still a boundary issue with the first transcript in the array.  From the annmas inspect results, it looks like the first A adapter never shows up (I think Aziz mentioned something about it getting "chewed off" before it makes it onto the sequencer.  Instead, the first transcript starts just with the 10x adapter, so if you use that for your boundary instead, it should get us one more transcript per read.
Observe below, where the first segmented reads in the output are from B to the next 3' adapter, missing the first transcript that's delimited by the 10x adapter and not A.

I looked to see if there was a way to also get the last transcript in the read that's not delimited by a MAS-seq adapter, but there doesn't seem to be an obvious way to do that.
Also, can you double-check the multiprocessing in the annotate step?  This seems to be taking nearly as long in multi-threading mode as it is in single-threading mode.  Here are the times reported:
One thread:
$ python -m annmas annotate -t 1 -o test_output.bam ../tests/test_data/test_input.bam
[INFO 2021-02-02 14:26:48] annmas: annotate started
[INFO 2021-02-02 14:26:48] Running with 1 sub-processor(s)
[INFO 2021-02-02 14:26:50] Using default annotation model
Progress: 100 read [05:31,  3.03s/ read][INFO 2021-02-02 14:32:22] annmas annotate: annotated 100 reads with 7009 total sections.
Progress: 0 read [05:31, ? read/s]
[INFO 2021-02-02 14:32:22] annmas: annotate finished.

11 threads:
$ python -m annmas annotate -o test_output.bam ../tests/test_data/test_input.bam
[INFO 2021-02-02 14:14:33] annmas: annotate started
[INFO 2021-02-02 14:14:33] Running with 11 sub-processor(s)
[INFO 2021-02-02 14:14:36] Using default annotation model
Progress: 100 read [04:48,  3.74s/ read][INFO 2021-02-02 14:19:24] annmas annotate: annotated 100 reads with 7009 total sections.
Progress: 0 read [04:48, ? read/s]
[INFO 2021-02-02 14:19:24] annmas: annotate finished.

Merging as discussed - will create new branch to address speed increases.


Add skeleton for Task class

Codecov Report
Base: 71.27% // Head: 70.21% // Decreases project coverage by -1.05% :warning:

Coverage data is based on head (b60b376) compared to base (52742fc).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #88      +/-   ##
============================================
- Coverage     71.27%   70.21%   -1.06%
  Complexity      402      402
============================================
  Files            72       74       +2
  Lines          1267     1286      +19
  Branches        129      131       +2
============================================
  Hits            903      903
- Misses          332      351      +19
  Partials         32       32

Impacted Files
Coverage Δ

src/main/java/seedu/address/model/task/Name.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/model/task/Task.java
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

No issues


remove wechaty dependency

There is a wechaty dependency in normalize-file-box, which will cause error in local wecaty test. So, remove it.

@huan Waiting for your review to test puppet-official-account with hostie.


Add retries around infrastructure flakes

Fixes https://github.com/istio/istio/issues/29847
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
74e6d26f1dbb621513ef5b6376e0e1d3779f8fa4
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
74e6d26f1dbb621513ef5b6376e0e1d3779f8fa4
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


string.char implementation

I'm not 100% on the error messages, so i modeled them after PUC-Lua's.

This would actually work better as an implementation of utf8.char

right now the implementation charges 1 fuel per argument, but can/should be adjusted?


How to get the logit tensor of generated text?

Hi, thank you so much for providing this excellent library.
I can't seem to figure out how to get the logit value of the token at generation time. Actually, I just want to get the logit value of the first token generated for each request (i.e. max_new_tokens=1), Instead of getting sampled tokens. How do you do that?
For example, for "yes" and "no" tokens, how to retrieve the logit values of these specific tokens in each generated sequence?

Hi @randomx207, this is not something we expose in MII currently. It is on our roadmap to provide additional features like this. I can provide a PR sometime next week to add this!

Thank you for the update and for considering this feature in the roadmap. I appreciate your willingness to provide a PR for it. Looking forward to seeing the enhancements you have in store next week!

any update on this?

I encountered the same problem. Has it been resolved?


Q: 404 pages

How would you do 404 pages with this library?

Check out the Fragment section in the readme--use the forNoMatch prop in your last Fragment


compute-applicable-* should allow for use of the various cost functions

I don't think you're forgetting anything; I think this was an accidental consequence of both the cost-function changes and accomplishing the original by uncoordinatedly tweaking things 'til they worked.

@ecpeterson Should the compute-applicable-* functions be generic? Right now they only consider fidelity, but we also support (elsewhere in the compiler) duration as a cost metric.
Originally posted by @notmgsk in https://github.com/rigetti/quilc/issues/684#issuecomment-738862555

I doubt it should be generic (in the generic-function sense), but maybe it can take some extra arguments controlling how to sort the applicable compilers according to custom or more generic policies.

I doubt it should be generic (in the generic-function sense), but maybe it can take some extra arguments controlling how to sort the applicable compilers according to custom or more generic policies.

See also #653 .

See also #653 .


Follow up to #277: tone down git-credential warning slightly

cc @SBrandeis

Are you sure of the will > might?

Personally I'd even favor removing this warning completely given that when interacting with a repo through Repository (the library's main point of interaction with a repo) from what I understand it's going to set the user's local git config to use it anyways

Yeah but if using git clone manually you'll be asked to authenticate again

I'd be very in favor of keeping it, even if I understand the tone-down

and i know very few people (no-one outside of Google Colab?) who use store as their system wide git credential helper so this error message would be displayed for everyone IMO

Ok then let's keep the message but apply this PR? WDYT? or feel free to close, no big deal =)

I understand where you're coming from and the potential issues this can bring. I'll take a second look at having a cross-credential-helper solution and if I still fail to identify a good solution, then let's revisit the warning problem.


Python development headers

How can I install the development headers for Python for asdf Python installation?

I was able to build my python version including development headers by using an environment variable.
I found it by reading the python-build documentation from pyenv
https://github.com/pyenv/pyenv/tree/master/plugins/python-build#building-with---enable-shared
export PYTHON_CONFIGURE_OPTS="--enable-shared"
asdf install python 3.9.8

Sadly this didn't work for me. I'm also stuck on this.

These headers are already installed, at least for me. I was running into issues installing some packages with pip due to being unable to find Python.h and related header files. asdf/pyenv is not wiring up CFLAGS, I'm not sure if this is expected or not, but I unblocked myself with export CFLAGS="$(python-config --cflags) before the pip install which enabled the builds to succeed.


Required property doesn't seem to work

I'm using the old version of JSON Schema 'required' usage (the boolean value on each individual field) as I remember reading this tool requires (though this may be out of date).  When I set a variable as required, I'll notice in the auto-generated comment in the resulting java file the "(Required)" string, but no enforcement of this requirement seems to be present other than in the comment (and is treated by ObjectMapper in the same fashion as non required fields).

Yes, there's no enforcement of this. These types aren't really designed to enforce the schema constraints, we only read the structural rules in a schema to create a Java type that is able to bind to the data. If you're interested in enforcing these constraints, you may want to look into the JSR-303 support.
There was a feature request raised to enforce this constraint via parameters in the Jackson annotation: #429. This would need to be implemented for both v3 and v4 (old and new) 'required' style.

adding true to the configuration in the plugin worked for me.

...
...
true


Generic closures

This RFC adds the ability to define generic closures:
<T: Debug>|x: T| println!("{:?}", x);

Rendered

Can you make the closure generic over lifetimes as well?
Are there any potential ambiguities with this syntax? Should we have the generics introduced with the for keyword?

Can you make the closure generic over lifetimes as well?

Of course. Note that this is already possible:
|x: &(i32, i32)| -> &i32 { &x.0 }

This closure is generic over all possible lifetimes for the input reference.

Are there any potential ambiguities with this syntax? Should we have the generics introduced with the for keyword?

There should be no ambiguities. It is already possible to invoke a function using the <T>::method() syntax, so a leading < character should not be a problem.

Where do we put the move?
move <T: Debug> |x: T| ...
<T: Debug> move |x: T| ...

I doubt the feasibility here is that generic functions can't be values.
We can't declare a variable with the type Vec<T>, unless we specify a concrete type for the type parameter T.
So, how can we store this <T: Debug>|x: T| println!("{:?}", x); in a variable ? Closure is just a syntax sugar for anonymous types. Can you elaborate the underline implementation without syntax sugar?

@F001 The closure only has a single type, it's just that it implements the Fn traits generically. See the example code linked in the RFC for a working example without syntax sugar.

Would this let you do:
let foo = <T: Debug>|x: T| println!("{:?}", x);
foo(42);
foo("bar");

(I'm guessing no.)

@durka Yes it would.

I see. The generic type parameter can only used in the arguments, not the captured values.

@kennytm The move would go in the front (your first example). I've amended the RFC to specify that. The only thing I'm not sure about is how this interacts with &move, but I don't think there should be a problem.

That's really neat. I'm fully in favor of this. 👍

Functionality-wise I agree that this would be a good thing to have.
The proposed syntax strikes me as arcane and haphazard; although I'm not sure whether it's possible to do any better. Two things in particular bother me about it:

Heretofore generics parameter lists have only ever appeared "attached" to some keyword or identifier (impl<T>, fn foo<T>, struct Foo<T>, for<'a>). I think this is a sensible policy. Here, it would be "suddenly appearing out of nowhere". I really don't like this: I think it's bad for readability. Reading the code left-to-right, you have to read quite a bit ahead and backtrack several times before you can realize "oh, so this thing here is a closure; and all of that syntax back there was a type parameter list for it".
One alternative would be to introduce it with for, as with HRTBs at the type level (as mentioned by @durka): so for<T: Debug> |x: T| println!("{:?}", x). The potential drawback here is that, thus far, although we've already been using for to mean different things, it's meant one thing at the value level inside function bodies (for..in loops), and another thing at the type level outside function bodies (for<'a> HRTBs), reducing the potential for confusion between them. Now you'd have both of them appearing in the same context. Although not all is lost: presumably for..in would only ever appear as a statement, while for<T> |x: T| would only ever appear as a subexpression (e.g. as a HOF argument), so you would still only ever expect to see one of them at any given point.
In any case, I think I do prefer this alternative.

Similarly, up to now where clauses have only ever appeared at the item level, and this would be a completely new use for them. So far they don't even appear in the syntax for types! No to even mention terms. That's something @nikomatsakis has mentioned he's concerned about when discussing the possibility of extending HRTBs to work with type parameters as well (#1481): you'd have F: for<T: Foo> Fn(T) -> T.... and then F: for<T> where T: Foo Fn(T) -> T, or F: for<T> Fn(T) -> T where T: Foo? The two questions seem to be closely related: if the syntax we use here is for<T: Debug> |x: T| ..., then the question of "where does the where clause go" is the same in both cases.

(The syntax for specifying closure types |u: u8| -> u8 { u*8 } is already a strange amalgam of type- and value-level syntax, so these would not be without precedent, but they would exacerbate the issue.)
It's interesting that if we wanted to be able to write a type annotation for a generic closure, we'd need #518 (just like for non-generic closures), and #1481 as well (which was mentioned above). If we did have both of those, another way to write a generic closure would be let f: impl for<T: Debug> Fn(T) = |x| println!("{:?}", x) or (|x| println!("{:?}", x)):  impl for<T: Debug> Fn(T) using type ascription.
Takeaway: this seems closely related #1481 in terms of both syntax and functionality, so maybe there should be some cross-pollination going on between them.

@glaebhoerl does it conflict with potential HKT syntax? (or is this just HKT-for-closures as it is?)

HKT is totally separate from this I think. It's "higher-ranked trait bounds quantified over types and not just lifetimes" (iow, "for<T> not just for<'a>") which is related in different ways to both this and HKT.

Right. So... if we end up using for<T, U> for HKT and then we also use it for these closures, it might be confusing. But I also agree with you that with no keyword it seems to require a lot of lookahead (possibly more than the parser currently supports).

I don't think it would be confusing, because the meaning matches up.  The expression for<T> |t: T| -> T { ... } would satisfy the higher-ranked trait bound for<T> Fn(T) -> T.

if we end up using for<T, U> for HKT and then we also use it for these closures, it might be confusing.

We wouldn't. for<T, U> ... isn't higher-kinded types, it's higher-ranked types (or bounds/constraints in this case). Think of the difference as higher-ranked types being "higher-order generic functions", and higher-kinded types being "higher-order generic types". So higher-ranked types means being able to have (generic) functions which take other generic functions (like these here generic lambdas) as arguments, while higher-kinded types means being able to have generic types which take other generic types as type arguments. The latter would look like Foo<Option> or Bar<Vec>, not for<T>.

Can the text of this RFC please mention some alternative syntaxes that don't have the lookahead problem? I feel the same as @sfackler that the lack of drawbacks/alternatives is not duly diligent.

If we did have both of those, another way to write a generic closure would be let f: impl for<T: Debug> Fn(T) = |x| println!("{:?}", x) or (|x| println!("{:?}", x)): impl for<T: Debug> Fn(T) using type ascription.

It's interesting to note what it could look like with the any/some proposal from https://github.com/rust-lang/rfcs/pull/1522#issuecomment-221760674:
let f: some Fn(any Debug) = |x| println!("{:?}", x);

Or in a call:
foo(|x: any Debug| println!("{:?}", x));

This is potentially a stronger argument for the any/some syntax than anything in that thread, since generic closures with explicit argument lists are quite ugly. @glaebhoerl's description of "arcane and haphazard" seems apt, and I agree that it's hard to do better than @Amanieu's syntax - unless you anonymize the type parameters with any.

Noooooo don't pull this RFC thread into that neverending one.
But anyway, that syntax doesn't seem fully general since you can't refer to
the generic type, i.e. you can't call .collect::<Vec<T>>(). So there
would still have to be a way to expand it to something like that proposed
here, which seems fine to me if a keyword is added in front.
On Tue, Jun 21, 2016 at 9:54 PM, Scott Olson<EMAIL_ADDRESS>wrote:

If we did have both of those, another way to write a generic closure would
be let f: impl for Fn(T) = |x| println!("{:?}", x) or (|x| println!("{:?}",
x)): impl for Fn(T) using type ascription.
It's interesting to note what it could look like with the any/some
proposal from #1522 (comment)
https://github.com/rust-lang/rfcs/pull/1522#issuecomment-221760674:
let f: some Fn(any Debug) = |x| println!("{:?}", x);
Or in a call:
foo(|x: any Debug| println!("{:?}", x));
This is potentially a stronger argument for the any/some syntax than
anything in that thread, since generic closures with explicit argument
lists are quite ugly. @glaebhoerl https://github.com/glaebhoerl's
description of "arcane and haphazard" seems apt, and I agree that it's hard
to do better than @Amanieu https://github.com/Amanieu's syntax - unless
you anonymize the type parameters with any.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1650#issuecomment-227622445, or mute
the thread
https://github.com/notifications/unsubscribe/AAC3n-Dvc5lP_ugmtzdXV4n2sHUK5fkIks5qOJXggaJpZM4I2Wcq
.

@durka Sorry. :stuck_out_tongue: any/some needs its own discussion area - but I thought it was interesting that it could help solve an ergonomics problem in a separate area.
any/some isn't fully general in any of the places its been proposed to be used, so I'm not suggesting it as an alternative, just a more ergonomic shorthand that hopefully applies in the majority of cases. (The minimalistic form impl Trait is not fully general either, and requires an explicit form.)

for<..> |..| syntax may conflict with #1657 as we'd be representing Λ and ∀ the same way.

+1 for this RFC. I'm in a situation today where I have a closure which is generic over a lifetime and I need to refer to that lifetime explicitly, but there's no syntax to do that.
In other words I have this: |foo: &Foo| { ... }
But I need: for<'a> |foo: &'a Foo| { /* So that I can write 'a here */ }
Just adding this would be a good first step and would be simpler than adding closures which are generic over types aswell.

@canndrew In fact, we support that today, if the closure is an argument to a generic function which has a Fn{,Mut,Once} bound on the type of the closure.
In fact, I tell people to never put closures anywhere other than function arguments, if they can, for this reason.

@eddyb Doesn't help in my situation unfortunately. Although it looks like my problem is actually a bug.

@Amanieu It should be explicit that the generic parameters have to be used in the argument types, i.e. the rule that prevents impl<T> Fn() for X from compiling: the type parameters must be deducible from Self and trait parameters.
This also mean for<T: Default> || T::default() doesn't work even if fn foo<T: Default>() -> T { T::default() } does (or even fn bar<T: Default + Debug>() { println!("{:?}", T::default() }).
However, there's an interesting point to made here: bar cannot be called without explicitly providing a type argument. You can say foo() desugars to foo::<_>() where typeof foo::<T>: Fn() -> T.
Where you actually end up is the distinction between early-bound and late-bound parameters which @nikomatsakis has discussed mostly for lifetimes.
With HRTB, it's obvious: late-bound lifetimes allow you to use for<'a> over them, but early-bound have to be inferred when the function is originally referenced.
For closures, allowing parameters that you have to explicitly supply seems pointless, at least until we have HKT, which would let you abstract over such closure types to some extent.
OTOH, being able to use generic functions like generic closures, at least over their late-bound type parameters (if they weren't inferred to anything specific), can be an useful extension to this RFC.
It also doesn't require syntax additions, i.e. Clone::clone can be for<T: Clone> |x: &T| x.clone().

If the for<..> probably I speculate on exists. |<..> ..| .. syntax should work, but is pretty ugly.

WIth this proposal, would this be possible?

@reddraggone9 AFAICT, yes it would.

ping @Amanieu @pnkfelix
status?

I've been thinking about this RFC. Here are a few thoughts:

It feels wrong to implement this without HRTB of type parameters. <T>|x| x is a type which implements for<T> Fn(T) -> T. Essentially I don't like that the genericity of these closures can't be preserved across function boundaries.
The fact that this parametricity can't be inferred (because how we would know what the bound is?) is a downside to this RFC to me. Currently, closures are almost never type ascribed; this would be a stark contrast to that.

Despite the second point, I think overall we should do this, once/if we have HRTB of type arguments. It seems like a logical extension with that feature in place.

Despite the second point, I think overall we should do this, once/if we have HRTB of type arguments. It seems like a logical extension with that feature in place.

We could start by just doing it for lifetimes.

@canndrew we do allow the construction of such closures, but we don't have syntax for ascribing the lifetime parameter.
https://is.gd/B8EXO9
    let closure = |x: &u32| *x;
    {
        let x = 0;
        closure(&x);
    }
    {
        let y = 0;
        closure(&y);
    }

but we don't have syntax for ascribing the lifetime parameter.

That's what I mean though. I've needed that syntax before.

I suggest we postpone this RFC until we're a good bit further along with the impending trait system revamp, which I think should make this kind of thing much easier to implement and reason about.
@rfcbot fcp postpone

The FCP has elapsed without any further comments. I'm going to go ahead and close as postponed, to be revisited when the new trait system implementation is in place. Thanks @Amanieu for the RFC!

Just ran into a situation that'd benefit form these.

This should probably be labelled as "Postponed" for reference.

Oh, the suggestion in https://github.com/rust-lang/rfcs/pull/1650#issuecomment-227622445 is actually now viable since universal_impl_trait has been implemented (can't compile yet)
#![feature(universal_impl_trait)]

use std::fmt::Debug;

// fn f(x: impl Debug) {
//     println!("{:?}", x);
// }

fn main() {
    let f = |x: impl Debug| println!("{:?}", x);                                                     //"
    // (currently an error)
    //~^^ ERROR [E0562]: `impl Trait` not allowed outside of function and inherent method return types
    f(1);
    f(true);
    f((4, 5, 6));
}


JSON parse failure in defaultHttpResponseTransform

function defaultHttpResponseTransform(data, headers) {
  if (isString(data)) {
    // Strip json vulnerability protection prefix and trim whitespace
    var tempData = data.replace(JSON_PROTECTION_PREFIX, '').trim();

    if (tempData) {
      var contentType = headers('Content-Type');
      **if ((contentType && (contentType.indexOf(APPLICATION_JSON) === 0)) || isJsonLike(tempData))** {
        data = fromJson(tempData);
      }
    }
  }

  return data;
}

In defaultHttpResponseTransform() above, the response data is parsed as json, if either content type is application/json or is JSON like. In this case the data is unable to parsed as JSON in fromJson(), the exception is thrown at JSON.parse, which causes request to be rejected with empty object.
This makes it hard to debug response issues in production especially if response is dynamically generated, as no response data can be captured in this case.
My suggestion would be to reject with original response data in such cases and let client handle the failure.

I assume that by "debug [...] in production" you mean logging client errors  to the server and analysing them to find issues. For that usecase, this makes sense.
Of cource, you can create your own transform that captures that, but if someone wants to create a PR, I we can consider making this change in core.

That's interesting, because prior to 1.6.0, a parse error wouldn't even be forwarded to the rejection handler / application code. Are people now finding new bugs in their apps because we let $q reject errors?

I think it would (but in a slightly different way).
Before 1.6:

Error
Promise rejection + $exceptionHandler

After 1.6:

Error
Promise rejection
If rejection not handled: $exceptionHandler

I assume that by "debug [...] in production" you mean logging client errors to the server and analysing them to find issues. For that usecase, this makes sense.
Yes @gkalpak

I'm interested in creating a PR. Is there any suggested approach you want me to follow to fix this?

Can we catch the exception in defaultHttpResponseTransform and reject with original data in cases where JSON data cannot be parsed?

Off the top of my head, a reasonable approach would be to wrap the relevant code in a try-catch block, catch the error and throw a more informative error (containing the original).
This should be a minErr error though, so it needs an error page etc. Take a look here for an example of how this may look like.

@chirag64: Thx for stepping up btw 👍

@gkalpak Thanks for the help, I've made some changes on my forked repository - 529cf2f854998e502bc66c655af0868e3b57eace. I'm not sure how I can test my changes or how I can call this function in a unit test (if a unit test is needed). Would appreciate your help on this. Thanks.

@chirag64 Yes, we definitely need a test for this. The tests are in httpSpec.js, this should be in the describe block for json parsing. Once you have cloned the repo you can run grunt autotest to start the karma server, which will then run all the tests. You can isolate a single test by changing the it to fit.
HOWEVER. I am actually not sold on throwing a hard error here. Shouldn't we reject the promise with the original data instead?

@Narretz So inside the httpSpec.js file, I created a new describe block for json parsing, and inside an it function, I'm trying to run defaultHttpResponseTransform but the tests keep erroring out saying defaultHttpResponseTransform is not defined  no-undef. I checked the httpSpec file to see how we're getting the other functions to work but couldn't find a pattern. Any hints on this?

@chirag64 in your forked repository 529cf2f, can you throw tempdata instead of data

@chirag64
There's actually a section about the json already in the httpSpec.js: https://github.com/angular/angular.js/blob/71f437c15a606b542536e70c392808e84d982078/test/ng/httpSpec.js#L1186
There's a test about JSON deserialize errors: https://github.com/angular/angular.js/blob/71f437c15a606b542536e70c392808e84d982078/test/ng/httpSpec.js#L1372
Instead of a SyntaxError, we have to match for a minErr now: https://github.com/angular/angular.js/blob/71f437c15a606b542536e70c392808e84d982078/test/helpers/matchers.js#L308
It's also better to open a PR, so we can see the difference right away.
@anupbelambe I don't really understand what you mean.

A problem I see is that with this behavior, you won't have access to the raw response string. Can we achieve this together with a minErr? Wdyt @gkalpak?

Sounds reasonable. We could embed the response (as string) into the minErr (and hope it is not huge 😛).

Still unsure how to call defaultHttpResponseTransform in httpSpec.js for unit testing. Would appreciate some help with that and comments on the checked in code and documentation.

Thanks @gkalpak and @chirag64.
I see this has been added to backlog milestone but in which Angular release would this fix be available.

v1.6.4


worekd instead worked

I noticed this little issue in my console:
Today you worekd:

Thanks for reporting @Futosone  I ran a gnu aspell on all the files and found 5-6 more typos :)

@omidfi you're welcome, thanks for your tool :)  oh and btw the german magazine t3n wrotes an article about your tool. Good Work!
http://t3n.de/news/kommandozeile-terminal-time-tracking-zeiterfassung-803805/

Oh thanks @Futosone for the article link. I was wondering why it got 20 stars on github all of a sudden :D


Fix for pallet_assets::create benchmark

Benchmark for create should use origin returned by T::CreateOrigin::try_successful_origin instead of SystemOrigin::Signed(caller).
E.g.  ForeignCreators does not work with that, because it expects PalletXcm::Origin which is correctly returned from T::CreateOrigin but then caller is wrapped with SystemOrigin::signed(caller) which does not pass EnsureXcm validation here
Fixes: https://github.com/paritytech/cumulus/issues/2727

bot bench $ pallet dev pallet-assets

bot merge


Race condition in -[AFImageDownloader downloadImageForURLRequest:withReceiptID:success:failure:]

v3.1
==================
WARNING: ThreadSanitizer: race on a library object (pid=20259)
  Read-only access of object NSMutableDictionary at 0x7b0c0010d0d0 by thread T19:
    #0 -[__NSDictionaryM objectForKeyedSubscript:]
  * #1 __78-[AFImageDownloader downloadImageForURLRequest:withReceiptID:success:failure:]_block_invoke_2.190

  Previous mutating access of object NSMutableDictionary at 0x7b0c0010d0d0 by thread T9:
    #0 -[__NSDictionaryM removeObjectForKey:]
  * #1 -[AFImageDownloader removeMergedTaskWithURLIdentifier:]
    #2 __61-[AFImageDownloader safelyRemoveMergedTaskWithURLIdentifier:]_block_invoke
    #3 __tsan::invoke_and_release_block(void*)
    #4 _dispatch_client_callout
    #5 -[AFImageDownloader safelyRemoveMergedTaskWithURLIdentifier:]
    #6 __78-[AFImageDownloader downloadImageForURLRequest:withReceiptID:success:failure:]_block_invoke_2.190

  Issue is caused by frames marked with "*".

  Thread T19 (tid=6605263, running) is a GCD worker thread
  Thread T9 (tid=6605223, running) is a GCD worker thread

SUMMARY: ThreadSanitizer: race on a library object <redacted> in __78-[AFImageDownloader downloadImageForURLRequest:withReceiptID:success:failure:]_block_invoke_2.190
==================

T19: AFImageDownloaderMergedTask *mergedTask = self.mergedTasks[URLIdentifier];     <--- AFImageDownloader.m:241
---
T9: [self.mergedTasks removeObjectForKey:URLIdentifier];   <--- AFImageDownloader.m:336

https://github.com/AFNetworking/AFNetworking/pull/4065
Have a choose for you.

+1 on this issue.

+1 on this issue

I believe this was fixed by https://github.com/AFNetworking/AFNetworking/pull/4246, which means this issue could be closed.


Allow multi language (subtitles)

It would be great the app would allow to download several subtitles (english, spanish,...) for the same course.

Thanks for your suggestion. I will see if we can implement this any time soon.


DEFAULT CURRENT_TIMESTAMP not valid SQL

org.apereo.cas.audit.entity.AuditTrailEntity and org.apereo.cas.trusted.authentication.api.MultifactorAuthenticationTrustRecord both contain the following column definition:
@Column(columnDefinition = "TIMESTAMP DEFAULT CURRENT_TIMESTAMP")
This is not valid SQL on the DB2 database I'm using (on DB2 it would be "TIMESTAMP WITH DEFAULT").
Why do these 2 entities even contain a default value? CAS never inserts into these tables without specifying the timestamp, so "DEFAULT CURRENT_TIMESTAMP" could just as well be omitted.

Handled in the latest snapshot.


Fix already processed fragments being recognised as new due to change of base fragments url

Same fragments might get different urls on a different worker server on two consecutive updates of hls playlist. HLSDownloader._fill_queue relies on comparison of full fragment urls to pick new ones, so when this happens it will treat all urls from the current playlist chunk as new, which will cause about ten fragments to get downloaded for a second time, leading to about a ten seconds segment of the video being repeated twice in the recording.
Here is an example of two different urls pointing to fragment with the same number and seemingly the same content:
https://us-west-1-media-worker1036.live.fc2.com/a/stream/v3/24678502/52/data/73436.ts?time=1703265219&hash=67345c5328fe0ebb54e35c3c1614d340625c55f264ffc66248879583423d2e3a
https://us-west-1-media-worker1035.live.fc2.com/a/stream/v3/24678502/52/data/73436.ts?time=1703265219&hash=2354e75fddf69a76f6f5b8337b880fa992ae42a15e4ddb6f9d077760bee1a54d

This PR makes it that only filename part of the fragment url (73436.ts for the links above) is used for comparison, which fixes the issue.
Currently there is no warning issued when it happens, but it can still be detected by [hls] Found 12 new fragments line in output. Perhaps some dedicated debug message should be added?

Thanks! I've been wondering why some of my recordings have repeated segments, but looks like this is the issue.


clarify support of new features across version-skewed clusters

Follow up from https://github.com/kubernetes/website/pull/11060, tracked in https://github.com/kubernetes/website/issues/12329
How users are expected to manage use of new features in version-skewed clusters is not clear in user-facing documentation:

[ ] what statement should be made about new features in version 1.x when running with a 1.x+ control plane and kubelets older than 1.x? is the user responsible for labeling nodes and workloads to only steer pods using those features to nodes with those capabilities? @kubernetes/sig-node-pr-reviews @kubernetes/sig-architecture-pr-reviews

Page to Update:
https://kubernetes.io/docs/setup/version-skew-policy/

This is difficult because it depends on the feature. Some features only require an updated control plane (e.g. things that are wholly implemented in the apiserver such as support for CRD versions or in the schedule like multiple scheduler support) while others require kubelets to pick up a new version.
It seems like each feature should describe the minimum required version for the feature to be used, and also indicate whether that version applies only to the control plane or also to the nodes. For features that require nodes to be updated, labeling can be helpful, but it would be better if the feature owner implemented the feature to degrade gracefully in the scenario where the control plane version is ahead of the node version.

/wg lts

/language en

/kind feature
/priority backlog

/remove-lifecycle rotten

I see a PR got merged; is this Done?

/reopen

/remove-lifecycle rotten

Hey
I see that this issue was just opened again. Is there anything I could do here?

/remove-lifecycle stale

@liggitt : Could you please elaborate if there's anything @Aut0R3V could help with here?


Latest release build has the wrong Nog Version environment variable

Latest release build has development set as the environment variable when you hover over the Nog icon in the system tray.

Fixed. Thank you!


After reboot not falling back to node red anymore

Hi,
I have succesfully installed the fallback skill on the latest release of piCroft. Everything was running fine after first installation. (tried the 'what does verge say' question succesfully) After reboot of the Picroft though it is not falling back anymore to the node red skill. it tries Wolfram and then goes directly to the UnknownSkill.
Same behavior on my desktop install. It works directly after first installation, but it looks like that it is changing settings somewhere in the first run resulting in not working anymore after a restart (of skill services)
Just to be clear, it is only the fallback part. For instance 'ping node red' is still working, so the skill is loaded.
Any ideas?
Thanks

I am having the same problem with the fallback (node-red.ask), stops working after a while.  The converse method does work though.

Found the solution for this problem.
It has to do with the priority setting. After the first time it will take the value from the skill config file (which is synced/connected/filled from the mycroft,ai backend). The parameter should be given in the registerfunction as an integer. After I changed that piece of code in the skill code into int(self.settings["priority"]) it was working perfectly.
I have not (yet) many expierence with contributing to code via Git (should learn, i know). maybe nodered or jarbas can apply this fix to the code.

fixed


CIS-CAT Pro finding <IP_ADDRESS>

Describe the Issue
Ensure successful and unsuccessful attempts to use the chcon command are recorded
Description:
The operating system must generate audit records for successful/unsuccessful uses of the chcon command.
UID_MIN=$(awk '/^\s*UID_MIN/{print $2}' /etc/login.defs)

[ -n "${UID_MIN}" ] && printf "

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=${UID_MIN} -F auid!=unset -k perm_chng

" >> /etc/audit/rules.d/50-perm_chng.rules \

|| printf "ERROR: Variable 'UID_MIN' is unset.\n"

Expected Behavior
A clear and concise description of what you expected to happen.
Actual Behavior
No auditd rules were found in the running config matching the regular expression:
"^\h*-a\h+(?:exit,always|always,exit)\h+(?:-S\h+all\h+)?(?:-F\h+path=/usr/bin/chcon(?:/)?)\h+(?!(?:\2\3))(-F\h+perm=x\h*|-F\h+auid>=1000\h*|(?:-F\h+(?:auid!=(?:unset|-1|4294967295)|(?:unset|-1|4294967295)!=auid)\h*))(?!(?:\1\3))(-F\h+perm=x\h*|-F\h+auid>=1000\h*|(?:-F\h+(?:auid!=(?:unset|-1|4294967295)|(?:unset|-1|4294967295)!=auid)\h*))(?!(?:\1\2))(-F\h+perm=x\h*|-F\h+auid>=1000\h*|(?:-F\h+(?:auid!=(?:unset|-1|4294967295)|(?:unset|-1|4294967295)!=auid)\h*))(?:-k\h+\H+|-F\hkey=\H+)\h(#[^
]+)?$"
Control(s) Affected
What controls are being affected by the issue
<IP_ADDRESS>
Environment (please complete the following information):

Ansible Version: [e.g. 2.10]
Host Python Version: [e.g. Python 3.7.6]
Ansible Server Python Version: [e.g. Python 3.7.6]
Using branch: [e.g. main]
Additional Details:

Additional Notes
Anything additional goes here
Possible Solution
Enter a suggested fix here

Essential Hygiene (CIS Critical Security Controls V8- IG-1)

NOTE: The template 99_auditd.rules.j2 has the hard-coded value auid!=4294967295 instead of auid!=unset.

NOTE: The template 99_auditd.rules.j2 has the hard-coded value auid!=4294967295 instead of auid!=unset.

Thanks @bbaassssiiee updated in may23_updates branch.


[WIP] Add DepthHeuristic to SABRE routing heuristics

Summary
This pull request introduces a new heuristic, DepthHeuristic, to the SabreSwap. The DepthHeuristic is designed to minimize circuit depth by penalizing swaps that increase the circuit's depth during the routing process. This enhancement provides users with additional flexibility to prioritize depth optimization, complementing the existing heuristics in SABRE.
Note: This pull request is currently a draft. I am still working on refining the depth calculation to ensure it's "truly correct," and additional enhancements will be added in future commits.
Details and Comments
Key Changes:

New Heuristic (DepthHeuristic) in heuristic.rs:

Added the DepthHeuristic struct, similar to BasicHeuristic and DecayHeuristic.
The DepthHeuristic includes weight and scale parameters, allowing users to adjust its impact on routing decisions.
Unlike LookaheadHeuristic and DecayHeuristic, this heuristic does not require additional parameters like size or reset. It is solely focused on depth-based penalties.

Depth Tracking in route.rs:

Introduced qubit_depths in RoutingState to track the depth of each qubit as routing progresses. It is only updated if the pass is ran with the depth heuristic.
Implemented a circuit_depth method to calculate the depth of the circuit as we progress through the routing, and considers the additional swaps as 3 cnots.
Integrated the DepthHeuristic into the choose_best_swap method to penalize swaps that increase circuit depth.
Updated the update_route method to correctly adjust qubit_depths when applying swaps and gates.

Updates to sabre_swap.py and test_sabre_swap.py:

Integrated DepthHeuristic into the SABRE transpiler, making it available for use alongside other heuristics.
Added tests for DepthHeuristic to ensure it functions correctly within the SABRE routing framework.

Future Considerations:

Depth Calculation Refinement:
Currently, the depth calculations are based on whether a swap adds depth to the circuit but do not consider the impact of immediate gates that can be applied after the swap. This refinement is critical because prioritizing swaps that enable multiple immediate gates without significant depth increase can improve routing efficiency. I have these changes in a separate branch and will be added once the corresponding tests are validated and passing.

Upcoming CriticalHeuristic:
I am also working on a new CriticalHeuristic in another branch and will make a seperate PR for that once that passes all the tests. This heuristic will focus on the critical path of the DAG, prioritizing gates that are part of this path.

Dynamic Scaling of Depth Impact:
We may want to think about having future iterations may explore dynamically scaling the depth penalty based on other heuristics or the size of the circuit, providing more nuanced control over depth optimization during routing.

Automated Depth Validation:
While manual tests were conducted to validate circuit_depth, an automated test would be beneficial. Specifically, this test should compare circuit_depth in RoutingState with the depth of a decomposed circuit in Python. At the moment, I could not think of an efficient way that matches qiskit's testing scheme to compare the result of a function in rust vs in python. The test should also address scenarios involving initial DAG circuits with swap gates, which are currently not decomposed into three swaps in the Rust implementation.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

51 of 72 (70.83%)  changed or added relevant lines in 3 files are covered.
9 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.008%) to 89.571%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/accelerate/src/sabre/heuristic.rs
8
29
27.59%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

crates/qasm2/src/lex.rs
2
92.98%

crates/qasm2/src/parse.rs
6
97.15%

Totals

Change from base Build<PHONE_NUMBER>0:
0.008%

Covered Lines:
67647

Relevant Lines:
75523

💛  - Coveralls

Thank you for the review! I’ve made the changes to address your comments.
The most consistent case studies where this new heuristic shows significant improvement over lookahead are circuits with sequentially dependent interaction chains, like QFT and GHZ. I’ve added a test case to demonstrate this improvement, though I’m not entirely sure how to conclusively prove the improvement is inherent to the depth heuristic rather than due to random variability.
From my testing, for large circuit sizes and coupling maps with higher connectivity than a ring, the depth heuristic consistently yields better depth reductions by leveraging parallel swaps, although it does lead to an increase in the number of gates added. To ensure thoroughness, the test I added runs multiple trials and compares the median results. However, in practice, a single trial often shows this advantage clearly.


Cucumber html report and command line metrics not correct when feature has a pending scenario

Current behavior
Currently, when a feature has a pending scenario the html report includes this as an executed test rather than skipping it. In the screenshot, it should be 2 executed. Also, the remaining steps in the undefined scenario are being shown as skipped but should also be pending. The first step in the undefined scenario has an attached image (due to the scenario being executed and reporting a fail) which should not be present as the scenario should not be executed.

On the command line, the undefined test scenario is counted as a failed test

If a feature has 2 tests which pass with 1 undefined scenario the report shows the run as undefined rather than a pass (red underscore)

Command line showing undefined scenario as a fail

Desired behavior
Cucumber html report and command line runner should report the correct metrics when a feature is run and pass or fails with an undefined scenario
Test code to reproduce
Run examples in README: https://github.com/ijaved/cypress-cucumber-preprocessor-reporting-example
Versions

Cypress version: 14.14.0:
Preprocessor version: 18.0.1:
Node version: 16.16.0:

Checklist

[ ] I've read the FAQ.
[ ] I've read instructions for logging issues.
[ ] I'm not using<EMAIL_ADDRESS>(package name has changed and it is no longer the most recent version, see #689).

Currently, when a feature has a pending scenario the html report includes this as an executed test rather than skipping it. In the screenshot, it should be 2 executed.

Why do you think so?

If a feature has 2 tests which pass with 1 undefined scenario the report shows the run as undefined rather than a pass (red underscore)

Are you implying that it shouldn't? If so, why?

@badeball

Currently, when a feature has a pending scenario the html report includes this as an executed test rather than skipping it. In the screenshot, it should be 2 executed.

There's an argument that the test scenario steps do not have matching step definitions to run so although the test is included in the test run it hasn't actually run. However, the current working way is fine.

If a feature has 2 tests which pass with 1 undefined scenario the report shows the run as undefined rather than a pass (red underscore)

Again, this is probably correct behaviour as all tests passing will show the green icon with a tick beside the accordion header feature/<feature-name>.feature and in the example there is an undefined scenario which is why it has the yellow icon with question mark.
Although, the command line metrics in the screenshots showing undefined tests as failing should be addressed.. Should also consider skipped tests which may show as failing although I haven't tested this...

Closing as not an issue with the preprocessor.

@badeball
For the undefined scenario, the remaining 3 steps are showing the skipped icon but should all show the undefined icon as they do not have any associated step definitions.


add ramp-up command

Hi, thank you that you are investing your time for this great tool!
Proposal
vegeta should have an option to ramp up the rate at the start. Example: rate of 200 is given and rampup of 10 seconds is given - than vegeta increase the rate of 10% per second:
first second: 10% - rate=20
second second: 20% - rate=40
...
tenth second: 100% - rate=200
command could be as followed:
-rampup int
    seconds to ramp-up the target-rate

That option would allow to attack/test targets more naturally, since traffic (at least on our servers) does not increase that much from one second to the other.
Background
I just tested some webserver-configurations and optimized them. webservers cannot handle the traffic-jump (like 10 rq/s to 1,000rq/s in less than a second), because they need to spawn extra workers and so on. Without the rampup the report is falsified, since the webservers needs some seconds to scale.
Workarounds
I'm not aware of a workaround.

@cklm one workaround  I can think of is to sequence test runs and aggregate the results.

1 on the need of the feature.

I've been successful using the load-ramping script with tweaked values for this https://github.com/tsenart/vegeta/tree/master/scripts/load-ramping.
I also wrote a RampPacer that does something similar to what you describe if you're interested in looking into the code, but it is used as a lib and not as a vegeta command.

A ramp up and down would be useful in any load test tool.


Not working after Feedly update

Feedly updated code around August 14 and the Chrome extension stopped working.

Thanks - but can you give more detail?  Does the screen look different?  What specific view are you using for your stories?  (I only ask these questions because I use the plugin every day and it's still working fine for me... so I'm probably not using it the same way you are).

Hi Aaron. Thank you for the quick reply.
Screen looks the same as when it last worked (maybe Thursday night). I'm
using Feedly on two Macbooks and the extension doesn't work on either.
I'm using default view (titles only). Since you asked I just tried Magazine
and it still didn't work.
I emailed Feedly yesterday and they said: "We cleaned up the HTML markup of
the feedly UI a lot. It could be that this cleanup might have broken that
extension. Hard to know without knowing how their extension is implemented."
I'm trying to think what else could mess with the extension.
Steve
On Mon, Aug 15, 2016 at 3:21 PM, Aaron Saray<EMAIL_ADDRESS>wrote:

Thanks - but can you give more detail? Does the screen look different?
What specific view are you using for your stories? (I only ask these
questions because I use the plugin every day and it's still working fine
for me... so I'm probably not using it the same way you are).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aaronsaray/feedlybackgroundtab/issues/10#issuecomment-239917131,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUEgPyvmEt0aejF_ZAXkvKM06yV3ozz4ks5qgMpigaJpZM4Jku26
.

Ok cool - I don't know how to explain this next part so bear with me...
On the magazine layout, does it say "All" or is it broken up into multiple items?  Reason I ask is the other night I had mine broken up for one load - the plugin stopped working - and I thought I was just too tired to use the computer - went to bed.  When I woke up it was still fine... sooooo is it 'all' or are you looking at specific feeds? And then I think I saw something like "Popular" vs "All" on there too - but I can't get that to pop back up for me.  So do you see popular on yours too?
Thanks for taking the time to describe.  Might take me a few days to update this - but should be by the end of the week max.

On Magazine layout (which I normally don't use), "All" still looks like
default.
When I click on one of my categories Magazine layout appears.
Either way -- whether I'm in All or in one of my feed categories -- the
extension still doesn't work in Magazine view.
Thanks again!
On Mon, Aug 15, 2016 at 3:44 PM, Aaron Saray<EMAIL_ADDRESS>wrote:

Ok cool - I don't know how to explain this next part so bear with me...
On the magazine layout, does it say "All" or is it broken up into multiple
items? Reason I ask is the other night I had mine broken up for one load -
the plugin stopped working - and I thought I was just too tired to use the
computer - went to bed. When I woke up it was still fine... sooooo is it
'all' or are you looking at specific feeds? And then I think I saw
something like "Popular" vs "All" on there too - but I can't get that to
pop back up for me. So do you see popular on yours too?
Thanks for taking the time to describe. Might take me a few days to update
this - but should be by the end of the week max.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aaronsaray/feedlybackgroundtab/issues/10#issuecomment-239923274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUEgP7bq0y7nreZjEtwDPjBqOVaxZYj6ks5qgM-RgaJpZM4Jku26
.

I can confirm that this is happening in the list view as well following the latest Feedly update. The plugin outputs Could not find any selectors from: .selectedEntry a.title,a.websiteCallForAction in the JS console. Looking at the source it appears that the markup has changed to .selected a.visitWebsiteButton. I'll submit a quick PR to address this.

I am having the same issue.   I see the same error in the js console.  It appears to becoming from keypress.js line 61.

Suggestion:  setup a PayPal donation account (or make a list a few of your favorite charities) so those of us who depend on this plugin can send $20.

You'd see my donation come in very quickly.  :)
On Wed, Aug 17, 2016 at 5:39 PM, rob9283<EMAIL_ADDRESS>wrote:

Suggestion: setup a PayPal donation account (or make a list a few of your
favorite charities) so those of us who depend on this plugin can send $20.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aaronsaray/feedlybackgroundtab/issues/10#issuecomment-240571056,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUEgP09Y42dtlbc3G-u_GBFdPmvmDT4vks5qg42lgaJpZM4Jku26
.

Ok - sorry for the delay. I'll be accepting the pull request and packaging up a new feedly plugin tomorrow.
Just wanted everyone to know I haven't gone radio silent - its coming very soon! :)

Hey all - I've released a fix - thanks to @bval for his suggested pull request.
Here's the tricky part - it was always working for me - it was only broken for everyone else apparently.  Don't ask me how!  At any rate, I came up with a fix that used @bval's solution but it also works for me.  It has been pushed out to the google store.  Please someone comment on this ticket when you get the update to validate it's working for you.
PS: Again, thanks so much for the offers of support via paypal/donations.  Instead, I've created a kiva.org group - check out the updated readme of this project to find out more.  The short version - this software is free and I never want money - but I'd appreciate you doing good by giving loans and joining my team on that website.  Super cool - you help out people in need with loans - and you get your money back - the cycle continues!

Works for me! Joined your Kiva team... what's next? Do I add funds?

@sholstein yup - basically you find a loan (click the lend button) - and find a story that connects with you. Once you find someone who you feel like supporting, you click 'lend' - and then you'll 'checkout' almost like a purchase.  Again - thanks for following through and joining kiva - but if you don't find a loan that you feel compelled to make, please don't make one.  Wait until next week! There are always new ones coming and going.
I have the updated version of the plugin and it's looking well to me too.  I'm going to close this ticket.  Thanks to all that helped.


Feature Request: Highlight global toggle

Would it be possible to have words be highlighted in all channels, please? Having it as a toggle option would be useful. Thanks.

Unfortunately I won't be adding it due to people will be highlighted if mentioned in channels they can't see. I'll think about it but it'll only be if they can see that channel.

Would it be possible to add channels through another channel? For example, let's say a server has a dedicated channel for bot commands, then they can add the channel ID to the string.

A channel option has been added as of 1.1.0. You can now do [p]highlight add #channel string you want highlighted OR you can use it as [p]highlight add string you want highlighted.
You must have access to the channel to use the toggle command however. If there's anymore suggestions or issues then let me know as I didn't have much time to test.

Thanks for adding the feature! One thing that seems to be missing is the ability to toggle new additions from the seperate channel. Thanks again!

I'll look into listing them all and read above as to why I didn't enable toggling from another channel.

By having "access", do you mean you have permissions or have to be inside the channel? Because I have permissions and still can't use toggle.

You must use the command in the channel directly as to avoid those with no access to the channel being able to add and toggle highlights in said channel.


Feature request: add 'changelog' metadata field (version and add/mod/del)

Is your feature request related to a problem? Please describe.

So that I can understand the changes that have occurred to the dataset over time, as a Data User, I want to see the rest of the changelog information for the dataset/collection (version, added, deleted, modified).
Describe the solution you'd like

Extend the linz:changelog metadata object, by adding 'version', 'added', 'modified' and 'deleted'
Location: collection top level field metadata
Name: linz:changelog
Description:

Contains a log of changes that have occurred within the data collection. The version and date should correspond to the 'dataset version' and 'dataset updated' values for that version. The description should be a concise summary of changes. The Added, Modified, and Deleted counts fields are recommended and should be automatically populated from the dataset change. These counts represent the following for given data content types:

Vector layers - Feature counts
Tables - Row counts
Rasters - Tile file counts
Point Clouds - Point counts.
Images - Image file counts

Optional/Required: "Required"
Restrictions: An object that must have
'date' (UTC datetime),
'version' (string),
'description' (string)
and can include
'added' (integer),
'modified' (integer),
'deleted' (integer).
Changelog history should ideally be ordered newest to oldest. Suggest structuring as a list of json objects.
Example
Date: 2020-04-22T02:17:24.900422Z
Version: "1.3.0"
Description:  "Replaced tile BG37_5000_1009 to include nodata region.

A LDS customer noticed that tile BG37_5000_1009 had black regions on the outer edges of the image. The tile was reprocessed using GDAL to set the black regions to a nodata value to match the other tiles nodata values within the dataset.

Refer to issue https://jira.linz.govt.nz/browse/TODATA-654"
Added: 1
Modified: 0
Deleted: 0

Describe alternatives you've considered

Additional context

Discussion with Victor
May need to expand on explanation for add/mod/del, like other data types and ways to count them


iot central minor swagger changes and description fixes

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

Pending for API board.
@rafarhat Please add code owner of the service to PR (if available) as well. Thanks.

@yaohaizh This is an update for our Swagger for the same set of IoT Central APIs that we have approval from API review board. Could you please take a look and add the appropriate tag?

@avneet723 @weidongxu-microsoft  updated.


uninitialized constant ActiveSupport::ParameterFilter in version 1.8.3 with rails 6

I am on Rails 6. Version 1.8.2 and 1.8.3 and throwing following error:
`block in load_missing_constant': uninitialized constant ActiveSupport::ParameterFilter (NameError)

however 1.8.1 is working. Disabling the gem makes the app work again:
Loading development environment (Rails 6.0.0)
irb(main):001:0> ActiveSupport::ParameterFilter
=> ActiveSupport::ParameterFilter

adding explicit require 'active_support/parameter_filter' in application.rb solved my problem. It seems like gem was loading earlier than active_support/parameter_filter during initialization process somehow

can confirm that this solved my issue. I will keep it anyway open.

When I add require 'active_support/parameter_filter' to my application.rb, I see the following error 🤔
FrozenError:
  can't modify frozen #<Class:#<Array:0x000055fd16c339d0>>: ["/app/app/api", "/app/app/channels", "/app/app/controllers", "/app/app/controllers/concerns", "/app/app/jobs", "/app/app/mailers", "/app/app/models", "/app/app/models/concerns", "/app/app/modules"]

Full trace
FrozenError:
  can't modify frozen #<Class:#<Array:0x000055fd16c339d0>>: ["/app/app/api", "/app/app/channels", "/app/app/controllers", "/app/app/controllers/concerns", "/app/app/jobs", "/app/app/mailers", "/app/app/models", "/app/app/models/concerns", "/app/app/modules"]
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/change_observer.rb:21:in `unshift'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/change_observer.rb:21:in `unshift'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:576:in `block in <class:Engine>'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:32:in `instance_exec'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:32:in `run'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:61:in `block in run_initializers'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `each'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `tsort_each_child'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `each'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `tsort_each_child'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `each'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `tsort_each_child'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `each'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `tsort_each_child'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `each'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `tsort_each_child'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `each'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:50:in `tsort_each_child'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:60:in `run_initializers'
# /usr/local/bundle/gems/railties-<IP_ADDRESS>/lib/rails/application.rb:363:in `initialize!'
# ./config/environment.rb:7:in `<main>'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require'
# /usr/local/bundle/gems/zeitwerk-2.4.0/lib/zeitwerk/kernel.rb:34:in `require'
# ./spec/rails_helper.rb:6:in `<main>'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require'
# /usr/local/bundle/gems/zeitwerk-2.4.0/lib/zeitwerk/kernel.rb:34:in `require'
# ./spec/modules/company_spec.rb:3:in `<main>'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:55:in `load'
# /usr/local/bundle/gems/bootsnap-1.4.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:55:in `load'

I'm on:

Rails (<IP_ADDRESS>)
Grape_logging (1.8.3)

I am also getting this on a brand new Ruby 2.7.0  & Rails <IP_ADDRESS> application. Here is my Gemfile:
source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby `cat .ruby-version`.chomp # 2.7.0

gem "bcrypt"
gem "bootsnap", require: false
gem "pg"
gem "puma"
gem "rack-cors"
gem "rails"
gem "rubocop"

# Grape
gem "grape"
gem "grape-entity"
gem "grape_logging"
gem "grape-swagger"
gem "grape-swagger-entity"

group :development, :test do
  gem "rspec-rails"
  gem "pry-rails"
end

group :test do
  gem "webmock"
end

group :development do
  gem "listen"
end

Here is the full stack trace:
18: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/railties-<IP_ADDRESS>/lib/rails/commands.rb:18:in `<top (required)>'
17: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/railties-<IP_ADDRESS>/lib/rails/command.rb:46:in `invoke'
16: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/railties-<IP_ADDRESS>/lib/rails/command/base.rb:69:in `perform'
15: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
14: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
13: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
12: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/railties-<IP_ADDRESS>/lib/rails/commands/server/server_command.rb:138:in `perform'
11: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/railties-<IP_ADDRESS>/lib/rails/commands/server/server_command.rb:138:in `tap'
10: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/railties-<IP_ADDRESS>/lib/rails/commands/server/server_command.rb:141:in `block in perform'
9: from /Users/davidshaffer/Dropbox/Coding/Personal/Apps/cover_band/cover_band_api/config/application.rb:20:in `<top (required)>'
8: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/2.7.0/bundler.rb:174:in `require'
7: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/2.7.0/bundler/runtime.rb:58:in `require'
6: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/2.7.0/bundler/runtime.rb:58:in `each'
5: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/2.7.0/bundler/runtime.rb:69:in `block in require'
4: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/2.7.0/bundler/runtime.rb:69:in `each'
3: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/2.7.0/bundler/runtime.rb:74:in `block (2 levels) in require'
2: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/2.7.0/bundler/runtime.rb:74:in `require'
1: from /Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/grape_logging-1.8.3/lib/grape_logging.rb:17:in `<top (required)>'
/Users/davidshaffer/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/grape_logging-1.8.3/lib/grape_logging/util/parameter_filter.rb:9:in `<top (required)>': uninitialized constant ActiveSupport::ParameterFilter (NameError)

Adding require "active_support/parameter_filter" to the top of application.rb does fix this, however this seems subpar. This is weird because I have some applications that have this same setup, though I would be willing to bet the reason those apps work and this one doesn't is because they load all of ActiveSupport by the time this gem is loaded.

fixed with https://github.com/aserafin/grape_logging/pull/72 thanks again @flanger001 💪


[Bugfix] keep the aggregate expr order when rewrite aggregate operator

What type of PR is this：

[ ] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：
Fixes #7659
Problem Summary(Required) ：
we should keep the aggregate expr order when rewrite, because we will use
singleDistinctFunctionPos to decide call update or merge

[FE PR Coverage check]
:heart_eyes: pass : 8 / 8 (100.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/sql/optimizer/rewrite/AddDecodeNodeForDictStringRule.java
8
8
100.00%

[FE PR Coverage check]
:heart_eyes: pass : 8 / 8 (100.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/sql/optimizer/rewrite/AddDecodeNodeForDictStringRule.java
8
8
100.00%

https://github.com/Mergifyio backport branch-2.1

https://github.com/Mergifyio backport branch-2.2

https://github.com/Mergifyio backport branch-2.3


Builtin git extension becomes unresponsive

Type: Bug
I recently started experiencing issues with the builtin git extension in VS Code. In some repositories (but not others), the extension initially works fine, detecting changes and showing them under "changes" in the "source control" panel on the left. However, very quickly, and after nothing more special than continuing to make changes to the code, the extension becomes unresponsive -- the buffering bar just keeps scrolling in the git tab, and the git logs in the bottom "OUTPUT" panel stop updating. However, my code editor still recognises and highlights file changes in the editor, and git still seems to work from the CLI.
VS Code version: Code 1.96.0 (138f619c86f1199955d53b4166bef66ef252935c, 2024-12-11T02:29:09.626Z)
OS version: Darwin arm64 23.4.0
Modes:
Connection to 'SSH: sagemaker-user.latest.studio.sagemaker' could not be established
Remote OS version: Linux x64 5.10.227-219.884.amzn2.x86_64
Remote OS version: Linux x64 5.10.227-219.884.amzn2.x86_64
Connection to 'SSH: sagemaker-user.latest.studio.sagemaker' could not be established  Canceled
Connection to 'ssh-remote+sagemaker-user.latest.studio.sagemaker' could not be established
Remote OS version: Linux x64 5.10.227-219.884.amzn2.x86_64

System Info

Item
Value

CPUs
Apple M3 Pro (11 x 2400)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabledwebgpu: enabledwebnn: disabled_off

Load (avg)
3, 3, 3

Memory (System)
36.00GB (0.45GB free)

Process Argv
--crash-reporter-id d87f7b15-3b38-4bf8-8ef4-871132323149

Screen Reader
no

VM
0%

Connection to 'SSH: sagemaker-user.latest.studio.sagemaker' could not be established

Item
Value

Remote
SSH: sagemaker-user.latest.studio.sagemaker

OS
Linux x64 5.10.227-219.884.amzn2.x86_64

CPUs
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz (16 x 0)

Memory (System)
124.35GB (111.57GB free)

VM
0%

Item
Value

Remote
SSH: sagemaker-user.latest.studio.sagemaker

OS
Linux x64 5.10.227-219.884.amzn2.x86_64

CPUs
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz (16 x 0)

Memory (System)
124.35GB (111.57GB free)

VM
0%

Connection to 'SSH: sagemaker-user.latest.studio.sagemaker' could not be established  Canceled
Connection to 'ssh-remote+sagemaker-user.latest.studio.sagemaker' could not be established

Item
Value

Remote
SSH: sagemaker-user.latest.studio.sagemaker

OS
Linux x64 5.10.227-219.884.amzn2.x86_64

CPUs
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz (16 x 0)

Memory (System)
124.35GB (111.57GB free)

VM
0%

Extensions (23)

Extension
Author (truncated)
Version

catppuccin-vsc
Cat
3.16.0

jupyter-keymap
ms-
1.1.2

remote-containers
ms-
0.394.0

remote-ssh
ms-
0.116.0

remote-ssh-edit
ms-
0.87.0

remote-wsl
ms-
0.88.5

vscode-remote-extensionpack
ms-
0.26.0

remote-explorer
ms-
0.4.3

remote-server
ms-
1.5.2

pdf
tom
1.2.2

ruff
cha
2024.56.0

copilot
Git
1.251.0

copilot-chat
Git
0.23.1

vscode-pull-request-github
Git
0.102.0

magit
kah
0.6.64

debugpy
ms-
2024.14.0

python
ms-
2024.22.0

vscode-pylance
ms-
2024.12.1

jupyter
ms-
2024.11.0

jupyter-keymap
ms-
1.1.2

jupyter-renderers
ms-
1.0.21

vscode-jupyter-cell-tags
ms-
0.1.9

vscode-jupyter-slideshow
ms-
0.1.6

(5 theme extensions excluded)

A/B Experiments
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30959799
pythonnoceb:30805159
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
dvdeprecation:31068756
dwnewjupytercf:31046870
nativerepl1:31139838
pythonrstrctxt:31112756
nativeloc1:31192215
cf971741:31144450
iacca1:31171482
notype1cf:31157160
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530

@adriancaruana, thanks for filing the issue. It would be great if you could be able to identity a set of repro steps that you can use to reproduce the issue so that we can then collect additional information. A recording (https://gifcap.dev) would also help significantly. Are there any commonalities for the folders/workspaces where you are able to reproduce this? Are you able to reproduce the issue with all 3rd party extensions disabled?

Hi @lszomoru. I think I figured this out. I believe that somehow I had two different versions of .vscode-server running on my ssh remote. After running ps aux | grep -ie .vscode-server | awk '{print $2}' | xargs kill -9 and re-connecting, the issue seems to have gone away.


(Resolved) Evaluation problem

Hi,
Thanks for sharing the code.
I have a problem running the evaluation.
I got this error:
_pickle.UnpicklingError: invalid load key, 'v'.
Any solution?
Thank you in advance.

I set num_workers=0 and faiss_num_workers=0 for run_patchcore.py and load_and_evaluate_patchcore.py

Hello, I have the same problem while loading the pkl file how did you solve it?
System: Window
Environment: python 3.9 torch 1.10

Set the num_workers=0 and faiss_num_workers=0

Sorry, I did not use Git lfs during the cloning repository. If we directly download the repository, we are not able to fetch data from git lfs file. So I clone the repository using git clone and than use git lfs to fetch pre-trained weights. In this way, we can load correctly. I think there is no connection of num worker with the loading of pkl file.

Set the num_workers=0 in run_patchcore.py and faiss_num_workers=0 in load_and_evaluate_patchcore.py
Hi, I don't know why, but I'm still getting errors with this setup!

Set the num_workers=0 in run_patchcore.py and faiss_num_workers=0 in load_and_evaluate_patchcore.py
Hi, I don't know why, but I'm still getting errors with this setup!
As @Ehteshamciitwah said, git the repository but not download. if download,files in models/ are just links.

Sorry, I did not use Git lfs during the cloning repository. If we directly download the repository, we are not able to fetch data from git lfs file. So I clone the repository using git clone and than use git lfs to fetch pre-trained weights. In this way, we can load correctly. I think there is no connection of num worker with the loading of pkl file.

Hi, sorry, I forgot a year ago, this problem occurred when I re-trained and wanted to evaluate it, this setting worked on my PC, maybe I did other settings too but I forgot

Sorry, I did not use Git lfs during the cloning repository. If we directly download the repository, we are not able to fetch data from git lfs file. So I clone the repository using git clone and than use git lfs to fetch pre-trained weights. In this way, we can load correctly. I think there is no connection of num worker with the loading of pkl file.

Hi, sorry, I think you are right, I forgot the other settings I did, it was a year ago


Fixing the issues in the tests

Description
This PR seeks to fix the issues pointed out by Matt in the initial commit of this repo.
Fixes #(issue)
I added a extensions for FillArrays and created default type parameters for an AbstractFill.
Checklist:

[x] Default parameters are defined for AbstractFill and AbstractUnallocatedFill types.
[x] Tests all run as expected with no errors

@mtfishman It looks like the problem was related to looping over the types written as sybmols. For example in for typ in (:Fill, :Zeros), typ was being interpreted as a symbol and, though we had defined a default_type_parameter for the AbstractFill type, we don't have default parameters defined for symbols which was causing the code to error out.

@mtfishman , I think the easiest would be if you merge this, I'll apply the new skeleton on top of that in a separate PR?


avoid deprecated calls

When running the action you will see:
Warning: The `add-path` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands

This has been fixed

Has it been released as a new version too?

This is patched in the current version, you don't need to change your workflow


[Build] ESP32-C3 build error visual-studio code

Build issue(s)
I Have followed https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/BUILDING.md build guide for macOS.

Checkedout Matter code
Synchronised submodules
Installed brew
Installed ZAP
Used following commands in terminal with success:

source scripts/activate.sh
source scripts/bootstrap.sh
gn gen out/host
ninja -C out/host
ninja -C out/host check
Then I usedVisual Studio Code with pre-installed ESP-IDF and opened folder /conncectedhomeip/examples/lighting-app/esp32

I have selected port for my ESP32 and set target to esp32c3 (Board I am using to test the code).
I build the code and get the following error:

CMake Error at third_party/connectedhomeip/config/esp32/components/chip/CMakeLists.txt:308 (message):
The 'gn' command was not found.  Make sure you have GN installed.Or have
followed necessary build preparations stated in BUILDING.md.
Can you please advise what to do I am running out of ideas, thanks.
Picture of the output:

Platform
vscode
Anything else?

@BartJozwicki On the same terminal window..you need to export esp-idf using source path/to/esp-idf/export.sh and then you need to activate matter using source path/to/connectedhomeip/scripts/activate.sh after that you can run idf.py build. Can you please try these steps in the same sequence?

@BartJozwicki
Are you referring to esp-idf extension for vscode?
What error do you get on building with vscode? is it same i.e., "The 'gn' command was not found. Make sure you have GN installed."
If Yes, can you please confirm that gn is installed on you system by running gn --version.

@BartJozwicki Can you please provide your inputs. If this seems to solve your issue, please close this.

Issue solved thank for help, I will close it now.


[V2] Price Slider: Ramp increments

From @briansw on March 8, 2016 14:6
is it possible to increment in a more nuanced way:

up to 10k = by $100
10–25k = by $500
25–50k = by $1k

Copied from original issue: artsy/force-private#4521

From @joeyAghion on May 23, 2016 16:50
As a cheapskate, I'd also love the price selector to start at $0.