handleTransition's setState batched, actions not called

I'm using withStatechart and this parallel machine (simplified):
export default {
  key: 'controller',
  parallel: true,
  states: {
    NormalizeItems: {
      initial: 'Normalizing',
      states: {
        Normalizing: {
          on: {
            NORMALIZE_SUCCESS: {
              Normalizing: {
                actions: ['startSessionSocket', 'subscribeItems'],
              },
            },
          },
        },
      },
    },
    SessionSocket: {
      initial: 'Disconnected',
      states: {
        Disconnected: {
          on: {
            START_SESSION_SOCKET: {
              Connected: {
                actions: ['joinSessionSocket'],
              },
            },
          },
        },
        Connected: {
          on: {
            SESSION_SOCKET_SUBSCRIBE: {
              Connected: {
                actions: ['emitSubscribeItems'],
              },
            },
          },
        },
      },
    },
  },
}

At some point, the first "child machine" calls startSessionSocket and subscribeItems, which look like this:
startSessionSocket = () => {
  this.props.transition('START_SESSION_SOCKET')
}

subscribeItems = () => {
  this.props.transition('SESSION_SOCKET_SUBSCRIBE')
}

This triggers the second child machine and should also call joinSessionSocket and emitSubscribeItems. However, only the second action (emitSubscribeItems) is called.
I suspect that's because I call one transition after the other, sync, and setState gets batched by React here. And since runActionMethods is called by componentDidUpdate, the joinSessionSocket action is not called.
I understand you may not see this as a bug, and I could possibly fix this by grouping this to one transition / one action, but this happens in more places in the app and I figured such a fix doesn't always result in maintainable code.
BTW: This component is one of the many "units" I have, and it has no UI. So I don't care much about re-renders.
TL;DR: Action methods are called in componentDidUpdate. When React happens to batch multiple setState() calls in handleTransition, the machine itself is in the correct state (thanks to setState(prevState => ...)), but only actions from the last transition are called.

I consider this a bug. Only rendering the last UI state is an optimization which makes perfect sense, but business logic must always be executed. We may discuss if intermediate transactions are to be executed sync or async, but completely omitting these is wrong IMO.

I was actually thinking of a solution, but it's tricky.
Calling the actions earlier than componentDidUpdate (perhaps in handleTransition right away) won't work I think, would break the Action component (and maybe more).
Preventing React from batching setState (eg. setTimeout) - ugly, and could also not maintain order correctly.
I was playing around with setState batching and found a way to tell if prevState is actually rendered: https://codesandbox.io/s/mo06pmz1my

Thank you very much @lnogol for investigating the issue.

calling runActionMethods earlier has a problem related to the component state: if one of the actions fires another transition with an updater, the prevState is out of sync.

setTimeout seems to be the easiest patch, but I wouldn't consider it.

your experiment around batching is interesting. However, it generates an inconsistency between the current machine state and the actions (i.e. the machine state is the latest, but the actions are accumulated from the last X transitions). Also, if any of the actions relies on the prevState it receives the final one, which is not correct.

I'll keep on thinking about a solution, and I'll update you here if I find something - please do the same.

Thanks!
Would forceUpdate() be of any help here? Also ugly, I guess.

To mitigate the problem, and make the current behaviour more explicit, I was thinking about adding an invariant while we find a solution.

To avoid confusion, and make the current behaviour more explicit, I was thinking about adding an invariant while we find a solution.

ln118 !this.isTransitioning should be -> this.isTransitioning or am I mistaken?
Haven't been digging into the code, but the invariant should possibly throw if another transition is already happening.

Thank you very much @oliverhausler for your comment.
invariant throws an exception when the provided value is "falsey".
In this case, we want to make sure !this.isTransitioning is true when we run a new transition.

How about not actually transitioning in handleTransition but rather add the requested transition to a queue that is processed in componentDidUpdate? Not sure if that would work, just an idea.

@MicheleBertoli said:

calling runActionMethods earlier has a problem related to the component state: if one of the actions fires another transition with an updater, the prevState is out of sync.

@lnogol said:

How about not actually transitioning in handleTransition but rather add the requested transition to a queue that is processed in componentDidUpdate?

I am not sure if Michele was talking about below problem in his comment [sorry my ignorance about the internal workings of React batching], but in the above example there are potentially 2 orders in which actions may be performed:
a. startSessionSocket -> joinSessionSocket -> subscribeItems -> emitSubscribeItems (stack)
b. startSessionSocket -> subscribeItems -> joinSessionSocket -> emitSubscribeItems (queue)
IMO they should be performed as in a., so that triggered actions are run immediately after the triggering action, as in a computer program with sub-routines, where a sub-routine is executed BEFORE the consecutive step in the main program is executed. So we may rather want to use a stack [which would not give Lukas the expected result, though].
This leads me to the question if stacked actions should be allowed at all. They make sense in xstate, where we have pure state, but they may simply not work with React, where state is batched.
@davidkpiano In which order would xstate execute actions? Is this defined?

In which order would xstate execute actions? Is this defined?

Order shouldn't matter (actions should be treated as atomic, and not dependent on other actions, according to Harel's paper), but in general, it's always:

onExit actions
transition actions (which should be preferred)
onEntry actions

@davidkpiano I can't grab Mr. Harel here on GitHub I guess, but if actions would be atomic, they couldn't ever trigger a transition, as this would immediately introduce a dependency. There couldn't be shared state if they were atomic. And exactly this is the problem that we have here:
What would happen if I had multiple actions in 2.? These are executed in the order they are contained in the array, so far so good. But what happens if one of these actions runs a transition which triggers another (sub-)action? Is the sub-action executed between the 2 actions in the array, or are all sub-actions queued and executed at the end?

Should this be closed? The bug is not fixed

Thank you very much for your comments @lnogol @oliverhausler.
I closed this issue with a commit that prevents to fire consecutive transitions and enforces the intended behaviour.
For example, the following handler:
handleClick = () => {
  this.props.transition('FOO')
  this.props.transition('BAR')
}

throws this error:

I'm not making any assumption but I couldn't find a use-case where firing multiple tranisitions in the same "render" was the only option.
Joao, on Twitter, expressed a similar opinion:

Well, if someone's doing consecutive transitions they need to step back and stop for a bit to think how state machines work.

Also, I disagree that "Using it for business logic like automata simply is an approach that doesn't work", I just think we need to find the correct approach to get the best of both worlds.
For example, when I started using Flux I hated the "cannot dispatch in the middle of a dispatch" error until I learned how to use it properly.
In any case, feel free to reopen this issue and most importantly to propose solutions and/or submit PRs, I'll be more than happy to discuss and review the code.
I will keep on thinking about this as well - it's just that I couldn't find a simple/clean solution and often, when this happens, it means I'm trying to solve the wrong problem : )

This seems related to the discussion above, so I'm adding it here. (Please let me know if I should move it to a new issue.)
I'm trying to use an intermediate "revealing" state to allow a GSAP animation to complete before it can reset (to avoid jank). The "reveal" animation is triggered when the component enters the viewport and the "reset" method is triggered when the component leaves the viewport. I'd like the intermediate "revealing" state to prevent the "reset" method from being called partway through the animation.
However, I am getting the following error:
Cannot transition on "REVEALED" in the middle of a transition on "REVEAL"

Chart:
const revealChart = {
  initial: `hidden`,
  states: {
    hidden: {
      on: { REVEAL: { revealing: { actions: [`reveal`] } }  }
    },

    revealing: {
      on: {  REVEALED: `revealed` }
    },

    revealed: {
      on: { RESET: { hidden: { actions: [`reset`] } } }
    }
  }
}

Methods of <Reveal /> class component (simplified for brevity):
handleWaypointEnter = () => this.props.transition(`REVEAL`)
handleWaypointLeave = () => this.props.transition(`RESET`)

reveal = () => {
  this.node.animation = TweenMax.from(this.node, 1, {
    css: { opacity: 0 },
    onComplete: this.props.transition(`REVEALED`)
  })
}

reset = () => TweenMax.set(this.node, { opacity: 0 })

Is this triggering the consecutive transition error because my "revealed" state has no actions associated with it?
My "revealed" state has no actions because it's purpose is simply to prevent unwanted actions (i.e. "reset") until the animation finishes. (It's essentially a pending/loading state.)
It seems like a pending state followed by a success state should be a pattern that works well in a state chart, but perhaps I'm implementing it incorrectly here. Any tips would be appreciated!

Thanks for the reply, @MicheleBertoli!
Here's a working example: https://codesandbox.io/s/mjzmpwr30j.
I'm probably making some kind of rookie mistake here... Any tips would be appreciated.

I think the logic here: https://github.com/MicheleBertoli/react-automata/blob/6f5b5051a4b14c7f21ba0a6aa63cf7e15e2ad2c3/src/withStatechart.js#L111 needs to be loosened a bit (specifically this.isTransitioning) for two reasons:

transitions should be considered zero-time (they should happen instantaneously, always)
we should defer the queued state updates to how React naturally handles it.

That might solve this issue and simplify the code a bit.

To make the "problem" clearer, I created a couple of examples of the most common approaches we could take.
Consider the following statechart:
const statechart = {
  initial: 'a',
  states: {
    a: {
      on: {
        EVENT: {
          b: {
            actions: ['myAction1'],
          },
        },
      },
    },
    b: {
      on: {
        EVENT: {
          b: {
            actions: ['myAction2'],
          },
        },
      },
    },
  },
}

Approach 1: actions in componentDidUpdate
That's the current approach, and it presents the problem described at the beginning of the issue: since multiple setState calls are batched and we fire the actions in componentDidUpdate, only the actions of the last transition are actually executed.
This is now mitigated by the isTransitioning flag, which makes the intended behaviour more explicit.
In general, although transitions should be considered zero-time, I like this solution because it's more inline with the way React works.
class Automata1 extends React.Component {
  machine = Machine(statechart)

  state = {
    machineState: this.machine.initialState,
  }

  transtion = event =>
    this.setState(prevState => ({
      machineState: this.machine.transition(prevState.machineState, event),
    }))

  componentDidUpdate() {
    this.state.machineState.actions.forEach(action => this[action]())
  }

  // this is never fired, because state changes are batched
  myAction1 = () => console.log('myAction1', this.state.machineState)

  myAction2 = () => console.log('myAction2', this.state.machineState)

  handleClick = () => {
    this.transtion('EVENT')
    this.transtion('EVENT')
  }

  render() {
    return <button onClick={this.handleClick}>Approach 1</button>
  }
}

Approach 2: actions in setState
Another potential solution would be to fire the actions right after the transition (and before the update).
This adheres to the statechart principles, but there's a downside: when the actions are fired, the new machine state hasn't been added to the state yet (because setState is async) and therefore its value is not correct.
class Automata2 extends React.Component {
  machine = Machine(statechart)

  state = {
    machineState: this.machine.initialState,
  }

  transtion = event =>
    this.setState(prevState => {
      const machineState = this.machine.transition(
        prevState.machineState,
        event
      )
      machineState.actions.forEach(action => this[action]())

      return { machineState }
    })

  // machineState is wrong, because setState is async
  myAction1 = () => console.log('myAction1', this.state.machineState)

  // machineState is wrong, because setState is async
  myAction2 = () => console.log('myAction2', this.state.machineState)

  handleClick = () => {
    this.transtion('EVENT')
    this.transtion('EVENT')
  }

  render() {
    return <button onClick={this.handleClick}>Approach 2</button>
  }
}

Sandbox: https://codesandbox.io/s/53lzpkww0l
I'm still not 100% convinced that we need to support multiple transitions, but I'm experimenting with various solutions from forceUpdate, to queues.
I'll keep you posted, and feel free to add your ideas to this thread or send a PR.
Thank you very much!

What about as a callback to this.setState()?
E.g.,
this.setState(
  () => {}, // set the finite state
  () => {}  // execute all actions that may also change state
);

Thank you very much for suggesting to use setState callbacks, @davidkpiano.
They work similarly to componentDidUpdate (approach 1):

The second parameter to setState() is an optional callback function that will be executed once setState is completed and the component is re-rendered. Generally we recommend using componentDidUpdate() for such logic instead.

But their behaviour is counter-intuitive sometimes (see my poll).
In fact, they would make the problem a bit worse: consecutive setState calls would still be batched (the issue described in the original comment) and all the callbacks would run only once the state is updated.
In the specific case, with the following implementation:
transtion = event =>
  this.setState(
    prevState => ({
      machineState: this.machine.transition(prevState.machineState, event),
    }),
    () => this.state.machineState.actions.forEach(action => this[action]())
  )

The component would be re-rendered once, and both callbacks would fire myAction2 (the final value of the machine state).

I am hitting this as well with concurrency as i have two updaters (user and server). Have you found a way to solve it?
When i hit a problem like this I think statemachine. I see it like we have three interacting here: React statemachine, xstate statemachine (mine) and react-automata statemachine. Because state transitions are not instant (except perhaps theoretically) it needs to handle both we can change. I am thinking of wrapping my statemachine in a "react-automata" statemachine so mine runs a a substate of the react-automata state.

Thanks for your comment, @larsbuch.
Would you be able to provide more information about your "concurrency" problem?


Prevent Zero Duration with Runtime Check in Timer

Objective

Fixes #8477

Solution

Create a new NonZeroDuration struct which ensures duration is never zero by panicing at runtime when it encounters a zero duration

Awesome, thanks! I just accepted that doc change

I think that (if possible) we shouldn't impl Default for NonZeroDuration as there isn't really an 'obvious' value to use.


Adding maintainer and email fields to example

Description

added maintainer field
added maintainer_email field
added license field

If you don't have these fields if you attempt to upload this cookbook this error happens:
15:55:39 JJs-MacBook-Pro vmware_playground > (master) knife cookbook upload example
Uploading example        [1.0.0]
ERROR: The data in your request was invalid
Response: Field 'metadata.maintainer' invalid

Signed-off-by: JJ Asghar<EMAIL_ADDRESS>

This smells like a chef bug too?


Error loading tslib helper library

Problem
I'm getting this error when I try running npm run build, even for a new project.
How to Reproduce

Install vue-sfc-rollup (i used sudo with mine because i am using linux)

sudo npm i -g vue-sfc-rollup

Create a new project with sfc-init with the ff.

Which version of Vue are you writing for? Vue 3
Is this a single component or a library? Single Component
What is the npm name of your component? test-component
What is the kebab-case tag name of your component? Enter
Will this component be written in JavaScript or TypeScript? TypeScript
Enter a location to save the component files: Enter

cd into the directory and type npm i
Test if the component is working using npm run serve
Attempt to build the component with npm run build

Output after Reproducing
><EMAIL_ADDRESS>prebuild
> rimraf ./dist

><EMAIL_ADDRESS>build
> cross-env NODE_ENV=production rollup --config build/rollup.config.js

Error loading `tslib` helper library.
[!] Error: Package subpath './package.json' is not defined by "exports" in /mnt/vms/Code/Sandbox/Vite/Plugins/test-component/node_modules/rollup-plugin-typescript2/node_modules/tslib/package.json
Error: Package subpath './package.json' is not defined by "exports" in /mnt/vms/Code/Sandbox/Vite/Plugins/test-component/node_modules/rollup-plugin-typescript2/node_modules/tslib/package.json
    at new NodeError (node:internal/errors:371:5)
    at throwExportsNotFound (node:internal/modules/esm/resolve:429:9)
    at packageExportsResolve (node:internal/modules/esm/resolve:683:3)
    at resolveExports (node:internal/modules/cjs/loader:482:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/mnt/vms/Code/Sandbox/Vite/Plugins/test-component/node_modules/rollup-plugin-typescript2/src/tslib.ts:11:23)

Expected Output
It should build the vue component.

The decision has been made to deprecate vue-sfc-rollup in favor of better tooling in the Vue ecosyste, specifically the vite "library build" configuration. It is an excellent project, which is capable of everything vue-sfc-rollup strived to accomplish, and more.


VNet Integration for Linux App Service - PORT environment variable still required

Typically, the WEBSITES_PORT works and yes as stated in the doc, we’re planning to deprecate ‘PORT’ app setting and to use ‘WEBSITES_PORT’ exclusively.

Originally posted by @AjayKumar-MSFT in https://github.com/MicrosoftDocs/azure-docs/issues/34451#issuecomment-509112992
VNet Integration for Linux App Service has gone GA but the PORT environment variable is still required to be used in the app. I'd just like to understand if that is expected and confirm if it still plans to be deprecated or not. For my Linux web app, I still see PORT set and if I don't listen on the port specified in PORT then my app does not work. Acocrding to the GA announcement I thought this restriction was suppose to have been removed.

@krispenner Thank you for your feedback! We will review and provide an update as appropriate.

@krispenner, Thanks for posting this question and sharing your valuable feedback.
Firstly, apologies for any inconvenience with this problem, I completely understand the concern here.
I noticed that you have also raised this question on Microsoft Q&A thread, and mentioned that "it is affecting all 20 of my Linux App Services. This all started this week."  sorry for any frustration with this. While I'm checking on this issue with the information you had shared and also discussing on this internally.
I wish to engage with you further offline for a detailed investigation and provide a quick and specialized assistance, please send an email with subject line “Attn:Ajay” to AzCommunity[at]Microsoft[dot]com referencing this thread and the Azure subscription ID, I will follow-up with you.
Thanks for your patience and co-operation.

Since we are engaging on this offline, we will close this out, but if you feel you need more information please just let us know.

In case anyone else experiences this issue.
This was a bug found with Linux App Services using VNet integration and managed identities (MSI). The ASPNETCORE_URLS environment variable was being overwritten by Azure and it should not have been. A fix has already been completed and deployment is pending at this time.

We shouldn’t be overwriting that environment variable. This was a bug that we found thanks to your feedback, and I wrote a fix. This is an environment variable that is mistakenly getting piped into your container in the VNET + Managed Identities configuration. Since its happening at runtime, it overrides the variable set in your docker image. I pushed the fix for our next platform update.

@Krispenner, Thanks for posting the summary update here to benefit the community.


Removed startNMandOHS.sh

Removed startNMandOHS.sh

@prkishor please check your commit. There are changes to 21 files, not just removal of the single file. I suspect you may not have rebased from master prior to making this commit.

I have created another PR for this issue, so closing this one.

I have created a new PR. I have closed the old one.
On 7/11/2017 8:28 PM, Bruno Borges wrote:

@brunoborges requested changes on this pull request.
Rebase your fork, and update your PR to have only the specific change
you are proposing (delete a file).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oracle/docker-images/pull/461#pullrequestreview-49224688,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Abm70_8TSSXtN3Cou2y0Oj7Lmi9Tp8-mks5sM42pgaJpZM4OTyJx.


Remove WCS module

Codecov Report
Patch coverage: 95.30% and project coverage change: +0.16 :tada:

Comparison is base (8f7e154) 96.14% compared to head (1ffed8c) 96.31%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #296      +/-   ##
==========================================
+ Coverage   96.14%   96.31%   +0.16%
==========================================
  Files          61       60       -1
  Lines        7295     7267      -28
==========================================
- Hits         7014     6999      -15
+ Misses        281      268      -13

Flag
Coverage Δ

unittests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

integration/test_timeout.py
100.00% <ø> (ø)

weaviate/backup/backup.py
100.00% <ø> (ø)

weaviate/schema/crud_schema.py
79.01% <ø> (ø)

weaviate/connect/connection.py
91.78% <81.08%> (+1.73%)
:arrow_up:

weaviate/gql/multi_get.py
86.36% <86.36%> (ø)

weaviate/client.py
98.50% <90.00%> (+0.20%)
:arrow_up:

integration/test_authentication.py
89.34% <92.85%> (+0.25%)
:arrow_up:

weaviate/embedded.py
96.26% <96.26%> (ø)

test/test_embedded.py
97.56% <97.56%> (ø)

integration/test_graphql.py
90.58% <100.00%> (+2.01%)
:arrow_up:

... and 10 more

... and 1 file with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Speedup using NVIDIA Apex

Hi,
According to PR https://github.com/huggingface/pytorch-pretrained-BERT/pull/116, we should be able to achieve a 3-4 x speed up for both bert-base and bert-large. However, I can only achieve 2x speed up with  bert-base. My docker image uses CUDA9.0 while the discussion in the PR https://github.com/huggingface/pytorch-pretrained-BERT/pull/116 is based on CUDA10.0... I am wondering if that makes the difference....
Thanks

Maybe. You can try with pytorch docker image dockerhub 1.0-cuda10.0-cudnn7 to debug, as we did in the discussion in PR #116.

Just verified that CUDA10.0 makes 4x speedup. It should be better to include this in the main document.

What GPU do you run ...


LabVIEW crashes on close after running grpc test VI

With the latest updates from <IP_ADDRESS> (and the fix for the crash mentioned here: https://github.com/ni/grpc-labview/pull/138), my LabVIEW crashes when I run the attached example and then close the VI. It should go to the LabVIEW splash screen, but instead the LV process disappears without a crash dialog or anything. This is causing our test suite to fail everything that uses grpc. A co-worker with the same version of LV and INI file doesn't have this problem, but it happens on my dev machine as well as on all our test machines. I can provide an IP address to developers that want to remote into a machine that reproduces this issue if needed.
test_grpcCrashLVAfterCloseTest.zip

We did some initial investigation and it appears there may be multiple deallocations of the same pointer. @chadallee found that a "timer_thread" may be de-allocating memory on close, but we haven't figured out where the problem is yet.

The crash occurs because a timer_thread is still running after the test VI is finished running.
Moreover, it's still running when the test VI is closed, which also unloads the labview_grpc_server.dll.  Once the DLL has been unloaded, that thread is still running and it wakes up and crashes.
Here is the callstack of the thread that's still running even when the VI is idle.
 # Child-SP          RetAddr           Call Site
00 0000008c`c29ff710 00007fff`8c27e1c0 labview_grpc_server!absl::lts_20211102::synchronization_internal::Waiter::Wait+0xba [C:\dev\github-grpc-labview\third_party\grpc\third_party\abseil-cpp\absl\synchronization\internal\waiter.cc @ 385]
01 0000008c`c29ff790 00007fff`8c27d098 labview_grpc_server!AbslInternalPerThreadSemWait_lts_20211102+0xd0 [C:\dev\github-grpc-labview\third_party\grpc\third_party\abseil-cpp\absl\synchronization\internal\per_thread_sem.cc @ 92]
02 0000008c`c29ff7e0 00007fff`8c27349a labview_grpc_server!absl::lts_20211102::synchronization_internal::PerThreadSem::Wait+0x28 [C:\dev\github-grpc-labview\third_party\grpc\third_party\abseil-cpp\absl\synchronization\internal\per_thread_sem.h @ 113]
03 0000008c`c29ff810 00007fff`8c2764aa labview_grpc_server!absl::lts_20211102::Mutex::DecrementSynchSem+0x5a [C:\dev\github-grpc-labview\third_party\grpc\third_party\abseil-cpp\absl\synchronization\mutex.cc @ 579]
04 0000008c`c29ff850 00007fff`8c275f2e labview_grpc_server!absl::lts_20211102::CondVar::WaitCommon+0x18a [C:\dev\github-grpc-labview\third_party\grpc\third_party\abseil-cpp\absl\synchronization\mutex.cc @ 2559]
05 0000008c`c29ff930 00007fff`8c1d5585 labview_grpc_server!absl::lts_20211102::CondVar::WaitWithDeadline+0x5e [C:\dev\github-grpc-labview\third_party\grpc\third_party\abseil-cpp\absl\synchronization\mutex.cc @ 2591]
06 0000008c`c29ff990 00007fff`8bbc21c4 labview_grpc_server!gpr_cv_wait+0x1b5 [C:\dev\github-grpc-labview\third_party\grpc\src\core\lib\gpr\sync_abseil.cc @ 92]
07 0000008c`c29ffab0 00007fff`8bbc235d labview_grpc_server!wait_until+0x1f4 [C:\dev\github-grpc-labview\third_party\grpc\src\core\lib\iomgr\timer_manager.cc @ 203]
08 0000008c`c29ffb60 00007fff`8bbc1c89 labview_grpc_server!timer_main_loop+0xad [C:\dev\github-grpc-labview\third_party\grpc\src\core\lib\iomgr\timer_manager.cc @ 255]
09 0000008c`c29ffbb0 00007fff`8c1d6bcb labview_grpc_server!timer_thread+0x39 [C:\dev\github-grpc-labview\third_party\grpc\src\core\lib\iomgr\timer_manager.cc @ 286]
0a 0000008c`c29ffc50 00007ff8`42a07034 labview_grpc_server!`anonymous namespace'::ThreadInternalsWindows::thread_body+0x26b [C:\dev\github-grpc-labview\third_party\grpc\src\core\lib\gprpp\thd_windows.cc @ 121]
0b 0000008c`c29ffd10 00007ff8`43f82651 KERNEL32!BaseThreadInitThunk+0x14
0c 0000008c`c29ffd40 00000000`00000000 ntdll!RtlUserThreadStart+0x21

It seems strange that the thread is still alive after the client & server have been closed, but it doesn't cause any issues as long as the DLL is still loaded.
Once the DLL gets unloaded, though, this thread causes a crash.

@NIbbuchanan @chadallee I have created a PR to fix the crash you were seeing on dll unload.
After this fix I was still seeing intermittent crashes when we close the VI. Our guess is that this is because of the additional threads grpc itself creates underneath which aren't shutdown when we close the gRPC calls in progress. This seems to be a known issue with grpc c++ which doesn't deal well with us treating it as an unpluggable component and unload dlls which initiate the grpc calls.
The suggested fix seems to be to make sure that the dlls which initiate grpc calls are never unloaded. We will put in a fix tomorrow to do an additional LoadLibrary() call within the labview-grpc dll to load itself again and make sure it is never unloaded till LV exits.

I tracked down the root cause of this last crash.
You are correct about the internal grpc thread not shutting down. The reason that thread (timer_thread) is still alive is because there was still one reference left open after shutting everything down in the test.
That last open reference was being kept alive because of a GenericMethodData object that @NIbbuchanan's test VI is never closing.
This VI from the test VI:

Eventually flows down into this vi:

With the Streaming=True constant in the test VI becoming the Complete Call=False in this deeper VI.
So the test VI is never calling CloseServerEvent on this thing
which means nothing ever calls CallData::Finish() (src/event_data.cc)
which means _status never gets set to CallStatus::Finish
which means the Finish state in CallData::Proceed() never runs to clean up and delete the CallData src/event_data.cc
which means this GenericServerContext CallData::_ctx never gets deleted src/grpc_server.h
which means that GenericServerContext never gets destructed so it never calls grpc_call_unref (third_party/grpc/.../server_context.cc)
Where the specific type of  call here is a grpc_core::FilterStackCall
which is holding onto a grpc_core::Channel (third_party/grpc/.../surface/call.cc) (third_party/grpc/.../surface/channel.cc)
And until that grpc_core::channel gets deleted, the threads (specifically that timer_thread) don't actually get stopped.
Specifically, we call grpc_shutdown() (via the LVStopServer entrypoint) but this --g_initializations == 0 check fails because of that grpc_core::channel that's still alive.
So that's a long explanation. We can fix it on the client side by making sure to call CloseServerEvent() and that should make our call to _server->Shutdown() actually kill the threads.
But maybe there's some way for that LVStopServer code to automatically call CloseServerEvent() on any GenericMethodData objects that are still open?

We could keep track of all CallData objects that were created but I am not sure if it would be safe to call Finish() on them in all cases when we call LVStopServer. For example, the call data could be waiting on a read here when we shutdown the server. In this case, it won't be safe to call Finish() on CallData and we would have to wait till the read is completed. There might be other such cases as well.
So ensuring that the labview-grpc dlls are not unloaded might be the safest solution for now.

@shivaprasad-basavaraj - Thanks for getting this checked in. I didn't see any change to keep the DLL in memory. Did i miss something?

@NIbbuchanan #143 is the PR that went in to ensure the DLL stays in memory.


Outside comparator input

If you place a comparator next to the input, it doesn't read the chest comparator output value.
This does make sense because the arrows show a Redstone dust line on them, and it consumes 1 power level.
However, it would be nice if you could place a comparator on that colored square to read the comparator output.
This mod has similar looking device, although you write code rather than placing blocks:
https://github.com/stfwi/redstonepen/tree/master/documentation/redstone-logic-control
They use R for the Red input that represents the normal Redstone power level. However, they have R.CO that allows you to get the comparator output value of blocks that provide it, such as chests and hoppers. Perhaps you could use a similar mechanism to get the comparator output value?

I think it makes sense and is more intuitive to only accept redstone signal, and not "read" comparator levels through the circuit. So i would prefer to keep it like this.

Ah, I was hoping it would be possible in conjunction with #25 as it would allow for a more compact sorter design. (Just like I can do w/ Red Pen mod, just without the code syntax; IC is more physical and vanilla like).
A compact design can still happen without and w/ #25, it just takes up 2x2 (IC behind comparator, IC powers/unpowers block underneath w/ a torch attached). vs w/ built in comparator, 1x1 without the torch outside the IC needed.
In general, I thought it would be neat to turn the R/B/Y/G squares into regular squares like the 15x15. By doing so, you could place a Redstone dust and have it be bi-directional (without the arrow). Or you could place a comparator and take the CO output from a Chest/Hopper as input. And then add a new component that controls input/output direction like those edge squares do, but it can be used anywhere in the 15x15 grid.
(I find the arrows somewhat weird because there isn't an equivalent vanilla component; But if there is a need for it, why not have it be a special IC component that can be placed anywhere).

I do like the idea of having inputs be colored floor tiles where you could place dust on top. Eliminating the input/output concept would be nice too. The reason i didn't originally do this is because the way the circuit is ticked. It has it's own update scheduler that is ran every tick inside the block entity, and doesnt work with updates from outer redstone. Maybe i will get to reworking that at some point.


[BUG] select CFG clears search

Describe the bug
Under the Runner tab, if you click "Select CFG" after searching for the config under Configs tab, it clears the search leaving you with all your configs to manually go through.
To Reproduce

Go to the Configs tab, and search for any config
Then go to the Runner Tab and click Select CFG

Version

Version 1.1.0

Additional context
I think this may have been because of the enhancement request made by someone else to search for configs in that box. But I'm not sure if that was even implemented yet.

It's not a bug, it was a feature request and I implemented it here https://github.com/openbullet/openbullet/commit/b5c64af9ff141a8176d8d5027e975161c12d24b4
Guys make up your mind please.

For now it will stay like this, later I will put the search box in the config selector as well so that it will show the filter and you can clear it from there directly.


randomizedtesting suffers from numerous maven issues

I've been wondering for a while why i can't get tests to pass (which would be useful, e.g. to try to submit some improvements)... i finally dug in.

randomizedtesting gets hit with https://issues.apache.org/jira/browse/MNG-5346. I was using maven 3.2.1. Maybe enforcer plugin can help prevent confusion instead of:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor (default-descriptor) on project junit4-maven-plugin: Error extracting plugin descriptor: 'No mojo definitions were found for plugin: com.carrotsearch.randomizedtesting:junit4-maven-plugin.' -> [Help 1]

mvn test doesn't seem to work (I tried several maven versions). I think its some issue with the shade plugin and multi-module builds. Looks like this:

[ERROR] Failed to execute goal com.carrotsearch.randomizedtesting:junit4-maven-plugin:2.2.0-SNAPSHOT:junit4 (junit4-tests) on project randomizedtesting-examples: The following error occurred while executing this line:
[ERROR] /home/rmuir/workspace/randomizedtesting/junit4-ant/target/classes/com/carrotsearch/junit4/antlib.xml:4: taskdef A class needed by class com.carrotsearch.ant.tasks.junit4.JUnit4 cannot be found: org/objectweb/asm/ClassVisitor
[ERROR] using the classloader AntClassLoader[/home/rmuir/workspace/randomizedtesting/junit4-ant/target/classes:/home/rmuir/.m2/repository/junit/junit/4.10/junit-4.10.jar:/home/rmuir/.m2/repository/org/hamcrest/hamcrest-core/1.1/hamcrest-core-1.1.jar]: org.objectweb.asm.ClassVisitor

A workaround for me is to not use mvn test, and to use mvn package

(1) didn't know about the issue, but yes, an enforcer rule can be added.
(2) this is in general a problem with maven - a {{mvn test}} never reaches those build stages that actually build the final distribution (obfuscate, repackage, etc.). You can {{mvn install}} the package first, then run {{mvn test}}, but it'd be testing what you have installed in your local repo, not the current code. I don't know how to solve this with maven, it seems it's just not a good fit for builds which do bytecode manipulation during packaging. @rjernst is working on a gradle plugin, perhaps he can convert the build to gradle so that build order dependencies actually make sense... :)

bq. A workaround for me is to not use mvn test, and to use mvn package
This isn't a workaround, it's "the maven way"...

Well, i am not sure its the maven way, I think something is wrong if you have module A and module B, and B.test depends on A.package, that is just my opinion. But i agree, maven is frustrating.

If you can constructively point me at a solution in which module A is repackaged and this is a form in which it should be tested (because repackaging and trimming can break things) and B just runs with "mvn test" then I'd love to change it. I haven't found a way to achieve it and I've tried many times. It'd require inter-module dependency so that B.test requires A.package, there is no such thing in maven.

If module A's tests depends on module B's package then those are integration tests, e.g. mvn verify. If run from the integration test phase (which happens after package), then things will always work.
And RR works nicely with integration tests now so I think it could be fixed to work that way?

You could simply bind the Mojo to the verify phase. It's part of pom, just change the phase setting. By default its bound to test.

Nothing is simple or straightforward with Maven. There is a corner case for every workaround... Trust me, I've been there, I hate it.
I know @rjernst is working on getting ES running with Gradle -- once he solves all the hard issues, I'm planning to migrate over to gradle too (and steal all that secret sauces he's been brewing).

And forbiddenapis also works with Gradle now :)


AWS Lambda delete runtime should have exact match semantics

When I ran
lithops runtime delete -b aws_lambda cubed-runtime

it didn't just delete the cubed-runtime image, but anything with cubed-runtime in the name, such as cubed-runtime-dev, cubed-runtime-main, etc. This is clearly a bug.
Previously I reported a bug where it wasn't possible to delete any AWS Lambda runtimes (#1290), where I suggested that runtime name matching should use equality:
runtimes = [tup for tup in runtimes if runtime_name == tup[0]]

But the fix in #1294, did not use equality, but instead used inclusion (in):
runtimes = [tup for tup in runtimes if runtime_name in tup[0]]

If I remember correctly, in the AWS Lambda backend this behavior was intended so that the runtime name passed to the list_runtime() can act like a filter in the way *runtime_name*.
I agree the runtime to be deleted should be only that runtime that exactly matches the name passed to the delete command, but in my opinion the fix should be placed in the delete_runtime() function of the cli, in here:
https://github.com/lithops-cloud/lithops/blob/155b43417192b80e2817776424ccf77a573479b5/lithops/scripts/cli.py#L633-L640

Thanks @JosepSampe.

If I remember correctly, in the AWS Lambda backend this behavior was intended so that the runtime name passed to the list_runtime() can act like a filter in the way *runtime_name*.

Other backends don't seem to have wildcard matching in list_runtimes(). For example:
https://github.com/lithops-cloud/lithops/blob/3bc81710e1d94ae52b1ab62652bf51a6e4d8a256/lithops/serverless/backends/gcp_functions/gcp_functions.py#L371
So it would be more consistent to make AWS Lambda do exact matches for list_runtimes() too don't you think?
(Also, the lithops runtime list CLI always shows all runtimes - there's no filtering or wildcard matching going on there either.)

Yes, I agree. Someone was using list_runtimes() programmatically in the AWS Lambda backend in the past (not trough the cli), but for now we can proceed like this


plot all observation values in time series

[ ] Closes #xxxx .
[x] I am familiar with the contributing guidelines.
[ ] Tests added.
[ ] Updates entries to docs/source/api.rst for API changes.
[x] Adds descriptions to appropriate "what's new" file in docs/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
[ ] New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
[x] Maintainer: Appropriate GitHub Labels and Milestone are assigned to the Pull Request and linked Issue.

The issue with the missing observations in time series plots is due to the fact that the processed observations are only plotted for the first instance of that processed observation. In the TA2 reports, the PNNL forecast is the first forecast/observation pair, so it gets the first pair index assigned to it during plotting. But that forecast has not yet been uploaded, so the observations are all dropped for that pair (recall missing forecasts are dropped on a forecast by forecast basis). And then there is nothing to plot.
This PR changes the observation plotting algorithm. The net result is that we plot the union of processed observations for all pairs.
Prod

This PR

I'm not aware of any good automated ways to test this.

This appears to have fixed the issue for some of the reports, but for reports like http://localhost:8080/reports/fc8eaa66-b289-11eb-9105-0a580a8002ec, observations are still not being plotted.

Found the bug here. For some reason, the report linked above has an extra timestamp at the beginning for the second pair that occurs before the first pair. in this case, pair one looks like this:
timestamp
2018-01-01 10:00:00-08:00           1           97.338150          62.6910
2018-01-01 11:00:00-08:00           1          116.819167          96.0788
2018-01-01 12:00:00-08:00           1          150.398333         112.9840
2018-01-01 13:00:00-08:00           1          147.845167         118.9730
2018-01-01 14:00:00-08:00           1           93.385300          95.5101
...                               ...                 ...              ...

and pair 2:
timestamp
2018-01-01 00:00:00-08:00           2           -0.348940            30.43
2018-01-01 10:00:00-08:00           2           97.338150           104.86
2018-01-01 11:00:00-08:00           2          116.819167           166.61
2018-01-01 12:00:00-08:00           2          150.398333           212.91
2018-01-01 13:00:00-08:00           2          147.845167           218.90
...                               ...                 ...              ...

And then when deduped, there is a trailing value before the start of the series which raises problems when the time range is pulled from the first and last index of the data in _fill_timeseries here: https://github.com/SolarArbiter/solarforecastarbiter-core/blob/63f9a0e6f0976e786755a49b359f40f5b09c507e/solarforecastarbiter/reports/figures/plotly_figures.py#L237-L239. We could solve this by sorting the index in _fill_timeseries, or by selecting only a single pair_index before filling. I think that sorting is probably the way to go, as that extra point only exists in a handful of the forecasts. Seems like maybe something wonky is happening with the filtering where it has trouble catching the first poing for ending labelled data?

I think the commit I pushed last night fixed this right?

I think the commit I pushed last night fixed this right.
Yep, sorry, missed that commit and was looking at my your branch from yesterday afternoon.

@lboeman can you approve and merge if you're happy with it?


in the new c++11 a space between string concatenation is mandatory

Note that GCC 6 compiles with C++11 support enabled by default, so this is required to compile rviz from source on for example Arch Linux. Since this is also true for the inidigo version, I think it is a good idea to backport it to indigo-devel.

Oh, #1010 already exists too


[Discovery] Lifting: Best way to handle this content?

Propose to remove the topic of Lifting from the content and featuring Apply as the One True Solution for the following reasons:

The ability to use Lifting is not consistent. Further, there is no clarity on when one can/cannot use it or why.
The alternative would be to try and find a way to explain when lifting can be used, when it can’t, and why in a concise and understandable way.
Having “Apply” as the universal way of manipulating response objects means we can consolidate Pulumi culture & increase adoption of one way that works consistently
We can reduce training complexity for Pulumi AI
We can simplify Google results on pulumi.com for new IaC / Pulumi devs

In the Accessing Nested Properties of an Output by Lifting section, there are the following code snippets:
let certCertificate = new aws.acm.Certificate("cert", {
    domainName: "example.com",
    validationMethod: "DNS",
});

// Apply example which would be replaced by the lifting example
let certValidation = new aws.route53.Record("cert_validation", {
    records: [
        // Need to pass along a deep subproperty of this Output
        certCertificate.domainValidationOptions.apply(
            domainValidationOptions => domainValidationOptions[0].resourceRecordValue),
    ],
    ...
});

// Lifting example
let certValidation = new aws.route53.Record("cert_validation", {
    records: [
        certCertificate.domainValidationOptions[0].resourceRecordValue
    ],
...

// Chaining example which would be replaced by the exact same lifting example

let certValidation = new aws.route53.Record("cert_validation", {
  records: [certCertificate.apply(cc => cc ? cc.domainValidationOptions : undefined)
                           .apply(dvo => dvo ? dvo[0] : undefined)
                           .apply(o => o ? o.resourceRecordValue : undefined)],

Can someone re-explain what is happening here to someone not deeply familiar with the workings of TypeScript? I am especially confused about how the lifting example translates to both the apply example and the chaining example.

The .apply().apply() example is just wrong: certCertificate.apply() isn't a thing, because certCertificate isn't an output, it's a Certificate:
Property 'apply' does not exist on type 'Certificate'.

Even if this did work, though, records: [ undefined ] wouldn't work anyway, because records is typed as Input<string>, not Input<string | undefined>.
We should simply this. It doesn't help and it's not even clear to me what it's trying to explain, other than that "you can chain calls to apply". That you can do this is good to know, so it'd be good to explain it somewhere, but it needn't be tied to the concept of lifting.
As for why lifting works, this line explains at least the typing of it:
export type Output<T> = OutputInstance<T> & Lifted<T>;

That means that (in Node.js at least) an Output<T> is either a normal output of the given type (requiring the use of apply()) or an instance of that same type (although that isn't actually true -- it's just that the apply has been called for you).  This explains why the following two accessors work:
const foo = pulumi.output([ { prop: "value" }]);

foo.apply(f => f[0].prop); // as an OutputInstance<T>
foo[0].prop;               // as a Lifted<T>

As to whether we should remove the documentation of it, I'm not sure. I do like the idea of leaning into apply() as the One True Way, for sure. The trouble however is that lifting exists, so people are going to wonder what it is when they see it. So my suggestion would probably be to cover it, but be clear that it's essentially syntactic sugar for apply() and that it only works only in Node.js. (I believe my assumptions are correct on this, but we should confirm just in case.)


Tried a lot, but still can’t run，Need help.

system:
os: mac big sur 11.6
grafana version : 8.1.0 or 8.2.1
clickhouse-grafana version:2.3.1

install
(1) use 'grafana-cli plugins install vertamedia-clickhouse-datasource' ,
then restart grafana, can't find clickhouse in datasource
I also find out that he will download it in '/usr/local/var/lib/grafana/plugins/vertamedia-clickhouse-datasource' directory
(2) download the zip package and unzip it ,
move it to /usr/local/var/lib/grafana/plugins/ , restart grafana not work.

I find another directory '/Users/liu/grafana-8.1.0/public/app/plugins/datasource/'. It already has some datasource like es or mysql.... So I put vertamedia-clickhouse-datasource in this directory and restart grafana.
This time I can see clickhouse in datasource tab and the plugin tab,but then I want to add clickhouse datasource ,it will return wrong like this:

how can I get the module directory?
Can't figure out where is wrong. Is someone has advice?
thx! :-)

@Slach Hi!
Yes after run the command 'grafana-cli plugins install vertamedia-clickhouse-datasource'

I check it in 'conf/defaults.ini' (didn't find grafnan.ini :-))
plugins = data/plugins  I have this directory but It's empty
so I move vertamedia-clickhouse-datasource directory to 'grafana-8.1.0/data/plugins/'  then restart grafana.
everything works! after I click the add datasource,It shows everything.
problem unsolved:
grafana-cli path is not same as the grafana config path. Maybe this is a grafana bug?


[vim9class] Fix string() to handle an object's function ref.

Fix #15129.

Rebased.
@yegappan Could you  take a look? A question is if the check for a partial being a class method is OK.

Huh, I just noticed that there's a comment I made that I can't find. Guess I didn't push the button.
This change brings the output of string() for an object function in line with what is looks like in a stack trace, #14390

There's an error in vimtags, doesn't look familiar; maybe from the rebase. Is there anything I need to do?

There's an error in vimtags, doesn't look familiar; maybe from the rebase. Is there anything I need to do?

that is strange, running cd runtime/doc; make; git diff is clean here. Looking at the diff in CI seems like it suddenly adds tags which are inside code samples in the help file. However, I cannot reproduce the failure on my side. It's clean here...

this should have been fixed by #10813 (Patch v9.0.0110), not sure why this happens now in CI again.

this should have been fixed by #10813 (Patch v9.0.0110), not sure why this happens now in CI again.

Fix for this found in https://github.com/vim/vim/pull/15099#issuecomment-2211425224

Thanks, I think this makes sense. Not sure about the question for partials

1 char change to test in PR. Need to escape a . in assert_match pattern.

A question is if the check for a partial being a class method is OK.

Not sure about the question for partials

We can say that it is not not OK since the test does work.
The pt_obj field was added with https://github.com/vim/vim/commit/29bb67f1beefc7fd393dbfd9ee77d92f1db3a3c0 specifically for "object funcref members" so it's probably a good check.

thanks, let me include it now.


Exception "Cannot access a disposed object." when exiting from Cowboy.Sockets.TestAsyncTcpSocketClient

Thanks for sharing your code.
Just want to report an issue.
When I run the test code for Cowboy.Sockets.TestAsyncTcpSocketClient. All good until I typed "quit" to exit from EXE file.
Thanks.
Here is the printout from Visual Studio 2017.
2017-05-30 16:25:20.2846|DEBUG|Cowboy.Sockets.AsyncTcpSocketClient|Connected to server [<IP_ADDRESS>:22222] with dispatcher
[SimpleMessageDispatcher] on [2017-05-30 06:55:20.2706152].
TCP server <IP_ADDRESS>:22222 has connected.
TCP client has connected to server [<IP_ADDRESS>:22222].
Type something to send to server...
hello
Client [<IP_ADDRESS>:23619] send text -> [5 Bytes].
Server : <IP_ADDRESS>:22222 --> hello
quit
2017-05-30 16:25:30.3226|DEBUG|Cowboy.Sockets.AsyncTcpSocketClient|Disconnected from server [<IP_ADDRESS>:22222] with dispatcher [SimpleMessageDispatcher] on [2017-05-30 06:55:30.3226203].
TCP server <IP_ADDRESS>:22222 has disconnected.
TCP client has disconnected from server [<IP_ADDRESS>:22222].
2017-05-30 16:25:30.3486|ERROR|Cowboy.Sockets.AsyncTcpSocketClient|Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.

Exception Details:
--------------------------------------
Exception Type: System.ObjectDisposedException
Message: Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
ObjectName: System.Net.Sockets.NetworkStream
TargetSite: Int32 EndRead(System.IAsyncResult)
HelpLink: NULL
Source: System

Exception StackTrace:
--------------------------------------
   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)
   at System.IO.Stream.<>c.<BeginEndReadAsync>b__43_1(Stream stream, IAsyncResult asyncResult)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncTrimPromise`1.Complete(TInstance thisRef, Func`3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Cowboy.Sockets.AsyncTcpSocketClient.<Process>d__36.MoveNext() in D:\Downloads\sourcecode\Cowboy-master\Cowboy\Cowboy.Sockets\Tcp\Client\TAP\AsyncTcpSocketClient.cs:line 260

Thank you for you report, and the issue has been resolved.

Hi Dennis,
thanks for your updates.
I noticed that you had added code to catch the exception. However the exception is still there.
I had done some research on this issue and I think I have found a solution.
on Program.cs of Cowboy.Sockets.TestAsyncTcpSocketClient project
calls a new method Shutdown() instead of calling Close()
                //_client.Close().Wait();
                _client.Shutdown();

Adds method Shutdown() to AsyncTcpSocketclients.cs of Cowboy.Sockets.TestAsyncTcpSocketClient project
        public void Shutdown()
        {
            _tcpClient.Client.Shutdown(SocketShutdown.Send);
        }

What is happening is that:

you type "quit" on client side
client calls Shutdown() which notifies server that client wants to disconnect.
Server returns with a 0-byte packet indicating server is ready to disconnect
Process() detects 0-byte packet and then close and dispose.

0x45FC, Worker Thread, receiveCount=6
0x3A40, Main Thread, _tcpClient.Client.Shutdown
0x45FC, Worker Thread, receiveCount=0
0x45FC, Worker Thread, Close() in Process()
0x45FC, Worker Thread, _stream.Dispose();
0x45FC, Worker Thread, _tcpClient.Close();
OnServerDisconnected

for more information see: this on stackoverflow
However, interestingly, only the TAP client test code has this issue. The APM and SAEA client test code don't. Maybe it is something to do with async and await?
Things may become more complicated if server doesn't following above good behaviours, i.e. returning a 0-byte packet. :(

@hzeng-tfs Great finding and thanks for your detail analysis.
I just improved the Close method to issue a Send shutdown notification to let the tcp channel receives a 0-byte, and that works gracefully. Please kindly have a review about it.

Then, finally, introduce and expose the Shutdown() method as public, so both the Close() and the Shutdown() can be used in user-side to determine whether need a graceful close.
Please kindly have a review about this implementation if you get free, thanks a lot.

That sounds good to me. :)


ID vs id mismatch in openapi spec vs the ach service

ACH Version: 1.18.1 (although I see the same issue is present in 1.20 too)
What were you trying to do?
Trying to use the typescript typing in https://github.com/moov-io/ach-node-sdk (which are derived directly from the openapi spec yaml file)
What did you expect to see?
I expected the typescript field names to precisely match up to the field names that I got back from the ach service. so I could use the typescript to inform intellisense and provide compile-time type correctness.
What did you see?
When running a GET of /files/{fileId}:
The service is returning fields named id in a bunch of places in the json that is returned, however the spec (and the derived typescript typing) indicates those fields should be named ID - and as a result the supplied typescript types are wrong.
How can we reproduce the problem?

POST any ach file to the ach service
GET the json format for that file from /files/{fileId}
Open up https://github.com/moov-io/ach/blob/master/openapi.yaml in a browser
Compare the GET results to the spec, noting that the service returns fields named id where the spec says they should be named ID

For instance the top-level file container object:

typescript typings: https://github.com/moov-io/ach-node-sdk/blob/master/api.ts#L1769
I think that corresponds to this in the openapi spec: https://github.com/moov-io/ach-node-sdk/blob/master/api.ts#L1769
I think that corresponds to this code: https://github.com/moov-io/ach/blob/master/file.go#L58

This same id vs ID issue seems to occur for many of the nested objects too, not just that top-level file container

Thanks for opening this @davidpricedev! Go is more lenient in allowing ID vs id to act as the same key. I've opened https://github.com/moov-io/ach/pull/1087 to enforce lowercase across the models. Once that's merged we can release ach-node-sdk with the fix.

We've released a bugfix for ach https://github.com/moov-io/ach/releases/tag/v1.20.1
Also I released v1.6.0 of ach-node-sdk. Can you try it out and let us know if that works?
https://www.npmjs.com/package/ach-node-sdk/v/1.6.0


[MOB-339] Change tokenization to use POST /payment-method

What is this
The old way of doing tokenization was with webpayments/{:id}/tokenize. However, we don't want to use that anymore and prefer POST payment-method.
What did I do

Updated the Customer and PaymentMethod models to accommodate the requisite changes
Updated TokenizePaymentMethod usecase to use POST payment-method
Updated the TakePayment usecase

:( Gotta fix these tests


Edge Browser, Fileplayer - unhandled error

<EMAIL_ADDRESS>Using Fileplayer on Edge 14/15, there's an unhandled error that prevents changing the playing state.
Unable to get property 'catch' of null reference
Fileplayer.js (171, 1)

Once this error is thrown, the player blows up and either won't render again or just stops responding to new props.  Here is a create-react-app repo with a super-simple example.
https://github.com/reergymerej/react-player-bug-repro/blob/master/src/App.js
I don't think this is a usage issue as it works in other browsers.
Please let me know if you need any more detail.

FWIW, it looks like <video /> elements return a Promise from .play() in good browsers and undefined in Edge.

Here's a way to monkey-patch from the library's consumer while you're waiting for a fix.
https://github.com/reergymerej/react-player-bug-repro/blob/monkey-patch/src/App.js#L17
It just tells the <video /> element to return a Promise if it doesn't already.

Just saw ff422195b5447340d6fe55dcfab050552c85af67. 🤐

Was there a problem with the last build to npm?  I've cleared my cache, tried Yarn and npm, various versions of Node and npm, several VM and I still get this problem.  Any advice?

Should be sorted in 0.25.1 👍


Won't open certain .cbr files

Works on many .cbr files, but when I use the menu or double-click to open certain files, nothing happens.  I know these files work because my iOS and Android comic reader apps both open them.  Let me know if you'd like me to submit an example of such a file.

This is probably too late for it to be any help for you, but I have experienced such a thing myself. If it is the same issue, then the reason some could open but others was that the cbr files that you could open actually weren't cbr, but a variation like cbz or cb7. I don't think all people that make cb* files know what the last character represents, and think cb(r/z/7) is all the same thing. There have been a recurring error going around where the XADMaster framework have failed when working against rar kind of files (like cbr), but the other kept working. And as some files with the cbr extension actually cbz, this one could easily slip under the radar.


feature - home api

Github Issue URL/Tags (required)
What's this PR do? Please give a technical summary (required)

[x] create home api

Any references (stackoverflow …) (optional)

Total linter violations in pull request: 1
Serious: 0
Warnings: 1

Total linter violations in pull request: 9
Serious: 0
Warnings: 9

:+1: There are no linter violations.


router_check: read routes from bootstrap config

Commit Message: router_check: read routes from bootstrap config
Additional Description: Support reading from bootstrap configuration and load runtime flags.
Risk Level: Low
Testing:
# bootstrap config
router_check_tool --bootstrap-config test/tools/router_check/test/config/ClusterHeaderBootstrap.yaml --test-path test/tools/router_check/test/config/ClusterHeaderBootstrap.golden.proto.json -l main

# router config
router_check_tool --config-path test/tools/router_check/test/config/ClusterHeader.yaml --test-path test/tools/router_check/test/config/ClusterHeader.golden.proto.json

Fixes https://github.com/envoyproxy/envoy/issues/35174

@adisuissa I also did a small refactor with options let me know if it makes sense and if you'd prefer to have as a separate PR . I must also add more tests but before would like to know if this high level approach with separate flag for bootstrap makes sense or you'd prefer a single flag for config, if yes I'd appreciate any pointer how I could do it. see https://github.com/envoyproxy/envoy/pull/35662#discussion_r1716080661

@cainelli needs a main merge
/wait

@adisuissa ping-nag

@adisuissa promised to followup on PRs today, but it looks likely to slip to another (business) day.

Thank you for following-up @ravenblackx and no worries, I understand and am patience. I appreciate the hard work from all Envoy maintainers :). Please let me know if I can make this any easier to review @adisuissa.

/wait
Per discussion thread https://github.com/envoyproxy/envoy/pull/35662#discussion_r1794234910, this pr seems to be waiting for the action from the author.


Makyen: Watch f+u+[ck]+

Makyen requests the watch of the watch_keyword f+u+[ck]+. See the Metasmoke search here and the Stack Exchange search here.

f+u+[ck]+ has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Coverage remained the same at 65.087% when pulling 815e9c545b2538359804284110d781be916b5282 on auto-blacklist-1524013166.9770958 into fbfe3d1618038a0909e30249cec274fba5c73fe6 on master.

!!/approve


Some elements of the editor overlap with others

Godot version:
3.1 9bd5315
OS/device including version:
Windows 10 Intel HD 4600
Screen Resolution
Around 1920x540px
Issue description:
When height of editor is small, some elements from right panel  overlap others, part around Node and Inspector tab are transparent and that do not look good.
I checked this and this seems to be caused by Profiler, other tabs, like Errors and Debugger looks good until I click to Profiler
https://streamable.com/mc97n

The same problem is with Tile Set
https://streamable.com/twfat

This seems to have been fixed in the master branch.

059a53ee1 still has problem with Profiler, Network Profiler and Video mem

Hm indeed, I couldn't reproduce it when I tried earlier, but now I can.
CC @YeldhamDev @groud you're good with boxes :o)

I took a good look at this, and honestly, I have no clue.
ScriptEditorDebugger currently inherits Control, so my first action was to change it to a MarginContainer, so it actually acknowledges the minimal size of its children, but it still refused to take the sizes into account.
The cause may be how the editor is placed (note that the tabs in the debugger go outside the bottom panel area), but I couldn't find where it tells the editor to do that. If anyone else is more lucky, let me know.

Has this already been fixed as well?

@YeldhamDev You got very close :) The only remaining issue after switching to MarginContainer is that ScriptEditorDebugger was overriding get_minimum_size() and directly calling Control::get_minimum_size() so any Container logic was skipped.


distro-sync requires --nobest

migrate2rocky.log did not finish. I had to add --nobest to proceed (dnf distro-sync)
This was not sufficient to proceed: dnf distro-syn --skip-broken
This worked: dnf distro-syn --skip-broken --nobest
Output from /var/log/migrate2rocky.log:
Error:
Problem 1: cannot install the best update candidate for package libreport-2.9.5-15.el8.x86_64

nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.x86_64
Problem 2: package python3-libreport-2.9.5-15.el8.rocky.6.0.x86_64 requires libreport = 2.9.5-15.el8.rocky.6.0, but none of the providers can be installed
cannot install the best update candidate for package python3-libreport-2.9.5-15.el8.x86_64
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.i686
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.x86_64
Problem 3: package libreport-web-2.9.5-15.el8.rocky.6.0.x86_64 requires libreport = 2.9.5-15.el8.rocky.6.0, but none of the providers can be installed
cannot install the best update candidate for package libreport-web-2.9.5-15.el8.x86_64
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.i686
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.x86_64
Problem 4: package libreport-plugin-ureport-2.9.5-15.el8.rocky.6.0.x86_64 requires libreport = 2.9.5-15.el8.rocky.6.0, but none of the providers can be installed
cannot install the best update candidate for package libreport-plugin-ureport-2.9.5-15.el8.x86_64
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.i686
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.x86_64
Problem 5: package libreport-plugin-mailx-2.9.5-15.el8.rocky.6.0.x86_64 requires libreport = 2.9.5-15.el8.rocky.6.0, but none of the providers can be installed
cannot install the best update candidate for package libreport-plugin-mailx-2.9.5-15.el8.x86_64
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.i686
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.x86_64
Problem 6: package libreport-cli-2.9.5-15.el8.rocky.6.0.x86_64 requires libreport = 2.9.5-15.el8.rocky.6.0, but none of the providers can be installed
cannot install the best update candidate for package libreport-cli-2.9.5-15.el8.x86_64
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.i686
nothing provides libreport-filesystem = 2.9.5-15.el8.rocky.6.0 needed by libreport-2.9.5-15.el8.rocky.6.0.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Thank you for the report! We have a fix coming in to address this.

Fixed packages should be in mirrors now.


Add Apple Silicon Build

Description
Adds an Apple Silicon runner to help reduce the chances of #965. There are some considerations with this approach. macos-14 runners are in beta and so it may take considerable time to acquire a runner. Due to the beta and the possible slow provisioning times this might be more hassle than good.
It can't harm to add the runner on a trial basis. If we run into any significant issues we can comment out the newer runner until it is out of beta later in the year

My only concern with this: It seems to take ages for the CI to acquire runners for Apple silicon. Dunno how to find out once CI/CD has finished, but on your initial run it took roughly half a day to get runner for the new targets. I kinda fear that this could heavily increase CI/CD for all PRs.
Is there a way to improve this?

Completely agree @SaschaWillems. This is also my concern. Im thinking that we should run the macos-14 build only if the branch is main. That way the provisioning times shouldn't affect PRs

That sounds like a good idea. I also don't think we need to run four different MacOS builds, like the initial PR did.

That sounds like a good idea. I also don't think we need to run four different MacOS builds, like the initial PR did.

One is Macos amd64 and the other is Macos arm64. Theres still some value there until macos-14 is in general release. We could merge the Build and Test V2 into the build job which save us some runners. I kept this separate to try and encourage moving more of the framework into modules (not quite there yet :) )
On this PR we can see this job is now skipped https://github.com/KhronosGroup/Vulkan-Samples/actions/runs/8239111840?pr=969
On the main of my fork we can see it runs the apple silicon job https://github.com/tomadamatkinson/Vulkan-Samples/actions/runs/8239110561
Should this PR tackle getting rid of duplicate builds? I dont mind doing that, just trying to keep the scope small

I've been thinking about this.  I believe iOS is arm64, could we count the CI for that as evidence that macos-14 should work?  There's very little differences between the two from a perspective of what gets built.

My main dev setup for VulkanSamples related development is M1 Studio + M2 Air which I compile 3 times a week on both systems. I can keep track and responsibility for these kind of issues. The M1 can be setup as PR builder and I could script that it runs and report problems to the PR. Not sure if it can be hooked up into Github CI directly as the availability of the M1 is 16 hours per working day.

Closing as stale


Refactor interpolating functions in some classes to use Math class

I now properly understand what @fire was meant in #69043. I also found that it is possible to refactor not only the bezier_derivative() implemented there, but also the bezier_interpolate() and lerp(), so I have refactor those.
The bezier formula is still duplicated in gltf_document.cpp, but since it is typed by the Template, I leave it as the original.

Thanks!


Validate External Tracker URL Format

Add some validation checks for external tracker URL format.
Attempts to check for simple typos by making sure there is a matching open/close brace for placeholder variable names if the opposite is present.
Fixes #7068

Codecov Report

Merging #7089 into master will increase coverage by <.01%.
The diff coverage is 92.3%.

@@            Coverage Diff             @@
##           master    #7089      +/-   ##
==========================================
+ Coverage   41.72%   41.73%   +<.01%
==========================================
  Files         443      443
  Lines       60159    60171      +12
==========================================
+ Hits        25103    25113      +10
- Misses      31780    31782       +2
  Partials     3276     3276

Impacted Files
Coverage Δ

routers/repo/setting.go
9.34% <0%> (ø)
:arrow_up:

modules/validation/helpers.go
94.11% <100%> (+1.8%)
:arrow_up:

models/repo_list.go
72.08% <0%> (-1.02%)
:arrow_down:

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 43cf2f3...cbfc6aa. Read the comment docs.


Profile Cards to Display the Team Members

Description
Create a section on the page where we can display our Team Members and Team Leaders with their social media handles in a representable manner and their Images and other contact details

[ ] Responsive
[ ] Create your own dummy dataset to store all the team members' details
[ ] Animation On Hover
[ ] Don't Copy as it is from the Example
[ ] Follow the Code Of Conduct

Screenshots
Here are some of the examples of the Profile Cards
Example 1

Example 2

Additional information
After the assignment of the task try to complete it within 5 - 7 days. Otherwise, it might be assigned to someone else
Follow the contribution guidelines and Code Of Conduct.
Create a responsive Adminpanel component using react which can be used in Websites.

Hey, Abirpal can you assign this task to me

Best Of Luck! 😊

Hi @Abirpal202049 , it has been long since this issue was last updated. Would love to volunteer to implement the mentioned feature if the issue is available for grab.


How to continuously read NFC tags

I try to implement continuously read NFC tags but the NfcManager.setEventListener only trigger event once after NfcManager.registerTagEvent, in order to receive the message again, I have to call NfcManager.unregisterTagEvent then use "magic" setTimeout to call registerTagEvent in order to prompt the NFC scan UI.
What I want to achieve is similar to this

I tried to go through the source code and document but still doesn't find out how to do it.
Please advice.
Regards,

It work on v1 but not v2, but v1 doesn't support write function.
Please advice.

Hi @hunterbmt , sorry for the late response and thanks for reporting that!
This should be fixed in latest v2.1.6. You should be able to simply use registerTagEvent with callback to complete continuous NDEF reading like this:
import NfcManager, {NfcEvents} from 'react-native-nfc-manager';

  _test = async () => {
    NfcManager.setEventListener(NfcEvents.DiscoverTag, tag => {
      console.warn('tag', tag);
    });

    try {
      await NfcManager.registerTagEvent();
    } catch (ex) {
      console.warn('ex', ex);
    }
  }

Thanks!

Dear @whitedogg13,
Just re-test on ios, I could confirm that the read and write function both working correctly on ios, will perform further tests on Android.
Thanks for your quick reply and the effort you put in for this awesome lib.
Regards,


DNS resolver responds with a non-zero transaction ID to a request with transaction ID zero

Version
Microsoft Windows [Version 10.0.19043.1466]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>-microsoft-standard-WSL2
Distro Version
Ubuntu 20.04
Other Software
Scapy, but it would work the same with any other DNS client which sends a DNS request with a 0 transaction ID.
(Tested it with a custom DNS application as well)
Repro Steps
Get the resolver IP address (for me it was <IP_ADDRESS>)
cat /etc/resolv.conf | grep nameserver | cut -d " " -f2
Start up scapy:
sudo scapy
Prepare and execute the following query:
req = IP(dst='<IP_ADDRESS>') / UDP(sport=RandShort(), dport=53) / DNS(rd=1, qd=DNSQR(qname='google.com', qtype='A'))
res = sr1(req)

Expected Behavior
If you run the same query with a non-zero transaction ID:

req = IP(dst='<IP_ADDRESS>') / UDP(sport=RandShort(), dport=53) / DNS(id=42, rd=1, qd=DNSQR(qname='google.com', qtype='A'))
res = sr1(req)
Begin emission:
Finished sending 1 packets.
.*
Received 2 packets, got 1 answers, remaining 0 packets

It responds with the same transaction ID so scapy can parse the answer.
Actual Behavior
The result will be an infinite wait:

req = IP(dst='<IP_ADDRESS>') / UDP(sport=RandShort(), dport=53) / DNS(rd=1, qd=DNSQR(qname='google.com', qtype='A'))
res = sr1(req)
Begin emission:
Finished sending 1 packets.
...^C
Received 3 packets, got 0 answers, remaining 1 packets

In wireshark you can see that the request will fail as the resolver responds with a non-zero transaction ID to a request with a transaction ID with zero.
If the same packet exchange is run in a vanilla Windows command line it works as expected:
PS C:> python3 -m scapy
... removed the welcome message from scapy ...

req = IP(dst='<IP_ADDRESS>') / UDP(sport=RandShort(), dport=53) / DNS(rd=1, qd=DNSQR(qname='google.com', qtype='A'))
res = sr1(req)
Begin emission:
WARNING: Mac address to reach destination not found. Using broadcast.
Finished sending 1 packets.
......................*
Received 23 packets, got 1 answers, remaining 0 packets

Diagnostic Logs
No response

@andras-gerendas I run your DNS request on a Fedora 35 and scapy (so there was no WSL layer involved) and Cloudflare name server. Here's the result:
req3 = IP(dst='<IP_ADDRESS>') / UDP(sport=RandShort(), dport=53) / DNS(rd=1, qd=DNSQR(qname='google.com', qtype='A'))
>>> res3 = sr1(req3)
Begin emission:
Finished sending 1 packets.
*
Received 1 packets, got 1 answers, remaining 0 packets
>>> res3.show()
###[ IP ]###
  version   = 4
  ihl       = 5
  tos       = 0x20
  len       = 72
  id        = 20080
  flags     = DF
  frag      = 0
  ttl       = 59
  proto     = udp
  chksum    = 0x2ca8
  src       = <IP_ADDRESS>
  dst       = <IP_ADDRESS>
  \options   \
###[ UDP ]###
     sport     = domain
     dport     = 37202
     len       = 52
     chksum    = 0x807b
###[ DNS ]###
        id        = 0
        qr        = 1
        opcode    = QUERY
        aa        = 0
        tc        = 0
        rd        = 1
        ra        = 1
        z         = 0
        ad        = 0
        cd        = 0
        rcode     = ok
        qdcount   = 1
        ancount   = 1
        nscount   = 0
        arcount   = 0
        \qd        \
         |###[ DNS Question Record ]###
         |  qname     = 'google.com.'
         |  qtype     = A
         |  qclass    = IN
        \an        \
         |###[ DNS Resource Record ]###
         |  rrname    = 'google.com.'
         |  type      = A
         |  rclass    = IN
         |  ttl       = 0
         |  rdlen     = None
         |  rdata     = <IP_ADDRESS>
        ns        = None
        ar        = None

It depends on the DNS server if you get an answer or not when id=0

This just means that the issue is present on that DNS server as well.
The DNS specification (RFC 1035) doesn't say anything about treating the value 0 for ID differently than the others.
If the DNS resolver behind WSL receives a message with ID zero it has to send the response back with it otherwise there's an ID mismatch and the response is not valid.
If it treats the number 0 in the ID as a malformed query it should return with a non-zero response code.


QA - SPARK CONNECTOR - seems to be quite slower than vwload -c with multiple files

# Description
Hi,
some observations on our QA clusters. Maybe you can try locally and see if it looks the same.
Andrei said it should be close to vwload -c even with YARN overhead.
Machine Info: (all 4 node clusters)
Cloudera: CDH 5.5.1 , Spark 1.5.0
uksl-kelch01-cent6-clu1
32GB ram, 4 cores
Hortonworks: HDP 2.3.4 , Spark 1.5.2
uksl-vortexqa-hdp22-clu1.actian.com
16GB ram, 2 cores
MapR: 5.0 , Spark 1.5.2
uksl-indecomm-mapR-clu1
16Gb ram, 2 cores
table to be loaded lineitem 7 GB file.
scenario 1: vwload and local table
#####################################################
vwload -t lineitem sample /mnt/stressdb/lineitem.tbl
CDH: 3 min
HDP: 3,5 min
MapR: 2,x mins
scenario 2: vwload -c and single hdfs file
#####################################################
vwload -c -t lineitem sample /mapr/my.cluster.com/Actian/tmp/parts/lineitem.tbl
CDH: 3 min
HDP: 6 min
MapR: 4 min
scenario 3: vwload -c and multiple hdfs files
#####################################################
vwload -c -t lineitem sample $(hadoop fs -ls /mapr/my.cluster.com/Actian/tmp/parts/x* | grep -o "/mapr.*$")
CDH: 1 min
HDP: 2 min
MapR: 1 min
scenario 4: Spark job YARN
#####################################################
$ spark-submit....
CDH: 3 min
HDP: 14 min
MapR: 13 min

After investigation, most of the time spent during execution is in the parsing library (spark-csv). There is little time spent in serialization of data values (there are however some performance issues regarding decimals that we plan to address), but in all there is little time spent in the connector code itself.
Closing for now.


Whether support Ali cloud ack service？

@DavenAaron please provide a description for what this means, what's Ali cloud ack???

1/ Container Service for Kubernetes (ACK)
2/ https://www.alibabacloud.com/product/kubernetes?spm=a2c5t.10695662.1097638.dnavproductsa7.ca9976f7AlJ4gd

Ah ok, I see that ACK is a Kubernetes certified service provider so Flagger should work on it without any issues.

FYI Flagger e2e tests run on Kubernetes Kind for each supported provider (Istio, Linkerd, NGINX, Gloo). The current minimum supported version is Kubernetes 1.11


Registry provider: New-Item -Force shouldn't blindly recreate the leaf path component (registry key)

New-Item -Force, at least with the filesystem provider, commendably employs desired-state logic:
If the specified path doesn't exist yet, it is created; if it already does, no action is taken (and no error is reported).
By contrast, the registry provider currently blindly recreates the leaf component of the path, which can result in data loss.
Steps to reproduce
# Create HKCU:/foo/bar with value 'baz1'; -Force ensures that ancestral component `foo` is implicitly created.
New-Item -Force HKCU:/foo/bar | Set-ItemProperty -Name baz1 -Value 1
# Now - seemingly - add another value, 'baz2'
New-Item -Force HKCU:/foo/bar | Set-ItemProperty -Name baz2 -Value 2
# List the resulting values.
Get-Item HKCU:/foo/bar

Expected behavior

    Hive: HKEY_CURRENT_USER\foo

Name                           Property
----                           --------
bar                            baz1 : 1
                               baz2 : 2

Actual behavior

    Hive: HKEY_CURRENT_USER\foo

Name                           Property
----                           --------
bar                            baz2 : 2

Only baz2 is present, because New-Item -Force HKCU:/foo/bar recreated the bar key, wiping out baz1 in the process.
Environment data
PowerShell Core v6.0.0-beta.9 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.674 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

That's exactly what happens with leaf items in every provider (if you new-item -force -type file it blows away the file).

@Jaykul:
That's true with files, yes, but the registry provider has no sub-item type that is the analog of a file - there's only one item type - a registry key - and it is always a container, and thus the equivalent of a directory.
Thus, my argument is: just as New-Item -Type Directory -Force /foo/bar doesn't blow away the content of an existing bar directory, neither should New-Item -Force HKCU:/foo/bar recreate key bar.


use ActiveRecord::Base.connection.schema_migration.table_name instead ActiveRecord::SchemaMigration.table_name for Rails 7.1 more

fix https://github.com/DatabaseCleaner/database_cleaner/issues/693
In ActiveRecord 7.1, ActiveRecord::SchemaMigration.table_name being removed.
As noted here, we will access it with ActiveRecord::Base.connection.schema_migration.table_name instead

I was working on a similar fix in https://github.com/DatabaseCleaner/database_cleaner-active_record/compare/main...jturkel:database_cleaner-active_record:fix-rails-edge. Not sure if the maintainers of this project are interested in adding Rails Edge to the CI matrix.

Hi @etagwerker, Could you please check this PR?
I have seen some repositories with failed tests.
https://github.com/kufu/activerecord-bitemporal/pull/105
https://github.com/rootstrap/yaaf/pull/83

@QWYNG  Thanks for taking a stab at this! I decided to go with this solution: https://github.com/DatabaseCleaner/database_cleaner-active_record/pull/78


cmd/go: 'go test' fails to vet runtime/cgo when gcc not installed

What version of Go are you using (go version)?

$ go version
go version go1.15.5 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build679279315=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I am running go test during the docker image build. My codebase consists of a single Go package and doesn't have any cgo code. Here is my Dockerfile:
FROM golang:1.15.5 as build

WORKDIR /go/src/app

# Cache Go dependencies
COPY go.mod go.sum ./
RUN go mod download

COPY . .

# This is needed to prove that the Go standard library gets recompiled.
# Since in order to recompile it requires gcc.
RUN apt-get remove -y gcc
RUN go test ./...

What did you expect to see?
I expected to see that go test successfully finishes after running my tests
What did you see instead?
go test failed with this message:
# runtime/cgo
exec: "gcc": executable file not found in $PATH
FAIL    github.com/georgysavva/driver-app/gateway/pkg/gateway [build failed]
FAIL    github.com/georgysavva/driver-app/gateway/pkg/gateway2 [build failed]

I've noticed that if I add go build -i -a std before the go test ./... command. It no longer needs to recompile:
FROM golang:1.15.5 as build

WORKDIR /go/src/app

# Cache Go dependencies
COPY go.mod go.sum ./
RUN go mod download

COPY . .

RUN go build -i -a std
# This is needed to prove that the Go standard library doesn't get recompiled.
RUN apt-get remove -y gcc
RUN go test ./...

go test ./... finishes successfully in that case.
My question is what is the condition for go test ./... to recompile that standard library, because if I remove any of those go build flags: -i or -a the solution is no longer works. And why would go test ./... need to rebuild the standard library on a fresh Go installation at all?
BTW, the situation is the same if I do go vet ./... instead of go test ./....
I encountered this issue the first time with golang alpine image(golang:1.15.5-alpine3.12) because it doesn't have gcc installed. So this is pretty related to https://github.com/golang/go/issues/28065. Maybe it's worth adding that command go build -i -a std to the official golang images to fix that kind of problem in user images that inherit them?
Thanks!

I wasn't able to reproduce this using the Dockerfile you gave. Could you please post:

go env output before running a command that rebuilds the standard library (if different from the go env output already posted)
go list -f '{{if .Stale}}{{.ImportPath}} {{.StaleReason}}{{end}}' std at the same point in time.

In general, a standard library package needs to be recompiled if something in the global configuration that changes, for example, if you set CC or CGO_ENABLED=0 or -tags, that triggers a rebuild. The go list -json output should say whether a package is stale and why.

Hi and thanks for your message!
Here is the additional information that you asked for:
go env Output before running go test ./...
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/go/src/app/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build578085697=/tmp/go-build -gno-record-gcc-switches"

Output of go list -f '{{if .Stale}}{{.ImportPath}} {{.StaleReason}}{{end}}' std was empty.
Here is also the link to the codebase that contains the Dockerfile that I posted earlier, so you reproduce it with my code:
https://github.com/georgysavva/driver-app/tree/go-std-recompile/gateway

In general, a standard library package needs to be recompiled if something in the global configuration that changes, for example, if you set CC or CGO_ENABLED=0 or -tags, that triggers a rebuild. The go list -json output should say whether a package is stale and why.

Yeah I understand that. But I use a fresh official Golang image and don't change anything in the global configuration so there should be nothing to trigger a rebuild.

Thanks for posting that repo. It doesn't look like the standard library is actually being recompiled with go test ./..., but an action is failing on runtime/cgo because gcc is missing.
It looks like it's actually vet that's failing. I see no errors when building with go test -c -vet=off. There are also no issues if I pre-populate the build cache with go vet std before removing gcc.
go test automatically runs a subset of the go vet tests for the packages named on the command line and their dependencies. vet analyzes source files passed to the compiler, which includes cgo generated sources. A C compiler is needed to run cgo. Vet results and cgo generated sources are stored in the build cache, but they aren't part of the Go installation, so that's why you might see failures when running go test without -vet=off.
I think we should probably close this, but cc @bcmills and @matloob in case they have other thoughts.

If running go vet on a user's pure-Go package requires cgo source files for other imported packages, then we should either fix vet not to do that or find a way to ship the C source files matching the compiled export data along with our installation. I don't think it's reasonable to require users to install gcc just to be able to run go vet on source code that isn't even part of their module.

@jayconrod yeah, you are right, vet is causing the problem and if you do go vet std before go test ./... the problem is gone. But as I mentioned earlier running go build -i -a std does the same (gcc is no longer required for go test ./...) and I wonder why go build -i -a std helps in this situation.
@bcmills I totally agree with you. And similar thoughts have already occurred to other users: https://github.com/golang/go/issues/28065#issuecomment-427664236, https://github.com/golang/go/issues/28065#issuecomment-725632025

vet needs to type-check files given the compiler, and that needs to happen on cgo-generated go files. I don't think we should include those files in the distribution, but it would be reasonable to skip running the standard vet passes enabled in go test for pre-compiled packages in std if a C compiler isn't available.
@georgysavva go build -a forces packages to be recompiled, even if they're already installed and up-to-date. As part of that recompilation, the cgo-generated go files that vet is missing will be written to the build cache. They'll be available later, even after gcc is uninstalled.

@jayconrod

it would be reasonable to skip running the standard vet passes enabled in go test for pre-compiled packages in std if a C compiler isn't available

I agree with that, but I think it's only tangentially related.
The OP listed go test ./... as the command to reproduce the failure. That should not be matching any package in std, so it shouldn't result in a vet run against any package in std.
I suspect that vet is re-typechecking dependencies imported by the named packages from source instead of reading their type information from export data. It probably should not be doing that.

@jayconrod thanks for clarifying this!
Thanks for looking into this, I hope you will find the reason.

I have the similar issue if using golang:1.15-alpine.
golang:1.15-buster works


WFLY-5455 change access log default to match EAP6

Once Undertow 1.3.3.Final is in this will work correctly, but there should be no problem merging it now


Collective weights

Add weight calculation and documentation to pallet-collective. Move finalize_proposal from vote to close.
polkadot companion: https://github.com/paritytech/polkadot/pull/1050
Changes:

Semantics / Logic:

Move finalize_proposal from vote to close to increase predictability and reduce weight of vote.

Adjustments for weight calculation:

Add old_count param to set_members to estimate weight.
Add proposal_weight_bound to vote so we're able to calculate its weight.

Benchmarks:

Update set_members benchmark to include the amount of proposals and associated votes.
Adjust benchmarks to the changes in vote and close.

Tests:

Add tests for new error cases introduced (TooManyProposals, WrongProposalBound).

Notes

Some of the weight calculation is a bit involved and convoluted, IMO. Notably the calculations for propose and close. Would be good to check them. Feel free to suggest improvements.

Related idea: Introduce tests that sanity check the weight calculations (out of scope for this PR right now IMO).

Todos:

[x] Pull out changes to ChangeMembers into separate PR.
[x] Make MaxMembers more implicit and require everyone to design around the constraint.

Follow-on Tasks

Potentially refactor Dispatchables to make it easier to get their length for weight calculations.
Redesign the limits to the amount of members and the resulting downstream changes necessary to other pallets.

related to #5596

Looking good so far!

@bkchr Thanks for reviewing! Can we move the discussion to #5985 ? @shawntabrizi convincingly argued that this should be a separate PR:

As discussed this PR adds the MAX_MEMBERS as an assumption and soft-constraint instead of a configurable (associated type) enforced constraint.
This means downstream pallets using collective will have to make sure not to overshoot that member limit. This was the motivation for making the const MAX_MEMBERS public, so that e.g. const_asserts become possible.

maybe merge master to make CI happy

You also need to fix the line width error that is popping up here.
This might help: https://stackoverflow.com/questions/29968499/vertical-rulers-in-visual-studio-code

Will update all weight calcs to saturating.

bot merge

@gnunicorn I would like to merge this PR :-)

Companion still needs a positive review.


[Monitoring V1] v0.2.0 should not show on 1.15 cluster

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):

use rke v1.1.9 to create a k8s v1.15.12-rancher2-6 cluster

import the cluster into a rancher:v2.5.3 setup

edit the branch of the system-library to dev-v2.5

go to the cluster monitoring page of the cluster

Result:

0.2.0 shows in the version list

Expected:

0.2.0 should not show in the list, it should show up only when the k8s version is 1.16 or higher.

@rmweir could you look into this since it's related to changes from https://github.com/rancher/rancher/pull/29559? The kubeVersion in the monitoring chart seems to be correct based on the fact that it matches the kubeVersion in upstream.
If the kubeVersion needs to be modified, I can make the fix but this seems like an edge case that should be handled by catalog v1 for charts that have similarly structured kubeVersions as kube-prometheus-stack.

@jiaqiluo Please test with a 2.5.4 setup because the UI filtering is added in 2.5.4 here

@maggieliu This is a really good point!
I passed a valid version when installing Rancher:
sudo docker run -d --privileged -e CATTLE_SERVER_VERSION=2.5.4  --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:v2.5.4-rc4

The good news is that monitoring 0.2.0 does NOT show on the k8s 1.15 cluster( only 0.1.4 shows in the list).
But there are both 0.1.4 and 0.2.0 showing on a k8s 1.16 cluster.
We expect that only the latest/highest version shows, so in this case, it should be only 0.2.0.

Will add the min Rancher version to 2.5.4. It is fine to have both versions showing because one of them is for k8s 1.15 in case user hasn't upgraded their k8s.

The fix is validated on rancher:v2.5.3
Steps:

run rancher:v2.5.3 single install
edit the system-library chart to points to the branch dev-v2.5
go to the cluster monitoring page

Result:

only 0.1.4 shows in the version list


unexpand Not working with empty string

When I tried this
perl6 -e 'use Text::Tabs; say unexpand(["", ])'
Rakudo (This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-44-gf0db882) complain:
Type check failed for return value; expected Array but got Any (Any)
in sub expand at /perl6/share/perl6/site/sources/CB069F052EBCAE0EEB6CCE926DE9C999A0A52436 (Text::Tabs) line 16
in sub unexpand at /perl6/share/perl6/site/sources/CB069F052EBCAE0EEB6CCE926DE9C999A0A52436 (Text::Tabs) line 26
in block  at -e line 1

Thank you very much for experiments and reporting! Latest commit hopefully fixed it, so closing now.


Cannot rename pairing boards after creation

Once a pairing board has been created, it is not possible to rename the pairing board. Currently, we have to create a new pairing board and move the pairs to that new board.

The current instance / deployment to Parrit.io is faulty. When renaming pairing boards, the new names do not show up until the page is refreshed.
I tried running this locally and renaming works as expected. The deployment on Parrit.io seems to have some problems