Bug: false positive of RSpec/LetSetup with context and outer shared_examples

This issue produces false positives of Rspec/LetSetup with the latest rubocop-rspec (1.36.0) when we put let! inside some context and we also have shared_examples referencing that let! outside the context.
Something like this:
shared_examples 'some shared example' do
  it 'checks something' do
    is_expected.to eq user
  end
end

context 'when inside some context' do
  let!(:user) { create :user }

  include_examples 'some shared example'
end

If we are to run rubocop-rspec on the code above it would produce the following:
spec/test_spec.rb:8:3: C: RSpec/LetSetup: Do not use let! to setup objects not referenced in tests.
  let!(:user) { create :user }
  ^^^^^^^^^^^

1 file inspected, 1 offense detected

This is a limitation of the static analysis. The shared examples could be defined in a separate file as well, and Rubocop does not cross-reference files. I would suggest to explicitly pass user in this well, like
include_examples 'some shared example', user

and
shared_examples 'some shared example' do |user|

This way you will not have a hidden dependency in the code.

I have just tried the proposed solution and it causes failures in my tests, as the user created by FactoryBot is reused between tests (since it is created outside of a test context). You also cannot declare user in a let above the include_examples and use it as a parameter for the same reason.

How about
  include_examples 'some shared example' do
    let!(:user) { create :user }
  end

That works, but it still raises a RSpec/LetSetup warning.

I guess the cop should really ignore let! inside include_examples blocks, as it can't determine whether the let is used in the shared examples or not

Agree. Another exception would be an example group that is including examples, since it's impossible to determine if it's referenced or not.

I'm fairly certain this isn't limited to shared examples.
If you have a top-level subject and create an object inside a context with a let!, you will get the same false positive.
I.e.
subject(:foo) do
  post "url",
    params: {
      id: my_object.id
    }
end

context "when calling the method" do
  let!(:my_object) { FactoryBot.create(object) } # you will get a false positive here

  it { .. }
end

I've hit this when using let! in shared_context, which is the reverse situation.

@StuartHadfield Why would you use a bang-let over a regular let, if the variable is referenced from a top-level subject definition, i.e. is always initialized?
@njm506 Can you please describe your case in more detail?

We use let!, for example, to set something up that needs to be present before before is executed, and that we also need to reference in the tests.  Here's a mock-up of part of the spec in question:
  shared_context 'when there is a local record' do
    let!(:record) do # rubocop:disable RSpec/LetSetup
      test_record(
        key: 'value' # Our use-case has a lot more properties
      )
    end
  end

  context 'when syncing a new foo' do
    include_context 'when there is a local record'

    before do
      rest_api_post.to_return(body: '{"id":"new-id"}', status: 200)
      described_class.sync_all	# This references the record that test_record created
    end

    it 'creates the foo' do
      expect(rest_api_post.with do |req|
        # Some criteria here
      end).to have_been_requested.once
    end

    it 'stores the returned id' do
      expect(record.foo_id).to eq('new-id')
    end
  end

  context 'when syncing a new foo but creation fails' do
    include_context 'when there is a local record'

    before do
      rest_api_post.to_return(body: '', status: 400)
      described_class.sync_all
    end

    ...
  end

I don't receive any offences @njm506
Inspecting 1 file
C

Offenses:

spec/a_spec.rb:1:1: C: Style/FrozenStringLiteralComment: Missing frozen string literal comment.
RSpec.describe 'A' do
^
spec/a_spec.rb:15:81: C: Layout/LineLength: Line is too long. [84/80]
      described_class.sync_all	# This references the record that test_record created
                                                                                ^^^^
spec/a_spec.rb:36:1: C: Layout/EmptyLinesAroundBlockBody: Extra empty line detected at block body end.

1 file inspected, 3 offenses detected

I'm using 1.42.0 and it's giving me it for that example (when I remove the rubocop:disable marker):
Inspecting 1 file
C

Offenses:

spec/test.rb:1:1: C: Style/FrozenStringLiteralComment: Missing frozen string literal comment.
describe 'foo' do
^
spec/test.rb:3:5: C: RSpec/LetSetup: Do not use let! to setup objects not referenced in tests. (https://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/LetSetup)
    let!(:record) do
    ^^^^^^^^^^^^^

1 file inspected, 2 offenses detected

Trying to add 2 cowries

Why would you use a bang-let over a regular let, if the variable is referenced from a top-level subject definition, i.e. is always initialized?

The plain let is lazy evaluated, i.e. executed when first called. If the subject is the first to instantiate the fixture, all of the instantiation's side-effects creep into the subject's execution scope. E.g. consider the example is about to measure the number of database calls for the execution of subject. This would include all database statements to instantiate the fixture too, likely unwanted.
let! is evaluated clearly before the subject is executed, and can therefore help to keep all unwanted, setup related side-effects out of the subject.

IMO, I generally do not use the case presented because it is also confusing when adding/updating/organizing tests. This is because in that case user, which is implicitly required by shared_examples, is not obvious to those using shared_examples. I feel that it is better to explicitly pass it as a parameter to shared example groups so that the intent is clear.
shared_examples 'some shared example' do | user |
  it 'checks something' do
    is_expected.to eq user
  end
end

context 'when inside some context' do
  let!(:some_user) { create :user }

  include_examples 'some shared example', some_user
end

@qaysar-labs just express your solidarity by pressing the thumbs up button under the ticket description.
Or, better, send a PR.

@phorsuedzie This might be a different issue of those lets not being detected as used. Most certainly due to the shorthand hash syntax.

subject(:update_user) { user.update(name:) }

expect { update_user }.to ...

This is prone to incidental state.
subject/let memoize their result, and won't run twice, which immediately makes them a bad fit for some cases, e.g.
subject(:remove_top_card) { cards.pop }
it "removes two cards" do
  expect { remove_top_card }.to change { cards.count }.to(1)
  expect { remove_top_card }.to change { cards.count }.to(0) # 💥
end

There's no point in abusing this mechanism, define a helper method:
def remove_top_card = cards.pop

def update_user = user.update(name:)

Also mind implicit block expectations.

FYI: My initial concern was about that the issue is independent from whether shared examples are involved.
Here is another one without any shared context/examples, and also without any incidental state that might distract from what I am actually talking about:
`bundle exec rspec -f d spec/array_size_spec.rb
RSpec is actually happy.
Array#size
  when array is a monopel
    when item is nil
      returns 1
    when item is boolean
      returns 1

Finished in 0.00081 seconds (files took 0.03884 seconds to load)
2 examples, 0 failures

bundle exec rubocop spec/array_size_spec.rb
Rubocop hints that neither array nor item were "referenced in tests".
But to remove any of the definitions will not make RSpec happier, obviously.
Maybe it's simply about the message here, i.e., rubocop guesses wrong.
...
Inspecting 1 file
C

Offenses:

spec/array_size_spec.rb:7:5: C: RSpec/LetSetup: Do not use let! to setup objects not referenced in tests.
    let!(:array) { [item] }
    ^^^^^^^^^^^^
spec/array_size_spec.rb:10:7: C: RSpec/LetSetup: Do not use let! to setup objects not referenced in tests.
      let!(:item) { nil }
      ^^^^^^^^^^^
spec/array_size_spec.rb:18:7: C: RSpec/LetSetup: Do not use let! to setup objects not referenced in tests.
      let!(:item) { [true, false].sample }
      ^^^^^^^^^^^

1 file inspected, 3 offenses detected

spec/array_size_spec.rb
# frozen_string_literal: true

RSpec.describe Array, '#size' do
  subject(:size) { array.size }

  context 'when array is a monopel' do
    let!(:array) { [item] }

    context 'when item is nil' do
      let!(:item) { nil }

      it 'returns 1' do
        expect(size).to(eq(1))
      end
    end

    context 'when item is boolean' do
      let!(:item) { [true, false].sample }

      it 'returns 1' do
        expect(size).to(eq(1))
      end
    end
  end
end

Gemfile
source "https://rubygems.org"

gem "rspec"
gem "rubocop-rspec"

Nice, thanks for the detailed reproduction example. Can you please file a separate ticket, or better send a PR, starting with just a failing spec?

Hold on, LetSetup is just about bang-let!.
Why you don’t use a regular let?

Why you don’t use a regular let?

let! is used to keep side-effects away from subject "prerequisites".

I don’t get it, can you elaborate?

let is evaluated if accessed for the first time. If the fixture is accessed first by the subject, all of its evaluation contributes to the "(side-)effects" of the subject itself.
With let!
I use let! to have prerequisite fixtures instantiated clearly before the subject is evaluated.
The example spies on the database, to check whether the implementation is "efficient". The spy covers "any statement", i.e. any (other) database access would be unexpected.
# bundle exec rspec spec/feed_articles_spec.rb
bundle exec rspec spec/feed_articles_spec.rb
....

Finished in 0.00467 seconds (files took 0.03769 seconds to load)
4 examples, 0 failures

Rubocop considers old_article "not referred by tests":
# bundle exec rubocop spec/feed_articles_spec.rb
spec/feed_articles_spec.rb:89:5: C: RSpec/LetSetup: Do not use let! to setup objects not referenced in tests.
    let!(:old_article) { Olds.new(database:).read }
    ^^^^^^^^^^^^^^^^^^

With let! substituted with let,  to make rubocop more happy
... RSpec becomes unhappy, because old_article is now evaluated (only) within the SUT, and therefore its side-effect (reads from the database too) "leaks" into the effects measured for the SUT.
Feed#articles
  when instantiated without old article
    returns one new article
    when database access is spied at
      reads efficiently from database
  when instantiated with old article
    returns two articles, oldest first
    reads efficiently from database (FAILED - 1)

Failures:

  1) Feed#articles when instantiated with old article reads efficiently from database
     Failure/Error: expect(database).to(have_received(:read).once)

       (#<Database:0x00000001078ac098 @results={"news"=>#<Enumerator: ["N1", "N2", "N3"]:each>, "olds"=>#<Enumerator: ["O1", "O2", "O3"]:each>}>).read(*(any args))
           expected: 1 time with any arguments
           received: 2 times with any arguments
     # ./spec/feed_articles_spec.rb:98:in `block (3 levels) in <top (required)>'

Finished in 0.0081 seconds (files took 0.03615 seconds to load)
4 examples, 1 failure

spec/feed_articles_spec.rb
# frozen_string_literal: true

class Database
  def initialize(results:)
    @results = results.transform_values(&:to_enum)
  end

  def read(category)
    @results.fetch(category).next
  end
end

class News
  def initialize(database:)
    @database = database
  end

  def read
    @database.read('news')
  end
end

class Olds
  def initialize(database:)
    @database = database
  end

  def read
    @database.read('olds')
  end
end

class Feed
  def initialize(news:, old_article: nil)
    @news = news
    @old_article = old_article
  end

  def articles
    [@old_article, @news.read].compact
  end
end

RSpec.shared_context 'when database calls are spied' do
  before do
    allow(database).to(receive(:read).and_call_original)
  end
end

RSpec.configure do |config|
  config.include_context('when database calls are spied', :setup_database_spy)
end

RSpec.describe Feed, '#articles' do
  subject(:articles) { feed.articles }

  let(:feed) { described_class.new(news:, old_article:) }
  let(:news) { News.new(database:) }
  let(:database) do
    Database.new(
      results: {
        'news' => %w[N1 N2 N3],
        'olds' => %w[O1 O2 O3]
      }
    )
  end

  context 'when instantiated without old article' do
    let(:old_article) { nil }

    it 'returns one new article' do
      expect(articles).to(eq(['N1']))
    end

    context 'when database access is spied at' do
      before do
        allow(database).to(receive(:read).and_call_original)
      end

      it 'reads efficiently from database', :setup_database_spy, :aggregate_failures do
        articles
        expect(database).to(have_received(:read).once.with('news'))
        expect(database).to(have_received(:read).once)
      end
    end
  end

  context 'when instantiated with old article' do
    let(:old_article) { Olds.new(database:).read }

    it 'returns two articles, oldest first' do
      expect(articles).to(eq(%w[O1 N1]))
    end

    it 'reads efficiently from database', :setup_database_spy, :aggregate_failures do
      articles
      expect(database).to(have_received(:read).once.with('news'))
      expect(database).to(have_received(:read).once)
    end
  end
end

Make “feed” a bang-let.

Make “feed” a bang-let.

Doesn't actually help. Consider:
-   let(:feed) { described_class.new(news:, old_article:) }
+   let!(:feed) { described_class.new(**feed_params) }

    context 'when instantiated without old article' do
-    let!(:old_article) { nil }
+    let!(:feed_params) { {news:} }

    context 'when instantiated with old article' do
-      let!(:old_article) { Olds.new(database:).read }
+      let!(:feed_params) { {news:, old_article:} }
+
+      let(:old_article) { Olds.new(database:).read }

I’m not convinced that the cop raises a false alarm.
You can collapse two examples into one, and kept efficient SQL to rails query cache and special sql statement counters.
If your spec says it was read twice, it’s not a problem with setup, it’s a problem with production code that attempts to read twice from the db, or expectations counting a read in a place before caching takes place.

I just provided an example, where

let! is used (only) in an inner context, and
declares a fixture, which is used by the subject, where
the subject is declared in (e.g.) the top-level scope.

LetSetup declares this let! "not referred by tests", which is actually not true.
It is not about Rails caches. This just illustrates a setup, where it actually reasonable to use let! to instantiate the fixture before the actual subject is evaluated, because the fixture

is a parameter of the subject
has side-effects when instantiated, that would affect actual expectations of the subject.

The example in https://github.com/rubocop/rubocop-rspec/issues/830#issuecomment-2525932583 illustrates, that it is actually possible to have subject and fixtures interact this way, and that it is reasonable, to use let! to keep things separated. If this cannot convince you, I'm a bit out of ideas.

Fixtures are an alien concept to RSpec. We, in this gem, focus on generic RSpec. I strongly suggest you to:

open a separate issue
Provide a minimal reproduction example (Not involving classes, fixtures, shared examples, stubbed database)
Come up with a suggestion
Send a PR fixing this case after some agreement on the approach

Otherwise, this discussion seems to become counterproductive.
Thanks for understanding.

Yes, I agree. Doesn't look like any progress.
What would be the problem to have LetSetup check whether the (whatever you call it, I name it fixture) defined by let! is by chance referred to in an outer context?

If it's referenced in outer context, that means it's used in runtime, and doesn't have to be a bang-let. Not directly related to the offence the cop is dealing with.
Again, please open a separate issue, let's discuss there, not here. This issue is named "LetSetup with context and outer shared_examples".

that means it's used in runtime, and doesn't have to be a bang-let

Could you elaborate on this statement? What is a runtime and how does this is related to let!. Might help to shed a light onto this issue, which is (AFAICS) not actually related to shared examples and only by chance has been opened with this title because it is one scenario where it happens.


add files hwsh

Add files : hwsh

@arielyao0822 tw/edu/tc/hwsh/mail.txt: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@arielyao0822 First stage of verification passed, official domain for 臺中市立惠文高級中學 is mail.hwsh.tc.edu.tw as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@arielyao0822 Thank you for your patience while waiting for a review and processing your request. Pull request merged.
Please start requesting the licenses in about an hour, to let the changes to propagate through our system.


helm3 packaging for m4d

Overview
To help simplify deployment of the-mesh-for-data we want the entire core (including connectors) to have a helm based deployment (optionally moving CRD into a separate deployment).
Stage 0: Helm Chart: manager CRDs
the reason for have a separate helm chart for CRDs is:

we may have several helm charts which depend on the CRDs requiring it be deployed independently
we want to be able to upgrade the CRDs independently from core
that this is an acceptable practice see rancher/fleet for example

so the result would be supporting:
helm install -g m4d-crd

This is how Rancher Fleet works: https://github.com/rancher/fleet/tree/master/charts/fleet-crd
And is defined as a plausible option (Method 2) here: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/
Stage 1: Helm Chart:  manager
The idea is to replace the current kustomize based manager deployment with a helm chart wrapper which enables to configure where the helm modules and module images are downloaded from (the docker registry location).
Stage 2: Helm Chart: manager + connectors
Next we add connectors to the deployment:

opa-connector
vault-connector
egeria-connector (or egeria replacement)

Replacing their current bash based deployment with extending the helm chart, and exposing configuration of: the service endpoints (and credentials) needed for the connectors to connect.
This work may also include merging the code into the manager as library code (currently the manager communicates to each connector which exposes the service at a designated port number)
Stage 3: Helm chart: manager + connectors + 3rd-party
In small (to evaluation/demo) deployments you may want to deploy some of the 3rd party tools, thus the proposal is to add these as configurable options such that one can either deploy m4d with a local/private instance of a required 3rd party of rather point to an existing shared 3rd party
specifically we should consider:

vault server
cert-manager server
TBD

Stage 4: Helm chart: manager + connectors + 3rd-party + modules
The current system of module management was intended to enable external parties to extend m4d w/o having to change the core of m4d, this approach makes sense for either super-large-and-complex OSS (which m4d is not, as the lines-of-code its 1/100 or 1/1000 or projects such as envoy, k8s, istio and others), or it was suppose to serve for extending a closed source project (which again is not the case of m4d).
So the proposal is to eliminate all together the module notion, merge it into the core of m4d and have it all managed via a single helm chart.
Stage 5: make architecture multi-cluster compatible/agnostic
to be agnostic to multi-cluster tool one should have deployment options which enable to setup each cluster mostly independant from others such as:

manager cluster: this is the cluster that the end-user works such as via a Jupiter Notebook (possibly as part of KubeFlow), in this location the user has access to local instances of remote data-sources ... so here we would have a M4DApplication
agent (or data source) cluster: this could be a branch office which is the owner the a data set which includes PI fields which have to be obfuscated or redacted before is can be shared with the manager ... so here we would need a new kind such as M4DApplicationDatasource

by this separation we now can deploy to each cluster totally independently such that the M4DApplication and the M4DApplicationDatasource can be pushed directly into the GitOps source feeding the multi-cluster solution (with labels per cluster defining what is deployment where). by doing this we would eliminate the plutter and its' integration with Razee API.
Supporting propriety extensions
WKC code which can't be released can still be supported to using an internal fork for m4d and then extending the code with the WKC connector capabilities. That said it is still recommended to revisit the WKC connector and consider reimplementation w/o the IP restrictions in the current implementation.

Stage 1: Helm Chart: manager (including CRDs)

Agreed.

Stage 2: Helm Chart: manager + connectors

I would have a single Helm chart for all connectors following the idea of a "stack" presented in https://github.com/IBM/the-mesh-for-data/issues/182 and keep it separate from the manager helm chart. I would wait with this one until we settle on #182.

Stage 3: Helm chart: manager + connectors + 3rd-party

I don't think that it's a good idea to vendor a helm chart for cert-manager (Vault already has a Helm chart btw but we don't use it yet).

The current system of module management was intended to enable external parties to extend m4d w/o having to change the core of m4d

A module implements a data-centric function to implement a policy action. This is completely separate from M4D control plane and must be extendible. We are definitely not planning to remove modules but feel free to raise this in the next community meeting for a broader discussion.

Supporting propriety extensions

I don't think that suggesting to fork the project is a good idea. Again, this should probably be discussed in a community meeting rather than an issue.

I think it would be good to open a separate issue for Stage 1.

This work may also include merging the code into the manager as library code (currently the manager communicates to each connector which exposes the service at a designated port number)

I don't understand how this can be done. There may be any number of catalog connectors, for example, while only one is configured for a specific deployment. We already have a policy manager merged as a library. The policy manager does not serve as a connector, though, but rather like a "connector manager" that is configured to work with a specific connector.

So the proposal is to eliminate all together the module notion, merge it into the core of m4d and have it all managed via a single helm chart.

Suppose an administrator wants to deploy only a subset of the modules. I don't see a way to manage this the way you propose.

@hunchback deployment should support the architecture, not the other way around.
Lets start with the 1st stage -- it is a very good idea.
We should keep the architecture concepts and a pluggable design. Specifically, connectors should not be part of the manager code, they need to be seperate, and we do envision out of tree connectors and modules

@roee88 : I would have a single Helm chart for all connectors following the idea of a "stack" presented in #182 and keep it separate from the manager helm chart. I would wait with this one until we settle on #182.

the idea behind the single helm (which includes in it the default or should I say static connectors) is that it provides the desired user experience, for example the Linux kernel has many extensions to the core is the form of modules but by default many of these modules are statically compiled into the kernel and deployed in the RPM which includes the kernel core.
this simplicity is vital for the success of any project but more so for an OSS which does not assume pain support.

Stage 3: Helm chart: manager + connectors + 3rd-party
@roee88: I don't think that it's a good idea to vendor a helm chart for cert-manager (Vault already has a Helm chart btw but we don't use it yet).

the idea is to include a minimal local cert-manager used only by m4d, this is commonly used in other projects (with the aim of simplification):

kubernetes installs an internal

skydive installs an internal ElasticSearch (https://github.com/skydive-project/skydive-helm/blob/master/values.yaml#L51)

The current system of module management was intended to enable external parties to extend m4d w/o having to change the core of m4d

@roee88 A module implements a data-centric function to implement a policy action. This is completely separate from M4D control plane and must be extendible. We are definitely not planning to remove modules but feel free to raise this in the next community meeting for a broader discussion.

a module has no independent role and requires m4d the fact that it is data centric be it flight-arrow, kafka, s3 does not in itself justify having is separated out of m4d, for example rancher is a huge project which integrates with many cert manager systems but the code for integrating (and even deployment of the internal services) are all part of the single rancher helm chart:(https://github.com/rancher/rancher/tree/master/chart )
now rancher is a project 100x larger and more complex than m4d (it is also highly popular and successful) so I am sure we can learn from that ...

Supporting propriety extensions

@roee88: I don't think that suggesting to fork the project is a good idea. Again, this should probably be discussed in a community meeting rather than an issue.

its' a reasonable option, a better option would be to think very carefully before implementing propriety code for m4d, specifically the WKC could be re-implemented as OSS, in any case the decision to write propriety extensions is also expensive in term of life-cycle-management and thus should be chosen light heartedly.

@roee88: I think it would be good to open a separate issue for Stage 1.
@ronenkat: Lets start with the 1st stage -- it is a very good idea.

Comments burst.

S1: good 👍
S2: we can always create a separate chart and then if we decide to we can include it as an optional dependency to the S1 chart. Not a big deal.
S3: You can't "privately" install a cluster wide dependency... Rancher here is a bad example given the context. Always consider the context and not just how big and wonderful a project is... Read the Warning in https://cert-manager.io/docs/installation/kubernetes/ please. Again, optional chart dependencies are a good option to consider here.
S4: modules are actually associated with connectors more than with to the core project. We can chat on a github issue for days but this is just something that we disagree about. Again feel free to raise this in a community meeting instead.

So the proposal is to eliminate all together the module notion, merge it into the core of m4d and have it all managed via a single helm chart.

@shlomitk1 Suppose an administrator wants to deploy only a subset of the modules. I don't see a way to manage this the way you propose.

why would an administrator actually care about if more modules that what he is using are deployed? do you care that you laptop OS has drives for devices you don't use (and it must have hundreds of such drivers) ... you don't.
and if there is  a really good reason not to deploy all modules then you can simply add a parameter to the helm values to not deploy that module (which then again in most cases this is an overkill)

This work may also include merging the code into the manager as library code (currently the manager communicates to each connector which exposes the service at a designated port number)

@shlomitk1 I don't understand how this can be done. There may be any number of catalog connectors, for example, while only one is configured for a specific deployment. We already have a policy manager merged as a library. The policy manager does not serve as a connector, though, but rather like a "connector manager" that is configured to work with a specific
connector.

but why can't the connectors be merged as libraries - called via API rather than over a socket?

Comments burst.

S1: good 👍
S2: we can always create a separate chart and then if we decide to we can include it as an optional dependency to the S1 chart. Not a big deal.
S3: You can't "privately" install a cluster wide dependency... Rancher here is a bad example given the context. Always consider the context and not just how big and wonderful a project is... Read the Warning in https://cert-manager.io/docs/installation/kubernetes/ please. Again, optional chart dependencies are a good option to consider here.
S4: modules are actually associated with connectors more than with to the core project. We can chat on a github issue for days but this is just something that we disagree about. Again feel free to raise this in a community meeting instead.

will start with s1 ...

@ronenkat We should keep the architecture concepts and a pluggable design. Specifically, connectors should not be part of the manager code, they need to be seperate, and we do envision out of tree connectors and modules

this is a claim a challenge post the demo would be happy to open up this topic in the OSS weekly with my main grievance being:

this break up makes not only deployment much more complex but also life-cycle-management including upgrades
this break up makes implementation of multi-cluster much more complex, thus as in our case forcing us to implement multi-cluster features (the the plotter effectively defines the per cluster blueprint) with the cost being that rather than being multi-cluster tool agnostic (with zero integration effort per tool) we rather require heavy integration effort per each tool (so if we replace Razee with Fleet we need to invest more effort).
the current pluggable architecture is a classical closed source software resulting architecture in which one has to provide means for extention assuming the core is not accessible to the 3rd party ... in OSS the dynamics are different on the contrary one wants to get 3rd party contributors to join the project and extend it (starting with a specific domain such as a data-source of interest) but later moving to extend the core.

so addressing deployment exposed issues in the current architecture which should be revisited

but why can't the connectors be merged as libraries - called via API rather than over a socket?

Let's say we have three catalog connectors: c1, c2 and c3.
Currently, manager will always contact one connector, using a configured service name/port.
If all are merged together, we will get three APIs instead of one, or three implementations of an interface. And if another connector is added, this will require to change the code. Unless I misunderstand something...

why would an administrator actually care about if more modules that what he is using are deployed? do you care that you laptop OS has drives for devices you don't use (and it must have hundreds of such drivers) ... you don't.
and if there is a really good reason not to deploy all modules then you can simply add a parameter to the helm values to not deploy that module (which then again in most cases this is an overkill)

Let's say there are two arrow-flight modules, one is propriety of org1, another - of org2. In org1 the admin will install one module, in org2 - another. Or any other considerations to replace one module by another that are not a part of manager decision or user input.

why would an administrator actually care about if more modules that what he is using are deployed? do you care that you laptop OS has drives for devices you don't use (and it must have hundreds of such drivers) ... you don't.
and if there is a really good reason not to deploy all modules then you can simply add a parameter to the helm values to not deploy that module (which then again in most cases this is an overkill)

Let's say there are two arrow-flight modules, one is propriety of org1, another - of org2. In org1 the admin will install one module, in org2 - another. Or any other considerations to replace one module by another that are not a part of manager decision or user input.

in this case our architecture should support org1 and org2 by each of them being a separate deployment of m4d in a separate namespace (org1 and org2) and all deployment anyway needs to be managed by the multi-cluster gitops solution (and should not be bypassed manually)

So starting with stage 1, you suggested to have one chart for CRDs and one chart for the manager due to the caveats described in https://helm.sh/docs/chart_best_practices/custom_resource_definitions/. I will focus on the CRDs first then.
The CRDs are generated from source code using controller-gen in https://github.com/IBM/the-mesh-for-data/blob/58e7129225302ae7fb503d7d1018e42c63854ac2/manager/Makefile#L40. This currently dumps the CRDs to config/crd/bases as part of the kustomize layout. I assume that we want to keep the kustomize layout at least until we're done with stage 1. My question is how do you want to ensure that the crds chart contains the generated CRDs rather than a manual copy.

closing as not relevant in current form (@roee88 please open alternative PR/PRs)

closing as not relevant in current form (@roee88 please open alternative PR/PRs)


Uncaught Error: Adding a pane item with URI '~/Dropbox/EECS 498 (Distributed Systems)/Project 3 (...

[Enter steps to reproduce:]

...
...

Atom: 1.21.2 x64
Electron: 1.6.15
OS: Mac OS X 10.12.6
Thrown From: Atom Core
Stack Trace
Uncaught Error: Adding a pane item with URI '/Users/bradymathieson/Dropbox/EECS 498 (Distributed Systems)/Project 3 (Paxos)/src/paxos/paxos_impl.go' that has already been destroyed
At /Applications/Atom.app/Contents/Resources/app/src/pane.js:514

Error: Adding a pane item with URI '/Users/bradymathieson/Dropbox/EECS 498 (Distributed Systems)/Project 3 (Paxos)/src/paxos/paxos_impl.go' that has already been destroyed
    at Pane.module.exports.Pane.addItem (/Applications/Atom.app/Contents/Resources/app/src/pane.js:514:21)
    at Pane.module.exports.Pane.activateItem (/Applications/Atom.app/Contents/Resources/app/src/pane.js:489:20)
    at TabBarView.module.exports.TabBarView.onClick (/Applications/Atom.app/Contents/Resources/app/node_modules/tabs/lib/tab-bar-view.js:715:25)

Commands
  7x -3:09.7.0 editor:toggle-line-comments (input.hidden-input)
     -2:24 core:save (input.hidden-input)

Non-Core Packages
atom-terminal 0.8.0
autocomplete-python 1.10.3
busy-signal 1.4.3
file-icons 2.1.13
go-debug 1.5.2
go-plus 5.6.0
go-signature-statusbar 1.2.3
hyperclick 0.1.5
intentions 1.1.5
language-markdown 0.25.1
linter 2.2.0
linter-ui-default 1.6.10
markdown-preview-plus 2.4.16
platformio-ide-terminal 2.7.0
Remote-FTP 1.2.6
todo-show 2.1.0

Thanks for taking the time to contribute!
We noticed that this is a duplicate of https://github.com/atom/tabs/issues/444. You may want to subscribe there for updates.
Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


dtool: replace rustc-serialize version to unbreak build

Description of changes
This PR adopts the same patch offered in #310125 to unbreak the build with versions of Rust > 1.76. Part of ZHF: #309482

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

[...]
dtool>     Finished test [unoptimized + debuginfo] target(s) in 28.90s
dtool> warning: the following packages contain code that will be rejected by a future version of Rust: serde_test v1.0.104
dtool> note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
dtool>      Running unittests src/main.rs (target/x86_64-unknown-linux-gnu/debug/deps/dtool-1df14c63a48c58ba)
dtool> running 19 tests
dtool> test modules::base64::tests::test_cases ... ok
dtool> test modules::base58::tests::test_cases ... ok
dtool> test modules::case::tests::test_cases ... ok
dtool> test modules::eddsa::tests::test_cases ... ok
dtool> test modules::aes::tests::test_cases ... ok
dtool> test modules::hex::tests::test_cases ... ok
dtool> test modules::hex::tests::test_h2b ... ok
dtool> test modules::html::tests::test_cases ... ok
dtool> test modules::number_codec::tests::test_cases ... ok
dtool> test modules::number_system::tests::test_cases ... ok
dtool> test modules::pbkdf2::tests::test_cases ... ok
dtool> test modules::hash::tests::test_cases ... ok
dtool> test modules::re::tests::test_cases ... ok
dtool> test modules::sm4::tests::test_cases ... ok
dtool> test modules::time::tests::test_cases ... ok
dtool> test modules::unicode::tests::test_cases ... ok
dtool> test modules::url::tests::test_cases ... ok
dtool> test modules::srdsa::tests::test_cases ... ok
dtool> test modules::ecdsa::tests::test_cases ... ok
dtool> test result: ok. 19 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.19s
dtool> Finished cargoCheckHook
dtool> Running phase: installPhase
dtool> Executing cargoInstallHook
dtool> Finished cargoInstallHook
dtool> Running phase: fixupPhase
dtool> shrinking RPATHs of ELF executables and libraries in /nix/store/ask7z11cc9zjr4i4gn0i92p3zv0l8rm2-dtool-0.12.0
dtool> shrinking /nix/store/ask7z11cc9zjr4i4gn0i92p3zv0l8rm2-dtool-0.12.0/bin/dtool
dtool> checking for references to /build/ in /nix/store/ask7z11cc9zjr4i4gn0i92p3zv0l8rm2-dtool-0.12.0...
dtool> patching script interpreter paths in /nix/store/ask7z11cc9zjr4i4gn0i92p3zv0l8rm2-dtool-0.12.0
dtool> stripping (with command strip and flags -S -p) in  /nix/store/ask7z11cc9zjr4i4gn0i92p3zv0l8rm2-dtool-0.12.0/bin
 nix shell -L .#dtool
 dtool case
asdf
ASDF
asdf
Asdf
asdf
Asdf
asdf
ASDF
asdf
aSdF


The searching is taking a very long time

Hey, I really like your code and it so much fun to work with it and really everything is working fine, but the searching is taking a very long time something like 10 - 15 seconds, can I improve it somehow?

Hi @roeinissim In my tests it is working normally. But feel free to make improvements, I'm happy to receive suggestions.

Understood, thank you!


This gui leaves A TON of trash on C making it fill up very fast when converting files

Can You guys make it optionable and remove all the files that are not needed realy after file was converted and new one was opened ?

Where does it create trash?


Adding refresh to plugin API

Plugins are old and slowly-but-surely unsupported technology, but we still need that API for some legacy apps.

@facebook-github-bot shipit


New version: Xmake-io.Xmake version 2.8.9

Pull request has been created with komac v2.1.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

An advice of locale.zh-CN.yaml is as follows. Same key-value pairs as locale.en-US.yaml are ignored, please just copy-paste them:
# Created with komac v2.1.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.locale.1.6.0.schema.json

PackageIdentifier: Xmake-io.Xmake
PackageVersion: 2.8.9+20240321
PackageLocale: zh-CN
#####
# Ignored section, they are the same as en-US one.
#####
ShortDescription: 一个基于 Lua 的轻量级跨平台构建工具。
Description: |-
  Xmake 是一个基于 Lua 的轻量级跨平台构建工具。
  它使用 xmake.lua 维护项目构建。
  相比 makefile/CMakeLists.txt，配置语法更加简洁直观。
  对新手非常友好，短时间内就能快速入门。
  能够让用户把更多的精力集中在实际的项目开发上。
Tags:
- cross-platform
- lua
- open-source
ReleaseNotes: |-
  新特性
  - #4843: 添加 check_bigendian 接口实现大小端探测
  改进
  - #4798: 改进 wasi sdk 检测
  - #4772: 改进 tools.cmake 去兼容支持 vs2022 preview (v144)
  - #4813: 添加 gb2312 编码
  - #4864: 改进抽取符号，支持 gdb 断点调试
  - #4831: 改进 target:fileconfig() 支持 headerfiles
  - #4846: 改进进度显示，解决顺序错乱问题
  Bugs 修复
  - 修复 select_script 的脚本模式匹配
  - #4763: 修复 {force = true}
  - #4807: 修复 nimble::find_package
  - #4857: 修复对 -P/-F 等基础选项的解析
ReleaseNotesUrl: https://github.com/xmake-io/xmake/releases/tag/v2.8.9
ManifestType: locale
ManifestVersion: 1.6.0

@thmeyer-msft
Thank you very much for your enthusiasm in creating a pull request for my issue, and I am very sorry for wasting your time and labor at this time. 😞 I see that you actively closed this pull request, I will address that issue independently in another pull request.
Thank you very much again for your work. ❤


How many rules can a single node ElastAlert generally support to run concurrently?

How many rules can a single node ElastAlert generally support to run concurrently?
Is 500 rules okay? How about 1000?

We also recommend asking questions on the Gitter channel
https://gitter.im/Yelp/elastalert

Yelp/elastalert is no longer maintained. Please use jertel/elastalert. Questions to the discussion below
https://github.com/jertel/elastalert/discussions


HBASE-23139 MapReduce jobs lauched from convenience distribution are nonfunctional

Add the hbase-thirdparty jar to base job dependencies.

Confirmed fix, merging

Just want to confirm that this fixed hbase mapredcp specifically? (Presuming gson thirdpart-gson is always needed for jobs based on our utils)

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
1m 16s
Docker mode activated.

_ Prechecks _

:green_heart:
dupname
0m  0s
No case conflicting files found.

:green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

:green_heart:
@author
0m  0s
The patch does not contain any @author tags.

:yellow_heart:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-1 Compile Tests _

:green_heart:
mvninstall
8m 26s
branch-1 passed

:green_heart:
compile
0m 42s
branch-1 passed with JDK v1.8.0_222

:green_heart:
compile
0m 46s
branch-1 passed with JDK v1.7.0_232

:green_heart:
checkstyle
1m 45s
branch-1 passed

:green_heart:
shadedjars
3m 15s
branch has no errors when building our shaded downstream artifacts.

:green_heart:
javadoc
0m 39s
branch-1 passed with JDK v1.8.0_222

:green_heart:
javadoc
0m 42s
branch-1 passed with JDK v1.7.0_232

:blue_heart:
spotbugs
3m  2s
Used deprecated FindBugs config; considering switching to SpotBugs.

:green_heart:
findbugs
2m 59s
branch-1 passed

_ Patch Compile Tests _

:green_heart:
mvninstall
2m  7s
the patch passed

:green_heart:
compile
0m 41s
the patch passed with JDK v1.8.0_222

:green_heart:
javac
0m 41s
the patch passed

:green_heart:
compile
0m 47s
the patch passed with JDK v1.7.0_232

:green_heart:
javac
0m 47s
the patch passed

:green_heart:
checkstyle
1m 42s
the patch passed

:green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

:green_heart:
shadedjars
3m  4s
patch has no errors when building our shaded downstream artifacts.

:green_heart:
hadoopcheck
5m 17s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

:green_heart:
javadoc
0m 33s
the patch passed with JDK v1.8.0_222

:green_heart:
javadoc
0m 42s
the patch passed with JDK v1.7.0_232

:green_heart:
findbugs
3m  4s
the patch passed

_ Other Tests _

:broken_heart:
unit
32m 33s
hbase-server in the patch failed.

:green_heart:
asflicense
0m 21s
The patch does not generate ASF License warnings.

75m  8s

Reason
Tests

Failed junit tests
hadoop.hbase.http.log.TestLogLevel

Subsystem
Report/Notes

Docker
Client=19.03.3 Server=19.03.3 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-705/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/705

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux e0fa3ff40f97 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-705/out/precommit/personality/provided.sh

git revision
branch-1 / 1d531f1

Default Java
1.7.0_232

Multi-JDK versions
/usr/lib/jvm/zulu-8-amd64:1.8.0_222 /usr/lib/jvm/zulu-7-amd64:1.7.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-705/1/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-705/1/testReport/

Max. process+thread count
713 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-705/1/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.

Tested with RowCounter and IntegrationTestBigLinkedList


KOGITO-5445 upgrade rpkgtests-maven-plugin version

KOGITO-5445
Upgrading version of rpkgtests-maven-plugin due to build issue in kogito-quarkus-test-list on OpenJDK 16.

How to retest this PR or trigger a specific build:

Run all builds
Please add comment: Jenkins retest this

Run (or rerun) specific test(s)
Please add comment: Jenkins (re)run [runtimes|optaplanner|apps|examples] tests

Quarkus LTS checks
Please add comment: Jenkins run LTS

Run (or rerun) LTS specific test(s)
Please add comment: Jenkins (re)run [runtimes|optaplanner|apps|examples] LTS

Native checks
Please add comment: Jenkins run native

Run (or rerun) native specific test(s)
Please add comment: Jenkins (re)run [runtimes|optaplanner|apps|examples] native

Full Kogito testing (with cloud images and operator BDD testing)
Please add comment: Jenkins run BDD
This check should be used only if a big change is done as it takes time to run, need resources and one full BDD tests check can be done at a time ...

The (build) Runtimes check has failed. Please check the logs.

Jenkins rerun runtimes tests


Usage example

Can you include a simple example of uploading a video to Wistia from a linux machine?
Something that anyone can copy/change/paste to have their files shot to wistia using this tool.
Thanks in advance...

Found this http://wistia.github.io/demobin/magicbox/

Hey Zohar, glad you found that. The wistia-uploader gem is a bit out of date and we usually recommend people just use curl (http://wistia.com/doc/upload-api#examples). But if it is working for you, that's great!

+1 Thanks!


fix some warnings: k8s-test client not closed

ci error
Error:  Failures:
Error:    MiniKubeTest.testJobFailed:193
Expected: a string containing "No such file or directory"
     but: was "master failed message:
Job has reached the specified backoff limit"
[INFO]
Error:  Tests run: 542, Failures: 1, Errors: 0, Skipped: 0


Use Pep8

https://www.python.org/dev/peps/pep-0008/

The current code is not passing pep8! Fix this!

now passes everything except 80 chars per line


Custom shader support

This is my attempt at adding custom shader support to niri-flake. There's no documentation yet, and I'm not sure about the approach either, but I figured I'll push it sooner rather than later.
The idea is to have something like:
programs.niri.settings.animations.window-close.custom = {
  curve = "linear";
  duration-ms = 250;
  shader = ''
    // Shader code here
  '';
};

This seems to work for me, but has the downside of allowing custom shaders even for animations where Niri does not support them. Not sure how to handle that yet.

Looks like you implemented shader support on main, so this one here is not necessary anymore.


msourcecf wideband noise on signals issue

I've been working with the library and noticed when I use msource to have files playback, noise, tones, etc all in one, I can only ever get at most about 60 dB of SNR.  I attached a screenshot of what I am talking about.  Based on my testing it seems like some sort of floating point and numerical error that introduced for specific frequency offsets.  If I place a tone at a multiple of sample rate divided by 1024, I get a nice filter effect, otherwise I get a "skirt" like seen on the noise signal.  The noise signals always have this "skirt" effect, even when generated in a user callback.  This was seen in the msourcecf example if a sufficiently low gain wideband noise signal was used as well.  The FIR filters, even with floating point error, should behave much better.

Consider setting the "bandwidth" of the tone to zero in the msource object:
// create msource object
msourcecf gen = msourcecf_create(1200, 4, 60.);

// add signals     (gen, fc,         bw,  gain)
msourcecf_add_tone (gen, 300./1200., 0.0,    0); // filtered tone
msourcecf_add_tone (gen,-300./1200., 0.5,  -25); // will show skirt

I notice if I have a tone offset in frequency by 1/1024 of the normalized bandwidth, I still get a fairly clean tone even when instantaneous frequency measurements are made (but still lousy noise rolloff).  First thing that comes to mind is this may be related to the NCO using a sine/cosine look up table of 1024 elements, and a rather interesting calculation method using float bit manipulation.  I am not sure if this is the reason for it, but have you ran into a similar issue before?  This behavior is shown in my original plot in this issue.  I did notice that when not at 1/1024 increments of center frequency that there was a skirt unless I used the PSD calculation including the initial FIR tap wind-up.  In theory, it should be possible to have clean tones when looking over many samples, without looking at all of the generated data.

Needs revisiting

may be related to the NCO using a sine/cosine look up table of 1024 elements

I've noticed that the NCO does produce a lot of (phase?) noise.


New flags for fathomnet_generate.py

Two suggestions for flags for the fathomnet_generate command line tool:

Flag to grab all concepts from objects that satisfy other filters.
Filter by image dimensions. This might make it easier to select among the cameras that have been deployed on MBARI ROVs.

Flag to grab all concepts from objects that satisfy other filters.

Could you clarify this? There is the --all flag to include all concepts from images that were found by the specified filters, if that's what you mean. Or, do you mean something along the lines of "don't filter by any concept, just filter by X Y Z metadata"?

Filter by image dimensions.

Could you provide an example usage of what you're envisioning? I would caution against using image dimensions as a proxy for camera identity, as the letterbox removal process has produced a wide variety of resolutions.

The latter: "don't filter by any concept, just filter by X Y Z metadata"?
Right, I forgot about letter boxing. I was hoping to filter by sensor. There are some overlapping dates for when different cameras were on different ROVs (a la this list that @hohonuuli furnished on Slack). I suppose holding off on this one is right call and we can think about how to do it later.

Resolved in c278ba5
I'll hold off on this.


Continuing from trained data will start the output images at 00000 rather than their current value

Not sure if this is by design, but restarting from a checkpoint will start overwriting the images at index 00000.jpg or what-have-you. I feel that it should by default output at the next incremented value, such as 001234.jpg to avoid deleting existing images.
If the current implementation is by design, perhaps a config switch?
Cheers,
Matt

I've run into this to. It might not make it in 1.0 but I'll tag it so we can improve this after. Pytorch lets us save arbitrary variables to the save files so we can just add it there.


__zone_symbol__xhrScheduled error in IE/Edge

I'm using an external library (oidc-client) and I am getting this error in IE/Edge, but otherwise it works fine in Chrome/Firefox.
I'd like to understand what could be the cause of this zone.js error. The app is an Angular 5 app.
SCRIPT5007: Unable to get property '__zone_symbol__xhrScheduled' of undefined or null reference
zone.js (2959,1)
ERROR TypeError: Unable to get property 'current' of undefined or null reference
SCRIPT5007: Unable to get property 'stackTraceLimit' of undefined or null referenceeval code (1466) (119,9)
SCRIPT5007: Unable to get property '__zone_symbol__xhrScheduled' of undefined or null referencezone.js (2959,1)
ERROR TypeError: Unable to get property 'current' of undefined or null reference
SCRIPT5007: Unable to get property 'stackTraceLimit' of undefined or null referenceeval code (1466) (119,9)
SCRIPT5007: Unable to get property '__zone_symbol__xhrScheduled' of undefined or null referencezone.js (2959,1)
ERROR TypeError: Unable to get property 'current' of undefined or null reference
SCRIPT5007: Unable to get property 'stackTraceLimit' of undefined or null referenceeval code (1466) (119,9)
SCRIPT5007: Unable to get property '__zone_symbol__xhrScheduled' of undefined or null referencezone.js (2959,1)
ERROR TypeError: Unable to get property 'current' of undefined or null reference
SCRIPT5007: Unable to get property 'stackTraceLimit' of undefined or null referenceeval code (1466) (119,9)
SCRIPT5007: Unable to get property '__zone_symbol__xhrScheduled' of undefined or null referencezone.js (2959,1)
SCRIPT5007: Object expectedzone.js (192,1)
Thanks for any help.

@DevInstinct , please post a reproduce repo, thanks.

Fix #1072 seems to get rid of one error, but I continue to get these errors, which were also in the original trace:

@DevInstinct, I still need a reproduce repo, maybe you use some 3rd party lib to make XMLHttpRequest changed.

Got the error using oidc-client and the silent renew feature in an Angular 5 app.
Worked around it by getting rid of Angular for the silent renew callback; stopped getting the errors even without the fix. Thanks.


copy /odimra/plugin-redfish/plugin-redfish /bin failed

Hi
I am trying to install the ODIM.
It shows copy failed as the title when I run "make all".
It fails on make grf_plugin process
I did not see the /odimra/plugin-redfish/plugin-redfish in the source.
Could you help check the issue?
Thanks

Hi Jay we will look into this issue and get back.

Hi Jay we will look into this issue and get back.

Hi @jaymainal can you please provide the console logs after make all command and and post it here.
It will be easy for us to find out the root cause for this. Thank You

Hi @jaymainal can you please provide the console logs after make all command and and post it here.
It will be easy for us to find out the root cause for this. Thank You

I did not see the issue after I reinstall it in another environment again.
Sorry and please help close the issue, thanks.

I did not see the issue after I reinstall it in another environment again.
Sorry and please help close the issue, thanks.

CLosing as per Jays comment

CLosing as per Jays comment


refactor/pnpm turborepo

Codecov Report

Merging #3 (2168297) into main (2b99127) will increase coverage by 2.86%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main       #3      +/-   ##
==========================================
+ Coverage   94.36%   97.23%   +2.86%
==========================================
  Files          22       28       +6
  Lines        1332     1408      +76
  Branches      168      172       +4
==========================================
+ Hits         1257     1369     +112
+ Misses         66       25      -41
- Partials        9       14       +5

Impacted Files
Coverage Δ

packages/core/src/index.ts
100.00% <100.00%> (ø)

packages/test-utils/src/setupJSDOM.ts
90.90% <0.00%> (-9.10%)
:arrow_down:

packages/utils/src/asserts.ts
93.75% <0.00%> (-6.25%)
:arrow_down:

packages/utils/src/misc.ts
97.10% <0.00%> (-2.90%)
:arrow_down:

packages/utils/src/pick.ts
98.78% <0.00%> (ø)

packages/utils/src/nested.ts
95.79% <0.00%> (ø)

packages/utils/src/primitives.ts
98.21% <0.00%> (ø)

packages/typings/src/index.ts
100.00% <0.00%> (ø)

packages/typings/src/common.ts
100.00% <0.00%> (ø)

packages/scripts/src/index.ts
100.00% <0.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2b99127...2168297. Read the comment docs.


how to get the zigbee mac address before init the zigbee task (TZ-219)

hello,
Is there a method to get the zigbee mac address before initializing the zigbee task?
Is it possible that the esp_zb_get_long_addres() function only returns the mac address after starting the zigbee task and receiving the steering signal?

Hi,
The function esp_read_mac() may is useful for you.


Improves Developer Ergonomics for LambdaHandler Conformances

This PR aims to improve developer ergonomics for simple LambdaHandler conformances when trying to quickly put together a local server to test against.
Motivation:
Swift 5.7 added primary associated types for protocols where you can start using generic bracket syntax for protocols. An issue for this was opened not too long ago in this repo (#266) with the primary motivation of improving developer ergonomics around types conforming to LambdaHander. However, swift's type inference system should be able to handle the aforementioned issue just fine without using primary associated types (although support for that could still be useful when defining properties conforming to LambdaHandler when you want to constrain the types).
Swift's type inference system does not pick up the Event and Output types for objects conforming to LambdaHandler because those types are defined in the covariant protocol EventLoopLambdaHandler. This means that you need to add type aliases for Event and Output when conforming to LambdaHandler - resulting in less than ideal developer ergonomics when trying to spin up a quick little local server.
Additionally, the initializer for LambdaHandler is currently a required function in the protocol. This is super useful for setup logic for your Handlers but degrades the developer ergonomics of the most simple/minimal use-case for LambdaHandlers. Developers should be able to continue having the capability of writing simple lambda handlers like they could do in 0.5.2:
import AWSLambdaRuntime
import Foundation

Lambda.run { (context, input: Request, callback: @escaping (Result<String, Error>) -> Void) in
    callback(.success(...))
}

The current state of affairs in comparison is to explicitly define the Event and Output associated types of LambdaHandler when writing a simple lambda as well as being forced to include an init that isn't necessarily always required to successfully run a simple lambda:
import AWSLambdaRuntime
import Foundation

@main
struct EntryHandler: LambdaHandler {
    typealias Event = SomeCodableEventType
    typealias Output = SomeCodableOutputType

    init(context: AWSLambdaRuntimeCore.LambdaInitializationContext) async throws {
        // The body of this could be blank and the lambda would still work
    }

    func handle(_ event: Event, context: LambdaContext) async throws -> Output {
        // lambda logic
    }
}

With the changes on main, a developer loses the ease of writing a three-line lambda that they could do in 0.5.2.
On top of all of this, when needing to run a server locally in Xcode, a developer would need to add an environment variable to their local scheme. This isn't a much used feature in Xcode for developers coming from iOS who are looking to maybe start writing swift on the server. This isn't too big of a deal, but could be a bit of pain to do when trying to set yourself up with Lambda for the first time. It also introduces the possibility of having to manage two different environment variables if you're switching between debugging in Xcode or running the server locally in your Terminal. It would be nice to have the capability of defining this in code so a developer wouldn't have to open a separate window to toggle a server running locally.
I may be wrong about this (not a lot of experience writing swift on the server), but if a developer is running a local server in Xcode, it should be safe to assume that the server isn't running on an environment like AWS Lambda or Docker. I think that if a server is running their Lambda in Xcode, LOCAL_LAMBDA_SERVER_ENABLED should be enabled by default. Doing so would enable developers to package ready-to-go example local servers with their example mobile apps (maybe they want to demonstrate the usage of an SDK or something).
Currently, developers in this situation would have to instruct their users to set up this LOCAL_LAMBDA_SERVER_ENABLED environment variable. If a user is a swift developer already, they might have the urge to open that Package in Xcode and just hit run without knowing they need to set that variable up.
With the support of a variable for enabling running as a local server in Lambda directly, a developer could package a ready-to-go local server package with their example apps that would only require opening the package and running in Xcode with no extra set up.
Modifications:

Removes ambiguities between LambdaHandler, EventLoopLambdaHandler, and ByteBufferLambdaHandler. The handle(_:context:) functions shared across all three prevented the swift compiler from properly inferring the Event and Output types between LambdaHandler and EventLoopLambdaHandler. The handle(_:context:) functions are now more descriptive with their primary parameter to match the protocol they are associated with:

LambdaHandler.handle(_:context) has now been changed to LambdaHandler(request:context:)
EventLoopLambdaHandler.handle(_:context) has now been changed to EventLoopLambdaHandler(event:context:)
ByteBufferLambdaHandler.handle(_:context) has now been changed to ByteBufferLambdaHandler(buffer:context:)

Adds an init function to the LambdaHandler protocol

Adds a default implementation for init(context:) that calls through to init() - this allows fully qualified structs conforming to LambdaHandler to omit their initializers if no setup is required for the Lambda handler

Adds a static var isLocalServerEnabled to the ByteBufferLambdaHandler protocol

Default is true when running in Xcode, but still respects the LOCAL_LAMBDA_SERVER_ENABLED environment variable.
This defaults to false if running outside of Xcode

Updates tests with new changes

Result:
With all of the changes in this PR, a developer could package a local lambda handler Swift Package with an example app that could look like this:
@main
final class EntryHandler: LambdaHandler {
    func handle(request: YourDecodableRequest, context: LambdaContext) -> YourEncodableResponse {
        // lambda logic
    }
}

All previous logic is still retained but the optional code needed is now opt-in with sensible defaults.

thanks @hectormatos2011, @fabianfett  and myself have been discussing some API changes to the main branch that should help address some of the points you bring up. should be able to put up a PR soon and then we can maybe see what else is missing and you can help get it over the finish line. wdyt?

@tomerd I'd love to contribute! Thanks for taking a look. Would you like me to close this one? There's some good nuggets of code in here that should at least help with the type inference issue

lets keep it open and focus on landing https://github.com/swift-server/swift-aws-lambda-runtime/pull/273. then we can see what else we need to bring over

hi @hectormatos2011 would you like to revisit this now that we have the 1.0 API in place?

Let me take a look at 1.0 and close the PR if need be

@tomerd Is it currently possible to have code in the Lambda that makes it always run with LOCAL_LAMBDA_SERVER_ENABLED or do we still have to put that in the target itself? I'd like to be able to deploy example documentation that a developer could just copy and paste into Xcode without having to finagle with Edit Schemes or anything like that

that is not possible right now, to protect users from accidentally deploying the mock / debug server


Add unit tests for Ratchet's JS libs

Are you looking to stick with QUnit as you guys use in Bootstrap or are you interested in something like Jasmine or Mocha?

What's the interest of using Jasmine or Mocha instead of QUnit ?

I don't think any pull request adding unit tests would be rejected on account of which unit testing library was chosen by its author.

My thoughts on pluses and minuses to each @johann-s (feel free to disagree though as a lot of opinion based)
QUnit:
Pros:

Lots of support across the board, from Q&A to CI server support

Cons:

Lacks fluent syntax
Configuration is a headache, and must constantly be maintained
Makes including 3rd party libraries (like assertion libraries) relatively difficult
Asynchronous testing can be a bit of a headache
No baked-in headless run support

Jasmine
Pros:

Simple setup for node through jasmine-node
Headless running out of the box
Nice fluent syntax for assertions built-in, and does play pretty well with other assertion libraries
Supported by many CI servers (TeamCity, Codeship, etc.) and some that don’t support natively have plugins (jenkins has a maven plugin)
Descriptive syntax for BDD paradigm

Cons:

Asynchronous testing can be a bit of a headache
Expects a specific suffix to all test files (*spec.js by default)

Mocha
Pros:

Simple setup
Headless running out of the box
Allows use of any assertion library that will throw exceptions on failure, such as Chai
Supported by some CI servers and plugins for others (jenkins has a maven plugin)
Has aliases for functions to be more BDD-oriented or TDD-oriented
Highly extensible
Asynchronous testing is a breeze

Cons:

Newer to the field, so support might be lacking in certain areas

Apparently @cvrebert is open to every unit testing library.
Thanks @kkirsche for your thougthts it was very interesting.
I only know QUnit and Jasmine and that's right Jasmine is very simple to setup and learn.
In all cases it would be very usefull to have unit test on Ratchet.
Just to know, Is it possible on SauceLab to test for specific devices @cvrebert ?

See https://saucelabs.com/platforms/#android


Update all mentions of adapters.json to reference new adapter "module" system

For more information, see the Modules pull request for Prebid.js.

PS @bretg i heard a rumor you might be working on some docs related to the new modules stuff?

@rmloveland - yup, see https://github.com/prebid/prebid.github.io/pull/275

did a find and squashed a couple more references to adapters.json

This issue is addressed by https://github.com/prebid/prebid.github.io/pull/275


Blank terminal screen after alpha48 upgrade

OS: Windows 10
Terminus version: 1.0.0-alpha.48
When I start a new terminal (doesn't matter whichever shell I choose), I only get this:

Reinstalling doesn't help. Any help would be appreciated.

Duplicate of #369


fix(packages): move jest-emotion to dependencies

closes #127

Deploy preview for project-koku ready!
Built with commit a4aff1250b5259cc4b33a07487e668c69c8e17c4
https://deploy-preview-130--project-koku.netlify.com

Although, I've restarted the build, Travis still appears to be failing.

:+1:
I was able to successfully build koku in production with this fix. I filed #131 as a followup to move test packages out of the production build and into devDependencies.

Codecov Report

Merging #130 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #130   +/-   ##
=======================================
  Coverage   89.26%   89.26%
=======================================
  Files         113      113
  Lines        1164     1164
  Branches      147      147
=======================================
  Hits         1039     1039
  Misses        114      114
  Partials       11       11

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4d4894...c711ebb. Read the comment docs.

:heavy_check_mark: Tests passed
:heavy_check_mark: @LandoCalrizzian approved
merging in 3... 2... 1... :bomb:


GitHub Actions are parallelized

closes #43

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@a539ef4). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #46   +/-   ##
=======================================
  Coverage        ?   56.64%
=======================================
  Files           ?       10
  Lines           ?      316
  Branches        ?       26
=======================================
  Hits            ?      179
  Misses          ?      135
  Partials        ?        2

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a539ef4...3cea03f. Read the comment docs.


grep: warning: stray \ before /

seen using postwhite
grep (GNU grep) 3.11

Since it is just a warning for GNU grep I wonder if it is not there
specifically to make it work with BSD gre but just guessing now.

gnu grep 3.8 introduced the warnings, it's generating a fair amount of output pollution with the integration I'm using.
I don't have a bsd system running to cross reference the behaviors.
Are you suspecting we need special handling depending which grep the endpoint has?
https://git.savannah.gnu.org/cgit/grep.git/tree/NEWS

Regular expressions with stray backslashes now cause warnings, as
their unspecified behavior can lead to unexpected results.
For example, '\a' and 'a' are not always equivalent
https://bugs.gnu.org/39678.  Similarly, regular expressions or
subexpressions that start with a repetition operator now also cause
warnings due to their unspecified behavior; for example, *a(+b|{1}c)
now has three reasons to warn.  The warnings are intended as a
transition aid; they are likely to be errors in future releases.


Always update version

Supersedes and closes #378, implementing this suggestion.

Cosmic bitflip? O_o Trying again..?


Improvement on email client function

In the section "Functions should do one thing" this change uses
the Array.filter method to get the active clients, then emailing
those with the forEach loop.

Cool, I like this! It's along the lines of "Favor functional programming".


Notifications Aren't Correct

When I use this, the notification popup for recipients says that the message is from "Slack API Tester".  Everything else acts the same as it does in the GUI except for this.  Is there any way to fix this?

I might be able to fix this, by setting the username in the PostMessageParameters. I'll have a look.
Reference: https://godoc.org/github.com/nlopes/slack#PostMessageParameters


WIP Create stats.js

Console.log stats for development purposes for now. Afterwards I'll actually output it to the user.

Already a bug.


Mysql error in Puppet installation

The first `puppet apply`` command on a host fails with
Error: /Stage[main]/Main/Service[mysql]: Could not evaluate: Could not find init script or upstart conf file for 'mysql'

Note that the mysql module is installed and appears in /etc/puppet/modules.

Second puppet apply does not fail, so this is probably a dependency issue.


Add Login UI frontend and backend code

Much has been split out from the old monolith Go code.
There is now a Login/Backend for dealing with the flows, and an Initial React frontend for it to allow going through the flow.

Ohh, forgot. Some URLs are hardcoded here. We should fix that before merging

It's not going to work deployed for real


Show rack preview when adding new devices

When on the add device page.
http://XXX/dcim/devices/add/
It would be beneficial to be able to preview the rack itself showing available placement after selecting the rack from the drop down list.
It would also be great once selected the RU location to show the device pending placement location in the rack being shown and then only committing to that location once it has been saved.

This is pretty easily accomplished by navigating first to the rack in which you want to install a device and then selecting the desired position to add it. Including a live preview of a rack on the "add a device" page would require quite a bit of new code and not provide any real new value.


Facebook or twitter login

Hi,
Is there any way to add facebook or twitter login integration ?
tks

Hi @sirfak ,
FB or TW with Cognito or stand-alone?
Thanks,
Vladimir

With cognito
On 21 Sep 2016 3:08 am, "Vladimir Budilov"<EMAIL_ADDRESS>wrote:

Hi @sirfak https://github.com/sirfak ,
FB or TW with Cognito or stand-alone?
Thanks,
Vladimir
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vbudilov/aws-cognito-ionic2/issues/1#issuecomment-248366717,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJOLHYmUla8fxXm_5s1Xok6NOPiFHeW8ks5qsBMqgaJpZM4KBPPV
.

It's just a matter of adding additional buttons and some code that's well documented here:
http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-configuring.html

Great !!
On Wed, Sep 21, 2016 at 3:13 PM, Vladimir Budilov<EMAIL_ADDRESS>wrote:

It's just a matter of adding additional buttons and some code that's well
documented here:
http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-configuring.html
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vbudilov/aws-cognito-ionic2/issues/1#issuecomment-248513577,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJOLHf9jdvFHbphuiOKUfwrccr9N5R9Vks5qsL0VgaJpZM4KBPPV
.

Please I need more explain !!


tempory cleanup of search stuff iteration

Just small changes so you can play around with the search box with minimum of 3 characters


It would be awsome if you publish any test/example programm in (maybe) another repo.

It would be awsome if you publish any test/example kernel in (maybe) another repo. Propably something like this already exist for testing use, so it would be even helpfull to publish it in a not working state!
It would help to understand the implementation, and could make this the first easier to understand method for printing in limine. There is no other simple implementation with direct flanterm. And also not in project like limine-c-template/rust-template.
Overall it looks like a verry helpfull project!

Hi! you can take a look at Ilobilix for an example https://github.com/ilobilo/ilobilix/blob/master/kernel%2Fdrivers%2Fterm.cpp


[azservicebus] Cancelling AcceptNextSession() causes the connection to reset

This is a side effect of handling session cancellation properly but it means that, if users are cancelling AcceptNextSession() they'll end up resetting their connection, causing a blip to any open Receivers.
We can fix this by bringing back some code we had earlier on, where we create a "stray receiver" cleanup goroutine that will keep waiting for the accept to come back and close it.

This bug is no longer valid. Our original plan for go-amqp was to push most of the handling of a cancelled/dangling Receiver to the caller but that turns out to be a lot of work - mostly just in externalizing a lot of the bookkeeping that go-amqp can do for free.
Instead, what happens now is that when you cancel we just exit the wait. If we cancelled before we send anything it's clean. If we cancel before the ACCEPT response has come back then we'll just clean it up on the next time through. So, at worst, we'll end up with an idle session receiver dangling until the next time the user calls to AcceptNextSession().


[WIP] Explore hashing bytes not text

Thank you ++... I merged this with https://github.com/spdx/tools-python/commit/649b7eb55600cd4dcc0f7a3ef49dc09827cf53bd and we will add tests later


[otbn, rtl] Squash call stack read data to 0 when stack is empty

Previous to this change we were seeing X prop issues where a branch happened using a call stack as one or both of the compare operands when the stack was empty. Whilst OTBN raises an error due to the use of the empty stack the branch result goes to X (as the comparison inputs are X) which produces Xs on the imem request interface.
With this change output from the stack gets squashed to 0 when its empty.
Draft PR for as I don't think this is an essential fix. When running a regression I'm seeing some new failures though I think they were hidden behind previous X check failures (overall pass rate is similar). Further investigation should be done before merging this.
There is a mild security argument for this fix as well, it stops previously used call stack values from leaking out, though I'm not sure what practically you could have done with that value (OTBN will halt due to the invalid stack access) and I don't think there'd be sensitive data in the call stack anyway.
Fixes https://github.com/lowRISC/opentitan/issues/21658 along with https://github.com/lowRISC/opentitan/pull/22116

Thanks for the review @rswarbrick
I did try adding the assertion that stack_data_intg is never unknown but I did see a couple of failures. It is possible for a program to push unknown bits into the stack (read from memory that has unknown data in then push to stack) so perhaps not a great assertion.
So no new assertions for now, I can look into the failure I found with the new stack_data_intg is never unknown assertion if you think that's a concern.

Good point about the assertion. No need to tweak it: this looks sensible to me.


Fix infinity loop when record number % page_size = 0

paginate goes into infinite loop if total records number % page_size = 0 (for example, 50).

Thank you for this PR. I have fixed this. I've refactored the code to build it on top of async-rest.


2024/01/20 cs updated , but dwViewAngles is wrong, pls fix it

2024/01/20 cs updated , but dwViewAngles is wrong, pls fix it

constexpr std::ptrdiff_t dwViewAngles = 0x1884F30;


Edit cron task

I have done below task:
1)Added new edit button
2)Added new model for edit cron
3)On submit call updatescheduler API.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

This will not be merged, closing.


fix(secret): corrects list secret command

Due to a recent refactor in the v2 client library, the list secrets function now returns the entire
secret objects instead of just reading the metadata in the previous implementation. This changed object altogther and the way other sections of code fetched the secret name.
This commit addresses the issue by correcting the
list_secrets function.

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


Allow configuring center_projectiles clientpref from site settings

Part of #373
Allows configuring tf2centerprojectiles from the user settings page.
The visual UI changes and new DB queries are both gated behind a new config flag, as this requires some annoying sourcemod setup... we may need some amendments to this if you are segmenting your sourcemod tables in a different db schema.
The queries are a bit icky but are intended to be easy to add support for more clientprefs down the line (ie #520)
Tested: with the new config flag disabled, the settings page looks the same as on master. With the new config flag, there is a new accordion+checkbox which reads/updates the sm_cookie_cache table correctly. Updating the setting then joining a server results in the client getting the new setting.

Clientprefs sql init does create an SQL function for updating cookies. I avoided it because A) my query seems simpler and maybe  faster when updating multiple cookies and B) there is no similar function for reading cookie values, so we have to interact with the tables directly anyways.
My biggest annoyance with this feature is that sourcemod caches cookies locally and delays writing updates to cookies. So a user who is ingame won't see a change to the website take effect right away. And trying to change the same setting ingame+on the website at the same time will be full of race conditions.

Presumably you ran into the same issue i did yesterday, which is that the pgsql sourcemod driver is built against pg v9 which does not support the newer SCRAM based authentication method that basically everybody uses at this point, as it was introduced in v10. Did you downgrade your authentication method to md5? Or did you somehow get this working some other way?
I was thinking about going through the trouble of updating the sourcemod driver to v12, as its the newest version available in ubuntu 20.04, which i think is the oldest platform they target, though its statically linked, so it really shouldn't matter.

Yeah I downgraded to md5, mostly a matter of touching pg_hba.conf and resetting passwords. Also had to grant the gbans server's db user permissions on the sm_cookies and sm_cookie_cache tables.

These looks good, ill wait to merge this and the motd one until the next version so i have a bit more time to deal with the pg changes. Don't worry about fixing the conflicts since there is a fair amount of them introduced, ill take care of them before merging.

Added the create tables calls to the migrations so they are always available and do not require the database role accessing those tables to have the create table privilege.
Updated settings page for new layout.


/v3/kafka/(cluster)/consumer returns empty

I'm running solsson/burrow 1.3.2 with Kafka 2.5.1 (cp-kafka). The endpoint "/v3/kafka/test-cluster/consumer" is returning "consumers:[]" (empty list of consumers). Our consumers are set to use auto-commits. I cannot hit the burrow endpoint to get lag information if I cannot get a list of consumers. Please let me know if anyone has any suggestions. Thank you.
bin/kafka-run-class.sh kafka.admin.ConsumerGroupCommand --list --bootstrap-server localhost:9092, list the consumer groups
I've verified that "enable.auto.commit = true".

https://gitter.im/linkedin-Burrow/Lobby?at=5d8aa4e65ab93616944fc931
Peter Bukowinski @pmbuko:
"You should make sure the version of burrow you are using is up-to-date. The latest release supports up to 2.5: https://github.com/linkedin/Burrow/blob/v1.3.4/core/internal/helpers/sarama.go#L26-L59 — the client profile section is important or it will default to using kafka version 0.8."

https://gitter.im/linkedin-Burrow/Lobby?at=5d8aa4e65ab93616944fc931
Peter Bukowinski @pmbuko:
"You should make sure the version of burrow you are using is up-to-date. The latest release supports up to 2.5: https://github.com/linkedin/Burrow/blob/v1.3.4/core/internal/helpers/sarama.go#L26-L59 — the client profile section is important or it will default to using kafka version 0.8."


Rstudio

Few clarifications - Can Rstudio be installed on GPU Instance? and does it new license for both CPU & GPU? Is feature in preview?
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 70b332b2-b671-a5e8-0db0-38aa1378dbaf
Version Independent ID: 13cd812a-48e4-dd85-3cc8-a0b357a5a453
Content: Create and manage a compute instance - Azure Machine Learning
Content Source: articles/machine-learning/how-to-create-manage-compute-instance.md
Service: machine-learning
Sub-service: core
GitHub Login: @swatig007
Microsoft Alias: swatig

@Rajini09
Thanks for your feedback! We will investigate and update as appropriate.

@Rajini09
Thanks for reaching out. MicrosoftDocs/azure-docs are mainly related to document feedback/issues and for troubleshooting an issue, I would recommend posting a question to Microsoft Q&A. Our community experts and champions can assist you with this issue.
We will now proceed to close this thread and feel free to add a comment if you have any questions.


Add manual steps describing how to check launcher behavior regarding POSIX signals

Issue Number

#8
Overview

[ ] I have added some manual steps to verify that SIGINT and SIGTERM are handled properly

Comments

It's more about having that written that so that, we won't forget to test it upon releases!

Sure :+1:, though, keep in mind that we do not handle the SIGKILL for now. This one is a bit tricky because in practice, we can't put a signal handler since the SIGKILL with forcefully and immediately terminates the process (which is, the expected semantic for a SIGKILL).
We had a chat this morning with @rvl about a way to handle that by having a shared socket between the supervisor process and its children. When the supervisor gets closed, one end of the socket will get closed as well, cascading to the child which will also terminate. For now, I'll mention the current behavior in the steps, and we can refine it later for the SIGKILL if we want to.

Yes, I noticed some comments about SIGKILL on other PRs later on, after putting this comment.
Just thinking If we won't support SIGKILL than maybe it would be worth putting this in some user facing documentation as a known issue/limitation/behaviour (not sure where, API doc?).

Well, it's not that we don't support SIGKILL, we do. But the semantic of SIGKILL doesn't allow us to do any clean-up after receiving it. So, if one kills the launcher, one doesn't kill the sub-processes the launcher has started.
Yet, ideally, we do want to "link" our launcher to the spawned processes at the system level, such that the OS will make sure to terminate the subprocesses when we kill the parent. One way to do that is to have a shared socket between the launcher and its children (which will anyway be the case with the new Haskell node since we'll communicate through a pipe).

Well, it's not that we don't support SIGKILL, we do. But the semantic of SIGKILL doesn't allow us to do any clean-up after receiving it. So, if one kills the launcher, one doesn't kill the sub-processes the launcher has started.

Well, not very fortunate selection of words on my side but that's what I actually meant by saying don't support ^ ;) i.e. that we don't clean up after kill -9 as of now. So if we wan't to go for this shared socket now (or very soon) to support it - that's cool :). If not at this point (or not in the near future), that's also OK, but then it would be worth to state it somewhere as a known limitation. That's what I meant. :)


js updates

Had some issues on Safari where the loader didn't show, refactored the click behaviours of the buttons

:+1: from me (as long as we are def transpiling our JS)


Merge sandbox 20150812a

This merge is to catch us up with Apache's incubator project.

This is merging in the wrong direction.


Use gofmt to fix lint issues and update perfdash README

In this PR:

I fix the lint issues from PR #1382. My gofmt/golint was not working properly. The PR was merged, but it failed the verify-lint test
I updated the readme to reflect that perfdash is no longer using godeps since we moved to go modules

/hold

/ok-to-test

This seems to be the reason why the lint pre-submit is failing:
verify/verify-lint.sh
metrics-downloader.go:49: File is not `gofmt`-ed with `-s` (gofmt)
	MetricsBkt     MetricsBucket
	Options        *DownloaderOptions
perfdash.go:49: File is not `gofmt`-ed with `-s` (gofmt)
	logsPath = pflag.String("logsPath", "logs", "Path to the logs inside the logs bucket")
make: *** [Makefile:49: verify-lint] Error 1

You can find it from the 'Raw build-log.txt' under prow test details page.

/unhold

Thanks for taking a look :) The lint-test passes now; I updated the PR comments to reflect the changes I made. Cheers @shyamjvs

/lgtm
/approve


How to Update installation

I would like there to be a way of updating my excisting installation. Now I have to create a new installation (in a new folder) and then do a lot of manual work (renaming/moving files etc) to get  ASSETS and DATAROOT to have the same content and the same links as they had before the update

All file references within SPX are relative. So once you have the new version installed, you can copy ASSETS and DATAROOT folders from the old to the new and all your content should work as is.
For DATAROOT-folder there is also an option to have it elsewhere on your filesystem, so it does not need to be within the SPX installation folder structure. This way you will only need to copy ASSETS (templates and media files) to your new installation.
There is a setting in config.json > general > dataroot to set the absolute path of the dataroot -folder.


Activating +forge in magit slows initial startup

What did you expect to happen?
Activating +forge only slows down forge-specific operations.
What actually happened?
Activating +forge slows down initial startup.
Without +forge:
Doom loaded 311 packages across 50 modules in 1.089s

With +forge:
Doom loaded 319 packages across 50 modules in 3.217s

The actual magit status buffer is loaded fast, so I expect that forge is somehow pulled during startup already.
Describe your attempts to resolve the issue
I looked at the magit module code but don't see any load statements out of place. There is a use-package statement but loading is deferred until after-call magit-status-buffer. I didn't really know where to go on from there.
Steps to reproduce

add (magit +forge) to init.el.
doom sync
start Emacs
observe the increased startup time

System Information
https://pastebin.com/MG35Si4x
EDIT: I should say that I don't have any magit-specific setup in my personal doom.d. However, it could be that another setting pulls magit right away, I don't know.
EDIT2: I tried with both, the Nix provided emacsql-sqlite (and ignoring the custom package), and the custom built emacsql-sqlite by straight.el.

I just realized that the delay is much worse, when workspaces (persp-mode) is deactivated. Then, I have the following startup times:
With +forge: 10s
Without +forge: 1s

I cannot reproduce this in vanilla Doom. Please double check your private config, in case you are eagerly loading magit, forge, or another package that is indirectly pulling it in (e.g. loading an org package will be expensive by itself, but may pull in orgit, which provides org<->magit integration, and may pull in forge as well).

I will check. The only thing that bugs me is that deactivating something (+workspaces) increases startup time. So there must be something fundamentally wrong.
I just checked my config. I do not reference magit nor forge. nor orgit, and I do defer all stuff related to org.
I do use NixOS. The only thing that comes to my mind is that some function enters a direnv directory thereby taking a while. I will investigate more when I have time.

OK, I just tested again, and I cannot observe the 10s anymore. No idea why.
I still observe a factor of 3 (3s with forge vs 1s without forge), independent of workspaces.
Do you also observe this difference or none at all?

I just checked, adding +forge still adds 3s to my startup time.

Somehow the bot doesn't remove the stale label. Not sure what to do. Maybe there is a delay.

Still an isse.


Documentation Links

Details
Some of the links in the documentation https://ts.llamaindex.ai/ referencing not found. For example for class VectorStoreIndex.

Checklist

[X] apps/docs/docs/modules/high_level/data_index.md ✅ Commit 4a8a603

• Check if the link to the VectorStoreIndex class documentation is correct. If it is not, correct the link.
• If the documentation for the VectorStoreIndex class does not exist, create a new markdown file for it in the appropriate location and link it in the data_index.md file.

 Read documentation
    Our documentation can be found at https://docs.trunk.io

 2. Get help and give feedback
    Join the Trunk community at https://slack.trunk.io

Closing due inactivity and for cleaning
Feel free to open again


Added Textures and Materials

Added Textures and Materials, unwrapped all models and applied materials. hide prototypes in play mode
Hey, I played your game and just had to add textures.
Great stuff on the algorithm btw, I love it :-)

Nice work!
I'm afraid that this it not the direction I want to take this project in, so I won't merge the PR. But I encourage you to continue to work on the fork. You are also welcome to publish a build of your version, for example on itch.io.
I hope you understand!

Thanks.
Of course I understand. Good luck with the project.


Refit model

Codecov Report
Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (f3fb2e1) 90.56% compared to head (d2a52c6) 90.26%.

Files
Patch %
Lines

autoemulate/compare.py
50.00%
8 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #177      +/-   ##
==========================================
- Coverage   90.56%   90.26%   -0.31%
==========================================
  Files          42       42
  Lines        1834     1849      +15
==========================================
+ Hits         1661     1669       +8
- Misses        173      180       +7

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


how to use in swift 3.0?

swift 2.3 can use aspects well, but not work in 3.0

Me Too， How to solve？

aspects work well with Swift 3.0 , Maybe the Swift funcation convert OC funcation have been changed, such as 'in' become 'with'

Here is an example :
try UIViewController.aspect_hook(#selector(UIViewController.viewDidAppear(_:)),
                                 usingBlock: unsafeBitCast(viewDidAppearCompletionBlock, to: Any.self))

I am using the .PositionAfter in swift 2.x so [] in swift 3. I could add with: [] in the method or delete it since this is the default value.


Added tests on input type and dimensions to GdmFull

by @632Katz & I

Coverage increased (+0.3%) to 82.421% when pulling ddf11afdd837dfa8a4c090fd6f03da43af979ea6 on jameslamb:firstPR into b75eedcb035dc89e9d8b285e6e0b4b3d08a739e5 on terrytangyuan:master.


Move the "park" logic

The "park" logic need to be moved into Vehicle object. So the code would look like this:
var vehicle = VehicleFactory.MakeCar(...);
var parking = ParkingFactory.MakeFactory(...);
vehicle.Park(parking);

Done ✅


[BUG]: On hover upper border gets hidden beneath the image above it (manage hovering effect)

The hovering effect/scale should be corrected and also can reduce card size for a better UI.

Cards should be of similar and slightly small sized for an appealing UI.
Kindly assign this issue to me under GSSOC'24.
Thanks!

Hi @SwatiAgwl @khushi-joshi-05 ,
I'd like to take on this issue and provide a solution. I believe the problem can be fixed by adjusting the z-index and position properties in the CSS to ensure the upper border remains visible on hover. Could you please assign this issue to me? Thank you!
Best regards,
[Dilip Kumar]

Hi @sunny0625 , @khushi-joshi-05,
Could you please review the PR and let me know if any adjustments are needed?


Check for disabled virtual 8086 mode in guest access-rights fields

The functions from vmcs_intel_x64::check_guest_cs_access_rights_type to vmcs_intel_x64::check_guest_gs_access_rights_remaining_reserved_bit_0 need to check if virtual-8086 mode is disabled before the check occurs. See section <IP_ADDRESS> (second bullet of the seventh bullet)

yeah, I bet some of that is wrong. Originally, these checks didn't do that because we just assumed that it was off as we didn't want to support that at all. With the second version of these we backtracked on that, so there might be some missing still

Fixed in #343


Read execution status/position

We need an API that would take in the exid and respond with its status and position.

[x] launch a new execution
[x] list executions
[x] cancel execution
[ ] read execution status/position

Sorry, I repeated your list in https://github.com/floraison/flack/issues/4#issuecomment-285895247 and I missed the point you highlighted here.


Add mysql install step to macOS instructions

Hey there, just getting the backend running locally and had to install mysql for the pip install to work. Not sure if universal but some updated docs in case anyone else hits it.

Ah just noticed the dev branch. Let me close this are re-open against that


Prepare for release Azure.ResourceManager.StorageMover 1.0.1

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


Let's track similar problems here and investigate if they re-occur.

Another one at http://ci.mxnet.io/blue/organizations/jenkins/GluonNLP-py3-cpu-unittest/detail/PR-935/1/pipeline#step-125-log-1116