chore: separate deploy from polywrap project

Creates a new PolywrapDeploy class which takes care of the deploy logic. Now user does not need to have polywrap.yaml to deploy a wrapper.
TODO:

[x] Remove deploy attribute from extensions in polywrap.yaml

block: #1476
closes #1426

one open question: now that this pr removes the dependency of having a polywrap.yaml to do a deploy, would it make sense to remove deploy from the extensions attribute of the polywrap.yaml manifest?

one open question: now that this pr removes the dependency of having a polywrap.yaml to do a deploy, would it make sense to remove deploy from the extensions attribute of the polywrap.yaml manifest?

I think there's precedent for this (polywrap.test.yaml), and deploy is a very similar manifest to test, so I'm in 100% agreement with this.

one open question: now that this pr removes the dependency of having a polywrap.yaml to do a deploy, would it make sense to remove deploy from the extensions attribute of the polywrap.yaml manifest?

I think there's precedent for this (polywrap.test.yaml), and deploy is a very similar manifest to test, so I'm in 100% agreement with this.

@pileks perfect, working on this now

Hey @cbrzn @pileks, some thoughts on how I think we should treat the project manifest (polywrap.yaml) and what we currently call "extensions" manifests (build, infra, test, deploy, etc).
First thought is, I think we should remove the concept of a project "extension" and create a much simpler & uniform experience for the CLI. Instead I think we should call them command manifests, which can be defined for the various CLI commands: polywrap.build.yaml, polywrap.infra.yaml, polywrap.test.yaml, polywrap.deploy.yaml.
Second, we should have the command manifests back-link to the project they are referencing (if needed). Currently only the polywrap.build.yaml manifest needs to reference a project that is to be built. It should do this through a property within itself, for example project: ./polywrap.yaml.
Lastly, commands will have default naming conventions for their manifests (i.e. polywrap.build.yaml, polywrap.deploy.yaml, etc).
The result of doing these things is that we:

Create a much simpler experience that can be explained easily.
Remove the unnecessary concept of "project extensions", which doesn't apply well to all manifest types (as we see here with deploy).

Thoughts?

Okay, spent some time digging into this https://github.com/polywrap/toolchain/pull/1482#issuecomment-1386325805 and have a bit more of an appreciation for the concept of a "project exetension". I think project extensions make sense for things like the build & codegen command, since they both require a project manifest (polywrap.yaml), and can optionally have additional configuration options set within another manifest (polywrap.build.yaml), which is the extension manifest.
So, this means that the following will be true:

Project commands like polywrap build and polywrap codegen will require a polywrap.yaml project manifest, and will look for an optional extension manifest for added configuration options. For example: polywrap.build.yaml, polywrap.codegen.yaml.
 For example: polywrap.infra.yaml, polywrap.test.yaml, polywrap.deploy.yaml.

I know this is right back where we started, but just wanted to fully explore the options here and explain the rationale.

Here's the PR @cbrzn: https://github.com/polywrap/toolchain/pull/1486

I know this is right back where we started, but just wanted to fully explore the options here and explain the rationale.

@dOrgJelli what you said makes sense, and I also thought that we should only have build as an extension in polywrap.yaml. Thanks for explaining the thing about the version, nice catch there.
I will merge and fix the tests


Fix classification bug

Fixes bug #28

[Current coverage][cc-pull] is 79.06% (diff: 100%)

Merging [#45][cc-pull] into [master][cc-base-branch] will increase coverage by 0.29%

@@             master        #45   diff @@
==========================================
  Files            11         11
  Lines           928        946    +18
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            731        748    +17
- Misses          197        198     +1
  Partials          0          0

Powered by Codecov. Last update [d7f5417...63b5746][cc-compare]
[cc-base-branch]: https://codecov.io/gh/dancingcactus/python-omniture/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/dancingcactus/python-omniture/compare/d7f54174e1e0215d39f825889feb2629b2ae58e2...63b5746daa36e05ce82b6bba4e075b5dc400cd2b?src=pr
[cc-pull]: https://codecov.io/gh/dancingcactus/python-omniture/pull/45?src=pr

Merging this one in. Thanks for the help everyone.


Elbow Injuries: Radial Head Subluxation

here is the text will load the picture

here is the image.

Here is the image


ngbdropdown from NgbDropdownModule is not working with new Angular CLI 1.3.0

My ngbdropdown from NgbDropdownModule are not working with new Angular CLI 1.3.0

[x] bug report -> please search issues before submitting
all my drop-down list are not showing anything
[ x ] feature request

Versions.
@angular/cli: 1.3.0
node: 6.11.2
os: win32 x64
@angular/animations: 4.3.5
@angular/common: 4.3.5
@angular/compiler: 4.3.5
@angular/compiler-cli: 4.3.5
@angular/core: 4.3.5
@angular/forms: 4.3.5
@angular/http: 4.3.5
@angular/platform-browser: 4.3.5
@angular/platform-browser-dynamic: 4.3.5
@angular/platform-server: 4.3.5
@angular/router: 4.3.5
@angular/cli: 1.3.0
Repro steps.
try to press on an arrow from a list that use ngbdropdown and anything happens
The log given by the failure.

Desired functionality.
How should I fix this issue ?
What would like to see implemented?
YES

This issue seems to be regarding a module in ngBoostrap and should be reported here: https://github.com/ng-bootstrap/ng-bootstrap

I have the same problem, these are my local dependencies vs the latest ones..
If I upgrade everything it doesn't work.. if I upgrade ng-bootstrap only it still works, so it could be an angular issue.

Had the same problem, installing the dependencies using npm instead of yarn fixed the problem :/

Hello thanks guys.
BREAKING CHANGES 1.0.0-beta.2 (2017-08-23)
dropdown: The up input is no longer supported by you can use more flexible placement setting now.
Before:

After:

BREAKING CHANGES 1.0.0-beta.1 (2017-08-11)
ng-bootstrap now requires Bootstrap CSS 4.0.0-beta
buttons: The btn-group CSS class needs to added explicitly for radio buttons.
Before:

  ...

After:

  ...

dropdown: Dropdown menu now requires usage of the new ngbDropdownMenu directive.
Before:

Toggle dropdown

Action

After (notice ngbDropdownMenu):

Toggle dropdown

Action

This is an issue with the particular library, not the CLI.. closing.


IngressBackend UpstreamTrafficSetting validations

Description:
Fixes #4638. Adds stricter validatingWebhook validations for IngressBackend and UpstreamTrafficSetting (duplicate backends and hosts respectively). This PR also changes MeshService -> IngressBackend retrieval process to match on port as well as service name. This appears to have been an accidental omission from the original design since one would expect to be able to create an IngressBackend that allows access to the same service on different ports.

Testing done:
Additional unit tests added in the appropriate Golang packages

Affected area:

Functional Area

Control Plane
[X]

Other
[X]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? no

Did you notify the maintainers and provide attribution? no

Is this a breaking change? no

Has documentation corresponding to this change been updated in the osm-docs repo (if applicable)? N/A

Codecov Report

Merging #4640 (f9c8297) into main (cf1395e) will decrease coverage by 0.00%.
The diff coverage is 76.25%.

@@            Coverage Diff             @@
##             main    #4640      +/-   ##
==========================================
- Coverage   69.71%   69.71%   -0.01%
==========================================
  Files         217      217
  Lines       15112    15181      +69
==========================================
+ Hits        10535    10583      +48
- Misses       4527     4548      +21
  Partials       50       50

Flag
Coverage Δ

unittests
69.71% <76.25%> (-0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

cmd/osm-controller/osm-controller.go
15.31% <0.00%> (ø)

pkg/policy/client.go
87.41% <66.66%> (-1.02%)
:arrow_down:

pkg/validator/validators.go
80.51% <67.34%> (-6.28%)
:arrow_down:

pkg/policy/conflicts.go
100.00% <100.00%> (ø)

pkg/validator/server.go
78.62% <100.00%> (+0.76%)
:arrow_up:

pkg/ticker/ticker.go
83.33% <0.00%> (-3.85%)
: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 cf1395e...f9c8297. Read the comment docs.


Fix bounce-back boundary conditions

From the point of contact with the wall, propagate all three components of the position with the reversed velocity. Refer to section 4.1 of
J. K Whitmer and E. Luijten, J. Phys. Cond. Mat. 22, 104106 (2010).
http://dx.doi.org/10.1088/0953-8984/22/10/104106

To clarify, the normal component was correct, z' = z - v_z⋅(2⋅t) = z - v_z⋅(2⋅z/v_z) = -z, but the parallel components of the position were wrong, since these also change for a bounce-back reflection.

Hi Peter,
Thanks a lot! Indeed, the position in x and y was not taking the collision time into account. I will review and merge soon.


extract fly.watch to plugin

As noted in the commit's comment:

Total time taken for tests execution dropped by 60% !!!

cc/ @jbucaran @hzlmn

@lukeed What do you mean? watch is still something I imagine end users will want to do anyway.

Yes, but not all. Now it's installed via fly-watch. I thought we both agreed on this yesterday.

About separating fly.watch into its own plugin, I agree.
What I realize now, is that 60% test exec drop refers to fly tests, which for reason I misinterpret as tasks running 60% faster.

Ah, yeah. I made that optimization a long time ago, wherein chokidar became lazy-loaded instead of eagerly loaded so that only those who actually ran fly.watch loaded up Chouinard.
We got same perf boost there too.
I'll link to that commit when I get back to computer.

@jbucaran for reference: 12ec1a3edcbf4402b080f49cd3974f04d73cf4ce and #236


Fix inspectdb

The first part is almost the same as the previous closed PR #276 Fix275, only with some fixed grammar typos and that Winter'21 is now available everywhere.
The second part is a series of fixes in order to can produce smaller models.py by inspectdb. A review of this part is desirable. I'm sure that the current solution is not perfect, but better than the previous state.
A test passed by CI is not important enough. A review of better readability and usefulness of simplified output models.py is also important.

So would we release this as 3.1.1?

Please pull it to a new branch.
The second part still requires a documentation and a change log note. I'm going to try the simplified inspectdb in some new project how is it likeable this week and then probably to prepare all for a release. In the worst case the release 3.1.1 will be created from the first part.


NavigationExperimental's NavigationTransitioner will update its state after unmounting

Description
We're building an app using NavigationExperimental's NavigationCardStack, which itself uses NavigationTransitioner. We dynamically generate our cards, which can mean that the routes passed to the card stack "change" even though the content doesn't really alter.
This generally works fine. However, NavigationTransitioner's componentWillReceiveProps will trigger an animation if the scenes are not identical before updates. When the animation finishes, the component runs _onTransitionEnd which updates the transitioner's state. If the transitioner unmounts before the animation ends, this produces the standard Can only update a mounted or mounting component warning.
I suspect the way we're generate pages isn't ideal, but that this could occur for any user of the component if they attempt to unmount a transitioner (or its ancestors) shortly after a route update. It can be "fixed" by guarding the state update in _onTransitionEnd with a check to see if the component is unmounted, though this feels suboptimal.
If this is not considered a bug, could I beg some advice on best practice to avoid this? If it is a bug, advice on a better fix so I can create a PR would also be most welcome.
Reproduction
Attempt to unmount a NavigationCardStack shortly after providing it with a navigationState containing new routes.
Additional Information

React Native version: v36
Platform: Both
Operating System: Primary development system is Mac/iOS

Thinking on it, a marginly better method for fixing this may be similar to:
     this._onTransitionEnd = this._onTransitionEnd.bind(this);
   }

-  componentWillUnmount() {
-    if (this.state.runningAnimations) {
-      this.state.runningAnimations.stop();
-    }
-  }
-
   componentWillReceiveProps(nextProps: Props): void {
     const nextScenes = NavigationScenesReducer(
       this.state.scenes,
@@ -172,18 +166,16 @@
     }

     // update scenes and play the transition
-    const runningAnimations = Animated.parallel(animations);
-    this.setState({ ...nextState, runningAnimations }, () => {
+    this.setState(nextState, () => {
       nextProps.onTransitionStart && nextProps.onTransitionStart(
         this._transitionProps,
         this._prevTransitionProps,
       );
-
-      runningAnimations.start(this._onTransitionEnd);
+      Animated.parallel(animations).start(this._onTransitionEnd);
     });
   }

-  render(): ReactElement<any> {
+  render(): React.Element<any> {
     return (
       <View
         onLayout={this._onLayout}
@@ -218,25 +210,23 @@
     this.setState(nextState);
   }

-  _onTransitionEnd({ finished }): void {
+  _onTransitionEnd(): void {
     const prevTransitionProps = this._prevTransitionProps;
     this._prevTransitionProps = null;

-    if (finished) {
-      const nextState = {
-        ...this.state,
-        scenes: this.state.scenes.filter(isSceneNotStale),
-      };
-
-      this._transitionProps = buildTransitionProps(this.props, nextState);
-
-      this.setState(nextState, () => {
-        this.props.onTransitionEnd && this.props.onTransitionEnd(
-          this._transitionProps,
-          prevTransitionProps,
-        );
-      });
-    }
+    const nextState = {
+      ...this.state,
+      scenes: this.state.scenes.filter(isSceneNotStale),
+    };
+
+    this._transitionProps = buildTransitionProps(this.props, nextState);
+
+    this.setState(nextState, () => {
+      this.props.onTransitionEnd && this.props.onTransitionEnd(
+        this._transitionProps,
+        prevTransitionProps,
+      );
+    });
   }
 }```

I rewrote my navigation state route creation code to prevent the underlying problem from my side (we were storing way more in the route than was really needed). I'm no longer confident that this is a bug, as I can't be sure there's any sensible way to trigger it. I leave it open here for people more familiar with the experimental navigation to say.

Thanks for the detail & follow up @archgrove! I personally wouldn't recommend working with NavigationExperimental directly unless you have extremely specific and custom needs for your app's navigation. I'd personally recommend https://github.com/exponentjs/ex-navigation instead, it's a layer on top of NavigationExperimental that solves a lot of common problems for you.
Pinging @ericvicenti in case this issue is interesting to him, but going to close for now.

@archgrove would you mind sharing some specifics on how you managed to avoid this issue? We are seeing the same problem: NavigationTransitioner.onTransitionEnd is attempting to update the state despite the Transitioner becoming unmounted (we too were utilizing dynamically generated cards in our solution).
We have an extremely customized routing solution in our app that is heavily reliant on NavigationExperimental - it would not be practical to adopt a different navigation solution, but we've been dealing with this specific issue for a few days now. I too am not convinced it's a bug, but chalk it up my lack of knowledge on best practices with NavigationExperimental, so any information would be helpful.
Cheers
React Native version: v35
Platform: Both
Operating System: OSX


A fast auto pinpoint agent plugin generate tool,How to contributing this tool to pinpoint?

I write A fast auto pinpoint agent plugin generate tool,How to contributing this tool to pinpoint?
Here is the tool:
https://github.com/bbossgroups/pinpoint-plugin-generate

Hello, @yin-bp
First of all, Thank you for your interest and the contribution to the Pinpoint Community.
I've gone through your project on plugin-auto-generator.
It's great! I think it would be perfect for the ones who need their application monitored but having a hard time understanding the instrumentation methodology or the architecture of the plug-ins for the Pinpoint.
I am still trying to think of better ways for your suggestions.
Since Pinpoint GitHub page only contains source to Pinpoint,
So far I've come up with is as below.

We can insert LINKs to your github repository from our Official Homepage
Pinpoint sub tools are under another repository such as naver/pinpoint-docker, naver/pinpoint-plugin-template. But since all sub tools are created by us and we've never had this kind of contribution from the community, I'm not even sure this is possible. I'll check on this, if you really want to continue this way and making it official sub repository.
Open for your suggestion:)!!

@yin-bp, waiting for your suggestion:)

Hi,Thank you for your comments.Here is my suggestion:

First
Insert a link of  pinpoint-plugin-generate  Github repository to pinpoint's  Official Homepage
Then
If  making it official sub-repository is  possible, I am very willing to do this work.
That's all,Thanks.

Hello, @yin-bp
The link has been added to the plugin dev guide
Thank you for your interest in the Pinpoint Community.
Have a nice day :)


Effect of changing interrupt from edge to level sensitive on previous write to edge

I have a related question about the clicintip[i] register. The specification says:
For edge-triggered interrupts, software writes will set/clear pending bits. In contrast, for level-triggered interrupts, software writes to pending bits are ignored completely
What happens in this case:

Software configures an interrupt to be edge-triggered by writing clicintattr[i].
Software sets the interrupt pending using clicintip[i].
Software reconfigures the interrupt as level-triggered by writing clicintattr[i].

After step 3, is the interrupt still pending, or not? What value is seen if clicintip[i] is read?
Thanks.
Originally posted by @JamesKenneyImperas in https://github.com/riscv/riscv-fast-interrupt/issues/149#issuecomment-826117338

Commit https://github.com/riscv/riscv-fast-interrupt/commit/6824500a22c5e29e67efc37c96cc7abbaf379dec clarifies the behavior of the clicintip bit.
Only the current values of clicintip affect the interrupt processing.


[10.4 stable] return 600M overhead limit for containers case

This reverts commit 6f761791b46394d5fa31377878f93ddd44baeb3c.
We notice increased number of customer issues on the latest EVE versions, when QEMU process was killed by the OOM killer. So revert the overhead to 600M value.
In the EVE master the estimation algorithm is more sophisticated, please take a look here:
d88091ba7959 ("New formula to estimate VMM memory overhead (x86)")
The rule of thumb is to leave the overhead tuning to a customer using the corresponding field on the controller side.

But in master it seems like we still do 100Mb for containers on amd64 (and more on arm). Do we also need to adjust that container number in master?

But in master it seems like we still do 100Mb for containers on amd64 (and more on arm). Do we also need to adjust that container number in master?

There is another PR #3504 for that, but you've already approved that.

But in master it seems like we still do 100Mb for containers on amd64 (and more on arm). Do we also need to adjust that container number in master?

There is another PR #3504 for that, but you've already approved that.

Yeah I saw that later.


Invalid uri error message from Python extension when opening a Native Notebook

Looks like its coming from the Notebook language component in Python extension

Opt your self into native notebooks
Open VS Code
Open a Notebook immediately

Can repro

This requires a fix to the python extension then.


fix(ifDefined): treat type as lit-analyzer in Lit 1 would

Lit analyzer would see ifDefined function name and simply calculate the type as if it were the value without undefined. This fixes an issue where passing in a DirectiveResult|undefined was being calculated instead as DirectiveResult | typeof nothing. This meant lit-analyzer could not understand that this was a directive and meant to be ignored by the type checker.
externalization of cl/378967428

I think we need to fix lit-analyzer, since this is lying about the return type.

Seems like lit-analyzer already checks each individual union type. This is an edge case anyway and the users' code can be rewritten. Will instead rewrite their code since I don't think it's prudent to spend as much time as I have already on legacy lit-analyzer code especially since it's just closure type checks which are internal-only anways.


slot variant that hides child query type

Hi!
In my scenarios, I'm mostly satisfied with the 'message' component provides, and many times I don't query the child components in parent eval. Therefore, it often feels to me like being forced to change component signature to parent components is something that could be avoided.
Would it be possible to provide 'slot' variant that does not allow you to query that component, but allows you to handle it's output messages?
Scenario:
Building a form, using traditional HTML inputs. Suddenly, need to turn one 'select' into select that's enhanced by JS, so I make lifecycleComponent, add some JS magic in its Init query, but then I need to get back to that form, and make it a parent. Even if I don't intend at all to query that component (though I understand it's often needed to query it).
It sort of feels to me like component Query type describes both the public, and the private operations. And if I have only the latter (or I'm not interested in the former), then why even bother?

Another scenario: "router" component. Basing on some state, it decides which component to render, and it renders it by passing some input. No querying after that. Currently I just have separate child path for each case, but this becomes unwieldy, especially that after cp10 I'll probably have to start define my own cps...

Yeah, this is useful. We currently are using this https://github.com/slamdata/slamdata/blob/master/src/Halogen/Component/Proxy.purs to hide or remap child queries. I think it's something that we could properly support though.

Oh! So much black magic :)
Let's take it step by step:
I'm currently doing something like:
type ChildQuery = ComponentA.Query
                       <\/> ComponentB.Query

type ChildSlot = Unit \/ Unit \/ Void

cpComponentA = CP.cp1
cpComponentB = CP.cp2

Then in rendering:
case location of
  RouteA someValue -> HH.slot' cpComponentA unit ComponentA.component someValue absurd
  RouteB -> HH.slot' cpComponentB unit ComponentB.component unit absurd

So, if I could hide the type of thie child query, that would work great. Now, looking at the aforementioned Proxy, I see that:
proxy
  ∷ ∀ f i o m
  . H.Component HH.HTML f i o m
  → H.Component HH.HTML (ProxyQ (Const Void) i o) i o m

Which looks tempting, because it hides the f. But in return, it exposes i in the ProxyQ type! I am using i only while rendering the component (see someValue above), so I don't want to pollute the ChildQuery with anything except maybe the component output (which I'm not handling now, all those components have Void output).

There's no way to avoid that with this setup, unfortunately, which is why it would be nice to have first-class support for it. For the proxy component to marshal the receiver input in a well-typed manner, it has to show up in the ProxyQ type somehow.

It may be possible to do a specialized, "unsafe" version of this though only for hiding, and not export any constructors for the Proxy's query type.

At this moment I've went with (just took the original slot definition, altered the types and slapped unsafeCoerce....):
-- | Defines a slot for a child component that ignores child query. Takes:
-- | - the slot "address" value
-- | - the component for the slot
-- | - the input value to pass to the component
-- | - a function mapping outputs from the component to a query in the parent
unsafeSlot
  :: forall f m p i o g h
   . p
  -> Component HTML g i o m
  -> i
  -> (o -> Maybe (f Unit))
  -> ParentHTML f (Const Void) p m
unsafeSlot p component input outputQuery =
  let f = unComponent _.receiver component
  in unsafeCoerce $ Core.slot (mkComponentSlot p component input f outputQuery Just)

Hope it won't become problematic;)

Closing this as something like it is now possible in Halogen 5, in that components can have internal "actions" to handle interaction, etc. distinct from the "query" they advertise to the outside world.


Wownero fork

Hi Michał,
I was wondering if you could give me some pointers on refactoring this library to operate with the Monero fork, Wownero.
I've forked the repo here: https://git.wownero.com/lza_menace/wownero-python
I've made some adjustments in monero/const.py just from evaluating diffs in the C++ code bases cryptonote_config.h (prefixes), but am having difficulty in trying use the library to generate new accounts:
ValueError: Invalid address netbyte 10. Allowed values are: 18, 24, 35, 3f, 1032, 2fb0

From evaluating the code it seems like the only places to change are the constants stored which are hardcoded Monero values and then the string slices in address generation. I would like some help/pointers in understanding those slices as I think they are where the problems lie and I'm not familiar enough with the underlying cryptography to know how to position them.
Any assistance or pointers would be greatly appreciated.

Also:
Nice.

Hi,
First of all, the error message shows there could be something wrong with the netbytes, as the last two values are more than 8 bits. If that's the case and Wownero uses longer addresses (e.g. using 2 netbytes instead of one), you must do some extra work and ensure proper endianness.
The official doc describes address structure: https://monerodocs.org/public-address/standard-address/
What it doesn't mention is the fact the first byte of the address is netbyte and it has different values not only for each network, but for each address class (base, subaddress, integrated). That's exactly what's in the const.py file.
Subaddress generation may also differ in Wownero (https://monero.stackexchange.com/questions/10674/how-are-subaddresses-and-account-addresses-generated-from-master-wallet-keys/10676#10676)
Here's a tool that could help you, even though it doesn't support Wownero: https://xmr.llcoins.net/addresstests.html

Thanks so much for the pointers, it is much appreciated! I will spend some more time investigating and debugging.


clash.net: Add version 1.0.1

A Clash GUI Proxy For Windows Based On .NET 5

scoop install clash.net
Installing 'clash.net' (1.0.1) [64bit]
Loading Clash.NET.1.0.1.x64.7z from cache
Checking hash of Clash.NET.1.0.1.x64.7z ... ok.
Extracting Clash.NET.1.0.1.x64.7z ... done.
Linking ~\scoop\apps\clash.net\current => ~\scoop\apps\clash.net\1.0.1
Creating shortcut for Clash.NET (ClashDotNet.exe)
'clash.net' (1.0.1) was installed successfully!

The software is discontinued and removed by the developer.
https://github.com/ClashDotNetFramework/ClashDotNetFramework


RFC #nc000 Nodecloud 2.0

This PR contains the contents of the RFC #nc000
cc: @rajitha1998 @rehrumesh @lakindu95

We need to create a Github secret for Host Docs GitHub action. Also, I have added the branch as nodecloud-next in the Github action. since we are merging this to the master branch shall I change it to master?

Let's change GH action config to master

#68


Update integrations 1/2

I updated first 10 (out of 20) integrations that are currently implemented in the source code - Integrations API.
gitlab-ci and hipchat are no longer in the API docs so I deleted them.
My idea is to update remaining 10 in the next PR.

@svanharmelen I returned deleted services back to the source code.
I also left URLs in function docs unchanged (and broken) because the oldest official gitlab docs archive is version 14.7 and it seems that those services were removed before that.


fix(pointcloud): Intelligent fitting failed when the rect is parallel to the coordinate axis

:tada: This PR is included in version 1.10.0-alpha.9 :tada:
The release is available on npm package (@alpha dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.14.0-alpha.9 :tada:
The release is available on npm package (@alpha dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.7.0-alpha.7 :tada:
The release is available on npm package (@alpha dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Fix: new wallets not showing cards due to filters

Issue with new wallet not showing any cards due to filters init.

@JamesSmartCell fixes https://github.com/AlphaWallet/alpha-wallet-android/issues/718


MangoBOX-Protocol

Project Abstract
MangoBOX is a fork and upgrade of fund-raising protocol Juicebox on Ethereum. It rewrites the logic and functions of Juicebox in the smart contract language of Ink! and allows the ecological projects in Polkadot to raise funds from their community and introduce the Juicebox treasury management model into the Polkadot ecosystem. Anyone can utilize the MangoBOX platform to freely create a project fundraising page, customize the funding structure, customize how the project allocates funds and reward community members with tokens.
For which grant level are you applying?

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $50,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied, renamed ( project_name.md) and updated.
[x] I have read and understood the FAQs, application guidelines and announcement guidelines.
[x] A BTC, Ethereum (USDT/USDC/DAI) or Polkadot/Kusama (aUSD) address for the payment of the milestones is provided inside the application.
[x] I have read and acknowledge the terms and conditions.
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted.
[ ] I prefer the discussion of this application to be in a private Element/Matrix channel. My username is: @_______

How Did You Hear About our grants program?

[ ] Social Media
[ ] Hackathon
[x] Personal Recommendation
[ ] Substrate Builders Program
[ ] Investor/VC
[ ] Online Search
[ ] Other: _______

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

I would be happy to support this if the milestones were more specific. The functionality is specified earlier; I would just like to see the milestones re-worded so that they focused on the specific functionality available at that milestone, as opposed to the modules that will be completed at each milestone. This will make testing and approving the milestones much easier.
Other than that minor point, looks good and I think it would be a great addition to the ecosystem.

I would be happy to support this if the milestones were more specific. The functionality is specified earlier; I would just like to see the milestones re-worded so that they focused on the specific functionality available at that milestone, as opposed to the modules that will be completed at each milestone. This will make testing and approving the milestones much easier.
Other than that minor point, looks good and I think it would be a great addition to the ecosystem.

Thank you for your advice, and your encouragement has given us more courage to do this career.
As you said, we're going to re-word our two milestones to make them more specific.
Please wait for our further updates.

Hi, @laboon, based on your suggestion and after discussions within our team, we have re-optimized our two milestones.
In the first milestone, we mainly realize how to create a fundraising project and initialize the project.
The second milestone we mainly complete when a project is launched, how to manage the funds raised by the project and manage its governance tokens.
This way, it makes our goals for both milestones clearer.
If you have any other suggestions, please feel free to leave us a message.

Hi, @Noc2 ,  thank you very much for your reminder, it is very helpful to us. Since Ink! smart contract is a very new technology, there are not many project cases in the ecosystem at present. Our technical team has now started working on each of the Ink! projects and learning their code. We want to maximize the best possible development of Ink!. We also hope that with the efforts of more and more teams, Ink! will grow and mature faster.

Hello @Noc2 , thank you very much for your suggestions and reminders, now that we have updated the PR, and here I explain in more detail the ERC-721 implementation in our first milestone.
First of all, the NFT we developed here is not a standard ERC721 token, it represents a management authority.
What we are doing is a DAO fundraising system, anyone can build a DAO organization to raise funds. When this fundraising system is established, it is necessary to have administrative rights to configure parameters for this organization. At this time, we did not directly set the management rights from the code, but abstracted the management rights into an NFT. Whoever owns the NFT can control the DAO organization and adjust the corresponding fundraising parameters.
Such a logical design can make the management authority of the DAO organization very easy to transfer, which is very convenient for the project party to manage the project.
This NFT function is just a small function in the first milestone. Our first milestone is mainly to complete the creation of the fundraising system, initialize its various functions, and finally realize that anyone who does not understand the code can quickly create a DAO fundraising system.
Thanks again for the reminder, and if you have any other new questions, please feel free to leave us a message.

Hi, @Noc2 , thank you very much for your patient answer, I will further clarify your two questions.
In our second milestone, when all Ink smart contracts have been developed, we are ready to develop a front-end file to realize the interaction between the contract file and the front-end file. Eventually we will develop a new set of UI pages and finally implement our DAO fundraising system.
Do we need to provide mock-ups if we develop front-end files? If necessary we will design a mock-ups and update it in the application file.
This is the solidity code link for Juicebox, we have updated this link to the PR.
https://github.com/Mangoboxlabs/juice-contracts-v2

Thanks for the quick reply and update. Just to double check: front-end files = front-end, which can be compiled and run locally, correct? It would be nice to have some very rough mock-ups or something similar as part of the application. Just to get an idea of what you plan to deliver.

Thanks for your quick reply, it gave us more clarity on what to do next. Yes, as you said: front-end files = front-end, which can be compiled and run locally, it is right.
We will design a few more product mock-ups and update them in the application file, please wait for us for a few more days.
Thanks again for your hard work!

Looking forward to seeing the updates!

Hi, @Noc2 @laboon , thank you very much for your continued help. Now we have updated six product UI mock-ups  in the application documents, and we will develop products with such mock-ups  in the future. However, it should be emphasized that this is not our final version, we will optimize and modify it in the actual development process. Now please review again.

Thanks for your quick reply. As you said, we have reduced the price for the 2nd milestone to 20k. We will go all-in on development work, so please look forward to our work.


Move tun mtu failing to an error log instead of fatal

As noted in the comment, the route table should have the MTU set as well. Failing to establish the route is a fatal.
closes #112

This does not fix my problem, as my server does bail out at line 197, the result of SIOCSIFTXQLEN. The setting of the MTU was no problem for me.


[FLINK-23164][tests] Harden JobMasterTest.testMultipleStartsWork

The JobMasterTest.testMultipleStartsWork fails because we don't wait for the JobMaster
to finish its suspension before restarting the JobMaster. This can lead to ignoring the
underlying control START control message. This again can lead to a situation where we are
in the STOPPED state and try to send UnfencedMessage(startJobExecution) in JobMaster.start.
This commit fixes this problem by waiting on the suspension future to complete before restarting
the JobMaster.

Thanks for the review @rmetzger. Merging this PR now.


JAVA version of this awesome work ?

Hi,
Is there a way to convert this awesome work to JAVA please ?
If yes, any help ?

@miranos I don't think you can automatically "convert" this code to Java, if that's what you are asking for.
I think the best you can do is to rewrite this codebase to Java. If you know both Java and Javascript this shouldn't be too hard.
Alternatively you can try using Java's ScriptEngineManager (https://docs.oracle.com/javase/6/docs/technotes/guides/scripting/programmer_guide/index.html) to run the Javascript code on JVM.


ruff: Fix FURB132 Use discard instead of check and remove

This is a preview rule, not yet enabled by default.
https://docs.astral.sh/ruff/rules/check-and-remove-from-set/

Merged, thanks @andersk!


Add Penny Dreadful format

I wanted to add the Penny Dreadful format. I've forked the repository to work on it: https://codeberg.org/LifeSymbiont/Best-MTG-Deck

Finished adding the Penny Dreadful format of my repository. Here is the commit

Would you open a pull request? What did you use to get the data? I use https://github.com/ElLorans/GoldfishScrape even though I haven't updated the db in a while.


Add userprofile changes and sheet table height settings to docs

We deploy the dev branch of SODAR in production and it links to the dev documentation on readthedocs. Alas, right now the deployment and the dev docs are a bit "out of sync", as I'm waiting for Varfish and Kiosc to catch up on the SODAR Core updates.
Hence I'll be adding these separate doc issues I plan on tackling at once when we are ready to deploy.
So, like, what it says on the tin. The sheet table height option and user profile settings updates should be documented.

This issue has been merged into #1689, closing.


Problems reading lines word by word where there are <and > signs in the editor with screen readers (fixed in Chromium, but in a higher version not yet used in VS Code / Electron 22).

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.80.0-insider (user setup)
OS Version: Microsoft® Windows® Operating System Version 10.0.22621.1778

Steps to Reproduce:
This issue is related to this chromium change to solve a bug related to reading lines word by word where there are <and > signs in the editor with screen readers.
This bug was fixed in Chromium 111 / Electron 24.
Could it be possible to backport this fix to the Chromium version used in the current version of electron/VS Code?
Nowadays, working with HTML or XML is really tedious and annoying.
For example, imagine this line:

text!

Starting from the beginning, what the screen reader reads to me when I press ctrl+right arrow is the following:

Pronounced
cursor at column

p>
<
> (col 3)

p><
< (col 4)

strong>
s (col 5)

strong>
> (col 11)

text
t (col 12)

!<
! (col 16)

!<
< (col 17)

strong><
s (col 19)

strong><
> (col 25)

strong><
< (col 26)

p>
p (col 28)

p>
> (col 29)

As you can see, the mechanism that looks for the boundaries between words is not taking into account the < and > signs when pronouncing each one of them. This is what has been solved in this bug.
Thanks in advance!
cc @isidorn

@deepak1556 this is the backport issue that we discussed.

Thanks for linking the CL, I will backport the fix.

@deepak1556 thank you very much for the fix 👏
@kastwey do you mind verifying in VS Code insiders from Wednesday if this is indeed fixed for you. Thank you

This bug has been fixed in the latest release of VS Code Insiders!
@kastwey, you can help us out by commenting /verified if things are now working as expected.
If things still don't seem right, please ensure you're on version 636dbcff557af8aa088ae118b1a094dce6632ce7 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.
Happy Coding!

@isidorn and @deepak1556 I just tested it and it's working perfectly!
Thanks guys, I really appreciate the effort to make the backport, and the speed with which you did it :) ❤❤


Jlannoy feature freemarker configuration

hey... I fixed the test and added a simple test to make sure getConfiguration works...


Add comments, explicit origin/watch dir, and fix CLI check

chore: this is a test commit

bors r+


Optionset Labels not displayed in View Filtering option

Dear UI Support team,
Since the last update my users are no longer able to filter by Optionset fields in Views.
The Optionset option labels are not displayed, only the Optionset option values are displayed. This way you do not know which value is which.
Example;
I have a  a Option set named 'Customer' type with 2 options;
-Customer
-No Customer
When I want to filter a view with this option set in it, I can only filter on my Option Values. I only see value 0 & 1. My users do not know the label of the value! I am having the same in all my other UI configured organisations.
Please resolve this issue with the Control_Grid_Filter. UI View filtering is un-usable now!

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

ID: 9ab324e0-f5c6-64cb-d93b-85d238bf25d3
Version Independent ID: 94fbb660-5300-51a1-9c98-4b6500800e29
Content: About Unified Interface Dynamics 365 Customer Engagement
Content Source: ce/admin/about-unified-interface.md
Service: crm-online
GitHub Login: @mduelae
Microsoft Alias: mkaur

hi @basvb1992,
The issue is fixed and is waiting for deployment, you should receive it soon.

Great @kunalks2003 !
Thank your very much for the fast solution! If I find any bugs like these, I'll contact you if needed. We are currently switching to a UI first implementation scenario.
Sidenote: if there are any testers needed for future releases, let me know!
Kind regards,
Bas

Hi,
Would it be possible to add to the documentation, how to use those fields  "External Type Name" and "external values" via webapi's. More specifically, how in we can use those to set values in a given entity, passing the external value and not the option numeric value.
Would appreciate it.
Best regards,
Manuel


[DataPipe] Make lengths of DataPipe dynamic

Stack from ghstack:

-> #873

Differential Revision: D40962187

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

This is somewhat of a BC-breaking change. Should I mark it so?

This is somewhat of a BC-breaking change. Should I mark it so?

I would say it's fine as it's fixing a bug.


problem when downloading the 'audioset_data'

When I run 'generate_dcase_task4_2021.py --basedir='../../data'', it paused as shown as follows:

How can I make the downloading successfully?

🤔 Good question.
If it is blocked here, it could be an internet connection.
Did you try to remove the "tmp/" folder, sometimes it can cause problems ?
Then,  line 722 you could try and change:
desed.download_audioset_data(desed_real_folder, n_jobs=3, chunk_size=10)
by
desed.download_audioset_data(desed_real_folder, n_jobs=1, chunk_size=10) and see if this works (could be a multiprocessing problem in that case).
Let us know if something worked.

Thanks for your help!
With experiments, 'tmp/' folder and the multiprocessing work are not the reason of this problem.  The reason is the internet connection. I have tested to download with a VPN. However, it is interesting that the work still failed in my ubuntu system but successfully in my windows one. Maybe it is an agency problem when the project calling in a ubuntu system?

This is weird indeed, I honestly have no idea where it can come from 🤔 Maybe firewall or anything like that, I don't even know if this could be from youtube_dl which would be different on your different systems...

Closing this issue since it works on one system, if someone has the same problem, feel free to reopen.


After fighting state problem

After existing Fighting state there are two possible outcomes:

Player won - in this case the enemy need to be deleted form the map so that the player doesnt trigger another fight with the same enemy as he will be standing in the same position where the fight stared.

The placeholder enemy list in Game state is weird. I would need to remove the enemy from it along with all the traces of the enemy from the collision map, imo the enemy list should be part of the map and have a function to remove a character form the map altogether.

Enemy won -  in this case we need the player to move back to the tile from which the fight was initiated.

Might not be thata hard to fix, but i literally dont know how the movement and map system works and dont want to read all the 400 lines of code to understand what i need to change, as right now i dont see a function that would let me move the charecter simply by providing a movement vector.

changed the conditions for the battle to start now the player cant walk "into" the enemy


Comonads; Good for something

Fixes #119 and #20
Now hearing arguments as to whether Copointed is a good idea.

Ugh.  Soooo many weird linker bugs still reside in Swiftc.

@CodaFi :(

@pthariensflame  Ready for Review

:+1:

In the absence of objections, merging.


Add default excluded services to our Beyla Helm chart

When deploying Beyla with our helm chart and we've also deployed Alloy (or the OTel collector), we can create accidentally an endless exponential cycle of data being generated. Essentially, Beyla will start monitoring Alloy and report a new event for every event Alloy sends, which in turn makes more data for Alloy and so on.
I'm adding a default list of excluded services from instrumentation: Beyla itself, Alloy and OtelCollector.

I'm not sure if I would disable Beyla by default. In some cases we auto instrument Beyla to get process metrics and show them in the debug dashboard.

I'm not sure if I would disable Beyla by default. In some cases we auto instrument Beyla to get process metrics and show them in the debug dashboard.

This doesn't affect in any way the internal metrics that Beyla ships. It only prevents the kprobes to track Beyla internal requests. What I'm describing here is 10 times worse if Beyla internal trace metrics are enabled, then it becomes even more of a problem.


Design autoscaling algorithm

Initial proposal here:
https://drive.google.com/open?id=1yr7XYKKkZub-rdhJjAAo46tu6wVktlAFJ7prsET034I

I am taking this on with a draft PR to be made very shortly.


BE: Fix sonar code smells

https://sonarcloud.io/project/issues?resolved=false&id=com.provectus%3Akafka-ui_backend

blocked by #1537

@Haarolean is this issue still open to work on ?

@dshubhadeep yes

@dshubhadeep any luck?

@Haarolean will submit a PR by this weekend


Refactor Resizable Runtime from blocking TiKV shutting down.

What is changed and how it works?

Issue Number: Close #17807 17807

What's Changed:
A new version of resizable runtime is added, with same performance but won't block the tikv shutting down.

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[x] Unit test
[ ] Integration test
[x] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

A new version of resizable runtime is added, with same performance but won't block the tikv shutting down.

/ok-to-test

/test pull-unit-test

/test pull-unit-test

/test pull-unit-test

BTW is there a test (other than the entire integration test in #17807) that explicitly demonstrates how the ResizableRuntime blocked TiKV shutdown previously, and now does not?

/test pull-unit-test

BTW is there a test (other than the entire integration test in #17807) that explicitly demonstrates how the ResizableRuntime blocked TiKV shutdown previously, and now does not?

The previous blocking is due to ConfigManager holds the ResizableRuntime and can't drop when shut down.
There is no specific unit test, but you could change the Weak ref to Arc ref in ConfigManager, and you could reproduce the blocking issue again.

/test pull-unit-test

/test pull-unit-test

/run-cherry-picker


No information loading on V3

When I run the server and load localhost:10080 in my browser I see the header "UK Railway Station Information Boards" but no train information:

I've probably missed made a basic error so here was my install process:

Download project
Navigate to project folder in Terminal
Edit app/.env.example to include LDBWS token and save to app/.env
Run docker-compose build
Run docker-compose up
Navigate to localhost:10080
Receive 500 Server Error
In new Terminal window navigate to project folder and run docker-compose exec laravel php artisan key:generate
Run docker-compose exec laravel chown -R www-data:www-data /var/www
The server returns the page above with no train information

N.B V2 works perfectly, I'm only seeing this with V3 and V3-Via-on-new-line branches.
Environment
macOS 10.15
Chrome 78.0.3904.70
P.S. This is a fantastic project which I'm running on a vertical monitor at work — thanks for sharing!

I never completed V3, so the homepage is blank. If you know the station code, you can load the board with the following url /departures/{station}, so for example http://<IP_ADDRESS>:10080/departures/man.
Closing this issue because I'm starting work on V4 and it's unlikely V3 will ever be completed (V4 will use most of the frontend from V3, replace backend with Electron/node)


run error util for mesheryctl error codes replacement

Notes for Reviewers
This PR adds a make target error-util for mesheryctl to run meshkit error utility for error code replacement.
Signed commits

[ ] Yes, I signed my commits.

// @Chadha93 @leecalcote

@Philip-21 You need to look at duplicate error codes, I believe. https://github.com/meshery/meshery/actions/runs/6250971194/job/16971021729?pr=8846

@Philip-21 You need to look at duplicate error codes, I believe. https://github.com/meshery/meshery/actions/runs/6250971194/job/16971021729?pr=8846

I'll fix it @MUzairS15


ignore SECURITY file for Arch tzdata package

Resolves https://github.com/tzinfo/tzinfo/issues/134

Thanks for submitting this.
I've merged it for inclusion in the next 2.0.x and 1.2.x releases.


useSelector(..) causing twice render - event the selected state doesn't change

What is the current behavior?
Hello guys,
I have some problems with the useSelector. It causes twice render of component.
In a nut shell
 store = {
   en1: 'A',
   en2: 'B'
 }
 actions: {
   changeEN1()
  }
  <ReactReduxProvider>
      | - EN1 (useSelector)
      | - EN2 (useSelector)
      | - EN1Connect (connect)

When I click a button in EN1, it will re-render EN1 twice, but EN1Connect only once.
So I think we have the problem with useSelector.
The Sandbox Link: https://codesandbox.io/s/awesome-zhukovsky-w82pb?file=/src/App.js .
After checking the source code, i think this is the reason. Please help me take a look:

What is the expected behavior?
It should render only once when the state changes.
Which versions of React, ReactDOM/React Native, Redux, and React Redux are you using?  Which browser and OS are affected by this issue? Did this work in previous versions of React Redux?

I found the reason ..
Due to React.StrictMode problems.
Thanks guys.


13 SEP 2021 - InnerSource SIG Meeting Minutes

Date
Monday 13 SEP 2021 - 11am EST / 4pm UK
Untracked attendees

Fullname, Affiliation, (optional) GitHub username
...

Meeting notices

FINOS SIG Leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS SIG meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[x] Convene & roll call (5mins)
[x] Display FINOS Antitrust Policy summary slide
[x] Review Meeting Notices (see above)
[x] Approve past meeting minutes

[x] Review FINOS Slack InnerSource SIG Channel - https://finos-lf.slack.com/archives/C01SYB503QT
[x] Review #22
[x] Open Source Readiness Update - @vmbrasseur / @gravax
[x] OSSF London - Can there we live SIG representatives at the event in Liverpool Street on 5th October?

https://events.linuxfoundation.org/open-source-strategy-forum-london/

[x] InnerSource SIG Licensing Update
[ ] AOB, Q&A & Adjourn (5mins)

Discussion
New SIG Co-Lead

Anyone can volunteer
Arthur nominated Elspeth

OSR Readiness SIG Update from VMBrasseur

OS Maturity Matrix - work proceeding, working through some technical snags.
James confirmed email list to subscribe is<EMAIL_ADDRESS>
OSSF London

Planning hybrid session, pre-recorded panel + in person discussion

License Update for InnerSource SIG Contributions

James working with LF Legal team to propose CC BY SA as a license option for FINOS (currently only CC BY option available).
Needs sign-off from board - this will take time. Next board meeting in October.
In the meantime, proposing contributing at ISC - contributors at meeting confirmed they should be able to do that.
Discussion re tool to use for documents - agreed we will experiment with formatting. Tools to check out include: https://docusaurus.io/ ; https://pandoc.org

SIG Meeting Schedule:

Discussed the idea of moving SIG Meetings to once a month.
Agreed we should - and have intervening meetings to work on outputs.

Decisions Made

We will give more details about the SIG Co-Lead role in a role description and leave the decision till next time.
Decision planned to made about Co-Lead in next SIG meeting
We will work on InnerSource Maturity Matrix in ISC repo while legal work ongoing in FINOS for appropriate licensing.
We will change SIG meeting schedule to once a month, and use intervening weeks on outputs.

Action Items

James to create SIG Co-Lead role description.
Anyone who is interested - please notify SIG as per instructions in description.
All who will be at OSSF in person - please let James know.

WebEx info

Webex : https://finos.webex.com/finos/j.php?MTID=m33975a6a163e1319c07e33a06bd3d1d5
Meeting number:<PHONE_NUMBER>

Join by phone

+1-415-655-0003 US Toll
+44-20319-88141 UK Toll
Access code:<PHONE_NUMBER>

Mailing List
Email<EMAIL_ADDRESS>to subscribe to the InnerSource SIG mailing list.

You can use @vmbrasseur to tag me in the agenda.

You can use @vmbrasseur to tag me in the agenda.

Thanks so much @vmbrasseur ... I have tagged you in the agenda 😸

Hello!

Jane @ FINOS here

Hello!

Hello everyone! 😀 👍🏻

Hello everyone

Hi everyone!

Hi all

👋

Hello!!

Luís Carlos César Maciel

Approved some time back 😉


Multi-select: long names wrap oddly in some cases

Current behavior

When an item in the multi-select is perfectly the width of the available area the (x) gets indented alone on the next line.

Expected behavior

Don't place (x) at the end of the line, but instead place it to the right side of the button.

Steps to replicate behavior

Check the multiselect on /blog/

Screenshots
Current

Expected
Something like:

Still an issue as of 2/13/18

@mistergone is working on this, so it should be resolved shortly.

Reported resolved by @mistergone !


Phaser 3?

Will it work with Phaser 3 ?
Thanks.

I think this project is dead..
Spine offered support to the Phaser team and they could implement spine in a further version.
https://phaser.io/phaser3/devlog/117
https://twitter.com/forleafe/status/969212163775717378
So we have to wait, I think..

thanks

This is for Phaser2, it will not work on Phaser3.  I wouldn't say this is dead yet, it's still the most upto date runtime that works with Phaser,  though a working spine runtime for Phaser3 would probably kill it.

I hope it works out of the box!

Is there an update on a Spine runtime for Phaser 3 yet or is still early in v3? 😊


Flatten behaviour unexpected

I have found myself reimplementing the flatten behaviour, because it has unexpected consequences which I find hard to square with the 'contract' I was expecting from Kefir's lazy subscriptions. In particular, flatten() seems to fall between two models of synchrony.
Consider flattening the constant property [1,2,3]
In one model, the upstream subscription is made when a subscription is made to flatten, then flatten processes the resulting array events, splitting them into elements and passing them on.
Model1
<value:current> 1
<value:current> 2
<value:current> 3
<end:current>

On another model, the upstream subscription is made BY flatten(), flatten consumes all synchronously-available events. Subscribers receive only entries from future arrays which will be flattened (which is none in this case). So when you call flatten on a constant property, you receive nothing by the time you've subscribed, so this would only be useful e.g. for realtime streams or pool.
Model 2
<end:current>

In fact, the model is somewhere in between these, and it's hard to describe what it is. What actually happens is the following...
Model3
flatten <value:current> 3
flatten <end:current>

It seems that when it receives a downstream subscriber, it subscribes upstream, receives an array, then throws away a whole load of the entries, serving only the final entry.
This script demonstrates the issue, as well as providing a basic implementation of the kind of behaviour expected (noted as 'bespoke).
var Kefir = require("kefir");

var source = Kefir.constant([1,2,3]).toProperty();

var flattener = function(emitter, event){
    if(event.type==="value"){
        event.value.map(emitter.emit);
    }
    else{
        emitter.emitEvent(event);
    }
};

Kefir.stream(function(emitter){
    var handler = flattener.bind(null, emitter);
    source.onAny(handler);
    return function(){
        source.offAny(handler);
    }
}).log("bespoke");

source.withHandler(flattener).log("withHandler");

source.flatten().log("flatten");

Is there any way to achieve the expected Model1 behaviour through Kefir operations and flatten? The current behaviour seems surprising, but is also something I need to work around.
Is there a clear statement of the subscription contract which is implied by Kefir's derived streams which explains how flatten and withHandler should operate?

The issue actually in property implementation. A property always has a single current value, if it receives multiple current values from its source, it just ignore all but the latest of them.
Also flatten returns an observable of same type, so since you apply it to a property it returns another property.
We have following options to fix this:

remove that constraint from the property (that it always has a single current value)
make flatten always return a stream
add a conventional way for converting properties to streams that preserves current value, so we could do prop.toStream().flatten() (we have prop.changes(), but it removes current)

I don't have a strong opinion on this yet, but perhaps (1) is what should be fixed. I haven't use Kefir for a while, and have lost the context of why that constraint was added.

I've been working on the assumption that flatten() wouldn't activate its upstream Kefir.constant() until the first onValue() subscription was made. Is this false? Is flatten() itself counted as a subscriber? Does this subscription behaviour apply to all observable transformations?
It's the fact that the value assignments of 1 and 2 are missing which is confusing, and doesn't seem to relate to the notion of Property directly. I think it would be fine that the property still has a single current value, but I'd expect in this case that the value is assigned first to 1, then 2, then 3 after the first onValue subscriber was added.
If you modify the example to replace the declaration var source = Kefir.constant([1,2,3]) with var source = Kefir.sequentially(0, [[1,2,3]]).toProperty(); all cases then conform to the expected 'model1' behaviour, suggesting the consumption of earlier events by flatten and withHandler doesn't relate directly to property nature.
However, there's a property-related explanation. The stream was already activated by the flatten() operation ('model2' behaviour) therefore all events '1', '2' and '3' have gone missing before first subscription, except that the property nature inherited by flatten() means it retained the last event '3'. I'm not sure this is ever what is wanted, though. On this analysis it seems that the design of flatten() means that it's actually impossible to catch all the events flattened from a Property which is surprising.
In the alternate sequentially(...) initialisation of the stream, an onValue subscriber is added before the first event was issued by the property, and therefore the flattened events are able to be detected by the onValue subscriber.
I thought that each step in the pipeline was only subscribed when it was activated (e.g. a downstream subscriber was added), and that transformations didn't themselves count as subscribers or activate the pipeline, so that's why the behaviour was so confusing to me.
In my use of Kefir Properties I very often employ them as syntactic sugar for an event which may have already happened, and may go on to happen several times in the future (meaning I don't have to handle the cases differently). For this reason, I definitely favour behaviours in which an event coming from a Property and an event coming from a Stream are normalised, preferably by default or if necessary by some workaround.

With respect to the alternative fixes you described...
I don't understand why Property nature would be inherited through observable transformations. At any point that you want to re-assert Property nature explicitly, you can do so with toProperty(), so it seems surprising. I understood toProperty as creating a derived stream which serves a single cached event to each new immediate subscriber, but that a Property continues to present itself as a stream without any additional affects on downstream subscribers beyond that serve-cache-on-immediate-subscribe behaviour. My preference would be to avoid property nature inheritance by transformed observables to avoid surprising model3 sequences, which are neither one or the other. However, I recognise I may not really understand the issues here.
The toStream() transformation (where this is understood to be equivalent to wiring a stream to the onAny of an observable and hence would received cached values from Properties) would have allowed me to debug the issue (and recreate the less surprising model2 behaviour), but it's still model1 flatten behaviour that I need which seems impossible by any transformation route at the moment.
I think the only chance of getting model1 behaviour is based on end-to-end lazy subscription (where the flatten() call doesn't itself activate the upstream source until a downstream onValue() is subscribed). If flatten() activates upstream, then the events have already gone. If the opposite assumption is baked into the Kefir library then I understand this won't be easy to achieve.
Sorry for lots of comments. If you're not actively working on Kefir it must be a pain, sorry. I find the library to be excellent, though (and well documented), so I'm very keen to continue building on it.

I've been working on the assumption that flatten() wouldn't activate its upstream Kefir.constant() until the first onValue() subscription was made. Is this false?

It activates upstream only after first onValue()

Is flatten() itself counted as a subscriber?

Well, it activates upstream by subscribing to it :)

Does this subscription behaviour apply to all observable transformations?

Sort of, when you apply a transformation, you create a new observable, that will subscribe to original one on activation.

It's the fact that the value assignments of 1 and 2 are missing which is confusing, and doesn't seem to relate to the notion of Property directly. I think it would be fine that the property still has a single current value, but I'd expect in this case that the value is assigned first to 1, then 2, then 3 after the first onValue subscriber was added.

Probably there is a misunderstanding of what I meant by property having single current value. I call "current" all values, that an observable emits immediately (synchronously) to a new subscriber right after it passed to onValue. Currently it's guaranteed that when you subscribe to a property, you'll at most one such value.

If you modify the example to replace the declaration var source = Kefir.constant([1,2,3]) with var source = Kefir.sequentially(0, [[1,2,3]]).toProperty(); all cases then conform to the expected 'model1' behaviour, suggesting the consumption of earlier events by flatten and withHandler doesn't relate directly to property nature.

With .sequentially(0, [[1,2,3]]).toProperty() you create a property with empty current value — it won't emit [1,2,3] to the first subscriber immediately, but will emit it after 0 timeout as a normal value.

I thought that each step in the pipeline was only subscribed when it was activated (e.g. a downstream subscriber was added), and that transformations didn't themselves count as subscribers or activate the pipeline, so that's why the behaviour was so confusing to me.

Yeah, that correct. All observables subscribe to their sources only on activation, and unsubscribe on deactivation. Thant conventions followed pretty strictly in Kefir.

I don't understand why Property nature would be inherited through observable transformations.

Take a property that represents a current value of a form input. Then suppose you want a property that represents a value of input multiplied by 2, you do mult2 = inputValue.map(x => x * 2). Does that makes sense? Properties are designed to represent values changing over time, when you always can say that a currently the value is X: input values, current scroll position, current mouse position, latest server response etc.

Sorry for lots of comments. If you're not actively working on Kefir it must be a pain, sorry. I find the library to be excellent, though (and well documented), so I'm very keen to continue building on it.

No problem, but I'd appreciate if questions would be more shorter. I indeed don't have much time to answer them :)

One more time what happening in constant([1,2,3]).flatten():
constant([1,2,3]) creates a property that will emit [1,2,3] to the subscriber immediately (what we call a current value, and what marked as current in .log)
prop.flatten() will create an inactive property, with prop as the source.
when you subscribe to prop.flatten():

it'll activates,
subscribe to prop,
get [1,2,3] from it,
apply transformation to [1,2,3], which results in 3 values 1, 2, and 3
as a result property will get 3 values in the immediate onValue subscriber call — i.e. 3 current values
property will ignore first 2 current values, and save 3 as it's current
property will call it's subscriber with 3

Brilliant detail and thanks. I can see the core ideas, definitely.

Currently it's guaranteed, that when you subscribe to a property, you'll get at most one such value.

The intention that a downstream onValue from an upstream Property would have to re-impose Property contracts (e.g. it would have to be a property, and would have to issue no more than one event in onValue), could be the issue here. This seems optional and potentially costly in terms of the surprising behaviours it introduces.
If you think of a Property as a behaviour explicitly requested at a single point in a pipeline, (i.e. a request to 'cache here'), rather than as an observable nature which continues through transformations and automatically reappears at later points in the same pipeline, then I think a lot of these issues go away.
At any later point where another 'onValue cache' is required, you can put one in with another toProperty(). Before our discussion (and my understanding more of your intent) I would have imagined the following would be required for a multiplied-by-two property (based on the idea of Property being a cache in a stream pipeline). I think it is more explicit and less surprising.
var singleProp = ....toProperty();
var mult2Stream = singleProp.map(function(value){ return value * 2;});
var mult2Prop = mult2Stream.toProperty();

For many purposes, the mult2Stream would end up with Property-like behaviour anyway, since when mult2Stream had its first onValue() call, then it would call onValue on singleProp, and get issued with its first event immediately. However, if you wanted a later onValue call to your mult2Stream to also re-trigger the last multiplied value, then you'd have to be explicit about making that a property instead, like mult2Prop.
FOR INTEREST
Any Kefir.stream() strategy can be expected to deliver a series of events triggered by an onValue, so it's hard to know what committing to the 'single-event' aspect of the contract really buys you.
Incidentally, multiple events triggered a downstream onValue() call is typical of scenarios in my project work, which may be why I'm hitting these issues a fair amount.
As an example of using Kefir.stream triggered by onValue, I have this fragment (tweaked for readability) in the library I'm building to allow subscribers to traverse all available topics now and in the future through a 'catchup' stream, dedicated to a single subscriber, but which falls back to the generic shared topic stream after traversing existing values, meaning they get up to date, and then handle later events in synchrony with other handlers against the shared stream...
    pastTopicAdded:function(){
        var tree = this;
        return Kefir.stream(function(emitter){
            _.forEach(Object.keys(tree.items), emitter.emit);
            emitter.end();
        });
    },
    catchupTopicAdded:function(){
        return Kefir.concat([this.pastTopicAdded(), this.topicAdded()]);
    },

If each transformation would return a stream, you'll lose propagation of current value, as stream provide current value only to the first subscriber, which consumes it.
function getScroll() {
  return document.body.scrollTop
}

var scrollTopProp = Kefir.fromEvents(document.body, 'scroll', getScroll).toProperty(getScroll)

var plus1 = scrollTopProp.map(function(x){return x+1})

plus1.log('a')
plus1.log('b')

// a <value:current> 753
// b <value:current> 753

If map would return a stream the output would be:
// a <value:current> 753

Certainly if map returns a stream, the output would be as you suggest, but I'm confused why this is a bad thing. It seems trivial to reintroduce Property contract at any point you choose in the chain. This is most likely where I've missed something huge, if this contract can't be consistently delivered later in the chain then that would explain the design decision and if so, then sorry again for useless noise.
To explore my own assumptions, I implemented the 'mapStream' alternative in the example below, which does indeed create a single event as you warned (log 'b' produces nothing when you run the second commented construction of plus1).
But I found simply extending the construction of my 'mapStream' with an explicit toProperty() call provides exactly the same as the original, but more explicitly and enabling us to avoid the fallout from Property nature inheritance in every Observable transformation (especially given there's no toStream() call available in the API). Am I missing something which means that this isn't always so trivial to do?
var Kefir = require("kefir"),
    events = require("events");

var evtSource = new events.EventEmitter();
function getScroll() { return 399; }

var scrollTopProp = Kefir.fromEvents(evtSource, 'scroll', getScroll).toProperty(getScroll)

scrollTopProp.mapStream = function(fun){
    var thisStream = this;
    return Kefir.stream(function(emitter){
        var handler = function(event){
            if(event.type ==="value"){
                emitter.emit(fun(event.value));
            }
            else{
                emitter.emitEvent(event);
            }
        }
        thisStream.onAny(handler);
        return function(){
            thisStream.offAny(handler);
        }
    })
};

//var plus1 = scrollTopProp.map(function(x){return x+1}) //original with property nature contagion
//var plus1 = scrollTopProp.mapStream(function(x){return x+1}) //stream-oriented alternative
var plus1 = scrollTopProp.mapStream(function(x){return x+1}).toProperty(); //stream-oriented alternative with explicit property request - equivalent result to property contagion case

plus1.log('a')
plus1.log('b')

Results in...
a <value:current> 400
b <value:current> 400

Currently we seem stuck with Properties once they are Properties through whatever transformations (especially in the absence of toStream()).
I don't fully get why there's a cost to having a stream result as the default from every Observable transformation, and there certainly seems to be a number of costs to having "Property-nature contagion" as the default. Surprising and unexpected results seem to follow from the expectation that the result of e.g. flatten should always implicitly satisfy Property nature just because the upstream observable has Property nature. 'Always results in a stream' seems parsimonious and harmless as far as I can see, although any breaking change to an API is a little terrifying.
Sorry if the word contagion sounds really negative, but it's intended to be purely descriptive - it seems to capture the irreversible downstream Propertyness when using the standard API.  At least I didn't mention zombies :)
MY OWN EXAMPLE
In my case, I'm relying on Properties to cache the last value of a remotely-served list of ids. I was expecting to use diff and flatten to be able to generate streams of events of 'single ids added', and 'single ids removed' even when multiple ids were actually added or removed by a remote update. Such updates could come either before or after subscription and activation. Of course because I'm using a Property, (so that any previously retrieved list can be accessed instantaneously without a round-trip), I'm now concerned there will be unexpected side-effects in the behaviour of diff and flatten.  Having the confidence that all transformations produce a realtime stream without a cache or Property contract enforcement (and assuming that the 'toProperty()' trick always works in case a cache is actually needed) would give me a lot of confidence to predict how the pipelines I'm creating would behave.

Certainly if map returns a stream, the output would be as you suggest, but I'm confused why this is a bad thing. It seems trivial to reintroduce Property contract at any point you choose in the chain. This is most likely where I've missed something huge, if this contract can't be consistently delivered later in the chain then that would explain the design decision and if so, then sorry again for useless noise.

Yeah, this the case. It can't be consistently delivered later. For example (supposed map returns a stream):
var prop1 = ...
var stream1 = prop.map(...)
var prop2 = stream1.toProperty()

stream.onValue(f1) // will consume the current
prop2.onValue(f2) // won't get the current

Also I find, than in most cases I want to get a property automatically, so I'd have to do p.map(...).toProperty() all the time.
And returning same type after transformation aligns well with the algebraic data types semantics e.g. when we apply map to a functor we get a functor of same type, same for flatMap and monads. And in Kefir both streams and properties can be counted as monads and functors.
Closing as this is more like a question issue, that can't be fully resolved. But free to continue discussion. Aslo see https://github.com/rpominov/kefir/issues/142

Also #144

Also #146 :)

I think the notion of Property we're working with may be two totally different concepts so when you say 'I want to get a property automatically' I'm probably unclear as to the contract you're expecting it to meet which can't be met by the later toProperty().
The contract I'm expecting is what I thought was summarised in the existing documentation - that it provides a cache of the last-served value.
So if the Property wasn't activated at the time a value was issued, then the value wasn't served, and hence it wasn't cached. I understood this was pretty common in cases of creating Properties already, (the toProperty() calls in my library are very often toProperty().onValue(_.noop) to force values to be served for this reason.
The example you describe where property behaviour can't be delivered later seems like a case of not being subscribed at the right time, which I understood was a common userland 'bug' and Kefir feature, as per e.g. https://github.com/rpominov/kefir/issues/125
The idea userland bugs like this should be solved through defaults in the Observables API (the 'current' value reaching forward through the pipeline) appears a challenge to consistency.
I am definitely missing something fundamental and should probably puzzle more before bothering you again as all the cases you describe as a problem seem absolutely the right behaviour to me which must mean I have the wrong model.


updated VM storage support - Ephemeral disk data

@ThalathBhagya : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@ThalathBhagya: I'm sorry - only the author of this article, @rayne-wiselman, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Hi @ThalathBhagya
Microsoft authors and contributors need to make content contributions through the private repository so the content can be staged and validated by the current validation rules.
After you review staging and fix all validation issues, you can add the sign-off comment to let PR reviewers know that the updates are ready to be merged.
For more information, see Should I work in a private or a public repo?
Would you create a pull request in the private repo to make these updates? We'll close this PR. Thank you.


HBASE-22421 update ruby used to run rubocop on branch-1 to 2.5

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2687/1/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
7m  1s
Docker mode activated.

_ Prechecks _

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

+0 :ok:
hadolint
0m  0s
hadolint was not available.

+0 :ok:
shelldocs
0m  0s
Shelldocs was not available.

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

_ branch-1 Compile Tests _

+0 :ok:
mvndep
2m 32s
Maven dependency ordering for branch

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 10s
Maven dependency ordering for patch

+1 :green_heart:
shellcheck
0m  0s
There were no new shellcheck issues.

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

_ Other Tests _

+0 :ok:
asflicense
0m  0s
ASF License check generated no output?

10m 53s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2687/1/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense hadolint shellcheck shelldocs

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

Build tool
maven

Personality
/home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-2687/out/precommit/personality/provided.sh

git revision
branch-1 / a0f55cd

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

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2687/1/console

versions
git=1.9.1 maven=3.0.5

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

This message was automatically generated.

Yep, that did it. Let me fix the commit message...

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2687/2/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 51s
Docker mode activated.

_ Prechecks _

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

+0 :ok:
hadolint
0m  0s
hadolint was not available.

+0 :ok:
shelldocs
0m  0s
Shelldocs was not available.

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

_ branch-1 Compile Tests _

+0 :ok:
mvndep
2m 34s
Maven dependency ordering for branch

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 10s
Maven dependency ordering for patch

+1 :green_heart:
shellcheck
0m  0s
There were no new shellcheck issues.

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

_ Other Tests _

+0 :ok:
asflicense
0m  0s
ASF License check generated no output?

5m  1s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2687/2/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense hadolint shellcheck shelldocs

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

Build tool
maven

Personality
/home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-2687/out/precommit/personality/provided.sh

git revision
branch-1 / a0f55cd

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

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2687/2/console

versions
git=1.9.1 maven=3.0.5

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

This message was automatically generated.

Oops, this is a dup of #2686. Closing


Reload Window while debugging will not stop the current debug process

Observed this behavior, while debugging a simple HTTP service in Windows. While debugging, I called reload window and try to debug again. This fails with the port already in use error.

@NipunaRanasinghe Is there a way to kill the service's process if the debug stop request is not sent?

@NipunaRanasinghe Is there a way to kill the service's process if the debug stop request is not sent?

@prabushi @hasithaa As it seems like the mentioned issue is not reproducible on Ubuntu or Mac, I suspect this could be a windows-specific issue. I will give a further update after debugging the debug server on windows.

Closing with https://github.com/wso2/ballerina-plugin-vscode/issues/86