Fix panic when ctr exec contains no command

Normal exec should be ctr exec --id xxx --pid xxx command, if user
forget to input command, runv-containerd panics.
Signed-off-by: Zhang Wei<EMAIL_ADDRESS>Part of panic log:
panic: runtime error: index out of range

goroutine 38 [running]:
github.com/hyperhq/runv/hypervisor.stateRunning(0xc820284120, 0x7f64e419d218, 0xc820301360)
	/home/darcy/gocode/src/github.com/hyperhq/runv/hypervisor/vm_states.go:716 +0x1c08
github.com/hyperhq/runv/hypervisor.(*VmContext).loop(0xc820284120)
	/home/darcy/gocode/src/github.com/hyperhq/runv/hypervisor/hypervisor.go:30 +0x4c1
github.com/hyperhq/runv/hypervisor.VmLoop(0xc820226b90, 0xd, 0xc82024c300, 0xc82024c360, 0xc82023eaf0)
	/home/darcy/gocode/src/github.com/hyperhq/runv/hypervisor/hypervisor.go:49 +0x1e9
created by github.com/hyperhq/runv/hypervisor.(*Vm).Launch
	/home/darcy/gocode/src/github.com/hyperhq/runv/hypervisor/vm.go:51 +0x19e

goroutine 1 [chan receive]:
main.daemon(0xc82010f860, 0x24, 0xc820138aa0, 0x14, 0xc820138ac0, 0x15, 0xc820138ae0, 0x1f, 0x0, 0x0)
	/home/darcy/gocode/src/github.com/hyperhq/runv/containerd/main.go:141 +0x3f2
main.main.func1(0xc8200d8780)
	/home/darcy/gocode/src/github.com/hyperhq/runv/containerd/main.go:115 +0x513
github.com/codegangsta/cli.(*App).Run(0xc82008ef20, 0xc82000a120, 0x6, 0x6, 0x0, 0x0)
	/home/darcy/gocode/src/github.com/hyperhq/runv/Godeps/_workspace/src/github.com/codegangsta/cli/app.go:201 +0x13d8
main.main()
	/home/darcy/gocode/src/github.com/hyperhq/runv/containerd/main.go:120 +0xe6

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

goroutine 5 [syscall]:
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
	/usr/local/go/src/os/signal/signal_unix.go:28 +0x37

goroutine 9 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0xf84260)
	/home/darcy/gocode/src/github.com/hyperhq/runv/Godeps/_workspace/src/github.com/golang/glog/glog.go:882 +0x67
created by github.com/golang/glog.init.1
	/home/darcy/gocode/src/github.com/hyperhq/runv/Godeps/_workspace/src/github.com/golang/glog/glog.go:410 +0x297

goroutine 10 [select, locked to thread]:
runtime.gopark(0xb8c938, 0xc820029728, 0xa72340, 0x6, 0x18, 0x2)
	/usr/local/go/src/runtime/proc.go:185 +0x163
runtime.selectgoImpl(0xc820029728, 0x0, 0x18)
	/usr/local/go/src/runtime/select.go:392 +0xa64
runtime.selectgo(0xc820029728)
	/usr/local/go/src/runtime/select.go:212 +0x12
runtime.ensureSigM.func1()
	/usr/local/go/src/runtime/signal1_unix.go:227 +0x353
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

    ...

which command will be invoked when the command is not specific?

Reproduce steps:
$ sudo ctr --address unix:///run/runv-containerd/containerd.sock containers start busybox /tmp/busybox-runv/

$  sudo ctr --address unix:///run/runv-containerd/containerd.sock containers exec --pid busybox-exec --id busybox

Note that correct exec should be:
$  sudo ctr --address unix:///run/runv-containerd/containerd.sock containers exec --pid busybox-exec --id busybox  sh

which command will be invoked when the command is not specific for docker/containerd?

You mean default command? I think there's no default command, if the command is not specific, containerd will report error:
[ctr] rpc error: code = 2 desc = "containerd: container did not start before the specified timeout"

so, could you check it in the supervisor/process.go and report/return error when the args is not specific?

OK. I'll do it.

I made a mistake, the correct error message should be "args cannot be empty".
This is consistent with docker/containerd. Already fixed.


Fail to delete folders from one attached bob container via RBAC

Storage Explorer Version: 1.8.1_master_20190610.4
Platform/OS: Linux Ubuntu/macOS High Sierra/Windows 10
Architecture: ia32/x64
Regression From: Not a regression
Steps to reproduce:

Give RBAC access to a container to a user like 'Blob Data Owner Role'.
Attach the blob container via RBAC(For non-adls gen2 blob containers).
Expand 'Local & Attached' -> Storage Accounts -> (Attached Containers).
Open the attached blob container -> Upload one folder to it.
Try to delete the uploaded folder -> Check the result.

Expect Experience:
Succeed to delete the folder.
Actual Experience:
Fail to delete the folder even though the attached blob container has been given Owner permission.

More info:
This issue doesn't reproduce for one attached adls gen2 blob container via RBAC.

Fix merged into master. Please test the following from an attached via RBAC container to help verify this fix:

Delete
Upload (non-AzCopy)
Download (non-AzCopy)
Undelete


Fix sampled data not used

The result_pca RDD is sampled however it was not previously used for the subsequent 3D scatter plot.

thank you very much! [x] merged


Deploy with graphics

Updates deployment scripts to only bring in graphics via LFS. Also updated desktop background and removed some unused icons.
Please follow instructions this page
to test deployment.
Some lines will need to be changed before merging to master.
Closes #1277
Self-review checklist:

[x] Self-review: looked through the Files changed tab, browsed repository in branch
[x] Documentation updated - reflects changes in code, electrical or mechanical design
[x] Documentation and graphics follow the documentation style guide
[x] New content is linked, easily discoverable, does not require too many clicks
[x] Follows other relevant parts of contributor wiki
[x] PR has a descriptive name
[x] Tagged relevant reviewers

Software only:

[x] Follows our code style
[x] Commented code, particularly in hard-to-understand areas
[x] All tests pass - new and old, locally and on CI
[x] No new warnings or static check failures
[x] Tests that prove fix is effective or new feature works
[x] Manual tests are explained, with instructions for reproducing them

failing to build controller on RasPI
admin@rw-ventilator:~/ventilator/software/utils/rpi_config $ ./update.sh
Continuing with update...
Already up to date.
Building and deploying cycle controller...
Removing .pio
~/ventilator/software/controller ~/ventilator/software/controller
Deploying: stm32
Processing stm32 (platform<EMAIL_ADDRESS>board: custom_stm32)
--------------------------------------------------------------------------------
Tool Manager: Installing platformio/tool-dfuutil @ ~1.11.0
Error: Could not find the package with 'platformio/tool-dfuutil @ ~1.11.0' requirements for your system 'linux_aarch64'

@asmodai27 any idea what the problem might be?

any idea what the problem might be?

TLDR: ststm32 platform relies on dfu-util for some of its functions (which I don't think we use), but this bring a dependency that is not yet available for linux arm64. We can either roll back to an old version of ststm32, or compile dfu-util ourselves on th pi and submit it to platformio team for integration to their registry.
This looks a lot like https://community.platformio.org/t/ststm32-could-not-find-the-package-with-platformio-tool-dfuutil-1-9-190708-requirements-for-your-system-linux-aarch64/24059
Albeit with a different version.
Also look at related platformio issue.
Looks like we have to either:

build dfu-util 1.11 on the pi and submit it to platformio for integration to their package registry
roll back to an old ststm32, which uses a version of dfu-util available for linux aarch64

I'll try to build the library myself, and see what to do from there.

Successfully built the package following instructions in the aforementioned thread. Asked platformio community how to share the package: https://community.platformio.org/t/ststm32-dfuutil-missing-for-linux-aarch64/28669

Works now!


Address security issues in analytics python code

See https://github.com/DataBiosphere/data-browser/security/dependabot and
https://github.com/DataBiosphere/data-browser/pulls
See if we can upgrade the python packages to remove these errors.

@hunterckx can you look at the specific GH pull requests and see if they can be applied?
Thx

Complete Thanks @hunterckx


Causing a panic by accessing arr out of range doesn't pass the test

I've been running through the koans today and came across an issue with the array out_of_index Koan. If I try to access an arr index that is out of bounds instead of passing the test I am presented with this error.
error: index out of bounds: the len is 5 but the index is 5
  --> src/koans/array.rs:25:5
   |
25 |     arr[5];
   |     ^^^^^^
   |
   = note: #[deny(const_err)] on by default

error: aborting due to previous error

In order to get the test to pass I have to call a panic! myself like this
#[test]
#[should_panic]
fn out_of_index() {
    let arr: [&'static str; 5] = ["rust", "is", "mostly", "for", "nerds"];
    panic!("panic");
}

It might just be I'm doing it wrong, or my rust version as I am running 1.29.0, or of course the #[deny(const_err)] config but I thought I'd bring it up.
Sorry if this is in the wrong place!

You're correct. They added a lint to catch this common error in the time since the koans were written. When I do the 2018 edition update, I will re-work this one. Thanks for the report!

Thanks to a tip from @shepmaster, the solution I used was:
    let i = 5;
    arr[i];

I thought it was a clever test used to find the limits of the linter. That is, "how do you force a panic?"

I ended up using
arr[arr.len()];

That worked too.

Looks like this issue has been fixed in a recent update so I'll close the issue, thanks for everyone's input!

FYI, this is still an issue with latest rust release rustc 1.34.2 (6c2484dc3 2019-05-13)

FYI#2, it is still an issue with:rustc 1.51.0 (2fd73fabe 2021-03-23)


how to add and use custom sensor

I'm now trying build my custom fish-eye sensor from Unity. What should I do after building to the assestbundle? How can I add it to the cloud and use it sensor configuration?
Thanks for answering.

Hi, @nanali0126, thanks for posting.
Unfortunately, I was not very familiar with adding new sensors to SVL, therefore you might need to investigate yourself.
You should take a look at the data structure for sensors stored in MongoDB and create something similar.


Support indirect/multi-leg currency conversions ( A->{Bridge Currencies}->B )

Expected Behavior

The system is able to handle currency pairs that are not directly convertible into the account currency
Actual Behavior

The system is unable to perform currency conversions if it can't find a direct pair leading back to the account currency. On crypto exchanges, it's normal fare for currencies/tokens to not be directly convertible to fiat of any kind, for example, on binance no coins are directly convertible to fiat (USDT doesn't count :) ). In such cases we need to move through a 'bridge' currency, such as BTC and then can use a BTCUSD rate (maybe even a BTCUSDT if it's the best available), in order to price securities in terms of dollars (or whatever your account currency may be).
This can get unwieldy if you consider the above example but for an account currency of EUR. We now would require three 'legs', an additional one to move from USD (or USDT) to EUR, unless of course the exchange provides a BTCEUR pair of it's own to skip the USD middleman.
Potential Solution

The below may have spiraled into stream of consciousness but I think the comments shed some light on some potential issues/solutions/paths forward so it's left unaltered.

I think to start we should list the various concerns and cases. The main issue I see here is that it's potentially unbounded (the number of potential paths from A->...>B) and may also be temporal, IOW, if there's multiple paths how do you choose which path is the right one (and be consistent!), so things like using market cap (or volume) to give preference to particular currencies to act as 'bridge' currencies can lead to different paths depending on market movement (which might actually be the right thing to do?).
Another thought is first limiting the unbounded aspect (say max of 3 hops? A -> Bridge1 -> Bridge2 -> B, maybe 4?) and could compute a range of potential conversion rates and pull the mean (would require some work to how we pull conversion rates)... I think in all cases the fact that we currently use the security's current price for the conversion rate should be decoupled so that there's a component that provides conversion rates (perhaps IConversionRateProvider) and he just so happens to be initialized with some securities, so a refactoring step could be creating this abstraction and implementing for the existing direct case A->B and then expand on that for cases where we require multiple hops.
Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching issues

I was thinking about this before.
We are dealing with graph with bidirectional connections.
Assets ETH, USD, REN are nodes. Pairs ETHUSD, ETHREN are connections between nodes.
Connections are not just string/name of pair, but also hold some sort of List<T>, where T is object that contains IBrokerage, Price, Volume.
For calculating most precise conversion between assets, for example RENUSD, we can use Max flow algorithm.
Souirce node is REN, Sink node is USD.
Define Volume as a max flow through connection.
So ok, you run Max Flow algo, and you have now defined Flow on each connection.
Flow can be positive or negative, depends what is meant in each step, like RENETH (positive) or ETHREN (negative)?
Now, what is next step I am not sure, but it probably involves calculating PriceStep = Price * Volume * Flow.
And then somehow you need to propagate PriceStep again (maybe second iteration with MaxFlow) to get final result.
Will give more thought to this later, ok :)

Reserved for concerns.
Possible concerns:

Market manipulations, wash trading (fake volume), pump & dumps
Brokerages can get offline for time being, that shouldn't mess with multi-leg conversion

Suggestions:

ConversionRateProvider object should be customizable, at-least by picking from what brokerages ticks should be pulled.

I think to start we should list the various concerns and cases. The main issue I see here is that it's potentially unbounded (the number of potential paths from A->...>B) and may also be temporal, IOW, if there's multiple paths how do you choose which path is the right one (and be consistent!), so things like using market cap (or volume) to give preference to particular currencies to act as 'bridge' currencies can lead to different paths depending on market movement (which might actually be the right thing to do?).

So ok, this one may not be so hard. I came up with something:
You have graph G with bidirectional connections. G holds all known assets and pairs.
Remember, node is asset, connection is pair.
You have X node and Y node. Example X = REN, Y = USD.
X and Y represent target pair you want to calculate.
And then you have list P. This list holds Paths, for example REN-ETH-USD.
Ok, now all you do is repeat this process:

Find shortest path p from X to Y in graph G. If none found, terminate.
Remove path p from G (remove connections), and add it to list P (nodes and connections)
Go to step 1.

That is, you should be left with all possible paths. The graph G will be left with un-related pairs and could be removed.
And p shouldn't hold any non-sense paths like 'REN-ZRX-ETH-BTC-USD'.
I am not sure what is metric/heuristic d(x,y) for shortest path yet, it can just be "hops between X and Y", or if it should include volume.

Link to the branch connected to this issue, just to show current progress.
https://github.com/viliwonka/Lean/tree/feature-2060-multi-leg-currency-conversion
It's still in rough shape, still deciding how to execute this elegantly as possible - least modifications in lean source code, and some things are not seen in the code - "still on paper".


RSS: parallel-fetch the stream urls

Issue
Users are seeing timeout with the RSS calls.
Results

Before:

After:

Aside
Even before this PR, inf seems to produce the results significantly faster than odysee.com.
CF messing things up?

Interesting that it's faster on inf...not sure how to explain that.


better-sqlite3 doesn't plays nicely with jest

Opened up a issue on their repository but wanted to bring into your notice too - https://github.com/facebook/jest/issues/3931

Error -
TypeError: Cannot redefine property: MAX_VALUE
        at Function.defineProperty (<anonymous>)

      at defineStatic (node_modules/integer/index.js:14:9)
      at Object.<anonymous> (node_modules/integer/index.js:7:1)
      at Object.<anonymous> (node_modules/better-sqlite3/index.js:3:26)
      at Object.<anonymous> (tests/random.test.js:1:107)
          at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:169:7)

Interesting. Thanks for bringing this to attention

@JoshuaWise could you look at this comment and tell if it's feasible to remove Integer lib from sqlite?

I suppose it's possible in the next major release. It seems odd that I should reduce the convenience of this package in order to work around package's bug, though.
I'd be more interested in getting jest to support native module resolution.

I'm going to drop jest and close this issue. Been waiting for close to a month, its just better to use some alternative testing framework. I'll still keep the issue on their repo open till they fix it, No such need to drop Integer library @joshuawise :+1:


feat: Adds pip freeze to several sessions in the noxfile to aid in troubleshooting

Adds the pip freeze command to several sessions in the noxfile to aid in troubleshooting.
When tests fail, especially with older versions of the code it is sometimes useful to know what versions of the dependencies have been installed.

The prerelease failure is a known entity. It is being handled in another Issue/PR.
In fact, this PR is being incorporated to help enable better troubleshooting in issues such as that one.

system-3.9 seems to be failing due to connection flakiness

system-3.9 seems to be failing due to connection flakiness

This is the known problem I reference above and has been consistent for many days.
I have a second PR that will hopefully correct that problem, but I am waiting on this to merge to help with some of the debugging.

FAILED tests/system/test_gbq.py::TestReadGBQIntegration::test_timeout_configuration appears unrelated. I'll see if I can use some admin powers to merge.


udpated the scroll bar

done the work which you assign me please review it and merge it the issue was #533

@harshalhonde21 Few Changes I would like to suggest:

Create a separate branch and raise a PR from it.
Make the color on scrollbar light and try to make it with theme.

okk, I will do the changes which you suggest and generate the PR with separate branch

Okay. Closing this one.


Removed infra changes from dm

Change description
Remove infra changes.
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

No longer required, upgraded terraform azurerm


ReleaseDetails doesn't open

Describe the bug
Opening ReleaseDetails causes endless loading.
To Reproduce
Steps to reproduce the behavior:

Go to Releases
Click on any release
See endless loading

Expected behavior
Should open details
Additional context
Regression of #4653
Fix almost done.

Relates to: https://github.com/lensapp/lens/pull/4653#issuecomment-1012510693


Callback stuck on auth.process_response

backend: Fast API
frontEnd: Next.js
python3-saml version 1.15.0
Hi, I am using python3-saml for SSO implementation in my project which successfully takes me to the login page, Once I enter my credentials press login button it triggers callback function which gets stuck on this line "auth.process_response"

I am having this same issue.

Can you add a debugger and see where inside the process_response got stuck?

Hi, I was able to get that issue resolved by downgrading the lbxml library from version lxml==5.1.0 to lxml==4.9.4. However, now I have another issue. When I try to get attributes I am unable to get email, can this be configured in settings.json, advanced_settings.jscon or in saml.py?

---

I was able to get that issue resolved by downgrading the lbxml library from version lxml==5.1.0 to lxml==4.9.4

Have you tried to install the lxml library as follows:
pip install --force-reinstall --no-binary lxml lxml

When I try to get attributes I am unable to get email

It seems the IdP is providing username, eduPersonScopedAffiliation, firstname, lastname, fullname but not the email.
You will need to contant the IdP administrator and ask them to release the email info in the SAMLResponse.

lxml==4.9.3 works, thx for saving my day.

I had this issue with a Django 4.2 app. I can confirm that installing lxml via pip install --force-reinstall --no-binary lxml lxml seems to have fixed it. @pitbulk do you have any insight into why the binary package for lxml doesn't work? We prefer to use binaries in our build pipeline when possible.
I can also confirm that downgrading to lxml==4.9.4 also worked for us. That's what we're using in our build at the moment.

@smaccona if you search in the Issues section there were tons of issues recently with the lxml version for different reasons.
The main issue was due to incompatibilities with libxml2.
@NeuraByte-UCSD-ITS , you should not be using async calls for the SAML handshake.


Adding prelude and update changelog commands for DCA

Signed-off-by: charlyF<EMAIL_ADDRESS>What does this PR do?

clean up the releasenote-dca folder that was located in the agent's one and other relno not in the /notes.
Add command to create a prelude for a DCA release (differs from the agent's with the URL to link the changelog of the version we pin to). Usage inv release.add-dca-prelude 1.9.1 7.23.1 and inv release.add-dca-prelude 1.9.0 7.23.0 --agent6-version=6.23.0 in case of a minor release associated with 6 and 7.
Add command to update the DCA changelog. Differs from the agent as I could not use the --earliest-release flag (I think it's because dca-1.X.Y is not semver). As we sync DCA releases with the agent's, we can use the devel tag to identify when the new release dev started and the branch to only use the relnos in the releasenote-dca folder (that needs to be specified in the command). Usage: inv release.update-dca-changelog 1.9.1 7.23.1 (need to clean the tag from dca-1.9.1 to 1.9.1, but not a big deal).

Motivation
I first want to get a pre-approval on the process as there is some overlap with the commands for the agent, happy to refactor if deemed necessary.
Additional Notes
Documentation to come after. I am going to release 1.9.1 as the 7.23.1 has a fix that affects the DCA.
Any objection in simply referring to the agent's changelog to avoid duplicating the relnos in both folders?
Notes on the workflow:

Banch off 7.A.x is in sync with the branch off of dca-1.B.X
DCA tag, changelog gen and release of minor (subsequently to the agent's)

Now, if there is a bugfix for the agent that does not affect the DCA, we don't make a bugfix release.
However, if subsequently there is one, we rebase off of the most recent and make a bugfix release, this can lead to a changelog for dca-1.9.1 pointing to the 7.23.5 (if the first 4 bugfixes were not relevant).
Describe your test plan
During the next release, follow the doc, if the changelog is A-OK -> ✅

Are we GTG @KSerrania ?

Yes this is something I have documented. On mac sed does not support the --null-data so we will still need manual action.
I added a sed to do the magic on non darwin distros.


Refactoring documentation contribution point

Problem
Many language/extension implement really cool refactorings, but many users never discover these or figure out how to reliably trigger them.
Proposal
Add a way for an extension to contribute documentation for their refactorings. Our goal here would be to help users reach the documentation and leave the presentation of the documentation up to extensions themselves.
Target UX
Let users explicitly request to see the refactoring documentation from the existing code action refactor menu. This could be as simple as a Learn more entry at the bottom of the refactoring menu.
The learn more action would do the following:

If we are in a language that only has one refactoring documentation provider, then show that documentation directly
If we are in a language with multiple refactoring documentation providers, show a quick pick so that users can tell us which documentation they are interested in (this is similar to how our remote documentation works today)

API
Current proposal
The current proposal is the add a documentation field to CodeActionProviderMetadata that let's extension surface a command that shows documentation:
export interface CodeActionProviderMetadata {
	/**
	 * Static documentation for a class of code actions.
	 *
	 * The documentation is shown in the code actions menu if either:
	 *
	 * - Code actions of `kind` are requested by VS Code. Note that in this case, we always pick the most specific
	 *  documentation. For example, if documentation for both `Refactor` and `RefactorExtract` is provided, and we
	 *  request code actions for `RefactorExtract`, we prefer the more specific documentation for `RefactorExtract`.
	 *
	 * - Any code actions of `kind` are returned by the provider.
	 */
	readonly documentation?: ReadonlyArray<{ readonly kind: CodeActionKind, readonly command: Command }>;
}

original proposal
I see two possible ways this could be implemented:
Through a contribution point
Create a new documentation.refactoring contribution point that lets extension define a command that shows the documentation:
  "contributes": {
    "documentation": {
      "refactoring": [
        {
          "title": "%documentation.refactoring.title%",
          "when": "typescript.isManagedFile",
          "command": "_typescript.learnMoreAboutRefactorings"
        }
      ]
    },
}

Through a new refactor.documentation code action kind
Define a special code action kind called refactor.documentation. If an extension returns a code action with this kind, then we could surface this using some special UI in the refactor menu
(extensions would be expected to return the refactor.documentation action whenever refactorings are requested)
/cc @kieferrm
/cc @jrieken for api
/cc @misolori for ux

@akaroml @DanTup Also interested to hear if this is something you would find helpful for your extensions and if you have and other ideas about how this documentation could be presented

I don't know that I have the data to populate this, though the idea sounds good to me.
I think there many other places that exposing docs would be great - I opened https://github.com/microsoft/vscode/issues/71541 previously, but there it was resolved as a dupe of another case that never got a concensus on the fix (which is a shame, because I think it's a tiny change with a large impact for users).

I'm in favor of the contribution point, but both approaches work.

While the static contribution point would work perfectly, the refactor.documentation could have more potential by allowing vscode to:

Specify more context, e.g. the position where the documentation is requested
Have a special UI to show the documentation, e.g. documentation overlay without switching to another editor tab.

This also allows the language server to generate more precise documentation according to the context.
So I prefer the LSP way.

My preference is for something static but similar to the previous approaches we need to make sure that extensions can provide this - tho the approach seems to have the right amount of indirection for this.
I am wondering if there are synergies with the work we are doing around extensions adding "getting started" or "playground parts" etc?

@DanTup If you have a webpage that documents refactorings, you could link users to that. It doesn't need to be anything fancy to start off, just a list and a quick description of what each refactoring does

@akaroml Good points about the LSP support.
One other consideration with using code actions to return documentation is that other editors would likely not know what to do with the returned Refactor.documentation items besides showing them inline in the code action list (which is probably not what you want)

@jrieken I also like the idea of idea of integrating this with our other documentation exploration but worry that may take a while to finalize. Maybe we should try delivering a scoped solution that only handles code actions so that Java and others can play around with the idea, and then look into how this would fit with our larger documentation/getting started experiences?

@jrieken Thank you for bringing up the synergy idea! I do see those three approaches sharing similar goals. As an extension author, I really appreciate the platform providing a clear picture of how those UI elements can work together and serve different use cases!
And here to share some of the challenges and use cases.
Code Actions Challenges

Visibility/Discoverability
Provide a full list of what's available. And CodeAction.disabled will help serve that purpose.
Triggers
We also find it challenging for the users to figure out how a code action could be triggered. E.g. the "Invert Boolean" could be triggered by placing the cursor inside the expression, then the whole expression will be inverted because we infer the biggest possible from the cursor, or, the users can also select a part of the expression, then only the selected part will be inverted.
The challenge here is how we could educate the users about the differences. I think the discussion in this particular issue can help provide a place to document that behavior explicitly.

Getting Started

Key Binding Challenges
This is so important for experienced users. We have enough key binding extensions but the challenge here is that vscode and other editors/ides do not have 1:1 feature parity and we will have missing keystrokes for sure. And as the love for vscode grows, users would want to learn and adapt to vscode conventions.
One idea here is to let the language extension handle the missing key bindings. For example, users may try F8 to start debugging while it does nothing by default. Then the Java extension could respond by hinting the user "Are you trying to start debugging? To do so, press F5 instead.".
How to challenges
We identify common tasks that users would want to perform and provide documentation accordingly. The challenge here is how users can find them. It's like digging something in a library, and a search based tool can help.
The idea here is to allow an extension to contribute getting started documentation and users can locate those entries by typing some keywords.

 And tutorials are great for them to learn and practice. Now the best we can do is to show the documentation and an editor side by side. It's already working but it could be even better if the documentation can interact with the editor, and I see that a playground.
@mjbvz Agreed. We'll always happy to try new APIs and see how they work.

@mjbvz 👍 for moving fast. Circling in @eamodio for some "getting started" ideas that point in a similar direction

@jrieken I've changed the contribution point proposal to be more generic to better support that:
  "contributes": {
    "documentation": {
      "refactoring": [
        {
          "title": "%documentation.refactoring.title%",
          "when": "typescript.isManagedFile",
          "command": "_typescript.learnMoreAboutRefactorings"
        }
      ]
    },
}

Here's how this is rendered in practice:

@jdneo This is an enhancement to the documentation of refactoring features. Let's try it.

I'm going to push the following changes:

Added telemetry on which code actions are applied
Show the code actions in the top level light bulb menu if any refactoring code actions are returned

The telemetry was added to provide a baseline so that we can understand if documentation entry improves refactoring usage (we have had js/ts specific refactoring telemetry for a long time, but now we can measure other languages/extensions as well). To measure if the documentation entry improves refactoring usage, we probably want to  do an A/B test. There are a few options we are interest in comparing:

Refactoring usage with no documentation entry
When refactoring documentation is only shown in the refactor menu
And when refactoring documentation is shown in the lightbulb menu as well

Note: explore moving this into the CodeActionProviderMetadata for Feb

fb622a8b83c3f9fb661f7a86ffb89ccb6a2b0581 Changes it so that the documentation actually is pulled from the CodeActionProviderMetaData.
	export interface CodeActionProviderMetadata {
		/**
		 * Static documentation for a class of code actions.
		 *
		 * The documentation is shown in the code actions menu if either:
		 *
		 * - Code actions of `kind` are requested by VS Code. Note that in this case, we always pick the most specific
		 *  documentation. For example, if documentation for both `Refactor` and `RefactorExtract` is provided, and we
		 *  request code actions for `RefactorExtract`, we prefer the more specific documentation for `RefactorExtract`.
		 *
		 * - Any code actions of `kind` are returned by the provider.
		 */
		readonly documentation?: ReadonlyArray<{ readonly kind: CodeActionKind, readonly command: Command }>;
	}

Some rational for this change:

This links the documentation to a specific language (and a specific provider). Using the contribution point based approach, we had to use when clauses to emulate this

This pushes the documentation into the API, which should make it more discoverable for extension authors.

Let me know if you have any concerns / thoughts about this new proposal

For the PowerShell extension, we show a CodeAction to navigate to the particular linter rule:

Show documentation for: ...

I don't really see how this could be done client side so I'd want some way to send documentation CodeActions back from LSP.
For us, it'd be really convenient if CodeActionKind had a Documentation option or something like that with the same UI experience as you've already shown.

@TylerLeonhardt You should be looking at this: https://github.com/microsoft/vscode/issues/11847#issuecomment-578055139. Using a code action to help with a lint-message isn't what we have in mind - you should be using the new Diagnostic#code: { value: string, target: Uri }-api.
This issue is about discoverability. Often refactorings go unnoticed because you have to click the right element to see them, like "extract const" and with this item we want to make all refactorings of a language/extension more discoverable/explorable

Thanks I've +1'd that. The proposed experience seems more like a "apply this CodeAction for all diagnostics that fall into this Provider".

And I'm wondering if it's best to rather make this strictly about documentation... we make it more generic. "This CodeAction appears every time for this CodeActionProvider"

Hi @mjbvz
I was trying this new contribution point, but the when clause seems not working if I set it to editorLangId == xxx. (The learn more menu item does not show)
Other conditions like isMac works. Is this a bug?

@jdneo In VS Code, we've update the proposal to use a CodeActionProviderMetadata .documentation property instead of a static contribution. Try using that and let me know if you run into any issues

Thank you @mjbvz
In our case, the Java language server will directly return the code actions to the client so we do not have a code action provider at the client side. I tried to registered a dummy provider like following:
export class RefactorDocumentProvider implements CodeActionProvider {
    provideCodeActions() {
        return [];
    }

    public static readonly metadata: CodeActionProviderMetadata = {
        providedCodeActionKinds: [
            CodeActionKind.Refactor,
        ],
        documentation: [
            {
                kind: CodeActionKind.Refactor,
                command: {
                    command: Commands.LEARN_MORE_ABOUT_REFACTORING,
                    title: 'Learn more about Java refactorings.'
                }
            }
        ]
    }
}

No matter I return [] or undefined or [new CodeAction('dummy')] in provideCodeActions(), the document command does not appear in the context menu. Was there anything I did wrong?
I have set the enableProposedApi to true, the Insider version I use is Version: 1.44.0-insider Commit: 1876b51870e30e9ba8f35dc0dcfaf49a3799a8ef

@jdneo Your provided needs to return one or more code actions of the given type (such as refactoring) for the documentation to show up.

Thank you @mjbvz
I've tried to return a valid code action, like return [new CodeAction('dummy', CodeActionKind.Refactor)];, but still cannot see the documentation:
 🤔

@mjbvz ping...
I tried the latest Insider today but still cannot see the document command entry in the menu. Not sure if I did anything wrong.
BTW, since in our case, the CodeActions are directly returned from the Language Server, adding a dummy code action provider at client seems wired to me. Still hope that the when clause like editorLangId can work in the contribution point for refactoring document in package.json
Thank you for your time.

I've update our code action example to show how to use the documentation property: https://github.com/mjbvz/vscode-extension-samples/commit/e4b0a506dd494ab203c0dbe39327a7cf1f97137b

Our eventual goal is to integrate documentation proposal into the language server protocol as well

Thank you @mjbvz for the sample. I made a mistake that I forgot to pass the metadata when registering the code action provider. Now everything works great! And the document command can show-up even I return an empty array in the code action provider. Then we can avoid using the contribution point in the package.json.
Thank you for your help!

Hi @mjbvz, another question about the document: Code actions of kind are requested by VS Code. In this case, VS Code will show the documentation that most closely matches the requested code action kind.
Let's say I have a code action provider defined as below:
export class RefactorDocumentProvider implements CodeActionProvider {
    provideCodeActions() {
        return [];
    }

    public static readonly metadata: CodeActionProviderMetadata = {
        providedCodeActionKinds: [
            CodeActionKind.RefactorExtract,
            CodeActionKind.Refactor,
        ],
        documentation: [
            {
                kind: CodeActionKind.RefactorExtract,
                command: {
                    command: Commands.LEARN_MORE_ABOUT_EXTRACT_REFACTORING,
                    title: 'Learn more about Java extract refactorings.'
                }
            },
            {
                kind: CodeActionKind.Refactor,
                command: {
                    command: Commands.LEARN_MORE_ABOUT_REFACTORING,
                    title: 'Learn more about Java refactorings.'
                }
            }
        ]
    }
}

It won't return any code action. But registered document command for both Refactor and RefactorExtract. When user click the Refactor... in the editor's context menu, which one should be shown?
I tried from my side and found that, even if the code action listed are all RefactorExtract kind, VS Code still shows document for RefactorExtract instead of Refactor.

Some findings:
In the above case, the client code action provider won't return any code action but registered different kinds of document. The real code action is resolved at the Language Server side.
If the refactoring list is popped up by click the Refactoring... in the context menu

Then the refactoring kind of the document will always be CodeActionKind.Refactor.
If the refactoring list is popped up by triggering the keyboard shortcut of command editor.action.codeAction which customized by user, then the refactoring kind of the document will be the kind that user set in args.

@mjbvz Just noticed the release target update to April release. Does that mean the API will have some changes?

@mjbvz This change was pushed several times. Can we expect the release in June?

@akaroml We were kinda waiting for you feedback to know if the proposed API change is sufficient for your need?

@jrieken I should have pointed out this earlier and @jdneo is from my team and he is the on-point of adopting this new capability. Please check out his comments above.
I'll share a list of GitHub handles of my team through email.

@jrieken @mjbvz Just FYI we've already proposed a draft PR for this new API (Attached a gif in that PR).
So far so good! Just one question: When user clicks Refactoring... in the context menu and gets a list of refactorings which are all the same kind (Let's say: RefactorExtract), is it possible for the new API to return RefactorExtract instead of Refactor?


Large commits take long time to complete

Large commits are taking a long time (> 60 seconds)
Users with configured timeout in a network component on the way to lakeFS (such as load balancer) fail to commit due to timeout

Current status
What's Done

We seem to be re-using existing ranges properly. That is, we do not write existing ranges again during the commit.
TierFS/Pyramid does not seem to cause the slowness - similar performance was measured when using the native filesystem.
CPU profiling suggests that a substantial time of the commit is spent calculating SHA256 hashes. Changing the hash to MD5 (faster calculation) didn't seem to decrease the run time.
CPU profiling suggests we spent time waiting for a response from Postgres. We tried to increase Postgres RDS size in order to get more i/o operation. It didn't change the results.
Separate the merge and commit operation.
Mutex profile stack traces of holders of contended mutexes hasn't suggested we spent significant time waiting for unlock.

In progress

Keep-alive on request for long operations - reject for now. #2710
Parallelization by breaking the ranges on fixed points. Estimated time - one month. #2875

Next steps

In case we'll see the parallelization will decrease the time complexity significantly (< 1 min) we will implement it completely.

Pyramid should be speeding things up, not slowing down.  (It uses CPU but saves time...).
Have we tried boosting the local cache size to be e.g. 100GiB, and seen that it still happens?

@arielshaqed
Boosting the cache size did improve the commit time.
for a large commit that took 2:40 boosting the cache reduced the time to 1:37

Considering the latest feedback we got from users, saying that commits take < 60 sec to complete, I'd like to close this issue for now and re-open it when needed.
This means that we shall park https://github.com/treeverse/lakeFS/pull/2921 until users experience this pain. The reasons are: this change requires a lot of work to verify that nothing breaks, and although the implementation is almost done there is still more work to do there.
@guy-har @eden-ohana @itaiad200 are you ok with this?


Make Static Dir Configurable

Is it possible to make the "static root dir a setting", eg in app.conf
static.root = /home/some_project/public_stash
static.url = /public/

[dev]
static.root = ./test_static

[prod]
static.root = ~/public_stash

Ideally in production you would want to have your proxy bypass revel completely to access the public static files and folders directly. But I would not be totally against this, the change would be in the static module, static.go:serveFile:81
-		basePath = revel.BasePath
+		basePath = revel.Config.StringDefault("static.root", revel.BasePath)

But since this is a module issue you need to create the issue against the revel/modules project, so I am closing this, feel free to do a pull request with the above code.

Err am perplexed..
The static module is "build in revel".. not here
https://github.com/revel/modules
but here
https://github.com/revel/revel/tree/master/modules
So it means here ??
https://github.com/revel/revel/blob/master/modules/static/app/controllers/static.go#L85
Also whats in the back of my head is having the {{static_ver "/js/foo.js"}} tags

Try https://github.com/revel/modules/tree/develop You want to target the change against a development branch.
I am not sure what you mean by the {{static ...}} tag we already have {{url "public/js/foo.js"}} tags to do reverse routing using the routes file

WTF.. Ok so this is version "next realsase right"..
Maybe I better change some of the docs to reflect this now...
and am switching everything here over to develop..

AFAIK next release is v0.12 https://github.com/revel/revel/wiki/Roadmap#v012-see-issues so I would say yes develop will move to master.

@pedromorgan file a RFC explaining the problem you're trying to solve and why we should care about it. Thanks.
PS - what are you talking about "switching everything here over to develop"?

With the new routing you can now use the url to specify static routes as well, so no need for this to be in the conf


job: get image name from target

1b7cb6c changed workers so that they don't have access to the distro
that was used to create a manifest anymore. I thought this meant that
they also don't know what the filename of the final image in the store
is. That commit worked around this by picking the only file that
resulted in that build. That was a bit of a hack.
Turns out, the Target struct already has an ImageName field.
Fixes #348

Update: that ImageName was not actually set for the default local target.

The ImageName field is not the name of the file, but the name the caller of the weldr API wants the image to have in the target cloud provider. I filed an alternative PR #374

The ImageName field is not the name of the file, but the name the caller of the weldr API wants the image to have in the target cloud provider. I filed an alternative PR #374

I think you're right. Thanks for catching that!


putting a code block inside a spoiler display undefined

Putting a very long fanced code block bewteen spoiler tags I get undefined instead of the code.
{% spoiler title %}
sometext:

```python
0 :  <class 'type'>
1 :  <class 'weakref'>
[...]
157:
```
{% endspoiler %}

All is rendered except the code. I suspect this is because of the <> surrounding the classes.
Outside the spoiler tags this is rendered properly (I'm using hexo-renderer-markdown-it).
https://github.com/fletchto99/hexo-sliding-spoiler/blob/7b4aeb3ea7dbf30e3ac7e72292ae756fd4b3eeef/index.js#L4-L7

In fact I also added a normal code block
```
test
```

and it also results into undefined

I'll have to look into this. In the meantime I suggest taking a look into using code blocks. See #3 - I believe that was the same issue.

{% spoiler subclasses %}
{% codeblock lang:python %}
code here
{% endcodeblock %}
{% endspoiler %}

Worked but this require less markdown and more template lang. Also loosing the syntax highlight in the code editor.

I'm looking into this over the christmas break. I'm hoping to have a fix by the end of the week.

The latest version 1.2.0 has been published to NPM fixing this issue. The fix was easier than I expected :) - Sorry it took so long to get to, this project hasn't been a high priority recently 😓


Clear search when running actions

A number of our users are accidentally creating chat groups they don't mean to because if you search, start a chat, then search again the original list is retained. Instead we'll clear out your list if you choose any of the actions (search, folders, etc)
Since I was in here i decided to clean it up a bunch

[x] Use regular connect
[x] Fix mixed controlled input which causes your typing to be overwritten as results streamed in

This is split into multiple commits which show the various logical changes and different commits for pure cleanup. Please look at the commits in order to understand the changes instead of the overall diff

@keybase/react-hackers

The commits 191e2dbe5cd7...04335ceac56f introduce visual changes on linux. :mag_right: 9 changed

Changed: Search-Waiting (before) (after)

Changed: Search-Searching (before) (after)

Changed: Search-Group_non_user_Out_of_invites (before) (after)

Changed: Search-Group_non_user_No_Avatar (before) (after)

Changed: Search-Group_non_user_Has_Invite (before) (after)

Changed: Search-Group_non_user (before) (after)

Changed: Search-Group (before) (after)

Changed: Search-Chat_enabled (before) (after) (diff)
Changed: Chat_List-Normal (before) (after) (diff)

The visdiffs look correct to me ^

The commits 9b5d39bd87ce...486bd015c216 introduce visual changes on linux. :mag_right: 8 changed

Changed: Search-Waiting (before) (after)

Changed: Search-Searching (before) (after)

Changed: Search-Group_non_user_Out_of_invites (before) (after)

Changed: Search-Group_non_user_No_Avatar (before) (after)

Changed: Search-Group_non_user_Has_Invite (before) (after)

Changed: Search-Group_non_user (before) (after)

Changed: Search-Group (before) (after)

Changed: Search-Chat_enabled (before) (after) (diff)


Clarify network related variables

The variables controlling where GCP instances and firewall rules were
created were ambiguous, making it unclear where a separate VPC and
project were used or required. This commit changes the names to match
the variables used by google_compute_instance and
google_compute_firewall, and adds project_id as a default value for
the subnetwork_project variable.

Hold off on merging until I've run test-kitchen one more time.

All tests pass, this should be good to go. /cc @efouarge


updating readme in branch example

Updates
I updated the readme file. Please review and accept.

Thoughts
I probably shouldnt but ok 👍


Fix peer event subscriptions

There is a bug in the peer connection where if a peer_socket emits an error or end event multiple times per one connected event it causes an issue with http_server managing the connected peers.
Only way i was able to get the peer_socket to emit multiple error events was to have a peer connect to my laptop then disconnect the wifi. There will be an error event emitted from the ping timer code that says its connection timed out. But there is another event being thrown from somewhere else.

r+  Mergey.


spidermultusconfig: validate customcniconfig if is valid

name: Pull request
about: Tell us about your contribution
labels: ["pr/release/none-required"]

Thanks for contributing !
Before submitting a pull request, make sure you read about our Contribution notice here: https://spidernet-io.github.io/spiderpool/contributing/development/pullrequest/#need-review
What this PR does / why we need it:
spidermultusconfig: validate customcniconfig if is valid
Which issue(s) this PR fixes:
https://github.com/spidernet-io/spiderpool/issues/2151
Special notes for your reviewer:
make sure your commit is signed off

update the test/doc


Set canonical tags to help Google index correctly

Describe the bug
Now that we have versions of pages, and those can be unchanged between versions, we have a bit of a problem. Which is the "original" page? That's what Google is asking itself.
Google Search Console tells us that the canonical tag is incorrect, so it's choosing... whichever it wants.
This is hurting our Google ranking.
We have a problem, though. We want to direct people to the newest version of all pages (Google uses the canonical one as the search result), so if they click around, they will reach the newest ones. Especially since it is not at all clear that you're currently viewing an old page (that should be its own ticket). So from a "marketing perspective", the right way would be to set the newest "main" version of each page to be the canonical one.
From a "technical correctness" perspective, the correct way to set the canonical tag would be to say "this information first appeared in 0.27, so as long as we have not changed it, that's the canonical version".
I suppose we would rather go for the marketing perspective. As a bonus, it also happens to be much easier to implement, because then we don't need to keep track of whether a page has been unchanged or not, and just always set the old branches' tags to point to the new version.
Screenshots
Google Search Console complains like this:

Additional context
Add any other context about the problem here.

Nice catch! It's these small details that make a great impact.
Yeah, let's go for the "marketing perspective" which is conveniently also the easiest to implement. :smile: At any rate, as a developer, I prefer a search engine to direct me to the newer (not older) version of documentation.
I had to do quite a few out-of-workflow commits -- including back-porting some fixes -- but we got what we wanted:
$ for VERSION in v0.32 v0.31 v0.30 v0.29 v0.28 v0.27 v0.26; do echo $VERSION; for PAGE in user-guide/ ciso-guide/ user-guide/prepare/; do curl --silent https://elastisys.io/compliantkubernetes-$VERSION/$PAGE | grep canonical; done; echo; done
v0.32
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/ciso-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/prepare/">

v0.31
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/ciso-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/prepare/">

v0.30
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/ciso-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/prepare/">

v0.29
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/ciso-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/prepare/">

v0.28
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/ciso-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/prepare/">

v0.27
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/ciso-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/prepare/">

v0.26
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/ciso-guide/">
        <link rel="canonical" href="https://elastisys.io/compliantkubernetes/user-guide/prepare/">


Clarify Rust shutdown documentation

I noticed a bit of funky grammar here, so I took a moment to improve it.

Thanks!


JOSS Review: file 'oasis.md' contains a link to 'assets/nomad-oasis.zip' which is not found in the  documentation files

Following the directions at https://nomad-lab.eu/prod/v1/docs/develop/setup.html
./scripts/setup_dev_env.sh

...
Successfully installed nomad-lab-1.2.0rc1.dev124+gaa26e28b7
INFO     -  [macros] - Macros arguments: {'module_name': 'nomad/mkdocs', 'modules': [], 'include_dir': '',
            'include_yaml': [], 'j2_block_start_string': '', 'j2_block_end_string': '', 'j2_variable_start_string': '',
            'j2_variable_end_string': '', 'verbose': False}
INFO     -  [macros] - Found local Python module 'nomad/mkdocs' in:
            /mnt/c/Users/sterg/Documents/GitHub/sparks-baird/nomad
INFO     -  [macros] - Found external Python module 'nomad/mkdocs' in:
            /mnt/c/Users/sterg/Documents/GitHub/sparks-baird/nomad
INFO     -  [macros] - Extra variables (config file): ['generator', 'homepage']
INFO     -  [macros] - Extra filters (module): ['pretty']
INFO     -  Cleaning site directory
INFO     -  Building documentation to directory: /mnt/c/Users/sterg/Documents/GitHub/sparks-baird/nomad/site
INFO     -  The following pages exist in the docs directory, but are not included in the "nav" configuration:
              - aitoolkit.md
WARNING  -  Documentation file 'oasis.md' contains a link to 'assets/nomad-oasis.zip' which is not found in the
            documentation files.
WARNING  -  Documentation file 'oasis.md' contains a link to 'assets/nomad-oasis.zip' which is not found in the
            documentation files.
WARNING  -  Documentation file 'plugins.md' contains a link to 'assets/nomad-oasis-with-plugins.zip' which is not found
            in the documentation files.
INFO     -  Documentation built in 14.97 seconds

Yes there is an additional script creating those .zip files that should be called in ./scripts/setup_dev_env.sh.


Change LRU logic to optional, off by default

When obtaining a SignatureProvider from the cache, maintaining LRU order by removing and adding to front has shown a 10% performance reduction when a small number of SignatureProviders are in play.
For SignatureProviders, it is not important to maintain the LRU logic, just make sure the cache doesn't blow up.

Danny is picking up this work.


[otlp-exporter] web exporters should set User-Agent header upon requests.

        Error: Uncaught AssertionError: 'Refused to set unsafe header "User-Agent"' === 'Request Timeout' (webpack-internal:///../../../node_modules/assert/assert.js:199)

Originally posted by @JamieDanielson in https://github.com/open-telemetry/opentelemetry-js/issues/3790#issuecomment-1542692197
The current test based on headless Chrome will return above error due to Chrome's limitation.
Setting the user-agent header in Chrome browser by Headers object or using fetch() will have no effect but won't throw any error.
Using XMLHttpRequest.setRequestHeader() will throw the above error.
As other browsers (tested on latest Firefox and Safari) work as expected, I suggest we use a try...catch block and ignore the output and complete the implementation as per specification.
Another thing is that the current implementation uses sendBeacon if available and if no custom header being set. As the user-agent header should be present as per spec. We should remove the use of sendBeacon.
We can also rely solely on fetch and drop XMLHttpRequest. Users should use a polyfill for fetch if they want to support legacy browsers.
Related: #3790 #3806 #3291

We can also rely solely on fetch and drop XMLHttpRequest. Users should use a polyfill for fetch if they want to support legacy browsers.

I found some usages of modern javascript features (such as Object.entries()) in the sendWithXhr function. Is there a guideline of browser compatibility or I suggest we just use fetch instead.

I've finished the user-agent part in #3811. Should I replace sendWithXhr with fetch?

not stale


Some tweaks to RandomAccessIteratorTransformer

This is three commits: new tests (without changing behavior), better operators (without observably changing behavior, and unrelated to the new tests), and then an ambitious change to the C++20 iterator-concept machinery (which does change behavior, reflected in the new tests). Each one could be taken upstream independently from any of the others, if you like.

Each one could be taken upstream independently from any of the others, if you like.

Thanks, I did test them individually!

I'm actually not sure how VecType::const_iterator::value_type was getting the correct value before this commit.

There is a (subtle?) fix with the last commit.
using ConstVecType = const VecType;
// Before has const
static_assert(std::is_same_v<const int, typename ConstVecType::iterator::value_type>);
 // After does not
static_assert(std::is_same_v<int, typename ConstVecType::iterator::value_type>);

New behavior is the correct one and matches the result for std::vector in msvc/clang/gcc. I added a commit with tests that showcase this, and then it is fixed in the last commit.
What's interesting is that std::vector has not moved to contiguous_iterator_tag.
Demo: https://godbolt.org/z/ejWqq8o5Y
What's more interesting is there is discrepancy in pointer_traits::element_type, where msvc yields T, but clang/gcc (->stdlib) yield T*.
Demo: https://godbolt.org/z/3sMnox46j

arrow_proxy

Have tried this before: https://github.com/teslamotors/fixed-containers#arrowproxy and there are some issues. I am on the lookout for a solution that allows the removal of the API discrepancy, but so far the current implementation seems like the least-downsides option in my opinion. There was a suggestion about flat_map having a solution for this here, will look into it.

Thank you for this modernization!

I'm actually not sure how VecType::const_iterator::value_type was getting the correct value before this commit.

There is a (subtle?) fix with the last commit.
using ConstVecType = const VecType;
// Before has const
static_assert(std::is_same_v<const int, typename ConstVecType::iterator::value_type>);
 // After does not
static_assert(std::is_same_v<int, typename ConstVecType::iterator::value_type>);

New behavior is the correct one and matches the result for std::vector in msvc/clang/gcc.

What you wrote there isn't quite correct (ConstVecType::iterator should be VecType::const_iterator), but what you wrote in the new test (line 53) is correct. I was confused by the fact that my assert (line 44) passed before the change:
static_assert(std::is_same_v<std::iter_value_t<VecType::const_iterator>, int>);  // before and after

but I see now that that was only because C++20 iter_value_t quietly strips cv-qualifiers ("overloads" 5,6,7 here). So that answers my confusion: VecType::const_iterator::value_type was getting the wrong value, but I failed to see that it was wrong, because I was looking only at std::iter_value_t<VecType::const_iterator>, which masks the difference. All good now. :)

What's interesting is that std::vector has not moved to contiguous_iterator_tag. Demo: https://godbolt.org/z/ejWqq8o5Y

I'm 99% sure that it would be conforming for vector to advertise contiguous_iterator_tag. I think the reason existing vendors haven't changed their vectors is because they're worried about user code in the wild that checks for random-access-ness via std::is_same_v<std::iterator_traits<It>::iterator_category, std::random_access_iterator_tag> instead of using std::is_convertible/std::is_base_of. Such a check was fine pre-'20, but does the wrong thing for contiguous iterators in '20 and later. A C++20 library targeting devs who "live at head" shouldn't need to worry about that.

What's more interesting is there is discrepancy in pointer_traits::element_type, where msvc yields T, but clang/gcc (->stdlib) yield T*. Demo: https://godbolt.org/z/3sMnox46j

Hmm, I've been here before. :) I filed libc++ bug #31354 for exactly this issue back in early 2017, but then decided that it wasn't really a bug because C++20 contiguous_iterator wasn't yet on anyone's radar. Now that C++20 contiguous iterators are a thing — in fact they are exactly the same thing as pre-C++20 fancy pointers — I think that bug should probably be reopened and __wrap_iter<T> should provide an element_type the same way your library now does.

arrow_proxy

Have tried this before: https://github.com/teslamotors/fixed-containers#arrowproxy and there are some issues. I am on the lookout for a solution that allows the removal of the API discrepancy, but so far the current implementation seems like the least-downsides option in my opinion. There was a suggestion about flat_map having a solution for this here, will look into it.

By non-random coincidence, I'm the author of sg14::flat_map and libc++ std::flat_map, both of which use the arrow_proxy pattern. (And I did a blog post on it, back in the day.) I don't think I understand the problem you were seeing well enough to say with confidence that you were wrong; but it certainly does seem like there's nothing special about your use-case that would preclude the same kind of arrow_proxy that so many other libraries have used successfully.

What you wrote there isn't quite correct

Ah, sorry about the typo, likely copy-pasted incorrectly.

Hmm, I've been here before. :) I filed https://github.com/llvm/llvm-project/issues/31354

Nice read. The results are definitely on the surprising side.

arrow-proxy

I will try the arrow_proxy pattern again. The problems from last time are catalogued in the README, but maybe there was an oversight.

Thanks for the above @Quuxplusone ! I was able to find a solution that no longer requires an API discrepancy. PR here
With a small delta on top of that, here is the ArrowProxy approach as well. It matches a flat_map exactly (as in, all static_assert()s yield the same results for iterators of EnumMap/FixedMap/flat_map). The implementation is simpler, but not returning an l-value has some issues from a user's perspective:

Need to suppress -Wrange-loop-bind-reference globally because they trigger on common loops (in contrast to std::map):

    for (const auto& key_and_value : s) { }

    for (const auto& [key, value] : s) { }

These non-cost & don't work at all (in contrast to std::map):

        // error: non-const lvalue reference to type 'pair<...>' cannot bind to a temporary of type
        // 'pair<...>'
       for (auto& key_and_value : s) { }

        // error: non-const lvalue reference to type 'pair<...>' cannot bind to a temporary of type
        // 'pair<...>'
        for (auto& [key, value] : s) { }

range-v3 has issues (but not std::ranges, std::map works with either):

    int first_entry = (*f.begin()).second;  // Can't use arrow with range-v3 because it requires
                                            // l-value. Note that std::ranges works

Minor issues, but possibly worthwhile going for l-value to be closer to a drop-in-replacement-of-std::map.


API authentication method call deprecated

GitHub has started emailing users who call their API with the deprecated URL authorization scheme.

Please use the Authorization HTTP header instead, as using the access_token query parameter is deprecated.

More information.

Same here, also got the GitHub notification mails...

It would be great if someone forks this and fixes this issue. There are no maintainers on this project anymore it appears, and this twice a week email will be scary for my end-users. If someone does fork this to fix this, please comment here so we can be informed.

I'm working on this now. The main problem is Github now requires you to send the username corresponding to the access token, which means we need to change the project API. GITHUB_USER is used to refer to the project being downloaded, uploaded, or released, so we need a different variable or format for this.

@kevinburkemeter actually you don't: sending the token base64 encoded as a basic authentication header works. You can also do "Authorization: token ".

Oh! OK, let me try that.

OK, just pushed a fix to github.com/meterup/github-release, as well as a 0.7.4 release. Please try it out! https://github.com/meterup/github-release/releases/tag/v0.7.4

Same API, no need to pass in an auth username, but you can if you want.

I had an older fork at https://github.com/gdm85/github-release; I will also add support like @kevinburkemeter did but without introducing the github.com/kevinburke/rest dependency.

@kevinburkemeter I don't know why you disabled issues on your repository, but I thought it was supposed to be a drop-in replacement. My command, which has worked for years until this day, does not work on your fork.
./linux-amd64-github-release upload --user 250 --repo Steam-250 --tag snapshots --name snapshots.tar.xz --file tar --replace --security-token '***'

./linux-amd64-github-release: Permission denied
##[error]Bash exited with code '126'.

Looking forward to trying @gdm85's fork instead.

Yes, the goal was to make it a drop in replacement. Considering you're getting something for free, and I have no obligation to help anyone in this situation, I'm a little frustrated with the tone you're taking.
I didn't touch the Makefile at all so I'm not sure why it's broken. The file you are trying to run needs to be executable though. Try running chmod +x linux-amd64-github-release.

I suspect it has to do with b61ce1a1426379d208f188311954fde680ac99f0 which was added after 0.7.2 was released. So, drop in replacement for the untagged master version of the github-release project.
Anyway, I'll push a fix later today.

I may be inclined to just look at the script we have this in, and see if it's easy enough to replace it with hub rather than chasing down forks of a third party tool to begin with. It looks like gh from GitHub doesn't yet have release functionality, but hub does.

The best would be to use GitHub official CLI, there is no doubt.
Until that I have updated my fork at https://github.com/gdm85/github-release and tagged v0.8.0 for the working version that adds support for --auth-user/GITHUB_AUTH_USER and uses the Authorization header (cc @Bilge).
NOTE 1: please do some thorough testing before putting this into your important workflows; I have tested only the following:

info
release
upload
delete

And assumed that the rest are working correctly as well.
NOTE 2: do not use go get to install it: I am waiting for feedback on this PR to solve that issue (if you use go get then the built version will not accept --user, --auth-user, --repo and you can only use environment variables for them).

@Bilge I just confirmed that the issue you ran into was introduced in the last commit on the original project, in 2017, so it's been there for three years. The reason you haven't seen it before is that commit never made it into a release version.
In any event, I just pushed a fix to meterup/github-release@c3c29b795c7dac3c1d5736dc0388493e5519df43, which is present in v0.7.5.

Dear @kevinburkemeter,
thanks for picking up the work on github-release. We have been getting respective notification mails from GitHub and hoped someone would have made the appropriate patches to this program already.
We are happy to see it has been you. Updating the documentation was easy (https://github.com/hiveeyes/terkin-datalogger/commit/8c58bd886e24caca8c8cc806b5062c585deaea31).
So, thanks to @aktau for conceiving this fine program and to you for bringing in important maintenance patches.
With kind regards,
Andreas.


Added name generator to reroll function.

Added name generator to reroll function, so that a new random name is generated for character.

added function to to reroll function.


Logging broken by upgrade to SLF4J 2

The recent upgrade of pathling.slf4jVersion from 1.7.36 to 2.0.7 has caused logging to stop working.
This commit needs to be reverted in order to fix this issue: 0c6cfca7b4eecccfab69b40a746e22cc35d15156
This issue affects Pathling 6.3.0.

any alternative solution for above??

@jerrin89 We've just released v6.3.1 which should solve the problem.
Feel free to reopen this issue if you have any further problems.

@johngrimes the above V6.3.1 is a SLF4J  version or something else??

6.3.1 is a Pathling version: https://github.com/aehrc/pathling/releases/tag/v6.3.1
If you are using the server, there is a new image on Docker Hub: https://hub.docker.com/r/aehrc/pathling/tags

@johngrimes we are not using pathing is there any other way to resolve the issue??Atm on the console log the scenario is showing as passed when it actually failed.


How is it compared to WebSocket

Have you successfully run a demo, how is it compared to websocket, any improvement?

It's quite buggy and I haven't had time to fix it. There is sadly not much performance gain, due to the nature of VNC protocol.


use rtc with LocalTrackSubscribed, update examples

superseded by livekit/python-sdks#238

we still need to use this in voice_assistant and other examples

yep, but we still haven't cut a release in python-sdks for that change


GetAllConversation Returning Null

Hey there - Thanks for this project!
I was trying to fetch all emails from an OSS google groups, but noticed that conv.GetAllMessages(http.Client{}, true) doesn't return any messages within the conversation. `GetAllConversation' returns the subject lines. but only those located on the first page of the google groups. Any tips?
func fetch(group_name string) string{

    group := crawler.NewGoogleGroup(group_name)
    conversations := group.GetAllConversations(http.Client{})

@kininaru

Sorry for the bug. Preparing for an important test this year so I may not able to enhance the code for you... sorry.
Actually I encountered the same problem while developing the crawler. I worked on it for few days and I failed. For result, in some cases, the crawler can only get the conversations in the first page.
My advice: Manually sync the earlier conversations, and run the crawler regularly to sync new conversations  automatically.
As for the message, I suggest you to fill your cookie and retry. Good luck!
Source code of Google Groups' front end haven't been changed for years, and encoded by the special tools, it is really difficult to read and understand... It has weird function names and strange data structures which is not for human to read.


Crash in AFURLResponseSerialization.m at line 137

We are getting crashes reported on Crashlytics at line 137 of AFURLResponseSerialization.m inside the validateResponse method.
Crashed: com.alamofire.networking.session.manager.processing
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000f7202bec8
0 | libobjc.A.dylib | objc_object::release() + 16
1 | MyApp | AFURLResponseSerialization.m line 137-[AFHTTPResponseSerializer validateResponse:data:error:]
2 | MyApp | AFURLResponseSerialization.m line 239-[AFJSONResponseSerializer responseObjectForResponse:data:error:]
3 | MyApp | AWJSONResponseSerializer.m line 25-[AWJSONResponseSerializer responseObjectForResponse:data:error:]
4 | MyApp | AFURLSessionManager.m line 292__72-[AFURLSessionManagerTaskDelegate URLSession:task:didCompleteWithError:]_block_invoke.147

@Haberdashery1234   you should update to the latest version.
#3526 had fixed that.

I think this problem is not fixed, my team use the same code as the

@Haberdashery1234 you should update to the latest version.
#3526 had fixed that.

Maybe this question is not fixed. I have the same code in my app, but it still have the same question.

@mcmengchen - the latest version release (3.2.1) does not include the changes, but if you pull from the master branch using:
pod 'AFNetworking',  :git => 'https://github.com/AFNetworking/AFNetworking.git', :commit => '685e31a31bb1ebce3fdb5a752e392dfd8263e169'

Then you'll get the fixes.

It looks like 4.0.0 was just released, which should fix this issue, and so I believe this could be closed.


doc update + make streams/undo more robust

Codecov Report

Merging #248 into master will increase coverage by 0.39%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #248      +/-   ##
==========================================
+ Coverage   99.18%   99.58%   +0.39%
==========================================
  Files          67       30      -37
  Lines        2956     1440    -1516
==========================================
- Hits         2932     1434    -1498
+ Misses         13        3      -10
+ Partials       11        3       -8

Flag
Coverage Δ

#dot_changes
100% <ø> (ø)
:arrow_up:

#dot_changes_diff
100% <ø> (ø)
:arrow_up:

#dot_changes_run
100% <ø> (ø)
:arrow_up:

#dot_changes_table
100% <ø> (ø)
:arrow_up:

#dot_changes_types
100% <ø> (ø)
:arrow_up:

#dot_example
100% <ø> (ø)
:arrow_up:

#dot_ops
98.68% <ø> (+0.26%)
:arrow_up:

#dot_ops_bolt
97.61% <ø> (ø)
:arrow_up:

#dot_ops_nw
98.91% <ø> (ø)
:arrow_up:

#dot_ops_pg
?

#dot_refs
?

#dot_streams
?

#dot_streams_undo
?

#dot_test_seqtest
?

#dot_x_dotc
?

#dot_x_fold
?

#dot_x_heap
?

#dot_x_rt
?

#dot_x_ui_collab
?

#dot_x_ui_dom
?

#dot_x_ui_html
?

#dot_x_ui_input
?

Impacted Files
Coverage Δ

changes/changes.go
100% <ø> (ø)
:arrow_up:

streams/scheduler.go

x/dotc/structs.go

x/dotc/union.go

x/dotc/slice.go

refs/container.go

x/ui/collab/node.go

refs/caret.go

x/dotc/slices.go

x/dotc/unions.go

... and 26 more

Continue to review full report at Codecov.

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


MGMT-15668: Cluster name and base domain name fields need to type something for trigger validations

https://issues.redhat.com/browse/MGMT-15668
Before:
https://github.com/openshift-assisted/assisted-installer-ui/assets/87187179/7759919a-22f6-4b10-ae52-431500857873
After:
https://github.com/openshift-assisted/assisted-installer-ui/assets/87187179/e67192e5-b606-49e5-b0d5-939115098282

@jgyselov these changes also affect CIM forms?

@jgyselov these changes also affect CIM forms?

Yes.


error, display of Arabic word in csv file

VSCode Version:  1.49.0
OS Version:  macos 10.15.6

Steps to Reproduce:

I have a line in sublime  as the below pic show

when i copy the line in sublime to vscode,  vscode show the line like the below pic show. The position of "," is wrong.

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

some example text:
a,b,الإسكندرية، مصر,91495380f7f5cc2b6ad1b99359616ffe

Once an extension that adds CSV highlighting is installed (like Rainbow CSV), the rendering is the one that is expected:


[GLUTEN-2193][CH] Support sort_array

What changes were proposed in this pull request?
How was this patch tested?
UT

没看到 spark 33 的ut


[Proposal] PubSub canary capability

In what area(s)?
/area runtime
Describe the proposal
Problem space
Diagnosing pubsub issues takes time, particularly when teams/individuals are unfamiliar/new to Dapr.
When diagnosing an issue with pubsub. The first thing I want to know is:

"Is it an infrastructure / dapr configuration / dapr component issue ?"

or

"is it a user-code issue ?"

if I could simply port-forward onto a sidecar, and submit a canary message, I can very quickly exercise the infrastructure/configuration of the sidecars and the pubsub component, to see if the canary is received on the receiving sidecar.

How to publish the Canary message?
Couple of options :
1. New path segment
Create a new path on the PubSub publish endpoint specifically for triggering a canary message. For example :
POST http://localhost/:3500/v1.0/publish/general-purpose-pubsub/TopicA/**canary**
This is my least-favoured approach, when compared to option 2
2. Metadata property
POST http://localhost:3500/v1.0/publish/general-purpose-pubsub/TopicA?metadata.canary=true
or
POST http://localhost:3500/v1.0/publish/general-purpose-pubsub/TopicA?metadata.canary-Id=123456
I prefer canary-id, its easier to explicitly identify a single canary message among many canaries.
How would the canary message be observed?
My gut here is to simply write to stdout on the receiving sidecar with enough info to identify the canary among among the other log output
level=info msg="Canary received. Id : '23456'. component: 'general-purpose-pubsub', topic: 'TopicA'
There may be other ways to observe the canary, such as writing to a state store, or calling a webhook, but I feel this defeats the point as it would implicate other moving parts that may or may not be in their own state of failure. Keeping it simple with less moving parts wins here IMO.
Scope / Assumptions

Delivery of the message to an actual subscriber endpoint is not part of the Canary pathway. This is deliberate because I believe we want to specifically test the sidecar-to-sidecar infrastructure and not the user-code of the receiver. As such, there would need to be some code in the component that does not deliver the message to the registered endpoint, and instead simply prints the canary to stdout. There is an assumption here that the metadata.canary-id value is propagated to the receiving sidecar somehow.

Assumption is the receiving sidecar would need to have at least 1 active/registered subscriptions, otherwise there would be no physical output channel to deliver the canary on. Unless of course we can simulate an output channel but I'm less sure this is right. In all honesty, I don't know enough here to recommend one way or the other, so leave that to those in the know.

For scenarios where the receiving logic is not yet implemented (so there can be no typical subscription), maybe it is possible to declare a subscription as virtual/ mock / canary :

In this example, I've declared it as canary, but not hugely opinionated.

Only canary-decorated messages will ever arrive at the canary subscriber. Remember, this canary subscriber exists purely to create a physical output channel if one doesn't already exist.

apiVersion: dapr.io/v2alpha1
kind: Subscription
metadata:
  name: my-pub-sub-receiver
spec:
  topic: TopicA
  routes:
    default: /checkout <-- /checkout may or may not exist right now, but it doesn't matter, as the msg wont be delivered to it
  pubsubname: general-purpose-pubsub
  canary: true
scopes:

Additional / Optional

Messages which are published as Canary messages are still normal messages with payloads and properties etc, It may be desirable to serialize the message payload to stdout too for additional debugging purposes. But this raises an additional security concern.

level=info msg="Canary received. Id : '23456'. component: 'general-purpose-pubsub', topic: 'TopicA', payload: '<PAYLOAD>', content-type: '<CONTENT TYPE>'

I think this is a useful addition, before delving deeper into the suggested designs here (all seem reasonable overall), I want to ask if using tracing doesn't help in debugging message delivery between publisher and consumer?

I want to ask if using tracing doesn't help in debugging message delivery between publisher and consumer?

I'm sure it would, providing the organisation had a decent observability platform, and the developer/operators were well versed in utilising and navigating it. Unfortunately, I suspect this isn't as common as it should be, but I have no data to back that up...
I see this being useful for those on early side of Dapr adoption, and for those users who need a super quick, sure-fire way to check that the infra is working as intended, even when running a self-hosted / local set-up as part of the Getting Started guides.
I can see it fitting into the diagnostic FAQs and being used as a first-response to users raising questions on GitHub and Discord about general problems with PubSub.
There may also be opportunity to surface this capability in Conductor, as a way to ClickOps a canary, or even better frequent automated publishing of Canaries across the cluster as part of health checks.

@yaron2

I want to ask if using tracing doesn't help in debugging message delivery between publisher and consumer?

I'm sure it would, providing the organisation had a decent observability platform, and the developer/operators were well versed in utilising and navigating it. Unfortunately, I suspect this isn't as common as it should be, but I have no data to back that up...
I see this being useful for those on early side of Dapr adoption, and for those users who need a super quick, sure-fire way to check that the infra is working as intended, even when running a self-hosted / local set-up as part of the Getting Started guides.
I can see it fitting into the diagnostic FAQs and being used as a first-response to users raising questions on GitHub and Discord about general problems with PubSub.

Regarding canary-id, wouldn't canary mode usually entail sending a single canary? in which case sending an id for the purpose of filtering out multiple canary messages isn't as useful. I like the metadata.canary=true setting as it's clearer and removes some cognitive overhead from the developer in generating an id and making sure the id is unique etc.

Regarding canary-id, wouldn't canary mode usually entail sending a single canary? in which case sending an id for the purpose of filtering out multiple canary messages isn't as useful. I like the metadata.canary=true setting as it's clearer and removes some cognitive overhead from the developer in generating an id and making sure the id is unique etc.

If we don't have a canary-id to correlate, the only way to get a correlation is with a timestamp... which could be fine as its printed in the stdout of the receiver, however you don't have a timestamp at your fingertips that you can easily refer to on the publisher side (unless you used a tool like insomnia or postman, which has its own log data)
For me having an ID provides a nice correlating experience, better than a timestamp.
Alternatively, dapr could auto-assign a canary ID, and then return it as a response header, such as x-dapr-canary-id : 1234 - Then you can stick with the simpler metadata.canary=true API surface. I would be fine with that from a Dev Ex perspective.
if auto-assigning an ID, I’d like to see a friendly ID, such as what dapr CLI provides as an auto app-id - as these make for easier correlation
Example
X-Dapr-canary-id: terriershag-wizard
—
I think if its low-cost to provide an id with the canary, do it, as the potential gain is worth it IMO. but if the cost is significant and becomes a chore in itself, then hold off for now.

bump

Ok, I think I've come up with a simple approach to satisfy some of this.
Developer Experience
To send a Canary message, simply override cloudevent.type to be dapr-canary and publish the message by any means
i.e. http://localhost:3500/v1.0/publish/{pubsub-component}/{topic}?metadata.cloudevent.type=dapr-canary
Observe the canary received message in the output of the daprd process.

Optionally, if it is important to easily correlate many canary messages, simply override metadata.cloudevent.id with a custom value.
i.e. http://localhost:3500/v1.0/publish/{pubsub-component}/{topic}?metadata.cloudevent.type=dapr-canary&metdata.cloudevent.id=123

Implementation
  eventType := cloudEvent[contribpubsub.TypeField]
  if eventType != nil {
          if eventType == "dapr-canary" {
                  log.Infof("🐦 Canary received! -- CloudEvent Id %s", cloudEvent[contribpubsub.IDField])
                  return nil
          }
  }

All that is required is this change to prevent any messages being delivered via the app channel if cloudevent.type field is set to dapr-canary -- the canary message is essentially short-circuited and ACKd without delivery.
https://github.com/olitomlinson/dapr-pubsub-canary/blob/e7ea203290ed6271716752fadb00d15ba14c705c/pkg/runtime/processor/pubsub/publish.go#L118-L124
Implementation criticism
You could argue that this is a magic string implementation, and a dedicated/explicit method of enabling this behaviour would be better (as originally proposed) however, at present there is no mechanism for passing additional metadata from a publisher to a subscriber, so this would have to be implemented too i.e. https://github.com/dapr/dapr/issues/5179.

Requirements

Canary messages must utilise a valid CloudEvent envelope in order to be detected.
This approach requires that an app channel is established, and also one or more pubsub output channel is established via a Subscription.

Future enhancement
Ideally, I'd like to be able to support a scenario where an app channel is not established (think about a user that is early in the dapr learning curve and hasn't set up an App yet, and just wants to check the wiring between two sidecar processes with dapr run ). But this can be figured out later.

Bump

bump

Was this intentionally closed? I remember seeing POC work around this

@cicoyle not intentionally closed no.
However, it didn't create that much interest from the community, so I don't intend on maintaining the PR until there is more interest :)


Import not working

I get only folders. No docs, no tasks.

@sanekmin currently docs exporting not supported by ClickUp. But, tasks should be synced as list

@sanekmin currently docs exporting not supported by ClickUp. But, tasks should be synced as list

Tasks too not sync, if you need, i can show logs (say how i can collect it)


word break cause by color tag

Issue details
the second draw of font should not break the word "international".  It just one word with different color.
Reproduction steps/code
	public void render(float delta) {
		Gdx.gl.glClearColor(0.6f, 0.6f, 0.6f, 1.0f);
		Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

		batch.setProjectionMatrix(camera.combined);

		shape.begin(ShapeRenderer.ShapeType.Line);
		shape.setColor(Color.RED);
		shape.rect(0, VIRTUAL_HEIGHT - 600, 300, 600);
		shape.end();

		batch.begin();
		font.getData().setScale(0.5f);
		font.draw(batch, "[BLUE]Is this a bug? international string123456789abcdefghiklmn",
				0.0f, VIRTUAL_HEIGHT,
				300.f, Align.left, true);
              // [output](http://pasteboard.co/OPDave7xa.png)
		font.draw(batch, "[BLUE]Is this a bug? inter[RED]national string123456789abcdefghiklmn",
				0.0f, VIRTUAL_HEIGHT - 200,
				300.f, Align.left, true);
               // [output](http://pasteboard.co/OPuY5FCP6.png)
		batch.end();

	}

Version of LibGDX and/or relevant dependencies
libgdx 1.9.5

@NathanSweet @tommyettinger If you guys are not on this already I would have a look at it tomorrow. I wanted to fix this tomorrow actually anyways and didn't even know there was an issue about this already 😄

I'm not on it. Best of luck! thar be dragonz

Hey guys, I need some opinions to actually be able to fix this bug.
GlyphLayout#setText() at the moment does many things in one single loop:

Adding glyphs
Checking linebreaks and color-markups
Truncating + (non-color-markup) line wrapping
Handling all the special cases for the above

It does this by reusing all the same variables all the time. This makes it incredibly hard to follow and debug. And it also connects all the above tasks directly to another via the shared variables, making it even worse to debug.
If I add correct line wrapping for color-markup (which would be possible I believe) it will be very very very hard for other people to ever understand what's going in the code. You already need to know a lot about fonts and you have to understand all the GlyphLayout/GlyphRun/Truncate/Wrap/Color-markup logic and how they interact (!!) already.
To actually make this thing "maintainable" it would be necessary to break it up into several steps. It might loose a little performance (even if I doubt it would be really relevant at all / possible to prove it in a alive test) but it would be possible handle less "tasks" at a time and make it easier to understand what's going on.
Propositions would be:

Do everything in "the one loop"
Pro: Maybe bit faster (if all all)
Con: A hell to maintain, debug and to understand

Parse all GlyphRuns first (+ truncate if applicable), then do wrapping in an extra loop
Pro: Easier logic, separation of concerns in the code, making it easier to add new features or to debug
Con: Might be a bit slower (if all all)

There are several options to parse the GlyphRuns
a) One GlyphRun per word/color-markup
Pro: Easy line wrapping and to understand/maintain
Con: Needs more GlyphRuns (but they would be shorter!)
b) GlyphRuns can span several words
Pro: Less GlyphRuns (but they would be longer!)
Con: More work/effort to line-wrap than a)
What are your thoughts on this? I don't want to do a days work just to find out you guys don't like the idea.
My personal preference would be 2.a) But I'm also happy to implement any other proposition as long as it's doable.
@NathanSweet @tommyettinger What are your preferences?

It's hard to judge how much of an impact such refactoring would have on performance. I can say when starting Spine, GlyphLayout#setText is called 4723 times. After start up it's called around 2-20 times per frame. I'm not super excited about making it slower so the code can be easier to follow. I'm most interested in the code doing the right things, and quickly.
There are many edge cases in text layout. The current GlyphLayout code has had issues ironed out for a long time and is pretty solid. I'm not sure it's worth starting over and going through the inevitable new problems, performance implications aside.
As for code readability, I'm sure it's possible to make it nicer as you say, maybe by doing it in multiple passes. However, I'm also pretty sure it would still be quite a monster in the end due to the number of edges cases and the complexity needed to handle them all.
The code used to do everything in one pass, eg keeping a running calculation of the widths, adjusting as needed. Relatively recently this was changed to go over all the runs at the end. Maybe it could be adjusted to create the runs, then do the wrapping. It's not clear how much better this will be though, as much of the same work needs to be done.
I haven't looked at what would be needed to prevent wrapping at color tags. I have a feeling it shouldn't be too hard using the existing code, enow that we have kerning between runs (that didn't used to be the case). I'm inclined to explore that before risking instability with a larger refactoring.

Yeah, it might be worth it to look at how kerning handles the interaction between runs, since that should be similar to how runs could be wrapped as one unit (or split on a word boundary rather than a run boundary). I'm also definitely in favor of fast code over readable code in this case, because text layout is rarely especially readable even in the best case, but it needs to be fast for text-heavy applications. We also hopefully won't need to read this code especially often as any remaining bugs are ironed out (wishful thinking, ha).

If we didn't need this damn feature to not wrap color runs, we could call it perfect as is! :D
Giving it some thought, it'd go like this:
We place a run that fits on a line, we move to the next run, it doesn't fit! We need to decide where to break the run to wrap it. Currently if it doesn't have a break char, we move the whole run to the next line.
Instead of doing that, we need to look at the runs before it (potentially all of them on the same line) for a break char. If we find one, that's the run we need to break. Afterward, we need to reposition any runs after it (just position, don't need getGlyphs again) until we get back to the original run that didn't fit, then we continue placing runs on the next line.
That sounds a little tricky when written out, but may not be too bad in code (and by that I mean just as bad as the other code!).

@NathanSweet Yes, what you wrote up is exactly what I was going to try. Maybe it's even possible to store the last potential linebreak-position/index while parsing the runs so you mustn't look where one is later. And fontData.getWrapIndex(run.glyphs, i) goes back the whole run/s anyways.

Cool!
I'm not sure about keeping track of the last possible break position. getWrapIndex can be overridden to customize the logic. CJK each use different rules and need more logic than isWhitespace and isBreakChar. For example: http://n4te.com/x/2057-6deb.txt

Thanks for the info! I already started it wrong then... It's actually harder than I thought...

Not doing it is an option! ;)

Nah, I spent so much time already, I'm not going to resign.
I already abandoned the option we talked about above as it turned out to be really crazy because recursive linebreaks are needed where you have to keep track of all runs which are already dangling behind the one to wrap, etc. Not really a sane option, I tried it so I know. Or I just didn't get it working correctly, also possible.
Whenever something is overly complicated I often remember that in these cases normally the underlying data structure or architecture is not suited to the problem to be solved. After looking at the whole thing the problem with the data structure here is that wrapping is mixed with color changes. I.e. lines are broken because of color changes. That's the reason why wrapping is so complicated.
There is a really cool way to solve this problem I'm working on right now which would require the GlyphRuns to change the color-change handling a little bit, the rest of the code would even be simplified a lot and still using the all the methods which are already in use. It'll basically will be only one GlyphRun per line.
If GlyphRun color handling is not to be touched this can also changed to create GlyphRuns as they are now with a little overhead.
When I'm finished, please test with your project if you notice any difference. Even if you guys do not like it I will still use it for my own project, as I'll be using color-markup in many texts I guess.

Closed by #6587


[FEAT] Custom Error Page 404

I will design an Error Page for calls or redirecting to pages which do not exist.
Hello!
I am Viraj Chandra, a proud contributor at GSSoC '23. I would like to the contribute to this project by designing an Error Page for calls or redirecting to pages which do not exist.
Things I will be doing as of now:

[ ]  Designing the error page 404

@AtriSukul1508  Please Assign me this.

@virajchandra51 assigned, make sure to fetch the repo before making a PR

@AtriSukul1508 i also want to add 404 error page

hey @AtriSukul1508 may i proceed , will complete asap !!

@PatilHarshh you can now work on that issue, change the color combination. Follow the current color combination of the website


actions: add chameleoncloud

Same as in #511 but for ChameleonCloud. This can leverage the scripts that are available here. The code for these actions will reside in https://github.com/popperized/chameleon.
General description on how to implement actions can be found here. Two actions can be initially implemented:

request. Given the configuration in YAML format (as expected by the enos) library, it requests an allocation in chameleoncloud. See example of how this was done earlier.

release. Given the same configuration, release all acquired resources. See how we were doing this before here.

@ulshell I've updated the description of this issue. Please let me know if something is not clear.