BNO085 IMU support

Description
The existing code supports GY-50 IMU https://github.com/rosmo-robot/smartcar_shield/tree/master/src/sensors/heading
Definition of Done
It is possible to use BNO085 IMU with this lib

If someone really wanted to integrate this, it'd be relatively simple considering that Adafruit has done a good job on creating a very easy library.
If you really want, I can create an simple wrapper for it, which would make it compatible with the rest of the Smartcar library, but I will not be including it in the "upstream" Smartcar library for reasons we've previously discussed if  I am not mistaken.
I don't have the means to test it and I will not be creating unit tests for it, but it looks simple enough to minimize the chances of issues.

A wrapper would be great, thanks I'll order one and can test it.

@samuk  who is @platisd ?

@platisd is the boss :)
He developed the original hardware platform, he also wrote and maintains the Smartcar Shield library

ok


ticker: 4.3.0 -> 4.4.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/ticker/versions.
meta.description for ticker is: "Terminal stock ticker with live updates and position tracking"
meta.homepage for ticker is: "https://github.com/achannarasappa/ticker"
meta.changelog for ticker is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
/nix/store/gs39c2fc7i5wx4j1aa7fgmzlgfsi4wzs-ticker-4.4.4/bin/ticker passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 4.4.4 with grep in /nix/store/gs39c2fc7i5wx4j1aa7fgmzlgfsi4wzs-ticker-4.4.4
found 4.4.4 in filename of file in /nix/store/gs39c2fc7i5wx4j1aa7fgmzlgfsi4wzs-ticker-4.4.4

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
docbookrx
ticker

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gs39c2fc7i5wx4j1aa7fgmzlgfsi4wzs-ticker-4.4.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ticker https://github.com/r-ryantm/nixpkgs/archive/c49815a8e93c126dc1aedff403aeb9d36d578280.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gs39c2fc7i5wx4j1aa7fgmzlgfsi4wzs-ticker-4.4.4
ls -la /nix/store/gs39c2fc7i5wx4j1aa7fgmzlgfsi4wzs-ticker-4.4.4/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ticker

Maintainer pings
cc @siraben @kalbasit for testing.

Result of nixpkgs-review pr 151712 run on x86_64-darwin 1

1 package built:

ticker

Looks good to me. I put all my money into GameStop because of this package.
$ nix run github:r-ryantm/nixpkgs/auto-update/ticker#ticker -- -w GME,AAPL,TSLA


Add status page for service

It would be helpful to have a page status page (like https://www.githubstatus.com/) that shows the current state of the service. We had an issue where our contributors file had a typo, and knowing the service was still running would have narrowed down the troubleshooting process.

That’s a good point - although as this used a serverless architecture, there isn’t a container of server to ping for status check.
One other thing I could do is promote the playground:
https://github.com/ColinEberhardt/cla-bot-playground
This is a repo where you can experiment with the bot. I created it but haven’t really promoted it yet!


Assigning Service # to Resource Account

On this page, under 'Prerequisites to assign a phone number to a resource account' bullet 6, it is confirmed the that new prerequisites for assigning a service number to a resource account is E1, E3 + Phone System or E5. A calling plan is not needed. Also, when assigning a service number to a resource account; 1. You'll need to wait up to 24 hours after assigning the necessary subscription and 2. Don't search for the service number by area code but by country code which will then display all acquired non-assigned service numbers that are available to be assigned to a resource account.

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

ID: 81fa6268-92b2-546f-9200-f323bb48e90e
Version Independent ID: 6ce89bc0-ae69-b6f1-df50-532e46b2e67b
Content: Manage resource accounts in Teams
Content Source: Teams/manage-resource-accounts.md
Service: msteams
GitHub Login: @jambirk
Microsoft Alias: jambirk

@LDolce @ Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

@officedocsbot assign @scanum

@LDolce Thank you for reaching out and helping improve MS Docs.  Just for clarity, are you suggesting adding a note in the article with your suggestions.

Yes. The key points I submitted would really help reduce new and re-opened
service requests on this issue.
On Thu, Jul 4, 2019 at 7:55 AM Lindsay<EMAIL_ADDRESS>wrote:

@LDolce https://github.com/LDolce Thank you for reaching out and
helping improve MS Docs. Just for clarity, are you suggesting adding a note
in the article with your suggestions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/2539?email_source=notifications&email_token=AFJTHJIKL4IA3347OENLSGDP5XQMBA5CNFSM4H4APA5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZHGWZI#issuecomment-508455781,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFJTHJJN3NMGIRHXYWPI6LTP5XQMBANCNFSM4H4APA5A
.

--
Mobile:<PHONE_NUMBER>
https://www.linkedin.com/in/ldolce

THIS EMAIL IS INTENDED ONLY FOR THE USE OF THE PERSON(S) OR OFFICE TO WHOM
IT IS ADDRESSED, AND CONTAINS PRIVILEGED OR CONFIDENTIAL INFORMATION
PROTECTED BY LAW.  IF YOU HAVE RECEIVED THIS FAX IN ERROR, PLEASE DESTROY THE
ATTACHED DOCUMENT(S) AND NOTIFY THE SENDER OF THE ERROR BY CALLING
(754)800-9791.  THANK YOU.

@Waseemhashem please verify the action needed here. @Ldolce we recently updated the info for the zero cost licenses,  it may already be handled

This is very confusing between what is here and on the issue  I submitted here.
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/2628
So to assign a service number to a resource account I need a E level subscription Phone System, and no calling plan? Then what is the "Virtual Phone System" addon used for? Also, if no calling plan is required , then how are voice minutes applied -   if connected to a user and then pulls from their pool of minutes? I know things are in transition from SfB but this is a bit confusing and it seems no matter how I license a resource account I can't assign a service number.  (It also doesn't really make sense that a non login autoattendant account needs an E-level license for this? Is that really correct?)

@mbigus - this might help. @jambirk FYI

Get a service number by going to Voice > Get phone numbers* or porting (transferring) one from a carrier.
In  Org-wide settings > Resouce accounts create a resource account and add select whether it's an auto attendant or call queue.
Buy a Phone System license or get a Phone System Virtual User license.
Buy a Domestic or International Calling Plan.
Assign the Phone System or a Phone System Virtual User license to the resource account.
Assign the Phone System or a Phone System Virtual User license to the resource account.
Assign a Commmications Credits license to the resource account.
Set up Communication Credits and set up auto-recharge for your organization.
In  Org-wide settings > Resouce accounts > Assign/Unassign, assign the service number to the resource account (that you assigned the license to).
In Voice > Auto attendants or Call queues, create your auto attendant or call queue.
When you are creating the auto attendant or call queue, click Add accounts then search for the resource account you created in Step 2.
If you already have an auto attendant or call queue created and want to use this new resource account,  you need to link the resource account by clicking in  Org-wide settings > Resouce accounts > Edit and under Resource account, select the correct voice service (whether it's an auto attendant or a call queue.

@LDolce Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


Unable to compile Bonfire: Repeat a string repeat a string

Challenge Bonfire: Repeat a string repeat a string has an issue.
User Agent is: Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.
I am unable to compile my code below. This is a repeat of same issue on this Bonfire.
Please, how do I resolve this?
My code:

function repeat(str, num)
{
   if (num === 0)
    {
      return str;
    }

  if(num < 0)
    {
      return null;
    }

  // repeat after me
  var newString1 = str.split(",");
  var newString2 = [];

  while(num > 0)
    {

      for(var i = 0; i < newString1.length;i++)
        {
         newString2 = newString1.push(newString1[i]);
        }

       --num;

    }

 return newString2.join('');

}

repeat("abc", 3);

Your code takes too long to complete or contains an infinite loop.  And here is what I get in the console:

Ok. I'll take a look, review the code and revert. Thanks @jlslew

Closing as not an issue with the tests, but please feel free to reply if you need further clarification.
Thanks and happy coding!


Patch 1

Thank you for sharing leonel.
But this pull request is from an unknown branch into the main branch.
Please create a pull request on the respective branch and make a pull request from the exact same branch on your forked repo.


Updated virtual-hyperscript dependency

Resolve for #24 issue

virtual-dom has a lot of dependencies so I just added parse-tag into this library and removed the virtual-hyperscript dependency

Updated in v2.4.2


Ori and the Blind Forest shows warnings

Software information
Ori and the Blind Forest (Steam, Definitive Edition)
XBox One S Controller
Full Screen, Full HD, Vsync, all details
System information

GPU: NVIDIA GTX 1050 Ti 4 GB
Driver: Proprietary 396.51.0
Wine version: 3.14
DXVK version: 0.70

Log files

d3d11.log: oriDE_d3d11.log
dxgi.log: oriDE_dxgi.log

While the game seems to work perfectly (I completed it 80% now, no crashes, no graphical glitches), I see some errors and warnings in the log. Is anything here critical or important to be supported by dxvk?

Nothing to worry about here - just some DX11.2 warnings, but the game doesn't require it, and a lot of warnings about a format that doesn't actually exist. Unity Engine loves to do that for some reason.


Would it be better if i fine-turn the model on my dataset？

Hi, author. thank you for your good job！I have run the hfnet for retrieval and the result is perfectly good.
But i wanna know that Would it be better if i fine-turn the model on my dataset？
i have no ground truth, learn your code, i find the GT is from NetVLAD and SuperPoint, so i'm not sure it's useful to fine-train...
thanks for your time！

Hi there,
You could indeed run the distillation on your dataset if you believe that it is substantially different from the one we used (Google Landmarks). All is required is a folder of diverse images, ideally in a large number (>200k).
If you only need retrieval and do not care about efficiency, then you could use NetVLAD. If you still want to use HF-Net, then you could first check that it actually performs sufficiently lower than the baseline NetVLAD+SuperPoint on your kind of data. If so, you can do distillation following the instructions here (see also issue https://github.com/ethz-asl/hfnet/issues/5).


fix: Update required ibm provider version to >= 1.56.1

/run pipeline

@akocbek looks like fscloud profile was missed

/run pipeline

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


More nmap features

UDP scanning
Service scan
Top 1000 ports
Scanning multiple IP's / subnet

Emulating UDP scanning is more difficult than I thought. Because of its connection-less nature, you need to send something over UDP and then wait for a response... The problem is if you don't send something valid it typically won't respond. This means that UDP would need to send service-specific requests. That's not something I want to support.
Anyways for documentation purposes, this is the general idea:
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
socket.setdefaulttimeout(0.5)
s.sendto(b'DATA', (ip, port))
recv, svr = s.recv(4096)
print(recv, svr)

The problem is that sending something like DATA won't get a response. If this was a DNS server, sending a DNS request would work however.
Also, a balanced timeout with select would need to implemented in the above approach. Something like this: https://stackoverflow.com/a/2721734 The problem again is that if the right service request is not sent, nothing will come back.
My way forward on this is to first look at how nmap does this, and then if there is not a good solution to document the infeasibility of supporting UDP port scanning in a project this size.

Also, calling this module nmap is probably a rip... I'll rename this portscanner or something generic in the next release.

Definitely not a solution for all the ports you have listed in ports.py, but if we cut that down to maybe 10 or so common UDP ports, we can turn it into a dict that holds a valid input for the suspected service. DNS specifically is a simple protocol.
udp_ports = { 53: ""AA\x01\0\0\x01\0\0\0\0\0\0\x07example\x03com\0\0\x01\0\x01" }

yea I know. Just wanted to put out a maybe semi solution

UDP scan works by sending a UDP packet to every targeted port. For some common ports such as 53 and 161, a protocol-specific payload is sent to increase response rate, but for most ports the packet is empty unless the --data, --data-string, or --data-length options are specified. If an ICMP port unreachable error (type 3, code 3) is returned, the port is closed. Other ICMP unreachable errors (type 3, codes 0, 1, 2, 9, 10, or 13) mark the port as filtered. Occasionally, a service will respond with a UDP packet, proving that it is open. If no response is received after retransmissions, the port is classified as open|filtered. This means that the port could be open, or perhaps packet filters are blocking the communication. Version detection (-sV) can be used to help differentiate the truly open ports from the filtered ones.

Unless you want to write a complicated ICMP listener I think we're cooked.


[FUZZ] Lodestar crash-a5b0215768616e956c13a3b4c662e59e1a7aac817a50cfced3a4da1d14ea5b0f

I've identified a fuzzer crash and am contributing to the security of Ethereum 2!
I've done and provided the following:

[x] Checked to see if any other [FUZZ] issue already refers to that crasher

[x] Attached the crashing input (either attached to the issue as a .zip or .gz, or as a link to a file sharing service)
crash-a5b0215768616e956c13a3b4c662e59e1a7aac817a50cfced3a4da1d14ea5b0f.zip

[x] Noted the beacon-fuzz version or commit used.

e099075

[ ] Provided crash output
[x] Noted the command or fuzzer used to generate the crash

make fuzz-all
error occurred when fuzzing Lodestar / in the jsfuzz workspace

[x] Name of the original crash file

crash-a5b0215768616e956c13a3b4c662e59e1a7aac817a50cfced3a4da1d14ea5b0f

[ ] (Optional but optimal) Checked if the crash can be consistently replicated by re-running the input.

Info to Reproduce

Command run: e.g. make fuzz-all
Crasher file name: crash-a5b0215768616e956c13a3b4c662e59e1a7aac817a50cfced3a4da1d14ea5b0f.zip
Client exercised: Lodestar
Fuzzing engine used (if applicable): NA

Your Environment

Fuzzer ran: make fuzz-all
Version/Commit used: e099075
Operating System and version: MacOS Mojave, 10.14.4; Docker version 19.03.4, build 9013bf5

Thanks for the report,
Same issue than https://github.com/ChainSafe/discv5/issues/71.

Fixed in master ;)
Thanks @cooganb


Google translation

is not working ;)

Have you generate and add your google Api Key to config?

It is working for me too.

Google Translation was removed ?

or how i can use it ?

Yes, it was removed. It never made into a tagged release. Currently you can't use this feature. For details, see the conversation at the commit.


Replace __dirname and __filename in .css.ts file source

Allows __filename and __dirname to be used in .css.ts files. Resolving this repro:  https://github.com/AndrewLeedham/vanilla-extract-filename
It uses a somewhat naive approach of regex replacement since that is what Vite does. The '__' + 'filename' instead of just '__filename' is intended to prevent Vite from replacing the replacement when using the plugin 🙄

The internal esbuild compile bundles all the internal files into a single output. This solution would lead to __filename and __dirname being incorrect for all but the entrypoint file. It would also lead to the same file having different values if it was imported in multiple places. To solve this you'd need to replace at the file level with an esbuild plugin that run for each internal file.
Outside of the solution though, what scenario would having __filename and __dirname be useful for?

Outside of the solution though, what scenario would having __filename and __dirname be useful for?

I am exporting the filename of each .css.ts file, so when I import it in each component I can reference it and use it in a React hook which handles including the resulting CSS file on the page. Which is handled by a path transform on said filename.
It is something along the lines of
export const stylesheetPath = getStylesheetPath(__filename);

The internal esbuild compile bundles all the internal files into a single output. This solution would lead to __filename and __dirname being incorrect for all but the entrypoint file. It would also lead to the same file having different values if it was imported in multiple places. To solve this you'd need to replace at the file level with an esbuild plugin that run for each internal file.

I created https://github.com/seek-oss/vanilla-extract/pull/668 for different reasons, but that should address the bundling/entry issue.


Reduce load on Pilot by ignoring services

Hi,
I'm trying to think of ways to reduce the load on pilot and one of those is having the ability to exclude certain services from EDS, so that if the pods for these services change the updates just aren't propogated.  These are services that will never receive an incoming connection from my applications.
For example:

calico-typha.kube-system.svc.cluster.local
heapster.kube-system.svc.cluster.local
metrics-server.kube-system.svc.cluster.local
prom-snmp-exporter.kube-system.svc.cluster.local
tiller-deploy.kube-system.svc.cluster.local

etc etc...
can anyone think of a way to exclude a kubernetes service from the mesh?

With 1.2, you can add an annotation to these services networking.istio.io/exportTo with value set to '.' . This would cause the service to become visible only in the kube-system namespace. Other sidecars wont see this service. If they dont see this service, there wont be an EDS update.

@rshriram that sounds awesome, shame it's two major releases away haha :D

Not sure, if it is right to point out. Learning by making mistakes here :sweat_smile:
Should we mark this issue close ?

Oh sorry I meant 1.1 thats gonna be out in a few days

Aweeeesoommmeeee
On Tue, 12 Feb 2019, 3:06 pm Shriram Rajagopalan<EMAIL_ADDRESS>wrote:

Oh sorry I meant 1.1 thats gonna be out in a few days
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/11664#issuecomment-462794576, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABaviTE0xQ1c69dcm57U-mdL7wpC2MuRks5vMthtgaJpZM4az9Fz
.

OK for anyone else following this issue, this feature is only part implemented in 1.1, you won't be able to select namespaces, only . (current namespace) and * (all namespaces).

OK this is following on from a conversation with @rshriram regarding our real life use case for exportTo.  I didn't really know where else to post it but hopefully it will explain why the concept of "import" on a Sidecar resource doesn't really fit our CI/CD process or organisational model.  This is all born out of a conversation where I discovered exportTo is not going to be fully complete for 1.1, thus not addressing the OP.
Take the following simplistic service architecture where a service and a namespace correlate one to one:

Each application is owned by a different product team within the organisation, they are effectively the gatekeepers as to who can talk to their service.  They do that in their applications configuration file with the allowIngressFrom block.  note they are abstracted from underlying kubernetes/istio concerns, they don't care about NetworkPolicy, Gateways, Sidecars, VirtualServices or anything like that.
This then goes on, when deployed, to generate NetworkPolicy, with ingress rules for the given namespaces.

When a new service comes along, that wants to talk to one of these services, they send the team a pull request adding their new service to the allowIngressFrom block.  This then updates the NetworkPolicy to in turn allow that ingress.
What we effectively want to do is marry the new exportTo feature, to this already pre-defined list of services, because they are always going to be equal.  So in the case of Service A, as well as a NetworkPolicy allowing ingress from service-b and service-c, we would also generate the VirtualService to have exportTo: [service-b, service-c].
Unfortunately this feature is not going to make it to 1.1, which I am pretty disappointed about, because we've been talking about network isolation for some time and I've explained our use case quite a lot!  However, what is going to make it to 1.1 is the ability to specify on a Sidecar resource, import, which allows you to tell a sidecar which services it will talk to, thus controlling what config it will pull in.
However, as you can see however from the above diagram, the only way to know what the values for Sidecar should be for say, service B, would be to infer it from the fact it is in the allowIngressFrom blocks of service A and service C, however they're deployed in complete isolation.  We simply can't do it.
Another workaround would be to maintain an egress list in App B, but then we're asking teams to do two get their apps communicating.  And those two things will undoubtedly get out of sync.  It's also a leaky concern for us, we're asking the teams to over complicate their config to work around a platform problem.
On top of that, we have 160 applications deployed in this fashion, and wanted to seamlessly implement namespace isolation as the data for what we need is already there, if you're taking it from the perspective of the ingress service.
So I guess in summary, I'd really like to know:

Is this completion of this feature being prioritized, considering it isn't working as per the prelim doco (https://preliminary.istio.io/docs/reference/config/istio.networking.v1alpha3#ServiceEntry)
What an ETA for this work would be?  Due to our ongoing issues with scaling and namespace isolation?  I'm a little frustrated because I've been telling people at AutoTrader that this is coming in 1.1, and now it's not :(

cc. @nmittler

cc @louiscryan

@Stono Thanks for describing the scenario so clearly. I think your namespace-per-service use case is pretty common, so the priority to support exportTo namespaces other than current or all, should be pretty high. As you can see, it is certainly covered by the api, just not implemented in the first release. I'll let @rshriram confirm, but I would say this is definitely a 1.1 feature, just not 1.1.0. Maybe it could be in 1.1.1, which should be pretty soon too.

The priority for 1.1 is to control what services are visible in a given namespace - which is defined by Sidecar.egress.
Ingress control is expressed and enforced with Istio RBAC - we plan for 'exportTo' to feed into and generate equivalent RBAC config, but this is not ready, as I mentioned the focus was on visibility.
In practice - until exportTo or "egress" are fed into RBAC, you MUST maintain 2 configs, one for visibility and one for access.  Visibility is not enforceable and easily bypassed.
We also found many apps using custom ACL ( built-in, custom, etc ) - and apps with large number of
users ( auth, databases, shared infra ) where managing the visibility on the caller side is not practical.
But if you have configs defining "A allows ingress from B" - I think it should be possible to generate the reverse, "B is making egress calls to A".  I'm not entirely sure I understand the problem - any code that generates 'A exportsTo: B,C' can also generate the opposite.
The reason we think 'egress (importsFrom)' is important: a team maintaining a service should be able
to control what dependencies it uses. Using 'exportTo' will mean that a random other team can accidentally impact the behavior of the app. In general - both sides must declare trust in each other, and
the server must have enforcing checks.
I can't think of any good way to declare this only once - maybe in some cases there is a source of truth, but in the general case the client can't be forced to use a particular service just because the server exports to it.

To be clear: exportTo is planned and eventually can be used to configure RBAC, so you don't have do do this twice ( unless you have advanced configs that really need full RBAC ).
But we need consent from both sides - and we need to support '*' ( i.e. services that are exposed to everyone in the mesh and do their own ACL, as well as clients that import all services that allow that, like prometheus ).
The RBAC and exportTo is under control of the service, the egress under control of the client which might pick a specific implementation/version of the server or might not actually need to use a service even it is exported.
RBAC and exportTo are also defined in terms of service accounts ( which are equivalent to namespaces), while egress can be specified on a service and port level.
"exportTo"/RBAC pointing to anything except service account is not really enforceable with the current
Siffee model, since the access is based on the identity of the caller.

Hey everyone!
Thanks for your detailed responses.
I do just want to clarify something however, I don't consider exportTo to be an RBAC concern?  I only gave the association to NetworkPolicy to explain how our organisation puts the responsibility with the owning squad to populate that list and how that list will always actually need to be identical to the NetworkPolicy ingress rules.
@costinm you said "is important: a team maintaining a service should be able
to control what dependencies it uses" - I agree, and that's what we have.  It can declare what dependencies it uses, but it shouldn't be allowed to use them without the dependency agreeing.  Which is why we have gone down the route of having the listening side the arbiter of that config, not the sending side.  So Team B "declares" it uses service-a from Team A by sending a pull request to their config to allow the NetworkPolicy ingress.  Asking them to then add to service-b "egress" config to service-a is nothing more than duplication as from an organisational perspective, they've already declared that dependency.

PS I'm at GCP Next SF if anyone wants to whiteboard this in person haha

I kinda feel ExportTo wont help here. I wonder if scoping/sharding the number of sidecars/mesh components that Pilot needs to synchronise configuration would help. For example if all of the network policy could be scoped based of namespace/label and this can be used by Pilot to resolve the mesh components that need synchronising. An example is how NetworkPolicy is able to be applied based of namespace/PodLabels.
@Stono I'm also pretty sad to not see namespace isolation prioritised as it still a big issue for multi-tenant environments and creates a massive blast radius when erroneous configuration is applied to the mesh.

Yeah, I've been pushing for it since mid last year @castlemilk :-( as our cluster grows the risk increases

This is very important for us too. We have many services (potentially hundreds) on each cluster and not only do we need namespace isolation but the config bloat on each sidecar is a real problem. We might be able to make it work with exportTo: . and duplicating resources for each namespace, but that seems like the wrong way to do it.

@dwradcliffe The new Sidecar resource is supposed to address the config bloat problem.

As Frank mentioned refining exportTo to handle explicit namespaces as well
as 'same namespace' & 'all namespaces' is something we'll be looking to do
in a 1.1.x release. The APIs have been explicitly designed to handle the
'publisher controls visibility' case in addition to the 'consumer controls
visibility' case which is handled by the new Sidecar resource.
We prioritized dealing with the config bloat problem from the consumer
perspective first as it ultimately provides the most control and should
provide some value to everyone if they are having footprint issues.
@Stono - I really appreciate the detailed feedback, in particular
validation of the 'producer oriented' model. This is how Google works
internally and it's something I believe many organizations should adopt as
it generally scales better from a management perspective, i.e it aligns
with the microservices philosophy.
On Wed, Feb 27, 2019 at 11:30 AM Frank Budinsky<EMAIL_ADDRESS>wrote:

@dwradcliffe https://github.com/dwradcliffe The new Sidecar resource
https://preliminary.istio.io/docs/reference/config/networking/v1alpha3/sidecar/
is supposed to address the config bloat problem.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/11664#issuecomment-467998061, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIoKPMqyai4qdfLeZyaE77OqaboPWDmFks5vRtzVgaJpZM4az9Fz
.

@Stono I would expect once exportTo is fully implemented, at least on visibility side  ( and we're not that far away ) to support exactly your model. The client can do 'import /' - which will generate only the list of services/namespaces that exportTo the client. So no need to duplicate if you have a consistent policy
of having 'producer declare deps'.
There are few reasons we focused on 'import' first - the 'exportTo' is effective only if all producers
follow this rule and strictly export to allowed clients ( which should also be fed into RBAC/enforced).
In practice most users don't have this - and getting the RBAC/enforcement is more complicated.
As I mentioned, a problem many people had was a service 'exporting' some resource accidentally.
I think you reported few bugs around this :-) If you chose to go with exportTo only, and import * it is
hard to avoid this problem. DestinationRules can be exported - and multiple namespaces may export rules for same host.
Explicit import avoids this problem and has a stricter isolation - keep in mind that on the server side
you need to rely on enforcement/RBAC, visibility is not doing much.
I hope we'll have some tools to simplify keeping them in sync - and of course there are options to use
only exportTo or only import, but long term I think most users should have isolation on both ends.

Hey @costinm - I completely understand what you're saying and definitely agree that being explicit on both sides is best, however I have to balance that with a pragmatic implementation and minimal impact on the users of our platform.
The only other thing I can think of doing is writing a controller that watches for our ingress policies and manages sidecar resources outside of ci/cd.  Just feels wrong though, I prefer explicit IaC.

The other reason we really need this, average istio-proxy usage for memory is 128m, across 500 proxies, that's a fair whack.

Closing this, Sidecar isolation has all but solved this for us: https://twitter.com/karlstoney/status/1110255431644049409


Is it possible to delete resume data after canceling the download request?

Hi,
When I cancel the download request and close the app, I found there is still big data in my app.
I think it may be resume data. I don't want to resume the download.
I wanna delete the resume data after canceling the download request.
How can I do it?
Thanks!

Hi @chaocharleswang,
These types of questions are best suited for Stack Overflow with an alamofire tag. We use our GitHub project to bug reports and feature requests.
Best of luck! 🍻

From our Contribution Guidelines
Asking Questions
We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.


cortex-m-rt doesn't build on Windows anymore

On Windows, with a fresh clean install of arm-none-eabi-gcc, building cortex-m-rt eventually fails with:
Internal error occurred: Failed to find tool. Is `ar` installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)

As a workaround, setting the TARGET_AR environment variable to arm-none-eabi-ar fixes it. This was not necessary before, and is not documented anywhere if it is a new requirement.

I had the same issue on windows.
Thank you for this fix!

IMO, cc should be using a prefixed archiver if already using a prefixed compiler / assembler. I have filed alexcrichton/cc-rs#330 to request changing the behavior.

I fell over this today :/


Check HTTP on the book cover

A warning appeared in devtools about the security of URLs with HTTP instead of HTTPS. I would have to look if the URL provided by Google Books uses HTTP and if it can be changed to HTTPS.

Done in 1166a31: Changed HTTP to HTTPS in the URL of the covers


BUG? Wrong position of the Select content in Dialog.

Thanks for making such a great UI component!
I tried using the Select component in the Dialog, but the Select.Content display an incorrect position.
The same behavior occurs in the Popover. 🤔

I think you’d need to wrap the select in https://www.radix-ui.com/docs/primitives/components/dialog#portal. Have you tried using that?

Closing due to inactivity


Cannot find module '../index'

Hey, thanks for this package, works a treat usually!
Getting below on latest release.
Cannot find module '../index'
Require stack:
- <path>/node_modules/shopify-sync/bin/sync

Changing to ../package/index fixes my end.

Hey @possibleworlds, what package manager are you using?

@possibleworlds Fixed! It seems I forgot to relink the CLI package, thanks for taking the time to submit the issue, really appreciate it.

Thanks! Just for reference was with plain old npm.

Just curious, As a user, is there any features you’d like to see in the first major? I’ll be shipping a fair few improvements. Would being able to minify help you? Or is there something missing that you would like to see? Do you use the CLI over the script? Any insights will be great, thanks.

Hey, no not really actually, it ticks all the boxes for me! I am using config file with targets for dev / live, and I generally use https://github.com/sezna/nps so basically npm scripts to trigger.
My main pain point (besides Shopify generally) is localhost server setup. I use browsersync just because I am used to using it, but the config is cobbled together from other repos and manually figuring out the preview_theme_id and installing ssl feels fragile. A proxy server that does all this based on the sync config would be a nice to have, either as part of this module or as a separate package.

Thanks for getting back to me, I can optionally provide a way print the theme id via the CLI. I do have a complete dev environment locally that I use for developing themes that provides all this, I will see what I can do in terms of potentially combining it.

Yeah, yours is probably one of the boilerplates I was using, that or the slater-theme. For me its the boilerplate involved that turns me off, and only having a vague understanding of whether what I am doing is correct... something that abstracts that config away so I can be lazy would be great, but I don't think its the role or responsibility of this lib. Will look at your strap again.


[ML] Add Custom Applications to Compute Instances

Description
Adds support for Custom Applications on Compute Instances. Users can use the new custom_applications field to define custom applications that can be run on CIs.
Fixes a bug where enable_node_public_ip did not return a proper value from the Rest API.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.

Please add @experimental annotation to new classes you're adding.


[release/1.6 backport] Add cleanup package for context management during cleanup

[release/1.6] client.newUnpacker: call abort() on ctx.Cancel() and fetchErr
This code did not call "abort" on ctx.Cancel() and fetchErr before
commit 8017daa12dd4159e90701bedd1caaa9be5fb0357
https://github.com/containerd/containerd/blob/030c1ac1caa49f88cd572a43a053fb3b7007f94b/unpacker.go#L215-L241
But after the code was moved to pkg/unpacker, abort calls were added;
https://github.com/containerd/containerd/blob/8017daa12dd4159e90701bedd1caaa9be5fb0357/pkg/unpack/unpacker.go#L353-L381
That code is not part of the 1.6 branch, so applying it here.
and backport of

https://github.com/containerd/containerd/pull/7859
https://github.com/containerd/containerd/pull/7861

:warning: Conflicts in:

metadata/db.go
pkg/unpack/unpacker.go (due to https://github.com/dmcgowan/containerd/commit/8017daa12dd4159e90701bedd1caaa9be5fb0357 missing)
runtime/v2/shim.go

Conflicts:
diff --cc metadata/db.go
index 2d9cbf31a,60a65b5b4..000000000
--- a/metadata/db.go
+++ b/metadata/db.go
@@@ -26,9 -26,13 +26,14 @@@ import
  	"sync/atomic"
  	"time"

 -	eventstypes "github.com/containerd/containerd/api/events"
  	"github.com/containerd/containerd/content"
 -	"github.com/containerd/containerd/events"
  	"github.com/containerd/containerd/gc"
  	"github.com/containerd/containerd/log"
++<<<<<<< HEAD
++=======
+ 	"github.com/containerd/containerd/namespaces"
+ 	"github.com/containerd/containerd/pkg/cleanup"
++>>>>>>> b550526cc (Use cleanup.Background instead of context.Background for cleanup)
  	"github.com/containerd/containerd/snapshots"
  	bolt "go.etcd.io/bbolt"
  )
diff --cc runtime/v2/shim.go
index 456ffb440,3f1c84b87..000000000
--- a/runtime/v2/shim.go
+++ b/runtime/v2/shim.go
@@@ -32,15 -32,13 +32,13 @@@ import
  	"github.com/containerd/containerd/events/exchange"
  	"github.com/containerd/containerd/identifiers"
  	"github.com/containerd/containerd/log"
- 	"github.com/containerd/containerd/namespaces"
  	"github.com/containerd/containerd/pkg/timeout"
 -	"github.com/containerd/containerd/protobuf"
 -	ptypes "github.com/containerd/containerd/protobuf/types"
  	"github.com/containerd/containerd/runtime"
  	client "github.com/containerd/containerd/runtime/v2/shim"
 +	"github.com/containerd/containerd/runtime/v2/task"
  	"github.com/containerd/ttrpc"
 +	ptypes "github.com/gogo/protobuf/types"
  	"github.com/hashicorp/go-multierror"
- 	"github.com/sirupsen/logrus"
  )

  const (
@@@ -131,11 -126,10 +129,15 @@@ func loadShim(ctx context.Context, bund
  	if _, err := s.PID(ctx); err != nil {
  		return nil, err
  	}
 -	return shim, nil
 +	return s, nil
  }

++<<<<<<< HEAD
 +func cleanupAfterDeadShim(ctx context.Context, id, ns string, rt *runtime.TaskList, events *exchange.Exchange, binaryCall *binary) {
 +	ctx = namespaces.WithNamespace(ctx, ns)
++=======
+ func cleanupAfterDeadShim(ctx context.Context, id string, rt *runtime.NSMap[ShimInstance], events *exchange.Exchange, binaryCall *binary) {
++>>>>>>> b550526cc (Use cleanup.Background instead of context.Background for cleanup)
  	ctx, cancel := timeout.WithContext(ctx, cleanupTimeout)
  	defer cancel()

* Unmerged path pkg/unpack/unpacker.go

I applied the pkg/unpack/unpacker.go changes to /unpacker.go instead
I also noticed that not all calls to cleanupAfterDeadShim use cleanup.Background (not sure if that's intentional?)
git grep cleanupAfterDeadShim
runtime/v1/linux/runtime.go:                    if err = r.cleanupAfterDeadShim(cleanup.Background(ctx), bundle, namespace, id); err != nil {
runtime/v1/linux/runtime.go:                    if err := r.cleanupAfterDeadShim(ctx, bundle, ns, id); err != nil {
runtime/v1/linux/runtime.go:                    err := r.cleanupAfterDeadShim(ctx, bundle, ns, id)
runtime/v2/manager.go:          cleanupAfterDeadShim(cleanup.Background(ctx), id, m.shims, m.events, b)
runtime/v2/shim.go:func cleanupAfterDeadShim(ctx context.Context, id string, rt *runtime.TaskList, events *exchange.Exchange, binaryCall *binary) {
runtime/v2/shim_load.go:                        cleanupAfterDeadShim(cleanup.Background(ctx), id, m.shims, m.events, binaryCall)
runtime/v2/shim_load.go:                        cleanupAfterDeadShim(ctx, id, m.shims, m.events, binaryCall)

I'll keep this one in draft for now, perhaps @dmcgowan should have a look

Timestamps / timing and Windows.. always fun. Guess this is a flaky test that may need to be adjusted to be a bit more relaxed;
=== FAIL: metadata TestContainersCreateUpdateDelete/UpdateExtensionsFieldPath (0.02s)
    containers_test.go:696: timestamp for updatedat not after createdat: 2023-07-14 11:07:00.1507916 +0000 UTC <= 2023-07-14 11:07:00.1507916 +0000 UTC
    --- FAIL: TestContainersCreateUpdateDelete/UpdateExtensionsFieldPath (0.02s)

Good news; looks like there's a PR on main that we can cherry-pick;

https://github.com/containerd/containerd/pull/7350


Merge master branch to prTesting1_201903171005 branch

OPS Build status updates of commit bb153b0:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

split/updateTestCon1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


How to implement animated 3D objects? (fbx or gtfl)

Maybe here is a better place for my problem:
(https://github.com/immersive-web/webxr/issues/457)
I need your help. I have done the webxr tutorial with enthusiasm. (https://codelabs.developers.google.com/codelabs/ar-with-webxr/#0)
Now I would like to display animated objects. With blender I animated the object in fbx format and loaded it into an html with the FBXLoader of the three.js library. That works!
Unfortunately I did not succeed to use the fbx object with the same FBXLoader in the AR example of the tutorial.
Is there an example for this? Is gtlf object better usable than fbx objects? What needs to be changed in the code so I can use the loader?
Thanks a lot!
three.js FBX Loader:

var loader = new THREE.FBXLoader();
loader.load( 'models/fbx/AR_Tutorial.fbx', function ( object ) {

	mixer = new THREE.AnimationMixer( object );
        var action = mixer.clipAction( object.animations[ 0 ] );
	action.play();

	object.traverse( function ( child ) {

		if ( child.isMesh ) {

		       child.castShadow = true;
		       child.receiveShadow = true;

		 }

		} );

		scene.add( object );

	  } );

Hello! Once parsed, assuming models are exported with compatible features, there is no difference in glTF and FBX during runtime. glTF appears to be best choice moving forward. The three.js tag on stackoverflow is a better place for general three.js questions like this -- good luck!


Feature/cab 3181

Coverage decreased (-0.02%) to 80.261% when pulling 7465b68e523be4ca2913118678f094b8fee453c7 on feature/CAB-3181 into 732014e35de21a8ec462a2f53b181def172248c2 on develop.


Fix compile warning caused by 0b21d2f6

Coverage remained the same at 84.677% when pulling fe6bf3c74614b38976d43ed3f4714d0e901571cf on ycho:fix_warning1 into ab4d23e21975f27ad7553081d7e17e16e3c0d794 on xiph:master.


SampleLibrary page prevents tab navigation

(Not an important issue, but should be mentioned regardless)
How to replicate the problem:

Start New Project (optional)
Create Node type "SimplePlayer".
In the Inspector, under "Config"->"Samples", change from  to New SampleLibrary.
Click it again and select "Edit".

This will overlap your current page with the sample library page.
You are unable to leave this page by clicking on the tabs; 2D, 3D, Script or Help - so you are forced to finish whatever you are doing. A way I have found to leave this page (when not doing anything) it is by clicking on any node in the Scene window.
Worth mentioning there is no indication of where you are (not counting inside the Inspector window). No title saying "Sample Library" or some other information to tell the user what "page" is he on. (Granted; most people usually know where they are and how they got there, but let us pretend the user is a dummy and create a user friendly program!)  :)
A suggestion to remedy this might be to make it appear in a new window instead of replacing whatever page/tab you are currently in.

this is not actually an issue, the sample library editor is not a tab, it's drawn over the tab mode, to leave the editor you should click on any node of scene_tree or the left-arrow on inspector (back to SamplePlayer node)

Yeah... current dialog popup implementation makes it close if you click outside of the dialog, so you can't change values on the inspector; and adding a close button to the sample panel would be confusing also, because it's already filled with unused controls... Theme editor needs to be completely moved to a separate window, including inspector...

There are a few editors that work like this. I know it kind of sucks, but i'm unsure about how they should behave.  Maybe a popup window instead of something that replaces the tab?

This seem to be working well now. This now opens a new area on the bottom of the viewport that allows you to add or edit samples, and in order to "leave" the window, you just go "back" from the inspector (left arrow) or select a different node. :)
If there are no objections, I believe this issue can be closed.

Sure thing


CDN link on documentation website not working

Describe the bug
The CDN link on the documentation doesn't seem to be working, can you update the CDN link to be the same as the one on the code playground on codepen
To Reproduce
you'll find the error here, where it says installation via CDN
@jinsupark

Thank you @nelsonmic, link has been updated.


Outline the source

Hi Barrett,
I am wondering whether is possible to outline procedures' names and other stuff in the OUTLINE panel. I think it will be very helpful.
What do you think about it?

That is an awesome idea and would save a lot of headache trying to find things.
However, this type of feature starts diving into Language Server Protocol (LSP).
I only did some brief searching and found this StackOverflow post
Based on that post, I believe that outline view is bundled into LSP. I believe to get an LSP extension off the ground, I'd have to make a set of parsers to be able to build some sort of syntax tree for RPG, RPGLE, CL, etc.
While this is definitely not impossible to do, it would be quite the undertaking. There are some lexers/parsers floating around for IBMi languages like RPGLE Parser.
Implementing a LSP extension opens up a ton of awesome things such as the outline view, intellisense, and "go to symbol". Maybe one day I can start chipping away at this, but I can't say it would be anytime soon unfortunately.
Thanks for the suggestion, I would love this feature

@mlstoppa closing this issue to move discussion to https://github.com/halcyon-tech/code-for-ibmi/issues/32 .


AB#4604 payment request per PA + cleanup

@RubenGeo @elwinschmitz I believe I'm done with these code-changes + successfully testing various scenarios I can think off. Given the importance I was wondering if (next to normal reviewing) you have input on which scenario's we should test to be complete..
I have tested with 1 PA, multiple PA's, all error-reasons I can think off (Dutch phone number, simulator not open, wrong API-key, etc.). I have tested that NLD still works (it does).


[5.3][Sema] Warn on exporting implementation-only imported types in SPI

This completes type-checking work for #32902. Bringing back the diagnostic on exporting implementation-only imported types in SPI as a warning. This check was previously reverted from 5.3, and now it can be valid when relying solely on swiftmodule files or when using -experimental-spi-imports. This is part of a staged transition to a long term language feature of imports as SPI.

Scope of Issue: This is affecting projects using both @_implementationOnly and @_spi.
Origination: Introduction of @_spi, and revert in #32552.
Risk: Low, this only adds a warning on decls marked with @_spi.
Resolves: rdar://66336527

@swift-ci Please test

@swift-ci Please nominate


Changing libstdcxx dependency in a minor version release is bad

Just found out on SLES 15 SP3.
The amdclang shipped with rocm 5.4.0
ldd /soft/compilers/rocm/rocm-5.4.0/llvm/bin/clang++
	linux-vdso.so.1 (0x00007ffdc3a8d000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f97aa0cf000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f97a9ec6000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f97a9cc2000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f97a9aab000)
	libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f97a987d000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f97a946a000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f97a911f000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f97a8f06000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f97a8b11000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f97aa2f2000)

With rocm 5.4.3
ldd /soft/compilers/rocm/rocm-5.4.3/llvm/bin/clang++
/soft/compilers/rocm/rocm-5.4.3/llvm/bin/clang++: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /soft/compilers/rocm/rocm-5.4.3/llvm/bin/clang++)
	linux-vdso.so.1 (0x00007ffd15d9f000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fafdc84c000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fafdc643000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fafdc43f000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fafdc228000)
	libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fafdbffa000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fafdbbe7000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fafdb89c000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fafdb683000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fafdb28e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fafdca6f000)

The system gcc 7 is not qualified. What is the new requirement? It is gcc 12. That is a huge surprise.
The expectation is no major dependency change in a minor release. So please make it gcc 7 sufficient.
If a newer gcc is needed to build this clang or a later release, make a conservative choice of gcc version and maximize compatibility.
On my ubuntu 20.04, rocm clang++ is happy with gcc 9. I would assume the choice of gcc 12 in SLES is an oversight when packaging rocm 5.4.3. I have not checked 5.4.1 or 5.4.2 but please lower the version of gcc dependency.

@nartmada this was the source of the pain described https://github.com/ROCm/ROCm/issues/2084

Hi @ye-luo, apologies for the delay in responding to your issue.
I think that the discussion in https://github.com/ROCm/ROCm/issues/2084 provided a justification for why the libstdc++ version was increased, though this still should not have gone out in a minor release.

The expectation is no major dependency change in a minor release.

We do have internal rules to prevent breaking changes in minor/patch releases, and it seems that this in this case we missed that check. I understand your frustration in encountering a breaking change in a minor release and we apologize for the pain that's caused. Thanks for your feedback.


Create settings to enable/disable the plugin repl

Today, by default, the plugin runs a nrepl server at the 7770 port. In development or debugging this makes sense, but it should not be enabled by default.
Create a setting for the plugin where the user can enable or disable this.

This should be fixed, prod plugins now don't start a nrepl process.