Update README.md

fixing little mistakes in readme

Duplicate of https://github.com/ankhers/mongodb/pull/162

Closing because of duplication. Thank you.


Linting temporary file breaks relative imports for dartanalyzer

Currently, ale is coping the current file to a temporary file.  This is problematic with dartanalyzer because it can no longer resolve relative imports.
For example, if I have something like
import '../shared/book_model.dart';

At the head of a file, it will (currently) always raise an error, complaining that the target of the URI doesn't exist, even if it is perfectly valid.
This means that I have to write all of my imports using absolute imports:
import 'package:my_package/shared/book_model.dart';

This is a little inconvenient, especially when one has hundreds of imports across an entire codebase.  Is there any way of doing the checks in-place?  If not, it would be nice to have a short explanation of this in ale-dart-dartanalyzer help page.

Maybe we should just change the linter to only check files on disk instead, and give up on linting while you type with dartanalyzer then. The gold standard for me is eslint with its --stdin-filename option. Something like that would probably be required here.

Now ALE will only check the file on disk for dartanalyzer, so relative imports ought to work, but you can't check for errors while you type.

If support is added for the Dart LSP, that might be useful for linting while you type. See here: #1006

Thank you!  I'll be excited if the LSP is implemented for ALE.  This will be more than fine for the time being, though, since dartanalyzer is pretty slow.


Automn 2022 refresh 🍂

Package refresh including:

CI on node 16+18
refreshed package-lock, fixing vulnerabilities without major lib upgrades
improved install safety net
license year bump

Released as v<IP_ADDRESS> (shasum: 29345de5b571f011cf501d9823527c47e649a147)


Open connection on mobile device not practical

To open a connection in the matches tab, in a desktop application user usually uses mouse over the match and then sees that he/she can request a connection or rate the connection as not good. On a mobile device this does not work, that makes it almost not possible to open connections with other needs on mobile devices

this is already better now


Add preset (and field?) for crossing=no

To map situations:

Where crossing is not suitable, possible or legal. Used at places where one would expect a crossing, but where there isn't one.

Suggestion from https://github.com/openstreetmap/id-tagging-schema/pull/590#discussion_r979270139
Might also be useful as a field for certain road vertices (e.g. to mark traffic signals where crossing is not allowed)?

See also:

#548


Fix bulkValue check

Reset _bulkValue to 0 after initial size check

This bug slipped in post code review. We have decided to regress to the previous behavior detailed in
https://github.com/hCaptcha/hmt-token/pull/15
What do you think about it? . While we appreciate commit we already emit transfer events when individual transactions complete.

Cool. Firing events for each tx does make more sense.


SocketAbstract class>>#onShutdown improperly stripped

I've created an executable based on Dolphin 7.1.20 (thank you for the guidance to steer clear of master!). My basic smoke test went well till I closed the app and I got "SocketAbstract class does not understand #onShutdown". I looked at the deployment log and it was listed as removed because it was not sent. I added a sender and it is no longer stripped. Perhaps the method should be in a "do not strip" category?

The "must/must not strip" categories are a bit of a blunt instrument, so I like to try and understand why something is gone (or not gone) before wielding them
In this case the issue is that the only reference to onShutdown in the image is the class initialize method of SocketAbstract, because it sets up the event handler. Class initialize methods are normally removed at deployment time, so that would have left onShutdown unreferenced. I'm not sure what referenced it before, but whatever it was it must have been removed from 7.1 at some point. Usually in these cases I wield the blunt categorisation tool to force the class initialize method to be kept as there are often other event registrations.
BTW: You must be using the old Sockets Connection package that implement asynchronous operations using Windows messages. You might want to switch over to the "newer" Dolphin Sockets package. I was intending to remove the old package in the next version (that I think really ought to be called 8, rather than 7.2, given the level of change). It will still be in the repo, but no longer loaded in the image.


callback-binding error on _.zipWith

Hi,
Thanks for this plugin, we want to use it but encountered several issues as the following,
This sample code from _.zipWith lodash docs:
_.zipWith([1, 2], [10, 20], [100, 200], function(a, b, c) {
  return a + b + c;
});

Reports an error:

Do not use Lodash 3 thisArg, use binding instead (lodash/callback-binding)

Seems to be a problem with analyzing the (…Array) argument

On it. If there are other issues, please report them and we'll make sure to fix them.

Thanks for the quick fix!

Equal situation with sortedIndexBy:
let idx = _.sortedIndexBy(collection, value, 'property');
// Do not use Lodash 3 thisArg, use binding instead (lodash/callback-binding)

in docs: _.sortedIndexBy(array, value, [iteratee=_.identity])

Fixed the bug with _.sortedIndexBy in v1.8.4.
Thanks for the heads up!


add: prototype implementation of tarp in sbi

What does this implement/fix? Explain your changes
Tarp is a diagnotics method, which can help identify over-/underdispersion and bias in trained neural posteriors. The corresponding paper is located here:
https://arxiv.org/abs/2302.03026
the repo code for numpy is here:
https://github.com/Ciela-Institute/tarp/
Does this close any currently open issues?
No, this was part of the Mar 2024 SBI hackathon in Tübingen
Any relevant code examples, logs, error output, etc?
Not yet, I am trying to reproduce the examples given in the paper. At a later point in time, I'd like to bring the tests as well as a tutorial in line to what is available with sbc.
Checklist
Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask. We're here to
help! This is simply a reminder of what we are going to look for before merging
your code.

[x] I have read and understood the contribution
guidelines
[x] I agree with re-licensing my contribution from AGPLv3 to Apache-2.0.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have reported how long the new tests run and potentially marked them
with pytest.mark.slow.
[x] New and existing unit tests pass locally with my changes
[x] I performed linting and formatting as described in the contribution
guidelines
[x] I rebased on main (or there are no conflicts with main)

Note, I am stopping work on this PR for the time being. I ran into issues reproducing the tarp paper: https://github.com/Ciela-Institute/tarp/issues/8
Once they are resolved, I'll continue working on this.

Dear @janfb and @JuliaLinhart,
an alpha version of TARP (arxiv) as a SBI diagnostic is now ready from my point of view. I'd love someone of you to have a look. There are two files that I added sbi/diagnostics/tarp.py and tests/tarp_tests.py. The last unit test also documents how tarp would be used with SBI posterior predictions.
Feel free to have a look.
I'd have some questions though:

at this point, the tarp coverage estimates are returned as raw numbers, i.e. I don't perform any hypothesis testing on them, should I add (i.e. a KS test) that?

the TARP diagnostic class currently implements a run and a check function (to be aligned with the SBC code); the run function practically doesn't do anything TARP related but rather draws samples from the posterior, check actually performs tarp without any hypothesis test. I'm unclear if we should rather have run to compute the coverage stats and check do the hypothesis test for example. What do you think?

the TARP paper also offers a bootstrapped version of the diagnostic, would we want to have that in SBI too?

I think, if TARP is included in SBI, there should be a tutorial about it. I'd rather not make this part of this PR though. Is that OK?

@psteinb just checking in here. Do you plan to continue working on this soon so get it into the upcoming release?
We could also schedule a video call to discuss my points, which could be more efficient then sending another round of comments back and forth?

Sure thing, will contact you directly on this.

As just discussed:

short term goal for this PR is to push TARP to be available in a way that sbc is in sbi
no progress bars
try to reuse plotting functions as much as possible that already exist for sbc

@janfb I refactored the tarp implementation as discussed offline. Feel free to have a look again. Should I add a small tutorial notebook?

Merging this into main for now. The method is working with similar API like the SBC method.
What is missing and post-poned to a future PR:

unify API with SBC
refactor to have most of the logic in a run_tarp method. maybe there is a away to combine it with SBC even
make use of batched sampling
add explanation and code to Diagnostics tutorial

The next PR could come with a bigger refactoring for the SBC methods as well.

Thanks so much for the final commits to push this across the finish line.

Hi @psteinb !
Sorry, I really didn't have the time to look at this PR for now! But I think it's great you took the time to look into and implement this diagnostic! Thank you! I will have a look at it as soon as I can!

No problem @JuliaLinhart and thanks for your kind words. I am happy that TARP is part of SBI now. It is a global method and quite fast. But the details are a bit hard to grasp from my point of view.


[WFCORE-2368] Add description of Elytron ldap-realm.identity-mapping.filter-name default value

Elytron ldap-realm.identity-mapping.filter-name default value gets its default depending on the value of "rdn-identifier" attribute. Since we cannot represent it using set-default, this issue adds the information in the attribute description.
Its default value is assigned in LdapSecurityRealmBuilder.IdentityMappingBuilder#build method.
Jira issues:
https://issues.jboss.org/browse/WFCORE-2368
https://issues.jboss.org/browse/JBEAP-7336

Full integration - Windows Build 3920 outcome was FAILURE using a merge of 5e41aee7236ffe1faa2926beefaeaf343d30deef
Summary: Tests passed: 4110, ignored: 112; swabra cleanup failed (new) Build time: 02:14:50


Prometheus graphs traffic drops regularly

I'm using gnmic to monitor various Juniper MX devices, i'm subscribing to interface metrics and the sample interval is configured as 10s. My output is prometheus which is configured to scrape every 20s.
Once I graph my data, there is a routine drop in traffic across every device and every interface roughly every 60 minutes. At this point i'm unsure if it's something the Juniper device is doing, or something gnmic is doing or where to begin troubleshooting.
Example graphs from 2 different devices, different hardware (MX10k vs MX204) running different Junos software versions.

I would be surprised if this is coming from the routers if it's happening on all devices.
It looks like the period is more like 50minutes.
Could you share the prometheus output config used for gNMIc ? Do you have export-timestamps set to true there ?
I would also look at the promQL expression used in Grafana, I assume it uses the rate() function.
Which interval is used for the rate function? It's usually recommended to use $__rate_interval.

I'd agree they are every 50 minutes. My output config is largely the default
# Configure outputs
outputs:
  prometheus:
    type: prometheus
    listen: :9804
    path: /metrics
    event-processors:
      - interface-descriptions
    service-registration:
      address: <IP_ADDRESS>:8500
      service-address: <IP_ADDRESS>

My promQL expression is using irate vs rate. If I change to rate the dips in the graph become less severe but they are still there. The expression is using $__rate_interval
Example query
irate(interfaces_interface_state_counters_in_octets{source=~"router1|router2", description!=""}[$__rate_interval])*8
irate:

rate:

Maybe worth checking the raw collected metrics over the window where the dip is seen. To check what gnmic actually received from the NE

Could you try with export-timestamps: true ? Without it Prometheus assigns the scrape request timestamp to the metrics, instead of the device timestamp.
The second set of graphs show that the dips are not in sync across devices while maintaining the ~50minutes dip interval, I would then manually check the values sent by the device for potential lower counter values as @hellt pointed above.

So, adding export-timestamps: true fixed the dips in the graph (see below). However, it has also had an adverse impact on the majority of devices whereby the interface metrics are no longer being recorded.

I can't find any reasoning for it. All devices are synced to an NTP time source and have their timezone set to UTC. What's equally interesting is that it only impacted interface metrics, subscriptions to other metrics such as bgp continued to work correctly.
Looking at the metrics exposed by prometheus, it's reporting the same number of samples scraped so my only assumption is that prometheus is dropping them for some reason?

Are the timestamps sent by the devices in nanoseconds ?
Is the prometheus server also synced ?

They are sent by the device in miliseconds - example timestamp<PHONE_NUMBER>000
I confirmed that both the server running gnmic and the server running prometheus are sync'd to the same timesource and the reported time between those servers and the Juniper devices is correct.

By way of a visual example. I have 2 routers in this graph, both in the same physical location, both sync'd to the same NTP time source, both showing the same time running show system status. Both are subscribed to by the same gnmic collector (I run a pair using consul for target registration.
One continued to work whilst I had export-timestamps: true whilst the other did not. Once I removed the configuration, the non-working device started working again.

gNMIc Prometheus output converts timestamps from nanoseconds to milliseconds.
The gNMI notification timestamp should be sent by the device in ns, while Prometheus expects ms.
Can you double check using the cli which timestamp unit the device uses?
If the device sends timestamps in ms, there is a processor to convert them to ns:
processors:
  ts-ms-to-ns:
    event-starlark:
      source: |
        def apply(*events):
          for e in events:
            # change timestmap to ns
            e.timestamp = int(e.timestamp * 1000 * 1000)
          return events

Then add the processor name under the prometheus output:
outputs:
  prometheus:
    type: prometheus
    listen: :9804
    path: /metrics
    event-processors:
      - ts-ms-to-ns # <--new processor
      - interface-descriptions
    service-registration:
      address: <IP_ADDRESS>:8500
      service-address: <IP_ADDRESS>


Stabilize more file operations

For the coin-operated file viewer I need some more advanced file operations as mkdir(), listdir(), deleteFile(), rmdir().
How's the progress with stabilizing these methods? Alternatively I could use the unstable methods from blockstack-storage-js, but it seems that they won't change massively later.

We are going to be dropping support for directories in Gaia v2.  The supported operations going forward will be getFile(), putFile(), deleteFile(), and listFiles().

How's the rough ETA for this? :)

@jcnelson That's an awesome set of operations. Love it.

@vsund I'm aiming for end of next week, fingers crossed.  I'm currently working through this issue, which will set the pace for the remainder of the implementation: https://github.com/blockstack/blockstack-core/issues/556


lntest/itest: resolve mempool flake in multi-hop htlc local timeout test

The test assumed that transactions would be broadcast and confirmed at incorrect heights. Due to timing issues, it was possible for the test to still succeed, resulting in a flake.
The test assumes that Bob will sweep a pending outgoing HTLC and commit output back to their wallet. This commit ensures that these operations are done when expected, i.e.:

Bob force closes the channel due to the HTLC timing out.
Once the channel is confirmed, Bob broadcasts their HTLC timeout transaction.
Bob broadcasts their commit output sweep transaction once its CSV expires.
Bob broadcasts their second layer sweep transaction for the timed out HTLC once its CSV expires.

We can't do exact height values because all the tests are being run on the same chain.

We can't do exact height values because all the tests are being run on the same chain.

Ok. Or write the comments so they include heights relatively to the start height of the test. "We are now at height +50 and the commentment tx should be in the mempool. The htlc expires at +50 also, but we only publish the 2nd level tx after the commit tx confirms at +51. There is a 40 block csv wait, so this 2nd level tx can be swept at +91."
But as said before, it isn't blocking. Just brainstorming about how to clarify the comments, so that not as many questions need to be asked.


quick fix for windows ci

PR as a test (why don't actions run on branches?)
update: it worked!

Sorry for the slight (cough...) delay.
This was due to changes in Github Actions and is fixed by #94 .


brew cleanup removes the current version of portable-ruby

brew doctor output
❯ brew doctor
==> Downloading https://ghcr.io/v2/homebrew/portable-ruby/portable-ruby/blobs/sha256:49847c7a13f7094b211f6d0025900dd23716be07dac894a3d6941d7696296306
Already downloaded: /opt/workbrew/home/Library/Caches/Homebrew/portable-ruby-3.3.3.arm64_big_sur.bottle.tar.gz
==> Pouring portable-ruby-3.3.3.arm64_big_sur.bottle.tar.gz
Your system is ready to brew.

Verification

[X] My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
[X] I ran brew update twice and am still able to reproduce my issue.
[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output
❯ brew config
WORKBREW_VERSION: 0.2.1
==> Downloading https://ghcr.io/v2/homebrew/portable-ruby/portable-ruby/blobs/sha256:49847c7a13f7094b211f6d0025900dd23716be07dac894a3d6941d7696296306
Already downloaded: /opt/workbrew/home/Library/Caches/Homebrew/portable-ruby-3.3.3.arm64_big_sur.bottle.tar.gz
==> Pouring portable-ruby-3.3.3.arm64_big_sur.bottle.tar.gz
HOMEBREW_VERSION: 4.3.5-95-g24f74c0
ORIGIN: https://github.com/Homebrew/brew
HEAD: 24f74c05280870be60168ed7287789e59b9e4ff9
Last commit: 5 hours ago
Core tap HEAD: 39c4d9bb45d8d1e993be50a46390cad92dbabda3
Core tap last commit: 79 minutes ago
Core tap JSON: 06 Jun 19:54 UTC
Core cask tap HEAD: 5d6faad7cfec3b34f25251c2792ab9025807a08f
Core cask tap last commit: 80 minutes ago
Core cask tap JSON: 06 Jun 19:54 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_AUTO_UPDATE_SECS: 43200
HOMEBREW_BAT: set
HOMEBREW_BOOTSNAP: set
HOMEBREW_CASK_OPTS: []
HOMEBREW_DEVELOPER: set
HOMEBREW_EDITOR: nvim
HOMEBREW_FORBIDDEN_OWNER: your Workbrew administrator
HOMEBREW_FORCE_BREWED_CURL: set
HOMEBREW_FORCE_BREWED_GIT: set
HOMEBREW_GIT_EMAIL<EMAIL_ADDRESS>HOMEBREW_GIT_NAME: Carlo Cabrera
HOMEBREW_INSTALL_BADGE: ☕
HOMEBREW_MAKE_JOBS: 16
HOMEBREW_NO_CLEANUP_FORMULAE: zsh
HOMEBREW_NO_INSTALL_FROM_API: set
HOMEBREW_SORBET_RUNTIME: set
HOMEBREW_SYSTEM_ENV_TAKES_PRIORITY: set
Homebrew Ruby: 3.3.3 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.3/bin/ruby
CPU: 16-core 64-bit arm_palma
Clang: 15.0.0 build 1500
Git: 2.45.2 => /opt/homebrew/opt/git/bin/git
Curl: 8.8.0 => /opt/homebrew/opt/curl/bin/curl
macOS: 14.5-arm64
CLT: <IP_ADDRESS>.1.1708646388
Xcode: 15.4
Rosetta 2: false

What were you trying to do (and why)?
Run brew cleanup to see if it would remove older installs of portable-ruby. It did, but it also removed the version of portable-ruby currently in use.
What happened (include all command output)?
It deleted the latest version of portable-ruby.
❯ brew cleanup
Removing: /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.3... (1,565 files, 31.9MB)
Removing: /opt/workbrew/home/Library/Caches/Homebrew/bootsnap... (513 files, 4MB)
==> This operation has freed approximately 35.9MB of disk space.

What did you expect to happen?
It should not delete the portable-ruby currently in use.
Step-by-step reproduction instructions (by running brew commands)
brew developer on
brew update
brew cleanup

Step-by-step reproduction instructions (by running brew commands)
brew developer on
brew update
brew cleanup

@carlocab cannot reproduce on latest master:
$ brew update; brew cleanup
==> Updating Homebrew...
Already up-to-date.
Removing: /opt/workbrew/home/Library/Caches/Homebrew/bootsnap... (524 files, 4.1MB)
==> This operation has freed approximately 4.1MB of disk space.

Caused by HOMEBREW_USE_RUBY_FROM_PATH -- this needs to be unset.

We could probably move some of the Linux-specific code (https://github.com/Homebrew/brew/blob/754c026dd47085efb171b2e7e5009422d0b8f2c2/Library/Homebrew/extend/os/linux/cleanup.rb#L11-L19) to be generic code and then make the macOS one defer to the generic code if that env is set


HMR issue while reloading windi.config.ts changes

Describe the bug
My project uses svelte+vite+cypress to develop component library. I would like to hot reload changes done in windi.config.js during development. When I make extend color with following code inside windi.config.js, the changes are not reloaded.
	theme: {
		extend: {
			colors: {
				primary: colors.yellow,
			},

Based on this issue, if I change the extension to ts, it works. However, in doing so any color variations do not get reloaded when I change color in my svelte file from say bg-yellow-100 to bg-yellow-200.  It throws following error in the console
Trying to load windi configuration from ./windi.config.ts
Unknown Error while loading the config
Error: typescript currently not supported
    at Object.load (./node_modules/.pnpm/svelte-windicss-preprocess@4.1.1/node_modules/svelte-windicss-preprocess/dist/index.js:98:11)
    at ./node_modules/.pnpm/svelte-windicss-preprocess@4.1.1/node_modules/svelte-windicss-preprocess/dist/index.js:332:28
    at new Promise (<anonymous>)
    at markup (./node_modules/.pnpm/svelte-windicss-preprocess@4.1.1/node_modules/svelte-windicss-preprocess/dist/index.js:324:14)
    at process_markup (file://./node_modules/.pnpm/svelte@3.44.0/node_modules/svelte/src/compiler/preprocess/index.ts:183:26)
    at preprocess (file://./node_modules/.pnpm/svelte@3.44.0/node_modules/svelte/src/compiler/preprocess/index.ts:224:30)
    at compileSvelte2 (file://./node_modules/.pnpm/@sveltejs+vite-plugin-svelte@1.0.0-next.30_svelte@3.44.0+vite@2.6.13/node_modules/@sveltejs/vite-plugin-svelte/src/utils/compile.ts:40:19)
    at TransformContext.transform (file://./node_modules/.pnpm/@sveltejs+vite-plugin-svelte@1.0.0-next.30_svelte@3.44.0+vite@2.6.13/node_modules/@sveltejs/vite-plugin-svelte/src/index.ts:172:24)
    at Object.transform (./node_modules/.pnpm/vite@2.6.13/node_modules/vite/src/node/server/pluginContainer.ts:509:20)
    at doTransform (./node_modules/.pnpm/vite@2.6.13/node_modules/vite/src/node/server/transformRequest.ts:160:27)

This seems to be happening because @nbh/utils used by the current library don't support typescript. If I make a force reload vite.config.js through any change then the color variations do get reloaded.
System Info
System:
    OS: macOS 11.6
    CPU: (4) x64 Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz
    Memory: 88.69 MB / 16.00 GB
    Shell: 3.3.1 - /usr/local/bin/fish
  Binaries:
    Node: 16.12.0 - ~/Library/pnpm/node
    Yarn: 1.22.15 - /var/folders/n0/qyzlydqj6cv8qt68qd6dbprh0000gn/T/fnm_multishells/14429_1635420832550/bin/yarn
    npm: 8.1.0 - ~/Library/pnpm/npm
  IDEs:
    Nano: 2.0.6 - /usr/bin/nano
    VSCode: 1.61.2 - /usr/local/bin/code
    Vim: 8.2 - /usr/bin/vim
    Xcode: 13.1/13A1030d - /usr/bin/xcodebuild
  Browsers:
    Chrome: 95.0.4638.54
    Chrome Canary: 97.0.4685.0
    Edge: 95.0.1020.40
    Firefox: 93.0
    Safari: 15.0
  npmPackages:
    svelte: ^3.44.0 => 3.44.0
    svelte-windicss-preprocess: ^4.1.1 => 4.1.1
    windicss: ^3.2.0 => 3.2.0

Used Package Manager
pnpm

@bhvngt thanks for the idea of supporting live reload for config files. This feature is currently not implemented, I will address this as soon as possible

Just added first iteration (v4.1.5-beta.1) with experimental support. Have not released it on stable yet.  If you would like to test, and see if it works with vite - I am not testing with vite currently -  please use:
npm i<EMAIL_ADDRESS>

Sure @alexanderniebuhr. I will do the testing from my end with vite.

I have setup a sandbox to test out your build. I did my testing with following results

Setup custom colors  in windi.config.ts

Using this colors in `app.svelte'

When I make changes in windi.config.ts, it live reloads this changes.

When I make changes in app.svelte, changes don't get reflected. This time however, no error is thrown

When I touch vite.config.js, vite restarts the server and so the changes gets reloaded.

Hm that is strange and I don't think it is an issue with the reload of the config, since it already picked up the config.
I will check your repo later, I am afraid it is caused by some lifecycle issue of svelte and vite.
I'll update as soon as I know the reason

You are right. I had to putWindiCss before svelte in the plugin section of vite.config.js. This answer in [stackoverflow](https://stackoverflow.com/questions/69601626/windi-css-hmr-not-working-for-svelte-vite-app) helped me fix this issue.
With this change, it all seems to be working out fine. Thanks a ton for your super quick patch.

I tried the same fix in my current setup with<EMAIL_ADDRESS>and that seems to have resolved the reloading issue with typescript based config file.
I still see Error: typescript currently not supported error when I test it with your 4.1.5-beta.1 build. Not sure if I should ignore that!!

Typescript config files are currently not really supported (had to disable support for them some versions ago). I would suggest .mjs for best support. Adding .ts support later, but if it works, you can ignore the message.

With the beta release you should be able to use .js and if the file does trigger vite, just change a svelte file after changing the config and it should load the new config automatically :)

Thats true. Works the way you have explained. Thanks a ton...


✨ feat(accidental): add operator +-

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
831

Relevant Lines:
831

💛  - Coveralls


Directions are not clear

There is not a summary of what we should expect to have in place once we complete these steps. We should know how many apps we are making and what each app does so we can actually understand what we are doing, not just blindly clicking away. The steps to create the Intune policy for printer deployment are not in sync with the field names in intune, so without understanding what exactly we are building prior to these steps its impossible to figure out what data goes in which field. In step 4 (Step 4 - Configure the required MDM policies) you reference steps 3.3 - 3.5 thing is step 3 is about delegation and doesn't pertain to what we are doing in Step 4. Also this should be updated to give instructions on how to use the new Azure App Registration pages, but even using the legacy App registration these instructions just fall down.

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

ID: 21d1d072-911f-92c0-248a-9e44efbff42d
Version Independent ID: 0fdb921d-d97d-5b12-ae28-286216e130df
Content: Deploy Windows Server Hybrid Cloud Print
Content Source: WindowsServerDocs/administration/hybrid-cloud-print/hybrid-cloud-print-deploy.md
Product: windows-server-threshold
Technology: windows server 2016
GitHub Login: @msjimwu
Microsoft Alias: coreyp

Thanks for your dedication to our documentation. If we have been unable to review your issue in a timely manner, we sincerely apologize for the delayed response. We have captured the informtion you have provided for review. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


disqus not loading

It seems like disqus isn't loading properly and gives "We were unable to load Disqus. If you are a moderator please see our troubleshooting guide."
My best guess is that trusted domains aren't set up properly but I can't verify that.

thx - was planning on removing the disqus. You are quick - just trying out
web designs!
On Apr 18, 2017, at 12:18 AM, Dason Kurkiewicz<EMAIL_ADDRESS>wrote:
It seems like disqus isn't loading properly and gives "We were unable to
load Disqus. If you are a moderator please see our troubleshooting guide."
My best guess is that trusted domains aren't set up properly but I can't
verify that.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
On Tue, Apr 18, 2017 at 12:18 AM, Dason Kurkiewicz<EMAIL_ADDRESS>
wrote:

It seems like disqus isn't loading properly and gives "We were unable to
load Disqus. If you are a moderator please see our troubleshooting guide."
My best guess is that trusted domains
https://help.disqus.com/customer/portal/articles/1261429 aren't set up
properly but I can't verify that.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/useR-2018/useR-2018.github.io/issues/1, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAPdB9Urtp1S4JWaYCNO0kn96gano7Izks5rw3SpgaJpZM4M_Lwo
.


Revert "[cxx-interop][SwiftCompilerSources] Use C++ enums directly from Swift"

Reverts apple/swift#61153
It breaks the "hosttools" build mode.

@swift-ci smoke test and merge


Node cannot catch up

System information
Network: mainnet
op-node version: ghcr.io/bnb-chain/op-node:0.2.2
OS & Version: Linux
Since December 7th, our node cannot catch up
Here are our startup commands：
command: >
op-node
--l1.trustrpc
--sequencer.l1-confs=15
--verifier.l1-confs=0
--l1.http-poll-interval=3s
--l1.epoch-poll-interval=45s
--l1.rpc-max-batch-size=20
--rollup.config=/rollup.json
--rpc.addr=<IP_ADDRESS>
--rpc.port=8546
--p2p.sync.req-resp
--p2p.listen.ip=<IP_ADDRESS>
--p2p.listen.tcp=9003
--p2p.listen.udp=9003
--snapshotlog.file=./snapshot.log
--p2p.priv.raw=
--l1={private node}
--l2=http://l2:8551/
--l2.jwt-secret=/config/jwt-secret.txt
--rpc.enable-admin
--rpc.addr=<IP_ADDRESS>
--rpc.port=8545
This is log:
t=2023-12-07T16:38:33+0000 lvl=warn msg="L1 head signal indicates a possible L1 re-org" old_l1_head=0x16ad12d7437bdc3c4d22d8e9bfb822eb11406b110c99367e5d40343fcf78952b:34150796 new_l1_head_parent=0x088a1ae5dd978c9cc8ee0bdf12995caaebff4cdb8576ab305491d2b01ea7a58b new_l1_head=0xfaf427fac3297dd248b86525c76188c95b30ab30bf341075a76c33c7adb4aea7:34150798
t=2023-12-07T16:38:33+0000 lvl=info msg="New L1 finalized block"                 l1_finalized=0x1347b16a9513b2d85e89c03aac26b1199c3984d92784c1cc30bf21682e3d76ef:34150822
t=2023-12-07T16:38:33+0000 lvl=info msg="received L1 finality signal, but missing data for immediate L2 finalization" prev_finalized_l1=0x1347b16a9513b2d85e89c03aac26b1199c3984d92784c1cc30bf21682e3d76ef:34150822 signaled_finalized_l1=0x1347b16a9513b2d85e89c03aac26b1199c3984d92784c1cc30bf21682e3d76ef:34150822
t=2023-12-07T16:38:33+0000 lvl=info msg="Advancing bq origin"                    origin=0x9d43e508d51fd31fc92307d66b783cb913dde5e55cbebae320caf6fd8a3c913c:34131415 originBehind=true
t=2023-12-07T16:38:41+0000 lvl=info msg="Advancing bq origin"                    origin=0xe2def21265b09fd38d744ec3e317140ddeaf0028e047a8e8033511686877b089:34131416 originBehind=true
t=2023-12-07T16:38:43+0000 lvl=warn msg="failed to notify engine driver of L1 head change" err="context deadline exceeded"
t=2023-12-07T16:38:50+0000 lvl=info msg="Advancing bq origin"                    origin=0xdaee59dc1d604d3c2a9e0d630f866f339ec09395b268ffa622384083d7797c1e:34131417 originBehind=true
t=2023-12-07T16:38:53+0000 lvl=warn msg="failed to notify engine driver of L1 head change" err="context deadline exceeded"
t=2023-12-07T16:39:03+0000 lvl=warn msg="failed to notify engine driver of L1 head change" err="context deadline exceeded"
t=2023-12-07T16:39:05+0000 lvl=info msg="New L1 safe block"                      l1_safe=0xe8ae4a5ad1abbd538893b96f30f4952f5c282e64ea85ca225f681d1b4b1cb316:34150830
t=2023-12-07T16:39:05+0000 lvl=info msg="Advancing bq origin"                    origin=0xdc5cf7d5f1cb993706dfbaf207da9b9a6c9210b2822c8f358b442eb9d7dda974:34131418 originBehind=true
t=2023-12-07T16:39:12+0000 lvl=info msg="New L1 finalized block"                 l1_finalized=0xe8ae4a5ad1abbd538893b96f30f4952f5c282e64ea85ca225f681d1b4b1cb316:34150830
t=2023-12-07T16:39:12+0000 lvl=info msg="received L1 finality signal, but missing data for immediate L2 finalization" prev_finalized_l1=0xe8ae4a5ad1abbd538893b96f30f4952f5c282e64ea85ca225f681d1b4b1cb316:34150830 signaled_finalized_l1=0xe8ae4a5ad1abbd538893b96f30f4952f5c282e64ea85ca225f681d1b4b1cb316:34150830
t=2023-12-07T16:39:12+0000 lvl=info msg="Advancing bq origin"                    origin=0xe89e4e2621d583023528cc9af3624f42b310850eef8aa2c78fad50ae81803be9:34131419 originBehind=true
t=2023-12-07T16:39:12+0000 lvl=info msg="Reading channel"                        channel=53bf067a06c701ca09a13d44b8526d36 frames=2
t=2023-12-07T16:39:12+0000 lvl=warn msg="L1 head signal indicates a possible L1 re-org" old_l1_head=0x9ee29df21e0c6e5bb2536e0ff8073c33e94838a05a23a39a25c8fd8831b04ffa:34150805 new_l1_head_parent=0xdd2b7e00b7b06c686d7e84a90de544dde6c2a4c6790879292b4032a5ff20e935 new_l1_head=0x6004023a6fd5841f936e910a8cbcd9657ccedd310f4a21c4c8b3e07438b8d4dd:34150811
t=2023-12-07T16:39:12+0000 lvl=warn msg="L1 head signal indicates a possible L1 re-org" old_l1_head=0x3ff6c05de5d2f7e752cc81817b8c90542c57a6ece914b89f90d9fdff7ac8ec9b:34150814 new_l1_head_parent=0x464202f4fd6480760689e18fc0a31ad9961e488511cab23476f7450e2297f3d0 new_l1_head=0xd579499c2ff4ec9cbfdb08c5d9d2ec4eb5e18192673e59db729b5c253c2e444c:34150818
t=2023-12-07T16:39:12+0000 lvl=warn msg="L1 head signal indicates a possible L1 re-org" old_l1_head=0xe738092f7e318d2d665d6c88ac6ce94557066f2d319bc857872adfcbee510ba4:34150829 new_l1_head_parent=0xe8ae4a5ad1abbd538893b96f30f4952f5c282e64ea85ca225f681d1b4b1cb316 new_l1_head=0xf032ba24400eb57e7a2fc686a2f519203bde43c13d4e053a182e116abe0d0637:34150831
t=2023-12-07T16:39:12+0000 lvl=warn msg="L1 head signal indicates a possible L1 re-org" old_l1_head=0xf032ba24400eb57e7a2fc686a2f519203bde43c13d4e053a182e116abe0d0637:34150831 new_l1_head_parent=0x8b14e56f63742dcf1e8ff3cb2f13287779175df68d64804e33f4be43922c96d3 new_l1_head=0x2500ab1a29abe6b14251aac497a78423a891ff9def0604673e16e5b0fa7332dc:34150834
t=2023-12-07T16:39:17+0000 lvl=info msg="Advancing bq origin"                    origin=0xfc106be75512417d8d2dd997aa2cd38a2d2b132b4fcb62b69faef9c38d4d14f7:34131420 originBehind=true
t=2023-12-07T16:39:23+0000 lvl=info msg="Advancing bq origin"                    origin=0x7e4627e8cc25d143f6d21c080f7d1a98f146581d8c8b70978480b5bef13609c0:34131421 originBehind=true
t=2023-12-07T16:39:28+0000 lvl=info msg="New L1 finalized block"                 l1_finalized=0x31123f2e659a685465cd682bef97c81141489e7eb4bb7b8cd27e3496834ee581:34150838
t=2023-12-07T16:39:28+0000 lvl=info msg="received L1 finality signal, but missing data for immediate L2 finalization" prev_finalized_l1=0x31123f2e659a685465cd682bef97c81141489e7eb4bb7b8cd27e3496834ee581:34150838 signaled_finalized_l1=0x31123f2e659a685465cd682bef97c81141489e7eb4bb7b8cd27e3496834ee581:34150838
t=2023-12-07T16:39:28+0000 lvl=warn msg="L1 head signal indicates a possible L1 re-org" old_l1_head=0x2500ab1a29abe6b14251aac497a78423a891ff9def0604673e16e5b0fa7332dc:34150834 new_l1_head_parent=0x26a6885c0070230cb6752f141d6b1b10137536fbfe703c590eb5bacb2b2fdee4 new_l1_head=0x31123f2e659a685465cd682bef97c81141489e7eb4bb7b8cd27e3496834ee581:34150838
t=2023-12-07T16:39:28+0000 lvl=info msg="New L1 safe block"                      l1_safe=0x31123f2e659a685465cd682bef97c81141489e7eb4bb7b8cd27e3496834ee581:34150838
t=2023-12-07T16:39:28+0000 lvl=info msg="Advancing bq origin"                    origin=0x6a72821ffb5730744b8e9dca2e0968634c33a8dc3cc67fe4bd2a5738a94283d7:34131422 originBehind=true
t=2023-12-07T16:39:35+0000 lvl=info msg="Advancing bq origin"                    origin=0x9b1a3d81119bede115a2f39ee1ba2646ed18805055c6be14f4955cf83420125e:34131423 originBehind=true
t=2023-12-07T16:39:43+0000 lvl=info msg="Advancing bq origin"                    origin=0xf1325acf5749fbdbfe83cca8169580b8734a51390c7a27501f1387c496382ec5:34131424 originBehind=true
t=2023-12-07T16:40:06+0000 lvl=warn msg="failed to notify engine driver of L1 head change" err="context deadline exceeded"

I was using the L1 address https://bsc-dataseed.bnbchain.org:443 and ran into the same problem

I'm using a private L1 archive node and I'm getting the following error
t=2023-12-08T11:07:17+0800 lvl=warn msg="failed to poll L1 block"                label=safe      err="failed to fetch head header: not found"
t=2023-12-08T11:09:54+0800 lvl=warn msg="failed to notify engine driver of L1 head change" err="context deadline exceeded"

Same issue even with own dedicated full node as L1.

My nodes are back in sync.

My nodes are back in sync.

Have you caught up?

Also back in sync.

Excuse me, have all the nodes recovered by themselves? Or what has been optimized?

Excuse me, have all the nodes recovered by themselves? Or what has been optimized? @YuXiaoCoder @3eph1r0th

Recovered by themselves

Excuse me, have all the nodes recovered by themselves? Or what has been optimized? @YuXiaoCoder @3eph1r0th

Try adding BOOT_NODES to geth as well.
https://docs.bnbchain.org/opbnb-docs/docs/tutorials/running-a-local-node#start-components

My node hasn't caught up yet. It seems like advancing bq origin slowly.

@zhangxinars Hi, during that time, BSC was experiencing a period of high peak TPS, the maximum transaction volume in a block had reached about 8k, which far exceeded the previous peak. Therefore, it was very challenging for L2 to fetch data and derive it. In fact, accessing the RPC nodes of L1 during that period can be alleviated by improving the configuration of the L1 endpoint, but this is only a temporary solution. We are also looking for a more stable and non-sensitive solution to deal with this possible sudden increase in traffic. Sorry for this and we are on it...

Hi. Issue happened again on all our nodes.

We have optimized some time-consuming operations, and BSC has provided some specific interfaces (not supported in ETH) that can help us retrieve L1 data more efficiently, especially when there is a sudden increase in L1 transaction volume. The activation method is to add--l1.rpckind=bsc_fullnode in the configuration options of the op-node. In our own tests, this has significantly alleviated the issue of slow synchronization speed under extreme conditions.


Use POJOs more often

Yasson does not currently handle parameterized types in an @JsonbCreator function properly.

It should be fixed when commit 6ae0add gets released (it has already been merged in to master).
See: eclipse-ee4j/yasson#230


[BUG] doom doc reports libvterm missing even though it exists

Describe the issue
doom doctor reports that it can't find libvterm, but libvterm is installed and vterm can be used in Emacs.
Output of doom doctor:
Checking your enabled modules...
    (:term vterm) Couldn't find libvterm. Vterm module won't compile

I expect doom doc to report the presence of libvterm correctly. I've looked at term/vterm/doctor.el and saw that it checks for the presence of vterm-ctrl.
On my system, which is openSUSE Tumbleweed (Snapshot 20190730), vterm-ctrl is available in a package called libvterm-tools while the library itself is in libvterm-devel. I guess that only the latter is required as I was able to use vterm in emacs without any obvious issues. After I installed libvterm-tools, doom doctor did not complain anymore, but I did not spot a different within emacs.
System information

((emacs
  (version . "26.2")
  (features . "XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS GLIB NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD")
  (build . "Aug 02, 2019")
  (buildopts "--disable-build-details --without-pop --with-mailutils --without-hesiod --with-gameuser=:games --with-kerberos --with-kerberos5 --with-file-notification=inotify --with-modules --enable-autodepend --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --localstatedir=/var --sharedstatedir=/var/lib --libexecdir=/usr/lib --enable-locallisppath=/usr/share/emacs/26.2/site-lisp:/usr/share/emacs/site-lisp --with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-rsvg --with-dbus --with-xft --without-gpm --with-x-toolkit=gtk3 --with-toolkit-scroll-bars --x-includes=/usr/include --x-libraries=/usr/lib64 --with-libotf --with-m17n-flt --with-xwidgets --build=x86_64-suse-linux 'CFLAGS=-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -flto=3 -g -D_GNU_SOURCE -DGDK_DISABLE_DEPRECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label -fno-optimize-sibling-calls -fno-PIE -DSYSTEM_PURESIZE_EXTRA=55000    -DSITELOAD_PURESIZE_EXTRA=10000 ' LDFLAGS=-Wl,-O2"))
 (doom
  (version . "2.0.9")
  (build . "HEAD -> straight, origin/straight 40eb9cf1 2019-07-29 21:23:51 +0200"))
 (system
  (type . gnu/linux)
  (config . "x86_64-suse-linux-gnu")
  (shell . "/usr/bin/zsh")
  (uname . "Linux 5.2.3-1-default #1 SMP Fri Jul 26 08:52:13 UTC 2019 (f5296b5) x86_64")
  (path "~/.rbenv/shims" "~/bin" "~/.cargo/bin" "~/.yarn/bin" "~/.rbenv/bin" "~/.cabal/bin/" "~/.emacs.d/bin/" "~/.local/bin" "/usr/local/bin" "/usr/local/sbin" "/usr/bin" "/usr/sbin" "/bin" "/sbin" "~/.fzf/bin" "/usr/lib/emacs/26.2/x86_64-suse-linux"))
 (config
  (envfile)
  (elc-files . 32)
  (modules :completion company (ivy +icons +fuzzy) :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) treemacs vc-gutter vi-tilde-fringe window-select workspaces :editor evil file-templates fold multiple-cursors rotate-text snippets :emacs dired electric vc :term vterm :tools editorconfig eval flycheck flyspell (lookup +docsets) lsp magit :lang data emacs-lisp (haskell +intero) (javascript +lsp) latex markdown (org +attach +babel +capture +export +habit +present +protocol) perl plantuml (python +lsp) rest (ruby +rbenv) (rust +lsp) sh web :config literate (default +bindings +smartparens))
  (packages "dockerfile-mode" "salt-mode")))

$ rpm -ql libvterm-tools
/usr/bin/unterm
/usr/bin/vterm-ctrl
/usr/bin/vterm-dump

$ rpm -ql libvterm-devel
/usr/include/vterm.h
/usr/include/vterm_keycodes.h
/usr/lib64/libvterm.so
/usr/lib64/pkgconfig/vterm.pc

libvterm is build during the build process of emacs-libvterm, so it doesn't have to be installed on the system.

libvterm is build during the build process of emacs-libvterm, so it doesn't have to be installed on the system.

Are you saying this doom doctor check is wrong and there are no checks needed if  libvterm is installed since launching vterm takes care of it anyway?

@alexandergraul libvterm is built when you launch vterm for the first time. doom doc doesn't know about that, and it seems to be designed to find possible wrong-doings, not all of them being true. If you know that it is wrong - please ignore the warnings for now, after asserting everything works the way you want.

doom doc doesn't know about that, and it seems to be designed to find possible wrong-doings, not all of them being true.

What I am trying to get at is that checking if vterm-ctrl exists is not a useful check for doom doc (unless it enables some extra features that I have not come across yet). The report is misleading, since libvterm does compile even if vterm-ctrl is missing. Looking at https://github.com/akermu/emacs-libvterm/blob/master/CMakeLists.txt#L36 it seems that these headers are used: https://github.com/neovim/libvterm/tree/master/include - and they do not depend on vterm-ctrl. Therefore I think this check can be removed from doom doc.

If you know that it is wrong - please ignore the warnings for now, after asserting everything works the way you want.

Sorry, but I think this is the wrong approach. I think doom doctor should be fixed instead of telling its users to ignore warnings - once you go into that direction you can't expect anyone to trust it for any output.

Your points are valid and well-researched, and this I can agree upon. Feel free to submit a PR with the proposed change for @hlissner to review it when possible.

@alexandergraul I agree that the doctor should be fixed. The check was a naive heuristic I came up with while unaware that vterm-ctrl was a soft dependency. I would greatly appreciate a PR if you can think of a better check. I'm afraid I'm not familiar enough with libvterm enough to offer a solution (and haven't figured out how to properly install it after switching to NixOS, for that matter).

Sorry for the late response. The vterm-ctrl check was removed in 6cd601cf0f42, so I'll consider this resolved.


Occasionally the ESX01 server fails to communicate with vCenter

On several occasions I've observed an ESX host (so far it has always been ESX01 but that my be coincidence) disconnects from the vCenter but continues to run VMs fine.
This will cause trouble when trying to deploy the Anthos cluster. Manually logging in and resetting the management agents on the ESXi server seems to remedy this.
If we see this continue to happen often then we should try to determine the underlying reason. We can attempt to write a simple script that will reset the agents proactively on each of the ESXi servers before attempting to do the cluster install, though I'm not sure that will solve the issue until we know what triggers it.

This appears to be an issue with ESXi 6.5. Recommend using ESXi 6.7 with the c3.medium.x86. see: https://github.com/packet-labs/google-anthos#using-packet-gen-3-hardware-and-esxi-67


adding moxie

Hi team,
Raising a new PR to add Moxie Protocol and it's deployer addresses.
Please let me know if there are any issues or questions
Cheers,
Ignas

/validate 1d38cd19ce36c8895a7016e7dcab2bdae6206c32

Hi @ccerv1 thank you!

Hi @ccerv1 I had a quick question - is there anything else pending on our side for the Moxie contracts to get indexed by OSO? Just trying to understand if I missed a step.
Appreciate the support.

Hi @ccerv1 I had a quick question - is there anything else pending on our side for the Moxie contracts to get indexed by OSO? Just trying to understand if I missed a step.
Appreciate the support.

Hey @shnoodles
Yep, I'm seeing 55K contracts deployed (on Base)! That sound about right to you?

Hi @ccerv1 sorry for delayed response. Yes, sounds about right (approx).
We have deployed 53k+ TokenLockWallets to manage our Airdrops - those vesting contracts allow users to participate in the protocol with the vesting tokens, while they are vesting.


Bugfix: Retry on "database locked" error (or add support for PostgreSQL/MySQL DB backend)

when using the documented method to add or update links in parallel ,
or using the gui while updating on the cli ,
plenty of database locked errors ,
and since the somehow lengthy ( min. 500ms per page only to check , up to 6*120 s with timeout 2m )
a simple RETRY_DB_WRITE variable and the corresponding code would help
(or just switch to SQL , since it is way faster , especially when running 20Mbyte+ sqlite files from SD/MMC )

By "switch to SQL" do you mean switch to PostgreSQL or MySQL? If so we're probably not going to do that anytime soon. You can already do it optionally but I'm not going to make it the default since it massively increases the complexity for the average user.
Parallel archiving is not yet fully stable, it's going to get better in v0.5 and v0.6, you can see the roadmap here: https://github.com/ArchiveBox/ArchiveBox/wiki/Roadmap
The plan is to enable parallel archiving by moving to a message passing architecture and using an async queue worker like Huey/Dramatiq to handle running multiple extractor threads / link archiving threads at once.

By "switch to SQL" do you mean switch to PostgreSQL or MySQL? If so we're probably not going to do that anytime soon. You can already do it optionally but I'm not going to make it the default since it massively increases the complexity for the average user.
Parallel archiving is not yet fully stable, it's going to get better in v0.5 and v0.6, you can see the roadmap here: https://github.com/ArchiveBox/ArchiveBox/wiki/Roadmap
The plan is to enable parallel archiving by moving to a message passing architecture and using an async queue worker like Huey/Dramatiq to handle running multiple extractor threads / link archiving threads at once.

you should have a look at cabot , it is in python  , has a que
and does nearly the same ( get something from somewhere and analyze  headers/content/statuscode )

you should have a look at cabot , it is in python  , has a que
and does nearly the same ( get something from somewhere and analyze  headers/content/statuscode )

You can already do it optionally

How does one do that ?

You can already do it optionally

How does one do that ?

You can edit archivebox/core/settings.py and change the DATABASE section to use a standard postgres connection.
Although I highly doubt it will be faster, SQLite is extremely fast on SSDs, and often beats PostgreSQL on benchmarks for queries run locally.

You can edit archivebox/core/settings.py and change the DATABASE section to use a standard postgres connection.
Although I highly doubt it will be faster, SQLite is extremely fast on SSDs, and often beats PostgreSQL on benchmarks for queries run locally.

Just to throw in my two cents, it is actually not only a matter of performance.
Postgres is IMO a better choice for a whole lot of reasons:

better handling of concurrent requests
overall, better maintainability and security
and for me at least: ability to seamlessly connect ArchiveBox database to our other databases

Could you direct me to a relevant documentation for that "standard django postgres connection" you mentioned?
Thanks,
S.

While Postgres is better at concurrent writes (not necessarily reads), it's definitely not a clearcut winner on "better at maintainability and security". Postgres is significantly less tested than SQLite. I think you forget that Airbus planes, rockets, boats, most iOS apps and other native apps, and tons of modern critical infrastructure run on SQLite!

https://www.sqlite.org/testing.html
https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-qps-on-a-single-server/
https://antonz.org/sqlite-is-not-a-toy-database/
https://github.com/rqlite/rqlite

We might add Postgres/MySQL support in the future, but it's not a priority because ArchiveBox is focused on long-term data format durability above all else, and SQLite is the clear winner in that regard, having been standardized to the point of wide adoption far beyond Postgres and MySQL and others. Side note, I love Postgres, but honestly MySQL is slightly better for the ArchiveBox use-case, InnoDB compression is better, and it can handle many more concurrent threads than Postgres with lower resource usage on smaller machines/containers.

Note I've added a new DB/filesystem troubleshooting area to the wiki that may help people arriving here from Google: https://github.com/ArchiveBox/ArchiveBox/wiki/Upgrading-or-Merging-Archives#database-troubleshooting
Contributions/suggestions welcome there.


Consider tweaking the default display of notebooks tab

Is the screenshot of the notebook (https://github.com/DataBiosphere/saturn-ui/issues/58) still the plan for the 'cards view'?
If not any time soon, please consider the following two changes:
(1) The notebooks tab displays the 'cards view' by default. This is fine when there are only a few notebooks in the workspace, but consider automatically defaulting to the 'list view' when there are more than a few notebooks. Or make the users' choice of view sticky across sessions. Please take a look at the 'try-saturn' workspace as an example workspace with many notebooks.
(2) Also the current version of the 'cards view' could take better advantage of the screen real estate by decreasing the size of the large grey Jupyter icon on each card and instead showing the full name of the notebook instead of the truncated name currently shown.

It would also be really nice if the end-user had some way of controlling the ordering of notebooks in the list or card view. Today the list is ordered by most recently updated. It would be nice to be able to control that. Simply having the option of alphabetical ordering would be nice.
If we had alphabetical ordering, then I would create a series of notebooks in sample workspaces such as:

0 - Start Here
1 - Install software and restart kernel
2 - Load data from workspace
<etc>

Recent mocks have us moving to a table view. Users could sort on any column. We'll sort alphabetical by name by default. I'm moving this out to Q2 as we're soaked on billing work until then. We will definitely get to it though.


Picker: need to come up with a better way to do state received from props.

When trying to use Picker with outside services it didn't update easily. Now we adjusted it to be able to getDerivedStateFromProps. This allows us to still use the Picker logic and allow outside apps to handle it easily. This works fine so far, but there could be some better ways to implement this logic.
We may want to come up with a breakdown between PickerBase and Picker that we see in Moonstone. Maybe what we have now is a good middle ground, but I'm sure other components with trickier states may run into similar problems so we should come up with a more standard solution.

The standard approach within Enact for managing controlled vs uncontrolled component is to either:

Accept a defaultXXX prop to set an initial value and allow the component to control the value from that point on
Accept the XXX prop and allow the consumer to control the value based on external events or the event callbacks supported by the component.

For the common use cases, this capability is codified into Changeable and Toggleable but has also been built into a few other components.
I've refactored Picker a bit to use Changeable and will submit a PR where we can discuss further.


import/export httpserver from route

needs and exposes HttpRequestRef/HttpResponseRef types from there

Why?

the http server types are part of the public API of the presto router, ie anyone declaring presto routers must also have access to the http server types (since they're implementing parts of a http server) -> it should be exported here so consumers of presto don't have to import httpserver on their own.


Update button.md

The button docs confused me. I wanted to build my own button, but in the "how to build your own" paragraph it linked only to TouchableOpacity (too high level) and TouchableNativeFeedback (Android only)

Deploy preview for react-native processing.
Building with commit c44c152d7c9a95a972e945061c3111b975414199
https://app.netlify.com/sites/react-native/deploys/5e91a80bff72cd000713b17e


Added NOT LIKE support for WildcardFilters

Sorry for the large diff on the test file due to hitting the reformat.
Also - changed the 'wildcard' filter method on the UniqueDimension to 'like' to make it more natural to use.

Coverage increased (+0.05%) to 92.953% when pulling fbb3522e4b299e8455dca81bb7df2d9754480721 on mikeengland:add-negated-wildcard-filter into 09853f604dd88e862f3f9872ed0616bbac131b56 on kayak:fireant1.0.


[Feature Request]: Badge character control for permanent notification on Android - BeaconMonitoring

Summary
When using BeaconMonitoring a permanent notification shows up. By Android requirement it needs to be there but what about the badge number on application icon? Is it possible for it not to set that 1 character number for the permanent notification only. Users, I'm told, keep thinking they need to open the app to remove the badge and doesn't understand why it doesn't go away.
API Changes
Shiny.Beacons
Intended Use Case
For the user not to keep thinking that there is an unread notification or something they need to do in the app because the badge doesn't go away.
Code of Conduct

[X] I agree to follow this project's Code of Conduct

This has been added for a future release


ci: reduce Homebrew cleanup

brew upgrade makes too much noise and takes too long, skip for now.

Don't skip ci for this one, we like to have a full run to see if Colima works now.

Oh, it's because the skip ci on the commit itself.

Let's remove the skip ci (do another commit) and at least see the tests start to work.


Dumping estimated parasitics as SPEF

Description
You can run estimate_parasitics prior to RCX extraction with OpenROAD, however, there isn't a way to dump this data to a SPEF file as far as we can tell. We're trying to bring up a PDK internally and it would be helpful for calibrating the RC values.
Suggested Solution
A way to dump the estimated parasitics would be ideal.
Additional Context
No response

There isn't a method currently.  How would you use the spef?  If you just need something like total C that's simpler.

I'd also like this

There isn't a method currently. How would you use the spef? If you just need something like total C that's simpler.

We're trying to compare the values pre and post-routing (and RCX) to try and calibrate the RC values to try to get the pre-routed values a bit closer to post-route extracted parasitics.
If total C (presuming you meant per-net) can also be dumped the same format pre and post routing and RCX, that would also be helpful as a starting point.

@donn take a look in ORFS where we have a script that does linear correlation between GPL, GRT, and RCX parasitics on both total cap and total res.
write_net_rc.tcl contains a bunch of procs for extracting cap and res for each net.
write_net_rc_script.tcl uses those procs to get the GPL, GRT, and RCX cap and res into CSV files.
correlateRC.py does a simple linear regression on the estimated cap and the extracted cap to generate a correlated setRC.tcl
make correlate_rc will run these scripts on a specific design
make correlate_rc_platform will run the correlation on all designs in an entire platform, rather than just on a single design. Although for some reason Make always wants to rebuild a design from scratch even if it exists.

@eder-matheus please help @joaomai with this as an initial project


Graph performance/optimization

Hello, everyone. First of all, thanks for the software, I've found it really useful. I was comparing it today to "Obsidian Publish" and noticed that their graph preview does not lag at all in my computer. On the other hand, Quartz graph lowers my browser fps to 20 and increases the CPU load massively. Has anyone found out why this is the case? I would love to make it more accessible to lower-end devices

Closing to continue in https://github.com/jackyzha0/quartz/issues/1144


Application to enroll not available on this page

[Enter feedback here]

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

ID: d1db021c-1d09-d455-f2b7-e417844ccc85
Version Independent ID: 9f469880-6a23-71e4-d728-8bf7b05bb8e7
Content: Program Requirements - Microsoft Trusted Root Program
Content Source: trusted-root-docs/Program-Requirements.md
Service: security
GitHub Login: @kasirota
Microsoft Alias: kasirota

Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


Update profile picture through API

I have a PUT API for a profile picture update and I am sending JSON request
{
"profilePicture": "https://mdcorpeus2cdnendpoint.bcom3test.com/profile/aefb5d5c-dfcb/"
}
But profile picture is not getting update:

Since you're sending a URL to an API, I guess the remote service who's API you're calling is expected to be able to access that URL to download the profile picture. I would check to see if the remote service has access to that URL. Sorry, but I can't be more helpful with the available information. Anyway, this topic is not really related to the OpenTest functionality.


Make constants configurable via envars

Addresses https://github.com/audrow/yatm/issues/375 by relying on environemnt variables instead of constants defined in src files.

YATM_TEST_CASE_CONFIG_PATH: The absolute path to the YAML file that specifies the test case generation, as well as filters for what test cases to create from requirements and to specify the dimensions that should be varied for the test cases. See example-test-case.config.yaml
YATM_REQUIREMENTS_DIRECTORY_PATH: The absolute path to a directly containing YAML files files that describe testing requirements. See Creating Requirements for more details.
YATM_OUTPUT_DIRECTORY_PATH (OPTIONAL): The absolute path to a directory where YATM should output test cases to. If unspecified, a generated-files/ directory is created in the current working directory.
GITHUB_REPO_OWNER: The name of the github organization or owner containing the repository below.
GITHUB_REPO_NAME: The name of repository where Issue tickets for test cases should be opened.
GITHUB_TOKEN: Your Github Personal Access token which has the ability to read and write to the repository above.

Requirements that were stored here have been deleted and moved to ros2_test_cases via https://github.com/osrf/ros2_test_cases/pull/1057.

We should probably merge #368 in and rebase this PR to incorporate the core changes from that PR. (will need to move the DSITRO constant to an envar). In the meanwhile, @audrow what do you think of these changes?

@Yadunund, I hope this was done. I didn't remember that I had mergify automerging PRs with approvals.
I made a PR removing this #408 and merged it in.
You may want to rebase your PRs. You can use @mergifyio rebase, I believe.


bug: idTokenClaim user picture null because it's called avatar

https://github.com/logto-io/dart/blob/08e2f3cb27d543a01da4a7ee349c99ae2a44fe6b/lib/src/modules/id_token.dart#L16
the json contains a field called picture

Thx for the report.


Update README.md with info on Sunsynk 8.8kW

Added info on Sunsynk 8.8kW inverter and moved some of the text around. Also added pin 3 to the pin out table as GND

Thank you Dirk!


arch: riscv: add ARCH_HAS_SINGLE_THREAD_SUPPORT

Enable single-threading support for the riscv architecture.
Add z_riscv_switch_to_main_no_multithreading function for
supporting single-threading.
The single-threading does not work with enabling PMP_STACK_GUARD.
It is because single-threading does not use context-switching.
But the privileged mode transition that PMP depends on implicitly
presupposes using context-switching. It is a contradiction.
Thus, disable PMP_STACK_GUARD when MULTITHREADING is enabled.

Add qemu_riscv* targets to the tests that list below.
These set CONFIG_MULTITHREADING=n.

tests/kernel/fatal/no-multithreading
tests/kernel/mem_heap/mheap_api_concept
tests/kernel/mem_slab/mslab_api
tests/kernel/threads/no-multithreading

note: tests/kernel/timer/timer_api/ test failed. It seems caused by driver. This PR does't enable it.

This doesn't look optimal but refinements could come as follow-up PRs.
However there is a correctness issue with function arguments that should
be addressed now, even if those are unused in practice. Please consider
merging the following:
diff --git a/arch/riscv/core/thread.c b/arch/riscv/core/thread.c
index 6533cee07d..255c84154d 100644
--- a/arch/riscv/core/thread.c
+++ b/arch/riscv/core/thread.c
@@ -280,10 +280,14 @@ FUNC_NORETURN void z_riscv_switch_to_main_no_multithreading(k_thread_entry_t mai
 	main_stack = (Z_THREAD_STACK_BUFFER(z_main_stack) +
 		      K_THREAD_STACK_SIZEOF(z_main_stack));

+	register void *a0 __asm__("a0") = p1;
+	register void *a1 __asm__("a1") = p2;
+	register void *a2 __asm__("a2") = p3;
+
 	__asm__ volatile (
 	"mv sp, %0; jalr ra, %1, 0"
 	:
-	: "r" (main_stack), "r" (main_entry)
+	: "r" (main_stack), "r" (main_entry), "r" (a0), "r" (a1), "r" (a2)
 	: "memory");

 	/* infinite loop */

@npitre
Thank you for pointing out.
It make a sense, need to handle arguments.
I applied this diffs.

@fkokosinski

Did you try running these tests on an actual HW platform?

I forgot to run it on HW.
I just now ran it with sparkfun_red_v_things_plus.
It was mostly OK (also OK philosophers sample), but there were two Fails.
I think it's caused by the real HW timer (It seems timinig or accluacy problem), but I need to investigate.

===================================================================
START - test_cpu_idle
Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/threads/no-multithreading/src/main.c:75: no_multithreading_test_cpu_idle: (diff not within 10 +/- 2)
Unexpected time passed: 16 ms
FAIL - test_cpu_idle in 0.056 seconds
START - test_irq_locking
PASS - test_irq_locking in 0.018 seconds
START - test_k_busy_wait
Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/threads/no-multithreading/src/main.c:30: no_multithreading_test_k_busy_wait: diff not within 10 +/- 2
FAIL - test_k_busy_wait in 0.040 seconds

@fkokosinski @npitre @edersondisouza ping

Hi @soburi

It was mostly OK (also OK philosophers sample), but there were two Fails. I think it's caused by the real HW timer (It seems timinig or accluacy problem), but I need to investigate.

How is your investigation going? :)

@fkokosinski , @teburd
I'm having trouble getting it to work.
I tried in two environments, and both failed.
(Both are configurations I made...)
The red-v is almost the same as SiFive's FE310, so I don't think there is a big difference from other SiFive boards.
sparkfun red-v things plus/hifive1 (SoC: FE310)
The behavior itself looks fine, but the time accuracy is bad. Since the clock of the timer is 32K, the accuracy should be low, but there may be some problems because there is a difference of 5ms to 10ms.
Also, this is the same result with MULTITHREADING=n.
Since this test is simply a test to confirm that the timer interrupt cancels k_cpu_idle(), the setting of MULTITHREADING does not seem to have much to do with it.
Running TESTSUITE no_multithreading
================================================== =================
START-test_cpu_idle
timeout_handler
Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/threads/no-multithreading/src/main.c:77: no_multithreading_test_cpu_idle: (diff not within 10 +/- 2)
Unexpected time passed: 15ms
FAIL - test_cpu_idle in 0.060 seconds
longan_nano (SoC: GD32VF103)
Unrelated to this PR, k_cpu_idle() needs to be fixed.
(The test in tests/kernel/context/kernel.context does not pass.)
Since no-multithreading also uses this function, I am looking there first.

Unrelated to this PR, k_cpu_idle() needs to be fixed. (The test in tests/kernel/context/kernel.context does not pass.) Since no-multithreading also uses this function, I am looking there first.

Hi @soburi, thanks for pointing that out. If this is unrelated to this PR, I think you should report this in an issue here on GitHub so that it can be tracked separately.

@soburi any update?

@MaureenHelm
Sorry, I was bit busy. I'll update.

@soburi could you rebase this? Thanks!

@carlescufi

@soburi could you rebase this? Thanks!

Rebasing done.


refactor: refactor openapi schema generation

Pull Request Checklist

[x] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR
[x] Pre-Commit Checks were ran and passed
[x] Tests were ran and passed

Description

We share a lot of state between each of the different schema element builder functions, so this PR takes a different approach by sharing that state via factory types.
It's a bit of a big PR, apologies.
To summarize, the existing functional approach relied on passing a lot of the same shared state between them to generate the schemas, so this PR takes a different approach through implementing factory types for each of the schema elements that we generate.
The pattern is one factory instance per element generated, i.e., there should be a single OpenAPIFactory instance for the application, one PathItemFactory instance per HTTPRoute, one Parameter factory per handler, and so on.
Close Issue(s)

precursor work for #2804.

This PR also addresses one of the remaining cognitive complexity issues left in the code base: https://sonarcloud.io/project/issues?resolved=false&types=CODE_SMELL&id=litestar-org_litestar&open=AYeibLEUxZTizGEJ182r

Thanks heaps for reviews @guacs & @provinzkraut!


The Falcon integration for Falcon 3.0.1

The Falcon integration passed the tests for Falcon 3.0.1, 2.0.0, 1.4.0 (Python 3.8) and Falcon 2.0.0, 1.4.0 (Python 2.7)

any news about this ?

Hello @bartolootrit !
Thanks for your contribution!
We also got an PR for Falcon 3.0.0 from @Seluj78:
https://github.com/getsentry/sentry-python/pull/1073
Could you @bartolootrit talk to @Seluj78 on how you can merge the two PRs into one? So we have only one Falcon Integration that we can review and eventually merge?

Maybe also @pecalleja could help somehow?

https://github.com/getsentry/sentry-python/pull/1073 was closed. Are my changes from there in here ? :)

Hey @Seluj78
I am not sure if your changes are in here (or what your changes are, to be precise ;-) )
Could you have a look at the files changed to see if they are here: https://github.com/getsentry/sentry-python/pull/1297/files ?

Looking good, it just seems like the imports are differently named now ? https://github.com/getsentry/sentry-python/pull/1073/files#diff-af8d1eba8feb85336f0d9a1a04a78beaa87da4a8efa675b478a18b8f603d63f8R20

FYI @bartolootrit and @Seluj78
I have now added Falcon 3.0.0 and 3.1.0 to our test suite here:
https://github.com/getsentry/sentry-python/pull/1378
If all the tests for this are green I can merge this into master and then you can rebase your pull request onto the new master, so we can run all our tests in Falcon 3.0 and 3.1!

antonpirker
Ok. I'll rebase this pull request after https://github.com/getsentry/sentry-python/pull/1378 has been merged.

Hey @bartolootrit !
Turns out I can not merge https://github.com/getsentry/sentry-python/pull/1378 because it fails (because it has not Falcon 3 support) :-)
So I changed this PR to be merge into the branch with the Tests. Lets see how this turns out.
If there are errors, you can try to fix them in your branch and push again, the tests should be triggered again.

@antonpirker I've rebased this branch. An approval is needed to run workflows.

The doc still say that it is compatible only with  1.4 and 2.0 only
https://docs.sentry.io/platforms/python/guides/falcon/
The Falcon integration adds support for the [Falcon Web Framework](https://falconframework.org/). The integration has been confirmed to work with Falcon 1.4 and 2.0
Could you please confirm that it is now compatible with falcon 3.0.1 ?

Is there any reason why this pull requests has never been done ?

Why this pull request has never been merged ? Could be great to have falcon 3 support !


some confuse about tf.shape(x) and x.shape

When I learning the document about transformer, I meet some different about tf.shape(x) and x.shape
tf.version == 2.3.0
code:
class Encoder(tf.keras.layers.Layer):
    def call(self, x, training, mask):
    ##########  it will raise a error when using x.shape[1]  ##########
        seq_len = tf.shape(x)[1]
        x = self.embedding(x)
        x *= tf.sqrt(tf.cast(self.d_model, tf.float32))
        x += self.pos_encoding[:, :seq_len, :]

        x = self.dropout(x)

        for i in range(self.num_layers):
            x = self.enc_layers[i](x, training, mask)

        return x

the error when using x.shape[1] to replace tf.shape(x)[1]:
InvalidArgumentError: 2 root error(s) found.
  (0) Invalid argument:  Incompatible shapes: [64,38,128] vs. [1,8216,128]
	 [[node transformer_14/encoder_19/add (defined at <ipython-input-104-62f8963562be>:19) ]]
  (1) Invalid argument:  Incompatible shapes: [64,38,128] vs. [1,8216,128]
	 [[node transformer_14/encoder_19/add (defined at <ipython-input-104-62f8963562be>:19) ]]
	 [[gradient_tape/transformer_14/decoder_14/embedding_34/embedding_lookup/Reshape/_466]]
0 successful operations.
0 derived errors ignored. [Op:__inference_train_step_1459223]

Errors may have originated from an input operation.
Input Source operations connected to node transformer_14/encoder_19/add:
 transformer_14/encoder_19/mul (defined at <ipython-input-104-62f8963562be>:18)

Input Source operations connected to node transformer_14/encoder_19/add:
 transformer_14/encoder_19/mul (defined at <ipython-input-104-62f8963562be>:18)

it waste a lot of time to find it, who can explain the different betweent them, thanks

@Dragon-GCS
I ran the code shared on tf nightly and do not see any error, please find the gist here.

@Dragon-GCS
I ran the code shared on tf nightly and do not see any error, please find the gist here.

The code in my question is not complete，you can see the whole code in this notebook。It‘s from this document. You can run all the cell in colab,and you wil find the error in the last cell output. This error occur in the class Encoder, when you change x.shape[1] to tf.shape(x)[1], this program can run well.

@Dragon-GCS
Please provide me with a colab gist with code that replicated the error.

Here is the simplified code:
import tensorflow as tf

def scaled_dot_product_attention(q, k, v):
  matmul_qk = tf.matmul(q, k, transpose_b=True)
  dk = tf.cast(tf.shape(k)[-1], tf.float32)
  scaled_attention_logits = matmul_qk / tf.math.sqrt(dk)
  attention_weights = tf.nn.softmax(scaled_attention_logits, axis=-1)
  output = tf.matmul(attention_weights, v)
  return output, attention_weights

class TestModel(tf.keras.Model):
  def __init__(self, d_model=128, num_heads=8,input_vocab_size=233,target_vocab_size=666, pe_input=233, pe_target=666):
    super(TestModel, self).__init__()
    self.embedding_inp = tf.keras.layers.Embedding(input_vocab_size, d_model)
    self.embedding_tar = tf.keras.layers.Embedding(target_vocab_size, d_model)
    self.pos_encoding_inp = tf.random.uniform([1,input_vocab_size,d_model])
    self.final_layer = tf.keras.layers.Dense(target_vocab_size)

  def call(self, inp, tar):
    ##########      it will raise a error when using inp.shape[1]      ##########
    #####  When use tf.shape or ignore adding self.pos_encoding_inp, it run well  #####
    seq_len = inp.shape[1] # tf.shape(inp)[1]
    inp = self.embedding_inp(inp)
    inp += self.pos_encoding_inp[:, :seq_len, :]

    tar = self.embedding_tar(tar)
    tar, _ = scaled_dot_product_attention(v=inp, k=inp, q=tar)   ## raise error
    out = self.final_layer(tar)
    return out

testmodel = TestModel()

train_step_signature = [tf.TensorSpec(shape=(None, None), dtype=tf.int64),
             tf.TensorSpec(shape=(None, None), dtype=tf.int64)]

optimizer = tf.keras.optimizers.Adam()
loss_object = tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True, reduction='none')

@tf.function(input_signature=train_step_signature)
def train_step(inp, tar):
  tar_inp = tar[:, :-1]
  tar_real = tar[:, 1:]
  with tf.GradientTape() as tape:
    predictions = testmodel(inp, tar_inp)
    loss = loss_object(tar_real, predictions)
  gradients = tape.gradient(loss, testmodel.trainable_variables)
  optimizer.apply_gradients(zip(gradients, testmodel.trainable_variables))
  print('step over')

input = tf.constant(np.random.randint(0, 100,[64,40]),dtype=tf.int64)
target = tf.constant(np.random.randint(0, 100,[64,39]),dtype=tf.int64)
train_step(input, target)

I m able to replicate this issue on tf 2.3,2.5 and nightly, please find the gist here can you please refer to this comment based on the error reported.

I read the link you mentioned, and I think my issue is not same as it. When I debug this error, x.shape and tf.shape(x) will rasie different value. So I think it will be a hidden danger and I mainly want to know why they are different.
BTW, thanks for your patients and replys.

@Dragon-GCS I didn't look at your code in detail but the main difference between x.shape (which results in static shape) and tf.shape (which results in dynamic shape) are described here. Thanks!


Need to sudo to install the package as well as perform update.

Currently upgrades fail with:
docker-machine upgrade reinesdocker
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Thx -- could you please sign your commit? https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work

Sorry, signed :pencil2:

LGTM

Thanks!


Using Assign() on consumer with Partition.Any doesn't consume anything

Description
I'm trying to create a consumer that will, when started, always read from the beginning of a topic that has multiple partitions. I could achieve this by always generating a new group ID and using AutoOffsetReset.Earliest, but somehow that doesn't feel like the right way.
In the consumer example is Assign() called with a specific partition value of 0 and offset beginning, but I don't think that's going to work for my use case, since I'm trying to read from all partitions.
I've tried creating a consumer and using assign with:
var consumerConfig = new ConsumerConfig
{
    GroupId = new Guid().ToString(),
    BootstrapServers = settings.BootstrapServers,
    AutoOffsetReset = AutoOffsetReset.Earliest
};

var consumer = new ConsumerBuilder<string, string>(consumerConfig).Build();

consumer.Assign(settings.Topics.Select(topic => new TopicPartitionOffset(topic, Partition.Any, Offset.Beginning)));

However, that doesn't seem to work, as in, it's not consuming anything from the topic. Explicitly specifying a partition (for example 0), does work.
Checklist

Using Confluent.Kafka 1.0.0 nuget version

You should check out the answer in this question. I guess the only thing that will be different is .High ->.Low

If you don't need to use the consumer group re-balance capability, then best not to use Subscribe - just assign directly as you're doing. Due to a quirk of librdkafka, you'll still need to specify a group id, though it's ignored. Instead of using Partition.Any, you need to specify a TopicPartitionOffset for every partition you want to consume from. You can use GetMetadata on the AdminClient to get information about number of partitions if you don't know this ahead of time.

Thanks, I think that's the missing piece then, I kind of assumed Partition.Any meant I don't care which one, just read from all partitions. If that's not the case, when would one use Partition.Any then?
I don't think I need the rebalance capability. This service is deployed in a Kubernetes cluster and will be scaled horizontally to a given number and I need each instance of the service to read the entire topic from all partitions.
Our topics do have a fixed number of partitions, so I suppose I could get it to work then by using your suggestion to specify a TopicPartitionOffset for each partition. I'll play around with this and see what works best, this or using the AdminClient.
Do you reckon it would be useful to extend this library to provide a convenience option for Assign() so that it does work the way I expected it to work, by reading all partitions? Or perhaps making it a bit clearer in the docs?

Using the AdminClient indeed works fine, so I'll close this one then. Thanks for the suggestion!


Missing test timeout causing extremely long test runs

What happened?
It looks like occasionally the nodejs test times out but it takes it 2 hours. This blocks downstream tests from the bridge.
We should likely time out much quicker.
Example
https://github.com/pulumi/pulumi-f5bigip/actions/runs/7673813070/job/20917408287
https://github.com/pulumi/pulumi-f5bigip/actions/runs/8480521522/job/23236558203?pr=427
Output of pulumi about
.
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@VenelinMartinov What is the expected timeout for TestAccVirtualAppliance? If it takes 1 minute normally, but a bug caused it to hang forever, then we should shorten the timeout. If it normally takes 1.5 hours, then 2 hours is a reasonable timeout.
In other words, is the problem a flakey test or a overlong test.

another instance of this: https://github.com/pulumi/pulumi-f5bigip/actions/runs/8716924785/job/23911478597


Change to use sentry2

https://app.clubhouse.io/spiirdk/story/9177/change-to-use-sentry2
Draft until I update build pipeline

Pipeline updated with variables and test environment's keyvault updated with sentry2 dsn

Also updated sandbox and prod. (Will require release or restart of app services to take effect.)


[terra-notification-dialog] accessibility/focus issue

Bug Report
Description

Whenever the notification dialog is opened the focus is not assigned to an interactable element like the buttons at the bottom of the dialog. Instead the focus is being assigned to the dialog itself and the user has to press tab to get to the buttons.
demo here: https://web.microsoftstream.com/video/10c492af-5fac-434a-89b1-94b36c810a06
Steps to Reproduce

go to https://engineering.cerner.com/terra-ui/components/cerner-terra-framework-docs/notification-dialog/notification-dialog
start screen reader (JAWs for windows, VoiceOver for Mac)
open notification dialog
The issue can be observed in this step. We're expecting the focus to be assigned to a button at the button the dialog, but it's not.

Additional Context / Screenshots

Expected Behavior
When the modal dialog is opened I expect the focus to be assigned to one of the buttons at the bottom of the dialog.
Possible Solution

Environment

Component Name and Version: terra-notification-dialog and version 4.23.0
Browser Name and Version: Edge and version 105.0.1343.53
Node/npm Version: [e.g. Node 8/npm 5]
Webpack Version:
Operating System and version (desktop or mobile):

@ Mentions

Spoke with Rachel Magario from our UX/Accessibility team and they concluded that this is functioning correctly, so closing this issue.


When use batch_size>2

Hi, thank you for sharing code! As the default batch_size=2, training is fine. But when use batch_size = 8 , get error as bellow:

Hoping for your reply!

Thank you, decrease to 3 is work. Another question, the Prediction head of MobileStyleGAN is only useful for training, when model forward, those part can skip.

@zhongtao93 it works on iPhone 12 for 4fps with the output size of 1024x1024, we didn't test for less resolution.

Thank you. Do you think this model is likely to run realtime with the output size of 256x256 on the mobile phone? After reduce the number of channels or other Pruning method.

Hi,I have a same question.Did you have any results?


unixPB: Dont install GA JDK17 bootjdk on alpine aarch64

[x] commit message has one of the standard prefixes
[ ] faq.md updated if appropriate
[ ] other documentation is changed or added (if applicable)
[ ] playbook changes run through VPC or QPC (if you have access)
[x] VPC/QPC not applicable for this PR
[ ] for inventory.yml changes, bastillion/nagios/jenkins updated accordingly

Installing GA JDK17 aarch64 alpine linux as a bootjdk (using the adoptopenjdk_install role) is causing an error since the GA doesnt exist. We install a nightly version in the common role.
Theres an issue here to discuss merging the bootjdk installs in the common role and the adoptopenjdk_install role, but until then this pr will stop errors such as https://ci.adoptium.net/job/centos7_docker_image_updater/574/execution/node/77/log/ in the build image updater job
 > [5/5] RUN set -eux;  cd /ansible;  ansible-playbook -i hosts ansible/playbooks/AdoptOpenJDK_Unix_Playbook/main.yml -e "git_sha=8803a16b196c127edb73c33b63ec9ace14008fd5" --skip-tags="debug,hosts_file,hostname,adoptopenjdk,jenkins,nagios,superuser,docker,swap_file,crontab,nvidia_cuda_toolkit";  rm -rf /ansible; apk del ansible:
671.6
671.6 TASK [adoptopenjdk_install : Download latest release (Linux/Alpine-Linux)] *****
672.3 FAILED - RETRYING: Download latest release (Linux/Alpine-Linux) (3 retries left).
678.1 FAILED - RETRYING: Download latest release (Linux/Alpine-Linux) (2 retries left).
683.8 FAILED - RETRYING: Download latest release (Linux/Alpine-Linux) (1 retries left).
689.6 fatal: [localhost]: FAILED! => {"attempts": 3, "changed": false, "dest": "/tmp/jdk17.tar.gz", "elapsed": 0, "msg": "Request failed", "response": "HTTP Error 404: Not Found", "status_code": 404, "url": "https://api.adoptium.net/v3/binary/latest/17/ga/alpine-linux/aarch64/jdk/hotspot/normal/eclipse?project=jdk"}

Now that hyphens are removed in the boot jdk symlinks, they should be remove from the symlinks created in the Common role too, which this pr also includes

Will we still have a JDK17 (Temurin EA or from elsewhere) installed on the machine to bootstrap the 17EA builds?

Will we still have a JDK17 (Temurin EA or from elsewhere) installed on the machine to bootstrap the 17EA builds?

Yes, line 183 will still install a nightly boot JDK17 on aarch64 alpine linux

Closing this as the PR has been closed (Noting that it was in iteration 3 but I can't currently select that as it's closed).
Haroon, I don't think there's any reason to but feel free to re-open if you believe there is more work here.


Network model

Dear sir:
Thank you for the code you provided, I can already run it, but there are still some questions as following:
1,The training effect is not very good, I trained epoch=6, looked at the results is not very good, I don't know if it is because the number of training is too small. what about yours?
2, I read the code you wrote, it is very good, and I have some points do not understand, such as the setting of some parameters, can you provide the model of the network?
Thank you so much

@qiuxiaqing

6 epochs is not enough, besides, there is a related issue #5.
I am sorry that I haven't saved any model for this code.

@qiuxiaqing

The original paper recommends 200 epochs for training

I have some saved models based on modifications of this code. Please find them here
https://github.com/andrewginns/CycleGAN-Tensorflow-PyTorch/releases

The default parameters match those found in the orignal paper. What parameters would you like further information on?

@andrewginns Thanks so much for your help. I will take a closer look at the model you provided.
I have some small details in the code that I don't understand. For example,
1, In train.py, why set a2b_sample and b2a_sample,
2,In train.py, there is "g_loss_a2b = tf.losses.mean_squared_error(a2b_logit, tf.ones_like(a2b_logit))", I don't know why is tf.ones_like(...) instead of tf.zeros_like(...).
The same is d_loss_a_real = tf.losses.mean_squared_error(a_logit, tf.ones_like(a_logit)).
I know that this is also the case in the original GAN network, but I don't know why it is, can you help me?
My English is a bit poor, I don't know if you can understand me, thank you very much.


Update timestamp to 1.0.1

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Thank you for the contribution. It was merged directly as d2189fa73e82526177e6cf970f68f0c210c50ba1. Your contribution is still credited to you.


Improvements to file list UI

Short description of the problem this fixes or functionality that this introduces. This may be used for the CHANGELOG
Improvements to file list UI

Don't show the agent as loaded until the runtime is ready

Currently the UI shows an empty workspace even when it says it's ready

Filter files based on gitignore at the API level, not the runtime level

Runtime should have access to all files

Always filter .git
Show a "loading" message instead of zero state when waiting for files

Give a summary of what the PR does, explaining any non-trivial design decisions
Most controversial thing here is probably running wait_until_alive in the runtime constructor.

Link of any specific issues this addresses

@xingyaoww would love your thoughts on whether:

it's OK to move the file-hiding logic out of the runtime (IMO this is important--agent might want to e.g. look inside node_modules to debug)
it's OK to wait for the runtime to be ready inside the constructor

@rbren maybe we could put some effort together? :)
https://github.com/All-Hands-AI/OpenHands/pull/3771


Freezing issue on Bluestacks

In the latest version of bluestacks, attempting to use any script causes FGO to immediately lock up as soon as you hit the play button and require a hard reset of the emulator.

Seems like an issue between Ankulua and Bluestacks.
You can either wait until the Ankulua devs fix this issue, or try using another emulator.
Looks like other people are also having that problem >
http://ankulua.boards.net/thread/1568/all-screen-freezes-starting-script

I figured out how to fix it-- turning on the Advanced Graphics Engine in bluestacks options makes everything work fine. ID-10T error~


Unique ID for full sample JSON in modal

Resolves #3431
In 0.21.6, modal sample data can be overwritten by the group carousel due to globally unique id store in relay. Adding a -modal suffix to sample IDs when they are requested without pagination data resolves the issue. The -modal naming is tentative.
The best way to add an e2e test is to screenshot the JSON panel in a group dataset. In progress

@benjaminpkane today I tried two ways to test this and failed,

I tried screenshotting JSON viewer but quickly realized new attributes added to samples are not available in JSON viewers at all so I stopped.
I confirmed that new attributes are visible in canvas if you hover over a label with attribute. But, canvas testing does not look straight forward so far...

@sashankaryal what do you advise?

If it turns out uneasy to test, I vote for merging it since it is a low risk code path,

I tried screenshotting JSON viewer but quickly realized new attributes added to samples are not available in JSON viewers at all so I stopped

The attributes should be present in JSON. I don't think this is true.
I think adding JSON viewer method(s) to the Modal POMs would be valuable, but it doesn't have to be for this PR. I'm fine with merging without tests.


Deflake Mac module_test_ios

Deflake module_test_ios as no flake in recent 100 commits.
https://github.com/flutter/flutter/issues/89175

It hit https://github.com/flutter/flutter/issues/97303, try rebasing onto https://github.com/flutter/flutter/pull/98297 ?
https://ci.chromium.org/p/flutter/builders/try/Mac module_test_ios/12058?
See also https://github.com/flutter/flutter/issues/99039 for the other simulator infra issue we're seeing.

Well module_test_ios passed but now you need to rebase on https://github.com/flutter/flutter/pull/99075.  Are we having fun yet? 🙂


Tracy improper instrumentation when memory tracing

Tracy throws improper instrumentation error after short time. Reason is reporting of previously allocated but not freed address.

When COLLECT_PRINTF is used during compilation error is gone; only programmatic effect of this debug flag is this.