ADLS Gen2 copy, move

AZ Storage Explore Version 1.10.1, AzCopy 10.2.1
There is currently now way to reorganize a once created structure in ADLS Gen2, without writing code.
It would be great to have a copy and a move operation in Azure Storage Explorer to reorganize hierarchical structures inside the ADLS account as well as copy these structures inside the ADLS account, which can keep the security settings in-place.
Using Data Factory for this operation seems to be an overkill and introduces a steep learning curve for getting the job done.

We have done some integration work to enable copying data in ADLS Gen2 blob containers via AzCopy. Unfortunately, we don't support preserving ACLs between copies.

A move feature has been added for ADLS Gen2 containers and will be included in 1.15.0.


samples: boards: nordic: system_off: add console checking

Basic verification of output.

Rebased (due to conflict)


cannot connect to botnet monitor

[E 150522 20:34:57 websocket:405] Uncaught exception in /botnet/connect
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/tornado/websocket.py", line 402, in _run_callback
callback(*args, **kwargs)
File "/home/anarky/PycharmProjects/RootTheBox/handlers/BotnetHandlers.py", line 87, in open
box = Box.by_ip_address(self.request.remote_ip)
File "/home/anarky/PycharmProjects/RootTheBox/models/Box.py", line 123, in by_ip_address
ip = dbsession.query(IpAddress).by_address(ip_addr).first()
AttributeError: 'Query' object has no attribute 'by_address'

This is actually thrown when attempt to run the bot on a computer, not the monitor

Fixed.


Configurer improved version matching (allow RHEL >= 7.4, < 8.0)

Makes it possible to define more advanced host configurer version matchers. Currently it's only possible to list each version separately:
Before:
class Rhel7 < Configurer
  register_config 'rhel', '7.4'
  register_config 'rhel', '7.5'
  register_config 'rhel', '7.6'
  register_config 'rhel', '7.7'
end

After:
class Rhel7 < Configurer
  register_config 'rhel', /^7\.[4-9]|\d{2,}/
end

This has been used in this PR to make the rhel7 configurer match RHEL >= 7.4 && < 8.0. (Including something like 7.19-beta2.rc4)
The matcher can be anything that handles triple equals.

Any progress on this?

Any progress on this?


Print JS errors to stderr

Codecov Report

Merging #1155 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1155   +/-   ##
=========================================
  Coverage     86.16%   86.16%
  Complexity     3654     3654
=========================================
  Files           370      370
  Lines         14382    14382
  Branches       1602     1602
=========================================
  Hits          12392    12392
  Misses         1555     1555
  Partials        435      435

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 72268f6...20f369c. Read the comment docs.

Note that 404 errors aren't printed properly, because the reason doesn't have a result property in that scenario
Maybe we should print just reason instead?

I'll come back to the 404 thing in a follow-up


Openapi tool source code not getting regenerated after removing the generated code.

Description:
In openapi automate client generation, if the code is generated once with bal build, that code is deleted and bal build run again, the code is not getting generated again. However if we delete the target dir (which contains a cache for openapi tool), the generation works fine.
Steps to reproduce:

In a new ballerina project add an openapi tool entry. [[tool.openapi]]
 id = "oa1"
 filePath="service.yaml"
 targetModule="oa1_target"
 options.mode = "client"

Run bal build. This will create both target dir and the generated dir.
Delete only the generated dir
Re-run bal build

Affected Versions:
2201.9.0
OS, DB, other environment details and versions:
MacOS
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

@gayaldassanayake, With my concern, from a design perspective, there is a dependency between the target and generated directories, particularly with the package build commands, shouldn't we validate whether the target directory is available and ensure the presence of the generated folder, and vice versa, before continuing the process?

One option is for the package build commands to provide a warning and continue executing the process. In this case, every tool that integrates with the package build command can handle this scenario in their own way.
Alternatively, the package build command can give an error and terminate


Update policies.rst

Hi @JimmyHannon, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

@blowdart Please review.

Oops, yea, that's good :)

:shipit:

Thanks for the PR. Merged in 29c3d17ddefb669ce2a1b3253fb6e30255bfa706


Reproduce the final results

Dear @xu-ji ,
Thank you for your brilliant work. I have trained the IIC network, and have some questions about reproducing the final results:

Are the parameter settings of CIFAR-10-clustering shown in "IIC/examples/commands.txt" same as the settings in paper? Or are there always exists some fluctuations in final results? It seems like I can't reproduce the best acc 61.7 on CIFAR-10 dataset. I only got 59.01% best acc.
Is there any possibility you update a python3 version code? Or have you test the performance of code in this repo https://github.com/sebastiani/IIC?

Sorry to bother. Looking forward to your reply.

There will be some variation. I did not set some random seed for perfect reproducibility; I should have.
I want to leave it as it was when I did the work. But I don't think the changes to python3 syntax are very complicated. I have not tested that repository you linked.


Auto-update with remote registry URL

This PR moves the registry logic to pkg/registry + set up auto-update logic in case of remote registry

now TorProxy struct has a Registry member representing either ConstantRegistry (from file or from JSON string) or RemoteRegistry from a remote URL.
Using StartAutoUpdateRedirects function, the proxy is now able to set up an auto-updater: refetching the registry from remote URL every 12 hours.

it closes #12
EDIT: maybe the interval should be configurable via CLI option ?
@tiero please review

@louisinger remove TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA from the TLS cypher suites, please.


ARM compilation - giflib error

I'm trying to compile precomp for arm, since it's getting more and more common every day, and there are fast and robust systems built around it.
But I'm getting this:
./contrib/giflib/egif_lib_gcc.c:116:29: error:
  use of undeclared identifier 'S_IREAD'
                      , S_IREAD | S_IWRITE);
                        ^

./contrib/giflib/egif_lib_gcc.c:116:39: error:
  use of undeclared identifier 'S_IWRITE'
                      , S_IREAD | S_IWRITE);
                                  ^

./contrib/giflib/egif_lib_gcc.c:124:29: error:
  use of undeclared identifier 'S_IREAD'
                      , S_IREAD | S_IWRITE);
                        ^

./contrib/giflib/egif_lib_gcc.c:124:39: error:
  use of undeclared identifier 'S_IWRITE'
                      , S_IREAD | S_IWRITE);
                                  ^

Do you support building precomp for ARM?

Didn't have a working ARM version so far, but also tried to compile on my Android phone and my Raspberry Pi with the same result. These are some calls to file open routines that should be possible to replace so it compiles.

@M-Gonzalo Could you check the arm-test branch I created? Had to do add additional checks and CMake specific stuff to your solution to enable building everywhere (Windows/Linux, ARM, ARM64).
The branch is based on the multithreaded-reconstruction branch and works for me on a Huawei tablet (ARM 64-bit) and a Motorola mobile phone (ARM 32-bit) - except for the packJPG and packMP3 bugs, these seem to be char-related and might be possible to fix later, too.

There's a second branch called "arm-test-packjpg-packmp3-fix" now that is based on the arm-test branch and contains fixes for packJPG and packMP3, tested both of them on single files successfully.
I will do some further testing, but for now it looks good and I'm looking forward to merge this :+1:

For the sake of completeness, here are build instructions for others that want to test the ARM compile:
git clone https://github.com/schnaader/precomp-cpp.git
cd precomp-cpp
git checkout arm-test-packjpg-packmp3-fix
cmake ./
make -j

Will do! Expect results in the next few days.

OK, sorry for the delay. I was in the middle of moving out to a new apartment and it was a mess.
I tested precomp against hundreds of GB of data on my phone using Termux, including thousands of jpgs and mp3s. Always roundtrip OK except for big files with a lot of streams (mostly apks). I keep seeing error reports about missing temp files.

A different thing, Matthias' pack* libraries appear to be significantly slower on ARM than on comparable x86_64 CPUs, but that is only a subjective observation...


chore(3): add first integrated project

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)

Adds the first integrated project with solution

Here's where I'm at after trying to get some more tests working:

A couple other things on the todo list:
-Remove wallet.json or rename it to wallet-example.json?
-Maybe rename the project to 'Build a Solana Smart Contract' or something
-Remove solution
-Add that test-ledger to vscode hidden files?


Why does fetching threads failed on services other than ESS?

Error from Dev Tools
Fetching Threads failed TypeError: Cannot read property 'threads' of null
    at Object.fetchThreadsSuccess (https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:846905)
    at c (https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:1061149)
    at https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:1634937
    at f (https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:802991)
    at https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:1523218
    at https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:283910
    at dispatch (https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:1632507)
    at t.dispatch (https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:284395)
    at l (https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:1061553)
    at Object.u.(anonymous function) [as fetchThreadsSuccess] (https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:353819)
    at https://private.deciphernow.com/services/apps/1.0/gmadmin/static/js/main.13e263b3.js:1:848697
    at <anonymous>

We need to determine if the /threads endpoint exists for the services failing in this way (seem to be all but ESS) and determine if this might be due to ElasticSearch klobbering the request with a redirect to GMData

@tilleryd - Perhaps you might be able to look into this. This may intersect with the versioning stuff I mentioned about Finagle.

Some of the enhanced error handling in the AJAX Worker thread should help diagnose this issue. This needs likely needs attention from @joshua-rutherford if this is critical.

Upon further investigation, this is indeed due to different Finagle versions. Closing issue.


Form: login/register page

Description
Adds base pages for /login and /register
FE tasks

[ ] Add base template
[ ] Apply styles

BE tasks

@bdimaggio @JulesKhong I'd make the case for depriotizing this since wp-login exists as a out of the box solution for standard user login and registration such a unique implementation for each project. User login and reg feels like a feature that'd be a Find A Hike for any project it appears on.
What does everyone think?


youtube-dl unable to download some vlive channels

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like this: [x])
Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2<IP_ADDRESS>. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

[ ] I've verified and I assure that I'm running youtube-dl 2<IP_ADDRESS>

Before submitting an issue make sure you have:

[x] At least skimmed through the README, most notably the FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add the -v flag to your command line you run youtube-dl with (youtube-dl -v <your command line>), copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'-v', u'http://www.youtube.com/watch?v=BaW_jenozKcj']
[debug] Encodings: locale cp1251, fs mbcs, out cp866, pref cp1251
[debug] youtube-dl version 2<IP_ADDRESS>
[debug] Python version 2.7.11 - Windows-2003Server-5.2.3790-SP2
[debug] exe versions: ffmpeg N-75573-g1d0487f, ffprobe N-75573-g1d0487f, rtmpdump 2.4
[debug] Proxy map: {}
...
<end of log>

If the purpose of this issue is a site support request please provide all kinds of example URLs support for which should be included (replace following example URLs by yours):

Single video: https://www.youtube.com/watch?v=BaW_jenozKc
Single video: https://youtu.be/BaW_jenozKc
Playlist: https://www.youtube.com/playlist?list=PL4lCao7KL_QFVb7Iudeipvc2BCavECqzc

Note that youtube-dl does not support sites dedicated to copyright infringement. In order for site support request to be accepted all provided example URLs should not violate any copyrights.

Description of your issue, suggested solution and other information
Explanation of your issue in arbitrary form goes here. Please make sure the description is worded well enough to be understood. Provide as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.

I'm getting Failed to Parse JSON error on some vlive channels that worked in the past such as
http://channels.vlive.tv/EDBF
http://channels.vlive.tv/E832DF
http://channels.vlive.tv/ECDF
http://channels.vlive.tv/FD53B
Error seems to exist even with the linux version
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['http://channels.vlive.tv/EDBF', '--verbose']
[debug] Encodings: locale cp1252, fs mbcs, out cp1252, pref cp1252
[debug] youtube-dl version 2<IP_ADDRESS>
[debug] Python version 3.4.4 - Windows-10-10.0.15063
[debug] exe versions: none
[debug] Proxy map: {}
ERROR: EDBF: Failed to parse JSON  (caused by ValueError('Expecting value: line 1 column 1 (char 0)',)); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpfdfxmx88\build\youtube_dl\extractor\common.py", line 676, in _parse_json
  File "C:\Python\Python34\lib\json\__init__.py", line 318, in loads
  File "C:\Python\Python34\lib\json\decoder.py", line 343, in decode
  File "C:\Python\Python34\lib\json\decoder.py", line 361, in raw_decode
ValueError: Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpfdfxmx88\build\youtube_dl\extractor\common.py", line 676, in _parse_json
  File "C:\Python\Python34\lib\json\__init__.py", line 318, in loads
  File "C:\Python\Python34\lib\json\decoder.py", line 343, in decode
  File "C:\Python\Python34\lib\json\decoder.py", line 361, in raw_decode
ValueError: Expecting value: line 1 column 1 (char 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpfdfxmx88\build\youtube_dl\YoutubeDL.py", line 776, in extract_info
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpfdfxmx88\build\youtube_dl\extractor\common.py", line 433, in extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpfdfxmx88\build\youtube_dl\extractor\vlive.py", line 241, in _real_extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpfdfxmx88\build\youtube_dl\extractor\common.py", line 670, in _download_json
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpfdfxmx88\build\youtube_dl\extractor\common.py", line 680, in _parse_json
youtube_dl.utils.ExtractorError: EDBF: Failed to parse JSON  (caused by ValueError('Expecting value: line 1 column 1 (char 0)',)); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Thanks


add IP to VM Address

add IP after FQDN

I think it would be also usable to add network name (e.g. eth0 not ovirtmgmt), MAC and IPv6 adresses

@leistnerova why do you need IP when you have the FQDN?

I admit, that it is 'nice to have' feature. I use IPs for firewall or postgres, so it's comfortable to copy it directly.

@lizsurette @lwrigh let's discuss in the next redesign meeting

IP Addresses to be added in #700
Epic for #652 will also include a view for NICs that should show at least the nic's name and vnic profile.


move viewer to JavisViewer

PR Checklist
If you are contributing to Javis.jl, please make sure you are able to check off each item on this list:

[ ] Did I update CHANGELOG.md with whatever changes/features I added with this PR?
[ ] Did I make sure to only change the part of the file where I introduced a new change/feature?
[ ] Did I cover all corner cases to be close to 100% test coverage (if applicable)?
[ ] Did I properly add Javis dependencies to the Project.toml + set an upper bound of the dependency (if applicable)?
[ ] Did I properly add test dependencies to the test directory (if applicable)?
[ ] Did I check relevant tutorials that may be affected by changes in this PR?
[ ] Did I clearly articulate why this PR was made the way it was and how it was made?

Link to relevant issue(s)
Closes #460
How did you address these issues with this PR? What methods did you use?
In this PR I remove all parts of Javis that are used for the liveview and will add them in the JavisViewer.jl package.
Once I create a PR in JavisViewer I will reference this one.

Codecov Report

Merging #461 (c314a8d) into master (b7f78a4) will increase coverage by 0.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #461      +/-   ##
==========================================
+ Coverage   96.47%   96.60%   +0.12%
==========================================
  Files          35       33       -2
  Lines        1617     1530      -87
==========================================
- Hits         1560     1478      -82
+ Misses         57       52       -5

Impacted Files
Coverage Δ

src/Javis.jl
96.78% <ø> (-0.09%)
:arrow_down:

src/morphs.jl
95.97% <0.00%> (-0.51%)
: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 b7f78a4...c314a8d. Read the comment docs.

@Wikunia @TheCedarPrince And with a new PR a new interface question.
I am going similar to JavisNB with the equivalent of embed being stream the question is I am moving the liveview=true option into stream and entirely out of render, or at least that would be the plan. Is this a good idea or do you prefer the possibility to call liveview from  render itself? Perhaps the best is having it in both render and  stream acting in the same way?
Let me know what you think!

I think I would use a liveview function which works similar to the embed function. No need for a liveviewer keyword anymore. Stream sounds more reasonable to me when we have a stream to twitch functionality or something like that.


Rebuild to receive updated run_exports from fontconfig

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Context: https://github.com/conda-forge/r-base-feedstock/issues/91

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Ready for review / merge :)

Ping :)

Thanks!


update configuration.md with serviceaccount/tf example

add info on setting up aws serviceaccount role
add new terraform example section for setting up helm chart along with service account role/policy.

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


2captcha support

Description
WARNING More tests are needed. I did not have accounts with captcha :(

2captcha support
Loop implementation for those who want to leave it running. It will check accounts queue every X seconds (X can be set on config.py)
Two new variables in config.py.

I don't think 2captcha solving should be done in a separate queue. You'll increase the logins unnecessarily


show_blocking_widget debug option makes the application hang

Describe the bug

Enabling the show_blocking_widget option causes the application to hang. Observed both locally and on https://www.egui.rs/
To Reproduce
Steps to reproduce the behavior:

Go to https://www.egui.rs/
Open Settings windows and expand the Debug collapsing header
Check the last option "Show what widget blocks the interaction of another widget"
The UI stops responding, without using any CPU

Expected behavior

The debug option draws the overlapping rectangles and doesn't freeze the UI.
Screenshots

Desktop (please complete the following information):

OS:  Fedora 37
Browser  Firefox
Version 110.0

Additional context

This is the code that runs when this option is enabled:
https://github.com/emilk/egui/blob/7215fdfb7c7407b8085d53052582dac10124bdfc/crates/egui/src/context.rs#L587-L598
The problem seems to be that this code being called inside a Context::write() call, whereas both acquiring and using the layer painter requires some Context::read() and Context::write() calls, so it causes a deadlock.

I can reproduce it in the web version on chromium 110, Linux


Feature/shared list

Feature for shared item list for events.

Fully functioning items list system, stored within an event.
Dynamic FE.

Codecov Report

Merging #278 (040e9ce) into develop (8cd3a6e) will decrease coverage by 0.05%.
The diff coverage is 97.01%.

@@             Coverage Diff             @@
##           develop     #278      +/-   ##
===========================================
- Coverage    99.04%   98.98%   -0.06%
===========================================
  Files           52       52
  Lines         2409     2468      +59
===========================================
+ Hits          2386     2443      +57
- Misses          23       25       +2

Impacted Files
Coverage Δ

app/database/models.py
95.62% <90.47%> (-0.67%)
:arrow_down:

app/routers/event.py
98.10% <100.00%> (+0.41%)
:arrow_up:

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 8cd3a6e...040e9ce. Read the comment docs.

@yammesicka @subscorp ,
Uploaded a pack of changes according to your reviews.
If there's anything else I should fix or add to the code - let me know.
Thanks!

BTW, HTMX probably could make this a very easy ticket :)) I'd suggest to take a look


[HOLD] Disable files panel when selecting no

Why was this change made? 🤔
Resolves #3505. HOLD for testing in deployed env and by PO. Please squash when merging!

How was this change tested? 🤨
Locally, deployed to QA for PO testing
Does your change introduce accessibility violations? 🩺
No new ones

Bug 1:
@amyehodge has found a problem with attached files that I think is related to initially saving a draft with neither Yes/No select.

Edit a deposited work
Don't select Yes or No. Save the draft
Edit it again and select Yes. Add a file.
HB error: https://app.honeybadger.io/projects/55564/faults/100610329

I am not sure yet of the source of the error, but I think it has to do with the use_previous_attached_files method in the base_work_form.rb and it attaching (empty?) files that don't get checksummed later.
I am not sure why we removed logic to require users to select Yes/No even when creating a draft. It seems like that would be good to do anyway, to avoid having a nil new_user_version param  saving nil user_version numbers into the work_version.
Bug 2
If you don't select Yes/No, save the draft, and then re-open the draft, the previous version's version description is getting displayed:

I made a change in the last commit to require users to select Yes/No for a new version even in draft mode.  Forcing a selection seems to prevent the bugs above, pending further testing in QA. The styling could use a tweak (see below) to be bolder.
If this does not match with the desired UX, we will need to find a different solution.


Add spaces in code snippets for consistency

Change for consistency:

Add a space after : in json
Indent 2 spaces in yaml

/kind cleanup
/lgtm
/approve
Trivial edits.


Project Test Case 9_03

Hiii I encounter this problem regarding test case 3. My code was able to pass all the public cases but not this private case. I was looking through other questions on test case 3 and mostly because of not updating the queues properly, but my test output looks different from theirs, so im not sure what causes my error.
My approach was creating a doneTime attribute in server. nextAvailableTime of server will be updated with the restTime and doneTime will not, then time for Done event will be the doneTime of server. I basically did not change much from previous lab until this stage.

You may not need a doneTime attribute in Server, since when you instantiate a Done event, you call the constructor with the time done. Only when

a Done event is retrieved from the priority queue
its next() method is called

Then should the rest() method be called on the server

You may not need a doneTime attribute in Server, since when you instantiate a Done event, you call the constructor with the time done. Only when

a Done event is retrieved from the priority queue
its next() method is called

Then should the rest() method be called on the server

hii thx for the reply! does it mean that i should write a separate rest() method which is only called when done event is retrieved and next() on done is called?

Would recommend Server to have a rest() method so that you can tell a server to rest. Just like Customer with getServiceTime() you should take care not to call rest() multiple times

Would recommend Server to have a rest() method so that you can tell a server to rest. Just like Customer with getServiceTime() you should take heed not to call rest() multiple times

ok! i'll try that, tysm!

from your output, it seems like the server's nextAvailableTime is not being updated correctly with restTime because 10 is being served immediately after 9 is done (lines 33-34) and also because 12 doesn't get served until line 47 although server 2 is already done in line 39 of your output. or it could also be that the time you're checking against in isAvailable method for the server is mismatched.

from your output, it seems like the server's nextAvailableTime is not being updated correctly with restTime because 10 is being served immediately after 9 is done (lines 33-34) and also because 12 doesn't get served until line 47 although server 2 is already done in line 39 of your output. or it could also be that the time you're checking against in isAvailable method for the server is mismatched.
since you pass the public test cases, you might wanna consider crafting your own test case and use print statements to trace where the error is. personally I didn't create an additional attribute but hope this helps :)

tyyy berry!!! i got it alr!

hi can i ask how you managed to resolve this issue i also am stuck here with the exact same errors

hi can i ask how you managed to resolve this issue i also am stuck here with the exact same errors

hii! I followed what zuoshihua commented above! I removed my doneTime attribute and wrote a rest() method in Server. the server will rest when next() is called on Done event. hope this helps!

You may not need a doneTime attribute in Server, since when you instantiate a Done event, you call the constructor with the time done. Only when

a Done event is retrieved from the priority queue
its next() method is called

Then should the rest() method be called on the server

May I ask why can't next available time of server be updated together with the rest time all inside Serve? Cuz I did that and have the same test case failure as op

The server has to be dequeued when it is done serving not done resting. IMHO the easiest way is to dequeue the server in the Serve event and update the server's next available time in the Done event. Otherwise, your customer won't queue at a server when it is resting (although it is perfectly fine to do so)


Refactor URL builder

As discovered while trying to implement a new parameter, our URL building is not ideal. In this particular case, we URL-encode stuff twice: when we pass parameters to the builder and then in the builders themselves.
Most share pages use URL parameters, so wouldn't it be better for each social network to only define its main URL along with the needed parameters? Then, we can take the built-in URL and URLSearchParams to build the final URL.
A while ago, Dario did a similar thing, also adding a lot of other stuff. Since then, Shareon lost TypeScript, switched bundlers, heck, even the default branch is different. It might make more sense to re-implement this.
It is very important that the final size remains as small as possible, ideally under 1 kB for the ESM bundle. Use pnpm test to build and test for size. See also https://github.com/kytta/shareon/issues/62

An important note: This issue is blocked by pretty much every other issue. Using URL and URLSearchParams is a potentially breaking change, and I want to add support for as many new buttons as possible before finally releasing v3


Can't manage to use different version of NPM with specific Node versions

This is not an issue, more a request of clarification: is this possible with NVM? I want to match a different version of NPM for every Node version installed through NVM.
Thanks

It's possible with node and npm itself, by npm installing the version you want into each individual node version nvm manages.
It's not possible for nvm to switch npm versions, since the npm version exclusively follows the node install.
Duplicate of #964.


Update Buttons design doc to include guidance to designers about when to use buttons vs links

It is not always obvious when to use a Button vs a link. Ghost buttons, for example, and styled to look like links but should actually be used to represent actions. For accessibility considerations, it is important to differentiate links that use the  tag to navigate to a new page from actions that keep the user on the current page. Providing some examples of common use cases like buttons and actions in cards or toolbars would be helpful.
Current Button design doc here: https://github.com/patternfly/patternfly-design/blob/master/patternfly-4/components/button/design.md

From an implementation perspective, there is a difference in the html elements that would be used. A "link" is anything that navigates to a new url. The url could be a section on the current page, or a new page. Anything else is a button.
At our last a11y meeting, there was a general consensus that users should know when a clickable element is a navigation link or an action button, but I would be hesitant to make a statement that <a> elements must always look like links and <button> elements must always look like buttons.
There are many use cases when designers would swap the visual styles for the element being used. For example:

a link that displays in a toolbar along with other buttons (e.g. when the action to open a wizard is a full page wizard and not in a modal)
a link that is the main call to action on a web page
icons in the masthead could be a mix of buttons and links. Alternatively, the settings icon could be a link to a settings page in one product and a button that opens a modal in another product, depending on how complex the settings are.
a button that displays inline within a body of text (e.g. "Download product documentation for... ".

As part of this issue, it would be great to make sure these cases are considered.


fix: Move FoundationStreamBridge from Thread to GCD for stream callbacks

Issue #
https://github.com/awslabs/aws-sdk-swift/issues/1467
Description of changes
I discovered the CFWriteStreamSetDispatchQueue which configures a Foundation stream to deliver callbacks on a GCD dispatch queue instead of on a RunLoop.  This PR makes the switch, and eliminates the Thread and Runloop previously used for interacting with the stream.
Apple docs for perform(_:on:with:waitUntilDone:modes:) warn of incorrect behavior when performing on a different thread from a GCD queue:
https://developer.apple.com/documentation/objectivec/nsobject/1417922-perform#
Moving stream interactions to GCD should avoid this, and should also interact better with Swift concurrency.
Scope

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

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

LGTM pending CI passes


switch to entering gas price instead of total fee

people probably are more used to doing it that way.

reexamining issues I opened. this issue remains


🐛 frame.isMirrored is false with selfie camera on iOS

What's happening?
frame.isMirrored is false with selfie camera on iOS, while the image in the frame object is mirrored.
Reproduceable Code
const frameProcessor = useFrameProcessor((frame) => {
  'worklet'

  console.info(frame.isMirrored)

Relevant log output
.

Camera Device
{
  "minZoom": 1,
  "formats": [],
  "maxZoom": 121.875,
  "position": "back",
  "sensorOrientation": "portrait",
  "hasFlash": true,
  "name": "Back Camera",
  "minExposure": -8,
  "id": "com.apple.avfoundation.avcapturedevice.built-in_video:0",
  "hasTorch": true,
  "supportsRawCapture": false,
  "supportsFocus": true,
  "physicalDevices": [
    "wide-angle-camera"
  ],
  "neutralZoom": 1,
  "minFocusDistance": 15,
  "hardwareLevel": "full",
  "isMultiCam": false,
  "supportsLowLightBoost": false,
  "maxExposure": 8
}

Device
iPhone 13 (iOS 17.5)
VisionCamera Version
4.4.2
Can you reproduce this issue in the VisionCamera Example app?
Yes, I can reproduce the same issue in the Example app here
Additional information

[X] I am using Expo
[X] I have enabled Frame Processors (react-native-worklets-core)
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Oh, I forgot to add isMirrored on iOS. Fixed in https://github.com/mrousavy/react-native-vision-camera/pull/3078


changes made to the tailwind

I have fixed the issue that was occurring with the warn, it was that you haven't clearly defined as to where you wanted the tailwind to work.
This fixes #1

Solved in #5


Fix documentation favicon, avatar image and background pattern.

Fixes PR #49
Preview:

@josue the gh-pages branch is what GH pages uses to deploy the documentation and it's not meant to be committed to directly. The documentation is generated by Docsify and automated by GH actions when you merge into master.

@3p3r ahh, yikes!  😱 i missed that, thanks!

no worries, honestly the gh-pages branch needs to be reset from scratch. it contains so much unnecessary files. it's confusing. I'll make a ticket for myself to fix it soon.

I know this is closed but regarding the extra stuff in gh-pages the drone plugin force pushes everything - wiping out old files. I wouldn't be surprised if there was an option to do the same with the action I used. I'd start there.


Cannot change the .23 in loading.

Hello i've been using CircularProgressBar since last night, i've gotten it to say % but cannot get it to start from 0% to 20% without having this: 0.23% to 20.23%
I want to remove that ,23% from loading, but i do not know how. Could you help me please?

look at  Subscript and Superscript properties


Thanish's submission

5th XGB model. Code in XGB_sub_5.R and the predicted facies in XGB_predicted_facies_5.csv

Hey Thanish... that gets 0.514.


Milvus example

When checked out the project it failed to build. So I fixed it with the first commit (update import in the ChatWithDocumentsExamples class)

@IuriiKoval I have added example manually, thank you!


Create template for experimental results CSV

We will want to have our partners submit their experimental results in a set manner.
We propose a CSV file with the following fields:

Ligand Name
Affinity (nm)
Affinity Error (nm)
Annotation

Note 1: Affinity error should probably be set to something like -1 when unavailable.
Note 2: Annotation should be for things like "assay changed here" or ">1000", etc...

Is the plan to write this template into the docs, I imagine most will be using scripts to generate the data so an actual CSV with this header might not be super helpful?

Yeah, docs sound good - if we can get an example Zenodo submission with the csv that would be useful.


Derive Subcommands

Is their a plan to add subcommands to the derive macro?

I have thought about adding support for deriving the trait for enums, which would allow a limited form of subcommand parsing. The reason it hasn't been done is because there are some ambiguities to resolve between subcommands and positional arguments. Consider a naive example:
#[derive(Debug, OnlyArgs)]
struct Args {
    /// Some subcommand.
    sub: SubCommand,

    /// Put everything else into a vector.
    comment: Vec<String>,
}

#[derive(Debug, OnlyArgs)]
enum SubCommand {
    /// Addition.
    Add(i32, i32),

    /// Subtraction.
    Sub(i32, i32),
}

Passing "unknown" or "non-argument" strings to the CLI should push the strings to the comment field, and it currently doesn't matter where these positional arguments are placed:
$ ./cli this is a comment add 2 2
Args {
    sub: SubCommand::Add(2, 2),
    comment: ["this", "is", "a", "comment"],
}

$ ./cli add 1 3 this is also a comment
Args {
    sub: SubCommand::Add(1, 3),
    comment: ["this", "is", "also", "a", "comment"],
}

$ ./cli this will add the numbers add 2 2
Error: `add` expects `(i32, i32)`

Using a hand-written parser doesn't have this problem because the parsing rules are explicitly encoded in the [hand-written] trait implementation. The author decides how to resolve the ambiguity, possibly with a fallback mechanism to push unparseable strings into the comment field with back-tracking as necessary.
I don't think there is a good way to provide this kind of CLI with the macro because the "best" ambiguity resolution depends on what the application author wants. The most conservative solution is that the macro should just disallow ambiguous command lines by construction. For instance, declaring an enum and a Vec<T> (subcommand and position args) together in the same command line parser would be a compile error.
In short, it needs a good design to put this feature into the derive macro.

Yea I've had a think about how to solve the issue too.
FWIW Clap compiles fine, but complains at runtime about an unexpected argument:
use clap::Parser;

#[derive(clap::Parser, Debug, Clone)]
#[command(name = "test_cmd")]
pub struct Args {
    #[command(subcommand)]
    pub cmd: SubCommand,

    pub comment: Vec<String>,
}

#[derive(Clone, Debug, clap::Subcommand)]
#[command(about = "A subcommand")]
pub enum SubCommand {
    Add { opa: i32, opb: i32 },

    Sub { opa: i32, opb: i32 },
}

fn main() -> anyhow::Result<()> {
    let args = Args::parse();

    let result = match args.cmd {
        SubCommand::Add { opa, opb } => opa + opb,
        SubCommand::Sub { opa, opb } => opa - opb,
    };

    println!("result: {result}");
    println!("comment: {}", args.comment.join(", "));

    Ok(())
}

❯ cargo run --bin play -q -- sub 1 2 hello this is a comment
error: unexpected argument 'hello' found

Usage: play sub <OPA> <OPB>

There was a recent blog post about difficulties with subcommands in clap, which is relevant to this issue: https://gribnau.dev/posts/puzzle-sharing-declarative-args-between-top-level-and-subcommand/


Add HEYYEYAAEYAAAEYAEYAA by ProtoOfSnagem

Song Name
HEYYEYAAEYAAAEYAEYAA
Artist Name
ProtoOfSnagem
Source
Youtube
Youtube Link
https://youtu.be/ZZ5LpwO-An4?si=TarLYwn_xT4-RxvJ
Direct File Link
No response
Song ID
500
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 76634261
Downloaded: No

accept

accept
Vào Th 5, 19 thg 9, 2024 vào lúc 00:42 auto-nong[bot] <
@.***> đã viết:

Thanks for contributing!
Someone will soon review your request.
Here is the JSON result for the reviewer:
{
"name": "HEYYEYAAEYAAAEYAEYAA",
"artist": "ProtoOfSnagem",
"source": "youtube",
"startOffset": 0,
"yt-id": "ZZ5LpwO-An4",
"songs": [
500
]
}
To accept the request, a reviewer needs to write "accept".
—
Reply to this email directly, view it on GitHub
https://github.com/FlafyDev/auto-nong-indexes/issues/4170#issuecomment-2359060477,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5G4NFSWJ5U6GCVU6YF3ZCTZXG3P7AVCNFSM6AAAAABOOGTVN6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJZGA3DANBXG4
.
You are receiving this because you authored the thread.Message ID:
@.***>


Use npm version for version bumps

Found a bug whilst testing docs changes for:

https://github.com/alphagov/govuk-frontend/issues/3547

When bumping package versions we unintentionally leave package-lock.json and other workspaces behind
Using npm version
We should use npm version to bump our package version:
npm version patch
npm version minor
npm version major
npm version 5.0.0

This lets npm keep package-lock.json and workspaces that install govuk-frontend in sync

Perhaps related to:

https://github.com/alphagov/govuk-frontend/issues/3526


Help Troubleshooting

Hello andreaskeller96! Thank you for sharing your project! I'm hoping you can help me with some troubleshooting...
I'm using:
Visual Studio 2022
Unity 2022.3.16f1
I've tried Unity 2021.3.18f1 to the same effect.
I'm running Visual Studio in ADMIN mode.
I printed the model you supplied and am using flat IR tape. The single change I made to the sample was to change the radius of the spheres to 0. I've also modified the manifest according to @petergu684 's HoloLens2-ResearchMode-Unity - but alas not luck!
I would be very grateful for any help you can provide :)

BuildOutput_HL2IRToolTrackingSample.txt

From the log you provided, it all looks correct. Only thing i could possibly see happening is that the tape is not reflective enough, but that is a long shot. Try placing the marker such that it faces the headset head on, at a distance of about arms length and see if detection works.
Other than that, all I can think of is double checking that the sample scene is setup correctly (you can even run it 100% normal, so with radius 6.5, it will only show tha tool 6.5mm offset from the actual position in that case).

Thank you for your reply! I rebuilt and this time made no modifications. I included the notes from releasing it in visual studio and debugging it.
Could the errors below be the source of the problem?
Debug_Notes_07_29.txt
ReleaseNotes_07_29.txt
[XR] [4888] [14:06:49.187][Info   ] Stage 1 Missing Entry Points: (1)
[XR] [4888] [14:06:49.190][Info   ]   xrInitializeLoaderKHR
[XR] [4888] [14:06:49.191][Info   ]
[XR] [4888] [14:06:49.191][Info   ] Stage 2 Missing Entry Points: (5)
[XR] [4888] [14:06:49.193][Info   ]   xrGetVisibilityMaskKHR
[XR] [4888] [14:06:49.193][Info   ]   xrGetD3D12GraphicsRequirementsKHR
[XR] [4888] [14:06:49.194][Info   ]   xrCreateFoveationProfileFB
[XR] [4888] [14:06:49.194][Info   ]   xrDestroyFoveationProfileFB
[XR] [4888] [14:06:49.195][Info   ]   xrUpdateSwapchainFB
[XR] [4888] [14:06:49.203][Info   ] Requested feature extensions not supported by runtime: (3)
[XR] [4888] [14:06:49.203][Info   ]   XR_MSFT_spatial_anchor_export_preview: Feature="Mixed Reality Features": Version=1.5.1, Company="Microsoft"
[XR] [4888] [14:06:49.204][Info   ]   XR_MSFT_controller_model: Feature="Motion Controller Model": Version=1.5.1, Company="Microsoft"
[XR] [4888] [14:06:49.204][Info   ]   XR_FB_render_model: Feature="Motion Controller Model": Version=1.5.1, Company="Microsoft"

Your remark on the tape not being reflective enough stuck with me. I upgraded to ifm E21015 Reflective tape and it's now working as expected!
Thank you for your help :)

Great to hear! Thanks for posting the fix here too :)


libjuju version hardcoded to 2.9.9

Currently in requirements.txt 1, the libjuju version is hardcoded to 2.9.9. We could replace this with:
juju ~= 2.9

which would allow the snap to install the latest 2.9.x compatible version 2 (2.9.42 currently). This would allow the snap to receive the latest libjuju improvements and fixes.

Imported from Launchpad using lp2gh.

date created: 2023-06-13T13:50:57Z

owner: dashmage

assignee: None

the launchpad url

(by eric-chen)
The teams is working on compatible with juju 3.1. After that, this issue should be fixed. Therefore, I remove good-first-bug tag.

(by mertkirpici)
Since charm-juju-backup-all installs juju-backup-all through python package not snap, during dependency resolution process of the charm build, charm also ends up getting libjuju version 2.9.9. Marking this bug affects the charm project as well.

(by mertkirpici)
Since charm-juju-backup-all installs juju-backup-all through python package not snap, during dependency resolution process of the charm build, charm also ends up getting libjuju version 2.9.9. Marking this bug affects the charm project as well.

(by eric-chen)
The teams is working on compatible with juju 3.1. After that, this issue should be fixed. Therefore, I remove good-first-bug tag.


Fix a race in pkg/discovery/memory

- What I did
Fixed a race found in #22964
- How I did it
Introduced a mutex
- How to verify it
TESTDIRS=pkg/discovery/memory BUILDFLAGS=-race TESTFLAGS="-test.count 1000" make test-unit
Signed-off-by: Akihiro Suda<EMAIL_ADDRESS>

The failure in gccgo is unrelated to my change (known flaky test https://github.com/docker/docker/issues/22879)

LGTM :angel:
/cc @LK4D4 @runcom @icecrime @cpuguy83

LGTM


Lane polygons and other layers only show after unticking and reticking them

As illustrated in the GIF below.
Should they be unticked to start with? I guess not, the road polygons are IMO one of the most useful features.

OK it's more an issue with layer order. Will update the issue title accordingly.
Suggested fix: put the more interesting least intrusive layers on top by default meaning:

Lane markings
Lane polygons
Geometry
Then, finally, OSM

That's a logical starting order for me, otherwise the interesting geometries generated by osm2streets is obscured by the OSM geomtries that are already well-know.
Before:

After:

I'm misunderstanding how Leaflet chooses layer z-ordering. If you untick the "Imported area" group, it turns everything off. If you tick it again, it turns everything on, but following the order shown in the panel, and then it's correct. (OSM is on the lowest level, lane markings are on top).
I'll read a bit how it decides and try to fix this. Thanks for pointing it out!


Functions idea - "data_insights" function

While it's nice to have really simple functions - it might obscure some of the rationale of why we do functions in the beginning (when will you ever have a "times_2" function)
Could we start by showing some repetitive code, explaining that it's hard to maintain, and then how you could simplify it to have a really simple function that does something like
data_insights <- function(x) {
    x_insight <- x %>%
    filter(something) %>%
    group_by(something) %>%
    summarize(something)

    return(x_insight)
}

as the basis for this lecture?
Then we return to basics, followed by tibble examples, etc

even just adding this would be great!

showing real examples could be cool too from our work maybe?


Images and samplers inside structs

I have a simple shader that's not compiling and throwing this assert:
"Attempting to use arrays of separate images. This is not possible to statically remap to plain GLSL."
The shader isn't exactly using arrays of samplers but rather has defined a struct which contains both a sampler and an image. I understand the problem with separate samplers/images but I think in this case it should be trivial to do the remapping? If it was my code I could just modify it but we're using NVIDIA's public implementation of FXAA which uses this kind of pattern.
EDIT: I forgot to add that this hlsl is being fed into glslang, which then gets passed to SPIRV-Cross.
The shader is the following:
struct CombinedTexture
{
	SamplerState smpl;
	Texture2D tex;
};

CombinedTexture g_combinedTex;

float4 sampleTex(CombinedTexture combined, float2 coords)
{
	return combined.tex.Sample(combined.smpl, coords);
}

float4 main(float4 input : TEXCOORD0) : SV_Target0
{
	float4 color = sampleTex(g_combinedTex, input.xy);
	return color;
}

You'll probably need to call buildCombinedImageSamplers when emitting desktop GLSL. See the README . --vulkan-semantics might work, as it supports separate image samplers natively.
However, I'm not sure what kind of code-gen is generated here by glslang. I fear it's trying to emit a uniform struct with two members. I doubt that's legal SPIR-V ... It certainly won't work in SPIRV-Cross as is.

It's in the call to build_combined_image_samplers that this assert is triggered, I'm using the API and not the standalone provided by SPIRV-Cross, but I'll try turning on the vulkan semantics and see if that changes anything.
An alternative shader that also fails is one where we specify the image and sampler separately (so there are two uniforms as is the normal case), join them in the struct, and pass them to a function.
struct CombinedTexture
{
	SamplerState smpl;
	Texture2D tex;
};

Texture2D g_myTex;
SamplerState g_mySampler;

float4 sampleTex(CombinedTexture combined, float2 coords)
{
	return combined.tex.Sample(combined.smpl, coords);
}

float4 main(float4 input : TEXCOORD0) : SV_Target0
{
	CombinedTexture combinedTex;
	combinedTex.tex = g_myTex;
	combinedTex.smpl = g_mySampler;

	float4 color = sampleTex(combinedTex, input.xy);
	return color;
}

Weird stuff, never seen uniform structs with opaque types in them before ...
The codegen here by HLSL does not make much sense. If I understand the spec correctly, you cannot declare a uniform struct in SPIR-V (unless it's a block type like UBO/SSBO), and that's what the resulting SPIR-V is doing. Maybe HLSL allows it, and does code-gen on that without checking.
Unless proven otherwise, I believe this is a glslang bug.
I didn't consider the case where the type could be a struct, so that's probably why you're getting an error about "arrays" (which is another failure case that is relevant).

// Module Version 10000
// Generated by (magic number): 80001
// Id's are bound by 63

                              Capability Shader
               1:             ExtInstImport  "GLSL.std.450"
                              MemoryModel Logical GLSL450
                              EntryPoint Fragment 4  "main" 56 59
                              ExecutionMode 4 OriginUpperLeft
                              Source HLSL 500
                              Name 4  "main"
                              Name 9  "CombinedTexture"
                              MemberName 9(CombinedTexture) 0  "smpl"
                              MemberName 9(CombinedTexture) 1  "tex"
                              Name 17  "sampleTex(struct-CombinedTexture-p1-t211;vf2;"
                              Name 15  "combined"
                              Name 16  "coords"
                              Name 22  "@main(vf4;"
                              Name 21  "input"
                              Name 39  "color"
                              Name 40  "aggShadow"
                              Name 41  "smpl"
                              Name 44  "tex"
                              Name 47  "param"
                              Name 54  "input"
                              Name 56  "input"
                              Name 59  "@entryPointOutput"
                              Name 60  "param"
                              Decorate 41(smpl) DescriptorSet 0
                              Decorate 44(tex) DescriptorSet 0
                              Decorate 56(input) Location 0
                              Decorate 59(@entryPointOutput) Location 0
               2:             TypeVoid
               3:             TypeFunction 2
               6:             TypeSampler
               7:             TypeFloat 32
               8:             TypeImage 7(float) 2D sampled format:Unknown
9(CombinedTexture):             TypeStruct 6 8
              10:             TypePointer UniformConstant 9(CombinedTexture)
              11:             TypeVector 7(float) 2
              12:             TypePointer Function 11(fvec2)
              13:             TypeVector 7(float) 4
              14:             TypeFunction 13(fvec4) 10(ptr) 12(ptr)
              19:             TypePointer Function 13(fvec4)
              20:             TypeFunction 13(fvec4) 19(ptr)
              24:             TypeInt 32 1
              25:     24(int) Constant 1
              26:             TypePointer UniformConstant 8
              29:     24(int) Constant 0
              30:             TypePointer UniformConstant 6
              33:             TypeSampledImage 8
   40(aggShadow):     10(ptr) Variable UniformConstant
        41(smpl):     30(ptr) Variable UniformConstant
         44(tex):     26(ptr) Variable UniformConstant
              55:             TypePointer Input 13(fvec4)
       56(input):     55(ptr) Variable Input
              58:             TypePointer Output 13(fvec4)
59(@entryPointOutput):     58(ptr) Variable Output
         4(main):           2 Function None 3
               5:             Label
       54(input):     19(ptr) Variable Function
       60(param):     19(ptr) Variable Function
              57:   13(fvec4) Load 56(input)
                              Store 54(input) 57
              61:   13(fvec4) Load 54(input)
                              Store 60(param) 61
              62:   13(fvec4) FunctionCall 22(@main(vf4;) 60(param)
                              Store 59(@entryPointOutput) 62
                              Return
                              FunctionEnd
17(sampleTex(struct-CombinedTexture-p1-t211;vf2;):   13(fvec4) Function None 14
    15(combined):     10(ptr) FunctionParameter
      16(coords):     12(ptr) FunctionParameter
              18:             Label
              27:     26(ptr) AccessChain 15(combined) 25
              28:           8 Load 27
              31:     30(ptr) AccessChain 15(combined) 29
              32:           6 Load 31
              34:          33 SampledImage 28 32
              35:   11(fvec2) Load 16(coords)
              36:   13(fvec4) ImageSampleImplicitLod 34 35
                              ReturnValue 36
                              FunctionEnd
  22(@main(vf4;):   13(fvec4) Function None 20
       21(input):     19(ptr) FunctionParameter
              23:             Label
       39(color):     19(ptr) Variable Function
       47(param):     12(ptr) Variable Function
              42:           6 Load 41(smpl)
              43:     30(ptr) AccessChain 40(aggShadow) 29
                              Store 43 42
              45:           8 Load 44(tex)
              46:     26(ptr) AccessChain 40(aggShadow) 25
                              Store 46 45
              48:   13(fvec4) Load 21(input)
              49:   11(fvec2) VectorShuffle 48 48 0 1
                              Store 47(param) 49
              50:   13(fvec4) FunctionCall 17(sampleTex(struct-CombinedTexture-p1-t211;vf2;) 40(aggShadow) 47(param)
                              Store 39(color) 50
              51:   13(fvec4) Load 39(color)
                              ReturnValue 51
                              FunctionEnd

Is the SPIR-V.
              10:             TypePointer UniformConstant 9(CombinedTexture)
   40(aggShadow):     10(ptr) Variable UniformConstant

:(

I think I see what you mean. Let me take this to the glslang team.

Similar looking Vulkan GLSL fails with the similar snippet:
#version 450

layout(location = 0) out vec4 FragColor;

struct Combined
{
   sampler samp;
   texture2D tex;
};

layout(binding = 0) uniform sampler uSamp;
layout(binding = 1) uniform texture2D uTex;

vec4 samp(Combined combined)
{
   return texture(sampler2D(combined.tex, combined.samp), vec2(0.5));
}

void main()
{
   Combined c;
   c.samp = uSamp;
   c.tex = uTex;
   FragColor = samp(comb);
}

Warning, version 450 is not yet complete; most version-specific features are present, but some are missing.
ERROR: /tmp/test2.frag:21: 'structure' : non-uniform struct contains a sampler or image: c
ERROR: /tmp/test2.frag:21: '' : compilation terminated
ERROR: 2 compilation errors.  No code generated.

Thanks for the glsl example, I'll add this snippet onto the glslang bug as well.

Closing this as this isn't a SPIRV-Cross bug unless proven otherwise.


Update with the latest config-defaults

Pull in the real sharable config and update linting as needed. Again this may be better viewed with the whitespace flag off.

:+1:


Time typed custom field parses time differently on development and production

Bug report
Required System information

Node.js version: v16.18.1, Nixpacks v0.13.0 with nodejs-16_x on production side
NPM version: 8.19.2
Strapi version: 4.4.7
Database: Postgres
Operating system: Windows (also tried with MacOS), Linux on production side

Describe the bug
I've created a custom time typed field with the plugin generator.
When I save an entry which has this custom field, the time get parsed differently.
Example:
The input value is "13:00:00".
In development, this value parsed to "13:00:00.000".
In production, the value parsed to the same format as it was, "13:00:00".
This is a problem for me because I'm using a Combobox to select the values and the Combobox using the .find command to search for the currently selected value, and it compares the values in the Combobox list with the given value (which got parsed).
Steps to reproduce the behavior

Create a plugin, which will register a custom time typed field.
console.log the value in the custom field's admin UI element (to see how it gets parsed)
Create an entry.
Save the entry.

Expected behavior
The time field gets parsed in the same way both in development and production.
Screenshots
In both screenshots, the 1st row is printed when I select the value, and the 2nd row is printed when I save the entry.
Development:

Production (ignore the middle row):

Code snippets
My repository with the created plugin can be found here.

Transferring this issue over to the design system as I think it relates to the time option in the DS

Sorry for the late reply, this doesn't seem to have a minimal reproduction of the issue. We've also updated the Combobox in the design system from 1.7.2 onwards so that should hopefully improve your situation. We're currently working on converting the TimePicker to use a combobox, so in theory there won't be a need for said custom field.


Add angle brackets to surroundingPairs in Rust language-configuration.json

Feature description
Typing < wraps the selection into <> pair. This is useful when I want to write the turbofish or wrap the type inside Result/Option.

We usually avoid defining a pair for <> because of the ambiguity when using the < comparator, e.g. when typing code like a < 3 it might result in a < 3>.

Hi, my suggestion is about surroundingPairs which only applies when there is at least one non-whitespace character selected. If the  3 is not selected before typing <, the final result should still be a < 3. This behavior is already provided by rust-analyzer, but it is too heavy when the project is large and all I need is reading a single source file and possibly making some trivial changes.

To verify, open a rust file, make a selection and type <. The selection should be surrounded with <>.


Fix SEP-31 transfer_received_at calculation

PR Checklist
PR Structure

[x] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[x] This PR's title starts with name of package that is most changed in the PR, ex.
paymentservice.stellar, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[x] This PR adds tests for the most critical parts of the new functionality or fixes.

What
This PR implements the TODOs in PaymentOperationToEventListenerTest. As part of this, I found that the payment_received_at calculation in the JDBC SEP transaction was incorrectly calculated when the observed payment amount is lower than expected.
Why
Adding these tests back increases test coverage.
Known limitations
N/A

Reference Server Preview is available here:https://anchor-ref-pr939.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr939.previews.kube001.services.stellar-ops.com/

Something went wrong with PR preview build please check

Reference Server Preview is available here:https://anchor-ref-pr939.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr939.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr939.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr939.previews.kube001.services.stellar-ops.com/


Fix python_requires

Python 3.0 and 3.1 are not supported.
Also add 3.7 to classifiers.

Pull Request Test Coverage Report for Build 20

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.067%

Totals

Change from base Build 19:
0.0%

Covered Lines:
1168

Relevant Lines:
1179

💛  - Coveralls

Pull Request Test Coverage Report for Build 20

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.067%

Totals

Change from base Build 19:
0.0%

Covered Lines:
1168

Relevant Lines:
1179

💛  - Coveralls

Pull Request Test Coverage Report for Build 20

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.067%

Totals

Change from base Build 19:
0.0%

Covered Lines:
1168

Relevant Lines:
1179

💛  - Coveralls

@jaraco How does this look?

This looks good to me. Thanks for bringing it to my attention. Separately, we should probably drop support for Python 3.3 and maybe 3.4 also soon.

Hmm. Looks like the work was superseded by #45.

Oh, so it was! Thanks!


[NOJIRA] Fix Serializer and OutboundPacketTracker caps

OK, I've taken a look at the code outside of the PR and it all makes sense, but since it might take a while until this gets refactored, I'd try to make a step in the right direction by changing the module names. It doesn't seem to break much as the elements are mostly used via bins from the same package.
I'd suggest:

Serializer -> HeaderGenerator, (Header)MetadataGenerator or similar.
OutboundPacketTracker is more tricky, but my ideas are: (Outbound)TrackingSerializer or just OutboundSerializer

With that changes in place, I'll sleep better awaiting a rewrite of the outbound RTP pipeline :wink:

I've introduced requested changes but honestly speaking I would keep OutboundPacketTracker. It looks like it is able to generate some parts of the header too :exploding_head: and the previous name was symmetric to InboundPacketTracker. I made renamings in separate commits so we can revert the last one if you want to.


Added my part for madlib

Added my part. Can someone check for me?

Looks good! Merging your PR

Looks good.


Bug Report: 新版本Clang编译JoltPhysics库报错导致项目编译失败

Describe the bug | Bug描述
项目无法在最新的Clang和Xcode中编译通过。
Steps to reproduce | 如何复现
使用LLVM>=15或最新版Xcode，运行编译脚本即可观察到报错。
Expected behavior | 预期行为
第三方库JoltPhysics正常编译。
Actual behavior | 实际行为
编译JoltPhysics时产生大量报错导致编译失败。
Screenshots/Logs | 截图/日志
CompileC /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleCollisionTester.o /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleCollisionTester.cpp normal arm64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'Jolt' from project 'Piccolo')
    cd /Users/mlekow/Documents/repos/Piccolo
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -ivfsstatcache /var/folders/1w/x1psvkys0t3djz6hfk0217j40000gp/C/com.apple.DeveloperTools/14.3-14E222b/Xcode/SDKStatCaches.noindex/macosx13.3-22E245-.sdkstatcache -target arm64-apple-macos13.3 -fmessage-length\=193 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -Wno-implicit-fallthrough -DCMAKE_INTDIR\=\"Debug\" -D_DEBUG -DJPH_PROFILE_ENABLED -DJPH_DEBUG_RENDERER -DPICCOLO_VK_LAYER_PATH\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS -DPICCOLO_VK_ICD_FILENAMES\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS/MoltenVK_icd.json -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -g -Wno-sign-conversion -Wno-infinite-recursion -Wno-move -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-range-loop-analysis -Wno-semicolon-before-method-body -I/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug/include -I/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources-normal/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources -F/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug -std\=c++17 -I. -Wall -Werror -std\=gnu++17 -MMD -MT dependencies -MF /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleCollisionTester.d --serialize-diagnostics /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleCollisionTester.dia -c /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleCollisionTester.cpp -o /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleCollisionTester.o
In file included from /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleCollisionTester.cpp:6:
In file included from /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleCollisionTester.h:6:
In file included from /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Body/Body.h:8:
In file included from /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Collision/Shape/Shape.h:12:
/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Core/Result.h:153:73: error: unqualified call to 'std::move' [-Werror,-Wunqualified-std-cast-call]
        void                            SetError(string &&inError)                                      { Clear(); new (&mError) string(move(inError)); mState = EState::Error; }
                                                                                ^
                                                                                std::
In file included from /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleCollisionTester.cpp:12:
In file included from /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/PhysicsSystem.h:12:
In file included from /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/PhysicsUpdateContext.h:10:
/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Core/JobSystem.h:58:65: error: unqualified call to 'std::move' [-Werror,-Wunqualified-std-cast-call]
                inline                          JobHandle(JobHandle &&inHandle) noexcept        : Ref<Job>(move(inHandle)) { }
                                                                                ^
                                                                                std::
/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Core/JobSystem.h:65:89: error: unqualified call to 'std::move' [-Werror,-Wunqualified-std-cast-call]
                inline JobHandle &      operator = (JobHandle &&inHandle) noexcept      { Ref<Job>::operator = (move(inHandle)); return *this; }
                                                                                ^
                                                                                std::

CompileC /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleAntiRollBar.o /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleAntiRollBar.cpp normal arm64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'Jolt' from project 'Piccolo')
    cd /Users/mlekow/Documents/repos/Piccolo
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -ivfsstatcache /var/folders/1w/x1psvkys0t3djz6hfk0217j40000gp/C/com.apple.DeveloperTools/14.3-14E222b/Xcode/SDKStatCaches.noindex/macosx13.3-22E245-.sdkstatcache -target arm64-apple-macos13.3 -fmessage-length\=193 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -Wno-implicit-fallthrough -DCMAKE_INTDIR\=\"Debug\" -D_DEBUG -DJPH_PROFILE_ENABLED -DJPH_DEBUG_RENDERER -DPICCOLO_VK_LAYER_PATH\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS -DPICCOLO_VK_ICD_FILENAMES\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS/MoltenVK_icd.json -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -g -Wno-sign-conversion -Wno-infinite-recursion -Wno-move -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-range-loop-analysis -Wno-semicolon-before-method-body -I/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug/include -I/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources-normal/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources -F/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug -std\=c++17 -I. -Wall -Werror -std\=gnu++17 -MMD -MT dependencies -MF /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleAntiRollBar.d --serialize-diagnostics /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleAntiRollBar.dia -c /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleAntiRollBar.cpp -o /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleAntiRollBar.o

CompileC /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/Vec3.o /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Math/Vec3.cpp normal arm64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'Jolt' from project 'Piccolo')
    cd /Users/mlekow/Documents/repos/Piccolo
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -ivfsstatcache /var/folders/1w/x1psvkys0t3djz6hfk0217j40000gp/C/com.apple.DeveloperTools/14.3-14E222b/Xcode/SDKStatCaches.noindex/macosx13.3-22E245-.sdkstatcache -target arm64-apple-macos13.3 -fmessage-length\=193 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -Wno-implicit-fallthrough -DCMAKE_INTDIR\=\"Debug\" -D_DEBUG -DJPH_PROFILE_ENABLED -DJPH_DEBUG_RENDERER -DPICCOLO_VK_LAYER_PATH\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS -DPICCOLO_VK_ICD_FILENAMES\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS/MoltenVK_icd.json -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -g -Wno-sign-conversion -Wno-infinite-recursion -Wno-move -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-range-loop-analysis -Wno-semicolon-before-method-body -I/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug/include -I/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources-normal/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources -F/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug -std\=c++17 -I. -Wall -Werror -std\=gnu++17 -MMD -MT dependencies -MF /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/Vec3.d --serialize-diagnostics /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/Vec3.dia -c /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Math/Vec3.cpp -o /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/Vec3.o

CompileC /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/UVec4.o /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Math/UVec4.cpp normal arm64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'Jolt' from project 'Piccolo')
    cd /Users/mlekow/Documents/repos/Piccolo
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -ivfsstatcache /var/folders/1w/x1psvkys0t3djz6hfk0217j40000gp/C/com.apple.DeveloperTools/14.3-14E222b/Xcode/SDKStatCaches.noindex/macosx13.3-22E245-.sdkstatcache -target arm64-apple-macos13.3 -fmessage-length\=193 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -Wno-implicit-fallthrough -DCMAKE_INTDIR\=\"Debug\" -D_DEBUG -DJPH_PROFILE_ENABLED -DJPH_DEBUG_RENDERER -DPICCOLO_VK_LAYER_PATH\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS -DPICCOLO_VK_ICD_FILENAMES\=/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/VulkanSDK/bin/MacOS/MoltenVK_icd.json -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -g -Wno-sign-conversion -Wno-infinite-recursion -Wno-move -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-range-loop-analysis -Wno-semicolon-before-method-body -I/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug/include -I/Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources-normal/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources/arm64 -I/Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/DerivedSources -F/Users/mlekow/Documents/repos/Piccolo/build/engine/3rdparty/JoltPhysics/Build/Debug -std\=c++17 -I. -Wall -Werror -std\=gnu++17 -MMD -MT dependencies -MF /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/UVec4.d --serialize-diagnostics /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/UVec4.dia -c /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Math/UVec4.cpp -o /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/UVec4.o

note: Run script build phase 'Generate CMakeFiles/ALL_BUILD' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'ALL_BUILD' from project 'Piccolo')
note: Run script build phase 'CMake PostBuild Rules' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'PiccoloEditor' from project 'Piccolo')
note: Run script build phase 'Generate engine/CMakeFiles/PiccoloPreCompile' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'PiccoloPreCompile' from project 'Piccolo')
note: Run script build phase 'Generate CMakeFiles/ZERO_CHECK' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'ZERO_CHECK' from project 'Piccolo')
note: Run script build phase 'Generate engine/shader/CMakeFiles/PiccoloShaderCompile' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'PiccoloShaderCompile' from project 'Piccolo')
note: Run script build phase 'CMake PostBuild Rules' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'PiccoloParser' from project 'Piccolo')
** BUILD FAILED **

The following build commands failed:
	CompileC /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/Wheel.o /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/Wheel.cpp normal arm64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'Jolt' from project 'Piccolo')
	CompileC /Users/mlekow/Documents/repos/Piccolo/build/build/Jolt.build/Debug/Objects-normal/arm64/VehicleController.o /Users/mlekow/Documents/repos/Piccolo/engine/3rdparty/JoltPhysics/Jolt/Physics/Vehicle/VehicleController.cpp normal arm64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'Jolt' from project 'Piccolo')
(2 failures)

Desktop | 桌面环境

OS: macOS
Version: Ventura 13.3.1 (a) (22E772610a)
CPU: Apple M1 Pro
GPU: Apple M1 Pro
Memory: 32 GB
Compiler: AppleClang 14.0.3 (Xcode 14.3)

Additional context | 补充信息
问题看起来与未做限定的move操作有关。

该问题与 https://github.com/BoomingTech/Piccolo/issues/390 相似.

#449 给Clang编译器加了一个屏蔽警告的选项，目前测试可以编译通过了。


Get AccessToken during auth flow

Description
Added code to query twitter for user AccessToken so that user based twitter queries will be authorized.
Changelog

Add TwitterSession for storage of AccessToken
Add request to Twitter to receive AccessToken from oauth_verifier

Addresses Issues
#49

Looks good to me.


[6.x] Add checkout feature and promote chain operation for session

Hi, I'm here to submit PR again. Although, previous submissions were rejected.
But I still love laravel. If you read my instructions carefully this time and choose to reject it, I hope you can give me some more tips, not just:  I think it's OK for now.
New Feature
During SSO (single sign on), session switching is usually used to prevent the current session from polluting the main session.
Client -> passport.domain.com -> master session （*.domain.com) -> current session (a.domain.com | b.domain.com)

Switch from the current session to the master session

$session = $request->session();

$id = $session->get('master_session_id');

$session->checkout($id, false);

// Enter the main session domain

Switch from the master  session to the current session

$session = $request->session();

$id = $request->cookies->get($session->getName());

// If the same, a new session should be created
if ($id === $session->getId()) {
    $id = null;
}

$session->checkout($id);

Chain
Most methods of illuminate\session\store object return void, which makes chain operation complicated.

Resolve #1952

There are several breaking changes here so this is best to be sent to master instead.


Update copyright year.

Thank you for the time you are putting into AlaSQL!

Codecov Report

Merging #995 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #995   +/-   ##
========================================
  Coverage    67.26%   67.26%
========================================
  Files            1        1
  Lines        10495    10495
  Branches      3136     3136
========================================
  Hits          7059     7059
  Misses        3436     3436

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 f61e78d...44ac1af. Read the comment docs.

Thank you!


Update Tutorials Page

Only two sections now:

"Try these first!"
"Other Tutorials"

Remove the recipes section (since it is now in the header).

Updated some images

CSS Patch to make it so images on docs are max-width 800

Remove some custom hack on the tutorial images

Adds the new Grafana tutorial

I plan to make another iteration to change the card style on the tutorials for something that takes up a bit less space.


Backup Requests With Cross-Server Cancellation (Feature Request)

https://youtu.be/1-3Ahy7Fxsc?t=1207
Backup requests are the idea of sending requests out to multiple replicas, but in a particular way. Here’s the example for a read operation for a distributed file system client:
send request to first replica
wait 2 ms, and send to second replica
servers cancel request on other replica when starting read
A request could wait in a queue stuck behind an expensive query or a packet could be dropped, so if a reply is not returned quickly other replicas are tried. Responses come back faster if requests sit in multiple queues.
Cancellation reduces the frequency at which redundant work occurs.
You might think this is just a lot of extra traffic, but remember, the goal is to squeeze down the 99th percentile distribution, so the backup requests, even with what seems like a long wait time really bring down the tail latency and standard deviation. Requests in the 99th percentile take so long that the wait time is short in comparison.
Bigtable, for example, used backup requests after two milliseconds, which dramatically dropped the 99th percentile by 43 percent on an idle system. With a loaded system the reduction was 38 percent with only one percent extra disk seeks. Backups requests with cancellations gives the same distribution as an unloaded cluster.
With these latency tolerance techniques you are taking a loaded cluster with high variability and making it perform like an unloaded cluster.
Source: http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html

I will file under envoy, thanks

Can you link the related issue(s) you created?

https://github.com/envoyproxy/envoy/issues/2784


bytes slice with size > 512 KB

writing a bytes slice with size > 512 KB to a buffer using buffer.Write() does not properly copy it. If you write it by chunks of 512 KB, the slice is correctly copied.
bytes.NewBuffer(b) - this works as workaround

I cannot reproduce it anymore (many things have changed since then).
But I'd prefer to still keep it as it is now
buf := bytes.NewBuffer(b)

instead of
buf := &bytes.Buffer{}
buf.Write(b)

closing


Add notification in SDK for uploaded files

When you upload a file via URL on the frontend you have to manually call your backend if you want to react there to this event.
We could have a hook/callback in the SDK that automatically creates these sandbox-related notifications.
This hook could be either an instance or class method:

As instance method — requiring you to have a sandbox connection:

sandbox.filesystem.onFileUpload((path) => {})

This could be implemented via watchDir functionality relatively easily.

As a class method — this would allow you to have the hook without a sandbox connection:

Sandbox.onFileUpload(sandboxID, (path) => {})

Implementing this is noticeably harder — it would require us to have a notification system/infra and changes to the envd to allow forwarding events to this system.

The current solution is for example to call the server from the frontend after POSTing to the fileURL, or POSTing to the server and calling sandbox.uploadFile from there.

@ValentaTomas I would like to work on this issue.
Can you assign me?

Duplicate of https://github.com/e2b-dev/E2B/issues/291


Error configuring script

Hi, I'm following the instructions in README to configure the script.
Am successfully generating Withings token and providing back to the script when prompted. Error as follows:
docker run -v $HOME:/root --interactive --tty --name withings ghcr.io/jaroslawhartman/withings-sync:master --garmin-username=<USERNAME> --garmin-password=<PASS>

2023-01-05 01:29:49,878 - withings - ERROR - Can't read config file /root/.withings_user.json
2023-01-05 01:29:49,878 - withings - WARNING - User interaction needed to get Authentification Code from Withings!
2023-01-05 01:29:49,878 - withings - WARNING -
2023-01-05 01:29:49,878 - withings - WARNING - Open the following URL in your web browser and copy back the token. You will have *30 seconds* before the token expires. HURRY UP!
2023-01-05 01:29:49,878 - withings - WARNING - (This is one-time activity)
2023-01-05 01:29:49,878 - withings - WARNING -
2023-01-05 01:29:49,878 - withings - INFO - https://account.withings.com/oauth2_user/authorize2?response_type=code&client_id=183e03e1f363110b3551f96765c98c10e8f1aa647a37067a1cb64bbbaf491626&state=OK&scope=user.metrics&redirect_uri=https://jaroslawhartman.github.io/withings-sync/contrib/withings.html&
2023-01-05 01:29:49,878 - withings - INFO -
Token : <TOKEN>
2023-01-05 01:30:26,885 - withings - INFO - Get Access Token
2023-01-05 01:30:28,411 - withings - ERROR - Received error code: 503
2023-01-05 01:30:28,411 - withings - ERROR - Check here for an interpretation of this error: http://developer.withings.com/api-reference#section/Response-status
2023-01-05 01:30:28,411 - withings - ERROR -
2023-01-05 01:30:28,411 - withings - ERROR - If it's regarding an invalid code, try to start the script again to obtain a new link.
2023-01-05 01:30:28,411 - withings - INFO - Refresh Access Token
2023-01-05 01:30:29,273 - withings - ERROR - Received error code: 503
2023-01-05 01:30:29,273 - withings - ERROR - Check here for an interpretation of this error: http://developer.withings.com/api-reference#section/Response-status
2023-01-05 01:30:29,273 - withings - ERROR -
2023-01-05 01:30:29,273 - withings - ERROR - If it's regarding an invalid code, try to start the script again to obtain a new link.
Traceback (most recent call last):
  File "/usr/local/bin/withings-sync", line 33, in <module>
    sys.exit(load_entry_point('withings-sync==3.5.1', 'console_scripts', 'withings-sync')())
  File "/usr/local/lib/python3.10/site-packages/withings_sync-3.5.1-py3.10.egg/withings_sync/sync.py", line 396, in main
    sync()
  File "/usr/local/lib/python3.10/site-packages/withings_sync-3.5.1-py3.10.egg/withings_sync/sync.py", line 323, in sync
    withings = WithingsAccount()
  File "/usr/local/lib/python3.10/site-packages/withings_sync-3.5.1-py3.10.egg/withings_sync/withings2.py", line 189, in __init__
    self.withings = WithingsOAuth2()
  File "/usr/local/lib/python3.10/site-packages/withings_sync-3.5.1-py3.10.egg/withings_sync/withings2.py", line 73, in __init__
    self.refresh_accesstoken()
  File "/usr/local/lib/python3.10/site-packages/withings_sync-3.5.1-py3.10.egg/withings_sync/withings2.py", line 180, in refresh_accesstoken
    self.user_config["access_token"] = body.get("access_token")
AttributeError: 'NoneType' object has no attribute 'get'

Any guidance appreciated please!

I updated to 3.5.1 (just published) and am getting the same 503 error. The only difference is that I already have the generated .withings_user.json config file on my system and do not see the first few errors and warnings you get (under the 2023-01-05 01:29:49,878  timecode).

Note: file /root/.withings_user.json is not created during script execution.

Note: file /root/.withings_user.json is not created during script execution.

That file was generated for me when I followed the README and ran withings-sync -f 2019-01-25 -v, but that was using the previous version I installed via pip.

I am having the code 503 error too
After several minutes I get a message in the terminal ending with this :
self.user_config["access_token"] = body.get("access_token")
AttributeError: 'NoneType' object has no attribute 'get'

Hello,
Any news on that issue?
I just made a fresh install today and get the exact same error code 503.

Same error here.
Runs on a python 3.9.2 with latest withings-sync 3.6.1 on debian11 in a venv.
(Runs fine on windows 10 with python 3.8.2 also with lateset v3.6.1)
Any news or help?

I've been experiencing the same issue.  Nothing I have tired has made a difference.  Everything up to current version.
Any suggestions please?

Fixed my issue by replacing the $HOME env value with a name for the volume.  I used 'withings'.  It created the volume as expected and wrote the withings_user.json file to it.  I'm no Docker expert and don't know why the original stopped working, but hope this may help someone.

seems like setting a valid $HOME resolved this issue. thanks for sharing!


Fix deterministic deployment for zksync

PR-Codex overview
The focus of this PR is to refactor the contract deployment process by adding support for deterministic deployments with custom salt values.
Detailed summary

Added support for deterministic contract deployments with custom salt values
Refactored contract deployment logic based on data.deployDeterministic flag
Updated the contract deployment process to include the custom salt value for Create2 deployments

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#2609  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @kumaryash90 and the rest of your teammates on  Graphite


Revert merging develop for bionic/stretch fixes

This reverts commit 4afc7b55b5a8549902bedecdcc3cc7fbd828e06d, reversing
changes made to 409d605d92fe037a976e481abed503d4e9844045.

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!approved-for-mainnet


duplicate entities which can't be removed

Somehow, since the last update I have duplicate entities which cant be removed

Funny thing they are not in any of the .storage files

That's an issue related to the newly introduced UI based configuration and there is no workaround for it, I'm sorry.
Breaking changes with Lightener v2
Configuring Lightener lights in configuration.yaml is still possible but it is not anymore the best way for it. The proper way to do so now is through the UI in the Integrations page. Just click in "Add integration" and search for "Lightener".
Solution
Lighteners from configuration.yaml now don't have a unique_id and therefore HA created a new entity for them. The old lights (the ones not ending with "_2") should be "deletable" and (maybe) HA will create them again after restarting (I didn't try this, so let us know!)
The ideal solution instead is starting from scratch, which means deleting all the entries from configuration.yaml and recreating them thought the UI in the Integrations page. You'll be able to assign them the same entity_id you had before so any existing automation will continue to work.
Let us know if this works for you. Thanks!

I've amended the release description, pointing to this issue as a reference for migration problems.
Apart from the issue described here, there should be no other problems and Lightener should work just like before, just with a much nicer way to configure it (and several minor fixes and improvements as well).
This is probably be the only big breaking release of Lightener but it was necessary so we could bring it to its next level in terms of seemingless integration with HA. Again, I'm sorry for the troubles during the migration.

After I removed the integration and added it again, the duplicates are gone. 👍
(For a system where you play around a lot I like YAML more, but for "the general public" config via the interface is probably the nicer way)

@martinhoess, thanks for letting us know. In fact, removing and re-installing the integration is even a better option.

(For a system where you play around a lot I like YAML more, but for "the general public" config via the interface is probably the nicer way)

The biggest advantage with the UI options is that there is no need to restart HA when creating or changing configurations. But yes, YAML rules and fits the bill as well ;)


You can't use onMount on computed

Found by @dkzlv
Repro: https://codesandbox.io/s/compassionate-bohr-e4bpx?file=/src/App.js
Expected:
The callback returned from onMount shouldn't be called. Because we always stay subscribed
Harsh reality:
The callback returned from onMount is called.
Explanation:
When we return store from computed we do destructuring of the internal derived store. Thus returning the initial lc: 0 and we never update it. All subscriptions change lc of the internal derived.
Thus onMount think that we have no listeners and calls "unmount code"
Possible Fix:
The simplest fix is to return the same store:
derived.deps = deps
return derived

instead of
return {
  deps,
  ...derived
}

If we can't do this for some security reasons or anything. We should highjack the derived listen method

Can you send PR with possible fix?
Looks it will fix the problem.
cc @Eddort

Fixed https://github.com/nanostores/nanostores/commit/b76e07a4d2ddfd8f8245373746a7bf24ab6d8fe9

Thanks!