Getting UCSC tools into the depot

@natefoo can we get the UCSC binaries into the depot? We need them for a data manger and some converters.

@bgruening okay, done. Completely untested, I just did a ./build and scp... =)

@natefoo this is how it should work. As less work as possible for you. Let's see!
@blankenberg do you have any thoughts on one package for all UCSC tools vs.  X separate packages?

I'm ok with either, since they all just build at once a single package certainly makes sense.

Great also my preferred solution! I will create/update such a package.

Best to just make sure it only includes the commercially usable stuff (src/lib, src/inc and src/utils and python directories):
This directory contains the entire source tree for the
UCSC Genome Bioinformatics Group's suite of biological analysis
and web display programs as well as some of Jim Kent's own tools.
All files are copyrighted, but license is hereby granted for personal,
academic, and non-profit use.  A license is also granted for the contents
of the src/lib, src/inc and src/utils and python directories for commercial
users.

@bgruening Thanks! :)

@blankenberg we should be good on licensing issues.
@bgruening maybe this would be a good time to try out @jmchilton's planemo's ability to decompose tools into separate repositories? I feel like a single repo would be nice from a dev perspective, but end-users only need a couple of the tools for a basic galaxy installation (e.g. faToTwoBit for trackster) and shouldn't need to install the full complement of UCSC tools?

@erasche it's about tool dependencies here, I'm not aware of a feature that can decompose tool_dependencies. Moreover, if you depend on a lot of UCSC tools you need to write a lot of code. It's < 150MB if we take all binaries. Is this too much?

@bgruening ah, of course, I was thinking about tools...

@bgruening you're writing up wrappers for them right? Something that'll make it to tools-iuc eventually?

@erasche yes if time permits and on urgent demand ;)
@blankenberg also needs this for a data manager. So things coming together.
See here: https://github.com/bgruening/galaxytools/pull/129
I'm not sure about the repository thought. Imho these are more converters and should be attached to datatypes ...

@bgruening hmm, good point. Many of them are just datatype converters. Ugh. Maybe we wait, pending that IUC datatype meeting?

Exactly :)

Initial version is now available and I have seen an increased usage :).
Thanks!


Why does EmitMemberAccessor.CreateConstructor(Type) require a public constructor?

It seems that entity objects I read/write from/to DynamoDB need to have a public constructor, otherwise EmitMemberAccessor.CreateConstructor(Type) returns null and the DdbClassInfo constructor throws an InvalidOperationException. Is there a reason for this limitation? Or could the limitation be removed to support non-public constructors?

If I remember correctly, there were issues with deserializing DDB response to objects if there is no parameterless constructor. I would like to add support for other constructor types but I need to evaluate how much work is required for it.

I agree that there needs to be a parameterless constructor. The limitation is that the parameterless constructor must be public. I think the issue is line 19 in EmitMemberAccessor.cs shown below.
ConstructorInfo? realMethod = type.GetConstructor(BindingFlags.Public | BindingFlags.Instance, binder: null, Type.EmptyTypes, modifiers: null);

The binding flags are BindingFlags.Public | BindingFlags.Instance - i.e., BindingFlags.NonPublic is missing.
If BindingFlags.NonPublic were to be added, then it should be possible to have a non-public parameterless constructor.

I think some limitations prevented us from supporting non-public constructors but I don't remember what was that exactly. I will check again later this week and post my findings. If it's indeed possible to support non-public constructors I'm up to removing this limitation.

Thanks @firenero.

@bill-poole public constructors are required now because objects are created using the IL Emit in EmitMemberAccessor.CreateConstructor(Type) as below:
generator.Emit(OpCodes.Newobj, realMethod);

It only works for public constructors. Fallbacking to reflection in case of private constructors is not that trivial because sometimes the type without a public constructor can be a generic argument of Type parameter. So far I'm not convinced that adding support for non-public constructors is worth the effort because usually you can add a public constructor.
Can you tell something about your use case and why non-public constructors are important there?

I have objects that I'm saving to DynamoDB that have certain invariants that the object enforces - i.e., its properties can't just have any value. However, when loading an object from the database, we can trust that the data is correct - i.e., we don't need to worry about enforcing the invariants. If I have a public parameterless constructor, then I cannot guarantee that the invariants are enforced because an object can be created with no property values, and then I need to have public setters for all the properties, allowing any values to be set for the properties - i.e., bypassing all the invariants.
That's why ORMs tend to support creating entity objects with non-public parameterless constructors.
Note that EfficientDynamoDb seems to support setting property values using non-public setters. I just can't get EfficientDynamoDb to create the objects using a non-public parameterless constructor.
What do you mean by "sometimes the type without a public constructor can be a generic argument of Type parameter"?
It looks like some work was done in this space for .NET 8 (see here and here). Would ConstructorInfo meet your requirements and allow invoking non-public constructors?

What do you mean by "sometimes the type without a public constructor can be a generic argument of Type parameter"?

Disregard that. I meant that the EmitMemberAccessor.CreateConstructor(Type) method is used to create not only user-provided types but also some internal wrappers required for the library to work, such as `GetItemEntityProjection. However, it seems like this doesn't matter in this case.
I think we can indeed fallback to a reflection call in case there is only a private constructor. However, I need to do more tests to confirm it works for all possible cases and do some benchmarks to confirm that it doesn't hurt the optimal flow. However, keep in mind that if all goes well and this feature is added, it will have worse performance characteristics simply because reflection is much slower than IL emitting.

I tried adding BindingFlags.NonPublic at line 19 in EmitMemberAccessor.cs as shown below and the CreateConstructor(Type) method successfully returned a non-null Func<object> delegate to invoke a private parameterless constructor.
ConstructorInfo? realMethod = type.GetConstructor(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance, binder: null, Type.EmptyTypes, modifiers: null);

Once the CreateConstructor(Type) method has created the constructor delegate for a type, the delegate is cached, so it shouldn't matter to the performance of invoking that delegate whether the constructor is public or private. However, just to make sure, I benchmarked both scenarios.
I also tested performance of invoking the constructor (public and private) using reflecting using the new ConstructorInvoker class added in .NET 8.
The benchmark results are below.

Method
Mean
Error
StdDev

Public_DynamicMethod
3.681 ns
0.0793 ns
0.0703 ns

Public_ConstructorInvoker
5.062 ns
0.1021 ns
0.0955 ns

Private_DynamicMethod
3.660 ns
0.0759 ns
0.0710 ns

Private_ConstructorInvoker
5.137 ns
0.0624 ns
0.0553 ns

Unfortunately, we can't use ConstructorInvoker because the library still targets netstandard2.1 that doesn't have access to .NET 8 APIs. I've benchmarked realMethod.Invoke() approach and it's ~2 times slower than doing emit and slightly slower than ConstructorInvoker:

Method
Mean
Error
StdDev
Ratio

Reflection
6.147 ns
0.1245 ns
0.1165 ns
1.00

Emit
3.417 ns
0.0977 ns
0.0960 ns
0.56

Invoker
5.140 ns
0.0629 ns
0.0589 ns
0.84

Overall, I believe there is not much we can do about private constructors to narrow the gap so I think we can use the reflection for this case. It will take some time to implement and test the change but hopefully, I can get it done next week.

Can you help me understand why you can't use emit for private constructors (i.e., just update line 19 in EmitMemberAccessor like I proposed above)? It seems to work for private constructors in my testing and without the performance hit of using reflection.

Sorry, I've misread your previous message. Just tried it again and it indeed works. Probably I changed something else last time I tested and accidentally broke emitting.
In that case, nothing stops us from adding this feature. I still want to test various cases but since it's a less dangerous change I think I will have time to do that by the end of the week.

That's great, thanks!


feat: add lint struct_marked_non_exhaustive_changed_type

This implemnents the second part of https://github.com/obi1kenobi/cargo-semver-checks/issues/954
Resolves https://github.com/obi1kenobi/cargo-semver-checks/issues/954
TODO:

[x] The implementation is based on https://github.com/obi1kenobi/cargo-semver-checks/pull/962, to remove the merge conflict once that is merged ^^
=> will need to rebase before this is reviewable
[x] Self review tomorrow

think this still needs a snapshot file update to pass CI

Oops, missed those files / forgot to change the testcases during the renaming


I cannot start the BBBW

Hi, I tried to follow the quick start guide, but shortly after I turn on the Beaglebone, the user LEDs turn off and I can no longer access to the "kind of storage Beaglebone". I don't know if it is user error or my Beaglebone is broken. Please help me.

System boots from eMMC memory, I verified that the user LEDs shows the 'boot up', then the usr0 LED blink in a heartbeat pattern, but shortly after all LEDs turned off :/

@SayethRd
Hi SayethRd,
Did you find the root cause for this issue? I am also seeing the same problem on my board first the board gets recognized after  1-2 minutes i am getting usb was not recognized and boards get disconnected (then the usr0 LED blink in a heartbeat pattern, but shortly after all LEDs turned off )

I don't know exactly what is the root cause, but it fixed when I put the antennas (of Wi-Fi and Bluetooth) out of the board. Tell me if it works on your Beagle too.

Thank you SayethRd for immediate response,
Today morning i have connected my BBB to my computer again with out any
changes but it started working.
On Fri, May 15, 2020 at 10:10 AM SayethRd<EMAIL_ADDRESS>wrote:

I don't know exactly what is the root cause, but it fixed when I put the
antennas (of Wi-Fi and Bluetooth) out of the board. Tell me if it works on
your Beagle too.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/beagleboard/beaglebone-black-wireless/issues/13#issuecomment-629257416,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYSHNUSRJJ6LUVKRRRZHMTRRVEN3ANCNFSM4F7N7QOA
.

It happened to my BBB to, but eventually it stopped working untill I put the antennas out of the board (like the box image). I hope it not happen to your BBB.

Hi SayethRd,

i thought you told me to remove the antenna connectors before
2.My board also worked after i placed the antennas pointing outside the
board (just as you said like box image).

Thank You
On Sat, May 16, 2020 at 2:03 AM SayethRd<EMAIL_ADDRESS>wrote:

It happened to my BBB to, but eventually it stopped working untill I put
the antennas out of the board (like the box image). I hope it not happen to
your BBB.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/beagleboard/beaglebone-black-wireless/issues/13#issuecomment-629594312,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYSHNQHYXESG2TISOBYHSTRRYUC7ANCNFSM4F7N7QOA
.

Good. Sorry if I wasn't clear before 😅.

Thank you very much for your help. I am a beginner, could you please
Suggest some specific websites particularly for beagle bone black wireless
for a beginner.
On Thu, May 21, 2020 at 11:12 AM SayethRd<EMAIL_ADDRESS>wrote:

Good. Sorry if I wasn't clear before 😅.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/beagleboard/beaglebone-black-wireless/issues/13#issuecomment-632141339,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYSHNQGVNGVVVMZ7BI7XZ3RSVAG5ANCNFSM4F7N7QOA
.

Humm sorry, I just read the Exploring Beaglebone book 😅, but I think the Beaglebone Cookbook is useful for beringers.

Thank you for the information 🙏
On Thu, May 21, 2020 at 3:39 PM SayethRd<EMAIL_ADDRESS>wrote:

Humm sorry, I just read the Exploring Beaglebone book 😅, but I think the
Beaglebone Cookbook is useful for beringers.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/beagleboard/beaglebone-black-wireless/issues/13#issuecomment-632304241,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYSHNXEZP2NXXDTI7WM33LRSV7QPANCNFSM4F7N7QOA
.


Improve Test API for Engines

This improves Test API for ember-engines, we need to document this on Engine Guides 🎉
Introduces two new APIs:

loadEngine -- Loads the specified engine (including assets), instantiates it, and returns the Engine's "owner" via this.engine.
setupEngine -- A convenient wrapper around loadEngine that works nicely in the same style as ember-qunit.

Rendering tests
import { module, test } from 'qunit';
import { setupRenderingTest } from 'ember-qunit';
import { render, click } from '@ember/test-helpers';
import hbs from 'htmlbars-inline-precompile';
import { setupEngine } from 'ember-engines/test-support';

module('Integration | Component | setupEngineRenderingTest', function (hooks) {
  setupRenderingTest(hooks);
  setupEngine(hooks, 'ember-blog');

  test('should change colors', async function(assert) {
    assert.expect(2);

    // set the outer context to red
    this.set('colorValue', 'red');

    await render(hbs`<PrettyColor @name={{this.colorValue}} />`, { owner: this.engine });

    assert.equal(this.element.querySelector('[data-test-pretty-color]').textContent.trim(), 'Pretty Color: red', 'starts as red');

    this.set('colorValue', 'blue');

    assert.equal(this.element.querySelector('[data-test-pretty-color]').textContent.trim(), 'Pretty Color: blue', 'updates to blue');
  });

  test('should update title on button click', async function(assert) {
    assert.expect(2);

    await render(hbs`<MagicTitle />`, { owner: this.engine });

    assert.equal(this.element.querySelector('h2').textContent.trim(), 'Hello World', 'initial text is hello world');

    // Click on the button
    await click('[data-test-title-button]');

    assert.equal(this.element.querySelector('h2').textContent.trim(), 'This is Magic', 'title changes after click');
  });
});

Unit tests
import { module, test } from 'qunit';
import { setupTest } from 'ember-qunit';
import { setupEngine } from 'ember-engines/test-support';

module('Unit | Route | post.likes', function (hooks) {
  setupTest(hooks);
  setupEngine(hooks, 'ember-blog');

  test('it exists', function (assert) {
    assert.expect(1);

    let route = this.engine.lookup('route:post.likes');
    assert.ok(route);
  });
});

Application tests
import { module, test } from 'qunit';
import { visit, currentURL } from '@ember/test-helpers';
import hbs from 'htmlbars-inline-precompile';
import { setupApplicationTest } from 'ember-qunit';
import { setupEngine } from 'ember-engines/test-support';

module('basic full application test', function(hooks) {
  setupApplicationTest(hooks);
  // no setupEngine in application tests, because they should load the engine automatically

  test('the user can visit blog engine', async function(assert) {
    await visit('/routable-engine-demo/blog/new');

    assert.equal(currentURL(), '/routable-engine-demo/blog/new');
  });
});

@rwjblue I did your solution, but it don't work
export function setupEngineTest(hooks, engineName) {
  hooks.beforeEach(function() {
    if (!this.owner) {
      throw new Error('You must call one of the ember-qunit setupTest(),'
        + ' setupRenderingTest() or setupApplicationTest() methods before'
        + ' calling setupEngineTest()');
    }

    let resolver = engineResolverFor(engineName)

    setResolver(resolver);
  });
}

I get this error:

FYI - @villander and I are working on this together, we have a nice working solution for setupRenderingTest and setupTest. Working on making setupApplicationTest a bit nicer still....

Integrations tests
import { module, test } from 'qunit';
import { render } from '@ember/test-helpers';
import hbs from 'htmlbars-inline-precompile';
import { setupRenderingTest } from 'ember-qunit';
import { setupEngineTest } from 'ember-engines/test-support';

module('Integration | Component | hello-name', function(hooks) {
  setupRenderingTest(hooks);
  setupEngineTest(hooks, 'ember-blog');

  test('it renders', async function(assert) {
    // Set any properties with this.set('myProperty', 'value');
    // Handle any actions with this.set('myAction', function(val) { ... });

    await render(hbs`{{hello-name name='Michael'}}`);

    assert.equal(this.element.textContent.trim(), 'Hello Michael');

    // Template block usage:
    await render(hbs`
      {{#hello-name}}

      {{/hello-name}}
    `);

    assert.equal(this.element.textContent.trim(), 'Hello');
  });
});

Unit tests
import { module, test } from 'qunit';
import { setupTest } from 'ember-qunit';
import { setupEngineTest } from 'ember-engines/test-support';

module('Unit | Route | index', function(hooks) {
  setupTest(hooks);
  setupEngineTest(hooks, 'ember-blog');

  test('it exists', function(assert) {
    let route = this.owner.lookup('route:index');
    assert.ok(route);
  });
});

Also, we need to finish off https://github.com/emberjs/ember-test-helpers/pull/664 before this will actually work properly.

for eager engines
module("Asdf", function(hooks) {
  setupRenderingTest(hooks);
  setupEngineTest(hooks, 'engine-name-here');
})

for lazy engines
module("Asdf", function(hooks) {
  setupRenderingTest(hooks);
  setupEngineTest(hooks,  'engine-name-here', 'mount-point');
})

@rwjblue this solution it's good? if yes, I can finish emberjs/ember-test-helpers#664 to merge this as well

I don't think we should need the mount point, I'd like to figure out why that was necessary and remove it before we land this.

@rwjblue any update here? do you have any idea to load lazy engine without mountPoint?

@rwjblue any news?

I don't think we should need the mount point, I'd like to figure out why that was necessary and remove it before we land this.

@rwjblue can you figure out if is possible finish this without mount point, please? I'd like of turn test API for engines more friendly

@villander Thanks for pushing this forward!
Few questions:

I see we are using beforeEach to load the engine, am I correct in assuming this is so on each test, we will setup a clean instance of the engine?
I do not see any unload of the engine on an afterEach or after hook. So as we run many engine tests, more engines will be loaded and the environment will be polluted with engines loaded from previous tests?? I'm thinking if we should unload on after hook
Since I am not involved earlier, how does https://github.com/emberjs/ember-test-helpers/pull/664 play along with this? Do we need to land that PR first?

How does https://github.com/emberjs/ember-test-helpers/pull/664 play along with this? Do we need to land that PR first?

Yes, we need to land that first. Specifically, without that change it is not possible to render components as if you were within the Engine instance (and therefore the components would not be found by the normal resolution process).

Just curious, but what's the status on this PR? It seems like we were waiting on https://github.com/emberjs/ember-test-helpers/pull/664 to land?

@villander tried this approach in our app and had to remove preloadAssets(manifest).then(start) from tests/test-helper.js for lazy loading engine.
Otherwise I get error
Error: Assertion Failed: invalid engine: missing mountPoint

@villander do you have any idea what I'm missing?

@SergeAstapov are you using this custom branch for ember-test-helpers https://github.com/emberjs/ember-test-helpers/pull/664?

@villander I've used latest release of @ember/test-helpers with fixes from emberjs/ember-test-helpers#664 applied.

@villander BTW this is only an issue for component rendering test, controller unit test works just fine

this must work for integration and acceptance tests as well.

@villander the difference is in this.owner.hasRegistration(engine:${engineName}):

when assets are pre-loaded via preloadAssets(manifest).then(start) it evaluates to true
when I have start() and assets not pre-loaded, it evaluates to false hence invokes loadEngine().

I assume difference comes from the fact that in first case it invokes this.owner.buildChildEngineInstance(engineName) and in the second - it executes router._loadEngineInstance()
I'm happy to discuss details in Discord if that could help.

@villander im finding it hard to setup my tests for the engines... how far along is your standalone helpers? is it possible for me to pull your branch and use it? or if this will be merged with the master soon, should i wait till that happens?

@TheLooseCannon you can pull my branch and reuse it, but don't forget of the ember-test-helpers. emberjs/ember-test-helpers#664?

@SergeAstapov I had to replace preloadAssets(manifest).then(start) with start() in tests/test-helper.js for lazy loading engine.
And it continues working fine, check it out the tests.

@villander yeah, that seem to make the trick. If that's expected and acceptable, then no issue here.
Just an idea - this need to be referenced in docs somehow, I assume we could do so once this PR lands.

Following a short discussion with @villander on Discord, I wanted to raise a concern regarding this update: during acceptance tests I imagine that multiple engines might be necessary, in which case setting engine instances on this.engine can potentially cause some issues when access to those engines' contexts is necessary.
I propose using a registry of sorts instead, so that  setupEngineTest could be executed multiple times. Thoughts?

during acceptance tests I imagine that multiple engines might be necessary

Why would you need to access the engine instance in an acceptance test? In general, acceptance tests already work without modification as the engine content is loaded just like it would be loaded in a normal production application (either this.mount or {{mount).

during acceptance tests I imagine that multiple engines might be necessary

Why would you need to access the engine instance in an acceptance test? In general, acceptance tests already work without modification as the engine content is loaded just like it would be loaded in a normal production application (either this.mount or {{mount).

My specific case is that I have a service that uses window.location to redirect to an external URL, in an engine. In an acceptance test in the host app I need to stub this behavior, because window.location is read-only and currently I have no clean way of doing this.
I think there could be other edge cases where stubbing services inside an engine is still needed, so if it's not hard to give a test access to an arbitrary engine's context, why not give developers the freedom to do it?
Finally, from what I understand from the comments on this PR, you still need to use setupEngineTest in acceptance tests, which will set up this.engine. So this becomes a pitfall for a developer that might rely on it, then they add a second setupEngineTest for engine B for some reason, and suddenly the test now fails.

you still need to use setupEngineTest in acceptance tests, at least with lazy engines, which will set up this.engine

No, you shouldn't need setupEngineTest at all in acceptance tests.

My specific case is that I have a service that uses window.location to redirect to an external URL, in an engine. In an acceptance test in the host app I need to stub this service, because window.location is read-only and currently I have no clean way of doing this.

I would expect that you either have a window service in the app that is provided to each of your engines (and that would naturally flow down into the engines without any custom munging in the engine itself) or you would use something like ember-window-mock to avoid needing any specialized code at all.

The idea of having a single this.engine is flawed if setupEngineTest can be called multiple times.

Maybe? Not sold personally, but we can certainly prevent calling it multiple times and avoid the foot gun.

In general, acceptance tests already work without modification as the engine content is loaded just like it would be loaded in a normal production application

I totally agree!
Maybe we need to load two engines to test flow in acceptance tests? I'm not sure, will depend on how you structure your architecture

btw we are currently using this test helper:
import { getApplication } from '@ember/test-helpers';
import { setupRenderingTest as _setupRenderingTest } from 'ember-qunit';

import { set } from '@ember/object';

import LinkToExternalComponent from 'ember-engines/components/link-to-external-component';import engineResolverFor from 'ember-engines/test-support/engine-resolver-for';

import TestContext from '../test-context';

const modulePrefix = 'some-engine';
const resolver = engineResolverFor(modulePrefix);

// https://github.com/ember-engines/ember-engines/issues/525#issuecomment-402131973
export default function setupRenderingTest(hooks: NestedHooks) {
  _setupRenderingTest(hooks, { resolver });
  const app = getApplication();

  hooks.beforeEach(function (this: TestContext) {
    this.owner.__registry__.fallback.fallback = app.__registry__;
    const config = this.owner.resolveRegistration('config:environment');
    if (config) {
      set(config, 'environment', 'test');
    }

    this.owner.register('component:link-to-external', LinkToExternalComponent);
  });
}

The interesting addition compared to https://github.com/ember-engines/ember-engines/issues/525#issuecomment-402131973 is
const app = getApplication();
this.owner.__registry__.fallback.fallback = app.__registry__;

This make render tests work with service injections of addons like ember-responsive or ember-intl, that define their own custom registrations, like breakpoints:main and formats:main respectively.

jumping in after we encountered the issue ourselves on our team.
the file @buschtoens sent, alongside the replies here, really helped and saved us tons of hours.
Here is our version with some refactoring:
import { getApplication } from '@ember/test-helpers';
import { setupRenderingTest } from 'ember-qunit';
import { set } from '@ember/object';
import engineResolverFor from 'frontend/tests/engine-resolver-for';

// https://github.com/ember-engines/ember-engines/issues/525#issuecomment-402131973
export function setupEngineRenderingTest(hooks, modulePrefix) {
  const resolver = engineResolverFor(modulePrefix);
  setupRenderingTest(hooks, { resolver });
  const app = getApplication();

  hooks.beforeEach(function () {
    this.owner.__registry__.fallback.fallback = app.__registry__;
    const config = this.owner.resolveRegistration('config:environment');
    if (config) {
      set(config, 'environment', 'test');
    }
  });
}

notice we added the engine module prefix to support multiple engines.
I hope this will be a part of the ember engine testing API soon

Does this PR fix this?
this.owner.setupRouter()  //  this.owner.setupRouter is not a function

Is there any progress on this? AFAIU, it removes the need for overriding the resolver, which causes issues with mirage in integration tests.
Are we just waiting on https://github.com/emberjs/ember-test-helpers/pull/795 to be completed now?

@amk221

Does this PR fix this?
this.owner.setupRouter()  //  this.owner.setupRouter is not a function

Yes.

We discussed this at todays ember-engines team meeting, and are trying to "reboot" this and get it landed soon.

After our monthly meeting today, we decide to try this possible API to make our tests on Engines simpler, and more likely the usual tests are already written to a normal Ember app or addon. Also once it landed the preloadAssets ( which is unrealistic, give the real flow the engines are loaded on-demand ) will be needless
module('setupEngineTest', function (hooks) {
    setupTest(hooks);
    hooks.beforeEach(async function() {
      this.engine = await loadEngine('my-engine-name');
    });
    test('it exists', function (assert) {
      assert.expect(1);

      let route = this.engine.lookup('route:post.likes');
      assert.ok(route);
    });
  });

  module('setupEngineRenderingTest', function (hooks) {
    setupRenderingTest(hooks);

    hooks.beforeEach(async function() {
      this.engine = await loadEngine('my-engine-name');
    });

    test('should change colors', async function(assert) {
      assert.expect(2);

      // set the outer context to red
      this.set('colorValue', 'red');

      await render(hbs`{{pretty-color name=colorValue}}`, { owner: this.engine });

      assert.equal(this.element.querySelector('div').getAttribute('style'), 'color: red', 'starts as red');

      this.set('colorValue', 'blue');

      assert.equal(this.element.querySelector('div').getAttribute('style'), 'color: blue', 'updates to blue');
    });
  });

/cc: @rwjblue @dgeb @buschtoens

Looks like we need this solution for our upgrade to Ember 3.24, due to some changes in linkToExternal now breaking with the engines not actually set up. Is there something I can do to help push this through and get it committed?

@richgt we need some effort to land this PR first - https://github.com/emberjs/ember-test-helpers/pull/795
Then, finally, we can release this one to Ember Engines. I'm very excited to see it done and make Engines more stable. I'm waiting for @rwjblue to have some time free to jump on that.

I've rebased and updated to the new APIs from @ember/test-helpers. I still need to bump to the latest version (separately from this PR).

@runspired could you please offer some support here?

@villander there are some comments that have not been addressed that @bertdeblock left.

@bertdeblock @btecu I addressed all comments, thank you!
It still breaking because we need @ember/test-helpers: 2.5.0 and the current ember-qunit still using 2.4.2
Also, we need to upgrade all tests here to upgrade the qunit, since we're still using 4.x version
cc: @rwjblue @runspired @SergeAstapov

I think we are ready to rebase to pull in the changes from #797

Merged master to get a new set of CI runs, and bring in Ember 4 compat stuff.

Closes #525

@SergeAstapov @rwjblue @runspired can we get it merged and released?

@villander merged!
@rwjblue could you please release to npm?

The information in this thread wasn't added into the official documentation, was it? Let me know in case I'm missing something, open to add the new test API into it 😄.

@Gorzas that's true buddy. Feel free to open a PR to the documentation repository and I can support you on it 😄


tracing: clean code

Please provide a description of this PR:
follow up: https://github.com/istio/istio/pull/43453#discussion_r1112038814
cc @ramaraochavali

@zirain: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

integ-pilot_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-pilot

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

integ-pilot_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-pilot

gencheck_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

integ-pilot_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-pilot

gencheck_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test gencheck

integ-security-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-security-istiodremote

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

integ-pilot_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-pilot

gencheck_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test gencheck

integ-security-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-security-istiodremote

integ-telemetry_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-telemetry

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

integ-pilot_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-pilot

gencheck_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test gencheck

integ-security-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-security-istiodremote

integ-telemetry_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-telemetry

integ-telemetry-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-telemetry-istiodremote

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

integ-pilot_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-pilot

gencheck_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test gencheck

integ-security-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-security-istiodremote

integ-telemetry_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-telemetry

integ-telemetry-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-telemetry-istiodremote

integ-cni_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@zirain: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

analyze-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test analyze-tests

unit-tests_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test unit-tests

integ-basic-arm64_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-basic-arm64

release-test_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test release-test

integ-ipv6_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-ipv6

integ-pilot_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-pilot

gencheck_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test gencheck

integ-security-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-security-istiodremote

integ-telemetry_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-telemetry

integ-telemetry-istiodremote_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-telemetry-istiodremote

integ-cni_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-cni

integ-security_istio
f8cdb2ce80bd6bf54d1490937413dafeea94770f
link
true
/test integ-security

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Fix getSettings link in documentation

Nice catch. Though I actually had it backwards. The link is correct but the conversion stuff is supposed to be in ClayConfig not Clay


Add "powermock-api-unsupported-cglib"

From<EMAIL_ADDRESS>on December 28, 2010 18:36:03
Add a "powermock-api-unsupported-cglib" module to the API:s that implement a ProxyFrameworkImpl that uses CGLib (copy the one from EasyMock API). This allows people to use unsupported frameworks like JMock without depending on the EasyMock API or creating their own ProxyFrameworkImpl.
Original issue: http://code.google.com/p/powermock/issues/detail?id=305

From<EMAIL_ADDRESS>on April 10, 2011 05:47:37
Labels: -Milestone-Release1.4 Milestone-Release1.6


Remove trusted.gpg.d artifacts

https://github.com/geerlingguy/ansible-role-docker/pull/436 introduced a change to the path where the apt key was placed, and to the associated repository listing in /etc/apt/sources.d/docker.list. We've just run into a problem with this approach, as detailed in the issue I raised, https://github.com/geerlingguy/ansible-role-docker/issues/460.

Ran this against staging-euwest1 and observed that the additional tasks ran, and that they were successful.
TASK [gluckgames.docker : Ensure apt key is not present in trusted.gpg.d] ****************************************************************************************************
changed: [ec2-52-19-166-4.eu-west-1.compute.amazonaws.com]

TASK [gluckgames.docker : Ensure the repo referencing the previous trusted.gpg.d key is not present] *************************************************************************
ok: [ec2-52-19-166-4.eu-west-1.compute.amazonaws.com]


paperwork: fix locale path

Motivation for this change
The path where paperwork was looking for localization files was wrong. This PR fixes this.
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

ping @aszlig ?

@symphorien: Are you sure your change is correct?
https://github.com/jflesch/paperwork/blob/1.1.2/src/paperwork/paperwork.py#L89-L90

Oh, never mind, misread the diff...


Dynamic pages take too long to open

What version of this package are you using?
"next": "^12.3.4",
"next-translate": "^2.0.5",
"react": "^17.0.2",
"next-translate-plugin": "^2.0.5"
What operating system, Node.js, and npm version?
MacOs: 13.3.1
Node: 18
npm v8.19.3
What happened?
I've updated next-translate from version 1.0.5 to 2.0.5. On vercel when deploying the project with the new version next-translate, the dynamic pages like [id].js are very long open the first time. For example:
src/pages/users.tsx
src/pages/users/[userId].tsx
next-translate - compiled page: /users - locale: en - namespaces: translation - used loader: getStaticProps
next-translate - compiled page: /users/[userId] - locale: en - namespaces: translation - used loader: getServerSideProps
There my next.config.js:
const nextTranslate = require('next-translate-plugin');
module.exports = nextTranslate({
  webpack: (config, options) => {
    //....
    return config;
  },
});

middleware.ts
import { NextResponse, NextMiddleware } from 'next/server';

const PUBLIC_FILE = /\.(.*)$/;
export const middleware: NextMiddleware = (req) => {
  const acceptLanguage =
    req?.headers?.get('accept-language') &&
    req?.headers?.get('accept-language')?.slice(0, 2);

  if (
    req.nextUrl.pathname.startsWith('/_next') ||
    req.nextUrl.pathname.includes('/api/') ||
    PUBLIC_FILE.test(req.nextUrl.pathname)
  ) {
    return;
  }

  if (req.nextUrl.locale === 'default') {
    const newUrl = req.nextUrl.clone();
    newUrl.locale = acceptLanguage || 'en';
    return NextResponse.redirect(newUrl);
  }
};

What did you expect to happen?
Dynamic pages open quickly as usual before the update.

Would be great if you create a reproducible example in a repo 😊  in this way we can investigate if this problem is related to the next-translate library or not. Thanks!

I'm having the same issue, for some reason it takes ages to load

Try:

next-translate - version 2.3.0-canary.3
next-translate-plugin - version 2.3.0-canary.6

(requires Next.js 13)


replace the registry with cgr.dev

Signed-off-by: Batuhan Apaydın<EMAIL_ADDRESS>
What type of PR is this?

/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:

Special notes for your reviewer:
Does this PR introduce a user-facing change?

replace the registry with cgr.dev

/ok-to-test


Friends&Foes server crash

Do you have any idea, what can be the cause based on this issue? https://github.com/Faboslav/friends-and-foes/issues/191
Is Canary Class Analysis thing calling my classes on bad environment?

I don't believe you're at fault for this. Looking over the report, log, source of your mod and canary it looks like some other mod overrides Entity#collidesWith and is attempting to use PlayerInfo somewhere in it without checking the side. At least that's my best guess.

This is likely a symptom of all 3 mods being present at the same time.

Since this is not an issue with neruina itself as it handled it in an expected manner, I'm closing this


NL: Fix dates in scatter title

Bug: https://github.com/datacommonsorg/website/issues/2548

Thanks


Acorn trips up on this input, and the regex fallback does too

Describe the bug
I created this acorn issue https://github.com/acornjs/acorn/issues/1191, but I think it's also helpful to make an issue here because the regex fallback in this repository seems to choke as well. Here is the problematic code input, ripped out from the Vite project where I discovered this issue:
import __variableDynamicImportRuntimeHelper from "vite/dynamic-import-helper";
const asyncWrapper = async () => {
  const name = "test";
  console.log("[dynamicA/test.json#message]", (await __variableDynamicImportRuntimeHelper((import.meta.glob("./dynamicA/*.json")), `./dynamicA/${name}.json`)).default.message);
  console.log("[dynamicB/test.json#message]", (await __variableDynamicImportRuntimeHelper((import.meta.glob("./dynamicB/*.json")), `./dynamicB/${name}.json`)).default.message);
};

asyncWrapper();
const _sfc_main = {};

import { mergeProps as _mergeProps } from "vue"
import { ssrRenderAttrs as _ssrRenderAttrs, ssrInterpolate as _ssrInterpolate } from "vue/server-renderer"

function _sfc_ssrRender(_ctx, _push, _parent, _attrs, $props, $setup, $data, $options) {
  _push(`<div${
    _ssrRenderAttrs(_mergeProps({ class: "whatever" }, _attrs))
  }>${
    _ssrInterpolate(new Date())
  }</div>`)
}

import { useSSRContext as __vite_useSSRContext } from 'vue'
const _sfc_setup = _sfc_main.setup
_sfc_main.setup = (props, ctx) => {
  const ssrContext = __vite_useSSRContext()
  ;(ssrContext.modules || (ssrContext.modules = new Set())).add("entrypoints/App.vue")
  return _sfc_setup ? _sfc_setup(props, ctx) : undefined
}
import _export_sfc from 'plugin-vue:export-helper'
export default /*#__PURE__*/_export_sfc(_sfc_main, [['ssrRender',_sfc_ssrRender],['__file',"/Users/aryse/Projects/open-source/vite-ssr-issue-vue-sfc-dynamic-import/entrypoints/App.vue"]])

I'm not sure why acorn has a problem with this, but after it raises an error, causing the regex fallback to engage as a replacement, the final output I get is this:
import __variableDynamicImportRuntimeHelper from "                          ";
const asyncWrapper = async () => {
  const name = "    ";
  console.log("                            ", (await __variableDynamicImportRuntimeHelper((import.meta.glob("                                                                                "/Users/aryse/Projects/open-source/vite-ssr-issue-vue-sfc-dynamic-import/entrypoints/App.vue"]])

Which is obviously not correct.
Reproduction
https://github.com/acornjs/acorn/issues/1191
System Info
System:
    OS: macOS 12.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 146.80 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.19.0 - ~/.volta/tools/image/node/16.19.0/bin/node
    npm: 8.19.3 - ~/.volta/tools/image/node/16.19.0/bin/npm
  Browsers:
    Chrome: 109.0.5414.119
    Safari: 15.6

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

Alright I think I found more precisely what the issue is.
In the output above there is a part like import.meta.glob("./dynamicA/*.json"). Later, near the end, there is a comment like /*#__PURE__*/. It seems that stripLiteralRegex thinks the ending */ in the #__PURE__ comment goes with the /* in the import.meta.glob pattern. Here's a minimal reproduction:
import { stripLiteralRegex } from "strip-literal";
console.log(stripLiteralRegex("'./dynamicA/*.json' /*#__PURE__*/"));

The output of console.log is './dynamicA.
This explains the strange behavior I was seeing in my Vite project. The breakdown of how I understand the problem is as follows:

Due to the Acorn bug I opened here, the output above incorrectly raises a syntax error even though there is none.
After falling back to the RegEx version, the issue I describe here causes the output to be totally wrong.
As a result, the second import.meta.glob gets incorrectly omitted by stripLiteralRegex, and my code throws a __vite_ssr_import_meta__.glob is not a function error as I describe here.


Making the carousel dynamic

Is your feature request related to a problem? Please describe.
In the e-commerce project, the carousel in the hero section appears to be static, which can negatively impact the overall user experience. To enhance user engagement and improve their browsing experience, it is advisable to implement a dynamic carousel that displays moving images or content
Describe the solution you'd like
I can make the carousel dynamic by modifying the javascript
Describe alternatives you've considered
Using bootstrap carousel

@TusharKesarwani  can you assign this to me


all: add ci job to close stale issues and prs

What
Add a CI job to comment on stale issues and pull requests after 30 days of inactivity and close them 30 days after that, so 60 days total.
Why
There are a lot of stale issues. We've had success with using this same pattern to clean up the stellar-protocol repo.
I've noticed that @2opremio routinely checks in on long lived pull requests to see if they should be closed. We don't have a huge amount of open pull requests so there isn't as big of an issue with them as we have with issues, but checking in on long lived pull requests is something a bot can do rather than it being on a human on the team.
Known limitations
In the stellar-protocol repo we had some labels that clearly signaled an issue shouldn't be closed, and so we configured the stale checker to ignore those issues. In this repo there is no clear label that signals that issue should stay around, so there are no issues/prs exempt from the check.

I'd rather not do this. We're aware that we need to do a better job of triaging our issues on this repo. It's something we're ramping up on as we hire more people. Auto-closing issues is not helpful when there is backlog work here that we would actually like to do.


latest_stamps parameter in Python Module

Hi everyone!
Recently I've been using download_profiles() instead of download_profile() since it was deprecated since version 4.1.
In download_profile(), it would save the profile ID .file into the directory, however with download_profiles() it does not. Thus, username changes are not detected and, the directory is not renamed. I understand that the latest_stamps function saves [profile-ids] but I am unsure how to use the latest_stamps (Optional[LatestStamps]) parameter. Do I need to create a latest-stamps.ini file?
Similarly, I trailed --latest-stamps in the CLI version instead, and it does create a latest-stamps.ini file. However, I'm hesitant to use latest stamps since when a profile rename occurs it does not rename the directory, instead it creates a new one as seen in issue https://github.com/instaloader/instaloader/issues/1276.
Thank you.
L = instaloader.Instaloader()

L.download_profiles(profiles=[profile], latest_stamps=None)

Can confirm issue #1276 is still an known bug.


CAMEL-16639: Use symbolic links

With Antora 3 we can now use symbolic links within the git repository, and we no longer need to copy files over to the docs directory. This is a major refactor of how the Gulp is configured not only for creating symbolic links but also removing duplicate functionality and utilizing a configuration object to generate Gulp tasks from instead of manual task generation.
Having the configuration now effectively declarative (look for details in the gulpfile.js) it should be easier to tweak and maintain how the content is managed in the docs directory.
Other relevant changes also included as they were part of the refactoring:

images are now stored in ../images instead of ../assets/images
templates for nav.adoc files have a uniform naming
a summary document (dsl/src/main/docs/dsl.adoc) was added to help group DSL documents in the other category
adds symbolic links for JSON Camel metadata documents, currently disabled (see NOTE in gulpfile.js)

This work takes is largely inspired by the work by David Jencks on #6040
This PR also contains two other commits for fixing grouping attribute. And to keep the PR as small as possible doesn't include a regen commit which would apply the changes in the Gulp build.

I've converted this to draft, I need to investigate why the website build fails with the broken xref's. Could be on my end, but just to make sure this doesn't break the website build.

I'm having quite a bit of weird issues with this, when running locally, that is pointing antora-playbook.yml to my local git repository two issues occur:

_attachments/Hohpe_EIP_camel_20150622.zip is a directory not a ZIP file
source points to my GitHub fork not referenced in the paybook

[17:07:09.934] INFO (asciidoctor): possible invalid reference: MicrometerComponent-counter
    file: docs/components/modules/ROOT/pages/micrometer-component.adoc
    source: https://github.com/zregvart/camel.git (refname: camel-2.x, start path: docs/components)
EISDIR: illegal operation on a directory, open '.../camel-website/documentation/components/latest/eips/_attachments/Hohpe_EIP_camel_20150622.zip'

So I've pushed to a test branch, with regenerated documentation (i.e. I ran yarn gulp in docs), and pointed the playbook to that (instead of main), and that seems to work without issues (still need to run checks).
So unless I'm doing something wrong, and I can't find what, this seems to cause issues when working locally, which would point to a bug in Antora/isomorphic-git?

Sorry, I should have mentioned those problems.

I have to run rm core/camel-core-engine/src/main/docs/modules/eips/attachments/* to get a build against local  sources to succeed. The build works fine against remote repos.
There's a problem with logging that doesn't reference the local worktree source, instead it references the origin repo. I mentioned this one on Zulip but haven't seen a response. https://antora.zulipchat.com/#narrow/stream/282400-users/topic/.5BAntora.203.20a.2E9.5D.20Logger.20appears.20to.20specify.20the.20wrong.20source

Thanks for the hint @djencks, seems that inability to build from a local branch other than main is a preexisting issue. I've tested on a copy of main, i.e. without these changes and received the same error.
I think this is now ready to be merged. I'll leave it open for a bit if anyone else wishes to provide some feedback.

I'm amazed by this naming trick! I still don't understand why it works... What would you think of encapsulating it in a method, like

JavaScript has some interesting properties, I was also trying to create a function that would make this a bit readable, but did not succeed. This is how I tested:
const name='xyz'
const { [name]: f1 } = { [name]: () => void 0 }
const { [name]: f2 } = { [name]: function() {} }

const lambda = (n, f) => {
  const { [n]: ret } = { [n]: f }
  return ret
}

const func = function(n, f) {
  const { [n]: ret } = { [n]: f }
  return ret
}

console.log(f1)
console.log(f2)
console.log(lambda('xyz', () => void 0))
console.log(lambda('xyz', function() {}))
console.log(func('xyz', () => void 0))
console.log(func('xyz', function() {}))

When run it gives:
[Function: xyz]
[Function: xyz]
[Function (anonymous)]
[Function (anonymous)]
[Function (anonymous)]
[Function (anonymous)]

So that halted that effort...

You have to construct the lambda in the closure in order for the name to stick (at least that's my interpretation of the behavior).  So my first suggestion
function nameTask (name, task) {
  const { [name]: x } = { [name]: () => task() }
  return x
}

works because of the new lambda () => task() in the function.  After some more consideration, I like this better:
function nameTask2 (name, task, args) {
  const { [name]: x } = { [name]: () => task(...args) }
  return x
}

called like
    const c = nameTask2(`clean:asciidoc:${type}`, clean, [asciidoc.destination, asciidoc.keep])

or maybe
    allTasks.push(series(
      nameTask2(`clean:asciidoc:${type}`, clean, [asciidoc.destination, asciidoc.keep]),
      nameTask2(`symlink:asciidoc:${type}`, createSymlinks, [asciidoc.source, asciidoc.destination]),
      nameTask2(`nav:asciidoc:${type}`, createNav, [asciidoc.destination] )
    ))

I included the suggestion from @djencks and the changes resulting from running the build in docs. I'm going to merge this and keep an eye on the website build.


Create Package not putting files on desktop

Description of Problem or Question
Tried updating my scenario, A Little Night Music, today, but when I press "Create Package" in the editor, nothing happens.  No error, no files/folders placed on desktop.
I manually zipped the files, renamed to .Valkyrie, and uploaded to my repository on GitHub.  I incremented the version number (GUID?) in the existing copy of ALittleNightMusic.ini which I had, since I didn't know how to create that file manually.
Unfortunately, my scenario doesn't show the download icon in the scenario explorer, so it seems that Valkyrie is not recognizing that I have uploaded a new version on GitHub.
Valkyrie Version
2.4.03
Attach Save, Quest or Scenario
Log File:
%LOCALAPPDATA%Low\NA\Valkyrie\output_log.txt
Saves:
%appdata%/Valkyrie/MoM/Save
%appdata%/Valkyrie/D2E/Save
Quest:
%appdata%/Valkyrie/D2E/Editor
Scenario:
%appdata%/Valkyrie/MoM/Editor

Forgot - I'm on Windows 10, 64-bit.  I even tried running Valkyrie as an administrator, but Create Package is still not putting the files on my desktop.

I can't reproduce this.
Can you please upload a zip of the files you are trying to package?

Solved.  It was Windows Defender "Controlled Folder Access" being turned-on.  I turned it off and the Create Package function is working properly again.  Sorry :-)


Proposal for more RESTful URL Semantics for SBOM Retrieval

The current URL semantics for retrieving a BOM uses query parameters:
bom-retrieval-url    = system-url "?" bom-identifier-query
bom-identifier-query = "bomIdentifier=" bom-identifier
bom-identifier       = *( pchar / "/" / "?" )
                        ; an identifier that uniquely identifies a BOM
                        ; pchar as defined in RFC3986

However, in accordance with RESTful principles, using the path to represent resources is preferred over query parameters, especially when a resource can be uniquely identified by a specific parameter.
To better adhere to RESTful design principles, I'd like to propose updating the URL semantics as follows:
bom-retrieval-url    = system-url "/" bom-identifier
bom-identifier       = *( pchar / "/" / "?" )
                        ; an identifier that uniquely identifies a BOM
                        ; pchar as defined in RFC3986

Where the bom-identifier directly follows the system-url, making the URL structure clearer and more intuitive.
The current design for SBOM submission already adheres to RESTful principles. Specifically, SBOMs are submitted using a POST request to:
bom-submission-url = system-url

By modifying the retrieval URL, we can achieve consistent RESTful design across both submission and retrieval operations.
Use of Query Parameters for Filtering:
While proposing to change the URL semantics for retrieval, it's worth noting that query parameters are still valuable and can be used on the system-url for filtering mechanisms. For instance, when searching or narrowing down results based on certain criteria, query parameters can efficiently convey this information. The distinction is that for direct and unique resource identification, as with the bomIdentifier, the path component is preferable in line with RESTful design.

I second this proposal, since it only requires a server capable of HTTP Content Negotiation.

@stevespringett what would be the best place to start this discussion?

I'm fine with this approach, at least for artifact retrieval anyway. There will be additional APIs that provide data that will not be artifact based however.
@coderpatros thoughts?

This was actually my initial approach, and my personal preference. But I ended up going with a query string parameter as I wasn't sure how easy folks would find correctly encoding path segments. Especially with SPDX document identifiers. Where as, in my experience, developers regularly need to encode query string parameters, and languages/frameworks tend to provide helpers for that. Either way I'm happy to go with the general consensus on this one.

Since we are reworking the API and providing an OpenAPI spec we can certainly go for more restful. We are working on a new spec proposal - participate in the group or stay tuned :-)


HSEARCH-2999 Upgrade to Elasticsearch 5.6.7

https://hibernate.atlassian.net/browse/HSEARCH-2999

We should also update the Elasticsearch test version; actually that's probably the most important part of the upgrade: from what I saw, the Java REST client rarely changes.
I'll update it and push a commit.

thanks, apparently I missed that at the previous round as well.
Merged.


Add feature: Provider can Stake

Implementation of feature to allow staking tokens to selected Provider

[x] Add tests for staking

FYI, Cancel Stake doesn't hide the form, but since we're changing how all that's done in my PR, I don't think you should bother fixing it.

That's strange it's working for me. I will note to add a test for that too.


chore: update examples dependencies

Codecov Report

Merging #56 (cd0f020) into master (53f1a22) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master       #56   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           29        29
  Lines          291       291
  Branches        32        32
=========================================
  Hits           291       291

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 53f1a22...cd0f020. Read the comment docs.


Wiremock for @QuarkusTest and @QuarkusIntagrationTest simultaneously

Hello.
I would like to ask how can I handle Wiremock usage simultaneously for both: @QuarkusTest and @QuarkusIntegrationTest.
Here is simple reproducer: GITHUB
I think that my case is quite simple and straightforward. I'd like to understand how should I properly set properties for native test in my application.properties files (main & test).
Please use wiremock branch in provided reproducer -> then go to test/kotlin/org/acme/GreetingResourceTest and check testHelloEndpoint(). As you can see here, I am registering my client's endpoint for wiremock which url matches the url in ExampleClient.class. So far everything is easy to understand.
This test with @QuarkusTest annotation works properly. There is property
quarkus.rest-client."org.acme.client.ExampleClient".url=http://localhost:${%dev,test.quarkus.wiremock.devservices.port}
set in test/resources/application.properties so wiremock is able to determine correct url for the test.
My issue occurs when I run @QuarkusIntegrationTest (check native-test dir).
Since native env doesn't look for test properties, to make this test passes I had to set exactly the same property as above one in main/resources/application.properties file but unfortunately this approach is obviously bad one (guess I don't have to write why).
So my question is, how can I overcome this problem properly so both tests (native + normal) will use correct url so in result wiremock will be able to determine client's path as expected.
I realise that most probably it isn't any bug but rather my lack of understanding of how native tests work.
Thank you for any advice/feedback for my issue in advance. :)

Not stale


Add Market expiration to market details

Check font size and spacing in designs
Desktop: https://www.figma.com/file/6y4nvjfeVZwzwKcoXB0neq/Simplified-UI?node-id=93%3A17660
Mobile: https://www.figma.com/file/6y4nvjfeVZwzwKcoXB0neq/Simplified-UI?node-id=292%3A5428

Needs' Market Expiration:' and comma after the day (see above)

Needs' Market Expiration:' and comma after the day (see above)


Authz doesn't work with some osmosis-specific messages

Summary of Bug
Trying to grant a generic authorization via authz doesn't work for /osmosis.lockup.MsgLockTokens. Other messages may potentially be affected as well.
Version
Current Production (osmosisd 7.0.3)
Steps to Reproduce
export $granter=osmo...
export $grantee=osmo...
The following auth grant tx works:
osmosisd tx authz grant $granter generic --msg-type=/osmosis.gamm.v1beta1.MsgJoinSwapExternAmountIn --from=$grantee
The following fails:
osmosisd tx authz grant $granter generic --msg-type=/osmosis.lockup.MsgLockTokens --from=$grantee
An example of the failing transaction can be seen in https://www.mintscan.io/osmosis/txs/C407AA9A2631A6A159EDA5632F761A096DCBC8ABDDF0AC2CF0257B2C6D81D718
The grenerated transaction (with the addresses redacted) is:
{"body":{"messages":[{"@type":"/cosmos.authz.v1beta1.MsgGrant","granter":"osmo...","grantee":"osmo...","grant":{"authorization":{"@type":"/cosmos.authz.v1beta1.GenericAuthorization","msg":"/osmosis.lockup.MsgLockTokens"},"expiration":"2023-03-13T19:21:27Z"}}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"350000","payer":"","granter":""}},"signatures":[]}

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Ah I found the bug
All of our modules have to register a message server. Here is how its done for staking: https://github.com/osmosis-labs/cosmos-sdk/blob/v0.45.0x-osmo-v7/x/staking/module.go#L138
Here is where its not done for lockup (and presumably more of our modules): https://github.com/osmosis-labs/osmosis/blob/main/x/lockup/module.go#L144

FYI "/osmosis.superfluid.MsgLockAndSuperfluidDelegate" also doesn't work, producing the exact same error.

Lockup module, superfluid module and creating gauges won't work at the moment.
Amm swaps and LP'ing should work right now
Should get fixed in v8, not much we can do to get it fixed until then unfortunately :(

If this gets fixed in v8, what is the timeline then? 2-4 weeks. Is this just another sprint?

v8's targetted to get on chain first week of April at the moment. The big goal is:

Stability improvements to Superfluid
larger refactor of the AMM module
Stableswap
Further IAVL stability

And then bug fixes. (The PR I just opened should fix this on main, v8 is just the next upgrade on chain that'll happen)

Thanks for the quick fix!

fyi.
This issue also affects cosmwasm.

Why does this matter if it affects cosmwasm? Does this delay the fix?

Not yet unfortunately, mainnet upgrade hasn't happened yet

Yeah I think you can plan for it landing by then. The v8 release is still under development unfortunately, but its written in that erlease

Thanks that is helpful. Last question, how do you track the v8 release and whether it is deployed or not? Is there some place to check this? The v8 is huge. Includes your stableswap, superfluid stability, and new AMM module lol... that is a lot

You can track progress here! #1141
We;re working on keeping that more up to date. The signal for it being ready is going to be governance proposal on Osmosis + github releases, etc


An object property for referencing taxonomic units from specifiers

Proposed term: references_taxonomic_unit (object property)
Definition: A taxonomic unit referenced by a specifier. A specifier might reference multiple taxonomic units, any of which can be matched.
Domain: Specifier
Range: TU (obo:CDAO_0000138)
See also: scratch ontology, PHYX context
Competency questions:

Which taxonomic units does a particular specifier refer to?

See comment on #8 re: supporting competency question(s). Isn't there references_TU already in CDAO, so that we could simply import that term?

I've added a competency question -- let me know what you think! We could use cdao:represents_TU instead, but that term has an explicit domain of cdao:Node -- so using it would imply that a Specifier is also a Node, which doesn't make sense to me. Could we somehow include it without including that implication?

I've added a competency question -- let me know what you think!

Good start, but it doesn't necessarily show (yet?) why we need this property. For example, wouldn't we be able to get the answer by simply querying which objects of type cdao:TU are linked to the specifier subject, regardless of property?

We could use cdao:represents_TU instead, but that term has an explicit domain of cdao:Node -- so using it would imply that a Specifier is also a Node, which doesn't make sense to me.

Right. I think that's an issue to be reported to the CDAO tracker.
Are you saying that if that were fixed in CDAO, there would be no hindrance to reusing the CDAO property?

Could we somehow include it without including that implication?

Yes, at least temporarily. I think it may not be viable anyway to import CDAO as a whole as it's now (because it drives up the required expressivity profile), so we'll probably at least in the interim end up extracting a subset of axioms from CDAO.

Good start, but it doesn't necessarily show (yet?) why we need this property. For example, wouldn't we be able to get the answer by simply querying which objects of type cdao:TU are linked to the specifier subject, regardless of property?

I'm not sure I understand what you mean. If this isn't the property used to link Specifiers to cdao:TU, then what is? Or do you mean that my competency question should be more specific? I've added two new competency questions to the issue that might help with this -- let me know what you think!

We could use cdao:represents_TU instead, but that term has an explicit domain of cdao:Node -- so using it would imply that a Specifier is also a Node, which doesn't make sense to me.
Right. I think that's an issue to be reported to the CDAO tracker.

Are you saying that if that were fixed in CDAO, there would be no hindrance to reusing the CDAO property?

Actually, yes. I think node identification and specifier identification are similar enough that we could refer to them in the same way.

Could we somehow include it without including that implication?
Yes, at least temporarily. I think it may not be viable anyway to import CDAO as a whole as it's now (because it drives up the required expressivity profile), so we'll probably at least in the interim end up extracting a subset of axioms from CDAO.

Sounds good! I've modified this issue to incorporate cdao:represents_TU rather than creating our own term. If we do this and it works successfully, we could open an issue with them to broaden the range of cdao:represents_TU.

In light of the conclusion from recent discussions that at least for purposes of phylogenetic clade definitions there is no discernible difference between a specifier and a referent to a taxon concept, I would argue the concern about the domain constraint of cdao:represents_TU is no longer pertinent, since there is no good reason not to link directly from a node to the cdao:TU that it represents. Therefore this should be closed.

Agreed! Closing.


Spike: support client-go auth-providers

Background
We now believe that the best way to support authentication against all different types of Kubernetes clusters is to use $KUBECONFIG. The explore describes the different types of authentication $KUBECONFIG supports. We believe we can support all of them (except the deprecated ones).
Questions
Among the different auth-provider configs, OIDC is the only one which is not getting deprecated. We believe we can support it, as it stores the ID and refresh tokens we're used to, but we want to make sure we can do this fully. In particular, we want to confirm that we can refresh the token when necessary. Obtaining the token is out of scope, as it is assumed that the user has already done it at this point.

Instead of trying to support the oidc auth-provider in particular, today we managed to find a way to support all auth-providers generically!
auth-providers implement an AuthProvider interface which has a WrapTransport method, taking an http.RoundTripper and wrapping it. We found this to be remarkably similar to the ConnectionWrapper interface in the CF CLI! The ConnectionWrapper wraps a Connection, which has a very similar interface to http.RoundTripper, so we were able to implement ConnectionRoundTripper, an adapter from Connection to RoundTripper. This could then be wrapped with AuthProvider.WrapTransport() and then used!
This proved to work with the gcp auth-provider and we believe it would work with all of them, including oidc. This approach allows to reuse a lot of code, including persisting tokens in $KUBECONFIG, which needs to be protected by locks to avoid races.
At the end of the day, we looked at using a similar approach for exec plugins, but we had no luck. The exec plugins modify the TCP configuration of the HTTP client to be able to inject client certificates, and getting those out seems complicated. We might give this a second shot but our previous approach, invoking the executable directly, looks simpler. On the other hand, the client-go implementation comes with a lot of interesting functionality (e.g. caching) that we don't have (yet).

Update on re-using the client-go exec authenticator code
It is possible to use the code from exec.go. The interface is different from the auth-provider code we borrowed above. In this case, we must invoke UpdateTransportConfig passing a *transport.Config that we control.
This does two things. First it sets the TLS.GetCert property on the transport config to grab the certificate, if any, from the credentials plugin. Secondly it sets up a wrapper function so a RoundTripper can be wrapped by one providing the bearer token from the credentials plugin.
Caching and execution of the credentials plugin is taken care of, so we don't have to worry about that. If the user has to login from the GetCert() trigger, a second login will not be required when getting the bearer token.
We can use the *transport.Config object to retrieve the client certificate, if any, by calling GetCert(). Unfortunately, the PEM cert and key have already been parsed and converted into an x509.Certificate. We need them back in PEM format to configure the k8s client, so there is the messy process of reversing that transformation.
We can also invoke the WrapTransport method on the *transport.Config object to use the ConnectionRoundTripper built for the auth-provider work. This will add the bearer token if the credentials plugin returned one, and if the authorization header is not already set.
So overall, this appears quite reasonable. The code is slightly verbose given the string of potential errors returned, but using *transport.Config doesn't feel that hacky!

Note that we can test the client cert part of the credentials plugin by using a pinniped configuration. And to test an credentials plugin that produces a bearer token, targeting a GKE cluster and switching the config to use https://github.com/sl1pm4t/gcp-exec-creds works.


before feature

My artillery script has a 'before' feature which basically does the jwt authentication once and then runs the scenario with parsing of the token in the header. This works well in artillery.
However when I run the same script using serverless artillery this 'before' feature isn't being recognised. Hence JWT Token is not being parsed into my scenario section of the headers. I understand 'before' is a new feature in artillery -- how do I get serverless artillery to handle this?

I'd like to be able to use this Artillery feature as well....


bzip2 build failure

OS:windows
Compiler: msvc

error:
-- Using cached D:/vcpkg-master/downloads/bzip2-1.0.6.tar.gz
-- Cleaning sources at D:/vcpkg-master/buildtrees/bzip2/src/1.0.6-8838f21f8e.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source D:/vcpkg-master/downloads/bzip2-1.0.6.tar.gz
-- Applying patch fix-import-export-macros.patch
-- Applying patch fix-windows-include.patch
-- Using source at D:/vcpkg-master/buildtrees/bzip2/src/1.0.6-8838f21f8e.clean
-- Configuring x64-windows-static
-- Building x64-windows-static-dbg
-- Building x64-windows-static-rel
-- Fixing pkgconfig
-- Acquiring MSYS Packages...
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
Command failed: D:/vcpkg-master/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc -c "pacman -S --noconfirm --needed pkg-config"
Working Directory: D:/vcpkg-master/downloads/tools/msys2
Error code: 1
See logs for more information:
D:\vcpkg-master\buildtrees\bzip2\msys-pacman-x64-windows-static-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_acquire_msys.cmake:127 (vcpkg_execute_required_process)
scripts/cmake/vcpkg_fixup_pkgconfig.cmake:281 (vcpkg_acquire_msys)
ports/bzip2/portfile.cmake:51 (vcpkg_fixup_pkgconfig)
scripts/ports.cmake:79 (include)
buildtrees/bzip2/msys-pacman-x64-windows-static-err.log:
error: msys: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
error: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" could not be looked up remotely
error: database 'msys' is not valid (invalid or corrupted database (PGP signature))

Related to #12288 I believe.

I run this command:
D:/vcpkg-master/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc -c "pacman -S --noconfirm --needed pkg-config"
and here is the error:
bash: pacman: command not found

I edit /etc/pacman.conf,and let SigLevel be Never,then it been corrected!

Related PR, which fixes these key issues: #12467

I edit /etc/pacman.conf,and let SigLevel be Never,then it been corrected!

This worked for me, though I gather it means signatures will not be verified. The file is in vcpkg/downloads/tools/msys2/msys64/etc/pacman.conf

I edit /etc/pacman.conf,and let SigLevel be Never,then it been corrected!

This worked for me, though I gather it means signatures will not be verified. The file is in vcpkg/downloads/tools/msys2/msys64/etc/pacman.conf
works for me


⚠ Bofrost.be has degraded performance

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

HTTP code: 200
Response time: 2517 ms

Resolved: Bofrost.be performance has improved in 0e66b94.


Adjust Like/Dislike -- include an option to request a response to a comment and a way to see that stats

We recently received a "dislike" with a valid comment that I would have liked to respond to, but there was no email address available.  As well, it would be nice for users to be able to just Like/Dislike without getting a "make a comment" box that they have to cancel.  I recommend the flow be:

Offer the "Like/Dislike" as today.
On click, record a record of the click -- like/dislike and date/time.
Change the Like/Dislike to "Submit a comment/suggestion" and have that as the footer for the remainder of the session.  This would prevent submitting multiple like/dislikes in a session.
If they click to submit a comment/suggestion, take them to the "normal" request page that includes the being able to make a comment/suggestion with an email address so we can respond.

We also need to document how we can see the like/dislike history.  Perhaps a secret URL that we can bookmark that shows a summary (all time, last year, last 30 days, last 7 days) with counts?

Sure, from my understanding the like/dislike data is just sent via email so we will likely need to either a) add a new endpoint to aries VCR to store and query the data or b) use another sort of telemetry service to log likes/dislikes and make them accessible. Do you have any preference for either option @swcurran?

My own preference is to store the data and query it later, as I don't understand the long term history we would get with using, for example, the API Metrics for this.  I feel like that wouldn't adequately track the data we would want.
@WadeBarnes -- do you think the API Metrics are sufficient for this or does it make sense to record the data in the database.

We can see the feedback endpoint called in the API metrics (see screenshot below).  The metrics only track the number of calls and the names of any parameters used with the calls, but not the value used for a given parameter.  We could use the metrics to track like/dislike by calling the endpoint with either a like or dislike parameter with an arbitrary value.  That said the endpoint itself then becomes a no-op that relies on a metrics implementation to be put in place for it to be of any use to anyone.
I think storing the data in the database and having a way to retrieve the information would be the better option, but then we'd need to determine a way to limit abuse.

Regards the abuse.  We can address it in the Web App context -- but is your concern the exposed API -- that someone could create a bot to hit the API continuously?  Is there anyway to prevent that?

My concern is the API.  Perhaps rate/ip limiting.

@wadeking98, please work with @WadeBarnes and @amanji to settle on a solution for the open issue and then get this implemented.
Priority for cleanup.

just to clarify, we need the ability to query like/dislike metrics but not the comments/suggestions. We need to control for abuse in the like/dislike functionality but we aren't concerned with the comment functionality since that goes to email instead of the database. Is this correct @swcurran ?

Yes.  We are basically looking for two features that are linked.  Like/Dislike flags for people to vote, and access to that information. From either, the ability for a person to submit a tracked comment via email, as we do for other features.

@amanji has found another solution that is worth exploring.  It would only impact the frontend and use the GDX analytics to collect the statistics.  Since the orgbook-bc-client and the GDX analytics are both BC specific implementations this makes sense, we're not imposing BC's implementation on the rest of the community.  It might require he GDX team to update the reporting, but there may also be some additional beneficial information collected along the way.


updates readme and fix typo

I have been studying this repository for a long time, and whenever I come across a typo, I fix it.
I discovered 2 issues in a total of 2 files. Then I merged them together.
The code quality is exceptionally high, so sincerely hope my PR can help make this repository more standardized.

@miles-six thanks for the suggestions — could you take a look at the conflicts, please?


UI trading exchange

I have one question, is this the library used to build this website? The documentation is not clear but I'm really interested

Yes, this is a React component library

Yes, this is a React component library.Because I am usually very busy, I sometimes overlook some information. I apologize for that.

Yes but which one is it?

Yes.the website all common components are here.

Yes.the website all common components are here.

yeah i can see the website but what libraries are you using? I'd like to use it for a personal project. But I need the library of documentation for the components

You can install blofin-ui in Nextjs/React. You can use the clone project. Run yarn storybook to view the document. Here are examples of all components

can you please send me the links? I didn't find any documentation or library/components I could install

If there are any issues, feel free to contact me on Telegram: https://t.me/leo1445.

This is the link to the npm package, and this repository contains the source code


[edit] Dynamic library another pro

Link: https://zakuarbor.github.io/blog/building-code/
Description:
If changes to library, no need to recompile entire project.

implied in Easy to update if a bug exists


In docker toolbox getting ECONNREFUSED error and registration failure

HI @dshuffma-ibm ,
i am trying to run marbles application using docker toolbox option in local.
While executing the gulp command in the prompt getting the ECONNREFUSED error and registration failure message.
My docker-compose.yml file looks like:
membersrvc:
image: hyperledger/fabric-membersrvc
command: membersrvc
vp0:
image: hyperledger/fabric-peer
environment:
- CORE_PEER_ADDRESSAUTODETECT=true
- CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375
- CORE_LOGGING_LEVEL=DEBUG
- CORE_PEER_ID=vp0
- CORE_PEER_PKI_ECA_PADDR=membersrvc:7054
- CORE_PEER_PKI_TCA_PADDR=membersrvc:7054
- CORE_PEER_PKI_TLSCA_PADDR=membersrvc:7054
- CORE_SECURITY_ENABLED=true
- CORE_SECURITY_ENROLLID=test_vp0
- CORE_SECURITY_ENROLLSECRET=MwYpmSRjupbT
links:
- membersrvc
command: sh -c "sleep 5; peer node start --peer-chaincodedev"
my mycreds_docker_compose.json file looks like:
{
"credentials": {
	"peers": [{
		"api_host": "localhost",
		"api_port": 7050,
		"type": "peer",
		"id": "vp0"
	}],
	"users": [{
		"enrollId": "bob",
		"enrollSecret": "NOE63pEQbL25"
	}],
}

}
Can you please explain what are all the configuration changes need to do in the following files app.js, setup.js, docker-compose.yml and mycreds_docker_compose.json.

have you tried the new documentation? (its brand new, posted it yesterday)
https://github.com/IBM-Blockchain/marbles/blob/master/docs/use_local_hyperledger.md
if you are using docker toolbox then i'm assuming you are on windows. therefore the api_host param is not correct, it won't be on localhost. its probably on <IP_ADDRESS>. when you open the docker toolbox command prompt it will be there at the top:

closed inactivity


changes to handle new globus tokens

Couple points:

Is this backwards compatible with the old globus token format?  Some are still in circulation and they have a full year to expire.  I think there is still a way to create new ones (older version) in globus.

Does this require a change in the AUTH_GLOBUS_TOKEN_URL config value?  The current default setting is the correct url for the old token format.

Can you please send this pull request to develop branch first.  I like to do function and integration testing with whats in develop branch before sending to master.


Update Docs for Zabbix

I see references in zabbix.py for a zbx_key param but no zbx_item, so as best I can tell this is the correct fix. But I have no Zabbix system to verify so I'm expecting the submitter has verified this change.

I see references in zabbix.py for a zbx_key param but no zbx_item, so as best I can tell this is the correct fix. But I have no Zabbix system to verify so I'm expecting the submitter has verified this change.

Currently, Zabbix does not work properly with the latest ElastAlert. We are planning to issue a pull request for bug fixes, so we will also make a pull request with the operation check result at that time.

Currently, Zabbix does not work properly with the latest ElastAlert. We are planning to issue a pull request for bug fixes, so we will also make a pull request with the operation check result at that time.

Share what you learned about schema.yaml.
If the key and data type are described in schema.yaml, it seems that the data type is checked when actually executing the alert notification. For example, if you enter a number that is a string and is not enclosed in single or double quotes, an error will occur. Therefore, it seems that there is no problem even if a key that does not exist is written. So it seems that there was no problem even if there was a zbx_item that did not exist until now.


test-branch/execute-job/quoted-authorization/83ab67fa-4e41-4f8d-91d5-74d8090a20ad

PR for testing fbc752ae88a4116144af0c97957c2b15232fb33e

/canonical/self-hosted-runners/run-workflows fbc752ae88a4116144af0c97957c2b15232fb33e


[mvk-error] SPIR-V to MSL conversion error: Argument buffer resource base type could not be determined.

After I updated to the latest version of MVK I git the following error:
[mvk-error] SPIR-V to MSL conversion error: Argument buffer resource base type could not be determined. When padding argument buffer elements, all descriptor set resources must be supplied with a base type by the app.
[mvk-error] VK_ERROR_INVALID_SHADER_NV: Fragment shader function could not be compiled into pipeline. See previous logged error.`
The shader is written in hlsl, here are the relevent inputs:
[[vk::push_constant]]
struct rx_pushConstants {
uint instanceRefIndicies[6];
} rx_pushConstants;
[[vk::binding(0, 0)]] ByteAddressBuffer   rx_staticResBlocks;
[[vk::binding(1, 0)]] ByteAddressBuffer   rx_dynamicResBlocks;
[[vk::binding(2, 0)]] Texture2D			rx_textures[];
[[vk::binding(3, 0)]] SamplerState		rx_samplers[];
I use dxc to compile hlsl to spirv and MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS = 1
SpirvCross may does not like the ByteAddressBuffer? Is there a way around this problem without breaking my code?
Thanks for your help!

Looks like a SPIRV-Cross issue. Please repost this to the SPIRV-Cross issues list.

I see the same problem (plus others related to descriptor indexing) on an old Intel MacBook running Catalina with an Intel HD Graphics 4000 iGPU.   I believe this old machine is running Metal 1.  The same code runs just fine on more modern Intel/AMD and Apple Silicon Macs running Ventura with Metal 2.
I can force the code to run on the old machine by setting MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS = 0, but with some graphics artifacts (not sure if related).  I am curious about what GPU h/w, macOS, and Metal versions you are targeting to see the problem.  Could this be a SPIRV-Cross or MoltenVK issue on older environments?

The latest 1.3.275.0 is now working for me.

Had same issue, updating the Vulkan SDK to 1.3.275.0 did solve the issue for me as well


Update DAWG-PAC analysis resource page

Add link to notebook analyzing rat phenotypic data, including summary statistics, correlation analysis, statistical testing, and regression models.

Merged changes to default branch.


Move TCCP card sorting dropdown below filters' expandable

To increase the sorting dropdown's visibility, move it outside the expandable. To accommodate no-JS users, it's moved via JS instead of at the template level.
The load event listener was replaced with DOMContentLoaded because our JS only needs to wait for the DOM to load and not all images, stylesheets, etc.
See https://github.local/Design-Development/Design-Thinking-and-User-Research/issues/241
@chosak form="tccp-filters" gets added to all select elements but it technically only needs to be on the sorting select element. It's harmless but lmk if you'd prefer I create a separate widget for the sorting element.
How to test this PR

Visit the cards page and you'll see the sort dropdown is below the expandable when JS is enabled.
tox -e unittest -- tccp
yarn cypress open --spec test/cypress/integration/consumer-tools/credit-cards/explore-cards.cy.js

Screenshots

before
after

Checklist

[ ] PR has an informative and human-readable title

PR titles are used to generate the change log in releases; good ones make that easier to scan.
Consider prefixing, e.g., "Mega Menu: fix layout bug", or "Docs: Update Docker installation instructions".

[ ] Changes are limited to a single goal (no scope creep)
[ ] Code follows the standards laid out in the CFPB development guidelines
[ ] Future todos are captured in comments and/or tickets
[ ] Project documentation has been updated, potentially one or more of:

This repo’s docs (edit the files in the /docs folder) – for basic, close-to-the-code docs on working with this repo
CFGOV/platform wiki on GHE – for internal CFPB developer guidance
CFPB/hubcap wiki on GHE – for internal CFPB design and content guidance

Front-end testing

Browser testing
Visually tested in the following supported browsers:

[ ] Firefox
[ ] Chrome
[ ] Safari
[ ] Edge 18 (the last Edge prior to it switching to Chromium)
[ ] Internet Explorer 11 and 8 (via emulation in 11's dev tools)
[ ] Safari on iOS
[ ] Chrome on Android

Accessibility

[ ] Keyboard friendly (navigable with tab, space, enter, arrow keys, etc.)
[ ] Screen reader friendly
[ ] Does not introduce new errors or warnings in WAVE

Other

[ ] Is useable without CSS
[ ] Is useable without JS
[ ] Does not introduce new lint warnings
[ ] Flexible from small to large screens

@chosak I ended up adding a new class, lmk if I should go about it a different way.


(1.17) Crash on startup

Simply crashes on startup, even if it's the only mod running. Gives the typical "An unexpected issue has occurred and the game has crashed. We're sorry for the inconvenience. Exit Code: 0"

Same here
Is the MedievalWeapons mod a requirement?
Crash Log: https://pastebin.com/XXscNnBF

https://gist.github.com/TheNimbleNinja/43f6bab51915f9c61c870a8c59a6f4d2

dualwielding-1.0.5.zip
please test this version if it is fixed :) you have to unzip the file.
MedievalWeapons shouldn't be a requirement

it didnt crash on that version

Great :)