Set default device setting without using MQTT?

Is there a way to set default device property, specifically $stats/interval in setup code? can’t find anything online that details it and would like to change it to 5 minutes by default for all devices instead of just 1 minute
so I found const uint32_t STATS_SEND_INTERVAL = 1 * 60 * 1000; in Constants.hpp but still can’t seem to figure out the correct way to set this without modifying the lib code

Nope (that I know of) will add in my next release.

Awesome thank you, just the ability to configure or override any default settings would be perfect 👍  thanks!!

@timpur now that i'm looking at this ... is it even possible to set interval via MQTT?  I can't seem to figure out any way to change the interval value used ... which maybe I don't understand the purpose of it, but my understanding is that interval would be something settable so you can change it as needed ... but now it looks like it's just a static value?

The interval is used to send info like signal and up time
It would be nice to be able to configure this. Thinking of doing this through the config, thus you can also update over mqtt via incremental json

But isn't it also important for the MQTT server to receive this kind of "ping" message in a not "too long" interval? Kind of keepalive. Otherwise he will consider the device offline?!?
I don't know enough about MQTT (whether and how it is possible to connect and tell the server at the same time how often you will ping it). I only remember having problems with one (non C) MQTT library where I couldn't set a keepalive interval and had to make sure to ping the server once every minute.

The keep alive period is handled by the mqtt lib and has nothing to do with homie. By protocol (my understanding) when the client connects it tells the broker the keep alive period and if that period is broken then the broker considers the connection broken....
Nothing to do with this stats interval with homie.

@timpur yeah i'll probably start working on this and submit a PR if you haven't already ... did you have any specific ideas in mind of how to set it up?  I can probably work on the code if you wanted it done in a specific way, but I will need this for my current project.
Reason being ... use case scenario would be outputting data on a dashboard ... so when the user is viewing dashboard for a device, we would want to update the interval to say, every 15 seconds to give a better UI experience, whereas, when just storing stats, we would only want it set to every 300 seconds (5 minutes) instead

Okay well that's not a big change let me do this today. I'll get onto it now

Closed by #455
You can now add the interval in seconds in the config file, which means you can also use incremental json to change this via mqtt if you like. Node not yet set this in the web UI configurator

Awesome, thank you!!  Yeah I doubt it would need to be set in the web UI, but if someone really needed it they could just setup a "custom" setting to allow for that, thanks again, will test and let you know if i find any issues!

Any possibility of adding a function similar to Homie_setFirmware for the interval, say, Homie_setStatsInterval to allows configuring initial interval in the setup function?
I did see you added the ability in the config file, just wasn't sure if Homie would read incremental config.json from spiff or not ... as I do still want to use the Web UI setup (interval not necessary to set in web UI)
Also posted this in #454

@timpur yeah understandable, but I meant that I would like to be able to set the default value configured for the device even before it's setup and ready to go.
Mainly to set default to around 5 minutes, and then I can adjust via MQTT once it's connected to the broker via incremental json.  I guess for now I can just immediately send an incremental json to the device once it connects to the broker and change it from 1 minute to 5 minutes ... which just be much cleaner to be able to set the default value in the setup function, just like we would with a normal HomieSetting

i think you miss understand, you can upload the config file from your computer with the 5min value with out the need of mqtt. See http://marvinroger.github.io/homie-esp8266/docs/develop/configuration/json-configuration-file/ .You also dont need to use configurator if you wait to just upload the config file via your computer. Uploading files to file system
also see https://github.com/marvinroger/homie-esp8266/tree/develop/data/homie


Issues with Curse page

The links to McJtyLib and ElecCore are broken
It says "If you want to discuss RFTools" instead of "If you want to discuss Deep Resonance"
The spotlight video uses an insecure HTTP URL, so browsers won't show it unless you "Load unsafe scripts"

Fixed 1 and 2. Don't know how to fix 3 as I cannot seem to edit that url

For 3, hit the "Source code" button on the toolbar (looks like </>), and look for the "iframe" tag. Then just change the "http" to "https".


files belonging to a relation being created (transaction not yet committed/rollbacked) are reported as orphaned

corner case as the file exists but RelidByRelfilenode returns InvalidOid (which makes sense as the relation is not created/visible yet)

has been fixed in commit: 94887e4fc562625e5dabc31b13f22ddb589635ad


Error: "xcodebuild redefinition of 'sqlite3_xxx'" when building fresh expo project

Problem
Can't build expo app, get a bunch of errors like
❌  (ios/Pods/Headers/Public/react-native-quick-sqlite/sqlite3.h:723:8)

  721 | */
  722 | typedef struct sqlite3_file sqlite3_file;
> 723 | struct sqlite3_file {
      |        ^ redefinition of 'sqlite3_file'
  724 |   const struct sqlite3_io_methods *pMethods;  /* Methods for an open file */
  725 | };
  726 |

Also get a warning when I run expo-doctor about this package being 'Untested on New Architecture'
Steps to reproduce

create an expo app with npx create-expo-app
install with npx expo install @journeyapps/react-native-quick-sqlite
Try and build the project with npx expo run:ios

Having this problem as well when using eas build

Hey @felixsebastian and @histefhere
This issue is caused by multiple versions of SQLite3 being included in your project, which happens because expo-updates also depends on SQLite. The solution is to enable the third-party SQLite pod for expo-updates.
To fix this, update your app.json or app.config.js to include the following configuration:
{
  "expo": {
    "updates": {
      "useThirdPartySQLitePod": true
    }
  }
}

For more details, you can refer to the discussion in Expo issue #30546.
Let us know if this works for you.

I'm confused because I see the original developer list the fix as:
expo.updates.use3rdPartySQLitePod: "true" via 30826
Is the correct syntax what you have provided @mugikhan ?
My issue pertains to an error starting with
` 37 | #include <regex.h>
38 |

39 | static void sqlite_regexp(sqlite3_context* context, int argc, sqlite3_value** values) {
|                           ^ unknown type name 'sqlite3_context'; did you mean 'exsqlite3_context'?
40 |   if ( argc < 2 ) {
41 |     sqlite3_result_error(context, "SQL function regexp() called with missing arguments.", -1);
42 |     return;`

Platform: ios
Target OS: 15.1
I reinstalled pods, changed configs, took out any db interactions I had, etc. however, I still come to the same problem.
It's actually a problem with react-native-sqlite-storage; however, I'm guessing that's common knowledge?

@DeliveranceTechSolutions My statement is correct, I have tested it personally and it works. It also aligns with what is currently in the Expo package See here.
Is there any other packages you are using that could be providing sqlite3 maybe expo-sqlite?

After running prebuild I added
 {
  "expo.updates.useThirdPartySQLitePod": "true"
}

```to **ios/Podfile.properties.json**, and then after that I ran npx expo run:ios, which successfully build the app on the simulator. However when I then run an EAS build I still get this error: Build failed: The "Run fastlane" step failed because of an error in the Xcode build process. We automatically detected following errors in your Xcode build logs:
redefinition of 'sqlite3_file'
redefinition of 'sqlite3_io_methods'
redefinition of 'sqlite3_vfs'
redefinition of 'sqlite3_mem_methods'
conflicting types for 'sqlite3_create_filename'
conflicting types for 'sqlite3_free_filename'
redefinition of 'sqlite3_module'
redefinition of 'sqlite3_index_info'
redefinition of 'sqlite3_index_constraint'
redefinition of 'sqlite3_index_orderby'
redefinition of 'sqlite3_index_constraint_usage'
redefinition of 'sqlite3_vtab'
redefinition of 'sqlite3_vtab_cursor'
redefinition of 'sqlite3_mutex_methods'
redefinition of 'sqlite3_pcache_page'
redefinition of 'sqlite3_pcache_methods2'
redefinition of 'sqlite3_pcache_methods'
redefinition of 'sqlite3_snapshot'
typedef redefinition with different types ('struct (unnamed struct at /Users/expo/workingdir/build/ios/Pods/Headers/Public/react-native-quick-sqlite/sqlite3.h:10109:16)' vs 'struct sqlite3_snapshot')
could not build Objective-C module 'SQLite3'
Refer to "Xcode Logs" below for additional, more detailed logs.

After running prebuild I added {
"expo.updates.useThirdPartySQLitePod": "true"
} to ios/Podfile.properties.json, and then after that I ran npx expo run:ios, which successfully build the app on the simulator. However when I then run an EAS build I still get this error: Build failed: The "Run fastlane" step failed because of an error in the Xcode build process. We automatically detected following errors in your Xcode build logs:
redefinition of 'sqlite3_file'
redefinition of 'sqlite3_io_methods'
redefinition of 'sqlite3_vfs'
redefinition of 'sqlite3_mem_methods'
conflicting types for 'sqlite3_create_filename'
conflicting types for 'sqlite3_free_filename'
redefinition of 'sqlite3_module'
redefinition of 'sqlite3_index_info'
redefinition of 'sqlite3_index_constraint'
redefinition of 'sqlite3_index_orderby'
redefinition of 'sqlite3_index_constraint_usage'
redefinition of 'sqlite3_vtab'
redefinition of 'sqlite3_vtab_cursor'
redefinition of 'sqlite3_mutex_methods'
redefinition of 'sqlite3_pcache_page'
redefinition of 'sqlite3_pcache_methods2'
redefinition of 'sqlite3_pcache_methods'
redefinition of 'sqlite3_snapshot'
typedef redefinition with different types ('struct (unnamed struct at /Users/expo/workingdir/build/ios/Pods/Headers/Public/react-native-quick-sqlite/sqlite3.h:10109:16)' vs 'struct sqlite3_snapshot')
could not build Objective-C module 'SQLite3'
Refer to "Xcode Logs" below for additional, more detailed logs.

I tested this locally and on EAS build. Adding my findings here for context.
I ran the following to create a fresh app.
npx create-expo-app
npx expo install @journeyapps/react-native-quick-sqlite
npx expo run:ios

For me this did not give any errors. The app launched after building. Since this issue is related to multiple definitions of SQLite. I manually added expo-updates with npx expo install expo-updates. I could then reproduce the issue.
I followed the steps recommended by Mugi of adding the settings to my /ios/Podfile.properties.json file and the build then succeeded locally. I then triggered an EAS build with eas build -p ios --profile preview  which also succeeded.
For some background: It seems like expo-updates will use the system version of SQLite now by default. If the system SQLite3 library is used in conjunction with React Native Quick SQLite then these redefinition of ... errors will be present. Setting expo.updates.use3rdPartySQLitePod: "true" will cause expo-updates to instead install the sqlite3 pod dependency. This still technically results in multiple versions of SQLite being present in the project, which is not ideal, but with the default project linking settings this seems to be less error prone than using the system version. If using frameworks with static linking other issues may still arise.
@histefhere I'd start by verifying the ios folder and Podfile.properties.json files are not added to any gitignore of easignore entries. Otherwise could you share a minimal reproducible example repo?


BUG: Cannot build jaxlib on CentOS

Description
I am trying to follow these instructions to build jaxlib with CUDA support on a Slurm computing cluster. When I run python3 build/build.py --enable_cuda, I get the following error:
Downloading bazel from: https://github.com/bazelbuild/bazel/releases/download/5.1.1/bazel-5.1.1-linux-x86_64
Traceback (most recent call last):
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 1348, in do_open
    h.request(req.get_method(), req.selector, req.data, headers,
  File ".../anaconda3/envs/py10/lib/python3.10/http/client.py", line 1282, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File ".../anaconda3/envs/py10/lib/python3.10/http/client.py", line 1328, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File ".../anaconda3/envs/py10/lib/python3.10/http/client.py", line 1277, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File ".../anaconda3/envs/py10/lib/python3.10/http/client.py", line 1037, in _send_output
    self.send(msg)
  File ".../anaconda3/envs/py10/lib/python3.10/http/client.py", line 975, in send
    self.connect()
  File ".../anaconda3/envs/py10/lib/python3.10/http/client.py", line 1454, in connect
    self.sock = self._context.wrap_socket(self.sock,
  File ".../anaconda3/envs/py10/lib/python3.10/ssl.py", line 512, in wrap_socket
    return self.sslsocket_class._create(
  File ".../anaconda3/envs/py10/lib/python3.10/ssl.py", line 1070, in _create
    self.do_handshake()
  File ".../anaconda3/envs/py10/lib/python3.10/ssl.py", line 1341, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File ".../jax/build/build.py", line 555, in <module>
    main()
  File ".../jax/build/build.py", line 473, in main
    bazel_path, bazel_version = get_bazel_path(args.bazel_path)
  File ".../jax/build/build.py", line 195, in get_bazel_path
    for path in filter(None, get_bazel_paths(bazel_path_flag)):
  File ".../jax/build/build.py", line 183, in get_bazel_paths
    yield download_and_verify_bazel()
  File ".../jax/build/build.py", line 150, in download_and_verify_bazel
    tmp_path, _ = urlretrieve(uri, None,
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 241, in urlretrieve
    with contextlib.closing(urlopen(url, data)) as fp:
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 216, in urlopen
    return opener.open(url, data, timeout)
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 519, in open
    response = self._open(req, data)
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 536, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 496, in _call_chain
    result = func(*args)
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 1391, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
  File ".../anaconda3/envs/py10/lib/python3.10/urllib/request.py", line 1351, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997)>

What jax/jaxlib version are you using?
jaxlib v0.3.15
Which accelerator(s) are you using?
GPU
Additional System Info
Python 3.10.4, CentOS 7 (Core)

Possibly related issue: #11304

It sounds to me like something is broken with SSL root of trust in your python implementation. This isn't really JAX specific: this means that python is unable to open an https connection to github.com. I suspect you need to fix something about your Python installation or the SSL key store that it is using.
(Or just use a prebuilt jaxlib.)
I'm not sure there's any action we can take here.


Node 7.7 broken

When I try to build better-sqlite3 for node 7.7, I get this error:
In file included from ../node_modules/nan/nan.h:47:
/Users/josh/.node-gyp/7.7.0/include/node/node.h:44:10: fatal error:
      'tracing/trace_event.h' file not found

It works fine in node 7.6

Never seen a tracing header. I think you should file a bug against node.js, or node-gyp. I believe there has been some reshuffling of files and directories. My theory is that no native modules can be built with Node 7.7.

See https://github.com/nodejs/node/issues/11628, which is being fixed at https://github.com/nodejs/node/pull/11634
(tl;dr: It’s Node’s fault and 7.7.1 will be out with a fix soon)

Thanks for a quick response. I'll leave this issue up until I can remember to close it, so we hopefully don't get repeat filings.

Cool, thanks for the info.

@kkoopa v7.7.1 is out


The script deleted all my non-steam shortcuts

I used NSL to install an EA game last week, and after this installation, I lost all my other non-steam games: emulation games from Emudeck, and abandonware games that I added manually (Blur, NFS Carbon, ...)
I ended up deleting everything and I'll will reinstall them one by one but if you could check that, it would be nice so it doesn't happen again.

@jullebarge this is already fixed in the new update?


Fix/no floating promises

closes #3515

added @typescript-eslint/no-floating-promises: error rule
changed "no-console": ["error"] to "no-console": ["error", { allow: ["warn", "error"] }] (we at least log the error messages of the floating promises)
fixed lint/compile errors

bors r+


Apple Pay is work in simulator, but not in real

Describe the bug
when i use useApplePay to check is supported Apple Pay, it's return true in simulator, but return false in real;
To Reproduce
follow official doc steps:  https://stripe.com/docs/apple-pay?platform=react-native;
and repeatedly confirmed that the merchant ID is consistent

i have configed StripeProvider merchantIdentifier

Mainland China's Apple Pay is not supported...
After I switch to the foreign bank card, it's worked


UEB: Omission character emitted for empty MathML tags

If I send the following to MathCAT:
<math> </math>

I get ⠬ as the computed braille string. This seems od, but while on the topic, I'm wondering what one sends to MathCAT to intentionally get this result?

I've been working on the space/omission code for the last several days. There is no obvious method to tell if a space is an omission or just a space, but my changes are at least moving towards making it clearer in what MathCAT does. One of the changes is to attempt to measure the size of a space and if it is big enough (still deciding on the cutoff, but probably 1em to 1.3em), it is an omission otherwise just a space. A single non-breaking space in the new code will be a space but two of them will be an omission. The idea being that an omission should be more obvious.
If the space is small (maybe < 0.25em), then it is thrown out as a spacing tweak and not a true intended space.
The best solution is for the author to state what they mean. The MathML WG has tentatively added intent='blank' as a way of marking an omission. Some example usages are:
<mi intent='blank'>__</mi>
<mi intent='blank'>?</mi>
<mo intent='blank'>□</mo>
<mspace intent='blank' width='3em'/>
<menclose intent='blank' notation='box'> <mspace width='3em'/> </menclose>

We probably should also add either a 'this space intentionally added' or 'this space is just a tweak' concept also.
To answer your question, you can write:
<math>
   <mspace intent='blank' width='2em'/>
</math>

There are lots of other methods that should work after I finish my rewrite, but using mspace gives you control over how wide the space should be.

I've checked in code that does what I mentioned above. Additionally, if the space is wide enough (two non-breaking spaces or an mspace with width='1.3em' or greater, that will be consider an omission also. Specifying `intent=':blank' is safest.


Proper fix for digest auth

For monero-wallet-rpc as of v<IP_ADDRESS>, this library occasionally fails the digest auth. This is because monero-wallet-rpc expects both requests (first, unathenticated and second, with "Authorization" header) for digest auth to occur in exactly same TCP session. This can be done by using custom HTTP Agent.
https://nodejs.org/docs/latest/api/http.html#http_class_http_agent
https://stackoverflow.com/questions/10895901/how-to-send-consecutive-requests-with-http-keep-alive-in-node-js

OK, will try this out

I'd recommend you switch over to the much more up to date https://github.com/sneurlax/monerojs (soon to be https://github.com/monerojs/monerojs), though.  Your contributions would be very much appreciated there


refactor(backend): index change authors

Having authors indexed for each change in the database should help implementing Trusted Contacts when filtering trusted/untrusted Changes and Heads.

Now we are getting the "1690447002992640" is not greater than "1690447003000000" error all the time


An error report

Hi,
This is Ruoyu. I found a small issue in the function meq_vec:
@ti.func
def meq_vec(rho_local,u):
out = ti.Vector([0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0])
out[0] = rho_local;             out[3] = u[0];    out[5] = u[1];    out[7] = u[2];
out[1] = u.dot(u);    out[9] = 2u.xu.x-u.yu.y-u.zu.z;         out[11] = u.yu.y-u.zu.z
out[13] = u.xu.y;    out[14] = u.yu.z;                            out[15] = u.x*u.z
return out
All the non-zero meq component should have density component, but the meq[k] except for meq[0] does not contain rho_local.
Regards,
Ruoyu

Also, a few components of meq is missed out, such as meq[8], meq[12], etc.

Hi Jianhui,
Thanks for your reply. What is the paper you are referring to? The attachment is not seeable.
Regards,
Ruoyu

Here it is:
Ahrenholz, B., et al. "Prediction of capillary hysteresis in a porous
material using lattice-Boltzmann methods and comparison to experimental
data and a morphological pore network model." Advances in Water
Resources 31.9
(2008): 1151-1173.
On Wed, 13 Sept 2023 at 01:25, Ruoyu66666.github.io <
@.***> wrote:

Hi Jianhui,
Thanks for your reply. What is the paper you are referring to? The
attachment is not seeable.
Regards,
Ruoyu
—
Reply to this email directly, view it on GitHub
https://github.com/yjhp1016/taichi_LBM3D/issues/19#issuecomment-1716759112,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJEDKQFETLUC6URA3CCG7HTX2D4OTANCNFSM6AAAAAA4UE357A
.
You are receiving this because you commented.Message ID:
@.***>

Thank you Jianhui, I'll check it out.


feat: configuration file for sam cli commands

add passthroughs to the CLI command line interface via a configuration
file

local defaults are set at: .aws-sam/sam-app-config

This commit contains code copied and modified from https://github.com/phha/click_config_file/blob/master/click_config_file.py under MIT license

Design doc PR is separate: https://github.com/awslabs/aws-sam-cli/pull/1503

[ ] Design doc

[ ] Write unit tests

[ ] Write/update functional tests

[ ] Write/update integration tests

[x] make pr passes

[ ] Write documentation

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

Integration tests are working locally, need to investigate appveyor gates. Unrelated PR: https://github.com/awslabs/aws-sam-cli/pull/1501 is experiencing similar issues.

open to modification of --identifier. it could be environment, mode, config.

@awood45 thanks for the review! yes those tests will be added in next series of commits.


Upgrade to Vite 6

Which scope/s are relevant/related to the feature request?
create-analog
Information
Vite 6 brings the new Environment API for framework authors to support multiple environments more natively with Vite.
Describe any alternatives/workarounds you're currently using
No response
I would be willing to submit a PR to fix this issue

[x] Yes
[ ] No

I think this is blocked until vitest 3.0 is released

https://github.com/vitest-dev/vitest/releases/tag/v3.0.0-beta.1
We decided to skip Vitest 2.2 and release Vitest 3 with support for Vite 6 instead. There will be no more Vitest 2 versions. Vitest 3 is the first version that supports Vite 6 (excluding 2.1.6). We aim to have a stable release in January.


Fix generic parser

Previously, the parser looked for the active and verified columns twice:
First, by looking for such column names and, secondly, by checking
column number 9 and 10 (which are fixed).  This PR removes the
latter part.

Thanks for the PR @Nilix007 . Are you in the position to add some small unit tests like the other parsers have? Would make it easier for us to trust the PR also ;-)

Uh, lost track of this PR.  Rebased to dev 👍


Add withdraw by comment.  Update tests and libs.

Contract
A small change to the contract code.
Now it's possible to withdraw all the available coins (minus minimum for storage) by sending a simple comment message with text w from a cold wallet (e.g. ledger) to its nominator.
TS
I've been unable to run the tests after cloning the repo. This PR updates the TS imports and removes some deprecated code used with "ton" lib, by switching to a modern library - "@ton/ton".

In humble duty, I present this craft; earnestly beseech thine grace for acceptance.

alhamdulilh


New major version -- what do we want to change

Regarding #4, now might be a good a time as any to start a new major release and get rid of some of the legacy weight. Especially now that the number of users is still rather low. Perhaps we can start by brainstorming what we would like to change.
As a general guideline, I also don't think we need to make a plugin that can be customized to suit for everybody's code style. For one thing, there are other plugins such as  @trivago/prettier-plugin-sort-imports.
And, more importantly, prettier itself is already an opinionated code formatter that prescribes a certain code style.  For reference, here's is their rationale: https://prettier.io/docs/en/option-philosophy.html

They only want options that are required for some purpose, such as to support external tools. But no options that are just people's opinions on how the code style should look like.
Also: people who need a very particular code style won't be using prettier, and in extension, they also wouldn't use this plugin. I beliebe prettier plugins should keep at least somewhat to the spirit of prettier. Having a single plugin that by now probably has accumulated more options than the program for which the plugin is meant feels a bit strange. Having many options also makes tests and maintenance a pain, since you now have to test various combinations of options, or get lots of bug reports if you don't.
Let's review the options we've got

importOrderBuiltinModulesToTop - We wanted to remove this in the next major release, it always puts builtins at the top.
importOrderParserPlugins - Needs to stay, this is required for the plugin to work correctly
importOrderSortSpecifiers - Any reason not to remove this and have it enabled always?
importOrderSeparation - Are people really that picky about having new lines? I also work with Java + Eclipse and it just groups imports and separates them by new lines, and nobody in our team has an issue with this. I'd just remove this and have it
importOrderGroupNamespaceSpecifiers - I'm honestly not exactly sure what this does. I also don't see any tests where this is set to true?
importOrderCaseInsensitive - This is an option I could image we might want to keep. Any opinions? If we don't, what would be the value for this?
importOrder - Other than the technical importOrderParserPlugins, I feel like this should be the main option of this plugin, if not the only one.

The default for this option is [], which I feel is a pretty bad default. It just sorts everything alphabetically, including relative imports etc.
The other thing I don't like about this option is that it requires you to specify each @scope manually. Adding a new dependency now requires you to review and sometimes change the prettier config for this plugin.
What I'd suggest is that by default, the plugin just groups all @scope/...  imports, builtin imports, and relative imports automatically.
Another additional idea would be to get rid the regexp approach and replace it with a more restricted approach that only allows the order of the various groups to be changed, something like importOrder: ["builtins", "unscoped", "@ui", "relatives", "@typescript", "scoped" ]

For the new options proposed by #4
Two more options are definitely too much. If anything, since some people might prefer separate type imports, I'd propose a single option importOrderMergeTypeImports with two values separate and mixed. Default being mixed.

mixed combines all type and value imports import {foo, type bar} from "a"
separete actively splits all type and value imports, ensuring a consistent style. So   it would change import {foo, type bar} from "a" into import {foo} from "a"; import type {bar} from "a"``

Although I'd also be fine with not having this option and just defaulting to mixed.
What we need to check
We should take a look at common, default ESLint / TypeScript ESLint options and check if they conflict with the way this plugins formats code.

Overall, I support the project of slimming down the options.
importOrderBuiltinModulesToTop
I say we drop this option & do this always.
importOrderSeparation
I say we drop this option, and let people insert "" in importOrder to express where they want gaps. (There may be a bug in how that works now, at least I struggled with that).
importOrderCaseInsensitive
I say we drop this option, and just default it to always-insensitive. I have yet to meet someone who believed capital letters shouldn't be sorted adjacent to their lowercased forms.
importOrderSortSpecifiers
I say we drop this option, and default to always sorting. I can't see a runtime-reason not to do this, and it's in the name of the plugin.
importOrderParserPlugins
Are we sure we have to keep this option? Can we detect decorators from tsconfig::experimentalDecorators? Can we detect jsx from file-extension? Can't we add typescript if a tsconfig is present?
importOrder
I definitely think we should keep this valuable option. I specifically think it's valuable because many codebases need to highlight clusters of internal packages and treat them like a special cluster of 3rd party packages. This is what my team members commented on when I added this plugin -- this was a convention before, that had to be manually enforced. Prettier doing that for us was a win. If we lost this option our package-imports would be sandwiched with 80% of 3rd party imports above, and 20% of 3rd party imports below, followed by local imports. #awkward
importOrderGroupNamespaceSpecifiers
I say we drop this option, because as far as I can tell, you can't have multiple namespace specifiers in a single import expression: import * as K, * as L from "./foo"; // illegal I'm not sure what it used to do.
Behavior change: group & sort type-imports separate from value imports
Related to importOrderGroupNamespaceSpecifiers : for #20 -- I say we should group type-imports and value imports within a single ImportDeclaration import { type A, type B, c, d } -- and we should sort these groups. This was done in the codemod from @IanVS -- but he put type imports last. I think they should be first!
import {
  type A,
  B,
  type C,
  D,

(Case I'm worried about based on current behavior, we sort by identifier if I read the code correctly)
importOrderMergeDuplicateImports importOrderMergeTypeImportsIntoRegular
Combine these two into importOrderMergeImports with 3 values: "mixed" | "separate" | "off" with the default of "mixed" -- only if the above behavior change of grouping type-imports for independent sorting is applied.
-- I think the fact that in leaves us confused on how to merge comments has me worried.

importOrderParserPlugins
Are we sure we have to keep this option? Can we detect decorators from tsconfig::experimentalDecorators? Can we detect jsx from file-extension? Can't we add typescript if a tsconfig is present?

Since I didn't write the original plugin, I'm not sure about the edge cases. Though in general we need to keep in mind that auto detection can fail for unusual use cases (e.g. if somebody runs prettier programatically?). I'd say we apply auto detection (if that's possible) when importOrderParserPlugins is not specified, but keep it for when auto detection fails. Unless somebody knows of a way that we're sure will never fail. I'm fine with a non-formatting related option.

importOrderCaseInsensitive

I think you're right, case-insensitive is probably the preferred approach here.

This was done in the codemod from @IanVS -- but he put type imports last. I think they should be first!

Personally I'd also put type import first if I have to do it manually.

If we lost this option our package-imports would be sandwiched with 80% of 3rd party imports above, and 20% of 3rd party imports below, followed by local imports.

Just for reference, could you post a sample of how your imports look like, and how your importOrder settings looks like?

I don't think we should auto-group by scope-packages, I worry about the default behavior for newlines-between groups. Lots of random 3rd party modules come from scopes now, so I don't want scattered newlines in my imports.

Yeah, more and more packages are moving towards scopes and it's not too hard to image that sooner or later most if not all packages could be scoped.That was just a wild suggestion. I'm more concerned with a sensible default anyways, and  importOrder: ["builtins", "thirdParty", "local"] sounds good.

@fbartho @blutorange thanks for the detailed proposals here.  Overall, I think we're all in agreement, with perhaps a few small details to work out.

importOrderSeparation
I say we drop this option, and let people insert "" in importOrder to express where they want gaps. (There may be a bug in how that works now, at least I struggled with that).

What problems have you been having?  Maybe you can open a new issue for it?

Personally I'd also put type import first if I have to do it manually.

Just curious, why do you both prefer that?  My rationale for putting value imports first was that value imports feel more "important", and they're also often times shorter (especially including the type notation), and it just feels more balanced to have shorter things first.  /shrug.  I don't feel strongly about it, but I do prefer value before types.  Curious to hear your thoughts.
importOrder
I agree with updating the default to sort builtins, third-party, then relative imports, but keeping it as an option.  I also agree with not treating scoped packages as special.  Personally, in my project I use @ for aliases as well (wish I had picked $, but oh well), and I need a custom importOrder rule to keep those separated from third party scoped packages.  I'd also like to maintain the regex ability.  For instance, I want to ensure that my (non-side-effect) .css files are sorted after my javascript files. So, my full importOrder looks like this:
importOrder: [
    '^(@api|@assets/|@components/|@hooks/|@util/|@dn-types/|@test-setup/|@global/)(.*)$',
    '^(?!.*[.]css$)[./].*$',
    '.css$',
],

importOrderParserPlugins
Let's keep this as an escape hatch, as @blutorange suggests.
importOrderMergeTypeImports
I think this is fine to have as a new option.  But, we'll need to keep in mind that separate will only apply to explicit type imports, right?  Right now, it's possible to mix value and type imports without specifying which ones are types.  I imagine that we won't do anything to change those, even if the option is separate, right?
importOrderGroupNamespaceSpecifiers
Here's where this was added: https://github.com/trivago/prettier-plugin-sort-imports/pull/105.  I don't see a ton of value in it, personally, and would be okay with removing it.

What problems have you been having? Maybe you can open a new issue for it?
I remember now that it was actually caused by #17 so I have no objections to assuming it should work, and defaulting to that.

type-import-grouping

Personally I'd also put type import first if I have to do it manually.
Just curious, why do you both prefer that? My rationale for putting value imports first was that value imports feel more "important", and they're also often times shorter (especially including the type notation), and it just feels more balanced to have shorter things first. /shrug. I don't feel strongly about it, but I do prefer value before types. Curious to hear your thoughts.

It's definitely subjective, but it feels like the very top things are the least important, because you're going up to check on them from reading the code and scanning back up to the references. Putting the type Foo statements first allows you to scan up first to the runtime imports, and treat the types more as ambient? -- Super subjective and I won't fight you for the default choice. Consistency is king, so I'm fine whichever way we end up.
importOrderGroupNamespaceSpecifiers
Oh Ew! This complicates our alphabetical sorting, and I'd vote delete the functionality!
importOrderParserPlugins
Unanimous: keep but try to add auto-detection so it's an escape hatch

importOrderMergeTypeImports
I think this is fine to have as a new option. But, we'll need to keep in mind that separate will only apply to explicit type imports, right? Right now, it's possible to mix value and type imports without specifying which ones are types. I imagine that we won't do anything to change those, even if the option is separate, right?

Yes, I consider resolving imported modules and applying TS specific logic to check whether an import is a type or a value to be beyond the scope of what this plugin can and should do.

Personally I'd also put type import first if I have to do it manually.
Just curious, why do you both prefer that? My rationale for putting value imports first was that value imports feel more "important", and they're also often times shorter (especially including the type notation), and it just feels more balanced to have shorter things first. /shrug. I don't feel strongly about it, but I do prefer value before types. Curious to hear your thoughts.

That's really just my gut feeling. I don't look much at imports in general, but perhaps I'm just not working on large enough projects? As I've said, personally I only want a reasonable default (canonical) behavior I can apply to all of our projects, with the same configuration (if any) for all.
If I had to give a reason, I'd put all import type { ... } from "a" before value imports, like this

And perhaps by the same token, I'd use the order import { type A, type Y, B, X } from "a".
But come to think of it, if somebody uses import { type A, type Y, B, X } from "a", that looks a lot like they really just want to separate type and value imports. If somebody wants imports to be mixed, then perhaps we should just go for import { type A, B, X, type Y } from "a".
So:
// mode: separate
import type { A, Y } from "a"
import { B, X } from "a"

// mode: mixed
import { type A, B, X, type Y } from "a"

Other than that, I'd say we also consider how it's being done in various projects and what seems to be most common
Several widely-used packages I looked at use eslint-plugin-simple-import-sort  (https://github.com/mongodb/node-mongodb-native/blob/main/package.json#L60, prisma). That plugin has only one option: Custom grouping (which corresponds to our importOrder) If you check out their github, they also have a rationale and explanation there. Perhaps we could take some ideas from them as well. In particular:

importOrderCaseInsensitive

Not sure how this plugin handles it, but as mentioned by the eslint-plugin-simple-import-sort, if we sort case-insensitively, we need to make sure that we break ties by falling back to case-sensitive sorting (or we end up with non-deterministic formatting).
E.g.
import { a } from "someTHING";
import { a } from "SOMEthing";

Let's discuss the ordering of the mixed option somewhere else, we can feel it out both ways and make a decision later.
Good point about breaking ties with imports that differ only by capitalization.  That's something we should check.  I've opened https://github.com/IanVS/prettier-plugin-sort-imports/issues/23 so we don't forget.

Let's discuss the ordering of the mixed option somewhere else, we can feel it out both ways and make a decision later.

Yes, let's how it goes. The main purpose of this issue was to find a direction for where we want to take this plugin, and it seems we all agree on that.

I've filed #24, #25 for further discussion.
I've also added a milestone for stuff I think we should address in this breaking release.

How do we want to proceed? I'm happy to do charge ahead on this.
Proposal: Can we get #19 and #20 to merge on the understanding that we're not going to ship it that way, and then we build from there?

Hey @blutorange @IanVS I still want to make progress on what we talked about! — Can we get #19 & #20 to merge, potentially as additive options?
I’d be happy to roll forwards with the other refactors to prepare a major release as we discussed up-thread?

I wanted to remove importOrderCombineTypeAndValueImports and always enable it, but I think it's not possible without checking that the user's TypeScript version is at least 4.5.   I also don't want to try to detect the user's TypeScript version, for a few reasons:

It's tough to do reliably.
It would likely require reading a package.json file from the filesystem, which would impact perf.
Upgrading TypeScript would trigger a mass reformat to combine type and value imports, which is a little unexpected.

So instead, I'm going to experiment with enabling the option by default, with the possibility for the user to disable it if they're using an older version of TypeScript.  Flow has supported the syntax forever, so it's not a problem there at least.

We could offer a typescript max version override to enable this and future version downgrades?

Hmmm, that's an interesting thought.  Can you talk a bit more about how you might envision that working, @fbartho?

If I understand you correctly, we'd add a setting like importOrderTSVersion that the user could set to whatever their version is, and we might use it to determine the kind of syntax to generate. For now, maybe we just use it for this case of importOrderCombineTypeAndValueImports, but there may be other features in the future as well that depend on the TS version.

@IanVS You exactly understood what I was suggesting. For now this would be limited to this one edge case.
I would suggest we say “absence means we’ll generate the most modern output”. It’s not like we have a habit or need to generally downgrade typescript-dependent syntax, so we may never use it again, but this way it’s not a flag that says “include option 45”.
By defaulting to the most modern output, we can avoid having most users need to specify this.

I see your point, and I considered defaulting to most modern, but I foresee that causing two problems:

Anyone using a version of TypeScript older than 4.5 will have a broken codebase after using this plugin, unless they change the setting.  That's not a great first-time experience, and many users will not spend the time to figure out what they need to do to fix it.
If we want to add new features for more modern versions in the future, it would require a major release because users would be automatically opted-in to the new behavior.

By defaulting to the least-modern, we avoid those issues, at the cost of not merging type and value imports for TypeScript users unless they provide a version of 4.5 or above.  In that situation, their code at least still works, and since we'll have very few options in the plugin by then, it'll be easy to discover and opt-in to that feature.

That's an interesting approach to detecting the TS version, and I think it would work in most cases.  However, it could return bad results if someone has multiple versions of typescript installed in their node_modules (either due to monorepo setup, or a transitive dependency that brings in typescript).  The version that our plugin requires could differ from the version the user executes to actually check or transform their code.  I was chatting with one of the TS maintainers, and he suggested looking into using https://github.com/sindresorhus/resolve-from, and I guess we'd resolve from cwd.  We can try looking into that, but I worry about it being fragile and/or hurting performance.  Making the setting explicit also gives folks a way to opt-out of type and value combining, in case it turns out that people really don't like that.
I guess the best of both worlds would be to auto-detect the version and still allow folks the ability to override the setting with their config.

I think the last thing remaining that we talked about for 4.0 is a way to automatically detect which parser plugins should be used (https://github.com/IanVS/prettier-plugin-sort-imports/issues/24).  It seems like the current defaults are working for most users, or at least we haven't heard from users that it's a problem.  I'm tempted to release 4.0 without that feature, and perhaps consider it together with automatically detecting the typescript version as we also discussed above.
If that's the case, I think there are two more issues that we can look into and try to solve as part of 4.0:

https://github.com/IanVS/prettier-plugin-sort-imports/issues/54
https://github.com/IanVS/prettier-plugin-sort-imports/issues/9

Lastly, I think we should look through upstream issues/PRs/releases/discussions to see if there's anything we want to pull in or address here.  Let me know if you think there's anything else I'm forgetting about before we can release 4.0.

I think we can release 4.0 without #24 and address that later — if it’s a big pain point. It’s only a pain for new plugin adopters though, so we may not get many complaints.
#9 and #54 seem related, and are indeed important.
I think what’s going on is that comments in certain positions are considered “attached” to the import syntax node, and we either render that attachment wrong (injecting a new line) or reformat the comment, and eat a new line.

If you have a little time, would you like to look into that and see if you can fix it?  I can take a pass through the upstream repo to see if there's anything else important for us.

Yeah, added a bunch of annoyingly bugged test cases, now to fix them all

Now that #71 is merged, do we have any more outstanding work that we wanted to get done before 4.0.0? (note: trivial cleanup in #74)
I don't think we to advertise prettier-3 support yet since that's still in alpha, and also, see: https://github.com/IanVS/prettier-plugin-sort-imports/pull/75#issuecomment-1546096919

I'm going to release another prerelease after reviewing your PRs, then the only other thing I planned to do was take a look through the upstream issues and PRs to see if there's anything we can quickly tackle.

I almost forgot we wanted to change the default importOrder.  I've created an issue and tagged it with the 4.0 milestone.

Some upstream issues/prs we might want to consider:

https://github.com/trivago/prettier-plugin-sort-imports/pull/219
https://github.com/trivago/prettier-plugin-sort-imports/issues/203 (could we add dts: true to the default?)
https://github.com/trivago/prettier-plugin-sort-imports/issues/162 Could be interesting to explore as a follow-on to 4.0
https://github.com/trivago/prettier-plugin-sort-imports/issues/181 Is an interesting one.  Should we add a way to disable the plugin?

I don’t think we should do:

https://github.com/trivago/prettier-plugin-sort-imports/issues/162 - because detecting if a path is a local-import at babel-parser time is… difficult without touching the filesystem or trying to resolve it. Unless you say that paths with file-extensions should be treated as local imports?
https://github.com/trivago/prettier-plugin-sort-imports/issues/181 — couldn’t they change the parser plugins using the overrides and disable the plugin that way? Or is that an option that can’t be overridden per file?

I don’t think we’re subject to https://github.com/trivago/prettier-plugin-sort-imports/issues/203 — is that something we’re seeing? (Worth adding a test-case maybe?)
I
No opinion on

https://github.com/trivago/prettier-plugin-sort-imports/pull/219 — I don’t use vue! I’m not sure what effect this have on our parser’s code.
re: https://github.com/trivago/prettier-plugin-sort-imports/issues/199 I had to disable jsx for #78 so maybe we need a richer parser-plugin configuration system :(

Unless you say that paths with file-extensions should be treated as local imports?

No, I don't think that's the way to do it, but we could potentially use the paths option from tsconfig/jsconfig.  I don't think it's something we should address now, but personally I'd love to find a solution to this, because currently I have to duplicate some config between tsconfig and the prettier config to keep things sorted correctly.

couldn’t they change the parser plugins using the overrides and disable the plugin that way?

I didn't confirm yet, but I think that would be more likely to just cause an error to be thrown than to disable the plugin.  And if they're using normal javascript, no plugins are needed to process the code, so there'd be no change.  We could consider adding a importOrderDisable option to make it explicit.

maybe we need a richer parser-plugin configuration system :(

Perhaps.  Or maybe we just need to do something like Vite does, and use overrides to only enable jsx for .tsx and .jsx files by default, and let the user specify it explicitly in their parser plugins option if they need it in other files.  We could even do something similar for the typescript plugin, and only enable it in .ts and .tsx files, rather than everything.  Though I haven't tried this out to see if it's really possible to do.

Alright, I think we've done what we want to do for the 4.0 release.  I'll close out this issue, and let the beta cook for a few days while before releasing 4.0 stable.  Thanks for the excellent discussion and planning here in this issue!


Blur Filter Performance

Describe the bug
As it was noted in #6, the performance leaves much to be desired. Applying the CSS3 blur has a huge detrimental effect on performance. With CSS3 blur applied, there is a big frames/second drop.
To Reproduce
Steps to reproduce the behavior:

Go to 'Restik'
Click on 'whatever'
Scroll down to 'whatever'
See low fps

Expected behavior
There are alternatives to using filter: to blur an element and its background that have better performance.
Screenshots
Not applicable
Desktop (please complete the following information):
Any desktop slow enough
Smartphone (please complete the following information):
Any smartphone slow enough
Additional context
Maybe, this and this could help.

✨ closed by #74


Support jsconfig.json files

tsconfig-paths v4.0.0 now supports jsconfig.json files. (see https://github.com/dividab/tsconfig-paths/pull/199)
https://github.com/dividab/tsconfig-paths/blob/master/CHANGELOG.md#400---2022-05-02

This plugin doesn't use the walkForTsconfig function.
Also duplicate of #22


Bugfix - Remove partial ANSI colour codes when truncating object.inspect

When truncating an object using ObjectFormatter.format that exceeds the max_formatted_output_length remove any partial ANSI color codes.
This fixes an edge case where partial ANSI color codes eg \e[3 is printed to the terminal which corrupts the output.
eg calling object.inspect = "#<\e[33mClass\e[0m \e[36mname: \e[0m"foobars" \e[36mcount: \e[0m42>"
If this was truncated at the 19th char then the result would be: "#<\e[33mClass\e[0m \e[3"
(which results in an invalid escape code).
This commit will remove the partial ANSI code so the result is now: "#<\e[33mClass\e[0m "
To demonstrate the problem here is a screenshot of an example spec running rspec-support 3.4 with good output:

And here is the same spec running rspec-support 3.5 with a bad ANSI code corrupting output:
(The output in the expected [] to include... line contains the bad ANSI code which seems to reset the terminal to the top so the output overwrites)

Thanks :heart:


Faulty plugs brick silverbullet

If a plug is faulty and never returns a manifest it can brick the silverbullet instance, because this promise never resolves, resulting in the silverbullet instance to never finish initializing.
lib/plugos/sandboxes/worker_sandbox.ts
return new Promise((resolve) => {
  this.worker!.onmessage = (ev) => {
    if (ev.data.type === "manifest") {
      this.manifest = ev.data.manifest;
      // Set manifest in the plug
      this.plug.manifest = this.manifest;

      // Set assets in the plug
      this.plug.assets = new AssetBundle(
        this.manifest?.assets ? this.manifest.assets as AssetJson : {},
      );

      return resolve();
    }

    this.onMessage(ev.data);
  };
});

Right, I suppose the best way to handle this is to add a load timeout.


Test details: remove query parameter requirement

Actually it is better to let it optional and use a zod validator to correct parse the values which will set the value to the default when undefined


Sections are displaying incorrect information

This behavior appeared after the curation_concerns upgrade.  I'm not sure if it's related.
Steps to reproduce the problem:

Create a monograph using the UI
Create 2 sections on that monograph (chapter 1 and chapter 2)
Visit the monograph show page
When I click the link for chapter 1, it displays chapter 2 info.  Chapter 2 also displays chapter 2 info.

The sections appear to be correct in fedora, but reindexing the sections doesn't fix the problem.

This behavior affects all sections - if you create multiple monographs with multiple sections, all sections in all monographs display content from the most recently-created section.

I suspect this might be a problem with the ordered_member_docs method in the MonographPresenter

Hint:  The search in the curation_concern_from_search_results method seems to be returning 3 solr documents instead of 1, and then the method returns the first one in the list, which is the wrong one.  I'm guessing the solr query is missing the ID somehow.


Add Items

Metadata
JSON Key: itemSettngs
Outputfile: item.json
Unanswered Questions:

food.itemEffect: What does this do? Is it needed?
food.itemEffectPercent: What does this do? Is it needed?
food.growthPercent: What does this do? Is it needed?

Example
{
	"templateId": "ITEM_BLUK_BERRY",
	"itemSettings": {
		"itemId": "ITEM_BLUK_BERRY",
		"itemType": "ITEM_TYPE_FOOD",
		"category": "ITEM_CATEGORY_FOOD",
		"dropTrainerLevel": 100,
		"food": {
			"itemEffect": ["ITEM_EFFECT_CAP_NO_MOVEMENT"],
			"itemEffectPercent": [1],
			"growthPercent": 0.1
		}
	}
}

Expected Output
{
    "id": "ITEM_BLUK_BERRY",
    "name": "Bluk Berry",
    "category": {
         "id": "ITEM_CATEGORY_FOOD",
         "name": "Food"
    },
   "dropTrainerLevel": 100
}

food.itemEffect: It's needed becouse it show's what the berry do.
Possible input's right now:

ITEM_EFFECT_CAP_NO_MOVEMENT(the berry what does this isn't currently obtainable in the game)
ITEM_EFFECT_CAP_CHANCE_SINGLE_THROW (Razz and Golden Razz. Easier to catch the Pokemon with it)
ITEM_EFFECT_FULL_MOTIVATION (Golden Razz. when feeded in gym it fill the motivation bar)
ITEM_EFFECT_CAP_TARGET_SLOW (Nanab. Increase the time between attack and jump animations)
ITEM_EFFECT_CANDY_AWARD (Pinap. Duplicates the candy)
ITEM_EFFECT_CAP_TARGET_MAX (the berry what does this isn't currently obtainable in the game)

food.itemEffectPercent: This says that how effective what they do. For example on candy award (Pinap Berry) it's value is 2 and we got double candy with Pinap
food.growthPercent: Maybe a future feature?

Alright, started a new branch. See #13


[SPARK-48414][PYTHON] Fix breaking change in python's fromJson

What changes were proposed in this pull request?

Fix breaking change in fromJson method by having default param values.
Why are the changes needed?

In order to not break clients that don't care about collations.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Existing UTs.
Was this patch authored or co-authored using generative AI tooling?

No.

Merged to master.


Cache successful runs as generated playwright code, with a fallback to an agent run on failure

Initial implemented closed by #30


Add ability to create and configure NSXMLParserOptions from another package

When I create AEXMLDocument object by the constructor, I can pass options struct to it, but I can't create it from any external package or change its default properties (Error 'AEXMLDocument.NSXMLParserOptions' cannot be constructed because it has no accessible initializers). This commit makes all NSXMLParserOptions properties public and creates public initializer

Thanks, this is now merged (manually).


Will this gem work with fcm?

Currently it doesn't, but if someone volunteers to integrate that would be awesome!! :)
Wanna give it a try?


acirenderer: optimize PathWhitelist handling

The current implementation of PathWhitelist is slow when the list of
files is big.
This commit sets the current PathWhitelist outside of the Walk loop to
avoid calling pwlToMap on every file. It also removes a
filepath.Clean() call since the following filepath.Join will call Clean
anyway.
This helps with appc/docker2aci#34

LGTM, gracias!


Enable AppVeyor testing

Required to test #86 - I don't have Windows, so let's see where & how it crashes ...

Meh - looks like this won't be easy:

It looks like the main issue is that Windows doesn't support such filenames.
I know it may be quite an extra work, but I think the right way to go is to put the links as the first line in the file and use simple filenames.


Configure maven-surefire-plugin

Part of this has been merged in #14 and there are other changes that are not part of #15. I'll cancel this one.


Pipeline: refine log

What problem does this PR solve?
Issue Number: ref #6518
Problem Summary:
What is changed and how it works?
ref https://github.com/pingcap/tiflash/pull/6520#issuecomment-1386613354 and https://github.com/pingcap/tiflash/pull/6520#issuecomment-1386637324

Refine QueryExecutor to hold the MemoryTracker instead of ProcessListEntry, ref https://github.com/pingcap/tiflash/issues/6413
change the log->id of PhysicalPlanNode from ${mpp_task_id} ${plan_type} to ${mpp_task_id} ${plan_type} ${executor_id}
Hold the LoggerPtr in Operator, Task, Event, Pipeline, PipelineExecStatus, QueryExecutor.
Add some logs of Task and Event, such as switchStatus.

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-all-tests

/cc @windtalker @ywqzzy @yibin87

/merge


The plot caption overlaps with the legend

Fixed: https://github.com/JetBrains/lets-plot/commit/d3683b26c394cc94fab3a57360110c55e285ad3e


td-color-hover should be darker than td-color-striped

TuSimple/naive-ui version (版本)
2.21.1
Vue version (Vue 版本)
3.2.23
Browser and its version (浏览器及其版本)
Mozilla Firefox 94.0.2
System and its version (系统及其版本)
Arch Linux 5.15.4-zen1-1-zen
Node version (Node 版本)
Reappearance link (重现链接)
https://codesandbox.io/s/naive-ui-td-color-hovered-demo-rgppd?file=/src/App.vue
Reappearance steps (重现步骤)
Create a data table with the striped option
Expected results (期望的结果)
td-color-hover should be darker than td-color-striped
Actual results (实际的结果)
td-color-hover is the same as td-color-striped
Remarks (补充说明)

变量颜色重新定义下 @07akioni


chore: add make lint.fix to address auto fixable lint issues

What type of PR is this?

What this PR does / why we need it:
This PR adds make lint.fix to address auto-fixable lint issues.
gci, which is the most annoying one for me, has to be handled separately since it doesn't support auto-fix in golangci-lint, somehow.
Which issue(s) this PR fixes:

Fixes #

lint.fix-golint should be the name?

@zirain Addressed your points.

gofumpt's autofix should be supported within golangci-lint, unlike gci.


Onboarding: Mark strings sent by welcome bot for translation

The PR is ready for review. But there are some issues with our current translation system that should be fixed. Details below.

There are broadly three cases in which welcome bot sent messages

Case 1: When a user creates the organization, the welcome bot sends messages to various streams to introduces concepts like private streams, topics, etc.

Case 2: When a user creates an account/organization welcome bot PMs the acting user with details on how to download mobile apps, change settings, etc. It also asks the user to enter anything back to the bot.

Case 3: When the user replies back to the welcome bot in PM, one final message is sent by the welcome bot acknowledging the message.

There seems to be a mismatch in the language used for translation in the three cases. I verify the language by printing django.utils.translation.get_language() in the 3 respective functions.
In case 1 and case 2, the language used for translating the welcome bot messages by Django is the one sent by the browser at the time of organization or account creation.
In case 3
The language used for translation seems to be the one mentioned in users profile as the default language. And the default language is not necessarily the language sent by the browser. Currently, it seems like we use the default language of the organization and not the browser for setting the default language of the user.  So the language used for translating the welcome bot message in Case 3 would not be necessarily the one sent by the browser resulting in a mismatch between Case 1,2 and Case 3.
I think one possible solution would be

To set the default language of the user as the one sent by the browser during registration and not the one mentioned as the default language in organization settings.

We would also need to set language sent by the browser during realm creation as the default language of the organization. Currently, it seems to be set as English irrespective of browser language. The default language of the user, on the other hand, seems to be set correctly as the browser language realm creation.
This is the behavior that I observed while I was testing. I have not yet verified the code.

I merged these commits as the series ending with 22b5297e328000a49d7ab6b9ea69433e804dbc31, after tweaking the line-wrapping as I suggested above.  Can you add a commit for the onboarding.py move?
The language issue seems tricky; it's really not clear to me what the best strategy is (whether to favor what the browser sends or the configurable "organization default language").  Maybe we should extract your writeup above to a new issue and get some discussion on it?

Closing this since I created #16289 and #16288 for the requested followups.


Cleanup: remove unused SPAR roles

Describe the task
When we onboard SPAR to FAM, we created 2 sample roles, USER_WRITE and USER_READ. Confirm with the SPAR team to see if they still need the sample, if not then we can remove them. Also we have SPAR roles from the old SPAR system, confirm with SPAR team if they still need those roles, if not then we can remove them.
Acceptance Criteria

[x] unused roles are deleted for SPAR(DEV,TEST,PROD)

Additional context

Add any other context about the task here.
See #1206 for new role additions

Confirmed with team Evergreen, they just need 3 roles for the next release, we'll do a one time cleanup to remove the old SPAR roles in FAM, and we'll add what they need in the future.


Update User / Admin documentation

As per @csoc-kevink comment in #41 the admin documentation needs updating, just opening this issue to track that!

Thank you for the updated readme :)


Move the trrack-vis to panel on the right (similar to the navigation bar)

Request from Alex

Should have an ability to close itself with an "X"

Should have an ability to close itself with an "X"


prop-types module missing from peerDependencies

Since prop-types was moved to devDependencies in 2.1.2, it should be added to peerDependencies.  I believe that may break compatibility with anyone running older versions of react (< 15.6).

Thanks, good point!
Added in 04b8617 and released with v2.1.3.


track widget dimensions as properties

some logic other than draw code, such as mouse code, needs to know how big the widget is. instead of duplicating the explicit passing of width and height everywhere it could conceivably be needed, it should be queriable as a property on the widget's private table

it can be set in an on_resize method implemented by Widget. this method should be called when:

the game client resizes
a widget resizes within its container (so currently just in Overlay)

resolved by 8692cc1150f9814a3a559c0ac1dd2e574e384987


can't login to my account

Subject: can't login to my account
Description:
I tried to login with my email
and also with my user name
B.Speechy
Results:
it says: Couldn't find that user.
Backend version: develop-0023fa73
Frontend version:
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Page: https://couchers.org/login
User:

not enough info


Rancher 2.3.2 pipeline very slow when building docker image

What kind of request is this (question/bug/enhancement/feature request):
Question/enhancement
Steps to reproduce (least amount of steps as possible):

Set up pipeline for gitlab repository
Define pipeline config
Mine is as below

stages:
- name: Build
  steps:
  - runScriptConfig:
      image: my.registry.com/gitlab/gitlab-laravel-builder:php-7.3
      shellScript: |
        composer install --prefer-dist --no-interaction
        # Install Node dependencies.
        npm install
        # Copy over testing configuration.
        cp .env.example .env
        echo "###### Applying database variables ######"
        sed -i "s|###APP_KEY###|$APP_KEY|g" ".env"
        sed -i "s|###APP_ENV###|$APP_ENV|g" ".env"
        sed -i "s|###APP_URL###|$APP_URL|g" ".env"
        sed -i "s|###DB_CONNECTION###|$DB_CONNECTION|g" ".env"
        sed -i "s|###DB_HOST###|$DB_HOST|g" ".env"
        sed -i "s|###DB_PORT###|$DB_PORT|g" ".env"
        sed -i "s|###DB_DATABASE###|$DB_DATABASE|g" ".env"
        sed -i "s|###DB_USERNAME###|$DB_USERNAME|g" ".env"
        sed -i "s|###DB_PASSWORD###|$DB_PASSWORD|g" ".env"
        npm run dev
    env:
      # All ENVs here #
- name: Build image
  steps:
  - publishImageConfig:
      dockerfilePath: ./.devops/Dockerfile
      buildContext: .
      tag: my.registry.com/project/vacation-fpm-nginx:${CICD_GIT_BRANCH}-commit-${CICD_GIT_COMMIT}
      pushRemote: true
      registry: my.registry.com
- name: Deploy
  steps:
  - applyYamlConfig:
      path: ./.devops/deployment.yml
timeout: 60

Result:
Build image step takes very very long to build, I have noticed that it hangs specifically on COPY and RUN chown steps where it takes most of the time, my Dockerfile is as below
FROM my.registry.com/base-images/laravel:php-7.3

WORKDIR /var/www
# Copies built code to image
COPY . /var/www/

RUN chown -R www-data:www-data /run && \
  chown -R www-data:www-data /var/lib/nginx && \
  chown -R www-data:www-data /etc/nginx && \
  chown -R www-data:www-data /var/log && \
  chown -R www-data:www-data /var/www/

EXPOSE 8080

USER www-data

This image takes around 40-50 mins to build which is ridiculous. Maybe I am doing something wrong here and someone could suggest how to speed up this?]
I would appreciate any help, because this pipeline feature looks like something I could replace with my current gitlab CI/CD approach.
Thanks!
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
2.3.2
Installation option (single install/HA):
HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory):
VM 4 CPUs/4GB memory
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"d647ddbd755faf07169599a625faf302ffc34458", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.4", GitCommit:"67d2fcf276fcd9cf743ad4be9a9ef5828adc082f", GitTreeState:"clean", BuildDate:"2019-09-18T14:41:55Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client: Docker Engine - Community
 Version:           19.03.3
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        a872fc2f86
 Built:             Tue Oct  8 00:58:10 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.3
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.10
  Git commit:       a872fc2f86
  Built:            Tue Oct  8 00:56:46 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

same issue

very slow

Real slow


typo: time.seconds => time.second

tiny fix to time.seconds => time.second :D

Wow, awesome thank you!


customise edge colours

Using the online editor.
I would like to be able to set the colour of the individual edges.
This will help distinguish lines on busy diagrams.

Do you want arbitrary color? Do you have a particular syntax in mind for edge descriptors?

I suggest an optional #rgb to the arc type in the edge definition, so e.g.:
'b-|a' where '-|' is the arc definition, could become: 'b#0f0-|a' for a green edge.
Optionally, affect only the edge elements after the color specification, and allow different colors for different elements, e.g. 'b#0f0-#f00>a' for a green line and a red arrow.


UV... hell..  and ptex problems...

i know we talked about the tricks of getting uv's to work... but some times i have to use non square textures and it kicks my ass... the math in getting it to work is good... but its math... and sometimes i get my ass kicked... but its fun..
so i started using ptex... i get simple ptex from 3d-coat...and that works ok. but more complex textures tend to give me problems... i use the applink..  but mudbox ptex files will not work... does anyone have any tips on how, or a ptex workflow that you would like to share...
I think i read something that you guys are working on PRman uv system to be more like Cycles... it this true...  and when will it save me...
Thanks Bloodboy_

Can we get a bit more info?  Maybe an example?  For instance you said "more complex textures tend to give me problems..."  What kinda problems?

ok.. first i tried a simple cube.. from blender to 3d-coat i just painted a few lines of color... save the ptex file... did the ptex setup and it rendered fine... then i painted more detailed textures with leaves on a cube.. but then in renderman i get the texture applied to every face of the cube... or a tilled look... i dont have that example saved...
i thing the problem comes when i up res./ the ptex file. in 3d-coat...
i am doing R&D stuff for a project i want to do with PRman.. and i am testing  shader and textures..
its not that i want a solution right now... just wanted to see if anyone else use ptex and how it works for them

Hmm looks like I will be making some changes to the code to support this better as it currently is difficult to get working correctly.

Let me know what you're thinking.
On Tue, Nov 8, 2016 at 10:46 PM, MWY3510<EMAIL_ADDRESS>wrote:

Hmm looks like I will be making some changes to the code to support this
better as it currently is difficult to get working correctly.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bsavery/PRMan-for-Blender/issues/202#issuecomment-259344817,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABzffG6sCiDX0oCtkkpAh-viCqI4r4Lhks5q8WwpgaJpZM4HhEq9
.

--
<EMAIL_ADDRESS>508-274-8700

So currently ptexTexture is connected to texture gen for regular textures. This causes problems since the ptx file is not copied to the texture folder. Additionally the file is renamed which causes some problems.
My thought would be to have a special case for ptexTexture in generate texture. Let me know if you have any problems with that.

Hmmm. Do ptextures need anything done with them?  Can't they just be
referenced directly?  I suppose copying them over would be fine.
On Wed, Nov 9, 2016 at 8:41 AM, MWY3510<EMAIL_ADDRESS>wrote:

So currently ptexTexture is connected to texture gen for regular textures.
This causes problems since the ptx file is not copied to the texture
folder. Additionally the file is renamed which causes some problems.
My thought would be to have a special case for ptexTexture in generate
texture. Let me know if you have any problems with that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bsavery/PRMan-for-Blender/issues/202#issuecomment-259461245,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABzffPZCgjzdoXEA3uJR14cw_rTOgu6Rks5q8fevgaJpZM4HhEq9
.

--
<EMAIL_ADDRESS>508-274-8700

The ptextures don't need anything done but they do need to be excluded from renaming. Copying the file is good though.


Metamask and Ledger not working for making a deposit using the launchpad

The latest version of metamask and ledger do not work with the Launchpad.
I have tested different machines (2 Windows and one Mac), different browsers on each (Firefox, Chrome, Brave), and different ledger devices (s and x) with no luck. All devices and applications are updated to the latest versions.
Metamask error log when using Chrome and Brave (both require a bridge to Ledger Live app) is there are not sufficient funds (this is not correct since wallet has more than enough to cover the deposit as well as the gas):
"op": "add",
"path": "/err",
"value": {
"message": "[ethjs-query] while formatting outputs from RPC '{"value":{"code":-32000,"message":"insufficient funds for gas * price + value"}}'",
"stack": "Error: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32000,"message":"insufficient funds for gas * price + value"}}'\n    at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:18:142161"
},
"note": "transactions:tx-state-manager#fail - add error",
"timestamp":<PHONE_NUMBER>113
Metamask error log when using Firefox (does not require Ledger Live app) is the following:
"Ledger device: UNKNOWN_ERROR (0x6b0c)",
"stack": "TransportStatusError@https://metamask.github.io/eth-ledger-bridge-keyring/bundle.js:18125:18/nTransport/this.send@https://metamask.github.io/eth-ledger-bridge-keyring/bundle.js:22001:15/n"
Last week I opened tickets with Ledger and Metamask but no feedback yet from them.

There is a known issue with Ledger devices, MetaMask and the launchpad. You usually need to enable Debug data in addition to enabling Blind signing to complete the transaction sucessfully. Enabling Debug data will ask you to confirm a bunch of fields when signing the transaction but it should pass in the end. This issue has been reported a countless amount of times to Ledger.

This is likely related to #549


Version Bump 0.1 -> 0.2

Anticipated changes

#15
#18
#17
#19
#21
#23
Adding get_combined_table() to return joined onetable, get_covid_df(), get_vax(), and calc_add_risk()
#35
#36

All tests passing and commits in. Testing now with routine products for any errors.

All routine reports checked and verified working. Waiting for review


bing 模型下的快速模式是怎么做到？官方好像只有三种

Is your feature request related to a problem? Please describe.
新功能是否与解决某个问题相关, 请描述
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
你期望的新功能实现方案
A clear and concise description of what you want to happen.
Additional context
其他
Add any other context or screenshots about the feature request here.

这是一个官方没有公开的模式, 是社区发现的, 据说是gpt3.5驱动


Re-enable hipGraph version of device_adjacent_difference test

Previously, we disabled the hipGraph version of the LargeIndices test for the device_adjacent_difference algorithm because it was failing on Navi3x and MI300.
The root cause of this failure was a call to hipMemset that occasionally continued to run while the hipGraph was instantiated. I've now learned that this is expected behaviour - hipMemset runs asynchronously unless the pointer it is passed refers to pinned host memory. This is true even if the call to hipMemset is issued into the default stream, like it is in this case. hipMemsetAsync's behaviour differs only with respect to pinned host memory (it's non-blocking in that case). This behaviour is not currently mentioned in the HIP documentation, so I'll put in a request to add it there.
This change just inserts a call to hipStreamSynchronize to ensure that the hipMemset call completes before the graph is instantiated. It also removes the GTEST_SKIP() call that disabled the hipGraph version of the test.

Rebasing to re-trigger checks.


Cleaning a polygon

Hello,
I've a tool selection for my SVG, with polygon and rectangle drawings.
If I click the polygon tool (which launches a svg.polygon.draw()) and immediately after that I click the rectangle tool (svg.rect.draw()) without actually using the polygon, rect will place two small circles on starting and ending corners of the rectangle.
Is there any workaround to avoid this behaviour? I tried this without succedding:
polygon.draw('cancel')
as set doesn't exist at the moment of calling it
// Remove all circles
    this.set.each(function () {
        this.remove();
    });

I can't tell if this is an issue with the clean function or I'm doing something wrong.

I made a pull request with a simple fix that seems to work properly.

Noticed this problem has been fixed already in github but the updated version is not yet on npm. @Fuzzyma are you planning to update npm soon with recent changes?


Use IIFE for injected javascript.

Otherwise the global name variable is overriden by the last assigned callback and all function invocations target the last defined callback.
This fixes a bug whereby using multiple callbacks when calling add_window like this:
app.add_window(attrs, Some(vec![ipc, log_error, log_info, log_warn]))?;

Without this fix all javascript function invocations call the Callback named log_warn (the last one defined); after applying this fix each Callback should be invoked as expected.

We should have added a change file on this PR, totally forgot that we have covector now :|


Improve search block

Fix many aspects of the search block. Each commit should be pretty atomic, so at the end I'll gather a list of what has been changed.

@tiberiuichim man, you rock!!!
Showing initial results works.
Restricting the "sort on" values works like a charm!


IDocument needs to be documented

 Issue by dodyg
Monday Jul 27, 2015 at 09:19 GMT
Originally opened as https://github.com/Wyamio/Wyam.Web/issues/3

Right now it is quite hard to figure what what properties are available on IDocument.
This makes module such as http://wyam.io/modules/if harder to use than necessary.

 Comment by daveaglick
Monday Jul 27, 2015 at 12:15 GMT

Yeah, I agree. My original plan was to create a module that would use Roslyn and XML doc comments to generate MSDN-like API docs and then use that to output details for the interfaces in Wyam.Abstractions. I'll still do that, but in the meantime I'll go ahead and add some manual documentation for the interfaces in the next couple days.

 Comment by daveaglick
Wednesday Jul 29, 2015 at 21:31 GMT

Added a whole API section here: http://wyam.io/api/ Thanks for the suggestion!


KAFKA-3896: Unstable test KStreamRepartitionJoinTest.shouldCorrectlyRepartitionOnJoinOperations

@ijuma i checked the cases where this test has failed and it seems to always be on the verification of the left join. I've ran this test plenty of times and i can't get it to fail. However in the interest of having stable builds, i've removed just the part of the test that is failing (which happens to be the last verification).
Thanks,
Damian

@dguy Any idea why it would fail? Is it a timing issue?

It must be timing on the slow build boxes. I've not seen it fail locally and i've ran it repeatedly as part of the build and individually

@dguy mentioned offline that the code paths the leftJoin is executing are covered by other tests, and hence why he suggested removing the test. I am not too familiar with the code, so I'll let @guozhangwang review it.
My take is that it's important to understand how a slow build box could cause the incorrect result and if there's a way to make the test more robust, that would probably be better (my opinion is not as well-informed @dguy's and hence why I'll defer to whatever @guozhangwang thinks).

@dguy which test case do you think covers this last verification already?
BTW I have also seen that no records or fewer-than-expected messages were produced in the integration tests, even after 30 / 60 seconds: https://issues.apache.org/jira/browse/KAFKA-3882. So I think parallel running integration stream tests may some time stall completely.

@guozhangwang the repartition logic is covered by all of the other verifications in that test. The leftJoin is covered by JoinIntegrationTest.
I've ran the build repeatedly on my maxed (100%) laptop and I have yet to get any failures.

It is a bit puzzling why this seems to happen relatively often in Jenkins, another instance here: https://builds.apache.org/job/kafka-trunk-git-pr-jdk7/4400/

@guozhangwang @ijuma - i've changed the JoinWindow to 1 day  (from 1 minute) and this looks like it has fixed the issue. I checked the previous failures on Jenkins and this test was taking around 1.5 to over 3 minutes - so a 1 minute JoinWindow for this test was too small.
I've ran it without fail on jenkins https://jenkins.confluent.io/job/kafka-trunk-debug/  (the one failure wasn't a test failure).

Thanks for the investigation @dguy , the reasoning is reasonable to me.
LGTM and merged to trunk.


[Bug]: @serwist/next cannot handle runtimeCaching with dynamic import

Provide environment information
    "@serwist/next": "^9.0.5",
    "next": "14.2.6",
    "serwist": "^9.0.5"

Which project is this issue for?
@serwist/next
Link to reproduction - Issues with a link to complete (but minimal) reproduction code help us address them faster
https://stackblitz.com/github/issueset/serwist-import-error
To reproduce
Open the link https://stackblitz.com/github/issueset/serwist-import-error or clone https://github.com/issueset/serwist-import-error, run pnpm install && pnpm run build and you can see the following error:
> next build

  ▲ Next.js 14.2.6

 ✓ Linting and checking validity of types
   Creating an optimized production build ...
 ○ (serwist) The service worker will not be automatically registered, please call 'window.serwist.register()' in 'componentDidMount' or 'useEffect'.
 ○ (serwist) You may also want to add '@serwist/next/typings' to your TypeScript/JavaScript configuration file at 'compilerOptions.types'.
 ✓ (serwist) Bundling the service worker script with the URL '/sw.js' and the scope '/'...
Failed to compile.

static/chunks/994.c7647ae96e8068d7.js from Terser
  x Expected ';', '}' or <eof>
   ,-[1:1]
 1 | "use strict";
 2 | {
 3 |
 4 | /***/ 994:
   :       ^|^^
   :        `-- This is the expression part of an expression statement
 5 | /***/ (function(__unused_webpack_module, __webpack_exports__, __webpack_require__) {
 6 |
 7 | /* harmony export */ __webpack_require__.d(__webpack_exports__, {
   `----

Caused by:
    0: failed to parse input file
    1: Syntax Error
Error:
  x Expected ';', '}' or <eof>
   ,-[1:1]
 1 | "use strict";
 2 | {
 3 |
 4 | /***/ 994:
   :       ^|^^
   :        `-- This is the expression part of an expression statement
 5 | /***/ (function(__unused_webpack_module, __webpack_exports__, __webpack_require__) {
 6 |
 7 | /* harmony export */ __webpack_require__.d(__webpack_exports__, {
   `----

Caused by:
    0: failed to parse input file
    1: Syntax Error

> Build failed because of webpack errors
 ELIFECYCLE  Command failed with exit code 1.

Describe the bug
In client/f1.ts, I use await import("./f2") to import another module, and it seems that somehow @serwist/next cannot handle it. If I don't use await import, no error is shown.
Expected behavior
No error.
Screenshots (if relevant)
No response
Additional information (if relevant)
No response

Fixed in 9.0.6.
Also, just saying, but semantically, dynamic imports in service workers is not a thing... yet :) It's thanks to webpack that this even works.


Feature/cache post reactions counts

Caching for both post and comment reaction counts at the view level.

Nevermind.. Given that every item would. have to be cached. per user basis as it excludes reactions from blocked users and such, there is no point in caching. We would have to clear it everywhere any of these conditions are met.
Also we cant cache the Emoji instance as the keyword attribute is dynamic given the request language... a


Add momentum design

Description
Add momentum.design app code into the repo. Also updated README's and added missing CONTRIBUTING file.
Related Issue
fixes #21
Motivation and Context
momentum.design relies on the collab-ui libraries and serves as the documentation for usage and styles. This will enable us to setup CI publishing of the docs site to coincide with publishing the libraries, as well as test changes against the documentation.
How Has This Been Tested?
All existing tests are passing
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation update
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[x] Other... Please describe:

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

In the angular/CONTRIBUTING.md file, line 47, maybe clarify that the yarn install && yarn bootstrap needs to be called in the root folder of collab-ui

I updated all of the Contributing files to only reference the root file for installing. This should make it more clear

@pauljeter @elenagiere  Copying over toggle switch to this mono and followed the angular contributing steps, works great.
Only thing I noticed that wasn't in the instructions was with the examples.module.ts
The newly generated component (ToggleSwitchComponent) was auto imported and included in the exports and declarations array, where I then deleted those. I'll check to see if this happens again when I create a new component.


Sensitive config values with fallback

Feature
Implement sensitive configuration values:

foo.bar.alias -> resolves from the value
foo.bar -> resolves directly from config
optionality must be done manually

@benhid if you want, feel free to take this


tests for gift cards

I want to merge this change because I created tests for gift cards

PR intended to be tested with API branch:
Screenshots

Pull Request Checklist

[ ] This code contains UI changes
[ ] All visible strings are translated with proper context including data-formatting
[ ] Attributes [data-test-id] are added for new elements
[ ] Changes are mentioned in the changelog
[ ] The changes are tested in different browsers and in light/dark mode

Test environment config

API_URI=https://master.staging.saleor.cloud/graphql/

Task linked: SALEOR-4251 Create tests for gift cards


Allow to drop windows shortcuts into editor area

Issue Type: Bug
Repro steps:
Create a shortcut to a file.
Drag the shortcut to the editor window.
Actual behavior:
Editor shows the following message: "The file is not displayed in the editor because it is either binary or uses an unsupported text encoding. Do you want to open it anyway?".
Expected behavior:
When dropping a shortcut (.lnk file), the editor should attempt to open the file that the shortcut points to, not the shortcut file itself.
VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:48:04.245Z)
OS version: Windows_NT x64 10.0.19042

As far as I know, there is no way to read a windows shortcut using node.js, but I fail to find an issue for that now.


doesn't rebuild dynamic chunks unless the cache changes

So if you delete your dist dir, and build your app, dynamic chunks won't be in the resulting bundle. This isn't in reference to rebuilds, but just regular builds, whenever the config hash hasn't changed.
webpack version: 4.5
splitChunks config:
splitChunks: {
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendor',
          chunks: "all"
        },
        lang: {
          test: /[\\/]i18n[\\/]/,
          chunks: 'async'
        }
      }
    }

I saw this issue and subsequent PR:
https://github.com/mzgoddard/hard-source-webpack-plugin/issues/176
https://github.com/mzgoddard/hard-source-webpack-plugin/pull/215
But in my case, the dynamic imports aren't nested. I simply have one in my entire app:
import(/* webpackChunkName: "lang/[request]" */'../i18n/' + lang)

I also tested without using a dynamic expression, and still have the same issue:
import('../i18n/en')

It must be a webpack 4 issue. Also note: the issue occurs without using any config.optimizations options.
Also note: this isn't just a stats issue. The actual dynamic import chunks are not in fact built, nor on re-builds when watching with webpack-dev-server.

Ok, this is happening with basically zero customizations of the webpack config. ..I'm gonna make you a repro? do you have an example repo you'd like me to re-use?

Happening with our project as well. Is there a possible workaround for this?

Call me "American singer-songwriter Pink" because I'm trying to get this (rebuilding dynamic chunks) party started.

@faceyspacey did you ever find a go-to reduced test case to fork for bug illustration purposes?

I made the PR with a failing test:
https://github.com/mzgoddard/hard-source-webpack-plugin/pull/308
This is actually a duplicate of https://github.com/mzgoddard/hard-source-webpack-plugin/issues/300
so I'm closing.


Make error handling more user friendly for common accidental mistakes by showing resolution steps

This is mostly a nice to have. Example -- running dbutils.help() without setting up cluster throws:
databricks.sdk.core.DatabricksError: Missing required field: cluster_id
We could add something along the lines of how to setup cluster, point to the relevant docs.
Full error stack:

@tanmay-db -  If this is not worked and needed.
can I pick this issue ?


JBPM-5088 - KIE-Server process images are not found when stored insid…

…e packages
@etirelli this could be important for the product too

jenkins retest this


chore: upgrade react and some other dependencies [TECH-336]

No functional changes.

ItemHeader needed a small refactor due to changes in react-redux
Removed use of theme, which is for mui, which is going away. (LoadingMask, FilterSelector)
css tweaks for the Item Selector, needed due to the ui-core upgrade

material-ui/core was not upgraded since the upgrade caused issues in the Translation and Sharing dialog.  Will need to address that later.
https://jira.dhis2.org/browse/TECH-336

The code looks good, haven't tested locally, but you're sure this has no visual impact?
Is it safe to upgrade to React v16.13.1? All other apps seems to be running 16.8.x.

I haven't spotted any visual impacts. It all looks the same.
Per the discussion in the analytics team meeting, it is fine to upgrade to the latest React.


New Contribution

Contributor: s1mple1122
SSH Public key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH7jG2sDGJ3C7Xz2m1qTVeuz7nQ+dvPL/zX849iRqCH5
Attestation: s1mple1122

Ready to contribute


Question about Dynamic System Identification

Hello,
I have been trying to follow your tutorial and its really great! Thanks for sharing everything in a well documented manner. I have read the issue posted by @wqwanghanzhang and I think I have similar questions related to “Dynamic System Identification (via VirtualRC)”.
Although you have decribed the procedure in detail but I was not able to figure out some things, like the steps require the use of the previous SDK (ethz-asl/dji_onboard_sdk_ros), on which I think you are not working now and the latest version (ethz-asl/mav_dji_ros_interface) directly uses those params. I know you wanted to keep this version as consize as possible, so you removed those stuff.
I needed to do this since my configuration is a bit different. I am using Matrice100 with NVIDIA jetson TX2 and a different camera. So is it fine if I am using your older SDK just for performing Dynamic system Identification? as I am still facing some issues.
These are some things that I have tried,

Following the given steps, I am able to take control over the matrice100 though joystick. Testing without props seems fine and the change in corresponding rotor speeds can be seen on changing pitch and roll from joystick.
But when trying with props, when given a little thrust, the quad starts to gain height but keeps drifting in one direction. Also changing roll and pitch values from joystick doesn’t help much to stabilize the quadrotor. Even after landing it and releasing controls from joystick, the quad behaves erratically until I stop the script and give control back to the remote control.
(Although I have no problem in flying quadrotor manually and it looks quite stabilized.)

While debugging it,

I tried to look for any discrepancies in “/dji_sdk/vc_cmd” and “/joy” topics by comparing it to one of your rosbags but the values seem to be well in range with correct offset and appropriate directions.
Also the imu readings from the quad look fine.

I have tried hovering and step response experiment with your calibration settings, although its able to fly but I think the system parameters need to be tuned.
Can you suggest any thing that I can try or might be doing wrong?

Are you as concerned as we are about rebuilding this open source project, but we've had some problems with the step response experiments that follow the github tutorial  https://github.com/ethz-asl/mav_dji_ros_interface/wiki/First-Autonomous-Flight%3A-Hover-and-Step-Response  . Can  you provide your E-mail ? , I have some questions to ask. please


Fetch closest sensor

Modify the existing geolocation logic to work with the new PurpleAir API.

[ ] approved


update accessibility guidance for tooltips

What component is this related to?
ic-tooltip
Why do we need it?
Following changes to tooltips under https://github.com/mi6/ic-ui-kit/issues/860, the guidance should be updated to reflect the changes made. In particular, may want to reference the new silent prop.

Dependent on https://github.com/mi6/ic-ui-kit/issues/1227 being completed.


Azure CLI/Bicep Deployment Ignores Inline Parameters when Supplied with bicepparam File

Bicep version
2.57.0
Describe the bug
When deploying a Bicep template using az deployment sub create, all inline parameters specified in the command are ignored when also passed in with a bicepparam file. This occurs regardless of whether the parameters are hardcoded or passed from Azure Pipeline variables/parameters. The deployment proceeds with the default values specified in the Bicep file.
To Reproduce
Define a main.bicep template which includes a parameter to be passed from a bicepparam file, and a parameter to be passed inline, with a default value to avoid the bicepparam file throwing an error:
param tags object
param deployFoo bool = true

resource fooResourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' = if (deployFoo ) {
  name: 'foo-rg'
  location: 'uksouth'
  tags:tags

}

Define a params.bicepparam file:
using '../main.bicep'

param tags  = {//omitted for brevity}

Define an azure-pipelines.yaml and use the AzureCLI@2 task with PowerShell to deploy the template whilst supplying both a parameter file and an inline parameter:
trigger:
- main

pool:
  vmImage: 'windows-latest'

steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: '<YourServiceConnectionName>'
    scriptType: 'ps'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az deployment sub create `
      --location "uksouth" `
      --template-file "path/to/main.bicep" `
      --parameters "path/to/params.bicepparam" `
      deployFoo=false

When the above pipeline is run, the deployFoo value is seen as true, and the resource group is deployed.
Additional context
I've seen a few issues and threads about the problem, but it still persists:
https://github.com/Azure/bicep/issues/11445
https://github.com/Azure/bicep/issues/11042

Could you try instead using:
trigger:
- main

pool:
  vmImage: 'windows-latest'

steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: '<YourServiceConnectionName>'
    scriptType: 'ps'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az deployment sub create `
      --location "uksouth" `
      --template-file "path/to/main.bicep" `
      --parameters "path/to/params.bicepparam" `
      --parameters deployFoo=false

@anthony-c-martin Ah that does work!
Do you think it's worth updating the docs to clarify this? Or is this more of a workaround until a longer term fix is implemented?

Good question - I'm actually not sure if this is a bug or by design. Either way, I think updating our docs to give some examples of inline parameter overrides is a really good idea - tagging @mumian.

When using multiple arguments with a .bicepparam file, I get the following error:
ERROR: Can not use --parameters argument more than once when using a .bicepparam file

@ossiam - can you share the full command and parameters that you tried to pass that led to this failure?

@Ossiam - it sounds like you are using an old version of Azure CLI; support for supplemental parameters was added in 2.54.0. Please could you try again with a more recent version, and confirm this is still an issue?

The article has been updated - https://github.com/MicrosoftDocs/azure-docs-pr/pull/270808.