Remove some redundant variables and executions.

Note: If you encounter failed tests when building the project by running "mvn clean package", please remove "cool-core/src/test/java/com/nus/cool/core/refactor", and try to build the project again. The failed tests already exist before this pull request.

Note: If you encounter failed tests when building the project by running "mvn clean package", please remove "cool-core/src/test/java/com/nus/cool/core/refactor", and try to build the project again. The failed tests already exist before this pull request.

We have refactored the COOL system codes that is why we have a new folder "cool-core/src/test/java/com/nus/cool/core/refactor". Later, we will delete all other codes with the old version (e.g., Extendedxxxxx.java).
There may be some unit tests that will fail due to the version conflict, and we will remove these codes with the old version and clean all the unit tests.

In the refactored codes, it is easier for developers to understand the codes, and we also have updated many functions.
e.g., support extending datasets, reducing redundancy storage, and so on.

KimballCai wrote:

In the refactored codes, it is easier for developers to understand the codes, and we also have updated many functions. e.g., support extending datasets, reducing redundancy storage, and so on. <<<

Sure. That will be very helpful!

Sure. That will be very helpful!

KimballCai wrote: In the refactored codes, it is easier for developers to understand the codes, and we also have updated many functions. e.g., support extending datasets, reducing redundancy storage, and so on.

we will remove all the codes with the old version in the next two weeks.

Old-Version Code will be removed


need a logo

logo, like a jesus fish

Added a logo - Jesus fish with omari.io in the middle. Let me know what you want and I will do my best.

Dat logo is nice

It works!


Fuzzer improvements (janus branch)

Description
Warnings I added in #54 and #56 highlight certain improvements to make to the newly added fuzzer on the janus/release-0.1.7 branch; the following changes silence these warnings and provide the following improvements:

Added c++17 attributes to mark unused function parameters, improving clarity and making it easier to spot if parameters are unintentionally unused.
Unused argv and argc parameters removed from fuzzer's main().
Remove unused variable declaration in util_tests.
Avoid implicit conversions that alter a value (float promotion to double), make those explicit conversions instead, or compare floats to float literals rather than floats to double literals.
A copy assignment operator never returns in debug mode, as it contains an assert(false ...) - in this case, the function is now marked [[noreturn]] to clarify expectations.  The return call is now only present in the absence of the NDEBUG macro, where the assert would have no effect.
CAddrMan had a non-virtual destructor, despite being a polymorphic base class - the d'tor is now marked virtual as it should be.

BTC/BGL PR reward address
ETH/USDT: 0x50b92AB67A3D3DE8c3506D9287893D9a52655486

Which value do we gain from this?

The value you gain is as follows:

Unintentionally unused function parameters now generate a warning, allowing future developers to catch unintended bugs where an important parameter to a function has been missed.
Intentionally unused function parameters are clearly marked as unused, preventing future developers from wondering if there is a bug in the code where the decision has been made intentionally.
Removing unused arguments to functions cleans up the code, reduces code size, and improves readability, ultimately reducing ongoing cost of maintenance and technical debt.
Implicit conversions between float and double can change the value being converted; this can lead to subtle and unexpected bugs, especially when it the floating point values are compared directly without a sigma.  Ensuring there are no implicit conversions avoids potentially difficult to identify and machine-specific bugs.
Where a conversion is intentional, making it explicit makes the intention clear to future maintainers, reducing future maintenance burden and technical debt.
Introducing a warning to catch unintentional conversions prevents future introduction of such bugs.
CAddrMan had a non-virtual destructor, despite being a base class from which others inherit.  Base class destructors should be virtual, otherwise memory leaks can result - this is a common bug and there is no question whether it is correct for the destructor to be made virtual.  It absolutely should be, in this case.  That is why GCC produces a warning for this code, and my changes also add a warning to catch other such bugs.


C# Perimeter of Square

Resolve issue #442
Added C# code that solves for the area of a square & updated readme with solutions appropriately.

Hey @whtann
Thanks for contributing to this project 😃
This PR will be reviewed and merged shortly.

https://codinasion.web.app/programme/perimeter-of-square/


Pod not updated

It seems that when adding the project in a Podfile it does not get updated (getting 1.1.0 version).
Please check.

Agree, can someone update the pod?


De-duplicate code in the bpfman-agent

Created a common loop for reconciling *Programs
Created a common reconcileBpfmanProgram() function
Added some more getters to the bpfmanReconciler interface so we don't have to pass as many parameters around
Made all of the functions in common.go that use ReconcilerCommon methods of ReconcilerCommon

Some additional changes:

Used a different Type in the BpfProgram CRDs for fentry and fexit. With this change, the fentry and fexit controllers will only get triggered for the their own programs, and you can see the type when you get the bpfprogram CRD.
Modified Makefile in examples

Made building go userspace code and bytecode dependencies of their respective build-*-image targets
Added a target to build-all-images
This combines 4 steps into one if you want to build both images.

Fixes: #1065

/packit build

The only thing I noticed is the uprobe reconciler seems to run even when not needed at times.

Because uprobes can be attached inside containers, we need to attach them if new pods are created and delete them when pods are deleted.  So, we watch for pod events and check for relevant changes.

I'm done addressing comments.  This is ready for review again.


Bugfix. Adjust min-max ranges for get_duration_from_node_param(..)

Relates https://github.com/ros2/rosbag2/pull/1419
Bugfix. Adjust min-max ranges for get_duration_from_node_param(..)
Also, add the expected range to the exception message

@roncapat One more fix in addition.
I've realized that I put the wrong limits for min-max values for durations.


upgrade dojo.js to 0.7.9

you would need to fix the functions for contract calls with this update.
Resources: https://github.com/dojoengine/dojo.js/releases/tag/v0.7.9

On it🚀🚀🚀


i could not import the library

Error:Could not find property 'plugin' on com.android.build.gradle.LibraryExtension_Decorated@5e34222f.

Manifest merger failed : Attribute application@appComponentFactory value=(android.support.v4.app.CoreComponentFactory) from [com.android.support:support-compat:28.0.0] AndroidManifest.xml:22:18-91
is also present at [androidx.core:core:1.0.1] AndroidManifest.xml:22:18-86 value=(androidx.core.app.CoreComponentFactory).
Suggestion: add 'tools:replace="android:appComponentFactory"' to  element at AndroidManifest.xml:33:5-314:19 to override.


generateMipmap with 1x1 will flash back in uc.

Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information:

Codecov Report
Base: 44.60% // Head: 43.46% // Decreases project coverage by -1.13% :warning:

Coverage data is based on head (1483ac1) compared to base (932a076).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1246      +/-   ##
==========================================
- Coverage   44.60%   43.46%   -1.14%
==========================================
  Files         345      345
  Lines       18320    18321       +1
  Branches     2546     2547       +1
==========================================
- Hits         8171     7963     -208
- Misses       9495     9746     +251
+ Partials      654      612      -42

Impacted Files
Coverage Δ

packages/rhi-webgl/src/GLTexture.ts
43.98% <0.00%> (-0.21%)
:arrow_down:

packages/core/src/RenderPipeline/RenderContext.ts
44.44% <0.00%> (-55.56%)
:arrow_down:

...ges/core/src/RenderPipeline/BasicRenderPipeline.ts
25.00% <0.00%> (-29.42%)
:arrow_down:

packages/core/src/Camera.ts
31.84% <0.00%> (-19.91%)
:arrow_down:

packages/rhi-webgl/src/WebGLRenderer.ts
45.12% <0.00%> (-19.52%)
:arrow_down:

...ckages/core/src/shadow/CascadedShadowCasterPass.ts
17.94% <0.00%> (-16.93%)
:arrow_down:

packages/core/src/RenderPipeline/SpriteBatcher.ts
13.58% <0.00%> (-13.59%)
:arrow_down:

packages/core/src/base/Util.ts
16.21% <0.00%> (-8.11%)
:arrow_down:

packages/core/src/RenderPipeline/RenderQueue.ts
8.91% <0.00%> (-7.01%)
:arrow_down:

packages/core/src/shader/ShaderMacroCollection.ts
44.70% <0.00%> (-5.89%)
:arrow_down:

... and 9 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


[Public Catalog] Add Crazy egg script to top 6 quickstart details pages

We'd like to add the crazy egg script to the following quickstart details pages in order to better understand where users are interacting with the details page so we can make more informed design decisions on how to best optimize this page.

Codestream
Dotnet
Java
Apache
Php
Node-js

Script
 <script
          type="text/javascript"
          src="//script.crazyegg.com/pages/scripts/0045/9836.js"
          async="async"
        />

Acceptance Criteria
note: this is script is set in the DevSetSEO.js component.
-  we are seeing an error when loading the crazy egg script on production, we should resolve this.
Moved this AC to a new ticket.
Uncaught Error: CE: multiple userscripts installed
    <anonymous> https://script.crazyegg.com/pages/scripts/0045/9836.js:1

[x] Add the crazy 🥚 script to the quickstart pages listed above
[ ] When complete notify @legnaleama so he can start evaluating the data for design improvements

re: Multiple userscripts error
According to the crazyegg docs, this will not interfere with the data collection and usually happens when there is more than one account tracking the same page. I did not find that to be the case for us.

I will keep digging around.

Interesting, I'm curious to what you find @tabathadelane.

We have decided to revisit the multiple userscript error in a later ticket.


Type binding

The PR is not showing enough changes since the base branch is https://github.com/golemcloud/golem/pull/822, however shows the fundamental logic addition and test changes  (that verifies the change) for easier review.

Able to specify if there is an ambiguity in types (type annotation), as our stack based interpreter needs to know the actual types and cannot guess (we made some hacks during release 1.0 such as fall back to u64 if user specified a number which can be u8, u16 etc but this leads to a lot of corner cases, and we decided to take this path). Example returning an empty list is never possible without this strategy.

let my_list: list<u8> = [];
{status: 200, body: my_list}

There is no need to specify the type if it can infer from any function calls to worker. The following will work

let x = 1;
call_my_function(x)

Limited support, as you need to write a let binding to specify the types. But this PR will unblock users to a great extent.

Obviously, it will be a bit more user friendly for simpler expressions to work without type annotation. Example, with this PR, we see we have to specify the type of x.
let x : u8 = 1;
x

Avoiding u8 would make it sound user friendly, but making ways to allow such thing will introduce a lot of hacks into our type inference logic, and thereby the future maintainability of Rib will be in question, unless we find a non hacky structured solution to bring such user friendliness. Not to mention, Rib is mainly used to call worker functions and to a relatively good extent types will be inferred.
We had some flexibility in the code previously, to get release 1.0 going with whatever worker bridge used to do until then, but introduced corner cases.

There are things to clean up, but this is definitely 10x improved version compared to release 1.0.0
The following needs to be done:

[ ] Add TypeName node in Let Expr binding, its Protobuf versions etc (I didn't do this because most of the tests don't read from any persistent expr store. Now we need to ensure these annotations in Expr is kept intact when writing back to DB etc
[ ] Make sure CLI tests pass


After presentation review and notes

The HackMD document presented issues for some students and faculty because it requested login or sign-up -> https://hackmd.io/9wXT4nMySiG_O9y0HP58gw?view
One possible solution would be to publish the HackMD before presenting again. Or migrating it into github?

One point of confusion was when Titus jumped to the end of the notebook to show the plots for the explanation of the classical Monte Hall situation. Before the next step of the lecture (i.e. adding more doors), add some plot code chunks for students to follow.

Scott gave a simple intuitive explanation on the solution that nicely primed for deeper discussions on the math.

With always_switch() you win every time you got your initial door pick wrong! (i.e. You only get pick the wrong door initially 1/3 of the time. Winning 2/3 of the time.)

This paired with Titus' board drawing was nice. Add it to the hackmd?

Door 1
Door 2
Door 3
Probability

If car in Door 1:
Initial pick has car
Monty Hall Choice
Monty Hall Choice
$\frac{1}{3}$

If car in Door 2:
Initial pick has 'goat`
~Monty Hall Choice~
Monty Hall Choice
$\frac{1}{3}$

If car in Door 3:
Initial pick has goat
Monty Hall Choice
~Monty Hall Choice~
$\frac{1}{3}$

This explanation and table help 10 doors become immediate intuitive.

Could also add in the central limit theorem wiki
https://en.wikipedia.org/wiki/Central_limit_theorem


[version] 8u121 b13

Hello,
just a demo on how I have fixed the new url link of oracle.
Tell me what you think.

thanks @albundy83!


fix(HMS-2618): format regions error correctly

Moves the error state on RegionSelect to use inline FormHelperText and error validations.
The fix itself is wrapping the RegionSelect in FormGroup.
BEFORE:

AFTER:

Thanks! :orange_heart: definitelly better then what we have, I'm discussing with Maria how to make it even better :)


LSP failed to start in the vscode extension

Describe the bug
Failed to spawn serverpod LSP in vs code extension code. The available code has been utilized in the VSCode extension code.
To Reproduce
Steps to reproduce the behavior:

Clone the code
Head into tools/serverpod_vscode_extension
Open it in a new vs code.
Run npm i
Now hit F5.

Expected behavior
The Serverpod's LSP should run without any issues.
Screenshots

Serverpod versions

CLI Version: 1.1.0 (Github - main branch)

Platform information
ProductName:		macOS
ProductVersion:		14.0
BuildVersion:		23A5286i

Some issue with the system, but A restart fixed it. But got something new.
[Error - 01:23:43] Request textDocument/documentColor failed.
  Message: File is not being analyzed
  Code: -32007
/Users/mr.minnu/Documents/testpod/testpod_server/bin/main.dart
[Error - 01:23:43] Request textDocument/inlayHint failed.
  Message: File is not being analyzed
  Code: -32007
/Users/mr.minnu/Documents/testpod/testpod_server/bin/main.dart
[Error - 01:23:43] Request textDocument/inlayHint failed.
  Message: File is not being analyzed
  Code: -32007
/Users/mr.minnu/Documents/testpod/testpod_server/bin/main.dart
[Error - 01:23:43] Request textDocument/documentSymbol failed.
  Message: File is not being analyzed
  Code: -32007
/Users/mr.minnu/Documents/testpod/testpod_server/bin/main.dart

Was this expected?

I'm not able to replicate, are you running the serverpod cli from main as well? The language server is built into the CLI and you will also have to use the latest CLI for this to work.
After you switch to the main branch and pulled all the latest changes, make sure you run dart pub global activate --source path . from the serverpod_cli folder, to ensure you are running the latest version.
Please let me know if this didn't fix the issue.

Oh I just saw your linked code. the main branch has changed the implementation here!
You have to  change this
args: ['language-server', '--no-development-print'],

To this
args: ['language-server', '--quiet'],


Ack() unhandled request error

Hello, I can't get output of a function through ack() but it works well via say().
Also it works when output of ack() has less symbols but I wan't to emphasise that output of unhandled request within limits. It has only 1780 characters.
Thank you.
 Thanks for your question 🙌
Could you explain why you are trying to get the output of a function through ack()? Are you just trying to view the function output in your app logs, or something else?

@hello-ashleyintech  Hello, sure. I use ack() because it allows me to print output in a private-style(*Only visible to you), where only the requester receives the information. It helps avoid a spam of messages and can be used from any channel and in private conversations.

@acckiydarik Glad to hear it! Thanks for submitting this issue - since you figured it out, I'll close this out, but feel free to submit a new issue if you have any other questions 😄


163 quick action commands confirmation

Problem
Quick commands without parameters would instantly run when clicked through the menu.
Solution
Instead of instantly running the command, we show a confirmation text in the prompt input, which can be confirmed by pressing enter and denied by unfocusing or pressing escape.

Tests

[ ] I have tested this change on VSCode
[ ] I have tested this change on JetBrains

License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Is there a purpose to these checklists?

@justinmk3 We've mainly added that checklist to encourage contributors outside of the core team to think about actually testing larger (possibly breaking) changes in IDEs, as we've had some contributions come through which seemed fine at first but ended up not working properly in the actual IDE environments.

Everyone just ignores it, so it's noise.

I think it'd be better to add an alternative option stating something along the lines of "This PR doesn't necessarily require in-IDE testing".

I think it'd be better to add an alternative option stating something along the lines of "This PR doesn't necessarily require in-IDE testing". It's not being ignored in every PR, and the main reason for adding it was more so aimed at preventing external contributors from not being mindful about testing. Currently, we do not really have active external contributors.

No, we're not gonna add such kind of option and this PR definitely requires a test on vscode and jetbrains. Since it is customer facing, it is best to see them also in VSCode and IntelliJ before merging.
As an additional note, let me mention the regression we've created related with the liveserver. Our tests were passing, everything was looking ok but we've it caused the installation process to broke for the VSCode (and also most likely the JetBrains).
Depending on the PR (like changing some text etc. or just adding a new test into e2e tests) we can decide it is required or not.

Everyone just ignores it, so it's noise. Noise should be reduced.

We'll ask for a specific reason to ignore it in the PRs. We want to avoid any kind of regression as much as possible. And this checks shouldn't be skipped.
Again, as an example: to avoid regressions like postinstall liveserver addition.


Put differential entropy in separate function and keep original function

We are still missing tests!

Shouldn't we directly merge into master?

Yes, we should.
Did you run the tests on a GPU before merging each PR?
If you have a machine to do this it's fine, otherwise let me test on my GPU and do the final merge (after your review).
Usually we let the person who opened the PR merge it, while the others act as reviewers.
Sometimes after reviews, even if they all approve, the original author would like to make some small changes.
For this PR, let me run the tests against master.


How is the score calculated in "eval_detection_results.py"?  " df = pd.DataFrame(detection_list, columns=["video-id", "cls","t-start", "t-end", "score"])"

Hi!I'd like to know the score's meaning and computing method of it in "df".

Hi  have u resolve it?


Shader crashes the game after last update

revert to 90a7646b667e2f3bc5f9ac8e89b9944ac988059e solve the issue.

Lightning broken

Latest update comes with bindless texture support (require OpenGL 4.6), the decals are now temporary unavailable.


Showing result for feature not working as I thought

JIRA issue created by: rcook
Originally opened: 2011-11-28 02:16 PM
Issue body:
(nt)
This issue has attachments associated with it (external link):
government.png
government1.png

JIRA Comment by user: rcook
JIRA Timestamp: 2011-11-28 02:19 PM
Comment body:
I have misspelled this search, and we used to have a feature that would correct the spelling (that part seems to work) and then show a message "showing results for" that would then give other suggestions.

JIRA Comment by user: pkiraly
JIRA Timestamp: 2011-11-28 05:17 PM
Comment body:

	I don't think, that it is an error. The reason of this is, that stemming makes the suggestion out of the table. The suggestions displayed when there is no result at all. Try a term, which ends with an incorrect suffix, like "govermnet", it will give you the right term as suggestion.

JIRA Comment by user: rcook
JIRA Timestamp: 2011-11-28 07:41 PM
Comment body:
Can you fix the alignment issue?

JIRA Comment by user: pkiraly
JIRA Timestamp: 2011-11-29 10:36 PM
Comment body:

	Fixed

Issue resolved: 2011-11-29 10:36 PM


Add fixed-mode-toggle-chat

This is actually a fork of https://github.com/deathbeam/example-plugin/tree/fixed-mode-hide-chat but since that repo was a bit messy I've decided to do a "v2". Viewport can now be resized to normal size if chat is open (configurable).
If I didn't do this the right way, please tell me, the other option I have is making a pull request on the orig repo.

Generally we prefer PRing features to hub plugins rather than making a "v2" for small changes. Deathbeam is active and will review changes if PRed there I'm sure.


Static dimensions

In addition to static typing, matrix dimensions should be determined at compile time to:

Format matrix identifiers differently from scalar identifiers
Validate operation dimensions at compile time
Validate access-in-range at compile time
For smaller matrices, use more efficient/specialised fixed size versions
Avoid dynamic allocation in constrained environments
Allow syntax for automatically sized matrices, such as identity and unit vectors

Some problems have inherently dynamic dimensions, whether that be reading a matrix from a file, user input, or even using values unknown at compile-time for manually specified dimensions. We cannot statically deduce all dimensions, but it will be a major strength where possible.
Probably one of the first steps is to revert the assumption that a 1x1 matrix is-a scalar. This is used to mimic mathematical syntax where for a column vector x, we have xᵀx ≡ ‖x‖². From an implementation standpoint it will be much easier to treat a matrix as a container and fundamentally different type. The implicit conversion of 1x1 matrix to scalar could be implemented in the dimension checking pass, but result in an error if the dimensions cannot be deduced at compile time.

Static dimensions are implemented in https://github.com/JohnDTill/Forscape/pull/58. The PR was quite large, so I left autosizing for another time.


Add a flag to disable web security

In my project, the web requests is wrapped by other library, not fetch, so setting the headers isn't easy for me. I have to set webSecurity option to access other domains in my unit test, so I add a new flag to do this :)

Yea, after looking through new BrowserWindow it looks like plenty of other options could be potentially requested as well:

nodeIntegration
nodeIntegrationInWorker
zoomFactor
defaultFontSize

https://electronjs.org/docs/api/browser-window
Could we update this PR to add a new flag which accepts JSON content?
https://github.com/tj/commander.js/tree/v2.15.1#coercion
.option('--browser-window-options <json>', 'Flags to pass to all new browser window options', JSON.parse);

Great, I can do it in this weekend😄

I believe this PR got some accidental commits in it. It's also been inactive in the trajectory we discussed for 1 month so I'm going to close it


Minor cleanups

Miscellaneous code cleanups that do not affect functionality.

@lukego Can this be merged or do you want to amend further? Going to tag the 2015.03 release any time now.


Block async-std >= 1.7.0 from being pulled in to fix the CI.

test_runner depends on async-std. async-std depends on crossbeam_utils. crossbeam_utils 1.8 does not work with our nightly Rust (due to const_fn-related churn). The existing dependency allows Cargo to pull in async-std 1.7, which pulls in crossbeam_utils 1.8 and breaks our build. By limiting async-std's version to <1.7, this prevents crossbeam_utils 1.8 from being pulled in, keeping our build working.
I tried to update our nightly Rust version to fix this, but encountered several issues that will take some time to solve. This fix is intended to last until we update to a newer Rust nightly.

bors r+


Scope Enhancement - Fixed lines in Device Location APIs

As enhancement for Device Location APIs (verification, retrieval), this proposal includes the support of fixed lines n those APIs as a natural evolution, not restricting the access of mobile lines.
Scope enhancement:

Include landlines in location APIs (verification, retrieval)

Related to #92

Hello @jgarciahospital
Sorry if my question si a bit dumb but when we are about localisation I tend to think we are in (explicit) consent legal base. So in the case of the landline how do you envision the capture of this consent?


FIXupdate config for disable_nested_complex_type

Proposed changes
update disable_nested_complex_type  with master-only and description
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run p0

run buildall

run p0

run buildall

run buildall

run buildall

run buildall

run compile

run p0


Add Traffic Ops Client Update Funcs

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/707/
Test PASSed.


trash and ram-disk

Hi.
make ram-disk & cd to
touch file
trash file
trash -l
does not show files in trash bin.
Maybe you can also make your 'trash' look more like rm?
trash -I file   # remove without confirmation
trash directory_name   # remove without warning etc.
Regards.

does not show files in trash bin.

The file inside a ramdisk (or any other kind of mounted volumes) are trashed to /Volumes/[ramdisk]/.Trashes/[uid]/, and unfortunately sudo is required to access that directory. It is only possible to get that via AppleScript or SBApplication (which is the method ObjC trash used). Last time I checked it was not easy to do the SBApplication way with swift, but seems it is feasible now.

Maybe you can also make your 'trash' look more like rm?

I'll add the -i switch, but I'll not change the behavior trashing a directory.

The changes are push to the repo.


Read files without triggering onDidOpenTextDocument.

vscode.workspace.openTextDocument(..) will trigger the vscode.workspace.onDidOpenTextDocument(..) callback
Some extensions (eg. vscode-java) may relay on this (particularly for pom files) in order to activate other functionality generating a false positive (ie. pom file was "opened")

Signed-off-by: Roland Grunberg<EMAIL_ADDRESS>I was able to reproduce this by having vscode-quarkus + vscode-pde installed (with all associated dependencies), and then opening eclipse.jdt.ls as a project, and ensuring that some Java source file is opened. Once the project is loaded, you should see a flurry of notifications opening and disappearing very quickly. They all appear to be from the vscode-java dependency analytics prompt.

I don't think I see popups, but I do see something on the left of the bottom bar. Is this what you are mentioning? If so, then this PR does prevent that from happening.


VSR: Messages prior to pipeline must be committed

The commit_max ~cannot~ must not fall behind replica.op -| pipeline_max.
Since DVCs include replicas' commit_min instead of commit_max, we can't just rely on taking the maximum from the DVCs.

Superseded by https://github.com/tigerbeetledb/tigerbeetle/pull/364


--env: support more shells, allow explicit shell selection

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.
[x] Have you successfully run brew tests with your changes locally?

brew --env can be given an explicit shell argument via shell.
The basename of the path is compared against a known list of
shells.
An explicit argument of --shell= or --shell ''
with an empty string forces brew --env to dump the environment in
the key: value format that it uses when it detects that
stdout is a tty.
If an explicit shell is not supplied from the command line and
stdout is not a tty, then brew --env will check the parent process,
then its parent process etc until it finds a process with an
argv[0] that is either a known shell name or a known shell name with
- prepended
When I ran the test suite I encountered one failure in an integration test
if I run the test suite under tcsh but none if I run it under bash. The integration test
will probably need to be updated to use an explicit shell.
Here's an excerpt of the failing case.
  1) Failure:
IntegrationCommandTests#test_env [/Users/greg/opt/brew/brew-dev/Library/Homebrew/test/test_integration_cmds.rb:113]:

I used the construction
for x in 1..MAX_ITERATIONS
    # body does not include x
end

which was rejected by the style-checker / static analysis tool.
Is there a way to run the style tests locally?
Is there anything like Integer::times but with early termination?

It probably wants you to do
(1..MAX_ITERATIONS).each do
   # ... body, and I think you can use 'break' for early exit ...
end

> Is there a way to run the style tests locally?

Yep. `brew style <filename.rb>`. This uses [RuboCop](https://github.com/bbatsov/rubocop), with some Homebrew-specific options.

Made a bunch of comments here. I like the idea and where it's going but probably needs a few rounds of style tweaks to get there. Thanks!

When I ran the test suite I encountered one failure in an integration test
if I run the test suite under tcsh but none if I run it under bash. The integration test
will probably need to be updated to use an explicit shell.

Could you do this? Thanks.

Just want to point out:

You can find a existed implemention to find present shell at here https://github.com/Homebrew/homebrew-command-not-found/blob/master/cmd/brew-command-not-found-init.rb#L3-L17
I think the method of finding parent/preferred shell as well as how to export value in these shells can be used in multiple place of Homebrew. So I think it is a better idea to put shell related methods to a new file, e.g. Library/Homebrew/utils/shell.rb. It could be something like this:

module Utils
  module Shell
    def self.preferred_shell
    end

    def self.parent_shell
    end

    def self.shell_profile
      # move current method at https://github.com/Homebrew/brew/blob/master/Library/Homebrew/utils.rb#L510-L517 to here
    end

    def self.export_value(shell, key, value)
    end
  end
end

Still todo:

tests
refactor shell-related utility commands to utility class
2a) use symbols for shell names instead of strings
ARGV
Do we look at the argv[0] of just the parent processes or multiple processes before falling back to SHELL?

So, I cleaned up the style a little bit, fixed the failing integration test, and added sh_quote (also works for fish) and csh_quote implementations that should probably be refactored into the new shell utility class. The existing practice of putting double quotes around the raw value breaks for values containing ", $, ` ... `, $( ... ) (and possibly more) in sh-derived shells and for values containing ", $, !, ` ... ` or a literal newline in tcsh.
I'm also overloading --shell so that with an an explicit empty value --shell=, it prints in the key: value and doesn't quote anything. This is the format used when brew detects that the output is a tty. This format is convenient to script against if you need to parse the output for some reason.
@mikemcquaid
I fixed the style issues. As for the parsing ARGV I can't seem to find documentation for a value method for arrays or for ARGV specifically (which I think is just an array). I essentially haven't written any Ruby before so even basic stuff is tricky :/
@xu-cheng
I just want to get a better understanding of what the different methods in the proposed utility module do.
Does self.preferred_shell return the value of the SHELL environment variable or does it return the value taken from the command line?

@gregory-nisbet For example, you can:
module Utils
  module Shell
    def self.preferred_shell
      case ENV["SHELL"]
      when %r{/(ba)?sh} then :bash
      when %r{/zsh} then :zsh
      when ... then ...
      else :bash # default to bash
      end
    end

    def self.parent_shell
      case `ps c -p #{Process.ppid} -o 'ucomm='`.chuzzle
      when %r{/(ba)?sh} then :bash
      when %r{/zsh} then :zsh
      when ... then ...
      else preferred_shell
      end
    end

    def self.shell_profile
      # move current method at https://github.com/Homebrew/brew/blob/master/Library/Homebrew/utils.rb#L510-L517 to here
     case preferred_shell
     when :bash then "~/.bash_profile"
     ...
     end
    end

    def self.export_value(shell, key, value)
      case shell
      when :bash, :zsh then "export #{key}=\"#{value}\""
      ...
      end
    end
  end
end

@gregory-nisbet You might want to look at the shellwords module for the quotes thing.

I fixed the style issues. As for the parsing ARGV I can't seem to find documentation for a value method for arrays or for ARGV specifically (which I think is just an array). I essentially haven't written any Ruby before so even basic stuff is tricky :/

Don't worry, we're happy to help. ARGV.value is a Homebrew internal thing; you can see a usage example here: https://github.com/Homebrew/brew/blob/1fa48234e5301f018dc93e62bc7e03d71729b296/Library/Homebrew/cleanup.rb#L141-L149

I added the utils/shell.rb file and some tests to test_intregation_cmds.rb .
The shell_profile method (https://github.com/Homebrew/brew/blob/master/Library/Homebrew/utils.rb#L510-L517) has been moved and its tests updated.
Broadly speaking, most of the changes I made involving shell_profile are probably wrong / not idiomatic since I used Utils::Shell.shell_profile all over the place. I'm still trying to figure out the module system works and how pseudo-static methods (def self.method_name) work.
ARGV.value does not seem to distinguish an explicit value of empty string, e.g.
When executing this command
$ brew --env --shell=

The value of ARGV.value("shell") would be nil.
I think it should be empty string, but other parts of the codebase may depend on this behavior. So right now I'm using --shell=none to explicit force brew --env to output the build environment in the key: value format. I'm thinking it should probably either be --shell= with an empty argument or a dedicated command line option like --noshell or --prettyprint or something.

The last few builds seem to be failing at least in part because a merge conflict that I resolved manually (affecting diagnostics.rb) in this branch seems to be producing an invalid patch file or something. (Although I think there's also a problem related to ruby 1.8 compatibility ...)
This PR now has a bunch of changes in it that could be factored into two PRs... one for utils/shell.rb and one for csh and fish support.

I allowed myself to tweak the PR title to make it more descriptive. Feel free to adjust it if I failed to capture the gist of this PR.

This PR now has a bunch of changes in it that could be factored into two PRs... one for utils/shell.rb and one for csh and fish support.

I think it's fine to keep them together. After all, utils/shell.rb grew out of the needs of this PR. However, you could rebase your work on top of master (if you haven't already), then squash and possibly amend the commits in your branch so that you end up with these two commits:

Introduces utils/shell.rb. Makes adjustments to affected parts of Homebrew.
Enhances cmd/--env.rb.

(This will also help resolve the problem that our test bot is currently unable to pull your changes.)

I added some unit tests for utils/shell.rb in tests/test_shell.rb, alphabetized the shells in utils/shell.rb. and updated the unit tests.
I changed the way that csh_quote and sh_quote work to be more like Shellwords.shellescape. Instead of wrapping the whole thing with "...", it just inserts \ as needed and replaces newline with "\n" or "\\n" as appropriate.

Also ... how do I squash the commits so the tests can be run on the build bot?

Squash commits by running brew update; git checkout $YOUR_BRANCH; git rebase --interactive origin/master and then mark each commit other than the first as squash or fixup then git push -f. Thanks!

Okay, I'm really confused now. In the latest test run, I'm seeing the following statuses for the result of two tests in Yosemite, El Capitan, and Mavericks.
tests	1 min 18 sec	Fixed
tests --no-compat	56 sec	Fixed

I don't see any errors, but the build is still marked as failing. I'm also seeing test (no failures) in the summary for each of the OSes.
I've incorporated all the feedback I've gotten so far (thanks again for your patience, everyone), except for @xu-cheng's suggestion to change the export key=value message to something shell-specific in a few places because I'm not sure what to do.
I followed @UniqMartin's suggestion to change brew --env to have backwards-compatible behavior (I think the only thing that I changed is escaping the contents of variables). Meaning that it will use the plain output if stdout is a tty and bash-compatible syntax if it is not. An explicit shell can be specified with --shell and a shell will be inferred if --shell=auto. The --env option also honors --plain.

I don't see any errors, but the build is still marked as failing. I'm also seeing test (no failures) in the summary for each of the OSes.

Ignore the failure, it's a false negative.

@BrewTestBot test this please

Wait ... no way. It's passing now? What was up with the test bot? Also, the way the csh_quote works is broken because it doesn't insert double quotes when inserting a single-quoted newline. I'm going to update that now and add a test.

What was up with the test bot?

It was suffering from a mild case of the ol' FUBAR. We're hoping to fix the real issue at some point but for now there's a mitigation in place.

I have modified the help text in diagnostic.rb to be shell-specific and added tests for the new features.

So there might not be enough csh users to justify including that specifically and I can remove it, but I think the Utils::Shell thing and shell-specific profile advice is probably useful. I don't think there are any open style concerns at the moment...

This is looking really good now. A few final, minor tweaks and conflicts that need resolved and I think we can 🚢 this. Thanks for all the patience and hard work @gregory-nisbet: almost there!

Just to check, will shell_profile continue working or does every example need to be changed?
We use shell_profile in at least a couple of formulae (And it should be used more widely really, rather than assuming everyone in the world uses bash).

Sorry for the late comment and for the long intermediate silence @gregory-nisbet! I'd like to give this a more thorough test and a review, but I'm a bit short on time this weekend. I'd appreciate if merging this could wait a few more days. (I'll try to follow up with a proper review as soon as possible.)

Thanks for your patience and feedback, everyone.
@MikeMcQuaid
I factored out the regex into a constant. I’m not sure what to call it since newlines are also unsafe (in fact, they are so unsafe they need to be quoted individually).
UNSAFE_SHELL_CHAR = /([^A-Za-z0-9_\-.,:\/@\n])/

sh_quote and csh_quote are still pretty similar, not really sure what to do since the right place for sh_quote would probably be in some kind of compatibility wrapper for ruby 1.8 since it’s the same as shell_escape. csh_quote could easily be just a call to shell_escape that throws an exception if the string contains a newline.
@DomT4

As for shell_profile, the old shell_profile is still there in Library/Homebrew/utils.rb, so there shouldn’t be a problem with scripts that depend on it. I can add a deprecation notice to the old definition.
Since the new method is in a new utility module I think it needs to be referred to as Utils::Shell.shell_profile, but I’m not sure how the Ruby module system / strategy for namespace management actually works.
@UniqMartin
Sounds good. I look forward to your feedback.

I factored out the regex into a constant. I’m not sure what to call it since newlines are also unsafe (in fact, they are so unsafe they need to be quoted individually).

👍

As for shell_profile, the old shell_profile is still there in Library/Homebrew/utils.rb, so there shouldn’t be a problem with scripts that depend on it. I can add a deprecation notice to the old definition.

Yeh, add one using opoo and move it to Library/Homebrew/compat/utils.rb, thanks.

Sorry for the delay. Moved the shell_profile function, added deprecation warning.

LGTM. Any final thoughts, @UniqMartin?

An explicit argument of --shell= or --shell ''
with an empty string forces brew --env to dump the environment in
the key: value format that it uses when it detects that
stdout is a tty.

brew --env --shell='' appears to run as brew --env does. brew --env --shell ''  produces Error: No available formula with the name "".
brew --env --shell=bash produces export CXX="clang\+\+" which seems wrong.

@gregory-nisbet any news here?

@MikeMcQuaid
Thanks for the ping and sorry for the long delay.
I think that brew --env --shell '' is bypassing cmd/--env.rb completely.
As a quick experiment I added a debug puts in cmd/--env.rb and doesn't print in the brew --env --shell '' case, but does with --shell='' and --shell bash.
  8 module Homebrew
  9   def __env
 10     ENV.activate_extensions!
 11     ENV.deps = ARGV.formulae if superenv?
 12     ENV.setup_build_environment
 13     ENV.universal_binary if ARGV.build_universal?
 14
 15     shell_value = ARGV.value("shell")
 16     puts "woof"
 17     puts shell_value

as for escaping the + when the shell is set to bash, this is what Shellwords.escape does.
irb(main):010:0> Shellwords.escape '+'
=> "\\+"

If it's overkill / looks bad in this case I can change the sh_quote function to be less aggressive.
export CXX="clang\+\+"
I can add a test for the brew --env -shell '' case and try to track down why it isn't delegating to the --env subcommand like we would expect.

If it's overkill / looks bad in this case I can change the sh_quote function to escape things less aggressively.

That's fine then, ignore me 👍

I can add a test for the brew --env --shell '' case and try to track down why it isn't delegating to the --env subcommand like we would expect.

Thanks 👍

regarding the mysterious brew --env --shell '' thing. The same error shows up if you give it a name that isn't a valid formula.
brew --env --shell fishl for instance does fails with the same error
Error: No available formula with the name "fishl"
fish, bash, zsh and the other shells I tested just happened to also be valid formula names.
I'm going to change the --env command so that it doesn't keep processing unused arguments as formula names.

Is there a plan for cleaning up argument parsing and making it more consistent?
I think fixing the brew --env --shell <whatever> case should be a consequence of cleaning up the argument parsing rather than special-cased, since we're grabbing the command line argument with ARGV.value anyway.
brew --env <name_of_formula> does have a valid use case. It's just that most formulas happen not to modify the environment.

I'm afraid I don't understand why the observed behavior is a problem. ARGV.value("shell") returns <whatever> from --shell=<whatever> (note the equals sign instead of a space). It doesn't work if used with --shell <whatever>, but it happily returns an empty string for --shell= (i.e. an empty value to the --shell option). --shell <whatever> could be handled by ARGV.include?("--shell") followed by ARGV.next, but I'm strongly in favor of only supporting the --shell= style.
Sorry if I'm completely missing the point and for how long the PR has been sitting here. I've failed to set aside some time to review it and to help get it to a mergeable state …

@gregory-nisbet @UniqMartin What's your understanding of what needs addressed here before merge?

I don't think there's anything else that needs to be addressed, since some of the quirks of argument parsing have a reasonable explanation.

Looks good to me locally. Thanks for the hard work and patience here @gregory-nisbet!  You rock! 👏


add bcc replay protection opreturn output when coinselection signals …

…it should be added

Worth mentioning that there's direct control over the data being written in the OP_RETURN, but the potential for abusing this feature is rather low.. users would notice it pretty quickly, plus it's limited to 80-bytes, and there can only be one per transaction.


[BUG] "Configure node certificates" needs details

What is the bug?
when DN of a certificate does not match any in plugins.security.authcz.admin_dn, you will see the following log:
[2021-11-16T06:35:07,521][ERROR][o.o.s.t.SecurityRequestHandler] [<IP_ADDRESS>] OpenSearchException[Illegal parameter in http or transport request found.
This means that one node is trying to connect to another with
a non-node certificate (no OID or security.nodes_dn incorrect configured) or that someone
is spoofing requests. Check your TLS certificate setup as described here: See https://opendistro.github.io/for-elasticsearch-docs/docs/troubleshoot/tls/]

"Check for special characters and whitespace in DNs" states:
https://opendistro.github.io/for-elasticsearch-docs/docs/troubleshoot/tls/#check-for-special-characters-and-whitespace-in-dns

The security plugin uses the string representation of Distinguished Names (RFC1779) when validating node certificates.
If parts of your DN contain special characters (e.g. a comma), make sure you escape it in your configuration:

actually, what users should know is not the RFC nor "special characters" in the RFC, but the following command:
openssl x509 -noout -in /usr/local/etc/opensearch/localhost.pem -subject -nameopt RFC2253

"Configure node certificates" states:
https://opensearch.org/docs/latest/security-plugin/configuration/tls/#configure-node-certificates

The simplest way of configuring node certificates is to list the Distinguished Names (DNs) of these certificates in opensearch.yml. All DNs must be included in opensearch.yml on all nodes.

it is not that simple in reality. when playing with a new application, the best way is to try the example provided and to change one thing at a time. the example in the documentation is:
plugins.security.nodes_dn:
  - 'CN=node.other.com,OU=SSL,O=Test,L=Test,C=DE'
  - 'CN=*.example.com,OU=SSL,O=Test,L=Test,C=DE'
  - 'CN=elk-devcluster*'
  - '/CN=.*regex/'

the example is correct, definitely. however, in reality, your DN might be:
CN=node.other.com,C=DE,OU=SSL,O=Test,L=Test

i guess it is semantically wrong, but anyhow, that is the DN in this case. it is hard to see the difference. it is user's error, but the log is not very helpful. instead of explaining the format, there should be a definite command that produces the correct DN, which is what users want to know.
elastic is far better in this regard. they have detailed troubleshooting guides, error messages and descriptions, common pitfalls, etc.
How can one reproduce the bug?
Steps to reproduce the behavior:

Try to configure TLS
Figure it why it does not work

What is the expected behavior?
the openssl command should be documented in the page.
"Configure TLS certificates" page needs more details. what is requirements for certification and key? does it support EC key? SAN is required? which one is used to verify hostname? CN, or SAN?
A page, "Troubleshooting TLS", should be there, too.
Do you have any screenshots?
no
Do you have any additional context?
no

Hey @trombik, thanks a bunch for reporting. Are you referring to the openssl command that returns a certificate's DN? If so, that's documented here: https://opensearch.org/docs/latest/security-plugin/configuration/generate-certificates/#add-distinguished-names-to-opensearchyml
Also, we have a troubleshooting TLS page in the troubleshooting section of the site: https://opensearch.org/docs/latest/troubleshoot/tls/
I agree that the section  is by no means extensive, so we try to add in content as issues come in or if we run into them ourselves during testing.
Hope this helps!

the bug is not specific to opensearch; there are many other applications that document TLS setup poorly. as opensearch now requires TLS by default, it is quite important to explain details in the doc. I know it is hard to maintain good documentation, but TLS section needs a lot of improvements. as manually maintaining a CA is not feasible in practice, many users use third-party tools, such as Active Directory or cfssl. detailed trouble-shooting section will certainly help. I will appreciate:

requirements in TLS (especially certificates)
clear explanations in logs (for example, "authentication failed" is hardly helpful)
better trouble-shooting section

anyway, please consider the Issue as an expression of my frustration. I believe many feel the same thing. this might be a major hurdle for potential users.


Suggestion: Add Chance of Random Research Removal

Greetings,
Just reading through the description, and could it be possible to add a percentage chance of losing random research on death?
Also is it possible to add in specific permission nodes so we could increase/decrease the values per Server Premium Ranks?
per say; you level up in-game with a prestige system, you have a lower chance of random loss/failed research percentages?

You want to allow people to pay money for premium ranks to be ‘punished’ less by this addon, which you added to the server?

No, No. Its not a money ranking system.
My ranks are not designed to be that way.
but i want it to be those who've grinded their way to the highest level, have less of a chance of research loss.

Hmm, Server Premium Ranks tend to mean something very specific, though benefit of the doubt I guess

plz!


Convert parameters to destructured object refactoring throws 'Could not apply refactoring'

TS Template added by @mjbvz
TypeScript Version: 4.8.0
Search Terms

getEditsForRefactor

Testing microsoft/vscode#158636

Open https://github.com/microsoft/vscode/blob/bb70d7ab19f7295fe669b6384a6c8ccd73d05cc3/src/vs/workbench/services/workspaces/common/editSessionIdentityService.ts#L35
Right click on workspaceFolder
Select Refactor > Convert parameters to destructured object from the context menu
See an error like so:

Minimal repo:
interface IFoo {
    bar(a: number, b: string): void
}

class Foo implements IFoo {
    bar(a: number, b: string): void { // run convert here
        throw new Error("Method not implemented.");
    }
}

@RyanCavanaugh @DanielRosenwasser  Should we omit the refactoring suggestion in this case? Or do we need to try to convert the parameters to a destructured object? I'm not sure about the following case
interface IFoo {
    bar(a: number, b: string): void
}

class C1 implements IFoo {
    bar(a: number, b: string): void { // run convert here
        throw new Error("Method not implemented.");
    }
}
class C2 implements IFoo {
    bar(a: number, b: string): void {
        throw new Error("Method not implemented.");
    }
}
class C3 implements IFoo {
    bar(a: number, b: string): void {
        throw new Error("Method not implemented.");
    }
}

Generally if something is crashing due to an unanticipated condition that's difficult to handle, simply not offering the refactoring is fine. We can take the "X refactor should show up under Y condition" suggestion issue later if it arises.


Bugfix: Presenter not destroyed when Fragment is popped off the backstack

Hello everyone,
currently I'm working on a fix for #33.
We thought it would be better if we add all relevant Unit-Tests first so it would be easier to develop the bugfix. Additionally I've created a new Activity for the "Sample" application which can be be used to interactively test the Fragment lifecycle under different circumstances (e.g. back stack or configuration change).
I would like to open this PR as early as possible to make it open for discussion.
Please feel free to comment and contribute!

I added stubs for all testcases and moved the current implementations to the matching method. There have been already two different implementations for case saviorTrue_retainTrue_backstackFalse_dontKeepActivitiesTrue_activityFinishing previously called saviorTrue_retainTrue_dontKeepActivitiesTrue_activityFinishing and saviorTrue_retainTrue_dontKeepActivitiesTrue_fragmentAttached_activityFinishing. I wasn't sure what "fragmentAttached" meant.

Method generator code, in case we have to adjust the method names in the future

fun main(args: Array) {
for (savior in listOf("true", "false")) {
    for (retain in listOf("true", "false")) {
        for (dontKeepActivities in listOf("true", "false")) {
            for (backstack in listOf("true", "false")) {
                for (action in listOf("activityFinishing", "activityChangingConfiguration",
                        "popBackstack")) {

                    if (backstack == "false" && action == "popBackstack") {
                        // not a valid case
                        continue
                    }

                    val impl = """
                    |        final TestPresenter presenter = new TestPresenter(new TiConfiguration.Builder()
                    |                  .setUseStaticSaviorToRetain($savior)
                    |                  .setRetainPresenterEnabled($retain)
                    |                  .build());
                    |
                    |          final TiFragmentDelegate<TiPresenter<TiView>, TiView> delegate
                    |                  = new TiFragmentDelegateBuilder()
                    |                  .setDontKeepActivitiesEnabled($dontKeepActivities)
                    |                  .setIsAdded(true)
                    |                  .setIsHostingActivityFinishing(${if(action == "activityFinishing") "true" else "false"})
                    |                  .setIsHostingActivityChangingConfiguration(${if(action == "activityChangingConfiguration") "true" else "false"})
                    |                  .setSavior(mSavior)
                    |                  .setPresenter(presenter)
                    |                  .build();
                    |
                    |          // TODO implement testcase
                    |          fail();
                    """.replaceIndentByMargin()

                    println("public void savior${savior.capitalize()}_" +
                            "retain${retain.capitalize()}_" +
                            "backstack${backstack.capitalize()}_" +
                            "dontKeepActivities${dontKeepActivities.capitalize()}_" +
                            "$action(){\n$impl\n}")
                }
            }
        }
    }
}

}

Great! 👍  I guess fragmentAttached was a fallacy :-D

I think I solved it!
First of all I made a few decisions:

Presenters will be destroyed when the Fragment is not managed by the FragmentManager. This happens when FragmentManager#remove or replaced is called and the Fragment is not in the Backstack.
The Presenter works now like the savedInstanceState but of course it doesn't survive process death.

TiConfiguration#setUseStaticSaviorToRetain(Boolean) will not be supported in the future. First of all nobody uses it, second it's a implementation detail of this library and especially when using Fragments there is no way to make Presenters survive without the Savior.

TiFragment will not work with setRetainInstanceState(true). I've learned that only Fragments without UI should set retainInstanceState to true. Since setUseStaticSaviorToRetain(false) was deprecated we can always use the Savior and everything works fine.

Solution
The solution requires the ActivityLifecycleCallbacks to detect when Activities get destroyed. Here is a Usecase which makes a lot of trouble:

Add FragmentA with backstack true
Replace FragmentA with another Fragment (B). FragmentA is not detached in the backstack, only onDestroyView got called, not onDestroy
Trigger Activity configuration change. FragmentA#onDestroy() andFragmentA#onDetach() got called. The FragmentManager only holds a serialised FragmentState from FragmentA, no instance exists.
Finish Activity. Because no instance of FragmentA exists the FragmentManager clears the FragmentState without any callback. Normally the TiPresenter of FragmentA would leak here.
New: ActivityLifecycleCallbacks detect the finished Activity and all associated Presenter and destroys them properly.

Missing

[ ] Using ActivityLifecycleCallbacks makes testing currently impossible
[ ] Documentation about deprecation of TiConfiguration#setUseStaticSaviorToRetain(Boolean)
[ ] Prevent setting TiFragment#setRetainInstanceState(true).

Please verify before merge:

[ ] same Fragment instance added and removed. Now added again. A new presenter instance should be created.
[ ] How does the Fragments behave in a ViewPager

@passsy I didn't understand the use of ActivityLifecycleCallbacks.
I thought this check should fix backstack problem
if (!mTiFragment.isInBackstack())

@ar-g the problem is that there is no Fragment instance where this code could be executed. When a Fragment is in backstack and the Activity get's recreated the FragmentManager only holds a FragmentState containing all information about the Fragment. Just a simple record. At this time the Presenter is still alive because a Fragment instance could be instantiated from the FragmentManager by popping the backstack.
When the Activity gets destroyed the FragmentManager drops this record. It doesn't create a Fragment instance which could give any callback. Because there is no callback I can't destroy the Presenter and it will leak. That's why I listen for the Activity to finish and destroy all remaining Presenters (those for FragmentState backstack entries) associated with this Activity.

The solution is ready all tests are finally green. Some documentation is missing and a lot of testing!

I'd be happy to test this. Is there a snapshot build I can grab with gradle?

we don't have public snapshots, sorry. But you can build the project and publish to your local maven.
// publish aars to mavenLocal()
./gradlew clean bundleRelease publishToMavenLocal`

add this to your project Top-level build.gradle:
allprojects {
    repositories {
        jcenter()
        mavenLocal() // access your local maven
    }
}

Look into jetpack.io (i think thats the name... many projects use this), it
gives you gradle dependency for any commit in a github repo. It also tells
you on its ui if the compilation was successful when you try resolving your
dependencies. Good luck☺
בתאריך 19 באפר׳ 2017 07:44, "Pascal Welsch"<EMAIL_ADDRESS>כתב:

we don't have public snapshots, sorry. But you can build the project and
publish to your local maven.
// publish aars to mavenLocal()
./gradlew clean bundleRelease publishToMavenLocal`
add this to your project Top-level build.gradle:
allprojects {
repositories {
jcenter()
mavenLocal() // access your local maven
}
}
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/grandcentrix/ThirtyInch/pull/78#issuecomment-295223262,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAxq9E4PIQLNRmPOwXUY8V7_F8wSzTuBks5rxexVgaJpZM4MiKf1
.

Jep. Like @dave08 said. You can use jitpack.io
-> https://jitpack.io/#grandcentrix/thirtyinch/bugfix~fragment_backstack_presenter_not_destroyed-SNAPSHOT
I've successfully triggered the build. So that this branch is ready to use ;)

I'm the original reporter of #33 and I'm happy to confirm that this fixes the issue for me. 👍

I was able to simplify the onDestroy() logic in TiFragment and TiActivity. I also added all required tests for the TiActivity.
Also:

removed the NonConfigurationInstance recover method. setUseStaticSaviorToRetain(false) is deprecated and therefore it was never used. The savior does a better job.
removed hard "Don't keep Activities" checks. This is not required anymore. isFinishing and isChangingConfigurations are enough information. The "Don't keep Activities" check was unreachable code.
TiFragment#setRetainInstanceState(true) will now throw and is not supported.
added documentation

I'm now happy with the result and look forward for the merge. Next step: write release notes 😁

multiple calls to TiPresenter#destroy() are ok. We have multiple triggers to detect the Activity destroy case and we can't say which one fires first. We could guard them with if (!presenter.isDestroyed()) { presenter.destroy(); }. I don't think this is useful.

I've checked the ViewPager behaviour like we discussed.
See #84


windows-switcher.exe

I need help finding Windows-switcher.exe on Windows 11 after following instructions.  It does not appear to be there. Thanks.

Windows Switcher does not need to be installed. Simply download and unzip the zip file, then click window-switcher.exe to run it.

Thanks but I could not find the .exe file ?

From: sigoden @.>
Sent: Monday, July 15, 2024 8:15 AM
To: sigoden/window-switcher @.>
Cc: Mark Rosenberg @.>; Author @.>
Subject: Re: [sigoden/window-switcher] windows-switcher.exe (Issue #123)
Windows Switcher does not need to be installed. Simply download and unzip the zip file, then click window-switcher.exe to run it.
—
Reply to this email directly, view it on GitHub [github.com]https://urldefense.com/v3/__https://github.com/sigoden/window-switcher/issues/123*issuecomment-2227837908__;Iw!!PDiH4ENfjr2_Jw!Ace3jh3r0kEQPIJWZFpapfOC5gu3T08Qj0FvJRtBVtga6lVhOuvv8EGY4oDnfpaRRgVXmx2TlgUZ_NKpA8aDfUtuwC2_i00h3hg$, or unsubscribe [github.com]https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/A46IR37T7IPTXL2IKSLVIJDZMNZHPAVCNFSM6AAAAABK36MWOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXHAZTOOJQHA__;!!PDiH4ENfjr2_Jw!Ace3jh3r0kEQPIJWZFpapfOC5gu3T08Qj0FvJRtBVtga6lVhOuvv8EGY4oDnfpaRRgVXmx2TlgUZ_NKpA8aDfUtuwC2_C2k6vUc$.
You are receiving this because you authored the thread.Message ID: @.***>

Did you really read the readme?
download the zip file from github releases, unzip it, and there is the window-switch.exe file in it.

I did read it. I find windows-switcher  configuration settings only- no exe file.

From: sigoden @.>
Sent: Monday, July 15, 2024 8:53 AM
To: sigoden/window-switcher @.>
Cc: Mark Rosenberg @.>; Author @.>
Subject: Re: [sigoden/window-switcher] windows-switcher.exe (Issue #123)
Did you really read the readme?
download the zip file from github releases, unzip it, and there is the window-switch.exe file in it.
—
Reply to this email directly, view it on GitHub [github.com]https://urldefense.com/v3/__https://github.com/sigoden/window-switcher/issues/123*issuecomment-2227895440__;Iw!!PDiH4ENfjr2_Jw!CIO6fDHw494tBUnx0UMLVTFxTQMyvXOm_R3T9rS94WaQoywRmQnh9DssfwEaMr141D55-11SIQ7HtcNVn5zs0qtBjG4BqD6IbDw$, or unsubscribe [github.com]https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/A46IR35K5RNZ62675IXL2XLZMN5WXAVCNFSM6AAAAABK36MWOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXHA4TKNBUGA__;!!PDiH4ENfjr2_Jw!CIO6fDHw494tBUnx0UMLVTFxTQMyvXOm_R3T9rS94WaQoywRmQnh9DssfwEaMr141D55-11SIQ7HtcNVn5zs0qtBjG4B2WFskzU$.
You are receiving this because you authored the thread.Message ID: @.***>

Maybe your window explorer hides the exe suffix.
There is only one file in the zip, what else is it besides exe?

Hi, Here is a screenshot of the folder (including hidden files).
Thanks.
[https://res.cdn.office.net/assets/mail/file-icon/png/photo_16x16.png]Screenshot 2024-07-15 092434.pnghttps://livemanchesterac-my.sharepoint.com/:i:/g/personal/mark_rosenberg_manchester_ac_uk/EZw480NlohtBgWSwgTq3UJYBhi4bi2mHaWm8kaqKZlEoHQ

From: sigoden @.>
Sent: Monday, July 15, 2024 9:08 AM
To: sigoden/window-switcher @.>
Cc: Mark Rosenberg @.>; Author @.>
Subject: Re: [sigoden/window-switcher] windows-switcher.exe (Issue #123)
Maybe your window explorer hides the exe suffix.
There is only one file in the zip, what else is it besides exe?
—
Reply to this email directly, view it on GitHub [github.com]https://urldefense.com/v3/__https://github.com/sigoden/window-switcher/issues/123*issuecomment-2227921472__;Iw!!PDiH4ENfjr2_Jw!HVt_nsSL6muuhXFxAu8nMa2h1cwZP-JYICwE7BrkVRF9KL9wn7DvB8PenDAInEuFdt8Vh-0PdldHcB0hcuBuvqbocitLgZIYNEo$, or unsubscribe [github.com]https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/A46IR34MN5FQTKVHKRC4WD3ZMN7QLAVCNFSM6AAAAABK36MWOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXHEZDCNBXGI__;!!PDiH4ENfjr2_Jw!HVt_nsSL6muuhXFxAu8nMa2h1cwZP-JYICwE7BrkVRF9KL9wn7DvB8PenDAInEuFdt8Vh-0PdldHcB0hcuBuvqbocitLvrqx2Nc$.
You are receiving this because you authored the thread.Message ID: @.***>


Outlook Web javascript error preventing the page to complete.

Outlook Web javascript error preventing the page to complete.  As a result the spinning icon on chrome tab never goes away.
I tracked the issue to this page:
https://webpoolbl20a24.infra.lync.com/ucwa/oauth/v1/applications/112963265580/events?ack=52&key=
The page somehow never returns and always has the pending status code.

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

ID: 427c5507-02f5-3f2a-cc5d-dca1409fd7c8
Version Independent ID: c3f76881-a543-e4dc-c8ed-6e2a1fe5d402
Content: Skype for Business Online support in Outlook on the web
Content Source: Skype/SfbOnline/set-up-skype-for-business-online/skype-for-business-online-support-in-outlook-on-the-web.md
Service: skype-for-business-online
GitHub Login: @tonysmit
Microsoft Alias: tonysmit

@intensite  Thank you very much for posting this issue. Considering the nature of the issue, it is advised that please open a service ticket in your tenant and follow with them for the resolution. If you wish to know how to open the service ticket, please follow this link https://www.youtube.com/watch?v=puuOy0sEg1Y
We will be very happy if you can share the outcome or resolution with us. We will certainly update this documentation with your valuable piece of information. Thanks again, for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Mod conflict report

https://www.curseforge.com/minecraft/mc-mods/vics-point-blank
1.21 farbic，when using together will wont display frying pan's texture

Unfortunately due their licensing, I cannot see their source code. I would report the issue to their project to see if they might be causing the issue.


fix Remove introduction to unstable features

Proposed changes

Remove introduction to unstable features
Rename some sub-titles to avoid mixed use of chiniese and english

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Add you to my RSS feed?

Hi,
I would like to add "formvalidator-swift" to my RSS feed – is that okay?
https://github.com/MKGitHub/TheSwiftSweets

@MKGitHub By all means, you may link to the repo in your RSS feed. :smile:
If you have any comments, questions, or concerns about the library don't hesitate to open an issue (or better yet an accompanying pull request!).


mozilla/thimble.mozilla.org#2581 - Added CSSAtRuleCodeHints and CSSPseudoSelectorHints to bramble extensions

I've added the bramble extension files according to Thimble issue mozilla/thimble.mozilla.org#2581. Please let me know if this looks okay!

@humphd Of course. Here is a demo of the CSSAtRuleCodeHints and CSSPseudoSelectorHints extensions at work, @flukeout.
CSS @ rules:

CSS pseudo selectors and elements:

👍 looks great—let's do it!

Thanks @ericsuhn, this is great!


JBEAP-19546 - Fixing an issue of getRequestURI().

Signed-off-by: Rhuan Henrique Silva<EMAIL_ADDRESS>

@rhuan080  I am closing this PR in favour of https://github.com/undertow-io/undertow/pull/898 that provides a more complete solution to the bug


Container image bad http status: 403 Forbidden

windscribe-proxy client version v1.2.0 is starting...
main.go:195: WARNING  Failed to load client state: open /state/wndstate.json: no such file or directory. Performing cold init...
main.go:198: CRITICAL Cold init failed: Session call failed: bad http status: 403 Forbidden, headers: http.Header{"Cache-Control":[]string{"no-cache"}, "Cf-Cache-Status":[]string{"DYNAMIC"}, "Cf-Railgun":[]string{"..."}, "Cf-Ray":[]string{"..."}, "Connection":[]string{"keep-alive"}, "Content-Type":[]string{"text/html"}, "Date":[]string{"..."}, "Expect-Ct":[]string{"max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""}, "Server":[]string{"cloudflare"}}, body: "\n\n"

Hi!
Old anonymous auth doesn't work anymore. Try to remove wndstate.json if it was created in program directory and specify login and password for windscribe account using -username and -password options.


[WIP] Generate links in api layer

Related Issue(s):

#432
Related to https://github.com/stac-utils/stac-fastapi/pull/453

Description:
Moves link generation into the API layer to create better separation of concerns between API/backend libraries.  Links are split into two categories:

Inferred links (self, root, parent, child etc.) are dynamically generated by the API layer based on the request path and the stac object returned by that request.
Backend specific links (next, prev, links to external resources etc.) may be returned by backend implementations and resolved by the API layer - urljoin(base_url, link['href']).   The current landing page is a good example of this; links to children collections are generated by the backend (Backend.all_collections) and resolved by the API layer.  This allows backends to return their own links, and makes it easy for users of those backends to extend this behavior.

With this PR the starlette request object is no longer passed to the backend client as a key word argument and core.py no longer imports HTTP specific things like urllib.parse.urljoin, fastapi.Request, and stac_fastapi.types.request.get_base_url.
TODOs

[ ] Check the API spec to make sure we are returning recommended links for each endpoint.
[ ] Make sure media types are correct.
[ ] Figure out a good way to differentiate between the two types of links mentioned above.  The API layer should override any inferred links returned by the backend and resolve + pass through any other links.
[ ] Write tests.

PR Checklist:

[ ] Code is formatted and linted (run pre-commit run --all-files)
[ ] Tests pass (run make test)
[ ] Documentation has been updated to reflect changes, if applicable, and docs build successfully (run make docs)
[ ] Changes are added to the CHANGELOG.

A few ideas for differentiating between links:

Reserve a handful of link relations to be used for inferred links.  Some link relations like self are obviously inferred but there is some gray area.  For example the data relation is currently used by the landing page for /collections but data could easily apply to other links too.
Require that backend implementations return additional link members indicating if the link should be inferred.  The API layer would strip this additional link member from the payload before returning the API response to the caller.  For example:

{
    "rel": "next",
    "type": "application/geo+json",
    "method": "GET",
    "href": "/search?token=12345",
    "inferred": false,
}

I definitely agree with the third option using precedence.
The other thought I had related to ability to control extensions that add additional links is to use the request.scope['routes'] and request.scope['route'] to introspect the App (same as how the OpenAPI docs are created - and there are some examples there that we could use) and to include any links that are at the next level up as the "self" link. This would mean that when requesting "/" endpoint, that it should auto-discover the "/conformance" endpoint and that it would be able to scan the routes and if the FiltersExtension was enabled, it would also find the "/queryables" endpoint. The mime_type would be able to be found on the response_class.

use the request.scope['routes'] and request.scope['route'] to introspect the App

I think this is a really good idea, I can play around with it in another PR.

Closing as OBE #555.


dynamic linking cannot be stepped through using gdb

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

$ go version
go version go1.13.3 linux/amd64

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

What did you do?

A simple demo
package main

import (
	"fmt"
	"os"
	"time"
)

var a = 0

//go:noinline
func TestFunc() {
	a++
	time.Sleep(time.Millisecond * 100)
}

func main() {
	fmt.Println(os.Getpid())
	for i := 0; i < 100000; i++ {
		TestFunc()
	}
}

go install -buildmode=shared -linkshared  std
go build -linkshared main.go
./main
Then I use gdb  to debug, when I use s for single step debugging, it will appear:
which has no line number information.
gdb attach 3839
What did you expect to see?
Can be debugged step by step.
What did you see instead?
Type "apropos word" to search for commands related to "word"...
attach: No such file or directory.
Attaching to process 3839
[New LWP 3840]
[New LWP 3841]
[New LWP 3842]
[New LWP 3843]
[New LWP 3844]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fb989b424b3 in runtime.futex ()
   from /root/py3/Project/go/pkg/linux_amd64_dynlink/libstd.so
(gdb) b main.TestFunc
Breakpoint 1 at 0x55563d1f77a0
(gdb) c
Continuing.

Thread 1 "main" hit Breakpoint 1, 0x000055563d1f77a0 in main.TestFunc ()
(gdb) s
Single stepping until exit from function main.TestFunc,
which has no line number information.

Thread 1 "main" hit Breakpoint 1, 0x000055563d1f77a0 in main.TestFunc ()
(gdb) s
Single stepping until exit from function main.TestFunc,
which has no line number information.
0x00007fb989b2c680 in time.Sleep ()
   from /root/py3/Project/go/pkg/linux_amd64_dynlink/libstd.so

Even if I use go build -gcflags = '-N -l' -linkshared main.go , still get the same error.
When I use the static link go build main.go, it can be stepped normally.
The process of my analysis:
Add -x option to re-compile, it can be seen that when ld is called, -w is added
root/py3/Project/go/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -installsuffix dynlink -buildmode=exe -buildid=0NYYkm8PmmuyphRyKmYC/4b2T8RfBMeRtkph2OZPF/9y-yYjcMEG_-re1WmH11/0NYYkm8PmmuyphRyKmYC -linkshared -w -extld=gcc /root/.cache/go-build/9d/9d922fc73643e08291edcd472d78431a941d02ea4a67c48a58d6e240635f2934-d
/root/py3/Project/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # internal

In the source code, if the -w option is added, the .debug_line information will not be generated
func dwarfGenerateDebugSyms(ctxt *Link) {
	if !dwarfEnabled(ctxt) {
		return
	}
	……

	// Write per-package line and range tables and start their CU DIEs.
	debugLine := ctxt.Syms.Lookup(".debug_line", 0)
	debugLine.Type = sym.SDWARFSECT
	debugRanges := ctxt.Syms.Lookup(".debug_ranges", 0)
	debugRanges.Type = sym.SDWARFRANGE
	debugRanges.Attr |= sym.AttrReachable
	syms = append(syms, debugLine)
	……
}

I guess -w was added here, and there is a legacy TODO
func buildModeInit() {
	gccgo := cfg.BuildToolchainName == "gccgo"
	……
	if cfg.BuildLinkshared {
		if gccgo {
			codegenArg = "-fPIC"
		} else {
			switch platform {
			case "linux/386", "linux/amd64", "linux/arm", "linux/arm64", "linux/ppc64le", "linux/s390x":
				forcedAsmflags = append(forcedAsmflags, "-D=GOBUILDMODE_shared=1")
			default:
				base.Fatalf("-linkshared not supported on %s\n", platform)
			}
			codegenArg = "-dynlink"
			// TODO(mwhudson): remove -w when that gets fixed in linker.
			forcedLdflags = append(forcedLdflags, "-linkshared", "-w")
		}
	}
}

I want to ask, for dynamically compiled programs,  cannot use gdb for single-step debugging, Is there any consideration or any bug?
Is there a supporting plan for this?
This scene is very important to me, I am looking forward to receiving your reply, thank you.

@jeremyfaller

I suspect that supporting this scenario is not something that can added easily or with tiny tweaks to the Go linker; some work will be required (possibly quite a lot of work).
First a bit of a digression on DWARF type generation in general:
DWARF type generation (e.g. creation of the part of DWARF .debug_info that relates to types of variables, function, etc) has an implicit assumption that the compiler has a complete picture of the type in question. Inside a DWARF type DIE (the unit of DWARF that describes a variable/value/function type) you can have references to other types, but those references have to be to some other well-defined DWARF type DIE -- you can't say something like "this struct type ABC has a field F refers to type X, where X is defined in some other shared library, please wait and look for it later".
As a result, most compilers handle this by emitting DWARF for a translation unit that is a complete picture of everything the compiler has seen referenced as part of the compile. So for example let's say you are compiling a C++ source file with a type like
  typedef struct {
     int somefield;
     SomeStruct content;
     std::set<int> visited;
  } Mumble;

For C/C++ it is a given that at the point we see a type T, we have seen textual definitions of all other types referenced by T.  For the type above, that means we've seen the entire definition of "SomeStruct" (including its dependencies) and all the complex stuff that goes into "std::set".
When a C++ compiler emits DWARF for an object file whose source file refers to the type above, it creates DWARF types for everything referenced by that type. [Note: some C++ compilers will omit DWARF for types that are entirely unreferenced, but this is something of a grey area.]. This generally results in huge amounts of duplicate DWARF info, since many source files include the same large set of headers. The result is that you get huge object files, long compile times, and giant amounts of duplicated DWARF info in the final executable.
The Go compiler, in contrast, emits DWARF type info only for types defined in the package being compiled. For example, when compiling this package:
 package p

 <imports>

 type Q struct {
   x int64
   mu sync.Mutex
   b bytes.Buffer
   ...
 }

The Go compiler will not emit DWARF type info for "sync.Mutex" (since this type is not defined in package p). It will emit a mostly-complete DWARF type unit for "Q", but with references (via relocations) to the other types that it uses (in contrast to C/C++, where the compiler would emit DWARF type records for the transitive closure of the referents of Q).  The Go compiler relies on the Go linker to combine together all of the type DIEs into a single consistent unit and resolve the references between them.
Doing things this way (as opposed to the C/C++ "emit DWARF for everything you have ever seen" strategy) is one of the reasons why Go builds are lightning fast, especially as compared with building a C/C++ program of equivalent size.
Inside the Go linker, a reachability analysis (also called "dead code") is performed at an early stage to collect up only those functions and variables that are actually used (transitively reachable from main.main). It then examines the set of reachable funcs/variables to see which types they use, and then finally it emits DWARF info for only those types. Consider this example:
 package mumble

 type Used struct {
   field AlsoUsed
 }

 type AlsoUsed struct {
   B bool
   X []byte
 }

 type NotUsed struct {
   something interface{}
 }

 func Hallo() Used {
   ...
 }

Here there are three types declared, but only two are referenced by some reachable function (let's assume that no other function in the program refers to the type "mumble.NotUsed"). The linker will pick up on this fact during DWARF generation, and will not generate any DWARF for the unused type.
This results in DWARF type info that is much more compact than what you would get from (for example) a C++ compiler, which is a major benefit for Go users. So with the Go toolchain you get two huge benefits: A) super fast builds, and B) nice compact binaries.
Getting back to the -linkshared case:
When you run "go build -linkshared main.go", the compiler emits DWARF type information for things in main.go, and then hands things off to the Go linker. At that point however the linker is presented with an incomplete picture with respect to DWARF types -- there will be references/relocations in the main.go object file to types that are defined in the standard library... but the standard library has already been compiled and linked.
Thus in order for things to work properly, we would have to invent some way for the linker to dig into the contents of libstd.so's generated type info to find the set of stdlib types referenced by the transitive closure of types reachable from main.go, then emit that into the resulting executable. DWARF type generation would need to be changed so that any time once type refers to another, we can handle the case where the thing being referred to has to be excavated from an already-compiled shared library.
This seems possible, but would require some doing.
It is also worth noting that -linkshared is a pretty unusual case for most Go users, meaning that fixing problems like this have not been a big priority.

Maybe a workaround is to generate DWARF line tables but not type info? The original issue is about single-stepping, so this will probably make it work.

That's certainly one way to go. Clang/LLVM supports that I believe (e.g. the -gline-tables-only option).

@thanm Thank you for your detailed reply.
I need to take a moment to understand this.
I found that golang  plugin mechanism can correctly generate debug information,
As far as I know, plugins is also dynamically links, is there any difference between the handling of plugins and linkshared?

@thanm Thank you for your detailed reply.
I need to take a moment to understand this.
I found that golang  plugin mechanism can correctly generate debug information,
As far as I know, plugins is also dynamically links, is there any difference between the handling of plugins and linkshared?

@thanm I guess we don't want to introduce another flag. We could do something like the following:

let cmd/go stop passing -w to the linker
if linkshared, the linker suppresses DWARF type generation but still generates DWARF line tables
if -w is explicitly requested, still disable all DWARF generation

Then the default case would work.

@WangLeonard the difference is that plugins are self-contained. When building a plugin, you have the full transitive dependencies.


Invincibility suggestion!

Came from the lifesteal plugin but so glad I found this!
Not sure if this is the right spot for suggestions but possible to add an alias for invincibility such as /timer? and a lang file to change the text? (My server is not English based). Much thanks for making such a simple plugin

Yes I can make that possible! Expect it to be done today or on Saturday! If you have any other suggestions (even for whole plugins) please tell me via Discord or here! :)

Good to know! I look forward to the release gracias !

All done you can download the latest release and it's all included! Just delete your current plugin folder and restart the server with the current plugin installed and you can edit the new config.yml to your liking. You can then test the plugin by deleting the logs folder, the playercache.json and in your world the playerdata folder! If you run into any problems or have suggestion just contact me here or on discord and I'll look into it! :)


Added the validation component

Thanks @tunr! You can see I did a bit of cleanup here: https://github.com/mattstauffer/IlluminateNonLaravel/commit/15803517c871e5761b6a8bc1e21f045f072b9e79
Great stuff!


start requiring kubelet trust

This pulls finishes the wiring for requiring proper serving certs from kubelets
@sjenning
/assign @sttts @mfojtik

kubelets are only signed by the CSR, so if we trust the CSR bundle we should be fine.

Only the typo, lgtm otherwise.

/retest

I need https://github.com/openshift/cluster-kube-apiserver-operator/pull/238 to have a conditional sync function.

/retest


Feature request: ignore fresh channels

When I run checkchannels on my node, the recommendations list contains several channels that are just a couple of days old. My own fee adjustment scripts need around 1 month to reach low levels, and I don't expect channels to perform in that time frame. As such, I'd appreciate a grace period in the computation, so that only old and useless channels show up in the checkchannels output. Let's say 2016 blocks aka 2 weeks?

That's a good idea. I think doubling that to 4 months might be even better.
When listing the channels, should there also be a flag for young channels?

Yes, that should help avoid confusion ("why isn't it in the recommendation list?"). And it's fair, as "never sent" and "never sent, very new channel" sound very different to me.

I've just pushed this improvement, let me know how it works for you

Perfekt, thank you!


How to uninstall?

I changed my theme to another one but the sidebar is still dribbbbish style.

Duplicate of https://github.com/morpheusthewhite/spicetify-themes/issues/120