cmd/go: seems to be attempting to install a package that is already available

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go-1.8
What operating system and processor architecture are you using (go env)?
linux x86_64
What did you do?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/builddir/build/BUILD/openshift-git-45.423f434/_build:/builddir/build/BUILD/openshift-git-45.423f434/_thirdpartyhacks:/builddir/build/BUILDROOT/openshift-<IP_ADDRESS>-0.1.git.45.423f434.el7exarch.x86_64/usr/share/gocode:/usr/lib/golang:/usr/share/gocode:/usr/lib/golang"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build897335929=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
If possible, provide a recipe for reproducing the error.
Trying to build openshift, and doing so on a system without root access.  I get the following error:
go install -p 1 -ldflags '-X github.com/openshift/origin/pkg/version.majorFromGit=3 -X github.com/openshift/origin/pkg/version.minorFromGit=0+ -X github.com/openshift/origin/pkg/version.versionFromGit=v<IP_ADDRESS>-45-g423f434 -X github.com/openshift/origin/pkg/version.commitFromGit=423f434 -X k8s.io/kubernetes/pkg/version.gitCommit=44c91b1 -X k8s.io/kubernetes/pkg/version.gitVersion=v1.1.0-alpha.0-1605-g44c91b1' github.com/openshift/origin/cmd/openshift
go install vendor/golang_org/x/crypto/chacha20poly1305: open /usr/lib/golang/pkg/linux_amd64/vendor/golang_org/x/crypto/chacha20poly1305.a: permission denied
Its very odd because the chacha20poly1305 package is already installed on the system, and is within GOPATH, so go install should not, by my understanding, try to install that package
What did you expect to see?
I expected to see chacha20poly1305.a not get installed and the compilation of openshift complete
What did you see instead?
see above.

Can you show us the output of go list -f '{{.Stale}} {{.StaleReason}}' vendor/golang_org/x/crypto/chacha20poly1305 ?

I'm also receiving this error on 1.8, and this is the output from the go list command you posted:
[dev@dev1 httpserver]$ go install httpserver.go
go install vendor/golang_org/x/crypto/chacha20poly1305: open /usr/lib/golang/pkg/linux_amd64/vendor/golang_org/x/crypto/chacha20poly1305.a: permission denied
[dev@dev1 httpserver]$ go list -f '{{.Stale}} {{.StaleReason}}' vendor/golang_org/x/crypto/chacha20poly1305
true build ID mismatch

"build ID mismatch" is not what I expected to see.  That indicates that something really did change in the package, or one of its dependencies, or in the compiler itself, and the package needs to be reinstalled.
But why would this happen for that specific package for two different people?  I have no idea.  I have not been able to recreate the problem myself.  Can anyone recreate it consistently?

I got the error when trying go build httpserver.go on this folder of the following repo:
https://github.com/coreos/go-systemd/tree/master/examples/activation/httpserver
I uninstalled 1.8, went back to 1.7.5 so I could continue working, then reinstalled 1.8 later today, and now it isn't happening anymore. Not sure what happened, but it's fixed for me.

I've been testing different things to try and nail down what could be causing the issue. I haven't yet been able to reproduce the issue outside of the rpmbuild process, but I did find that the sha1 sums of everything in the /usr/lib/golang/pkg/linux_amd64/vendor/golang_org/x/crypto folder match on working and non-working instances.

I'll get you the go list -f '{{.Stale}} {{.StaleReason}}'  today.  Please note that I'm building this from an rpm, and the chachapoly library is provided by a dependent package, which may be introducing some problems here (that is to say, golang has decided that, through some set of imports that chachapoly is needed, and even though its provided in GOPATH, its provided by the golang-bin package, and the expectation of the rpm build environment is that golang will link to the library.

My observation is that since go1.8 (some )test files are part of the buildid calculation and were not previously. We in Fedora, we ship _test files in separate sub-package. With go1.8 and some libs vendored in stdlib we see the errors that nhornman reported, surprisingly not with all stdlib tests though.
To test it on Fedora install golang "dnf install golang" and then "go list -f '{{.Stale}} {{.StaleReason}}' vendor/golang_org/x/crypto/chacha20poly1305", you should see stale package. Afterwards install "dnf install golang-tests" and the stale should be gone. This assumes Fedora rawhide(go1.8). I have double checked that I haven't mistakenly included some non-test files in the tests sub-package, but I haven't noticed any(double/triple check welcomed).
I'm about to investigate further.

Oh... and temp workaround for rpmbuild(mock build) should be to build require golang-tests.

go list -f '{{.Stale}} {{.StaleReason}}'
true no install target
Not sure if that helps or not...

@jcajka , your workaround seems to fix the chacha issue, but it still seems like there is a bigger problem here (or perhaps just a discussion that needs to be had),  when using go install, I'm using go install, I'm unsure why files are attempting to be written to /usr rather than to the local rpm buildroot, as the local buildroot is whats specified first in the GOPATH.  It seems like the current go install behavior is anathema to how rpm (and most packaging systems) operate.  If the answer is that go build needs to be used rather than go install to prevent errant out of buildroot installation, I suppose thats fine, but it would be good to have a conclusion on that

@nhorman The command to run was broken onto two lines above.  You only ran the first line.  Here is the command again, on one line:
go list -f '{{.Stale}} {{.StaleReason}}' vendor/golang_org/x/crypto/chacha20poly1305

@jcajka The build ID computation is relatively simple and as far as I can tell does not include any test files.  See the function computeBuildID in cmd/go/pkg.go (on tip this file has moved to cmd/go/internal/load/pkg.go, but the function is essentially unchanged).  Please let us know what you discover.

@ianlancetaylor I have been checking it and I really didn't see a way it failing there(actually 2 weeks ago, but couldn't get back to this until now), then I just again double checked the regexp and saw that chacha's test vectors are in regular source file.
It has been actually fixed in x/crypto by commit 854ae91cdcbf914b499b1d7641d07859f3653481, but as it seems it hasn't been pulled to the vendored version included in stdlib...
So fix should be update/respin of vendored deps.

For the record, the commit referenced in the previous comment is https://golang.org/cl/35875.

@jcajka Thanks for sorting this out.  I will send a CL for tip.

Reopening because we should copy this into the 1.8 release branch.

@ianlancetaylor thanks for quick fix, awesome that it will get in to 1.8.1 too :)

It's not obvious to me that this fix belongs in the Go 1.8.1 branch. The RPM generator here is broken, right? They're excluding *_test* from the distribution instead of *_test.go. The former is simply incorrect. A file named foo_test_bar.go should not be silently discarded by RPM packaging.
I'm inclined not to cherry-pick this. Fixing the RPM generator will let them issue new RPMs for both Go 1.8 and Go 1.8.1 that works just fine.
Thoughts, @ianlancetaylor?

@rsc You're right.  I looked at the RPM spec file.  I'm fine with not backporting this.


MSM testing

Another function for MSM testing.

GPU/lurkrs new_compress/#0, 7980043 scalars
                        time:   [29.914 s 30.198 s 30.490 s]


Using the 'footnote' for needed Windows version is difficult

It is really difficult to use this documentation to determine what is/is not supported on a particular version of Windows 10, or to see what was added in the latest update. Using search in the document for a "5" to find things added in 1809 doesn't work so hot. The footnote is not a good way to handle this. Maybe just include the "Added in Windows 10, version XYZA" verbiage in the template for each setting instead of the footnote?

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

ID: 66b1ab2e-1964-5580-7c99-4bd4cd480075
Version Independent ID: f7b5da46-04cb-3501-65fa-870a3c6f09b8
Content: Policy CSP - Defender
Content Source: windows/client-management/mdm/policy-csp-defender.md
Product: w10
GitHub Login: @MariciaAlforque
Microsoft Alias: maricia

Some of the other parts of MDM documentation already include the version info in each setting section, like here: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-education
That works much better for searching for things like "1809" on the page. Or being able to look at a setting and know what version is required without scrolling to the bottom of a very long page.

@officedocsbot assign @e0i

@npherson
The issue has been noted and the document will be revised in the light of your feedback.
Thank you.

@npherson Thank you for reaching out and helping improve MS Docs. Just to double check, are you suggesting replacing each note reading "This policy is only enforced in Windows 10 for desktop" with your verbiage "Added in Windows 10, version XYZA"?

"Just to double check, are you suggesting replacing each note reading "This policy is only enforced in Windows 10 for desktop" with your verbiage "Added in Windows 10, version XYZA"?"

Thanks for double checking! No, not suggesting you replace that verbiage, just add the new. Take a look at the MDM link from above to see what I am suggesting. Each feature description area includes the "Added in Windows 10, version XYZA" verbiage.
And, I see that SOME of the entries on the Defender page actually do follow the same model - features released with 1607 or 1709 do have the "Added in Windows 10, version 1709" verbiage right at the start of their description.
This helps with 2 use cases: Someone came here looking for all the new things that came in the latest release can use search to find all the version 1903 features, and people looking at a particular feature will know the minimum version they need to be on to use it without having to scroll to the bottom to lookup the footnote.

@npherson Thank you for clearing that up.  I'll have the team look into having the relevant information added soonest.

@npherson The issue is under investigation.

@npherson
We have been informed that the CSP reference documentation are being updated for consistency and the use case you have brought up is being taken into consideration for improvements.
In the meantime, you may find the following document useful as an alternative,
What's new in mobile device enrollment and management
Thank you for providing feedback and following up.

@officedocsbot close


Support for load balancing

It doesn't seem possible to specify load balancing options. It would be really useful if multiple forward hosts could be specified along with the load balancing option, e.g. least_conn.

Duplicate of https://github.com/jc21/nginx-proxy-manager/issues/156


Package request: dkron

Dkron - Distributed, fault tolerant job scheduling system
Metadata

homepage URL: https://github.com/distribworks/dkron
source URL: https://github.com/distribworks/dkron
license: lgpl
platforms: unix, linux, darwin

up for this


Nested inclusion produces wrong SQL

We have the following layout:
Category.hasMany(Datapoint), Datapoint.belongsTo(User). Hierarchy is enabled on Category.
I want to query now a Category, with all their subcategories, and with all Datapoints assigned to this category and its subcategories and with all Users assigned to the Datapoints. The js looks like the following:
const datapointInclusion = {
  association: Category.DatapointsAssociation,
  required: false,
  where: {
    typeId: req.body.typeId
  },
  include: {
    association: models.Datapoint.Creator,
    attributes: models.User.WhitelistedFields,
    required: false
  },
};
const rootCategory = await Category.findByPk(req.body.categoryId, {
  include: [{
    model: models.Category,
    as: "descendents",
    hierarchy: true,
    include: datapointInclusion
  },
  {
    ...datapointInclusion,
    separate: true
  }
  ],
});

The SQL generated is the following:
SELECT
	"Category"."id",
	"Category"."name",
	"Category"."createdAt",
	"Category"."updatedAt",
	"Category"."hierarchyLevel",
	"Category"."parentId",
	"descendents"."id" AS "descendents.id",
	"descendents"."name" AS "descendents.name",
	"descendents"."createdAt" AS "descendents.createdAt",
	"descendents"."updatedAt" AS "descendents.updatedAt",
	"descendents"."hierarchyLevel" AS "descendents.hierarchyLevel",
	"descendents"."parentId" AS "descendents.parentId",
	"descendents->Categoryancestor"."CategoryId" AS "descendents.Categoryancestor.CategoryId",
	"descendents->Categoryancestor"."ancestorId" AS "descendents.Categoryancestor.ancestorId",
	"descendents->datapoints"."id" AS "descendents.datapoints.id",
	"descendents->datapoints"."quantity" AS "descendents.datapoints.quantity",
	"descendents->datapoints"."timestamp" AS "descendents.datapoints.timestamp",
	"descendents->datapoints"."meta" AS "descendents.datapoints.meta",
	"descendents->datapoints"."createdAt" AS "descendents.datapoints.createdAt",
	"descendents->datapoints"."updatedAt" AS "descendents.datapoints.updatedAt",
	"descendents->datapoints"."categoryId" AS "descendents.datapoints.categoryId",
	"descendents->datapoints"."creatorId" AS "descendents.datapoints.creatorId",
	"descendents->datapoints"."typeId" AS "descendents.datapoints.typeId",
	"descendents->datapoints"."shiftId" AS "descendents.datapoints.shiftId",
	"descendents->datapoints->creator"."id" AS "descendents.datapoints.creator.id",
	"descendents->datapoints->creator"."username" AS "descendents.datapoints.creator.username",
	"descendents->datapoints->creator"."firstname" AS "descendents.datapoints.creator.firstname",
	"descendents->datapoints->creator"."lastname" AS "descendents.datapoints.creator.lastname",
	"descendents->datapoints->creator"."preferredName" AS "descendents.datapoints.creator.preferredName",
	"descendents->datapoints->creator"."email" AS "descendents.datapoints.creator.email",
	"descendents->datapoints->creator"."language" AS "descendents.datapoints.creator.language",
	"descendents->datapoints->creator"."initial_page" AS "descendents.datapoints.creator.initial_page",
	"descendents->datapoints->creator"."style" AS "descendents.datapoints.creator.style",
	"descendents->datapoints->creator"."active" AS "descendents.datapoints.creator.active",
	"descendents->datapoints->creator"."siteId" AS "descendents.datapoints.creator.siteId",
	"descendents->datapoints->creator"."teamId" AS "descendents.datapoints.creator.teamId",
	"descendents->datapoints->creator"."pictureId" AS "descendents.datapoints.creator.pictureId",
	"descendents->datapoints->creator"."phone" AS "descendents.datapoints.creator.phone"
FROM
	"public"."Category" AS "Category"
	LEFT OUTER JOIN ("public"."Categoriesancestors" AS "descendents->Categoryancestor"
	INNER JOIN "public"."Category" AS "descendents" ON "descendents"."id" = "descendents->Categoryancestor"."CategoryId") ON "Category"."id" = "descendents->Categoryancestor"."ancestorId"
	LEFT OUTER JOIN "Datapoint" AS "descendents->datapoints" ON "descendents"."id" = "descendents->datapoints"."categoryId"
		AND "descendents->datapoints"."typeId" = 1
	LEFT OUTER JOIN "public"."User" AS "datapoints->creator" ON "datapoints"."creatorId" = "datapoints->creator"."id"
	AND "datapoints->creator"."active" = TRUE
WHERE
	"Category"."id" = 6;

The problem happens in the last LEFT OUTER JOIN so the join where the user information is appended to the datapoints. There are two problems:

The ON condition is "datapoints"."creatorId" = "datapoints->creator"."id". Unfortunately "datapoints" is not a valid table. The correct alias descendents->datapoints from the LEFT OUTER JOIN above was not used in this ON condition.
The alias datapoints->creator itself is wrong. It should be descendents->datapoints->creator, as the field selection above is suggesting.

Is there a hotfix available? Is this a problem in this repo or from sequelize?

Sorry for slow reply - I just saw your issue.
This looks like a problem with Sequelize rather than sequelize-hierarchy. To find out, just remove the hierarchy: true option and try running the query. If it still fails, it's Sequelize causing the problem.
Please let me know...

Did you have any luck discovering if this is a problem with sequelize-hierarchy or Sequelize itself? If it turned out to be Sequelize, could you close this issue please?

Our code evolved around this problem, I don't have any oppertunities to test this, sorry.

No problem. Thanks for letting me know.


What the shortcut to jump to error line shown in debug console?

VS Code Version: 1.55.2
OS Version: win10

Hi, I'm debugging an AutoHotkey script, when there's an error like on the image below, if i press the shortcut F8 it does not jump to the line:

Isn't the F8 key to jump to the error line?

Only goes to the line if i ctrl+click the message. There's any other shortcut for this action?

No unfortunetly there is no shortcut for this. If you want to use the keyboard you have to move the focus on the debug console, find the link and press enter or space.
We currently do not plan to change this, thus closing this as designed


I think the Java Home Path is wrong

I think the Java Home Path is wrong. The correct one is JAVA_HOME: C:\Program Files\Android\Android Studio\jre\bin

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

ID: 3b1a8b54-1913-1721-4a8d-2fd3ce3d300d
Version Independent ID: e39706ca-3548-03e8-672f-9e7d5bff92ae
Content: React Native for Android development on Windows
Content Source: hub/dev-environment/javascript/react-native-for-android.md
Product: dev-environment
Technology: windows-javascript
GitHub Login: @drewbatgit
Microsoft Alias: drewbat

Thank you @suleymancetiner81! Corrected! https://github.com/MicrosoftDocs/windows-uwp/commit/989a8a2dcfa1d61b304c313da1cc206400a90f08


[WIP] Add merge command to README

Adds the merge CLI tool that will allow combining yml files

this is being implemented in another PR


Interactive and clickable graphs

We demonstrate, document, and/or implement a method to create scatter plots (and potentially other types of graphs) with clickable callbacks that allow us to link them to widgets

Keeping track of this in the epic for now, closing the specific issue


Corrected grammatical error in README.md

Added missing hyphen for backwards-compatible

Since merging PRs is an expensive process due to multiple CI jobs needing to be run, we will not accept PRs that have a delta of just a small number of characters.
Please fix an entire file/directory instead of just one typo. Combine this with #34225 and fix the entirety of both files.


Mirroring

One perc of other casting services (like Chromecast) is that they offer you to fully mirror your screen , which as a result unlocks the potential to cast any and every app and site regardless if it's built in or not. Fcast works great with grayjay but if I wanted to stream local videos , or videos from some site or another app I'm now back to being forced to using Chromecast or some other closed source service. Of course while it would be wonderful if every single app that supports casting would built in fcast its unlikely to happen. So it would be so beautiful if Fcast could at least do full screen mirroring as opposed to being limited to only grayjay

screencasting would be incredible. It is definitely a strong point in favor of chromecast and airplay.


Spaces and newlines not supported in base64 encoded images

Description
When you use base64 encoded images like that
<Image style={styles.image} source={{ uri: `data:image/png;base64,${data}` }} />

if your base64 encoded data contains \r, \n, \r\n,  or any other space character, then your app assumes it should be a file:
Could not find image file:///<long path>.app/data:image/png%3Bbase64,<escaped data>.png

Seems like a regression in latest versions, because in 0.69 there were no such problem
React Native Version
0.71.6
Output of npx react-native info
info Fetching system and libraries information...
System:
    OS: macOS 13.2.1
    CPU: (8) arm64 Apple M1
    Memory: 109.64 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 19.6.0 - /opt/homebrew/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.4.0 - /opt/homebrew/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
    Android SDK: Not Found
  IDEs:
    Android Studio: 2022.1 AI-221.6008.13.2211.9514443
    Xcode: 14.2/14C18 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.18 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0
    react-native: 0.71.3 => 0.71.3
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps to reproduce

Take a valid base64 encoded image without newlines or spaces
Check that you can see it with <Image style={styles.image} source={{ uri }} />
Add newlines or spaces in base64 encoded data => error on both ios and android

Snack, code example, screenshot, or link to a repository

import { StyleSheet, Image, View } from 'react-native';

export default function App() {
  const uri = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAMAAABEpIrGAAAABGdBTUEAALGPC/xhBQAAACBjSFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAC4lBMVEUAAABh2fpk4v9h2vth2/xh2fth2vph2vxg2vtj2fp+/99i2vtt3fpi2vxg2vpk4vph2/tg2fpi2fyM2tNa3fxg2fte2fpX2vhj2/tj2Plg2/xe3flo1P9h2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2fph2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2/xh2vth2vth2vth2vth2vth2vtg2fth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2vth2/th2vv////ZYyFdAAAA9HRSTlMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJ5PwZ4MDHOubDVlSMll9iztcgukq4NBTery0HMtj0KpJEIv3GI2+GQEGq7BwnB6O9LYL69x5QrbJogOajsfX7tH4SfJ9/C1/Dp7tPAqR4CAqDZ0YNo5ARi5c/QAdymRxx0rRhfG5tuHUpmVNpc4jwSsTrgXVIp56JT+5mKqkb0rJ6PhVWNUMoXQ3pEdhZad81JE932jjSL43ULAqcP3okRpQFtusbEKHItJGcZ1gwhFD4zk7QaIq9eDmVXNk8DLKFMKjg7h5hzskijWWFYb4JrVk18JoACbLPUwAAAAAFiS0dE9UXSG9sAAAAJcEhZcwAAOw4AADsOAcy2oYMAAAAHdElNRQfkBgwKLzcjoaGYAAAC9UlEQVQ4y2NggABGJlk5OXkFZgYGZgV5OUUlFlYGVMCsrKKqpq6hycyspa2jq6dvwIwmz2xoZGxiamYub2FpZa1gY2vHxo6qwN7BkZmB2djJ2cXVDchw9/BENYLZy9sdKM4s7+Prxwxk+Ad4oSmwDwSZoBUUHKwSAmSEBtijKuDgDAu2CY+IjIqOiVWLiPOKT+BCUcBskmiblJySmuYNBD7pGZlJWdk5CBXMuRF5+QXphUXFRQolJSalZe7R6eUVdrKVUCXMJaFV1TW1gXWu9V4NjY1NXmbNLQGtbZEp7SUQFcwdnV0mzMyO3Z09vX1fvuj19ndOkGNmVpjYOQmsgJsnQYMX6PDJU6byTZv+5cv0aWwzpkwGCjDOTOAXgATiLGCoMJv69inMnvPly5zZCnN9TYECJvPCBAXAVkTozK8VYl6QobPQc1Fq6iLPxSlLZjJzLI3vtIC4gU14mbfK8hXmpSuTVykoKysszYxerW+xxnztOhGYN5jXt+tt2Ji3wHfT5sTEzVt8nabO2Zq8rZYZKayYFbaUa/RZzikzNy+bo6KnXRG2nRU1KHfs3MJssstpt1/b7j17FZij9+3HiM0DQIf31h9Urd8LiqxML2zRDfRQVFQ/iHb3RldgoifHzMY8We/QYb0jzMzMRw+iJRhRZsXDx46fqMjKbt1Z0a55zDueGT1RntyZfyq56DQzs3FokM4GvTNo8kAVxqambhxAYQ6xsz3nepHlmT0jVqw4b4JuZKUCzBbmOIcLiy6eQE/nl5bDkiXz5anbmZdd8Wy4WmQqfm3a9RvXmCcfXXlzov6t29AEc3nWney6qb2Gjn7ad460LLs78ezdEzca73lEQJMlc/iSSPOd9x/UPzz/yHFpy/XHT+4FS0hKgcyFWWG7PvTx7Z6nNcueJW5budRp5TrtSmkZJAVnmr2uPX9x7cJL2Vdur99obTm6S/vtu1etRusUoFbYHLvNbPCeM7ww2N9z6Yf4xR+ZL3+aef5z0SeQEQD3NgVcYcTe6gAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMC0wNi0xMlQxMDo0Nzo1NCswMDowMOLjIDsAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjAtMDYtMTJUMTA6NDc6NTQrMDA6MDCTvpiHAAAAIHRFWHRzb2Z0d2FyZQBodHRwczovL2ltYWdlbWFnaWNrLm9yZ7zPHZ0AAAAYdEVYdFRodW1iOjpEb2N1bWVudDo6UGFnZXMAMaf/uy8AAAAYdEVYdFRodW1iOjpJbWFnZTo6SGVpZ2h0ADUxMo+NU4EAAAAXdEVYdFRodW1iOjpJbWFnZTo6V2lkdGgANTEyHHwD3AAAABl0RVh0VGh1bWI6Ok1pbWV0eXBlAGltYWdlL3BuZz+yVk4AAAAXdEVYdFRodW1iOjpNVGltZQAxNTkxOTU4ODc07t6mCAAAABN0RVh0VGh1bWI6OlNpemUANDEzNzVCQlDBGGsAAABYdEVYdFRodW1iOjpVUkkAZmlsZTovLy4vdXBsb2Fkcy81Ni9OdnZWb1E1LzI0MTUvcmVhY3Rfb3JpZ2luYWxfd29yZG1hcmtfbG9nb19pY29uXzE0NjM3NS5wbmcvCeAIAAAAAElFTkSuQmCC";
  const uri_with_newline = uri.slice(0, 100) + "\r\n" + uri.slice(100);
  return (
    <View style={styles.container}>
      <Image style={styles.image} source={{ uri }}/>
	  <Image style={styles.image} source={{ uri: uri_with_newline }}/>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
  image: {
	width: 32,
	height: 32,
  }
});

Had the same issue in "react-native": "^0.71.0". Tested with latest "react-native": "^0.71.6". Issue is still there.

My image data strings come from a backend and worked in all versions before. Current workaround is {uri: r.img.replace(/(\r\n|\n|\r)/gm, '')}

Yes, we do the same thing. The issue is not that big, but it's very hard to understand the problem judging by the error message alone

Thanks @mklb
You will also need to replace spaces so I recommend
img.replace(/(\r\n|\n|\r|\s)/gm, '')

I have react native 0.72.3 and still have the same issue With Image not reading Base64 decoded

Weirdly I encountered this issue only in iOS as android was rendering the image perfectly, thanks @joshua-revolutions though!

My image data strings come from a backend and worked in all versions before. Current workaround is {uri: r.img.replace(/(\r\n|\n|\r)/gm, '')}

you made my day


so like I got banned for saying the n word in a private command

yea I did /trust nigger as a joke cause I was screen sharing with a mate and didnt realize that It would be seen and aswell as that I didnt think anybody would care but turns out _the auto moderator doesnt like that _ ### but anyway can I get unbanned lol (also my username is emerald_lord)

That's definitely hilarious, don't get me wrong. Of course we would have an autobanner for that kind of language, considering what the word is, but still amusing it catches commands like that. I'll unban you, but know that type of language is moderated.


fixes to std.math such that all unit tests pass on LDC 64bit windows.

fixes to std.math such that all unit tests pass on LDC 64bit windows.

Any chance we can try with the floating point constants? lol.
If I am interpreting the 64 bit real issue correctly, the problem isn't one of processor support, but of calling conventions. Variables larger than 64 bits have to be stored in memory and can't be stored in registers, yet LDC stores them on the stack and pushes them into registers. I have no idea how to touch this.
Mind you, a week ago I didn't know about 64 bit calling conventions and a whole lot of other stuff... so who knows what I'll be able to do in the future.

Is there a version that is for both win64 and LDC?
That was something else that I thought about.. shouldn't all of the version = whatever lines be all in one place?

I didn't realize that they had private scope. I just checked the predefined versions. I think I assumed that some of them must not have been predefined and were therefore imported.

I am interesting in following the topic.  I too am working on 64-bit reals, specifically arm.
I think one common problem area for us in std.math is exp().  In the unit test you versioned out there is a test set for 80-bit real.  I started on a test set for 64-bit reals but have not filled in the cases for under and overflow.  I find a 1 bit difference in exp() results sometimes.
All other unittests work as expected except I get a funny answer from acosh() when optimization is enabled and subnormal behavior is different for some functions on iOS.
If you diff ios branch with release-0.15.0 branch, you can see where I made
changes.
https://github.com/smolt/phobos/blob/ios/std/math.d

A 1 bit difference is no biggy. Floating point math is not deterministic between different compilers or platforms. Any comparisons should be made with the std.math.approxEqual function instead of ==.
I'll take at your tests in the morning. Is there a standard somewhere that tells what tests should be made or are you just winging it?

No standard, just winging it with the 80-bit real exp() tests cases as starting point.  Still need to calc some cases that are commented out.
I agree that 1 bit diff is usually a don't care, but coming from a place that built ASIC DSP, I usually want to understand the reason.

Hi Kevin,
Perhaps you can split these changes into a few smaller ones? That way a few of your changes can be merged-in. Also, some of the changes should go upstream, I think.

The changes to sqrt and atan2 are clear improvements. For atan2, I wonder if it'd be better to use LLVM asm expressions (http://wiki.dlang.org/LDC_inline_assembly_expressions), for better codegen. I'm not sure, but I believe LLVM can reason better about such assembly code.

The unittest for sqrt(-1) looks like it should go upstream!

LDC+MSVC can now parse floating point constants: https://github.com/ldc-developers/ldc/commit/2fdd4fe502ad9b7c5d188cf4425857ecc300931d

Instead of disabling some of the 80-bit real tests, we should add 64-bit tests (should go upstream). @smolt : are you going to submit your 64-bit tests upstream?

@JohanEngelen yes, after I completed the rest of the test set.  If someone else gets to it first, that would be great as I have been involved in some other fun projects :-)

@KevinBrogan Thanks for the work! Like @JohanEngelen I think it is better to break this PR in parts.
@JohanEngelen Yes, using the LLVM assembly results in better code. E.g. DMD style assembly is not inlined.

I've come up with https://github.com/D-Programming-Language/phobos/pull/3285 to address the std.math.exp() issues.

@kinke - I only have iOS flavored ARM setup now and it has some unique properties.  I don't think I can provide any additional input at this time besides some comments and that the real-64 test cases for exp() look good.  I patched your dlang pull #3285 into my os-merge-2.067 branch, but I still have IPhoneOS differences.  Subnormal cases always result in zero and IEEE flags never get set for any cases.
On iOS, subnormals generally are not supported.  ARM FPU Flush-To-Zero mode is enabled by default (subnormal math results become zero) by iOS runtime.  When I explicitly disable Flush-To-Zero mode, libm math routines such as ldexp still flush subnormals .  std.math.exp() uses libm ldexp() making all subnormal test cases end up with result of 0.0.  Also, IEEE flags are not set by ldexp, nor by libm exp(), so none of the expected overflow/underflow cases ever pass.  IEEE flags are tricky.  Any math subroutine may clear them.  And I still have ldc-developers/ldc#888 to think about.

I cut the sqrt() fix and the unit test and committed it. This is really a bug which affects all platforms.
I also created an upstream pull request for the unit test: https://github.com/D-Programming-Language/phobos/pull/3293
Thanks for spotting this!

Thanks! - All my std.math unittests pass for iOS now.  The sqrt() test for negative args did wonders for the acosh() unittest in -O builds.
Out of curiosity, I had to study why acosh() worked in iOS debug builds.  In debug builds, the optimizer doesn't get a chance to lower llvm_sqrt() intrinsic llvm.sqrt.f64 so ARM vsqrt.f64 instruction is generated, correctly producing NaN for negative args.  With optimizer turned on, llvm.sqrt.f64 is lowered to LLVM undef and that seems to be treated like an uninitialized variable.  Optimized assembly code for llvm_sqrt() uses whatever value is already in a floating point register leading to funny (undefined) results.
I see David documented this behavior in druntime ldc/intrinsics.di back in 2012.

Yep, that fixes the std.math-release issue(s) on Win64 too.
@smolt Wrt. the subnormal tests: parsing subnormal literals as 0 if the target doesn't support them would probably be the best solution and fix these feqrel() asserts, right? Wrt. the IEEE flags: the LLVM exp.f64() intrinsic doesn't set the flags either (at least on Win64), so I was planning on simply skipping the flags tests in LDC altogether.

@kinke - To handle subnormal cases on iOS, I pass all expected results from table through this function before comparing to exp() result:
    real expect(real x)
    {
        version(IPhoneOS)
            return isSubnormal(x) ? 0.0 : x;
        else
            return x;
    }

Maybe a specific version to opt-in or opt-out of flag IEEE testing for exp()?  Is does work on some platforms.  I wish for a way to know when IEEE flags are valid for checking, but seems like all corner cases.

@redstar - There is another instance of llvm_sqrt in druntime core.math that may need the nan recheck, depending on its purpose.  Not sure if that module is supposed to be bare intrinsics.
https://github.com/ldc-developers/druntime/blob/ldc/src/core/math.d#L111
I noticed that checking for and returning nan before calling llvm_sqrt() prevents IEEE invalid flag from being set.  Nothing to do about that, just a note because IEEE float flags have so many corner cases (e.g. ctfe or lowering removes float operation).  So far only reliable way to get IEEE flags seems to be calling libm functions (core.stdc.math) or do inline assembly.

I am closing this PR because all Tests in Win64 are green now.


[bug]

Bug Report
Current behavior:

Expected behavior

Steps to reproduce:

Screenshots

Dogecoin Core version

Machine specs

OS:
CPU:
RAM:
Disk size:
Disk Type (HD/SDD):

Extra information

Compare the forks across the branch


numpy.sum is incompatible with any of scipy.sparse matrixes

When called, numpy.sum(scipy.sparse.*) where * is csc_matrix / csr_matrix / lil_matrix throws an error, where it complains about unexpected "dtype" argument in sum function.
Here is a full trace:
File ".../source.py", line xxx, in foo
    np.sum(bar, axis=1)
File ".../lib/python2.7/site-packages/numpy/core/fromnumeric.py", line 1711, in sum
    return sum(axis=axis, dtype=dtype, out=out)
TypeError: sum() got an unexpected keyword argument 'dtype'```

in case 'dtype' is removed, 'out' becomes unexpected keyword. In case both are removed, the function cannot carry out it's purpouse.

In SciPy 1.10.0 (current main), all three operations mentioned above work:
>>> row = np.array([0, 2, 2, 0, 1, 2])
>>> col = np.array([0, 0, 1, 2, 2, 2])
>>> data = np.array([1, 2, 3, 4, 5, 6])
>>> S = csc_matrix((data, (row, col)), shape=(3, 3)).toarray()
>>> np.sum(S)
21
>>> S = csr_matrix((data, (row, col)), shape=(3, 3)).toarray()
>>> np.sum(S)
21
>>> S = lil_matrix(S)
>>> np.sum(S)
21

I believe this issue can be closed. Please reopen otherwise!

Thanks @melissawm. The issue here is that this should work without .toarray(), so np.sum(a_sparse_matrix). That does seem to have been improved somewhere along the way, because the .sum method of sparse matrices now supports a dtype keyword:
>>> row = np.array([0, 2, 2, 0, 1, 2])
>>> col = np.array([0, 0, 1, 2, 2, 2])
>>> data = np.array([1, 2, 3, 4, 5, 6])
>>> S = csc_matrix((data, (row, col)), shape=(3, 3))
>>> np.sum(S)
21
>>> S = csr_matrix((data, (row, col)), shape=(3, 3))
>>> np.sum(S)
21
>>> S = lil_matrix(S)
>>> np.sum(S)
21

So this is indeed fixed.


When injecting content, error message position is wrong

Example with right position of error message:

Example using the gem and an injected paragraph:

The workaround at the moment is, in these cases, to not use the fieldset legend to include the header, but instead to render the header (and any content in between this and the radios) separately, and then set the legend to visually hidden.
Or, in this case in particular, to change the little paragraph to hint text. But in other scenarios, this might not work out well. Example:

Hey @zheileman, I think I've fixed this in #103. If you're using the #govuk_radio_buttons_fieldset/#govuk_check_boxes_fieldset varients this is slightly more complicated and might necessitate adding a new helper to the builder so users can place them exactly where they want them.
However, for the described problem above I believe my fix will suit your needs for the time being. Please let me know and I'll get a release out today.

Hi @peteryates, thank you very much. Yes this solves the mentioned issue. I've not gone too far with the gem, I've just started using it for a legacy project (built with form elements) that we intend to migrate to the new design system.
We don't need this fix released any time soon, so feel free to accommodate this change any way you see fit 👍


Adds support for source maps

Adds the ability to turn on source maps. Disabled by default in dev and prod. Fixes #179.

On second thought, it makes more sense to default to enabled in dev. Made that change.

Oh boy, I reviewed this horribly.

Great work, thanks! Merging shortly.

Published as v5.0.0. Thanks @blakevanlan!