Err on GNU sparse files with content at end

GNU tar --sparse produces archives we can't process, we hit this error:
https://github.com/alexcrichton/tar-rs/blob/8d51b538da744eb7a30022b2a3d13b6a49f6f419/src/archive.rs#L410-L413
A sparse file with content at the end, such as:
$ for i in $(seq 0 1); do truncate -s ${i}M a.big; echo "${i}MB through" >> a.big; done
$ hexyl a.big
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ 30 4d 42 20 74 68 72 6f ┊ 75 67 68 0a 00 00 00 00 │0MB thro┊ugh_0000│
│00000010│ 00 00 00 00 00 00 00 00 ┊ 00 00 00 00 00 00 00 00 │00000000┊00000000│
│*       │                         ┊                         │        ┊        │
│00100000│ 31 4d 42 20 74 68 72 6f ┊ 75 67 68 0a             │1MB thro┊ugh_    │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘

Packed into a tar with tar -cf a.tar --sparse a.big into a.tar.gz
apparently produces this header structure:
regular header 0: GnuSparseHeader { offset: 0, length: 4096 }
regular header 1: GnuSparseHeader { offset: 1048576, length: 12 }
regular header 2: GnuSparseHeader { offset: 1048588, length: 0 }

...and we hit the error as 12 % 512 != 0.
I notice remaining does hit zero after this subtraction:
https://github.com/alexcrichton/tar-rs/blob/8d51b538da744eb7a30022b2a3d13b6a49f6f419/src/archive.rs#L426-L431
Do we need to break the header parsing if we see a sparse header with a length of zero?
Do we need to skip the 512 byte alignment check for the last chunk, or if we're at the end of the entry?
Tested with GNU tar 1.30 (ubuntu 20.10 amd64). We can parse its -H pax output fine.

Apparently we can't parse the pax output fine either; the unpacked files are not even the right length. I'll try and raise a different bug about that.

Thanks for the report! I don't have a ton of experience with sparse archives, but given how relatively rarely they're used I wouldn't be surprised if there's a bug in the handling within this crate.
I don't have a ton of time to investigate this myself at the moment but I would be happy to review a PR!


.listNodes() returns error

Describe the bug
.listNodes() returns an error
To Reproduce
Steps to reproduce the behavior:
Try to use .listNodes()
Expected behavior
Gets node list
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Irrelevant
Smartphone (please complete the following information):
Irrelevant
Additional context
You didn't capitalize an L in application/methods/nodes/listNodes.js
return Req.getRequest('listNodes', null, null);
should be
return Req.getRequest('ListNodes', null, null);

Looking into it

Found the issue, I had a typo in the code. Thanks :)

v1.6.7 released.


Give filters field more concise

I'm using ransack filters from 'administrate_ransack' for replicate the solidus_backend fields search functionality.
At this moment the choosing of witch filter fender for witch field is made with a switch case in the _filters.html.erb.
I think it need to be moved to a render_filter field approach to be concise with the administrate approach.

Some progress are made with filters_helper.rb but its better to render as a Field::Class like


BEP: Backstage Notifications System

🔖 Feature description
The Backstage Notifications System provides a way for Backstage plugins to send notifications to users. The notifications are displayed in the Backstage frontend UI, but future extensions can allow them to be sent via external channels such as email. The system includes a push mechanism to make sure that users receive notifications immediately, as well as persistence of notification history and read status.
🎤 Context
#22212
✌ Possible Implementation
No response
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

To support asynchronous tasks, external systems need to be able to create new notifications.
In the early implementation of Notifications, this is possible by reaching the REST endpoint exposed by the Notifications backend, optionally authenticated.
In the BEP , this can be achieved by (custom) building yet another BE plugin exposing another REST endpoint of the same or very similar API which enforces authentication and passing-through data.
Such a composition increases complexity.
What about allowing external systems (non BE plugins) to reach the notifications REST endpoint and enable/disable such flow by configuration?

@mareklibra the BEP suggests that the API for sending notifications is protected by service-to-service auth. That will restrict access from users, but other backend services are still able to call the API, regardless of whether they're backstage backend plugins or external systems. With our current implementation of service-to-service auth all that is required is to generate a valid JWT using the configured backend secret, although this is something we plan to evolve and improve upon separately as part of #15999

A notification should further contain:

title
Human readable text shortly describing the notifications

priority
One of predefined values to help with presentation of the messages or filtering
Values: Critical, High, Normal, Low

icon - optional
To improve UX. A string referencing an icon name from MUI icon library of a defined version.
If missing, it will be determined from the priority

topic
A string value helping to group notifications of particular context
Use cases:

several notifications emitted by an asynchronous external task can be grouped by a single topic
a BE plugin can group several related messages to a particular processing, i.e. asynchronous progress monitoring

time-stamp of creation

to filter messages or prune the DB eventually or detect "long unread notifications"

origin
Identifications of the creator, i.e. the BE plugin

The payload should cover:

additional text
Optional in-depth content of the notification to be displayed to the user

a list of URLs and their descriptions
Use cases:

an external system can provide more details related to the notification
an action in an external system is requested within asynchronous task
a BE plugin can provide link to other part of the Backstage UI (i.e. to the Catalog)

I think most of the things in @mareklibra comment can be added later. If we just get the basic functionality working, it's then possible to add more stuff for UX etc. I am doing some refactoring based on the BEP to #21889.

@drodil I'd like is to try to figure out the overall strategy for managing the notifications schema. I agree finer details like whether there's an icon link or not could wait, but it would be good if we could get to the point where it's obvious where it would be added and how it is consumed. Discussing a couple of concrete examples is a good way to get there, so I think it makes sense to dive into some depth still.

I think it may be important to be able to segregate generation-time (the producing system decides this, this is probably an optional parameter and is present both in the input and output schema) and reception-time (the notifications backend decides this, and it's always present with a value only in the output schema).
This becomes extra important if the producing system buffers events or generate the events based on an external truth (such as a timestamp from a third party system).

I have a question about the use of the signal backend's use of a signals topic. It's mentioned that the signal backend might get a broader set of use cases in the future. But let's say that the catalog backend wants to start publishing "entity with ref k:ns/n has finished stitching with changes". It wants to broadcast that fact to the world, definitely not only for the purpose of notifications. How will it do this? Will it send two events - one general on a topic that it controls, and a narrower one also on the signals topic? Or is there some form of a bridge between the two topics then?
I know this is much to ask at this point, but it may be relevant to at least have some form of a plan for this, and whether some more labels-based scheme could have served those use cases batter.

@freben tbh I think the catalog should just publish a separate signals event that matches what has been implemented in the catalog frontend. It keeps things a lot simpler, and the main thing we need to make sure is that sending signals without anyone listening is cheap, which is something we need to solve for anyway.

Lots of good discussion in https://github.com/backstage/backstage/pull/22641 👍
List of unresolved threads:

[ ] How to generate in-app links for notifications: https://github.com/backstage/backstage/pull/22641#discussion_r1475794686
[ ] Whether notifications should be immutable: https://github.com/backstage/backstage/pull/22641#discussion_r1475857522
[ ] Removing image URL: https://github.com/backstage/backstage/pull/22641#discussion_r1475858757

I think we agree on this one, but the proposal still references image URLs in text

[ ] Handling of multiple links: https://github.com/backstage/backstage/pull/22641#discussion_r1475860873

As far as I can tell we all agree that some way to represent multiple links can be useful, but what do we need to have built-in as part of the core schema?

[ ] Notification as Tasks: https://github.com/backstage/backstage/pull/22641#discussion_r1475927485

Let's avoid diving into discussions on any of these topics in this issue, please instead open a PR towards the BEP and link the PR here, then we'll have the details discussions there.

Further things to consider adding to the system

[ ] User specific notification settings (ways to get notifications from core and processors, topics, etc.)
[ ] Adding support for analytics using analyticsApi
[ ] Automatic cleaning of old notifications based on configuration

Not stale, still lots of TODOs

I want to highlight this discussion around structured metadata for notifications, where we also discussed moving some of the existing fields to be metadata instead, such as links, icons, or anything that you don't need to be able to query notifications by. Any general thoughts?


merge from template-coveralls

package.json

chore(package): add 0.0.0-semantic-release (version)

:tada: This PR is included in version 5.0.34 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v5.0.34

Your semantic-release bot :package::rocket:


NMS.GEN.MCTS.005 - Ability to modify phone number of kilkari beneficiary via UI or CSV

The NMS system shall provide means to modify the MSISDN of a Kilkari Beneficiary by providing new MSISDN information along with existing MCTS id using CSV upload or MDS UI. However, this procedure is not allowed if the number is already being used by another Active Kilkari beneficiary for same pack.
A history/change table shall be created with old and new number for the beneficiary whose MSISDN number is being changed.
The language mapping for the beneficiary does not change due to change in MSISDN number.

I think this is the format used in the existing system.  The NMS format will either be the same, or very similar.  Note that the msisdn is more than 10 digits so it will need to be converted to take the last 10 digits.


Idea: display only Failure/Success/Controlled

I think it would be useful (especially for testing) to show, using kwargs, just some of the results. Something like:

-f /  --failure: shows only the Failure list
-s /  --success: shows only the Success list
-c / --controlled: shows only the Controlled list

I'm open to the idea, but unsure the best implementation. @basepi ?

Right now we already have show_success. I see no reason anyone would ever want only the successes and not the failures. Failures are why we're here.
Controlled is a little bit weirder. Right now we treat it as success for compliance computation, but it's not really the same as success....
I'm thinking we add a new config value, hubblestack.nova.treat_controlled_as_success, which will default to True. And we'll remove Controlled and Success when show_success is False. Thoughts?

I came with the idea because I had to scroll up to the top of the results just to see just one result I was looking for. BTW, is targeting just some of the checks available anymore (as we did it at the beginning, with regular expressions: hubble.audit CIS-4.2.\*)?

And, if hubblestack.nova.treat_controlled_as_success = False, they will be counted as failures?

Yes, targeting is still available, both in hubble.audit, and in topfiles.
No, controlled will never be counted as failures. This is a confusing configuration value. Maybe instead we should just add show_controlled as well.
I understand that right now you're interested in what's at the top (because Failures are generally at the bottom). But in the wild, I think people will only be interested in failures.

And I should also note that in the wild, people will actually control checks and/or update their boxes until there are no failures. Then the output will be much shorter (at least with show_success and show_controlled set to False).

so, currently, are inspections that include the control tag only organized into the control section of the output?  i.e. not grouped together with successes if the test would normally be a success?

control checks are simply skipped and put into the "Controlled" section of the output. They are not listed at all under Success or Failure.

Should they be executed, and if successful, then go under success.  but if they fail, then go under control?

I'm curious @grimamethyst opinion here.

@cedwards / @dgmorrisjr, it think it's better just to skip the control checks. Why wasting time on making a check that doesn't matter anyway? Even if it's a small amount, it's still wasted (I usually try to follow the perfection). In the current design, for a tag_data that contains the control key, we just continue the for loop that iterates through the tags to be checked. No time is wasted on doing that check. If we'd really want to check the control ones, we could add a new option that signals hubble to do so.

IF the inspection with a control option were processed, here is a situation where I think the tag is a bit helpful:
    ip6tables_should_be_running:
      data:
        Red Hat Enterprise Linux Server-6:
        - ip6tables:      V-38551
      description: |
        (Medium) The os must connect to external networks or information systems
        only through managed IPv6 interfaces consisting of boundary protection
        devices arranged in accordance with an organizational security architeture.
      control: |
        If the system is a cross-domain system, this is not applicable.
        If IPv6 is disabled, this is not applicable.

for the STIGS, in most systems, ip6tables must be running.   however, there are two situations where the control is not applicable.   So ideally here is the logic I think would be helpful:

if ip6tables service is running then = success
else list it under "control" so that it can manually be determined if it's a failure or success.

if it's under the failure group, then you have to sift through all of those to find these weird situations.

@dgmorrisjr What would this logic look like? Would it be a bash command (like with unless and onlyif in salt)? I've thought about having specific logic-based control but haven't thought of a really good way to implement it.
I should note that for the separate control configs, the audits will likely be run, and only failures will end up in the Controlled list. This is because separate control configs will be processed by hubble.py, post-audit.

I think supporting command requisites could be one way of doing that.  maybe something like this:
ip6tables_should_be_running:
      data:
        Red Hat Enterprise Linux Server-6:
        - ip6tables:      V-38551
        unless:
          - grep "install ipv6 /bin/true" /etc/modprobe.d/modprobe.conf
          - grep -i "NETWORKING_IPV6=no" /etc/sysconfig/network-scripts/ifcfg-eth*
          - grep -i "IPV6INIT=no" /etc/sysconfig/network-scripts/ifcfg-eth*

but within the unless construct, is it possible to specify an OR or an AND logic?

In salt, unless doesn't support a list, only a single command, so AND and OR aren't a thing there. I'll have to think if there's a way to make it happen for us.

Got it, more than anything I was trying to provide a working example of the types of checks that might need to be done.   I think there are simpler situations where there is just one value you want to validate against...    but the condition (e.g. the unless) could be:

value in a file(s) (e.g. setting in sysctl),
the presence of a file(s) (e.g. file in /etc/modprobe.d),
thx output of a command (e.g. chkconfig, rpm, etc),
combinations using AND / OR logic

Yeah, I understand where you're coming from. I'll have to think on this.

So, focusing back on the core of this issue, I think we should just add a show_controlled argument and configuration setting like we did for show_success. As far as requisites and whatnot, we should move the discussion about those into new issues.

This issue was moved to hubblestack/hubble-salt#33


bugfix(issue 20043): Parameter save_relative_paths of tf.train.Saver do not work non-local filesystem.

Fix the bug on issue 20043:  parameter save_relative_paths of tf.train.Saver do not work non-local filesystem.

I signed it!

i am sure that i have signed a CLA with my gihub account name  "jony0917" as "GitHub Account Name" in the CLA form,  and i am sure that the email address  from "git config --global user.email" has been added to my github account, so do i miss something?

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 29 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 44 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 59 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 74 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 89 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 104 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 119 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 137 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 152 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 29 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 44 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 59 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 74 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 89 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 119 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 134 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 149 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @rohan100jain: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 164 days with no activity and the awaiting review label has been applied.

I'm going to go ahead and close this PR, because it seems to have stalled. If you're still interested in pursing this (and responding to my comments), please feel free to reopen!


Deleted users lead to 500 responses on various time-related API endpoints

Description
When a user deletes their account, they become a Ghost account.
Such a user may already have logged time on issues.

In such a case, the following web API endpoints return 500.

GET /repos/{owner}/{repo}/issues/{index}/times
GET /repos/{owner}/{repo}/times
Other endpoints may also be affected, but our scripts did only ran into trouble here.

In particular not affected is GET /repos/{owner}/{repo}/times/{user} as long as user is not the id of a deleted user.
Gitea Version
1.17.2
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
We are running Gitea with docker from  image: gitea/gitea:1.17.2. Gitea DB is mariadb:10.9.2. The web API is behind a traefik reverse proxy.
Database
MySQL

Have you tried to upgrade to 1.17.3 ?

It would be very helpful to see the logs for these.

I am sorry, we did not retain logs.
A easy workaround is removing the user in question manually from the DB (just delete all entries of the user from tracked_time).
But repro should be easy:

Create new user
Log time to some issue
Delete user
Query API for issue or repo in question with admin user


Are EC schema the same / compatible with older ones?

Hi,
when reading documenation EC schemas, I have not found any comparison or information about "compatibility" with existing EC schemas as used in V8i and CONNECT Edition products.
Questions that crossed my mind:

Are EC schemas used in iModelJs the same? E.g. version information is based on 3 digits (I like an idea behing the digits meaning :-), but now 2 digits are used, so it seems the schemas itself developed into new version / syntax.
Are schemas available also as XML?
What about compatibility with existing schemas tool like Bentley Class Editor or iModel Schema Editor?
What about compatibility with DGN storage? Now MicroStation is able to import EC schemas into DGN file, which creates self-contained repository (similar to iModel SQLite). Is such scenario applicable also for new EC schemas?

With regards,
Jan

The new schema xml is compatible with the iModel Schema Editor (which will have a read only public beta release soon)

I downloaded Beta 2 and it looks nice! Will try this tool more later ;-)

Jan,
The description of what has changed between EC2 and EC3 made it out onto the public imodel.js documentation site.  Check it out here: https://imodeljs.github.io/iModelJs-docs-output/bis/ec/differences-between-ec2-and-ec3/
Please let me know if you want more info.  I will enhance the docs.  If the current documentation is sufficient please close this issue.

Closing, please reopen or create a new issue if you need more information.
Thanks

Colin


qdrant-web-ui   console

What are the main functions of the web ui console? I tried using this to create collections and save the code, but it doesn't seem like I actually created it. Thank you

It is an interactive console to your Qdrant instance!
To run a snippet, click the RUN hint above it. I believe you can also use CTRL+Enter.

thank you
石树礼
厦门同步网络有限公司
@.***
   		 厦门同步网络有限公司  	 企业主页

信息安全声明：本邮件包含信息归发件人所在组织所有，发件人所在组织对该邮件拥有所有权利。
请接收者注意保密，未经发件人书面许可，不得向任何第三方组织和个人透露本邮件所含信息的全部或部分。以上声明仅适用于工作邮件。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.
This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.  ------------------------------------------------------------------
发件人：Tim @.>
日　期：2023年06月13日 15:15:32
@.>
@.>; @.>
主　题：Re: [qdrant/qdrant-web-ui] qdrant-web-ui console (Issue #56)
It is an interactive console to your Qdrant instance!
To run a snippet, click the RUN hint above it. I believe you can also use CTRL+Enter.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Update mktime header declaration to match upstream LLVM libc.

Fixes:#1971

I'm guessing this isn't backwards-compatible with older toolchain distributions?

.. which it needs to be

Thanks for bringing up the compatibility question. I should've added the testing info to the PR description.
The change is compatible with the old toolchain revision.
I was able to use the current Clang toolchain revision - e894df6392beea3723627329009f3e6d51d16f47 against pico-sdk master branch with this PR's commit cherry-picked. The bazel build was completed successfully.

mktime is now included in LLVM libc time.h header, so the correct solution here is to delete that declaration altogether, but we also need to bump the toolchain version in MODULE.bazel.

I opened https://github.com/raspberrypi/pico-sdk/pull/1976 which updates the toolchain.

mktime is now included in LLVM libc time.h header, so the correct solution here is to delete that declaration altogether, but we also need to bump the toolchain version in MODULE.bazel.

That makes sense. @armandomontanez Will there ever be a case in Pigweed presubmits where the patches landed in the "develop" branch here be built with the toolchain revision mentioned in Pigweed's bazel source files?

Not automatically. For now, we'll be manually revving the required version of the Pico SDK. There may come a day where we do builds against HEAD of develop to learn about breakages sooner, but that's a ways out.

Not automatically. For now, we'll be manually revving the required version of the Pico SDK. There may come a day where we do builds against HEAD of develop to learn about breakages sooner, but that's a ways out.

Great! I'll close this PR. I'm assuming when we update the toolchain revision in Pigweed, we will update the PicoSDK revision which includes #1976 to get the presubmits to pass.


Better handling of remote content with transitions

Currently, remote content, unless loaded really quickly, or already cached in-browser, will not always show the (CSS) transitions, which is a nuisance.
This change makes it so that the "in" class is not added to the modal until loaded even is triggered (if applicable). This seems to work well, though if there are suggestions on a better/preferred alternative implementation, I'm certainly flexible.
Additionally, I did not add any Unit tests, because I didn't see any examples of how you would be handling remote/ajax requests in your tests? This change will only be applicable in situations where the "remote" option is set. I am assuming the best way would be to "mock" the request; if you have any suggestions, I would be happy to add test cases. All existing tests still passed when I ran the suite.

Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED
Commit: 1b52b3b318c1194d80d87fcc27f61acd874d9bf3
Build details: https://travis-ci.org/twbs-savage/bootstrap/builds/91480067
(Please note that this is a fully automated comment.)

Is there any way that I can solve the @twbs-savage issue where it times out after trying to connect for 10 minutes? Is that an issue with the code or with the continuous integration process? To me it seems like the latter.

Added an "Issue" for this PR: https://github.com/twbs/bootstrap/issues/18275

You can ignore @twbs-savage for now; the bot is having some problem communicating with Travis. We need to look into it.
Closing this per https://github.com/twbs/bootstrap/issues/18275#issuecomment-157228086


Hard to tell whether chat variables were used

Submit a chat request with some #file or other variables. Since variables don't show up "used references", it's impossible to tell from the UI whether or not they were actually used by the agent. They may not be used if they represent a lot of data that doesn't fit into the context window. We should always add variables to "used references" so that when they're missing, you know that they weren't used.
It would still be helpful to know specifically why they were missing and have even more feedback here, so we can probably go further.
We can also do more to compress the values of variables to fit more data into the context window.

Yeah, to add some extra commentary here, I notice when I tag multiple files with #file, and then ask a question about those files, it'll often say "I don't have access" or will hallcuinate something unrelated. Anecdotally I don't seem to have that issue when selecting code in the editor, and getting a "used reference" that way.
It would be great if using #file worked exactly the same as selecting text and getting a "used reference".


Getting No module named 'azure.keyvault.v7_0' error

I installed azure cli in Dockerfile like so:
RUN echo Y | apt-get install azure-cli
and I don't see any errors. I also logged into a service principal like so:
RUN az login --verbose --service-principal -u  $AZ_APPID -p $AZ_PASSWORD --tenant $AZ_TENANT_ID --allow-no-subscriptions
but when I'm trying to run the following command in Dockerfile:
RUN az keyvault secret show --name "<secretname>" --vault-name "<vaultname>" --query "value"
I get an error saying:
1.586 ERROR: CLIInternalError: The command failed with an unexpected error. Here is the traceback:
#0 1.587 ERROR: No module named 'azure.keyvault.v7_0'

The online solutions suggest using a specific version of azure-keyvault through pip but I'm using apt-get to install things. Does anyone know how to fix this?

keyvault

what is this supposed to mean?

Can you share the CLI version with az version?
Our official installation doc is https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

az version
2.18.0

Can you reinstall following https://docs.microsoft.com/en-us/cli/azure/install-azure-cli and see if the keyvault dependency works?

everything works fine if I install with pip . I still face issues when I use apt

@jiasli Do you know what could happen to cause this with apt?

I'm not sure honestly

Apparently, you are not installing the official Azure CLI. Please see https://github.com/Azure/azure-cli/issues/19640.


MODELDB CI: GitHub synergy

We are relying on the ModelDB API to downloads models. However we would be able to leverage better the GH API if models were synced between GH and MDB. What is needed?

[ ] Sync all ModelDB models to Github
[ ] Make sure those all are in sync
[ ] CI could rely on Github Repo

Been playing a bit with the GitHub CLI. Some notes:

we could add topics to models, i.e.gh repo edit ModelDBRepository/194897 --add-topic "neuron"

then getting a list of NEURON models:gh repo list modeldbrepository --topic "neuron" --json name -L 2000

It would be convenient to create releases and then we would download with:gh release download -R ModelDBRepository/266775 --archive=zip

or simplyhttps://github.com/ModelDBRepository/266775/archive/refs/heads/master.zip


Building failed with gcc 4.9.2 in Ubuntu 15.04

Hi,
I have some problems building with gcc 4.9.2. Here is the output
In file included from src/symbol/./graph_executor.h:16:0,
                 from src/symbol/graph_executor.cc:11:
src/symbol/././static_graph.h:186:84: error: converting to ‘const std::unordered_set<unsigned int>’ from initializer list would use explicit constructor ‘std::unordered_set<_Value, _Hash, _Pred, _Alloc>::unordered_set(std::unordered_set<_Value, _Hash, _Pred, _Alloc>::size_type, const hasher&, const key_equal&, const allocator_type&) [with _Value = unsigned int; _Hash = std::hash<unsigned int>; _Pred = std::equal_to<unsigned int>; _Alloc = std::allocator<unsigned int>; std::unordered_set<_Value, _Hash, _Pred, _Alloc>::size_type = long unsigned int; std::unordered_set<_Value, _Hash, _Pred, _Alloc>::hasher = std::hash<unsigned int>; std::unordered_set<_Value, _Hash, _Pred, _Alloc>::key_equal = std::equal_to<unsigned int>; std::unordered_set<_Value, _Hash, _Pred, _Alloc>::allocator_type = std::allocator<unsigned int>]’
                                      const std::unordered_set<uint32_t>& banned = {}) const;

It seems that there are some grammar problems. However, the problem is solved when I set
export CC = gcc-4.8
export CXX = g++-4.8

I wonder what causes the problem compiling with gcc 4.9.2. Thank you !

I have the same error on CentOS 6.5(Rocks OS) with GCC 4.9. But it works before i run "git pull". Maybe there are some error in recent commits. @mli

http://stackoverflow.com/questions/26947704/implicit-conversion-failure-from-initializer-list
By replacing {} with "std::unordered_set<uint32_t>()" in graph_executor.cc and static_graph.h, I successfully compiled mxnet.

could you please make a PR? http://mxnet.readthedocs.org/en/latest/contribute.html

Here is my modifications: https://github.com/shiyemin/mxnet/commit/16bc2a241c33f60363eeeec2f23c997a8e9bd391
I will soon submit a pull request for this PR.


Redis events: relaxing constraint of revision starting at 0

Summary
I'm not sure if this is a bug or feature request (probably the latter), but here is what I want to do vs what happens.
What I want
GIVEN events with revisions "m" through "n" exist for a certain aggregate (regardless of whatever other events exist),
WHEN I query for events using getEventsByRevision(aggregateId, m, n, callback),
THEN I expect to receive events with revisions "m" through "n" in the callback response.
What happens
GIVEN events with revisions "m" through "n" exist, BUT some events with revisions "0" through "m" (i.e. if any events between "0" and "m" do not exist),
WHEN (same as above),
THEN I receive the wrong events (sometimes no events)
When would this happen?
I have a use-case where we store lots of events for lots of aggregates, and we wanted a combination of speed and cheap(er) scalability (in terms of absolute event size). In other words, we didn't want an increasing number of events to slow down the querying of events too much.
Our solution was to write to 2 event stores simultaneously (using dynamo and redis), but only keep the most recent "N" events in the redis store for fast retrieval (once we've confirmed events were written to both stores). This means we have to remove old events (with old revisions) and want to continue being able to use the redis event store for querying in the same way.
How to fix
I made this work for our use-case a little while back, but then got busy and forgot to open a PR. I will link it shortly once I open it. This relaxes the constraints that all events (starting at revision 0) exist in the store, and retrieves the correct events by revision in either case (by using filter vs slice).
@adrai hope this makes sense. Let me know if you have questions about why or how, or changes you'd like to see.

https://github.com/adrai/node-eventstore/pull/133


[Feature Request] Wind Controls

Flag waver is great and all, but the wind you simulate swings around a lot and varies in strength.
The feature suggestion here is to add controls so the user can customise the wind they want.  So blowing from a particular direction and at a certain strength.

Siting @meson1 How do we can control wind?
Thank you btw!

I added a knob to control wind direction. Check out my fork here
The Pull Request is here

@loderunner this version is great, but I would love new features along with wind direction, like...

Ability to select how many flag poles on 1 screen (Limit can be 500 flagpoles)

Ability to raise and lower the flags (You set a timer by saying (Example: 2m 2s) and then start the timer to start raising or lowering the flags)(you can choose which to do; raise or lower)

Ability to select wind speed (Just type in (Example: 15 mph / kph) and press GO to set new wind speed.)

Attach a URL or file to select background (Same as the bar to put in your flag's Url or file)

Thanks for seeing this and I hope to see these features become reality!

Seems like 2.0.0 implemented this!! Yay!

Finally closing this since updated FlagWaver now features wind controls.

how to download as gif file?

@TNTGaming25 you can file a new issue for that question 🙂


feat: add struct_timestamps option

I ran into an issue today with a device of ours that had a file from 1970 (or at least that was the timestamp). In turn, stream-zip gave a cryptic error. Turns out, the ZIP file format simply does not support timestamps from before 1980. This is a known issue and python's built-in zipfile module provides the strict_timestamps option as a workaround for this.
In short, this PR:

Adds strict_timestamps as an optional argument to stream_zip. It defaults to true (replicating the current behaviour; no breaking changes).
When you set strict_timestamps=False then the library coerces any modified_at timestamps into [1980; 2108). This silently avoids underflow/overflow.

The CPython zipfile implementation inspired my implementation in this PR.
Let me know what you think!
Side note: Thank you for this great library (along with stream-unzip). :+1: It's crucial for the backup/restore feature on our devices. :)

Ah thanks for the PR!
So probably yes, should do something about this... But...

I'm leaning to not having an option at all and just "make it work" so earlier/later timestamps should in all cases be clamped so the zip file is created (Unless we can think of a use case where an error is desirable? Maybe some cases do need some validation for not-too-early-or-too-late timestamps, but I suspect that shouldn't be part of stream-zip)
And I'm leaning to not clamping the extended/unix timestamp if there is one, and only ever clamp the MS DOS one. I'm guessing a bit, but I think it would mean that clients that support the extended timestamps would then still in all cases use the right timestamp.
And leaning to having a bit of documentation on this behaviour somewhere, i.e. for older clients or all clients when extended_timestamps=False, the dates are clamped due to a limitation of the ZIP format

And also - I think would be good to add or change an existing tests around this, checking cases above and below the clamping range for both with and without the extended timestamps somehow.

@frederikaalund Let us know if you want to do the above / discuss more? No is all good of course, but in that case I would be tempted for us to make the changes at our end. I'm seeing this PR as essentially a bug report and keen to get it sorted.

To just think out loud, I wonder also if the extended/unix timestamps need to be clamped for times outside of the range representable by a signed 32 bit integer, e.g. after 2038...

Thanks for the feedback and I apologize for me late reply. It's been a busy week :)
I lean towards (1) too and only decided to not implement it that way since it's technically a breaking change. If you're okay with this subtle change then I'll gladly implement it without the kwarg option. 👍 It is an edge case after all.
If we go down this route, I too think that it's a good idea to clamp the timestamps in general (regardless of whether we store them in the MSDOS header or the Extended timestamp header). Something like this:

MSDOS timestamp header: Silently clamp to [1980; 2108)
Extended timestamp header: Silently clamp to [1902; 2038)

As for tests and docs, of course, let me add that as well as part of this PR. :) I would ask for the same thing myself so I just shamelessly tried to get away with not doing it 😅
Let me know what you think. Thanks again for your feedback on this PR!

If you're okay with this subtle change then I'll gladly implement it without the kwarg option. 👍 It is an edge case after all.

I think I am - it's the better behaviour I would say for my use cases, and it sounds like yours too, and it's simpler to not have an option. I avoiding a breaking change I don't think is worth it really.

Something like this:
MSDOS timestamp header: Silently clamp to [1980; 2108)
Extended timestamp header: Silently clamp to [1902; 2038)

Yes exactly (and I might lean to the making the range are large as possible i.e. clamping to exactly the largest/smallest second that's representable for each)

Hi again, finally found some time to work on this. :)
I just pushed a rework that silently clamps the timestamps to the available precision in the MS-DOS and UNIX headers. I added tests for each.
Note that the timestamp limits are:

MSDOS timestamp header: Silently clamp to [1980; 2108)
Extended timestamp header: Silently clamp to [1970; 2038)

Note that I now use a lower limit of 1970 (and not 1902 as previously discussed). Some tools (unzip in particular) has problems with negative timestamps. It's technically a bug in unzip but it's a rather popular tool so why not just abide.
I also added tests and docs. Let me know if you want anything changed 👍

Looks great! Having a bit of a nose around and think still - will leave comments in the code


Issue processing packages containing node_modules directory

When a node_module directory is present in a workspace package it gets picked up for processing of version number.
Here's my config:
$ node -v
v18.9.0
$ yarn --version
3.2.3
$ tree -L 3 packages
packages
├── packagegroup2
│   └── sample-package
│       ├── node_modules  **this is the cause of the issue**
│       ├── package.json
│       ├── README.md
│       ├── src
│       └── tsconfig.json
└── packagegroup1
    ├── package2
    │   ├── dist
    │   ├── jest.config.js
    │   ├── package.json
    │   ├── README.md
    │   ├── src
    │   ├── test
    │   └── tsconfig.json
    ├── package3
    │   ├── dist
    │   ├── jest.config.js
    │   ├── nest-cli.json
    │   ├── package.json
    │   ├── README.md
    │   ├── src
    │   ├── test
    │   ├── test-data.json
    │   ├── tsconfig.json
    │   └── tsconfig.tsbuildinfo
    ├── package4
    │   ├── dist
    │   ├── jest.config.js
    │   ├── package.json
    │   ├── README.md
    │   ├── src
    │   ├── test
    │   ├── tsconfig.json
    │   └── tsconfig.tsbuildinfo
    ├── package6
    │   ├── cucumber.js
    │   ├── dist
    │   ├── jest.config.js
    │   ├── node_modules    **this is the cause of the issue**
    │   ├── output.json
    │   ├── package.json
    │   ├── README.md
    │   ├── test
    │   ├── TestEvidence
    │   └── tsconfig.json
    ├── package1
    │   ├── dist
    │   ├── jest.config.js
    │   ├── nest-cli.json
    │   ├── package.json
    │   ├── README.md
    │   ├── refsets
    │   ├── src
    │   ├── test
    │   └── tsconfig.json
    └── package5
        ├── dist
        ├── package.json
        ├── src
        ├── tsconfig.json
        └── tsconfig.tsbuildinfo

$ cat package.json
{
        "name": "mycompany",
        "version": "1.0.0",
        "description": "xxx",
        "private": true,
        "husky": {
                "hooks": {
                        "pre-commit": "npx lint-staged"
                }
        },
        "lint-staged": {
                "**/*.{js,jsx,ts,tsx,md,html,css,json,yaml}": [
                        "prettier --write"
                ]
        },
        **"release-it": {
                "plugins": {
                        "@release-it-plugins/workspaces": true
                },
                "npm": false,
                "git": {
                        "commitMessage": "bumping release to v${version}"
                }
        },**
        "scripts": {
                "...": "..."
        },
        "workspaces": {
                "packages": [
                        "packages/**/*"
                ]
        },
        "devDependencies": {
                "@jest/globals": "28.1.3",
                **"@release-it-plugins/workspaces": "^3.2.0",**
                "@types/dotenv": "^8.2.0",
                "@types/jest": "28.1.1",
                "@types/node": "^18.7.18",
                "@typescript-eslint/eslint-plugin": "^5.37.0",
                "@typescript-eslint/parser": "^5.37.0",
                "copyfiles": "^2.4.1",
                "dotenv": "^16.0.2",
                "eslint": "^8.23.1",
                "eslint-config-prettier": "^8.5.0",
                "eslint-plugin-prettier": "^4.2.1",
                "husky": "^8.0.1",
                "jest": "28.1.3",
                "jest-cli": "28.1.3",
                "lint-staged": "^13.0.3",
                "prettier": "^2.7.1",
                **"release-it": "^15.4.2",**
                "rimraf": "^3.0.2",
                "ts-jest": "28.0.8",
                "ts-loader": "^9.3.1",
                "ts-node": "^10.9.1",
                "tsconfig-paths": "^4.1.0",
                "tslib": "^2.4.0",
                "typescript": "^4.8.3",
                "webpack": "^5.74.0"
        },
        "dependencies": {
                "fast-glob": "^3.2.12",
                "glob": "^8.0.3",
                "moment": "^2.29.4",
                "moment-timezone": "^0.5.37"
        },
        "packageManager"<EMAIL_ADDRESS>}

Running the command
08:40 $ release-it --ci -i minor --dry-run
! npm ping --registry https://registry.npmjs.org
! npm whoami --registry https://registry.npmjs.org
$ git diff --quiet HEAD
$ git rev-parse --abbrev-ref HEAD
$ git config --get branch.XXX-000/update-docker-performance.remote
$ git remote get-url origin
! git fetch
$ git rev-parse --abbrev-ref HEAD  [cached]
$ git describe --tags --match=* --abbrev=0
$ git symbolic-ref HEAD
$ git for-each-ref --format="%(upstream:short)" refs/heads/XXX-000/update-docker-performance
$ git log --pretty=format:"* %s (%h)" v1.0.0...HEAD
🚀 Let's release package1-server (1.0.0...1.1.0)
Changelog:
* more (35c90f59)
* more (39f193e7)
* more (a9dea473)
* more (d3dd7c0f)
* More (2e897798)
* more (7b008f16)
* more (58aba259)
* more (4f4af868)
* more (9577aaf6)
* more (5bcb0f0f)
* more (06520cef)
* more (4ed45dbe)
* more (999cf0e9)
* more (f94aac73)
* broken docker (6d0e38d7)
* more (14a47eaf)
* Improve Docker build (89b16cf4)
* Merged in XXX-1003-data (pull request #290) (38c04b72)
* Merged in XXX-1128---Time (pull request #298) (5bc0ba45)
* Merged in adding-test-data-for-XXX (pull request #297) (0780c253)
* Merged in XXX-1194 (pull request #291) (aca5e754)
* Merged in XXX-000/dockerfile-broken (pull request #296) (95b77167)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/reporters` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-changed-files` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-config` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-resolve-dependencies` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runner` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-watcher` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `@jest/test-sequencer` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/fake-timers` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       devDependencies: `jest-matcher-utils` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/expect` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `glob` -> ^1.1.0 (from ^7.1.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-worker` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.0)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.0)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/schemas` -> ^1.1.0 (from ^29.0.0)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.2)
$ Processing packages/docs/sample-package/node_modules/babel-jest/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `babel-preset-jest` -> ^1.1.0 (from ^29.0.2)
$ Processing packages/docs/sample-package/node_modules/babel-plugin-jest-hoist/package.json:
$       version: -> 1.1.0 (from 29.0.2)
$ Processing packages/docs/sample-package/node_modules/babel-preset-jest/package.json:
$       version: -> 1.1.0 (from 29.0.2)
$       dependencies: `babel-plugin-jest-hoist` -> ^1.1.0 (from ^29.0.2)
$ Processing packages/docs/sample-package/node_modules/diff-sequences/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/docs/sample-package/node_modules/glob/package.json:
$       version: -> 1.1.0 (from 7.2.3)
$ Processing packages/docs/sample-package/node_modules/jest-changed-files/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-circus/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/expect` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-each` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-matcher-utils` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-cli/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/core` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-config` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-config/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/test-sequencer` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `babel-jest` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `glob` -> ^1.1.0 (from ^7.1.3)
$       dependencies: `jest-circus` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runner` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-diff/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `diff-sequences` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-docblock/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-each/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-get-type/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-haste-map/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-worker` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-leak-detector/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-matcher-utils/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-diff` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-message-util/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-pnp-resolver/package.json:
$       version: -> 1.1.0 (from 1.2.2)
$       peerDependencies: `jest-resolve` -> 1.1.0 (from *)
$ Processing packages/docs/sample-package/node_modules/jest-regex-util/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-resolve-dependencies/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-resolve/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-pnp-resolver` -> ^1.1.0 (from ^1.2.2)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-runner/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-docblock` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-leak-detector` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-watcher` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-worker` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `source-map-support` -> 1.1.0 (from 0.5.13)
$ Processing packages/docs/sample-package/node_modules/jest-runtime/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/fake-timers` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/globals` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/source-map` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `glob` -> ^1.1.0 (from ^7.1.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-snapshot/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/expect-utils` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-diff` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-matcher-utils` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-util/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-validate/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/docs/sample-package/node_modules/jest-watcher/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest-worker/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `supports-color` -> ^1.1.0 (from ^8.0.0)
$       devDependencies: `jest-leak-detector` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/jest/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/core` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-cli` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/docs/sample-package/node_modules/source-map-support/package.json:
$       version: -> 1.1.0 (from 0.5.13)
$ Processing packages/docs/sample-package/node_modules/supports-color/package.json:
$       version: -> 1.1.0 (from 8.1.1)
$ Processing packages/docs/sample-package/package.json:
$       version: -> 1.1.0 (from 1.0.0)
$       devDependencies: `@types/jest` -> ^1.1.0 (from ^29.0.2)
$       devDependencies: `jest` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package2/package.json:
$       version: -> 1.1.0 (from 1.0.0)
$       devDependencies: `@jest/globals` -> 1.1.0 (from 28.1.3)
$       devDependencies: `@types/jest` -> 1.1.0 (from 28.1.1)
$       devDependencies: `@mycompanyscope/package5` -> 1.1.0 (from workspace:*)
$       devDependencies: `jest` -> 1.1.0 (from 28.1.3)
$       devDependencies: `jest-cli` -> 1.1.0 (from 28.1.3)
$       devDependencies: `ts-jest` -> 1.1.0 (from 28.0.8)
$ Processing packages/packagegroup1/package3/package.json:
$       version: -> 1.1.0 (from 1.0.0)
$       dependencies: `@mycompanyscope/package5` -> 1.1.0 (from workspace:*)
$       dependencies: `source-map-support` -> ^1.1.0 (from ^0.5.21)
$       devDependencies: `@jest/globals` -> 1.1.0 (from 28.1.3)
$       devDependencies: `@types/jest` -> 1.1.0 (from 28.1.1)
$       devDependencies: `jest` -> 1.1.0 (from 28.1.3)
$       devDependencies: `jest-cli` -> 1.1.0 (from 28.1.3)
$       devDependencies: `ts-jest` -> 1.1.0 (from 28.0.8)
$ Processing packages/packagegroup1/package4/package.json:
$       version: -> 1.1.0 (from 1.0.0)
$       dependencies: `@mycompanyscope/package5` -> 1.1.0 (from workspace:*)
$       devDependencies: `@jest/globals` -> 1.1.0 (from 28.1.3)
$       devDependencies: `@types/jest` -> 1.1.0 (from 28.1.1)
$       devDependencies: `jest` -> 1.1.0 (from 28.1.3)
$       devDependencies: `jest-cli` -> 1.1.0 (from 28.1.3)
$       devDependencies: `ts-jest` -> 1.1.0 (from 28.0.8)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/reporters` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-changed-files` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-config` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-resolve-dependencies` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runner` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-watcher` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `@jest/test-sequencer` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/fake-timers` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       devDependencies: `jest-matcher-utils` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/expect` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `glob` -> ^1.1.0 (from ^7.1.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-worker` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.0)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.0)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/schemas` -> ^1.1.0 (from ^29.0.0)
$ Processing<EMAIL_ADDRESS>$       version: -> 1.1.0 (from 29.0.2)
$ Processing packages/packagegroup1/package6/node_modules/babel-jest/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `babel-preset-jest` -> ^1.1.0 (from ^29.0.2)
$ Processing packages/packagegroup1/package6/node_modules/babel-plugin-jest-hoist/package.json:
$       version: -> 1.1.0 (from 29.0.2)
$ Processing packages/packagegroup1/package6/node_modules/babel-preset-jest/package.json:
$       version: -> 1.1.0 (from 29.0.2)
$       dependencies: `babel-plugin-jest-hoist` -> ^1.1.0 (from ^29.0.2)
$ Processing packages/packagegroup1/package6/node_modules/diff-sequences/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/glob/package.json:
$       version: -> 1.1.0 (from 7.2.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-changed-files/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-circus/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/expect` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-each` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-matcher-utils` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-cli/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/core` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-config` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-config/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/test-sequencer` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `babel-jest` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `glob` -> ^1.1.0 (from ^7.1.3)
$       dependencies: `jest-circus` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runner` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-diff/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `diff-sequences` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-docblock/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-each/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-get-type/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-haste-map/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-worker` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-leak-detector/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-matcher-utils/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-diff` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-message-util/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-pnp-resolver/package.json:
$       version: -> 1.1.0 (from 1.2.2)
$       peerDependencies: `jest-resolve` -> 1.1.0 (from *)
$ Processing packages/packagegroup1/package6/node_modules/jest-regex-util/package.json:
$       version: -> 1.1.0 (from 29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-resolve-dependencies/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-resolve/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-pnp-resolver` -> ^1.1.0 (from ^1.2.2)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-validate` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-runner/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/console` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-docblock` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-leak-detector` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-runtime` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-watcher` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-worker` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `source-map-support` -> 1.1.0 (from 0.5.13)
$ Processing packages/packagegroup1/package6/node_modules/jest-runtime/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/environment` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/fake-timers` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/globals` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/source-map` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `glob` -> ^1.1.0 (from ^7.1.3)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-regex-util` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-resolve` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-snapshot` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-snapshot/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/expect-utils` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-diff` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$       dependencies: `jest-haste-map` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-matcher-utils` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-message-util` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-util/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-validate/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-get-type` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/packagegroup1/package6/node_modules/jest-watcher/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/test-result` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest-worker/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `supports-color` -> ^1.1.0 (from ^8.0.0)
$       devDependencies: `jest-leak-detector` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/jest/package.json:
$       version: -> 1.1.0 (from 29.0.3)
$       dependencies: `@jest/core` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       dependencies: `jest-cli` -> ^1.1.0 (from ^29.0.3)
$ Processing packages/packagegroup1/package6/node_modules/source-map-support/package.json:
$       version: -> 1.1.0 (from 0.5.13)
$ Processing packages/packagegroup1/package6/node_modules/supports-color/package.json:
$       version: -> 1.1.0 (from 8.1.1)
$ Processing packages/packagegroup1/package6/node_modules/ts-jest/package.json:
$       version: -> 1.1.0 (from 29.0.1)
$       dependencies: `jest-util` -> ^1.1.0 (from ^29.0.0)
$       devDependencies: `@jest/transform` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `@jest/types` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `babel-jest` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `glob` -> ^1.1.0 (from ^8.0.3)
$       devDependencies: `jest` -> ^1.1.0 (from ^29.0.3)
$       peerDependencies: `@jest/types` -> ^1.1.0 (from ^29.0.0)
$       peerDependencies: `babel-jest` -> ^1.1.0 (from ^29.0.0)
$       peerDependencies: `jest` -> ^1.1.0 (from ^29.0.0)
$ Processing packages/packagegroup1/package6/package.json:
$       version: -> 1.1.0 (from 1.0.0)
$       devDependencies: `@types/jest` -> ^1.1.0 (from ^29.0.2)
$       devDependencies: `jest` -> ^1.1.0 (from ^29.0.3)
$       devDependencies: `ts-jest` -> ^1.1.0 (from ^29.0.1)
$ Processing packages/packagegroup1/package1/package.json:
$       version: -> 1.1.0 (from 1.0.0)
$       dependencies: `@mycompanyscope/package5` -> 1.1.0 (from workspace:*)
$       devDependencies: `@jest/globals` -> 1.1.0 (from 28.1.3)
$       devDependencies: `@types/jest` -> 1.1.0 (from 28.1.1)
$       devDependencies: `glob` -> ^1.1.0 (from ^8.0.3)
$       devDependencies: `jest` -> 1.1.0 (from 28.1.3)
$       devDependencies: `jest-cli` -> 1.1.0 (from 28.1.3)
$       devDependencies: `source-map-support` -> ^1.1.0 (from ^0.5.21)
$       devDependencies: `ts-jest` -> 1.1.0 (from 28.0.8)
$ Processing packages/packagegroup1/package5/package.json:
$       version: -> 1.1.0 (from 1.0.0)
$ Processing additionManifest.versionUpdates for ./package.json:
$       version: -> 1.1.0 (from 1.0.0)
$ git status --short --untracked-files=no
Empty changeset
! git add . --update
! git commit --message bumping release to v1.1.0
! git tag --annotate --message Release 1.1.0 v1.1.0
$ git symbolic-ref HEAD  [cached]
$ git for-each-ref --format="%(upstream:short)" refs/heads/XXX-000/update-docker-performance  [cached]
! git push --follow-tags
$ npm publish ./packages/docs/sample-package/node_modules/@jest/console --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/core --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/environment --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/expect-utils --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/expect --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/fake-timers --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/globals --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/reporters --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/schemas --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/source-map --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/test-result --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/test-sequencer --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/transform --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@jest/types --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/@types/jest --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/babel-jest --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/babel-plugin-jest-hoist --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/babel-preset-jest --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/diff-sequences --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/glob --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-changed-files --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-circus --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-cli --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-config --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-diff --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-docblock --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-each --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-get-type --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-haste-map --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-leak-detector --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-matcher-utils --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-message-util --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-pnp-resolver --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-regex-util --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-resolve-dependencies --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-resolve --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-runner --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-runtime --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-snapshot --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-util --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-validate --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-watcher --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest-worker --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/jest --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/source-map-support --tag latest --dry-run
$ npm publish ./packages/docs/sample-package/node_modules/supports-color --tag latest --dry-run
$ npm publish ./packages/docs/sample-package --tag latest --dry-run
WARNING @mycompanyscope/package2: Skip publish (package is private)
WARNING @mycompanyscope/package3: Skip publish (package is private)
WARNING @mycompanyscope/package4: Skip publish (package is private)
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/console --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/core --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/environment --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/expect-utils --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/expect --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/fake-timers --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/globals --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/reporters --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/schemas --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/source-map --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/test-result --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/test-sequencer --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/transform --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@jest/types --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/@types/jest --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/babel-jest --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/babel-plugin-jest-hoist --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/babel-preset-jest --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/diff-sequences --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/glob --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-changed-files --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-circus --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-cli --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-config --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-diff --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-docblock --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-each --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-get-type --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-haste-map --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-leak-detector --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-matcher-utils --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-message-util --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-pnp-resolver --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-regex-util --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-resolve-dependencies --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-resolve --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-runner --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-runtime --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-snapshot --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-util --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-validate --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-watcher --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest-worker --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/jest --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/source-map-support --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/supports-color --tag latest --dry-run
$ npm publish ./packages/packagegroup1/package6/node_modules/ts-jest --tag latest --dry-run

Not sure if it's just the dry-run however I didn't want to proceed without the flag

I've just run through the workspace plugin code and realised it's an issue with my workspace declaration... my glob string was too wide. Changing it to pacakges/*/* has done the trick.
I'll leave this around in case anyone else does the same thing!


Incorrect test definitions

Our first review of the tests turned up some incorrectly defined tests.
Incorrectly defined tests
(So far I haven't found the below in the issues raised with test cases, hence, they may have been added during implementation. In one case this could be an area that the standard could improve, but doesn't currently cover (and hence can't be part of a compliance test).
1)
https://github.com/finos/FDC3-conformance-framework/blob/cd8969bb0b7adff6f4d52fc02094e3b129995a4c/tests/src/test/fdc3.broadcast.ts#L117
This directly contradicts the Standard: Joining User Channels in 2.0 and Joining Channels in 1.2:

If an app is not joined to a User channel fdc3.broadcast will be a no-op and handler functions added with fdc3.addContextListener will not receive any broadcasts.

Remove this test please.
2)
https://github.com/finos/FDC3-conformance-framework/blob/cd8969bb0b7adff6f4d52fc02094e3b129995a4c/tests/src/test/fdc3.broadcast.ts#L376
No such error exists in FDC3 1.2 or 2.0. See https://fdc3.finos.org/docs/1.2/api/ref/Errors
There is at present no statement of what should or should not happen when an invalid context object is passed. What is known is that it would not be delivered to a filtered context listener without a type, but that is all that's specified.
Remove this test please - or at least comment it out with a note that its not defined in the standard.
3)
https://github.com/finos/FDC3-conformance-framework/blob/cd8969bb0b7adff6f4d52fc02094e3b129995a4c/tests/src/test/fdc3.broadcast.ts#L696
No such error exists in FDC3 1.2 or 2.0. See https://fdc3.finos.org/docs/1.2/api/ref/Errors
Remove this test please - or at least comment it out with a note that its not defined in the standard.
4)
https://github.com/finos/FDC3-conformance-framework/blob/cd8969bb0b7adff6f4d52fc02094e3b129995a4c/tests/src/test/fdc3.broadcast.ts#L738
You didn't wait for it to do its broadcasts here as you do in other tests:
https://github.com/finos/FDC3-conformance-framework/blob/cd8969bb0b7adff6f4d52fc02094e3b129995a4c/tests/src/test/fdc3.broadcast.ts#L749-L757
This is an example of a place where coordinating messages could be used instead of waits... see Implementation feedback #74.
5)
https://github.com/finos/FDC3-conformance-framework/blob/cd8969bb0b7adff6f4d52fc02094e3b129995a4c/tests/src/test/fdc3.open.ts#L101
This test should/will never pass as the (malformed) context has no type, so it can't be routed to a typed context listener. Perhaps better to confirm it did get started by another means... However, behaviour with an invalid argument is not defined in the standard. Hence, I'd probably just go ahead and remove this test.
6)
https://github.com/finos/FDC3-conformance-framework/blob/cd8969bb0b7adff6f4d52fc02094e3b129995a4c/tests/src/test/fdc3.raiseIntent.ts#L86
Note that IntentResolution.source is of type TargetApp, which can be the string name or an AppMetadata object. Thats not why Finsemble fails this test - but led me to this error.
Note that this needs fixing in multiple tests in this file.

I've created a PR that addresses these issues:
https://github.com/finos/FDC3-conformance-framework/pull/75

All addressed in #75


Error connection with SQL and param string Trusted_Connection=True

Hi everyone, I found an issue when building the string connection with sql on the module:  sqlserver_data_source.py
When the connection is trusted, you dont need user and pass, so the solution could be:
(the last two lines were added)
self.connection = pyodbc.connect(
("Trusted_Connection=YES;" if self.trusted_connection else "")
+ ("TrustServerCertificate=YES;" if self.trust_server_certificate else "")
+ ("Encrypt=YES;" if self.encrypt else "")
+ "DRIVER={"
+ self.driver
+ "};SERVER="
+ self.host
+ ","
+ str(self.port)
+ ";DATABASE="
+ self.database
+ (";UID=" + self.username  if not self.trusted_connection else "")
+ (";PWD=" + self.password  if not self.trusted_connection else "")
)
Many thanks guys for the job done, i am starting to use it and i like it :)

SAS-2143

Thank you for the report @rodrigomartinez1302 ! Would you like to open a PR with the fix? I'll be happy to merge it ASAP.

Hi, Is this issue fixed ?

Not yet, would you be able to open a PR for this @rodrigomartinez1302 ?

Fixed this in #2160


build: drop un-used samples directory

:tada: This PR is included in version 1.8.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


SPI transfers limited to approximately 4KiB

Attempting to transfer more than 4092 bytes (using DMA) results in E (63662) spi_master: spi_device_queue_trans(620): txdata transfer > host maximum.
Solutions, in order of most desirable to least:

spi_device_transmit handles larger blocks transparently
The SPI code provides a mechanism for user code to query the maximum transfer size
The SPI documentation is updated to reflect the limitation

I'd be willing to submit a PR, if there was a reasonable chance it would be accepted.

https://github.com/espressif/esp-idf/blob/master/components/driver/spi_master.c#L87

https://github.com/espressif/esp-idf/blob/63e1e4e502178ced9d29999e45050c952be29c26/components/driver/include/driver/spi_common.h#L60

Hi @MrSurly , did the above suggestion help you resolve the issue?

@MrSurly
As @negativekelvin said, there's a configuration field to set the max transfer size, this is mainly because we have to allocate space for the DMA descriptors at initialization.
If this field is not set, we only use 1 descriptor which support up to 4094 bytes buffer length.

@FayeY Yes, that works.  Thanks.

I am having the same issue in using SPI to update a LCD module. I need 38400 bytes of DMA buffer in calling spi_device_transmit. It is only around 4000 bytes could be sent at once.

Hi @bonmotwang ,
Please set the parameter here, and also prepare enough size of Internal buffer for RAM
https://espressif-docs.readthedocs-hosted.com/projects/esp-idf/en/latest/api-reference/peripherals/spi_master.html#_CPPv4N16spi_bus_config_t15max_transfer_szE
https://espressif-docs.readthedocs-hosted.com/projects/esp-idf/en/latest/api-reference/system/mem_alloc.html?highlight=heap_caps#_CPPv416heap_caps_malloc6size_t8uint32_t
If the internal RAM is not enough, please split the data into pieces and send by several times.


fix: Option usedefaults re-assign

var options = {
  reverse: true,
  usedefaults: false
}
var formatter = new StringMask('+00 (00) 0000-0000', options)

Old code;
usedefaults: this.options.usedefaults || this.options.reverse

OR operator (||) returns the condition on the right side but the expected one was to have returned the left side.
OR for defaults can be convenient because it is short and easy to write but to booleans parameters it was not good.

Coverage remained the same at 100.0% when pulling 5cd69bb264f9de10ceab4e1dd5fe246e2a4aacb5 on financialsistemas:bug/options-default into 094cc3104040c61a78564c6c0e640408b3264bb0 on the-darc:master.


Release 0.6.1?

Any thoughts about releasing a version 0.6.1? There's been a lot of stuff since 0.6.0. :^)
(Opening a ticket doesn't seem like the best way to suggest this, but I wasn't sure what else would be better.)

Opening a ticket is fine as it is easy to reference. I am currently overseas on holidays for another week. I can create a 0.6.1 release when I am back home.

Awesome; thanks!

Following a suggestion by @nielsonsantana this will probably be 0.7.0 as there are quite a few changes.

? progress

Done - and thanks for everyone's patience.
Please check README.md and DEVELOPMENT.md in the develop branch for important information regarding current releases.