From you current Camera description, the one the user is using to take the picture/video.

//Properties you need in your controller class

final cameras = List ([]);
int camIndex = 0;

Then just check after taking the picture, like this:

 if (cameras.value[camIndex].lensDirection == CameraLensDirection.front) {
 originalImg = img.flipHorizontal(originalImg);
 }


@StephanTLavavej @CaseyCarter feel free to edit this if my analyzation for any LWG issue is incorrect, or P/R for any issue hasn't been voted into the working paper.


Good afternoon Miroslav, I have a question, how can I place your application on hosting, not in the way that you indicated in the documentation, but with the standard npm run build command, but the problem is when I run it, I get an error, how can I run the npm run build comm
New Bitmap Image
and here is an example what a normally compiled file looks like


Hello @VladimirGorin,
For questions please do not post here but join with us on Discord forum - `hepl-and-support channel`. Thank you!


Sorry, I don't think you've made a case for any code changes. You have made a case for documentation changes, and 2950, which will close this ticket when merged, will document (in both places) that scatterLines needs to be set at both the DS and DSV level.


Ok. Your call certainly. Documenting will help avoid the possibility shown below using sample/Chart/33_Chart_create_scatter2.php.

Case 1: As written - behavior as expected

$series = new DataSeries(
 DataSeries::TYPE_SCATTERCHART, // plotType
 ...
 DataSeries::STYLE_SMOOTHMARKER // plotStyle
);

image

Case 2: Modified to comment the SMOOTHMARKER designation. I suggest this might be reasonable thinking since, after all, I know one line will be smooth, one straight, and one has no line at all. To ensure the correct display, I have specified each DSV's line charactieristics. Since I don't want to have the series combination ($series) override each DSV assignment, I comment the last line,)
The smooth line is now a straight line.

$series = new DataSeries(
 DataSeries::TYPE_SCATTERCHART, // plotType
 ...
 // DataSeries::STYLE_SMOOTHMARKER // plotStyle
);

image


@jwinarske Thanks for filing the bug. For the record, @stuartmorgan is the TL for this area of the code so he's the one who should make the final call on this.

It sounds like there's an ambiguity in your request. We support several Linux-based platforms, for example Android and GTK. Plugins for different platforms are quite different (for example, plugins on Android are typically in Java, whereas on GTK they are in C!).

The core problem, I think, is that we don't yet have extensible logic in the tool so that you can easily add new platforms. We should definitely work on that. URL is where we're tracking that issue. You can discuss this in #hackers-tool on our Discord. As a heavy user of a custom embedding, you may be interested in getting involved in this work; we haven't really started on it in earnest yet but it is an area we are very interested in.


Wow, thanks @frederick-vs-ja! This is a ton of work. I'm going to tag this (and any relevant PRs) as "blocked" until we actually get approval for the proposed resolutions in the WG21 virtual plenary on 2022-07-25, but folks should feel free to go ahead and submit/review such PRs.


This feature is now fully implemented on master.
Just doing some testing and then I should be able to release a new version with this functionality included.


Very odd. Can you check the following:

- Does the problem persist when you flush all caches?
- Does the config file `installer.settings.json` exist in your active config directory?
- If it does, what are the contents?

Background to this: the first problem seems that in `array_merge($filters, $server)` the $server variable seems to be null, but there's a default setting, so it at least contains ` URL


The problem is not likely related to the upgrade. In D7, the installer is a module called `update`, which doesn't exist in Backdrop, where the installer is called `installer`. In fact, no "D7 to Backdrop" upgrade ever has the `installer` module on after the upgrade (it's one of those modules that don't get automatically enabled) - you always have to enable it manually after the upgrade, regardless of whether the D7 had `update` on or off. So you can most likely discard the upgrade process (in fact `installer.install` has only one hook_update_N(), which is not related to the upgrade process).

As @indigoxela pointed out, the most likely culprit is a problem with `installer.settings.json`. Inspect that file both in your site's `files` folder and in the `core/modules/installer/config` location.

Also, you may have a files directory problem. Check the site's `settings.php` file (and any possible `settings.local.php` file) for the line `$config_directories['active']` and see where it points, then be sure that `installer.settings.json` is present in that folder.


I agree. In fact, I've upgraded dozens of sites while testing other PRs and this hook has never before run. I think it's safe to remove this hook, as there is no "update" from a D7 version, as `installer` doesn't exist in D7 (update_1000() is used for upgrades from D7).

I've done more testing to verify: I can confirm that enabling Installer in a freshly upgraded D7->B site does not run `installer_update_1000()`. I've tested this via en UI and via bee. I haven't tested with drush.

Bottom line: I can't explain if or why this hook ran in @yorkshire-pudding site. But it's probably a good idea to leave this open in case others run into this issue.


Is there a solution for videos? **also why does this issue keep getting closed even when it is unresolved! Just because people are not commenting, it does not mean the issue has magically stopped being an issue!


This isn't a bug - using IPC requires a render frame, which a worker doesn't and can't have.


`--dbus-user=proxy` is not supported. It's `filter`.

---

The fallback code a program uses if an dbus name does not exists is outside of the scope of firejail, consider reporting this to jetbrains then.

If you believe this happens because of an implementation deatil of xdg-dbus-proxy, report it there.

TL;DR: Is this a firejail issue?


I meant --dbus-user=filter, of course. Does --dbus-user=proxy even work?

Anyway, this program uses libappindicator. That's what uses GtkStatusIcon as a fallback.

This problem doesn't happen without firejail, as the fallback works properly in that case, though it's very possible that it's a xdg-dbus-proxy thing.


Yeah, I managed to reproduce it with the following setup:

xdg-dbus-proxy "$DBUS_SESSION_BUS_ADDRESS" dbus --log --proxy &
DBUS_SESSION_BUS_ADDRESS="unix:path=$PWD/dbus" ~/.local/share/JetBrains/Toolbox/bin/jetbrains-toolbox


Looking at git blame - this update hook came in with #3105 and still seems OK. Its main intention was to prevent enabling core updates for B sites installed before the core update was enabled.

There are two situations, though, where this hook does harm:

1. Upgrading from D7
2. Very, very old B sites (older than 1.11.0) that have the installer disabled

So, why does this stub config problem exist.
You can verify with following code:

$config = config('foobar');
debug($config);
$config->set('bla', 'blu');
debug($config);
$config->save();// Problem!

The fix can be a one-liner, we only have to check if `$config-isNew()` and in that case do nothing.


A PR is available for testing and review.

**How to test:**

Update from D7 and verify there's no stub installer.settings.json file in the active config dir
or
Update from a B install older than 1.11.0 - in that case: if the installer was on, the core updates should be off in config. If the installer was off, no stub file gets created in the active config dir.

I hope, my explanation is clear enough (I often fail to properly explain things) :wink:.


Thanks @indigoxela. I confirm:
- after running `core/update.php` there is no `installer.settings.json`
- After enabling Project Installer it is there and module works as expected.


Sorry I don't get it...
What are you trying to do and where is it related to dbus-java?
What is xdg-dbus-proxy and why should I use it?
Which version of dbus-java is involved here?
Are you using it as client or is it running the embedded dbus?


xdg-dbus-proxy is a utility used for separating apps that use dbus from the rest of the system, giving them only access to the specific services that they need. It creates its own dbus server and connects to the system's dbus server to proxy and filter calls. This is incredibly useful for any kind of sandboxing technology, such as flatpak and firejail.

I am trying to get an app that uses dbus-java to run inside a sandbox whilst using xdg-dbus-proxy to restrict its access from most dbus services. My current trail of debugging has led me towards this library, as removing its transport jar changes the result of the execution, causing it to not connect to dbus at all, instead of hanging.

The version of dbus-java involved, according to the jar files in jetbrains-toolbox, is 4.0.0.


I think probably a thousand person, me included, have written similar scripts. This is just absurd.


Is there any sort of log produced by dbus-java? Usually dbus-java uses Slf4j with any slf4j compliant logger to log what's going on. Especially turning on TRACE-logging would definitely help to find out what is going on.


@ahejlsberg Please help us in the name of practicality and peace of mind.


Are you sure you are xdg-dbus-proxy the correct way?
Just using --filter will cause xdg-dbus-proxy to block all communication except for the initial handshaking to DBus.
See here.

When using xdg-dbus-proxy and a patched version of jetbrains-toolbox (with logging enabled) I can see that dbus-java connects to the Bus for the handshaking stuff, but as soon as jetbrains-toolbox want to listen to signals of com.canonical.Unity.LauncherEntry the signal is not being answered and the socket is closed.
For me it looks like if there are missing a lot of options for xdg-dbus-proxy to tell the proxy to allow talking to com.canonical.Unity.LauncherEntry and may others as well.


I wasn't able to tell which dbus services it was trying to access, but yeah I reckon it needs a few whitelists to work. Still, I don't have a com.canonical.Unity.LauncherEntry on my system, so it should have the same behavior here? And if DBUS_SESSION_BUS_ADDRESS is set to some bogus value like "foo", it gracefully and silently fails as well..


Aha! I see that update hook was added as per this comment in that issue. 3105 Thanks @indigoxela. (I did my homework and read the whole thread this time 😉 )

Your fix makes sense. But your explanations for testing make only partial sense to me:

This doesn't make sense to me. Before your patch, none of the D7 upgrades I'm doing ever run `installer_update_1000()`, and none of them ever create a "stub" `installer.settings.json` file - neither before, nor after your patch. This is because `installer` doesn't exist in D7, and therefore it is always disabled when upgrading from D7. And when you manually enable `installer` with the current version of Backdrop after the upgrade, the update hook is not run (which is the expected behavior).

As I said above, the D7 upgrade **itself** was probably never the problem. It alone can't explain @yorkshire-pudding problem. There must have been an additional problem in between.

Update from a B install older than 1.11.0 - in that case: if the installer was on, the core updates should be off in config. If the installer was off, no stub file gets created in the active config dir.

So, this is also not clear to me.

I did try this:
- Started with version 1.10.2. (Backdrop looked a bit different back then! 😄 )
- I manually turned off the installer.
- I upgrade to 1.11.0. No "stub" file is created. Simply: the update hook is not run because `installer` is off, and the stub json file is not created.

Then I tried this:
- Started with version 1.10.2.
- I made sure installer is ON. The file `installer.settings.json` file exists normally "sans" the `core_update` setting
- Updated to 1.11.0. The `installer.settings.json` file is updated (the update DOES run this time) and `"core_update" : false` is added normally. The rest of the json file is left untouched - it's not a stub file, but a beautifully looking full settings file.

So none of these situations can explain @yorkshire-pudding problem either.

My theory is that something went wrong with @yorkshire-pudding's site, and that it was really a fringe case. Therefore fixing `installer.install` with your patch may not be necessary. Your patch doesn't do any harm and is very simple, but it may not be needed in normal situations. Still... better safe than sorry, so I'm going to marked this as RTBC.

So this is my theory of what happened to @yorkshire-pudding:
- He probably updated from D7 before 1.11.0. But this fact is probably irrelevant as I explained above.
- He enabled `installer` in his pre 1.11.0 version in a way that did not move `installer.settings.json` to the config folder (perhaps manually switching it on in the database?), OR that json file was somehow removed from the config directory. So he ended up with an enabled `installer` and no json file, **somehow**.
- He then updated Backdrop to 1.11.0, and this ran `installer_update_1000()`. But since there was no json file in the config folder, then the empty stub was created


We could have an admin page of "allowed tags" that users can suggest or add (like our body performance tags or `pit`-related tags). That would reduce the impact of users adding synonyms or tags that generate notes.


@argiepiano thank you so much for your thorough testing! :pray:

You're absolutely right, the problem must be something else - and I found a way to reproduce it on a fresh vanilla install:

1. Disable and uninstall the installer module (json file gone)
2. Go to /admin/reports/updates/settings
3. Save the file - at this point the stub json file gets created
4. Enable the installer module again - the file stays broken

So the bug is indeed somewhere else: it's in function update_settings() - the form still displays the core update setting, even if the installer module isn't enabled.


Never too late to switch strategy. :wink:

A totally different PR is available for testing and review. Sorry to waste your (testing) time.

This time testing is much easier (can also happen in the sandbox). Just follow the steps in my previous comment.


Wow! That explains the problem, and it's indeed something that can happen much more often. I think the problem is that the option to enable the Manual self update should not be shown if installer is disabled, right?

I see you just submitted a new PR. I'll take a look


That makes sense and is almost certainly what happened.
Thanks - will do test


This new PR looks great and WFM. All tests passing. RTBC. Perhaps we should change the title of this issue to reflect the new direction?

Thanks for digging into this and finding the culprit, @indigoxela!


One more thought.

For sites that currently present the problem described by @yorkshire-pudding in this issue (because Project Installer was disabled, and they visited and saved the form at `/admin/reports/updates/settings`): this patch with not fix the already problem created by the faulty code. The stub json file already exists in the config directory.

In fact there are only two ways to fix the problem once it's created: (1) manually fix the json file as @yorkshire-pudding did. (2) Or you would need to enable and then disable `installer` to fully remove the faulty json file.

Should we provide another upgrade hook that checks that the json file exists, and if it contains the key `"installer_server"`, and if not, creates the default installer_server entry?


I've tested the PR and works. Thanks @indigoxela you are a star.
@argiepiano - good point, though not sure how common it will be.


@argiepiano @indigoxela
Would a suitable title be: "Project installer doesn't work if settings are changed while disabled"
?


Okay, the update with this has been released. Currently testing it locally and I am not hitting into any trouble.
That being said, I would be very careful using this - it could quite easily mess up your Jellyfin library or provider watch lists.


It can be common. If you upgrade a D7 site, Installer is disabled by default. If you visit `/admin/reports/updates/settings` and save that form, the faulty json file is created. At this point the only way to fix the problem is to manually alter the json file as @yorkshire-pudding did, OR installing - fully uninstalling - installing again Project Installer so that the uninstall step removes the faulty file.

This update hook is simple. It would check if a faulty json config file exists, and restore the default value. It could look like this

php
function installer_update_1001() {
 $config = config('installer.settings');
 if (!$config->isNew() && empty($config->get('installer_server'))) {
 $config->set('installer_server', array(
 'url' => ' URL
 'name' => 'Backdrop',
 ));
 $config->save();
 }
}


Thanks @indigoxela, @yorkshire-pudding, and @argiepiano! I merged URL since it stands alone as a great fix.

@argiepiano I think your idea to make a "fix bad JSON" update might also help be comprehensive. Do you think we should add that as well?


Perhaps on a separate issue, for 1.23.0, since this was merged already? Or is there time to do this for 1.22.2? I can probably open a new issue and PR in the next 3 or 4 hours


Yeah let's do it as a new issue. Doesn't necessarily need to wait for
1.23.0 though. We could get it in 1.22.3.

On Thu, Jul 21, 2022, 5:27 PM Alejandro Cremaschi ***@***.***>
wrote:


I finally found some time to fix it all and also finished upgrading to Vite 3 :) Everything should be working in latest, feel free to give it a try and let me know how you go. Raise a new issue if there's any problems.


This has to do with the exception handling of the calling code.
When DBus is not available dbus-java will instantly fail with an `AddressResolvingException` or an `IOException`. When the calling code swallows the exception, nothing will happen (no DBus usage, no blocking).

When blocking certain calls the problem is different. While establishing connection to DBus worked (handshaking, sending Hello etc), specific calls get blocked. In that case the connection (at least in version 4.0.0) gets into some sort of half-disconnected behaviour, which causes the connection to be treated as connected when it actually isn't.
This was fixed in 4.1.0 of dbus-java.

When using 4.1.0 with your setup, the application will only block for about 10-20 seconds due to waiting for method replys which will never be received.

I improved this in the latest 4.1.1 snapshot, so dbus-java will no longer wait for method-replies if the disconnection from the bus was caused by an `IOException` (e.g. of the transport like in this case).

The error message 'invalid client serial' you see is not from dbus-java but from some launcher used to start the jetbrains-toolbox.
I guess that this has something to do with messages not arriving at that application, but usually this does not hurt.


Thanks a lot for digging into this issue! Glad to know the mechanics of all of this now. It makes sense, as xdg-dbus-proxy works in a way many applications don't expect, but I guess I was confused since I've never seen similar behavior in other programs using dbus. Many thanks for implementing a workaround anyway, I'll be patiently waiting for that to trickle downstream :)

And yeah, the "Invalid client serial" message comes from xdg-dbus-proxy itself: URL
I wrongly assumed that would be the issue since I didn't see this message pop up during correct operation. It might not be related at all.


The library causing the hang turned out to be dbus-java, not libappindicator. The issue is further discussed here, with a potential fix that might appear in future releases: URL

For now, a different workaround to get the application to not hang yet still display a GtkStatusIcon-powered tray icon would be to run with `dbus-user none`, and writing the following in `~/.config/JetBrains/Toolbox/toolboxrc` to start a dummy non-proxying D-Bus server in the sandbox:

eval $(dbus-launch)
export DBUS_SESSION_BUS_ADDRESS
./$app "$@"
kill $DBUS_SESSION_BUS_PID
exit


@mid-kid Thanks for the details.

(Re-closing as "not planned" since the bug is not in firejail)


Hi Team,

Turning off **Optimize Conversion** setting via UI does work.
Is there a way to do that via the Postman API?

I am using the Automation-API Workflow and still getting the error. Documentation is not clear/ doesn't show settings available in the UI

 URL


This is now available in the latest snapshot build, and will be part of the next Chrysalis release.


This conversation is really frustrating. While I can understand not adding the .js suffix under the rationale of not modifying Javascript (though I disagree with it), what I *cannot understand* is the compiler happily producing code that will fail to run. There should **at least be an option to fail compilation if I don't use a .js suffix in the import**. I don't even care if it's a default option, as long as it's exposed.

In the meanwhile, what do people recommend doing? What's the safest way to make sure tsc doesn't produce Javascript that will fail in this instance? I'm using node 16 and would really like top level awaits.


Yeah, it's not like there aren't already 1000 compiler options to tune the
behaviour of TypeScript, one more won't hurt...

On Sat, 23 Jul 2022, 19:13 Nathan Coleman, ***@***.***> wrote:


And to reiterate, I'm not asking for am option that rewrites the imports, just an option that makes the compiler say "hey, this probably isn't what you want and will generate broken code", like a fatal warning. There could even be a flag that would override the warning and allow compilation anyways.

So `"failOnInvalidModuleImport": true` in tsconfig (defaults to false), which would cause the compilation failure, and a flag `tsc --allow-invalid-module-import`which would ignore even if the setting was true, and compile anways.

TypeScript team, can you comment on adding an option like this? This is clearly a problem people have, and I can't see how exposing a default false option to give some greater compile safety could be a bad thing there. It would be a great way to earn some developer good will :)


As you all also see in my pull req, the rewrite are only a few lines of code


Additional resources...

Regarding delaying tasks (will be useful to understand how timeouts work and how we intend to persist them):

* URL
* URL
* URL
* URL

Regarding serialisation and persistence of lazy tasks (the persisted task in the Queue backing the DB isn't a promise, it's just some data on disk, but we may give back a lazy promise as an in-memory reference to the task):

* URL
* URL

We may not actually be serialising arbitrary code, but instead allow domains to register function callbacks into the queue, and then the queue will then call back these registered functions. That way the functions are somewhat dynamic but not just arbitrary code execution.

As for the lazy promise representation, make sure to take some ideas from URL I'm wary of bringing in such a huge library and API, so we should just take ideas from it and implement it in our own promise abstractions.

As for the worker dispatch, we want the workers to pull in tasks from the queue when done. However threadsjs (used by js-workers) doesn't expose a complex queue to use. So we won't be able to use their own queue, instead, we would want to augment our workers or augment the `Pool` class to take work from our own persisted queue. See: URL


During the testing of this it would be nice to incorporate URL ( URL into the model based checking of the queue functionality. Some background: URL


I'm sorry, but I've had no solid block of time to focus this issue since then.


I'm still having the issue with Strapi 4.2.3 and Sentry 6.19.6 for all Sentry packages :/

Are you sure it is fixed?
Is it a regression @lforst?

Thx


@VictorienTardif could you run `yarn why @sentry/core` and `yarn why @sentry/hub` and reply with the output (`npm ls` will work like `yarn why` if you're using that)


Hello @AbhiPrasad, here it is:

yarn why @sentry/core
yarn why v1.22.17
[1/4] 🤔 Why do we have the module "@sentry/core"...?
[2/4] 🚚 Initialising dependency graph...
[3/4] 🔍 Finding dependency...
[4/4] 🚡 Calculating file sizes...
=> Found "@sentry/core@6.19.6"
info Reasons this module exists
 - "_project_#@strapi#plugin-sentry#@sentry#node" depends on it
 - Hoisted from "_project_#@strapi#plugin-sentry#@sentry#node#@sentry#core"
info Disk size without dependencies: "932KB"
info Disk size with unique dependencies: "5.09MB"
info Disk size with transitive dependencies: "5.09MB"
info Number of shared dependencies: 5
✨ Done in 0.51s.

yarn why @sentry/hub
yarn why v1.22.17
[1/4] 🤔 Why do we have the module "@sentry/hub"...?
[2/4] 🚚 Initialising dependency graph...
[3/4] 🔍 Finding dependency...
[4/4] 🚡 Calculating file sizes...
=> Found "@sentry/hub@6.19.6"
info Reasons this module exists
 - "_project_#@strapi#plugin-sentry#@sentry#node" depends on it
 - Hoisted from "_project_#@strapi#plugin-sentry#@sentry#node#@sentry#hub"
 - Hoisted from "_project_#@strapi#plugin-sentry#@sentry#node#@sentry#core#@sentry#hub"
 - Hoisted from "_project_#@strapi#plugin-sentry#@sentry#node#@sentry#core#@sentry#minimal#@sentry#hub"
info Disk size without dependencies: "564KB"
info Disk size with unique dependencies: "3.99MB"
info Disk size with transitive dependencies: "3.99MB"
info Number of shared dependencies: 3
✨ Done in 0.32s.


@VictorienTardif, could you try upgrading to v7? This may fix the error as per: URL


May I also add to the question that whenever I try to do something like
1. first point
2. second point
3. third point

and then have sub-points under it like
1. first point
 * sub
3. second point

it will leave the list as 1., 3. and skipping 2 - that is really a bummer as it makes numbered lists unusable for me.


@Hixie Thanks for the constructive response, I'll look into the referenced issue and Discord channel.


cibuildwheel is becoming pretty standard as a way to build wheels for lots of platforms. You can see pyzmq as an example that builds wheels including a bundled (C++) library dependency, covering pypy, arm, windows, etc.


Hi, I found out that it was a problem with Strapi docker image that installs Strapi globally.
There must be a mismatch with Sentry versions or something.
Installing everything locally and running outside of docker it's working fine.

Thx for your help.


@VictorienTardif, if this is not the case already, I would encourage you to use the official Strapi integration for Sentry. They are not always on the newest version of Sentry, but they do make sure that Sentry works properly.


I'm having trouble reproducing this. On my Windows VM, printing to a file or a printer works without an issue. I suspect that the problem here is not with printing itself, but with the disconnect. I'll keep looking, though.


I believe every issue has now been processed. We have PRs out for the majority, I've recorded the two that patch `zip` in #2252, filed issues for the three that don't yet have pull requests, and submitted a PR to cleanup comments for the two we implemented speculatively with comments.

Thanks to everyone, and again extra-special thanks to @frederick-vs-ja for filing this issue and a majority of the resolution PRs.


Yes, I agree that it seems there is some reason that ctrl+P is causing a refresh of the connection. Let me know if I can do anything else to help troubleshoot.


Hello
We also have a relatively similar problem but without any change or modification to settings and configuration files.
After installing new fresh BBB 2.5.4 on a dedicated server (12 core + 64 ram) (also I tested before in vps ( 8 core + 16 ram) with the same issue):
- Sometimes when we have about 3-5 concurrent web came sharing with presentation enabled, we have unsynced sound for about 3-10 seconds delay from the video, and it may be continued for a while for some of the attendees or moderators from 1 minute to much more minutes.
- No special Errors in --status and --check but this one :
 URL
Regards


P2165R4 also changes `zip_view` etc. (making them no longer use `pair`) and `basic_common_reference` and `common_type` partial specializations.


I also ran into this bug and couldn't open my duckdb from Python, not even with `read_only=True`.

Disconnect in DBeaver didn't help, only closing the DBeaver application completely resolved the issue.

Is there anyone that can fix the DBeaver connector to disconnect properly?

In [82]: con = duckdb.connect("my-db.duckdb", read_only=True)
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
Input In [82], in ()
----> 1 con = duckdb.connect("my-db.duckdb", read_only=True)

RuntimeError: IO Error: Could not set lock on file "my-db.duckdb": Resource temporarily unavailable


I had success using this command "Connect-PnPOnline -s -url $Url -Credentials $Creds"


I will add a note to the OP to make sure that `zip` implementation doesn't miss the changes from P2165R4. There's enough to P2165R4 that I think of it as more a standalone feature than simply a patch on `zip`, so I'll leave the separate feature issue.


Hey all, just wanted to sum up the discussion and close the issue since it was resolved with the release of 3.0.0-rc.0, which is the very first version that supports the new React Native renderer, Fabric. 🎉

If you’d like to try running **Reanimated on the new Fabric architecture**, you need to upgrade to React Native 0.69 (or newer) and install Reanimated 3.0.0-rc.0 (or newer). Note that it will not work with Reanimated 2.x or React Native 0.68.x. For more details, check out this blog post.

If you want to use **Reanimated on the old Paper architecture**, you can still use version 2.x and React Native 0.64+. However, if you don't use old Reanimated 1 API, we encourage you to upgrade to Reanimated 3 (which is fully-compatible with Reanimated 2 API and built from sources on both platforms).

Currently (as of July 2022), Expo SDK does not support Fabric yet. Expo SDK 45 includes react-native 0.68.2 and react-native-reanimated 2.x which does not support Fabric.


Additionally:

It would be nice if you could configure to transfer all forms to another user / the admin, when a user is deleted (instead of removing the forms). This would be useful e.g. if a user leaves your company.


hey, can you try again? it's a known issue, and it's due to the fact that we disabled asymmetric adds


this is the same issue as:
395 and 389.

What's our strategy here? @bksifchain (My understanding is that we won't re-enable asymmetric liquidity adds anytime soon)


@hungng157 i have flagged this issue on the **eng-support** slack channel


So I'm thinking that rather than queueing arbitrary code, you have to first register handlers like `queue.registerHandler(fName, f);` Then subsequently when you push a task like `queue.pushTask(task);` the end result is that when the task gets executed, it ends up executing a "static pointer" which is the `fName`.

But then this is actually really similar to `EventEmitter` and our `EventBus`. Basically registering handlers is the same as adding event handlers, then pushing tasks is similar to emitting events. See: URL

So there are similarities, there are some differences, our scheduling of tasks is not just a simple synchronous call, nor is it an asynchronous call as we have in `EventBus.emitAsync`.

The queue is also persistent unlike the eventbus, the actual emission of the event may be delayed by an arbitrary amount of time that is also persisted. There's a controlled concurrency to dispatching tasks.... etc.

So similar, but different. In that sense, there's no need to extend from `EventEmitter` (especially since we need to change that to event target)...


This URL has an interesting solution. They support static priorities. These priorities are set when an item is enqueued.

Once enqueued, the user gets back a ID.

There are 256 possible priorities from 0 to 255 inclusive.

When the item is stored, a key is derived from both the priority level and its ID.

 // Create new PriorityItem.
 item := &PriorityItem{
 ID: level.tail + 1,
 Priority: priority,
 Key: pq.generateKey(priority, level.tail+1),
 Value: value,
 }

As you can see here, the IDs are generated by the queue, and they are a counter that is simply incremented.

The resulting database KEY is likely a concatenation of the priority level and the ID. Assuming lexicographic encoding, there's just basically `PRIORITY + SEQUENCE`.

So then in the database, we can always find the highest priority with just the ordered keys, as it will be ordered by the priority first then the sequence second.

Interestingly, when dequeueing, it doesn't seem to consult the database, but some in-memory structure that indicates what is currently highest priority level to consider. But I wonder if this is necessary.

Surely it can just take a row off the database, as the database is the source of truth of what is highest priority.


The URL has 2 interesting features:

1. The ability to delay the dispatch of a job that is queued
2. The ability to stream dispatch jobs

The first feature appears to be done by passing a handler that determines when a job is valid to be executed

This handler is simply checked repeatedly whenever a job is iterated over.

The second feature is an asynchronous loop that just iterates over the jobs. If a job isn't valid, it just sticks it back into the queue.

In that sense it is really using it like a queue, but I don't think it's very efficient as if a job that isn't valid, it just repeating a busy loop with a delay until it checks again when the job is valid.


The concept of URL is interesting as it indicates the idea of priority that can grow or decay as a function of time. So then when an item is inserted, it's inserted at time `T` rather than with a priority. But there's a priority function associated. Therefore, to know the priority of the item, apply the function to `T`. This is an abstract interface, the implementation might be more complex.

But it is interesting because we can definitely store `T` into the database, but our indexing of the queue becomes more complex. In the case of the go solution, the priority is part of the index, so it's easy to find what is the lowest priority just by getting a sorted key-value.

One way to do this, that upon first starting the queue, we scan the contents of the queue which is an O(n) procedure. This gives us an understanding of what is in the queue, and then to create in-memory twins of this data. In particular this would be useful for any persisted delayed jobs, where we put down the time it was inserted, and the desired amount of delay.

The queue is not meant to be big, so O(n) at the beginning when loading the queue should be fine.

Now can this same mechanism be used to apply dynamic priorities, where because we know the time of the items in the queue, we can then re-sort them according to an in-memory priority? To do so, may seem to require some sorted partitioning of the jobs into their relative derived priorities.


The idea of scanning the priority queue database at launch is necessary because persisted start times with delays have no other way of being made available to the code.

Unless one were to index the database by scheduled time. Schedule time would be `INSERTION TIME + DELAY`.

Then the items would be indexed by this number.

A numerically sorted key-values, upon which popping the lowest number, would be the item that is earliest to be scheduled for execution.

At the same time, because the program knows its own time, we can attempt to pop tasks only within a given range search.


Imagine index of `INSERTION TIME + DELAY`.

Time is ticked 1 second at a time. Insertion time grows linearly.

Delay can be 0 or more.

As tasks are inserted at linear time steps `1+100, 2+50, 3+10, 4+0`, this fills up a queue of:

4
13
52
101

The dispatch, looks for all task where `index <= currentTime`.

Suppose current time is 32, then you get `[4, 13]` which are tasks that are due to be executed. In particular you have 2 tasks are overdue. But that's ok, this is best-effort execution.

But when does this dispatch execute? Is it just polling every second? The database is not capable of triggering things. It's state, not a process.

So dispatch may check at each time-tick, but this is also inefficient.

The dispatch can instead look for lowest indexed item. Then set a timeout to be executed based on the scheduled time in-memory. This is assuming all times are in the future. If they are in the past, then they should be dispatched now.

So suppose the above queue.

Upon the first lookup, it would see task 4. Assume current time to be at 2.

Then it would `setTimeout` for `2` to pop a task at time 4, which would find all tasks `index <= 4`.

However what happens if new tasks are entered into the system that should be executed even earlier. In that case, the insertion of new tasks should also trigger the dispatcher, but only if the new task `INSERTION TIME + DELAY` is earlier than task `4`.

So at any point in time, there will always be a `setTimeout` set to the earliest task that has to be executed. And this is reset every time a task is executed.

This avoids having to do an O(n) scan at the very beginning, and instead is more like an O(1) scan.


So that deals with tasks with delays and also no delays. No delays just mean a delay of 0.

What we have is a list of tasks ordered by "scheduled" execution times.

Static priority is just a matter of adding a numeric prefix. Starvation may occur here.

Dynamic priority means tasks should start with an initial priority. But then as we pop tasks out we must execute a function to figure out its priority.

Suppose there are 2 tasks, both are scheduled for immediate execution, that is a delay of 0. Which task should be executed assuming only 1 can be executed at a time?

The priority function is applied to both tasks, using the tasks's `INSERTION TIME` as a parameter.

The priority function will take into their account their initial priority, plus their dynamic priority returned by the function. This added up is weighed together, and the highest priority task is executed, the other task remains in the queue.

This means priority is not indexed at all, it's just a value. And we solve the starvation problem now.


@VictorienTardif I don't know if your issue is already resolved. The Strapi folks fixed this in their `4.11.1` version - please update to at least that version (as you're still on `4.2.3`). Additionally, make sure that all your sentry deps are on the same version. (check in lockfile)


Hello @alzhab! Thanks for submitting the issue. Here are some more questions:

1. Do you use Expo?
2. Did you remember to run `RCT_NEW_ARCH_ENABLED=1 pod install` in `ios` directory of your app?


I've just created a fresh RN 0.69.3 app, added react-native-reanimated, build the app for iOS and it works fine.

Please make sure that you enable Fabric via environmental variable `RCT_NEW_ARCH_ENABLED` and not directly in Podfile.

Related issues:
* URL
* URL


We still need a `TaskId`, and if we use `IdSortable`, we pass in a `nodeId` into the `IdSortable` constructor. This is only used to to ensure that Ids can be generated uniquely and not conflict between different nodes. But this is only useful if the `TaskId` is going to share the same namespace.

Since this is not going to happen, it doesn't really matter, and we should make the `nodeId` optional.

Note that however, if the node ID changes, that should involve reassigning the `generateTaskId` function with the new node ID.


Note that since we are indexing by "scheduled time", we cannot just extract the time component of the `TaskId`.

So we have multiple sub levels here:

1. `['Queue', 'tasks']` - `TaskId -> Task`
2. `['Queue', 'time']` - `Time -> TaskId`

When creating a task, we create a task id, insert it with the task, then also assign a time to the task to be executed.


Hi.
thx for forms in nextcloud.
I got also to this. I would prefer to share the edit feature to someone else, e.g. a circle.


For yarn users, add this to the root of `package.json`:

json
 "resolutions": {
 "ethereumjs-abi": " URL
 }


Hello
1 No, i don't use Expo
2 Yes Fabric enabled and run command with flag RCT_NEW_ARCH_ENABLED=1


@Eilon @rmarinho Could I get informatiom regarding that issue?


Hey @kickbk I think I'm having the same issue, could you please share this fork?


The recommendation to preemptively append `.js` extensions to TypeScript source is not only counterintuitive, it breaks ts-jest tests. It seems to me that TypeScript is in the wrong here. Why ban `.ts` extensions from import statements and encourage leaving them off altogether if the extension is resolved by the language server but *not* the compiler?

I just encountered this issue while attempting to port a library to TypeScript. I didn’t have to deal with it in prior projects because I was building apps with a bundler. Now that I’m emitting modules that can be tree-shaken downstream, this behavior, intended or not, leaves me in a bit of a pickle.


@adamshaylor for what it's worth, vitest supports `.js` imports in test code and is largely API-compatible with Jest.


I have the same issue for something I solely distribute as a `.deb` package - my main issue is that I have to update the version in both my Debian packaging files and in my Cargo.toml, which is quite tedious and has been error-prone in my setup.

At the least it would be nice to able to simply overwrite the version during a build via a CLI flag. Even if the version key didn't have to be present, it would still be ideal to have that so my program could determine the proper version to set in things like a `--version` menu.


I think the most simple solution is `cargo new` setting initial version to `v0.0.0` (instead of `v0.1.0`).


This isn't really an issue with what the default version is, but just how to have no version at all. I think that argument merits its own issue imo.


@Laradius we will check this out in an upcoming bug triage meeting. I'm wondering if the async behavior is somehow affecting this? I'm not sure how the MVVM Toolkit attributes work with this, either. What happens if you call `NotifyPropertyChanged(nameof(IsNotBusy))` after setting it to false?


Turning off "Optimize conversion" worked for me... thanks a lot.


Is not busy property returns true and notifies all bindings about the change.


Just a small note on all of this, recently stumped me and had to use the `-g` flag.

Could we also get a better error message if the transaction runs out of gas? `Transaction Failure: 0x1b07…a3ff` is not the most obvious. I'm down to implement this myself, just curious if others would agree or there's some reason we don't currently do that.


We had the same. We call it a work around, becasue we want to quit using a credential. Our line is.
Connect-PnPOnline -Url $AdminSiteURL -Credentials $credential -SPOManagementShell


+1 on @devanonon's comment, haven't gotten around to opening an issue yet but here's a related repro with other issues: URL


I don't think `useMemo` is need at all, in fact, it's doing the opposite becuase `selector` and `eqlFn` are most likely being updated every render, I believe `useRef` would best serve the purose (storing `prevValue`)

ts
import { useContextSelector } from 'use-context-selector';

export const useSelectedContext = (ctx, selector, eqlFn) => {
 const prevValue = useRef(null);
 const patchedSelector = (state) => {
 const nextValue = selector(state);
 if (eqlFn(prevValue.current, nextValuue)) {
 return prevValue.current;
 }
 return (prevValue.current = nextValue);
 }
 };
 return useContextSelector(ctx, patchedSelector);
};


Found URL and URL and URL

We could replicate a little about the API design here.


When scheduling a new task. The task object is created.

This task object needs to represent a lazy promise.

A lazy promise in this case means that the promise doesn't mean that the execution has started. It's simply queued.

Because tasks are persisted into the DB, it's possible for the PK agent to be restarted, and one may wish to await for a given task ID. That means acquiring a promise for that task ID.

I'm thinking that we can lazily create a promise, that is one to one for each task. Then you can await this promise's result.

If multiple calls to acquiring this promise is made, the same promise is shared among all callers. This means a single `resolve` or `reject` call will send all awaiters.

Here's an example:

ts
async function main () {

 const p = new Promise((resolve, reject) => {
 setTimeout(() => {
 reject(new Error('oh no'))
 }, 500);
 setTimeout(resolve, 1000);
 });

 const f = async () => {
 await p;
 return 'f';
 };

 const g = async () => {
 await p;
 return 'g';
 };

 const r = await Promise.allSettled([
 f(),
 g()
 ]);

 console.log(r);

 // @ts-ignore
 console.log(r[0].reason === r[1].reason); // This is `true`

 // The same exception object is thrown to all awaiters

}

void main();

There are some constraints:

1. You cannot acquire a promise for a task that does not exist in the queue.
2. Creation of the promise may involve hitting the disk if the promise doesn't already exist relative to a task ID.
3. Creation of the promises has to be protected against race conditions with the object locking map pattern.
4. If you get a promise, it is guaranteed that within some finite amount of time that this promise will eventually resolve.

How is point 4 guaranteed? It is only possible to get a task promise in 2 ways:

1. During creation of a new task, the promise can be created afterwards.
2. One can ask `queue.getTask()`.

Now because it's a lazy promise, this could mean that the task is already executed by the time you ask for a promise for the task. This is only possible if the task is no longer in the queue (or is in some invalid state).

In this situation, when asking for the promise, the promise should be immediately rejected. Alternatively since the acquisition of this promise is lazy, one may throw an exception at this point. The point is, if you do get a promise, the promise must be settled eventually.

One of the initial ways to do this is to add an event listener for every task as soon as it is put into the queue. The problem with this is that now you get in-memory space complexity of O(n), where you have 1 listener for every task.

Listeners aren't always necessary, and maybe lots of tasks are put into the queue. In such a case, we can make the promise/listener itself lazy.

getTask(): Promise {
 // if we give you back a Task
 // you can be guaranteed to have it resolved or rejected
 // if we cannot give you a Task, because it's already executed, then we throw an exception at this point
}

Alternatively we do something like:

getTask(): Promise ;

And `undefined` means it's not possible to give you a promise to the task.


Another problem is that exactly is a `Task`? Is a data structure, or is it a promise? Maybe it's both?

The `Task` could be a class instance with enumerable properties, along with a method that allows one to acquire the promise?

I'm considering an API like this:

// true means that you are tracking the task immediately
const task = await queue.pushTask(lazy: true);

// Waits for the promise
await task;

// false means you are not tracking the task
const task = await queue.pushTask(lazy: false);

// Now it may result in an exception if the task is already executed
// This has to distinguish from the task itself being rejected
// ErrorTaskReference
// ErrorTaskRejected
await task;

Something like this means `Task` is in fact an extension of the `Promise`. Or at least a class that has the `then` method. It doesn't actually have to satisfy the entire promise interface. Which would include `.catch` and `.finally`.

Either way, the `lazy` boolean allows one to switch from a lazy promise to an eager promise.

In this sense, lazy simply means whether the task itself is being tracked or not. If it is being tracked, then `await task` is always guaranteed to either result in `ErrorTaskRejected` or the task's result. If it is not being tracked, then it only starts tracking when `await task` is called. Which calls the `then` method. At this point it may throw `ErrorTaskMissing` or `ErrorTaskRejected`... or anything else.

I may have something like:

ErrorTaskMissing - task itself is no longer around, it may already been fulfilled
ErrorTaskReference - task handler was not found
ErrorTaskRejected - task was rejected, see the cause chain


Is there a utility in having `ErrorTaskRejected`? Maybe only to create a set of possible exceptions, as the cause chain can have anything that the task handler itself throws. Otherwise we are just rethrowing the exceptions. URL


So within `Queue`, we will have 2 methods that that are used as part of `start` and `stop`.

protected async startProcessing(): Promise ;
protected async stopProcessing(): Promise ;

Their job is to peek into the job schedule. (I've started to realise that this is more a "schedule" not a queue, since the priority doesn't apply until the tasks are due for execution).

In the job schedule, they find:

* Tasks that are due for execution are dispatched the execution queue
* The next task not due for execution will have its scheduled time set as a `setTimeout`

The `startProcessing` will also be called by the `scheduleTask` method. This is because there be no tasks in the schedule, and upon scheduling a task, we trigger the start processing again.

Calling `startProcess` should be idempotent, as in, if the processing is already started, then nothing happens. It would only matter if the `setTimeout` delay should be made smaller because a more recent task has be scheduled.


The queue now would have 2 "queues".

1. Schedule - this is purely time based, by using `IdSortable` as the `TaskId`, this means all tasks have unique scheduling time (up to the maximum amount of ticks the `IdSortable` is capable of). Which means there will always be 1 task that is in front to be executed. Here priority does not matter, it is simply a matter of scheduling time
2. Execution Queue - this is the queue of jobs that are actually pending execution right now, here is where priority actually matters. This can make use of dynamic priority assuming the number of tasks sitting here is not too much. One can just round robin here, or select the task that has sat here the longest. Perhaps a double index sort between initial priority and time of insertion.

If the task is never fulfilled (resolve/rejected), it should stay in the execution queue (which should still be persistent).


Originally in order to "connect" a lazy promise to a task execution, this was done with a callback that I called a "listener".

Now I realised that the deconstructed promise is itself already a set of callbacks to be executed on the task execution.

This means during actual task dispatch, we could just do something like:

ts
taskHandlerExecution(...taskParameters).then(
 resolveTaskP,
 rejectTaskP
).finally(() => {
 this.promises.delete(taskId.toString() as TaskIdString);
});

That is, the promise that comes from executing the task handler gets connected to the deconstructed promise of the task abstraction.

And at the end, the task promise is deleted once the task is done.

This only occurs IF the task promise was first created. If it was lazy promise, it may never get created in which, and if so, nothing is there to observe/await the task execution. That's fine as the task's side effects continues to be done.


So now I have:

* `Queue` - this is an _encapsulated_ dependency of `Scheduler`
* `Scheduler` - this is the main access to the tasks domain

During the `PolykeyAgent` start process, we expect that the `Scheduler` is going to be a *required* dependency of other relevant domains.

ts
const scheduler = new Scheduler();
await Discovery.createDiscovery({ scheduler });
await NodeGraph.createNodeGraph({ scheduler });
await scheduler.start();

Why not use `await Scheduler.createScheduler();`? This is because, this would require us to inject `handlers` from the very beginning, and these handlers are only known by the other domains. Which results in a circular dependency.

Here we are directly constructing the `Scheduler` and using it like a `StartStop` system.

However it is actually CDSS, as there is a `destroy` method too that removes all the persisted state.


One of the issues with this is that certain methods must be possible by the time it is constructed, but not necessarily asynchronously started...

But at the same time asynchronous start is necessary to do any async setup such as creating the database levels... etc.

So now I'm thinking that `start` and `stop` is still used, and thus `createScheduler` is used, but when `Scheduler.start` just doesn't actually start the processing of tasks, necessitating one to call `scheduler.startProcessing()`.

But then it's not going to be symmetric if the `Scheduler.stop` does call `stopProcessing` but `start` doesn't call `startProcessing`.


The alternative is that we use a callback/hook abstraction similar to the `EventBus`. So now instead function hooks is registered in the other domains first. These end up calling the `scheduler` system.

Another alternative is that `Scheduler` is only `StartStop` instead, but again this isn't nice, if there needs to be asynchronous creation routines.


I've added a `delay` boolean to `Scheduler.start` in order to not start the processing. That way users can start scheduling with `Scheduler.startProcessing()` manually afterwards.

By default the `delay` is `false`, so that by default the processing does already start.

This means in the `PolykeyAgent.createPolykeyAgent`, we should instead see something like:

ts
const scheduler = await Scheduler.createScheduler({ delay: true });
await Discovery.createDiscovery({ scheduler });
await NodeGraph.createNodeGraph({ scheduler });
await scheduler.startProcessing();

When stopping the processing this doesn't actually stop the execution of any tasks, it just stops the processing of the scheduler.


My test results in #454 show that the writing is good but not verification. But that is based on ATmega2560 with xboot, not ATxmega256a3. So ATxmega256a3 may get more issues (need to get some one to help testing as I do not have ATxmega256a3).

* URL


The scheduler doesn't _execute_ the tasks. It _dispatches_ to the queue. The queue _assigns_ tasks to workers, workers is what _executes_ the task. At the same time, the workers may also _pull_ tasks from the queue when they are idle.


The `Queue` will need to work with threadsjs queue too: URL I'm not sure yet if this means our `WorkerManager` will need to be changed to work with the `Queue`, since I don't really want there to be 2 queues. Maybe `Queue` is for managing the queue persistence, while embedding the `WorkerManager` in-memory queue that is one to one for each task that is persisted.

Alternatively we actually don't use `WorkerManager` pool, and instead manage our own "pool" directly.


I haven't completed the full design of `Task` class. But I suspect it needs to be similar to lazy promise here: URL and even threadsjs representation uses a `then` method to allow `await` to work on their objects. Their type is:

ts
/**
 * Task that has been `pool.queued()`-ed.
 */
export interface QueuedTask {
 /** @private */
 id: number;
 /** @private */
 run: TaskRunFunction ;
 /**
 * Queued tasks can be cancelled until the pool starts running them on a worker thread.
 */
 cancel(): void;
 /**
 * `QueuedTask` is thenable, so you can `await` it.
 * Resolves when the task has successfully been executed. Rejects if the task fails.
 */
 then: Promise ["then"];
}


If `Task` is in fact a `class Task extends Promise`, it would have properties that would be enumerable, and properties that are not. We may need to specify this explicitly: URL

Alternative is to form an a plain object like threadsjs does instead of using classes.


Note that since `TaskId` is a `IdSortable`, it's strictly monotonic due to our storing of the last task ID...

But this assumes the last Task ID is always stored, and we are intending on deleting tasks off the schedule once completed. I wasn't thinking keeping historical tasks are useful (except for maybe debugging? Although it seems like it would be dropped in production, and logging/tracing systems should be maintaining the audit log).

This means the last task ID may be undefined. So we would store the last Task ID regardless of whether there are any tasks left in the scheduler.

Furthermore, when the clock is shifted backwards, the time will be incremented by 1 until it is greater than the last time. The 1 is the smallest unit of precision, in which case this would be 1 millisecond.

Afterwards, it will be strictly monotonic ID but have a weakly monotonic timestamp up to 4096 IDs per millisecond. After 4096 it would roll over.

The expectation is that it's not possible to generate more than 4096 IDs in a millisecond, so by that time, the time must have increased by at least 1 millisecond.

Anyway this means we need to store `lastTaskId` into the `Scheduler` under level separate from the `Scheduler/tasks` level.


The `node-forge` has its own workers implementation it doesn't actually use `WorkerManager`. We are looking into refactoring `WorkerManager` with respect to the `Queue` and `Scheduler` implementation in #329. And replacing the crypto is important for our (second, our first one was back in around Jan - Mar 2021 which failed) beta launch, because we want users to be using #168.


Benchmark in js-workers shows that the overhead to call the workers takes about 1.16 to 1.5ms.

A CPU intensive task should be greater than that time to be worth sending to the worker.

However most scheduling work seems it might not actually be CPU intensive. Like NodeGraph and Discovery is mostly IO. I suppose discovery may have have CPU work to pattern match the data to find the right data on the pages it loads, but this should be dominated by the time spent on IO.

Furthermore sending it to a worker can introduce locking problems. The async locks do not work across the worker threads, they only work within the same event loop context. They are not thread-safe nor process-safe.

This should mean that we should not directly integrate `WorkerManager` into the `Queue`, instead individual domains may have their handlers directly pass work to the `WorkerManager`. The `Queue` does not decide this since it does not know the nature of the task. The domain that registers the handlers can decide the nature of the task. So they can execute within the main thread, or send it off to a web worker and await for it.


This means naturally the `Queue` can have either 1 as a concurrency limit or `0` to indicate unbound concurrent limit. With an unbound concurrency limit, it just immediately proceeds to execute everything that is due for execution.

Priority only comes into play with a concurrency limit so that things get put into priority order. Otherwise all tasks will be asynchronous and immediately executed.

The worker's concurrency/parallel limit is not a concern of the `Queue` then.


Perhaps duplicate of URL Please try out latest xcuitest-driver with Appium 2.


The issue has been fixed. Please use the recent driver release (only available as part of Appium2)


As a follow up. In my own app I created a button to change the value of the binding of one of my buttons that's not being disabled from the start as it should. With the new button it acts just like what I described above. I can officially enable and disable my save button by changing the binding value with the new RelayCommand attached to the new button.


I'm wondering if there is any solution to this. Since this triggers for me always. So, I'm not even sure if my `nixos-rebuild switch` does actually complete.

As mentioned in the initial description of the issue:

This never seems to be the case, since the actual message is "Started Network Manager.".
Apart from that I'm wondering why it relies on a log message string, when the status of `NetworkManager.service` would be way less prone to errors.


Sounds good! @mtreinish should a synthesis interface be used for this?


Hi @GrizzlyAK and thank you for your report.

I was unable to reproduce this on a similar setup (Win10, Firefox, Bitwarden 2022.08).

Could it be possible that the popup was still open, a popped out window of the extension was open or Bitwarden was open in the Firefox sidebar? If the answer to any is yes, then this has previously been reported with URL

You also mention changing some settings on Firefox, do you remember which settings you changed, in case the above mentioned does not resolve this.

Please report back and provide further information or close this issue if it has been resolved.

Kind regards,
Daniel


`Could it be possible that the popup was still open`
No.

I do not remember exactly which settings I changed, but I was flipping a lot of them off/on sequentially, although I do believe that all of the settings are as they originally were. I was testing to see if I could find ONE that was causing the issue with Twitter. I do know that I disabled all of my add-ons, except, I believe, BW.

As expected, I disabled the BW add-on, and after re-enabling it, I had to supply the Master PW. I will try to see if I can reproduce this problem. But I can attest that BW was in a "resting" state in my browser overnight (i.e., not open, but previously unlocked and used for logins) and failed to lock during that period.


@altro3 Any plans to add support for `@JsonValue` annotation?


I'm getting the same issue on `expo-cli` `6.0.2` when I run `expo prebuild --clean`


@altro3 Hi! I thought about it, but could not come up with a normal solution to support this annotation. Watch how the library works: the analyzer parses the structure of classes and enums, and can read the annotations that are used there.

So, the problem is: in order to support JsonValue, you need to call the method, i.e. run certain logic to understand what value will be the result.

In general, I'm just not sure that such logic is possible in this library. :-(


@daltonconley Hi! I thought about it, but could not come up with a normal solution to support this annotation. Watch how the library works: the analyzer parses the structure of classes and enums, and can read the annotations that are used there.

So, the problem is: in order to support JsonValue, you need to call the method, i.e. run certain logic to understand what value will be the result.

In general, I'm just not sure that such logic is possible in this library. :-(


@umnex @timbochamp Just making sure this doesn't get lost in translation, this **works** if we were to use the POSTMAN UI to import, but **doesn't work** via API (no field to turn off optimize conversion. Any suggestions?


I got an N64 digital this week and was finally able to investigate first hand.

I wasn't really a fan of the workaround I made to fix it, the N64 SI is means to have device with open drain IO. So switching to push-pull is not really ideal IMHO.

This is really an issue caused by the N64 Digital mode and I think the fix should be an HW on it.

To fix it I added a 74AHCT125N buffer between the the PIF pin 16 and the N64D ribbon COM pad

This did the trick F-Zero X menu doesn't glitch with BlueRetro and the N64D OSD still work as before.
kicad_qEtttH5Odq

The best would be to design a ribbon with a pad for the tiny 1 gate variant 74AHCT1G125W5-7

PXL_20220813_205732992
PXL_20220813_205811684


Will you please leave the software fix in place for those of us without skills to mod our systems? I would have to pay for this work to be done :-(


Problem is this fix doesn't work for everybody, and it actually break it for some people without a N64D.

Old FW stay available so you can keep what you currently have, and if any major update occur I can always post a special version in this thread


Publishing to `gh-pages` always uses the root because that's the default content location for GitHub Pages sites that use the `gh-pages` branch. Remember that the `gh-pages` branch created using `quarto publish` will have no other content in it so it's not really important that a subdirectory be used


Y'a eu un gros remaniement du code chez HA pour tout ce qui est énergy dashboard et utility meters. Je vais devoir deepdive à nouveau ce code pour bien intégrer.


Yes, it's a big issue, I am struggling for over 1 week though my code has a problem. then I read this here which is the same of my issue.
I have 2 buttons both of them are getting value by the binding first one is always true whatever I do.
image

really I begin to believe that CommunityToolkit and DotNet Maui are very buggy and it needs a long time to be stable, which pushes us to move to other languages, really sorry to say that.


You haven't demonstrated that this is in fact a bug in the MVVM Toolkit whatsoever yet. As far as I can see, it's not.

It might be a bug in MAUI, yes, and for that this is the wrong repo. Have you opened an issue on the MAUI repo too?


I've experienced this once so far (this is how I found this bug).
BW 2022.8.0
FF 103.0.1, 64bit, Fedora

When this occured I had not changed any FF settings, or done any changes to extensions. I just noticed that the extension was still unlocked when it should not have been. Manually selecting "Lock now" from the settings menu also did not lock the vault.
I had unlocked the vault, and used it, I believe, only in private windows, through the Right click->Bitwarden->Auto fill functionality.
I've not been able to reproduce this so far, but if it ever happens again, are there logs/debug information that I could collect?


@Sergio0694 I think u have your point, but really it is disappoint us when we face simple issues that should not exist or miss essential features.
On the other hand, sharing our code for some private software is not easy as well too, I hope u understand the situation.
anyway a big thanks to the contributor for their great work, and I am sorry if I show a misunderstanding.


to be more silicification, my problem is the button can't disable itself from the C# code.
and sometimes from the other buttons as well.


Hi
I have already posted this at another repo
 URL
my problem is the button can't disable itself from the C# code.
and sometimes from the other buttons as well.
any guide pls, my whole work is stope at this stage.


@pierre-wehbe have you tried openapi-to-postman as a workaround?
 URL

You should be able to set `optimizeConversion=false` that way I want to say!


I have started experiencing this issue recently.
BW: 2022.8.0
FF: 103.0.2, 64bit
System: macOS

I have the settings to lock from the day one & it used to lock automatically after inactivity. Now it hasn't locked from 2 days. "Lock Now" failed for me as well.


I just got an ATxmega32A4U breakout (from MCUZone) and there is no issue to program the flash using AVRISP mkii clone. And the device works fine after the programming (it has two buttons and two LEDs).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude.exe -c avrispmkii -p x32a4u
-U flash:r:atxmega32a4udemo_mcuzone.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9541 (probably x32a4u)
avrdude.exe: NOTE: Programmer supports page erase for Xmega devices.
 Each page will be erased before programming it, but no chip erase is performed.
 To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude.exe: reading flash memory ...

Reading | ################################################## | 100% 0.67s

avrdude.exe: writing output file atxmega32a4udemo_mcuzone.hex

avrdude.exe done. Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude.exe -c avrispmkii -p x32a4u -e

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9541 (probably x32a4u)
avrdude.exe: erasing chip

avrdude.exe done. Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude.exe -c avrispmkii -p x32a4u
 -U flash:w:atxmega32a4udemo_mcuzone.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9541 (probably x32a4u)
avrdude.exe: NOTE: Programmer supports page erase for Xmega devices.
 Each page will be erased before programming it, but no chip erase is performed.
 To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude.exe: reading input file atxmega32a4udemo_mcuzone.hex for flash
avrdude.exe: writing 36786 bytes flash ...

Writing | ################################################## | 100% 3.00s

avrdude.exe: 36786 bytes of flash written
avrdude.exe: verifying flash memory against atxmega32a4udemo_mcuzone.hex

Reading | ################################################## | 100% 0.67s

avrdude.exe: 36786 bytes of flash verified

avrdude.exe done. Thank you.


@KazuCocoa When I try set location on Appium2 this issue appear, do you have any advice?

Screen Shot 2022-08-18 at 16 47 13


### Website
 URL

### GitHub cli/cli repo
Check the comments made by @heaths on ticket #3488


It looks like Apple has excluded pyobjc from the standard python deployment
We need to avoid python usage in general for such scenarios


Running `gh help template` (or maybe "templates") will show you lots of information with examples. `gh pr list --help` should say that like I know other commands do. Does it not?


@LangLangBart thanks that's helpful, I didn't find it

@heaths neither `gh help template` nor `gh help templates` does anything useful for me. Aha, but combined with what @LangLangBart pointed out, I am guessing `gh help formatting` is what you had in mind?

As it is `gh pr list --help` does not mention this or anything like it. And e.g. `gh issue list --help` also lists a `--template` option, but again without any examples or pointers where to find out more.

If

 -t, --template string Format JSON output using a Go template

was changed to, say

 -t, --template string Format JSON output using a Go template, for more details consult `gh help formatting`

or if those help pages just would mention this at the bottom, that'd be swell


@fingolfin Thats seems like a good idea. Will you make the PR ?

___

Once you have selected your values for your `--json` flag and made them pretty with `--template`, you can then pass your command through fzf for an interactive experience.

Take advantage of the environment variable `GH_FORCE_TTY`, to enable terminal-style output even when the output is redirected (see `gh environment` for more details about it).
### Example:
#### Code

zsh
# .zshrc gh pr list command extended with fzf, see the man page (man fzf) for an explanation of the arguments.
function ghpr {
 [[ ! "$(git rev-parse --is-inside-work-tree)" ]] && return 1
 GH_COMMAND='gh pr list --state open --json number,author,additions,deletions,updatedAt,title --template "
 {{- tablerow (\"PR\" | color \"blue+b\") (\"LAST UPDATE\" | color \"blue+b\") (\"AUTHOR\" | color \"blue+b\") \"\" \"\" (\"TITLE\" | color \"blue+b\") -}}
 {{- range . -}}
 {{- tablerow (printf \"#%v\" .number | color \"green+h\") (timeago .updatedAt | color \"gray+h\") (.author.login | color \"cyan+h\") (printf \"+%v\" .additions | color \"green\") (printf \"-%v\" .deletions | color \"red\") .title -}}
 {{- end -}}" --search'
 FZF_DEFAULT_COMMAND="$GH_COMMAND ${1:-\"\"}" \
 GH_FORCE_TTY=100% fzf --ansi --disabled --no-multi --header-lines=1 \
 --header $'CTRL+B - Browser | CTRL+D - Toggle Diff | CTRL+X - Checkout\nCTRL+E - Edit | CTRL+I - Toggle Info | CTRL+Y - Comment' \
 --prompt 'Search Open PRs >' --preview-window hidden:wrap \
 --layout=reverse --info=inline --no-multi \
 --bind "change:reload:sleep 0.25; $GH_COMMAND {q} || true" \
 --bind 'ctrl-b:execute-silent(gh pr view {1} --web)' \
 --bind 'ctrl-d:toggle-preview+change-preview(gh pr diff {1} --color always)' \
 --bind 'ctrl-i:toggle-preview+change-preview(gh pr view {1} --comments)' \
 --bind 'ctrl-e:accept+execute(gh pr edit {1})' \
 --bind 'ctrl-x:accept+execute(gh pr checkout {1})' \
 --bind 'ctrl-y:accept+execute(gh pr comment {1})'
}

#### GIF
In the example I used `nano` as editor to write the comment, but you can set your own with `gh config set editor ...`.


Probably a M size issue (up to 6 weeks), and it is not urgent if not something else goes wrong. We should look at it as an improvement for next quarter, and evaluate if there is any overlap with other initiatives around inter-partitions communication, i.e. switching to gRPC.


Right now the only difference between the MSI and EXE options provided by this project are the system service and the firewall rules (plus any intrinsic MSI behaviour).
Is the EXE not an option for your use case?


What happened to the Bitwarden browser plugin? Not only will my BW client in Firefox no longer lock after the timeout has lapsed, but it won't lock using the Lock Now command in Settings either. I've also noticed that Search is fracked and returns NOTHING when entering anything.

For example, I search for "github" and...

image

and I just used it to log into to Github to post this! You can see, the little "1" on the BW badge indicating that Github knows it's there yet... 🤷♂

I'm quickly losing confidence in the security of BitWarden. I hope this can be resolved soon. None of these issues affect the Desktop App. It locks after the timeout and Search works fine. Is anybody seeing this in any other browsers than Firefox?

 Is there a way to install a previous version in FF, maybe?

I saw there was an "Info Needed" tag added. What Info do you need? I thought this would get a little more attention.


@daltonconley I have good news for you. I implemented JsonValue annotation support :-). We are waiting for the merge of my changes and the new release (see URL


Thank you @mykola-mokhnach setLocation function is working well on MacOS latest version (12.5.1)


to check if Formula has been updated in order to tackle the issue for Low Liquidity Pools


I think I'm running into this.

`systemd-networkd-wait-online.service`

Aug 22 08:38:49 erin-laptop systemd[1]: Starting Wait for Network to be Configured...
Aug 22 08:40:49 erin-laptop systemd-networkd-wait-online[26249]: Timeout occurred while waiting for network connectivity.
Aug 22 08:40:49 erin-laptop systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Aug 22 08:40:49 erin-laptop systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Aug 22 08:40:49 erin-laptop systemd[1]: Failed to start Wait for Network to be Configured.

It only happens after I've connected my USB-C dock with an ethernet connection at least once after boot. (Note: I'm running tmpfs on root, so my system should "forget" everything about my dock on reboot.)


Now that I'm back at a workstation, running `gh issue list --help` does show:

`gh pr list --help` shows the same thing:

Given I was on my phone with no easy way to look up, I misremembered "template" (or variant) instead of "formatting", but that's what I was trying to remember.

If the maintainers are good with adding text to the individual usage line, do it at the following locationand it'll apply to all commands using it: URL


It seems as as long the command method with the [RelayCommand] is synchronous, all works fine. When using an Async command, the button stays gray after the first click (although it's clickable as expected). Only on Windows, not in Android.


We decided not to bother with preventing resource starvation, however an idea is like this.

1. Take advantage of DB's natural key ordering.
2. Create a bimap index of Priority/Timestamp -> Task Id AND Timestamp/Priority -> Task Id
3. Now we can iterate task ids based on 2 compound indexes: highest priority + earliest timestamp AND earliest timestamp + highest priority
4. Use dynamic programming/kinetic priority function that iterates through both sublevels (indexes) simultaneously to fill up a fixed concurrency pool (if unlimited, this policy is unnecessary, just iterate through as fast as posssible)

Simultaneous iteration that uses the timestamp to weight the priority, where the timestamp delta starts from 0 and goes towards infinity. Once could say that this multiples the priority based on a "rate". A delta of 0 multiplies by 1. A delta of infinity multiplies by infinity. Therefore the rate produces a multiplier between 1 to infinity.


Closing this out as @vorporeal made a bunch of improvements to our text rendering. Please reopen if you are still seeing blurry fonts!


Hi @5hv5hvnk,

Thanks for flagging, I will mention to the team!

I will leave this issue open and report back :)


Hi,

I have linked the issue to a PR that was working on an implementation for `ivy.flatten`. Once this PR has been merged this issue will be closed.

Thanks for Flagging!


I would be thrilled for better docs around this and am cool with heaths's suggestion. I would also be fine with further additions added to `gh help formatting` if there are ways to make that doc more helpful.


I updated the admin page to vue here URL , would be great if someone could give it a review


Like @GrizzlyAK, my FF Lock Now button wasn't working, and toggling extension enabled fixed it.

Like the others, this morning I experienced an unlocked vault without re-entering my password. Vault timeout set to 1 hour.


@djsmith85 I see this error in my browser console from `vaultTimeout.service.ts`:


<img width="992" alt="Screen Shot 2022-08-25 at 7 33 40 PM" src=" URL


@altro3 Was pleased to see the above PR as I have a similar issue with @JsonValue which I expected would be fixed with your latest commit. I've built 4.5.0-SNAPSHOT from your PR and updated the dependency of my minimal recreation project locally and there's some improvement as it seems to obey the @JsonProperty annotation but still doesn't work for me with @JsonValue.

Interestingly I now get the warning:

Note: Generating OpenAPI Documentation
{path omitted}.../swagger-enum-gen/src/main/java/com/example/ResponseEnum.java:8: warning: Can't find enum class com.example.ResponseEnum

when running, but it still outputs the yaml with the Enum names (and one JsonProperty value).

The checked in bug recreation project above is still on the default dependencies rather than on your snapshot version. Please shout if I can be of any assistance. Thanks very much for your efforts!


You may install the buildpack on the server using github repo: URL


@dclarke18 @daltonconley I also tested this functionality. Well, unfortunately this functionality cannot be done in any way. I rolled back my changes because my solution only works at the testing level. The problem lies in the limitations of Java itself. Java, when executing annotation processors, does not load classes from the main classpath and does not provide access to the source codes of these classes. Those. the annotation processor only accesses the structure of the classes, but cannot call methods from these classes or read the method bodies in any way. So the only solution for enums is to put a JsonProperty annotation on each enum value.

Processing JsonValue at the annotation processor level is impossible to do :-(


I have exactly this problem on dedicated server (32 core CPU + 16 GB Ram)


Can you check the audio delay on

 URL

and let us know if you encounter the same delay. You can use

 URL

to join with multiple users.


This does not always happen to everyone! But I have a session recorded on my server that shows it happening to one person in a session with 6 people.


I re-wrote a dependency library based on the Camera package to solve the front-facing camera flip problem, you can see:
 URL
 URL


I re-wrote a dependency library based on the Camera package to solve the front-facing camera flip problem, you can see:
 URL


Has there been any progress in adding SPM support? Is this something anyone would be interested to pick up?


Note that 16.17 has proper support for ed25519:

image

Current latest 22.05 is still 16.16.


Hi @paulmitchell507 ,
Thanks for logging the issue and will get back to you with proper response soon.


Hi @frank-brandt ,
Thanks for raising the issue and will get back to you with proper response soon.


I think that's the reason for the crash: URL

Closing this issue. Sorry for incorrectly reporting it here.


Was wrong about it. Upgrading Electron to the latest doesn't fix the problem. The problem is somewhere else.


closing as asymmetric adds are currently disabled. Flat fees is introduced in order to re-enable asymmetric adds. The issue is not expected to appear once asymmetric adds are re-enabled


Yes. I will start working on building a reproducible demo.

Did you try to import and call an electron module in a WebWorker (loaded with `type: "module"`)? Does it work for you?


`type: "module"` will be supported in `v0.9.3`, coming soon. 🚚


I also have encountered some problems with the changes introduced in commit 830e84a79c2c32b57824a227bc88b95406c3944d.
It forces Conan to always be called with a build profile. This changes some of the internal behavior of Conan and prevents the imports() method from copying files of private requirements of my top-level package (I am not sure if this might be a bug in Conan or if it is desired behavior, haven't looked into it, yet)

I have a implemented a workaround that removes the "default" base profile when creating the Docker runner. This should now behave like the non-Docker path (pull request #604)


I found the solution. Here are the steps that I took:
1) I created a new secret in the IceBreaker OAuth App in Azure AD
2) I granted myself permissions in the IceBreaker key vault to edit secrets
3) I added a new version with the new client secret for secret MicrosoftAppPassword.
4) I removed my permissions in key vault.
5) To test open the logic app and click run or choose adapt the schedule


@paulmitchell507 Sounds like you have the same problem that I had. Check my steps to resolve the problem in URL


The Release 0.38.1 includes the hotfix the PR #604. Please, update your local copy: URL


Hi @paulmitchell507 ,

- It seems that new secret has been created. To confirm whether it has been updated or not. Go to keyvaults -->Secrets-->if don't have permission to view-->Go to Access policies-->Select checkboxes as shown below.-->Add you Id under principal tab-->Create-->Go to Secret whether the new secret has been applied or not.

<img width="899" alt="image" src=" URL

image

image

- To test open the logic app and click run.

Hope it helps


@mjibson has wanted this for a while! One nit: I wouldn't call the new proposed binary `adapterd`, since most of the "adapter" layer will still live in `environmentd`. @mjibson has proposed `pgwired`, which I like! Though if these handle HTTP connections too... I'm sure there's an even better name we could come up with.

A few things to consider:

 * How do we automatically scale `pgwired`? This is the core problem that we need to solve to make this approach worthwhile, IMO. If there's one `pgwired` handling all client connections, we're strictly worse off than before, as far as I can tell, because we've got an extra network boundary that's not in service of scalability or fault tolerance.
 * Our cloud infrastructure layer is not yet equipped to handle multiple `pgwired`s. With multiple `pgwired`s, we'll need a load balancer. (Right now we're able to provision environments pretty quickly because we get away with _not_ provisioning a load balancer.)
 * The current versioning and deployment scheme involves force-upgrading all binaries to the same version. That's going to frustrate the goal of restarting `pgwired` less frequently than `environmentd`. We'd need more granular versioning, so that `pgwired` is only restarted when the `environmentd`—`pgwired` protocol evolves.

----

Probably s/`storaged`/`persist` here?


We can now use mitoteam/jpgraph, which is maintained in Composer, in place of jpgraph/jpgraph. Closing this issue.


Great! So, for now, there is no need for me to create a reproducible demo, right?


<img width="1340" alt="image" src=" URL
There's something wrong with building esm support, I'm trying to Debug Vite and it's confusing.
Or I'll use Rollup to get around this.
Sorry for the wait.


Hello @shawnWXN,

Please use English and provide more information about the issue.

If the localization is incorrect, then please suggest a better translation.


A little context (it might be useful for you):
- I don't get any error from Vite when using `type: "module"` when creating a new WebWorker.
- `import something from 'module'` doesn't work if I don't set the `type: "module"`.

I also may use WebWorker without `type: "module"` but I'm not sure how should I import stuff. Maybe it's not possible?


`type: "module"` doesn't work with Electron, probably because Electron doesn't support ESM well.
I built the ESM version of the plugin, but Electron doesn't work when `type: "module"` is enabled.

Support `type: "module"` branch 👉 vite-plugin-electron/tree/type-module

Run setup

bash
cd playground/usecase-in-main

npm run dev

Errors

log
App threw an error during load
Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/atom/Desktop/github/vite-plugin-electron/playground/usecase-in-main/dist/electron/main/index.js from /Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js not supported.
Instead change the require of index.js in /Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js to a dynamic import() which is available in all CommonJS modules.
 at c._load (node:electron/js2c/asar_bundle:5:13343)
 at loadApplicationPackage (/Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js:110:16)
 at Object. (/Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js:222:9)
 at c._load (node:electron/js2c/asar_bundle:5:13343)
 at Object. (node:electron/js2c/browser_init:185:3104)
 at ./lib/browser/init.ts (node:electron/js2c/browser_init:185:3308)
 at __webpack_require__ (node:electron/js2c/browser_init:1:128)
 at node:electron/js2c/browser_init:1:1200
 at node:electron/js2c/browser_init:1:1267
 at c._load (node:electron/js2c/asar_bundle:5:13343)


I'm creating the WebWorker from the renderer process. Is this relevant?


As do NARA over in the United States - their "Citizen Archivist" programme has volunteers doing a similar task, and makes use of tagging. They even have "missions" which are a targetted way of prioritising certain activities. Maybe there is merit in us looking at this?

 URL
 URL


We have discussed internally, and we have accepted that this function should be added to Ivy's functional API. This item has been added to our ongoing Ivy Extension issue. Therefore, this issue will now be closed. Thanks!


I'm in the process of swapping from webpack to vite, and one of the issues I have atm is the production build is crashing when trying to use nodejs modules, but works fine in development.

e.g.

`index.ts`:

import TestWorker from "@/workers/test-worker?worker";
const testWorker = new TestWorker();

`workers/test-worker.ts`:

import * as path from "path";
console.log(path.parse(__dirname));

I have `nodeIntegrationInWorker: true`, and as I said it works fine in development, but in the production build it doesn't recognise the path module and the built worker file looks a little sketchy:

image

Is this the right issue to report this? Am curious if the work you're doing will fix this or if my issue is unrelated.


This project is just for my personal interest, I have not tested many cases, such as `web worder`.
By the way, Vite behaves very differently during development and build, so I run into really tricky issues a lot of the time.


Hello @KaelWD,

In Vuetify 2, Select does not behave the same when I use a blank string as model value: URL


Sorry, power outage deleted my response.

v3 keeps items defined in the model (#4000), so this is more like URL
An initial value of `null` has the behaviour you want.


It has been one year, did anyone found out how to resolve/workaround this bug that'd be great, Im sure this is one of the major bugs.


Thanks for the response.

Now, we are using null for the initial value.


But since it was working properly till a few days ago, what is caused the problem?


hmm, missed "til a few days ago" part in the original description.
Still might have to do with the PR I mentioned since some of the issues it tackles are intermittent by nature.


Hi @paulmitchell507 ,
It seems that the secret ID has been updated instead of secret value. Could you please update with secret value(highlighted one).
<img width="725" alt="image" src=" URL


It's an example of the problem:
 URL
(Note that the recording starts when the timer is 7 seconds. and in the video, it's shown that I press the stop and it says the meeting is no longer being recorded, but since the video is too behind, It's even shown after that I end the meeting!)


Done. Here is the repo: URL

The important part is in `renderer/main.ts`:

ts
document.body.addEventListener('click', () => {
 new Worker(new URL('./worker.ts', import.meta.url), {
 type: 'module'
 })
})

Clicking on the "hello" text will run the code and the `BrowserWindow` will crash. You can open DevTools before you click the "hello" text so you can see DevTools shows a message as well.


I think I was able to reproduce this issue with BBB 2.6 demo server. Sounds to be a bug! @prlanzarin

It is the result: URL

**steps:**
 - start the meeting
 - share your screen
 - wait for about a minute
 - start recording
 - after a little, stop the recording and close the room as fast as possible!


:wave: hey there, please refer to URL as the source of truth for supporting more regions than just EU and US. We are closing this issue to consolidate to the single issue.


I re-created a secret value and updated the MicrosoftAppPassword in the keyvault but I still see the same error. Do you think MS support can help?


Hi Tom, right now such a capability does **not** exist. However, I'd like to add new functionalities (where possible) based on the need.

OCSMesh uses `Jigasw`'s Python wrapper as the meshing engine, and as far as I know `Jigsaw` doesn't accept custom error function. So the best way I can think of to add this functionality is to fiddle with the size function. A method can be added to the `hfun` objects to make sure the specified size is within a given bound or criteria. Right now size constraint based on the topobathy exists; it shouldn't be too hard to add one that gets a reference velocity and timestep to constraint based on CFL as well. For example depending on the model being implicit or explicit you'd do something like:

python
hfun = ...
hfun.add_contours(...)
...
hfun.add_cfl_constraint(cfl_upper=1 , cfl_lower=-np.inf, ref_vel=10, ref_dt=150, rate=0.1)
...

which means *after* applying all refinements, it will check the specified sizes and if it falls outside the specified CFL bounds it will modify it and for regions adjacent to the adjusted location it will propagate based on the distance from the adjusted location.

Do you have a specific way of achieving the CFL check in mind? Is what I described above useful for your use case?


Hi Soroosh, thanks for your quick response.

That's a good suggestion you've made. I wonder how dependent it would be on the reference velocity and dt values that are chosen.

Having read the documentation of OceanMesh2d, they deal with the CFL number not by changing the grid size, but by suggesting the timestep for the model run using the minimum current number. This could potentially be an easier solution to changing the mesh itself?

They also also estimate u as a function of sea surface elevation and depth (|u| = ssh/sqrt(g/h)), taking ssh as 2m which is probably suitable for most regions. I've included an image of the documentation as they describe it better than I can .

Having some form of CFL check would be extremely useful. I'm looking to generate meshes over large basins, so manually estimating the CFL number for selected points isn't really feasible.

image


At a minimum we need to clarify

* What circumstances might we hide material or destroy data on their requests
* Policies on re-embargoing. Need technical measures ( URL first, but even if they exist it needs to be clear in UI and/or help pages what the expectations should be.


URL would be a good place for this.

Need to also check T&C's.


@TPCollings, I think it really depends on what solver you're using and how you want to set it up; for example for implicit solvers we might actually have to be careful for Courant number to remain above 1. In either case, one either has to choose what their Courant number is and what time step they'd like to use, then find the mesh size from it; or already have the mesh size and Courant number and would like to know what time step is suitable.

- For the first functionality it makes sense to have a method that manipulates the *size function* - as described in this comment - where it gets input η or velocity reference as well as dt and the bound on Courant number.
- For the second functionality it is more sensible to add a method to *mesh* object. So that when you already have a mesh, pass in the bounds on Courant number and get an estimate for dt.

@WPringle I haven't really worked with OceanMesh2D, can you please comment on this? Does what I'm saying make sense based on your experience?


@astoilkov 👋
Eventually, I found that using `ipcRenderer` in a Web Worker would cause the Electron-Renderer to crash. This is confusing!
 URL
I submitted a PR to try to bypass access to ipcRenderer.


Great, thanks! Are you going to implement a fix in electron-vite-renderer?


This problem may come from Electron itself, what we can do is to hide `ipcRenderer` when using electron module in Web Worker. Not sure if this is the right thing to do or if we need to state this in the README.md. 🤔


@SorooshMani-NOAA Yeah I see your point. I'll be using Schism (more specifically PySchism), so I believe the minimum Courant number shouldn't be less than 0.4 for most modelling applications. How long do you think it might take to add the first functionality described above, which involves manipulating the size function?


Maybe not a bug but it took me days to discover this problem and understand why our Web Worker is crashing. Maybe you can just handle the error and throw a user friendly error.


I think you can safely hide `ipcRenderer` in Web Worker because it seems, as I learned just now, that you shouldn't access it and the behavior is expected because there isn't a `webFrame` inside of workers — URL


Please see related comment on #7489, copied below:

---

There seems to be some confusion that is related to the closing of the following issues:

 URL
 URL
Please note: This is not a an update of the status of this issue (closing or opening). The reason for the consolidation is that we now have a proliferation of different regional issues being raised by users. It doesn't make sense for users to directly raising issues about specific required regions, as when it comes to rolling out new regions we'll need to review:

Costings
Latencies
Current + predicted future usage of Gitpod
...and many other factors.

It makes sense for this conversation to happen in a single issue, which is this one. Please continue to share any thoughts or feedback. We'll look to update the description soon as a consolidation of current thinking, as there are now multiple region related issues with many comments.

Thanks all 🙏


Please see related comment on #7489, copied below:

---

There seems to be some confusion that is related to the closing of the following issues:

- URL
- URL

Please note: This is not a an update of the status of this issue (closing or opening). The reason for the consolidation is that we now have a proliferation of different regional issues being raised by users. It doesn't make sense for users to directly raising issues about specific required regions, as when it comes to rolling out new regions we'll need to review:

Costings
Latencies
Current + predicted future usage of Gitpod
...and many other factors.

It makes sense for this conversation to happen in a single issue, which is this one. Please continue to share any thoughts or feedback. We'll look to update the description soon as a consolidation of current thinking, as there are now multiple region related issues with many comments.

Thanks all 🙏


Another idea: You can throw an error if someone tries to access an ipcRenderer property (using a Proxy) and explain the issue. This will be very helpful to other users.


Yes there are two ways to do it, both we try to do in OM2D. First is try to manipulate the size function beforehand estimating what the Courant number would be based on size function and depth there and what timestep you want to use. Second way is to post-process the mesh based on final Courant number by deleting or adding in new points and locally remeshing. We did add the second for SCHISM type meshes where we want to provide a lower bound on Courant number, and so therefore we try to add in more points, as well as deleting points to make the upper bound on Courant number which is usually more important for ADCIRC.


@SorooshMani-NOAA That would be great thanks. There's no super urgency, but it would be great to have it before the end of the month. Cheers!


Had issues with 2.5.5 as well. Recording webcam and audio were extremely out of sync, and during the meeting everything seemed fine, mostly. For one test recording, for example, the webcam video stopped long before the audio did. Reverting to 2.5.4 was our solution.


I think this has significantly improved the debugging experience. If these are not present, it is close to impossible to tell what exactly happened in the failing container / why did a certain CLI command fail.

In the long term, we should instead pipe logs from each container to a file and preserve them as artifacts after running the CI job. This would remove the need for the extra logging. However, in the meantime, I think having more logs is better than having none


Might not be as simple as adding `s.T().Parallel()` due to the need for synchronizing some shared variables.