Make RunOnce a non-manual System impl

Objective

RunOnce was a manual System implementation.
Adding run criteria to stages was yet to be systemyoten

Solution

Make it a normal function
yeet

I do really like simplifying this impl + the general progression we've had toward consolidating system logic under "system functions". But I'm also not particularly happy with "functions returning closure systems" as our public interface.
I don't think its possible with IntoSystem as it stands (because it requires a "nameable type" to assign the returned system type), but I rather like the idea of:
struct RunOnce;
// maybe IntoSystem could default to () for its generics to enable this
impl IntoSystem for RunOnce {
    // this should work if/when "impl trait in associated types" lands.
    type System = impl System<In = (), Out = RunCriteria>;

    fn into_system(self) -> Self::System {
        let mut ran = false;
        (move || {
            if ran {
                ShouldRun::No
            } else {
                ran = true;
                ShouldRun::Yes
            }
        }).system()
    }
}

This would allow users to transform arbitrary structs (and use their fields) to construct closure function systems. Slightly more boilerplate, but it has the benefit of allowing stuff like:
app
  .add_system(foo.with_run_criteria(FixedTimestep::from_seconds(2.0)))
  .add_system(bar.with_run_criteria(FixedTimestep::from_duration(Duration::from_secs_f64(1.0))))

Compared to stuff like:
app
  .add_system(foo.with_run_criteria(fixed_timestep_from_seconds(2.0)))
  .add_system(bar.with_run_criteria(fixed_timestep_from_duration(Duration::from_secs_f64(1.0))))

The former is much more discoverable, documentable, and "rusty" in my personal opinion.
I'm down to discuss this, but if we agree thats what we should be aiming for ultimately, maybe we should adopt something like this in the interim?
impl RunOnce {
    pub fn new() -> impl FnMut() -> ShouldRun {
        let mut ran = false;
        move || {
            if ran {
                ShouldRun::No
            } else {
                ran = true;
                ShouldRun::Yes
            }
        }
    }
}

Heck, maybe thats better than an IntoSystem impl?

bors r+


G-CSF treatment

https://www.ncbi.nlm.nih.gov/pubmed/32113042

This is related to #168. I'll include G-CSF treatment along with G-CSF test and use this reference.


feat: add 'Launch in Fiddle' button to code blocks

Finally the last bit to integrate a Launch in Fiddle button to code examples on our webpage.
The button will only be shown if the code block's data-fiddle-url html attribute is set (see https://github.com/electron/i18n/pull/769 for more context on how we derive that from the markdown docs).
To use this feature, just create a gist (url: electron-fiddle://gist/{id}) or a file in the electron repo (url: electron-fiddle://electron/{ref}/{path/to/example}) and add the url to the corresponding code block in our /e/e docs:
```javascript fiddle='electron-fiddle://gist/{id}'
const { app } = require('electron')
...

cc @felixrieseberg @erickzhao @zeke @HashimotoYT

🎉 Is there a staging URL for trying this out?

I think https://electron-website-pr-2848.herokuapp.com works - but since there are no docs equipped with a fiddle, you won't notice 👀.

This doesn't show any helpful information to the user when Fiddle doesn't installed. Maybe redirect to /fiddle?

Yeah, i remember the idea of a launchpad floating around. Unfortunately, i don't think there's currently space on my backlog for it - also i never created sth like that. Maybe @felixrieseberg can give us some detail on how it's done at Slack.

We can run a specified version of an Electron? Some APIs can be work on 5 but doesn't work at 6.

According to @erickzhao, the version will be derived from the url when you link a file on a specific branch. For a gist, it defaults to the most recent version (but we don't care about that in docs anyway).

How about this approach for now? Simply redirecting the user to the /fiddle page when fiddle is not installed.
Would be nice to add a notice for the user somewhere why this happened tho - any suggestions for a good place :)?

How about this approach for now? Simply redirecting the user to the /fiddle page when fiddle is not installed.

For UX reasons we definitely need to send them first to a place that says something like "Attempting to open Electron Fiddle", then when it doesn't appear to work we need to tell them (a) what fiddle is and (b) where to get it.
The page itself should be relatively small and live in the fiddle.electronjs.org site.  For example here is the Slack launchpad, a spinner and a few lines of text.

Oh I like the idea of Open link in browser - because that's absolutely possible with gists & repo files. Well, then let's put this launchsite somewhere on my backlog 👀

Now using the new http://fiddle.electronjs.org/launch page. This is ready to roll:

Ah the docs on electronjs.org finally were updated again - let me test this :)

Meh, meanwhile got kicked out the electron org and don't have push access anymore - but if you rebase to master, this one works as expected :)
cc @MarshallOfSound

Perfect, ty - ready to be merged by someone with write-access :)
https://electron-website-pr-2848.herokuapp.com/docs/api/screen


[chip-test] SiVal test plan updates for USBDEV

Added list of usbdev features.
List usbdev chip-level tests available for SiVal.
Note:
A number of these tests are not yet available, pending merging into the repository but they can be included soon.
For now, tests related to Suspend, Resume, Sleep and Wake are not included in this SiVal test list although they cover important functionality. These tests still require completion.
This PR does however list the features/functionality that they shall cover.
Describes/depends on new tests in PR #19672 and PR #19673.

Also, we need to fix some errors that are tripping up CI, for example:
Fixing file: "hw/top_earlgrey/data/ip/chip_usb_testplan.hjson"
##[error]Whitespace check failed. Please run util/fix_trailing_whitespace.py on the above files.

CHANGE AUTHORIZED: hw/ip/usbdev/data/usbdev.hjson

A conflict in the test plan needs to be resolved before merging this.

A conflict in the test plan needs to be resolved before merging this.

Okay, rebased.

CHANGE AUTHORIZED: hw/ip/usbdev/data/usbdev.hjson

Thanks for this good work. I think this is a very detailed and sufficient test plan for OpenTitan's USB. Just a few comments, but once those are done it should be ready.

Two of the newly-created SiVal tests just got merged, so I've rebased on top of those changes and hopefully it's good to go now.

Ignoring kokoro failure (it's broken for everything: nothing to do with this PR!). Let's go with this.


Pipe Character Splitting Prompt

I am using a prompt which has multiple | symbols used in it. Somehow, promptfoo splits the prompt into multiple prompts. Is there a fix or workaround for this without removing the pipe character?

Example config?
This is probably due to the behavior of pipe in YAML, which can be escaped.

The config file is as follows:
prompts:

../../../../prompts/myPrompt.txt

providers:

insert provider data here, using openai:gpt-4o at the moment.

tests:

assert:

type: icontains-all
value:

'someValue'

The myPrompt.txt looks like the following:
Some very long text here blah blah blah | Something written here | Something written here too | Some more very long text here.
This gets split up like this, which is not what I wanted:

Unfortunately I'm unable to repro with the following.  If you could share an exact example or a zip, that could help.
promptfooconfig.yaml:
prompts:
  - prompt.txt
providers:
  - openai:gpt-4o-mini

tests:
  - assert:
    - type: icontains-all
      value:
        - 'someValue'

prompt.txt:
Some very long text here blah blah blah | Something written here | Something written here too | Some more very long text here.

Ah apologies, I just noticed that there was the --- separator between the pipe characters, which is why it was being split. Didn't notice these before.

Got it.  One workaround here would be to override the separator to something that you're not using, with the PROMPTFOO_PROMPT_SEPARATOR environment variable.
For example
PROMPTFOO_PROMPT_SEPARATOR=xxxxxxxxxx promptfoo eval

Thanks! Closing this.


Wrong calculations by pow()

I just realized that pow() produces wrong results.
Specifically:
pow(-2, 2) yields inf instead of 4.

This is the NuttX implementation of pow():
double pow(double b, double e)
{
  return exp(e * log(b));
}

A friend of mine advised me that it is incorrect to use log() with negative numbers.
(I am not capable of evaluating such math expressions myself, sorry...)
So we need special handling for negative bases, I guess?

Note to self.
This is how the C standard defines the pow() function:

The pow function computes x raised to the power y. A domain error occurs if x is negative
and y is not an integral value. A domain error occurs if the result cannot be represented when x
is zero and y is less than or equal to zero. A range error may occur.

@fjpanag I talked with project maintainer of the LibmCS and he trying to get authorization from ESA to let's include it on NuttX to replace our Rhombus' libm implemantation.  It would be great to include a high quality library in NuttX!
For the record, I fixed this specific function. I just haven't pushed it yet.
I haven't done so because the exact same Lua test fails again, although the function seems to behave correctly now.
Thus, either my fix is wrong, or other libm functions are called for the same operation, and there is another bug elsewhere...
Compiling with the toolchain provided library fixes all issues.

Just to add to the libm discussion and motivations for libmCS: https://github.com/apache/incubator-nuttx/issues/6767

So my fix is indeed correct algorithmically, but the library itself is not very accurate. This is what makes the tests fail.
For example, 2^3 yields 8.0000000000000089 instead of just 8.0.
My toolchain's library tends to be more accurate, and thus it makes the tests pass.
I will provide a PR to fix the issue, so negative bases will be able to be used with pow(), but a new more accurate library is surely needed.


cookie get on version 0.1.51 is not working on streamlit 1.1.0

Using the example from the main page for cookies,
the cookie is created, but get always return None.
Tested on Chrome and Edge.

I confirm the behavior reported by @vvvlad

Issue fixed on 0.1.52

confirm issue fixed, thank you!


Remove codacy badge

Remove codacy badge to test out auto-publishing of documentation

Sorry not enough sleep. PR to wrong repo.


Revisit using migrations for initial data seeds

There are possible issues with using migrations to add new data, such as if we want to squash migrations in the future and tying the addition of data to a historical model version of when they were added. It could be simpler to reconsider using migration and have a different seeding model like a class yielding some value, etc. That would be more flexible too IMHO.

The Django docs describe how to provide initial data here: https://docs.djangoproject.com/en/3.0/howto/initial-data/
The alternative to data migrations described on that page is using fixtures. I don't remember why I went with migrations instead of fixtures. Probably because writing Python is less annoying than JSON. Or because data migrations are included when the user runs ./manage.py migrate and fixtures require an additional command (which is easy enough to mention in the docs).

@pombredanne , can you please suggest other concrete alternatives. As @haikoschol suggested  we can use fixtures , but is that going solve the problem? In fact I still don't understand the problem.


Allow reuse of host checks for extension authors

Following on the heels of #151, this commit exports the internal logic used to determine if a host is GHES deployment or a tenant.
Exporting these functions allow extension authors like github/gh-copilot to provide tailored experiences consistently with gh.

From @williammartin:

With the addition of normalizeHostname  to IsTenancy and IsEnterprise it looks like maybe there could be a few more test cases like api.tenant.ghe.com  or api.github.com or api.github.localhost


A fairly complete explanation about DetectNet input and output layers

Hi everyone
I'm trying to train DetectNet with my own custom data and so am looking for a guide to rightly customize the network for my purpose, I have images of 320 by 240 and the object width I wish to detect vary from 20 to about 80 pixels. The annotation is like this example:
Car 0.0 0 0.0 221.00 54.00 260.00 91.00 0.0 0.0 0.0 0.0 0.0 0.0 0.0
Car 0.0 0 0.0 207.00 121.00 264.00 175.00 0.0 0.0 0.0 0.0 0.0 0.0 0.0
Car 0.0 0 0.0 147.00 106.00 200.00 154.00 0.0 0.0 0.0 0.0 0.0 0.0 0.0
Car 0.0 0 0.0 1.00 148.00 75.00 208.00 0.0 0.0 0.0 0.0 0.0 0.0 0.0
I've checked DetectNet: Deep Neural Network for Object Detection in DIGITS and from what I have found "DIGITS overlays the image with a regular grid with spacing slightly smaller than the smallest object we wish to detect" (this smallest object I have set to 20 in "Minimum box size (in pixels) for validation set" when creating LMDBs).
Now for training I followed Deep Learning for Object Detection with DIGITS except the fact that I didn't resize my data to 1536 by 1024 because it couldn't fit in my GPU's memory (4GB) even with batch size set to 1. Here it's mentioned: "Note that in order for DetectNet to successfully detect objects in an image, the object size should be between 50×50 and 400×400 px in the input images." I wonder where this number comes from?! and if that's the case why we set  "Minimum box size (in pixels) for validation set" and also the stride which is set to 16 by default.
So, I just copied detectnet_network.prototxt as the network definition but I changed the default x and y sizes (1248 and 384) to my own data size, meaning I changed these line:
79: image_size_x: 1248
80: image_size_y: 384
118: image_size_x: 1248
119: image_size_y: 384
2504: param_str : '1248, 352, 16, 0.6, 3, 0.02, 22, 1'
2519: param_str : '1248, 352, 16, 1'
2545: param_str : '1248, 352, 16'
But to be honest I don't understand the last 3 ones (and Why 352 is used instead of 384?) the other parameters are set as mentioned in Deep Learning for Object Detection with DIGITS and up to now (epoch 300 with batch size 10 and batch accumulation 2) I'm getting very low recall and mAP (1.6). Here is my loss graph (I omitted the parts with very large train loss so that mAP is recognizable)

This the entire loss graph:

I tried to test an image by this network I trained and I got no bounding boxes, however the heat map below (I believe that's what it's called) fits the objects very well,

Sorry that it got too long, but this is the end! Now to summarize my questions:
1. What is the "detector's working area" (the 50 by 50 and 400 by 400 numbers) and how to calculate
and even change it?!
2. what is 'param_str' in lines 2504, 2519, 2545 of detectnet_network.prototxt, which I mentioned
above? and how to change them to fit our data? (this question have also been asked in  #980)
3. Other related points in order to better customize detectNet for other data sets?!
4 and Last. why does the heat map shows the objects but the are no bounding boxes listed?
Thank you so much for your help.

Ok, I tried the thing suggested by jbarker-nvidia in #980 (setting crop_bboxes: false) and it improved the mAP from 1.6 to 14 percent after epoch 400 (though far from desirable accuracy it still shows significant improvement), also I was able to get bounding boxes at inference time. but I still fail to see why the heat map I attached before does not result in detections.
Also as the topic suggests as my main question, I want to find out more about the network so I can further improve my results, and so am I correct in assuming that by setting crop_bboxes to false we invoke random cropping?
My other questions still hold!

@szm2015 some answers to your questions:

The network has a receptive field of 555x555 pixels with a stride of 16 pixels. This means that each cell in the output grid is influenced by 555x555 pixels in the input image.  The 50 and 400 numbers for object size are approximate and come from experience with DetectNet rather than a precise calculation.  For your problem where the object sizes are smaller I would recommend that you increase your training image sizes (perhaps double them) and then use training time cropping to the original image size (320x240) to keep memory size down.  This will bring your target objects in to the range that DetectNet is sensitive to.

The 'param_str' parameters are lists of parameters used by the clustering.pyand mean_ap.py functions found in $NVCAFFE_HOME/python/caffe/layers/detectnet.  The comments in those Python scripts explain the parameters - in short, they are the output grid size and stride and parameters used by the OpenCV function GroupRectangles that is used to cluster the output bounding boxes produced by DetectNet.

If you are not currently using exponential learning rate decay I recommend trying that with a decay rate of 0.99.  Other than that the required customizations are dataset and target object size dependent.  It is possible to reduce the stride of DetectNet, which may help for your problem, but it will also greatly increase GPU memory usage so may not work for you.

The heatmaps you show are actually the predicted offset for the bounding box corner at each pixel.  The coverage heatmap above that in the DIGITS output will show the likelihood that an object is present at each location.  The clustering layer that post-processes the DetectNet output applies a threshold based on the coverage value, so even though the heatmaps show that the network is sensitive to the presence of the objects the coverage value may not be exceeding this threshold.

@jbarker-nvidia Hi, thank you for your complete reply, it really enlightened things for me! (specially reading clustering.py and mean_ap.py)
I did what you said and increased my image size to 2.5 times the previous ones (now my objects would be between 50 and 200 pixels width). I was also using exponential decay from before, with the same stride of 16 and setting the crop_bboxes: false with image x and y set to 320 and 240), I got better results (recall = 72.5, precision = 32, mAP = 23.7) after 300 epochs and I don't think training it more would do any good as it's been roughly the same number from epoch 200. any idea why the precision is so low?
I must add that I trained for another object on this same size images (object width between 60 and 140 pixels) with the same configuration, this time I got a mAP of 94 percent! well to clarify, the first object I mentioned is a car and this second one a bus. what do you think could be the difference? (Note that I didn't have to resize the images this time as the objects width was well within the range, and so I set crop_bboxes: false with image x and y the same as image width and height)

Where can I find definition of layer "DetectNetTransformation"?

[https://github.com/NVIDIA/caffe/blob/caffe-0.15/src/caffe/layers/detectnet_transform_layer.cpp](The code is here)

@szm2015 - what's the size of your dataset? I also had similar problems to yours and having increased the number of training/val images made a significant difference.

for cars I have 243 images with 755 labeled objects (cars) and for bus I have 482 images with 512 labeled objects (buses). the number of labeled objects is less for bus yet it has a far better result, but none the less I will increase car objects to see whether it makes a difference or not.

@jbarker-nvidia
After checking the .py files, i came to a conclusion that you set the dimension to be 352 not 348 to make it a multiple of the stride. Is this correct?

To contribute to the "guide", in my experiments disabling all transformations in the transformation layer helped getting a very good mAP. The used transformations didn't suit my data, so disabling them helped much.
Additionally, @jbarker-nvidia suggestion of using randomly cropped patches helped much in getting better mAP and faster convergence.

@jbarker-nvidia
" For your problem where the object sizes are smaller I would recommend that you increase your training image sizes (perhaps double them) and then use training time cropping to the original image size (320x240) to keep memory size down "
Do I have to change the x and y coordinate values in the label file while resizing the image.
Or just use the resize option in the digits interface?

@varunvv DIGITS will automatically resize the labels too. You need the extent of the coordinates in the label files to match the original images that DIGITS ingests at dataset creation time.

I had a similar problem, I solve by increasing the number of epochs. My net 600 pictures 1024x720, Box~140-170 px. I got mAP after 40 epoch.


Policy for scheduled events could use some tweaking

Seems like there could be some improvements to support the schedule event type.
Given a serverless.yml config essentially like this:
service: myservice
frameworkVersion: "=1.45.1"

functions:
  myfunc:
    events:
      - schedule: rate(1 minute)

The events policies generated look like this:
    {
      "Effect": "Allow",
      "Action": [
        "events:Put*",
        "events:Remove*",
        "events:Delete*"
      ],
      "Resource": [
        "arn:aws:events:*:*:rule/myservice-*-us-east-1"
      ]
    },

But i found this error, on sls deploy:

An error occurred: MyfuncEventsRuleSchedule1 - User: arn:aws:iam:::user/serverless-agent is not authorized to perform: events:DescribeRule on resource: arn:aws:events:us-east-1::rule/myservice-dev-MyfuncEventsRuleSchedule1-1VUFLZR5PHGXL (Service: AmazonCloudWatchEvents; Status Code: 400; Error Code: AccessDeniedException; ...

i changed that portion to the following, to resolve that (added events:DescribeRule and changed the resource value):
    {
      "Effect": "Allow",
      "Action": [
        "events:Put*",
        "events:Remove*",
        "events:Delete*",
        "events:DescribeRule"
      ],
      "Resource": [
        "arn:aws:events:*:*:rule/myservice-*"
      ]
    },

Thanks for writing this generator.

Could you create a pull request and I'll approve it


Coveralls always shows 0% when xcov shows 40% ?

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description

Completing a coverage report with xcov then uploading to coveralls.io results in 0% for all coveralls files and project overall (xcov output will report the correct value though), all looks correct on the fastlane build and its successfully uploaded to coveralls.io
Command executed

Fastlane xcov
xcov(
      workspace: ".xcworkspace",
      scheme: "",
      output_directory: "./fastlane/xcov_output",
      html_report: true,
      only_project_targets: true,
      coveralls_service_name: "travis-pro",
      skip_slack: true,
      ignore_file_path: "./fastlane/.xcovignore",
      coveralls_service_job_id: ENV["TRAVIS_JOB_ID"]
    )

What output are you getting when running the lane that includes that action call? (best with --verbose)


Text in lists can break mdx parser, should be escaped for html safety

docu-notion makes this into

{`Dropbox`}{` will ask whether you want to “Remove `}<book title>{` from your Dropbox account and all devices?” Click “Move out of Dropbox”. If you do not want to see such notices in the future, you can tick the box “Don’t ask me this again”.`}

Instead, the text should be encoded so that it doesn't mess up the html parser.
Q: what if there is content in there that we do want to be parsed?

It isn't easy to know when we want to to do this or not.
For now, I've made it simply change < to < and < to > unless it is a code block.
But we could do fancier things in the future like not escape it if it has a matching closing tag or is a self-closing tag.
We could also not escape if the text is wrapped in backticks (`).


Add cloudflare:request-context utility

This mechanism uses async context propagation to store references to the request, env, and ctx such that they can be retrieved without having to pass those explicitly through various layers. This is helpful, of instance, when using third party libraries and you need to access something like a configured binding. One could use AsyncLocalStorage directly for this but there are use cases where we do not necessarily want to require enabling nodejs_compat. It also reduces common boilerplate.
// (does not require nodejs_compat to be enabled)
import getRequestContext from 'cloudflare:request-context';

function doSomethingWithCtx() {
  const [ req, env, ctx ] = getRequestContext();
  // do something...
}

export default {
  async fetch(req) {
    // do something that eventually leads to doSomethingWithCtx....
  }
}

The alternative using AsyncLocalStorage would be:
// (requires nodejs_compat to be enabled)
import { AsyncLocalStorage } from 'node:async_hooks';
const reqCtx = new AsyncLocalStorage();

function doSomethingWithCtx() {
  const [req, env, ctx] = reqCtx.getStore();
  // do something...
}

export default {
  async fetch(req, env, ctx) {
    return reqCtx.run([req, env, ctx], () => {
      // do something that eventually leads to doSomethingWithCtx
    });
  }
}

/cc @dario-piotrowicz

@irvinebroque ... just a heads up on this. The request for this came from @dario-piotrowicz ... the basic idea is to leverage async context propagation to ensure that the request, env, and ctx passed in with a fetch handler (es module syntax only, only the older addEventListener syntax) can be accessed even if the values are not explicitly passed around. This is helpful, for instance, when using third-party components that are not workers aware but we still need to be able to access things like bindings or header values. A worker can accomplish the same basic thing using AsyncLocalStorage directly but that requires that nodejs_compat be enabled. Later, once the standardized AsyncContext is added to the language that could be used but (a) we don't have a timeline on when that will arive and (b) this still saves a bit of boilerplate that would be needed, so I think the new api makes sense to support.
Each individual exported handler type would need to store it's context. I've included context propagation for fetch, scheduled, tail, and test exported handler types.
Still need to add tests to this. But before going much further I want to make sure there are no objections to adding this api.

Can we put together a few examples that highlight the boilerplate this reduces?
Would like to get a chance to experiment with this a bit with this first.

Added a couple examples in the PR description

@dario-piotrowicz — would be curious to understand examples from you on where passing down a context, or passing down request, ctx, env` is a prohibitive burden. Not opposed, understand the convenience, just curious for more examples of current pain.

@dario-piotrowicz — would be curious to understand examples from you on where passing down a context, or passing down request, ctx, env` is a prohibitive burden. Not opposed, understand the convenience, just curious for more examples of current pain.

My use case is with our Next.js adaptor, there an API that would allow users to get hold of their cf and ctx objects (potentially + bindings as well) is missing and quite needed (we've been thinking of implementing a solution in our adapter and have also received a PR from a community member) but after chatting with @jasnell and seeing that a runtime alternative might be feasible that does sounded like the cleanest approach.
So I wouldn't say that passing things down would be a prohibitive burden but we it might not be the cleanest approach (and a very next-on-pages specific one).
I don't have other examples but I would imagine that even complex workers could quite benefit from such a runtime API instead of requiring the users to potentially have to drill down their cf, ctx and env objects to every place that might need it.

This would also be very convenient for Shopify Hydrogen/Oxygen. Currently, we need to pass down request headers, waitUntil and env (to access an internal utility service binding) in multiple places.
Even if we had the nodejs_compat enabled, we'd still need to pass it all down until a point where we can call asyncLocalStorage.run(...) and share access to that instance of the storage (or ask the user to do this manually but it might be confusing).
A simplified example for us would be something like the following:
// Entry file controled by the user
import build from './app-build/...';
import {createRequestHandler} from '.../oxygen';
import {createGraphQLClient} from '.../hydrogen';

export default {
  async fetch(req, ctx, env) {
    const waitUntil = (p) => ctx.waitUntil(p);

    const gqlClient = createGraphQLClient({
      waitUntil, // This could be removed
      cache: await caches.open('hydrogen'),
      someRequiredProperty: env.SOME_ENV_VAR,
      someRequiredHeader: req.headers.get('xyz'),  // This could be removed
    });

    const handleRequest = createRequestHandler({
      build,
      // We could also remove env and waitUntil here
      context: {gqlClient, env, waitUntil}
    });

    return handleRequest(req);
  }
}

Internally, gqlClient is manually caching POST responses to a GraphQL API and implementing SWR. For this, we need waitUntil and some headers that come in the request to avoid API rate limits.
We struggle at times to add utilities etc. because we need to make breaking changes to pass down extra headers or anything like this. It would be very simple if we had access somehow to the proposed getRequestContext.

ok, I think given the feedback there's more than enough justification to move forward on this. I'll get this PR updated and completed with tests and a few other bits and will get it ready to land.

Given that AsyncContext has been Stage 2 for 6 months — are we close enough to it reaching Stage 3 that we could provide an implementation of it in Workers, rather than exposing an API that is specific to Workers in cloudflare:request-context? Is the AsyncContext proposal stable enough to go that route?
const reqCtx = new AsyncContext();

function doSomethingWithCtx() {
  const [req, env, ctx] = reqCtx.getStore();
  // do something...
}

export default {
  async fetch(req, env, ctx) {
    return reqCtx.run([req, env, ctx], () => {
      // do something that eventually leads to doSomethingWithCtx
    });
  }
}

Given that AsyncContext has been Stage 2 for 6 months — are we close enough to it reaching Stage 3 that we could provide an implementation of it in Workers, rather than exposing an API that is specific to Workers in cloudflare:request-context? Is the AsyncContext proposal stable enough to go that route?
const reqCtx = new AsyncContext();

function doSomethingWithCtx() {
  const [req, env, ctx] = reqCtx.getStore();
  // do something...
}

export default {
  async fetch(req, env, ctx) {
    return reqCtx.run([req, env, ctx], () => {
      // do something that eventually leads to doSomethingWithCtx
    });
  }
}

I have no idea.... I'd be curious to hear @jasnell's opinion, personally I think that AsyncContext will still take some time to be finalized (and be part of the specs) and that no real assumptions can be made right now...
If we're opposed to this runtime api we can indeed implement what you suggested using AsyncLocalStorage that'd be feasible, the only issue being that it forces nodejs compatibility which requires extra steps from users and it not as convenient as James' proposed solution.
But anyways I totally get your reasoning (and indeed I'd also prefer a solution that doesn't require us to have any non-standard Cloudflare specific runtime API), if we add this runtime API then later even if other standard alternatives like AsyncContext are available we'd still need to maintain this proprietary API, so it is not a light decision to make....
Anyways I do think that this would still indeed be pretty useful/convenient for the foreseeable future, but if we think that it's too non-standard and that it unnecessary pollutes the runtime I totally understand.

are we close enough to it reaching Stage 3 that we could provide an implementation of it in Workers, rather than exposing an API that is specific to Workers in cloudflare:request-context? Is the AsyncContext proposal stable enough to go that route?

We wouldn't provide the implementation of AsyncContext, we're largely waiting on V8 to provide that. Given the current progress I would anticipate seeing it around first or second quarter next year at the absolute earliest, so not too far off, but it's TC-39 so it could end up taking longer.

The other part of using AsyncContext that adds complexity here is that, like AsyncLocalStorage, it still requires that the AsyncContext is available to all of the user code that needs it in order for it to be accessible. Alternatively, an import is accessible everywhere without explicitly passing anything around.

I should add I'm also perfectly fine if we decide to wait for AsyncContext to be finished and not add this API.

I think me and @jasnell are totally on the same page, I think it would be a nice addition and it would be very convenient even after (/if?) AsyncContext makes it into the language (no need for manual setup on the user/framework's side).
When (/if?) AsyncContext makes it into the language we could use that as @irvinebroque suggested which would be more convenient than the current potential AsyncLocalStorage solution but not as convenient as James' API, so an in-between I'd say, the advantage is that it'd be totally specs compliant.

Think we're close to something, let's marinate on this and figure out what we want to do start of next week. Don't want to be blocker / limiting factor

Ok, will keep this in draft then and will let it simmer. Let's revisit later once we have more clarity. Just to note here tho, TC-39 met this week and reviewed the status of AsyncContext and it is remaining at stage 2 for the time being as far as I can tell.

This takes away the application's ability to understand and control what libraries have access to the environment

I agree that this is absolutely the strongest argument against introducing this.

If we're concerned about this being available by default (and therefore giving all libs access to the environment), but agree that this could be a useful feature in certain circumstances (e.g. Next.js, and more generally, React), what about opting into this with a compatibility flag?

Not sure about a compatibility flag but I'm wondering about whether we can somehow allow list which modules in a worker bundle are allowed to access it.

That would be pretty tricky. I'm often using a bundler which will split modules for me arbitrarily, and I wouldn't have any easy way to associate that back to which original modules I'd want to grant access from.

Ok, given the concerns that @kentonv raised here, I think it's going to be a more tractable approach to require workers to explicitly use ALS (and eventually AsyncContext) for this. For example...
globalThis.requestContext = new AsyncLocalStorage();

export default {
  async fetch(req, env, ctx) {
    return globalThis.requestContext({env,ctx}, () => {
      // do whatever.
    });
  }
};

With the requestContext stored on globalThis, any modules would have the ability to access it but they wouldn't have to pass the requestContext variable down explicitly everywhere (potentially through library code paths the user code cannot modify/control).
Given that, I'm going to go ahead and close this.


Task :app:lintAnalyzeDebug FAILED when gradle build

When building android gradle giving the following error.
==> Task :app:lintAnalyzeDebug FAILED.

What went wrong:
Execution failed for task ':app:lintAnalyzeDebug'.

Could not resolve all files for configuration ':app:debugAndroidTestCompileClasspath'.
Failed to transform out.aar (project :react-native-community_netinfo) to match attributes {artifactType=android-lint-exploded-aar, com.android.build.api.attributes.AgpVersionAttr=7.4.2, com.android.build.api.attributes.BuildTypeAttr=debug, com.android.build.gradle.internal.attributes.VariantAttr=debug, org.gradle.usage=java-api}.
java.io.IOException: Unable to delete directory<EMAIL_ADDRESS>Failed to delete some children. This might happen because a process has files open or has its working directory set in the target directory.
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-

Gradle specifications
    kotlinVersion = "1.8.10"
    buildToolsVersion = "34.0.0"
    minSdkVersion = 24
    compileSdkVersion = 34
    targetSdkVersion = 34
    ndkVersion = "25.1.8937393"

android/build.gradle:
classpath("com.android.tools.build:gradle:7.4.2")
gradle-verison: distributionUrl=https://services.gradle.org/distributions/gradle-7.5.1-all.zip
Versions

Android:
react-native-netinfo:@react-native-community/netinfo": "^11.3.2
react-native:^0.72.10
react:^18.3.1

Same issue for me. my version is 11.3.2

this does not seem related to netinfo, it appears to be a local build failure


SNC version

Hi guys
Is there a specific reason that this bundle is using 1.1.x-dev of the snc/redis bundle and not 2.0?
I was running the 2.0.0-rc1 version of oro platform fine but in the last 10 days, a requirement for this bundle was added https://github.com/orocrm/platform/commit/62371cfed0de443cf57df15aa693ce19ac8b73e0
Cheers
Luke

Hi
I think because at the moment we don't have plans to switch snc/redis to 2.0.

Hi @mkudelya
What are your reasons for not updating to 2.0.0?  It is the recommended branch for Symfony2.7+ and the only branch that will work with Symfony3.

Hi @LRotherfield
I have read 2.0 UPDATE.md and this version are fairly minor changes. We now have quite a busy schedule and i think we will consider this update when we move to the next major version of symfony.

@LRotherfield,  I am now closing this issue as it has been inactive for a while. Please, feel free to reopen it if you have any questions.


Remove Unneccessary Brackets

This bug may have been repeated countless times, but here's a fix for just the first occurrence I noticed.
Fixes this JavaDoc rendering bug:

Those brackets are actually intended.
It renders absolutely fine with the official JavaDoc tool.
This is a new feature of JavaDoc 16 which was added here.
This is, actually, an Intellij bug, which means such bug report should be reported to JetBrains instead.


IteratorChain

Feature request
I propose the addition of a foundational chain feature, namely, the IteratorChain to LangChain. Unlike a convenience function, this feature is intended to enhance the flexibility and usability of LangChain by allowing it to handle collections of inputs for any existing chain, propagating them sequentially or asynchronously.
from langchain.chains import IteratorChain, LLMChain

llm_chain = LLMChain(...)
iterator_chain = IteratorChain(llm_chain)

inputs = [{"text": "Hello"}, {"text": "World"}]
outputs = iterator_chain.run(inputs)

In the current LangChain framework, when dealing with lists or collections of inputs, developers are required to manually loop through the input list and call the run method for each item. This approach not only results in more code but also creates challenges with LangChain's features like LangSmith logging, especially when lists are dynamically generated from previous chains.
The IteratorChain would encapsulate this looping, resulting in cleaner code and better integration with LangSmith logging and other LangChain features.
Motivation
Many real-world use-cases involve the processing of collections of similar inputs. In its current form, LangChain requires developers to manually iterate over such collections and apply the underlying chain to each item, which can lead to inefficiencies and less intuitive code.
This feature proposal stems from the need to improve the processing of collections of inputs, making the code more readable, efficient, and better integrated with the LangSmith logging feature.
Your contribution
I'm prepared to contribute to the development of this feature, if decided that it is a good addition and is not already possible using existing capabilities.

The proposed IteratorChain could address a current issue I'm having when dealing with nested lists of inputs. Let's consider the current SequentialChain setup below:

The proposed IteratorChain could address a current issue I'm having when dealing with nested lists of inputs. Let's consider the current SequentialChain setup below:
SequentialChain(
    chains=[
        ChainA(input_variables=["inputA"], output_key="outputA"),
        TransformChain(input_variables=["outputA", "auxiliary_input"], output_variables=["outputB"], transform=process_A_to_B),
        TransformChain(input_variables=["outputB", "auxiliary_input"], output_variables=["outputC"], transform=refine_B_to_C),
        TransformChain(input_variables=["outputC", "auxiliary_input"], output_variables=["final_output"], transform=process_C_to_final)
    ],
    input_variables=["inputA", "auxiliary_input"],
    output_variables=["final_output"]
)

In this setup, process_A_to_B and refine_B_to_C are both creating lists of inputs for further chains. However, these lists of inputs are currently not being processed elegantly. We have to loop manually over the list and call the underlying chain for each item. This not only leads to cumbersome code, but also hinders proper interaction with the LangSmith logging feature.
def process_A_to_B(params) -> List[Dict[str, Any]]:
    ...
    for item in items:
        chainB = SomeChain(...)
        output = chainB.run({"input": item, "auxiliary_input": auxiliary_input})
        ...
    return {"outputB": outputs}

def refine_B_to_C(params) -> List[Dict[str, Any]]:
    ...
    for item in items:
        chainC = AnotherChain(...)
        output = chainC.run({"input": item, "auxiliary_input": auxiliary_input})
        ...
    return {"outputC": outputs}

The addition of an IteratorChain feature would address these issues. It will encapsulate the manual loop and make the list handling process more intuitive and efficient, ensuring proper integration with LangSmith logging and other LangChain features.

I think there may be an example using SequentialChains. I'd love feedback if anyone has experience with this.


Hard to find things hiding exactly under other things

Description
Our job is to make Ravine 1 touch the lake. On
https://www.openstreetmap.org/edit#map=20/42.12078/-87.73522
we cannot find the lake.
Yes, it is hiding underneath
https://www.openstreetmap.org/way/33869646
And yes, if we temporarily detatch and move a node from the latter, the
lake polygon is revealed.
But we need to click a node in the way first, and see if "Detach" is
available in the menu... only then do we get a hint that there is more
to the way then what meets the eye.
Yes, one could say there are the colored outlines... But we click on it
only to find one...
Anyway, compare Vespucci: it always wants to know what of several piled
up features the user intends to select.
But with iD never mind selecting: even being able to know if there is
more than one item where the user has made their selection is hard.
(Yes, we finally made Ravine 1 touch the lake.)
Screenshots

Michiganders have glued the administrative boundary to the lake area, presuming that cities end at the lakefront. You can tell that the boundary has been glued to something because its vertices are gray instead of white. A linear feature such as a boundary way always takes visual precedence over an area because – as you mention – you can select the area by clicking its margin. (If the boundary way were glued to something linear like a roadway, the roadway would appear instead, but #9866 causes it to be unselectable.) Regardless of what you see, extending the waterway to the boundary also connects it to anything that the boundary is glued to.

Oh, and in the above picture, if we put our mouse upon the yellow fringe, we immediately see in the left panel "Beach".
But if we put our cursor on the blue fringe, nothing happens... for about two seconds.
By which time we probably have moved our cursor elsewhere, having given up on thinking the blue item is selectable.
Perhaps this is due to the enormous size of the blue item compared to the yellow item.

Perhaps this is due to the enormous size of the blue item compared to the yellow item.

Yes, this is why.


Add support for Security Group Adoption

This fix allows adoption of existing security groups. Tests have been successful in at least two test scenarios: adopting an existing SG and then modifying its properties, trying to adopt an invalid SG.
I've also ran a few additional tests with the modified controller to be sure that existing functionality didn't break:

Create a new SG
Modify this SG
Delete this SG

Issue #, if available: https://github.com/aws-controllers-k8s/community/issues/1946
Description of changes:
The existing logic doesn't allow for adoption of existing SecurityGroups because spec.Name is a required property for creation but the aws SDK returns GroupName. The deepCopy in sdkFind then is not enough because of the different names.
By copying SecurityGroup GroupName into spec.Name as part of the sdk_read_many_post_set_output we solve this issue.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/ok-to-test

/retest

@nnbu - I rebased against the latest release. Changes seem to be ready for merge


Not clear which one should I choose to build

If I am working on linux platform and would like to build an exe file for windows (use linux to generate windows exe file). Which one shall I choose, the one with ‘linux' as post-fix or with 'win32/64' as post-fix?

Win 👍


feat(ui): auto reload coverage iframe after test run

Description

Closes https://github.com/vitest-dev/vitest/issues/5057

I tested a simple iframe reloading and tested by pnpm -C examples/basic test:ui --coverage:
Show demo
스크린캐스트 2024-02-20 13-35-10.webm

But actually I'm worrying that there might be some race condition here:
https://github.com/vitest-dev/vitest/blob/a479115913c6428dd28ed8339b9b80e7ce3ccc06/packages/vitest/src/node/core.ts#L529-L530
If reportCoverage takes significant time, then reloading iframe during onFinished might end up fetching old coverage html.
To avoid this race condition, it might be necessary to either:

add new reporter hook (like onReportCoverageFinished) just for this, or
move up reportCoverage before onFinished (this would likely mess up terminal output for coverage text reporter) or
provide a dedicated "iframe reload" button on UI, so users can at least reload it manually.

I'm leaning towards the 1st option, but what do you think?
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[ ] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Using the html reporter from Istanbul for UI has always been quite hacky solution. In long term it would be best to create new custom coverage reporter that extended the html one. This reporter would integrate with browser through web sockets.

Using the html reporter from Istanbul for UI has always been quite hacky solution. In long term it would be best to create new custom coverage reporter that extended the html one. This reporter would integrate with browser through web sockets.

That's an interesting idea, but it feels a bit overkill? With the custom reporter, we can have access to onEnd to notify UI, but then that would still require managing websocket rpc and need adding some reporter hook at the core level.
For now, I went with adding onFinishedReportCoverage reporter hook.

I think it's more of a bug fix than a feature.


[Enhancement 394]  fixed some golint warnings

I have deleted my old PR #396 since too many merge conflicts were occurring.
I have fixed some warnings as addressed by the issue #394. I have generated PR just to make sure that nothing is broken till now.
I have followed the convention as suggested by @jlewi .

This change is

Coverage increased (+0.05%) to 44.516% when pulling 244b75bc4178c71f32eca5bc68c7b6d0b3edba91 on AK-ayush:enhancement-394 into a36b350e04f92c8e67013c3c9ff5a0f0ee2fecd9 on kubeflow:master.

@AK-ayush Thank! Please rebase your branch :)

@ScorpioCPH  I tried to rebase branch but there are too many conflicts. Can you suggest me some other alternative for rebasing.

@AK-ayush Hi, checkout new branch from master (or reset --hard to ignore local changes), them re-run the golint script?

thanks @ScorpioCPH
I will checkout a new branch from master and generate a new PR.


Site references artifacts that don't exist due to transfer of ownership

At http://www.clara-rules.org/docs/firststeps/, the instructions for adding Clara to a project list [com.cerner/clara-rules "0.12.0"] as the artifact, but that doesn't exist anywhere.
Updating to 13.0-RC4, however, isn't easily done because as far as I can tell, those API docs aren't available at http://www.clara-rules.org/apidocs/*
I'd recommend either publishing the given artifact, or updating the API docs to 13.0-RC4.

@KevinGreene releases prior to 13.0-RC4 are under org.toomuchcode, not com.cerner.  See https://clojars.org/org.toomuchcode/clara-rules
We recently moved clara-rules to Cerner's corporate GitHub organization, hence the change.  There is a blog post on this at http://engineering.cerner.com/blog/clara-rules-joins-cerner-open-source/ We'll look at fixing these inconsistencies.

@WilliamParker Yup, understood!
Perhaps I wasn't as clear, but the issue I have is that the introduction documentation is wrong. It references [com.cerner/clara-rules "0.12.0"], but as you mentioned that doesn't exist.
Originally I was going to just update _config.yml to point to the correct release, but I think it's confusing to point to one version in the docs, but link to API docs for a different version.
However, it seems the API docs aren't automatically generated with each release, as http://www.clara-rules.org/apidocs/0.12.0/clojure exists, but http://www.clara-rules.org/apidocs/0.13.0-RC4/clojure does not.
So, I didn't want to update the config.yml, but as a result the "first steps" someone takes with Clara is bound to be an error message informing them that [com.cerner/clara-rules "0.12.0"], the suggested version on the website, doesn't exist.

I hadn't re-generated the Clojure or JavaDocs for the 0.13 series since I thought of them more as release candidates rather than releases, but it probably makes sense to go ahead and do so given the transfer of the project.
Note that there is a gen_api_docs script in this project (See https://github.com/cerner/clara-site/blob/gh-pages/gen_api_docs.sh), which given the path to clara-rules and a version (e.g. 0.13.0-RC4), will generate the docs and copy them to the right place in the clara-site project, so they can then be simply committed and visible on the site. Once that's done, changing the _config.yml version to 0.13.0-RC4 will get everything pointed at the right place.
I'm happy to do this myself, but wanted to share this the history and presence of the script with the group.

Alright, I went ahead and generated the doc for 0.13.0-RC4 and updated the config accordingly, which is now reflected on the site. Thanks for letting us know about the discrepancy!

Also, closing the issue now since this is taken care of. We can re-open if I'm missing anything.

Thanks for the quick fix! As far as I can tell everything looks good.


Changing the highlight group of a DevIcon doesn't affect the icon colors of nvim-tree

I have a color scheme (.vim) and I'm trying to set the colors there (instead of hard coding this in my config).
If I call :hi DevIconLua guifg=#ff0088 as a command it seems to be working fine. However, when I set it in my theme file it doesn't.  For comparison when I set hi NvimTreeFolderIcon guifg=#ffffff in my theme file for example, it works.
NOTE: This is in reference to https://github.com/kyazdani42/nvim-web-devicons/issues/101#issuecomment-998319192

Hi :)
1st could you try adding an exclamation mark to your highlight in your colorscheme to see if it changes something ? I don't think it'll resolve this if the colorscheme applies before nvim-web-devicons sets it's colors on colorscheme change though.

Hum forget it, just tried it, the highlight gets overriden by nvim-web-devicons.

should be working now, i made a hack around this for now


need a way to suppress errors in individual commands?

There's a good chance we don't need this, but I want to think about it. In shell, the way you suppress the exit status of a command is something like foo || true. The same works in duct using .orthen(). But in both cases it's awkward as hell. Maybe we should just let you specify status=0 at the command level?
On the other hand, has anyone ever needed this ever?

Folding into https://github.com/oconnor663/duct/issues/6.


Synchronize common aspects of developer guides

There are currently 3 or 4 primary places that new contributors can go for basic HoloViz project set-up instructions:

hvPlot developer guide
Panel developer guide (HoloViews points here too)
HoloViz contributing guide
HoloViz contributing guide > Operating guide > Pyctdev

I think these instructions should be synchronized whenever possible, and only diverge if there is a package-specific reason to do so.
Here are the primary steps from each source listed above:
Panel:
conda install -c pyviz "pyctdev>0.5.0"
doit env_create -c pyviz/label/dev -c conda-forge --name=panel_dev --python=3.9
conda activate panel_dev
doit develop_install -c pyviz/label/dev -c conda-forge -c bokeh -o build -o tests -o recommended
pre-commit install

hvPlot:
conda install mamba -c conda-forge
conda create -n hvplot_dev
conda activate hvplot_dev
conda config --env --append channels pyviz/label/dev --append channels conda-forge
conda config --env --remove channels defaults
mamba install python=3.x pyctdev
doit develop_install -o tests -o examples --conda-mode mamba
pre-commit install

HoloViz Contributing:
conda install -c pyviz/label/dev "pyctdev>0.5.0"
doit env_create -c channel1 -c channel2 --name=dev-env --python=3.x
conda activate dev-env
doit develop_install -c pyviz/label/dev -c conda-forge -o tests -o examples

HoloViz Operating > Pyctdev:
conda install -c pyviz/label/dev pyctdev
doit env_create -c pyviz -c conda-forge --python=3.8 --name=my_dev_env
conda activate my_dev_env
doit -c pyviz -c conda-forge develop_install -o tests -o examples

The HoloViz Contributing guide contains a critical tip:

The reference sources to find out which commands to run to install the correct dependencies and to execute the tests and other tasks are the Github Actions Workflows files that you can find in the .github folder of each repository.

And while that is quite important, the CI files can be quite confusing for non-core HoloViz contributors, as they have to cherry-pick which commands to run locally.
Also, I think the nbsite section on the HoloViz Operating guide might be the only source of guidance on building the docs, other than the CI workflows.

What would be a common set of basic instructions?
Should we recommend that people use pyviz or the pyviz/label/dev channel?
Should we recommend the use of mamba?
Should we stop suggesting the use of pyctdev?

Somehow I missed this message, which happens to be quite related to the issue I opened on pyctdev the day after this one was posted https://github.com/pyviz-dev/pyctdev/issues/104.
My take on this at the moment:

I am in favor of recommending contributors to install their dependencies with pip. I think that now pip has a dependency solver (albeit I believe not as sophisticated as conda's) people are less likely to get into trouble, notwithstanding the fact that most packages are now distributed as wheels. We could still indicate that if they want to use conda they can do it via pyctdev, pyctdev providing this very nice feature of collecting the dependencies that need to be installed. So we'd recommend something like python -m venv .venv, source activate .venv/bin/activate and pip install -e [tests,examples].
Whatever we suggest, it must be tested on CI.
Whatever we suggest, someone must be in charge of maintaining that documentation up-to-date. Now the HoloViz group has more contributors, I think we should be able to distribute that job pretty well without it becoming a burden.
I think we should focus first on improving the dev instructions for testing as it's the most common task contributors may be willing to tackle. Next would be building the docs. I think building packages is pretty rare, that's low priority.


How to show the downregulated marker genes by sc.pl.rank_genes_groups?

[ ] Additional function parameters / changed functionality / changed defaults?
[ ] New analysis tool: A simple analysis tool you have been using and are missing in sc.tools?
[ ] New plotting function: A kind of plot you would like to seein sc.pl?
[ ] External tools: Do you know an existing package that should go into sc.external.*?
[✔] Other?

Hello Scanpy,
I'm wondering whether it is possible to show the downregulated marker genes by sc.pl.rank_genes_groups() or other functions, so that we can export the gene list for further GSEA analysis?
I know sc.pl.rank_genes_groups_dotplot can show the downregulated genes by change n_genes to negative numbers, but it didn't work in sc.pl.rank_genes_groups().
Thanks!
Best,
YJ

solved. increase the head() number to the number of input genes.


Did the repo name change from ng-quill to ngQuill?

My bower_components directory has both now and my index.html and Gulpfile are all sort of confused.

yeah, i removed it, because the git conventions changed in the time... so repos should be written in kebap-case (no uppercase letters)
SO ng-quill is the correct and new name :)

Sorry I'm still a little confused. So I just rm -rf'd my bower_components folder and ran bower install ng-quill#1.5.4. This is the output:
> ~/project (dev) $ bower install ng-quill#1.5.4
bower ng-quill#1.5.4        not-cached https://github.com/KillerCodeMonkey/ngQuill.git#1.5.4
bower ng-quill#1.5.4           resolve https://github.com/KillerCodeMonkey/ngQuill.git#1.5.4
bower ng-quill#1.5.4          download https://github.com/KillerCodeMonkey/ngQuill/archive/1.5.4.tar.gz
bower ng-quill#1.5.4           extract archive.tar.gz
bower ng-quill#1.5.4      invalid-meta for:/var/folders/7y/dtxc4j3x3s76312w320yqrtmzsqbnh/T/ziggajt1/bower/10aff419f8a1f4fb06efb4ee1552cfb8-19263-i5bE0S/bower.json
bower ng-quill#1.5.4      invalid-meta The "name" is recommended to be lowercase, can contain digits, dots, dashes
bower ng-quill#1.5.4      invalid-meta The "main" field cannot contain minified files
bower ng-quill#1.5.4          mismatch Version declared in the json (1.5.3) is different than the resolved one (1.5.4)
bower ng-quill#1.5.4          resolved https://github.com/KillerCodeMonkey/ngQuill.git#1.5.4
bower quill#0.20.1              cached https://github.com/quilljs/quill.git#0.20.1
bower quill#0.20.1            validate 0.20.1 against https://github.com/quilljs/quill.git#0.20.1

And what ends up in my bower_components folder is /ngQuill
So is ng-quill really the correct name? If so why am I getting ngQuill?

From a different project (we keep our bower components in a separate artifact that the main project downloads for version control purposes) it looks like I'm getting both dirs:
project (dev) $ bower install ng-quill#1.5.4 --save
bower ng-quill#1.5.4            cached https://github.com/KillerCodeMonkey/ngQuill.git#1.5.4
bower ng-quill#1.5.4          validate 1.5.4 against https://github.com/KillerCodeMonkey/ngQuill.git#1.5.4
bower keycloak        extra-resolution Unnecessary resolution: keycloak#1.8.1
bower ngInfiniteScroll extra-resolution Unnecessary resolution: ngInfiniteScroll#1.2.1
bower angular-sanitize extra-resolution Unnecessary resolution: angular-sanitize#^1.5.3
bower angular-cookie   extra-resolution Unnecessary resolution: angular-cookie#^4.1.0
bower Autolinker.js    extra-resolution Unnecessary resolution: Autolinker.js#~0.26.0
bower angular-ui-select extra-resolution Unnecessary resolution: angular-ui-select#^0.19.4
bower ngQuill#1.5.4              install ngQuill#1.5.4

ngQuill#1.5.4 bower_components/ngQuill
├── angular#1.5.9
└── quill#0.20.1

project (dev) $ git status
On branch dev
Your branch is behind 'origin/dev' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   bower.json
	deleted:    bower_components/ng-quill/.bower.json
	deleted:    bower_components/ng-quill/.gitignore
	deleted:    bower_components/ng-quill/LICENSE.txt
	deleted:    bower_components/ng-quill/README.md
	deleted:    bower_components/ng-quill/bower.json
	deleted:    bower_components/ng-quill/karma.conf.js
	deleted:    bower_components/ng-quill/src/ng-quill.js
	deleted:    bower_components/ng-quill/src/ng-quill.min.js
	deleted:    bower_components/ng-quill/test/ng-quill-component.spec.js
	deleted:    bower_components/ng-quill/test/ng-quill-config.spec.js
	modified:   bower_components/ngQuill/.bower.json
	modified:   bower_components/ngQuill/.gitignore
	modified:   bower_components/ngQuill/LICENSE.txt
	modified:   bower_components/ngQuill/README.md
	modified:   bower_components/ngQuill/bower.json
	modified:   bower_components/ngQuill/src/ng-quill.js
	modified:   bower_components/ngQuill/src/ng-quill.min.js


Issue #218 Add horizontal scrolling logbook table

It still doesn't work. There is no horizontal scroll for all the columns. Now there is a small scroll, but it doesn't cover all the values.
The horizontal scroll in the statistics tables works correctly.
Checked on tablet and mobile.

oh, you mean that even on mobile devices it should show the full logbook table withou hiding the columns?

Exact. Same as in statistics tables, all columns are shown and you can scroll horizontally


Develop naming scheme for data-driven classes

Data driven classes need unique names and synonyms.  They can keep non-unique shorter context specific names where there are clear use-cases for these.
Rough draft

Node only automatically gets a name if it has a preferred alias that is not some simple derived thing (e.g. RNAseq 058-085)
Include some name transformation rules that transform some names taking into account major branches
append: 'of {brain region} {{species})'

We need a similar system for symbols - keeping short names, but with context.
e.g.
L2/3 IT ->
label: L2/3 intratelencephalic projecting glutamatergic neuron of primary motor cortex (Mus musculus)
symbol: L2/3 IT MOP (Mus)

This is a great idea. AIBS has a nomenclature standard for data sets, so maybe there is a way to coordinate at some level if these are interacting.
BTW, I think 'IT' in the example is "intratelencephalic-projecting" -- this demonstrates the need for this schema.

This is a great idea. AIBS has a nomenclature standard for data sets, so maybe there is a way to coordinate at some level if these are interacting.
BTW, I think 'IT' in the example is "intratelencephalic-projecting" -- this demonstrates the need for this schema.

Add symbols to BDS classes - recipe:
stem = 'preferred_cell_set_alias' or 'additional_cell_set_alias'[0] if  'preferred_cell_set_alias'  is null
symbol = stem + ' ' + brain_region_abbv + ' ' + species_abbv
brain_region_abbv & species_abbv will be recorded in  taxonomy_details.yaml for each taxonomy.
this will be used to populate  columns in dosdp_tsv driving a symbol recipe in the DOSDP.

[ ] Extend schema for  taxonomy_details.yaml to add new keys @dosumis
[ ] Extend dosdp mega template to add symbol recipe @dosumis
[ ] Write pipeline code to populate dosdp tsv. @hkir-dev
[ ] Add abbreviations to YAML @shawntanzk

First 2 steps done.  Passing off to @hkir-dev for next step.

Third step is done.
@shawntanzk can you update added dummy abbreviations:
https://github.com/obophenotype/brain_data_standards_ontologies/blob/d36de2cfa35dd8f0024188187e3d61a65485c2d8/src/dendrograms/taxonomy_details.yaml#L10
https://github.com/obophenotype/brain_data_standards_ontologies/blob/d36de2cfa35dd8f0024188187e3d61a65485c2d8/src/dendrograms/taxonomy_details.yaml#L14

@hkir-dev couldnt write on that branch so i created one off it - https://github.com/obophenotype/brain_data_standards_ontologies/blob/abbv/src/dendrograms/taxonomy_details.yaml
happy for you to merge to whichever is the correct branch.
Thanks :)

Updated in the banch

Wonder how we would handle other abbreviations (eg projections such as IT, ET) @dosumis

Wonder how we would handle other abbreviations (eg projections such as IT, ET) @dosumis

We keep them as-is.  The aim here is to have something close to the symbols defined by the Allen/BICCN but to extend to include scope.  We should also consider adding symbols in CL for grouping class names from the nomenclature.

Implementation completed and merged: https://github.com/obophenotype/brain_data_standards_ontologies/pull/131


Support for Single Kubernetes Cluster Mode

Feature Request

What should the feature do:
Crossplane defines the concept of a workload and resources today. Today, a workload is a schedulable unit that includes a payload (config YAML) that can be deployed to a target Kubernetes cluster. This model enables deployments across different clusters, and clouds.
However, if your goal is use a single Kubernetes cluster only this model gets in the way. We should consider supporting a single cluster mode for Crossplane. In this mode we do very little with workloads and scheduling of workloads, and instead focus only on resource claims, classes and their associated controllers.
If we consider the Gitlab scenario in a single cluster mode, they could run their helm chart as is against a Kubernetes cluster, and use the Postgres, Redis and other APIs provided by crossplane without having to do anything with workloads.
What is use case behind this feature:
Customers that want to run crossplane on a single Kubernetes cluster.

@bassam In recent discussions around supporting Gitlab we mentioned updating the Gitlab Helm chart to generate Crossplane workloads and resources. I wonder if we could maintain that same pattern in the proposed single cluster mode by adding a resource that satisfies the KubernetesCluster resource claim with a reference to the cluster upon which Crossplane is running (rather than by spinning up a hosted Kubernetes cluster)?

Yeah a short-circuited KubernetesCluster could work, however it still requires wrapping YAML in a workload. I was thinking about a mode where I don't want to use the workload scheduling features of crossplane, just the resource abstraction/controllers.

On rereading this issue, I feel like this is a pretty common use case that we support today. I'm going to close this - let me know if I'm missing something.


Improve test framework - remove test_console.rb

It's better to remove test_console.rb because we don't have to maintain extra patches for tests. I did two things.

change the place where INTERNAL_INFO is generated as a json
modify PTY block

Conflicts are found. could you check it?

@ko1
I did.


Agent & collector details

Please answer these questions before submitting your issue.

Why do you submit this issue?
[ *] Question or discussion
[ ] Bug
[ ] Requirement
[ ] Feature or performance improvement

Question

We installed Docker setup H2 for skywalking. We installed OAP server and UI. We need to setup collector. Kindly provide the collector software and network port details from agent to collector or How the communication established from agent to skywalking

Regards
Nowshaht

All your questions are already documented, please read before asking: https://github.com/apache/skywalking/tree/master/docs/en/setup
P.S. H2 is for developing / testing purpose , we don't recommend to use it in production environment

All your questions are already documented, please read before asking: https://github.com/apache/skywalking/tree/master/docs/en/setup
P.S. H2 is for developing / testing purpose , we don't recommend to use it in production environment


feat(pages): created white and g100 example pages

Related Ticket(s)
https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/6732
Description
Created the White and Gray 100 page examples.
Changelog
New

created new test pages for Carbon themes

Getting this for some reason when viewing the page

Looking at the image files, am thinking we should probably avoid a mix of upper caase and lower case in the file names. Should probably stick with all lower case.

@kennylam Hadn't noticed the ~ thing, thanks! As for the other components in the dark page, I'm actually confused since everything shows up just fine locally.
https://user-images.githubusercontent.com/24970122/134425916-0b487154-5ba8-4f40-a3b5-d5ce2a2805ff.mov
Though sometimes after constant reloading it does go back to how it looks like in the preview. I'm wondering if this might have to do with the way the styles are being loaded in NextJS? Seems like the default/"white" styles override the dark theme colors, so the text ends up blending with the background.
@jeffchew Now using lowercase for the files and the current rc.1 - had that specific version since canary at the time hadn't updated with a React wrapper that I needed.


Refactor Staking contract (met dragons - eip170)

Optimized modular system introduced
Staking contract refactored - split into modules
Tests updated to the new modular structure
Refactored stakeBySchedule
Restored function Staking.stakeWithApproval
Note: original Staking contract and all the inherited ones are left for review/comparison at the moment and will be removed except for IStaking which is adapted to the new structure
Restored require/revert messages to their full text
Fixed governance Team Vesting cancelling out of gas issue [MERGE FORM ANOTHER BRANCH PENDING]

Looks good! The modules make sense, documentation is clear. There are only a few things I noticed.
* The stakeBySchedule function was not refactored as expected (details in comment). I recommend refactoring this in a separate PR.

* The error messages were shortened to error codes in the past due to the contract size issue. i would prefer for them to be restored to their full length, because it makes debugging a lot easier.

All done


[Question] why do we need to pass location={this.props.location} to switch when animating?

I've finally managed to add nice route transitions into react native app, its actually extremely simple once you do it once, but I have one question that remains.
In native docs: https://reacttraining.com/react-router/native/guides/animation there is a section on why we need to use <Switch />

It’s important to use a . It will ensure that only one route can match, and therefore gives us a single element on props.children to hang on to and render during the animation. Finally, you must pass the location to Switch. It prefers props.location over the internal router location, which enables the saved child element to be renered later and continue to match the old location.

Indeed if I don't pass props.location my old rout doesn't persist while animating, but I can't understand why it makes such a change , isn't <Switch /> esentially listening to same location as a component that users withRouter ?

I'm not really familiar with React Native animation, but see #4351 which discusses why it is necessary for animation with react-transition-group.

Thanks mate! finaliy solved it :1st_place_medal:

@IljaDaderko  How to add nice route transitions into react native app?Can you tell me how to do it?

@terrytianliang try example below, you need to wrap  in it
import React, { Component } from "react";
import PropTypes from "prop-types";
import { Animated } from "react-native";
import styled from "styled-components/native";
import GridCell from "./GridCell";
import Animate from "./Animate";
import { animation } from "../Styles";

const SGridCell = styled(GridCell)`
  opacity: ${props => props.aopacity};
  margin-top: ${props => props.amargin}px;
  flex: 1;
`;

class RouteAnimationBase extends Component {
  // -- prop validation ----------------------------------------------------- //
  static propTypes = {
    children: PropTypes.node.isRequired,
    location: PropTypes.object.isRequired,
    initialReveal: PropTypes.bool.isRequired
  };

  // -- state --------------------------------------------------------------- //
  state = {
    animationValue: new Animated.Value(this.props.initialReveal ? 1 : 0),
    previousScene: null,
    hidden: true,
    pointerEvents: false,
    modalOpen: false
  };

  // -- methods ------------------------------------------------------------- //
  componentWillReceiveProps({ location, initialReveal }) {
    if (location.state && location.state.modal) {
      return this.setState({ modal: true });
    } else if (this.state.modal) {
      return this.setState({ modal: false });
    }
    if (initialReveal && this.state.hidden) {
      this.setState({ hidden: false }, () => {
        this._onAnimation(1);
      });
    } else if (
      initialReveal &&
      location.pathname !== this.props.location.pathname
    ) {
      this.setState({ previousScene: this.props.children }, () => {
        this._onAnimation(0);
      });
    }
  }

  _onAnimation = value => {
    this.setState({ pointerEvents: false });
    Animated.timing(this.state.animationValue, {
      duration: animation.duration.base,
      toValue: value
    }).start(() => this._handleAnimationLogic(value));
  };

  _handleAnimationLogic = value => {
    if (value === 0) {
      this.setState({ previousScene: null }, () => {
        this._onAnimation(1);
      });
    } else {
      this.setState({ pointerEvents: true });
    }
  };

  // -- render -------------------------------------------------------------- //
  render() {
    const { children, ...props } = this.props;
    return (
      <Animate
        aopacity={this.state.animationValue.interpolate({
          inputRange: [0, 1],
          outputRange: [0, 1]
        })}
        amargin={this.state.animationValue.interpolate({
          inputRange: [0, 1],
          outputRange: [-5, -15]
        })}
      >
        <SGridCell
          {...props}
          pointerEvents={this.state.pointerEvents ? "auto" : "none"}
        >
          {this.state.previousScene || children}
        </SGridCell>
      </Animate>
    );
  }
}

export default RouteAnimationBase;

@IljaDaderko Thank you very much for your help


nodesdk: added typesafe error names

Just some small improvement on errors by adding a const variable ERROR_NAMES holding all possible error names.

Thanks @benjaminstrasser ! LGTM 🚢
Could you please rebase with main ?
Thanks


Add types for Enumerator::Chain

This PR adds RBI type definitions for the standard library's Enumerator::Chain class, including a T::Enumerator::Chain metatype.
The change follows the example of the existing Enumerator::Lazy and T::Enumerator::Lazy support.
Motivation
Prior to this change there were no types for Enumerator::Chain in Sorbet's standard library, which meant that calling Enumerator::Chain.new would result in an invalid constant error.
Test plan
See included automated tests.
bazel test test --config=dbg is passing locally, but I never managed to get bazel test //... --config=dbg to work (I hit build errors even before I made any changes).

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_N7FhOOFW3xi1PL
→ https://go/builds/bui_N7FhdR9hJVCuKo


License the project under MIT

If this PR is approved, all the code in Toltec (except otherwise stated, in particular in the scripts/opkg folder) will be licensed under the MIT license. Past and future contributors would retain their copyright, but agree to place their contributions under that license.
It needs to be approved by all the contributors: @fenollp, @Eeems, @LinusCDE, @raisjnn.

Just need to add the license header to the new package before merging

@matteodelabre No need to, I've updated the #111  with the license headers.


Use more selective imports at module imports

AFAICT selective imports have been fixed in 2.071.0 and now enough time has passed down the road.
FWIW I still hope that we get Dependency-Carrying Declarations (DIP1005) at some point and can completely get rid of these global imports and make Phobos entirely pay for what you need.

:sob:
ggplotd 1.1.3: building configuration "ggplotd-test-default"...
source/ggplotd/colour.d(30,7): Deprecation: catch statement without an exception specification is deprecated; use catch(Throwable) for old behavior
source/ggplotd/stat.d(511,12): Error: module std.typecons import 'Erase' not found
source/ggplotd/geom.d(1044,25): Error: template instance ggplotd.stat.statDensity2D!(MapResult!(__lambda3, Zip!(MapResult!(__lambda1, Result), MapResult!(__lambda2, Result)))) error instantiating
source/ggplotd/example.d(120,9):        instantiated from here: geomDensity2D!(MapResult!(__lambda3, Zip!(MapResult!(__lambda1, Result), MapResult!(__lambda2, Result))))
source/ggplotd/stat.d(511,12): Error: module std.typecons import 'Erase' not found
source/ggplotd/geom.d(1044,25): Error: template instance ggplotd.stat.statDensity2D!(MapResult!(__lambda1, double[][])) error instantiating
source/ggplotd/example.d(234,21):        instantiated from here: geomDensity2D!(MapResult!(__lambda1, double[][]))
source/ggplotd/stat.d(511,12): Error: module std.typecons import 'Erase' not found
source/ggplotd/stat.d(603,28): Error: template instance ggplotd.stat.statDensity2D!(Aes!(double[], "x", double[], "y")) error instantiating
dmd failed with exit code 1.

LGTM. Are these changes related the the ggplotd errors, or did the latest release just break it?

Are these changes the cause of the the ggplotd errors, or did the latest release just break it?

I haven't seen this particular ggplotd error on the project tester before, so it's most likely from this PR (I rebased to force a rerun to be sure though).

Probably because some functions were relying on a combination of nested imports and module-level blanket ones, which changing to selective broke.

Probably because some functions were relying on a combination of nested imports and module-level blanket ones, which changing to selective broke.

And I foolishly assumed that this was fixed / deprecated, but it seems like it's not:
module foo;
import c;
//import c : NotErase; // <- breaks build of module `bar`

module bar;
unittest
{
    import foo : Erase;
    assert(Erase == 2);
}

module c;
int Erase = 2;
int NotErase = 2;

Wait, what? So the import c; is somehow acting as a public import?
Did the fix for 314 make the problem its opposite?

Wait, what? So the import c; is somehow acting as a public import?

AFAICT yep :/

Did the fix for 314 make the problem its opposite?

I think https://github.com/dlang/dmd/pull/5485/files simply didn't touch this. Even 2.062 treats import c as a public import.

Wait, what? So the import c; is somehow acting as a public import?
AFAICT yep :/

-> https://issues.dlang.org/show_bug.cgi?id=17630

Can you investigate this a bit more and add that info to the bug report, including that it's been around for a while?  This seems like a fairly important import leak remaining, would be good to explore how large it is.  Ironically, using selective imports at module scope, as you do in this PR, actually plugs the leak, but breaks code that unintentionally relies on leaking symbols.

Can you investigate this a bit more and add that info to the bug report, including that it's been around for a while?

Yeah I tried to. My DMD foo is pretty low atm unfortunately. So I can only say that the leaked symbols are found in the local symtab table.

This seems like a fairly important import leak remaining, would be good to explore how large it is.

It's pretty large. AFAICT all module-level imports, non-selective imports leak their symbols.
However, even selective imports leak their selected symbols:
import imports.test17630b; // works __falsely__ as public import
import imports.test17630b : Erase; // works __falsely__ as public import

Funnily even private import X; doesn't work.

It seems like the entire implementation of selective imports never took visibility into account properly.  This is where having so few compiler devs' eyes on the source of such a massive language is hurting D.

I plan to remove the current visibility deprecation for 2.077, would be a good timing for this change as well. Still need to check how many projects still haven't fixed their deprecations though.

Likely just needs to be rebased and updated, would be good if you added Andrei's commented-out selective imports from #5948 too.

Oh, I guess you're waiting on the 1-year deprecation period for the selective import leak to pass before getting this in?

Yes and it hasn't even started yet, see e.g. https://github.com/dlang/dmd/pull/6676
I will close this PR now to avoid other people bumping into it, but once the selective import leak has been deprecated, imports at Phobos can finally made selective.
Also as a note to reviewers: new top-level imports can and should always be selective - there's no need to increase the area of the symbol leakage (and it's also dangerous because we could introduce a new symbol leak during the deprecation period).


⚠ Bofrost.de has degraded performance

In 62cf32c, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1611 ms

Resolved: Bofrost.de performance has improved in f4831d8 after 13 minutes.


Devices List

Please add details on why this cmdlet returns devices that are not shown in the OWA -> Options -> Phone list.

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

ID: 6ade56cc-22bf-0a4b-5d17-b34c8f4cac91
Version Independent ID: 28eaa44b-2fed-aa95-bd12-07924ef6c164
Content: Get-ActiveSyncDevice (exchange)
Content Source: exchange/exchange-ps/exchange/devices/Get-ActiveSyncDevice.md
Service: exchange-powershell
Product: unspecified
GitHub Login: @chrisda
Microsoft Alias: chrisda

@danmyhre does the Get-MobileDevice cmdlet return the same results (I assume it does)? The *-ActiveSyncDevice cmdlets have been 'replaced' by corresponding *-MobileDevice cmdlets. I say 'replaced' because you get a warning when you run them, but they've never been removed.
Interestingly, I found some old chatter on the web describing the opposite effect: more partnerships were being shown in OWA than were shown using Get-ActiveSyncDevice.
Thanks for the feedback.

Scenario: In a organization there is a generic email ID used by Employee_1 who has ActiveSync enabled on his mobile. After he left from that organization ActiveSync to be enabled to new employee Employee_2. Now how to block previous employee Employee_1 and allow to new employee Employee_2 only.


Tech debt: clean up RuboCop warnings and errors.

Should we just remove the line length check?

That'll do.


Display the NICs' status during ISO installation

Related issue:

https://github.com/harvester/harvester/issues/1280
https://github.com/harvester/harvester/issues/1328

@yaocw2020 currently the bond IP is not displayed anywhere after success configuration, wondering if we can put it after the selected NICs with bracket.

Please consider including https://github.com/harvester/harvester/issues/1328 here

Dependency pull request: https://github.com/harvester/os2/pull/11

We should also show the mac address of the nic as well, since macs are commonly used to identify the nics.

We can resolve the mac address and long text enhancement in the next console UI refactoring, @yaocw2020 can u please help to address the following case only first, thanks
[ ] Do not block the installer (seems getNetworkInterfaceOptions now blocks for a while)

I guess there is no express path to resolve the long description issue at this moment. Wrap not works because wrapping only happens inside a gocui.View level but the all the options of select widget is a single gocui.View.


ci(workflows): added github action to publish package to npm

Changes proposed
[x]: GitHub action workflow for publishing orbits UI to npm whenever version changes

Check List (Check all the applicable boxes)

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

Thank you!

@all-contributors please add @AnishDe12020 for code, docs and ci

@all-contributors please add @AnishDe12020 for docs, code and ci


SiriusXM Online Streaming connector request

Does anyone else have SiriusXM that would be willing to look into creating a connector for it?
https://player.siriusxm.com/

Cheat Codes  0 && vm.track.trackName.length > 0">- No Promises (f. Demi Lovato)

This seems to be the code for the artist / track.
I'm not really familiar with javascript but I'm happy to provide information from the player and test the connector if someone else doesn't have SiriusXM

'use strict';

Connector.playerSelector = '#player';

Connector.artistTrackSelector = '.np-track-artist';

Connector.playButtonSelector = '.play';

I thought it would be like this, but it isn't scrobbling, is there some kind of debug method?

You can view the logging information from the background page. See https://github.com/david-sabata/web-scrobbler/wiki/How-to-debug-the-extension

Ah, well it's not throwing any errors, so I guess it's just not the right elements.

@andrewc2:

Connector.playButtonSelector = '.play .RegularPlay01'; rather than above, containing .play element is always visible.
Have you registered your connector in core/connectors.js?
No errors, or no info in console at all? Correctly registered connector should generate bunch of debug info in logs (indicating matched URL, injected scripts, detected player state etc)...

Ooh okay I'll try that.
I think so, the icon shows up saying "this site is supported for scrobbling"
I see the connector get loaded but nothing more. It made me think my connector code was just that far off.

Thanks to everyone's help this is now a working connector! I've opened a pull request with the implementation.


[#2PlaysAMonth]:Github UserFinder Completed

First thing, PLEASE READ THIS: ReactPlay Code Review Checklist

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
Checklist:

[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Screenshots or example output

@ANKIT9761 Are you done with the reviews?

Yes @atapas already done with the changes and made another commit within same day

Hi @ANKIT9761 there are other pending changes.
Please take care of them. In case you have doubts, please ping me over discord.

@atapas thanks for the bearing with me 😂. I guess now there shouldn't be any overriding of styles plz check it now.

@atapas thanks for the bearing with me 😂. I guess now there shouldn't be any overriding of styles plz check it now.

Catch me on discord. I still see the issues. @ANKIT9761

Hi @ANKIT9761 Have you taken care of the comments?

Hi @ANKIT9761 Have you taken care of the comments?

Yes @atapas i had done the changes and recorded the video on stackstream.

@ANKIT9761
Please add #2PlaysAMonth tag by editing play

@ANKIT9761
Please add #2PlaysAMonth tag by editing play

Done it in the local but as externally nothing changed so it is not showing any modified file.
Is it ok?

@ANKIT9761 I see merge conflicts while merging the PR. Can you please take care?

@ANKIT9761 I see merge conflicts while merging the PR. Can you please take care?

Hi @atapas i have resolved the merge conflicts.

@ANKIT9761 There is a lint error that fail the build

@ANKIT9761 There is a lint error that fail the build

@atapas Done with the linting issue  and raised new commit against it.


Fullscreen Search: New pattern for mobile web

More details to follow...

We can close this ticket if we feel like this is more of an adaptive pattern that responsive.


Update "list" command (items)

This is a similar feature to AB3's list command.
We need to update it to list all items in inventory.
The inventory item model has to be implemented first.
Command: list  items

Require no further changes


StormLoader wont connect - Change SQL hostname to portal.stormloader.uk from dynamic hostname

When ever I try to open the repo list it says could not connect!

Same here. I tried redownloading and I cannot connect to the repo.

Same here

it may be a firewall or antivirus issue, ill take a look at your log if you want

Nope not it already did that!

it is also saying that it wont connect for me

Hostname expired, its fixed now, I need to change it to use the IP rather than a dynamic hostname, i wont close this as its something I need to do

Thx

I'm re-opening this because I haven't enacted the change yet


Stopping charging session

Describe the bug
Hello,
normally a charging session should stop if the status of the charging wire changes (from connected to not connected or vice versa), right?
This does not seem to work anymore (maybe a result of bug #15407, #15411, #15415, #15431. ?) so I wanted to STOP a session manually. We changed the cars (the other one is now charging) but the session is still the previous one.
Is there any way to stop? At the charging session list you can change the car (that´s good!) but you cannot stop a session so that a new new session will start.
Steps to reproduce
no steps
Configuration details
not necessary

Log details
no log

What type of operating system are you running?
Linux
Version
0.129

normally a charging session should stop if the status of the charging wire changes (from connected to not connected or vice versa), right?

Yes. And that is determined by the charger, not the car.


numerical LU factorization

This adds numerical LU factorization kernels to initialize the factors from the matrix and run the factorization. It uses the Csr lookup structures to implement the required sparse vector additions, and a sync-free waiting approach similar to our custom triangular solvers.

Nit: maybe add a short description of this PR (before you merge).

I'll wait for the pipelines to finish here, then rebase and merge directly, since the previous changes only related to Github Actions.

The clang-cuda issues seem unrelated, so I'll still proceed

rebase!


Add caching to Travic configuration to speed up builds.

See https://docs.travis-ci.com/user/caching/#pip-cache .

Comparing the build logs to before/after, it looks like Travis does this intelligently anyway, so it's not needed.


Confused on usage

Hi! Thanks for the great project.
In terms of usage, where would you define the plist keys? You have a Keys extension but what is the Keys class? A bit insure on where to configure this. Thanks!

Hi!
Key and Keys has been defined in this library.
https://github.com/ykyouhei/SwiftyConfiguration/blob/master/SwiftyConfiguration/Classes/Configuration.swift#L28

Thank you for the quick response! My bad for not seeing that-- I forgot to import it and got a bit lost. The project works great! 😃

Also-- README update for Swift 3:
let plist = Bundle.main.path(forResource: "Configuration", ofType: "plist")!
let config = Configuration(plistPath: plist)

OK! Later update the README.


[AutoRelease] t2-deviceregistry-2024-04-18-17945(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/2048
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=6877

issue link:https://github.com/Azure/sdk-release-request/issues/2048


157 logout stale session

Closes #157
Rather simple approach based on throwing error upon non-200 response instead of refactoring our custom QueryRenderer.
Other screens might have to replicate this feature so another option is to move the onLogout + redirect logic to an external helper.LiveURL: https://kiwicomsmart-faq-tabyontjld.now.sh

cc @jaroslav-kubicek


Sensu handler for CachetHQ

I have written a sensu handler for cachethq.
https://github.com/bimlendu/sensu-cachethq
It updates cachethq based on sensu check output. I am using it to monitor aws status page and reflect the changes there to update components which we use, it works as of now.
Probably this can be added to Addons section.

This is really nice! We'd love a pull request to add your handler to our Addons list :)

Sent in a pull request.

Closed in #575


Clean logs in /var/log/supervisor

Task: log files stored on tira hosts in /var/log/supervisor are messy

messy= they display todos and other things that do not belong there

Goal: the logs in /var/log/supervisor should contain only relevant and easy to understand messages and describe every process step from start to end, like "starting vm", "vm is started", "stopping vm", "vm stopped"

So far I have not been able to locate any files in the tira hosts. i have:

printed a list of tira hosts using tira vm-list on betaweb042
ssh'd into every host in the list that is a betaweb machine and there:
-> i have used "sudo docker ps | grep tira", with the result that most of them did not host a dockerdized tira (or any tira at all?)
-> for those that returned a container-id for the tira-host, i have used "sudo docker exec -ti container-id bash" followed by "ls /var/log/supervisor"
-> none of the /var/log/supervisor-folders contains any log files

Now there are resulting questions:

does the /var/log/supervisor/ directory never hold logs? -> which logs should i then "fix"
did i look at the wrong location, that is, might there be another place called /var/log/supervisor which actually contains the wanted files?
did i not get the right tira hosts  that do contain log files in the said folder  (file with inspected hosts and results is attached), if not, where do i get a full and correct list?
tira-notes-issue99.txt

As discussed in the meeting, instead of the /var/log/supervisor/ directory on the tira hosts, the /var/log/supervisor/ directory on pod tira-bg-webclient should be inspected.


backend/drm: don't reset conn->pageflip_pending in drm_connector_cleanup

If a pageflip is pending before cleanup, it's still pending after. This
is used line 1177: drm_connector_cleanup is called and
conn->pageflip_pending is checked afterwards.
Fixes #1297
@Emantor Can you try this?

Sure, I'll try when I'm back at my docking station.

Yes, this one seems unrelated. Can you create a new issue with rootston debug logs?

With rootston hotplugging is stable (ignoring sometimes not using edp-1, but I'll chalk that up to the Link Training Failures the kernel reports). I am using a drm-tip kernel to get stable MST, which of course has other bugs. I'll resubmit to the sway repo with full logs.

Thanks!


Photoshop Click/Drag

Software works great but in Photoshop I'm constantly experiencing a click and hold/drag behaviour when I'm only performing simple single clicks. It appears to happen randomly but with regularity. If I click back and forth between two layers for instance this will always happen but not with a predicable pattern (could happen after 1 single click or 15... but it always happens eventually). This is with the latest Mac OS X and the lastest Creative Cloud version.

There is possibility of a hardware issue that your mice button is bouncing.
Please enable "General > Don't remap any pointing devices" and confirm your issue still happen.


SparseAttention doesn't support cache mechanism will cause unexpected keyword argument bug

Hi!  At the moment,SparseAttention class inherits from  Attention but it does not support cache mechanism.  I guess it is the reason of the  unexpected keyword argument bug.
CODE
dalle_pytorch/attention.py line 366
def forward(self, x, mask = None, rotary_pos_emb = None):

dalle_pytorch/transformer.py line 60
class CachedAs(nn.Module):
    """
    A wrapper that defines a key for the inference cache.
    """

    def __init__(self, cache_key, fn):
        super().__init__()
        self.cache_key = cache_key
        self.fn = fn

    def forward(self, x, *, cache=None, **kwargs):
        return self.fn(x, cache=cache, cache_key=self.cache_key, **kwargs)

and line 279
            if isinstance(attn, Attention):
                attn = CachedAs(f'attn_{ind}', attn)
            else:
                # at the moment, other attention classes don't support cache
                attn = NonCached(attn)

It seems that the problem still occurs. Have you ever solved this problem?

Not yet. Instead, I choose to use the sparse attention mentioned in the paper(e.g. axial_col)

i'm still getting this bug