Null HandleLink when Aetheryte has space in name

Might a English specific issue.
When aetheryte has a space in the name, like "Sinus Lacrimarum" following error occurs:
ERR: [Dinvination.AetheryteLinkInChat] HandleLink: aetheryte ("SinusLacrimarum") == null
This issue does not happen with aetherytes without spaces in the name, e.g. "Tomra"
Thank you for the plugin and the new updates. 🙇

Hello.
Thank you for your bug report. I apologize for the lack of testing on the non-Japanese version.
I will fix the logic to work with the non-Japanese version.
In addition, non-localized strings will be translated in the future.
Best regards!

Starting with commit https://github.com/horoscope-dev/Divination.AetheryteLinkInChat/commit/9abc81d3e0b11d814b0a56dbf1df9312fff5a713, the plugin no longer depends on TextPayload (i.e., the name of the aetherite). This should eliminate language-specific bugs.
You may see unexpected behavior due to the use of a low-level API (RawPayload). Please let me know if you have any further problems.
Thanks!!!

As there seem to be no new bugs, I promoted this version to the stable repository.


Documentation on blocks is confusing / inaccurate

Thanks for this awesome project! We're really excited to start using it.
That said, we've had a lot of trouble understanding the documentation.  In particular for blocks, it appears to be a combination of missing information, out of date, and internally inconsistent.  The clearest example of this is in the documentation for Gazetteer (link).  We're using Gazetteer on a large quantity of data, so we're trying to use matchBlocks() instead of match(), but even with reading the source code, we haven't been able to figure out how to properly set up the blocks. As an initial example, the Gazetteer object in the docs actually defines matchBlocks() twice, with different documentation that includes different examples.
First definition, with the final example block structure as follows (the example itself is also syntactically invalid, the parens don't match up):

The second redefinition doesn't have a direct page link, so go here and then scroll up slightly to see it.  Final example block structure it gives:

StaticGazetteer has the same issue, presumably due to inheritance.
Can you clarify what the right way to do blocking is? Thanks so much!

Realized I filed this issue on the wrong repo; closing in favor of https://github.com/dedupeio/dedupe/issues/789.


Generate Geth genesis with pre-loaded ewasm precompile contracts

WIP Still need to clean this up.
E.g. python genesis.py --genesis genesis.json 0x00000000000000000000000000000000000000ff,target/wasm32-unknown-unknown/release/ewasm_precompile_identity.wasm

I don't think this script belongs here, but into the testnet repo.

agreed.


Update enforce_fully_covered list with pm_list.js.

This is to just update the fully enforced list inside test-js-with-node to run test upon pn_list.js as well.

Automated message from Dropbox CLA bot
@adnrs96, it looks like you've already signed the Dropbox CLA. Thanks!

Codecov Report

Merging #5537 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5537   +/-   ##
=======================================
  Coverage   86.72%   86.72%
=======================================
  Files         432      432
  Lines       53651    53651
  Branches     2093     2093
=======================================
  Hits        46528    46528
  Misses       7123     7123

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 6b91195...e41281d. Read the comment docs.

Merged, thanks @adnrs96!


RHEL8 (CentOS 8, Rocky Linux 8,...) support, Refactoring of deprecated modules, new features, version bumps, made to run with latest Mastodon

Hi, I have made these changes to the bare playbook and vagrant with these changes
I have tested these changes manually using Vagrant with Ubuntu 20.04 LTS (Focal Fossa) and Rocky Linux 8.5 Vagrant boxes and was able to register, login and post on the Mastodon instance deployed from my modified playbook.
I have never used ServerSpec and CircleCI for this repo appears to be gone, so creating a RHEL spec file is something I might actually need help with.
Vagrant:

Increased Vagrant RAM up to 4GB due of precompile assets silently failing with just 1GB of RAM
Bumped ubuntu/bionic64 Vagrant box to ubuntu/focal64
Added geerlingguy/rockylinux8 box as a comment for RHEL testing
Changed the mastodon_host variable from example.com to mastodon.local, as .local TLD doesn't leak to the internet as per RFC 6762
Added redis_pass variable to be passed as extra ansible var

Init Role:

Added RHEL8 support
Enable Powertools repository for RHEL8

Postgres Role:

Added Postgres initialisation and initialisation checks for RHEL, as its not initialised automatically as on Debian
Added Postgres to be enabled and started via systemctl
Defined task name if creating postgres database and user on remote host
Replaced deprecated include module with include_tasks
Added separate package manager caching to speed up installation before package installation, as it was refreshing cache with every package attempted to be installed
Removed APT specific variables from the package module, as it made the module non-OS generic

Redis:

Replaced deprecated include module with include_tasks
Added separate package manager caching to speed up installation before package installation, as it was refreshing cache with every package attempted to be installed
Removed APT specific variables from the package module, as it made the module non-OS generic

Web Templates and files:

Created a new env.production.j2 template for installation so that initial setup is not required to be ran
Modified nginx mastodon.conf.j2 to have additional option of using self-signed SSL certificates or using HTTP only, as well as relocating the web root from /home/user/mastodon/live/public to a symlink to eliminate risk of path traversal attack
Updated mastodon systemd service files to be up to date with the main Mastodon repository and added variables

Web:

Added firewall-cmd.yml to set up firewall for RHEL
Replaced deprecated include module with include_tasks
Added separate package manager caching to speed up installation before package installation, as it was refreshing cache with every package attempted to be installed
Removed APT specific variables from the package module, as it made the module non-OS generic
Made mastodon.yml fetch the latest Mastodon release tag to clone using git ls-remote, instead of just cloning directly from main
Mastodon.yml now automatically generates SECRET_KEY_BASE, OTP_SECRET, VAPID_PRIVATE_KEY and VAPID_PUBLIC_KEY and installs it into a .env.production file if it doesn't detect one, eliminating the need for running the initial setup
Added a task that sets the mastodon public folder under the nginx group, even when we run nginx under the user mastodon. This is for some strange reason required on both RHEL and Ubuntu/Debian.
Refactored service restart to use the service ansible module instead of raw command
Modified NGINX to run under the mastodon user, use the service ansible module to start and enable nginx, symlinked the mastodon public folder to eliminate risk of path traversal attacks and added RHEL support by setting SELinux properties and RHEL specific configuration directories
Added nodejs.yml for RHEL8 support. This task checks if RHEL has NodeJS 10 module enabled, and if yes, disables it. It then enables NodeJS 16 dnf module and installs NodeJS 16
Added redis.yml to start and enable redis service, set the Redis password and restart the service
Added RHEL support for repositories.yml by adding RPMFusion and RHEL Yarn repos
Added selfsigned-ssl.yml task for generating self-signed SSL certificate, as when running locally with Vagrant, there's no way how to access the site as LetsEncrypt is disabled, HTTP traffic is redirected to HTTPS and NGINX did not have any SSL certificates to serve the site

Vars:

Bumped ruby_version from 2.7.4 to 3.0.3
Bumped rbenv_version from v1.1.2 to v1.2.0
Bumped uby_build_version from v20210707 to v20220426
bumped node_major_version from 12 to 16
Changed mastodon_db from "{{ mastodon_user }}_development" to "{{ mastodon_user }}_instance"
Added use_http, redis_host, db_host, self_signed_cert_location and self_signed_key_location to bare/vars/common.yml
Changed the ubuntu_codename variable from hardcoded bionic to "{{ ansible_distribution_release }}"
Added acl package to debian_vars.yml as Ansible can't set permissions on temporary files Ansible needs to create when becoming an unprivileged user when running as unprivileged user as explained in Ansible docs
Added redhat_vars.yml
Changed example local domains and local hosts to use mastodon.local or localhost in variables.yml

Documentation:

Updated documentation to encourage users to use Ansible Vault as previous example leaves the mastodon credentials in the shell history
Removed section about needing to run mastodon wizard, as its no longer required
Updated the roles and settings I did in the readme

Hi @moritzheiber
Sure I'll submit a new PR against the V2 branch

Thanks! Much appreciated!


Update windows-iot-core.md

Added the differences between iot enterprise and core

Docs Build status updates of commit d515154:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/windows-iot-core.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Dynamic classes in speaker stats

Dynamic classes in the speaker stats.

Current dependencies on/for this PR:

main

PR #36   👈

This stack of pull requests is managed by Graphite.


[feat] Refactor query panel to use React & Typescript

Overview
Opening this as a draft as its a longer term effort that will likely require some collaboration whereas the current implementation with vanilla JS can be improved and maintained at its currently complexity level fine. Consider this a wish list feature we may circle back to or welcome contributions for, but not of critical importance.

Closing as Vue implementation has been merged.


Working rotate with reduced mesh waffle pi

Launch files work with ros2 launch hello_world_simulation empty_world.launch.py
Rotation occurs after launching ros2 launch hello_world_robot rotate.launch.py

Requires xacro patch
Some plugins not working correctly, under investigation

Signed-off-by: Ross Desmond<EMAIL_ADDRESS>By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Travis builds passed - merging.


Add navigation region point  and segment queries

Adds point and segment queries for regions, e.g. closet point, point normal, or segment intersection.
Also updates the function documentation for the related map queries.
This gets added because quite frequently users voiced the need to do more local queries just on a single region instead of an entire navigation map.
Something to consider, a noticeable amount of this demand came from users that replaced their Geometry2D or physics queries with navigation queries as the API works better for their project needs. E.g. the Geometry2D class is unfriendly to query more complex polygons and physics has its own set of query limitations.

Thanks!


Simplify the setup of new projects

Remove the separate pages for creating or importing projects, because since #102 classes and tags can be added/edited on the project details page.
Adding new projects
The projects overview home page has been extended to contain a form for adding new projects or importing existing ones:

If the given path exists, we check if there is an existing project config file and otherwise create a new one, same for the required sub-directories.
Fixing outdated projects
Projects with an outdated path can now also be edited right on the projects overview page:

Classes and tags explanation
An explanatory message box (previously on the new project page) is added to the project details page:

@nahuakang Thanks for the in-depth testing! In your case above I would suggest though that you either update the path on the left side (if the project has been moved) or first remove the old one and then create a new one (if you want to start from scratch).


dup and clone failing on hash

Struggling to reduce the code on this one, however we have two classes in different projects presenting the issue:
https://github.com/PlaceOS/drivers/blob/master/drivers/cisco/dna_spaces.cr#L89-L92
and
https://github.com/place-labs/clustering/pull/3
the compiler throws an error that looks like
In drivers/cisco/dna_spaces.cr:94:41

 94 | @description_lock.synchronize { loc.dup }
                                          ^--
Error: instantiating 'Hash(String, String)+#dup()'

In /usr/local/Cellar/crystal/0.36.0/src/hash.cr:1775:23

 1775 | hash = self.class.new
                          ^--
Error: wrong number of arguments for 'Hash(String, String)#initialize' (given 0, expected 3)

This is the code triggering the issue above

I tried casting as I assume the issue is caused by generics, Hash(String, String)+ in the error message.
As you can see though, the type should not be ambiguous

Do you have types inheriting from Hash? If so, they must have an argless constructor.
Dup and clone were changed to create the same type.
If that doesn't work I think we should revert that change for 0.36.1. I was against it in the first place too, so...

Do you have types inheriting from Hash? If so, they must have an argless constructor.
Dup and clone were changed to create the same type.
If that doesn't work I think we should revert that change for 0.36.1. I was against it in the first place too, so...

Nothing inheriting from the hash, in both cases a plain String => String class instance variable
Quite strange

Nothing inheriting from the hash, in both cases a plain String => String class instance variable
Quite strange

If the compiler says Hash(String, String)+ then there must be something inheriting Hash. Maybe not by your app but one of the dependencies.

If the compiler says Hash(String, String)+ then there must be something inheriting Hash. Maybe not by your app but one of the dependencies.

In any case, I think we should revert that "dup/clone preserving types" nonsense.

In any case, I think we should revert that "dup/clone preserving types" nonsense.

I'm talking about this PR: https://github.com/crystal-lang/crystal/pull/9871
The reason I'd like to revert this is because dup and clone will not work out of the box if the subtype doesn't define an argless constructor. If someone wants dup and clone for their subtypes they should define those. What do we do with extra variables that are defined in subclasses? It's not clear.

I'm talking about this PR: https://github.com/crystal-lang/crystal/pull/9871
The reason I'd like to revert this is because dup and clone will not work out of the box if the subtype doesn't define an argless constructor. If someone wants dup and clone for their subtypes they should define those. What do we do with extra variables that are defined in subclasses? It's not clear.

This reproduces the issue:
class Foo(K, V) < Hash(K, V)
  def initialize(@foo : Int32)
    super()
  end
end

class MyContainer
  @hash : Hash(String, String) = {"1" => "2"}

  def hash
    @hash
  end
end

Foo(String, String)

MyContainer.new.hash.dup

@stakach A workaround until the next release is to add this somewhere in your codebase:
class Hash(K, V)
  def dup
    hash = Hash(K, V).new
    hash.initialize_dup(self)
    hash
  end
end

Something similar should be done for clone, the original code is in that linked PR.

This reproduces the issue:
class Foo(K, V) < Hash(K, V)
  def initialize(@foo : Int32)
    super()
  end
end

class MyContainer
  @hash : Hash(String, String) = {"1" => "2"}

  def hash
    @hash
  end
end

Foo(String, String)

MyContainer.new.hash.dup

@stakach A workaround until the next release is to add this somewhere in your codebase:
class Hash(K, V)
  def dup
    hash = Hash(K, V).new
    hash.initialize_dup(self)
    hash
  end
end

Something similar should be done for clone, the original code is in that linked PR.

For reference, this has also been reported on the forum: https://github.com/crystal-lang/crystal/issues/10328

For reference, this has also been reported on the forum: https://github.com/crystal-lang/crystal/issues/10328

I agree to revert #9871. Inheriting Hash should not be encouraged in general. And if you do, it shouldn't break other's code because you missed to define an argless constructor.

I agree to revert #9871. Inheriting Hash should not be encouraged in general. And if you do, it shouldn't break other's code because you missed to define an argless constructor.

@stakach it's on the dependencies.
Searching 156 files for "< Hash"

0 matches

Searching 1872 files for "< Hash"

/private/tmp/drivers/lib/habitat/spec/habitat_spec.cr:
   18  end
   19
   20: class Generics < Hash(String, String)
   21    Habitat.create do
   22      setting should_work : String = "with generics"

/private/tmp/drivers/lib/http-params-serializable/src/http-params-serializable/errors.cr:
   72          @path = param_path.to_a + nested_path
   73          full_path = @path
   74:         _type = type < Array ? "Array" : type < Hash ? "Hash" : type
   75
   76          super("Parameter #{build_path(*param_path).inspect} is of type #{_type}, but has nested content at #{build_path(full_path).inspect}")
   ..
   83        def initialize(path : Tuple, type)
   84          @path = path.to_a
   85:         _type = type < Array ? "Array" : type < Hash ? "Hash" : "Object"
   86
   87          super("Parameter #{build_path(*path).inspect} is of type #{_type}, but set explicitly with #{(build_path(*path) + '=').inspect}")

/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/status.cr:
    1: class PlaceOS::Driver::Status < Hash(String, String)
    2    def set_json(key, value)
    3      key = key.to_s

/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/storage.cr:
    2
    3  # Abstraction of a redis hset
    4: abstract class PlaceOS::Driver::Storage < Hash(String, String)
    5    DEFAULT_PREFIX = "status"
    6

5 matches across 4 files

And  EdgeStorage & RedisStorage redefine the constructors dropping the zero-argument overload. (funny, I wouldn't expect that you should be able to declare a abstract class that inherit a non-abstract one...)
/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/storage/edge-storage.cr:
    2  require "../protocol"
    3
    4: class PlaceOS::Driver::EdgeStorage < PlaceOS::Driver::Storage
    5    def initialize(@id : String, @prefix = DEFAULT_PREFIX)
    6      super()

/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/storage/redis-storage.cr:
    3
    4  # Abstraction of a redis hset
    5: class PlaceOS::Driver::RedisStorage < PlaceOS::Driver::Storage
    6    REDIS_URL = ENV["REDIS_URL"]? || "redis://localhost:6379"
    7

I think #9871 was a good change in the theoretical aspect for every class. In a practical sense, I am fine leaving out the use case for inheriting hash.

@stakach it's on the dependencies.
Searching 156 files for "< Hash"

0 matches

Searching 1872 files for "< Hash"

/private/tmp/drivers/lib/habitat/spec/habitat_spec.cr:
   18  end
   19
   20: class Generics < Hash(String, String)
   21    Habitat.create do
   22      setting should_work : String = "with generics"

/private/tmp/drivers/lib/http-params-serializable/src/http-params-serializable/errors.cr:
   72          @path = param_path.to_a + nested_path
   73          full_path = @path
   74:         _type = type < Array ? "Array" : type < Hash ? "Hash" : type
   75
   76          super("Parameter #{build_path(*param_path).inspect} is of type #{_type}, but has nested content at #{build_path(full_path).inspect}")
   ..
   83        def initialize(path : Tuple, type)
   84          @path = path.to_a
   85:         _type = type < Array ? "Array" : type < Hash ? "Hash" : "Object"
   86
   87          super("Parameter #{build_path(*path).inspect} is of type #{_type}, but set explicitly with #{(build_path(*path) + '=').inspect}")

/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/status.cr:
    1: class PlaceOS::Driver::Status < Hash(String, String)
    2    def set_json(key, value)
    3      key = key.to_s

/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/storage.cr:
    2
    3  # Abstraction of a redis hset
    4: abstract class PlaceOS::Driver::Storage < Hash(String, String)
    5    DEFAULT_PREFIX = "status"
    6

5 matches across 4 files

And  EdgeStorage & RedisStorage redefine the constructors dropping the zero-argument overload. (funny, I wouldn't expect that you should be able to declare a abstract class that inherit a non-abstract one...)
/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/storage/edge-storage.cr:
    2  require "../protocol"
    3
    4: class PlaceOS::Driver::EdgeStorage < PlaceOS::Driver::Storage
    5    def initialize(@id : String, @prefix = DEFAULT_PREFIX)
    6      super()

/private/tmp/drivers/lib/placeos-driver/src/placeos-driver/storage/redis-storage.cr:
    3
    4  # Abstraction of a redis hset
    5: class PlaceOS::Driver::RedisStorage < PlaceOS::Driver::Storage
    6    REDIS_URL = ENV["REDIS_URL"]? || "redis://localhost:6379"
    7

I think #9871 was a good change in the theoretical aspect for every class. In a practical sense, I am fine leaving out the use case for inheriting hash.

IMO we should never allow subclassing any of the stdlib containers, similar to how String has an inherited hook that raises immediately.

IMO we should never allow subclassing any of the stdlib containers, similar to how String has an inherited hook that raises immediately.

Probably close these too then?
#9874
#9753

Probably close these too then?
#9874
#9753


fix(maven): Correctly convert repositories

When resolving artifacts using a ProjectBuilder, remote repositories from the Eclipse Aether library have to be converted to the model used by the Maven repository system. So far, only the most prominent properties have been converted. In certain constellations, this is not sufficient. In a concrete case, resolution failed for an artifact located in a repository that was defined in a pom of a transitive dependency. For this repository the information about the required proxy was lost, and so network requests caused exceptions.
Fix this by also dealing with the properties related to the proxy and authentication.
Note: It would probably be good to have a synthetic fun test for the problematic constellation, but I don't think it is feasible to create one, since the constellation is rather special and also requires a specific network/proxy setup.

LGTM


feat: Make it possible to attach a PayloadProcessor to process model predictions

Motivation
This PR seeks to address the model-mesh side of kserve/modelmesh-serving#284.
Modifications
It provides a PayloadProcessor interface. PayloadProcessors are picked by ModelMesh instances at startup and predictions (Payloads) are processed asynchronously at fixed timing.
A first logger implementation allows to log Payloads (at info level).
Result
A SPI for post processing model predictions.

resolves kserve/modelmesh-serving#284

A README is provided.

@njhill @ckadner would you be able to have a preliminary look ?

Re: failed DCO check:

Commit sha: 24aad57, Author: Tommaso Teofili, Committer: Tommaso Teofili; The sign-off is missing.
Commit sha: 2e48123, Author: Tommaso Teofili, Committer: Tommaso Teofili; The sign-off is missing.

DCO
There are 2 commits incorrectly signed off. This means that the author(s) of these commits failed to include a `Signed-off-by` line in their commit message.

To avoid having PRs blocked in the future, always include `Signed-off-by: Author Name<EMAIL_ADDRESS>in every commit message. You can also do this automatically by using the `-s` flag (i.e., `git commit -s`).

Here is how to fix the problem so that this code can be merged.

## Rebase the branch

If you have a local git environment and meet the criteria below, one option is to rebase the branch and add your Signed-off-by lines in the new commits. Please note that if others have already begun work based upon the commits in this branch, this solution will rewrite history and may cause serious issues for collaborators ([described in the git documentation](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) under "The Perils of Rebasing").

You should only do this if:

    You are the only author of the commits in this branch
    You are absolutely certain nobody else is doing any work based upon this branch
    There are no empty commits in the branch (for example, a DCO Remediation Commit which was added using --allow-empty)

To add your `Signed-off-by` line to every commit in this branch:

    Ensure you have a local copy of your branch by [checking out the pull request locally via command line](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally).
    In your local branch, run: git rebase HEAD~4 --signoff
    Force push your changes to overwrite the branch: git push --force-with-lease origin FAI-948

I think I've fixed the missing Signed-off by commits

We should probably include both the modelId and vModelId with each payload (latter may be null).

this is still in a work in progress state, however I hope most of the comments got addressed.

this also add a RemotePayloadProcessor which sends payloads to a remote endpoint (HTTP).
There's no any registered processor anymore in ModelMesh just the code that parses definitions, if any.

@njhill would it be possible for you to have a look to the updated PR?

Thanks @tteofili I will review the updates today/tonight

@njhill hopefully all comments have been addressed, would you mind having a (final?) look?

@tteofili I have pushed a commit with some suggested changes to this branch, perhaps you could cherry pick it to your PR branch if they look ok.
Other things which I didn't address and would be good if you could have a go at are:

I included a Status field in the Payload class which is the grpc response status for responses and null for requests, but I didn't look at everywhere that should be changed to incorporate that (e.g. the remote payload serialization, maybe other places)
The AsyncPayloadProcessor uses a scheduled executor service but this should really be shut down as part of the overall shutdown procedure. This is so that shutdown isn't blocked by its non-daemon threads and also so that all payloads get logged in the case of upgrades etc. So probably we should make PayloadProcessors Closeable and have the close method shutdown the threadpool for the async processor, so that it interrupts the consumer loop and cleanly processes remaining items in the queue.

@tteofili I have pushed a commit with some suggested changes to this branch, perhaps you could cherry pick it to your PR branch if they look ok.

I don't get the logic behind the ownership concept as it is implemented right now in ModelMeshApi: payloadProcessor is called with takeOwnership=true for requests and, as a consequence, data.retain() isn't called, whereas payloadProcessor is called with takeOwnership=false and data.retain() is called, what is the rationale behind this distinction between requests and responses?
Also I think it's reasonable to assume that a PayloadProcessors can't actually consume the binaries (mayTakeOwnership method), eventually making them unavailable for other processors or ModelMeshApi class, hence I was initially a bit confused about the PayloadProcessor refactoring that connects taking ownership with the result of the process call.
However if you feel like this is a better design, that's fine by me.

Other things which I didn't address and would be good if you could have a go at are:

I included a Status field in the Payload class which is the grpc response status for responses and null for requests, but I didn't look at everywhere that should be changed to incorporate that (e.g. the remote payload serialization, maybe other places)

ok, I've included also in the remote processor.

The AsyncPayloadProcessor uses a scheduled executor service but this should really be shut down as part of the overall shutdown procedure. This is so that shutdown isn't blocked by its non-daemon threads and also so that all payloads get logged in the case of upgrades etc. So probably we should make PayloadProcessors Closeable and have the close method shutdown the threadpool for the async processor, so that it interrupts the consumer loop and cleanly processes remaining items in the queue.

sure, I'll add that part too.

@njhill I've included your patch, with minor changes and implemented the some other points you raised.

@njhill I've included your most recent comments, please let me know if you want me to address anything else.

@njhill I've also included the Base64 fix, I don't see anything else to be addressed right now; this should be good to be merged.


DecisionTree struct cleanup

Currently  there is:

display_depth (in DTC)
pdf_smoothing (in all  *C)

that are hyperparameters that we added for our convenience rather than actual hyperparameters.

The first one should be ditched in favour of passing a tree-display function  that can take kwargs
The second one should be ditched in favour of a more generic transformer step (also the initial  reason it was there has been removed since we're clamping the cross entropy now).

These are now resolved.


Custom attributes are not valid

What problem does this feature solve?

being buffered by linting- / validation-tools about the invalid html
risking conflicts with future html / svg / MathML-specs

What does the proposed API look like?
short version
Instead of <… v-bind= …> use <… data-v-bind= …>
long version
I think I can add to the discussion on https://github.com/vuejs/vue/issues/273 but unfortunately I am not allowed to, so I opened this duplicate.
Why it buffers me much:

Any html-validator I know – Node.js, browser-plugin, IDE – thinks it is invalid and will tell me so.

Why it buffers me minor:

The specs gave us the data- for custom attributes so we can be sure not to conflict with native attributes in future specs. Since native attributes will be intepreted as is in source-code I think that JS will remove the invalid attributes is not a fitting argument.
custom attributes with data also have there own JavaScript API. I like how it differs the code from native attributes structurally and visually.

Why I think it's great

I think data- might be more bloated but that is a problem with the specs.

My opinion has been fully stated at https://github.com/vuejs/vue/issues/273#issuecomment-252372047 - this is not something we will ever consider. Also, changing the syntax at this point is a practical impossibility because the whole ecosystem is built upon the existing syntax.

changing the syntax at this point is a practical impossibility because the whole ecosystem is built upon the existing syntax
Well, case closed, I guess. Thanks for your reply.

What should we do when using inline templates in a non-SPA website? Even if Vue converts the markup to valid HTML5 when executed, it wouldn't be valid initially, when the page loads.
I'm a little confused because it seems, as seen in most issues and forum answers that the only recommended or imposed way to use it is with Single File Components, previously compiled, despite Vue's progressive approach.
I know that this isn't a common practice anymore but there are cases where I'd like to use Vue as a library to add some functionality to existing HTML (WordPress theme for instance) yet have valid HTML. Should I be worried about this anyway?

@sebastiandedeyne , recommend to check out Vuecket - it's the project to integrate VueJS and Apache Wicket.

@PhantomYdn Thank you, interesting project, I will see if it can match our need


Typo "@@SERVERNAME"→"@@SERVERNAME"

https://docs.microsoft.com/en-us/sql/t-sql/functions/servername-transact-sql?view=sql-server-ver15
#PingMSFTDocs

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"


upgrade_oh_my_zsh - Failing?

Received an error this morning when I went to update oh-my-zsh...
custom/example.zsh: needs update
custom/plugins/example/example.plugin.zsh: needs update
refusing to pull with rebase: your working tree is not up-to-date
Is this because OS X 10.10.4 update? or Xcode 6.4 update? Maybe it's because I've been fiddling around with custom plugins... but I thought git ignores the custom directory.
$HOME
└── custom
    └── example
            └── example.plugin.zsh
    └── example-custom
            └── example-custom.plugin.zsh
            └── README.md
    └── example.zsh
Any ideas?

That sounds like you've made changes to files in the oh-my-zsh repo that are tracked.
Git ignores the custom directory... except for those example files that are provided with the oh-my-zsh distribution. You can see this in the .gitignore at the project root.
custom
!custom/plugins/example
!custom/example.zsh
!custom/example.zshcache

Is that stuff under your $HOME dir, or under ~/.oh-my-zsh (which is $ZSH's default location).
Post the output of git status run from ~/.oh-my-zsh and let's see what's going on.

I appreciate the the feedback APJ and thank you for such a quick reply. Bear with me because this is, however, my first post to github about an ongoing issue.
Here's my output after running git status within ~/.oh-my-zsh
stephen-lempke in ~/.oh-my-zsh on master✘✘✘ using ‹› 15-07-07 - 9:22:42
» git status
# On branch master
# Your branch is ahead of 'origin/master' by 3186 commits.
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#	modified:   .gitignore
#	modified:   custom/example.zsh
#	modified:   custom/plugins/example/example.plugin.zsh
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#	themes/slempke.zsh-theme
no changes added to commit (use "git add" and/or "git commit -a")
Updating oh-my-zsh has always been smooth, even with having a custom theme within the themes directory. Here's the output when running upgrade_oh_my_zsh
stephen-lempke in ~ using ‹› 15-07-07 - 9:45:03
» upgrade_oh_my_zsh
Upgrading Oh My Zsh
.gitignore: needs update
custom/example.zsh: needs update
custom/plugins/example/example.plugin.zsh: needs update
refusing to pull with rebase: your working tree is not up-to-date
There was an error updating. Try again later?
Thoughts?

Yeah, it looks like the fact that those two OMZ-provided example files have been modified.
If you want to keep your changes, do this:
cd ~/.oh-my-zsh
cp custom/example.zsh custom/my-example.zsh
mkdir custom/plugins/my-example
cp  custom/plugins/example/example.plugin.zsh custom/plugins/example/my-example.plugin.zsh

And then do this to undo the changes on the main files.
git checkout -- .gitignore
git checkout --  custom/example.zsh
git checkout -- custom/plugins/example/example.plugin.zsh

Then I think the update will work for you again; you can run it manually by doing env ZSH=$ZSH zsh -f $ZSH/tools/check_for_upgrade.sh.
It's a little odd that git says your branch is 3800 commits ahead. I guess we'll worry about that later if there's still a problem.

Well, that worked! Thank you.
Was the issue because I didn't create the directory and file for a custom plugin through terminal?
Still receiving:
» git status
On branch master
Your branch is ahead of 'origin/master' by 3193 commits.
Much appreciated!

The issue was just that you modified existing files in the ~/.oh-my-zsh/custom directory instead of creating new ones.
I don't think that limitation is documented anywhere, so it's not surprising that you hit it. We should document that or do something else about it.

Yes, we should add a warning in those example files.

Please close this issue.


removing roll from Feature Layer rendering mode sample

@tschie Can you look at this?
Issue: https://devtopia.esri.com/runtime/java-se-sdk/issues/1154
Had to remove roll from camera so that the sample ran like it did before roll was implemented.

@tschie Can you do me a favor and redo the gif for this. I usually do this on my windows computer but eclipse doesn't want to open on it. Thought it be an easy fix, but appears not. Once the gif is done this can be merged.

@tschie Got eclipse working.


Update create-management-group-azure-cli.md

When the Root Management Group when is created, users don't have access to it. --->
When the Root Management Group is created, users don't have access to it.
I assume that the second "when" is a typo (not required).

Thanks, @shigeooooooooooo!


Handle multiple cameras and serial ports

Can be done with multi-threading, only I'm still not sure what exactly needs to be done and what the UI will look like - but it will be exciting!

Some information regarding multithreading with OpenCV: https://stackoverflow.com/a/58599708/13240268

For micropython to receive input whilst running, I need to better understand threading, multiprocessing and asyncio.  Could make the microcontroller side of things greatly improved, and potentially enable communication between boards by having separate read and write threads.
For asyncio, Peter Hinch is a great resource.

Managed to implement multi-canera support without threading. Remains to be seen if fps are unaffected, and thus whether threading will be needed later. Nevertheless, that shouldn't be too tricky now.

Cameras are heavily affected. Trying to figure out whether to use threading, asyncio or multiprocessing to work around it.

For the serial communication, there might be some useful info here: https://forums.raspberrypi.com/viewtopic.php?f=144&t=301414.

Managed with multiprocessing. Serial communication will be discussed elsewhere.


NaN or Inf found in input tensor.

Hi,
I was running train_autoenc.py with default hyperparameters and I encountered this error then stopped training.
Would you mind helping with this?
Epoch 11: : 1200it [21:02,  1.05s/it, loss=0.0638, v_num=0, val_loss=0.054, val_rec_loss=0.0454, val_kl_loss=0.819]                               Metric val_rec_loss improved by 0.010 >= min_delta = 0.0. New best score: 0.045
Epoch 12: : 600it [11:53,  1.19s/it, loss=nan, v_num=0, val_loss=0.054, val_rec_loss=0.0454, val_kl_loss=0.819]NaN or Inf found in input tensor.
...
Epoch 12: : 1200it [20:38,  1.03s/it, loss=nan, v_num=0, val_loss=0.054, val_rec_loss=0.0454, val_kl_loss=0.819]NaN or Inf found in input tensor.
Epoch 12: : 1200it [20:40,  1.03s/it, loss=nan, v_num=0, val_loss=nan.0, val_rec_loss=nan.0, val_kl_loss=nan.0]                                   Monitored metric val_rec_loss = nan is not finite. Previous best value was 0.045. Signaling Trainer to stop.
Epoch 12: : 1200it [20:40,  1.03s/it, loss=nan, v_num=0, val_loss=nan.0, val_rec_loss=nan.0, val_kl_loss=nan.0]

Meanwhile, in the above commit I added an easy option to continue training the autoencoder from a checkpoint (this option already existed for the diffusion model training).

Thanks for the suggestions! @jleinonen
I restart from a checkpoint and the problem occurs again using the command below,
time python train_autoenc.py --ckpt_path lightning_logs/version_0/checkpoints/epoch\=11-val_rec_loss\=0.0454.ckpt

I'm trying to print some message for debugging it.
     (raw, _) = split.train_valid_test_split(raw, var, chunks=chunks)

     print('RZC scale: ', raw["train"][var]["scale"])
     variables[var]["transform"] = transform.default_rainrate_transform(
         raw["train"][var]["scale"]
     )

The output information is as follows,
Loading data...

Loading cached sampler from ../cache/sampler_autoenc_test.pkl.
Loading cached sampler from ../cache/sampler_autoenc_train.pkl.

I found the RZC scale have NaN. Is it caused by this?

The rain rates are stored as 8-bit unsigned int values that are then translated to physical values in mm/h using the scale array. It is true that the last elements of scale are left at nan but this is because these values should never occur in the 8-bit data. I have never seen a problem that the actual inputs to the training would contain nan, so I'm a bit puzzled by this. Could you verify by drawing samples from the datamodule and checking with e.g. np.isfinite(x).all()?
Meanwhile I re-ran the autoencoder training and I saw that around epoch 10 the training loss spikes. In the worst cases this can cause the loss to go to nan, while in other cases it recovers quickly. And it seems that after this happens once, it does not occur again. It's as if the network somehow reorganizes itself. I recall now that I found the same thing happening back in October-November when I was first training the autoencoder.

The rain rates are stored as 8-bit unsigned int values that are then translated to physical values in mm/h using the scale array. It is true that the last elements of scale are left at nan but this is because these values should never occur in the 8-bit data. I have never seen a problem that the actual inputs to the training would contain nan, so I'm a bit puzzled by this. Could you verify by drawing samples from the datamodule and checking with e.g. np.isfinite(x).all()?

Thanks for explanation and suggestion. I will try to check it.

Meanwhile I re-ran the autoencoder training and I saw that around epoch 10 the training loss spikes. In the worst cases this can cause the loss to go to nan, while in other cases it recovers quickly. And it seems that after this happens once, it does not occur again. It's as if the network somehow reorganizes itself. I recall now that I found the same thing happening back in October-November when I was first training the autoencoder.

I run again to restart from a checkpoint using the command below and works fine now.  It's so strange.
time python train_autoenc.py --ckpt_path lightning_logs/version_0/checkpoints/epoch\=11-val_rec_loss\=0.0454.ckpt

In addition, I guess this is maybe because log10(scale) is NaN when the scale is 0, then I replaced log_scale = np.log10(scale).astype(np.float32) in ldcast/features/transform.py to log_scale = np.log10(scale+1).astype(np.float32). I tried to run train_autoenc.py and also works fine.

Note that a couple of lines below
log_scale = np.log10(scale).astype(np.float32)

we have
log_scale[~np.isfinite(log_scale)] = np.log10(fill_value)

which should ensure that all values in log_scale are non-NaN. (The default is fill_value=0 but in default_rainrate_transform it is set to 0.02, so it has a finite logarithm).

Note that a couple of lines below
log_scale = np.log10(scale).astype(np.float32)

we have
log_scale[~np.isfinite(log_scale)] = np.log10(fill_value)

which should ensure that all values in log_scale are non-NaN. (The default is fill_value=0 but in default_rainrate_transform it is set to 0.02, so it has a finite logarithm).

Thanks for the explanation! @jleinonen


uv export does not work if conflicting groups are defined

I have a project that requires a different version of a library based on the infrastructure we are testing against. I defined those dependencies in 2 different dependency groups and told uv that they conflict:
[project]
name = "tls-certificates-interface"
version = "0.1.0"
requires-python = ">=3.10"

dependencies = [
    "cryptography",
    "jsonschema",
    "ops",
    "pydantic",
    "rpds-py==0.18.1"
]

[dependency-groups]
test = [
    "coverage[toml]",
    "pytest",
    "pytest-operator",
    "pytest-asyncio==0.21.2",
    "ops[testing]",
]
dev = [
    "codespell",
    "pyright",
    "ruff",
]
test-juju-2 = [
    "juju==<IP_ADDRESS>"
]
test-juju-3 = [
    "juju>3"
]

[tool.uv]
conflicts = [
    [
        { group = "test-juju-2" },
        { group = "test-juju-3" },
    ],
]

It works well for most of our workflows, but it fails when trying to run uv export to generate a requirements.txt file for another tool, with the error:
$ uv export --no-group test-juju-2 --no-group test-juju-3
Resolved 83 packages in 1ms
error: Cannot represent `uv.lock` with conflicting extras or groups as `requirements.txt`

I have tried many different switches to get uv to ignore those groups, as I do not need them in the requirements file, but found no way of making uv export work with those conflicts.
A workaround I found was to use this instead:
uv pip compile pyproject.toml -o requirements.txt

I manually validated the output against the uv.lock file and everything seemed to match, but I am not certain this is guaranteed when using the pip interface.

I believe this was already fixed in more recent versions.

You are right, I just upgraded to the latest version and it works. Thank you, sorry for the noise!

No problem, glad it was easy to resolve.


PCB Rev A: Implements Battery Charge and Power Path Controller

This PR addresses #642

This PR addresses #642

from discussion: https://respiraworks.slack.com/archives/C011NJ8MHCJ/p1611898061064700
As I dive more into what the power design might look like, just to share what is going through my head:

There doesn't seem to be a single converter that can produce a stable 12V at the currents we want while also charging the battery and routing the input power to the load.
So it looks like it's going to be AC Adapter -> battery charger/power path controller (can be one IC, yay) -> DC/DC converter.
I don't like this idea of a buck-boost followed by another buck-boost.  That's 8 FETs to fail in the chain (plus 2 for charge control).  ::poop emoji::
With a 3s lithium battery the voltage swing is 9V to 12.6V, which is both above and below our AC adapter input of 12V AND our system voltage of 12V, basically forcing buck-boost.
If we go to a standard laptop supply input of 19V, and the battery goes to 4s which is 12-16.8V, you get a nice buck-buck :chicken: which is 4 FETs total (plus 2 for charge control)..
This does put all the power on one string.  They're all single points of failure, same as the AC adapter, blower, etc.  Though, it's not like you really have a ventilator when you have a blower and no controller, or a controller and no blower.

bonus<EMAIL_ADDRESS>power adapters are everywhere because laptops, while we're feeling the squeeze trying to find 12V@10A adapters.  (digikey: 12V, 4 options; 19V, 10 options) The connectors also become less of a problem because of the reduced current to get the same power.

Battery controller design is up for review

Buck battery charger and power path controller added
Battery protector / balancer / fuel gauge added
VSYS 12V Buck converter added

completed my scrub.  added part numbers for some of the specific parts, updated comments

Style stuff:

Connectors should probably be the Conn_x symbols rather than the Conn_x_male/female symbols (for clarity/consistency)
Connectors could
Pretty much all the footprints I saw so far pointed to the KiCAD libraries rather than RespiraWorks_Std (I'll pull over the new footprints so they can be consisti-fied with the rest)
Most hierarchical connectors on the top-level (battery_controller.sch) are pointing in rather than out: 12VOUT, PG_12VOUT, PMON*, SDA (which is bidir I guess)
battery_charger: inductor doesn't have footprint assigned yet
battery_balancer: it looks like a few connections use GND, while most use either BAT_N or SYS_N.  I assume the ones on GND (from pins 12, 6) should be SYS_N?
battery_balancer: the bottom 10nF cap is missing its junctions
battery_controller: would be good to have the connector 'value' field match the other schematics by showing what it connects to (like 'Battery' or 'Power wiring harness'); text next to each pin where it's not obvious what it does already (POWER_SWITCH_P seems pretty obvious) would be useful too

Technical stuff:

I'd vote to put the input-power TVS downstream of the fuse, rather than upstream: that way if there's any kind of sustained TVS current it'll blow the fuse and limit the dissipation, less likely to catch on fire etc.
Functionality-wise everything looks good otherwise at first glance, but I haven't read through the datasheets of the battery chips and looked in detail at parameters etc. yet - that's up next.

For the battery balancer - gotta be careful with this and I could use a double check.  According to the datasheet and EVM, only some signals are referenced to the SYS_N side and others to the BAT_N side.
Will post back here when the other things are fixed.  Thanks for the review!

Ha yep, potential for much ground confusion!
battery_controller:

Maybe switched-VLink (POWER_SW_N) should be broken out to a hierarchical connector so that we can run the 5V buck converters and maybe stepper drivers off of the intermediate voltage?
Fuses don't have footprints assigned yet

battery_balancer:

Looks like those GNDs on pins 6, 12 actually should go to BAT_N
I'm a little concerned about the availability of the MAX17320G20+; there's only ~900 at RS components and that's it - some of the other variants have better availability (none particularly great) but those are in the "WLP" BGA-like packages
AOLDO could use a 10K resistor to BAT_N, according to the datasheet, if not used (I'm guessing it needs a minimum load?)
The "Balancing current: 100 mA max." note is a little misleading - with 4.4V max. cell charging voltage and the 50 ohms external + 9 ohms internal, the max. current is only 75 mA which gives a nice 50% of those resistors' typical power rating (which I'm guessing is why you picked 1206-size).  The 100mA through 50 ohms had me doubting the sizing at first.
Is there a reason to use the JST B5B... connector for the cells instead of a Micro-Fit?  (As in, is it a semi-standard thing where you can already buy battery holders with sense cables that have this connector?)  Looks like it doesn't have a footprint yet.

power_vsys:

If the steppers are getting fed from 12V, should EN have a pull-up resistor with transistor pulling it down, controlled by hierarchical input?  This could be what the FPGA drags down to disable the actuators.  If the steppers are getting fed from VLINK instead though (which is probably better, as powerstep01 can take the voltage just fine, and is current-controlled anyways) then ignore this as we should find something different for it to disable.
DITH pin cap can be 220 nF; more standard value and matches RES pin cap + others (moves dither freq. from 417 to 379 Hz)
Same goes for making the SS pin cap 100 nF, even if it speeds up startup a little
Equation 13 on p.18 of the LM5141 datasheet suggests that over the full input range of 13-20V (ripple current pk-pk of 0.31-1.62A), the minimum inductance should be 17-88 uH to make the slope compensation work correctly and avoid subharmonic oscillation.  I'm not sure what other assumptions are baked into their formula though, would have to go back and brush up on the slope compensation math to work it out independently...
Peak current limit can be as low as 6.3A (with +10% inductor ESR), which puts the max. output current as low as 5.5A (with the 1.62App ripple 20Vin case).  Is this enough for the blower?  I'm not familiar with its typical current draw; the WM7060-12V shows 15A max. but I'm assuming that's stall current.
Is there a specific reason HO has a gate resistor but LO doesn't?  Not saying it's wrong, just wondering what I'm missing.
The footprint assigned to the inductor, despite having a disturbingly similar part number, actually has smaller pads.  I'll add a footprint later to the library for this one.
The MOSFET voltage rating of 30V makes me a little nervous, considering ringing etc. (at least they can tolerate it for tiny low-avalanche-energy parasitic-ringing ones...) and the max. clamping voltage of the 20V TVS diode is ~32V - so if there's input over-voltage and the TVS clamps, there's also a chance it'll avalanche the MOSFETs as well.  The CSD18563Q5A is in the OPL and very available outside of that too, is rated to 60V and only has ~20% higher Rds-on and ~50% higher gate charge (which isn't really a limiting factor with these nice slow switching speeds).

battery_charger:

Looks like VLINK should be an output?
Value and mfg p/n don't match on the IC: is it supposed to be the BQ25773 or BQ24773?
Haven't finished this one yet.

Battery charger:

Looks like the divider on ACDET activates ACOK and switches to the AC adapter at 2.4V*(100k+68k)/100k = 4V.  Seems low, maybe 13V would be a better threshold to guarantee the blower buck has something to work with?  High-side resistor could be 442k for this.
Should probably have the datasheet-recommended filtering (10 ohms + 1uF) on the VCC pin; can de-populate if we end up not needing it
The 1nF cap at top-left is weird; it's just adding input-to-gate feedthrough-capacitance which we're trying to minimize; the datasheet's application schematic has it though so can't argue I guess.
Are the 33uF 25V polarized output caps supposed to be tantalums, or tantalum-polymer / niobium oxide?  If regular tantalums, should prob. bump the voltage rating a bit just to be safe.  Either way the 0805 size seems small; Digikey for example doesn't find any tantalums even with a 25V rating in that package - also should be a polarized footprint.
Datasheet recommends 100nF for the ACN/ACP CM and DM filtering caps; is there a reason for using the 33nF ones instead?
Should put one or two of the 33uF caps at the top level AC supply input next to the TVS, to damp any parasitic ringing on plug-in of a powered-up AC supply and make the TVS work less/make it less likely that something will over-voltage.
The voltage thresholds are a little close for comfort on some things: the 20V rating of the P-FET connected to the battery, for example, where VLINK on the other side can be up to 20V.  I can't think of a specific case where there would be a "hard" 0V on the other side of the FET, but I suspect there may be some kind of weird edge case where it can exceed 20V on that P-FET.  The reverse voltage on the internal BTST diode (rated at 20V, p.11 of datasheet) also feels a bit close for comfort - even ignoring various transient cases, under normal conditions if the AC supply input gets to 20V then this diode will see 20V+(REGN - ~0.8V)-REGN = ~19.2V reverse.  I don't know why TI didn't use a higher-voltage diode considering the rest of the system can handle a 20V input fine.

Turning @dcstraney's comments into a checklist for convenience.  Will edit this note with comments to make it easier to follow each thread.
battery_controller:

[ ] Maybe switched-VLink (POWER_SW_N) should be broken out to a hierarchical connector so that we can run the 5V buck converters and maybe stepper drivers off of the intermediate voltage?

The amount of power draw is pretty small so it probably won't make a lot of difference either way.  There may be failure mode reasons to think about.

[ ] Fuses don't have footprints assigned yet

power_vsys:

[ ] If the steppers are getting fed from 12V, should EN have a pull-up resistor with transistor pulling it down, controlled by hierarchical input? This could be what the FPGA drags down to disable the actuators. If the steppers are getting fed from VLINK instead though (which is probably better, as powerstep01 can take the voltage just fine, and is current-controlled anyways) then ignore this as we should find something different for it to disable.

We can do that, but if we do we should make sure that we run the logic power off VLINK as suggested above.

[ ] DITH pin cap can be 220 nF; more standard value and matches RES pin cap + others (moves dither freq. from 417 to 379 Hz)
[ ] Same goes for making the SS pin cap 100 nF, even if it speeds up startup a little
[ ] Equation 13 on p.18 of the LM5141 datasheet suggests that over the full input range of 13-20V (ripple current pk-pk of 0.31-1.62A), the minimum inductance should be 17-88 uH to make the slope compensation work correctly and avoid subharmonic oscillation. I'm not sure what other assumptions are baked into their formula though, would have to go back and brush up on the slope compensation math to work it out independently...
[ ] Peak current limit can be as low as 6.3A (with +10% inductor ESR), which puts the max. output current as low as 5.5A (with the 1.62App ripple 20Vin case). Is this enough for the blower? I'm not familiar with its typical current draw; the WM7060-12V shows 15A max. but I'm assuming that's stall current.

Peak current here is adapter current, which at 19V is 120W.

[ ] Is there a specific reason HO has a gate resistor but LO doesn't? Not saying it's wrong, just wondering what I'm missing.
[ ] The footprint assigned to the inductor, despite having a disturbingly similar part number, actually has smaller pads. I'll add a footprint later to the library for this one.

Rockin', thanks.  Will implement when the footprint is in.

[ ] The MOSFET voltage rating of 30V makes me a little nervous, considering ringing etc. (at least they can tolerate it for tiny low-avalanche-energy parasitic-ringing ones...) and the max. clamping voltage of the 20V TVS diode is ~32V - so if there's input over-voltage and the TVS clamps, there's also a chance it'll avalanche the MOSFETs as well. The CSD18563Q5A is in the OPL and very available outside of that too, is rated to 60V and only has ~20% higher Rds-on and ~50% higher gate charge (which isn't really a limiting factor with these nice slow switching speeds).

battery_charger:

[ ] Looks like VLINK should be an output?
[ ] Looks like the divider on ACDET activates ACOK and switches to the AC adapter at 2.4V*(100k+68k)/100k = 4V. Seems low, maybe 13V would be a better threshold to guarantee the blower buck has something to work with? High-side resistor could be 442k for this.
[ ] Should probably have the datasheet-recommended filtering (10 ohms + 1uF) on the VCC pin; can de-populate if we end up not needing it
[ ] The 1nF cap at top-left is weird; it's just adding input-to-gate feedthrough-capacitance which we're trying to minimize; the datasheet's application schematic has it though so can't argue I guess.
[ ] Are the 33uF 25V polarized output caps supposed to be tantalums, or tantalum-polymer / niobium oxide? If regular tantalums, should prob. bump the voltage rating a bit just to be safe. Either way the 0805 size seems small; Digikey for example doesn't find any tantalums even with a 25V rating in that package - also should be a polarized footprint.
[ ] Datasheet recommends 100nF for the ACN/ACP CM and DM filtering caps; is there a reason for using the 33nF ones instead?
Should put one or two of the 33uF caps at the top level AC supply input next to the TVS, to damp any parasitic ringing on plug-in of a powered-up AC supply and make the TVS work less/make it less likely that something will over-voltage.
[ ] The voltage thresholds are a little close for comfort on some things: the 20V rating of the P-FET connected to the battery, for example, where VLINK on the other side can be up to 20V. I can't think of a specific case where there would be a "hard" 0V on the other side of the FET, but I suspect there may be some kind of weird edge case where it can exceed 20V on that P-FET. The reverse voltage on the internal BTST diode (rated at 20V, p.11 of datasheet) also feels a bit close for comfort - even ignoring various transient cases, under normal conditions if the AC supply input gets to 20V then this diode will see 20V+(REGN - ~0.8V)-REGN = ~19.2V reverse. I don't know why TI didn't use a higher-voltage diode considering the rest of the system can handle a 20V input fine.

Note that with the NVDC design, VLINK should be 16.8V max, but there probably isn't much harm in going to higher voltage FETs, just more losses.

Minimum inductance/slope compensation: those values do seem weirdly high to me too.  There may be something off (or unexpected) with their slope compensation formula.  Testing sounds like a good idea, any subharmonic oscillation should be really easy to see on the switch node.
1nF Cgd: my guess is that it was added to the datasheet by someone at TI who was not paying attention / an intern, who saw the "at least 40:1 ratio" note and totally missed the "at least" (and didn't understand the circuit/problem it was describing) to misinterpret that as "keep the ratio around 40:1".

Didn't find anything about BTST diode on TI's E2E support forums, going to post a question.  However I did learn a couple useful things along the way:

Charging doesn't start automatically; the CC will have to configure it and more specifically, set a charge current first
The bq24773 doesn't decide on its own when charging is done; the CC (in our case) is responsible for figuring that out, according to https://e2e.ti.com/support/power-management/f/196/t/817964 and https://e2e.ti.com/support/power-management/f/196/p/612141/2261043 (although it looks like if set up with proper limits it won't over-charge the batteries anyways)

Thanks.  That's a good point about the charge current setting bring set by the host controller.  I couldn't find a way to make this setting non-volatile, so this means that the very first time it is plugged in, or if the battery ever goes fully flat with no AC input power, the ventilator will not charge until the controller has been turned on at least once.  On my first pass at part selection I didn't find many standalone NVDC chargers out there that could handle the currents we wanted, but I will look again.  As for end-of-charge, the fuel gauge is probably best for this as it has the coulomb counter.  I think we can program it either to end the charge using it's own FETs  or have it send a signal to the battery charger.  I'll take a look.
The need for the controller to be involved in the charging control is not ideal.  That said, the battery backup capability was meant mostly as a proof-of-concept in this revision, so I think it's ok to focus priority on other things to keep the integration moving, and to make these improvement if we have spare time or in a future revision.

Yep, agreed all around on that.
Probably won't be able to even post a question until Tuesday it looks like, due to forum weirdness.

For the record, here's TI's answer on the BTST diode.  Short version: datasheet is badly worded, possibly written by intern.
"Apologies for the confusion; the way the spec is written is a bit misleading. With 20 V of reverse voltage across the BTST diode, the reverse current should not exceed 2 uA. Please think of Vr = 20 V and Ir = 2 uA as the operating point at which the BTST diode is characterized, not as the absolute maximum reverse voltage that the diode can withstand. The BTST diode can safely withstand higher voltages without being damaged, even in excess of 30 V. We have tested the BQ24773 EVM with input voltages up to 24 V with no issues. The customer does not need to be concerned about the BTST diode, especially since their adapter voltage is only up to 20 V."


missing i18n translation and correct formatting archive pages year listing

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have searched for relatived questions
[X] I have read documentations

Describe the issue
Similar to discussion https://github.com/razonyang/hugo-theme-bootstrap/discussions/998, there is a problem with the  dateFormat parameter  in the archive listing year
The default english and default dateFormat in the lines with the page title and the month paragraphs are ignored.
The current appearance
October
2 Beiträge insgesamt
Sonstiges   Oct 30
GIT         Oct 11

The expected look
Oktober
2 Beiträge insgesamt
Sonstiges   Okt 30
GIT         Okt 11

Steps to reproduce
config/_default/languages.toml
[de]
  languageName = "Deutsch"
  weight = 1
  defaultContentLanguage = "de"
  [de.params]
    dateFormat = ':date_full'
    description = "Anleitungen, HowTos, Code-Schnipsel & Blog"
    pygmentsUseClasses = true
    comment = false
  [de.params.archive]
    dateFormat = "1. Jan"

Expected behavior
The expected appearance would be a translation into german
Oktober
2 Beiträge insgesamt
Sonstiges   Okt 30
GIT         Okt 11

What operating system(s) are you seeing the problem on?
Linux
What browser(s) are you seeing the problem on?
Chrome
What version of theme are you using?
pull master-branch a few minutes ago
What version of Hugo are you using?
0.119.0
What version of Node.js are you using?
No response
What version of Git are you using?
2.42.0
Additional context
The error should be in this file:
/layouts/partials/archives/year.html
in the lines 7 and 20:
https://github.com/razonyang/hugo-theme-bootstrap/blob/master/layouts/partials/archives/year.html#L7
https://github.com/razonyang/hugo-theme-bootstrap/blob/master/layouts/partials/archives/year.html#L20

In line 20 I've a look at  /layouts/partials/archives/list.html and "copied" it:
{{ .Date | time.Format (default "Jan 2" site.Params.archive.dateFormat) }}

Unfortunately I have no idea for line 4
{{- $yearPage := $page.GetPage (printf "%s%s/" $basePath .Key) -}}

Fixed by cde8594c0d3a32d2a8615da9e9bda36f7e1ef659

Thank you.

Fixed by cde8594

Because you've already closed it
May I politely ask if you have any ideas for line 4?

The basePath is /archives by default, which was passed from the https://github.com/razonyang/hugo-theme-bootstrap/blob/f663634be27a3e0ef421e5582ea5d17b7e0762df/layouts/_default/archives.html#L18.
The .Key is the year part of post's date.

That code is used to get the archives pages that group by year.

Seems that I missed one, do you want this to be cofigured?

Seems that I missed one, do you want this to be cofigured?

Ah yes! That's right. That's what I was trying to describe. I think line 4 should be changed here, but my tries so far have been unsuccessful.

@rainerrose I didn't find a localization date format for month only on https://gohugo.io/functions/time/format/#localization, it may be impossible.
But I can add a parameter to format it as number instead, e.g. 01.

@rainerrose I didn't find a localization date format for month only on https://gohugo.io/functions/time/format/#localization, it may be impossible.

Ah. Uh. What a pity.

But I can add a parameter to format it as number instead, e.g. 01.

That would be great! Thank you.

@rainerrose Added, see https://hbs.razonyang.com/v1/en/docs/layouts/archives/, you can also use the localization token in the future if there is any format for month only.

@rainerrose Added (archive.monthFormat), see https://hbs.razonyang.com/v1/en/docs/layouts/archives/, you can also use the localization token in the future if there is any format for month only, since I'm not sure there is one.

Thank you very much! That was once again very fast. I just have to do something else (family time) and will try this a little later.

Works fine! Thanks a lot.

@rainerrose I didn't find a localization date format for month only on https://gohugo.io/functions/time/format/#localization, it may be impossible.

I submit an feature request https://github.com/gohugoio/hugo/issues/11673

@rainerrose I looked into the Hugo source code, month only format is supported, I pushed a bugfix to master branch, you can try and close that feature request.

First of all, thank you very much.
The request has already been closed. I neglected to use the forum first.
Thanks for the patch. Now it looks the way I would like it to. Thank you very much for your work.


EndpointSlices Endpoint using v1beta1 not v1

Expected Behavior
Calico would use the new v1 version of EndpointSlices not v1beta1 after an upgrade to k8s 1.25.
Current Behavior
The calico-typha pod is not coming online and running pods in other node pools are also erroring out but at least reporting themselves as running.
Log of calico-typha pod (regardless of if running with kubelet 1.24.6 or 1.25.2):
[INFO][7] watchercache.go 188: Failed to perform list of current data during resync ListRoot="/calico/resources/v3/projectcalico.org/kubernetesendpointslices" error=resource does not exist: KubernetesEndpointSlice with error: the server could not find the requested resource

K8s API resources:
> kubectl api-resources | grep discovery
endpointslices                                         discovery.k8s.io/v1                      true         EndpointSlice

Steps to Reproduce (for bugs)

Update to k8s 1.25.2
That is all.

Your Environment

Calico version: 3.21.6
Orchestrator version (e.g. kubernetes, mesos, rkt): 1.25.2 on AKS (preview), tigera 1.23.8
Operating System and version: Ubuntu 22.04 (iirc)
Link to your project (optional): https://github.com/Azure/AKS/issues/3315

Hi @siegenthalerroger, it seems like calico v3.21 (and v3.22 as well) still haven't had the API updated to v. Is it possible to move to a more recent Calico version (v3.23+)?

Sadly when using AKS the tigera operator and calico are in Microsoft managed namespaces that we can't change. So we're stuck waiting for an update on their side. The issue is known by MS though so I expect it'll be fixed before k8s 1.25 is GA.

Hi @siegenthalerroger, it seems like calico v3.21 (and v3.22 as well) still haven't had the API updated to v. Is it possible to move to a more recent Calico version (v3.23+)?

Hi @coutinhop Upgrade calico (v3.23+) can help on this issue ?

Calico has already updated to use the v1 API - I think we should close this as it's an issue with an external integration pulling in an outdated version of Calico, rather than a bug in Calico itself.

fwiw the calico documentation still makes no reference to 1.25 support which was one of the contributing confusing factors. https://projectcalico.docs.tigera.io/getting-started/kubernetes/requirements


update homepageUrl to next 5 🎉

since next 5 is out
Currently the homepageUrl is https://zeit.co/blog/next4
query {
  repository(owner: "zeit", name: "next.js") {
    homepageUrl
  }
}

{
  "data": {
    "repository": {
      "homepageUrl": "https://zeit.co/blog/next4"
    }
  }
}

My preference would be changing it to https://zeit.co/blog/next5 because keeping developers up to date is super important :)

@timneutkens maybe we can setup next.now.sh or something like that with a redirect to the latest blog post

@sergiodxa that'd be fancy. But I think it's fine to change it manually for now.
Since we might be working on a website for Next.js soon.

BTW:
Thanks @benatkin
I changed the link.


Need to add "Compile Include ..." to use files generated during the build but this causes more errors

Environment data
dotnet --info output:
Ferramentas de Linha de Comando do .NET (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

VS Code version: 1.17.0
C# Extension version: 1.12.0 (I think)
Steps to reproduce
The attached project uses <Compile Include="$(IntermediateOutputPath)\*.cs" /> so GrammarParser is recognized. But usage of Compile causes others problems in Problems view and with dotnet cli.
If I remove Compile the project builds correctly with dotnet cli, but then OmniSharp does not recognize GrammarParser.

antlr4-netcore2.zip

Many thanks for the detailed repro! I can definitely reproduce with this project.

Thanks again for the repro project. I have found the cause of the issue. We are failing to set the BuildingInsideVisualStudio in OmniSharp, which causes the Antlr targets to fail to include the generated files.
You can workaround this problem by setting BuildingInsideVisualStudio as an environment variable. Here's what I did from a Visual Studio Command Prompt.
> set BuildingInsideVisualStudio=true
> code .

No errors!

OK. I have a fixed checked into OmniSharp to address this issue. It turned out to not be the same root cause as https://github.com/OmniSharp/omnisharp-vscode/issues/1531, so I appreciate you taking the time to file this with an excellent repro.
Once we take a new release of OmniSharp into C# for VS Code, I'll close this issue.

> set BuildingInsideVisualStudio=true
> code .

I confirm this works when the files are already in obj, created by dotnet build.
But if I clean obj, should OmniSharp also cause the files to be generated? Currently it is not.

It won't generate the files simply by passing that variable, but it will with my full OmniSharp change. The project needs to be restored first though. There is an issue in OmniSharp where it won't reload a project after a restore in some cases (and this is one of them). However, if the project is already restored, the files will be generated when OmniSharp loads the project. I just tried this to verify.

@asfernandes : I just wanted to let you know that I just released on a new beta of C# for VS Code that fixes this issue: 1.3.0-beta5. You can following these instructions if you're interested in trying it out.

Seems working. It does not update generated files automatically when I save .g4 files, but it updates when I run the build target in vscode.

Correct. It will only regenerate the files when MSBuild runs. That happens on initial project loading and during build.


Resolving paths using path aliases

Summary
When using path aliases which are prefixed (e.g. using "@", "#" or "~"), paths can't be resolved correctly. Unless the prefix is also present in the name of the folder on the filesystem, files can't be found.
I'm not certain if this is really a bug or if it's working as expected, but it can't hurt to share the issue.
Note: I've seen #124 which seems to be kind of the same thing, but I'm not certain. I haven't heard yet of "import maps" so in case I'm talking about the same issue here, feel free to mark it as duplicate.
Reproduction steps
You can find a simplified example of the problem at the following repository, which includes a README on how to setup the repo:
https://github.com/kevin-st/skott-example
I also added a logs folder, which contains the output of the commands.
Details
We're using prefixed aliases (using an "@"-symbol) in a project I'm working on. The project is setup with Webpack and TypeScript and follows a similar configuration as found in the repository linked up here.
When using these "@"-symbols in the path aliases the import statements are written like this:
import ARComponent from "@ar/components/ARComponent"

and the path alias is configured as follows:
"@ar/*": ["ar/*"]

and the actual folder on the file-system is called ar.
If we look at the logs, we see that it's trying to resolve the path as follows:
Resolving @ar/components/ARComponent using EcmaScriptDependencyResolver

 Start resolution for packages\@ar\components\ARComponent

 ✖ Failed to resolve<EMAIL_ADDRESS>
 ✖ Failed to resolve<EMAIL_ADDRESS>
 ✖ Failed to resolve<EMAIL_ADDRESS>
which can be basically seen as: tsConfig.baseUrl + import statement.
However, earlier on in the logs, we can see that it's registering the path alias:
Extracting path aliases from tsconfig: tsconfig.json

 Found path alias "@ar/*": ["ar/*"]

 Registering path alias without wildcards "@ar": ["packages\ar"]

I'm under the impression that the wrong information is being used to resolve the paths. I'd think that it should be able to use the information from the registration (being @ar which is mapped to packages\ar) and replace that in the import statement when trying to resolve it.
e.g. if the import statement is written like:
import ARComponent from "@ar/components/ARComponent"

then I'd think it would be possible to replace the @ar with packages\ar, making the final import statement packages\ar/components/ARComponent. (This is me thinking the easy way 🤷♂)
Sidenote: The easy solution on my side would be to get rid of the prefixes in our path aliases, then the issue is fixed. It still leaves me wondering though if this is working as expected 😅
Standard questions
Please answer these questions to help us investigate your issue more quickly:

Question
Answer

skott installed version?
0.31.3

Operating system?
Windows

Would you consider contributing a PR?

Node.js version (node -v)?
18.0.0

Hey @kevin-st, thanks for reporting the issue and providing that very detailed repro.

I've seen https://github.com/antoine-coulon/skott/issues/124 which seems to be kind of the same thing, but I'm not certain. I haven't heard yet of "import maps" so in case I'm talking about the same issue here, feel free to mark it as duplicate.

It's not the same issue so you were right to open it, the #124 is about supporting Node.js path aliases while the issue you're encountering is only specific to TypeScript path aliases.

I'm under the impression that the wrong information is being used to resolve the paths. I'd think that it should be able to use the information from the registration (being @ar which is mapped to packages\ar) and replace that in the import statement when trying to resolve it.

This is exactly how it's supposed to work (and how actually it seems to work for non-Windows environments).
From the very quick investigation I did the issue only seems related to Windows environment where paths are handled in a different way. On my Mac, I was not able to reproduce the problems you mentioned on your repo, could you please confirm me that it's the same for you if you have a Mac near by? I'll create a StackBlitz sandbox tomorrow to provide you an example to be sure that this is only a Windows problem.
The issue seems to come from the resolution step because paths aliases registered are weirdly mapped to anti slashes hence the resolver does not consider @ar/components/ARComponent to be a path alias as it's not found in the TS path aliases registry. That's why it then attempts to map<EMAIL_ADDRESS>etc on the real-file system, the path was not considered as a path alias.
So essentially I think that this is not related to the symbols @ / ~ or whatever, only due to the fact that the module import path does not match any path aliases for some Windows specific reason even though this should be supported as this is purely TS path aliases.
I'll investigate in more details tomorrow, I'll keep you updated.

From the very quick investigation I did the issue only seems related to Windows environment where paths are handled in a different way. On MacOS, I was not able to reproduce the problems you mentioned on your repo, could you please confirm me that it's the same for you if you have a Mac near by? I'll create a StackBlitz sandbox tomorrow to provide you an example to be sure that this is only a Windows problem.

We have checked it on a Mac and it's working there as expected, so it seems to be a Windows issue indeed. I also tried to run it on WSL (Windows Subsystem for Linux), so I would expect it to run the same as on Mac, but it seems as if something's wrong there as well and that could be a separate issue.
Regarding this issue, we've been trying to look into it, but we haven't found the cause yet. However, I can share the following:

Given the path @ar/components/ARComponent;

We see that the code is coming in the EcmaScriptDependencyResolver.resolve-method, in which several checks are being made. The check which seems to be going wrong on Windows is the isTypeScriptPathAlias function, which is resolving to false on Windows, but to true on Mac.
On Windows, we see that the isTypeScriptRelativePathWithNoLeadingIdentifier check is resolving to true, which is the reason why we eventually see in the logs that it's trying to find the files at packages\@ar\components\ARComponent.
Following the isTypeScriptPathAlias function, we see the arguments passed to the function as follows:
moduleDeclaration: @ar/components/ARComponent
aliasLinks: Map(3) {
  '@ar' => 'packages\\ar',
  '@configurator' => 'packages\\configurator',
  '@xmlParser' => 'packages\\xml-parser'
}

and pathSegmentToMatch is set to @ar/components.
That value is not set in the map, so we reach the while-loop in the function. This while-loop is never executed though, as isNotBasePathSegment resolves to false. It should resolve to true however, since we have a path seperator in pathSegmentToMatch. If we want the loop to execute, we should invert the first part of the condition:
while (!isNotBasePathSegment(pathSegmentToMatch) && pathDepthAttempts < 10)

Note: Personally, I think the isNotBasePathSegment name is a bit confusing, maybe it would be better to rename this to isChildPathSegment, or the return-statement could be inverted and then you can name the function isBasePathSegment, which makes it less confusing I think.
After making this change, the function returns true. However, something else seems to go wrong if we do it like this and from there on we currently have no clue yet what the issue exactly is.
Maybe this gives some insight.

Thanks for the detailed analysis, it confirms the hypothesis that I had even though I didn't have time to deep dive, problem is I need to prepare few meetups, one this week and the other one next week, so I'm not really sure if I'll have time to fix the issue until middle of next week.
You have already spent a lot of time deeply investigating through that issue and I appreciate it, if you ever find a fix that solves the issue while keeping all the tests to green (+ the one that will be added to cover the current case) I'll be able to merge/publish the fix in the meantime. Otherwise I'll take the lead fix the issue asap, I have a Windows computer that I can use to troubleshoot the issue, it will be easier for me to fix it, for now it's only speculation on my side.
I also take notes about the naming suggestions there :)
Feel free to keep me updated if you guys ever find other interesting stuff to share.
Thanks

I've been taking a look further into the issue and the reason why isNotBasePathSegment is returning false is because the function is checking if the given path contains a path.sep, which on Windows is a backslash and not a forward slash. However, since all of the import statements are written with forward slashes, it does not find the separator and thus the function returns false.
I tried to track down where the import statements are being collected and I found out that a possible location to fix the issue is in the extractModuleDeclarations function.
The way I see it, a possible solution is to check if the current platform is Windows and then making sure that the paths are formatted correctly. For example, if the import statement is written like
import ARComponent from "@ar/components/ARComponent";

The collected path would be @ar/components/ARComponent. However, if we're on Windows, we can replace the forward slashes with a backslash, which would make the collected path be @ar\\components\\ARComponent.
From then on the isNotBasePathSegment function would return true and the isTypeScriptPathAlias is resolving correctly, making the graph contain all nodes.

The only issue(?) I'm seeing here is that there is no arrow from the ARComponent to ar.handler, but I don't know if that's intended behaviour or not. If not, then that's a separate issue I guess.
The current changes that I made are as follows:
This way the changes are minimal and everything should work correctly on unix systems as nothing has changed for those platforms.
However, I'm not sure under which circumstances the other if-statements in this functions are triggered, so I don't know if they work correctly on Windows or not.

Hello @kevin-st,
Great job investigating! As previously said I didn't have time myself to do it and I won't have time before tomorrow, but I highly appreciate your analysis.
To be honest I'm kind of confused that cross platform path issue was not covered yet, I might have mis-used the API in some kind of way, replacing double slashes might be one solution or maybe avoid relying on path.sep in the first place.
The fact that you don't have an link (arrow) where it should means that there is a mismatch between the graph representation and the module resolution so the relationship won't be established. The node's path needs to be exactly the same as when it's resolved and when it's put in the graph (both for the node and the directed link), otherwise it won't show up. Consequently resolving correctly the alias is one thing, but then we should map and add the real path (existing in the alias map) within the graph.
Do you have that repro nearby that I could locally pull for the latest example? I'll start setting up my Windows machine and help you out resolving the thing.

@kevin-st as shown in this workflow Windows platform has some unit tests failing (not even skott package yet) so I would not be amazed that some of the unit tests from skott fail on Windows (that's a good thing). I need to catch up pretty quick with Windows support, I have to admit that it is entirely my bad, I forgot to add Windows in the matrix-os so all features might not be supported/working as expected.

Hello @kevin-st,
Just opened a pull request (#128) that will, I hope, fix all windows-related issues, including the one you described there.
Implementation is mostly done, I just need to add changelogs and publish changed packages. Just FYI the fix will be included in<EMAIL_ADDRESS>Here is an overview of the graph I got with skott's version from the pull request based on the repro you provided me:

It now seems to be behaving as expected, correctly following TypeScript's path aliases.
I'll let you know when the release is published so that you can test on your own.

Hello @kevin-st,
Just published<EMAIL_ADDRESS>that should fix the issue. Let me know if it works for you and if not feel free to re-open the issue.
Thanks again for submitting the issue and providing such detailed information.

Hello @kevin-st,
Just published<EMAIL_ADDRESS>that should fix the issue. Let me know if it works for you and if not feel free to re-open the issue.
Thanks again for submitting the issue and providing such detailed information.

Hi @antoine-coulon,
I'm so sorry for my late response; with the holidays kicking in I completely forgot about the issue. I just checked the update and everything seems to be working as expected.
Thanks for taking the time to look at this!

Hello @kevin-st, no worries, no news is good news with open-source.
Thanks for letting me know, don't hesitate to re-open issues if you still encounter some problems (related to this or not) :)


TN-3048 /api/patient/<>/research_study extended for staff_eligible

Front end was erroneously disabling the control for a staff follow up on EMPRO trigger, once the patient has subsequent global study work pending.
The /api/patient/<>/research_study API now includes an additional staff_eligible boolean.  Only when that is false does the control for staff follow up need to be disabled.

Hello @pbugni! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file portal/views/research_study.py:

Line 63:80: E501 line too long (83 > 79 characters)


CI: Test every commit

We have an explicit policy that each commit merged into master should pass CI but we are not currently enforcing it in the github actions.
An example can be seen here: https://github.com/rust-bitcoin/rust-bitcoin/pull/988#issuecomment-1359979058.

This is strongly related to "setup bors" I think.


Complete Data models

Rename section to Technical Details. It shall contain:

data models (@MichalMed)
more? suggest

Closed by https://github.com/kbss-cvut/termit-web/pull/10


[BUG]A black rect in the center of ShockwaveFilter on some Android devices.

A black rect in the center of ShockwaveFilter on some Android devices.
When time become bigger , the black rect would disappear.
Android 7.0 + Samsung S7.

there is a thread talk about it , but I don't know how to solve.

The black hole is not always black, sometimes there a some other color rect in it. (with different arguments)

Dont divide by zero, i guess. Center is a special case.

@ivanpopelyshev , I found the reason :  normalize(dir).
In some platforms , if dir is vec2(0,0) , will take errors. , in some platforms , will ignore the error.


better support for mpicc, mpicxx, and mpifort

Currently the MPI wrapper compilers mpicc, mpicxx, and mpifort are not guaranteed to work out of box unless the corresponding host compilers (gcc_linux-64, gxx_linux-64, and gfortran_linux-64 in Linux) are also installed in the Conda environment, see https://github.com/conda-forge/openmpi-feedstock/issues/34#issuecomment-460663987:

The openmpi package doesn't depend on the compilers because it's most often installed as a runtime dependency, not as a compiler. To use the mpi compiler wrappers and the compilers they wrap, the conda compilers must be installed. # 35 adds openmpi-mpicc etc. as new outputs so that users have a simple package name to install to pull in both dependencies needed to compiler with openmpi (openmpi and the relevant compiler)

A solution just merged to conda-forge feedstocks yesterday (conda-forge/mpich-feedstock/pull/32
and ongoing conda-forge/openmpi-feedstock/pull/35) was to add additional outputs in the MPI recipes, including mpich-mpicc, mpich-mpicxx, mpich-mpifort, and their openmpi counterparts.
Let us wait for a while and see if it is a sustainable solution before adapting it. In the meanwhile one can always conda install the host compilers to make the MPI wrapper compilers work.

more context: conda-forge/mpich-feedstock/issues/25

Good to know. Thanks for the links. Agree to wait a bit and see how good this solution is.

I'm not sure which packages you are using these in, but FWIW if you have a package that requires MPI as a compiler, you can depend on both mpi and the given compiler as runtime requirements, e.g.:
requirements:
  run:
    - mpich
    - {{ compiler('c') }}

This is the ultimately the same as the new mpich-mpicc package, but more explicit if it's an actual requirement. The mpich-mpicc package and friends are meant really only for users, where the {{ compiler('c') }} template variable isn't available. I would use this pattern in recipes, regardless of the presence of the new convenience packages.

Thanks @minrk for the comment. This is indeed better for packages requiring an MPI compiler. This issue was opened mainly to document my observation that using MPI as a compiler, as you put it, requires a bit of change. However, I suspect most of our users don't need any MPI compiler.


decimal op

Issue #71
Description of changes:

Add IS operator test for decimal type.
Add invalid decimal type parameter to fail/staticAnalysis

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

Could you briefly explain the rules for DECIMAL type and IS operator? How to lower-scale and lower-precision values compare with high-scale and/or high-precision types and visa-versa. Thank you for adding these tests.


Add SLE BCI image for istio-installer

Add SLE BCI image in Dockerfile of istio-installer (https://github.com/rancher/istio-installer)

We need to create a new tag from master. (e.g.: 1.11.4-rancher2)

Testing steps:
https://github.com/rancher/istio-installer#manual-tests
Use the latest image 1.11.4-rancher2 to test the changes. Also test Istio using the normal test plan to validate everything.
cc: @rishabhmsra

Tried validating this on rancher v2.6-head (e55a04c) but could not proceed because of the issue #36588.
Rancher Server:

v2.6-head (e55a04c)
docker install

Validation steps :

Created a AWS node driver downstream cluster (1-cp, 1-etcd, 2-worker).
Rancher server got crashed and became inaccessible #36588.
Also tried creating custom cluster using (1-cp, 1-etcd, 2-worker), but after running the registration commands on nodes Rancher server got crashed with same error.

Re-opening this issue :
The manual testing step mentioned here is failing for this test case.
Rancher Server :

v2.6-head(8c785a1)
docker install

Steps to reproduce :

Provision AWS node driver cluster (1-cp, 1-etcd, 2-worker), using k8s v1.22.6-rancher1-2
Install monitoring 100.1.1+up19.0.3 chart
Install Istio 100.1.2+up1.11.4, enable Kiali, Jaeger and Egress gateway.
Follow the steps mentioned here.
The chart update fails.
istioctl logs:

setting up kubeconfig
Switched to context "rancher-istio-context".
generating ssl certs
Generating a RSA private key
..........................+++++
...........+++++
writing new private key to '/etc/ssl/private/github.com.key'
-----
running nginx
2022/02/24 11:56:58 [notice] 52#52: using the "epoll" event method
2022/02/24 11:56:58 [notice] 52#52: nginx/1.19.8
2022/02/24 11:56:58 [notice] 52#52: built by gcc 7.5.0 (SUSE Linux)
2022/02/24 11:56:58 [notice] 52#52: OS: Linux 5.11.0-1022-aws
2022/02/24 11:56:58 [notice] 52#52: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2022/02/24 11:56:58 [notice] 53#53: start worker processes
2022/02/24 11:56:58 [notice] 53#53: start worker process 54
2022/02/24 11:56:58 [notice] 53#53: start worker process 55
2022/02/24 11:56:58 [notice] 53#53: start worker process 56
2022/02/24 11:56:58 [notice] 53#53: start worker process 57
starting sleep for 30 seconds
starting istioctl commands
client version: 1.11.4
control plane version: 1.11.4
Info [IST0102] (Namespace istio-system) The namespace is not enabled for Istio injection. Run 'kubectl label namespace istio-system istio-injection=enabled' to enable it, or 'kubectl label namespace istio-system istio-injection=disabled' to explicitly mark it as not needing injection.
Info [IST0118] (Service jaeger-collector.istio-system) Port name jaeger-collector-grpc (port: 14250, targetPort: 14250) doesn't follow the naming convention of Istio port.
Info [IST0118] (Service jaeger-collector.istio-system) Port name jaeger-collector-http (port: 14268, targetPort: 14268) doesn't follow the naming convention of Istio port.
running istioctl upgrade
2022-02-24T11:57:32.033596Z info proto: tag has too few fields: "-"
Control Plane - istio-egressgateway pod - istio-egressgateway-7b8554fc78-bmpwq - version: 1.11.4
Control Plane - istio-ingressgateway pod - istio-ingressgateway-5659c66658-dndh8 - version: 1.11.4
Control Plane - istiod pod - istiod-5b4d98d68d-7hvwd - version: 1.11.4
Upgrade version check passed: 1.11.4 -> 1.11.4.
2022/02/24 11:57:32 [error] 54#54: *1 open() "/opt/istio-releases/1.11.4/istio-1.11.4-linux-amd64.tar.gz" failed (2: No such file or directory), client: <IP_ADDRESS>, server: github.com, request: "GET /istio/istio/releases/download/1.11.4/istio-1.11.4-linux-amd64.tar.gz HTTP/1.1", host: "github.com"
<IP_ADDRESS> - - [24/Feb/2022:11:57:32 +0000] "GET /istio/istio/releases/download/1.11.4/istio-1.11.4-linux-amd64.tar.gz HTTP/1.1" 404 125 "-" "Go-http-client/1.1"
2022/02/24 11:57:32 [info] 54#54: *1 client <IP_ADDRESS> closed keepalive connection
2022-02-24T11:57:32.530810Z info Error: failed to generate Istio configs from file [/app/istio-base.yaml] for the current version: 1.11.4, error: failed to fetch URL https://github.com/istio/istio/releases/download/1.11.4/istio-1.11.4-linux-amd64.tar.gz : 404 Not Found
Error: failed to generate Istio configs from file [/app/istio-base.yaml] for the current version: 1.11.4, error: failed to fetch URL https://github.com/istio/istio/releases/download/1.11.4/istio-1.11.4-linux-amd64.tar.gz : 404 Not Found
error found during istioctl upgrade

Note : Tested below scenarios for istio 100.1.2+up1.11.4 and it's working as expected.

Fresh install checks
Upgrade istio from 100.1.1+up1.11.4 —> 100.1.2+up1.11.4 (after upgrade deployed book app and validated traffic and traces through kiali and jaeger)
Upgrade with custom overlay
Kiali
Jaeger traces
Reinstall with Kiali and Jaeger enabled
Fresh install with modified ingress gateway
Unistall/reinstall checks
Istio pointing to externally-installed Prometheus
Multiple ingress
Egressgateway
Validated weighted book demo app.

blocked on monitoring chart installation : https://github.com/rancher/rancher/issues/36639#issuecomment-1056878526

Re-validated on rancher v2.6-head(f2a4147). Created a k8s v1.22.6-rancher1-2 cluster -> 4 node(1-cp, 1-etcd, 2-worker). Monitoring chart installed successfully. Validated the test steps as mentioned here, it's working as expected, hence closing the issue.


Overlapping of icons

When used in combination with iTheme, profile icon, library header, and recently added overlap each other. This occurs regardless of order of theme applied.

Don't use in combination with iTheme.


Heavy dependencies

Hey,
I have noticed that there is a heavy dependency accelerate included in the requirements.
accelerate has a dependency on torch, which results in a pretty big total size (I believe torch is about 600mb). I traced down the dependency to a PR that was adding support for local LLM runs.
Have you considered adding extras_require to setup.py so these local run dependencies are only installed if the user wants to run the LLM locally?
I am happy to open up a PR with a suggestion.

thanks for bringing it up. afaik we do not have local LLM support yet so it must be something else (I vaguely remember huggingface requiring it). Can you link to the commit where accelerate was added?

hey @vprelovac, commit where it was added: https://github.com/kagisearch/pyllms/commit/6247eb012712f89a098456643f1b6a7aeca53fff

Ah you are correct, this is for local execution of HF models and that does require acelerate. Yes please go ahead with the PR to localize the use of this.


chore(release): v1.2.1 🎉

:robot: I have created a release *beep* *boop*
1.2.1 (2022-11-24)
Bug Fixes

cicd: use node v16 in gh actions (e341fea)
deps: fix dep versions to ensure its buildable on cicd (fba09f4)
tests: use fs.unlink instead of fs.rm (392f410)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ehmpathy/simple-on-disk-cache/releases/tag/v1.2.1 :sunflower:


Jump to definition does not work on objects defined as property on window

In my tern set up in emacs, this code works fine when I do M-. on util.foo:
var obj = {};
obj.foo = function() {
    return true;
};

obj.foo();

But when I do the same on the following, it says "No definition found."
window.obj = {};
obj.foo = function() {
    return true;
};

obj.foo();

I tried making each refernce to obj as window.obj. Doesn't seem to help. Am I missing something?

I just realized that it works on the online demo.
BTW, I tried using a new variable as namespace instead of window, and it works fine:
var ns = {};
ns.obj = {};
ns.obj.foo = function() {
  return true;
};

ns.obj.foo();

If I paste your example into a .js file and open it in emacs, I can Alt-. from foo on the last line to the definition of obj.foo just fine.

See my answer at http://stackoverflow.com/questions/29450235/jump-to-definition-does-not-work-on-objects-defined-as-property-on-window/30637975#30637975

@angelozerr, Great! It works. Thanks.