(projectile-project-root) returns incorrect value

What did you expect to happen?
Run (projectile-project-root) visiting non-project buffer, expect to get nil.
What actually happened?
Returns the last project visited. Furthermore, it resulted in visible breakage of doom-modeline path entry (since it relies on projectile to display buffer path information).
Additional details:
This appears related to #3205 but that fix seems to not be effective here.
When I traced through (projectile-project-root) in edebug it was clear that somehow the cache gets into a bad state (i.e. variable projectile-project-root-cache contains entry for non-project files), and M-x projectile-invalidate-cache was not effective in removing the bad cache values and the associated mode line breakage; I had to restart Emacs.
Note also that this behavior doesn't happen with plain emacs (emacs -Q) with only projectile loaded.
Attached is a repro that clearly shows wrong project names in ivy buffer and as eval results.  None of the org files in this example belong to projects yet they are reported to belong to project "projectile" (since that was the last project visited).
Below the gif is a screenshot demonstrating the doom-modeline breakage due to incorrectly reported project root. The incorrect buffer names will persist until I restarting Emacs, which is quite annoying.

I believe the cause of this is the same as 60ca118, which I just pushed a fix for. Let me know if that isn't the case and I'll reopen this. Thanks for bringing it to my attention!

Appears to be working, thanks!


Upgrade to Spring Boot 3.0.1

Bumping spring boot to 3.0.1. Have to use java 17 since that's the minimum version spring boot 3 is supporting. Client /java generation with openapi still annotates with javax.* and not jakarta, but it seems to work fine nevertheless? Think this is fixed in newer versions of openapi-generator, so we should remember to upgrade.

I think the annotations don't do much here anyway 🤔 It seems like they are mostly for checking your code for warnings in intellij etc

LGTM, but is it fine to "demand" integrators to use java 17 @thxmasj  ?

LGTM, but is it fine to "demand" integrators to use java 17 @thxmasj ?

I think it is ok for now. Java 17 is current LTS and has been out for 1.5 years soon. If we see that as a problem it shouldn't be a big deal for us to change and compile everything but the webflux-client and client-test with target 11 again.


[SDK-4333] Implement remaining OAuth apis

🔧 Changes
Implements the following remaining OAuth APIs:

LoginWithAuthCode
LoginWithAuthCodeWithPKCE
LoginWithClientCredentials
RefreshToken
RevokeRefreshToken

As well as the UserInfo API on the top level Authentication client.
For the UserInfo response, we implement a custom UnmarshalJSON to allow us to store unknown claims in a AdditionalClaims field in the returned struct, this is to hopefully avoid the need for solutions like this in the auth client.
📚 References

🔬 Testing
Covered by added tests and manually tested.
📝 Checklist

[ ] All new/changed/fixed functionality is covered by tests (or N/A)
[ ] I have added documentation for all new/changed functionality (or N/A)

Codecov Report
Patch coverage: 74.19% and project coverage change: -0.11 :warning:

Comparison is base (0234aea) 94.48% compared to head (6e9eccc) 94.38%.

Additional details and impacted files
@@            Coverage Diff             @@
##             beta     #226      +/-   ##
==========================================
- Coverage   94.48%   94.38%   -0.11%
==========================================
  Files          43       43
  Lines        7455     7547      +92
==========================================
+ Hits         7044     7123      +79
- Misses        324      333       +9
- Partials       87       91       +4

Impacted Files
Coverage Δ

authentication/oauth.go
66.36% <72.72%> (+20.90%)
:arrow_up:

authentication/authentication.go
88.88% <76.92%> (-11.12%)
:arrow_down:

authentication/authentication_request.go
74.15% <100.00%> (+6.74%)
:arrow_up:

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


Extra whitespace in footer after "Edit on GitHub" link

Looks like the intent is for the dot is to be a separator, not a period, which is why there is extra padding.  The actual character being used is unicode code point 183 -- the · HTML entity -- which is a bit higher off of the baseline than a period.  Agreed that the extra spacing makes it harder to tell that the dot is being used this way.  Perhaps a different symbol would be clearer... like maybe a dash, or a lighter/heavier dot?
Looks like the responsible code is actually in the cloudflare-docs-engine repo: https://github.com/cloudflare/cloudflare-docs-engine/blob/master/src/components/docs-footer.js#L25-L27

Closing as not a bug - this is expected behavior.


Is there an option to disable slugified URLs?

I have a notion with multiple pages of the same title, so slugified URLs break. I don't mind having a URL with the full ID, is there any way to disable slugifying URLs?

After a bit of detective work I figured it out.
I realized that the URLs are not slugified in production, so there must've been a toggle somewhere.
This seemed curious https://github.com/transitive-bullshit/nextjs-notion-starter-kit/blob/main/lib/map-page-url.ts#L5
So I set includeNotionIdInUrls  to true in the site config, every URL is not slugified now!

You should really consider pinning this issue, or at least adding the includeNotionIdInUrls config option to site.config.js template.
Anyways, thank you for this amazing project, my site looks amazing!

I have the same problem as you. Can you tell me in detail how you solved it？

@MHC-I add "includeNotionIdInUrls": false as part of the JSON in your site.config.js.

@transitive-bullshit  Yeah, I failed to reload just now. Now I have solved it. Thank you very much. This is a good project.


Version 2.0.0-beta.1

Needs to have a beta since replicache beta 7.0.0-beta.3 is not
compatible with v1.

Will deal with 1.x first though


Docker image eating up my disk space that is not used by docker

I have setup docker and I have used  completely different block device to store docker's system data:
[root@blink1 /]# cat /etc/sysconfig/docker
# /etc/sysconfig/docker

other_args="-H tcp://<IP_ADDRESS>:9367 -H unix:///var/run/docker.sock -g /disk1/docker"

Note that /disk/1 is using a completely different hard drive /dev/xvdi
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  5.1G  2.6G  67% /
devtmpfs        1.9G  108K  1.9G   1% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
/dev/xvdi        20G  5.3G   15G  27% /disk1
/dev/dm-1       9.8G  1.7G  7.6G  18% /disk1/docker/devicemapper/mnt/bb6c540bae25aaf01aedf56ff61ffed8c6ae41aa9bd06122d440c6053e3486bf
/dev/dm-2       9.8G  1.7G  7.7G  18% /disk1/docker/devicemapper/mnt/c85f756c59a5e1d260c3cdb473f3f4d9e55ac568967abe190eeaf9c4087afeac

The problem is that when I continue download docker images and run docker containers, it seems that the other hard drive /dev/xvda1 is also used up.
I can verify this problem by remove some docker images. After I removed some docker images, /dev/xvda1 has some more extra space now.
Am I missing something?
My docker version:
[root@blink1 /]# docker info
Containers: 2
Images: 42
Storage Driver: devicemapper
 Pool Name: docker-202:1-275421-pool
 Pool Blocksize: 64 Kb
 Data file: /disk1/docker/devicemapper/devicemapper/data
 Metadata file: /disk1/docker/devicemapper/devicemapper/metadata
 Data Space Used: 3054.4 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 4.7 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.20-20.44.amzn1.x86_64
Operating System: Amazon Linux AMI 2014.09

ping @vbatts :)

I have the same issue.  Also, if you have the extra disk(s) that you can alllocate for docker's use, please consider using the --storage-opt flag to give devicemapper a dedicated data and metadata block device. This is what it accomplishes by default in the loopback files. Though direct block device will be much better performance. See https://github.com/docker/docker/blob/master/daemon/graphdriver/devmapper/README.md

@PlugIN73 not sure if your case is the same here; this issue is about docker using up space in the wrong location, not "taking up space" in general. Bonus tip for your cleaning-up tasks; if you clean up containers that use "volumes", use docker rm -v ... to also delete the volumes, otherwise they will be left behind.

closing as dup of https://github.com/docker/docker/issues/9786


CONFIG_ROM_START_OFFSET change to be added to cause west flash reset fails, in NXP RT11xx platforms

Describe the bug
for RT1170 use below command to download the image, debug reset does not work, but hardwarereset works.
west build -b mimxrt1170_evk_cm7 west flash --runner jlink --tool-opt='-SelectEmuBySN<PHONE_NUMBER>94' --  '--device=MIMXRT1176xxxA_M7' '--reset-after-load'
the serial console has no output at all, press reset key works. but this blocks twister testing. bisect found below commit introduce such problem
`
commit 44628735b870b2806bbea47477c3300bb624ad31 (refs/bisect/bad)
Author: Daniel Leung<EMAIL_ADDRESS>Date:   Mon Feb 13 13:31:26 2023 -0800
linker: rom_start_offset: add to address instead of set

The CONFIG_ROM_START_OFFSET is supposed to be added to
the current when linking, instead of having the current
address set to it. So fix that.

Not sure why it worked up to this point, but llvm/clang/lld
complained that it could not move location counter backward.

Signed-off-by: Daniel Leung<EMAIL_ADDRESS>
diff --git a/arch/common/rom_start_offset.ld b/arch/common/rom_start_offset.ld
index 2e82f30d71..8546391614 100644
--- a/arch/common/rom_start_offset.ld
+++ b/arch/common/rom_start_offset.ld
@@ -4,5 +4,5 @@

SPDX-License-Identifier: Apache-2.0
*/

-. = CONFIG_ROM_START_OFFSET;
+. += CONFIG_ROM_START_OFFSET;
. = ALIGN(4);
`
Expected behavior
west flash can works
Impact
twister testing
Logs and console output
whent this happen no console output
Environment (please complete the following information):

OS: (e.g. Linux, MacOS, Windows)
Toolchain (e.g Zephyr SDK, ...)
Commit SHA or Version used:  zephyr-v3.3.0-530-g1751c8f0f5

this impacts mimxrt1170_evk_cm7 and mimxrt1160_evk_cm7

@dleach02 @mmahadevan108 this blocks all testing for RT11xx series, need check.

Pinging @dcpleung for awareness

Just revert it and we will deal with llvm/lld later.


Use regex for device name to match all Launchpad devices

Hey great project, it's awesome to be able to finally use the launchpad from ruby! (with one change!)
The hardcoded Launchpad device name causes the following error if one attempts to use this library to interface with another Launchpad model, such as the mini (which I own):
.../launchpad.rb/lib/launchpad/device.rb:350:in `create_device!': MIDI device  doesn't exist (Launchpad::NoSuchDeviceError)
	from .../launchpad.rb/lib/launchpad/device.rb:102:in `initialize'
	from ./examples/colors.rb:3:in `new'
	from ./examples/colors.rb:3:in `<main>'

This Mini's Portmidi output device is as follows:
> Portmidi.input_devices
=> [#<Portmidi::Device:1 @name="Midi Through Port-0", @type=:input>, #<Portmidi::Device:3 @name="Launchpad Mini MIDI 1", @type=:input>]

By applying the following fix, I was able to get it working.

You could still use the library as is by specifying the name of your device explicitly:
Launchpad::Device.new(device_name: 'Launchpad Mini MIDI 1')
# or
Launchpad::Interaction.new(device_name: 'Launchpad Mini MIDI 1')

The default device name "Launchpad" is just this: an overridable default. Since I wrote this quite some time ago, it uses the original launchpad's standard device name. I actually wouldn't want to use a regex here that just uses the first device that could match, since the API is designed to also work with arbitrary names, even when you have multiple launchpads attached.
I'm gonna close this now, but thanks for your suggestion. I'm glad the gem is still in use. :)


responsive support?

Any plans for responsive support?

From what I understood this is not only a PoC, but actually implemented in released versions.
<!DOCTYPE HTML>
<html style="width:100%; height:100%; margin:0px; padding:0px;">
  <head>
    <title>Responsive</title>
  </head>
  <body style="width:100%; height:100%; margin:0px; padding:0px;">
    <iframe id="viewer" src="/ViewerJS/#../welcome.odt" style="width:100%; height:100%; margin:0px; padding:0px;" allowfullscreen webkitallowfullscreen></iframe>
  </body>
</html>

Works both for documents in portrait mode, when zoom controller set to "Full width" or "Automatic" (which does 100% or fit to width if view too small), and in landscape mode (where no controller is offered by "Full page/slide" is hardcoded.
So closing this issue, as it seems already done. If I misunderstood the request, please reopen and tell what still is missing.


The file uploaded by the client in the mode of transfer encoding: chunked cannot be forwarded correctly by the gateway.

Describe the bug
Use version：spring-cloud-gateway-core：2.1.2.RELEASE

Upload the file as transfer encoding: chunked. When passing through the gateway, the gateway filters out the transfer encoding, but does not specify content length or transfer encoding, resulting in the downstream receiving no data

Sample
NettyRoutingFilter.class
//=========The transfer encoding request header is filtered out here

HttpHeaders filtered = filterRequest(getHeadersFilters(), exchange);
.......
		Flux<HttpClientResponse> responseFlux = this.httpClient
				.chunkedTransfer(chunkedTransfer).request(method).uri(url)
				.send((req, nettyOutbound) -> {
//=========The file uploaded by the client adopts transfer encoding: chunked

//=======Here, the transfer encoding request header is filtered out, but the content length is not specified, so the downstream //=======cannot obtain the content length / transfer encoding, so the file stream cannot be obtained. Personally, I suggest that if //=======the client is transfer encoding: chunked, the request header should also be specified here as transfer encoding: chunked
					req.headers(httpHeaders);
......
}

Gateway 2.x is not longer supported. Is this still an issue in 3.1.x? If so,
if you'd like us to spend some time investigating, please take the time to provide a complete, minimal, verifiable sample (something that we can unzip attached to this issue or git clone, build, and deploy) that reproduces the problem.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

problem is still exist

In RemoveHopByHopHeadersFilter you can actually set the list of headers removed using spring.cloud.gateway.filter.remove-hop-by-hop.headers.  So my first question is if they modify this property to not remove transfer-encoding if it would work?
Having a sample that reproduced the issue would be helpful in us assisting you.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


generating script run once without the plc name

The new generating file doesn't need any parameters and it can only be called once.
copy_new_gen was collecting the original not the new paths which resulted in an incorrect copy command coming from the check_matches function (only the per brick generator was affected by this).

Just back from hols!
@UrszulaNeuman did we decide that we were not going to merge this? Because we will require adopters to use a homing plc script per brick? (just checking my memory!)
If so lets close this PR and add a little bit of docs about how to split up your homing PLC scripts (I guess after you have converted them is best?)

Hi @gilesknap,
this change is still needed. The new generating script doesn't take any parameters and should be run only once per brick. This change of the converter tool only takes away the parameter (plc name) and makes sure the new script is run once per brick. Without this change the script will be run as many times as there is plcs in a brick - generating the same plcs over and over again. I hope this makes sense....
I am not convinced which way is better - splitting up first and converting next or converting first and splitting up next. I went through and wrote down the steps of splitting up first for one beamline. I was going to test converting first with some other beamline to check how it goes.
Still thinking on how to untangle generation of homing routines from PMAC_RULES.

OK thanks.
I guess that the current PMAC_RULES don't work with the new motorhome? But that when you fix them they will take advantage of this change?
We should make the PMAC_RULES work for both the old and new motorhome. Which requires a different name for the new sytle python files.

Hi Giles,
correct - PMAC_RULES need fixing to work with the new style python files and having a  different name for the new style python files sounds like a good plan.
This change is not related to the PMAC_RULES - sorry for the confusion. It is only related to the conversion process.
Thanks,
Urszula

I only just realised what you mean by PMAC_RULES 'taking advantage of this change'. Yes, PMAC_RULES will have to call the new style script exactly the same way as the converter - without any parameters only once per brick.


Clarify definition of CoherentRatioUnit or remove the class

Current definition: "A ratio unit whose numerator and denominator reduce to 1."
Maybe I'm just ignorant here, but this doesn't mean anything to me. We should clarify it for the general population.

DECISION: add skos:example (see above) that clarifies meaning of definition.

This is subsumed by #534 but I'm leaving it open so we make sure to consider the specific issues addressed here.

See discussion in #331.

On hold until major measurement changes are implemented

This should be moot, as ProductUnit and RationUnit are ambigous and likely going away.

Defer until units work has been decided.

Will be addressed in new Units of Measure (concept not needed).


Migrate to React function components

The use of classes had its merits, but there seems to be many instances where they're needlessly hard to work with when comparing with function components, such as state, hooks etc.

Done.


Updated classifiers in setup.cfg

SUMMARY
Signed-off-by: Abhijeet Kasurde<EMAIL_ADDRESS>ISSUE TYPE

Docs Pull Request

COMPONENT NAME
setup.cfg

superseded by #49


Measure the performance of obuilder on macOS

Measure the performance of obuilder on macos, where does time get spent during a build?
Provide an extended writeup of the performance model.
Based off the measurements, see where we could apply improvements to get more throughput from the macOS workers.

We have Metrics dashboard monitoring the throughput of the macOS x86_64 and ARM64 workers. Closing


⚠ Fortnite has degraded performance

In 0216178, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1604 ms

Resolved: Fortnite performance has improved in 1fb49b1.


about-view: clean up - Bitcoin Core logo

Before:

After:

NACK on changes of -version command-line argument output layout.

These two sections should be aligned

Updated Screenshots:

@hebasto
I ensured that the output is uniform for -version
thanks for the feedback! :)

I like the new style.
Though there is still a debate on whether the logo should be orange or black.
https://github.com/bitcoin-core/gui/issues/89
Concept ACK if we keep the color as is (we can always change it later to black if people want this).

@jonasschnelli - Since it is the about page - I thought using the web page logo might be useful. As it is now, the aboutMessage body is set up for further development - I was thinking of adding a menu bar that would replace the hyperlinks (It will look better).
A note on color usage and logo specification - keep in mind that most companies/entities create specifications for full color - gray scale and black/white - for different purposes such as web design, print, what ever - As far as I'm concerned - there really isn't a debate - because we should have a specification and media resource files that fit print/web/etc use cases.
Here is an example of a logo specification
https://ori.hhs.gov/logo-specification-guide

@jonasschnelli - Since it is the about page - I thought using the web page logo might be useful. As it is now the aboutMessage body is set up for further development - I was thinking of adding a menu bar that would replace the hyperlinks (It will look better).
A note on color usage - keep. in mind that most companies create specifications for full color - gray scale and black - for different purposes ass web design, print, what ever - As far as I'm concerned - there really isn't a debate - because we should have a specification and media resource files that fit print/web/etc use cases.

Concept ACK
The updated screenshots you posted above, the text should align with the logo such as below.

I would change that logo. This is Bitcoin, Core is secondary. Only forks want to reinforce the Core over Bitcoin.

Orange logo
Bitcoin bold
Core thin

I would change that logo. This is Bitcoin, Core is secondary. Only forks want to reinforce the Core over Bitcoin.

I disagree with this view. The GUI this repo is for is a product developed by Core that uses the Bitcoin protocol. Other implementations may one day exist that work on Bitcoin that aren't Core.

What do we want to communicate?
Do we want to have more force on the name Bitcoin or Core?
We cannot be always thinking about other people concerns, the software is what it is and other implementations can exist - and they do exist - without the need to reinforce this concept on the logo and be "apologetic".
I believe users of the Core implementation should feel they are running BITCOIN when running this "product" and not "Core".
When I see the black logo it makes me feel sad, it confuses me instead of reinforcing Bitcoin. Feels like you're putting Bitcoin "in the closet" and we should be ashamed to be Bitcoin instead of proud of it.

Do we want to have more force on the name Bitcoin or Core?

One or the other at this stage - currently both are used and its confusing.

I believe users of the Core implementation should feel they are running BITCOIN

You can still achieve this whilst using the black logo - do people think they are running something else when using products like electrum or bluewallet? I'd say no. This is the designers job to communicate this effectively and use the black and orange logos in their appropriate locations.
Do most people see Bitcoin Core = Bitcoin?

Do most people see Bitcoin Core = Bitcoin?
I believe people do and you're exactly trying to use the design to communicate otherwise.
I don't think people have to be communicated otherwise.

Why Bitcoin so thin and Core so bold? Isn't that trying to communicate Core over Bitcoin?
This project is not Electrum or BlueWallet, it's Bitcoin.

I've already explained my rationale many times above.
I'm still of the thought that:
Bitcoin Core is a group of developers who work on Bitcoin.
Bitcoin is a network that everyone is apart of.
Electrum and BlueWallet are part of the Bitcoin ecosystem as is the GUI developed by the Core developers.

I agree with not emphasizing "Core". Let's not institutionalize that emphasis further. Please keep them equal or put more weight on "Bitcoin".
One of my pet peeves is people writing "Core" instead of "Bitcoin Core" ("Core devs", "running Core", and so on).
See the Bitcoin Optech style guide:
Forbidden abbreviations:

Core (use Bitcoin Core)

100% agree with our Bitcoin Optech colleagues about this.

Don't get me wrong. I originally designed the black logo and I like it.
Though @gmaxwell made a valid comment here.
Changing the color might have greater impact than originally anticipated.

Concept ACK, sorry about not reviewing the PR itself, in general this looks very nice @RandyMcMillan and is a good improvement.

Thank you for the feed back!

I agree with the statement
The Bitcoin Core Developers
is a group and this is why I've maintained that "Developers" should be capitalized in the branding.
Further more...
From a copyright perspective - THE BITCOIN CORE DEVELOPERS should be in all caps - but this isn't mandated in any legalese that I have read...
But that is outside the scope of this PR. :)

@promag @jonatack
This approach is better. I am only using text styling to create "Bitcoin Core" and reusing the existing
bitcoin logo - this doesn't add any weight to the repo.

I've included "Core" to maintain existing branding continuity - but this can easily be removed if/when neccesary.

I didn't see the link - agree.
https://github.com/bitcoin-core/gui/issues/89#issuecomment-705384143

The logo should remain orange. This change would inadvertantly play into efforts to create a false equivalence between Bitcoin and various fraudulent clones.
We now know through leaked emails that even the renaming of Bitcoin Core to that name was dishonestly driven by malicious intent-- the parties that pushed for the name change did so because they were intending to attempt to take over Bitcoin from the community and move it under their control, and they wanted to "other" the community project and disassociate it with Bitcoin. Going along with it was an error. It's water under the bridge now but there is no reason to continue being victimized by past wrongs and compounding a past error.

@jarolrod - please add some context to the pic you posted.
OS - Screen resolution - dark theme? etc...
Thanks.

@jarolrod - please add some context to the pic you posted.
OS - Screen resolution - dark theme? etc...
Thanks.

OS: Arch Linux, DE: KDE Plasma 5.19.5, Res:3440x1440
The picture is pixelated because its cropped. Below is the full photo. I was trying to point out that everything looks off. The Bitcoin logo is in a weird position in relation to the logo text and the seperator bar. The logo text appears to have weird spacing. I'm not a designer, but this looks off to me.

@jarolrod
It is important to consider the way the text is rendered - keep in mind that we select a font family.
Due to the issues with licensing we don't embed a font in the app - so we select a font family - then your local system selects that actual font that is used. There will be variations.

Removed excessive space in the aboutMessage body.
These are the default dimensions when they first appear.

Updated default presentations:

🐙 This pull request conflicts with the target branch and needs rebase.
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

The code that is blocking this is NOT correct and should be considered a bug.
It omits the if logic and outputs bitcoind -h instead of the expected (-v) version string.

@practicalswift
The conflicting code is NOT correct.
This change should have never been ACKd
It removed the if logic necessary to select help (-h) versus version (-v) output.
https://github.com/bitcoin-core/gui/commit/6690adba08006739da0060eb4937126bdfa1181a#diff-214c41e31f440626f2b20c3858589d9270c843e254f38f2f97f5098ca83ef886R60

Posted PR in main repo:
https://github.com/bitcoin/bitcoin/pull/20597

When I started this - I didn't realize how badly the Gui needs to be abstracted away from the command line.
I believe this PR is a good step toward this ideal.

Whether I agree with the change or not, I don't see how it can be appropriate to slip in a name change.  Either the PR title should be changed, or a new PR created IMO.  It also doesn't make sense to me to have the name be Bitcoin Core on the loading screen, as well as Help->About Bitcoin Core yet then the about page say Bitcoin (without Core). It's just more inconsistency.
We also have other issues underway on branding discussing this issue that aren't cleared yet (#89, #100).  There's a lot of inconsistency.  Bitcoin.org uses orange; bitcoincore.org uses both; bitcoin repo uses black; bitcoin-core repo uses orange.  And now we're making additional naming changes before any decisions have been made.  Seems very messy.

@Rspigler - I agree it is a pretty serious issue...
There is a lot to do - and lot of decisions to be made.
This emphasizes the importance of a formal specification for branding/logo usage.
And yes...the scope of this PR has changed.
More importantly is - Working on the Gui has led me to believe there is a relatively easy work around to abstracting the Gui variables (PROJECT_NAME, etc..) from the build environment variables so Gui dev can progress and the plumbing can be refactored independently...
So once I know which direction to go concerning naming/branding/logo/etc...
How to proceed should be clearer...


Fix broken documentation

Found two issues with this document.
1.
Installing WALinuxAgent does not provide a latest copy from any repository that has these fields defined:
Provisioning.Enabled
Provisioning.UseCloudInit

Script block in section 12 should be changed from
# Configure waagent for cloud-init
sed -i 's/Provisioning.UseCloudInit=n/Provisioning.UseCloudInit=y/g' /etc/waagent.conf
sed -i 's/Provisioning.Enabled=y/Provisioning.Enabled=n/g' /etc/waagent.conf

to
# Configure waagent for cloud-init
if grep -q "Provisioning.UseCloudInit" /etc/waagent.conf; then
  sed -i 's/Provisioning.UseCloudInit=n/Provisioning.UseCloudInit=y/g' /etc/waagent.conf
else
  echo "Provisioning.UseCloudInit=y" >> /etc/waagent.conf
fi

if grep -q "Provisioning.Enabled" /etc/waagent.conf; then
  sed -i 's/Provisioning.Enabled=y/Provisioning.Enabled=n/g' /etc/waagent.conf
else
  echo "Provisioning.Enabled=n" >> /etc/waagent.conf
fi

2
The Azure datasource configuration provided in this document does not work and does not mount the azure datastore. To mount the datastore for cloud-init to consume I had to use the default configs from cloud-init official documentation.
Change from this:
echo "Allow only Azure datasource, disable fetching network setting via IMDS"
cat > /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg <<EOF
datasource_list: [ Azure ]
datasource:
Azure:
    apply_network_config: False
EOF

to this:
echo "Allow only Azure datasource, disable fetching network setting via IMDS"
cat > /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg <<EOF
datasource_list: [ Azure ]
datasource:
  Azure:
    set_hostname: true
    agent_command: __builtin__
    apply_network_config: true
    data_dir: /var/lib/waagent
    dhclient_lease_file: /var/lib/dhcp/dhclient.eth0.leases
    disk_aliases:
      ephemeral0: /dev/disk/cloud/azure_resource
  hostname_bounce:
    interface: eth0
    command: builtin
    policy: true
    hostname_command: hostname
EOF

Thanks

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

ID: 3f6b075e-e72b-aa46-4c91-3b722707347d
Version Independent ID: 6751d66c-9bdc-ab03-f989-1448740e1e58
Content: Create and upload a CentOS-based Linux VHD - Azure Virtual Machines
Content Source: articles/virtual-machines/linux/create-upload-centos.md
Service: virtual-machines-linux
GitHub Login: @danielsollondon
Microsoft Alias: danis

This is for the CentOS 7+ section

This is for the CentOS 7+ section

@besmirzanaj - Thanks again for bringing this to our attention. We have updated the Doc and it will be live once its merged.  We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

@besmirzanaj - Thanks again for bringing this to our attention. We have updated the Doc and it will be live once its merged.  We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Added a description of dev boards and some more content around ARM and C

Added a section to the "Why ARM" section which addresses arm
as a good platform more directly. Also some examples of projects
built with ARM processors
Added an explanation of what a dev board is to What Dev Board
Added two bullets to Disadvantages of not using C.
Fixed a few typos, and made a few clarifying changes to language.

Thanks for the PR! I'm pretty much :+1: about the content but I've sent a PR (cwoodall/copper#1) tweaking the wording a bit further.

@homunkulus r+
Thank you @cwoodall!

:pushpin: Commit 9b998bb has been approved by japaric

:hourglass: Testing commit 9b998bb with merge 9b998bb...

The test passed but homu didn't merge it for some reason ...
Merging manually.


pgadmin: 8.9 -> 8.10

Description of changes
Changelog
Diff
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 330912 run on x86_64-linux 1

4 packages built:

pgadmin4
pgadmin4-desktopmode
pgadmin4-desktopmode.dist
pgadmin4.dist

@ofborg test pgadmin4

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 330912 run on aarch64-darwin 1

4 packages built:

pgadmin4
pgadmin4-desktopmode
pgadmin4-desktopmode.dist
pgadmin4.dist

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 330912 run on x86_64-darwin 1

4 packages built:

pgadmin4
pgadmin4-desktopmode
pgadmin4-desktopmode.dist
pgadmin4.dist


Add a Notes App Project

Describe the project you want to add with tech stack

I have created a project which helps to add many important Notes at one place.
Expected behavior

We can add Different Notes Space Boxes in same website app and as many boxes we want.
We can delete the particular Notes Space boxes by clicking on given delete button.

Screenshots (optional)

@pranjay-poddar @Rakesh9100 I have already made a similar project. It also does the same things that you have mentioned.

@pranjay-poddar @Rakesh9100 I have already made a similar project. It also does the same things that you have mentioned.

I think there can be similar projects with different UI. Everyone is making their own with different styles and config.

@Rakesh9100 I don't think that is the issue here. Mine and your project is providing the same functionality.
So according to the standards no one can give the same project again right? Even it is having a different "UI"


Fix CSV download when Extended Profile switch is off

Overview
When the extended profile switch is turned off, we were filtering out
extended field headers from the embedded map download but ttill
showing the extended field values, causing a mismatch between the
header and rows.
Elsewhere in the embedded map, we treat the extended fields as custom
contributor fields if extended profile is turned off. We now handle both
extended field headers and values as custom contributor fields in the
embedded map facilities download.
Connects #1700
Demo
Embedded map download when the extended profile flag is on:
ExtendedProfileDownload.csv
Embedded map download when the extended profile flag is off:
NoExtendedProfileDownload.csv
Testing Instructions

Run vagrant ssh and ./scripts/server
As user<EMAIL_ADDRESS>upload and process a list with both extended fields and custom fields.
Navigate to http://localhost:8081/admin/ as<EMAIL_ADDRESS>and turn off the extended profile switch.
Navigate to http://localhost:6543/settings as<EMAIL_ADDRESS>and search for the list you just uploaded in the embedded map preview. Download the list as a csv. The list should display the extended map fields as contributor fields.
Navigate to http://localhost:8081/admin/ as<EMAIL_ADDRESS>and turn on the extended profile switch.
Navigate to http://localhost:6543/settings as<EMAIL_ADDRESS>and search for the list you just uploaded in the embedded map preview. Download the list as a csv. The list should display the extended map fields as extended fields.

Checklist

[x] fixup! commits have been squashed
[ ] CI passes after rebase
[x] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines

Thank you for reviewing!


[thci] Add configurable device connection type for OpenThread_WpanCtl

LGTM overall. However may I ask why so many style changes in this PR? @FiveDimensions

@librasungirl  I used "python3 -m black -l 119 -S " to format the file, is it correct?

For code style update, better to use a separate commit, thus the reviewer can focus on the major changes for the new features you want to introduce, which would help ease the review process.
Make sense?


cli failure on OSx: the instruction is not supported

> incognitee --direct unshield-funds $ME_PRIVATE $ALTER_EGO<PHONE_NUMBER>000
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
from ss58 is 5Ggf2LtT2W16YFmnTDiEdjdti5uvobNEwwhhGgsFpWQoG5tV
to  ss58 is 5HE8VuxGtt76rbaKrmZP3ACWJ1JN1qEH7SqGJ3yA1GnvWTBU
send trusted call unshield_funds from 5Ggf2LtT2W16YFmnTDiEdjdti5uvobNEwwhhGgsFpWQoG5tV to 5HE8VuxGtt76rbaKrmZP3ACWJ1JN1qEH7SqGJ3yA1GnvWTBU:<PHONE_NUMBER>000
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Unavailable, msg: "the instruction is not supported", cause: None }', /opt/rust/git/checkouts/incubator-teaclave-sgx-sdk-c63c8825343e87f0/3c903bd/sgx_ucrypto/src/util.rs:74:41
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

seems the randomness isn't available:
https://github.com/apache/incubator-teaclave-sgx-sdk/blob/1b1d03376056321441ef99716aa0888bd5ef19f7/sgx_ucrypto/src/util.rs#L74

Why, does the cli need randomness or sgx anyhow?


Vkontakte provider

I don't know, how to make pull request here.
Please, add this provider:
  'vkontakte': {
    auth_version: '2.0',
    authorize_url: 'https://oauth.vk.com/authorize',
    callback_url: ({ client_id }) => `vk${client_id}://authorize`,
    client_id: ({ client_id }) => client_id,
  }

Use the configurable API. #111 has been merged into master.

With 2.2.0 I think this issue is closable.


Fix cell positioning when using Size Classes

When a project is using Size Classes in interface builder, I've found that the collection view cells are not positioned correctly. Instead, they are shifted to the right and are therefore not completely visible on screen. I've found a workaround that fixes the cell positioning when the collection view will have one cell per row (similar to the UITableView layout). I'm not sure how this would affect other parts of the flow layout, however. Perhaps you could shed some light on this issue. Thanks!

Would you mind put up a screen for that issue, so we know what's happening?

A workaround is to set the UIImageView's frame equal to the UICollectionViewCell's bounds in the layoutSubviews() function of the UICollectionViewCell's.
override func layoutSubviews() {
        self.imageView.frame = self.bounds // required since image view doesn't automatically fill collection view cell
    }

Note that the same line of code would not work in awakeFromNib() since, at this point, the cell's bounds are not correct.

Also note that the UIImageView in the storyboard scene has autolayout constraints to fill the cell.

Can you check whether self.contentView bounds looks right?

Sure, this code in the UICollectionViewCell
override func awakeFromNib() {
        super.awakeFromNib()
        println("In awakeFromNib() \(self.contentView.bounds)")
    }

    override func layoutSubviews() {
        super.layoutSubviews()
        println("In layoutSubviews() \(self.contentView.bounds)")
        self.imageView.frame = self.bounds // required since image view doesn't automatically fill collection view cell
    }

outputs the following for each displayed cell:
In awakeFromNib() (0.0,0.0,50.0,50.0)
In layoutSubviews() (0.0,0.0,320.0,150.0)

if you don't use CSStickyHeaderFlowLayout, does it happens as well?

I just tried to use the default flow layout and the same problem occurs.

So since the default layout also have the problem, I suspect it's because of improper setup of autoResizeMasks or constraints. Our sample project also have size classes enabled, I placed an imageView and set constraints, seems looking fine to me.


Proposal for merging array or object options in tsconfig file

🔍 Search Terms
"extends", "merge", "compilerOptions", "paths", "outdir", "include", "exclude", "typeRoots", "tsconfig", "ability to merge tsconfig"
✅ Viability Checklist

[X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
[X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion
Subset of #56436
Today when you extend a config the options written in the final config override the options from the base config. Here is sample of what happens today:
// @fileName: /temp/test/base.tsconfig.json
{
    "compilerOptions": {
        "paths": {
            "@libs/*": ["libs/*"],
            "@project1/*": ["project1/*"]
        },
        "typeRoots": ["node_modules/@types"],
    }
}

// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "compilerOptions": {
        "paths": {
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["typings"]
    }
}

Here is what it would mean that project1 tsconfig was written as:
// @fileName: /temp/test/project1/computed.tsconfig.json
{
    "compilerOptions": {
        "paths": {
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["./typings"],
    }
}

Over years users have asked us for ability to create a final config that adds to base config instead of overriding. This is extremely useful for paths from compiler options.
This would allow to users to write a base config that contains common options that shouldn't have to be copied in all projects and yet allowing projects to specify there additional specific options.
For example in above sample, one would expect a way to write config such that final paths property is:
// @fileName: /temp/test/project1/computed.tsconfig.json
{
    "compilerOptions": {
        "paths": {
            "@libs/*": ["../libs/*"],
            "@project1/*": ["../project1/*"],
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["../node_modules/@types", "./typings"],
    }
}

Here are different proposals that are being considered:
Per Property Specific options
1. merge fields
Add merge as root level config property that specifies options that need to merged instead of completely overwritten in the final config.
From the above example writing the project1 config as:
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "compilerOptions": {
        "paths": {
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["typings"]
    },
    "merge": ["paths", "typeRoots"]
}

2. Inline merge options:
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "compilerOptions": {
        "merge": {
            // All the options that need to be merged
            "paths": {
               "@environment/*": ["env/*"]
            },
            "typeRoots": ["typings"]
        },
    },
}

3. merge:optionName in instead of just optionsName
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "compilerOptions": {
        "merge:paths": {
            "@environment/*": ["env/*"]
        },
        "merge:typeRoots": ["typings"]
    },
}

4. Root level merge:OptionsBagName to merge.
From the above example writing the project1 config as:
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "merge:compilerOptions": {
        "paths": {
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["typings"]
    },
}

5. merge-optionsName: true in the options
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "compilerOptions": {
        "merge:paths": true,
        "merge:typeRoots": true,
        "paths": {
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["typings"]
    },
}

6. Simple placeholder like ${base}: true or <merge>: true
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "compilerOptions": {
        "paths": {
            "${base}": true,
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["${base}", "typings"]
    },
}

7.  Detailed template substitution
This should allow you to control the order esp when extending multiple configs
From the above example writing the project1 config as:
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "compilerOptions": {
        "paths": {
            "${0.paths}": true,
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["typings", "${0}.typeRoots"]
    },
}

Global merge options
8. Add root level merge: true that merges all arrays and objects options:
From the above example writing the project1 config as:
// @fileName: /temp/test/project1/tsconfig.json
{
    "extends": "../base.tsconfig.json",
    "merge": true,
    "compilerOptions": {
        "paths": {
            "@environment/*": ["env/*"]
        },
        "typeRoots": ["typings"]
    },
}

Here is a chart of all options that are list or object type:

Option Category
Option
Type
Order Dependency
Eligible for Merge

CompilerOptions
paths
object
mayBe not

#44589, #20110 , For merging paths, we set pathsBasePath for resolving relative path, what happens to that when paths are merged

CompilerOptions
lib
list
no

#20110

CompilerOptions
rootDirs
list
yes?

CompilerOptions
typeRoots
list
yes

Now that we resolve types only from typeRoots, this seems to be important?

CompilerOptions
types
list
no?

global types to include

CompilerOptions
moduleSuffixes
list
yes

CompilerOptions
customConditions
list
no

CompilerOptions LS
plugins
list
mayBe

WatchOptions
excludeFiles
list
no

WatchOptions
excludeDirectories
list
no

TypeAcquisition
include
list
no

TypeAcquisition
exclude
list
no

Root
files
list
mayBe

#20110

Root
include
list
mayBe

#20110

Root
exclude
list
mayBe

#20110

Root
references
object
no

Transitive, vs listing only direct parent? #30608, #27098

📃 Motivating Example
A way to specify say project specific "paths" mapping without having to rewrite all the mappings from the base config.
💻 Use Cases

What do you want to use this for?
What shortcomings exist with current approaches?
What workarounds are you using in the meantime?

Can you provide an example of a project structure that this would actually be useful for?
I am having a difficult time thinking of any that isn't extremely convoluted by design (and I don't those are a problem for TypeScript to solve).
The beauty of tsconfig is that it is pretty much WYSIWYG. Every key will either have the value I specify or the value in the config I extend from with no ambiguity.

OP for this one is #44589 where there are many people complaining that it's not possible. Probably ask them 🙂

I think main motivation would be mono-repositories, where you would want to share typescript configuration across you repository's projects, which most of the time include paths.
Some real world example with Nx, a popular monorepo management solution  :
nx integrated monorepos typically have a root level tsconfig.base.json which is then extended by every app / library / package in the repository from which theses modules will find paths definitions among others:
(generated with nx's cli)
./tsconfig.base.json
// define libraries path so that they can be used in other local packages.
{
  // ...
  "compilerOptions": {
    // ...
    "baseUrl": ".",
    "paths": {
      "@myorg/some-lib": ["libs/some-lib/src/index.ts"],
      "@myorg/some-other-lib": ["libs/some-other-lib/src/index.ts"],
    }
  },
}

./apps/some-app/tsconfig.json
// project specific options
{
  "extends'": "../../tsconfig.base.json",
  // ...
  "compilerOptions": {
  // theses are local path aliases, only known to this module. needs full path as baseUrl is set in root tsconfig.base.json
    "paths": {
      "@somelocalalias/*": ["apps/some-app/src/somelocalfolder/*"],
    }
  },
}

Current behavior makes maintaining local imports a pain :/
Workarounds do exists but most of the time they involve custom scripts or adding a new dependency which is far from ideal for such uses cases as there is no opinionated way of achieving this.

@SainteCroquette Still not really understanding.  This is the exact problem that a monorepo solves--using packages.
In other words, why would you use inherited tsconfig paths instead of dependencies?
{
  "dependencies": {
    "@myorg/some-lib": "*",
    "@myorg/some-other-lib": "*"
  }
}

// my-app/some/file.ts

import { something } from "@myorg/some-lib";
import { somethingElse } from "@myorg/some-other-lib";

I can't speak for other tools but if you follow Nx (which doesnt rely on package name to resolve paths) integrated monorepository guidelines (which is really easy thanks to their cli & plugins) you end up with:

A root package.json listing all the external dependencies (dev included) used by all local repository packages (meaning you enforce sharing the same version of a dependency for all your consumer packages).
package.json for your packages without a single dependency listed (everything from root package.json is available to you anywhere, but you can still list somemore here if you want)
A root tsconfig.base.json which the Nx cli will update when addind / moving / removing local package from your repository.

Inside a package, build tools such as webpack or vite can then use a plugin provided by nx to feed them the path options from the local tsconfig. To be able to map correctly to other packages from your mono repository the local tsconfig needs to extends base tsconfig which holds the mapping configuration of the whole repository.
Defining a path option for the local tsconfig would then break the whole toolchain.
Would this means that nx's choice of relying on tsconfig as 'single source of truth' is against intended usage of tsconfig's path options?
Could you expand a bit on sharing tsconfig files via dependencies and how this would allows you to merge to path configurations together (or is this another way to achieve the same thing ?) ?

Could you expand a bit on sharing tsconfig files via dependencies and how this would allows you to merge to path configurations together (or is this another way to achieve the same thing ?) ?

@SainteCroquette  Package-based monorepos (ie npm workspaces) also work with Nx. The Nx integrated plugin "magic" is completely opt-in.  In other words, the need for merging tsconfig paths in such a setup is a direct consequence of the way Nx internals work. As such, it seems more reasonable to me that Nx (in this case) should provide a solution (eg via another plugin).
The question is, where does TypeScript draw the line about what it supports out of the box?  To me, it feels right that it works with the standard npm/node resolution.  Anything beyond that, I think, it likely to lead to endless scope-creep.

Just to mention that Webpack uses special '...' syntax to include defaults.

@jxdp one issue with TypeScript choosing to rely on npm workspaces/dependencies as the primary (or only) supported setup for mono-repos is that it unnecessarily couples TypeScript to node/npm for mono-repos. There are other runtimes for TypeScript, such as Deno and Bun. Personally, I prefer node, but it seems to me that a self-contained TypeScript solution for mono-repos has some advantages.
Now you could take your point more generically, that mono-repos are outside the scope of TypeScript. I.e. the burden of making TypeScript useful in mono-repos is entirely on npm, Nx, or whoever else wants to take it on. One problem with that is TypeScript is already part of the way there. Just using extends and paths allows you to easily create buildable code in a mono-repo. So at best, there is going to be a split burden because TypeScript mono-repos, whether or not they are using a third-party tool like npm or Nx, are sometimes going to use or these properties but then are also limited by them, and thus we will likely continue to see interest in issues like #44589.
As for the question on use cases, I think the Nx integrated mono-repo approach that @SainteCroquette mentioned is a reasonably common one. And I disagree with

the need for merging tsconfig paths in such a setup is a direct consequence of the way Nx internals work

At least in my use case, I use Nx just to orchestrate tasks. My code is able to build and run entirely without Nx. We could easily swap Nx out for a different task orchestration framework and still build and run all the same TypeScript code with all the same tsconfigs. So it would be nice to not have to copy-and-paste paths between those tsconfigs.
In fact, Nx effectively does not intrude on the actual mechanics of sharing code in your project by allowing you to either use npm workspaces (package-based) or TypeScript paths (integrated). In other words, they seem to be treating it as if npm and TypeScript provide two different, valid ways for sharing code in a mono-repo, and they just try to support both.
Also, to this objection:

The beauty of tsconfig is that it is pretty much WYSIWYG. Every key will either have the value I specify or the value in the config I extend from with no ambiguity.

I would argue that the extends property makes the tsconfig precisely not WYSIWYG. Especially, since you can have an indefinite chain of extends. It is not uncommon for me to have to go through a series of extended tsconfigs to find the property I am looking for, only to find it is not specified anywhere, at which point I have to look up the default value. Also, I don't think most of the proposed changes here would meaningfully alter the degree to which tsconfig is WYSIWYG. You would still see what is specified in your tsconfig and then have to look at the extended tsconfig for anything where your tsconfig indicates that it is using the extended tsconfig (i.e. by omitting the property or by explicitly merging it). So as long as a relatively intuitive approach is used for merging, not much changes. And I think the point of this issue is to evaluate how intuitive and useful each of the proposed approaches are.
TLDR

With the extends and paths properties of tsconfigs, it is not hard to create buildable code in a TypeScript mono-repo without any other tooling
This merging feature would make that experience even better, especially for paths, and regardless of what other tooling is used
tsconfigs are already not WYSIWYG

@saltman424 while templates are powerful & flexible and they do solve current problem, they often lacks readability. They might be too much vodoo for that kind of use case.
Personally, I favor comprehensiveness over conciseness. Moreover that would probably increase overall complexity of tsconfig files, going against its straightforward declarative syntax.
Proposals 1, 2 and 3 are explicit in that sense.
Not sure how you would handle the case where there is multiple files are extended tho #57567

@SainteCroquette that's fair. I mostly just don't want TypeScript to have to continually release refinements and new properties to address every edge case with merging. The main appeal to me with template variables is it gives me a lot of control so if there are edge cases that come up, I can resolve them myself. And the results are just more predictable. I find behind-the-scenes magic great when it works and really frustrating when it doesn't.
With that being said, the default merge logic would probably work for most of my current use cases, so I am not opposed to it. For multiple extends, I would assume the merge logic would just be applied in order of extends. I.e.
{
    "extends": [ "./a", "./b"],
    "compilerOptions": {
        "paths": {
            "@mystuff/*": ["./*"]
        },
    },
    "merge": [ "paths" ]
}

would use paths = merge(merge(a, b), { "@mystuff/*": ["./*"] })
And now that I think about it, another potential benefit of merge properties would be it encourages developers to split their extended tsconfigs into isolated configurations. I.e. with template variables, you could selectively pull out the parts of a tsconfig that you want, while with merge properties, you are merging an entire property from all of your extended tsconfigs, so you need to make sure you only have exactly what you need in the extended tsconfigs.
Side note: I would think template variables would be more comprehensive (cover more use cases more completely), while merge properties would be more concise (require less input from the developer)

@saltman424

Now you could take your point more generically, that mono-repos are outside the scope of TypeScript. I.e. the burden of making TypeScript useful in mono-repos is entirely on npm, Nx, or whoever else wants to take it on.

Yes, I would generally lean towards that as a guiding principle.

In fact, Nx effectively does not intrude on the actual mechanics of sharing code in your project by allowing you to either use npm workspaces (package-based) or TypeScript paths (integrated). In other words, they seem to be treating it as if npm and TypeScript provide two different, valid ways for sharing code in a mono-repo, and they just try to support both.

But npm workspaces and TypeScript paths are not fundamentally not equivalent.  npm workspaces are a dependency management solution; TypeScript is a DSL and a transpiler.
I am very skeptical about TypeScript adding complexity to handle problems that are complex, optional and can be resolved in user-land without any changes to TypeScript.
In the Nx case:

dependency resolution is complex
using tsconfig paths for dependency management is optional
it could be resolved fairly simply by letting Nx generate the tsconfig files (it already has Nx specific config files and understands your entire dependency tree, so this should be a fairly straightforward plugin–I wouldn't be surprised if it already exists)

@jxdp

But npm workspaces and TypeScript paths are not fundamentally not equivalent. npm workspaces are a dependency management solution; TypeScript is a DSL and a transpiler.

I totally agree. TypeScript paths are not meant to manage dependencies. They make that quite explicit in the documentation. However, it is a valid way to tell TypeScript that you are using another tool to resolve a given path, so you would like TypeScript to understand that path as well. When working with a bundler or executor, this means you can split your code into distinct folders without having them be separate packages, but instead all as input folders for bundling (i.e. every folder will be subject to the same compiler options; have the same dependencies available to them; and be built/transpiled together).
So I agree, these are not interchangeable solutions. They are two different approaches to mono-repos. But they are both viable approaches.
With that being said, this does make me realize that it is not Nx, but really bundlers, like esbuild, and executors, like tsx, that makes this approach to mono-repos viable. The problem, I would argue, is it definitely is not the scope of bundlers or executors to create/manage tsconfigs. They simply consume the tsconfigs for bundling or executing. So I think TypeScript is the most natural place to add this functionality, as numerous bundlers and executors seem to already rely on tsconfigs for specifying this type of path resolution. However, I hear the argument that it was not really the original purpose of paths to become this sort of configuration option for third-party tooling. I just think whether it was intentional or not, this is where we are, so why not make it a little more user friendly. And regardless, paths is not the only property that could benefit from merging and mono-repos aren't even the only case where merging would be helpful.

I said pretty much WYSIWYG. Every property is either the value in your tsconfig, or the value in the config it extends from. Even in a "Russian doll" scenario, you still end up on a single property (or none)–you do not need to mentally merge all the layers in your head to understand what your actual config is.

I think this depends on the person. I find the hopping around much more burdensome than having to append two lists or merge two objects in my head, but others may experience the reverse.
I also see a fair amount of confusion from a lack of merge functionality. E.g. developers confused why including a folder excludes another folder (because include overwrites the extended include).
Also, with template variables, it is all explicit, so I don't think that adds a lot of cognitive complexity, at least for a reader. And we already have merge logic on compilerOptions, so I think even with magic merge properties, people seem to be at least somewhat capable of understanding how it works without too much mental burden.

is there any fix here ?

Imho typescript would be better off just supporting typescript.config.{js,ts}, then you can offload all this merge/extend/etc logic to the user doing it in their code. Numerous tools already support .config.{js,ts} files.

My suggestion is to change the current behavior of to extending compilerOptions by default instead of overriding them.
And I suggest a new propertry "override" that allows setting which properties will be overriden.
{
  "extends": "@acme/tsconfig",
  "compilerOptions": {
    // this will override all the compiler options from the base tsconfig
    "override": ["types"],
    "baseUrl": ".",
    "types": [
      "node",
      "@acme/module-type-aliases",
      "@acme/theme-classic",
      "acme-plugin-sass"
    ]
  },
  "exclude": ["node_modules"]
}

This is bizzare, in 2024, this feature isn't implemented.
I want to use it for jsx, baseUrl, types but i can't.
This should work like deepmerge

Is there any workaround for this to reference the extended config on the project paths?

To be honest, having a tsconfig.ts where we could freely compose all the strong type configuration file fields (even dynamically if we want) would be much better than these merge options


Offline characters are not always removed by crontab from the map.

I noticed that few characters are quite often left on the map shown as online even though crontab job is running. Today at some point we had only one person online and 6 shown on the map:

I deleted them manually as shown on the picture but also checked esi.error.client.log and there is a lot of stuff like this:
https://pastebin.com/raw/bM1wYBJm
https://pastebin.com/raw/f7qijGPX
almost always online endpoint but sometimes ship too.
I'm getting also tons of these:
https://pastebin.com/raw/RC1q2hAP

Yea, its pretty much the same for me. Same errors in the logs etc.

this happens to me as well.


Peer to Peer code review

Suggestions

[ ] Keyword modification to increase code redability

Great job @JuanLPalacios! 🎉
Your list looks great and the “special effects” you gave it are really original and appealing! ✨
🧐 Although,
There are a few issues I'd like to mention to you 🔍:

The first one being the maximum length of your list:

😲 There are a lot of items in that screenshot, as you can see, but it shows that after too many elements added, the list breaks.

The second issue is length-related too:

🙀 As you can see, the same thing happens horizontally, with a task name that is too long, the text will escape its container and continue on outside the screen.

A quick solution could be to add an overflow property to the container of the items and a max-width and max-height, that way the items will stay inside and stop pushing everything 😎.

Good luck implementing the changes!🍀 And, once again, loving your project! 😍


ERROR: Check failed: ShapeEquals(proto) shape mismatch (reshape not set)

Not sure if error, but when specifying the "Pretrained Model" filepath on a custom network, DIGITS (or caffe) throws this error. However, when just specifying the Custom Network itself, the job starts fine. Any ideas as to why that is?
Also, when attempting to specify a pretrained model, upon creating the task, the DIGITS print trace shows this error:
Attempting to upgrade input file specified using deprecated V1LayerParameter: <modelPath>

where modelPath is the path to the pretrained model.

Hopefully im not just derping and doing something stupid here

See https://github.com/NVIDIA/DIGITS/issues/140#issuecomment-110545214
Check and make sure that Caffe is actually throwing an error and not just mis-reporting a warning as an error. I fixed this in https://github.com/BVLC/caffe/pull/2583, but it hasn't been merged into NVcaffe quite yet.

I updated the file found at 140, and rebuilt caffe, reran digits, and did the same as before... Still throwing the same error:
ERROR: Check failed: ShapeEquals(proto) shape mismatch (reshape not set)

Here's a copy of everything the server printed after the create job button was hit:
2015-10-20 03:10:07 [20151020-031006-ca44] [WARNING] Removing layer loss1/top-5 because top_k=5 while there are are only 2 labels in this dataset
2015-10-20 03:10:07 [20151020-031006-ca44] [WARNING] Removing layer loss2/top-5 because top_k=5 while there are are only 2 labels in this dataset
2015-10-20 03:10:07 [20151020-031006-ca44] [WARNING] Removing layer loss3/top-5 because top_k=5 while there are are only 2 labels in this dataset
2015-10-20 03:10:07 [20151020-031006-ca44] [INFO ] Train Caffe Model task started.
2015-10-20 03:10:12 [20151020-031006-ca44] [ERROR] Train Caffe Model: Check failed: ShapeEquals(proto) shape mismatch (reshape not set)
2015-10-20 03:10:12 [20151020-031006-ca44] [ERROR] Train Caffe Model task failed with error code -6

Things I had to do to get the Princeton GoogLeNet model to run (you mentioned it at https://github.com/NVIDIA/DIGITS/issues/373#issuecomment-148918129):

Download the files
Upgrade the old prototxt file using Caffe's upgrade tool
Remove the data_param.source and data_param.backend fields

Then I ran into the error you're reporting. For laughs, I tried it with the 0.14.0-alpha branch of NVcaffe and I got a much more helpful error message:

Looks like BVLC improved their error reporting in https://github.com/BVLC/caffe/pull/2927 - nice work!
Remaining steps:

Rename cls1_fc2 layer to cls1_fc2_new
Rename cls2_fc2 layer to cls2_fc2_new
Rename cls3_fc layer to cls3_fc_new

Now it's working!

This is why I caution people about fine-tuning with Caffe - it's non-trivial!

Hopefully the above steps will be a help to you and others who want to try their hand at fine-tuning.

Where would one find the caffe upgrade tools ?

Where would one find the caffe upgrade tools

Oh sorry, they're at $CAFFE_HOME/build/tools/upgrade_net_proto_text

is the Princeton Patch still valid?

I'm not sure what the patch does, but it sounds like it just helps with memory management to get you to the point of being able to train with a larger batch size. I wouldn't think that would be absolutely necessary.
If you do decide you need the patch, that's your own adventure. The commit their patch is based off of is almost a year old - https://github.com/BVLC/caffe/commit/e8dee35. The oldest release of NVcaffe that DIGITS still supports is based off of a BVLC/caffe commit from March.

Yeah according to Model Zoo Under the section "GoogLeNet GPU implementation from Princeton." they say this:
We implemented GoogLeNet using a single GPU. Our main contribution is an effective way to initialize the network and a trick to overcome the GPU memory constraint by accumulating gradients over two training iterations.

I guess the only reason i want it, is for faster training... Only have 4Gb of VRAM atm, so trying to make the most out of the system i've got ;)

Feel free to use their version of Caffe if that helps you, but I don't think you'll be able to use DIGITS to wrap it. You can try to merge this commit to get their version to work with DIGITS, but no promises on that.

I guess the only reason i want it, is for faster training...

I don't know how much their patch helps, but there are some really significant things that have been merged into Caffe since then that help with performance - namely multi-GPU and cuDNN v3.
I'm marking this issue as closed as this discussion is devolving from the original question.


Set initial page on form load

I am trying to set the initial page on the form load event (even tried the shown event) for the wizard using the NextPage method, but the wizard keeps coming up with the first page each and every time.
I tried to place the code in the constructor after the initializecomponents call, but I am getting a generic null object exception from within the wizard control library.
I don't want to use the suppress wizard page functionality, as I still want users to navigate to the skipped pages using the back button if needed.
Any suggestions?
Originally posted: 2014-03-22T22:00:53

The first page is set when the handle for the form is created. If you call NextPage after the handle is valid, it should work. If you need something else to make this work, suggest a model and I will work to get it into the code.
Originally posted: 2014-04-15T10:01:38


Edit release information for doosan_robot

kinetic/distribution.yaml
I manually edit the release information for doosan_robot(remove dsr_example_cpp package).
And I want to know how to delete the release information registered to Jenkins.
Thank you.

This PR shouldn't be necessary; we can continue the relevant discussion in #21572 .  I'll close this out.


-pw  does not seem working

Describe the bug
I saved the password using -pw  in extra putty arguments field. But sometimes it works but in most occasions, it does not seem working and still have to input the password when connecting
To Reproduce
Steps to reproduce the behavior:
Create connection entry for ssh.
Save password in "extra putty arguments" field -pw
Login.
It will still ask for password.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

From SuperPutty log...
PuttyStartInfo - SuperPuTTY is set to NOT allow the use of the -pw  argument, this can be overriden in Tools -> Options -> GUI
Do you allowed it in there?


Add Fast DDS Python bindings [main][14086]

This PR adds Fast DDS-Python to eprosima-dds-suite. It cannot be merged until Fast DDS v2.6.0 is released and set in the dds-suite.repos file.

Closed in favor of #22


Error when processing .fish file

Information
VIM version
NVIM v0.2.3-dev
Build type: RelWithDebInfo

Operating System: Linux - Ubuntu
:ALEInfo
:ALEInfo
 Current Filetype: fish
Available Linters: ['fish']
  Enabled Linters: ['fish']
 Linter Variables:

 Global Variables:

let g:ale_cache_executable_check_failures = 0
let g:ale_change_sign_column_color = 0
let g:ale_command_wrapper = ''
let g:ale_completion_delay = 100
let g:ale_completion_enabled = 0
let g:ale_completion_max_suggestions = 50
let g:ale_echo_cursor = 1
let g:ale_echo_msg_error_str = 'Error'
let g:ale_echo_msg_format = '%code: %%s'
let g:ale_echo_msg_info_str = 'Info'
let g:ale_echo_msg_warning_str = 'Warning'
let g:ale_enabled = 1
let g:ale_fix_on_save = 0
let g:ale_fixers = {}
let g:ale_history_enabled = 1
let g:ale_history_log_output = 1
let g:ale_keep_list_window_open = 0
let g:ale_lint_delay = 200
let g:ale_lint_on_enter = 1
let g:ale_lint_on_enter = 1
let g:ale_lint_on_filetype_changed = 1
let g:ale_lint_on_save = 1
let g:ale_lint_on_text_changed = 'always'
let g:ale_lint_on_insert_leave = 0
let g:ale_linter_aliases = {}
let g:ale_linters = {}
let g:ale_linters_explicit = 0
let g:ale_list_window_size = 10
let g:ale_loclist_msg_format = '%code: %%s'
let g:ale_max_buffer_history_size = 20
let g:ale_max_signs = -1
let g:ale_maximum_file_size = 0
let g:ale_open_list = 0
let g:ale_pattern_options = {}
let g:ale_pattern_options_enabled = 0
let g:ale_set_balloons = 0
let g:ale_set_highlights = 1
let g:ale_set_loclist = 1
let g:ale_set_quickfix = 0
let g:ale_set_signs = 1
let g:ale_sign_column_always = 0
let g:ale_sign_error = '>>'
let g:ale_sign_info = '--'
let g:ale_sign_offset = 1000000
let g:ale_sign_style_error = '>>'
let g:ale_sign_style_warning = '--'
let g:ale_sign_warning = '--'
let g:ale_statusline_format = ['%d error(s)', '%d warning(s)', 'OK']
let g:ale_type_map = {}
let g:ale_warn_about_trailing_blank_lines = 1
let g:ale_warn_about_trailing_whitespace = 1
  Command History:
(executable check - success) fish
(started) ['/bin/sh', '-c', 'fish -n ''/tmp/nvim1CKyeZ/2/aliases.fish''']
(finished - exit code 127) ['/bin/sh', '-c', 'fish -n ''/tmp/nvim1CKyeZ/3/aliases.fish''']

<<<OUTPUT STARTS>>>
/tmp/nvim1CKyeZ/3/aliases.fish (line 2): abbr -a mkdir='mkdir -p'
                                         ^
/tmp/nvim1CKyeZ/3/aliases.fish (line 3): abbr -a e='eval $EDITOR'
                                         ^
/tmp/nvim1CKyeZ/3/aliases.fish (line 6): abbr -a bi='bundle install'
                                         ^
/tmp/nvim1CKyeZ/3/aliases.fish (line 7): abbr -a be='bundle exec'
                                         ^
/tmp/nvim1CKyeZ/3/aliases.fish (line 19): abbr -a dc='docker-compose'
                                          ^
<<<OUTPUT ENDS>>>

What went wrong
The following error is printed.
"fish/.config/omf/aliases.fish" 19L, 352C
Error detected while processing function gitgutter#process_buffer[8]..gitgutter#diff#run_d
iff[2]..<SNR>135_NeoVimCallback[29]..<SNR>132_HandleExit[41]..ale_linters#fish#fish#Handle
:
line   14:
E684: list index out of range: 10
E116: Invalid arguments for function len
E116: Invalid arguments for function add

Reproducing the bug
Opening a .fish file with nvim

I'm sorry that I don't have more time right now to look further into the error. It seems to happen for all .fish files.
It could be a gitgutter issue. The lines above don't mean a lot for me. But maybe you can double check and see if they ring like a potential bug in ale.
Thank you for the plugin, btw, great work ;)

The error format in the test didn't match what fish -n returns in Linux, so I made the error handler handle both error formats.

this change seems to be conflicting with this documentation lines so they should be synchronized with the actual behavior or behavior should be fixed:
https://github.com/w0rp/ale/blob/b047271051d8ef448bf4bac120234205310b232a/doc/ale-fish.txt#L10-L11

also, false-positive results (usually to abbr and alias commands, like in the log provided in the first message) is related to this: https://github.com/fish-shell/fish-shell/issues/977


Move meshmodel components under "components" folder

Signed-off-by: leecalcote<EMAIL_ADDRESS>Notes for Reviewers
This PR organizes the meshmodel folder as one of two steps. A second step is needed to move the /meshmodel/relationships under /server/meshmodel/relationships, @sudo-nithishkarthik
Signed commits

[x] Yes, I signed my commits.

Codecov Report
Base: 16.70% // Head: 5.70% // Decreases project coverage by -10.99% :warning:

Coverage data is based on head (9f658a6) compared to base (166d873).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #6745       +/-   ##
==========================================
- Coverage   16.70%   5.70%   -11.00%
==========================================
  Files         116     116
  Lines       11274   11274
==========================================
- Hits         1883     643     -1240
- Misses       8916   10462     +1546
+ Partials      475     169      -306

Flag
Coverage Δ

gointegrationtests
5.70% <0.00%> (ø)

unittests
?

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

Impacted Files
Coverage Δ

server/cmd/main.go
0.00% <0.00%> (ø)

server/internal/store/thread_safe_store.go
0.00% <0.00%> (-100.00%)
:arrow_down:

mesheryctl/pkg/utils/sse-client.go
0.00% <0.00%> (-92.50%)
:arrow_down:

server/models/pattern/planner/graph.go
0.00% <0.00%> (-86.05%)
:arrow_down:

mesheryctl/internal/cli/root/perf/result.go
1.51% <0.00%> (-71.22%)
:arrow_down:

server/models/pattern/planner/queue.go
0.00% <0.00%> (-68.75%)
:arrow_down:

server/internal/store/store.go
0.00% <0.00%> (-67.50%)
:arrow_down:

mesheryctl/pkg/utils/helpers.go
0.00% <0.00%> (-58.65%)
:arrow_down:

mesheryctl/internal/cli/root/system/reset.go
0.00% <0.00%> (-52.46%)
:arrow_down:

mesheryctl/internal/cli/root/system/token.go
5.10% <0.00%> (-51.03%)
:arrow_down:

... and 26 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.


Feature, Shiny, Add File Builder, Predictors

Add File Builder for predictors in Shiny App.
Will need to get COMID from Lat-Long then merge with predictors file.

Actual commit was previous v<IP_ADDRESS>07 (put wrong issue number in NEWS).
https://github.com/leppott/KDHEtools/commit/cebde21a40c9c582dece38130a8561cf6d16e5c7


"Build and Deploy job" is not exist on Actions.

[Enter feedback here]
I cannot find a "Build and Deploy job" on the Actions page.
I think this button seems to be disappeared.

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

ID: 435e3dfc-59a1-4f1d-3d1e-060d51d2a25d
Version Independent ID: 43533133-b8a2-933a-512e-57b546b25a64
Content: 4-SWA: Create Static Web app  - Azure
Content Source: articles/javascript/how-to/with-web-app/static-web-app-with-swa-cli/create-static-web-app.md
Product: azure-nodejs
GitHub Login: @diberry
Microsoft Alias: diberry

If you have more comments, please feel free to reopen this issue.
#please-close


9 months later and issues still not solved... forgotten???

Dear all,
9 months ago I've been posting an issue on apktool:
https://github.com/wting/android-apktool/issues/780
It was closed with the hint that it's a duplicate of this one:
https://github.com/wting/android-apktool/issues/657
I've been trying out if it was solved by former releases and now by release 2.0.2 but it is not!!!
Can you please tell me when this issue will be fixed?
Thanks a lot and Kind regards,
Hardy

You are referencing a repository that was not made by me. Someone thought they were being helpful exporting a large open source project from Googlecode -> Github against the Project's wishes, which actually was not helpful.

This is actually bug #767 here (I think). Once again, referencing a repo I don't control nor support doesn't help anyone.

Last time I checked Apktool was open source and free. I don't get paid to work on anything. I work on this as a hobby for free with time I have. Bugs I fix are based on severity and ease of solution. Some bugs have been here for 2+ years before I fixed them. That sucks, but that is the fact of the matter when I am one person, who is a student, maintaining this tool.

There is no eta when your issue will be fixed, I think there is a pending pull request to fix the issue, but I remember some troubles I encountered testing it, so it has not been merged.
You are welcome to make a pull request or research the solution yourself.

Sorry, my hint was not meant to blame anyone! It was just meant as a reminder!
(sorry for my maybe insufficiant, missleading english - I'm not a native speaker)
You are doing a great job here and I know you're doing it in spare time.
So - thanks a lot for all your effort!!!


Proxy forward auth data

======
Currently the proxy extracts and forwards the client Principal to the broker. Client Principal is a modifiable string i.e can be changed or manufactured by the Proxy.
What we want to do instead is to send the clientAuthData to the broker - which is in most cases digitally signed. The broker will extract the client principal from the clientAuthData and reauthenticate the client.
In order to enforce this behavior we have introduced two new flags:-

authenticateOriginalAuthData on the broker
forwardClientAuthData on the Proxy

======
@msb-at-yahoo

@saandrews - have addressed your comments
@rdhabalia @merlimat - Please review this PR when you find time

retest this please

As with similar changes, try to put common logic in a single method

@merlimat - Have addressed your comments
I feel the last commit (https://github.com/apache/incubator-pulsar/pull/1169/commits/f986185eb7e79bcd3fac360d159057f39eeafcc6) addresses your comment but makes the logic more difficult to understand

@merlimat @rdhabalia - can I merge this or do you want to take one last look.

@rdhabalia - handled your comments - hope to get a +1 from you


Modifying models regression

regenerate diode model_regressions in a new model_reg file

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

regression run results for didoe model_reg

@RehabSayed-G Why did you close this PR?


Change font size and family in comments section

Problem
No CSS on fonts in comment section. Font size also small.
Changes proposed
Try this out.
font-family: 'Ubuntu', sans-serif;
  font-size: 1.1rem;

Alternative changes
Maybe use Poppins or some other font style.
Screenshot

Where are the HTML and CSS files for the same? @ShreyaPrasad1209 @satu0king

@CodeSarthak use inspection, name of the file will be shown.

is it still assigned to anyone? I want to fix this.

can i please work on this??


Can't use global autotype or copy paste when adding an account

I normally have "copy passwords" disabled. But global autotype doesn't seem to work for logging in to authorize cloud providers (even though I setup a window match). For Dropbox I was able to change my keepass settings and then paste the password on the screen, but for the "Authorize to OneDrive" screen I can't autotype and can't paste (using ctrl+v or mouse).

Which screen do you mean? The Authorization Dialog from KeeAnywhere when adding a new OneDrive account?
Do you want to have your OneDrive Password password entered from the KeePass instance you are currently using?

Yes to both!

Here is a workaround: Auto-type with KeePassXC.

Would it be possible to somehow remove the popup window block? The fact that we cannot copy our passwords and usernames (and stored totps) is because KeeAnywhere windows are blocking me from accessing KeePass main window (they are "on top")

@Swoy This is still a valid requirement. With v2.0 the internal browser will be removed (you can get a test version from #252).
But there is still a window on top and hopefully I can change it to be modal. Drawback: you can "loose" it in your background windows (as I already do it for e.g. Kee Vault Plugin).

@Kyrodan I did already download the test version, and so far it works well with Dropbox (restrictive creates the Folder KeeAnywhere inside App as expected), Google and OneDrive as far as I can tell.
I will keep you posted if I find something weird, I use KeePass daily. One question; who wins if two users save at the same time?


Missing icon import.png

@epwinchell seems like the icon got deleted in some refactoring

actually it's delete.png and import.png missing, maybe more?

@miq-bot assign @epwinchell


shorthand functions throwing error when passed an object

Since the shorthand methods are passing an object to the options argument on mock, both sides of the check on line 137 are truthy when you provide a response object causing the error to throw.
This is with v5.0.0

// Works
fetchMock.mock('http://foo.com', { foo: 'bar' })

// Error
fetchMock.get('http://foo.com', { foo: 'bar' })

// Also an Error
fetchMock.mock('http://foo.com', { foo: 'bar' }, { method: 'GET' })

Same thing here

Same error here.
As a workaround you can still use the one-argument signature:
fetchMock.mock({     matcher: 'http://foo.com',     response: { foo: 'bar' },     method: 'GET' })

As @ornj said, the error is thrown because the conditions if (options && /[A-Z]+/.test(response))on line 137 are truthy.
In fact, you want to check if response is a HTTP Method, so you check if response is a string. But /[A-Z]+/.test(obj), with obj a plain obj, return true - I don't know why, if someone knows please tell me why.
So others solutions to check if the user want to use a V4 signature would be:

check typeof response === "string", but in v5.0.0 response could be a string and an error will be thrown.
check if response is a HTTP method, but in the (rare) case where the user want to mock a call that return get, post, ... or other http methods, an error will be thrown.
check options && !options.methodbut the method will be required.

Instead, we should simply remove this legacy check ?

good spot. I'll add a failing test and release a fix as soon as I can. PRs to that effect welcome 🙊

/[A-Z]+/.test(obj), with obj a plain obj, return true - I don't know why, if someone knows please tell me why.

It's because {}.toString is something like [object Object]... which contains an upper case letter.
I should've used  /^[A-Z]+$/

Why the regex instead of just testing if the value is a string and in a list of HTTP methods?

simple way to throw a helpful error most of the time it's needed with hopefully few false positives.
It's not 100% foolproof, but I did say PRs welcome...

As time permits. Thank you for maintaining this project.

It's because {}.toString is something like [object Object]... which contains an upper case letter.
I should've used /^[A-Z]+$/

Thanks. :)


SPOSite Invalid Error Message

Details of the scenario you tried and the problem that is occurring
When running the configuration below, we get an error thrown:
No/invalid credentials were provided, or another error occurred logging on to SharePointOnline.
However, the error really comes from the fact that the Owner property is missing from the config block.
Verbose logs showing the problem
No/invalid credentials were provided, or another error occurred logging on to SharePointOnline.
Suggested solution to the issue
Improve error handling, and ensure this is catch at compilation time.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
# insert configuration here
```SPOSite ReadySite1
        {
            Title              = "DemoReady"
            Url                = "https://" + $ConfigurationData.NonNodeData.OrganizationName + ".sharepoint.com/sites/Ready1234171"
            CentralAdminUrl    = "https://" + $ConfigurationData.NonNodeData.OrganizationName + "-admin.sharepoint.com"
            Template           = "STS#0"
            Ensure             = "Present"
            GlobalAdminAccount = $GlobalAdmin
        }

#### The operating system the target node is running
N/A

#### Version of the DSC module that was used ('dev' if using current dev branch)
<IP_ADDRESS>3

Invalid Url property also seems to be throwing the exact same error message


PostgreSql json error

In Ktorm 3.3,
I have a postgresql database with a table that has a column named 'template' that has a datatype of json.
import org.ktorm.jackson.json
import org.ktorm.schema.Table

object TestTable: Table<TestTable>("test_table") {
    val id = varchar("id").primaryKey().bindTo { it.id }
    val template = json<Template>("template").bindTo { it.template }
}

interface TestTable: Entity<TestTable> {
    companion object: Entity.Factory<TestTable>()
    var id: String
    var template: Template?
}

I am able to successfully pull the model including the json field using the below query
fun findById(id: String): TestTable? {         return database.sequenceOf(TestTable)             .find { it.id eq id } }
However when I try to patch the table using the below query I get the following error
fun insertOrUpdateById(id: String, testTable: TestTable): Int {
        return database.insertOrUpdate(TestTable) {
            set(it.template, testTable.template)
            onConflict {
                set(it.template, testTable.template)
            }
        }
    }

Ktorm; bad SQL grammar []; nested exception is org.postgresql.util.PSQLException: ERROR: column \"template\" is of type json but expression is of type character varying\n  Hint: You will need to rewrite or cast the expression.\n  Position: 59

Do I need to do something specific in order to update the json value?

The code above is pseudo code, right? Some important information is missing. For example, what's your real query and what's the generated SQL looks like...
Would it be possible to give the real code that produced the problem? It would be helpful for debug.

Oh, I guess I know the root cause, check the code here https://github.com/kotlin-orm/ktorm/blob/master/ktorm-jackson/src/main/kotlin/org/ktorm/jackson/JsonSqlType.kt#L82
Here I use setString to pass the json string to the database, but it doesn't work for PostgreSQL's json type. As a workaround, you may need to update your table schema in database, change the column's type from json to varchar or text.

Will fix this in the next version

Hey Vincent, thanks for the quick responses. I had to stub a lot of the data in my example due to it being corporate code so if it's not entirely syntactically correct, thats why. Also I very much appreciate you telling me what the culprit could be otherwise I wouldn't have been able to come up with the following workaround.
I created a custom SqlType for postgres's Json type,
import org.postgresql.util.PGobject

    override fun doSetParameter(ps: PreparedStatement, index: Int, parameter: T) {
        val jsonObject = PGobject()
        jsonObject.apply {
            type = "json"
            value = objectMapper.writeValueAsString(parameter)
        }
        ps.setObject(index, jsonObject)
    }

This did the trick!

I update to ktorm 3.4, but still get the same error:
org.postgresql.util.PSQLException: ERROR: column "tag_data" is of type json but expression is of type character varying
  建议：You will need to rewrite or cast the expression.
  位置：72

By debugging JsonSqlType.kt, I found the issue is :
    override fun doSetParameter(ps: PreparedStatement, index: Int, parameter: T) {
        if (hasPostgresqlDriver && ps is PGStatement) {
            // set in postgresql way
        } else {
            // fallback
        }
    }

The ps you expect is PGStatement, but I'm using HikariCP and debugger tell me the ps is HikariProxyPreparedStatement

@hurui200320 Oh, thank you for your feedback. Let me think if there is a better solution.


cdn for oohtml?

Hi all.
Have you thought about having a cdn network (content delivery network) to host the libraries, templates for the oohtml community?
1. idea
<script<EMAIL_ADDRESS>integrity="sha384-w76AqPfDkMBDXo30jS1Sgez6pr3x5MlQ1ZAGC+nuZB+EYdgRZgiwxhTBTkF7CXvN" crossorigin="anonymous"></script>

1.1. why?

CDNs help reduce the bandwidth demands on origin servers, reducing bandwidth and web hosting costs for website owners. In general, going with a CDN provider will help businesses do away with the costs of setting up infrastructure, hosting and servers across the globe.
CDNs are used widely for delivering stylesheets and JavaScript files (static assets) of libraries like Bootstrap, jQuery etc.
Serving libraries' static assets over CDN lowers the request burden on an organization's own servers.

2. question/feedback
what do you all think of the idea?

Hi Code Hangen,
Thanks for your question. We definitely have. Our libraries are available
as npm packages and therefore automatically available via the unpkg cdn.
For example, oohtml is here:
@.***/oohtml/dist/main.js
Docs were down temporarily, but you can find these info in the docs.
Let me know if I answered your question.
Thanks.
On Thu, 29 Dec 2022, 21:46 Code Hangen, @.***> wrote:

Hi all.
Have you thought about having a cdn network (content delivery network) to
host the libraries, templates for the oohtml community?
—
Reply to this email directly, view it on GitHub
https://github.com/webqit/oohtml/issues/4, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADHNNQE5HGUSCW64JKZQ36LWPX2DHANCNFSM6AAAAAATMMFWHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi Code Hangen,
Thanks for your question. We definitely have. Our libraries are available
as npm packages and therefore automatically available via the unpkg cdn.
For example, oohtml is here:
@.***/oohtml/dist/main.js
Docs were down temporarily, but you can find these info in the docs.
Let me know if I answered your question.
Thanks.
On Thu, 29 Dec 2022, 21:46 Code Hangen, @.***> wrote:

Hi all.
Have you thought about having a cdn network (content delivery network) to
host the libraries, templates for the oohtml community?
—
Reply to this email directly, view it on GitHub
https://github.com/webqit/oohtml/issues/4, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADHNNQE5HGUSCW64JKZQ36LWPX2DHANCNFSM6AAAAAATMMFWHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


BoolToObjectConverter

Documentation added for .NET MAUI Community Toolkit proposals:

[Proposal] BoolToObjectConverter  https://github.com/CommunityToolkit/Maui/issues/50 includes:

Docs Build status updates of commit 45fb13f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/maui/TOC.yml
:white_check_mark:Succeeded
View

docs/maui/converters/bool-to-object-converter.md
:white_check_mark:Succeeded
View

docs/maui/converters/index.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

PRMerger Results

Issue
Description

Added File(s)
This PR contains added files. New files require human review.

Yaml File(s)
This PR includes changes to .yml file(s) owned by another author.

File Change Percent
This PR contains file(s) with more than 20% file change.

Index File
This PR contains a change to the index file.

Docs Build status updates of commit b778f0b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/maui/TOC.yml
:white_check_mark:Succeeded
View

docs/maui/converters/bool-to-object-converter.md
:white_check_mark:Succeeded
View

docs/maui/converters/index.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

PRMerger Results

Issue
Description

Added File(s)
This PR contains added files. New files require human review.

Yaml File(s)
This PR includes changes to .yml file(s) owned by another author.

File Change Percent
This PR contains file(s) with more than 20% file change.

Index File
This PR contains a change to the index file.