istioctl manifest apply output is confusing with component output

Preparing manifests for these components:
- NodeAgent
- PrometheusOperator
- CoreDNS
- Galley
- Cni
- EgressGateway
- Citadel
- Telemetry
- Base
- Tracing
- Pilot
- IngressGateway
- Injector
- CertManager
- Prometheus
- Policy
- Grafana
- Kiali

Applying manifest for component Base
Finished applying manifest for component Base
Applying manifest for component Galley
Applying manifest for component Citadel
Applying manifest for component IngressGateway
Applying manifest for component Prometheus
Applying manifest for component Injector
Applying manifest for component Telemetry
Applying manifest for component Pilot
Applying manifest for component Grafana
Finished applying manifest for component IngressGateway
Finished applying manifest for component Citadel
Finished applying manifest for component Galley
Finished applying manifest for component Prometheus
Finished applying manifest for component Injector
Finished applying manifest for component Grafana
Finished applying manifest for component Pilot
Finished applying manifest for component Telemetry

Component NodeAgent installed successfully:
===========================================

Component PrometheusOperator installed successfully:
====================================================

Component CoreDNS installed successfully:
=========================================

Component Galley installed successfully:
========================================

Component Cni installed successfully:
=====================================

Component Citadel installed successfully:
=========================================

Component Telemetry installed successfully:
===========================================

Component Base installed successfully:
======================================

Component Tracing installed successfully:
=========================================

Component Pilot installed successfully:
=======================================

Component EgressGateway installed successfully:
===============================================

Component IngressGateway installed successfully:
================================================

Component Injector installed successfully:
==========================================

Component CertManager installed successfully:
=============================================

Component Prometheus installed successfully:
============================================

Component Policy installed successfully:
========================================

Component Grafana installed successfully:
=========================================

Component Kiali installed successfully:
=======================================

"Preparing manifests for these components:" has a bunch of junk I didn't enabled
The end part also has the same junk I didn't enable
The end part should just look like, we don't need the : =======
Component CertManager installed successfully
Component Prometheus installed successfully
Component Policy installed successfully
Component Grafana installed successfully
Component Kiali installed successfully

@elfinhe I think you mentioned you fixed this and it got partially reverted, not sure if its the same

Yes, it is. I reopened that one as well: https://github.com/istio/istio/issues/18892.

This is still not fixed.
Current output:
Preparing manifests for these components:
- Pilot
- Cni
- Policy
- CoreDNS
- Citadel
- Base
- Telemetry
- Prometheus
- EgressGateway
- Kiali
- Galley
- Grafana
- NodeAgent
- Tracing
- IngressGateway
- CertManager
- PrometheusOperator
- Injector

Applying manifest for component Base
Finished applying manifest for component Base
Applying manifest for component Citadel
Applying manifest for component Prometheus
Applying manifest for component Galley
Applying manifest for component Policy
Applying manifest for component IngressGateway
Applying manifest for component Telemetry
Applying manifest for component Pilot
Applying manifest for component Injector
Finished applying manifest for component Citadel
Finished applying manifest for component Prometheus
Finished applying manifest for component IngressGateway
Finished applying manifest for component Pilot
Finished applying manifest for component Galley
Finished applying manifest for component Injector
Finished applying manifest for component Policy
Finished applying manifest for component Telemetry

Component Prometheus - manifest apply finished successfully:
============================================================

Component Galley - manifest apply finished successfully:
========================================================

Component Citadel - manifest apply finished successfully:
=========================================================

Component Base - manifest apply finished successfully:
======================================================

Component Telemetry - manifest apply finished successfully:
===========================================================

Component IngressGateway - manifest apply finished successfully:
================================================================

Component Injector - manifest apply finished successfully:
==========================================================

Component Pilot - manifest apply finished successfully:
=======================================================

Component Policy - manifest apply finished successfully:
========================================================

*** Success ***

Expected output:
Preparing manifests for these components:
- Base
- Citadel
- Pilot
- Telemetry
- Prometheus
- EgressGateway
- Galley
- Grafana
- IngressGateway
- CertManager
- Injector

Applying manifest for component Base
Finished applying manifest for component Base
Applying manifest for component Citadel
Applying manifest for component Prometheus
Applying manifest for component Galley
Applying manifest for component Policy
Applying manifest for component IngressGateway
Applying manifest for component Telemetry
Applying manifest for component Pilot
Applying manifest for component Injector
Finished applying manifest for component Citadel
Finished applying manifest for component Prometheus
Finished applying manifest for component IngressGateway
Finished applying manifest for component Pilot
Finished applying manifest for component Galley
Finished applying manifest for component Injector
Finished applying manifest for component Policy
Finished applying manifest for component Telemetry

Component Prometheus - manifest apply finished successfully
Component Galley - manifest apply finished successfully
Component Citadel - manifest apply finished successfully
Component Base - manifest apply finished successfully
Component Telemetry - manifest apply finished successfully
Component IngressGateway - manifest apply finished successfully
Component Injector - manifest apply finished successfully
Component Pilot - manifest apply finished successfully
Component Policy - manifest apply finished successfully

*** Success ***

The goal here - get rid of the ===== junk, remove components I don't install in the "preparing manifest", and sort output of "preparing manifest".
We can also be consistent with analyze and use checkmark. Also do we even need "preparing components? If we have "finished applying" why do we need the "manifest apply finished successfully".
Really here is my desired output:
- Applying manifest for component Base
✔ Finished applying manifest for component Base
- Applying manifest for component Citadel
- Applying manifest for component Prometheus
- Applying manifest for component Galley
- Applying manifest for component Policy
- Applying manifest for component IngressGateway
- Applying manifest for component Telemetry
- Applying manifest for component Pilot
- Applying manifest for component Injector
✔ Finished applying manifest for component Citadel
✔ Finished applying manifest for component Prometheus
✔ Finished applying manifest for component IngressGateway
✔ Finished applying manifest for component Pilot
✔ Finished applying manifest for component Galley
✔ Finished applying manifest for component Injector
✔ Finished applying manifest for component Policy
✔ Finished applying manifest for component Telemetry

✔ Installation complete

This is the first thing a users sees when they install Istio, so it should be clear and concise


[WIP] add GitHub Actions workflow for CI

Adds GitHub Actions support.
It currently runs everything that is setup with .travis.yml, and adds Python 3.7.x to the build matrix.
See an example run here: https://github.com/smola/modin/commit/391596d961039cdf4358c675de424b80fa54ae6c/checks?check_suite_id=290849650
Benefits

Higher usage limits than Travis: 20 concurrent jobs with 6 hours timeout per job. This allows to finish a full run in less than 40 minutes, even adding an additional Python version to the build matrix.
Integration of results right in GitHub.
Apparently better performance per worker.

Downsides

Codecov has no proper GitHub Actions integration yet, so it needs CODECOV_TOKEN. Setting up the token as a GitHub Actions secret makes it work only for branches in the main repository, not forks (as in external pull requests).

To Do

Speed up dependency install with cache. See: actions/cache.
Add macOS support.
Add Windows support.
Add Dask tests.

Thanks @smola for putting this in, this is great! It would be great to move to GitHub Actions.
A couple of notes:

Codecov has no proper GitHub Actions integration yet

I am okay to only test the master branch for now. We mainly use it to make sure new code/implementations are tested. For major refactors/internal changes, we (should) test the coverage locally before

Add macOS support.

We dropped Mac builds in #177 to speed up the build process. There's no code internally that changes between Mac and Linux, so it would mainly be testing Ray/Dask for each, which isn't necessarily a bad thing.

Add Dask tests.

This is something that was started in #782, but we found that the caching that Dask does between function calls causes some weird behaviors when doing very similar named operations (ge and gt) but when they are run individually, they all pass. I haven't had the time to debug the issue to see if we can turn off Dask's caching mechanism, but this is the state that the Dask tests are in at the moment.
Let me know your thoughts and if you'd like me to look into any of the TODOs.

Thanks @smola, this is really cool! Github Actions looks like it'll be a lot easier to work with as well.
Here are some thoughts on the downsides and future work:

Codecov has no proper GitHub Actions integration yet

We could keep Travis around to do the codecov until GitHub Actions has codecov integration to ensure that codecov is run for every PR.

Add Windows support.

This would be dependent on the issues that @devin-petersohn brought up with the Dask tests as only Dask is supported for Windows. This is due to the fact that Ray does not currently have Windows support.

We could keep Travis around to do the codecov until GitHub Actions has codecov integration to ensure that codecov is run for every PR.

@williamma12  Travis would have to run the tests to determine the coverage, I think it will be okay to avoid this altogether. We can determine coverage on the master and it should be fine, as long as we have some discipline with what we merge 😄.

@smola I think we can go ahead and merge this and iterate.
I created an issue #853 to track the updates we need for CI. It includes the TODOs you listed (which I don't think block this particular PR).
Thanks again for putting this in!


Don't install menhir_error_processor

This tool is used during compilation and should not be installed.

Thank you!


feat: thorchain lending improvements

Description

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #5568

PR #5569

PR #5579

PR #5590

PR #5593

PR #5605

PR #5608

PR #5609   👈

This stack of pull requests is managed by Graphite.


[blend2d] Update to beta_2020-04-19

How do i go about adding natvis file to visualizers dir? I can add instructions to usage but i think this should be automated.
ImageWatch extension requires natvis file to be resent in visualizers dir as it cannot be loaded from .pdb in this case.

The otl regressions are not related with this PR.

LGTM, thanks for this PR!

LGTM, thanks for the PR!
As for natviz files, we don't have an automated way of doing this other than putting them in the .pdb. You can put them in share\blend2d\ and they'll at least be available for the user to install into the visualizers dir if they want.


Wrongful data sanitization?

I've upgraded Sentry to 7.4.1 and raven-java to 6.0.0. While everything seemed to function I noticed that some of the fields are now improperly sanitized/treated as passwords (replaced with ********).
Specifically I am seeing this with timer fields named time_start and time_end and storing Long.toString(System.currentTimeMillis()). However a field named time_ms storing the difference between these ms timestamps gets recorded properly without sanitization.
I am not seeing this kind of behavior with anything in the raven python client so I figure this has to be something with the latest release of the java client. Is this something that could be addressed by client configuration or there might be an actual bug somewhere?

@dmk23 - I wasn't able to find anywhere in the codebase where this would be occurring, so I'm going to close this. (I'm not totally familiar with the codebase yet, so I could be wrong — but a quick scan of anywhere I'd expect it to be didn't turn up anything.)
If you're still experiencing this issue on the Sentry 8.0.0rc1 server, can you open a ticket on getsentry/sentry with an example payload that is being scrubbed?


Integrate ZNE from Mitiq into OpenQAOA

Prerequisites
Before raising this feature request, I have made sure:

[ ] It does not lead to duplication.
[ ] It has not already been requested.

Is your feature request related to a problem? Please describe.
Proposal a method into the object QAOA to indicate the parameters necessaries for Mitiq and try to mitigate the error for the problem.
Describe the solution you'd like
Add mitiq on OpenQAOA using ZNE mitigation error and implement in the QAOA class.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Amazing! Let me tag the rest of the team too: @KilianPoirier @vishal-ph @shahidee44
I'm very excited about the prospect of bringing error mitigation to OpenQAOA :)
Let us know if we can be of help!

Hi @KilianPoirier, @vishal-ph and @shahidee44. The team has been working on the planning, and we have a couple of questions. Here are the important points:

We have decided to focus only on Qiskit.
For the integration of ZNE, we plan to add another wrapper in the same section as the SPAMTwirlingWrapper. Do you agree with this idea?
We plan to fork the main branch and start working from there. Is this okay? Or do we need to work with another branch?
@AdrianoLusso has made a diagram of our understanding of the code and where ZNE will be integrated. I attached it below.

Thanks for the help!

Hi @KilianPoirier, @vishal-ph and @shahidee44. Here is an update on the project:

We managed to create a wrapper for ZNE. You can check the current version here. At the moment the code is messy but we will improve it during the rest of the tests.

We have some preliminary results with a random instance of the Max-Cut problem using noise models. These results are unoptimized, but they show the wrapper is working. Here, you can check the parameters of the simulation. Here is a cost history plot of the results:

We are currently working on benchmarking with the Max cut and Knapsack problem (Obtaining optimal solution in a noiseless simulation and then applying the noise model to find the optimal parameters of the ZNE method )


IHC component: ERROR (Recorder) [homeassistant.components.recorder.util] Error executing query: Object of type 'Element' is not JSON serializable

Home Assistant release with the issue:

0.74
Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io
Component/platform:

IHC / https://www.home-assistant.io/components/ihc/
Description of problem:
I see the error
2018-07-23 14:18:18 ERROR (Recorder) [homeassistant.components.recorder.util] Error executing query: Object of type 'Element' is not JSON serializable
and the history for temperature sensors is not working, it's only showing few points. I have tried to delete the database to start from scratch and wait few days but still very few points.
If i comment out this component the ERROR does not come up in the logs anymore.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

I can't seem to get more info from the recorder module what the problem is or what component causes this. I've added homeassistant.components.recorder: debug

Please provide your configuration.yaml about your 'temperature sensors'. It is possible the event recording for this platform raised the error.

@awarecan i am not sure which component does this and i can't see history for anything more than maybe a day where i know it should show history for 3 days (last time i reinstalled HASS completely and wiped the db). I need to find a way to see why HASS throws that error, which table, which field to figure out what's causing this.

You said

the history for temperature sensors is not working, it's only showing few points.

So, I want to know what is your temperature sensors since HA supports some many type of sensors. Is a custom component?
I am concerning following code block may cause your issue,
https://github.com/home-assistant/home-assistant/blob/6e1785173fd670c9a57a2fd7d6dd468945597d20/homeassistant/components/recorder/models.py#L97-L98
There are few places HA used Element, most of them are XML parsing related, I am guessing one of your device's state attributes has a raw XML Element in there.

Sure, most of my sensors 95% are from deConz component

So i am pretty sure the component is ihc that causes this. https://www.home-assistant.io/components/ihc/

@awarecan is there anything i can do myself to work around this issue beside disabling the component which is out of question since i need it.

recorder:
  exclude:
    entities:
      - your_entity_id

@awarecan i tried and no success, the error still comes up. Do i need to remove the database or something else ? I believe i added the two only entities which are created by this component to the exclude list as suggested above. I don't see any other entities.

I have been looking at this, and it is the auto setup feature of the IHC component that conflict with the recoder component. Excluding the IHC component from the recorder does not help.
(I don't think is was like this when the IHC component was made initially, and I think other components  must have had similar problems with the recorder because I borrowed this idea from other code)
The problem:
The auto setup in the IHC component passes the XML element (data from the IHC controller project file) as discovery info for each product that needs to be setup. The recorder component tries to serialize this XML element to json, and fails to do this.
(I am not sure why the recorder want to save the discovery info). I have tried to find a solution within the recorder component (like setting skipkeys to true for the json.dumps function), but I could not get anything to work.
Temporary solution:
Until I get it done, you can disable the auto setup, by creating an empty ihc_auto_setup.yaml file in you HA configuration folder.
You will have to setup each IHC id manually (so I know this is probably not a good idea)
Solution
I will change it so the IHC component extracts the needed XML attributes and only use regular types like strings in the discovery info. (It was nicer to have the XML passes because each platform can extract any extra parameters from the XML, and the IHC component does not need to know the platform specific)
I will let you know here when I have something ready for testing.

@dingusdk that's great to hear. Maybe @awarecan or @balloob can help with a suggested solution for you to fix this.
Until then i understand to set : auto_setup: False  correct ? Why would i add an empty ihc_autp_setup.yaml instead of disabling auto_setup ? I only have for the moment two devices so it's not a big deal to define them manually until you fix this.

You can do the auto_setup: False - this is for each platform: switch,light,sensor, binary_sensor. The empty ihc_auto_setup.yaml is just a fast way to disable all auto setup for all platforms

I will change it so the IHC component extracts the needed XML attributes and only use regular types like strings in the discovery info.

This is the correct solution @dingusdk . It is a hard rule that all data in events need to be serializable. Using discovery and events is also being deprecated in favor of using config entries and forward config entries to load platforms.

I have now removed the XML element from the discovery data (so all is now json serializable). If someone (@donnib ) with an IHC controller want to test you can get it here:
https://github.com/dingusdk/home-assistant/tree/ihc
I will do some testing myself now before I do a PR.


[test] More deserialization recovery vtable layout tests

rdar://problem/35508966

@slavapestov Anything else you can think of?
@swift-ci Please test

@swift-ci Please smoke test and merge

@swift-ci Please smoke test and merge


docker-compose: accessing node socket from host machine

Hello,
I seem to be unable to access the cardano node socket from my host machine.
I am running the following compose setup:
version: "3.9"

services:
  cardano-node:
    image: inputoutput/cardano-node:1.35.4
    volumes:
      - ./devnet:/devnet
    environment:
      - CARDANO_NODE_SOCKET_PATH=/devnet/ipc/node.socket # used by cardano-cli
      [...]
    command:
      [ "run" ...   ]

I can successfully start-up the node through docker-compose up -d, and from within the cardano-node container I can run cardano-cli commands correctly.
From the host machine, I can see the ./devnet/ipc/node.socket being created. However, if I try to point my local cardano-cli to that node and run any command, I get: cardano-cli: Network.Socket.connect: <socket: 13>: does not exist (Connection refused)

Go to the official page to request a chat with an agent to report this for review and for further assistance Support

I think this might be an OSX issue. I found the following docker-for-mac issue which gives some background context https://github.com/docker/for-mac/issues/483 about why this does not work.


Add apiVersion to specific message filter onXyz[Request|Response] methods

Type of change

Enhancement / new feature

Description
Adds apiVersion to specific message filter onXyz[Request|Response] methods.
Why:
Currently we do not have a way to access the apiVersion for Responses. The apiVersion is in the request headers but so far we have not made it available to response filters. This is a problem when we want to construct response data in the proxy, we need to know which fields can be serialized at the apiVersion used by the client. Also we have started adding code which is trying to sniff the version by checking for non-null fields, sometimes it might be cleaner to switch on the apiVersion instead.
I opted to add it to the signatures for requests and responses for symmetry despite apiVersion also being present in the request header data.
edit: alternatively it could be contextual data delivered via KrpcContext?

My initial reaction was we should include it on both the request and response methods in the API.
However this comment:

edit: alternatively it could be contextual data delivered via KrpcContext?

Triggered another thought: Should the onResponse methods have access to the request or the request Headers in general?
It moves us away from providing "pure" transformation filters into offering Request Response aware filters. I'm not really clear what the implications of that are or what use-cases that helps us support.
To answer the actual question though, No I don't think it should be part of the context as relates to a specific request response pair not general interactions with the proxy itself.

Triggered another thought: Should the onResponse methods have access to the request or the request Headers in general?

Filter authors can achieve this with the existing API. We already provide the guarantee that a filter instance is not re-used across channels. The filter author could implement a filter implements XRequestFilter and XResponseFilter.  On the request side, they cache whatever details they need from the request as filter instance state.   The response side then uses the information.   Admittedly, that is more work for the filter author.
If onResponse API were to offer access to the full request, that would mean that any XResponseFilter implementation would always impose the cost the decoding the request.  That would disadvantage use-cases that don't need the request (performance hit).
If onResponse API were to offer access to the request header only, there will would be a KafkaRequestDecoder#readHeader performance hit imposed on those use-cases.   Is it worth it?  The only thing it would give the response filter author beyond the apiVersion would be the clientId and the request's _unknownTaggedFields.

It moves us away from providing "pure" transformation filters into offering Request Response aware filters. I'm not really clear what the implications of that are or what use-cases that helps us support.
To answer the actual question though, No I don't think it should be part of the context as relates to a specific request response pair not general interactions with the proxy itself.

Filter authors can achieve this with the existing API. We already provide the guarantee that a filter instance is not re-used across channels. The filter author could implement a filter implements XRequestFilter and XResponseFilter. On the request side, they cache whatever details they need from the request as filter instance state. The response side then uses the information. Admittedly, that is more work for the filter author.

Yeah it's more work and potentially often repeated.
Note I'm thinking out-loud rather than advocating for it at this point. I'm trying to envisage the most helpful api for filter authors which makes the most common tasks simple.
Admittedly the sample size is small and potentially biased but most of the filters we have talked about so far are symmetric in that they apply to both the request and response. So I'm thinking about optimising for those cases.

If onResponse API were to offer access to the full request, that would mean that any XResponseFilter implementation would always impose the cost the decoding the request. That would disadvantage use-cases that don't need the request (performance hit).

That's a good point, but if we passed it in with a wrapper we can lazily decode as required (or return the pre-decoded value from the request) I think we have the state in the correlation manager anyway. Having said that what version of the request to provide to the response? The version the client sent or the version forwarded on?

The only thing it would give the response filter author beyond the apiVersion would be the clientId and the request's _unknownTaggedFields.

I think there is a fair chance that those would be interesting to a subset of filter authors. IIRC the schema registry uses that to mark schema coordinates and that's potentially useful in the response. But maybe we are talking about rare enough cases that caching the interesting data in onRequest is good enough.

That's a good point, but if we passed it in with a wrapper we can lazily decode as required (or return the pre-decoded value from the request) I think we have the state in the correlation manager anyway. Having said that what version of the request to provide to the response? The version the client sent or the version forwarded on?

Currently we are constrained in the Filters to only forward requests and responses at the apiVersion requested by the client (after it discovers the supported apiVersions from the broker+kroxy). So apiVersion in the onXyzRequest|Response signatures means the apiVersion from the client. If you tried to set fields incompatible with that version on the data object it will fail at encode time.
An exception is sendRequest, we should make the apiVersion configurable here since the request is initiated by the proxy.
I wonder if these are acceptable limitations. It's conceivable that we could, at the proxy, want to do things like forward a request to the broker at a higher apiVersion than the client supports and then downgrade again at the proxy.


Engineer's turrets models are messed up. They show up as swords on the ground and produce no damage at all

The first engineer turrets are bugged

Can confirm this
image of the sword: http://imgur.com/a/xHTNi
this for me was in the latest build : DAIL0055-FULL-HF2-11-0055CFI2
installed with option ng for the difficulty
no prevous installed mods (its the first one i have tried)
the sword does turn and trys to shoot the ememies, a ball appears but seems to imediatly hit the terrain
over on reddit the developer of the engineer class said he looked at the code but couldnt see anything wrong (posted there first as i was unsure if it was a bug or an unfinished feature)
link: https://www.reddit.com/r/Grimdawn/comments/54zthc/dail_mod_engineers_turret_bug/

Turrets summon correctly in test play.  Version 56 coming soon. Reevaluate this bug after version goes live.

tried full reinstall of the game twice but still have the issue, is the test version already 56 or did you test on a 55 build?
Will 56 hit nexus first or is it available somewhere else beforehand (keen to be able to play again)

I have a 56 stealth version up under dail/release. Points to my drop box.
On Oct 1, 2016 8:43 AM, "Mr G Reaper (aka Dave)"<EMAIL_ADDRESS>wrote:

tried full reinstall of the game twice but still have the issue, is the
test version already 56 or did you test on a 55 build?
Will 56 hit nexus first or is it available somewhere else beforehand (keen
to be able to play again)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/davoodinator/XADAIL/issues/84#issuecomment-250913173,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AULov9wGqvGJej3oqX7GZuokAFhI69EIks5qvmOFgaJpZM4KKFAk
.

Releases are showing as empty to me?

Could you please send a link to 56th release? I have no idea where to find it.

http://www.grimdawn.com/forums/showthread.php?t=46374&page=11
On Sat, Oct 1, 2016 at 9:35 AM, AndreRulofs<EMAIL_ADDRESS>wrote:

Could you please send a link to 56th release? I have no idea where to find
it.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/davoodinator/XADAIL/issues/84#issuecomment-250915561,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AULov159uoRDb56YUK3-nn5dEH1Jn9Qiks5qvm-jgaJpZM4KKFAk
.

0056 Does not work. Install on a clean game. Windows 10. The same model as in 0055. I must add, in 0054, the version that I use, the turrets model is also messed up, however it doesn't effect their ability to damage. Their model becomes this: http://i.imgur.com/A1YDZ4I.png. The turret in versions 0055 and 0056 does do damage but at a very close range, a monster needs to stand directly on top of it which brings me to a conclusion that because of the sword being on the ground, the projectile collides with it upon spawning and does damage around it.
Moreover, I play with a friend playing on 0055 while I play on 0054(he wants to play demon hunter, it somehow works with each other). He also sees swords instead of turrets(windows 7). I am a host, so while he sees swords, the turrets do shoot projectiles on his screen as well as on mine.
I hope it helps. In conclusion 0056 did not resolve the issue.

If you get the opportunity, test NG mode please.
On Oct 1, 2016 10:57 AM, "AndreRulofs"<EMAIL_ADDRESS>wrote:

0056 Does not work. Install on a clean game. Windows 10. The same model as
in 0055. I must add, in 0054, the version that I use, the turrets model is
also messed up, however it doesn't effect their ability to damage. Their
model becomes this: http://i.imgur.com/A1YDZ4I.png. The turret in
versions 0055 and 0056 does do damage but at a very close range, a monster
needs to stand directly on top of it which brings me to a conclusion that
because of the sword being on the ground, the projectile collides with it
upon spawning and does damage around it.
Moreover, I play with a friend playing on 0055 while I play on 0054(he
wants to play demon hunter, it somehow works with each other). He also sees
swords instead of turrets(windows 7). I am a host, so while he sees swords,
the turrets do shoot projectiles on his screen as well as on mine.
I hope it helps. In conclusion 0056 did not resolve the issue.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/davoodinator/XADAIL/issues/84#issuecomment-250919915,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AULov3NEXTJJGlEretrhENBmkFobr1PAks5qvoLNgaJpZM4KKFAk
.

installed 56 over 55, same bug
deleted the local version install on steam, re-installed then installed 56
same bug
tried in single player as well as hosting multiplayer
Only tried ng difficulty, will try the others after work
also windows 10

Tried on S version than on NG. Does not work. The same bug still happens.

Not sure if this could be a factor or not but I do not own the dlc pack

installed build 54 and the turrets work, with the model AndreRulofs showed, the large tank with red tanks around it. wierd thing is it even rotates to shoot the bad guys.
@Kathanious can we get this issue re-opened as it is still an issue with build 55 and the beta of 56

56 has been released on nexus. Play test and feedback show it working. The
installer has been disabled so you will have to download the parts you want
On Oct 2, 2016 8:48 PM, "Mr G Reaper (aka Dave)"<EMAIL_ADDRESS>wrote:

installed build 54 and the turrets work, with the model AndreRulofs
showed, the large tank with red tanks around it. wierd thing is it even
rotates to shoot the bad guys.
@Kathanious https://github.com/Kathanious can we get this issue
re-opened as it is still an issue with build 55 and the beta of 56
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/davoodinator/XADAIL/issues/84#issuecomment-251011839,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AULov3N4S08mxB5JlZaH7bl9ry4CsaX6ks5qwF7xgaJpZM4KKFAk
.

@Kathanious ok i deleted my local content and reinstalled grim dawn fresh, downloaded the first file in the dail's new nexus entry (the 7z 600mb file located here http://www.nexusmods.com/grimdawn/mods/29/?tab=2&navtag=http%3A%2F%2Fwww.nexusmods.com%2Fgrimdawn%2Fajax%2Fmodfiles%2F%3Fid%3D29&pUp=1)
extracted that to the mods folder using a program called 7zip http://www.7-zip.org/download.html (windows built in zip manager did not like the 7z file)
and although the tags dont display on my character in the main menu (to say he is an engineer) he works and more importantly so do the turrets!
Thank you!
(added as much detail as i could to help anyone else that may stumble on this issue, personally hate it when i have the same issue as someone and find "solved it thanks" with no detail lol, pet peev)

Once the mod is loaded, the tag error is gone. Until then, the game doesn't
know what that class is. Dail no longer over writes game files. Enjoy!
On Oct 2, 2016 9:23 PM, "Mr G Reaper (aka Dave)"<EMAIL_ADDRESS>wrote:

@Kathanious https://github.com/Kathanious ok i deleted my local content
and reinstalled grim dawn fresh, downloaded the first file in the dail's
new nexus entry (the 7z 600mb file located here http://www.nexusmods.com/
grimdawn/mods/29/?tab=2&navtag=http%3A%2F%2Fwww.nexusmods.com%2Fgrimdawn%
2Fajax%2Fmodfiles%2F%3Fid%3D29&pUp=1)
extracted that to the mods folder using a program called 7zip
http://www.7-zip.org/download.html (windows built in zip manager did not
like the 7z file)
and although the tags dont display on my character in the main menu (to
say he is an engineer) he works and more importantly so do the turrets!
Thank you!
(added as much detail as i could to help anyone else that may stumble on
this issue, personally hate it when i have the same issue as someone and
find "solved it thanks" with no detail lol, pet peev)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/davoodinator/XADAIL/issues/84#issuecomment-251014458,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AULov-fRyYNNksABKzHgjdDv4ijiY53qks5qwGcagaJpZM4KKFAk
.

@Kathanious i just went to grab it again (was going to try b difficulty) and link a mate to it for multiplayer and the link to build 56 no longer works, can not find it on mod nexus at all, was there a critical bug?

Pulled to get the nexus thing sorted out. Will have it back up this
weekend. If you both still have the 7z files, you can share those to get
multiplayer going.
On Oct 5, 2016 7:36 AM, "Mr G Reaper (aka Dave)"<EMAIL_ADDRESS>wrote:

@Kathanious https://github.com/Kathanious i just went to grab it again
(was going to try b difficulty) and link a mate to it for multiplayer and
the link to build 56 no longer works, can not find it on mod nexus at all,
was there a critical bug?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/davoodinator/XADAIL/issues/84#issuecomment-251661793,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AULovxUttWntvqnGZrNQeuK1c41E-gwbks5qw5m8gaJpZM4KKFAk
.


Don't Merge! PR real time test for source branch full build

OPS Build status updates of commit 531c3de:
:clock10: Pending: waiting for processors (11 builds ahead of you)
:warning: OPS Build is busy, click here to report any potential performance downgrade issues, or you could view Docs Portal for trend of build queue length.

OPS Build status updates of commit 531c3de:
:clock10: Full build: average full build time is 6 min(s) 16 sec(s) [calculated from last 95 build(s)]

Note: This is a FULL build due to a configuration change (usually in .openpublishing.publish.config.json and/or docfx.json). It is strongly suggested to merge this configuration change after the business hours, as it could impact the overall build performance of other PRs on the 'pr-basebranch' branch. For more detailed info, please click here.

OPS Build status updates of commit 531c3de:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

docfx.json
: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.


solarized theme

The solarized 1 theme is quite popular and better for the eyes. This is why I slightly changed the colors.
Timeseries have still a white background thought. The grid are quite nicer in my eye.

I guess the same remarks as #54 apply here: a theme switcher is needed before this sort of change can be made.

OK, I might try to look into this if I have some time.

Gonna close this for now--not because I don't want it, but because I can't find time to build the theme manager we need. I'm really sorry. Feel free to reopen when we get that built!


fix: reverted previous revert

Description
Reverted previous revert for these fixes and applied the changes
Test coverage results :test_tube:
:red_circle: Total coverage has decreased
// Code coverage diff between base branch:release and head branch: property-pane-updates

Status
File
% Stmts
% Branch
% Funcs
% Lines

:red_circle:
total
54.89 (0)
36.7 (-0.01)
34.21 (0)
55.42 (0)

:green_circle:
app/client/src/pages/Editor/PropertyPaneHelpButton.tsx
85 (0)
75 (8.33)
50 (0)
84.21 (0)

:red_circle:
app/client/src/pages/Editor/Explorer/PluginGroup/PluginGroup.tsx
88.46 (0)
60.78 (-0.62)
60 (0)
88 (0)

:red_circle:
app/client/src/utils/autocomplete/TernServer.ts
50.47 (-0.24)
38.26 (-0.87)
36.21 (0)
55.08 (-0.27)

/ok-to-test sha=c4b97b7

@Nikhil-Nandagopal List of issues observed:

Image widget name is getting cropped in List widget

JS Object is not coming in Entity Explorer to test js action line 21

3. Placeholder for fusion chart is not proper

/ok-to-test sha=0ed2b47


The ${BOARD} parameter is not provided at the start of the CMakeLists.txt file

During a recent update to zephyr the CMAKE variables availability changed and it is not possible to access them before the call to find_package(Zephyr), we have to support this behavior since currently all our exaples rely on using the BOARD variable.

Fixed in #192


Memory leaks in all the examples?

This is probably more of a generic problem on most javascript libraries out there but I thought it is important to point it out. Namely that the examples in the documentation all creates memory leaks. For instance:
var http = require('http'),
    path = require('path'),
    os = require('os'),
    fs = require('fs');

var Busboy = require('busboy');

http.createServer(function(req, res) {
  if (req.method === 'POST') {
    var busboy = new Busboy({ headers: req.headers });
    busboy.on('file', function(fieldname, file, filename, encoding, mimetype) {
      var saveTo = path.join(os.tmpDir(), path.basename(fieldname));
      file.pipe(fs.createWriteStream(saveTo));
    });
    busboy.on('finish', function() {
      res.writeHead(200, { 'Connection': 'close' });
      res.end("That's all folks!");
    });
    return req.pipe(busboy);
  }
  res.writeHead(404);
  res.end();
}).listen(8000, function() {
  console.log('Listening for requests');
});

The problem is that a new instance of the Busboy class is instantiated everytime a request is handled. This instance sets a couple of event listeners ('file' and 'finish'), however these listeners are never removed, therefore the GC will not be able to free the busboy object ever since the listeners will keep listening for ever...
An improvement here would be to remove the listeners in the 'finish' event handler, however this assumes that this event will always be triggered, but this may not be always the case. We could add a new event listener that listens for the 'error' event, and hopefully either 'error' or 'finish' will be called, however this needs to be guaranteed by the library, otherwise we are just assuming it and potential memory leaks still be there.
I know I am very late to the party but anyway, this is important in my opinion.

Actually after giving more thought to it, maybe there are no memory leaks at all, and I did not make a proper analysis. For instance the reference that keeps the busboy instance in memory is:
req.pipe(busboy)

If req gets unreferenced when the stream has completed/failed, then in the GC should be able to collect req as well as all the stuff req is referencing including the busboy instance and all their listeners.
I apologize if this is the case but I could not find any information about this in node's documentation.

Actually after giving more thought to it, maybe there are no memory leaks at all, and I did not make a proper analysis. For instance the reference that keeps the busboy instance in memory is:
req.pipe(busboy)

If req gets unreferenced when the stream has completed/failed, then in the GC should be able to collect req as well as all the stuff req is referencing including the busboy instance and all their listeners.
I apologize if this is the case but I could not find any information about this in node's documentation.

There is no problem with leaving event listeners on an emitter because busboy is limited to the scope of the HTTP request handler. Eventually the GC will collect all of those resources: busboy, req, res, etc. Setting those variables explicitly to undefined or similar is unnecessary due to how GC works in JavaScript.
If your process is crashing with an OOM error, then the culprit is going to lie elsewhere as there is no leak with the code you've provided. If it's not crashing with an OOM error, then most likely what you're seeing is the laziness of the GC. It doesn't free memory ASAP. You can however force a GC to occur by passing '--expose-gc' via the command line and then calling global.gc() whenever you want. However, forcing the garbage collector to run is not what you should be doing. If your concern is total memory usage, there are ways to limit V8's total memory usage.

There is no problem with leaving event listeners on an emitter because busboy is limited to the scope of the HTTP request handler. Eventually the GC will collect all of those resources: busboy, req, res, etc. Setting those variables explicitly to undefined or similar is unnecessary due to how GC works in JavaScript.
If your process is crashing with an OOM error, then the culprit is going to lie elsewhere as there is no leak with the code you've provided. If it's not crashing with an OOM error, then most likely what you're seeing is the laziness of the GC. It doesn't free memory ASAP. You can however force a GC to occur by passing '--expose-gc' via the command line and then calling global.gc() whenever you want. However, forcing the garbage collector to run is not what you should be doing. If your concern is total memory usage, there are ways to limit V8's total memory usage.


Added migration executor layer

standard executor preserves current behavior (i.e. applies tenant migrations
in sequence)
multiprocessing executor applies tenant migrations asynchronously

Fixes #38

Really nice feature!!
One question: Couldn't you easily run into issues with too many database connections, when your number of tenants exceeds your max connections on the DB server? Maybe it would be safer to be able to limit the level of concurrency, also to not get too many fork processes at once.

Sure, I'll add such limit as a django settings.

Really Good
in django_tenants/migration_executors/base.py you are checking that the version is greater than 1.7. You can get rid of that line
Any chance of a test for this feature.

Yeah, I started to develop for https://github.com/bernardopires/django-tenant-schemas then I noticed that we use your fork so I forgot that 1.7 :) Removing.
I'll add tests.

thanks

I added option to specify custom executor when running tests, they seem to pass both with default standard executor and with the multiprocessing one. I can also add unit tests for the executor module if you want, it's just I don't see unit tests here at all :)

@CGenie Testing is a bit thin as the parent project didn't have a lot. I am now trying to get untests a bit better.

I actually looked more carefully at tests -- I don't see point of inserting unittests to this code as it is quite simple. As for testing if migrations work, we have such tests in test_tenants.py so it is sufficient to run tests for every executor I think. Do you agree?

If you want I can add Travis integration to the project :)

@CGenie I will get this merged in later today thanks for your hard work

Tests pass, cool that this will be merged :)

Nice :) Thx, for merging. I thought it wold take more time. @CGenie is a real code genie ;)

@kosz85 I guess he works with you. I can see he is very good coder

@CGenie is there any way to add custom executors on my project and use it on migration?

@alexandrebarbaruiva Looking at
https://github.com/tomturner/django-tenants/blob/master/django_tenants/migration_executors/__init__.py
it seems you can. Just add a new class with a custom codename like this one:
https://github.com/tomturner/django-tenants/blob/master/django_tenants/migration_executors/standard.py
I don't know what you want to do in your custom executor, but task here was to wrap whatever django-tenants did during migrations into parallel code. So it's just about calling run_migrations from
https://github.com/tomturner/django-tenants/blob/master/django_tenants/migration_executors/base.py
which is a wrapper around django's MigrateCommand.


CBR vault SDK resource

Is there a plan for implementing CBR cli?

yes, later. I release the service in batches. Otherwise the review will be huge.


File download with original filename

Hi
Thanks for this awesome gem. - Really appreciate.
How do I download the file with its original filename? currently, the file gets downloaded by its id.

I'm assuming you're using filesystem storage. For now the only way to have file downloaded by filename is to actually save files to a location that ends with their filename. When the Content-Disposition response header is absent, the browser will default to using the last component of the URL as the filename.
class MyUploader < Shrine
  def generate_location(io, context)
    [super, *context[:metadata]["filename"]].join("/")
  end
end

But there is feature in the download_endpoint plugin that has been in my backlog for some time, which would automatically apply the behaviour you're requesting. The download_endpoint plugin provides a Rack endpoint which is an alternative way to download files (alternative to the Rack::File middleware in case of filesystem storage).
mount Shrine::DownloadEndpoint => "/attachments"

It has the ability to set the Content-Disposition response header to any file (which the browser would use a the download filename), but it currently doesn't know what is the original filename, it only knows what the URL provides and that's the uploaded file id.
uploaded_file.url #=> "/attachments/<file-id>"

The simplest solution would probably be to modify Shrine::UploadedFile#url, which generates the URL to the download endpoint when the download_endpoint plugin is loaded, to add an additional filename query parameter to the URL, which the download endpoint can then use to populate the Content-Disposition response header.
uploaded_file.url #=> "/attachments/<file-id>?filename=nature.jpg"

However, I think there is a better solution which would be more flexible, one which would expose all metadata to the download endpoint. The idea is to take the whole uploaded file hash
{
  "id": "9sguo8u298u.jpg",
  "storage": "store",
  "metadata": {
    "filename": "nature.jpg",
    "mime_type": "image/jpeg",
    "size": 893825
  }
}

and encode it into an URL-safe identifier, and then use it as the URL. The download endpoint would then receive that string, decode it back into a hash, and have all the file information available. That would be more flexible for several reasons:

it would be able to set the correct Content-Disposition header (your use case)
it would always set the correct Content-Type response header, whereas currently Content-Type is determine from file id extension using Rack::Mime, which doesn't know about all MIME types, and the file id might not have a file extension in all scenarios.
it would account for cases where the storage itself doesn't know about the filesize of the file, so then the size metadata could be used for the Content-Length header as a fallback.
it would allow obfuscating the file id from the user by using a secret key when encoding the hash
it would remove cache/store from the URL, which is unnecessary information for the user

Dragonfly does the same thing, it encodes processing commands in the URL, so this would probably use the same implementation as Dragonfly.

This has been fixed in https://github.com/janko-m/shrine/commit/e333647ab5ada1ba7ec95d836130baa17fd61a8b, which makes the download_endpoint automatically use the filename metadata value in the Content-Disposition header. So, to fix the issue, instead of having Rails/Rack serve the uploaded files, use download_endpoint instead.


pause music when game is paused

Pause music when game is paused. I think that's a good idea.

@Scruffy21 I agree, it makes sense that the music will be paused also.

Completed by @Scruffy21


Elastic interface logging in page {"statusCode":404,"error":"Not Found","message":"Not Found"}

🐛 Summary
This issue is regarding chapter 3 logging in to the web interface https://<LINUX_SERVER_IP/HOSTNAME>
Everything is setup and running. The docker containers on the linux server is running and Winlog is running on the Windows Event Collector.
For the Windows Event Collector:
The inbound firewall rule: TCP port 5985 is open to accept connections from the clients.
The outbound rule is open : TCP port 5044 is open for outbound connections to the Linux server
For the Linux Server:
Inbound: The TCP port 5044 is open for inbound connections from the Windows Event Collector.
What could be causing this? Any help is much appreciated, thank you.
To reproduce
Steps to reproduce the behavior:
I log in with my elastic credentials in the web browser interface and then I get this message:
{"statusCode":404,"error":"Not Found","message":"Not Found"}
Expected behavior
What did you expect to happen that didn't?
To get forwarded to the LME GUI after logging in.
Any helpful log output or screenshots
Paste the results here:

Add any screenshots of the problem here.

@markofsuccess - Are you sure you created this issue in the correct repo?

@markofsuccess - I'm closing this issue as I don't think it applies to this repository.  If you disagree, feel free to reopen it and explain how it is relevant.

Hey
Sorry I did not get notice of your reply. I dont understand, this problem is regarding the CISA LME guide chapter 3, is this not that repository?

Ah, LME is Logging Made Easy.  I'll move the issue to the correct repository and someone there should be able to help you.


Homebrew is designed to work without using sudo.

Homebrew is designed to work without using sudo. You can decide to use it but we strongly recommend not to do so. If you have used sudo and run into a bug then it is likely to be the cause. Please don’t file a bug report unless you can reproduce it after reinstalling Homebrew from scratch without using sudo
!/usr/bin/env bash
Install command-line tools using Homebrew.
Ask for the administrator password upfront.
sudo -v

What were you trying to do? None of my dotfiles contain sudo brew.


Added a class to manage asynchronous event handling

With the GamepadThread and the handler class it is now possible to use callbacks instead of direct polling for the events. The thread will poll the original library and use the callback only when necessary.
In this way it is possible also to run independent code in the main thread.
There are also few additional features like event filtering.
Added also the related documentation

Hi @Zuzu-Typ... Anything about this?

I'm sorry, my notifications were turned off for some reason.
I'll adjust the code a bit here and there and commit it to master.
Thank you very much for your great contribution!


Refactor the cluster package

While working on another feature I found this package hard to scale and add to. By moving the calls to their own functions it gives us a better platform to build upon the cluster sub-command.

Codecov Report
Base: 27.62% // Head: 27.62% // No change to project coverage :thumbsup:

Coverage data is based on head (fd20d05) compared to base (3c910c2).
 Consider uploading reports for the commit e2b754c to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #252   +/-   ##
=======================================
  Coverage   27.62%   27.62%
=======================================
  Files          45       45
  Lines        2476     2476
=======================================
  Hits          684      684
  Misses       1701     1701
  Partials       91       91

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

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


[Feature Request]: Adopt "Custom" Deployment Size from Model Serving for Workbenches

Feature description
Today we have a "custom" functionality in the Model Serving Server creation. This should exist in the Notebook size of things. There is really no difference to the two mechanisms.
Describe alternatives you've considered
No response
Anything else?

Continuation of https://github.com/opendatahub-io/odh-dashboard/issues/1513

Moved to Jira: https://issues.redhat.com/browse/RHOAIUX-30


Apparently LibSodium is missing

When an UDP Packets arrives i get the following nodered log entry and nodered crashes:
11 Apr 00:07:50 - [error] TypeError: sodium.crypto_pwhash is not a function
at DoorbirdUdpSocket. (/data/node_modules/doorbird/dist/index.js:121:55)
at step (/data/node_modules/doorbird/dist/index.js:56:23)
at Object.next (/data/node_modules/doorbird/dist/index.js:37:53)
at fulfilled (/data/node_modules/doorbird/dist/index.js:28:58)
How can i get it running?

@Naruk-TUBK can you provide more information on the runtime of Node Red (e.g. where do you run it or how do you run it)?

This issue may also be related to an issue in the underlying library: https://github.com/ihrigb/node-doorbird/issues/74
This is fixed and the node red plugin is updated: https://github.com/ihrigb/node-red-contrib-doorbird-ultimate/releases/tag/v1.2.3
Feel free to test it and let me know, if there are further issues.


super-productivity: 7.11.6 -> 7.12.0

Description of changes
https://github.com/johannesjo/super-productivity/releases/tag/v7.12.0
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Not related to this update, not sure if we can use electron_18 for this package :thinking:

I just gave it a try and it worked fine with electron_18.


May I know why it is BII-wushuang and not DII-wushuang

[di for di in ahh if not di in ahh]

EHHH


Add remaining documentation of python course

Description
Add 4 topics one PR lvl2 or 3 depends on content and time
Screenshots
No response

Please, assign it to me and I will make a PR asap and give me level 3, are you agree?

Ok but maintain the quality of content
Do not copy paste from anywhere
If possible improve the current documentation

Ok, I will not make copy and paste from anywhere @arpit456jain
Please, assign it to me to start working on it

Please, close this issue@arpit456jain

Please close this issue too @KKhushhalR2405


godot(-mono): Add Persistent Data

https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html

:D

Install and Update works with just the "persist" setting :P

So user who already used this software and have the configuration in %APPDATA%\Godot will have to start again after update.


Using IDcoumentSession as a singleton

I am instantiating an IDocumentSession object as a singleton, using ASP.NET Core DependencyInjection Provider.
I am also setting in UseMarten lazyStoreInitialization on true and in UseSessions the ServiceLifetime as Singleton.
This doesn't seem to be enough. I have inspected the code and fount out that the Connection object is being disposed and set to null on every commit, since The CommandRunnerMode is no external! Setting CommandRunnerMode to external means: The Transactions will not be comitted.
Managing the transactions on my side would be too complicated. All I needed is a singleton object, comitting on every saveChange call. Is that possible or do you have any demo for that case?

@mhabibal13 you should not use IDocumentSession as a singleton, it should be scoped or transient. DocumentStore should be Singleton.
That comes from the stuff like the timeouts etc. Underneath we're using NpgsqlConnection that officially is recommended to use as Transient, and never as a singleton.

@mhabibal13 you should not use IDocumentSession as a singleton, it should be scoped or transient. DocumentStore should be Singleton.
That comes from the stuff like the timeouts, transactions etc. It's practically not possible to maintain such long open connection/transaction.
Underneath we're using NpgsqlConnection that officially is recommended to use as Transient, and never as a singleton.

Yes, I agree on that. Still, I don't get the point of having UseSessions with the following override
IServiceCollection UseSessions(ServiceLifetime sessionLifetime = ServiceLifetime.Scoped, SessionOptions options = null). Doesnt that mean, that Session could be instantiated as a singleton.
Still, setting it to Singleton doesn't make it a one.
So I was confused of that behavior.

I think that you're referring to https://github.com/jokokko/marten.aspnetcore. You should file an issue there. This is not yet official Marten plugin.
It's almost official, as @jokokko is one of the Marten maintainers, but still, it's not yet in the Marten project official Umbrella.
Currently, we don't have any code in Marten directly related to IoC.
I believe that the intention was to not block User to register Session in different scope if the user needs it. Technically you can register it as a singleton, but in most of the cases that practically doesn't make much sense.

I see. Thanks

@mhabibal13 see also my sample of Marten IoC configuration https://github.com/oskardudycz/EventSourcing.NetCore/blob/master/Sample/Tickets/Core/Storage/MartenConfig.cs#L39


Log rotation

Substrate logs to stderr and stdout. It is impossible to organize log rotation without copying previously logged data. E.g. logrotate has to be configured with copytruncate option that copies the file and truncates it, losing some data in the process.
Would be best to use a logger that supports rotation out of the box, or at least allows reopening output file on SIGHUP
https://github.com/emabee/flexi_logger looks promising, as long as there's no performance regression.

AFAIK that is already done.

AFAIK that is already done.

It is done rather inefficiently. By copying gigabytes of data and losing some data in the process. logrotate copies all of the file and calls ftruncate on it. See copytruncate    description here Simply splitting the output would be more efficient indeed, but that would require using custom log file management, instead of relying on logrotate.

logrotate is quite standard in linux operating systems and modern service managers like systemd also connect to stdout resp stderr to pipe it into their journal. Even further container based deployments also rely on log output to stdout/err. The issue here that i see is that tracing produces too much data for that to handle.
The most easy solution would probably be to scale up the disk of the hosts (and use smaller log chunks to rotate) and be more specific in trace logging. Apart from that if one wants to deal with that on a host basis i suggest to make the logfile management at least optional, in larger setups it's probably easier to directly send the data off the host via rsyslog or something.

The issue here that i see is that tracing produces too much data for that to handle.

No it is not. I've already described the actual issue twice here. Namely copying the log data needlessly, but more importantly losing log data. logrotate does not account for new log writes while the file is being copied. This is documented in man page that I've linked earlier.  And it is already interfering with out ability to fix bugs. The important logs to fix https://github.com/paritytech/stakingops-issues/issues/15 or https://github.com/paritytech/stakingops-issues/issues/1 are missing exactly because of that.

I assume the is a correlation between the total amount of logs and the amount of logs being lost. my argument was refering to that systemd's journald cannot cope with the amount of data.
would it be possible for the client to respond to a signal e.g. SIGUSR1 for closing and reopening stdout/stderr? not sure how that would pass through systemd here though.

I assume the is a correlation between the total amount of logs and the amount of logs being lost. my argument was refering to that systemd's journald cannot cope with the amount of data.

Sure, if you produce less logs you'll lose less of them. With zero logs there won't be any losses at all. But we do need these log to fight bugs.

would it be possible for the client to respond to a signal e.g. SIGUSR1 for closing and reopening stdout/stderr? not sure how that would pass through systemd here though.

That's what I suggested in the issue description. Typically SIGHUP is used for ths.

Would be best to use a logger that supports rotation out of the box, or at least allows reopening output file on SIGHUP

That's what I suggested in the issue description. Typically SIGHUP is used for ths.

if output file can also still be stdout/-err then yes :)

I'm not sure I follow here: flexi_logger does support log rotation out of the box.
Would the ideal setup be:

Check if output is atty:
1.1 If it is, then do not log to a file, basically do nothing.
1.2 If it is NOT, then setup a log rotation (with what size limit / age limit?)
Profit?

Note that this does not do anything special with SIGHUP / SIGUSRX.
cc @gabreal @arkpar

Reasigning to @pscott because he already started.

Check if output is atty:
1.1 If it is, then do not log to a file, basically do nothing.
1.2 If it is NOT, then setup a log rotation (with what size limit / age limit?)

Looks about right. I'd also add a CLI option for configuring size/age limit. Unlimited by default.

So I've made some progress on this. I think the only way we can actually do log rotation with flexi_logger is if we specify from the beginning that our target is a file (i.e. not something like substrate 2>my_file.
What I'm thinking here is that we should have --log-file FILE and one of (--log-size U64 / --log-age U64) flags. Last but not least I would add the --log-duplicate BOOL flag, for the user to choose rather he'd like the log to be duplicated to stderr.
Does that sound good @arkpar ?

This avoid doing things like checking for isatty and trying to interpret what the user actually wants. Also makes logging much clearer and simpler imo :)

In that case --log-file should capture stderr indeed. We already have duplicating of INFO and WARN messages to stdout when stderr is redirected to a file. So that user could see default info in the console while extended log is written to a file. Would be ideal to preserve that.

So to make sure we're on the same page here: --log-duplicate should be set to default to INFO level?
We'd have this UX:

No --log-file provided -> all logs are written to stderr
--log-file provided -> logs are written to file, and logs >= INFO level are written to stderr

I would personally have added the --log-duplicate, making the logging to stderr an opt-in rather than default.
PS: to work with flexi_logger, I had to remove the piece of code that automatically duplicated the INFO and WARM messages to stderr (this was located in the format function passed in to the log builder). I can still add it back with a simple call to .duplicate(), so it's just a matter of how we want it to behave :)

More like this:

No --log-file provided -> all logs are written to stderr, INFO messages are duplicated to stdout but only if stderr is a file.
--log-file provided -> logs are written to file, and logs >= INFO level are duplicated to stdout. stderr is empty

Basically --log-file would simply redirect stderr to a file preserving existing behaviour and making stderr empty. --log-duplicate would duplicate all messages to stderr. But again, INFO messages should be additionally copied to stdout if stderr is not attached to a console.

Should be possible once https://github.com/emabee/flexi_logger/pull/51 gets merged :)

Reopening after #6627

So there were a couple of problems with #6564 :

init_logger() was modified to error when it failed, instead of warning. This resulted in a big API break, which is not desirable.
Add to that that it was very easy to break stuff because I did not notice that flexi_logger only accepts filters that do not contain hyphens. This is easily fixable by .replace('-', '_') on the filter we wish to add. My bad on this one!
On top of that, even though flexi_logger uses a similar syntax to env_logger, specific targets cannot be targeted. For example, using env_logger, one can add a filter that says my_target=trace, and have logs like info!(target: "my_target") be properly logged. Unfortunately, this is not possible (yet) with flexi_logger (from what I know). This is a big deal, as this means that there is no way to run for example substrate --log sub-libp2p=trace.

Last but not least:

API wasn't that ergonomic and @bkchr had to tweak it by putting the LogRotationOpt in an Option. We talked about it with @cecton and think LogRotationOpt should have public fields in order for it to be easy to construct without necessarily requiring a cli :) (no other constructor are implemented by LogRotationOpt).
Weird space / tabs were introduced (see this comment)

So all and all this was a mess! As soon as targeting specific targets gets supported by flexi_logger, everything should be fine as these are all really small and easy tweaks to do! :)

As soon as targeting specific targets gets supported by flexi_logger,

What you mean by this?

As soon as targeting specific targets gets supported by flexi_logger,

What you mean by this?

I created an issue on flexi_logger repo and I'm currently trying to see if I can solve it myself and submit a PR :)

I'm still more in favor of switching to slog. I know that we need to rewrite some parts of telemetry, but I started this here already: https://github.com/paritytech/substrate/commit/b91620bef6b7eaa3c35e08bf65f0ec3eb1561165

I'm still more in favor of switching to slog. I know that we need to rewrite some parts of telemetry, but I started this here already: b91620b

I'll let other participants jump in here :) @tomaka @arkpar @gabreal @marcio-diaz

from the devops perspective the particular implementation is not important. what is required is the ability to log everything to stdout/stderr in order to have systemd's journal or dockerized deployments easily aggregate the logs.

from the devops perspective the particular implementation is not important. what is required is the ability to log everything to stdout/stderr in order to have systemd's journal or dockerized deployments easily aggregate the logs.

If we use systemd with journald I don't see how we lose logs. If I understand right, we lose logs only because we use logrotate somewhere (please correct me if I'm wrong). Could we get rid of logrotate and use systemd instead everywhere?

that's correct yes (for loosing log entries with logrotate). afaik logrotate is not used anymore (as now systemd's journal is in use everywhere). maybe this could be useful for heavy trace logging. @ddorgan what do you think?

oh... ok :thinking: @arkpar do you know if we still lose logs somewhere?

Flushing the logs on SIGHUP would be really great. We're currently working around the logrotate losing some logs by using journald anyway, but it would nice to have the option of using logrotate without data loss.

Indeed this issue was originally filed to tackle log issues caused by logrotate. This is includes loss of log data and node stalling because copying around huge log files choked disk IO.
If logrotate is no longer used, this is less of an issue. Though custom log rotation would still be useful I think. Not all platforms have journald and for and end users it might be easier to use something build-in.

Actually it would be great to move away from journald logging if possible, there's quite a big performance overhead right now. So how far off is this? Would be very happy to test once ready.

@ddorgan A PR that adds log rotation out of the box will be ready as soon as this issue on flexi_logger's repo is fixed (this one basically).
This is, unless we decide to focus on slog or to keep on using env_logger :)

@pscott great, just ping me when it's ready to be tested.

Sorry but I'm going to play devil's advocate here.

it would nice to have the option of using logrotate without data loss.

Apparently log_rotate = data loss. The way the fix was designed is that substrate would play the role of log rotate. The next fix would be the same. Logrotate is out in all scenarios afaiu.

there's quite a big performance overhead right now.

I would really like to know more about that.
Also it's a sign that log rotation is not exactly easy to implement. Therefore a custom solution instead of a well known, battle tested and commonly used solution might not be the best idea.
My point is: handling logs might be best handled by the OS.

Not all platforms have journald and for and end users it might be easier to use something build-in.

I assume every platform has its own logging mechanism. On Linux it's mostly system.d. I'm not a fan of system.d but if it does it's job...
Overall I think our motivations are questionable. I'm really not against adding the feature of log rotation but I think it is important to not rush it. Don't forget that we just reverted our first attempt already. If there is no more urgency (since we use journald now), then we should consider taking our time and thinking this though.


Get a random available port

This would be perfect for making Ollama a child process.
Here's what this may look like:

The parent process starts
The parent process does a command like env OLLAMA_HOST=localhost:random ollama serve
The child process ollama gets a random available port from the OS and outputs the port number to stdout. Otherwise, it crashes.

This is already possible if you set OLLAMA_HOST=:0


[entrypoint] Adds --additional-bin-dir option to entrypoint

Adds --additional-bin-dir option to entrypoint to add binDir configuration option
As well as doc updates.

Pull Request Test Coverage Report for Build 880

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 73.66%

Totals

Change from base Build 879:
0.0%

Covered Lines:
948

Relevant Lines:
1287

💛  - Coveralls


Inconsistent number of ack ranges in new ackframe

• Failure [4.207 seconds]
Chrome tests
/home/lucas/src/github.com/lucas-clemente/quic-go/integrationtests/chrome_test.go:196
  with quic version 34
  /home/lucas/src/github.com/lucas-clemente/quic-go/integrationtests/chrome_test.go:194
    uploads a large file [It]
    /home/lucas/src/github.com/lucas-clemente/quic-go/integrationtests/chrome_test.go:193

    Expected error:
        <*errors.errorString | 0x1d5c8a60>: {
            s: "multipart: Part Read: InternalError: BUG: Inconsistent number of ACK ranges written",
        }
        multipart: Part Read: InternalError: BUG: Inconsistent number of ACK ranges written
    not to have occurred

    /home/lucas/src/github.com/lucas-clemente/quic-go/integrationtests/integrationtests_suite_test.go:120
------------------------------

Do you have a log for that?

Log: https://dl.dropboxusercontent.com/u/1428776/log_306.txt.zip

There's no such error in this log.

Pushed a test case.


Setting for rounding rule

Now with possibilty to configure which rounding rule should be used by PxWin

Nu har jag godkännt
/Maria
Från: MikaelNordberg @.>
Skickat: den 17 december 2021 10:01
Till: statisticssweden/PxWin @.>
Kopia: Gunnarsson Maria IT/UTV/KOM-Ö @.>; Review requested @.>
Ämne: Re: [statisticssweden/PxWin] Setting for rounding rule (PR #11)
@MikaelNordberghttps://github.com/MikaelNordberg requested your review on: #11https://github.com/statisticssweden/PxWin/pull/11 Setting for rounding rule.
—
Reply to this email directly, view it on GitHubhttps://github.com/statisticssweden/PxWin/pull/11#event-5783265615, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM66V426RLNE52HKX3B7ECDURL35DANCNFSM5KGL45VQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because your review was requested.Message ID<EMAIL_ADDRESS>


Initiators: Breakout vic2png into a separate Airflow DAG

Breakout vic2png into a separate DAG (invoked upon EDR arrival in S3)

@drewm-jpl can you please update this ticket with the current status, and target sprint?


Update azure-core-* packages to 1.0.0-preview.3

Update azure-core-* packages to 1.0.0-preview.3
Update azure-core-* dependencies in some Track 2 libraries because they use the new annotations or the ClientLogger updates

App Configuration
Key Vault
Event Hubs

Looks good. Just note Key Vault is about to move into /sdk, so this might need updating soon.

@JonathanGiles I'm hoping that this build finishes, is successful so I can leave the merging to @mitchdenny. 😈


Add SquareMosaicLayout to UI / Table View / Collection View

Added SquareMosaicLayout
Project URL
https://github.com/iwheelbuy/SquareMosaicLayout
Description
SquareMosaicLayout is an extandable mosaic UICollectionViewLayout with a focus on extremely flexible customizations.
Checklist

[x]  Only one project/change is in this pull request
[x]  Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 3
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Error

:no_entry_sign:
Found 2 link issues

Link issues by awesome_bot

Line
Status
Link

2377
Error
https://github.com/insanoid/CleanHeaders-Xcode  Connection refused - connect(2) for "github.com" port 443

2379
Error
https://github.com/orta/You-Can-Do-It  Connection refused - connect(2) for "github.com" port 443

  Generated by :no_entry_sign: Danger

Hey @iwheelbuy great work👌.
Thanks for contributing to awesome-ios 🙌🏻


Sqlite CLI Query Command

Added a new CLI command called "sqlite". It allows you to run SQLite queries on the database from the CLI.
Example: pocketbase.exe sqlite "DELETE FROM users WHERE name = 'foo'"
I saw issue 2236 and figured it would be easy to implement. First time contributing to open-source code. I ran the linter and there are no errors with my code.

Thank you but it is a little more complicated as we'll also to output a table with the query result, eg. in case a SELECT or EXPLAIN is used.
In any case, for now this is out of the roadmap and has a very low priority.
Before contributing, please check https://github.com/pocketbase/pocketbase#contributing.


✅ Integration tests

Hello, I've rebased and added an integration test, in order to execute it, the following steps need to be followed:

kind create cluster
kubectl -n default create secret docker-registry external-registry-secret --docker-username <my-user> --docker-password <"my-password">
kamel install --olm=false -n default --registry docker.io --organization <my-user> --registry-secret external-registry-secret --wait
k cluster-info # In order to retrieve kubernetes control plane ipaddress, ex. https://<IP_ADDRESS>:19459
kind get kubeconfig # In order to retrieve client-certificate-data and client-key-data values
finally execute test with mvn clean verify -Dkubernetes.master-url=<master-url> -Dkubernetes.client-cert-data=<client-cert-data> -Dkubernetes.client-key-data=<client-key-data> -Dkubernetes.trust-certs=true

A similar test was working with v0 API, I've added timer-to-log-binding.yaml in order to align with v1 API, but the integration cannot be installed due to the following error:
{"level":"error","ts":1656687148.9628937,"logger":"controller.integration-controller","msg":"Reconciler error","reconciler group":"camel.apache.org","reconciler kind":"Integration","name":"tralalala","namespace":"default","error":"error during trait customization: kamelets  found, cron-source,log-sink not found in repositories: (Kubernetes[namespace=default], Empty[])","errorVerbose":"kamelets  found, cron-source,log-sink not found in repositories: (Kubernetes[namespace=default], Empty[])\nerror during trait customization\ngithub.com/apache/camel-k/pkg/trait.Apply\n\tgithub.com/apache/camel-k/pkg/trait/trait.go:48\ngithub.com/apache/camel-k/pkg/controller/integration.(*initializeAction).Handle\n\tgithub.com/apache/camel-k/pkg/controller/integration/initialize.go:54\ngithub.com/apache/camel-k/pkg/controller/integration.(*reconcileIntegration).Reconcile\n\tgithub.com/apache/camel-k/pkg/controller/integration/integration_controller.go:308\ngithub.com/apache/camel-k/pkg/util/monitoring.(*instrumentedReconciler).Reconcile\n\tgithub.com/apache/camel-k/pkg/util/monitoring/controller.go:70\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:298\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:253\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:214\nruntime.goexit\n\truntime/asm_amd64.s:1371","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:214"}

Maybe the kamelets are not installed on that cluster?

Maybe the kamelets are not installed on that cluster

Thanks a lot, this was the issue! to better understand the process, should we expect the kamelet to be installed on the cluster? before executing the test I have installed all the kamelets in camel-kamelets/kamelets.
which means that GET on DeploymentsResource returns all the kamelets installed and I had to do minor changes to the test.

rebase needed


feat(component-renderer): look for components in app path

Hey @lonnieezell, I've made a not so interesting change in order to create the PR for discussion.
After the comment I've made (https://github.com/lonnieezell/Bonfire2/issues/5#issuecomment-908423807), I now realize that the structure of Bonfire2 is quite different from what I have, so I'd like to know what you are thinking about when locating view components.
If I understand correctly, in Bonfire2, each view in a theme can access the local components in the theme folder. And it would be nice to have a way to access common base components like buttons, links, form elements, or whatever to use across themes? So, one way would be to consider the default views folder a good place to put them, or even a Components folder directly in the default app path or themes path? Or another way would be to add a Components config file where we would add other discovery paths?
Also, I'm thinking maybe we would want to share common components to multiple themes but not all. For instance, Admin and Auth themes would have the same base components that the App would not need/share. So maybe the configuration should be done in the Theme class?
One more thing, when locating components, the Theme class is called to get the path, creating a coupling that may not be ideal for the future view components library.
I don't use themes for my project yet, I have a ViewComponents config file where I put the paths to look in. Then, I compare them with the current view path when locating the Components.
Anyways, sorry for the long comment, still trying to figure things out 😅

Wow - so sorry I let this one slip by.
If you're still around and interested I think making a config setting to specify the backup folders to look in would be the way to go. By default just having app/Views would be great.

Hey, no worries, I've worked on it on my project. I'll work on implementing it here sometime this week 🙂

Awesome. Looking forward to it!

As promised, I've pushed the changes :slightly_smiling_face:
Now, as a fallback, the ComponentRenderer's locateView() method will check for the component in the paths defined in the Bonfire config (the $componentsLookupPaths property to be exact).
Let me know if there are any changes to be made!

I've  made the change you requested, sorry I didn't see the Themes config!

Looks great. Thanks for this! Now one of these days I have to get back and explore the regexes some more to make it able to get values from the tag's attributes. :)

@lonnieezell Well, for what it's worth, I've come up with a solution for this but it's kind of a hack, not sure if it's any good (mostly performance wise): I serialize the value in the view to then deserialize it in the component class.
Here's an example to pass an array of options for a multiselect component:
// in the view
<Forms.Field
    as="MultiSelect"
    id="roles"
    name="roles[]"
    label="<?= lang('Person.episode_form.roles') ?>"
    hint="<?= lang('Person.episode_form.roles_hint') ?>"
    options="<?= htmlspecialchars(json_encode($taxonomyOptions)) ?>"
    selected="<?= htmlspecialchars(json_encode(old('roles', []))) ?>"
    required="true"
/>

// in the MultiSelect class component
public function setOptions(string $value): void
{
    $this->options = json_decode(html_entity_decode($value), true);
}

I do the same for other attributes when I need to cast the value to something other than string, here's the required attribute:
public function setRequired(string $value): void
{
    $this->required = $value === 'true';
}

Haven't had the time to really think about it and the code could use some refactoring to have this abstracted. Just like for the Entity, I thought of having a $cast property to set the passed values in the desired type.
Hope this helps!


no dist directory ?

I install your plugin using bower. There is not dist directory as your commit said and there is no minified js file. Am I missing something ?

+1 -- bower install bootstrap-maxlength didn't work for me, suspecting the missing dist-folder to be the culprit...

Please close issue.
Bower support is dropped.
Use git clone for now.
Npm is not updated yet.

npm updated


Warnings produced when splunk resources are in catalog

Affected Puppet, Ruby, OS and module versions/distributions

Puppet: 3.8.6 (with future parser enabled)
Ruby: 2.0.0
Distribution: RHEL 7
Module version: 5.1.0 with forked changes not yet put into Pull Requests (https://github.com/treydock/puppet-splunk)

How to reproduce (e.g Puppet code you use)
Include splunk or splunk::forwarder class on a system
What are you seeing
[root@splunk ~]# puppet agent --test --noop
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Redefining rhsm_register in Puppet::Type
Info: Redefining augeasprovider in Puppet::Type
Info: Redefining shellvar in Puppet::Type
Info: Redefining datacat_fragment in Puppet::Type
Info: Redefining ini_setting in Puppet::Type
Info: Redefining firewall in Puppet::Type
Info: Redefining firewallchain in Puppet::Type
Info: Redefining foreman_resource in Puppet::Type
Info: Redefining idmapd_config in Puppet::Type
Info: Redefining gpg_key in Puppet::Type
Info: Redefining rhsm_repo in Puppet::Type
Warning: The dns_rr resource type is deprecated. Use resource_record instead
Info: Redefining file_line in Puppet::Type
Warning: The a2mod provider is deprecated, please use apache::mod instead
Info: Redefining anchor in Puppet::Type
Info: Redefining datacat_collector in Puppet::Type
Info: Caching catalog for splunk.infra.osc.edu
Info: Applying configuration version '1486415397'

What behaviour did you expect instead
Output produced by commenting out profile that includes splunk class and resources.
[root@splunk ~]# puppet agent --test --noop
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for splunk.infra.osc.edu
Info: Applying configuration version '1486415694'

Any additional information you'd like to impart

I am seeing the same issue on my systems after trying to include the splunk::forwarder class, except in my case, the agent is trying to redefine a module with a Ruby dependency that isn't installed on the client, resulting in the agent run failing:
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Warning: The a2mod provider is deprecated, please use apache::mod instead
Info: Redefining anchor in Puppet::Type
Info: Redefining file_line in Puppet::Type
Info: Redefining firewall in Puppet::Type
Info: Redefining firewallchain in Puppet::Type
Info: Redefining ini_setting in Puppet::Type
Error: Could not autoload puppet/provider/make_server_update/ruby: cannot load such file -- net/http/post/multipart
Error: Could not autoload puppet/type/splunk_config: Could not autoload puppet/provider/make_server_update/ruby: cannot load such file -- net/http/post/multipart
Error: Could not retrieve catalog from remote server: Could not intern from text/pson: Could not autoload puppet/type/splunk_config: Could not autoload puppet/provider/make_server_update/ruby: cannot load such file -- net/http/post/multipart
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

This is with Puppet 4.2.2 as bundled in the puppet-agent 1.2.5 package.

Looks like this is because the splunk_config type loads all of the types in the environment with:
# Require all of our types so the class names are resolvable for purging
Dir[File.dirname(__FILE__) + '/*.rb'].each do |file|
  require file unless file == __FILE__
end

It should be changed to just load the splunk types, like:
# Require all of our types so the class names are resolvable for purging
Dir[File.dirname(__FILE__) + '/splunk*.rb'].each do |file|
  require file unless file == __FILE__
end

I'll do some testing and submit a pull request.

@iamjamestl That change works, the only types getting redefined are splunk module types, oddly only a couple types get redefined.
Info: Loading facts
Info: Redefining splunkforwarder_input in Puppet::Type
Info: Redefining splunkforwarder_deploymentclient in Puppet::Type


Github copilot should operate in the output window to help diagnose error messages

In code window you can press Ctrl+I to access code pilot and ask it to explain. When you build and get compiler / linker error messages in the output window it would be nice if you could highlight the error, press CTRL+I and ask for explain / fix.

That's a great idea! However you're in the wrong repo. See if anyone has suggested it here: https://github.com/orgs/community/discussions and if not, post it


pig QTLdb: GFF3 file violates the spec.

Some required values/columns are missing in the GFF distribution. As a result, there are lines with less than nine columns, which makes parsing more challenging.
(Pathological) example:

Chr.17  Animal QTLdb    Reproduction_QTL     61830469   61855765     QTL_ID=8814;Name=Teat number;Abbrev=TNUM;PUBMED_ID=22443659;trait_ID=167;trait=Teat number;breed=large white,meishan;FlankMarkers;VTO_name=nipple quantity;CMO_name=teat number;Map_Type=Linkage;Model=Mendelian;Test_Base=Genome-wise;peak_cM=85.9;Significance=Significant;P-value=<0.05;Likelihood_Ratio=67.2

Contact the team/helpdesk.

After all, the GFF file has the required (fixed) number of columns in all lines; the example above was copy/paste error. However, there were a couple of lines without start and end coordinates and are now fixed by the data provider.

It seems that In the updated GFF distribution there are still 127 feature lines without start/end coordinates. Work in progress...

Here is the list of QTL IDs:
107253,107254,107255,107256,37847,37610,37611,37612,37613,37614,37615,37616,37617,37618,37619,37620,57634,107257,107258,107259,107268,101475,101528,107269,95893,95923,38083,56250,107240,107245,107248,57638,106314,106315,106316,106317,106318,106319,106320,106321,107260,107270,71077,71078,71079,71080,71081,71082,71083,71084,71085,62295,107241,107246,107249,38056,107250,107261,107262,95943,95944,95945,95946,95947,95948,95949,106201,106202,106203,106204,106205,106206,106207,37672,37705,37733,37744,38063,38065,95950,106287,106414,106415,107263,101780,101786,101790,101805,101817,101846,101858,101878,101890,101905,101907,101914,101919,101934,101941,101414,101440,101451,101476,101485,101517,101529,101543,101744,101778,106288,106289,106290,106291,107251,107252,107264,107265,60828,64663,107242,107243,107244,107247,95951,95952,107266,107267


Add option to show diff between prev state and next state

I find that when troubleshooting I want to see what changes the action caused in the store. So if it was somehow possible to log the delta between prev and next state that would be great.
Perhaps the diffing should not be built-in in the logger, but instead we could provide an option function that receives both prev and next state and can output the desired diff. Today the state transform option functions only receive either prev or next state, not both.

https://github.com/fcomb/redux-diff-logger ?

@epeli Looks good!
However I think it still would be nice if we could get the possibility to extend redux-logger to show diffs.

Tested redux-diff-logger out and seems it does not support Immutable objects well. If we could invert it so the diffing logic is something we can provide from the outside then I could add Immutable support and other things myself.

I suggest continue a discussion in #136.


MIX_* .env variables not available in browser

Laravel Mix Version: 5.0.4
Node Version: 13.12.0
NPM Version: 6.14.4
Yarn Version: 1.22.4
OS: Ubuntu 18.04.4

Description:
I cannot access any process.env variables in my built app.js in Chrome, but I can see them in the webpack.mix.js build script.
Steps To Reproduce:

Add MIX_BASE_URL variable to .env
Dump process.env to console in webpack.mix.js
Dump process.env to console in app.js
Run php artisan config:clear
Restart yarn watch
See list of variables including MIX_BASE_URL in the console (good)
See {} in DevTools (bad)

We created this project with Laravel 7.13.0 just a couple of weeks back.

Here are the config and build script:
webpack.config.js
// This allows autocomplete and navigation in IDE.

module.exports = {
    resolve: {
        extensions: ['.js', '.css', '.scss'],
        alias: {
            '~': __dirname + '/resources/js',
            '^': __dirname + '/resources/sass',
        },
    },
};

webpack.mix.js
const mix = require('laravel-mix');
const config = require('./webpack.config');

// Externalized so IDE can parse it for import paths
mix.webpackConfig(config);

mix.babelConfig({
    plugins: [
        // allows fat-arrow syntax for class methods
        '@babel/plugin-proposal-class-properties',
        // allows ?. for accessing properties safely
        '@babel/plugin-proposal-nullish-coalescing-operator',
        // allows "export * as values from" syntax
        'transform-export-extensions',
    ],
});

mix.react('resources/js/index.js', 'public/js')
    .sass('resources/sass/app.scss', 'public/css');

// Environment-specific configuration

if (mix.inProduction()) {
    mix.version();
}
else {
    mix.browserSync('dealer-portal.test');
}

@dharkness I experienced a similar thing but the variable does give a value when I append the variable name. I don't know if this expected behavior or a bug but maybe it helps you out.
console.log(process.env); // returns {}
console.log(process.env.YOURVARIABLE); // does give the result

@kaphert You are indeed correct; it works. I tried this originally
console.log('url', process.env.MIX_DWS_URL);

and got undefined so I switched it to process.env to see all the variables. I must have done the switch before running php artisan config:clear and borked it too early. Thank you so much.


Release Google.Cloud.BackupDR.V1 version 1.0.0

Changes in this release:
No API surface changes; just dependency updates and promotion to GA.

Created release for Google.Cloud.BackupDR.V1-1.0.0

This was released: https://www.nuget.org/packages/Google.Cloud.BackupDR.V1


Method Encore\Admin\Grid::__toString() must not throw an exception, caught Error: Class 'Symfony\Component\Filesystem\Exception\FileNotFoundException' not found

Laravel Version: 5.5
PHP Version: 7.1.13
Laravel-admin: 1.5

Description:
Method Encore\Admin\Grid::__toString() must not throw an exception, caught Error: Class 'Symfony\Component\Filesystem\Exception\FileNotFoundException' not found
Steps To Reproduce:

Can you show your code ?

Can you show your code ?

No reply, close


Add a span macro

Problem

Spans don't need style interpolation as they have a single style, but it would be nice to constrict them with format strings.
Solution

Implement a declarative macro span! That effectively is a shortcut for Span::styled(format!(...), style)
Not sure where to put the style parameter for clarity. Either first or last might make sense.
Alternatives

Additional context

I would like to work on this but can I ask why PR: https://github.com/ratatui-org/ratatui/pull/803 closed?

I moved it over to https://github.com/ratatui-org/ratatui-macros instead. The rationale was a series of DMs on discord with @kdheepak, but basically we decided to move it over there to experiment with it for a bit before we bring it into the core.
Either way, this one can be closed for now.