Final layer (image config) always gets different SHA1, despite all layers being used from cache

It seems that the final layer always ends up having a different SHA1 even if nothing has changed and all layers were previously cached. That means makisu always pushes the last layer, despite no changes.
Example:
FROM alpine

RUN sleep 30 && echo first > first && echo "first layer"
RUN sleep 30 && echo second > second && echo "second layer"

  makisu-use docker run -i --rm --network host \
        -v /var/run/docker.sock:/docker.sock \
        -v $HOME/.config/gcloud:/root/.config/gcloud -e DOCKER_HOST=unix:///docker.sock \
        -v $(pwd):/makisu-context \
        -v /tmp/makisu-storage:/makisu-storage \
        makisu-gcr:latest build --modifyfs=true --load -registry-config=/makisu-context/registry.yaml -redis-cache-addr=<IP_ADDRESS>:6379 -t=gcr.io/my-project/christian-playground/makisu-test1 --push=gcr.io -f /makisu-context/test.Dockerfile ./makisu-context

here's the log output:
➜  makisu-use docker run -i --rm --network host \
        -v /var/run/docker.sock:/docker.sock \
        -v $HOME/.config/gcloud:/root/.config/gcloud -e DOCKER_HOST=unix:///docker.sock \
        -v $(pwd):/makisu-context \
        -v /tmp/makisu-storage:/makisu-storage \
        makisu-gcr:latest build --modifyfs=true --load -registry-config=/makisu-context/registry.yaml -redis-cache-addr=<IP_ADDRESS>:6379 -t=gcr.io/my-project/christian-playground/makisu-test1 --push=gcr.io -f /makisu-context/test.Dockerfile ./makisu-context
{"level":"info","ts":1545243470.2675872,"msg":"Starting Makisu build (version=v0.1.6-8-g2312b39)"}
{"level":"info","ts":1545243470.270377,"msg":"Using build context: /makisu-context"}
{"level":"info","ts":1545243470.2755976,"msg":"Using redis at <IP_ADDRESS>:6379 for cacheID storage"}
{"level":"info","ts":1545243470.783478,"msg":"Found mapping in cacheID KVStore: d54b73c => c7acfc2853d1dc7ab082765d57373e8c4585b893d3f590a32c3ca850871daa1b,3dbe2ffb5491fe01193af9e6872d42507866b8e722303d7a75eb9ed5234c05af"}
{"level":"info","ts":1545243470.7867148,"msg":"* Skipped pulling existing layer my-project/christian-playground/makisu-test1:sha256:3dbe2ffb5491fe01193af9e6872d42507866b8e722303d7a75eb9ed5234c05af"}
{"level":"info","ts":1545243471.1164923,"msg":"Found mapping in cacheID KVStore: 62e3baef => f649ccb7cf136191972cf1571af0fd7ab9d5c525d3d8fecc4086a3dfbdc8e763,15407b25fb3010ceaea41ee2e7b54f85545d07c829284a52b30626fbdced3675"}
{"level":"info","ts":1545243471.1198263,"msg":"* Skipped pulling existing layer my-project/christian-playground/makisu-test1:sha256:15407b25fb3010ceaea41ee2e7b54f85545d07c829284a52b30626fbdced3675"}
{"level":"info","ts":1545243471.1198847,"msg":"* Stage 1/1 : (alias=0,latestfetched=-1)"}
{"level":"info","ts":1545243471.12015,"msg":"* Step 1/3 (commit,modifyfs) : FROM alpine  (76c4d71f)"}
{"level":"info","ts":1545243471.120436,"msg":"* Started pulling image index.docker.io/library/alpine:latest"}
{"level":"info","ts":1545243473.6239452,"msg":"* Skipped pulling existing layer library/alpine:sha256:196d12cf6ab19273823e700516e98eb1910b03b17840f9d5509f03858484d321"}
{"level":"info","ts":1545243473.6239972,"msg":"* Skipped pulling existing layer library/alpine:sha256:4fe2ade4980c2dda4fc95858ebb981489baec8c1e4bd282ab1c3560be8ff9bde"}
{"level":"info","ts":1545243473.6265252,"msg":"* Finished pulling image index.docker.io/library/alpine:latest in 2.5060273s"}
{"level":"info","ts":1545243473.6310925,"msg":"* Processing FROM layer 4fe2ade4980c2dda4fc95858ebb981489baec8c1e4bd282ab1c3560be8ff9bde"}
{"level":"info","ts":1545243473.7080991,"msg":"* Untarred 469 files to / in 77ms"}
{"level":"info","ts":1545243473.7085698,"msg":"* Merged 469 headers from tar to memfs"}
{"level":"info","ts":1545243473.7086647,"msg":"* Execute FROM alpine  (76c4d71f) took 2.5884505s"}
{"level":"info","ts":1545243473.7118616,"msg":"* Committed gzipped layer sha256:4fe2ade4980c2dda4fc95858ebb981489baec8c1e4bd282ab1c3560be8ff9bde (2206931 bytes)"}
{"level":"info","ts":1545243473.7119517,"msg":"* Pushing with cache ID 76c4d71f"}
{"level":"info","ts":1545243473.7134151,"msg":"* Step 2/3 (commit,modifyfs) : RUN sleep 30 && echo first > first && echo \"first layer\"  (d54b73c)"}
{"level":"info","ts":1545243473.7161434,"msg":"* Applying cache layer 3dbe2ffb5491fe01193af9e6872d42507866b8e722303d7a75eb9ed5234c05af (unpack=true)"}
{"level":"info","ts":1545243473.7165127,"msg":"* Untarred 3 files to / in 0s"}
{"level":"info","ts":1545243473.7165604,"msg":"* Merged 3 headers from tar to memfs"}
{"level":"info","ts":1545243473.7166305,"msg":"* Skipping execution; cache was applied *"}
{"level":"info","ts":1545243473.7169766,"msg":"* Step 3/3 (commit,modifyfs) : RUN sleep 30 && echo second > second && echo \"second layer\"  (62e3baef)"}
{"level":"info","ts":1545243473.7190568,"msg":"* Applying cache layer 15407b25fb3010ceaea41ee2e7b54f85545d07c829284a52b30626fbdced3675 (unpack=true)"}
{"level":"info","ts":1545243473.7195861,"msg":"* Untarred 1 files to / in 0s"}
{"level":"info","ts":1545243473.7196596,"msg":"* Merged 1 headers from tar to memfs"}
{"level":"info","ts":1545243473.7196949,"msg":"* Skipping execution; cache was applied *"}
{"level":"info","ts":1545243473.7199235,"msg":"* Moving directories [] to /makisu-storage/sandbox/sandbox400623144/stages/MA=="}
{"level":"info","ts":1545243476.1945984,"msg":"* Skipped pushing existing layer my-project/christian-playground/makisu-test1:sha256:4fe2ade4980c2dda4fc95858ebb981489baec8c1e4bd282ab1c3560be8ff9bde"}
{"level":"info","ts":1545243476.5169935,"msg":"Stored cacheID mapping to KVStore: 76c4d71f => df64d3292fd6194b7865d7326af5255db6d81e9df29f48adde61a918fbd8c332,4fe2ade4980c2dda4fc95858ebb981489baec8c1e4bd282ab1c3560be8ff9bde"}
{"level":"info","ts":1545243476.5350976,"msg":"Computed total image size 2207244","total_image_size":2207244}
{"level":"info","ts":1545243476.5354578,"msg":"Successfully built image my-project/christian-playground/makisu-test1:latest"}
{"level":"info","ts":1545243476.536066,"msg":"* Started pushing image gcr.io/my-project/christian-playground/makisu-test1:latest"}
{"level":"info","ts":1545243478.9334683,"msg":"* Image gcr.io/my-project/christian-playground/makisu-test1:latest already exists, overwriting"}
{"level":"info","ts":1545243481.136437,"msg":"* Skipped pushing existing layer my-project/christian-playground/makisu-test1:sha256:3dbe2ffb5491fe01193af9e6872d42507866b8e722303d7a75eb9ed5234c05af"}
{"level":"info","ts":1545243481.1929977,"msg":"* Skipped pushing existing layer my-project/christian-playground/makisu-test1:sha256:4fe2ade4980c2dda4fc95858ebb981489baec8c1e4bd282ab1c3560be8ff9bde"}
{"level":"info","ts":1545243481.4203205,"msg":"* Skipped pushing existing layer my-project/christian-playground/makisu-test1:sha256:15407b25fb3010ceaea41ee2e7b54f85545d07c829284a52b30626fbdced3675"}
{"level":"info","ts":1545243485.0824435,"msg":"* Started pushing layer sha256:5d36b483aa47765548782ab14a482ede21da32dd8472b52c2bddb95310ce4eea"}
{"level":"info","ts":1545243491.0503204,"msg":"* Finished pushing layer sha256:5d36b483aa47765548782ab14a482ede21da32dd8472b52c2bddb95310ce4eea"}
{"level":"info","ts":1545243494.5341387,"msg":"* Finished pushing image gcr.io/my-project/christian-playground/makisu-test1:latest in 17.9975221s"}
{"level":"info","ts":1545243494.5342157,"msg":"Successfully pushed gcr.io/my-project/christian-playground/makisu-test1:latest to gcr.io"}
{"level":"info","ts":1545243494.5342376,"msg":"Loading image my-project/christian-playground/makisu-test1:latest"}
{"level":"info","ts":1545243494.5438924,"msg":"Image tarrer dir: /makisu-storage/sandbox/sandbox400623144/my-project/christian-playground/makisu-test1/latest"}
{"level":"info","ts":1545243494.7470047,"msg":"Successfully loaded image gcr.io/my-project/christian-playground/makisu-test1:latest"}
{"level":"info","ts":1545243494.7471056,"msg":"Finished building my-project/christian-playground/makisu-test1:latest"}

@yiranwang52  I ran an image build with your fix #134 but it still always adds one more layer with a non deterministic sha1 on each build.
What is this "image config" layer for and why is it even necessary to have it in makisu?
Having this image config layer contain some non-deterministic value like the build timestamp makes the whole image build non deterministic, causes a lot of clutter in an image registry with a seemingly unnecessary layers and it also makes the build / push slower altogether.
When I build with other tools incl. docker, there's no additional "image config" layer being produced.
For example when I ran this command
docker pull gcr.io/solvvy-dev/my-project/raw-docker:latest && docker build . -f ./test.Dockerfile -t gcr.io/my-prject/christian-playground/raw-docker:latest --cache-from=gcr.io/my-project/christian-playground/raw-docker:latest && docker push gcr.io/solvvy-dev/my-project/raw-docker:latest

subsequent runs will not produce any new layer.

I'm not sure if docker really treats the SHA of that json as the image ID.
When you run my command above multiple times it always creates an image with the same Id. However when running docker inspectthe LastTagTime property in the json displayed always changes, despite the SHA staying the same:
 "Metadata": {
            "LastTagTime": "2018-12-26T20:30:06.1740107Z"
        }

Generating always new image IDs even if nothing has changed causes a lot of cascading problems.
For example in my use case we have some kubernetes apps which consist of multiple containers and whose source code is defined in a single repository. Now currently, when using docker build, if I change some code that is included in image A, but nothing in image B, the CI/CD pipeline will built both images but for image B the SHA will stay the same. That means subsequent steps in the pipeline effectively can be skipped, i.e. no deployment / rollout of image B has to happen.
In makisu it would be really hard to detect if something in image B actually has changed (because the SHA is different, even if there are no actual changes), which means I have to run the rest of the pipeline in call cases.
This is just one example of a practical problem.
Another problem is that by always pushing at least one layer, it will be really hard for makisu to ever match or exceed the speed of docker docker pull && docker build --cache-from && docker push when the cache is already warm and cache hit ratio is 100%.
You can already test today that using makisu on a simple image above, with no changes, takes 3-4x the time of using docker pull + build + push.
Last but not least I believe other alternative image build tools like kaniko, img all reuse the image config json file of the cached layers.
In conclusion I think makisu should also attempt to reuse the older json file and just update the last tag time like docker does.

···
In makisu it would be really hard to detect if something in image B actually has changed
···
okay that's a compelling reason.

running into this being an issue as well.  wondering if there's a timeline to get this fixed.

We will work on this in Q3.

I've bumped into this problem as well.... think this problem has been around for a while.


Multiple instances of Atom, multiple versions in Finder right-click menu

Description
Atom has multiple instances open. And there's two versions of atom in the Open File With... Finder context menu.
Steps to Reproduce
Open files in Atom. I use the Dock drawer, Finder context menu and atom command line tool to open things in Atom.
Expected behavior: One instance of Atom, multiple windows.
Actual behavior: 2+ instances of Atom, each with own Dock icon.
Versions
1.5.3 and 1.5.4 (apparently, according to right-click menu)

@OKNoah Thanks for opening this! I'd love to know where on disk those different versions of Atom are. Right-click on each icon, select Options > Show in Finder, and that should show where the app is.

@joshaber 2 of them open to the same Atom.app in my Applications folder. The third doesn't open anything in Finder.
Actually, clicking the third one brings up a crashes version of Atom with the option to reopen or "close window". Clicking close window seems to close it, but click the dock icon again does the same thing. Also, it's not visible in Expose.

I've got what I think is the same issue; sometimes (especially after calling "atom" from the command line), I get two different instances open in my dock. Only one has an indicator light, but they're both open, and I can interact with them both. If I already have an instance of atom opened then run e.g. "atom ." inside a folder in Terminal, it flashes up a second dock icon and then takes it away again. Sometimes, it seems it's not taking it away and I end up with two instances.

Atom has a system where there is only supposed to be one main process no matter how many windows are open. This means that there will only be one icon in the Dock in normal circumstances. When you launch an additional instance, the second instance passes off the launch instructions to the original instance and exits. This is why there is sometimes a second item in the Dock that then disappears. This is still normal.
Under certain circumstances, such as when Atom has updated itself but you have not yet restarted, when you launch an additional instance the second item in the Dock remains. This is because the two copies of Atom are different versions. If you exit the original copy of Atom and then launch again, everything should be unified under the new Atom instance. This is also expected behavior. (Even if sub-optimal, working around this is probably not worth the effort.)
@jfi or @OKNoah, are you encountering any behavior that does not fall in line with what I'm describing?

@lee-dohm If Atom is automatically updating in the background, then that's possible. I'm not updating it myself though.

I've got what I think is the same issue; sometimes (especially after calling "atom" from the command line)

I also run from the terminal a lot.

@lee-dohm This happened again about 2 days ago. But a friend said to me later "geez, atom hasn't updated in a while". Sure enough I looked and it doesn't look like there was an update around that time. Moreover, the version on both said 1.8.0. Could it be caused by the release of the 1.9.0 beta? Maybe the issue is I've signed up for the beta and forgotten about it?

Experienced this same issue just now with version 1.9.8 Had atom open and then opened a directory from the terminal (atom .) and it spawned a new process and a new dock icon. Showing in finder reveals the same application for both instances. I'll try restarting and see if that fixes.

I've had all of the same problems. Mac OS Sierra v. 10.12.1, Atom 1.12.2 (and earlier versions). I usually try to fix it by restarting Atom, but it doesn't always work. I guess Atom doesn't necessarily install any newly downloaded updates upon restart?
Anyway, yesterday I uninstalled Atom entirely, then reinstalled it, which fixed the problem for the rest of the day. This morning the problem came back. After reading the above comments I checked for updates and found that one has been downloaded (1.12.3), so maybe Atom automatically downloaded it this morning while I was using it. So I clicked "Restart and Install" and unchecked the "Automatically download updates" box, hoping this will help prevent the workflow interruptions. I'll try to remember to come back here and report whether the problem persists or not.

Weird. It happened again, but I'm not sure why. I checked the version number and it was 1.12.2. It should have been 1.12.3 as I had clicked "Restart and Install." So I quit Atom. I tried opening it from the dock newly and the version number was still 1.12.2. I quit again and tried opening a file that would prompt Atom (a .php file). Now it said 1.12.3. So apparently keeping Atom in your dock between updates can lead to this problem. Presumably than, you can avoid the issue by:

Turning off "Automatically download updates" so that you don't get multiple versions unexpectedly

Removing it from your dock before updating

Or at least that should eliminate some of the triggers to the problem.

I am getting the same problem. Would appreciate a solution since this makes it really hard to open a working version. Most of the versions tends to throw a lot of errors in my face when I open them...

Same issue for me as well.

Me as well. Anything opened from CLI or from the GitHub GUI opens in another instance that always locks up then crashes. Has anyone figured out a fix for this?

For people who are only affected by the multiple versions in Finder, there are solutions in https://github.com/atom/atom/issues/1720.  Please do not comment here.

I've also run into this issue on the Github desktop app on Mac.

+1. Has been here for ages.

+1, it's pretty annoying - especially when opening from command line and you end up having multiple instances of Atoms open

@50Wliu Those are workarounds at best.

@Aea your comment was deleted as a violation of the Atom Code of Conduct as it is off-topic, unproductive and argumentative. You may consider this an official warning.

I'm experiencing the same problem.

@JWhiteUX please read my comment.

+1 on opening from the command line. Very frustrating.

+1

I've tried this rm -rf ~/Library/Caches/com.github.atom.ShipIt and this /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -seed -domain local -domain system -domain user but still get Atom 1.19.0 and Atom 1.18.0, 1.19.0 being the bad guy.

Did you restart Finder after removing ~/Library/Caches/com.github.atom.ShipIt via killall Finder or via a reboot? I just tried and it removed the other versions of Atom on my iMac.

I had to delete the .app in the folder ~/Library/Application Support/com.github.atom.ShipIt/update to solve this problem.
I deletes all version and did a clean install but the issue just came from the folder mentioned above in my case.

Kinda surprised this is still an issue…

@JWhiteUX Given that:

This has zero impact other than cluttering a menu that not everyone uses
It only affects one platform of three
Until recently, the cause of it was unknown
Now that the cause is known, all people have to do to not be affected by it is not launch Atom from their update folders
It has a well-documented fix even if someone accidentally launches Atom from their update folder

There are lots of other higher-priority things for the maintainer team to be working on. Perhaps you would be willing to lend a hand and help fix the underlying problem?

@lee-dohm what is the known cause? I have been watching this but didn't see that. My apologies if I missed it.
Also, what does launch Atom from their update folders mean? I downloaded the app, moved it to /Applications and have been updating it via in-app commands ever since and I experience this problem regularly.
Can point me in the direction of the documentation you mentioned in #5.
Oh, and thanks for making an awesome, open-source app. Often times you get more grief than thanks for all your hard work. But, seriously, thank you. Atom makes my life and job much easier!

@blakeperdue As mentioned by @50Wliu above, there are solutions in #1720, which point to my comment on Discuss, the solution I got from the Apple StackExchange site long ago after a quick Google search for multiple entries in the Open With menu. (By "well documented", I meant that Atom is not the only Mac app that occasionally runs into this issue, so the solution to resetting the menu is fairly easy to find. I had found this solution before I even started working on Atom.)

Also, what does launch Atom from their update folders mean?

Apparently, from comments like this one macOS is adding entries to the Open With menu for Atom.app not in /Applications but in ~/Library/Application Support/com.github.atom.ShipIt/update. The only reason for that would be if someone launched Atom from that directory, perhaps by launching Atom from a Spotlight (or similar tool) search and picking one of multiple Atom.app entries.

Oh, and thanks for making an awesome, open-source app. Often times you get more grief than thanks for all your hard work. But, seriously, thank you. Atom makes my life and job much easier!

You're welcome :grinning: I'm glad that we can help :+1:

@lee-dohm thanks for the reply. I saw those solutions but as I commented on #1720:

I'd love for an easier solution than wiping all the Finder data around apps. It's taking a sledgehammer to the problem.

Next time this happens to me I'll see if I can figure out how I launched Atom (updates folder or /Applications folder). This is happening with other Mac apps so I would agree that closing this issue is the right move and that this solution, as much as I don't like it, is the best remedy at the moment:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user && killall Finder
As noted on the Atom Discuss site, this issue will crop up again and again as new updates are released, so using a script like @lee-dohm's or DaveEveritt's when the problem appears seems easy enough for now.

https://github.com/atom/atom/issues/1720
I have tried all the method on this thread.
It worked but after my update, it shows two options again.

Very annoying, hope somebody could help us out, it should be an open ticket, since there is no useful way to fix the problem.

You have to use a solution after each update as each update will leave your system with two .app files somewhere on your system that Finder is referencing. So, each time you have the problem, you run the solution. It's not a run-once thing. It's a run after update, unfortunately.

For the last 2 years I've had this annoying problem. Usually I use an alias to open Atom from the command line:
alias atom='open -a Atom'

And regularly it will open different version in a new window which will crash. Then I have to close the crashed version and run the command again, then it correctly opens the directory in the existing window. Generally speaking I rarely restart Atom so could have a version running for 3-4 weeks as I never restart my computer.

In your home directory, you can delete the original versions of Atom in com.github.atom.ShipIt/Atom.app (It seems the new version will always be in the Applications(on macs) folder, or in Downloads if you’ve installed it from there and left it there.)
I deleted everything in com.github.atom.ShipIt and the .app there as well. This solved my problem. I imagine I will have to do this every time I update Atom.

Happy 2nd birthday to this low-priority issue.

I just found this page and I don't think it has been fixed yet. However I think I know why this is happening and I think I can provide steps to reproduce it.
Setting in question is: File>Settings>Core>Restore Previous Windows On Start
First let's open a few files on atom, let's say we opened: banana.txt, apple.txt, and watermelon.txt. Then we close atome.

If option is set to NO: next time atom is launched, everything is blank. If someotherfile.txt is opened via atom, that file will be shown.
If option is set to YES: next time atom is launched, everything is the way it was when atom was closed. If someotherfile.txt is opened via atom, that file will be shown.
-If option is set to ALWAYS: next time atom is launched, everything is the way it was when atom was closed.  If someotherfile.txt is opened via atom, TWO instances of atom are launched, the first containing whatever atom had open when it was last closed, and the second contains someotherfile.txt.

What I normally expect to happen is to open whatever was opened last time atom was closed and add a new file/tab for the file that was opened (in this situation someotherfile.txt).
Hope I am right about this and that I did not get things messed up. I don't think this is how it's supposed to be right?

Any update on this?

It's been a problem for years
It's still happening today
Looks to be related to ShipIt?
Only a problem on Mac

Other references to this same problem:
https://github.com/atom/atom/issues/13299
https://github.com/atom/atom/issues/9774
https://github.com/atom/atom/issues/17387
https://discuss.atom.io/t/atom-editor-will-be-listed-multiple-times-in-macos-x-native-right-click-menu/6061/2
https://discuss.atom.io/t/mutliple-atom-entries-in-open-with/3401
Sometimes it can be resolved by running:
rm -rf ~/Library/Application\ Support/com.github.atom.ShipIt

https://github.com/atom/atom/issues/17387 was not an instance of this issue and was closed because support refused to properly diagnose it. In that case, the newer version was inaccessible and would crash instantly and leave the older version saying no updates were available.
However, if you attempt to launch the newer version through a context menu and it crashes, but then launch the same file in the older version through the context menu, there is a 75% chance that the new version will install itself correctly and replace the previous version at some later point after closing the application completely (ie. right clicking the dock and selecting quit).
@FutureSharks There is a good chance your alias workaround is doing more harm than good, as it appears you are also experiencing the crash, but circumventing any chance it will correct itself.

@AbandonedCart

There is a good chance your alias workaround is doing more harm than good

I have the same problem when launching via the Dock icon also.

@FutureSharks An alias will inherit the problems of it's target, so that is expected.

@AbandonedCart so if I can't use the command line and I can't use a Dock icon, then how I am supposed to open an application? I have to open the finder every time?

@FutureSharks I don't recall saying any of that, but you go ahead and do whatever works for you. It isn't really a "functional" workaround, but every issue may be slightly different. Best of luck.

I don't recall saying any of that

Sorry, I meant the "doing more harm than good" part.
Anyway, I think after this long with this issue I will switch to VS Code.

I've got what I think is the same issue; sometimes (especially after calling "atom" from the command line), I get two different instances open in my dock. Only one has an indicator light, but they're both open, and I can interact with them both. If I already have an instance of atom opened then run e.g. "atom ." inside a folder in Terminal, it flashes up a second dock icon and then takes it away again. Sometimes, it seems it's not taking it away and I end up with two instances.

For me it was a Mac Issue showing "recent" applications.
Fix this with System Preferences > Dock > uncheck "Show recent applications in Dock"


Add json1 support for sqlite driver

It seems there's no support for the json1 extension of sqlite.
select json_array(1, 2);

no such function: json_array

And when I checked it seems the sqlite3 was not compiled with json1 extension.
PRAGMA compile_options;

+----------------------------+
|      COMPILE OPTIONS       |
+----------------------------+
| COMPILER=gcc-11.1.0        |
| DEFAULT_WAL_SYNCHRONOUS=1  |
| ENABLE_FTS3                |
| ENABLE_FTS3_PARENTHESIS    |
| ENABLE_RTREE               |
| ENABLE_UPDATE_DELETE_LIMIT |
| OMIT_DEPRECATED            |
| SYSTEM_MALLOC              |
| THREADSAFE=1               |
+----------------------------+

I'm on: Emacs 28.0.50 on Manjaro Linux
So far I'm using sqlite inferior process to send queries instead of lsp.
If there's documentation on how to manually update the drivers, sorry. I think it only needs to be built with json1 tag.

This is already done. go-sqlite3 support json1 builtin.


[Feature Request][Go SDK] Replace Go Direct Runner with a Portable Runner

What would you like to happen?
This is the tracking issue for changes related to adding a Portable local runner in Go to simplify SDK and User side testing.
Goals:

Be able to test and configure FnAPI surface. The implementations of FnAPI surfaces are difficult to test without a portable runner, but how each production runner (like Dataflow, or Flink) uses the FnAPI  vary from instance to instance. While the gold standard is running on every runner, that requires arbitrarily complex set up for each.
Validates Beam feature correctness across different configurations or variants in feature support.
Replace the Go Direct runner.

Non-Goals:

Performance. The runner will by default be in a test operation mode and be biased towards executing single transforms at a time, within memory. This ensures coder correctness. That said, the configurability enables alternative operation modes that would improve the performance and reliability, such as fusion, bundle retries, multi-processing, or writing and reading large datasets to files between stages.
Distributed processing. It's intended to be a local runner, and so won't operate distinct workers on separate machines, though it may spawn multiple SDK containers as needed. The Beam Model doesn't require distributed processing. Again, there's no reason this couldn't be added later, but not at the expense of the primary correctness and testing aims.

Initial prototype, which requires operation in loopback mode is being iterated on in a separate repo, but is being cleaned up for contribution to Beam.
https://github.com/lostluck/experimental/tree/master/local
Issue Priority
Priority: 2 (default / most feature requests should be filed as P2)
Issue Components

[ ] Component: Python SDK
[ ] Component: Java SDK
[X] Component: Go SDK
[ ] Component: Typescript SDK
[ ] Component: IO connector
[ ] Component: Beam examples
[ ] Component: Beam playground
[ ] Component: Beam katas
[ ] Component: Website
[ ] Component: Spark Runner
[ ] Component: Flink Runner
[ ] Component: Samza Runner
[ ] Component: Twister2 Runner
[ ] Component: Hazelcast Jet Runner
[ ] Component: Google Cloud Dataflow Runner

At this point prism is the default runner for the Go SDK.
I need to validate that things that fail prism at least mention how to fallback to the direct runner at this time, and mention the new default in CHANGES.md, then we can mark this issue as closed.

2.50 release manager here.
This issue is currently tagged for the 2.50.0 release, which cuts in a week on August 9th.
Please complete work and get it into the main branch in that time, or move this issue to the 2.51 Milestone: https://github.com/apache/beam/milestone/15

(I'm aware I posted to myself.)


[WIP] Bump COSMOS_SDK_REV to v0.46; use buf

In conjunction with protoc-gen-prost, uses buf to generate protos.
This makes it possible to upgrade the Cosmos SDK revision.

Closing in favor of #393, which provides a more incremental path.


Helm chart

Hi, I just created this PR to support helm chart deployment.
Using Bitnami charts as dependencies for: kafka, postgresql, cassandra and redis

This is what I was waiting for, thanks!
Any chance for getting it merged?

@midokura-agustin thanks for the Chart, I have tried on HUAWEI CCE and it works.

@midokura-agustin really appreciate for your great contribution!


[cmake] TBBGet.cmake stopped working after package renaming

As packages were renamed, regexp in the line becomes incorrect:
string(REGEX REPLACE ".*(https.*oss_${tbb_lib_archive_suffix}).*" "\\1" tbb_bin_url "${tbb_release_info}")

Beause it looks for "oss_" which is absent now: https://api.github.com/repos/01org/tbb/releases/latest

Hi, Anton
Thanks for reporting!
Fix for the issue will be published as part of one of the future releases.
For now, as a workaround, you may just remove the oss_ prefix from the regular expression.


[Win/Android/Skia.Gtk/iOS?] Regression - Incorrect height of FlipView with Stretch inside AutoLayout

Current behavior

After PR #663, the height of a stretched FlipView as a child of an AutoLayout is no longer correctly calculated. Wasm seems to be the only platform that's not affected by the regression. iOS needs to be tested to confirm.
Here is the behavior per platform (repro sample app attached):
ReproALFV regression.zip
Windows - the height of the FlipView item is divided by the number of siblings
Three children:
https://github.com/unoplatform/uno.toolkit.ui/assets/10283398/57488fdc-c6d8-40e6-b37f-c19afb0f8846
Five children:

Android - similar to Windows, but initially seems to load page with the correct height
https://github.com/unoplatform/uno.toolkit.ui/assets/10283398/e9c165d2-2a4b-4013-8673-b1a93b0b8ba4
https://github.com/unoplatform/uno.toolkit.ui/assets/10283398/5b8c53d1-3c1b-4ea9-8211-7a9c5b11dd2d
Skia.Gtk - looks better than Win/Android but something goes wrong when the height of the FlipView item surpasses the height of the ViewPort (see behavior on third FlipView page below)
https://github.com/unoplatform/uno.toolkit.ui/assets/10283398/8b6c85c4-2386-4d84-bd9e-7834695e14c9
Wasm - seems unaffected by the regression, but I would still test after the fix
https://github.com/unoplatform/uno.toolkit.ui/assets/10283398/a6273857-ad0a-44de-a3c1-a524501d9567
Expected behavior

Behavior before PR #663
https://github.com/unoplatform/uno.toolkit.ui/assets/10283398/b41b4137-2fb7-43bd-b8b1-5d8650aba2c3
ReproALFV before PR.zip
How to reproduce it (as minimally and precisely as possible)

Sample apps attached above.

Apply Stretch to a FlipView that's a child of an AutoLayout.

Nuget Package:
Package Version(s):
"Uno.Toolkit.WinUI" Version="4.2.22"
"Uno.Toolkit.WinUI.Material" Version="4.2.22"
and all the stable versions where the PR was backported
These are the versions used to show the behavior before the PR (sample app attached under Expected behavior):
"Microsoft.Extensions.Logging.Console" Version="7.0.0"
"Microsoft.Windows.Compatibility" Version="7.0.4"
"Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.756"
"Microsoft.WindowsAppSDK" Version="1.3.230724000"
"SkiaSharp.Skottie" Version="2.88.5"
"SkiaSharp.Views.Uno.WinUI" Version="2.88.5"
"Uno.Core.Extensions.Logging.Singleton" Version="4.0.1"
"Uno.Extensions.Logging.OSLog" Version="1.6.0"
"Uno.Extensions.Logging.WebAssembly.Console" Version="1.6.0"
"Uno.Material.WinUI" Version="3.0.0-dev.264"
"Uno.Dsp.Tasks" Version="1.1.0"
"Uno.Toolkit.WinUI" Version="4.0.0-dev.35"
"Uno.Toolkit.WinUI.Material" Version="4.0.0-dev.35"
"Uno.Resizetizer" Version="1.1.3"
"Uno.UI.Adapter.Microsoft.Extensions.Logging" Version="5.0.0-dev.1380"
"Uno.UniversalImageLoader" Version="1.9.36"
"Uno.Wasm.Bootstrap" Version="7.0.29"
"Uno.Wasm.Bootstrap.DevServer" Version="7.0.29"
"Uno.Wasm.Bootstrap.Server" Version="7.0.29"
"Uno.WinUI" Version="5.0.0-dev.1380"
"Uno.WinUI.Lottie" Version="5.0.0-dev.1380"
"Uno.WinUI.RemoteControl" Version="5.0.0-dev.1380"
"Uno.WinUI.Skia.Gtk" Version="5.0.0-dev.1380"
"Uno.WinUI.WebAssembly" Version="5.0.0-dev.1380"
"Xamarin.Google.Android.Material" Version="<IP_ADDRESS>"
Affected platform(s):

[ ] WebAssembly
[x] Android
[ ] iOS ? - needs testing
[ ] macOS (AppKit)
[ ] Mac Catalyst
[x] Skia

[ ] WPF
[x] GTK (Linux)
[ ] Linux Framebuffer
[ ] Tizen

[x] Windows

IDE:

[x] Visual Studio 2022
[ ] Visual Studio 2019
[ ] Visual Studio Code
[ ] Visual Studio for Mac
[ ] Rider Windows
[ ] Rider macOS

Relevant plugins:
Anything else we need to know?

If we removed the utu:AutoLayout.PrimaryAlignment="Stretch" we got the exact same issue that with a StackPanel
<StackPanel Background="{ThemeResource SurfaceBrush}"
				Spacing="32"
				Padding="32">

	<FlipView x:Name="flipView"
			  utu:SelectorExtensions.PipsPager="{Binding ElementName=pipsPager}">
		<FlipView.Items>
			<FlipViewItem>
				<Rectangle Height="200"
						   Fill="Crimson" />
			</FlipViewItem>
			<FlipViewItem>
				<Rectangle Height="400"
						   Fill="Crimson" />
			</FlipViewItem>
			<FlipViewItem>
				<Rectangle Height="600"
					   Fill="Crimson" />
			</FlipViewItem>
		</FlipView.Items>
	</FlipView>

	<muxc:PipsPager x:Name="pipsPager"
					utu:AutoLayout.CounterAlignment="Center"
					MaxVisiblePips="3"
					Orientation="Horizontal"
					Style="{StaticResource PipsPagerStyle}" />

	<Button Content="Button 1" />
	<Button Content="Button 2" />
	<Button Content="Button 3" />
</StackPanel>

android_autolayout
https://github.com/unoplatform/uno.toolkit.ui/assets/16021239/79e76569-3bfe-4001-b1cf-7e81bb7c988b
Android_stackpanel
https://github.com/unoplatform/uno.toolkit.ui/assets/16021239/d7fa727a-3ea3-471e-8b2b-f7f9107d46ab
wasm_autolayout
https://github.com/unoplatform/uno.toolkit.ui/assets/16021239/3190f610-4ba8-47f8-a08a-b836df5dccad
wasm_stackpanel
https://github.com/unoplatform/uno.toolkit.ui/assets/16021239/33002118-7e8a-4821-84c5-4eaa5ed1771a
windows_autolayout
https://github.com/unoplatform/uno.toolkit.ui/assets/16021239/452cb62f-fbdf-49ad-9189-c03453679e97
https://github.com/unoplatform/uno.toolkit.ui/assets/16021239/fe26b22f-049e-47b8-ad82-51680ca4e564
windows_stackpanel

Grid with  give a similar result.

@Robert-Louis should this be fixed by https://github.com/unoplatform/uno.toolkit.ui/pull/857?

@kazo0 yes

@silviuo can we double check that the issue is indeed fixed because I'm still seeing a blank FlipView when running on Android after updating the packages

fixed by https://github.com/unoplatform/uno.toolkit.ui/pull/857


Changing src reloads/crashes the page

Description
To test this behaviour I've used the example code from modelviewer.dev along with models from Smithsonians open gallery (https://3d.si.edu/explore).
When changing the src property 3-4 times, the page reloads/crashes. I've downloaded models from modelviewer.dev to make sure it's not the models, but the page reloaded/crashed after 10-15 times of chaning the src.
Keep chaning the src until it reloads. With other models (larger perhaps?) it happens very quickly (3-4 times).
It doesn't happen on desktop, only on Android and iOS.
Edit:
Watching RAM on PC makes me realize that Memory is going up every time I change the src. Which probably leads to out of memory on mobile.
Live Demo
https://www.deltareality.com/webar/smithsonian-gallery/
Open this on mobile device or Chrome inspection toolbar for mobile
Version

model-viewer: v1.3.0

Browser Affected

[x ] Chrome
[ ] Edge
[ ] Firefox
[ ] IE
[ x] Safari

OS

[ x] Android
[ x] iOS
[ ] Linux
[ ] MacOS
[ ] Windows

@elalish any update on this? I am also facing the same issue where in the browser (chrome and Safari) crashes after changing the src 3 times

@elalish any update on this? I am also facing the same issue where in the browser (chrome and Safari) crashes after changing the src 3 times

I believe there is likely a memory leak; I was not able to find its source (or to get reliable feedback from dev tools) the last time I hunted for it. It's probably time to try again. If anyone loves hunting memory leaks in JS, help would be most appreciated 🙏.

I believe there is likely a memory leak; I was not able to find its source (or to get reliable feedback from dev tools) the last time I hunted for it. It's probably time to try again. If anyone loves hunting memory leaks in JS, help would be most appreciated 🙏.

I believe that this issue still isn't resolved as of 3.0.2.

@diegoteran Hello! Thank you for replying! I'm trying to create scenes that don't contain client models so I can create a test case. Shall I create a new ticket with a CodePen (or similar) URL when I'm done?

@designbyadrian Yes, please! Filing a separate Issue and filling all the fields would be the most helpful for us, since we already closed this ticket.


Change address in channel opening used derivation path m/1017'/0'/0'/1/0, which the on-chain recovery misses

Disclaimer: I am sorry for the following un-reproducable issue. But I am posting it to see if anyone has some inputs as to how this could have happened as it is bothering me.
I had a corrupt channel.db file and therefore had to recover my on-chain funds using the AEZEED mnemonic.
Prior to having the corrupt database I was using the autopilot, which had opened exactly one channel to some other node (nearly one month ago).
When I recovered my on-chain funds I realized that only a small fraction of my on-chain balance had been recovered. After numerous tries I realized the following:
Recovering my wallet using my mnemonic with the create command looks for funds on the derivation path m/84'/0'/0'/0/i and m/84'/0'/0'/1/i, which I think is the standard thing to do in lnd. However, the change address from the old channel opening appears to be on the exact derivation path m/1017'/0'/0'/1/0 and was therefore not caught when recreating the wallet. I searched through this derivation path manually because I found it as a comment in the source file:
https://github.com/lightningnetwork/lnd/blob/a2336005e650b33a708081cee18eff8739d0b245/keychain/derivation.go#L24
As far as I understand it this exact derivation path should have been used for a revocation key? But can it also be chosen for a change address when opening channels?
I have tried all kind of things also using regtest trying to reproduce this issue without success.
One more thing: I did have the same problem with a corrupt db a month ago where I successfully recovered the wallet using the SCB (from another previous channel) in channel.backup via create --multi_file. But even trying to reproduce this does not result in this issue...
Any ideas as to how this could have happened? I still have the corrupted channel.db and old channel.backup file and the mnemonic. Unfortunately I did delete the lnd directory with logs. But I can also directly provide information on the transaction id for the channel opening the weird change output and provide the mnemonic and show the different addresses with their derivation paths.
Your environment

version of lnd: v0.9.0 (or v0.9.1, I am not completely sure at this point)
which operating system (uname -a on *Nix): Linux (Raspberry Pi)
version of btcd, bitcoind, or other backend: bitcoind v<IP_ADDRESS>

Steps to reproduce
Unfortunately not possible, see description above.

May want to look at this: https://github.com/btcsuite/btcwallet/pull/682

Yep see the commit above. Note that this issue only applies to master or v0.9.1.

Also it isn't unusual that it's hard to repro this bug, given that the bug itself is caused by pseudo-random behavior (map iteration order).

Ah thanks for the info! Good to know that this behaviour is known. And I won't have to lose my sanity over not being able to reproduce this, as it seemed so strange to me :)


Create README.md

Needs documentation of how to set up and use code. This can be an ongoing task as new features are added.

@wluxie Please approve these changes and merge the branch.


docs: Made collect_reactions page more explicit.

collect_reactions never used "override" with virtual void completed(), this changes that. Whilst it's not needed, it's better to be explicit.
This also clears the random indentation on line 36 (prev. line 29).

[x] My pull request is made against the dev branch.
[x] I have ensured that the changed library can be built on your target system. I did not introduce any platform-specific code.
[x] I have ensured that all methods and functions are fully documented using doxygen style comments.
[x] I tested my commits, by adding a test case to the unit tests if needed
[x] I have ensured that I did not break any existing API calls.
[x] My code follows the coding style guide (if you are not sure, match the code style of existing files including indent style etc).
[x] I have not built my pull request using AI, a static analysis tool or similar without any human oversight. Where I have generated this pull request using a tool, I have justified why this is needed.
[x] I agree to the terms of the DCO (Developer Certificate of Origin)

PR is marked as draft until #779 is complete so I can deal with the conflicts.

It appears "Files Changes" now shows changes from #779.

needs to be merged to dev not master, I have updated this

needs to be merged to dev not master, I have updated this

Thought I had, sorry about that!!


Ignite crashes on iOS versions less than 9.2 due to react-native-config

[x] Issue does not already exist
Identify exactly what aspect your issue is about

[x] ignite base application
[ ] ignite the cli
[x] ignite generated code

I'm encountering an issue after exporting Ignite-based apps to .ipa files for ad-hoc distribution on iOS devices in which the "Powered by React Native" screen is displayed for a second and then the app closes. The closest thing I have been able to find is this StackOverflow thread. Extracting the .ipa file shows that there is a minified JS bundle in it, but I haven't yet figured out how to build an .ipa with a non-minified bundle to compare.
I followed the "Building your app for production" section on the Running on Device page of the React Native docs (except for the section on ATS as I could not find that key in the project using grep) and then exported the app through Xcode's Product > Archive menu and selected Ad-hoc distribution to generate the .ipa.
This affects the base project generated by ignite new project. I tried using just react-native init project and that works fine as an .ipa.
ignite doctor output:
Computer
  Platform: darwin

Ignite
  Version: 1.10.1
  Path: /usr/local/bin/ignite

Node
  Version: v6.7.0
  Path: /usr/local/bin/node

NPM
  Version: 3.10.7
  Path: /usr/local/bin/npm

Yeoman
  Version: 1.8.5

React Native CLI
  Version: 1.0.0

App
  React Native Version: 0.35.0

Hiya @ipavl - Let's figure out this issue right?
Firstly, have you tried running on device but not as an IPA?  I ask because, that's usually how I debug device failures.  It's helpful to stay connected to device and see those logs and debug!
Secondly, I've seen this issue 2 times.  Once it was my rehydration of redux that was stopping crashes, so when I went to a device with no redux, I saw the issue.  You can mimic this locally by resetting your simulator as if it were a new device.
The other time this happened, it was a component I was using, and someone had filed a ticket on the component repo saying so.  Which saved me hours of narrowing down what component was misbehaving.  I forgot which one it was, now, but worth looking into.
I hope those help, please report back with findings.

@ipavl - any update?

Hi @GantMan, thank you for your response. I haven't had a chance to try on a device directly yet, but I had no issues running the Ignite base application on a fresh simulator.

gotcha.  Please run on device while tethered and let me know if you find anything.

There were no issues running it on a device from Xcode as Debug or Release directly.

that really doesn't make sense.   I'm not sure how you can debug the IPA.  Maybe add crashlytics or some other crash reporting 3rd party?

Short version
react-native-config's deployment target is 9.2 and the device I originally tested on was on a lower iOS version than I thought (<9.2). Changing its deployment target makes the app run.
I'm currently trying to see if there's a way to lower react-native-config's deployment target for my project in a way that could be checked into Git, otherwise I might just end up removing it.
Longer version
I was able to reproduce this by running the Ignite base application on a simulator running iOS 8, which matches the device it was failing on (I thought it was on 10). iOS 10 works fine.
This is what Xcode displays when the app crashes/stops loading:
dyld: Symbol not found: ___NSDictionary0__

Referenced from: /Users/.../Library/Developer/CoreSimulator/Devices/.../data/Containers/Bundle/Application/.../test.app/test

Expected in: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 8.3.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation

in /Users/.../Library/Developer/CoreSimulator/Devices/.../data/Containers/Bundle/Application/.../test.app/test

(lldb)

Adding CoreFoundation.framework and making it optional as suggested in this thread then results in a crash at return DOT_ENV of ReactNativeConfig.m:
- (NSDictionary *)constantsToExport {
    return DOT_ENV
}

From here I was able to find that the minimum iOS deployment target for react-native-config was 9.2. Changing it to 8 makes the app run, and removing CoreFoundation again still seems to work fine.

Hopefully react-native-config will be fixed up soon. We plan on testing this with our plugin system.

This is still an open issue on react-native-config https://github.com/luggit/react-native-config/issues/65

@hchoong has the work around for now.  Also react-native-device-info and react-native-maps does this too.  We'll look at overriding this in the plugins we create for these.


Plugin skips adding and committing paths containgin special characters

Noticed this when committing a file with this kind of path:
"pages/40.recipes/20.hot-smoked-salmon-salad-chermoula-dressing-saut\303\251ed-limes/recipe.md"
Accented characters are escaped in git listing and path is quoted, thereby avoiding any path filters configured in YAML (I have just [ "pages" ]).
Starting solution would be to match paths starting with quotes as well. Not sure if there are other edge cases that make adding regex support worthwhile.

Thinking for another minute(!), I think the problem might be in the commit string, since the path matches for display purposes :shrug:


NIFI-10740 Upgrade Spring Security from 5.7.4 to 5.7.5

Summary
NIFI-10740 Upgrades Spring Security from 5.7.4 to 5.7.5 to address several request filtering bugs.
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[X] Apache NiFi Jira issue created

Pull Request Tracking

[X] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[X] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[X] Pull Request based on current revision of the main branch
[X] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 8
[ ] JDK 11
[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Will review

+1 looks good, will merge.


Crypto trait in the high level interface and EAD

So far, we've only used crypto traits (#127) in the low-level objects, doing the hard-to-hacspec parts. This now applies the same to the high-level objects.
It still doesn't succeed in getting the dependency on all-the-implementations out, but at least now it's just a dev-dependency (depended on by the tests), and not a full dependency any more.
Examples moved to directly using the default edhoc-crypto selection, which makes it still easy to test around; actual applications I'd expect to depend on edhoc-crypto-something directly.

As git dev-dependencies are ignored by crates.io, I think that with this PR we can start #98 (publication to crates.io) over in earnest: edhoc-ead*, edhoc-consts, edhoc-crypto-trait and edhoc-rs could go to crates.io; the rest will stay unpublished for the moment.

Went through and it looks good!
The hax side fails but due to a known bug, should work when this is merged.
Will wait a bit before merge in case @malishav wants to take a look.


Move around Order Validator files

Codecov Report
Patch coverage has no change and project coverage change: -22.23 :warning:

Comparison is base (4d7bfc5) 100.00% compared to head (5670abe) 77.77%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff              @@
##              main    #1208       +/-   ##
============================================
- Coverage   100.00%   77.77%   -22.23%
============================================
  Files           46       46
  Lines         2652     2326      -326
  Branches       396      369       -27
============================================
- Hits          2652     1809      -843
- Misses           0      392      +392
- Partials         0      125      +125

Flag
Coverage Δ

foundry
77.77% <0.00%> (-0.04%)
:arrow_down:

production
?

reference
?

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

Impacted Files
Coverage Δ

contracts/interfaces/ERC165.sol
0.00% <0.00%> (ø)

... and 41 files with indirect coverage changes

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


Split geographic coordinate strings

Split strings given in edm:Place (DPLA::MAP::Place) into latitude and longitude.

I'm :+1:, other than the :squash:. I'd like @AudreyAltman and/or @no-reply take a gander.

I have nothing to add to what Tom wrote.  Looking good, @mb.

This looks great & is ready to go once we clarify the mapping pattern referred to here: https://github.com/dpla/KriKri/pull/144#discussion_r28072831
My notion is that looking for the delimiter is better since it makes fewer assumptions about the mapping/input data.

My changes allow mapping to both fields, giving preference to the lat, long format if both are given.  They also avoid destroying data unless we have successfully split the string.

@AudreyAltman and @anarchivist just a quick ping to remind that there are a few commits added to this PR yesterday. If one of you can review the latest changes, i think we're ready to :ship:

:ok_hand:

Squashed.


Add the standard image.Image output

It would have been perfect to be able to generate the standard image.Image, like image.NRGBA instead of already encoded PNG.
Or, if it is already possible, provide a documentation of how to do it.
Because I can see core/output has an Output interface with the GetImage() method, but couldn't figure how to get access to it.
Thanks!

GetImage() in Output interface actually returned is the encoded image format passed in when generating OutPut.
Like:
fileName := "test.png"
out := output.NewPNGOutput(imageSize)
quietZone := model.AutoQuietZone
qrcode, err = gqrcode.NewQRCode0(data, cons.QrcodeModel2, nil, mode.NewNumericMode(), quietZone)
if err != nil {
    t.Fatal(err)
}
qrcode.Encode(out, fileName)

There provide PNG, JPG and GIF formats, which you can find in image_output.go.


Let go layer create mobile thumbs

We do this in the go CLI, may as well let it handle mobile thumbs too since we're just using a JPG version

this is done...


Reduce KuduLite image size

Previously our KuduLite image reaches 8.78GB and Atlas team has hard time caching our images.
Fixes
In this PR, I made a few improvements to reduce the image size:

Turning on ENABLE_DYNAMIC_INSTALL, this is a Oryx feature to lazy load deployment tools (e.g. pip, npm, dotnet) only when customer triggers a build.
Clean up built-in SDKs by removing python, php, hugo and stripping nodejs!=9 and dotnet~2.
Squash the final image into a single layer.

Miscellaneous

Update KuduLite website to use .NetCore 3.1

Validation
Building the image from https://github.com/Hazhzeng/KuduLite/tree/hazeng-stage.
Uploaded the image to docker hub rogerxman/test:kudu-one and tested on private stamp.
The newly generated image now takes 3.01 GB.

CI fails due to github.com/Azure-App-Service/KuduLite master branch is still using dotnet~2


Feeding display_image_cleaner() path not working

I'm not sure what's going on. I can't get the image cleaner to work within my script. I've fed it an absolute path, a pathlib path from cwd, a os cwd path from changing dir, and no matter what, I get: TypeError: expected str, bytes or os.PathLike object, not NoneType
Full stack on the error:
---------------------------------------------------------------------------

TypeError                                 Traceback (most recent call last)

[<ipython-input-8-88fd12b35813>](https://localhost:8080/#) in <module>
    553     print(imgdir, defaultprint=True)
    554     print("Image Management Browser:")
--> 555     display_image_cleaner(imgdir)
    556
    557

4 frames

[/usr/local/lib/python3.7/dist-packages/jmd_imagescraper/imagecleaner.py](https://localhost:8080/#) in display_image_cleaner(path)
    187     icln_create_widgets(ICLN_BATCH_SZ)
    188     _,_,_,_,_,ddlFolder,_ = icln_pager.children
--> 189     icln_render_batch(ddlFolder.value, 0)

[/usr/local/lib/python3.7/dist-packages/jmd_imagescraper/imagecleaner.py](https://localhost:8080/#) in icln_render_batch(folder, batch, force_reload)
    131
    132   if(folder == "/"): folder = ""
--> 133   path = icln_base_path/folder
    134
    135   if((icln_folder != folder) or (force_reload)):

[/usr/lib/python3.7/pathlib.py](https://localhost:8080/#) in __truediv__(self, key)
    923
    924     def __truediv__(self, key):
--> 925         return self._make_child((key,))
    926
    927     def __rtruediv__(self, key):

[/usr/lib/python3.7/pathlib.py](https://localhost:8080/#) in _make_child(self, args)
    702
    703     def _make_child(self, args):
--> 704         drv, root, parts = self._parse_args(args)
    705         drv, root, parts = self._flavour.join_parsed_parts(
    706             self._drv, self._root, self._parts, drv, root, parts)

[/usr/lib/python3.7/pathlib.py](https://localhost:8080/#) in _parse_args(cls, args)
    656                 parts += a._parts
    657             else:
--> 658                 a = os.fspath(a)
    659                 if isinstance(a, str):
    660                     # Force-cast str subclasses to str (issue #21127)

TypeError: expected str, bytes or os.PathLike object, not NoneType

Output:
/content/drive/MyDrive/AI/Stable_Diffusion/images_out/time_to_stabilize
Image Management Browser:

As you can see, the path is correct, and leads to the images folder, but for some reason it always thinks the path isn't a string or bytes.

There seems to be some sort of conflict, nothing works, not even `display_image_cleaner('./') will work, same error. Something in my program (https://rebrand.ly/easy-diffusion) is conflicting with paths, but no clue what. It works fine in the colab example for the scraper.


Dataset not found

I got the following error
urllib.error.HTTPError: HTTP Error 404: Not Found
while running this command
!python examples/softmax_loss.py -d viper -b 64 -j 2 -a resnet50 --logs-dir logs/softmax-loss/viper-resnet50
The dataset has been removed I guess

You must be confusing repositories. We don't  have an example folder, nor a
softmax loss.
On Thu, Sep 26, 2019, 08:52 anoob09<EMAIL_ADDRESS>wrote:

I got the following error
urllib.error.HTTPError: HTTP Error 404: Not Found
while running this command
!python examples/softmax_loss.py -d viper -b 64 -j 2 -a resnet50
--logs-dir logs/softmax-loss/viper-resnet50
The dataset http://users.soe.ucsc.edu/~manduchi/VIPeR.v1.0.zip has been
removed I guess
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/VisualComputingInstitute/triplet-reid/issues/84?email_source=notifications&email_token=AAOJDTLR5DBMQGDIKSEL3GDQLRL2XA5CNFSM4I2V2PIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HNZPIBQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOJDTKDU73WHVNGEDCNCFDQLRL2XANCNFSM4I2V2PIA
.


line

adding contributors from comments

@all-contributors please add @gauravsofat  for projectManagement

@all-contributors please add @statebait  for projectManagement projectManagement


docs: update remote API responses and minor fixes

Add back the "old" networksettings fields that were removed,
but added back to maintain backward compatibility, in
https://github.com/docker/docker/pull/17538
Added changes to v1.22 that were applied to the v1.21 / v1.20 docs
after the API bump(s);
https://github.com/docker/docker/pull/17085
https://github.com/docker/docker/pull/17127
https://github.com/docker/docker/pull/13707
Also fixed some mixed tab/spaces indentation

@thaJeztah @tiborvass i have some important updates to the docs as well. Shall I use this PR to update them ? Atleast it will help avoid multiple PRs to track and cherry-pick.

@mavenugo are those the network case-change docs? (i.e. capitalize in the JSON response)?

@mavenugo either way is fine for me.

@tiborvass just chatted up with @mavenugo , and those changes are not API related, so he'll create a separate PR, thanks!

updated with /network changes
@moxiegirl @mavenugo PTAL

LGTM

@mavenugo can you give this a "lgtm" if it lgty? Just to double check :+1:

@thaJeztah do you want us to fix the IPAM in this PR or do another 1 ?

@mavenugo another one should be fine; let's take it one step at a time?

thanks @thaJeztah LGTM

Thanks for looking Madhu

@tiborvass please cherry-pick


Faq

Partial implementation of FAQ page, for design review
still todo:

[x] add navigation to FAQ page to footer
[x] add accessibility tests
[x] add additional question to surface downloadable resources (FAQ, one pager) in the FAQ page - BLOCKED on translations / final content approval
[x] add 508 compliant PDFS of downloadable resources - BLOCKED waiting on finalized PDFs

@jlhogan Can we update this sentence to remove the colon at the beginning?

@jlhogan real picky ask but can we add an A. on the last answer for continuity


Error when condition type is wrong

There are two situations in which a condition type can be wrong:

An AndCondition or OrCondition can receive two conditions with a different target type
The target type of the Condition does not match the type of the Resolver (or other parameter in case of a call other than getCollection()).

In both cases, an exception should be thrown.

This was done as a part of #145


Produce events "from scratch"

The Streams Producer should have a procedure streams.fromScratch that enables the huge loading of all nodes and relationships into the Kafka topics before tracing each new transactions

Use case -- you want to use source, and you want to bootstrap your topic with a full copy of neo4j before enabling source to product subsequent transactions to kafka

How would data be published?  Possibly new eventType
How to avoid 10 minute transaction timeouts?   Not sure yet.

3rd possibility -- apoc.periodic.iterate with streams.publish -- allows the user to customize their own publish format, while evading transaction timeouts.  Maybe?

Starting point -- write apoc.periodic.iterate documentation on how we can address this use case with an example of that.
Include how to use the notion of "filters" for source production, and how you might only want to match parts of the database.  Might want to address the CDC message format.  What should it be, if we don't know what the actual transaction "packets" were after the fact?


Main bundle size

I noticed just now that yarn build is reporting that index.js is over 2MB now. It appears this is primarily due to #100, which is now pulling in much more of the monaco editor -- without those changes, it is ~500kb

I personally think the squiggles are worth it. But we could also try to lazy load.

I'm not fussed for the moment, but we'll probably want to look into a slimmer version of the package at some point.
If not, maybe that's just the price of getting a full-featured Stan compiler and IDE in your web browser :p


Testing Vue components OL with jest isn't working

Version
1.0.0-beta.27
Reproduction link
https://github.com/openlayers/openlayers/issues/9317
Steps to reproduce
Add OL to project
What is expected?
complete any tests
What is actually happening?
crashed after start  unit testing

I created topic in Open Layers repository https://github.com/openlayers/openlayers/issues/9317 but it's problem possibly in low  jest's version

Please provide a reproduction in a GitHub repository that I can run to debug

This is an issue with your Jest setup:

You need to set Jest to transform node_modules
OL uses HTMLCanvasElement getContext which isn't implemented by JSDOM

Solve it by telling Jest to transform files from the ol package:
// jest.config.js
module.exports = {
  // ..
  transformIgnorePatterns: [
    'node_modules/(?!(ol)/)'
  ]
  // ..
};

And add a mocks.js file that patches getContext:
// mocks.js
HTMLCanvasElement.prototype.getContext = () => {}

import './mocks'; // Must be imported before the tested file
import { mount } from '@vue/test-utils'

thx


npm install problem with jasmine core

sorry I'm new to react, redux and koa (and node) but I wanted to try your starter as it looks like what I'm aiming for!
I'm getting the following error on install. It looks like jasmine is failing to install - have I misread it?
npm WARN deprecated<EMAIL_ADDRESS>Babel's CLI commands have been moved from the b
abel package to the babel-cli package
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fseve
<EMAIL_ADDRESS>npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\
node_modules\\npm\\bin\\npm-cli.js" "install"
npm ERR! node v6.3.1
npm ERR! npm  v3.10.3

npm ERR! shasum check failed for C:\Users\DELL\AppData\Local\Temp\npm-1988-94021
47c\registry.npmjs.org\jasmine-core\-\jasmine-core-2.5.2.tgz
npm ERR! Expected: 6f61bd79061e27f43e6f9355e44b3c6cab6ff297
npm ERR! Actual:   86b783a0d80a925e54c9e434a0f524f8b1333cc9
npm ERR! From:     https://registry.npmjs.org/jasmine-core/-/jasmine-core-2.5.2.
tgz
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     c:\projects\nodet\react-redux-koa\npm-debug.log

nvm, I ran it again and it worked - still not used to that yet.


kubectl_build: fix docker_build empty default values

Sorry, I forgot to fill the description – it's not good to do things in a hurry!
It fixes this error when building an image with the default secret value:
Build Failed: ImageBuild: could not parse secret: []: failed to parse csv secret: EOF

It was working before, I'm not sure exactly what changed — maybe the switch to a newer tilt version


[Snyk] Upgrade salesforce-alm from 54.8.1 to 54.8.2

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade salesforce-alm from 54.8.1 to 54.8.2.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 21 days ago, on 2022-10-17.

The recommended version fixes:

Severity
Issue
PriorityScore (*)
Exploit Maturity

Improper Input Validation SNYK-JS-XMLDOMXMLDOM-3092934
609/1000  Why? Proof of Concept exploit, Recently disclosed, CVSS 8.6
Proof of Concept

Prototype Pollution SNYK-JS-XMLDOMXMLDOM-3042243
609/1000  Why? Proof of Concept exploit, Recently disclosed, CVSS 8.6
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report
Base: 85.18% // Head: 85.18% // No change to project coverage :thumbsup:

Coverage data is based on head (2d118fb) compared to base (c08d82a).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           master      #43   +/-   ##
=======================================
  Coverage   85.18%   85.18%
=======================================
  Files          12       12
  Lines         871      871
  Branches      156      156
=======================================
  Hits          742      742
  Misses         67       67
  Partials       62       62

Flag
Coverage Δ

unittests
85.18% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out 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.


feat(@toss/validators): implemenet isBirthDate8 function.

Overview

It is related with isBirthDate6 function
I am developing applications comfortably through good functions such as isBirthDate6. When I create an application, I may need to receive 8 digits of your birth date instead of 6 digits.
So I created a new function. The internal implementation is almost the same.
PR Checklist

[x] I read and included theses actions below

I have read the Contributing Guide
I have written documents and tests, if needed.

@HoseungJang
Thank you for the comments!
Where can I find the standard for birthday?
Is it an international standard to mark birthdays in six digits as isBirthDate6 validates? 😁

I think the purpose of isBirthDate6 is close to validate the front resident registration number of Korea. And it's standard.

@HoseungJang Thank you for even showing examples of your own code!
I really understand


jax.scipy.special: fix gradient for xlogy & xlog1py

Fixes #15598

Can we use jtu.check_grads to check higher order AD too? (At 0 and elsewhere.)

Do those test at 0 though? If they did they already would have caught this bug, right?

Oh I see, but to be clear we don't have higher-order coverage for any jax.scipy.special functions: https://github.com/google/jax/blob/933d695170246efaba2f949b774235e407f1ea08/tests/lax_scipy_special_functions_test.py#L176

Ah something simpler than that, just take the current tests and add one new line to each, like jtu.check_grads(lsp_special.xlogy, (0.0, 3.0), order=2) and jtu.check_grads(lsp_special.xlog1py, (0.0, 3.0), order=2).

Ah that may not work because check_jvp and check_vjp may choose a negative step direction: https://github.com/google/jax/blob/933d695170246efaba2f949b774235e407f1ea08/jax/_src/public_test_util.py#L196
Nevermind, we should improve those utilities to handle this kind of case, but not block this PR on it.


(PUP-6623) Define an unwrap function

This commit adds an unwrap function for sensitive objects; this serves
to expose the plaintext value in case the wrapped value needs to be
operated on/interpolated/etc. While this does remove the safety measure
that the Sensitive object provides it also allows more general use of
the data type.

CLA signed by all contributors.

Looks good apart from not returning the result from the optionally given block.

Returning the result of the block also allows users to re-wrap sensitive information which is pretty neat; I've changed the function accordingly.

I'm :+1: on this once it rolls through Travis/Appveyor

@hlindberg thanks!


Drop .NET 6 Support

Why make this change?

.NET 6 is going out of support in a few weeks. DAB doesn't need to maintain support as it's published binaries are self-contained, meaning that dotnet runtime is included.

What is this change?

Removes .NET6 references from .csproj files for target framework.
Removes .NET6 specific code in authN handlers
Removes .NET6 sdk install in pipeline config
Removes .NET6 dependency section from src/Directory.Packages.props
CI/CD pipelines now complete quicker, as removing .NET6 shaves off about ~12-15minutes per test run. (Config file creation + integration tests)

How was this tested?

[x] Integration Tests
[x] Unit Tests

/azp run

Should we make changes in the scripts as well? FileName : scripts.publish.ps1
$dotnetTargetFrameworks = "net6.0", "net8.0"

Good initiative, we should check with @neeraj-sharma2592 with respect to dependencies on hosting before merging

I'm in touch with Neeraj for the same. Will add update accordingly.

/azp run

 This query will show files which still contain dotnet 6.0 reference.
There are some files with comments pointing to 6.0 related classes. Please check if these can be updated to 8.0

 This query will show files which still contain dotnet 6.0 reference. There are some files with comments pointing to 6.0 related classes. Please check if these can be updated to 8.0

Thanks, it was pointing to urls, updated and verified.

/azp run


Use print() function in both Python 2 and 3

Old-style print expressions are a syntax errors in Python3
print() function works as expected on both Python 2 and Python 3.

Good catch! I don't think symengine.py is supporting Python 2 any longer so everything should be Python 3

Yes.  Python 2 died more than 1,000 days ago on 1/1/2020 so there are almost no active projects that still support it.

Then we wouldn't need the from future import

That can be automated with pyupgrade --py37-plus **/*.py

Thanks for the tip and for the PR.


build: remove js-rln stuff

Not sure why CI is failing. Still investigating

CI failed but tracked in https://github.com/Rate-Limiting-Nullifier/rlnjs/issues/96#issue-1875299992


Make the Windows installer translatable

I suggest making the Windows installer translatable.
I dont know how but i think it says here how to do it:
http://nsis.sourceforge.net/Docs/Chapter4.html#langsinstructions
There is an example here that might help:
https://github.com/belphegor-belbel/instlux

This can be fixed with the PR #3501. It already includes some translation.

PR #3501 has been merged as v8.1.0616, so now we can translate the Windows installer. Closing.
Note: We have only 8 translations and half of them are still incomplete (Dutch, Italian, Simplified Chinese and Traditional Chinese). Updates for the translations are welcome. Please check nsis/lang/*.nsi.


Fix location of testutil pkg after prometheus update.

bugfix after prometheus update. https://github.com/prometheus/prometheus/pull/5893

Changes
prometheus tsdb/testutil has moved to util/testutil, so change it in thanos too
Verification

run go vet first
run go test ./... -v

Signed-off-by: johncming<EMAIL_ADDRESS>

Hm, I think if we want to fix this, we need to update deps as well, right? (:

Hm, I think if we want to fix this, we need to update deps as well, right? (:

Does it mean go mod？


Output HTML should be the filename.html.

When creating an HTML file there is an issue with the file name being the Title of the txt file rather than the filename.html.

Thank you, it is corrected.


add an example for converging mulitple recipes in README.md

I'm aware an example for using multiple recipes is included in lib/chefspec/solorunner.rb on line 95 but I thought it would be helpful for others to have one in the README.md as well.


Is the HLS output stream "live" or cached?

It seems that HLS chunks are cached in a local folder, so in some conditions it may happen to reproduce "old" content .
How is managed the local cache (.ts chunks) and "m3u8" index file with "live" / real time streams ?
Thank you very much,

The TS list will keep the latest 6 ones(now is hardcoded), and the old ones will be deleted automatically, the m3u8 file is generated according to the dynamic TS list.
In the future release , XIU will support to configure the values in the configuration file.

Thank you very much for explanation, I check with a live stream source and the behaviour is correct.
Yes, that feature sounds nice: it will also permit to optimize latency for HLS output stream.


Inconsistent MOs on linux vs macos

I'm running into inconsistent behaviour when running a simple HF calculation on linux. See the below test which gets the one-electron integrals in the MO basis twice, and checks for consistency:
def test():
    mol = gto.Mole().build(
        atom="He 0 0 0; He 0 0 1",
        basis="ccpvdz",
        verbose=0,
    )
    mf1 = scf.RHF(mol)
    mf2 = scf.RHF(mol)
    mf1.kernel()
    mf2.kernel()
    h1_1 = mf1.get_hcore()
    h1_2 = mf2.get_hcore()
    h1_1_mo = numpy.einsum('ki,kl,lj->ij', mf1.mo_coeff, h1_1, mf1.mo_coeff)
    h1_2_mo = numpy.einsum('ki,kl,lj->ij', mf2.mo_coeff, h1_2, mf2.mo_coeff)
    assert numpy.allclose(h1_1_mo, h1_2_mo)

This test consistently passes on macos with pyscf v2.0.1; both mf objects converge to the same ground state with identical MO coefficients.
On linux however, the energy of the two ground states are always in agreement, but the MOs are not. Sometimes it passes, sometimes it fails. I've tested this on three different linux systems, and on pyscf versions 1.7.6, 2.0.1, and 2.1.1, and the inconsistency persists.
It is my understanding that the HF solution is not unique, but I don't see how I could be finding two different solutions with the code above. Or why they should be different on linux compared to macos.
Thanks

The eigensolution is not unique with respect to phase. I think the assert is failing because of an occasional sign difference between solutions. For example one run fails the assertion because (looking at np.allclose) the values -4.68461519e-01 and 4.68461519e-01 produce False.

I think you are right @pwborthwick. My main concern is that, on macos, we consistently converge to the solution with the same phase, but on linux it is seemingly picks one at random. It is not clear to me where this randomness comes from.

It's down to rounding errors in the diagonalisation procedure I believe, which will differ slightly with operating environment. Some programs attempt to ensure consistency and this is discussed eg here and issue was raised in pyscf #580. This sign difference comes out in the wash when calculating physical (observables) quantities.

I think you are right @pwborthwick. My main concern is that, on macos, we consistently converge to the solution with the same phase, but on linux it is seemingly picks one at random. It is not clear to me where this randomness comes from.

The randomness is likely coming from threading. The operations required for diagonalization are not guaranteed to commute in finite precision, so threading can result in non-deterministic behaviour. If you set OMP_NUM_THREADS=1, you should get deterministic behaviour.

@obackhouse don't think it's related to threads. I've tried adding
import os
os.environ['OMP_NUM_THREADS'] = '1'

which returns with
import threading
print('Number of threads = ', threading.active_count()

the value
Number of threads = 1

and this make no difference as I still get random assertion errors.

It's down to rounding errors in the diagonalisation procedure I believe, which will differ slightly with operating environment. Some programs attempt to ensure consistency and this is discussed eg here and issue was raised in pyscf #580. This sign difference comes out in the wash when calculating physical (observables) quantities.

Well, another way to say it is that the wave function is arbitrary to a phase factor; for real functions this means a sign.
This also applies to any eigenproblems: Mv = ev is arbitrary to a sign of the eigenvectors, and therefore any comparisons of the eigenvectors should be done in a manner that is invariant to changes in the phase.

This is also not a Linux vs MacOS issue. Threading can cause small roundoff differences in the matrices, and change the sign of the solution. Different linear algebra libraries on the same platform can also yield different signs.

@harrkee to sum up

There was nothing wrong with the behaviour of your original code. The assert was correctly noting the arbitrary nature of the wavefunction phase as I noted in my first post

The eigensolution is not unique with respect to phase

and expanded on by susilehota. The computed values are all correct.

The arbitrary nature is due to

the operating environment

in general and , as susilehota has pointed out, not a difference between macos and linux (both unix based OS's) in particular.

obackhouse has elucidated the reason for the sign differences as being the multi-threading

The randomness is likely coming from threading

this is confirmed by adding the lines
from pyscf import lib
lib.num_threads(1)

after which I get assert=True consistently.  (Perhaps add
from pyscf import lib
print('Active threads = ', lib.num_threads())

to satisfy yourself that macos is multi-threading and the consistency that you're getting with it isn't because macos is already only using a single thread)

If you want to employ multi-threading and still want to get a consistent sign then you will have to use some convention to fix the sign of the eigenvectors as alluded to in the post I referenced earlier.

From the num_threads documentation

It’s recommended to call this function to set OMP threads than “os.environ[‘OMP_NUM_THREADS’] = int(n)”. This is because environment variables like OMP_NUM_THREADS were read when a module was imported. They cannot be reset through os.environ after the module was loaded.

Which explains why my attempt to use OMP_NUM_THREADS didn't work.

If you want to employ multi-threading and still want to get a consistent sign then you will have to use some convention to fix the sign of the eigenvectors as alluded to in the post I referenced earlier.

PySCF actually has a convention
https://github.com/pyscf/pyscf/blob/6f7f0a8145d7240a5f95b2d3837cd4c35c80c985/pyscf/scf/hf.py#L1166-L1167
but it does not deterministically handle the phase of coefficients corresponding to degenerate MOs

If you want to employ multi-threading and still want to get a consistent sign then you will have to use some convention to fix the sign of the eigenvectors as alluded to in the post I referenced earlier.

PySCF actually has a convention
https://github.com/pyscf/pyscf/blob/6f7f0a8145d7240a5f95b2d3837cd4c35c80c985/pyscf/scf/hf.py#L1166-L1167
but it does not deterministically handle the phase of coefficients corresponding to degenerate MOs

Degenerate eigenvectors are harder since they can be rotated arbitrarily amongst each other and the only mathematically valid check is if they span the same subspace...


Add multiple projects per issues function

Closes #12974
Test:
https://github.com/go-gitea/gitea/assets/1255041/ae4d75f9-b853-4c81-ab0b-c10e0a904d5c
Last tested:

Any question and any update?

Conflict has arisen, do not want to resolve, close


/tmp/cuda-installer.log causes subsequent installs of other users to fail

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
This is already described in here: https://github.com/conda-forge/cudatoolkit-dev-feedstock/issues/44
The solution is to remove /tmp/cuda-installer.log created by the user first installing cuda on the system.
However a backport to older cudatoolkit-dev is missing.
To my understanding, @jnooree tried but didn't find a fitting commit.
He mentioned to create another issue to notify maintainers, what I do now.
I use following environment.yml
---
name: tf2
channels:
  - conda-forge
dependencies:
  - python>=3
  - tensorflow==2.11.1=cuda112*
  - cudatoolkit-dev=11.2
  # ## not necessary (all required tools are in cudatoolkit-dev), though otherwise 11.8 is installed which is confusing
  - cudatoolkit=11.2

which fails with
ERROR conda.core.link:_execute(730): An error occurred while installing package 'conda-forge::cudatoolkit-dev-11.2.2-py39h3811e60_0'.

LinkError: post-link script failed for package conda-forge::cudatoolkit-dev-11.2.2-py39h3811e60_0
location of failed script: <some path>/.conda/envs/tf2/bin/.cudatoolkit-dev-post-link.sh
==> script messages <==
<None>
==> script output <==
stdout: Log file not open.
Running Post installation
downloading https://developer.download.nvidia.com/compute/cuda/11.2.2/local_installers/cuda_11.2.2_460.32.03_linux.run to <some path>/.conda/envs/tf2/pkgs/cudatoolkit-dev/cuda_11.2.2_460.32.03_linux.run
Extracting on Linux

stderr: <some path>/.conda/envs/tf2/pkgs/cudatoolkit-dev/cuda_11.2.2_460.32.03_linux.run: line 513: 680866 Segmentation fault
    (core dumped) ./cuda-installer --silent --toolkit --toolkitpath=/data/scratch/62320/tmpj5oiro_4 --override
Traceback (most recent call last):
  File "<some path>/.conda/envs/tf2/bin/cudatoolkit-dev-post-install.py", line 216, in <module>
    _main()
  File "<some path>/.conda/envs/tf2/bin/cudatoolkit-dev-post-install.py", line 212, in _main
    extractor.extract()
  File "<some path>/.conda/envs/tf2/bin/cudatoolkit-dev-post-install.py", line 124, in extract
    subprocess.run(cmd, env=os.environ.copy(), check=True)
  File "<some path>/.conda/envs/tf2/lib/python3.9/subprocess.py", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['<some path>/.conda/envs/tf2/pkgs/cudatoolkit-dev/cuda_11.2.2_460.32.03_linux.run', '--silent', '--toolkit', '--toolkitpath=/data/scratch/62320/tmpj5oiro_4', '--override']' returned non-zero exit status 139.

return code: 1

()

Installed packages
$ conda list
# packages in environment at /cfs/earth/scratch/slurmtest1/.conda/envs/tf2:
#
# Name                    Version                   Build  Channel

Environment info
$ conda info

     active environment : None
            shell level : 0
       user config file : ~/.condarc
 populated config files : <path to global config>/condarc
          conda version : 4.12.0
    conda-build version : not installed
         python version : 3.9.12.final.0
       virtual packages : __linux=4.18.0=0
                          __glibc=2.28=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : <path to spack installed>/miniconda3-4.12.0  (read only)
      conda av data dir : <path to spack installed>/miniconda3-4.12.0/etc/conda  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : <some loc>/.conda/pkgs
       envs directories : <some loc>/.conda/envs
                          ~/.conda/envs
                          <path to spack installed>/miniconda3-4.12.0/envs
               platform : linux-64
             user-agent : conda/4.12.0 requests/2.27.1 CPython/3.9.12 Linux/4.18.0-372.16.1.el8_6.x86_64 rocky/8.6 glibc/2.28
                UID:GID : 529000190:529000190
             netrc file : None
           offline mode : False

Facing the same problem too.


cant fill in my inputs

<!---   *** BEFORE SUBMITTING: PASTE CLIPBOARD HERE TO COMPLETE YOUR REPORT ***   ---!>

Closing because this is empty.


Scala removal2 - Memcached

There are some test failures I didn't see locally I need to investigate still.

Needs rebasing

Looks good otherwise 😄

I just have a few tests I need to fix up, could have sworn I tested before I did the last push :/

Rebased and fixes tests.

Pushed to master, thanks


[Question] PagedSliverList and decoration

How can I set decoration for infinite sliver list, for example, I want to set border radius and background color, or maybe shadow box

The same way you would do it with a SliverList. I've found these links:
https://stackoverflow.com/questions/60803149/how-to-corner-radius-on-slivergrid-sliverlist-on-flutter
https://stackoverflow.com/questions/58570208/how-to-give-borderradius-to-sliverlist/63251876#63251876
I hope it helps! Thank you!


Add Edit page button in oasis-core, oasis-sdk and oasis-core-ledger subsites

Currently, the Edit page button is visible only for general and network-primer docs. Edit page links for oasis-core and other external repositories are broken, because the .md files path begins with external/oasis-core/docs/..., but the root of the external repository path is actually external/oasis-core. Find a way to shave off the first two directories of the Edit page URL and enable the Edit button on externals repositories.

Implemented in #200.


Adding more handy folds

Codecov Report

Merging #85 into master will decrease coverage by 0.85%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #85      +/-   ##
==========================================
- Coverage     100%   99.14%   -0.86%
==========================================
  Files           1        1
  Lines         674      698      +24
==========================================
+ Hits          674      692      +18
- Misses          0        6       +6

Impacted Files
Coverage Δ

dist/partial.lenses.cjs.js
99.14% <0%> (-0.86%)
:arrow_down:

Continue to review full report at Codecov.

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