Neologin Uncaught (in promise): ReferenceError: global is not defined ReferenceError: global is not defined at

Installed Neologin in my angular project:
then imported it in the prefered component
import neologin from "neologin"
then I got this error

Uncaught (in promise): ReferenceError: global is not defined
ReferenceError: global is not defined
at Object../node_modules/buffer/index.js (index.js:43)
at webpack_require (bootstrap:84)
at Object../node_modules/safe-buffer/index.js (index.js:2)
at webpack_require (bootstrap:84)
at Object../node_modules/base-x/src/index.js (index.js:8)
at webpack_require (bootstrap:84)
at Object../node_modules/bs58/index.js (index.js:1)
at webpack_require (bootstrap:84)
at Module../node_modules/neologin/index.js (index.js:1)
at webpack_require (bootstrap:84)
at resolvePromise (zone-evergreen.js:797)
at resolvePromise (zone-evergreen.js:754)
at zone-evergreen.js:858
at ZoneDelegate.invokeTask (zone-evergreen.js:391)
at Object.onInvokeTask (core.js:39680)
at ZoneDelegate.invokeTask (zone-evergreen.js:390)
at Zone.runTask (zone-evergreen.js:168)
at drainMicroTaskQueue (zone-evergreen.js:559)

Angular: 8.2.14
Package                           Version

@angular-devkit/architect         0.803.25
@angular-devkit/build-angular     0.803.25
@angular-devkit/build-optimizer   0.803.25
@angular-devkit/build-webpack     0.803.25
@angular-devkit/core              8.3.25
@angular-devkit/schematics        8.3.25
@angular/cdk                      8.2.3
@angular/cli                      8.3.25
@angular/material                 8.2.3
@angular/pwa                      0.901.0
@ngtools/webpack                  8.3.25
@schematics/angular               8.3.25
@schematics/update                0.803.25
rxjs                              6.4.0
typescript                        3.5.3
webpack                           4.39.2

I've managed to reproduce the bug after creating a new angular project with ng, working on fixing it now.

The issue has been fixed now, please upgrade to the latest version of neologin (1.2.5). Thanks for the report :+1:

Pleasure is all mine, Closing the issue now...
Thanks for the quick response.

After installing the current version,
the error clears but a new error occurs

Error: Connection destroyed     at connectToChild.js:158     at createDestructor.js:15     at Array.forEach (<anonymous>)     at destroy (createDestructor.js:14)     at connectToChild.js:152     at ZoneDelegate.invokeTask (zone-evergreen.js:391)     at Object.onInvokeTask (core.js:39680)     at ZoneDelegate.invokeTask (zone-evergreen.js:390)     at Zone.runTask (zone-evergreen.js:168)     at invokeTask (zone-evergreen.js:465)

Looking into it

Hi @sahmmie,  could you give me some instructions to reproduce it? I couldn't get the error

I'm also having trouble reproducing it. How I've tried to do it:

Create a new project with ng new
Modify src/main.ts to add the following code:

import neologin from "neologin";
neologin.getAccount().then(console.log)

Serve with ng serve

After taking these steps neologin seems to be working fine.

Could you provide some more information on what is a component that doesn't belong to the root module (I'm not familiar with angular development)? I've tried using it inside src/app/app.component.ts and it seems to work.

Yes, the app.component.ts belongs to the root module, when a component is generate by default it is added to the root module(app.module.ts).
When a component doesn’t belong to the root module it is said to have another module other than(app.module.ts) for other reasons...
In my case I have another module which houses other components.

Hi @sahmmie, could you give me some instructions to reproduce it? I couldn't get the error

Create a new angular project

create another module aside (app.module.ts)

create a new component and import it into the newly created module

Import neologin into the new component and test run

Thanks! Tomorrow I'll try to reproduce it and fix the error.

Could you provide extended instructions? So far I've changed the files present in a new project created with "ng new" and left them like this:
app2.component.html
<div class="toolbar" role="banner">

    supp.
</div>

app2.component.ts
import { Component } from '@angular/core';
import neologin from "neologin";
neologin.getAccount().then(console.log)

@Component({
  selector: 'app-root',
  templateUrl: './app2.component.html',
  styleUrls: ['./app.component.css']
})
export class App2Component {
  title = 'angapp';
}

app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { App2Component } from './app2.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})

@NgModule({
  declarations: [
    App2Component
  ],
  providers: [],
  bootstrap: [App2Component]
})
export class AppModule { }

Yet it seems that neologin is working properly. Am I doing something wrong?

yes, you are. I'll give an example with the git repository below...
it will be modularized and I'll make use of neologin in the second section of the app.
I hope this makes the issue clear to you
here is the repository
[https://github.com/sahmmie/neologin-test.git](Git repo)

Error reproduced, working on a fix :+1:

Issue should be fixed now, could you verify it?
I'll create a PR upstream (penpal library) to warn about this kind of problems in their docs :+1:
Again, thanks for reporting it.

Okay... I’ll verify and give you a feedback

Issue has not been fixed yet...

I've forked your github repo, updated neologin to the latest version, built the project through github actions (you can find the repo here) and put the built page on Github pages.
The resulting page seems to be working fine, could you please point out which part of the neologin widget is broken now?

@sahmmie confirmed that now it's working fine.


feat: introduce rig pre setup functionality

Description
Introduce a pre setup functionality for rigs

:tada: This PR is included in version 1.7.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


feat(progress): adds the progress component

Adds the progress (bar) component.
Fixes #24

Deploy preview for pf-next ready!
Built with commit d5a3408646a6e6aa26b89c82c9b32e9870d1255d
https://deploy-preview-648--pf-next.netlify.com

Thank you @jgiardino!
On 1 and 2, I was going by this https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_progressbar_role
Maybe if you have time, we could meet to go over what to do?
On 3, Is there specific guidance non-text?
On 4, that's something I mentioned to @mceledonia and we didn't have a good solution. I'm open to ideas.

Yes, I'm happy to meet to go over this. I'm new to the progressbar role myself. I did test example 2 in the link you provided, and JAWS announces the aria-valuetext value and ignores the aria-valuenow value. Their example is actually more helpful that the wai-aria example, although if I had to choose between knowing the progress percentage versus the step number out of some unknown number of steps, I'm not sure which is more informative. 😕

Yeah this is looking great @srambach ! A couple requests:

(Re: @jgiardino comment 4) What happens when the percentage is too low and the bar can't fit the text? Is there a way to check what Patternfly currently does in that situation?

1b. If we can figure that out, a small visual change to request is changing the text size of the inside percentage down to fontsize-sm.
1c. If there's not a good solution there, I am ok with getting rid of this option, it doesn't seem to fill any gap that isn't filled by other options.

The "Progress Inside Success" text isn't going to pass accessibility... It's not the prettiest solution but we might have to change the text color from white to our primary dark text color here. Would it be possible to keep it white, then flip it to dark when the success state is triggered? The other option is to drop the percentage for the success state altogether, but I do like how it feels in the non-inside options.

Definitely open to suggestions here, let me know if you have any ideas!

@mceledonia Here's a screen shot of what currently happens with a very small percentage and the inside option. Obviously it can be such a small %age there is no way for it to fit at any font size. And if the 2 parts of the progress bar are contrasty, there isn't going to be one color that works on both.

Any other ideas?

@mceledonia Yes, I think the text color can be flipped to dark when the success state is triggered for the inside version if that's what you want.

@srambach Thanks for showing that, definitely not gonna work :) Found the solution that bootstrap (and probably PF3) uses! A min-width on the bar, so 0% is still enough of the par to show the percent.
https://getbootstrap.com/docs/3.3/components/#progress
I'm ok with that solution, let's try a min-width of 32px? That gives us about 4px on each side of the text which fits in nicely to our spacing system too.

This looks great to me! Nice work @srambach !

@srambach great work, I love the use of the grid for this.
Now, this implementation is changing classes and not overwriting CSS properties. We have an issue to investigate this approach #273
I don't think we should have some parts of the code written in one way and other in another. As we always say, the code should feel as if it was written by one person.
We can talk about this and decide what we want to do, but at the end of the day I'd like to use either but not both.

@srambach I have a concern about animations. At the point, we are setting the width of the indicator with a width property. And animating widths sometimes has poor performance.
I wonder if it's worth exploring using transform scale instead

@srambach I know we had a discussion about changing the format of the handlebar modifiers/attributes. I noticed you used the pf-c- format. We still haven't updated the docs so maybe you don't need to change yours if we do one big sweep :)


Wave causes an extra, short lived replica to be created in every deployment

Wave is causing an extra, short lived replica to be added to every deployment to which the wave.pusher.com/update-on-config-change: "true" annotation is added.

Deployment manifest
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    wave.pusher.com/update-on-config-change: "true"
  labels:
    app: bbox
  name: bbox
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bbox
  template:
    metadata:
      labels:
        app: bbox
    spec:
      containers:
      - command:
        - /bin/sh
        - -c
        - while true; do sleep 3600; done
        image: busybox
        name: busybox

Steps to replicate this:
First, install wave:
helm install wave wave-k8s/wave

Output of helm ls
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
wave    wave-test       1               2021-09-16 09:46:55.862965 +0100 BST    deployed        wave-2.0.0      v0.5.0

Apply the yaml file above:
kubectl apply -f deployment.yaml

I now see two pods start-up, one of which almost immediately enters a terminating state:
NAME                        READY   STATUS        RESTARTS   AGE   LABELS
bbox-57689566cf-8tc7p       1/1     Running       0          8s    app=bbox,pod-template-hash=57689566cf
bbox-68d685577f-p8s89       1/1     Terminating   0          8s    app=bbox,pod-template-hash=68d685577f

The pod in the Terminating state does not have the wave annotation; the Running one does.
Wave logs:
I0916 10:00:24.191390       1 handler.go:108] wave "level"=0 "msg"="Updating instance hash"  "hash"="100444e91862dd77d7ebe29f050c1e9a7f357c771e1a7b7650aae27e6a3a031d" "name"="bbox" "namespace"="wave-test"

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:30:33Z", GoVersion:"go1.15", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.16", GitCommit:"7a98bb2b7c9112935387825f2fce1b7d40b76236", GitTreeState:"clean", BuildDate:"2021-02-17T11:52:32Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

If I increase the replica count of the deployment to 2 I get four pods starting, two of which immediately enter a terminating state; as before the two 'extras' don't have the the wave annotation.
Removing the wave.pusher.com/update-on-config-change: "true" annotation from the deployment results in a deployment with no short-lived replicas, as expected.

Could you please share the contents of your deployent.yaml?
The behaviour you observe is expected if the Deployment and any of the ConfigMap or Secrets it consumes are updated at the same time. Could that be happening here?

The content of deployment.yaml is in the issue (expand the Deployment manifest section).
The deployment is not actually referencing any Configmaps or Secrets - merely adding the wave annotation to the deployment is enough to trigger this strange behaviour.

I think I see now.
This should only happen the first time the wave.pusher.com/update-on-config-change: "true" annotation is added.
In that case it is expected.
Adding the annotation causes a new ReplicaSet to be created (this is the case for any modification made to a Deployment.
Now with the annotation present, wave will take over managing the Deployment and add its own annotation containing a hash of the current configuration. This is used to track any changes to this configuration going forward.
In your case, the Deployment does not actually reference any config objects, so this is somewhat meaningless. If it did consume a ConfigMap, for example, any change to its contents would then cause wave to update the hash annotation and thus trigger a rollout.
The additional Pods being created if wave is enabled on a Deployment that already exists should not cause any problems and is unavoidable.

Thanks for your quick responses on this.
It's good to know that what I'm seeing is expected, but I'm not sure I agree that this behaviour is harmless, at least for my use case.
I'm working with deployments of 1 replica, where each replica is stateful database and can be very resource heavy in terms of memory and CPU requests. Scheduling an extra pod, even for a short time is probably not acceptable in that case. That's before factoring in the chance that both pods land on the same node and race/overwrite each other on the same PVC at startup resulting in neither of them being able to start successfully.
If this behaviour is unavoidable, I guess I'll have to look elsewhere for a solution for rolling these pods in response to secret mount changes.

This certainly is one of the challenges of running large, stateful workloads on Kubernetes.
The way wave is designed, the behaviour you have observed is sadly indeed not avoidable.
That said, it won't occur in steady-state but only when a Deployment is first created or the wave annotation first added.
After that initial double rollout, you should expect to see exactly one per config change, although I appreciate that may not be good enough for your use case.

Unfortunately, in the system I'm working with the creation/deletion of these deployments is highly dynamic, so this initial double rollout probably isn't going to work for us.
Thanks for your help on this 👍

@gargath What if Wave added its hash annotation only after the first time a secret/configmap is updated?

For anyone interested: This has now been fixed. With Wave 0.6+ you can enable webhook which eleminate an additional short-lived replica in almost any case.


Cannot read property 'search' of undefined

<script<EMAIL_ADDRESS>And I get this error
Cannot read property 'search' of undefined
Cannot read property 'dirty' of undefined
Anyone have this issue ?

My mistake


fix: Service worked scope

Service worker has to sit in root or at least higher level than everything else it needs to cache

Ah you beauty, thanks @gavmck


{Storage} Fix 17220: Refine help

Description

Fix #17220
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Storage


Sfu

hi there,
i'm taking CS writing course in SFU. my jobs is to review document on github.  your product has many function. however, the description of the function,"With Axlsx you can create excel worksheets with charts, images (with links), ...validation. "  is too long. customer may lose interesting and skip the description. therefore, i rewrote the description to separate the sentence in paralleled structure, and make it stronger.
i omitted "for the really funky stuff" because funky stuff is informal and redundant. "any value you specify" is good.
" - Images are known to not work with google docs" sounds awkward, i changed to "Images do not work with google docs" just as the sentence below.

@hairice I am making you a contributor.
It is a very refreshing thing to see someone interested in great documentation.
We are currently prepping the release-3.0.0 branch as our next release.
Would you be so kind as to direct your efforts onto that branch?


Support short centos image names in testcloud provision

It would be nice to support short names for CentOS images such as centos-8 in the testcloud plugin as well. Cloud images are available at the following location:

https://cloud.centos.org/centos/

Thanks for the idea, @sturivny :)

Thanks for the idea, @sturivny :)

Was glad to help =)

Was glad to help =)

Just heard it is quite a big and problematic, removing label

@frantisekz, is this something which should be implemented in tmt or would it be better to handle this in testcloud instead?
Plus a related question: Today we've discussed with @lukaszachy that it would be nice to be able to provision virtual machines from vagrant boxes as well. The implementation should be relatively easy, just unpacking the qcow2 image, so basically this:
tar xfz vagrant.box
mv box.img box.qcow2

And again the same question: Should this be a task for tmt or a testcloud?

I'd say that first step, getting the url to image/box should be handled by tmt.
Ideally with some plugin / search system so user can easily plug their own location/priority. E.g. there is a lot of official vagrant boxes from https://app.vagrantup.com/boxes/search but you might (not) want to use that.
Second step - extracting qcow2 from box should be done by testcloud

Makes sense to me, @frantisekz, what do you think?

It would be nice to support short names for CentOS images such as centos-8 in the testcloud plugin as well. Cloud images are available at the following location:

https://cloud.centos.org/centos/

I am planning to add support for centos:8 and centos:7 as a parameter to testcloud. However,the urls probably would be hardcoded as I didn't find a way to fetch them programmatically.

Makes sense to me, @frantisekz, what do you think?

Yes, it seems like a good plan. If tmt learns to pass a url to a vagrant box, testcloud will handle the extraction and vm preparations (if there are no terrible bumps on the road waiting). I'll take a look in a bit.

I am planning to add support for centos:8 and centos:7 as a parameter to testcloud.

Nice to hear this! Btw, would it be possible to support centos and fedora shortcuts as well for the latest released? Currently we handle the latest fedora image in this way.

Yes, it seems like a good plan. If tmt learns to pass a url to a vagrant box, testcloud will handle the extraction and vm preparations (if there are no terrible bumps on the road waiting). I'll take a look in a bit.

That's great! Thank you.

Vagrant support code is here: https://pagure.io/testcloud/pull-request/94 , however, there is a problem with missing cloud-init package in CentOS vagrant boxes (see the PR for more). I'll try to think if there is some elegant solution to install that package from testcloud and then expose the ssh connection.
Do you have any ideas how to solve this?

Nice to hear this! Btw, would it be possible to support centos and fedora shortcuts as well for the latest released? Currently we handle the latest fedora image in this way.

I have code ready for latest Fedora, pending on https://pagure.io/fedora_nightlies/issue/10 . Just one question: it's possible to have fedora:latest point to either latest compose or latest successful compose that passed OpenQA testing, which one do you prefer?
User friendly overview is available here: https://openqa.fedoraproject.org/nightlies.html

Testcloud master branch now support Vagrant Boxes (not a very nice piece of code, but gets the job done), CentOS version handles (centos:7/8/latest; centos-stream:8/latest ; this is unfortunately hard-coded for now, I'll try to ping someone if we can get a json form, I would try to avoid having to parse the html page) and fedora:rawhide handle (Rawhide Cloud is currently borked, filled a PR with fix: https://src.fedoraproject.org/rpms/cloud-init/pull-request/19# ).
I'll try to cut a new release soon.

That's great to hear! Thanks for all the improvements and sorry for late answer. Looking for the new release! :) Is there a copr build we could test with already now?

Just one question: it's possible to have fedora:latest point to either latest compose or latest successful compose that passed OpenQA testing, which one do you prefer?

I would suggest to keep the notation consistent with other provision plugins, so fedora:latest would be the latest Fedora which has been released (similar to what podman does).


ci: add support for SUSE 15.6

Test passed (job). Reverting https://github.com/newrelic/pkg-installation-testing-action/pull/27/commits/4b73f7df49f236caf4a4690e5e4047a2229c8262 with https://github.com/newrelic/pkg-installation-testing-action/pull/27/commits/df7b9ee6d0353cadab0c80151972bbe989ef1584


Client is missing from some callbacks

Most callbacks provide a client parameter, but some don't (e.g. goto_definition). Is there a reason for that? It makes using the client.log_message() method awkward.

Good question! There exists some historical context behind the current design. Basically, when I was prototyping the LanguageServer trait and Client struct, I wanted to grant the server access to the client where it was needed, but I also wanted to balance the complexity of trait method signatures and not have them be too verbose and unwieldy to type out by hand. As such, as a rule of thumb, I decided to grant Client access to all notification methods by default and piecemeal add in Client access to request methods where makes sense (e.g. initialize and workspace/executeCommand).
On one hand, I wouldn't mind amending the trait to grant Client access to more request methods (like goto_definition) if it makes language server authors' lives easier, like in your request, for example. But on the other hand, thanks to changes in #172, Client now implements Clone. I'm wondering if it would be possible not to pass in Client as an explicit argument to each individual method, but instead have it be passed in by move in fn initialize() and the server can store it inline as a struct field and used in whatever LanguageServer methods make sense to them.
Either way, some API design work and analysis of benefits vs. tradeoffs is necessary here, I think.

Linking #188 here as a somewhat related topic of discussion.

I'm wondering if it would be possible not to pass in Client as an explicit argument to each individual method, but instead have it be passed in by move in fn initialize() and the server can store it inline as a struct field and used in whatever LanguageServer methods make sense to them.

Seems reasonable to me!

The general problem here (and why I opened #188) is that if the Client gets initialized at runtime (in initialized) then you have to use something like Option<Client> (disregarding thread safety) for the code to compile, which makes using the Client a bit annoying.
My suggested solution would be have a wrapper type that implements Deref to Client and can be created without any parameters. Then it must be initialized in the initialized callback with a Client (or it can be something like ClientInner which would be an opaque wrapper around Client to prevent the usage without a wrapper), otherwise the methods will panic at runtime (a method to check if it's initialized could also be provided). This way we have the same ergonomic API and any number of such wrappers can exist, provided that they are initialized somewhere.
let wrapper = ClientWrapper::uninit();
assert!(wrapper.is_uninit());
wrapper.init(&client);
wrapper.show_message(...);

With this comment I think #188 can be probably closed to continue the discussion here.

I think I may have an alternative approach. We could change LspService::new() to take an FnOnce rather than a server directly, like so:
#[derive(Debug)]
struct Backend {
    client: Client,
}

#[tower_lsp::async_trait]
impl LanguageServer for Backend {
    async fn initialize(&self, _: InitializeParams) -> Result<InitializeResult> {
        Ok(InitializeResult::default())
    }

    async fn initialized(&self, _: InitializedParams) {
        self.client.log_message(MessageType::Info, "server initialized!");
    }

    async fn shutdown(&self) -> Result<()> {
        Ok(())
    }
}

#[tokio::main]
async fn main() {
    let stdin = tokio::io::stdin();
    let stdout = tokio::io::stdout();

    let (service, messages) = LspService::new(|client| Backend { client });
    Server::new(stdin, stdout)
        .interleave(messages)
        .serve(service)
        .await;
}

This way, Backend can be initialized with a client field in a type-safe way without forcing the user to manually track the initialization state in their code. Additional resources can be initialized ahead of time in main and passed into the closure, if needed.

With this comment I think #188 can be probably closed to continue the discussion here.

Good idea, @Timmmm! Let's consolidate the discussion here. I'll close the other issue and rename this one appropriately so we are all on the same page.

I've opened #199 with an implementation of this, if anyone would like to review!


Reorganise code owners

I've created a separate team on our organization for the maintainers of this project.

It already shows on this one, so I think we are good! Thanks :heart:


Links are not highlighted for issues found by search on some sheets

Something wrong with Apache POI 3.11-FINAL, too much time spent to investigations, hyperlinks were removed for now.


Support compression in fetch()

This became clear when inspecting indieweb/indiewebify-me#78.
Curl does not automatically support any compression. This is problematic as it also does not send an Accept-Encoding header. Note that not sending the header at all suggests to the server that any encoding is fine, and they are free to respond with a compressed format. It looks like most will not do this though, or this would have come up before.
I think we have two clear options:

Specify a specific Accept-Encoding value of identity, which should tell servers never to send compressed data; or

defining CURLOPT_ENCODING to automatically have Curl handle the compressions it knows about (DEFLATE and gzip):
curl_setopt($ch, CURLOPT_ENCODING, '');

Alternatively I wonder if we should offload this to an external dependency. Maybe even aaronpk/p3k-http. That way all those weird extra flags we need for HTTP/2, gzip, etc., only need to get added once and multiple projects will profit from it.
Thoughts, @aaronpk?

One of the goals of this library is to be self-contained so that it can be included in other projects without bringing in a lot of other dependencies. I think it's best to just add this flag here rather than bring in p3k-http or any other http client.


Parse Format of ExternalGraphic

With this PR, Format tag of SLDs ExternalGraphic will be parsed. geostyler-style and all other parsers and Components remain the same. Also, create new getIconSymbolizerFromSldSymbolizer() to keep code easier to read. Updated testfiles accordingly.
Supported mime-types are:
image/png image/jpeg image/gif image/svg+xml

@terrestris/devs open for review


Update the Logging Level to VERBOSE (Msal Default) for Token Caching Callback API

Currently, ERROR levels logs are logged for Exception in Token Caching Callback API,

It is expected to follow the default logging level of VERBOSE as discussed with @siddhijain

This issue is fixed in Release v1.13.2. Closing the issue.


(feat): obfuscate transactions and traces path params with config regex

Changes:
Based on the url_obfuscation_regex param from the newrelic.js config file.

obfuscate request.uri
obfuscate http.url (path part only)

For Transactions and Distributed Tracing (for incoming and outgoing http requests)
It also obfuscates attributes (with the same names as above) for Distributed Tracing (Spans and root of the transaction)
(To obfuscate url in Transaction Trace details use attributes.exclude array providing request.uri which also removes the attribute from Distributed Trancing attributes)

Proposed Release Notes
Links
Details

Thanks for the comprehensive review @bizob2828
I'll need some guidance on two things:

how the default.js config file is merged with a newrelic.js file (coming from an app)
when formatters are used and how they are being triggered on the app start.

I've made some changes on my local including a formatter:
in default.js I've included:
   /**
   * Default URL obfuscation regex - will never match anything
   */
  url_obfuscation: {
    formatter: regex, // formatter implementation doesn't matter for now
    default: null,
  },

And in the newrelic.js file:
  url_obfuscation: {
    regex: /.*/,
  },

I've put a bunch of breakpoints and tried figuring out how the two configs are merged, but I can't find the exact place. I know part of the logic is happening in this method but I'm struggling to identify the place where the merge happens.
For example for attributes.exclude this works as expected but with the above changes for url_obfuscation I ending up with config.regex = /.*/ instead of config.url_obfuscation.regex = /.*/
I've also put breakpoints at array and boolean formatters but with the default newrelic.js config they where never fired.


⚠ Bofrost.be has degraded performance

In 17a7948, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1843 ms

Resolved: Bofrost.be performance has improved in ed35c61 after 20 minutes.


Standardize builtin function parameters

Description

Builtin functions Get-Plugin and Get-Role use the non-standard parameters
plugin and
ole respectively where they should use
ame as is normal in
PowerShell functions. This commit updates those functions and their comment
based help to reflect the correct parameters.
This is a breaking change if people are relying on the old parameters.

Related Issue
This change resolves devblackops/PoshBot#7.
Motivation and Context
All builtin functions and publicly exposed functions should follow best practices and PowerShell standards.
How Has This Been Tested?
Ran the Test.ps1 with the updated code.
Screenshots (if appropriate):

Types of changes

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

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Thanks @michaeltlombardi

No problem!


update readme

To add note that when the game is copied to/run from another folder

Thanks for the suggestion, @SoumenDass! I'm thinking I'll add a runtime check that the directory exists, rather than a note in the docs, but I'm curious: why was it that you wanted to copy the game elsewhere?

Usually I keep my git repos and the location of binaries separate. So after building, I move the binary to the folder where I keep, e.g., games. If you already have support for make install, then the copying of the binary + the assets can be done as part of the installation and we do not need to add this note to README.

Ah gotcha, thanks. I'll keep that in mind.

Added checks for the asset directory in 63f5e56 and 53687ff, so I'll close this. Thanks for bringing this use case to my attention!


Global/File Thresholds - Warning Configuration

First off, great reporter, in addition to the latest enhancements that were implemented.  Wondering if we can expand on an existing enhancement...
Enhancement request: can we have a configuration that throws a warning instead of a hard fail when the coverage doesn't meet the threshold? See an example configuration below:
thresholds: {
alert: "warning", // options: "fail", "warning"
global: { // thresholds for all files
statements: 100,
lines: 100,
branches: 100,
functions: 100
},
each: { // thresholds per file
statements: 100,
lines: 100,
branches: 100,
functions: 100
}
}
We've implemented pre-commit hook that checks the threshold but would prefer it throws a warning rather than preventing the commit.  Thoughts?

Makes sense, I've added this in 1.3.0 🎉


Background blur doesn't work on websites after the new update

Same here, no blur running 1.0.1-a.2 on Linux.... only time the blur works is in the settings page, not on any actual website.

same here

+1, not working since quite a while.


Add facts that list all IPv4/IPv6 local addresses in CIDR format

Proposal: Add facts that list all IPv4/IPv6 local addresses in CIDR format
Author: Maciej Delmanowski <@drybjed>
Date: 2016/07/29

Status: New

Motivation
Ansible should expose all of the host IP addresses not only as simple strings, but as proper CIDR prefixes as well. This, combined with the ipaddr() filter already present in the Ansible core, will allow greater flexibility with IP address manipulation in certain situations.
Problems
Example existing usage pattern: the PostgreSQL database supports specifying the localnet value in the pg_hba.conf file to accept connections from hosts in the networks that the PG server host is connected to. This shrinks the attack surface significantly (host accepting connections from the entire Internet vs from hosts on the local networks) without the need to specify the CIDR networks the host is connected to.
This usage pattern could be applied to all manner of things - web control panels, sensitive network services, etc. However, at the moment Ansible does not offer an easy solution to the problem of getting local network ranges - it's either manipulation of various facts through Jinja to combine current information about local networks to a useful format, or leave an excercise to the user to specify local network CIDR ranges for the playbook/role to use.
Solution proposal
Ansible should expose host IP addresses not only in the current form of simple strings, but as a proper CIDR prefixes. For example, with these facts:
ansible_all_ipv4_addresses: [ '<IP_ADDRESS>', '<IP_ADDRESS>' ]
ansible_all_ipv6_addresses: [ '2001:db8:feed:beef::28', '2001:db8::1' ]

There should be a set of corresponding facts:
ansible_all_ipv4_cidr: [ '<IP_ADDRESS>/24', '<IP_ADDRESS>/20' ]
ansible_all_ipv6_cidr: [ '2001:db8:feed:beef::28/64', '2001:db8::1/48' ]

This way, playbooks and roles have access to the full information needed to extract the required information about local network ranges using the ipaddr() filter plugin.

This is helpful.


Consider adding dynamic target limits

Currently, we require that crates that take more than 15 minutes to build build only one target so that they don't clog up the queue for several hours. However, we have no similar limit for crates that take just under 15 minutes. This means that a crate that takes 14 minutes to build will take 5 times as long in the queue as a crate that takes 16. This doesn't seem right. To be fair, we could dynamically limit the number of allowed targets: 5 minutes to build allows 3 targets, etc.

See also https://github.com/rust-lang/docs.rs/pull/1002; it's not yet official that a time extension means you can only build one target.

This seems more complicated than necessary. No one has complained so far.


bug(hubble): killing gRPC streams that are stuck

When a client opens a stream (via subscribe() and immediately sleeps, the server doesn't realize that the client is not draining the stream, and continously writes to the stream, which just keeps getting buffered, eventually running out of RAM and OOming.
We can detect this situation on the server by monitoring the memoryUsage.rss and if it increases more than 1G during the loop, we can log them.
The current plan is to log this error in production, and then decide what we want to do. We can decide to destroy() the stream to protect the hub.

Closed by https://github.com/farcasterxyz/hub-monorepo/pull/843


failed to pull cf-operator images from private docker registry- 2.7.1 & 2.7.12

Hi Team,
while trying to pull cf-operator (2.7.1 & 2.7.12) images from private docker registry,
except for quarks-statefulset pod other pods are able to pull from private docker registry.
k get pods -n cf-operator
NAME                                              READY   STATUS             RESTARTS   AGE
cf-operator-quarks-bf75bd6bd-2llqx                1/1     Running            0          2m13s
cf-operator-quarks-job-69dd47c488-jlpqx           1/1     Running            0          2m13s
cf-operator-quarks-secret-79444db496-9mdwq        1/1     Running            0          2m13s
cf-operator-quarks-statefulset-6c88b796d4-qqjsv   0/1     ImagePullBackOff   0          2m13s
Events:
Type     Reason          Age                From                             Message

Normal   Scheduled       63s                default-scheduler                Successfully assigned cf-operator/cf-operator-quarks-statefulset-6c88b796d4-qqjsv to k8s-worker-1-kubecf288
Normal   SandboxChanged  50s                kubelet, k8s-worker-1-kubecf288  Pod sandbox changed, it will be killed and re-created.
Normal   BackOff         24s (x4 over 50s)  kubelet, k8s-worker-1-kubecf288  Back-off pulling image "myregistry/ghcr.io/cloudfoundry-incubator/quarks-statefulset:v0.0.1308-g6a8b2220"
Warning  Failed          24s (x4 over 50s)  kubelet, k8s-worker-1-kubecf288  Error: ImagePullBackOff
Normal   Pulling         12s (x3 over 62s)  kubelet, k8s-worker-1-kubecf288  Pulling image "myegistry/ghcr.io/cloudfoundry-incubator/quarks-statefulset:v0.0.1308-g6a8b2220"
Warning  Failed          12s (x3 over 51s)  kubelet, k8s-worker-1-kubecf288  Failed to pull image "myregistry/ghcr.io/cloudfoundry-incubator/quarks-statefulset:v0.0.1308-g6a8b2220": rpc error: code = Unknown desc = Error response from daemon: Head https://myregistry/v2/ghcr.io/cloudfoundry-incubator/quarks-statefulset/manifests/v0.0.1308-g6a8b2220: unknown: Authentication is required
Warning  Failed          12s (x3 over 51s)  kubelet, k8s-worker-1-kubecf288  Error: ErrImagePull

It was failed, since the cf-operator-quarks-statefulset values.yaml dont have mechansm to add credentials in values.yaml file.
Below are the changes that need to be performed inorder to pull images for private docker registry for cf-operator-quarks-statefulset.

Include global.image.credentials in values.yaml file for the images (quarks-stetefulset)
added/created service-account-pull-secret.yaml for both under the templates directory
calling image credentials from secret (created in 2nd step) in service-account.yaml

Same changes for cf-opeartor 2.6.1, 2.7.1, and 2.7.12.

Seems like it's fixed now.


Dockerize web builds

I'm not sure what the standard for web app containers is. I guess it should include a web server and (optional?) certificate handling.
I'm quite happy with Caddy as it handles the certificate stuff transparently, but would be happy with other solutions as well, e.g. nginx.

Just building FROM a webserver image and copying in the build should do the trick. My (opinionated) view is that certificates are better left to an extra reverse proxy set up by whoever is running the deployment, but either approach is possible.

You seem to be more experienced in this topic than me so I defer to you. Having the reverse proxy handling the certificates seems perfectly fine to me, as that's how I host my apps anyway.


Forgive "No overload matches this call" for union-type arguments, if assignment can satisfy a union of overloads

Suggestion
When determining if a union-typed argument is assignable to the parameters of an overloaded function: we should allow the assignment if — for each member in that union — there exists a compatible overload. the returned type should be the union of all applicable overloads.
// current state of TS compiler, as of TS v4.3.2
function double(val: number): number;
function double(val: string): string;
function double(val: string | number): string | number {
    if (typeof val === 'string') {
        return `${val}${val}`;
    }
    return val*2;
}

const num: number = double(2); // works fine
const str: string = double('hey'); // works fine

const process = (val: string | number): void => {
    double(val); // fails with "No overload matches this call"
    const doubled: string | number = double(val); // fails for same reason
}

The externally-visible overloads of double are:
(val: number): number;
(val: string): string;

Neither overload (taken individually) can accept a val: string | number, but we can see that for each member in the union string | number, there is a compatible overload.
There's enough information here to deduce that "assigning either string or number is supported", and that "if we did so: the result would be either string or number".
In the current example, the union of applicable overloads (val: string | number): string | number happens to be equivalent to making the implementation signature visible.
but this will not be true in the general case — for example if an overload (val: Date): Date; existed: it would not be considered applicable (the implementation signature would be required to accommodate it, whereas our union of applicable overloads could exclude it).
🔍 Search Terms
No overload matches this call.
The call would have succeeded against this implementation, but implementation signatures of overloads are not externally visible.

✅ Viability Checklist

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
Elaborated in full above.
📃 Motivating Example
I hope the minimal repro above is sufficiently clear.
A brief summary could be:
Permit assignment of union-type arguments to overloaded functions, if that assignment can be satisfied by a union of overloads. This eliminates a case where the compiler might reject an assignment, stating "No overload matches this call".
💻 Use Cases
A less contrived example is what I'm trying to contribute to the Snowpack devserver code — I receive a request req: http.IncomingMessage | http2.Http2ServerRequest, and wish to pluck serializable properties off that union argument, creating a new union Http1RequestData | Http2RequestData.
/**
 * {@link http.IncomingMessage} as a value type -- exposes data properties
 * without exposing access to sockets, streams, methods or iterators.
 */
export type Http1RequestData = Pick<
http.IncomingMessage,
'aborted' | 'httpVersion' | 'httpVersionMajor' | 'httpVersionMinor' | 'complete' | 'headers' | 'rawHeaders' | 'trailers' | 'rawTrailers' | 'method' | 'url'
>
/**
 * {@link http2.Http2ServerRequest} as a value type -- exposes data properties
 * without exposing access to sockets, streams, methods or iterators.
 */
export type Http2RequestData = Pick<
http2.Http2ServerRequest,
'aborted' | 'httpVersion' | 'httpVersionMajor' | 'httpVersionMinor' | 'complete' | 'headers' | 'rawHeaders' | 'trailers' | 'rawTrailers' | 'method' | 'url' | 'authority' | 'scheme'
>
/**
 * {@link http.IncomingMessage} or {@link http2.Http2ServerRequest} as a value type -- exposes data properties
 * without exposing access to sockets, streams, methods or iterators.
 * This is provided so that users of dev-server APIs may make decisions about
 * how to route a request (or transform its response), without being able to perform
 * side-effects upon the request handle.
 */
export type HttpRequestData = Http1RequestData | Http2RequestData;

function isHttp2Request(req: http.IncomingMessage | http2.Http2ServerRequest): req is http2.Http2ServerRequest {
  return req.httpVersionMajor === 2;
}

function dataPropertiesOfRequest(req: http.IncomingMessage): Http1RequestData;
function dataPropertiesOfRequest(req: http2.Http2ServerRequest): Http2RequestData;
function dataPropertiesOfRequest(req: http.IncomingMessage | http2.Http2ServerRequest): HttpRequestData {
  // there's a large number of props common to both request types, but since they have different optionality and readonly-ness:
  // I've opted to resist doing a "destructure common props".
  if (isHttp2Request(req)) {
    const {aborted, httpVersion, httpVersionMajor, httpVersionMinor, complete, headers, rawHeaders, trailers, rawTrailers, method, url, authority, scheme} = req;
    const requestData: Http2RequestData = {aborted, httpVersion, httpVersionMajor, httpVersionMinor, complete, headers, rawHeaders, trailers, rawTrailers, method, url, authority, scheme};
    return requestData;
  }
  const {aborted, httpVersion, httpVersionMajor, httpVersionMinor, complete, headers, rawHeaders, trailers, rawTrailers, method, url} = req;
  const requestData: Http1RequestData = {aborted, httpVersion, httpVersionMajor, httpVersionMinor, complete, headers, rawHeaders, trailers, rawTrailers, method, url};
  return requestData;
}

const server: http.Server | http2.Http2Server = createServer(async (
      req: http.IncomingMessage | http2.Http2ServerRequest,
      res: http.ServerResponse | http2.Http2ServerResponse
    ) => {
  // this assignment fails!
  const requestData: HttpRequestData = dataPropertiesOfRequest(req);

  // this assignment fails too! for brevity I won't show the `convertToSnowpackResponse` function,
  // or `SnowpackHttpServerResponse` union type — it's the same idea as above.
  // mainly showing this to demonstrate that the problem hit me twice.
  const snowpackResponse: SnowpackHttpServerResponse = convertToSnowpackResponse(requestData, res);
});

Other options could be to make the union of overloads externally-visible (which means repeating yourself, and serves counter to the purpose of my providing overloads with correlated parameter/return types):
function dataPropertiesOfRequest(req: http.IncomingMessage): Http1RequestData;
function dataPropertiesOfRequest(req: http2.Http2ServerRequest): Http2RequestData;
function dataPropertiesOfRequest(req: http.IncomingMessage | http2.Http2ServerRequest): HttpRequestData;
function dataPropertiesOfRequest(req: http.IncomingMessage | http2.Http2ServerRequest): HttpRequestData {

Another option is type-narrowing & duplication at the call-site:
// recall that `type HttpRequestData = Http1RequestData | Http2RequestData;`
let requestData: HttpRequestData | undefined;
if (isHttp2Request(req)) {
  // req is narrowed to http2.Http2ServerRequest; expression returns Http2RequestData
  requestData = dataPropertiesOfRequest(req);
} else {
  // req is narrowed to http.IncomingMessage; expression returns Http1RequestData
  requestData = dataPropertiesOfRequest(req);
}
assert(requestData); // make the variable truthy from now on

this wasn't super nice because we had to add a condition, a type-guard, implementation duplication and a truthiness assertion at runtime, purely to satisfy the type-system.
for this particular feature, I have the option of hand-waving a bit — the existing code starts with req: any, downstream code assumes req: http.IncomingMessage, so I could just tiptoe around that rather than trying to retrofit typesafety.

Duplicate of #44392 and many more. This is intentional. You're free to add another signature accepting the union type.

@MartinJohns do we know the reason why this is intended? it was unintuitive to me.

It's computationally too expensive for too little of a benefit.


get working on linux-32, python 2.7

Follow-on to #9 and #8.

:star2:

This is probably because there is some missing dependencies... there is a bug in Anaconda Server preventing upload packages from this combination... the bug was fixed and will be deployed in the next release, so this will desappear after that...

We are building in conda-forge and conda-forge does not support linux32 pacakges, so closing this one now.


.Net Bug: Bing Connector and Azure AI Search Issue

Describe the bug
When using the Web Search Engine plugin and Bing Connector in combination with Azure AI Search in the same request, I occasionally encounter a 400 Bad Request error, although it works at other times.
Error Message: "Invalid chat message detected: message content must be string"
Platform

AI Model: Azure OpenAI GPT4o
OS: Windows
IDE: Visual Studio
Language: C#
Source: NuGet package version 1.17.1

@Cobra86 can you provide more details on this?

@markwallace-microsoft  - FYI


"Skipping tail of [file] as it currently doesn't exist" goes forever in log.

ideas @cjh1?

When you say forever do you mean the life time of the task? If so this is correct behavior. In a task you can define output files that you want to tail in this case stat.txt. As we are using a dummy script this file is not produced, so we get these messages. We will however have to add back the functionality that displays these tailed files as some point in the future.

I haven't seen a task complete with this message going on. Or maybe I should wait more than 10 mins.


Add kubevirt_vmi_memory_total_bytes metric

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:
/kind bug

/kind enhancement
What happened:
What you expected to happen:
virt-handler expose kubevirt_vmi_memory_total_bytes metric
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version):
Kubernetes version (use kubectl version):
VM or VMI specifications:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

@wavezhang any chance that you can provide a patch?

Hello @wavezhang! I was tackling this issue and I was wondering if Kubernetes pod metrics could be enough for this...
Could you share a use-case for this particular metric?

@ArthurSens You mean pod memory request or pod memory limit or real-time pod memory usage? None of them are accurate

Yes, I was thinking about something like kube-state-metrics or metrics-server.
They are not accurate indeed, but usually, they are enough for alerting or giving a good idea about memory usage. Is there a particular reason for having an accurate metric about total memory available for a VMI?

hi @wavezhang
Keep track of memory usage percentage to know if the VMIs deployed are being over-dimensioned or under dimensioned for a particular use case

kubevirt_vmi_memory_available_bytes - Would be available memory for the VMI, coming from DOMAIN_MEMORY_STAT_AVAILABLE
kubevirt_vmi_memory_unused_bytes - would be unused memory by the VMI, coming from DOMAIN_MEMORY_STAT_UNUSED

Examples of usage for these metrics:

(100 * kubevirt_vmi_memory_unused_bytes) / kubevirt_vmi_memory_available_bytes

Will give how much memory(percentage) is not being used in comparison with the total memory available for each VMI

Was that what you had in mind? But again, I think that both metrics can be substituted by Pod memory metrics... if you could point a use-case where the pod memory metrics are not enough, that would help a lot
I think it's doable after #3568 gets merged since memBallooing might be required for this.


Voting server on nodes does not run

Voting server on nodes does not run
result_1  | [nodemon] starting node --debug server.js
result_1  | _stream_readable.js:498
result_1  |     dest.end();
result_1  |         ^
result_1  |
result_1  | TypeError: Cannot read property 'end' of null
result_1  |     at Socket.onend (_stream_readable.js:498:9)
result_1  |     at Socket.g (events.js:273:16)
result_1  |     at emitNone (events.js:85:20)
result_1  |     at Socket.emit (events.js:179:7)
result_1  |     at endReadableNT (_stream_readable.js:913:12)
result_1  |     at _combinedTickCallback (internal/process/next_tick.js:74:11)
result_1  |     at process._tickCallback (internal/process/next_tick.js:98:9)

@gandhivikas23 are you still encountering this issue? Can't reproduce


[Lake] Build table object and interface to access/update lake data

Motivation
Rather than accessing/managing tables through files, let's abstract the tables into an object that let's us: load/save/update parquet, manage the schema, etc..
Outline:

[ ] You shouldn't have to go to GQL DataFactory or ETL to access tables
[ ] GQL + ETL should be authoritative writing mechanisms, that are updating the lake
[ ] Everything else, should be read-only from tables
[ ] Tables should be wrapped in an Object that helps to built, save, load, tables, etc..
[ ] Tables can help maintain a pointer to dataframe, reduce number of reads, handle caching, etc..

DoD:

[ ] Tables offer a clean interface to read/update data
[ ] Code is updated to use tables through their interfaces

Shouldn't the ETL do the update and the Tables object just allow you to read the tables?


 Because of that I can't remember the correct environment variable to disable overcommit when I need it in those rare cases. First I try DISABLE_OVERCOMMIT=1 git commit just to notice it was the other way around.
What do you guys think of using the reversed wording DISABLE_OVERCOMMIT=1 in addition to the normal one? It would really help and such lazy people like me and make them happy :blush:
Would happily contribute a PR if this idea is somewhat reasonable to you.

I wonder if this would really solve the problem. Would it make sense to instead log something from overcommit when it fails, informing you about how you can ignore certain hooks. Something like
✗ One or more pre-commit hooks failed.
 E.g. `SKIP=EsLint git commit`.

(preferring SKIP here over disabling overcommit as it's a more lightweight way to disable certain parts of overcommit).

Might be an idea. My first thought was that "disable overcommit" makes more sense than the other way around. Just from the speech :)
Normally I have to use it for stashing or WIP/backup commits when I intend to resume the work next day or on another machine and just want to push the branch.
But to be honest, I was not aware of the SKIP variable. Might be the solution for me because it is almost always rubocop that complains (about my binding.pry e.g.). Thanks for the idea :blush:

There's also SKIP=all which you can use in the WIP scenario you're describing.

SKIP=all is just awesome! And so much easier to remember. Thanks, everything I need :blush:


Update redis/v9

go-redis has become redis office driver,and change to redis/go-redis

Thanks for the contribution, @tsingsun 🙏🏻


Make all routes protected

Description:
Unauthenticated user can't access home route (localhost:3000/), because user will be redirected to the login page. We say home route is protected. However, other routes are not protected. Unauthenticated user can access other routes like /profile. Make sure all routes are protected.
Find a way to write this logic only once, so that we don't have to write this "redirect logic code" every time we create new component.
Acceptance Criteria:
Profile route is protected.

It is needed to create a validation backend method


Jamf Agent

The Jamf Agent process is sometimes found to be inactive.  What should I check for?

@nlecchi The JamfAgent has been deprecated since Jamf Pro 10.31.0
See https://docs.jamf.com/10.31.0/jamf-pro/release-notes/Deprecations_and_Removals.html

This issue should be renamed as: "Show Jamf Agent status only when Jamf Pro version is lower than 10.31"

Thanks both for catching this - will be adressed in next release, i might drop this check as Jamf pro 10.31 is not supported anymore anyway.

I would suggest that the UI use the JAMF Binary version information to selectively hide or show this item.  If the version is 10.31 or older show it.  If greater, hide it.    Just in case someone is still using the applicable version for some reason.


Attach generated className to another property

I use a library which has some complex components like MenuButton. Which basically consists of a Button and a Menu from the same library. MenuButton.className property is applied to a Button. And MenuButton.listClassName is applied to a Menu subcomponent. However, I can't set Menu's className using styled-components because it always sets class name to a Button component.
Is there a way to attach generated class name to another property? If not, can you accept this as a feature request?
Maybe this could be possible if generated className was given to a function in attrs, like this:
const MoreMenuButton = styled(MenuButton).attrs(props => ({listClassName: props.className}))...;

My workaround is
const StyledList = styled.div({...});

...

<StyledList
  as={({
    className,
  }) => (
    <MenuButton
      listClassName={className}
    />
  )}
/>

The above is generally what you could reach for, a component that receives className and passes it on as a different prop, although I'd very much doubt that's a good idea 😅  Closing due to inactivity


ArcCell::get can restore old values

Assume you have a thread that sets increasing values in an ArcCell (1,2,3,4...) and another thread that occasionally gets values, it seems like the ArcCell get operation can rewrite an old value because the get operation performs a put operation after cloning the value?
From ArcCell's get code
let t = self.take();
// NB: correctness here depends on Arc's clone impl not panicking .
let out = t.clone();
---- A new value that is written by another thread here will be overwritten by the put ---
self.put(t);
out

Nevermind, the set operation does its own take()


The plot_arrowmap does not display arrows

Describe the bug
I am using MNE 0.20.6-Python 3.7.6 on a Windows OS. The example code plot_evoked_arrowmap.py on  https://mne.tools/stable/auto_examples/visualization/plot_evoked_arrowmap.html does not display arrows. There is a UserWarning caused by plot_arrowmap(): Tight layout not applied. The left and right margins cannot be made large enough to accommodate all axes decorations.
Steps to reproduce
import numpy as np
from mne.datasets import sample
from mne import read_evokeds
from mne.viz import plot_arrowmap
path = sample.data_path()
fname = path + '/MEG/sample/sample_audvis-ave.fif'
condition = 'Left Auditory'
evoked = read_evokeds(fname, condition=condition, baseline=(None, 0))
evoked_mag = evoked.copy().pick_types(meg='mag')
max_time_idx = np.abs(evoked_mag.data).mean(axis=0).argmax()
plot_arrowmap(evoked_mag.data[:, max_time_idx], evoked_mag.info)

Expected results
The first picture in the tutorial https://mne.tools/stable/auto_examples/visualization/plot_evoked_arrowmap.html. It is an arrowmap.

Actual results
The topomap is shown but the expected arrows are missing. And there is a UserWarning: Tight layout not applied. The left and right margins cannot be made large enough to accommodate all axes decorations.

Additional information
Platform:      Windows-8.1-6.3.9600-SP0
Python:        3.7.6 (default, Jan  8 2020, 20:23:39) [MSC v.1916 64 bit (AMD64)]
Executable:    C:\Users\xm\anaconda3\python.exe
CPU:           Intel64 Family 6 Model 61 Stepping 4, GenuineIntel: 4 cores
Memory:        3.7 GB

mne:           0.20.6
numpy:         1.18.5 {blas=mkl_rt, lapack=mkl_rt}
scipy:         1.4.1
matplotlib:    3.1.3 {backend=module://ipykernel.pylab.backend_inline}

sklearn:       0.22.1
numba:         0.48.0
nibabel:       3.1.0
cupy:          Not found
pandas:        1.0.1
dipy:          1.1.1
mayavi:        4.7.2.dev0 {qt_api=pyqt5, PyQt5=5.9.2}
pyvista:       0.24.0
vtk:           9.0.0

Hi, Thank you for your help. I try to include that, but it doesn't work
(arrows are still missing). Where do you you include plt.ion()?  Thanks.
Daniel McCloy<EMAIL_ADDRESS>于2020年7月20日周一 下午6:17写道：

I can confirm on Linux. A quick work-around is to include import
matplotlib.pyplot as plt and plt.ion() in your script. If you do that,
you will still get the tight_layout-related warning, but the arrows will
get drawn.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/8032#issuecomment-661207287,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEPE5MAX2OQXJ4JVTKOPLDR4R3Z3ANCNFSM4PCLFF6A
.

The problem has been fixed in the current master version of MNE-Python. But even without updating, this should work (putting plt.ion() before any plotting calls; typical practice is to put it right after the import statements:
import numpy as np
import matplotlib.pyplot as plt
from mne.datasets import sample
from mne import read_evokeds
from mne.viz import plot_arrowmap
plt.ion()
path = sample.data_path()
fname = path + '/MEG/sample/sample_audvis-ave.fif'
condition = 'Left Auditory'
evoked = read_evokeds(fname, condition=condition, baseline=(None, 0))
evoked_mag = evoked.copy().pick_types(meg='mag')
max_time_idx = np.abs(evoked_mag.data).mean(axis=0).argmax()
plot_arrowmap(evoked_mag.data[:, max_time_idx], evoked_mag.info)

Thanks. I have tried the code you provided, but the arrows are still
missing.
I have also updated my MNE to the master version. But the plot_arrowmap(
evoked_mag.data[:, max_time_idx], evoked_mag.info) always causes a memory
error and the restart of the kernel. There are still no arrows.
Daniel McCloy<EMAIL_ADDRESS>于2020年7月21日周二 下午6:30写道：

The problem has been fixed in the current master version of MNE-Python.
But even without updating, this should work (putting plt.ion() before any
plotting calls; typical practice is to put it right after the import
statements:
import numpy as npimport matplotlib.pyplot as pltfrom mne.datasets import samplefrom mne import read_evokedsfrom mne.viz import plot_arrowmapplt.ion()path = sample.data_path()fname = path + '/MEG/sample/sample_audvis-ave.fif'condition = 'Left Auditory'evoked = read_evokeds(fname, condition=condition, baseline=(None, 0))evoked_mag = evoked.copy().pick_types(meg='mag')max_time_idx = np.abs(evoked_mag.data).mean(axis=0).argmax()plot_arrowmap(evoked_mag.data[:, max_time_idx], evoked_mag.info)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/8032#issuecomment-662000303,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEPE5ODPSUJMOOBOV5JL73R4XGCXANCNFSM4PCLFF6A
.

To reduce memory usage you could try avoiding the .copy() operation:
evoked.pick_types(meg='mag')
max_time_idx = np.abs(evoked.data).mean(axis=0).argmax()
plot_arrowmap(evoked.data[:, max_time_idx], evoked.info)

I'll look into the plot_arrowmap function and see if there are ways to reduce our memory usage, but it might be a couple days.

Avoiding the .copy() is not enough. There seems too much memory usage.
Great. I look forward to your magic on the plot_arrowmap function. Many
thanks.
Daniel McCloy<EMAIL_ADDRESS>于2020年7月22日周三 上午12:41写道：

To reduce memory usage you could try avoiding the .copy() operation:
evoked.pick_types(meg='mag')max_time_idx = np.abs(evoked.data).mean(axis=0).argmax()plot_arrowmap(evoked.data[:, max_time_idx], evoked.info)
I'll look into the plot_arrowmap function and see if there are ways to
reduce our memory usage, but it might be a couple days.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/8032#issuecomment-662161025,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEPE5NQG4ZINPCD2R5PGSTR4YRS7ANCNFSM4PCLFF6A
.

@wsxmxm I finally had time to look into this, and honestly I can't understand why you keep hitting memory errors.  The code sample I entered above uses less than 200 MiB in my testing, and after a fair bit of profiling I can't see any obvious way to trim that down:

about 3/4ths of the memory usage is just from loading the libraries
only about 37 MiB are allocated during the call to plot_arrowmap()
of that 37 MiB, about 29 MiB are allocated by matplotlib for the figure creation and tight_layout.

In sum, there is very little to be done here to reduce memory usage here.  Since your system has 3.7 GB of RAM, this really ought to be possible for you to run (as long as you don't have several other programs running at the same time, using up memory).

Hi, many thanks for your double checking. I still have the strange memory
usuage problem. I will try to check on another computer. Thank you again
for helping me.
Daniel McCloy<EMAIL_ADDRESS>于2020年8月7日周五 上午3:13写道：

@wsxmxm https://github.com/wsxmxm I finally had time to look into this,
and honestly I can't understand why you keep hitting memory errors. The
code sample I entered above uses less than 200 MiB in my testing, and after
a fair bit of profiling I can't see any obvious way to trim that down:

about 3/4ths of the memory usage is just from loading the libraries
only about 37 MiB are allocated during the call to plot_arrowmap()
of that 37 MiB, about 29 MiB are allocated by matplotlib for the
figure creation and tight_layout.

In sum, there is very little to be done here to reduce memory usage here.
Since your system has 3.7 GB of RAM, this really ought to be possible for
you to run (as long as you don't have several other programs running at the
same time, using up memory).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/8032#issuecomment-670142318,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEPE5JETR2HEXRBFLTR5JTR7L6ETANCNFSM4PCLFF6A
.


Reduce _app bundle size to improve load time

Changes proposed
Import IconContext directly in NavBar.
Use getIcon to import icons in NavBar & Footer.
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.

I wonder if every import of react-icons/* should be converted?

Probably, but I picked the profile page & _app because the icons had the most effect on initial JavaScript load.

Sure 👍 the others like Alerts etc can come in another PR


App don't run

When I run my app including this addon, it output a lot of error messages and don't work.
Error messages are following.
[ error ] ofGLUtils: ofGetGLInternalFormatFromPixelFormat(): unknown OF pixel format-1, returning GL_RGBA
[ error ] ofGLUtils: ofGetGLFormatFromPixelFormat(): unknown OF pixel format-1, returning GL_LUMINANCE
[ error ] ofTexture: allocate(): ofTextureData has 0 width and/or height: 0x0
......
So I tried to uncomment 'ofxBlackMagic::getColorPixels()' line 80 - 83, it work.

Had the same issue here with my UltraStudio Mini recorder, did uncomment the lines and worked perfect.
Seems like the controller.rgbaFrame  colour conversion using DeckLink SDK it's not working.

Hi,
I can confirm that the color conversion using the DeckLink SDK is working.
You are getting these messages because there is still no rgbaFrame available, and therefore colorPix has not been allocated yet.
If I use the example project included, you could simply wait for a frame before drawing the color texture:
	void draw() {
        if (ofGetFrameNum() <= 1) {
            return;
        }

		cam.drawColor();
		ofDrawBitmapStringHighlight(ofToString((int) timer.getFramerate()), 10, 20);
	}


Clean up and fix ColorTrack

Various fixes/cleanup, including:

Fixing time calculation for videos longer than 1 minute
Making script work on multiple lines at once
Improving perfomance of ffmpeg on longer videos by cutting times before demux
Making most variables/functions local
Moving many parts of code into separate functions
Removing never-called parts of code

The problem is in the remainder ms calculation.

Interesting. Can you provide a sample which produces this behavior? I'm not quite sure I understood what you meant. I'll try to look into it soon.On May 29, 2022 17:07, Zahuczky @.***> wrote:
The problem is in the remainder ms calculation.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Change first ffmpeg run to
petzku.io.run_cmd("ffmpeg -ss "..starttime.." -an -sn -i \""..aegisub.project_properties().video_file.."\" -q:v 1 -vsync passthrough -frames:v "..numOfFrames.." -pix_fmt rgb24 \""..tmp..pathsep.."frame%%d.png\"",
or equivalent. That should fix it.

Whatever it'll get updated soon anyway.


Email validation reentry - continuing to main screen

Email validation takes you to a page, from which there needs to be a continue button to the CarbonSaver, or bring you in. Or back to the sign-in page if that is not possible

Fixed, I’ll open PR for this


xtensa/espressif/rmt: Implement a common RMT (Remote Control) driver for xtensa-based devices.

Summary

drivers/rmt: Implement an upper-half RMT character driver

The RMT (Remote Control) character driver allows to use the RMT peripheral (usually, a one-wire peripheral dedicated to driving IR remote control) as a character driver.

drivers/leds/ws2812: Fix WS2812 pixel size

Although the LED might be RGB-only, the LED data is packed in a 32-bit long variable and, then, this is the default size of a LED pixel to define the 'WS2812_RW_PIXEL_SIZE' macro. Please note that the lower-half driver will deal with the case of the addressable LED being 3 or 4-pixel sized.

xtensa/esp/rmt: Add the lower-half implementation of the RMT driver

The lower-half implementation of the RMT character driver based on Espressif HAL enables using the RMT peripheral of ESP32, ESP32-S2 and ESP32-S3 as a common xtensa-based Espressif driver.

xtensa/esp/ws2812: Add the lower-half WS2812 driver based on RMT

This lower-half WS2812 LED driver uses the RMT peripheral of the Espressif's SoCs to drive the RGB addressable LEDs. Compared to the SPI-based implementation, it is faster!

esp32s3: Fully integrate Espressif HAL repository to ESP32-S3

By integrating the Espressif`s HAL repository into the current ESP32-S3 implementation on NuttX, it is possible to call functions that make it easier to set up the registers of the ESP32-S3 and enable the usage of common Espressif drivers. Please note that Espressif's HAL repository was already being used for the Wi-Fi driver.

esp32s3/rmt: Use the Espressif's common RMT driver.

This commit use the new common RMT driver for all Espressif's xtensa-based chips on ESP32-S3.

esp32s2: Integrate Espressif HAL repository to ESP32-S2

By integrating the Espressif`s HAL repository into the current ESP32-S2 implementation on NuttX, it is possible to call functions that make it easier to setup the registers of the ESP32-S2, enabling the usage of common Espressif drivers.

esp32s2/rmt: Use the Espressif's common RMT driver.

This commit use the new common RMT driver for all Espressif's xtensa-based chips on ESP32-S2.
Impact
Implement a common RMT driver for xtensa-based devices. ESP32 requires updating the Wi-Fi driver to enable using the HAL (and the common RMT driver)
Testing
Internal CI testing + ESP32-S2-Saola-1 board and ESP32-S3-DevKitC-1 v1.0 board (loopback test + WS2812 LED strip)

but, it's good to use the vendor hal file directly

I'm sorry, I didn't understand what you meant. Could you please elaborate a little further?

but, it's good to use the vendor hal file directly

I'm sorry, I didn't understand what you meant. Could you please elaborate a little further?

All upstream code never calls vendor HAL directly, only download and  link the static library.

but, it's good to use the vendor hal file directly

I'm sorry, I didn't understand what you meant. Could you please elaborate a little further?

All upstream code never calls vendor HAL directly, only download and link the static library.

Oh, I see... this commit isn't about the "HAL", it's about the implementation of a common driver that is valid for all Espressif's xtensa-based devices. The same "common driver" approach is true for RISC-V-based devices, like ESP32-C3, ESP32-C6, ESP32-H2, for instance.
Espressif is making a huge effort to avoid using closed static libraries: we plan to provide as much as possible the sources. Specifically for NuttX, we are just using header files and building specific auxiliary functions. There is no direct usage of "Espressif's HAL" on NuttX. Drivers' code and HAL-adapters are implemented on NuttX. Please note that the same is valid for the Wireless driver of xtensa-based SoCs.

but, it's good to use the vendor hal file directly

I'm sorry, I didn't understand what you meant. Could you please elaborate a little further?

All upstream code never calls vendor HAL directly, only download and link the static library.

Oh, I see... this PR isn't about the "HAL", it's about the implementation of a common driver that is valid for all Espressif's xtensa-based devices. The same "common driver" approach is true for RISC-V-based devices, like ESP32-C3, ESP32-C6, ESP32-H2, for instance.
Espressif is making a huge effort to avoid using closed static libraries: we plan to provide as much as possible the sources. Specifically for NuttX, we are just using header files and building specific auxiliary functions. There is no direct usage of "Espressif's HAL" on NuttX. Drivers' code and HAL-adapters are implemented on NuttX. Please note that the same is valid for the Wireless driver of xtensa-based SoCs.

Just to make sure: please note that there is no generic code. The repository being downloaded is dedicated to providing sources being used on NuttX:
Similar approach with other manufacturers' implementation:

https://github.com/apache/nuttx/blob/master/arch/arm/src/nrf52/CMakeLists.txt
https://github.com/apache/nuttx/blob/master/arch/arm/src/nrf52/CMakeLists.txt
https://github.com/apache/nuttx/blob/master/arch/arm/src/nrf91/CMakeLists.txt
https://github.com/apache/nuttx/blob/0eeca0f3751876fc090108d01156d0999dd02116/arch/risc-v/src/bl602/Make.defs

Thanks for explanation, the change looks good to me.

@tmedicci hi, why is this driver not in drivers/rc ? can't this be implemented with common  drivers/rc/lirc_dev.c instead of creating vendor-specific drivers?

here is what I mean:

Hi @raiden00pl , I may have understood your concerns wrongly, but the current implementation is more like the GOOD than the BAD. See, let's check nuttx/boards/xtensa/esp32s3/common/src/esp32s3_board_rmt.cs board_rmt_txinitialize. This function initializes both the generic RMT driver and the RMT-based WS2812 driver.
Note that, the RMT peripheral is initialized by esp_rmt_tx_init, which is arch-specific (lower-half). Although not implemented, calling rmtchar_register here to register the generic RMT driver is totally optional. esp_ws2812_setup uses the lower half initialized by esp_rmt_tx_init.
Backing to esp_rmt_tx_init: it calls esp_rmtinitialize which registers priv->ops = &g_rmtops; here. g_rmtops registers the esp_rmt_read and esp_rmt_write to struct rmt_ops_s's read and write. Both esp_rmt_read and esp_rmt_write are implemented by arch code (lower-half): this seems to be the "RMT_COMMON".
esp_ws2812_setup receives a structure of the RMT lower-half driver initialized by esp_rmt_tx_init. The registered write function for struct ws2812_dev_s is esp_write (defined at arch/xtensa/src/common/espressif/esp_ws2812.c, i.e. a lower-half interface). This function end-up calling priv->rmt->ops->write(), which is the esp_rmt_write function of the lower-half driver (not the upper-half). As we used commonly-used names (read/write), this may have caused the confusion here.
Also, please note that the struct rmt_ops_s (at include/nuttx/rmt/rmt.h) isn't part of the upper-half generic RMT driver (nuttx/include/nuttx/rmt/rmtchar.h. I agree that the location of the
rmt.h file could be understood like that (and should eventually be moved to the arch folder, although it is used by more than a arch)

Also, please note that the struct rmt_ops_s (at include/nuttx/rmt/rmt.h) isn't part of the upper-half generic RMT driver (nuttx/include/nuttx/rmt/rmtchar.h. I agree that the location of the
rmt.h file could be understood like that (and should eventually be moved to the arch folder, although it is used by more than a arch)

My reasoning is that if it's in the common driver headers (include/nuttx/rmt), then it's upper-half part. So here is our difference :)
RMT upper-half itself seems to be wrong, as it's architecture specific driver. ESP architecture logic should implement RMT_COMMON and then based on RMT_COMMON there should be lower-half implementation for rc/lirc_dev.c and WS2818_UPPER.
Currently we have 2 drivers implementing IR driver that are incompatible with each other, which means there is no way to have a portable architecture between different vendors. Especially when drivers/rc was already upstream.

We can move it to arch folder. It's used by both xtensa and RISC-V.

The point is that the entire RMT driver belongs to arch and should be moved there.

It isn't, it's used by either RISC-V and xtensa devices with the RMT peripheral.

I can't agree here. It's vendor specific driver, only used by ESP chips, so it should be in arch. A long time ago there was a similar case with HRTIM which is a peripheral specific to STM32. It can be used to implement other drivers like PWM, SMPS and so one. My initial implementation also included an upper-half driver in drivers/hrtim which was eventually rejected by Greg, because it's and stm32-specific driver. It doesn't matter if it is present in stm32f3, stm32g4 or stm32h7, it is still a stm32-specific peripheral and of course Greg's decision was justified and correct.

We did this exactly the way you described for WS2812 upper-half. We didn't implement it for RC, but we encourage community to do it (and we can help with testing and validation). Then, I agree that we could even remove the RMT upper-half driver (nuttx/drivers/rmt/rmtchar.c) because it isn't coupled with the lower-half implementation.

RMT shouldn't be in drivers/ in the first place, it belongs to arch (yes, I know, I'm repeating myself :P) and IR feature should be provided with already present driver that provides good and standardized abstraction: drivers/rc/lirc_dev.c. Otherwise it looks to me like a violation of INVIOLABLES.md:
### No Short Cuts

  - Doing things the easy way instead of the correct way.
  - Reducing effort at the expense of Quality, Portability, or
    Consistency.
  - Focus on the values of the organization, not the values of the Open
    Source project.  Need to support both.
  - It takes work to support the Inviolables.  There are no shortcuts.

I agree that this is partially true for the RMT peripheral, but users can move between different devices/architectures (from ESP32 to ESP32-C3, for instance). About WS2812, this isn't true: the same application (https://github.com/apache/nuttx-apps/tree/master/examples/ws2812, for instance) can be used by any chip/arch/vendor that implements the driver.

I don't see a problem with WS2812, the problem is in RMT.
I wouldn't call the interchangeability of chips in a given vendor portfolio good architecture. Good architecture is when I can replace chip from one vendor to a chip from other vendor. Of course, assuming that the chips have the same capabilities.

In general, I agree with your considerations regarding the driver organization, but I'm not convinced that we aren't providing that. Not allowing binding a peripheral to an existing upper-half driver is different from providing an upper-half driver for a peripheral whose capabilities are not covered by the existing upper-half drivers. We implement our drivers thinking that they could be bound to any other existing driver (just like the ws2812 upper-half driver)

There is no feature that RMT implements that cannot be implemented with existing portable drivers. IR with drivers/rc/lirc_dev.c, and ws2812 as it's implemented now, but with the difference that esp-specific ws2812 implementation use esp-specific API for RMT.

The point is that the entire RMT driver belongs to arch and should be moved there.

Let's avoid using RMT generically. I suppose you didn't mean to move drivers/rmt/rmtchar.c to arch folder, right? It's clearly an upper-half driver and totally optional. It's just an interface to the lower-half.

It isn't, it's used by either RISC-V and xtensa devices with the RMT peripheral.

I can't agree here. It's vendor specific driver, only used by ESP chips, so it should be in arch.

You've said earlier:

RMT upper-half itself seems to be wrong, as it's architecture specific driver.

And I just said that it isn't architecture specific. It's vendor-specific (at least for now), not arch-specific.

RMT shouldn't be in drivers/ in the first place, it belongs to arch (yes, I know, I'm repeating myself :P) and IR feature should be provided with already present driver that provides good and standardized abstraction: drivers/rc/lirc_dev.c.

I suppose you are referring to include/nuttx/rmt/rmt.h, right? If so, as I've said earlier: it isn't related to the upper-half driver and it can be moved to the arch. I'm not that convinced that it's in the wrong place because it's totally decoupled with the upper-half RMT driver (drivers/rmt/rmtchar.c) and its header file (include/nuttx/rmt/rmtchar.h), but we can move it to arch folder (duplicating it for xtensa and RISC-V).

I don't see a problem with WS2812, the problem is in RMT.

Now I suppose you are referring to drivers/rmt/rmtchar.c, right? If so, I said earlier that this upper-half driver isn't needed for WS2812.

and ws2812 as it's implemented now, but with the difference that esp-specific ws2812 implementation use esp-specific API for RMT.

I'm not sure if I got your point here. The "common" API it uses is defined at include/nuttx/rmt/rmt.h. If we simply move it to arch-folder without any modification it'd be called "esp-specific API for RMT"? If so, again, I'm not against it...

There is no feature that RMT implements that cannot be implemented with existing portable drivers.  Our main goal is to provide support for the peripherals. Unfortunately, we have limited resources to create bindings to all of those upper-half driver, so we implemented the RMT lower-half driver and bound it with an existing upper-half driver (ws2812). Then, we provided a generic API for users to deal directly with the RMT peripheral (drivers/rmt/rmtchar.c). As soon as people bind the lower-half driver with the existing upper-half drivers, RMT upper-half wouldn't be necessary anymore and can be removed. There is a difference between the good and the needed.

Let's avoid using RMT generically. I suppose you didn't mean to move drivers/rmt/rmtchar.c to arch folder, right? It's clearly an upper-half driver and totally optional. It's just an interface to the lower-half.

If you want to stick with RMT character driver then yes, I mean to move it to arch/ folder. You can grep arch/ for register_driver and you can see that there is nothing wrong with upper-half arch-specific implementations in arch/.

And I just said that it isn't architecture specific. It's vendor-specific (at least for now), not arch-specific.

We can argue whether it's arch-specific or vendor-specific. This doesn't make sense to me, since both should be placed in arch/. We have here similar case as the HRTIM I mentioned earlier and the solution should be the same.

There is a difference between the good and the needed.

Again, this approach is against INVIOLABLES.md, but I understand that we are all busy and don't have time to do everything we would like to. In that case I propose to create an issue to not forget about this problem and in the future avoid vendor/arch specific drivers in drivers/ if possible.


request: command option count for jfrog rt s

Hi.
It would be great if there was a command option for Artifactory's search which would return for the given search criteria the only the number of found artifacts instead of JSON result.
Example:
$ jfrog rt s --count-only "frog-repo/rabbit/*.zip"
$ 42

Thanks in advance!

@sdrzazga,
You can easily count wuth the help of jq.
Here's how you do it:
$ jfrog rt s "frog-repo/rabbit/*.zip" | jq length
[Info] Searching artifacts...
[Info] Found 42 artifacts.
42

Only 42 is printed into stdout, so you don't need to worry about the Info logging.
Please let me know if this helps.

@eyalbe4
It is certainly one way to solve it.
However, it always requires a dependency on another program to do this job and additional piping which reduces readability. Also, piping doesn't work on windows system unless they have gnu tools installed. It is also not installed in the docker image for jfrog-cli.
Anyways, I would find it the easiest and most versatile option if it was implemented in frog-cli itself since you have the information there already instead of relying on something external.
Wouldn't you agree?

Agree @sdrzazga -
@AlexeiVainshtein created https://github.com/jfrog/jfrog-cli/pull/412 to allow this.

I believe this was implemented with 1.27.0 (Aug 16, 2019 - https://bintray.com/jfrog/jfrog-cli-go/jfrog-cli-linux-amd64#release):
"New --count option added to the search command."


jsx-no-target-blank: Allow to specify allowed hosts

This rule is great to prevent the target="_blank" security vulnerability, but there are times where you wouldn't want to set noreferrer, such as if you're linking to another website under your control.
For theses cases, instead of manually overriding each line, I think it would be useful to be able to pass an "allowedHosts" option, so the rule would allow static href values that have one of these hosts.

Why would you want target blank when a user is navigating within your own site? Target blank is a bad UX practice overall.

@ljharb Not within the same site, but between different sites that I control. Let's say between app1 and app2 and my landing page. I want to be able to track interactions & conversion, and I know these destinations won't abuse the Referer header.

@adarnon sure, but why would you want those to open in a new window?
In general, forcing a new window/tab on the user is rude; every browser and platform has an "open in new tab/window" idiom that a user who wants a new tab/window already knows how to use (the ones who don't, don't want it).

@ljharb I don't think the purpose here is to discuss UX... There are links, such as a link to my company's Terms of Service, that in my opinion should open in a new window.

If the ask is for a new linter rule, then one that enables poor UX means that UX is certainly worth discussing.
Do those cases happen often enough that an eslint override comment is insufficient?

Linters are meant to prevent programmer errors, not poor UX decisions. Target _blank is a necessary tools sometimes, and the purpose of this rule is to prevent security errors that this feature causes, not to prevent its usage overall.
I believe that eslint override comments should only be used when there's absolutely no other choice. They're hard to maintain and using them misses out on a big benefit of linter config - having a uniform way to do things across the entire app.
In this case, I think there's a generic use case for allowing certain hosts through without having to set noreferrer. When the string is static and not dynamic, and the user knows they're passing the call to a domain they control, the risks are minimal. Having an eslint override is dangerous - if sometime in the future someone changes the link href and forgets to remove the comment.

Poor UX decisions are programmer errors :-)
You're totally right about the purpose of this rule.
Having the config you're asking for is equally dangerous - if sometime in the future you no longer control that domain.

I also am looking for an option like this.  I have a few links to docs articles from my app, which I want to open in a new tab to avoid accidentally disrupting the user's work (please don't argue the UX of this, that's not the point).  I'm not worried about losing control of my docs website.  As it is, I need to manually disable every link to these docs.  I'm tempted to disable the rule in general because of the bad DX.  I hope you'll reconsider this decision, and permit an option to allowlist particular hostnames.

I'm not sure how the "UX of this" isn't the entire point?

This rule isn't "no-target-blank".  The rule is to avoid security issues when linking to sites that are not under your control.

The first line of the rule's docs is:

When creating a JSX element that has an a tag, it is often desired to have the link open in a new tab using the target='_blank' attribute.

So, the rule admits that it's a desired thing to do.  Then it says the purpose of the rule, (which is not to prevent all use of target=_blank):

This rule aims to prevent user generated link hrefs and form actions from creating security vulnerabilities by requiring rel='noreferrer' for external link hrefs and form actions.

So, what's being proposed here is greater control over what is considered "external", that's all.

That's fair that the docs imply what you're saying - but the rule's name implies what i'm saying.
allowedHostnames seems interesting, but using URL, which isn't available until node 10 (we support node 4) isn't an option.


Fix comments following documentation incorrectly reported

[x] Add regression tests for #1132
[x] Fixes #1132

:bulb: Can you include the following in your test as well?
/** <summary>more documentation.</summary> */
/* another comment */
public void TestMethod2() { }

I'll leave that test for a separate issue actually.


docs: Modified README.md Issue#50

Tag the issue you've solved and tag the moderators

@Suryanshu-09 Make your own Readme template we want you to learn as much as possible . Learning mark down will help you in the long run.


chore(main): release 1.6.0

:robot: I have created a release beep boop
1.6.0 (2024-05-22)
Features

delete-record (wip) (a48e5c9)

Bug Fixes

delete records (1b2a42d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/pythoninthegrass/gopappy/releases/tag/v1.6.0 :sunflower:


New App: Christmas Countdown

Description
Displays an animated tree along with "Merry Christmas" and (optionally) the number of days until Dec. 25.
Copilot

🤖[deprecated] Generated by Copilot at dcb84ba
Summary
📝📦🚀

This pull request adds documentation and a manifest file for the christmascountdown applet, which shows the days, hours, minutes, and seconds until Christmas on the Tidbyt device. These changes are necessary for publishing the applet to the Tidbyt app store and making it available for users to install and enjoy.

christmascountdown
A festive applet for Tidbyt
Comment and manifest

Walkthrough

Add a manifest file for the christmascountdown applet (link)
Document the applet name, summary, description, and author in a comment block in christmascountdown.star (link)

I have read the CLA Document and I hereby sign the CLA


macro use full name as default

Signed-off-by: Andy Lok<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 13 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.08%) to 80.962%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

minitrace-macro/src/lib.rs
0
13
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
1667

Relevant Lines:
2059

💛  - Coveralls


Theme type:light is ignored, wrongly detected as dark theme

Does this issue occur when all other extensions are disabled?: Yes

VS Code Version: 1.63.1
OS Version: Manjaro 21.2.0, 5.4.164-1

Steps to Reproduce:
This extension has "type": "light" set in its -color-theme.json, but VSCode ignores that and still shows it listed under dark themes regardless and applies .vs-dark to the monaco-workbench div. This results in bad contrasts, some wrong colors etc. I checked, the the GitHub json is not different from the one contained in the extension.
Maybe the author applied some ambiguous colors or misconfigured something, but with type:light set, this must never happen and is surely a bug.

Maybe value in package.json is overriding it?
https://github.com/manekinekko/windows-nt-vscode-theme/blob/5c0e241c2c3497299ba7d43ee1db0512eb963b97/package.json#L48

What matters is the value in the package.json. The color-theme file format does not really have a type attribute.


fix(Lint): Fix linter

Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 8.27%. Comparing base (17abf7e) to head (c70f967).
Report is 1 commits behind head on master.

Files with missing lines
Patch %
Lines

.../AffectedClustersTable/AffectedClustersTable.cy.js
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff            @@
##           master    #823      +/-   ##
=========================================
- Coverage    8.27%   8.27%   -0.01%
=========================================
  Files          68      68
  Lines        3952    3953       +1
  Branches      864     864
=========================================
  Hits          327     327
- Misses       3625    3626       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:tada: This PR is included in version 1.45.9 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


options: "files" throwing errors when passed basic string input, unable to find app root directory

Hi there,

Running stylelint '**/*.css' in CLI works as expected.
Configuring it through this package does not seem to get any matches. For all of the commented-out patterns I've tried (see the gist), I get:
Error: Files glob patterns specified did not match any files
The only exception to point 2 is '../../**/*.css'; this path begins to lint css in the node_modules folder.
If I try to go one level up, I get:
a EISDIR: illegal operation on a directory, read.
I get the same effect for all cases if I remove the configBaseddir, and configFile configuration properties.

This might be multiple separate errors. It looks like something is wrong with the way files is sending the glob pattern, and we're stuck searching for matches over contents of the stylelint folder, instead of the directory we want. In addition, when we go up enough levels, the plugin seems to be trying to access directories as files (point 4).
What do you think?
webpack.config.js below:
https://gist.github.com/sdtsui/feb5f1de7c7c53e6e42180f201d890cd
Thanks!
p.s. for completeness, here is my package.json, with the lint-css script that works.
https://gist.github.com/sdtsui/a16a054228999f9150bb0fadc6f6d647
I'm on Node v5.5.0.

forgot to name issue. closed and re-opened.

Hi @sdtsui
I see some things that could cause the problem:

You shouldn't set options.context to 'inherits from webpack'. You should specify a base path, or nothing and the plugin will take the path from the webpack context.
Sorry because the readme is not clear enough.

If you want to lint scss, you should also set the syntax option to scss (http://stylelint.io/user-guide/node-api/#syntax)

Also, configBasedir is not a valid option.

Let me know if that fix the problem.

@vieron Thanks! Makes sense -- wasn't thinking about options.context.

You shouldn't set options.context to 'inherits from webpack'.
why don't you just delete(/comment/etc) it from options example on README so devs will not be confused?