Smart Editor - Smartform Hide error with "contains" parameter

When creating expression which hides a field based on a CONTAINS parameter in another field, the field will disappear and will not reappear even when the value is changed back.  For example:
OutageDetail - Isolated Customers
HIDE "Account Number" if "Location Description" CONTAINS "gar"
The field, "Account Number" will disappear regardless of the input value for "Location Description".  The Field will also permanently disappear even when the input value is changed/refreshed.
Please see smart editor test_1 in Solutions DEV Ext to access these pre settings and data.

@MikeMillerGIS.

found the issue and will be resolved in next AGO release, thanks!


Reproducing paper's PPO results

Adds two scripts for reproducing the results of the paper with PPO. Needed to add one parameter that is forwarded to OpenAI's PPO, and I'm also sneaking a variable rename in here as the original seed name is wrong and majorly confused me at first.

Sorry for not merging earlier. Now it became a mess with a merge & missing CLA, so we'll merge this change internally and push it with the next update.
I'll close this PR
Thanks for the additions!


[Oracle][ODBC]Invalid SQL data type <-25>

I'm seeing the below error when trying to query one of our Oracle databases
Error: ODBC error
state: HY004
native error code: 0
message: [Oracle][ODBC]Invalid SQL data type <-25>.

Will try to narrow down the culprit when I can find the time to dig into it...

Same issue as the others with Oracle. Is there anything I can do to help find a workaround? Unfortunately, I am not an ODBC expert (yet)

We are using turbodbc heavily in our project and adding support for Decimal will help us a lot. Is there something in pipeline to add support for Decimal datatype.

Is there a way this issue can be bumped in priority ... seems like many are affected!
+1 to the list of affected users ....
Thanks!

Hi guys! Currently, my time for working on turbodbc is very limited, unfortunately. Even more unfortunately, this will not change in the near future. The best way to bump this issue in priority is to get active yourself, dig into the code base and provide a pull request.
If adding support for arbitrary decimal types sounds like too much, you could add optional support for using 32-bit integer types instead of 64-bit integer types. That should be easier and should help if your numbers stay below 4 billions / DECIMAL(8, 0).
Also, it would help if someone hosted a very small Oracle database that one could use for continuous integration.


Display CSS selector in pa11ycrawler output

This will require migrating to the latest JSON reporter for pa11y

Fixed in #38


CompletableFuture.join hangs if connection to server fails

Hitting a retrofit endpoint that returns a CompletableFuture and calling join will block forever if the connection to server fails (invalid URL, server not running, etc). There's an exception thrown in the OkHttp Dispatcher thread, but it's not properly caught by the call handler for CompletableFuture.
Repro at https://github.com/palantir/http-remoting/pull/503

@j-baker

Yep, I've been talking to Beck about this. See my PR to fix this.


Persist objects created in the local-scope (single docker host)

We need to persist the networks/service configuration data for local-scoped drivers.
This allows created networks and services to persist across reboots

Network and endpoint are now persisted for local-scoped drivers.


Suggestion: use yield.sent instead of function.sent

It IMHO explains itself a little better, and it looks more generator specific than function.sent (which looks like it would belong in any function, not just any generator).

All names of yield.xxx suffer from the issues:

yield.xxx and (yield).xxx have different semantics in generators.
yield.xxx have different semantics in generators (meta property) and non-strict non-generator codes (normal property).
yield.xxx and yield xxx looks close if the font of . is too inconspicuous 😂
yield.xxx and yield*xxx looks close if the font of . is too conspicuous 🤣
yield.xxx implies something caused by yield but actually the main reason of this proposal is about the first sent value before any yield (or without any yield).

I feel no any single issue is fatal, but there are too many potential ambiguity so maybe we should first consider alternatives of function.xxx instead of yield.xxx.

I don't think we have to worry about the font; anything can be unreadable with the wrong font.
Adding parens to things causes different semantics all over the place; i don't think that's a concern either - similarly, yield has a different semantic in generators vs non generators, so that's also not a concern.
However, your last point is compelling; it'd be great to find another alternative.

Adding parens to things causes different semantics all over the place

@ljharb  Could you explain more about that? I don't know other case which have different semantics between identifier.xxx with (identifier).xxx

it'd be great to find another alternative

Do you have any options? 😀

(a?.b).c vs a?.b.c
a, b.c vs (a, b).c
a + b + c vs (a + b) + c vs a + (b + c) when all three are different types
etc

No suggestions yet.

@ljharb What I mean is member access (or similar, like metaproperty) chaining 😅

a, b.c vs (a, b).c
a + b + c vs (a + b) + c vs a + (b + c)

So I don't think these two cases are comparable to yield.xxx vs (yield).xxx at all.

(a?.b).c vs a?.b.c

Actually this case seems weird at first glance, and there were several issues and discussions about that. IMO yield.xxx vs (yield).xxx is even worse because: it seems no real use case of (a?.b).c, but (yield).xxx in generator has valid use cases.

I have some thought about the name.
The real meaning of function.sent in a generator function is "the value sent by the last next() call to a generator object which created by this generator function". The problem is, strictly speaking, the value is sent to "generator object" not "generator function", so function.sent sounds more like "a function instance sent to somewhere".
I feel if we use function.xxx it should sound like "the value that generator function got".
Here are the names go to my mind:

function.got
function.input
function.lastValue
function.currentValue
function.receivedValue
var.received (while var seems have no relationship with generator, it could be understand as a special variable in the generator function)

@hax What about function.received?

@isiahmeadows Oh, I forgot to add it. Added now.
Currently I slightly prefer function.got or function.input because they are shorter 😛.
I also slightly worry about function.received could be considered to be a boolean.
What do you think of these names?

I remain concerned about using function for something that doesn't apply to all functions :-/

maybe function*.sent would work though (swap out "sent" for whatever the bikeshed produces)

Though function*.sent may work, it looks very unlike a "meta property", not sure how committee would accept it 😅 . And addition of * also make ergonomics a little bit worse (function is already long enough)

For me the best would be something able to retrieve every values sent though next (not only the first one)
keyWord may be any of: last, sent, received, input, ... => TO BE DEFINED
I agree with @ljharb , function.keyWord may be a little confusing. This specs only apply to generator functions intead of everyone.
(yield).keyWord => resolves first the yield, then go to the 'keyWord' property
yield.keyWord => returns the last value provided to next
I personally prefer yield.received as its for me the most explicit.

Note: function *f() { yield.received } throws an early error in Chrome, at least.
I do agree with @allenwb that yield.anything is not ideal, since it's a valid identifier anywhere else.

Note: function *f() { yield.received } throws an early error in Chrome, at least.
I do agree with @allenwb that yield.anything is not ideal, since it's a valid identifier anywhere else.

I'm not convinced that the fact yield is an identifier in sloppy mode is that compelling of a reason not to use it. It already has different meanings depending on context for tagged template literals (any others?):
yield `foobar`;

Although I do think the difference between (yield).blah vs yield.blah might be slightly confusing though given they can both occur in the same context. However I do feel like people wouldn't use (yield) as much with yield.blah available anyway.

I am considering maybe lastValue@yield could work 😂 though it still not solve:

yield.xxx (or xxx@yield)  implies something caused by yield but actually the main reason of this proposal is about the first sent value before any yield (or without any yield).

I strongly agree with yield.received

I strongly disagree with function.sent think something other would be better


Update python-app.yml to resolve build issue

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@c897937). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #50   +/-   ##
=======================================
  Coverage        ?   96.70%
=======================================
  Files           ?       24
  Lines           ?      334
  Branches        ?        0
=======================================
  Hits            ?      323
  Misses          ?       11
  Partials        ?        0

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 c897937...0955bd5. Read the comment docs.


Replace winston with console

Thanks for a great addition to dotenv. I ran into some trouble when using it though, and here's my proposal for a fix.
When using dotenv-extended with webpack, the compiler complains about dependencies as expressions in color.js which is used by winston and in winston itself:
WARNING in ./~/winston/lib/winston/transports.js
Critical dependencies:
23:17-34 the request of a dependency is an expression
 @ ./~/winston/lib/winston/transports.js 23:17-34

WARNING in ./~/winston/~/colors/lib/colors.js
Critical dependencies:
127:29-43 the request of a dependency is an expression
 @ ./~/winston/~/colors/lib/colors.js 127:29-43

WARNING in ./~/winston/~/colors/lib/extendStringPrototype.js
Critical dependencies:
106:31-45 the request of a dependency is an expression
 @ ./~/winston/~/colors/lib/extendStringPrototype.js 106:31-45

This is naturally an issue that needs to be addressed in winston and color.js, but since it seems a bit heavy to bring in winston as a logger only for one line of code, replacing winston with a plain old console.error in this project seems to me as a feasible solution.

Coverage remained the same at 100.0% when pulling 2c4a53bc453c6b0beac483d3e41d96bd2fda59f5 on Flexim:without-winston into 113ae82d2d06c99aab2e55f38ab6cb5f7c8f9c5f on keithmorris:develop.

Of course, now I realize that the errors came from me adding dotenv-extended to the webpack bundle, which is completely unnecessary. Removing it from the bundle resolved the issue.
Feel free to close this PR if you don't feel like slimming down the package by removing winston anyway.

Thanks @bostrom. I had a reason for using winston when I first wrote this due to something that I was planning to do. However, for the life of me I can't remember what it was. I definitely prefer the slimmed down version.


remove export before MONGO_URI in .env.example

Probably not a big deal but easy to miss when you just want to set up and run.

Absolutely, good catch!


EHOSTUNREACH from Docker container on Windows

I followed all the instructions as indicated on the README and DOCKER.md files.  My container starts up and clearly receives both configuration messages from the MBS SmartApp, as well as from the MQTT server.  However, it appears to attempt to change a device in Smartthings and get a bounceback due to EHOSTUNREACH:
2020-11-30 02:10:03 AM info: MQTT --> ST - Topic: [smartthings/Side Door/contact/cmd][closed] [Side Door][contact][closed]
2020-11-30 02:10:05 AM error: Error from SmartThings Hub: Error: connect EHOSTUNREACH <IP_ADDRESS>:39500
2020-11-30 02:10:05 AM error: {
"errno": -113,
"code": "EHOSTUNREACH",
"syscall": "connect",
"address": "<IP_ADDRESS>",
"port": 39500
}
2020-11-30 02:10:05 AM error: undefined

This set of messages happens once each time a device status is attempted to set on Smartthings hub (<IP_ADDRESS>).  I double-checked the firewall rule setup in Windows and even tried disabling the firewall completely.  This feels like a routing issue in Docker Desktop and WSL2, but you have instructions for using it this way so I'm not sure what is wrong.

I think I mention somewhere that if u r using docker, docker container  had it own virtual Mac and IP so u might need to play with that
Sent from my iPhone

On Nov 29, 2020, at 8:16 PM, robross0606<EMAIL_ADDRESS>wrote:

I followed all the instructions as indicated on the README and DOCKER.md files. My container starts up and clearly receives both configuration messages from the MBS SmartApp, as well as from the MQTT server. However, it appears to attempt to change a device in Smartthings and get a bounceback due to EHOSTUNREACH:
2020-11-30 02:10:05 AM error: Error from SmartThings Hub: Error: connect EHOSTUNREACH <IP_ADDRESS>:39500
2020-11-30 02:10:05 AM error: {
"errno": -113,
"code": "EHOSTUNREACH",
"syscall": "connect",
"address": "<IP_ADDRESS>",
"port": 39500
}
2020-11-30 02:10:05 AM error: undefined
This set of messages happens once for each device status it attempts to set on Smartthings hub (<IP_ADDRESS>). I double-checked the firewall rule setup in Windows and even tried disabling the firewall completely. This feels like a routing issue in Docker Desktop and WSL2, but you have instructions for using it this way so I'm not sure what is wrong.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I can't find where you mention that.  If you happen to find the URL, I really appreciate it.


Better form of choosing between accounts.

Something like this will help us with multiple accounts. Just change one line of code can choose between accounts instead of 3 now.
"
<AuthType: Google/Ptc
<PtcPassword:
<PtcUsername:
<GoogleUsername:
<GooglePassword:
"

Is this not a legit feature?

The second half wasn't there when I closed the issue

wouldn't separate auth files be better ?
The auth file will only contain:

auth_type
user
password
gmapkey
location (maybe?)

He's got this off another bot? I have the other bot he took this from :/

Rename your config.json to namebot.json
then use
python pokecli.py -cf ./configs/namebot.json
and you can run all of your bots

You're going to have issues, syncing the detail in them without making changes to both every time a change is made, or regularly doing a diff. I think this request is a valid one, whether someone takes it on is a different story

Yes, I saw this from another bot and saw it has some good point.
I could use separate files. Not of high priority.

I like what you did to separate auth and config.


Allow for contentType="oneTimeCode" input / paste

contentType="oneTimeCode" acts like a paste action in react native
fixes issue:
https://github.com/ttdung11t2/react-native-confirmation-code-input/issues/52

@export-mike
You can use a fork without this problem
https://github.com/retyui/react-native-confirmation-code-field

merging seems blocked atm?

what's the status on this?

what's the status on this?

The code export-mike provided didn't work properly for me. his code is not compatible with the way ios apply the code in the SMS to the textInput.
You can find the working code here.


Most tutorial links on website are broken

Go here: https://turing.ml/v0.22/tutorials/ and click any of the sidebar links (except linear regression which works) and you'll get routed back to the main page.

This is the old webpage (AFAIK nobody has access to) which also only contains old and outdated docs and tutorials. The Turing docs and tutorials are hosted at turinglang.org nowadays.

Oh, that's good to know! I don't suppose there's any way to have turing.ml point to turinglang.org (really, no one has access to that site?) If you google "turing julia" you get turing.ml so I imagine many people will end up there :\

Agreed. turing.ml is the first result for me and turinglang.org is the last on the first page. Most people are going to land on the old site to find outdated information,  and many will think its an abandoned or poorly maintained project. A redirect would be good if possible.

AFAIK unfortunately really nobody has access to the old turing.ml domain which means it's impossible to add a redirect.

Wait, how did we lose the domain?

I have no idea :shrug:

I did a little digging -- Freenom was sued by Meta a little bit ago. They suspended new domain signups and may be difficult to reach for the forseeable future.
Additionally, it looks like the .ml TLDs are kind of a mess anyway, since they're the Mali TLD and Mali decided to give them out for free?
Perhaps we can find a way to get GitHub to stop serving the files to them. Or are the files cached at the provider somewhere?

Some links are broken on the current website too. For example, in the Guide page, the link to the API is https://turinglang.org/v0.28/docs/using-turing/guide/%7B%7Bsite.baseurl%7D%7D/docs/library. It seems like {{site.baseurl}} was escaped to %7B%7Bsite.baseurl%7D%7D.

It was registered with https://www.freenom.com/en/index.html?lang=en. The freenom service stopped functioning a few months ago. Their customer service is not responding to requests. If anyone has a way to claim the domain back, let me know.

Have you tried contacting Google to have it removed? It should be possible to take it down, since it's a copyright violation for Freenom to keep the website up after you asked them to take it down.

The page seems to be served by cloudflare (nameservers audrey.ns.cloudflare.com and wilson.ns.cloudflare.com according to a lookup), maybe the old content is just cached there and there's no intentional copyright violation (the purpose of which I wouldn't understand anyway)?

I did a bit of digging as I was curious about this... it seems that Freenom lost management rights to the .ml and .ga ccTLDs around the time this issue was raised. Now, .ml is administered by the Malian government via their ICT agency AGETIC. There are some contact details for the .ml ccTLD found on the IANA Delegation Record and the NIC itself. Not sure if you'd have any lucky if you tried to reach out to them directly, @yebai.

I submitted a report to Google here: https://search.google.com/search-console/report-spam
I expect it will be ignored, but maybe if we're very lucky they'll de-list it.


Enabling different types of encryption for s3 dataset types.

Description
As an engineer I would like to be able to change the means of encryption on s3 datasets in order to save files on s3 in accordance with client information security requirements.
Context
When saving files to s3, some organisation require certain types of server-side encryption, namely amazon's Key Management System (KMS). As it is not easy to enable this in the s3 datasets, users are need to subclass the datasets.
Possible Implementation
Allow users to access the S3FileSystem on class instantiation, specifically, something to the tune of:
def init(credentials, s3fs_args, ...):
    _s3 = S3FileSystem(client_kwargs=_credentials, **s3fs_args)
   ...

Possible Alternatives
A singleton pattern to allow users to access the s3FileSystem object and set defaults prior to instantiation of the catalog.

As discussed on Slack, this is already work in progress. Will update this issue with the relevant commit when it's merged.

Yep no worries. Just thought I'd log here to follow the process.

Thanks for logging this @williamashfordQB, it's been addressed in https://github.com/quantumblacklabs/kedro/commit/f4f66f70beab6c04e087e4aaf6acec69d8181d34 and available in 0.15.5 🎉
I'm going to go ahead and close this issue. :)


Checking Pushpin with PVS-Studio static analyzer

Hello,
I have found some weaknesses and bugs using PVS-Studio tool. PVS-Studio is a static code analyzer for C, C++ and C#: https://www.viva64.com/en/pvs-studio/
Analyzer warnings:

V509 The 'new' operator should be located inside the try..catch block, as it could potentially generate an exception. Raising exception inside the destructor is illegal. src/proxy/websocketoverhttp.cpp 929

V595 (CWE-476) V595 The 'inRequest' pointer was utilized before it was verified against nullptr. Check lines: 452, 475. src/proxy/proxysession.cpp 452

In addition, I suggest having a look at the emails, sent from @pvs-studio.com.
Best regards,
Phillip Khandeliants

First issue: We don't explicitly use exceptions anywhere, and allocation failures should cause the program to abort anyway, so for now we don't consider this to be a real problem.
Second issue: Fixed.


As a sound engineer, I want to find audio cues for punching, coin collection, and coin depositing so that players will have audio-visual feedback

If you have a chance Thomas, find a few free audio cues for these noises and add them to the repo. One of the engineers will put them in.

Issue, .wav formatting isn't an acceptable file type for github, so I put them in a google drive, let me know if you cant access it.
https://drive.google.com/a/utexas.edu/folderview?id=0B8hZ59gyr7UlOVZLQk1zODNuNFE&usp=sharing

That's very strange. GitHub should be file agnostic so it shouldn't matter
what kind of file you try and upload. We should take a look into this the
next time we meet up
On Tue, Sep 6, 2016 at 5:00 PM tsurles<EMAIL_ADDRESS>wrote:

Issue, .wav formatting isn't an acceptable file type for github, so I put
them in a google drive, let me know if you cant access it.
https://drive.google.com/a/utexas.edu/folderview?id=0B8hZ59gyr7UlOVZLQk1zODNuNFE&usp=sharing
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nanomachines/filibusters-game/issues/30#issuecomment-245109678,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFOrBiZWTYvcYZ32Xe0rRwdSE5vTzI-nks5qneJvgaJpZM4J1ff9
.


Where is the tech report？

To furhter describe the issue, the hyperlink on the tech report in the readme links directly back into the readme.

seems to be on arXiv: https://arxiv.org/pdf/2411.13802


Add an abstract class for single input operators to use code.

A new class, AbstractSingleInputOperator is added to use the code in open, close, and getNextTuple. Many operators can extend this class and only implement its own matching logic.

After adding comments, please go ahead to do the merge.

LGTM now.


A note and same repost note near one of each other

Hi,
I think if someone repost a note that I already saw in the same say, this repost note shouldn't appear in the feed. Look this example:

We plan to collapse all reposts into one (jack and 5 others reposted... thingy) to avoid multiple repeating posts in the feed. But it will not track if you have seen or not.

We plan to collapse all reposts into one (jack and 5 others reposted... thingy) to avoid multiple repeating posts in the feed. But it will not track if you have seen or not.

Great.


Helper to load modules or find symbols built-in

Consists of a function that checks if a symbol is built-in, if not, it tries
to load the corresponding module. A macro wraps said function to be able to
work when dynamic modules support is disabled.
With these and the required changes in the respective code, programs created
with the fbp-generator no longer need to explicitly link to the modules they
use, since Soletta will take care of loading them if required.

I like this patch overall and solves a long-standing problem... it's just what I imagined :-)
What I'm still unsure is the error handling an sol_symbol_get() signature. Maybe make it receive the pointer to store the symbol as parameter and return int err, then change all cases to SOL_INT_CHECK()... or since the call is actually a macro make it take a goto label and make the error handling always be a goto.


Kata-CC: Upgrade to 0.6.3

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Summary

Kata-CC: Upgrade to 0.6.3
Change Log

Kata-CC: Upgrade to 0.6.3. A more detailed description can be found in the release notes

Does this affect the toolchain?

NO
Test Methodology

Pipeline build id: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=480130&view=results

Why are we pushing this change through the fast-track process instead of a regular release?

Why are we pushing this change through the fast-track process instead of a regular release?

This is an MSRC issue and we're trying to get this in before its CVE is published

Auto cherry-pick results:

main :x:

Auto cherry-pick pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=487424&view=results


fix: waitForNavigation issue with aborted events

Fixes #9881, fixes #8383.
The issue seem to be that we don't listen to all the possible event for Request/Response so we never try to see if there are no requests.
@OrKoN Let's take a closer look together to see if there are other "unhappy" paths that need to handled.

Nice, thanks for this @Lightning00Blade and @OrKoN ! 🙌  From this PR from the bot it looks like it will be released in 19.8.0?

This commit seems to result in continuously adding new request/response event listeners, ultimately leading to memory leaks. Please confirm this, thank you. @Lightning00Blade @OrKoN

This commit seems to result in continuously adding new request/response event listeners, ultimately leading to memory leaks. Please confirm this, thank you. @Lightning00Blade @OrKoN

Here is the snapshot：https://github.com/puppeteer/puppeteer/issues/5893#issuecomment-2047476695


Github CI test pipeline sporadically fails for macos and python 3.11

Error:
run_tests.sh: line 8:  1871 Illegal instruction: 4  python -m unittest discover -v -p "test_*.py" Error: Process completed with exit code 132.
However, rerunning the pipeline resolves the problem.

If the workflow is adjusted to use run_tests_osx.sh, the same problem occurs with python 3.11
run_tests_osx.sh: line 8:  1959 Illegal instruction: 4  python3 -m unittest discover -v -p "test_*.py"


Can't translate date filters with backpack files override

Bug report
What I did
Wan't to filter date in French.
What I expected to happen
Moment with locale translate or daysOfWeek and monthNames translate. No one work. (resources/views/vendor/backpack/crud/filters/date.blade.php)
What happened
I can't translate date filters with overriding filters files.
What I've already tried to fix it

Backpack, Laravel, PHP, DB version
When I run php artisan backpack:version the output is:
PHP VERSION:
PHP 7.2.14 (cli) (built: Jan  9 2019 22:23:26) ( ZTS MSVC15 (Visual C++ 2017) x64 )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
LARAVEL VERSION:
laravel/framework                     v6.13.1   The Laravel Framework.
BACKPACK VERSION:
backpack/crud                         4.0.36    Quickly build an admin interfaces using Laravel 6, CoreUI, Boostrap 4 and jQuery.
backpack/generators                   2.0.6     Generate files for laravel projects
backpack/permissionmanager            5.0.6     Users and permissions management interface for Laravel 5 using Backpack CRUD.

I resolved


Proto updates related to user management

Summary
The following PR is a split from #3689
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[x] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 52.768% (-0.004%) from 52.772%
when pulling d50cfee696f6a2f53be3bd0a9a2451b5807d1554 on proto
into 85f3123757b5ef9efb4eb376177413c07cdcba5e on main.


Sign in? What is the Account?

The 'traditional' installation instructions give the defaults, 'admin' and 'producer', both with the same password Mel Brooks uses on his luggage.  :-)

@Jinjie-Jack-Wang you can read the documentation here: https://josephdadams.github.io/TallyArbiter/docs/usage/control-interface

Thank you so much!


Dynamic Entry Page

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
UI Feature
🔖 Feature description
The default page for non-logged-in users should be the status page, but for logged in users the dashboard.
✔ Solution
A third "Automatic" option for "Entry Page", which redirects logged in users to the dashboard.
❓ Alternatives
Manually switching back and forth :/
📝 Additional Context
No response

Yess! Really good idea

@FlorianMifsud nope, then everyone is redirected to the dashboard automatically


Add DaViT

Adapt the DaViT model from https://arxiv.org/abs/2204.03645 and https://github.com/dingmyu/davit.
Notably, the model performs on par with many new models, such as MaxViT, whilst having higher throughput, a design that should allow for easy pyramid feature extraction, and resolution invariance. In my experiments, the model transfers well between training and test images of different sizes (train 56x56, infer 640x640 and vice versa).

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

@fffffgggg54 the FeatureDict methods can be used (I've been meaning to do this as an example for swin / maxvit / etc) but the swin ones need some re-org.
You want to reorganize the stages instead of having everything in module lists sequences by looping
DaViTStage
  self.downsample = PatchEmbed
  self.channel = Channel...()
  self.spatial = Spatial()

In general it's easier to reason about the model with say FX manipulation, layer-scale module maniuplation if models in the model (as ordered  by model.named_modules() and parameters) are generally ordered to match their call sequence...
I can sort this out maybe next week, I'm going to tackle this for FocalNet (they organized like swin w/ downsample at end of stage), swin

And also having the two cpe modules in a ModuleList instead of cpe1/cpe2 instantiated relative to the other modules in they order they are used in fwd would be preferred ... I've done a lot of checkpoint remapping on the fly for this sort of thing
https://github.com/rwightman/pytorch-image-models/blob/main/timm/models/convnext.py#L331
https://github.com/rwightman/pytorch-image-models/blob/0fe90449e5e07e91a78ea847b76eda6010b55283/timm/models/efficientformer.py#L488-L513

Made a couple changes, PR 5 in my branch.
cpe modules were moved out of ModuleLists and into separate stages as cpe1 and cpe2. Other stages (PatchEmbed) were separated out as much as possible without sacrificing flexibility. The main DaViT stages have also been put into a separate class. I feel that these changes should for sure stay.
Since the DaViTStage class bears a resemblance to some of the stuff in ByoaNet/ByobNet and the structure of DaViT is also similar to those models, it might make sense to try and use that here.
I also got rid of all of the ModuleLists and iterating and replaced them with SequentialWithSize, which works like sequential but includes the size argument. I was hesitant to go this route in yesterday's version because this class doesn't work with TorchScript. I'm not sure if this has something to do with my implementation or if it's on torch's side. Looping through ModuleLists seems to be the best naive way to get around this. It might be possible to rewrite everything without the size argument.
FeatureDictNet didn't work, since it calls module(x) instead of module(x, size). I'm not sure if its worth overwriting the method when overriding forward in DaViTFeatures also works. Implicitly determining size would fix this.
I'll work on removing the size parameter, which should solve both the TorchScript and the feature extraction issues. I'm not sure if you have any input for me regarding how to move forward with this.

I've removed the size argument and everything works with nn.Sequential now. TorchScript works, as does FeatureDictNet. PatchEmbed also no longer requires register_notrace_module. Some parts are a bit messy due to conversions between (N, HW, C), (N, C, H, W), and (N, H, W, C).

@fffffgggg54 changes looking good, a few minor formatting things I'll take care of and will do some testing, I'll likely combine it with polishing up FocalNet and do in same block of time, maybe later this week.
Don't be suprised if this PR gets closed after I merge to another branch and then merge that :)
FYI I did some refactoring of module imports so that's why tests broke, I can take care of the fix when I do final polish, but it's fairly simple change on the import

@rwightman Would it be possible for you to tell me specifically what needs to be done, specifically the formatting? I'm trying to learn about contributing to large projects and I want the experience. I've rebased my fork to use the new module structure.

@fffffgggg54 a number of the changes are just small style nits that I often do for consistency... I can point out a few examples.
For the downsample, I think I'd still keep the very first patch projection as it's own top-level .patch_embed module, and (and have none in the first stage), and then have one in the other stages. This is for consistency with convnet stems and some other hierarchical transformers.
I think that's it actually at this point, you've done a great job fitting the style and using the model builder featuers, etc. The last fix to the module naming change I made recently should be quick, you're already using the new multi-weight default cfgs w/ added pretrained tags which is awesome.
Import block looks something like this now, a bit more granular, non-model support modules have _ in front, so when looking at models dir they're all at the top, separate from models. layers moved out to another top level.
https://github.com/rwightman/pytorch-image-models/blob/84178fca60fca9d35c0ea5ec08af2e88bf058559/timm/models/maxxvit.py#L49-L59

For the downsample, I think I'd still keep the very first patch projection as it's own top-level .patch_embed module, and (and have none in the first stage), and then have one in the other stages. This is for consistency with convnet stems and other hierarchical transformers.

I've added this here. I don't like the way it looks compared to all the stages having a patch embed and attention blocks, but it makes sense.
https://github.com/fffffgggg54/pytorch-image-models/blob/10b3f696b4913132fac6c3d7d708405b92319818/timm/models/davit.py#L499-L501
The imports are also updated to the latest ones and passes tests in my repo. I've contacted a few of the authors for additional weights, but haven't heard back. It might make sense for you to ask once this gets merged.

@fffffgggg54 thanks again for PR, I've been fiddling with the models and I'm falling short of the official classification results trying to validate, I've run through a few different crop sizes and interpolation combos, best I got was 84.2 for B and official impl claims 84.6. I didn't see anythign obvs wrong, but feel like maybe a pad or somethign isn't quite right for the classification setup (weird that those models aren't in the official impl).

@rwightman I did a few tests and it seems that the setup of the head was likely causing trouble. Current impl has norm->pool->fc, while pool->norm->fc seems to get me ~0.5% higher top-1 for val accuracy for the tiny model. I'll update the PR and send my setup once I fiddle with it a bit more and get results matching the paper.

I changed the head to pool->norm->fc with an implementation from convnext. This got me 82.80% on T, 84.28% on S, and 84.58% on B with bicubic interpolation, 0.85 crop, and 224 image size. I updated the model config to reflect these settings. I'm not sure why the B variant is still off by 0.02%.

@fffffgggg54 thanks, merged, I did a bit of refactoring, I didn't really feel their 'patch embed' was a patch embed anymore given it was being used like a stride 4 conv for stem, and a 2x2 box filter like conv for downsample, so split.
Weights are in HF hub https://huggingface.co/timm/davit_base.msft_in1k


Settings UI small visual tweaks

I am now on the testing build. Thank you for adding the tray context menu there. I have one more suggestion related to this: As Falcon is a taskbar utility it would look nice if the tray context menu used the same style as Windows taskbar context menu itself. It could look like this:

Maybe this and this could help?
(Btw. I think the settings icon is built into Windows 10 as a font.)

Another idea: Maybe you could add one more label to divide Settings as "Animation options" (animation and animation speed), "Position options" (offsets and center between start checkbox) and "Taskbar style options" (as is now). I think this would make the UI easier to navigate.

Yet another: Maybe moving the animation time and offset position units after the textbox may look slightly cleaner as making the label shorter and thus easier to read. And it could potentionally help in localization process as well. Could look like this:

(Also you made a small typo in Transparent - "Transparant" :) but that´s not so important.)
Hope it doesn´t matter that I am posting more ideas in one thread, but these are just too small to have their own issues :)

No problem! i am just very happy you can point so much out :). I am currently trying to get every possible idea and fixes ready for update <IP_ADDRESS>.

I'm glad I can help.


error in cascade_compile

systems
Ubuntu
Matlab r2020b
gcc 9.3
While running the compile.m following error shows
Building with 'g++'.
/home/nasim/Desktop/voc-release5/2012/voc-dpm/fv_cache/fv_cache.cc: In function ‘void gradient_handler(int, mxArray**, int, const mxArray**)’:
/home/nasim/Desktop/voc-release5/2012/voc-dpm/fv_cache/fv_cache.cc:417:21: warning: narrowing conversion of ‘dim’ from ‘int’ to ‘mwSize’ {aka ‘long unsigned int’} [-Wnarrowing]
417 |   mwSize dims[] = { dim };
|                     ^~~
/home/nasim/Desktop/voc-release5/2012/voc-dpm/fv_cache/fv_cache.cc: In function ‘void get_model_handler(int, mxArray**, int, const mxArray**)’:
/home/nasim/Desktop/voc-release5/2012/voc-dpm/fv_cache/fv_cache.cc:510:23: warning: narrowing conversion of ‘(int)M.model::num_blocks’ from ‘int’ to ‘mwSize’ {aka ‘long unsigned int’} [-Wnarrowing]
510 |   mwSize dims[] = { M.num_blocks };
|                     ^~~~~~~~
/home/nasim/Desktop/voc-release5/2012/voc-dpm/fv_cache/fv_cache.cc:515:38: warning: narrowing conversion of ‘(((int)M.model::block_sizes) + ((sizetype)(((long unsigned int)i) * 4)))’ from ‘int’ to ‘mwSize’ {aka ‘long unsigned int’} [-Wnarrowing]
515 |     mwSize dims[] = { M.block_sizes[i] };
|                       ~~~~~~~~~~~~~~~^
MEX completed successfully.
Building with 'g++'.
Error using mex
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc: In function ‘double conv(int, int,
const float*, const mwSize*, const float*, const mwSize*, int)’:
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc:62:25: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘const mwSize’ {aka ‘const long unsigned int’}
[-Wsign-compare]
62 |     for (int xp = 0; xp < B_dims[1]; xp++) {
|                      ~^~~~~~~~~
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc: In function ‘double rconv(int, int,
int, int, int)’:
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc:97:43: error: cannot convert ‘int*’
to ‘const mwSize*’ {aka ‘const long unsigned int*’} in initialization
97 |   const mwSize A_dims = MODEL->featdims[L];
|                          ~~~~~~~~~~~~~~~~~^
|                                           |
|                                           int
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc: In function ‘double pconvdt(int,
int, int, int, int, int, int, int, int, int, double)’:
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc:116:43: error: cannot convert ‘int*’
to ‘const mwSize*’ {aka ‘const long unsigned int*’} in initialization
116 |   const mwSize A_dims = MODEL->featdims[L];
|                          ~~~~~~~~~~~~~~~~~^
|                                           |
|                                           int
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc: In function ‘double partscore(int,
int, int, int, int, int, double)’:
/home/nasim/Desktop/voc-release5/2012/voc-dpm/star-cascade/cascade.cc:195:43: error: cannot convert ‘int*’
to ‘const mwSize*’ {aka ‘const long unsigned int*’} in initialization
195 |   const mwSize A_dims = MODEL->featdims[L];
|                          ~~~~~~~~~~~~~~~~~^
|                                           |
|                                           int
Error in cascade_compile (line 55)
eval(mexcmd);
Error in compile (line 44)
cascade_compile(opt, verb);

I have the same error, have you solved it?


Please add this method to the new syntax   driver.element().getElementsCount(locatorToMultipleElements)

implemented and will be pushed with the next release


Flutter Support

If you could add support for running and developing flutter apps that would be amazing.

Does it support flutter now?

Does it support flutter now?

No I don't think so unfortunately.


CLI version history / update log

Is your feature request related to a problem? Please describe.
It seems like a lot of people on here are using Amplify to develop production and/or alpha environments that need stability, and are reluctant to upgrade to the latest NPM branch for fear of breaking the local environment by hitting an edge case or whatever else happens in between a dependency upgrade and a mental breakdown.
Describe the solution you'd like
A short, concise log that details every update, fix or enhancement made for every semantic version of the CLI.
Describe alternatives you've considered
npm i -g @aws-amplify/cli && echo 'hope push works after this and the upgrade was worth the dependency risk =)'

@jkeys-ecg-nmsu Yes, I agree this would be something great to have and we're tracking this a part of this issue - https://github.com/aws-amplify/amplify-cli/issues/450
I'll update that thread once we have a better approach of announcing the changelog with the CLI.


joints: fix return type of translation() or rotation() methods

Related to #694.

@jmirabel This patch should fix your issue. Please let me know if it works.

To make this fix consistent with time, it would be necessary to provide some unit tests to check that compiles well. I don't have time to do it currently, but at least if this patch is working on your setup, this will be fine.
@jmirabel Can you provide a case where you are calling this method (translation()), because externally, this should not happen, except if you call a joint-generic.

I don't have time to fully validate it neither.
I did a small test. I don't think this change will fix the issue as the error is not on the constness but on the type itself.
#include <Eigen/Core>

using namespace Eigen;

typedef typename Vector3d::ConstantReturnType LinearType;

// This does not work
// LinearType foo () { return LinearType::Zero (3); }
// This works
LinearType foo () { return LinearType::PlainObject::Zero (3); }

int main ()
{
  Vector3d v = foo();
}

Ok. I will set this case then.

I will merge it now. @jmirabel Thanks for this report, hoping it will be helpful but I'm not sure as it seems to be a bug from Eigen side.


Will it be fixed for Swift2 in Xcode7.0.1

Hi,
is there a fix for Xcode 7 in the pipeline?

The extra error in call is simple.
How to fix the "Cannot convert value of type (NSURLResponse..." Issue?

Thanks a lot,
ps

Hi @petershaw
Code is coming up : )

@hallas when is it coming up?

@lfarah Hi. I'm sorry I don't have much time to work on this project. Maybe someone new can take over?

@hallas I'd be happy to take over!

Hey @hallas. I've fixed the most urgent errors preventing the project from being compiled in Swift 2.0.
PR: #33

@lfarah Okay, that sounds good. How do you want to proceed then? We could create an organization and try to add more contributors.

Yeah, let's do it!

Any chance to review the PR I submitted? :)

@iOSCowboy Yes for sure, as soon as we add more contributors it should be one of the firsts things we do.

Does anyone have an idea for an organisation name?

I'd also like to help.
Why do you need an organization? Why not keep it under your username?

@zemirco he wants to have more help and more people managing the lib

There is not much missing. We simply have to make it work with Swift 3.
Don't think we need an organization just for a single repo.

We could go further than this.

On Oct 10, 2016, at 1:43 PM, Mirco Zeiss<EMAIL_ADDRESS>wrote:
There is not much missing. We simply have to make it work with Swift 3.
Don't think we need an organization just for a single repo.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/hallas/agent/issues/32#issuecomment-252706484, or mute the thread https://github.com/notifications/unsubscribe-auth/AH8H9clitLt1zM3zDHg5ybgf1-IJ3n4pks5qyodrgaJpZM4GIkp7.


docs(alert-controller): cosmetics

Changes proposed in this pull request:

public dependency injection
change let to const

Thanks for the documentation improvements.


PUT request sending empty body even though I'm setting it

Hi -- I'm having an issue where I'm setting the body of a PUT request but the body isn't being sent with the request. The code looks like this:
async saveData(itemId, customisations) {
  const options = {
    uri: this.endpoints.itemCustomisationData(itemId),
    method: 'PUT',
    headers: this.headers,
    body: { customisations: customisations },
    json: true,
  };
  console.log(JSON.stringify(options));
  const req = rp(options);
  console.log(req);
  return req.json();
}

When I inspect the options object in the console, the body is clearly set:
{"uri":"http://app.localhost/api/v1/current-user/item-customisations/5","method":"PUT","headers":{"X-App-User-ID":4,"X-App-User-Token":"8a257c17df4b3b3f153a7516af76722993a2491f"},"body":{"customisations":[{"index":0,"type":"required_text","name":"Your name","label":"Your name here"}]},"json":true}
However, when I inspect the request object in the console, its body is undefined.
I have intercepted the call using Charles as a proxy, and when I inspect the body of the call there, it has 0 bytes.
Also, the request does hit my local backend server, but when I print the raw post data, it is just empty.
So I'm pretty certain that the issue is that I'm doing something wrong with request-promise.
I've tried explicitly JSON.stringify()-ing the data and explicitly setting the Content-Type header to application/json, but all to no avail.
Can anybody advise me on where I'm going wrong, here?
Thanks for any and all advice,
Doug.

Can anybody offer me any advice on this?
I've tried everything I can think of, including:

Changing the PUT to a POST in the front end and backend -- exact same error
Changing the backend to return a 404 to make sure nothing is wrong there -- it worked as expected

Could anybody at least tell me that I've not done anything they can see wrong?
99.99% of the time these issues are something I've missed but I've gone through everything I can think of and am still drawing a blank.
Is there a request library similar to request-promise that I could try to drop in to make sure it's not a library issue? Like I say, I seriously doubt that it is but I've exhausted everything I can think of to try to fix this.
Thanks again for any and all advice you can offer,
Doug.

This is just some off the cuff suggestions so it may not be correct as I have not tried to run my theories.

Rename your variable
customisations: customisations
Won't this pull in and use your variable twice?

Do you need to wrap the value with '' ?

@biot023 I've also been able to reproduce this issue. I found the same symptoms after upgrading from Node 8.11 to Node 8.15. Somewhere between those two versions a breaking change appears to have been introduced. Rolling back to Node 8.11 resolved it for now but I've begun migrating to Node 10 anyway.

@biot023 I assume you already dealt with it. Anyways, better late than never. Your req.json() line is most likely the issue. Instead you should use a promise function like .then(...) to work with the promise. No need for .json(). Here is the example to post data which is the same for PUT: https://github.com/request/request-promise#post-data-to-a-json-rest-api
Thanks for mentioning the node version issue @Bendihossan . Anyone who finds this issue, try upgrading node.


Add IsViewManipulateHovered()

See #322
This helps to prevent viewport actions from being forwarded to the underlying window if you in fact clicked onto the view manipulator. The time of the first click will only set the mbUsingViewManipulate boolean to true after the imguizmo code ran - but this might be too late for applications that already executed the click for their viewport action.

Thanks


Fix server start time

- What I did
The server, on startup will require SSL certificates to start a SecureSocket. It will retry for certificates if not found for every 10 seconds (sleeps for 10 seconds) for retryCount times.
I have fixed an issue where the server goes to sleep once even if the certificates are available.
- How I did it
Moved the break condition in the retry loop to appropriate place.
- How to verify it
You can start the server, and check the startup time. It will not take more than 5 seconds now.

@kalluriramkumar please check this PR


Integrate fancy search feature into native search

As of now, Encore's fancy search feature displaces DOM nodes to show search results. It would be a lot more convenient and bug-free to make it native.

Also, it has different rendering across browsers. Can you also look at this issue?

As in? What happens in Safari?


Update license in setup.py

Overview
This PR updates the license in setup.py. This resolves #109. Thanks @ocefpaf!

Travis CI tests passed. Merging..

Pull Request Test Coverage Report for Build 330

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 ?%

Totals

Change from base Build 326:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls


How to show progress bar in specific element ?

I want show progress bar in my specific place not top of pages. because there are my header show with position fixed property. so the "progress bar" not showing properly.

Use the parent configuration property.
loadProgressBar(
    {
        parent: '#elementid'
    },
    axios
)

#elementid can be anything valid in a document.querySelector


[speed] and [sounds] extra dependencies installation.

This issue is a pinned issue relating to installing TwitchIO with extras.
The issue with installing some of these dependencies is easily fixed on Python 3.10 and newer.
To install twitchio with speed or sound extras simply specifiy them like below:
pip install twitchio[speed] --extra-index-url https://pip.twitchio.dev
The reason we have decided to use an extra index URL is because some of these packages are not easily installable or do not have wheels built to install on newer python versions.
If you have any issues regarding installing dependecies with either speed or sounds, please reply to this issue.
This index is maintained by a long time friend and is completely open source, visit it here:
https://github.com/AbstractUmbra/abstractumbra.github.io

If you have any issues regarding installing dependecies with either speed or sounds, please reply to this issue.

I tried both
pip install twitchio[speed] --extra-index-url https://pip.twitchio.dev
python -m pip install "twitchio[speed] @ git+https://github.com/TwitchIO/TwitchIO.git"

and they both give same error:

while error suggestion is quite clear - to go to https://visualstudio.microsoft.com/visual-cpp-build-tools/ and grab C++ tools - but idk if I'm really supposed to download 5GB for twitchio to work, so I guess, it's better to ask.

Side note: I actually had same error with cchardet (while using second line without extra index) but searching in Pythonista discord server led me to
python -m pip install cchardet --extra-index-url https://abstractumbra.github.io/pip/ --no-cache-dir

which solved the issue.
But looks like it won't work for ciso8601 because twitchio requirements are ciso8601<2.3,>=2.2 while they only have pre-built wheels for 2.3 and umbra site too. I might be clueless tho.

idk if I'm really supposed to download 5GB just for twitchio to work, so I guess, it's better to ask.
These C-based dependencies are entirely optional, im not quite sure what you mean. Unless you need the speed extra for some reason, simply don't install them

Ehm, well, I guess, I shouldnt have said that. Sorry, I'm out of touch.
It's just it looks like you guys want to simplify the [speed] installation process with pre-built wheels (so we dont have to download 5GB C++ tools) and it failed for me - so I came to ask about why twitch reqs are ciso8601<2.3,>=2.2 when your index has 2.3 wheels :c

Yeah those can probably be updated

version reqs have been relaxed on master.


1.8 alphas are not present on maven central

- Plugin Repositories (could not resolve plugin artifact 'io.github.takahirom.roborazzi:io.github.takahirom.roborazzi.gradle.plugin: 1.8.0-alpha-2')
  Searched in the following repositories:
    MavenRepo
    Google
    Kotlin-Bootstrap(https://maven.pkg.jetbrains.space/kotlin/p/kotlin/dev/)
    Compose-JB(https://maven.pkg.jetbrains.space/public/p/compose/dev)
    Gradle Central Plugin Repository

👀

I believe there are POM files in Maven Central. 👀
Do you have a repository that can reproduce this issue?
https://s01.oss.sonatype.org/service/local/repositories/releases/content/io/github/takahirom/roborazzi/io.github.takahirom.roborazzi.gradle.plugin/1.8.0-alpha-2/io.github.takahirom.roborazzi.gradle.plugin-1.8.0-alpha-2.pom
https://s01.oss.sonatype.org/service/local/repositories/releases/content/io/github/takahirom/roborazzi/roborazzi-gradle-plugin/1.8.0-alpha-2/roborazzi-gradle-plugin-1.8.0-alpha-2.pom
https://s01.oss.sonatype.org/service/local/repositories/releases/content/io/github/takahirom/roborazzi/roborazzi-gradle-plugin/1.8.0-alpha-2/roborazzi-gradle-plugin-1.8.0-alpha-2.jar

It's working for me now, it looks like maven central had an outage earlier when I tried 😓


Added options with redirectTo for user update

What kind of change does this PR introduce?
Accept options object with redirectTo and send it as a query parameter to the endpoint.
What is the current behavior?
While GoTrue accepts a query parameter for url redirect, there is no way to set it inside gotrue-js.
It's probably not the best solution, it may be better to create a different method for user email change, as mentioned in the issue.
What is the new behavior?
Accept options object with redirectTo and send it as a query parameter to the endpoint.
Additional context
Look at this issue

Hey @atzmanuel, thanks for flagging this out! this would need some fixing on gotrue's PUT /user endpoint since i would prefer to name the redirect_to param to something more explicit so it's clear that it will only apply to a user email update.

Hey @atzmanuel, thanks for flagging this out! this would need some fixing on gotrue's PUT /user endpoint since i would prefer to name the redirect_to param to something more explicit so it's clear that it will only apply to a user email update.

Hey @kangmingtay, thanks for your reply. I understand that it's not clear that it will apply only to email change but,
I don't think that renaming parameter on gotrue's endpoint is possible since  it uses a global API method called getReferrer which is shared across the project.
An alternative solution may be creating another method like changeEmail which accept redirectTo param and leave update() method as it is.
The method changeEmail will require a mandatory parameter newEmail and an optional redirectTo parameter and will fire the same PUT /user endpoint.
Let me know what do you think about this solution.

Closing this one out as this was fixed in #610.

@silentworks I may be mistaken, but the pull request was about "Remove system user" and there is no mention to redirect in that PR's commit, is it really fixed?

@JonathanPicques i think @silentworks was referring to this PR instead: https://github.com/supabase/gotrue-js/pull/610


fix: restrict hashed package.json files

Which problem is this PR solving?
Seeing the hashFiles taking minutes makes me think it searches the node_modules dirs as well.
I have experienced and debugged it for test builds as well.
The examples using action/cache hash package-lock.json files, which would generally make sense if we checked our package-lock files in.
Why don't we? I've forgotten, but it has been discussed multiple times.
Short description of the changes
Restrict the globs to only hash package.json.

I opened a random CI run here

From what I understand, the CI log shows the key (calculated with previous hash as hashFiles('**/package.json')), as "Linux-16-6bbd533bd80a63cf309894ff379bc9fb331e6d4bdcc4150df233f13da78e5283" and it took 0s.
Am I missing something?


Fix event recorder scheme

Fixes #1628.

I had spent some time investigating this issue yesterday and found the Scheme we were using was "bad" - I  found that using Scheme from k8s.io/client-go/kubernetes/scheme also addressed the eventing issue, though I'm not certain it had Catalog's types registered.  Your fix LGTM.

I was wondering about a test myself but wasn't sure how to even go about testing it? I'll hold off on merging for a sec just in case.

When I was working on a fix separately yesterday, I changed https://github.com/kubernetes-incubator/service-catalog/blob/master/vendor/k8s.io/client-go/tools/leaderelection/leaderelection.go#L199 to add le.config.Lock.RecordEvent("testing event recording, still leading")  and verified this shows up when you do a kubectl describe configmap service-catalog-controller-manager -n catalog
Probably achievable with an integration test, but I'm not certain its worth the effort.

Executive Decision: :shipit:


data keys changes fixed

Description
changed keys from camel case to snake case
Fixes #
Checklist

[ ] Targeted PR against correct branch.
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Run meteor npm run lint
[ ] Added an entry to the CHANGELOG.md file.
[ ] Re-reviewed Files changed in the Github PR explorer.

SHA-1 is a cryptographically broken, we should not be using it for anything. that will allow others to bruteforce our keys and hack our blockchain


No task was selected for evaluation; Use --eval to select a task

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
A clear and concise description of what the bug is.
Reproduction

What command or script did you run?

A placeholder for the command.

Did you make any modifications on the code or config? Did you understand what you have modified?
What dataset did you use?

Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment information and paste it here.
You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)

Error traceback
If applicable, paste the error trackback here.
A placeholder for trackback.

Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!
Training is normal, but what happens when it comes to assessment?

Please fill the place holder in the template so that we can better help you.
You need to pass a metric for evaluation. For example, if you are training COCO dataset, then you can set evaluation metrix as bbox.
https://github.com/open-mmlab/mmdetection/blob/d3cf38d91c454b1a6881e8c36c1e4a66dc5521b8/configs/_base_/datasets/coco_detection.py#L48


Add type for diagnostics where location is defined

Related to #22088 -- this would allow us to access diag.file without an undefined check if it came from the diagnostics of a source file instead of global diagnostics.

@sheetalkamat Good to go?


[5.2] Restored guzzle 5 support

IMO, the adoption of Guzzle 6 hasn't be large enough for us to drop Guzzle 5 support just yet. I proposal we instead remove it in 5.3. In this PR I've basically just copied over the two mail transport classes from 5.1 and replaced the ones currently in 5.2.

Is this for your own benefit? :smile:

Is this for your own benefit? :smile:

Actually, no. I'm not planning to move off 5.1 for now since it works just fine, and I don't need anything added in 5.2.
I do think that there are a lot of people that will want to upgrade to 5.2, and will be stuck with guzzle 5 due to other dependencies they have.


Error when running donejs develop

The is a problem with steal-tools live-reload.  Because we allow live-reload to run on the server, but still don't want it to try and establish a websocket connection with StealTools, we need to properly configure the environment so live-reload knows not to set itself up.  This is done by setting env to build-development so live-reload knows it's in a config.  We are doing this for the multi build but not for live-reload.

This is fixed now.


0.1% accuracy

This PR includes modifications to the hierarchy which allows Bolt transfer functions to reach 0.1% agreement with CLASS in perturbations like Phi, delta_c, delta_b, and the photon monopole.
This PR also includes a change of units! Previously we were using natural units with a base unit of eV. This is not very useful for cosmology -- we join the rest of the world and use Megaparsecs as the base natural unit.

Docs now build Jamie's notebook, see preview here: https://xzackli.github.io/Bolt.jl/previews/PR69/basic_usage/

Fwiw @xzackli if you're annoyed by test deps, I would recommend switching to having a test/Project.toml for test dependencies, rather than putting them in the main Project.toml, I think that's the current recommended thing. An added bonus is you can activate the testing environment with using TestEnv; TestEnv.activate() and you'll get the exact environment the tests see. I don't think the current thing works with that.

Wow -- I hated the way I had to use test deps, this is a nice development. I'll change it over.

Codecov Report

Merging #69 (05fb6ae) into main (de08e4d) will increase coverage by 24.60%.
The diff coverage is 57.77%.

@@             Coverage Diff             @@
##             main      #69       +/-   ##
===========================================
+ Coverage   46.09%   70.70%   +24.60%
===========================================
  Files           7        7
  Lines         692      693        +1
===========================================
+ Hits          319      490      +171
+ Misses        373      203      -170

Impacted Files
Coverage Δ

src/Bolt.jl
0.00% <0.00%> (-100.00%)
:arrow_down:

src/ionization/ionization.jl
19.71% <0.00%> (-4.88%)
:arrow_down:

src/spectra.jl
0.00% <0.00%> (ø)

src/background.jl
93.18% <83.33%> (+6.81%)
:arrow_up:

src/perturbations.jl
79.26% <90.00%> (+79.26%)
:arrow_up:

src/ionization/recfast.jl
91.78% <100.00%> (-0.08%)
:arrow_down:

... and 3 more

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 de08e4d...05fb6ae. Read the comment docs.


Ensure attaching to an application with an existing DDS instance is not treated as a fatal error

@DanTup, this should fix https://github.com/Dart-Code/Dart-Code/issues/2936.

I don't quite understand this PR. In this case did we failed to connect to the VM Service because 1) we tried to attach dds to a dds instance or 2) we tried to attach dds to a VM Service instance and that already had a dds?

See https://github.com/Dart-Code/Dart-Code/issues/2936 for exact repro details, but basically calling flutter attach for an application that currently has a DDS instance connected (e.g., an instance of flutter test --start-paused) currently causes the tool to exit. DDS can't connect to another DDS instance and the VM service will reject direct connections with a DDS instance connected. However, this isn't a fatal error as the VM service will redirect websocket connections to DDS, so we should be continue and try and connect to the service even though we couldn't get DDS to start.

Shouldn't we be trying to connect to the dds URI and not the VM Service URI?

Ahh, so we are given the correct URI, and we just need to accept not starting dds?

Ahh, so we are given the correct URI, and we just need to accept not starting dds?

That's correct :-) DDS is already running, so it doesn't matter that we failed to start it.

Can't seem to get this branch back into a good state so I've re-uploaded to #70847.


~SHEET doesn't compile when empty

defmodule ExampleSheet do
  use LiveViewNative.Stylesheet, :swiftui
  ~SHEET"""
  """
end
From @BrooklinJazz : I'd like to support that if possible for examples and exercises (Also, I think it's a better dev experience)

We'll leave open for now, but I just tried to reproduce and got this:
error: undefined function class/2 (expected ExampleSheet to define such a function or for it to be imported, but none are available)
  test/mocks/example_sheet.ex:2: ExampleSheet.compile_ast/2

This is happening not because of the ~SHEET sigil but because the compile_ast function expects at least one class/2 function to be defined. After v0.2.0 I have a fix already in that will inject the default def class(_, _), do: {:unmatched, ""} fallback via a @before_compile callback.
I'll close this out when that is pushed up


proposal: x/net/http2: add Transport.WriteByteTimeout

There are currently two ways to detect a broken HTTP/2 connection:

If a Read or Write to the net.Conn fails.
If no frames are received from the connection for ReadIdleTimeout, and no response is received from the subsequent ping within PingTimeout.

Pings are a reliable way to detect a broken connection (with the fix for #48810), but there are times when it would be nice to passively detect an unresponsive peer without needing to actively ping them.
I propose adding an additional knob to http2.Transport:
// WriteTimeout is the timeout after which the connection will be closed
// if no data can be written to it. The timeout begins when data is written
// to the connection, and is extended if any bytes can be written.
// If zero, no write timeout is set.
WriteTimeout time.Duration

Unlike ReadIdleTimeout, WriteTimeout will apply only at the time we try to write to a connection. Unlike per-request timeouts, WriteTimeout applies to the connection as a whole.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group


References in FFI types/signatures

Rust's &'a T is guaranteed to be interpretable as a nonnull raw pointer. Wrapping them in Option adds the null case. Given that Vulkan generally does not capture passed-in pointers, I think we could replace most uses of raw pointers to single objects in FFI signatures and structures with Rust references. This would help mitigate the footgun of storing a raw pointer in a struct and then dropping the pointee before passing the struct to Vulkan, and make builders less needed, though still nice for arrays.
Can anyone think of a reason not to do this?

That'd be a very welcome change indeed! Though we have to keep in mind to not "accidentally" generate this for DSTs like dynamic types and slices.

raw pointers to single objects

Any idea if we can do something similar for arrays? Those have been most problematic in our code (even with the builder pattern, ie. .some_array(&[single_item]).build();).
Finally, the builders already seem "unnecessary" in hiding the functions behind a separate struct to not have lifetimes on the FFI structs. If we go ahead with this change (and add 'a to FFI structs) we might as well drop the builders entirely and move its functions directly on the main struct.
We should go ahead and make this change, and dog-feed it to our own code as an initial feasibility test. Likewise should we reconsider making fn build unsafe?

Unfortunately I think this is impossible for slices, because Vulkan lays out the length inline in the struct, and we have absolutely no guarantee that the resulting layout would match that of a slice even if/when Rust slices do get a defined ABI. However, if we subsumed the builders into methods on structs as you suggest, I think we'd have the next best thing: such methods could easily enforce that a passed-in array outlives the struct, just like they do for builders today. It'd be a bit weird to use struct construction syntax for most things and a setter for arrays, but it'd work.

Likewise should we reconsider making fn build unsafe?

I don't think this accomplishes anything, for two reasons:

Vulkan code is almost invariably deep inside a big unsafe block anyway, so if you're not reading the docs it won't change anything, and we already document the hazard
This hazard is strictly orthogonal to the formal notion of safety in Rust: there is no way to invoke UB by calling build; the hazard only arises when you pass the structure to an (already-unsafe) function that has a documented requirement that the pointer is nonnull.

Anyway, it sounds like we have a good case for getting rid of builders entirely (which might help our compile times besides!)

Would every pointer be replaced with an Option of a reference in this case? I think that would be necessary in order to keep the Default impl working.

ffi signatures: Yes probably? But we are already exposing &T in our higher level bindings, so the win doesn't seem that big.
ffi types: Potentially yes? I was initially a bit worried that people who want to store these types would have to worry about the lifetimes. But you usually just construct them just before the function call anyway. Although would like to have a look at all the affected types.

However, if we subsumed the builders into methods on Vulkan structs as you suggest, I think we'd have the next best thing: such methods could easily enforce that a passed-in array outlives the struct, just like they do for builders today. It'd be a bit weird to use struct construction syntax for most things and a setter for arrays, but it'd work.

How would that look like?
Like this? let foo = Foo { f, .. Default::default() }.with_bar_slice(&bar)

A C pointer to a slice maps to a reference to its first element. So if slices can't go into structs due to ABI issues, then a separate count + reference to first element can work. Of course, this means you lose checking on the length, so methods may still be needed.

Like this?

Yep, that's what I was thinking of.

a separate count + reference to first element can work. Of course, this means you lose checking on the length, so methods may still be needed.

This feels really weird to me. I've also gotten the length wrong far more times than I'd gotten the lifetimes wrong, pre-builders.

I was initially a bit worried that people who want to store these types would have to worry about the lifetimes.

You could store a 'static version using None or pointers to constants, which should cover the cases where you'd want to do this. Note that Foo<'static> can be used with FRU syntax to produce a non-'static value.

Unfortunately I think this is impossible for slices, because Vulkan lays out the length inline in the struct, and we have absolutely no guarantee that the resulting layout would match that of a slice even if/when Rust slices do get a defined ABI.

I wasn't planning on laying out the slice one way or another inside Vulkan structs, rather how to model a safe borrow to it in the first place. Would a &'a borrowing the first element work, considering it's just a pointer? That only opens up confusing API though.
Lengths are troublesome anyway, consider for example SubmitInfo where wait_semaphores and wait_dst_stage_mask share the same field. Ideally that's turned into a single builder function taking both slices, and asserting their lengths to be equal.

However, if we subsumed the builders into methods on Vulkan structs as you suggest, I think we'd have the next best thing: such methods could easily enforce that a passed-in array outlives the struct, just like they do for builders today. It'd be a bit weird to use struct construction syntax for most things and a setter for arrays, but it'd work.

With this we'd basically be moving the lifetime parameter over to the struct itself, and automatically get rid of the .build() footgun - and we can turn single-object references into borrows too in case they would have been assigned to directly.

Likewise should we reconsider making fn build unsafe?

I don't think this accomplishes anything, for two reasons:

Vulkan code is almost invariably deep inside a big unsafe block anyway, so if you're not reading the docs it won't change anything, and we already document the hazard

At least in our codebase we're minimizing the scope of unsafe, even the .unwrap() or ? sits outside it where possible (and this usually allows rustfmt to place everything on a single line.
Regardless we have already accepted that Vulkan functions are unsafe, but builders are not. Making .build() unsafe would be another nudge to revisit all calls to it.

This hazard is strictly orthogonal to the formal notion of safety in Rust: there is no way to invoke UB by calling build; the hazard only arises when you pass the structure to an (already-unsafe) function that has a documented requirement that the pointer is valid.

Just like how .as_ptr() on various types looses all lifetime information, but isn't inherently unsafe itself. I have mixed feelings about this and appreciate some leeway to allow custom "hey, you better think twice before calling this" unsafe markings.

Anyway, it sounds like we have a good case for getting rid of builders entirely (which might help our compile times besides!)

:partying_face:

ffi types: Potentially yes? I was initially a bit worried that people who want to store these types would have to worry about the lifetimes. But you usually just construct them just before the function call anyway.

That's the purpose of lifetimes and this issue, to prevent users from having objects that reference dropped memory - they have to worry about lifetimes one way or another.

In an ideal world we should have all primitives and single-object borrows as public fields, but hide lengths and array pointers behind appropriate slice getters and setters to minimize the possibility for UB; both in terms of pointee-lifetime and slice length mishaps.

A C pointer to a slice maps to a reference to its first element. So if slices can't go into structs due to ABI issues, then a separate count + reference to first element can work. Of course, this means you lose checking on the length, so methods may still be needed.

I probably don't want to worry about storing slice lengths separately if they are already encoded in the Vulkan structs itself. However, they might address the above problem of multiple structs sharing the same length field while still being able to re-set a slice field later, with different sizes.

Would a &'a borrowing the first element work, considering it's just a pointer? That only opens up confusing API though.

Yes, but I agree it's a bit confusing. Then again, using setters only for array fields is weird too, unless we keep all the setters, which is a bit disappointing from a code savings perspective but makes for more consistent style. Not sure what the best balance is.

With this we'd basically be moving the lifetime parameter over to the struct itself, and automatically get rid of the .build() footgun - and we can turn single-object references into borrows too in case users like to interact with these fields directly.

Yes, that's the idea.

At least in our codebase we're minimizing the scope of unsafe

Most of my Vulkan code lives in functions that are almost exclusively concerned with making Vulkan calls or invoking methods that have unchecked assumptions about Vulkan state, so any narrowing further than the function level would lead to ~every expression being separately wrapped in unsafe, which does no good. I don't use ash's builders anywhere else.

Just like how .as_ptr() on various types looses all lifetime/borrow information, but isn't inherently unsafe itself

Yes, exactly. I can see both sides here, but my feeling is that using unsafe as a general-purpose red-flag cheapens it; if it's routinely used in places that have no direct semantics, then it's easier to get in the habit of skimming past it, and harder to identify and thoroughly audit code that genuinely does have unchecked soundness requirements.

using setters only for array fields is weird too, unless we keep all the setters, which is a bit disappointing from a code savings perspective but makes for more consistent style

Indeed, the end result inevitably has to look like https://github.com/MaikKlein/ash/issues/441#issuecomment-846921927 with fields and a default in FRU followed by one or more explicit setters. It's not consistent but we might as well try this and see what impact it has on our own programs (OTOH that's a lot of effort to implement when we already know what it looks like).

Yes, exactly. I can see both sides here, but my feeling is that using unsafe as a general-purpose red-flag cheapens it; if it's routinely used in places that have no direct semantics, then it's easier to get in the habit of skimming past it, and harder to identify and thoroughly audit code that genuinely does have unchecked soundness requirements.

I guess that already is the case for us in our Vulkan backend, unsafe simply doesn't stand out anymore whereas .build() sticks out like a sore thumb. Let's leave this as it is then, it becomes obsolete if we go ahead with this change anyway.

Adopting references for non-array stuff and moving all setters to the actual Vulkan structs rather than builders should be uncontroversial and a big win on its own; we can then separately consider stripping things down further.

The only controversy might be in the lifetime parameters that will have to be specified all across the generated functions and function-pointers which use these struct types directly, that could become annoying generator-wise (unless the new generator is used, which seems to have better support for a distinct parsing+analysis phase, separate from the code generation phase).

Sounds like a good reason to pursue this as part of the new generator, then!

https://twitter.com/dotstdy/status/1454505264246312980?t=Og0n2mof83gW_mmLQLzOdg Got linked this relevant thread that judges Ash build time and uses exactly the things we proposed here! (except the VulkanSlice1 as that might not work when the size field isn't right before the pointer field, including the ambiguity where multiple pointers share the same size field).
All in all this is probably something we can start working on right now, as it doesn't seem there's a lot of traction on the new one yet. @MaikKlein what's its status, is it something that everyone just needs to start working on?

https://github.com/MaikKlein/ash/pull/602 is a big step in this direction.

@Ralith is this still something you want to chase up? It might be relevant for the few structs one could construct directly without default() (i.e. making sure all fields are filled), and that's slightly ugly with the _marker: PhantomData.

I'm pretty bandwidth-starved at the moment, at least. The slice representation problem means we'll always need to rely on setters in some cases, so at least off the cuff I don't mind leaning into them.
Is vk.xml precise enough to let us judge where to use Option<&T> vs &T? I know that didn't pan out for Vulkan handles, but I forget whether it does for pointers. If not, this might be a step backwards in ergonomics. If so, we could leverage that to significantly improve readability of fields and setters both.

If we can't eliminate _marker entirely then eliminating it in most cases might just make the remaining ones even more confusing, since there won't be consistent norms to deal with them.

The slice representation problem means we'll always need to rely on setters in some cases, so at least off the cuff I don't mind leaning into them.

I previously linked a Twitter post but it seems to have gotten removed. It had a screenshot of some VulkanSlice1<', u32, T> type off the top of my head, for the common case where a count is directly followed a pointer, and I guess the type would safely abstract that away with slice access. I presume there's also a VulkanSlice2 when two slices share the same counter (see SubpassDescription::color_attachment_count which is immediately followed by p_color_attachments and p_resolve_attachments). It probably uses some trick to deal with the 8-byte alignment for pointers:
struct VkFoo {
    count: u32, // off=0
    _implicit_padding: u32, // off=4
    ptr: *const u32, // off=8
}

But that padding is not there in the parent struct if the previous members sum up to an uneven multiplier of 4-bytes
struct VkFoo {
    flags: u32,  // off=0
    count: u32, // off=4
    // No padding needed!
    ptr: *const u32, // off=8
}

And if I remember correctly there was one more template parameter in the screenshot which must have been driving this.

If we can't eliminate _marker entirely then eliminating it in most cases might just make the remaining ones even more confusing, since there won't be consistent norms to deal with them.

Only slices would prevent this, right? Then the VulkanSliceX type, if we can apply it globally, would have this as private member and we won't have it publicly anywhere (see below: perhaps it can have a const constructor).

Is vk.xml precise enough to let us judge where to use Option<&T> vs &T? I know that didn't pan out for Vulkan handles, but I forget whether it does for pointers. If not, this might be a step backwards in ergonomics. If so, we could leverage that to significantly improve readability of fields and setters both.

That's a question for @oddhack I think, I don't know if optional attributes are accurately absent.
TBH I don't think writing some_ptr: Some(&other_thing) is much worse than .some_ptr(&other_thing), though it'd be great if Option<> is only present where the spec mandates it.

On yet another note, especially if we end up going this route of VulkanSlice1 which needs a constructor, I wonder if we can and should annotate builder functions as fn const.

Only slices would prevent this, right? Then the VulkanSliceX type, if we can apply it globally, would have this as private member and we won't have it publicly anywhere

I don't such types can ever be sound. A nested struct is not guaranteed to have the same layout as the equivalent fields inlined into a struct.

I wonder if we can and should annotate builder functions as fn const.

Not sure when this would be very important, but it seems harmless since we're inlining them all anyway.

fn const would only be necessary if building and wanting to store these structs in const variables, but then because of inlining that may already be what the compiler emits. It's more of a usability thing for the user, though I don't have any concrete examples where this'd be useful (but there probably are!) :sweat_smile:

Catching up on this very old issue because of Matrix discussions, I think we might build the slice wrapper from the removed Twitter comment as long as we have different slice wrapper types around with different size/packing rules. That means the generator will have to keep track of the size and alignment of every field to pick the right one.
Example lacks an implementation and appropriate lifetimes. And we need a VulkanSlice2 variant for the waitSemaphoreCount linked above, which has one counter for two slices.
#[repr(C)]
#[cfg_attr(feature = "debug", derive(Debug))]
#[derive(Copy, Clone)]
pub struct VulkanSlice1<T> {
    size: u32,
    // Implicit u32 padding here
    pointer: *const T,
}
#[repr(packed(4))]
#[cfg_attr(feature = "debug", derive(Debug))]
#[derive(Copy, Clone)]
pub struct VulkanSlice1Packed<T> {
    size: u32,
    pointer: *const T,
}
#[repr(C)]
#[cfg_attr(feature = "debug", derive(Debug))]
#[derive(Copy, Clone)]
#[doc = "<https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VkDeviceCreateInfo.html>"]
#[must_use]
pub struct DeviceCreateInfoSlices<'a> {
    pub s_type: StructureType,
    pub p_next: *const c_void,
    pub flags: DeviceCreateFlags,
    pub queue_create_infos: VulkanSlice1Packed<DeviceQueueCreateInfo<'a>>,
    #[deprecated = "functionality described by this member no longer operates"]
    pub enabled_layer_names: VulkanSlice1<*const c_char>,
    pub enabled_extension_names: VulkanSlice1<*const c_char>,
    pub p_enabled_features: *const PhysicalDeviceFeatures,
    pub _marker: PhantomData<&'a ()>,
}
/// Ensure the size stays the same
const CHECK: usize = (std::mem::size_of::<DeviceCreateInfoSlices>()
    == std::mem::size_of::<DeviceCreateInfo>()) as usize
    - 1;

Keep in mind that the common pattern to have a size field before the pointer field might not apply everywhere. We'd have to scan through vk.xml to ensure there are few enough outliers to make this worth our time.


Unused and missing translation strings in Playnite 9.6

The generic launch action option that's displayed per platform when setting up multiples shortcuts (and checking LOCIncludePluginGameActions) isn't currently translated and there are no strings to do so for each platform. See for example the untranslated "Start using Galaxy" in the picture below :

The "Steam friends" button is also missing a translation, but the related string already exist (LOCSteamFriendsTooltip)

Done in the latest update.


View / Identifiers view CRUD update Alias)

Create and Read of Identifiers (KERI AID) are complete.
Update and Delete of an Identifier is a backlog item to be addressed in the future issue #56


Github: "Failed to configure Azure pipeline. Error: Repository ID for a GitHub repository should be in the form: OwnerName/Repository."

Some string got attached to the repo url. The Url in the service endpoint was like "OwnerName/Repository/randomstring"

@tejasd1990 it would be really helpfull if you can provide the repo name that you were using. Will make the task easier for us to debug.

https://github.com/tejasd1990/node_containers_from_dps. This is the repo I used.


DAI Transactions from Gnosis to Polygon with positive slippage not working

Describe the bug
DAI Pool on Polygon is heavily unbalanced towards DAI. Incoming transactions from Gnosis Chain should be receiving high positive slippage.

However, people are getting LowSlippage error when trying to arb this. For some reason, it seems that the system isn't allowing users to receive positive slippage.
To Reproduce
Steps to reproduce the behavior:

Go to bridge.connext.network
Select xDai or WXDAI on Gnosis Chain to DAI on Polygon
See that the amount received will be much higher than the amount sent (correct because of positive slippage)
Start bridge
See error

Additional context
https://discord.com/channels/454734546869551114/1105458360238747678/1105458535602601984
https://discord.com/channels/454734546869551114/1105446247109775470/1105446723775639682
https://discord.com/channels/454734546869551114/1105444722719326239/1105444739081318560

Slippage stuff seems to work correctly. The swap is failing because of a check https://discord.com/channels/992549151134982234/1032671441084235828/1105529872023044116 that prevents users from putting in a greater amount of an asset than there is in the pool (of that same asset).
As the pool gets rebalanced by smaller transactions, the larger ones are able to go through (for example: https://connextscan.io/tx/0xe792f1783b255e7dcb87b4b7c3540a424615f3e50518912d182994f6a6c99bbb).
The solution when opening up new pools is put warnings on the UI for this problem, telling users not to bridge too large amounts.

@Tommy-R8 is this still ongoing?


Wrong document path sent to GA

Hi,
After I installed the new version an extrange behavior started: every time I go to a route different to the root, a weird document path (dp property) is sent to GA and overriding the correct one.
Step #1, navigating http://mydomain.com/
Query string sent to GA:
dl: http://mydomain.com/ (ok!)
[NO dp property is sent]
Step #2 routing to "steptwo" after user interaction:
Query string sent to GA:
dl | http://mydomain.com/steptwo (ok!)
dp | https://mydomain.com/stepfour (wtf?!)
Step #2 routing to "stepthree" after user interaction:
Query string sent to GA:
dl | http://mydomain.com/stepthree (ok!)
dp | https://mydomain.com/stepfour (wtf?!!!!)
...
The result of this behavior, is that GA is tracking only / and /stepfour.
I can't understand why is overriding the document location with an aleatory document path.
Hint #1: "stepfour" it's a valid path.
Hint #2: Even in a develpment environment "dp" takes the full public location (mydomain instead of localhost:3000).
Hint #3: I've tried forcing the 'settings.pageview.locationProp' value but page breaks with the error 'Invariant failed: You should not use  outside a '.
Any ideas??

Hi, is it possible that you create a example repo with the bug?

Hi, thanks. Yes I will try to isolate the issue into a new project.
Meanwhile, does anyone have an example of the use of settings.pageview.locationProp in a React app that uses BrowserRouter?
Thanks


Build failure

Build fails because org.hamcrest:hamcrest-all:1.2 cannot be found.
Maven central indeed only has 1.1 and 1.3.

Merged PR, this should be fixed.


Option to disable accordion expand onClick

Is there a way to turn off the opening and closing when clicking on the accordion in different screen sizes ?
TIA

Gidday @spokzers, keep in mind that fundamentally all RAA is actually doing is toggling classes on your HTML elements. You can choose to style 'open/closed' classes at various breakpoints however you see fit.

Hope this helped to answer your query @spokzers, I'm going to close this issue now due to inactivity but feel free to re-open if you still have any questions.


Several warnings in console

This package works fine in general. But when I look into the console, I realize that this package is generating multiple warnings:
11:12:52.759 WARNING: WindowsApps.ModernControlPanel: App Setting: {'settings_uri': 'ms-settings:quietmomentshome', 'page_name': 'SystemSettings_QuietMoments_On_Home_Mode'} display name empty
11:12:54.250 WARNING: WindowsApps.ModernControlPanel: App Setting: {'settings_uri': 'ms-settings:batterysaver-usagedetails', 'page_name': 'SystemSettings_BatterySaver_LandingPage_UsageDetailsLink'} display name empty
11:12:59.428 WindowsApps.WindowsApps: Cataloged 37 items in 23.0 seconds
11:12:59.487 WARNING: WindowsApps.ModernControlPanel: App Setting: {'settings_uri': 'ms-settings:network-wificalling', 'page_name': 'SettingsPageNetworkWiFiCalling'} display name empty
11:13:03.715 WARNING: WindowsApps.ModernControlPanel: App Setting: {'settings_uri': 'ms-settings:signinoptions', 'page_name': 'SettingsPageAccountsManage'} display name empty
11:13:06.581 WindowsApps.ModernControlPanel: Cataloged 90 items in 30.1 seconds

Moreover, the time that it takes to load the package is on the slow side. Is this normal or am I missing something? How can I fix those warnings?

These warnings are settings pages that are removed in newer windows 10 versions. (On my Windows 10 1909 there are no errors)
Maybe quietly ignoring these would be better.
The reason cataloging is so slow is because to properly display the apps with icon and localized name the AppManifest has to be read. The AppManifest is a XML metadata file which has to be parsed in order to extract the relevant information. That sadly takes some time, far more time than just scanning directories and finding files (like the FilesCatalog).

Thanks you answering my question. I am using Windows 10 2004 fyi.
To solve this problem, I actually modified the code
from:
if not display_name:
    self.warn("App Setting:", setting, "display name empty")
    continue

to:
if not display_name:
    display_name = setting["page_name"].replace("_", " ").lstrip("SystemSettings").lstrip("SettingsPage").strip()

It may not be the best practice, but it has solved my problem.

Well it's no use to display these items. They would just jump to the start page of the windows settings.
I will change
if not display_name:
    self.warn("App Setting:", setting, "display name empty")
    continue

to
if not display_name:
    self.dbg("App Setting:", setting, "display name empty")
    continue

but I won't make a new release because of this.


promoting

your tool is cool
you could promote it in flutter weekly newsletters like Flutter tap
https://fluttertap.com/

I'll be closing this issue since it has been seen in https://fluttertap.com/issue-125/.
Thanks!


https://github.com/foldfelis/NeuralOperators.jl

@bischtob would NeuralOperators.jl be useful for any bits?

looks similar!


Cue list widget - cannot edit Notes field

Describe the bug
When using the the Cue List widget in Virtual Console, there is no mechanism or property that I can locate in the UI that allows the Notes field of the widget to be edited.
To Reproduce
Steps to reproduce the behavior:

In Virtual Console tab of UI during edit phase, click on "Cue List" widget and add to VC desktop.
Verify widget appears and drag to expand.
Verify title bar of new widget shows #, Cue list, Fade In, Fade Out, Duration and Notes fields
Right click on Widget and select "Properties" in speed menu
In the Cue List Tab of the Properties page, add a Chaser
Click OK to save the widget with it's Chaser. Verify the chaser steps are shown in the List, and that the #, Cue List, Fade In, Fade Out and Duration fields are populated and match the definitions in the chaser you have created on the UI functions Tab.
Verify that the Notes field is unpopulated, and is apparently Read Only.

Expected behavior
Each step in the chaser list should be editable in the CL Widget, to allow the Notes field to be populated.
Changes made in the Widget fields should back-propogate to the Chaser definition on the Functions Tab/page
Screenshots
Desktop (please complete the following information):

OS: Windows, Linux Mint, Ubuntu
QLC+ Version: all versions, currently 4.13.1
hardware setup (mandatory for audio/video issues): N/A - not a hardware problem. Incomplete software functionality.

Additional context

The new version 4.13.1 appears to have corrected this, permitting Notes to be edited in the Chaser function list entries.


Move this repository

We bootstrapped this project within redhat-et, but as the project grows, it should be moved to a neutral project-specific home. We should create a github org, move the repo there, and fix all the fallout.

I propose doing this right after merging #345, since we expect things to break for a bit then anyway.


java sample code

hi there
i need a sample java code for this 😃

you should use Main as class name


Video rotation not updated if CropGridViewer is showing grid

Hello.
I noticed that _controller.rotate90Degrees(...); is not updating CropGridViewer if showGrid:true is used.
Is that the expected behaviour?
Best regards,
Bozhidar

The showingGrid argument is only should be use in CropScreen because make a lot of bugs


throttleMs behavior: Immediate first input creates edge case for minimum input validation

Context
What's your version of nuqs?
"nuqs": "^2.0.4",

What framework are you using?

✅ Next.js (app router)
❌ Next.js (pages router)
❌ React SPA (no router)
❌ Remix
❌ React Router
❌ Other (please specify)

Which version of your framework are you using?
NextJS 14.2.15

Description
The throttleMs functionality is kind of strange. It will capture the first input instantaneously and then throttle according to the throttleMs parameter. That's pretty much it. This requires additional logic, for example, if you don't want to allow searching with just 1 letter.

In general, this throttleMs is not good for search text input. If you try to type, the second letter will be skipped. For example, if you try to type 'hello', it will appear as 'hllo'."

Yes, this is the expected behaviour for throttling: the URL is regularly updated, with an instant initial update.
While this works well for low-frequency UI elements like tabs or check boxes, high frequency ones (and particularly search) would benefit better from a debounce behaviour, where the update is eventually sent after a period of inactivity.
Debounce support is on the roadmap and should land soon, see #291.