Ground blending breaks exam centre tiles

Describe the bug
When the Ground Blending option is enabled and you are located in the Exam Centre (south-east of Varrock), the floor tiling produces an unexpected result.
To Reproduce
Steps to reproduce the behavior:

Go to the Exam Centre
Make sure Ground Blending is enabled in the plugin settings
See unexpected result

Expected behavior
The tiling to be maintained instead of blended like other textures are
Screenshots
With Ground Blending enabled:

With Ground Blending disabled

Environment (please complete the following information):

OS: Windows 10
RuneLite version: <IP_ADDRESS>
Launcher version: 2.1.6

Maybe we can work out a way to detect patterns like this and just stop it from blending I noticed it happens in a few places m
That would fix A LOT of areas if it could be done.

Wizards Tower, Rune shop in Port Sarim, Basically half the banks and all kitchens in pre 05 Runescape

When 117 made the plugin he manually overrode almost everywhere which has this, including almost all of the stuff that you mentioned @SirFancyBacon. Some were missed, it's hard to catch everything but it works reliably.

I dunoo I've seen this a lot tbh the solution defo works for now but think detecting the tile pattern could be easy enough at some point, but more important things to do

Yeah, maybe "RLHD 2.0" can have it; but for now i think override is the best option.
What material should these tiles be though? I feel like it would need to be some type of stone/masonry since you don't tile wood (that i've ever seen anyway)

Yeah, maybe "RLHD 2.0" can have it; but for now i think override is the best option.
What material should these tiles be though? I feel like it would need to be some type of stone/masonry since you don't tile wood (that i've ever seen anyway)

Looks pretty stone-y to me

That would fix A LOT of areas if it could be done. Wizards Tower, Rune shop in Port Sarim, Basically half the banks and all kitchens in pre 05 Runescape.

Didn't you fix it at the wizard's tower a while ago ? I went back for a quest there and it has this issue.

Something like this i am thinking; But with alternating colors

That looks nice.

If we could just fix specular highlights, we could have nice looking floors like that. It's probably also possible to detect checker patterns in tiles as a scene preprocessing step, then auto disable blending for those.

Yeah i fixed most of the top but only realized recently i didn't fix the bottom :nerd_face:

Probs be nice for other patterns that occurs also I think

I think this is looking pretty good


Increase timeout in strand dump test for bal test

Purpose

Describe the problems, issues, or needs driving this feature/fix and include links to related issues.

$title
Fixes #38676
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Ran the build with tests in Ubuntu 7 times in the Github runner, the test did not intermittently fail.

Shall we create an issue track to periodically check server start without waiting 30 seconds.

Shall we create an issue track to periodically check server start without waiting 30 seconds.

Created https://github.com/ballerina-platform/ballerina-lang/issues/38737.


Reinstate inlining of repeat statements

With the latest refactoring of the assembler we turned off inlining of repeat statements which had a pretty significant negative impact on cycle count. We should reinstate this inlining.
The high level logic could be that if a repeat statement consists of simple instructions (e.g., no inner control flow), it should result in a single basic block.
A potential alternative is to do something more general - kind of what we had before: merge all adjacent basic blocks into a single basic block regardless of how they were generated.

Closed by #1454.


Do not format blank lines in multiline string literals

Fixes https://github.com/apple/swift-syntax/issues/1959
For an example, see the following code
assertionFailure("""
  First line

  Second line

  """)

There are blank lines in line 3 and 5.
The conditions for a blank line are that StringSegments is only a newline character with no trivia (line 3), or that StringSegments is a zero-length string and the trailing trivia is a newline (line 5).
However, this condition would also match empty StringSegments immediately after string interpolation in the following code. (This case is covered by testStringInterpolationAtStartOfMultiLineStringLiteral.)
assertionFailure("""
  ABC
  \(myVar)
  """)

Therefore, I also added the condition that the previous token must be ended by a newline.

@ahoppen Thanks for the guide. The formatting problem for blank lines in multi-line string literals has been fixed. However, it seems to affect other test cases. The following three test-cases fail.

DeclarationTests.testProtocolParsing()
EnumTests.testEnum21a()
OperatorDeclTests.testOperatorDecl15()

The diff for each is as follows. Perhaps a space that should be inserted has not been inserted?
// DeclarationTests.testProtocolParsing()
–protocol P{{}case <#identifier#>
+protocol P{{}case<#identifier#>
 }

// EnumTests.testEnum21a()
 enum Recovery1 {
–  case <#identifier#>:
+  case<#identifier#>:
 }

// OperatorDeclTests.testOperatorDecl15()
 precedencegroup E {
–  higherThan: <#identifier#>
+  higherThan:<#identifier#>
 }

Hi @kishikawakatsumi,
Oh, I should have totally checked whether my changes still formatted all the remaining diagnostics correctly, I’m sorry. The issue is that in the parsed tree, we represent the missing identifiers by identifiers with empty text as well and they only get transformed to the <#identifier#> placeholders in a later PresentMaker pass. Thus, all my rules of checking whether the text is empty also applied to these identifiers, which was causing the issues.
Looking into it further, I realized that the proper fix required some more, slightly more invasive changes that I, myself, would like to get a review on. I have opened https://github.com/apple/swift-syntax/pull/1964 with these changes and hope you don’t mind me closing this PR in favor of that one.

Thanks!


iterating http_sd support towards generic discovery

I believe we can make http_sd work generically out of the box without relabel_configs.
by explicitly setting the __params_target label per target (and ideally using the host header and port from the request to set the target:port) we can get service discovery to work without any jiggery pokery.
I used https://github.com/pagarme/static-response-server to host the following
[
  {
    "targets": [
      "fastly-exporter:8080"
    ],
    "labels": {
      "__param_target": "0AizkuJPvMmqhulU7fXXXX"
    }
  },
  {
    "targets": [
      "fastly-exporter:8080"
    ],
    "labels": {
      "__param_target": "0KO5PPKDAMlzAQ22fsXXXX"
    }
  }
]

along with the following minimal http_sd_configs
  - job_name: 'fastly-exporter'

    http_sd_configs:
            - url: http://static-content:7070

and everything worked out of the box.

by explicitly setting the __params_target label per target (and ideally using the host header and port from the request to set the target:port) we can get service discovery to work without

How should the fastly-exporter change?

I used https://github.com/pagarme/static-response-server to host the following . . .

It should not be necessary to run a separate process in order to use the fastly-exporter with http_sd_config.

I used https://github.com/pagarme/static-response-server to host the following . . .

It should not be necessary to run a separate process in order to use the fastly-exporter with http_sd_config.

Oh, that was literally just to test that the new json worked the way I wanted without having to diddle the golang code first.
I had already gotten your relabel_configs variant working first before looking to see how we could iterate it.

Oh! OK, sorry for presuming :)

So instead of /sd returning
[
	{
		"targets": [
			"abc",
			"def"
		]
	}
]

you want
[
	{
		"targets": [
			"localhost:8080"
		],
		"labels": {
			"__param_target": "abc"
		}
	},
	{
		"targets": [
			"localhost:8080"
		],
		"labels": {
			"__param_target": "def"
		}
	}
]

Is that right? If it works, this avoids some configuration in the prometheus.yaml — does it do anything beyond that?
Unfortunately, I'm not sure it can actually work. Consider the case of load balancers, or NAT, or anything which puts a middlebox between the client and the exporter. The host header isn't a reliable source of truth. I've fought this battle many times actually!! As far as I can see it's a properly hard problem for a process to know it's own address in a way that permits it to serve that address back callers reliably.

/cc @SuperQ if you have any input

ok, I was thinking we might have the have some problems with the host header, so...
use the ip:port that is being connected to, as seen by the fastly-exporter, as the target?
that addresses at least some of the cases and for more complex ones folks can still do relabel_configs to fix up if needed.
not great, but possibly better?  we REALLY need a prometheus placeholder for http_sd that means "come back to the hostname you asked"
targets": [
			"__meta_http_sd_url_host"
		],

Which obviously CAN be done with relabel_configs but I'd love to have it available implicitly so things work out of the box.

It would be lovely if it were possible! But I'm not aware of a way for a server to reliably deduce the address that a client used to establish an incoming connection. NAT, VPNs, proxies, etc. can all sit in front of the connection in a way that's invisible to the server. Middleboxes can intercept and rewrite traffic at the IP layer.

Unfortunately not feasible.

Well, wait a sec.  you're right that there are a myriad of problems detecting from the server side, but in this case we would just need to provide a hint to the client, who does have enough information to make the right decision.
ala, "hey client, connect to me like last time"
So we just need to convince the http_sd folks to implicitly handle the hint on the prometheus side... ;)

As an interim step on our side, we can do as you mocked up as that at least reduces the complexity of the relabel_configs while we negotiate with the http_sd folks
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: service
      - target_label: __address__
        replacement: <IP_ADDRESS>:8080

to
    relabel_configs:
      - target_label: __address__
        replacement: <IP_ADDRESS>:8080

`"service": "" can optionally be added to labels as well if we still want that explicit label

We can't do what I mocked up. "localhost:8080" is not a valid target.

it should be, no?  assuming just about every system under the sun has a localhost -> <IP_ADDRESS> lookup.
potential alternate suggestions:

<IP_ADDRESS>:8080
fastly-exporter:8080

as really the target field is currently more used as a placeholder text string for replacement then an actual host/ip for binding
i.e. in our intermediate implementation, we don't need target resolvable, we just need it to be consistent to be replaceable with relabel_configs ;)

...aaaand I have a snippet from my first attempt to not have to update the address in two places (http_sd_configs -> url and __address__)
              - source_labels: [__meta_url]
                regex: '.*://(.+)/.*'
                target_label: __address__
                replacement: ${1}

slightly wordier, but keeps up to date with whatever is used in http_sd_configs -> url via __meta_url so folks don't have to update two places.

What about that? #85

...aaaand I have a snippet . . .

Does this actually scrape each service correctly?

Upon reflection, I don't think it's the job of the exporter to try to golf it's SD implementation to minimize the required configuration on the Prometheus side. I think we just do what Prometheus says we should do and leave it at that.

I'm not a fan of golf either (code or otherwise.  possibly miniature?)
So, let me take the 10,000 foot view and explain what I'm beating this gong so hard
automated discovery of service discovery endpoints
About a year from now, folks are going to be like

Hey, http_sd is nifty (it is!)  I'd like to autodiscover service discovery endpoints (not targets, endpoints) like what is available with /metrics endpoints in kubernetes for example.

ala
kubernetes
-> [autodiscover service discovery] <- hypothetical, but reaaaaallly likely
-> [service discovery endoint (e.x. fastly-exporter/sd)]
-> [target (e.x. fastly-exporter-1/metrics)]

Now, /metrics autodiscovery is awesome as /metrics works out of the box.  Any /metrics endpoint is processed the exact same way.  ...However, currently fastly-exporter service discovery needs application specific relabel_configs transforms to work.
Part of this onus is going to be on projects (like fastly-exporter) implementing http_sd, but I think the other part is going to be on the dhttp_sd docs and examples requiring service discovery endpoints work out of the box without relabel_configs by default.
Because otherwise fastly-exporter and other implementers are going to have a gnarly time of it that we can more easily nip in the bud early.
This is why I think it is so absolutely important that fastly-exporter /sd work out of the box, not with less relabel_configs (tho I did provide examples), but with none.

These are points to raise on the Prometheus repo, not this one, I think :)

oh, I'm poking them as well ;)  I also wanted to clarify why I'm not letting this go for this project as well.

Sorry, I didn't get a chance to review this quickly.

I don't think the exporter can serve a target host:port which is reliably correct.

Yes, this is going to be the tough part. For example, in our configuration we're going to have several exporters running different shards, with semi-dynamic hostnames generated by Kubernetes.
I haven't actually gotten a chance to test the existing implementation yet, as I am working on adding additional scrape target injection into our Kubernetes magement. I think that should be done soon, so I'll hopefully be able to report back before the end of the year.


Question on cache friendliness

Hi,
Sorry to bother you once again but I wanted to know how component storage is cache friendly. Of course you use std::vector to store components but es::Component (and hence, derived components) isn't std::is_standard_layout or std::is_pod so the data is not contiguous in the memory. Well, that's my understanding of C++ at least.

Not all components are POD. What if you want to store some larger components that use std::vector/std::unordered_map/sf::Sprite? Those types of variables are going to be allocated on the heap anyway, outside of the component itself. Either way, without any of those properties, most of your components should fit inside cache (excluding heap-allocated objects within those components). C++ structs can also have padding, which might make it not considered POD, but it certainly wouldn't affect storing in cache other than taking up more space.
Honestly, this is a much smaller issue than the real problem of iterating through entities with multiple components. Lets say you have a simple movement system, that just handles Position and Velocity. The entity query function might decide that iterating through velocity components is more efficient, since there are less instances of these than positions (could have some non-moving entities). So, it iterates through the Velocity components in order, being very cache efficient. But, since the loop requires accessing/changing the Position components, it will need to load those into cache as well. Both the Velocity and Position components might not fit into cache, so they could each push each other out, making everything less cache efficient. This is especially the case for when the Position components are not being processed in order, so a chunk of the vector of position components will probably be loaded into cache for each velocity component.
By improving the order in which components are stored, this may have a bigger performance improvement than worrying about micro-optimizing for pod/standard layout components. But there would have to be benchmarks done before doing any performance improvements.

http://en.cppreference.com/w/cpp/types/is_pod
http://en.cppreference.com/w/cpp/types/is_standard_layout
These are false for structs with private variables. They should still be contiguous though, but you'd have to really test to make sure. I also wonder how inheritance affects struct layout in memory.

I think that's where my interpretation of entity component system differs from yours. I think if you're storing something like sf::Sprite as your component, you're doing it wrong. You should only have a handle or plain data to a component and system should have the logic on operating on it or you directly do it. This has some problems of its own though.
Secondly, I agree about the ordering optimization but again I think iterating through component of same type in a system is more important than iterating through entities.
But yeah, this is premature optimization stuff and would need testing if it is even a problem. I was mainly concerned that component data stored inside memory maybe fragmanted due to not being POD.


Resolves segfault issue on ClearHistory() function call

Edited RemoveDisplay(item) function to delete the map value that was asked to be removed, rather than replacing it with an unititalized pointer.
Presence of empty pointer resulted in segfault during ClearHistory() function call.
Failsafe added to Clear History to ignore empty mapped values.
Resolves segfault occuring when any plugin had been removed during the active session prior to calling ClearHistory.
Second commit removes unnecessary files.

This looks good now, but I'm not sure why the build is failing.  It seems like it's having an issue installing ros-melodic-rqt-gui-cpp, which should exist... I'll investigate.


Update advanced-real-numbers.py

I think you want "result" to be the decryption of "c_res_hoist" here, when you are printing the results with hoisting. (Right now, you have "result" as the decryption of "c_res_no_hoist" twice, both here and above, when you are printing the results both with and without hoisting.)

Hello, thanks for your correction. Can you redo the same commit to the dev branch? We don't have a contributing guide yet but the desired flow is to commit to the dev branch, and then we release it together with other features.
We can do the correction in the dev branch, but if you do it on your side, your name will be included in the commit history.

Oh, that is courteous of you. Sure: I've just requested to merge into the dev branch instead.


Bug: TS bug when passing data in useAssets

Current Behavior
When data is passed for ResourceOptions, TS errors are generated:
ts: Type '{ resolution: number; resourceOptions: { scale: number; }; } | null' is not assignable to type 'Texture | undefined'.
  Type 'null' is not assignable to type 'Texture | undefined'.

Expected Behavior
Types to be valid as a Texture
Steps to Reproduce
Pass data as:
const {
  assets: [texture],
  isSuccess
} = useAssets([{
  src: `/${name}.png`,
  data: ResourceDataOptions
}]);

Environment

@pixi/react version: v8 beta 9
pixi.js version: v8
React version: 19
ReactDOM version: 19
Browser & Version: Chrome 127
OS & Version: MacOS 14

Possible Solution
No response
Additional Information
No response

If you do not explicitly hint useAssets with a type, it has no idea what type it should be.
Given the following deconstruction of your code back into the Assets.load call directly...

When I attempt to translate that to a hook, I get the following, which I agree is incorrect; however, I'm afraid I have to disagree that it should be a Texture, as we did not tell the hook it was a Texture using the generic type param.

If I take a pass at typing this against Assets.load, I get what I believe are the results you are expecting.

Finally, if I pass the type information to useAssets, I get the following, which, in my opinion, are the expected results with the exception of the data type being inferred incorrectly.

I believe the bug and the solution here is to ensure data is always any and not inferred from T as it is in the type implementation for pixi now. LMK if that is not you expect here.

It's less of the what type data should be, while data should still be typed (where possible). It's more the return type of the return type of assets: [texture], which isn't typed as Texture when passing data.

It will not be typed as Texture unless you type it as so with useAssets<Texture>. You can not infer that it is a texture from a src url.

I am working through some tests now and almost have a PR ready that will allow for proper typing.

@itsezc can you verify this issue is resolved in<EMAIL_ADDRESS>

@itsezc can you verify this issue is resolved in<EMAIL_ADDRESS>
Yes, its resolved


cache busting

When you do a 'npm run build' it be great if the files had checksums for cache busting (like webpack does). Otherwise you will still need to something like grunt to do that.

yea I believe this is more a parcel than rogue issue since ideally they'd be handling all the bundling and we'd just be setting up client/server specific options
Right now the build script is very minimal but I intend to look back at this later


A vulnerability.

The client can get the _G Access Key.

How?

For some reason the client can request any setting (expect datastores and trello stuff) via client.Remote.Get("Setting",{"The setting index you want to get"})

Well, this is interesting. Good job "harmful" _G settings are disabled by default in the settings.

client.Remote.Get("AllSettings") returns all settings too.

Good spot.

client.Remote.Get("AllSettings") returns all settings too.

There's no vulnerability here. It's only accessible to Creators+

https://github.com/Sceleratis/Adonis/blob/b082023e766765ec843853a77193948101e528e5/MainModule/Server/Core/Remote.lua#L154

The _G access key was also used for localscripts that needed to access client tables, though I think the majority of client related _G access stuff was disabled anyway so probably better to just blacklist it and maybe make a client specific key.

Truthfully I'd like to remove _G.Access entirely

Removing the _G access API in my opinion isn't good as it still has it usecases.
But the client shouldn't really have access to some settings expecially the access key.

I blacklisted the api key for the client in the most recent release. Closing this since it resolves the issue.


adding message option to the import subcommand

Fixes #15710

@monitorjbl this is going to need integration tests under integration-cli and documentation.

Sure thing, I just wanted to see verification jobs passed. They didn't, but I'm not sure if it was something I added or not.

+1 test and we can get this in quickly.
Thanks!

Sorry, I was at a conference this past weekend. I'll get tests added as soon as I can!

Thanks @monitorjbl, changes LGTM. I think you still need to add this flag to the man pages under man. But we should move this forward to docs review as soon as other maintainers give their lgtm.

Whoops, forgot about the man page. I'll get that updated too.

Added this option to the manpage for docker-import

LGTM, failures are unrelated.
Moving to docs review.

docs LGTM, thanks!

Docs LGTM - @calavera are you doing the merging?

Awesome, thanks guys!


[tree-sitter] Folding does not work

Are you using "tree-sitter" branch?
Yes
Describe the bug
Folding org-mode files not functional (at the moment?)
Steps to reproduce
Sample file:
* Unfiled
** DONE woops, wrong file
CLOSED: [2018-06-12 Tue 21:05]

Open file above
Use shortcut <Tab> or <Shift-Tab>

Expected behavior

Using  at top-level bullet should collapse/expand tree and elements below

Emacs functionality

Same(?) behavior from emacs org-mode and master branch orgmode.nvim: elements should be collapsible/expandable

Screenshots and recordings
Will provide screenshot/gif if requested.
OS / Distro
macOS 10.15.7
Neovim version/commit
NVIM v0.6.0-dev+212-g5f8518b3f (via Homebrew)
Additional context

Current dotfiles/nvim config settings: https://github.com/Happy-Dude/dotfiles/commit/8804a95604463edf313b750a811d4961c3c82319
Installed parser via :TSInstallFromGrammar org

I'm not able to reproduce this. Here's a gif:

Are you sure your <TAB> key is properly bind?
What you get as output for this command:
:map <TAB>

Thanks for pointing out that this was a problem with my own config;
I was setting buffer-local foldmethod/foldexpr via https://github.com/Happy-Dude/dotfiles/blob/fd8c052f7f04d47986bed5f23d98114701e0588c/vim/.vim/lua/treesitter.lua#L89-L103, and things work once I replaced that snipped of code with the following: https://github.com/nvim-treesitter/nvim-treesitter/issues/475#issuecomment-748532035
Closing as this was an issue with my personal config 👍

I'll add this to readme. I didn't think about treesitter foldexpr at all, since I'm not using it. People can easily run into this problem with both foldexpr and indentexpr.


[1.9.x] Fixed #26334 -- Removed whitespace stripping from contrib.auth password fields.

https://code.djangoproject.com/ticket/26334

Commit message should reference ticket #26334, not #26344.

Merged in d0fe6c915665fa3220e84bd691ba7002a357e5c5, thanks! For future reference, you can send PRs against master and let the committer take care of the backport.


Is 'redefined-outer-name' an issue in the coding style?

This is not a bug report. But about coding style preference.
I am learning Python programming to a higher level. I run a pylint for https://raw.githubusercontent.com/pyscf/pyscf/master/pyscf/scf/hf.py
I got
302:14: W0621: Redefining name 'mol' from outer scope (line 2132) (redefined-outer-name)

I guess this is about line 302, def get_hcore(mol):, mol as an argument, the scope is local. Line 2132
mol = gto.Mole()

mol is defined outside the functions, thus the scope is global.
For maintaining and developing a large-scale program, the style may be important. May I know, in-general, do this issue matter and why?

This error is caused by the if __name__ == '__main__' block. Some objects are created there globally. They should be the only source of the warning. These code blocks were written in a very early stage of this project. They are gradually removed when refactoring each module.
Creating global variables other than certain constants is a bad practice. This should be avoided for modules newly developed. Reusing names from outer scope is not recommended as the pylint tells. But it is still acceptable IMO if using these names makes code meaningful.

Thank you very much!


#3138, improved coverage for sharding-core-preprocessor

For #3138

Pull Request Test Coverage Report for Build 694

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 67.999%

Totals

Change from base Build 490:
0.05%

Covered Lines:
11332

Relevant Lines:
16665

💛  - Coveralls

Hi, please do not use Fixes xxx it the issue is not finished, otherwise the issue will be closed.
Please use for xxx if this pull request want related some issue but not finish.

Ok, Tks.
And changed


Real time display of how many campers are using Free Code Camp

We can hit Google Analytics realtime and show how many campers are using Free Code Camp at a given time. The plan is to replace the landing page with a simple call to action at the top of the page when a camper isn't logged in. My current copy is:
"Sign up to save your progress and hang out with the 502 campers who are coding here right now."
The number would change ever second based on the Google Analytics realtime user count.

I like this!! Great idea!


WIP: Add aws-iot-fleetwise-edge recipe

Description of changes:

Adds aws-iot-fleetwise-edge recipe

repo is currently private, hence the WIP status of this PR, but will update it with the correct SRCREV once it is public.

Questions/Notes:

At the moment this PR only adds the recipe to the gatesgath branch. Is the expectation that we should open a PR for each other branch?
The aws-iot-fleetwise-edge source code is currently licensed under the Amazon Software License 1.0, hence I've added that to the licenses/ directory.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Should add a README.md to explain about modifying the config.json file with suitable values.

/run

@hefroy I am curious why the layer compat is Gatesgarth - is this due to a specific BSP you're targeting? If really it's only gatesgarth then the PR needs to be to gatesgarth-next branch.  We can discuss offline. @nateglims can also discuss.

IoT FleetWise edge repo is now public: https://github.com/aws/aws-iot-fleetwise-edge
Commit updated to reflect this and WIP status removed.

Should add a README.md to explain about modifying the config.json file with suitable values.
Done

@hefroy I am curious why we target Gatesgarth - is this due to a specific BSP you're targeting? If really it's only gatesgarth then the PR needs to be to gatesgarth-next branch. We can discuss offline. @nateglims can also discuss.
Yes as discussed this is due to us targeting the NXP S32G BSP. I've changed the base branch to gatesgarth-next.


Implement simple work stealing

This is our first version of a work-stealing scheduler. We won't stop here, there is still lots of room for improvement.

bors r+


How to Display format menu for USB Drive

Anyone can help me to understand how to show again the format menu for format USB pen Drives?
I'm going to do it manually now via DISK PART but will be fine to be implement by default

have you looked inside the More options menu?


Add a github issue template to the project

I think that it could be nice to have some standard way of formatting an issue with some basic information to fill for the reporter (like the installation method) or to check before submitting the issue.

:100:

What do you think about checkboxes in the issue template, like fastlane/fastlane

I think a mix of checkboxes (for a checklist of what people have to ensure before creating an issue) and a markdown template (with various sections to fill by the user) could be perfect

Implemented in #241


Search tags simultaneously with URL titles.

Could you add support for searching into the tags as well? This is a lot quicker than manually selecting tags in the sidebar and is helpfull when the bookmark does not have the tag in the title.

This is getting addressed in #7

@naveci The issue has been addressed in 2.0.1. If you use Firefox the update is available in the store. If you use Chrome instructions have been added to the repo on how to install the update manually (sorry)


isProvider returning wrong value

Steps to reproduce
I am not sure if it is bug or not. I am querying a service inside a middleware in some intervals. It starts few seconds after the app is launched. Lets call it "internal check". I am using isProvider hook to enable authentication only for external providers.
BUT if i use this service via socketio before the first inernal check is made, the provider in this internal check hook is set to socketio thus authentication is required and it fails. And every next internal check has this wrong provider.
If i wait for the first internal check and query the service via socketio after, it is ok. External query is authenticated and every next internal check has undefined provider, so it does not authenticate.
Expected behavior
It should always return undefined when service is used inside app.
Actual behavior
It is returning last provider value.

isProvider checks the context.provider passed to the hook on every call. It has no control over what that value is set to.
Calling services from within middleware is not typical, so I do not know what the ramifications are. I believe one thing to watch out for is services are only ready after app.listen() is run.
I believe I've seen you have already asked a question concerning calling services in middleware. I think this question belongs there for the reason first mentioned.
I'll watch that conversation. Thanks.

I think we can close this now.


Builder to run Diktat

What's done:

added a builder to run Diktat
reused it in maven plugin

It closes #1563

integrating this change into gradle plugin will be a huge change too.

We can make diktat.jar as executable and run it without ktlint. It should resolve cli and gradle issues


<IP_ADDRESS>:6688

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

<IP_ADDRESS>:6688 does not work for me in the RSE simulator, because my IP address is different. when I click on Publish, an error message also appears. so far it works, but I have a problem with the data records, because <IP_ADDRESS>:6688 is stored there.
I am using Ubuntu 22.04 and the latest Chrome browser, as well as OpenV2X-Columbia.
What can I do
Thank you very much


Added Bookmark Landing Page

Description
I've added a bookmark landing page please review it .
Fixes:  #739
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[x] I have made this from my own
[ ] I have taken help from some online resourses
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK
https://github.com/Sulagna-Dutta-Roy/GGExtensions/assets/118350936/87a794a6-2bdc-4455-b934-980a1184a302

@Sulagna-Dutta-Roy  Please check I've changed the name


IERS_A warning after downloading bulletin

Talked with @bmorris3 about this issue, said I should post this.
In [1]: from astropy.time import Time

In [2]: import astropy.units as u

In [3]: from astroplan import Observer

In [4]: from astroplan import download_IERS_A

In [5]: download_IERS_A()
Downloading http://maia.usno.navy.mil/ser7/finals2000A.all
|==================================================================================| 3.0M/3.0M (100.00%)         6s

In [6]: now = Time("2016-10-28 00:00:00", format='iso')

In [7]: astrolab = Observer(longitude = -122.3115 *u.deg,
                    latitude = 47.65371*u.deg,
                    elevation = 63.4*u.m,
                    name = "Astrolab"
                    )

In [8]: sunset = astrolab.sun_set_time(now, which='nearest')
WARNING: Tried to get polar motions for times after IERS data is valid. Defaulting to polar motion from the 50-yr mean for those.
If you need enough precision such that this matters (~<10 arcsec), you can
download the latest IERS predictions by running:

    >>> from astropy.utils.data import download_file
    >>> from astropy.utils import iers
    >>> iers.IERS.iers_table = iers.IERS_A.open(download_file(iers.IERS_A_URL, cache=True))

 [astropy.coordinates.builtin_frames.utils]
WARNING: (some) times are outside of range covered by IERS table. Assuming UT1-UTC=0 for coordinate transformations.
If you need enough precision such that this matters (~<10 arcsec), you can
download the latest IERS predictions by running:

    >>> from astropy.utils.data import download_file
    >>> from astropy.utils import iers
    >>> iers.IERS.iers_table = iers.IERS_A.open(download_file(iers.IERS_A_URL, cache=True))

 [astropy.coordinates.builtin_frames.utils]

@tobyrsmith - could you respond also with your astroplan version (astroplan.__version__), astropy version (astropy.__version__) and Python version?

In [4]: astropy.version
Out[4]: '1.0.5'
In [5]: astroplan.version
Out[5]: '0.2.dev503'
Python 3.4.3

One more diagnostic thing to double check:
Does this return True?
from astroplan.utils import IERS_A_in_cache
IERS_A_in_cache()

@eteq Isn't this different from the intended behavior? I think we would prevent that astropy warning from being raised if astroplan updates astropy's IERS A table.

In [3]: from astroplan.utils import IERS_A_in_cache
In [4]: IERS_A_in_cache()
Out[4]: True

that's weird - indeed that warning shouldn't be coming up because you download the latest tables...

Oh, wait:
now = Time("2016-10-28 00:00:00", format='iso')

That's one year in the future, and I think the IERS A go 3 months or 6 months or something only...?

Despite the now assignment, that is the date that he intended. I think this may have exposed a corner case that we didn't check – if the dates requested are far enough in the future that they're off the most up-to-date IERS A table, you still get an astropy warning (or multiple). I'm assuming this is behavior we shouldn't override for any reason?

Pinging @eteq for clarification on the above question.


Bug: User with unverfied primary email in GitHub is an "Invalid Account", no sensible logs

Expected Behavior
A user with an unverified email logs in gets an error message about email verification failed. Logs have a mention about the user having an unverified email.

Current Behavior
A user of ours was trying to log in but got 403 every time. Logs didn't have anything close to mentioning a problem with their email.

Possible Solution
Add clearer logging stating that verification of users email is lacking.

Steps to Reproduce (for bugs)

Set up a GitHub backed oauth2_proxy
Try to log in with a user who has an unverified primary email
Profit

Your Environment

Version used: Tried with 4.0.0 and 5.0.0

This has come up before though I haven't managed to find where from my quick scan of issues. We definitely need to take a look at this and make this more obvious

I'm also seeing this issue with Azure and guest accounts.

In our case, this turned out to be that we had the --email-domain option set to only allow users with our domain instead of any email domain. So, that's why we were only seeing this with guest users on Azure. Now that we've passed-in * it works correctly. So... carry on.
Not sure if the OP is having the same kind of problem with GH or something different.

We have email domain as "*"

How could this be approached? I'd love to help, but I've never contributed to this project so starting feels quite cumbersome and hard to grasp

I guess the solution would be to add some logging in the GitHub provider if the primary email is not verified?


incorrect filenames

[Enter feedback here]
Mode                LastWriteTime         Length Name

-a----         6/3/2021   2:55 PM            464 ed25519
-a----         6/3/2021   2:55 PM            103 ed25519.pub
Missing "id_" in filenames?
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 4c89b7b3-c05f-b517-6109-04e6a97195c3
Version Independent ID: 1e4b742e-d999-2c1e-a396-dc149f7ac76b
Content: Key-based authentication in OpenSSH for Windows
Content Source: WindowsServerDocs/administration/OpenSSH/OpenSSH_KeyManagement.md
Product: windows-server
Technology: administration
GitHub Login: @maertendMSFT
Microsoft Alias: damaerte

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


Avoid shell html creation in module folder

Currently, the library saves a shell html file on the fly to the libraries /static folder each time you execute an image generation. Although it's not a problem for most users, this design causes some issues where there are ownership problems with the installed module on users OS.
We can get over this issue by using following page navigation via puppeteer;
await page.goto(data:text/html,${html});

:tada: This issue has been resolved in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add small section explaining how to use "void" for inline mutations

Coverage remained the same at 93.144% when pulling 67d7ba9c4a0b8389a61cfea2394be8116d996a03 on drcmda:patch-1 into 2897e129fbd2eddc79084d8a2830525736ef0caf on mweststrate:master.