Minimum viable package manager

Building a fully-fledged package manager is complex and too big of a time investment currently. Nonetheless, package management is one of the most asked-for features. That's why we have decided to build a minimum viable package manager while leaving options for expansion open for the future.
Technical design proposal

Packages live on https://github.com/typst/packages
Packages are submitted through pull requests (at least for now)
Each package version is a separate folder in the repository
Packages must have a TOML file with metadata, license, etc.
A GitHub action builds tarballs for all packages and uploads them to Azure blob storage
Package imports always need to specify the exact version (at least for now). This way, we don't need to deal with locking or anything like that. While this more easily leads to situations where a package is included in multiple versions, that's not really a big problem.
When a package is imported / included in the CLI, it searches for it in a well-known system location. If not found, it downloads it from its well-known URL. Because packages are immutable and full versions must be specified, the network is not touched if all packages are already available.
Similarly, when a package is imported / included in the web app, it searches for it / stores it in the IndexDB
A searchable list of packages with documentation will be available on https://typst.app/docs/packages. For now, packages can have one Markdown file of documentation (no Typst HTML export yet :/). In the future, we can have automatic documentation generation à la rustdoc.
Search index and docs are also built via GitHub action. While this doesn't scale, it should take us far enough (the process for each individual package is relatively cheap).

We are not yet decided on namespacing. Namespaces could be very useful, for instance for organization or university templates. A global namespace on the other hand is a lot more discoverable for packages. One possibility that would allow us to keep all options open, is to have all packages in a @preview namespace for now (e.g. #import "@preview/somepackage:0.2").
Submissions
There will be guidelines for what criteria a package needs to fulfill to be published. These will be reviewed upon submission via pull request. Below is a first draft of the submission guidelines. These guidelines are up for discussion!

Naming

Names should not include the word typst as it is redundant
Names should not be merely descriptive (e.g. not just slides) to create level grounds for everybody, without one package immediately being the "blessed" solution
Names (and all package contents) must be safe for work
Currently, there are many projects called typst-thing. To be published as packages, these will need to come up with a more creative name. Merely descriptive names could maybe be used in the future if things do become the blessed solution / an extension to the standard library

Documentation: All package exports intended for public use must be (at least briefly) documented in the accompanying Markdown file

Size: Packages should not contain large files or a large number of files. This will be judged on a case-by-case basis, but if it needs more than ten files, it should be well-motivated.

License: Packages must be licensed under the terms of an OSI-approved license

Open Questions

Best system location for package storage:

${XDG_CACHE_DIR}/typst/packages/* on Unix?
Somewhere in AppData on Windows?

Should we go with the @preview namespace?
Any changes or additions to the submission guidelines?

Any feedback on the design would be welcome. We plan to build this package manager in a matter of days and ship it in the next release.

Having experience with package managers (packager for multiple Linux distros, author of typesetting software with external packages, maintainer of vim plugins installable via multiple plugin managers, etc.) I would suggest this approach is going to be very hard to maintain long term. It isn't a terrible idea to get the ball rolling but you'll start having trouble with it when things start accruing.
I would highly recommend you go with the "everything is namespaced @preview" approach to make it much easier to migrate to next iteration of packages once you outgrow this approach.

A few thoughts:
names and namespacing
If we want to have distinct names as to avoid "blessed ones", I feel that we should have namespacing. If I currently have typst-thingy and I can't/don't want to give it a fancy name, I'd much rather call it @edhebi/thingy than edhebi-thingy. This is also useful in a more direct manner because for a direct import it makes it available in a thingy module rather than a edhebi-thingy module, which for long package names feel like it would be an issue fairly quicly
All that being said, I do think a @preview namespace is the right call in the beginning, maybe even @preview/v1.
Paths
Please do not default to a dot directory right under the home and instead follow the XDG Base Directories spec. This is a defacto standard because a lot of people are realy tired of home directories pollution. In the case of typst, the result would be storing packages in ${XDG_CACHE_DIR}/typst/packages/* and defaulting to $HOME/.cache/typst/packages/*. This also works on other OSes just by using a different fallback values for that directory.
Immutability
There's nothing technically preventing a package from being changed on the website, including an existing version of a package. I'd like to see hashing of packages at some point of the process. having to provide those along with the version would be incredibly unwieldy tho

Reg immutability: having a vendor folder would solve this on a project level
Hashing would be sth like a lock file and checks against this

@preview namespace is definitely the way to go for a temporary solution like this.
is there a risk with packages (can we still read ssh and invisibly embed it in a pdf)?
if not another solution would be to have a #import<EMAIL_ADDRESS>and maybe an option to specify the hash.
checks at runtime if the folder is conveniently organised ( helped by a typst-package.toml file )
ultimately it's free and people understand that it's the responsability of the owner of the package.
This could live alongside @preview where you have the assurance things have been reviewed and won't change.
Some might argue it's a terrible idea but I'm not so sure

is there a risk with packages (can we still read ssh and invisibly embed it in a pdf)?
I believe that this falls under another PR/RFC that has been opened that discusses a basic permission systems as a temporary stopgap.

Following @alerque and @astrale-sharp, while I can see the benefits of hashing out a package manager quickly, perhaps a better idea for now might be to allow users to import packages directly from GitHub à la Deno. Something like #import<EMAIL_ADDRESS>which would take the latest commit from that repository, while adding some specifier like a #commithash or a #v0.0.3 tag would allow being more specific. (Note the @git prefix, which would be generic enough to allow for other sites such as GitLab, codeberg etc.)
I feel this would be better as a temporary solution, as "there is nothing more permanent than a temporary solution" as they say, and this git approach would be permanently viable, while a unified repository requires a lot of maintenance, which I'm not sure would be the best thing for the Typst team to focus on.
Perhaps it would be nicer to keep that for a more ideal future where Typst has its own package distribution solution instead, which would likely also allow for more flexibility in general.
Anyways, just my two cents :)

What I don't like about the git approach is that:

There's no central place to discover packages: No search, no docs, no autocomplete for packages
There is no guarantee that some package doesn't randomly change or disappear (even if you add a hash, which realistically nobody will do, it can still disappear)
We have to deal with whatever people put into their repositories. The central repository approach allows us to discover potential problems through the PR process and adapt the submission guidelines accordingly. I'm optimistic that the available packages will be easier and safer to use and have better documentation.
To access packages in the web app, it would either need to do cross-origin requests to GitHub (difficult becomes of COEP, could download tons of data) or allow random GitHub downloads through our backend (not a fan)
More difficult to use packages for templates in the template gallery. With the central approach that can simply be configured through a key in the manifest file

In my opinion, the central approach allows for a simpler, safer, and more guided user experience. And good user experience is what Typst is about.

I agree a central repository is better in general, and would solve the problems you mention, but will the Typst team be able (/ have the time) to maintain it properly? Will it scale properly, when the repository starts inevitably accumulating tons of pull requests (as Typst's popularity increases)? That's my main concern, following @alerque's comments.
I'm not entirely sure how to best tackle this right now. However, if the proposal is implemented as is, we must already have in mind a migration plan for when Typst's own package distribution solution (something like crates.io) is inevitably rolled out (which would likely make everything a lot easier, once the initial heavy work is done). Of course, such a change, if it occurs, would come only in the far future, though, as I'm sure it would require having its own team of people working on it all the time (preferably separate from the compiler team).

Packages would be distributed through a REST endpoint. Thus, a migration to a crates.io-like registry would only change the package submission process, not the package retrieval process. It wouldn't break anything, we could simply push all existing packages from GitHub to that new registry and serve the REST API from there. The repository approach obviously won't scale forever, but it can bring a good user experience now (even if the package author experience is not yet ideal).

How about a package monorepo where each submission is a submodule? This has a number of advantages:

It isn't unwieldy to clone the repo as an index - then the tooling only has to check out the requested packages
Development happens in different repositories, so developers get to use their preferred host and don't need every other package in order to develop their own
PRs updating submissions have minimal git churn

I think submodules' git histories are fully navigable?

Regarding packages going away: how to prevent this anyways? As a package author I decide on license and stuff. The chances are high, that there might be packages that would disallow feeding a package manager source from a different golden source.
Or the property and rights on packages and code  would have to be transferred to some foundation or so.
As much as I would like to see stable packages, it might even be an obligation to remove a package (eg a court ruling).

Regarding packages going away: how to prevent this anyways? As a package author I decide on license and stuff.

We will exclusively accept packages with OSI-approved licenses so some sanity ground rules are ensured.

As much as I would like to see stable packages, it might even be an obligation to remove a package (eg a court ruling).

We will not be able to guarantee a package will never be removed. (Could violate any local jurisdictions rules, be harmful to someone, or otherwise in breach of our Terms of Service...) This isn't a block chain. But under normal circumstances, any given version of a package will not be changed or removed once published. Think about it as a convention.

Actually removal could be important. Not for example crates.io also guarantees that published packages won't change, but it does have a yank feature for removing problematic crates.

a yank feature for removing problematic crates.

While I can see how this is useful for rust, I fail to see in which circumstances that could be useful for packages in typst, after all, typst isn't expected (hopefully) to make web queries, etc., therefore, security issues or breaking bugs should not be expected. And for breaking bugs, I'd rather see a warning in the CLI warning me that the version is "not recommended for use" or something similar than see my document break.
I think this is of particular interest in scenarios where you're using automated documentation building pipeline: the pipeline might be five years old, you still expect it to work as the day you set it up.

While I can see how this is useful for rust, I fail to see in which circumstances that could be useful for packages in typst, after all, typst isn't expected (hopefully) to make web queries, etc., therefore, security issues or breaking bugs should not be expected.

While this is true currently this does not resolve issues with sth like malicious images. This would not be a problem with typst itself but rather libraries and a package author including content which utilizes the exploit. I think you want to pull such a package. Not to talk about non technical issues.

I think this is of particular interest in scenarios where you're using automated documentation building pipeline: the pipeline might be five years old, you still expect it to work as the day you set it up.

Agreed. But I also want to trust my build not to have unintended side effect. Not now, nor in five years time. The authors of the tooling I use are not responsible nor have they intended a malicious use case. Unfortunately, in the past, embedded images were an attack vector. And such content would be transportable using packages. Though I am definitely not some who can judge on the real risk of something like this.

The Typst compiler now has package management support on main. You can install packages locally or from the global package repository. The repository and all further details are on https://github.com/typst/packages.
We'd be glad if you'd try creating some packages and experimenting with them locally. If you find any issues, feel free to ping me. We will start accepting submissions to the shared package repository tomorrow. We'll be sure to create a PR template before that.
If everything works out fine, a new release and web app version with package management support will ship within a few days.


Outdated README.md

Command run-clj-csa was removed from makefile in commit hash ad26601

Fixed in https://github.com/ryukzak/course-bot/commit/5d6472889403a6ab54199ff990ccadd16ea5e7bc


fix: add modifying nested struct diagnostic

Add diagnostic for modifying a temporary value type
Description
Added check for if a nested value type is being modified.
Probably not a common issue so I went with a diagnostic.
I considered nested chain assignment or a with expression ie target.NestedValue = target.NestedValue with { StringValue = src.StringValue }; (can repeatedly chain)
Fixes #516
Checklist

[x] The existing code style is followed
[x] The commit message follows our guidelines
[x] Performed a self-review of my code
[x] Hard-to-understand areas of my code are commented
[x] The documentation is updated (as applicable)
[x] Unit tests are added/updated
[x] Integration tests are added/updated (as applicable, especially if feature/bug depends on roslyn or framework version in use)

Sorry, I though I had fixed all of this a week ago. Turns out I forgot to push it 😅

@TimothyMakkison ah yep on a second thought I think that makes sense, that only the second last is checked.

Added CS1612 to error message.
Modified the check to iterate backwards, checking for value type properties. Checking the penultimate member would work if field types didn't exist

Analyzer doesn't like the length of ValidateMappingSpecification. I've extracted the struct method but it's still too long.
Might be a bit controversial but I've temporarily disabled the warning, I'd argue a a long method with simple checks is easier to understand than one method calling 6 simple methods. WDYT?

IMO its okay here to ignore the warning, could you change it to suppressmessage attribute? Often the readability is improved that when reading a method and submethods are called instead of inlined code, code which I'm not interested in reading can be skipped easier.

IMO its okay here to ignore the warning, could you change it to suppressmessage attribute?

Added attribute

Often the readability is improved that when reading a method and submethods are called instead of inlined code, code which I'm not interested in reading can be skipped easier.

Should I extract all the methods?

Nope, should be fine like this, just my general opinion on the topic…


/compile is generating requests to validate id_token.  Why?

I noticed this because it was causing builds to fail when my login token expired.


petitioner and respondent age changes

Two distinct but related questions:

Will the age on the review screen, final form output, etc., advance automatically when we pass a DOB?

Currently testing this. Will know tomorrow.
If it does, what are the implications? This is desired for adult ages (and minors who get a year older but stay minors), but could confuse things for minors turning 18 because it will look like we know they're an adult even though all the minor stuff will still be in play(?)

Should we allow people to affirmatively edit their age?

if we decide to make age editable, also return to #230


Added the ability to tighten TS declarations of machine via generated metadata

https://www.loom.com/share/34bfa23a60f24cd985ea08acaee93b21

Looks like I have some work to do with getting this working on models

@Andarist Where you do you want me to add it? In the PR description?

@Andarist added a deep-dive loom

Huge nit: Can we rename this to TTypeMeta instead of TMeta, as TMeta makes me think this is for the meta property?

@Andarist ideas around how we can infer done.invoke.* events:
https://www.loom.com/share/de46bd18c393411e8c633eb00dfb671d

@Andarist We should extend DoneInvokeEvent so that it takes the name of the service too:
export interface DoneInvokeEvent<TData, TServiceName extends string = never>
  extends EventObject {
  data: TData;
  type: TServiceName extends string ? `done.invoke.${TServiceName}` : any;
}

This work is included in https://github.com/statelyai/xstate/pull/2674


Apply styling to page content

Issue found on privacy and terms pages and beyond:
Apply headings 1-3, paragraph, bolding, italics, bullets, links to the legal page
Prod:

Contentful:

s

 High-priority GitHub issues before launch

This also applies across the site:
Is it possible to apply all the possible stylings in Contentful rather than a select few? Or is this a big lift or lots of effort? What’s involved?
We can also just prioritize those with a star here if needed:
Paragraph or normal text *
Headings level 1-6 *
Bold *
Italics *
Underline *
Code snippet
Hyperlink *
Bulleted list *
Numbered list *
Block quote
Horizontal line *
Table
Embedded entry
Embedded inline entry
Embedded asset

It's a bit of a lift especially with all the other issues to be done, some styling are easier than others to implement (e.g. headings, bold etc.) while others will require more testing and implementation logic (e.g. embedded assets, code snippet etc)
What is the minimum "must-haves" for the launch that our current content requires and start from there for now

Minimum styling applied, new individual issues have been opened for other outstanding styling tweaks to come:
#134 Revise spacing and indent bullets for easier scanability and readability
#138 Review consistency in components with same functionality (ex: links)
#170 Line/paragraph breaks in Contentful not displaying in production (About/Contact/Hiring)
#171 Review padding around headings
#172 Review line spacing for resource H1
#180 Consider consistent H1 styling across site
#181 Lists are dense and can be hard to read - increase spacing around lists
#183 Ordered list - size of numbers does not match size of list item text
#184 Revisit hierarchy styles (H4 is smaller than paragraph text)
#189 When screen is narrow, resource H1 is smaller than body text

This appears to be resolved otherwise. @dylanzheng94 do you agree with closing this issue and keeping an eye on the others listed above?

@anikbrazeau closing this issue as it seems to be resolved & we have a better way to track them in individual issues


Create an eval-only script for existing ckpts

This PR adds scripts/eval.py, which evaluates one or more existing ckpts while bypassing the training steps.
It seems impossible to backfill evals back to the original wandb run, because "step" must always increase. Rewinding the run will truncate the log, which we don't want. Therefore, this script logs things to a new wandb run.
Starting from a training setup:

You can keep using the same yaml file.
Make a copy of the XXX.sh file into XXX-eval.sh, point to scripts/eval.sh, add a flag --wandb.group=XXX to ensure it logs to the same group, and specify --load_path to be either a single ckpt or all ckpts under a directory.
Make a copy of the XXX-launch.sh file into XXX-eval-launch.sh, change --task-name to XXX-eval, and change the command so it runs XXX-eval.sh.

See an example in peteish1-eval.sh and peteish1-eval-launch.sh.

Let me know when this is ready for another review?


how to customise the calendar to highlight current date and is it possible to disable previous dates

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Hello, sorry for the really really late reply. I had finals and I couldn't answer earlier.
Alright, so the highlight current date is a CSS class, you can override that.
The CSS class is cjslib-day-today.
To prevent from going back to old dates, just do this...
#calendarContainer-month-back,
#calendarContainer-month-next,
#calendarContainer-year-next,
#calendarContainer-year-back {
  display: none !important;
}

But people will still be able to click on the days of the next and previous month and switch accordingly.


Fix charmcraft.yaml build-on key

Issue

This PR is meant to fix the release to edge action: https://github.com/canonical/loki-k8s-operator/actions/runs/5891428029/job/16391092265#step:6:61

itest are failing because of this juju bug: https://bugs.launchpad.net/juju/+bug/2030110


Blog added but no progress after clicking crawl

I was able to add the blog and liked by url as well. But when I click Crawl nothing happens. No progress bar or activity. The blog is an NSFW blog and the likes are made visible. But there is no activity on either URl. This is my first time using TumblrThree. I downloaded it, opened the file, click on the name tumblthree which prompted extract. Extracted then clicked on TumblrThee after extraction, and type changed to application. Open the TumblThree window, added my blog to download, clicked Crawl... Nothing. I'm trying to download my own blog and likes. Logged in and added the liked by url. Clicked crawl and again nothing. Please help.

Read the readme on this page! It's explained in detail there..
You need to add a blog from the manager (left side) to the queue (right side), otherwise exactly nothing will happen. Click on a blog in the manager after adding it, then on the button "add to queue" or double click a blog or drag and drop a blog from the manager to the queue.
Please also take a look at the already answered issued. Your answer is there for sure, and it's faster as well then asking it multiple times and waiting for a reply.

Sorry man. Thanks for the reply. My first time using Github, didn't know I could view the closed issues until just now. Thanks again for the reply and help. I will try it again tonight.


Change input label for article doi/data/code/script and set https:// like default value

 Update the text above the field of the DOI/URL of the preprint, data, scripts and codes in the submission form


Ancestry icons don't load properly

Tried this module out today (thank you!) but the ancestry icons don't load for me.
Foundry version: 11 build 308
PF2e version: 5.5.3

Not sure if this is a settings issue on my end or not. The files definitely exist. It seems like the directory isn't accessible though. Any ideas?

The problem is a me problem because I do have both even if one is
deactivated. When I fiddled with the manifest file to rename it I didn't
fiddle with icon paths and I should have. I thought it was using system
defaults. I was wrong.
On Wed, Sep 20, 2023 at 1:05 PM navisayslisten @.***>
wrote:

Tried this module out today (thank you!) but the ancestry icons don't load
for me.
[image: image]
https://user-images.githubusercontent.com/27226232/269361026-21d821ee-0be1-4686-ad2d-4d5094ea6406.png
[image: image]
https://user-images.githubusercontent.com/27226232/269363243-9a79b743-2c47-4bb5-8e80-a659ee03d959.png
Not sure if this is a settings issue on my end or not. The files
definitely exist. It seems like the directory isn't accessible though. Any
ideas?
—
Reply to this email directly, view it on GitHub
https://github.com/Teraunce/pf2e-Extension-Pack/issues/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB4WRIN4WG4IW3MG57JHME3X3MO6DANCNFSM6AAAAAA5AH42O4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
www.freewebs.com/stee1dragon or Teraunce.deviantart.com


Upload all contents under binary folder

Describe what this PR does / why we need it
Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

Also need add the ossurl into release page.


npm start failed with node v6.2.0 and npm v3.8.9

I'm trying to install this quickstart project but I have some errors.
Will be really appreciate if you help solving this.
npm-debug.txt

Weird, I see no hint there of what could be happening.

Forgot to run npm install first...
It is working now.


Improve datetime to string logic to support a wider range of inputs

For Storage packages, most noticeably file-share, all date headers are treated as strings and logic is implemented in the client layer to convert user-provided datetime objects to strings the Storage service will accept. This is because the Storage service expects one more digit of precision in the microseconds than Python provides. This function is used for the conversion.
This function is quite limiting in two ways:

A datetime object must contain all fields (including microseconds) when being constructed for this function to form a properly formed ISO 8601 string that the service will accept. The Python isostring() function will not provide fields that are not specified and therefore appending a 0Z to the end may not always work.
All datetimes are assumed to be UTC since we append Z to the end. This function will not work if another timezone is provided. This may be okay since the service expects only UTC values but another option would be to support other timezones and convert them to UTC before sending. Or we could throw an exception if a customer tries to use some other timezone rather than the customer just getting a service error.

Likely we can try something like msrest does or possibly even contribute to it to optionally add an extra digit of prevision and then just use it.

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Storage:0.5799338,Azure.Core:0.20338458,Service Bus:0.0190688'

Pending change to autorest: https://github.com/Azure/autorest.python/issues/1588

FYI: This was fixed with #34041


upgrade go to 1.18

Mention this PR: https://github.com/privacy-scaling-explorations/zkevm-circuits/issues/904

update to 1.19


Add django-enable cli utility

Description
Add CLI utility for easier usage
References
Fix #20
Checklist

[x] I have read the contribution guide
[x] Code lint checked via inv lint
[x] changes file included (see docs)
[x] Usage documentation added in case of new features
[x] Tests added

Pull Request Test Coverage Report for Build 446603580

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 97.987%

Totals

Change from base Build 435545326:
0.1%

Covered Lines:
208

Relevant Lines:
210

💛  - Coveralls


fix #2734

Codecov Report

Merging #2752 into dev will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##              dev    #2752      +/-   ##
==========================================
+ Coverage   94.28%   94.28%   +<.01%
==========================================
  Files         166      166
  Lines       19900    19906       +6
==========================================
+ Hits        18763    18769       +6
  Misses       1137     1137

Impacted Files
Coverage Δ

...ita_db/metadata_template/base_metadata_template.py
95.36% <100%> (ø)
:arrow_up:

qiita_db/artifact.py
98.32% <100%> (+0.02%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32a0e17...72ba2dc. Read the comment docs.


Api doc- badge not readable

Tiny display bug on https://lisk.io/documentation/lisk-core/api-mainnet.html, the badge is not readable on mobile, as seen below

I checked on desktop, the issue is present too.

Should be fixed now :)

Lol that's a dirty fix! We can still see the borders (because of inset shadow I believe) and the corners.


BLE communication speed is random. (IDFGH-8738)

I created a loop below the BLE GATTS server example and executed esp_ble_gatts_send_indicate every 100mS.
Each time the power is turned on or the ESP is reset, the communication speed seems to change.
When communication is good, data is received relatively evenly every 100mS to the Android phone.
When communication is unstable, 100~500mS randomly comes in. At this time, there is a phenomenon that packets that have not been transmitted before are received at the same time.
It's not a problem with the connection process, but the performance is different every time the power is turned on or reset. In both cases, the logo is the same, so I can't find a difference.

BLE's communication mechanism is based on connection intervals, Every connection interval, the matser will initiate a packet, and then the slave will reply to a packet. If who have data to be transferred, then the PDU will be carried.
Therefore, the communication rate and delay, mainly depends on these aspects:

connection parameters, longer connection interval can slow down the communication rate, and different phones have different default connection parameters
MTU size, If the MTU is too small, the long packet will be divided and sent multiple times
Is there 2.4G wireless interference？ otherwise there will be too much retransmission

BLE's communication mechanism is based on connection intervals, Every connection interval, the matser will initiate a packet, and then the slave will reply to a packet. If who have data to be transferred, then the PDU will be carried.
Therefore, the communication rate and delay, mainly depends on these aspects:

connection parameters, longer connection interval can slow down the communication rate, and different phones have different default connection parameters
MTU size, If the MTU is too small, the long packet will be divided and sent multiple times
The data sent by the ESP32 is currently less than 10 bytes for testing purposes. The problem occurs regardless of the MTU size.
Is there 2.4G wireless interference？ otherwise there will be too much retransmission
Yes. There is 2.4G wireless interference. However, if you reset it when things go wrong, communication may work well. It has nothing to do with whether or not pairing is reconnected, and when it works perfectly, if you reset it, the performance will drop again afterwards. When performance is slow, pairing also doesn't work well, logo says "lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)"
RF calibration is fully calibrated every time. There may be a problem with the calibration process.

Could you make this change and test it again:

Update connection params(conn interval: 12, latency: 0, timeout: 400)  after the connection has been established. Use the API:

esp_err_t esp_ble_gap_update_conn_params(esp_ble_conn_update_params_t *params);

Add a flow control mechanism to send indicate
After sending a indicate package, wait until the confirm event (ESP_GATTS_CONF_EVT) comes back before sending the next package.

If the above two methods can not be improved, I hope to get your test code, I need to test it locally.

https://github.com/hyojincha/test/tree/master
Uploaded the test code to the URL.
ESP32 module is ESP32-WROOM-32D. and The board is self-made.
Please confirm operation. Thank you.

I used the ESP32-WROOM-32 and ESP32-WROVER-E test the sample code you provided.
The APP is also provided by you, I tested it more than one hundred times, and it came up only one time，In this fail case, I did not capture the connection request from the phone. It is possible that the air hit the bag.
What was the failure rate in your tests?


Eliminate nest.flatten() call in _filtered_call

Redundant, following nest.flatten() in _convert_numpy_outputs.
Note: PR not ready for merge yet, submitted for @sun51 and @kkimdev to check progress
Edit: In review

Benchmarks - mean & [median of means] of 10 trials with 30000 iters each:
defun_matmul: 185/184 us -> 171/167
defun_matmul_async: 93/92 us -> 89/88 us
defun_matmul_with_signature: 198/193 us -> 189/184 us

Pending tests passing, the last step would be to fix relevant aspects of tensorflow/python/autograph/g3doc/reference/error_handling.md

Last step is to fix relevant parts of tensorflow/python/autograph/g3doc/reference/error_handling.md


chore(scripts): remove unused autodoc/admin-api scripts

Summary
Our Docs team generates the admin-api docs using a different method now, this is dead code.
Checklist

[x] The Pull Request has tests (na)
[x] There's an entry in the CHANGELOG (na)
[x] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com (na)

Putting this in Draft state until we have confirmation from our Docs team that this is no longer needed.


Replace uses of breadth with dpi in the thumbnail action.

Fixes #2.

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Problem with trainning in levi_graph mode

Hi han,
i followed your steps to train the model using levi graph for several times.But they all lead to the warning, which the specific content is "arc_loss = *** exploded! please retrain **". Could you give me some advice to advoid this situation or i just need retrain for several times?
Thank you !

Hi,
Yes, you just need to retrain for another time whenever you see this warning. Sometimes the loss exceeds a large threshold and the resulted model performs significantly worse on the dev set. I don't have time to debug into the codes as lots of thirdparty codes are involved. So don't waste time to continue training if you see the warning.

Hi han，
thanks for your prompt response!I will follow your advice to retrain the model.
Hope you have a nice day!


Prepare "networks:" and "links:" for ddev v1.19

The New Solution/Problem/Issue/Bug:
For ddev v1.19 we'll have to update services that need to be reachable or reach the router or inter-project services.
How this PR Solves The Problem:
This removes superfluous links: and adds networks: [ default, ddev ] were inter-project communication is necessary.
Related Issue Link(s):
https://github.com/drud/ddev/pull/3403

This was not meant to be pulled before ddev 1.19 is out.
Oh, is https://github.com/drud/ddev/blob/master/pkg/servicetest/testdata/TestServices/docker-compose.solr.yaml linked somewhere in the docs? I think we could say this is not meant to be used before 1.19.
I also thought about how to make ddev projects "ready" for v1.19 without breaking v1.18 but have not come up with a good idea.
I am back to work since today and I'll monitor discord/Slack now again and try to support. Also watching ddev issues/pulls.

rebased and added networks: [default, ddev_default] to ALL services.

It may still be a month or more before ready, but thanks for maintaining this! I still hope to get support for postgres into this release.

We don't have to do this any more since ddev now adds the networks stanza, closing.

And thanks for all your work on this!


Minor roads

Add minor and service roads.

Minor roads (unclassified & residential) are introduced at z12 slightly smaller than tertiary.
Service roads are broken into two classes:

Plain service and service=alley. (introduced at z=13)
service=driveway and service=parking_aisle (Smaller, introduced at z15)

All 3 layers use the same minZoomFill of 16 as does tertiary, so that tertiary on down switch to fill at the same time.

Very nice!
Can do something about the street names so they are more readable? Maybe thicker casing or font, change of color?

@Mashin6, Do you mean changing the street names for minor/service roads? At particular zooms? Or all road labels?
If just minor roads, then it might make sense to keep using the offsetLabelStyle instead of switching to the centerLabelStyle at z17 since even with fill, these lines are very narrow.

@adamfranco I originally meant it for the your screenshot example. The street name labels get criss-crossed by the minor roads and because the font has the same color and also thickness I can barely read some of them. But since this problem is also caused by overlapping with secondary/ tertiary roads to some degree, it seems it might be better as a separate PR.

I've improved the differentiation between minor/residential and service roads (as well as big and small) by fixing the color on zoom. Need a re-review so that this can be merged. :-)


[Feature Request]  Ability to see DB config in UI.

Currently, you have to hit the api at /v2-beta/settings  and search through JSON. This can be time consuming.

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


Read more from pty

Resolves an issue with partial draws where programs like vim would send
data, but only part of it would be drawn.
The logic for escaping when a write is pending has been removed in favor
of limiting bytes processed during a pty_read call.
The value of MAX_READ may not be ideal.
cc #598

Works well. Nothing to complain about since 3 days as my daily driver.

Going to merge this and see if anyone makes noise ;). Thanks for testing @lord-re!

@jwilm this is great, feels faster too


Pub: Get Dependencies does not work for version 1.0.0-rc.1

Hi,
I am following the documentation for set the dependecies on pubspec.yaml:
https://github.com/dart-lang/polymer-dart/tree/1.0.0-rc.1
environment:
sdk: '>=1.0.0 <2.0.0'
dependencies:
browser: '>=0.10.0 <0.11.0'
polymer: '1.0.0-rc.1'
transformers:

polymer:
entry_points:

web/index.html

reflectable:
entry_points:

web/index.dart

I am using the WebStorm 11 EAP.
Occur this error:
Working dir: D:\Users\Administrador\WebstormProjects\testPolymer
C:\dart-sdk\bin\pub.bat get
Resolving dependencies...
Package polymer has no versions that match 1.0.0-rc.1 derived from:

testPolymer depends on version 1.0.0-rc.1
Process finished with exit code 1

Am I doing  something wrong?

This might help http://stackoverflow.com/questions/32242736/import-and-make-use-of-polymer-dart-0-17-dev-preview

The official release candidate has not yet been released, so you need to use a git dependency in the meantime:
dependencies:
browser: '>=0.10.0 <0.11.0'
polymer:
  git:
    url: git@github.com:dart-lang/polymer-dart.git
    ref: 1.0.0-rc.1


Camaleon documentation broken

Something seems to be broken here... http://camaleon.tuzitio.com/group/40747-documentation.html/
:(

Fixed!, thank you for the report.
I migrated to other server with better features.


Killed my dog, his name was Spot.

My dog is a programmer. Sorry, was a programmer. He tried to create a fork of nocode and died in the process due to circumstances beyond his control, which I don't even understand. How do I seek compensation?
BTW, I haven't had a dog in years and I'm trying to figure out how I got a dog and why his name was Spot (he's completely black). Can anyone help me figure this out? I didn't use any pills or drink anything from any bottles...

yes

cool

Great


Fill out untested gaps for Wasabi

@MaxHillebrand thank you for the review and especially for the link to the issue with the Wasabi RBF discussion---it's valuable to us RBF advocates to learn why people are reluctant to use RBF and there are several points in that discussion that I think are outdated or which could be addressed by data we can fairly easily collect.  I'll comment over on that issue later today.  Thanks!

@nopara73 @MaxHillebrand I pushed a commit to explain how the testing was done. Also updated the tested on date. Let me know if it looks good to you guys!

Let me know if it looks good to you guys!

LGTM

I've squashed commits. ACK 5416eb9c1ecdfcc57a260cb3dadc794b51d2d229


Add testbench support for GCS+gRPC

I will work on this feature by extending Python client to support GCS+gRPC with a different endpoint ( /grpc ).
The changes will be:

Change GrpcClient to work with different endpoint when testing with testbench.
Add /grpc endpoint to testbench.
Add test for existing RPCs like CreateBucket()

cc @coryan

@coryan
Some updates:
HybridClient is now passing integration test. I am using grpc_integration_test with this env set to media
https://github.com/googleapis/google-cloud-cpp/blob/70e507792b0edd06c05efd4dc2f32cc9ff46d888/google/cloud/storage/tests/grpc_integration_test.cc#L55
Because it is a large project, I have created a new repository for it https://github.com/vnvo2409/gcs-testbench
I have some questions:

Is it possible if I turn this project into a pip package and google-cloud-cpp will use it instead of the current testbench ? Because there isn't an offical emulator for gcs that supports both grpc and rest, we could extend this project and I think there will be many projects find this emulator useful.

Are all the integration tests inside google/cloud/storage/tests/ ?

Some updates:
HybridClient is now passing integration test. I am using grpc_integration_test with this env set to media
https://github.com/googleapis/google-cloud-cpp/blob/70e507792b0edd06c05efd4dc2f32cc9ff46d888/google/cloud/storage/tests/grpc_integration_test.cc#L55

Really cool, thanks!

Because it is a large project, I have created a new repository for it https://github.com/vnvo2409/gcs-testbench

Please remember to include the right license and copyright notices in this code. The majority of that code is owned by Google, and the License requires that you reproduce the Copyright notice in any copies of the code:
https://github.com/googleapis/google-cloud-cpp/blob/8d878749ec893b2005e2117a182d4386d30daac5/LICENSE#L89-L128

I have some questions:

Is it possible if I turn this project into a pip package and google-cloud-cpp will use it instead of the current testbench ? Because there isn't an offical emulator for gcs that supports both grpc and rest, we could extend this project and I think there will be many projects find this emulator useful.

There may be some interest in doing that, let's ask @frankyn if he can suggest a repository to host the testbench separately.

Are all the integration tests inside google/cloud/storage/tests/ ?

There are also examples (in google/cloud/storage/examples/), which may use slightly different code paths to access the testbench.

if we make it into a long term project, I will consider switching to Go since there are libraries allow us to run http and grpc in the same port

@coryan
Any update about hosting the testbench as separate repository ?

I got 30/32 integration tests passed.

error_injection_integration_test always throws Aborting because exceptions are disabled: send() has not been called yet.
thread_integration_test.ReuseConnections fails. I think the reason is using flask without gunicorn but I am not sure.

Since I didn't follow the current testbench strictly, the new testbench is not perfect. It will need more improvements and I will tell you when it is ready to use.

Thanks for the update!
ReuseConnections may be failing because the server (or testbench) is closing the connections before they can be reused, maybe this needs to become a test we only run against production.
error_injection_integration_test could be the test itself.  It performs all kinds of ~dirty tricks~cool stuff to return -1 from the C library functions at exactly the right time.  The sequence of calls might be different with flask-only and could need adjustment.

A quick question about googleapis
When we send a POST request to get the resumable session URI, it will always return 200 even if the generation's conditions aren't correct. This issue is already 5 years old https://github.com/googleapis/google-cloud-java/issues/201. GCS REST appends the query parameters to the location and only check for the generation's conditions when upload is done ( we have to use full location resumable_session_id for anything related to resumable upload instead of just upload_id indeed ).

How is GCS gRPC's behavior ?
Is there any reason to keep the current GCS REST's behavior ? IMO, checking those conditions in the first place is more reasonable.

GCS REST appends the query parameters to the location and only check for the generation's conditions when upload is done ( we have to use full location resumable_session_id for anything related to resumable upload instead of just upload_id indeed ).

How is GCS gRPC's behavior ?

I expect that GCS+gRPC will also (a) return OK when the upload is started, regardless of the pre-conditions, (b) save the preconditions on the server side, maybe encoded in the upload id too (say base64 encoded), and (c) will check them at the end.

Is there any reason to keep the current GCS REST's behavior ?

Yes.

IMO, checking those conditions in the first place is more reasonable.

I do not see how that would work.  Consider ifGeneration==0 and two simultaneous uploads, only one of them should succeed so the conditions need to be checked at the end of the upload.  More generally, checking the pre-conditions and taking the action that changes them should be an atomic operation, and that can only be done at the end of the upload.

The new testbench is almost done. My questions:

The PR will be quite large. Is it ok or I have to do something else ?
How to deal with protobuf generated python files ? It is particularly hard because they will break the import path if we don't place them in the right place.

Can you tell me what is "quite large"? How many lines of changes? If it is over 500 lines it might be best to split it, maybe one PR to introduce the gRPC components (without using them at first). Would it be possible to then split even further, say one that uses gRPC for buckets (but nothing else) and then another for objects? Or maybe something along those lines, you would know better what is a good split.

The testbench has been rewritten from scratch, mainly to keep the compatibility between REST and GRPC. Here is the philosophy behind the testbench:

Pass request (protobuf message, flask.request, FakeRequest) around and only extract the information when need. It allows us to have a common, short function definition for both Rest and gRPC ( something like update(flask.request) / update(request_message) instead of update(flask.request.args.get(...)) / update(request_message.if_match_generation) ).
The backend uses protobuf instead of dict.
Most functions have a variable context.  It allow us to abort the server without raising an error. (gRPC: context.abort, REST: abort ). I also use context to distinguish between gRPC ( context is not None ) and REST.
__init__ has no side-effect. I have several init_* to construct the class based on the input request. It is useful if we want to save the data to hard driver and load it back after.
Break utils into smaller files. Database operations should not be imported into gcs_bucket, gcs_object, ... It ensures that we don't have circular dependency. ( Database should know about the type of gcs_bucket, ... )
The testbench is fully-compatible with gRPC and REST. New gRPC methods should work just by passing the request into the corresponding funcitons.

You could take a look here https://github.com/vnvo2409/gcs-testbench/tree/refactor. I haven't done the cleanup yet but It could give you a general idea about what I am doing. ( server/rest_server.py, server/grpc_server.py, common/gcs_bucket.py, common/gcs_object.py ). I could break it into PRs. But it is completely unreleated to the old testbench so I am not sure it is the right way.

Please remind me: are these generated on the fly by the build system or do we need to commit them to the code? Can we install them via pip?

These files are used by the testbench so it could be either generated on the fly or commit them to the code. But I think commit them to the code will be much easier. About the pip, I can't find any package but I think you could ask internally about it. pip is the best way of course.

Can you tell me what is "quite large"? How many lines of changes? If it is over 500 lines it might be best to split it,

You could take a look here https://github.com/vnvo2409/gcs-testbench/tree/refactor.

Looks like over 2,900 lines of changes, definitely we need to split this in several PRs.

The testbench has been rewritten from scratch, mainly to keep the compatibility between REST and GRPC. Here is the philosophy behind the testbench:

Pass request (protobuf message, flask.request, FakeRequest) around and only extract the information when need. It allows us to have a common, short function definition for both Rest and gRPC ( something like update(flask.request) / update(request_message) instead of update(flask.request.args.get(...)) / update(request_message.if_match_generation) ).

Okay, that sounds sensible, but I guess pushes complexity into the update thing as it needs to deal with different request types.

The backend uses protobuf instead of dict.

SGTM.

Most functions have a variable context.  It allow us to abort the server without raising an error. (gRPC: context.abort, REST: abort ). I also use context to distinguish between gRPC ( context is not None ) and REST.

SGTM too.  Maybe this is a good start can you create a PR to make this change to most functions?  This is just a suggestion, you would know better how to start the changes.

__init__ has no side-effect. I have several init_* to construct the class based on the input request. It is useful if we want to save the data to hard driver and load it back after.

Break utils into smaller files. Database operations should not be imported into gcs_bucket, gcs_object, ... It ensures that we don't have circular dependency. ( Database should know about the type of gcs_bucket, ... )

That SGTM also.  Maybe another good place to start.

The testbench is fully-compatible with gRPC and REST. New gRPC methods should work just by passing the request into the corresponding funcitons.

I could break it into PRs. But it is completely unrelated to the old testbench so I am not sure it is the right way.

Well, one way to do it is to:

Start a new directory for the new testbench, testbench/grpc or testbench-grpc are my suggestions.
Implement the testbench in this directory in a series of PRs, think about 200-400 lines of code for each new one, avoid anything over 500.
Once completed, change one of the build scripts to use this new testbench, it may require several iterations of fixing the new testbench and/or the scripts.
Once it is working, change all the scripts to use the new testbench.
Then remove the old one.
Then (if we want to) rename the new one to simply testbench.

Please remind me: are these generated on the fly by the build system or do we need to commit them to the code? Can we install them via pip?

These files are used by the testbench so it could be either generated on the fly or commit them to the code. But I think commit them to the code will be much easier. About the pip, I can't find any package but I think you could ask internally about it. pip is the best way of course.

We are trying to enable at least one build to run against production using gRPC. That requires disabling a few tests here and there because production has gaps between gRPC and REST. I think this is orthogonal to your changes.

This test for example.
https://github.com/googleapis/google-cloud-cpp/blob/387409c5cb0be9036526911daa79242f951fd7a2/google/cloud/storage/tests/object_integration_test.cc#L806-L810
To me, UsingGrpc() will always return false because we don't set any environment variable at all. I think the if is no-op ?

That is true for most builds, but we are preparing a build that will set GOOGLE_CLOUD_CPP_STORAGE_GRPC_CONFIG, in that case UsingGrpc() will return true.  We may have to change the code to something like:
// TODO(#...) - production does not support DeleteResumableUpload() yet.
if (!UsingTestbench() && UsingGrpc()) GTEST_SKIP();

Or maybe we get to remove the code.

A series of PRs will take some time to complete. I think it will finish by October.

These files are used by the testbench so it could be either generated on the fly or commit them to the code. But I think commit them to the code will be much easier. About the pip, I can't find any package but I think you could ask internally about it. pip is the best way of course.

How about the generated file ?

A series of PRs will take some time to complete. I think it will finish by October.

These files are used by the testbench so it could be either generated on the fly or commit them to the code. But I think commit them to the code will be much easier. About the pip, I can't find any package but I think you could ask internally about it. pip is the best way of course.

How about the generated files ?

Trying to find if there are any.  I would prefer to generate them on the fly over committing them, and I would prefer to use pip over generating them.


waypoint delete all should clean up the use-waypoint annotation?

Describe the feature request
While enroll-namespace adds the use-waypoint annotation, delete all waypoint in the namespace doesn't clean the annotation up. Should we clean the annotation for user?
./istioctl x waypoint delete --all
waypoint default/waypoint deleted
 ~/Downloads/istio-dev/ k get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    istio.io/use-waypoint: waypoint
  creationTimestamp: "2024-04-04T18:13:55Z"
  labels:
    istio.io/dataplane-mode: ambient
    kubernetes.io/metadata.name: default
  name: default
  resourceVersion: "377263"
  uid: 5d6f54ab-bf56-41d1-81bc-83a349357450
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Alternative is to ask users to run $ kubectl annotate namespace default istio.io/use-waypoint-
Describe alternatives you've considered
Affected product area (please put an X in all that apply)
[x ] Ambient
[ ] Docs
[ ] Dual Stack
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

cc @MorrisLaw

For consistency with enrolling maybe error if they have it (or warn, but error might be safer) and have a flag to do it automatically?

For consistency with enrolling maybe error if they have it (or warn, but error might be safer) and have a flag to do it automatically?

@howardjohn, tbc... is your suggestion to error on the delete --all command and in addition provide some flag to delete waypoint? Or is your suggestion in the context of the --enroll-namespace command?

I think we should:

Warn or error if they have references to it
Maybe allow a flag to --unenroll

FWIW I think automating it is Hard to do for all cases. It can be labelled on a pod, and that is almost always controlled by a higher level object.


Fix for autocomplete fields SCRUM-1228

Oh weird ok...

Oh weird ok...

Ya, that's an unfortunate side-effect of enabling retriggering tests for PR that get their base branch changes (the only way is triggering on all updates and skip tests when the base branch wasn't changed)


Headers returned in get_vary_cache_on not present in Vary header

Summary
Returning a custom header in get_vary_cache_on does not result in that header being added to the response's Vary header.
Expected behaviour
The Vary header should also contain headers returned by get_vary_cache_on.
Actual behaviour
The Vary header does not contain headers returned by get_vary_cache_on.
Example
I've written a simple plugin displaying child plugins only when a custom Store-Id header matches a certain value (simplifed):
from cms.models.pluginmodel import CMSPlugin
from cms.plugin_base import CMSPluginBase
from cms.plugin_pool import plugin_pool
from django.utils.translation import ugettext_lazy as _

class StoreDependentContentPluginPublisher(CMSPluginBase):
    model = CMSPlugin
    module = _('Control')
    name = _('Store Dependent Content')
    render_template = 'acme_catalog/plugins/store_dependent_content.html'
    allow_children = True
    cache = True

    def get_vary_cache_on(self, request, instance, placeholder):
        return ['Store-Id']

    def get_cache_expiration(self, request, instance, placeholder):
        return 600

    def render(self, context, instance, placeholder):
        context = super().render(context, instance, placeholder)
        store_id = context['request'].META.get('HTTP_STORE_ID')
        context['show_content'] = store_id == 'foobar'
        return context

plugin_pool.register_plugin(StoreDependentContentPluginPublisher)

{% load cms_tags %}
{% if show_content %}
  {% for child in instance.child_plugin_instances %}
    {% render_plugin child %}
  {% endfor %}
{% endif %}

Requesting a page with this plugin containing a simple heading, using Store-Id: foobar:
λ ~/ curl -s -H "Store-Id: foobar" URL | grep 'Welcome'

Welcome to foobar!

Requesting a page with this plugin containing a simple heading, using Store-Id: barfoo after waiting CACHE_MIDDLEWARE_SECONDS:
λ ~/ curl -sk -H "Store-Id: barfoo" URL | grep 'Welcome'

So it basically works as intended. But sending the second request right after the first one yields the same result (as it is cached).
Furthermore, the Vary header does not contain Store-Id:
λ ~/ curl -Is URL
HTTP/2 200
cache-control: max-age=10
content-language: de
content-type: text/html; charset=utf-8
date: Wed, 16 May 2018 07:55:34 GMT
expires: Wed, 16 May 2018 07:55:44 GMT
server: WSGIServer/0.2 CPython/3.6.3
vary: Accept-Language, Cookie
x-frame-options: SAMEORIGIN
x-robots-tag: noindex, nofollow
content-length: 41697

Environment

Python version: 3.6
Django version: 1.11.12
django CMS version: 3.5.2
(relevant) bits of settings.py:

CACHES = {
    'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
    'LOCATION': os.environ['ACME_CACHE_LOCATION'],
}
CACHE_MIDDLEWARE_SECONDS = 10
# no other CACHE-settings

Is this functionality working at all?
I also tried installing cmsplugin-header-control
but the cms does not seem to do anything with the value returned by get_vary_cache_on

any workaround for cms plugins?


build: require swift 6 toolchain

Since we require swift 6 anyway, we should reflect this in the
package.swift so it's more obvious when using an older swift to attempt
to build.

Since we require Swift 6 anyway, make it so explicitly in the build.


IngestionAnomalyAlert

Fixes #
Proposed Changes

@iwafula025 - Images are not rendering on README.MD. Please correct it

Fixed image upload


Fix TextBlock TextAlignment issues when a HorizontalAlignment is defined

What does the pull request do?

This PR makes sure the TextBlock is always measured with an infinite width and only aligns it to finite space in the arranging step.
What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

[x] Added unit tests (if possible)?
[x] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

Fixes: #17396
Might fix: #17376

Add some render tests that is covering most measure / arrange scenarios

This bug is blocker for us as the Ribbon is messed up for every textblock. Is there any date for the next release ?

And this should be considered as backport to 11.2.x :)


Filter patients whose second dose is overdue

Ability to use a toggle filter to query and fetch all patients who have missed their second shot and are overdue for the second dosage of the vaccine.
Screenshot attached. This should only return results of all patient who have an  overdue status without the need to search

Some assumptions

Create a new patient on the registration page
Go to the profile page to record the first dose of the vaccine
On record first dose, use current date as a start date when you received the 1st shot
We shall use a 3-week window as the due date of the 2nd shot
On load patient list, if within the range before due date, show the user when you are due for the next shot, else show overdue status
Inpatient profile show when you were supposed to have received the 2nd shot - see screenshot. Label marked in red if overdue

Added some QA check on this issue #195 cc @syedowaisali90

it the case of covax it's not really overdue, but eligible, the restriction is more to not get the 2nd shot too early

What's window of duration should we use as a trigger ? e.g. 3 weeks cc.@pld

We want to configure that with a fhir resource, we could hardcore 5 weeks for now but in reality it'll depend on the vaccine

On Jun 4, 2021, at 14:43, Francis Odhiambo Otieno @.> wrote:

What's window of duration should we use as a trigger ? e.g. 3 weeks @.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Need to cherry-pick from this branch to close this issue, https://github.com/opensrp/fhircore/pull/240

This implementation will need to be redone as it does not cater for dynamic editing of resources i.e it sets initial values against each question explicitly as opposed to doing it dynamically for each and every question , which would best require writing code only once based on @MuhammadSalman-7214 PR here https://github.com/google/android-fhir/pull/536
cc @pld @MuhammadSalman-7214 @ekigamba

cc @ndegwamartin

This feature is missing on the main branch


Addresses four compaction service follow on issues.

While waiting for #1632 to be reviewed  I completed multiple follow on issues for the new compaction service.  I am submitting those as a single PR, but there is a commit for each. I can break them into multiple PRs if desired.

I would like @EdColeman to take a look at the metrics you added for compaction.  I will look over the other commits

Looking at the metrics generated by CompactionExecutorsMetrics.
My initial concern was that there could be cardinality issues if the metrics names are unbounded - that does not seem to be an issue.  Using the current code in your branch, I quickly added a delay in the FateConcurrencyIT test that forces a pause while a compaction FATE transaction is running so that the metrics system has time to write records to the test output file.  The generated record for the IT test tserver looks like:
1596645249079 tserver.compactionExecutors: Context=tserver, ProcessName=TabletServer, Hostname=ip-xxx-xxx-xxx-xxx, default_large_queued=0, default_large_running=0, default_medium_queued=0, default_medium_running=0, default_small_queued=0, default_small_running=0, meta_huge_queued=0, meta_huge_running=0, meta_small_queued=0, meta_small_running=0, root_small_queued=0, root_small_running=0, root_huge_queued=0, root_huge_running=0, default_any_queued=0, default_any_running=1
This looks good, but why is default_any_running=1 but nothing in default large, medium or small?  Is default_any a separate queue, or should it be the sum of all default_any_ ?
With this forced test, I know the FATE transaction is "IN_PROGRESS"  - it uses a slow compaction runner that pauses 250ms in the iterator before each next() call - could that be changing the "running" to something where the thread is paused and that does not count as "running"
Before digging I just want to validate that my assumptions w.r.t the names is accurate.

This looks good, but why is default_any_running=1 but nothing in default large, medium or small? Is default_any a separate queue, or should it be the sum of all default_any_ ?

@EdColeman do you still have the source for the test that emitted these metrics?  I would like to see the compaction config used in the test.

Not source code as such - the configuration would have been the defaults.
What I do is hack one of the IT tests that use the slow compaction runner and then just insert a hard Thread.sleep(xxx) - I usually let the test fail because of timeout, so I have as much time as possible for things to report.
One candidate would be in org.apache.accumulo.test.functional.FateConcurrencyIT.multipleCompactions() at line 496 - right before the compactions are cancelled.  The test starts 4 compactions with a slow iterator so there's plenty of time to have metrics reported.
When the test is running, you can use jconsole to examine jmx - or use the metric file output - with this the should be multiple metrics measurements.  You may need to adjust the metrics config so that the metrics files are written - they will end up in the target directory of the ITs.

@EdColeman @milleruntime @ctubbsii I would like to merge this before it ends up w/ conflicts.  I think I addressed all comments.  Did I miss anything or where there any other questions?

From what I had looked at, you answered the concerns that I had.  It seemed like you were going to try to manually examine the metrics emitted, do you have a chance?  More out of curiosity, I'm not suggesting that it needs to hold this up.

Since this branch has been sitting for a while, locally I merged this branch to main and reran all ITs matching CompactionIT*.  The test were all a success.


Arming UI improvements

Change arming button to a toggle instead of two buttons.
Have a confirmation modal that prevents accidental presses.
Show arming status. (Potentially separate drone status and waypoint creation into two different tabs)

closed after preview merged in. re-open new issue for new arrming UI implementations.


Flex with minimum size

I am upgrading from version 2.
The following settings result in 3 areas but the dividers do not work to resize the panes.
    _controller.areas = [
      Area(data: _randomColor(), size: 600, min: 100),
      Area(data: _randomColor(), size: 150, min: 100, max: 400),
      Area(data: _randomColor(), size: 150, min: 100),
    ];

If I add in a flex area, now the dividers act to resize. The size areas obey the min and max settings. But I cannot set a minimum size for the flex area. Adding min or max to the flex area has no effect.
    _controller.areas = [
      Area(data: _randomColor(), size: 600, min: 100),
      Area(data: _randomColor(), flex: 1 ),
      Area(data: _randomColor(), size: 150, min: 100, max: 400),
      Area(data: _randomColor(), size: 150, min: 100),
    ];

What am I doing wrong? How do I set a minimum size for a flex area?

Hi @AtlasAutocode!
The size(pixel) and flex are independent. The flex is applied to the space not used by "size". So in your example, it isn't working because you only have one flex area.

The problem is that if I don't include a flex then resizing does not work. The dividers do not work.
3 'size' areas => no resizing, moving the divider has no effect. Areas are frozen and cannot be adjusted with the divider.
If I add 1 flex then I get resizing of all 4 areas using the divider - but I then cannot set a minimum size for the flex area.
My app needs 3 'size' areas that have a min size - how can I get the dividers to work?
Yes, I understand that the min in flex is flex but I still need to set the minimum size in pixels. Are you saying that every time the main window changes size, I have to recalculate the min flex?
I think resizing should work with 3 size areas.

I used your configuration in the committed example, and it works as expected: fixed sizes in pixels will not allow resizing depending on the size of your window and whether it has already reached a limit (max or min). Pay attention to the max limit too, for one area to shrink, the other has to stretch.
The flex is in proportion to the window size like Column/Row. Min follows the same rule. It cannot be in pixels.
If you want to adjust the min flex based on pixels, you will have to adjust the calculation using a LayoutBuilder to know the size of the window. Remember that flex uses the window size by first removing the fixed pixels used. What is left is used in the value of your factors. This flex and pixel scenario can generate inconsistencies, these are handled when they occur (you can see the demo). Example: you define 2 areas with 500 pixels each but your window is smaller.
It seems strange to me that you use all areas in pixels because the window can resize. The pixel is most useful for pinning a single area, such as a side menu.
For now, there is no way to set the flex min in pixels. It's either flex or sized (pixels).

If it were possible to define the min in pixels for the flex area, there would have to be 2 options. Like minFlex and minPixels. But perhaps it generates new inconsistencies.

Version 2 did allow defining 3 areas whose starting size could be set with min and max values.
All 3 areas could be resized, and min size was followed.
It sounds like version 3 has changed to use size areas as fixed (not resizable) areas and min/max are ignored.
That is disappointing.

Sized areas are resizable as long as there is space for it in the window. You may have a problem in your code or the window does not have enough space.

With your configuration:
import 'dart:math';

import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:multi_split_view/multi_split_view.dart';

void main() => runApp(const MultiSplitViewExampleApp());

class MultiSplitViewExampleApp extends StatelessWidget {
  const MultiSplitViewExampleApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MultiSplitViewExample(),
    );
  }
}

class MultiSplitViewExample extends StatefulWidget {
  const MultiSplitViewExample({Key? key}) : super(key: key);

  @override
  MultiSplitViewExampleState createState() => MultiSplitViewExampleState();
}

class MultiSplitViewExampleState extends State<MultiSplitViewExample> {
  final MultiSplitViewController _controller = MultiSplitViewController();

  bool _pushDividers = false;

  @override
  void initState() {
    super.initState();
    _controller.areas = [
      Area(data: _randomColor(), size: 600, min: 100),
      Area(data: _randomColor(), size: 150, min: 100, max: 400),
      Area(data: _randomColor(), size: 150, min: 100)
    ];
    _controller.addListener(_rebuild);
  }

  @override
  void dispose() {
    super.dispose();
    _controller.removeListener(_rebuild);
  }

  void _rebuild() {
    setState(() {
      // rebuild to update empty text and buttons
    });
  }

  @override
  Widget build(BuildContext context) {
    Widget buttons = Container(
        color: Colors.white,
        padding: const EdgeInsets.all(8),
        child: Wrap(
            crossAxisAlignment: WrapCrossAlignment.center,
            spacing: 10,
            runSpacing: 10,
            children: [
              ElevatedButton(
                  onPressed: _onAddFlexButtonClick,
                  child: const Text('Add flex')),
              ElevatedButton(
                  onPressed: _onAddSizeButtonClick,
                  child: const Text('Add size')),
              ElevatedButton(
                  onPressed: _controller.areasCount != 0
                      ? _onRemoveFirstButtonClick
                      : null,
                  child: const Text('Remove first')),
              Checkbox(
                  value: _pushDividers,
                  onChanged: (newValue) => setState(() {
                        _pushDividers = newValue!;
                      })),
              const Text("Push dividers")
            ]));

    Widget? content;
    if (_controller.areasCount != 0) {
      MultiSplitView multiSplitView = MultiSplitView(
          onDividerDragUpdate: _onDividerDragUpdate,
          onDividerTap: _onDividerTap,
          onDividerDoubleTap: _onDividerDoubleTap,
          controller: _controller,
          pushDividers: _pushDividers,
          builder: (BuildContext context, Area area) => ColorWidget(
              area: area, color: area.data, onRemove: _removeColor));

      content = Padding(
          padding: const EdgeInsets.all(16),
          child: MultiSplitViewTheme(
              data: MultiSplitViewThemeData(
                  dividerPainter: DividerPainters.grooved2()),
              child: multiSplitView));
    } else {
      content = const Center(child: Text('Empty'));
    }

    return Scaffold(
        appBar: AppBar(title: const Text('Multi Split View Example')),
        body: Column(children: [buttons, Expanded(child: content)])
        // body: horizontal,
        );
  }

  Color _randomColor() {
    Random random = Random();
    return Color.fromARGB(255, 155 + random.nextInt(100),
        155 + random.nextInt(100), 155 + random.nextInt(100));
  }

  _onDividerDragUpdate(int index) {
    if (kDebugMode) {
      // print('drag update: $index');
    }
  }

  _onRemoveFirstButtonClick() {
    if (_controller.areasCount != 0) {
      _controller.removeAreaAt(0);
    }
  }

  _onDividerTap(int dividerIndex) {
    ScaffoldMessenger.of(context).showSnackBar(SnackBar(
      duration: const Duration(seconds: 1),
      content: Text("Tap on divider: $dividerIndex"),
    ));
  }

  _onDividerDoubleTap(int dividerIndex) {
    ScaffoldMessenger.of(context).showSnackBar(SnackBar(
      duration: const Duration(seconds: 1),
      content: Text("Double tap on divider: $dividerIndex"),
    ));
  }

  _onAddFlexButtonClick() {
    _controller.addArea(Area(data: _randomColor()));
  }

  _onAddSizeButtonClick() {
    _controller.addArea(Area(data: _randomColor(), size: 100));
  }

  void _removeColor(int index) {
    _controller.removeAreaAt(index);
  }
}

class ColorWidget extends StatelessWidget {
  const ColorWidget(
      {Key? key,
      required this.color,
      required this.onRemove,
      required this.area})
      : super(key: key);

  final Color color;
  final Area area;
  final void Function(int index) onRemove;

  @override
  Widget build(BuildContext context) {
    List<Widget> children = [];
    TextStyle textStyle = const TextStyle(fontSize: 10);
    if (area.size != null) {
      children.add(Text('size: ${area.size!}', style: textStyle));
    }
    if (area.flex != null) {
      children.add(Text('flex: ${area.flex!}', style: textStyle));
    }
    if (area.min != null) {
      children.add(Text('min: ${area.min!}', style: textStyle));
    }
    if (area.max != null) {
      children.add(Text('max: ${area.max!}', style: textStyle));
    }
    Widget info = Center(
        child: Container(
            color: const Color.fromARGB(200, 255, 255, 255),
            padding: const EdgeInsets.fromLTRB(3, 2, 3, 2),
            child: Wrap(
                runSpacing: 5,
                spacing: 5,
                crossAxisAlignment: WrapCrossAlignment.center,
                children: children)));

    return InkWell(
        onTap: () => onRemove(area.index),
        child: Container(
            color: color,
            child: Stack(
                children: [const Placeholder(color: Colors.black), info])));
  }
}

I copied your code.
I get 3 areas of width: 600, 150, 464.28
The dividers do not resize the first 2 areas.
I can change the width of the main window and area3 resizes. When it becomes 0, area2 shrinks.
The dividers never work.

Sized areas are resizable as long as there is space for it in the window

But not resizable by the user.

The initial size of 464.28 and the shrinking behavior is as expected given the configurable inconsistency handling.
Regarding the divider that doesn't move, it seems to me that it's another problem. Maybe it's a mouse event that isn't even being triggered. Maybe something related to your Flutter or OS version? You could download the source and test it by debugging. Check whether the _onDragDown and _onDragUpdate methods are being executed. They are in multi_split_view.dart. I test with Web and Linux. I don't expect this from Flutter but perhaps there is an event that I have to declare differently given the OS.
You will notice that within _onDragUpdate, there is a call to DividerUtil.move which has the logic to calculate the appropriate resizing.

I cloned your repo.
Running example code - all areas resizable.
Remove the flex area - dividers do not move. Both on Windows and Edge browser.
In all cases _onDrawDown and _onDrawUpdate are called even when the divider does not work.
_onDrawDown creates _draggingDivider
_onDrawUpdate does nothing because _draggingDivider == null
L185 sets _draggingDivider = null;
called because:  _lastAreasUpdateHash != controllerHelper.areasUpdateHash
forces loss of divider hence divider does not work.
Restoring the flex area, now the UpdateHashes match and dividers work.
Running Dart 3.4.3, Flutter 3.22.2

:thinking:
This line L185 resets the _draggingDivider in situations such as the window was resized, the theme was changed or some area was added/removed. So it makes sense to cancel the divider drag. But the first time the window opens, this code is executed and _lastAreasUpdateHash should be set with:
_lastAreasUpdateHash = controllerHelper.areasUpdateHash;

This areasUpdateHash is just an Object to indicate that an area has been added or removed. Every method that adds or removes areas creates a new Object.
I don't understand how on your machine it only works with flex. The hash is not related to flex or sized.
When you don't use flex, the divider drag always goes into the build method and L185 because of the _lastAreasUpdateHash != controllerHelper.areasUpdateHash comparison?
It doesn't make sense because then we have:
 _lastAreasUpdateHash = controllerHelper.areasUpdateHash;

Could you check if L139 (layout_constraints.dart) is also executed? This could create a new hash and keep this loop. This L139 is the controllerHelper.updateAreas(); inside the adjustAreas method.
      if (_lastAreasUpdateHash != controllerHelper.areasUpdateHash ||
          _layoutConstraints == null ||
          _layoutConstraints!.containerSize != containerSize ||
          _layoutConstraints!.dividerThickness != themeData.dividerThickness) {
        _draggingDivider = null;

                  /// KEEP HASH HERE
        _lastAreasUpdateHash = controllerHelper.areasUpdateHash;

        _layoutConstraints = LayoutConstraints(
            controller: _controller,
            containerSize: containerSize,
            dividerThickness: themeData.dividerThickness);

            /// BUT MAYBE RESET controllerHelper.areasUpdateHash HERE
        _layoutConstraints!.adjustAreas(
            controllerHelper: controllerHelper,
            sizeOverflowPolicy: widget.sizeOverflowPolicy,
            sizeUnderflowPolicy: widget.sizeUnderflowPolicy,
            minSizeRecoveryPolicy: widget.minSizeRecoveryPolicy);
      }

If you enter L139, you need to find out why changed is TRUE
if (changed) {
 controllerHelper.updateAreas();
 Future.microtask(() => controllerHelper.notifyListeners());
 }

L139 (layout_constraints.dart) is continuously executed
Reason: L117 is true because (totalSize < spaceForAreas && flexCount == 0)
L128 adjusts the size by  spaceForAreas - totalSize.  This has a value: 2.87 e-7 !!!
L136 changed = true forces redraw
It appears that the extremely small adjustment has no effect on the reported sizes and forces a continuous loop.
There are several places in the function where adjustment is calculated as too tiny.
If I add a statement like
if ( spaceForAreas - totalSize < 1 ) {
  return;
}

It now works
As an additional comment
SizeUnderflowPolicy.stretchAll is best for my use
SizeOverflowPolicy - would be good to have 'shrinkAll'

This wrong value is because of a floating point. :disappointed:
Tks,
Bug issue: #78
shrinkAll: #77

Version 3.2.2 release with the bugfix

Looks good. Thanks for your help.


h: Test args for truthy values instead of args.length

In my app, I am wrapping calls to h with another helper. This helper passes through args to h after applying some logic, as in:
function helper(first, second, ...rest) {
  // ... logic ...
  h(first, second, ...rest);
}

Checking arguments.length causes this helper to fail, since it is just passing through values, so there could be only 2 "truthy" arguments, but h would receive h(first, second, undefined), breaking the argument processing in h.
Switching to truthy checks appears to solve this and preserve previous behavior. What do you think of this?
Thanks for working on this library! :smile:

Hello @jryans. Sorry for the late response :cry: I think this a fine change and I can understand your issue.
But I don't like truthy testing. I'd rather use !== undefined instead as this is explicit about what is being tested.
Fix that and I will merge and release :+1:

Okay, I believe I've made the changes you asked for. Thanks for taking a look!

Splendid. Thank you.


What is the infection rate schedule?

E.g. for 3 epidemics, the infection rate is now 3.

Found it https://i.ytimg.com/vi/Xhm_mirncG8/maxresdefault.jpg


Crash on 1.20.1

Modrinth, Fabric - https://mclo.gs/CtE6yjb
Only after removing the mod I can actually open the game!

Try removing cosmetica. I don't see a crash in the log.


jsk_3rdparty: 2.1.21-2 in 'melodic/distribution.yaml' [bloom]

Increasing version of package(s) in repository jsk_3rdparty to 2.1.21-2:

upstream repository: https://github.com/jsk-ros-pkg/jsk_3rdparty.git
release repository: https://github.com/tork-a/jsk_3rdparty-release.git
distro file: melodic/distribution.yaml
bloom version: 0.9.3
previous version for package: 2.1.21-1

assimp_devel

No changes

bayesian_belief_networks
* add missing packages, closes https://github.com/ros/rosdistro/pull/26216 (#211 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/211>)
* Contributors: Kei Okada

collada_urdf_jsk_patch
* add missing packages, closes https://github.com/ros/rosdistro/pull/26216 (#211 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/211>)
* Contributors: Kei Okada

dialogflow_task_executive

No changes

downward

No changes

ff

No changes

ffha

No changes

gdrive_ros

No changes

jsk_3rdparty

No changes

julius

No changes

julius_ros

No changes

laser_filters_jsk_patch

No changes

libcmt

No changes

libsiftfast

No changes

lpg_planner

No changes

mini_maxwell

No changes

nlopt

No changes

opt_camera

No changes

pgm_learner

No changes

respeaker_ros

No changes

ros_speech_recognition
* add missing packages, closes https://github.com/ros/rosdistro/pull/26216 (#211 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/211>)
* Contributors: Kei Okada

rospatlite

No changes

rosping

No changes

rostwitter

No changes

sesame_ros

No changes

slic

No changes

voice_text

No changes

@clalancette @tfoote sorry to bother you again and again.
This time, I have reproduced the error on my local environment and confirmed the fix.
https://github.com/tork-a/jsk_3rdparty-release/commit/8e782cd3bb3a0408c5b4c970fc22d6dcec2f5486

Thanks @k-okada !  Merging.


Fix a badge (anti-shackaling)

Instead of the travis one you have on readme, I suggest
 ->
Code for it:
[![Travis Build Status](https://img.shields.io/travis/asc-community/MxEngine?logo=travis)](https://travis-ci.org/asc-community/MxEngine)

(I can't open a PR at the moment)

@MomoDeve 🦆

done


esp_wifi_init returns ESP_ERR_INVALID_ARG when WIFI_INIT_CONFIG_DEFAULT() is used (IDFGH-4609)

Error happens when initializing WiFi:
    esp_err_t result = ESP_OK;
    wifi_init_config_t wifi_init_config = WIFI_INIT_CONFIG_DEFAULT();

    result = esp_wifi_init(&wifi_init_config);
    if (result != ESP_OK)
    {
        ESP_LOGE(TAG, "Wi-Fi initialization failed with error code %x [%s].", result, esp_err_to_name(result));
    }

Seems like regression came from 9ff1609a2064c6e964ad27729aa2fbb273c3165e commit to master.
 What does git submodule status report?

 What does git submodule status report?

I didn't, that fixed the issue. Thank you for your help.

I didn't, that fixed the issue. Thank you for your help.


Install SpatiaLite on CI agents

Hmm... still can’t find the package on Ubuntu.

Oh duh. The container is 14.04. We need 16.04 (like the host).

Hey cool, they pass. 😏


Adjust floor for saturation and brightness possible?

I have several bulbs that vary in saturation and brightness when in color mode (values are too low). As a workaround, I have an automation that takes the hs_color that the app outputs and adds to these values, and turns on the light again with the new settings.  Obviously, there is a noticeable transition to the final color. Could this be accomplished with color profiles by setting a minimum for saturation and brightness with the hue left as is? If not, could I set a floor for these values in the app itself (py code)?

No, something like this is currently not really possible. While you could change the color profile's sample points, I doubt you would reliably achieve the desired effect. The problem is that all interpolation calculations are done in RGB space, which doesn't translate well to the HSV parameters for the lights.
I'm not really satisfied with the current interpolation model myself and I think it would be a good idea to switch to an HSV space interpolation instead. Then the color profile would be defined by HSV sample points and there should be no unexpected variation in saturation and brightness for interpolated values. I'll look into implementing this HSV mode and compare the results.

NiklasReiche, I just noticed the change in the configuration file when I was reinstalling after appdaemon update changed the config folder. The new change works well enough to turn off the automation workaround I wrote last year. Thank you.


Opt-in return type checks

Pull Request Description

Closes #8240

Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[ ] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[ ] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[ ] Unit tests have been written where possible.
[ ] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

TODO: add ascription to Sieve benchmark and check it

The CI did not run my added benchmark (perhaps I need to try again), but I've ran them on my PC.
JMH
[info] Benchmark                          Mode  Cnt     Score      Error  Units
[info] Sieve.Ascribed                     avgt    3   212,305 ±  161,777  ms/op
[info] Sieve.Ascribed_With_Return_Checks  avgt    3   225,027 ±  611,798  ms/op
[info] Sieve.Java_Script_All              avgt    3   595,150 ±  966,628  ms/op
[info] Sieve.Java_Script_File             avgt    3    44,876 ±  144,381  ms/op
[info] Sieve.Java_Script_Filter           avgt    3  1482,088 ±  385,427  ms/op
[info] Sieve.Java_Script_Natural          avgt    3  1381,269 ± 3863,190  ms/op
[info] Sieve.Original                     avgt    3   201,776 ±  165,169  ms/op
[info] Sieve.Without_Types                avgt    3   202,058 ±  178,725  ms/op

Enso Runner

Label
Measurement
Warmup

Sieve.Original
216.6
218.4

Sieve.Without_Types
293.4
225.2

Sieve.Ascribed
214.8
278.6

Sieve.Ascribed_With_Return_Checks
207.8
223.4

Sieve.Java_Script_All
607.5
453.0

Sieve.Java_Script_File
40.0
41.7

Sieve.Java_Script_Filter
1545.3
1295.8

Sieve.Java_Script_Natural
1442.9
1453.7

Interestingly the JMH and Enso Runner results differ a bit - Enso Runner seems to favor the type checks more while on JMH they get worse results relative to the one without.
Looking at the graph with marked std-dev we can see that all tests have similar performance - if we want to get any more detailed results we may need to increase the warmup time/iterations. Within the current setting it seems that the overhead is rather small, if any.

I did one more run with extended warmup and measurement iterations and times:
-options = Bench.options . set_warmup (Bench.phase_conf 3 5) . set_measure (Bench.phase_conf 3 3)
+options = Bench.options . set_warmup (Bench.phase_conf 3 7) . set_measure (Bench.phase_conf 5 7)

Label
Measurement
Warmup

Sieve.Original
196.0
215.6

Sieve.Without_Types
201.1
220.6

Sieve.Ascribed
216.5
217.2

Sieve.Ascribed_With_Return_Checks
217.6
251.7

Here we can see that the variants without type checks are slightly faster, even including the variance of measurements, the difference is by about 8%.

I decided to scratch the better error messages for now, and try to get this PR merged with the current state - return type mismatch resulting in:
Type error: expected `expression` to be Integer, but got Text.

I will create a second followup PR where I will try to improve it to be:
Type error: expected `function_name` result to be Integer, but got Text.

I decided to keep the PRs separate, as I see 2 possible approaches for implementing the error messages and I feel like at least one of them may be controversial - so I want to discuss it in a separate PR, without blocking merging of the basic feature that already works.


please consider adding additional format specifiers to jiff::fmt::strtime for strptime, strftime

The notable missing format specifiers from chrono, that I use pretty frequently, are:

spec
example
description

%c
Sun Jul  8 00:34:60 2001
Locale’s date and time (e.g., Thu Mar 3 23:05:25 2005).

%+
2001-07-08T00:34:60.026490+09:30
ISO 8601 / RFC 3339 date & time format.

They're really just convenience formatters, but they're pretty convenient. 😄

%c is probably a no-go if its specification is "the default format for the current locale." Jiff is very intentionally locale-unaware. I'm not sure if Chrono is even doing the right thing there. It would be better to use icu for that.
I am unsure about %+ because I'm not sure I want to encourage that format over RFC 9557 more than it already is. Moreover, it's unclear to me why you would use that when a Timestamp's default Display impl is exactly that: RFC 3339.

I'll noodle on that, but I think there may be an impedance mismatch here. The needs of a strtime DSL at the library level are likely somewhat different than the needs at a user facing CLI level. I'm still unsure of this because I want to be very careful about encouraging more offset-only formatting.


Feature: React 16 Support

I was wondering if the peer-dependency on React >= 17 could be dropped to >= 16. I am currently working with Apache Superset who, for various reasons, can't upgrade React in the near future. Are there any functions from React 17 that Lexical depends on?

Unlikely, but for your use case you can just add an override for "react" in your "package.json" and it will override all versions of react to use that specific one.

Good point, thanks for the quick response!


Add reject()

Need a way to redirect errors back into a generator.

We can only reject since we don't have a name.


Support async tests

Purpose
To support async tests as well.

Hi!
I started using this extension and I like it very much, but I miss the support for async tests and fixtures.
So I created this PR, although I'm not a ts developer, and I couldn't make the tests pass, not even on the main branch.

Checked out locally and the tests passed. I've found the tests are finicky unless they are ran through a launch configuration in vscode. LGTM, there's a small issue with self-referential function names but I can close that out quickly myself.


Schema

Hi Guys - can you upload your schema.js with resolvers (you can stub out the resolvers such as find one or many because they are database specific).  It would help me and hopefully others understand more about your entry points and connections. Many thanks Gary

Hey Gary, I have my project open here https://github.com/MyiWorlds/myiworlds.backend or directly to the schema area here https://github.com/MyiWorlds/myiworlds.backend/tree/master/src/schema .  This uses the nodejs-api-starter backend. (Docs will come when the project is connected and working).  It is connected to the spectacular Google Cloud Platform Datastore.  Hopefully the schema/resolves can be helpful to you.  Once you get your mind around everything the graphql/relay world gets much easier.
I have it connected to the react-static-boilerplate right now (which I will push to github once it's basics are working).  In my react-static-boilerplate I walked through with koistya and made it auto generate my frontend relay schema, so stay tuned for that.
If this was not at all what you were referring to ignore this lol

Thanks Davey - its very helpful Gary
On 8 November 2017 at 05:54, Davey<EMAIL_ADDRESS>wrote:

Hey Gary, I have my project open here https://github.com/MyiWorlds/
myiworlds.backend or directly to the schema area here
https://github.com/MyiWorlds/myiworlds.backend/tree/master/src/schema .
This uses the nodejs-api-starter backend. (Docs will come when the project
is connected and working). It is connected to the spectacular Google Cloud
Platform Datastore. Hopefully the schema/resolves can be helpful to you.
Once you get your mind around everything the graphql/relay world gets much
easier.
I have it connected to the react-static-boilerplate right now (which I
will push to github once it's basics are working). In my
react-static-boilerplate I walked through with koistya and made it auto
generate my frontend relay schema, so stay tuned for that.
If this was not at all what you were referring to ignore this lol
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kriasoft/react-static-boilerplate/issues/264#issuecomment-342718352,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJJY5OaQr90jve23P4P-UO9xrpoZM5sOks5s0UIdgaJpZM4QK-Gv
.

Hi Davey - it was the resolvers for
import { me } from './User';

import { stories, createStory, updateStory } from './Story';
import { createComment, updateComment } from './Comment';
That were of interest and they are not present.
Gary
On 9 November 2017 at 13:22, Gary McBride<EMAIL_ADDRESS>wrote:

Thanks Davey - its very helpful Gary
On 8 November 2017 at 05:54, Davey<EMAIL_ADDRESS>wrote:

Hey Gary, I have my project open here https://github.com/MyiWorlds/m
yiworlds.backend or directly to the schema area here
https://github.com/MyiWorlds/myiworlds.backend/tree/master/src/schema .
This uses the nodejs-api-starter backend. (Docs will come when the project
is connected and working). It is connected to the spectacular Google Cloud
Platform Datastore. Hopefully the schema/resolves can be helpful to you.
Once you get your mind around everything the graphql/relay world gets much
easier.
I have it connected to the react-static-boilerplate right now (which I
will push to github once it's basics are working). In my
react-static-boilerplate I walked through with koistya and made it auto
generate my frontend relay schema, so stay tuned for that.
If this was not at all what you were referring to ignore this lol
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kriasoft/react-static-boilerplate/issues/264#issuecomment-342718352,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJJY5OaQr90jve23P4P-UO9xrpoZM5sOks5s0UIdgaJpZM4QK-Gv
.

Those are in the nodejs-api-starter :)
createComment (linked) and update comment are on the following page
https://github.com/kriasoft/nodejs-api-starter/blob/b2e526bf74989ffa4b9990e97df98f8679ec801d/src/schema/Comment.js#L53
import { me } from './User';
https://github.com/kriasoft/nodejs-api-starter/blob/master/src/schema/User.js
and import { stories, createStory, updateStory } from './Story';
https://github.com/kriasoft/nodejs-api-starter/blob/master/src/schema/Story.js


Improve usage of flake8

This change improves the project internal usage of flake8.

First, instead of running pydocstyle and pyflakes standalone, we could use flake8 directly
Second, a configuration for flake8 was added
Third: existing flake8 vialoations are now resolved. This means, running 'flake8 diff_cover' doesn't return any error

hmm, this one is showing code changes but I think my github actions flow is not running.
I used to use TravisCI but they started charging and this project does not have revenue... I suspect I just have the hook running in master. Ill try and look as soon as I have a free evening

@kasium please update this one from master. I wanna say the PR build will run after you do that.

@Bachmann1234 done

Alrighty. lets merge this Thanks!