Comments in JSON config

In ESLint documentation it's said that comments are allowed.

JSON - use .eslintrc.json to define the configuration structure. ESLint's JSON files also allow JavaScript-style comments.

However sharec fails to apply them
sharec: × Configuration was not fully applyed due unexpected error
SyntaxError: Unexpected token / in JSON at position 868

Hello again :)
.eslint supports comments in json, but potentially we can read json with comments, but can't save them after merge. It is due because sharec is processing all configs as data-structures.

Maybe it's worth adding to documentation? I can try to update README

Yes, you can update root README and README in sharec package.

@AleksandrSl v2.3.0 will handle comments in json correctly


Thanos

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
This is a new feature added
Fixes # (#246)

#246
Add a Thanos snap effect to a webpage with JS.
Type of change
New feature

[x] New feature (non-breaking change which adds functionality)

Explain the Testing instructions
Test Configuration:

Operating system:
Version:
Text-editors used: VSCode

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

Thanos Effect added


Have a configurable timeout for connecting to snowflake before retrying

This adds a few helpers for retrying and timing out waiting for promises

converting to draft because there may be some cross contamination from testing - hold for now

closing in favor of #37


Add translator to yaml-header?

Should we add translator as a field in the yaml-header similar to author? And then building it into the project-file the same way we do for author (in the footer). That way we can give some credit also to the fine people doing the hard work of translating projects.

And put it in the footer, I guess?

Yes, exactly :)


Getting dropped into Insert Mode using Telescope

https://user-images.githubusercontent.com/57322459/220825282-a2ef4170-b4c7-4509-8b2d-2f93b873047b.mp4
To reproduce:

enable codeium (as shown in the beginning of the video, auto-completion works)
escape into Normal Mode
trigger <cmd>lua require('telescope.builtin').git_files()<CR> with C-g for finding files in Telescope
select target file
get dropped into Insert Mode (as seen by my random typing dfdfdf)

After disabling codeium, I no longer have this issue.
Any input is much appreciated. Thank you.

I have the same problem (using nvim v0.8.3 on ubuntu 22.04). I always thought it was my telescope that was broken until I saw this issue, and it's true that disabling Codeium removes the bug.

Yeah, I have the same issue too.

I have the same problem and found out if I disable hrsh7th/nvim-cmp the issue goes away. So the issue only appears if nvim-cmp and codeium are both installed.

OK, assuming that the culprit really was that redrawstatus call, I've fixed this by guarding it behind a check to see if the user is actually using GetCodeiumStatus.
If you're experiencing this bug and not using Codeium's status line, please let me know if this fixed the issue.

I still have this issue. In fact,  key does not change the mode from "Insert" to "Normal" when this plugin is installed.

notice that: the culprit could also be some plugin to call startinsert.

I'm also getting this issue until i remove codeium from my statusline.

I was just having this problem today.
Buffers were randomly being set into insert mode, mostly after using telescope to navigate.
After disabling the lualine configuration to show the status, everything seems to be working as expected


Bugfix/ixvy 3449 remove target class hack master

pr for branch 8.0 was accepted, this one here is the same stuff.


Completion for module specifiers

This PR provides completion for module specifiers. It works only if you type one character in the specifier. Ex :
import {L // here Ctrl+space shows List} from "./list"

The completion returns isSpecifier: true In my case (tern.java), I need that because my completion provides "List" and "List(head, tail)" (it's helpfull for function, but not for specifier).

Code related to import declarations does not belong in the modules plugin, which is a generic piece of infrastructure for all kinds of module systems. I've pushed an alternative patch that uses the existing isImport functionality to do this in a module-system-independent way.

Thanks @marijnh for your patch whcih works well and thanks to have keeping isSpecifier: true.
I finnd it's just shame that it doesn't work when no word are typed (I have found a solution to do that).

I looked at your code and didn't see anything to handle this situation. How did you detect that the cursor is in such a position?

Yes I know I had the same problem than you, I would like just tell you about this limitation and I hoped that you will find a solution, but I'm afraid that it is not possible.

You could do your own custom superficial parse of the source text to figure out whether the position is between braces in an import, but for now I think that's too much complexity.


Mistake in the implementation?

On page 7 of the paper, you can see that cnt starts at 0, it is still 0 when it is passed to the first hash function in the expand stage. It is then incremented according to s_cost. When cnt is used during the mix stage, its value is greater than its initial value.
In this implementation, cnt is initialised to 1, a reference is then passed to the expand function. In Python, integers are immutable so when it is incremented a copy is made and that copy is incremented, instead of incrementing the original. When cnt is passed to the first hash function in the expand stage, its value is 1. It is then incremented according to s_cost, but the accumulated value is thrown away at the end of the expand function, and when cnt is passed to mix, it is still its initial value.
As cnt is used in the security proof this divergence in the implementation should be considered a severe error. I suggest you stop breaking the balloon function up into sub functions, as how Python passes primitives to functions is confusing and is leading to mistakes.

Hmm I'm initializing it to 1 because I already pass the hash into the buffer with a cnt of 0 on the line before. See line 109.
This:
buf = [hash_func(0, password, salt)]
cnt = 1
expand(buf, cnt, space_cost)

is equivalent to their implementation:
buf[0] = hash(cnt++, passwd, salt)
for m from 1 to s_cost-1:
    buf[m] = hash(cnt++, buf[m-1])

See the update 5e1eb7acf00842

Just had a quick look and it looks fine now. You were right about the initial value, btw. Out of interest, did the default values for time_cost and space_cost come from the paper, or were they just chosen randomly? They seem on the low end to me.
Otherwise, good work, thank you.

This was a few years ago, but I believe I took them from the author's repo.


[FR] Allow previewing and/or editing (and pasting in) of board JSON while editing in UI

@aomarks Just checking in, is this one you wanted to look at at some stage? (Happy for you to reassign if yes, or leave it with me if no.)

@paullewis I have no plan currently to work on this

I think we're good on this one since we can now copy-paste etc.


Interested in Llamaindex integration

Can I use any other memory apart from Pinecone? Do you have plans to integrate with LlamaIndex?

Coming up today!

We also have added vector DBs like Chroma, Redis and Qdrant.


Code Health Fix

Fixes #42
We claim files in a spreadsheet.

@eagmon We have a few TODO comments throughout the codebase. What do you want to do with them? We could turn them into github issues, for example. I'm not sure what they all mean or if they're even still relevant, so maybe we should go through them all at some point and decide which we actually need to act on

@eagmon We have a few TODO comments throughout the codebase. What do you want to do with them? We could turn them into github issues, for example. I'm not sure what they all mean or if they're even still relevant, so maybe we should go through them all at some point and decide which we actually need to act on

@U8NWXD -- ignoring TODOs in pylint is good for now. I'll look through and remove/resolve the easy ones in this PR -- adding it to the spreadsheet.

@U8NWXD -- ignoring TODOs in pylint is good for now. I'll look through and remove/resolve the easy ones in this PR -- adding it to the spreadsheet.

We now have a composites/toys.py with many toy Processes and Composites that can be reused.

We now have a composites/toys.py with many toy Processes and Composites that can be reused.

@prismofeverything -- Since you are signed up for experiment test coverage you should know I moved experiment.py tests to a new file test_experiment.py, and some of it to composites/toys.py. Perhaps test_experiment.py should be moved out of core/. This reduced experiment.py by nearly 1000 lines! We've been doing great with tests there.

@prismofeverything -- Since you are signed up for experiment test coverage you should know I moved experiment.py tests to a new file test_experiment.py, and some of it to composites/toys.py. Perhaps test_experiment.py should be moved out of core/. This reduced experiment.py by nearly 1000 lines! We've been doing great with tests there.

@1fish2 I saw you added no-self-use to the list of disabled checks. I also encountered issues with that in abstract methods that could be overridden to use self, but I disabled no-self-use on just those lines since in general, I think it's good to make methods static where possible. What do you think?

@1fish2 I saw you added no-self-use to the list of disabled checks. I also encountered issues with that in abstract methods that could be overridden to use self, but I disabled no-self-use on just those lines since in general, I think it's good to make methods static where possible. What do you think?

Also why do we have pull_data? It doesn't look like we ever override it:
https://github.com/vivarium-collective/vivarium-core/blob/758a97aa6bda333330bc2bc6ff6ecd0077631814/vivarium/core/process.py#L411-L412

Also why do we have pull_data? It doesn't look like we ever override it:
https://github.com/vivarium-collective/vivarium-core/blob/758a97aa6bda333330bc2bc6ff6ecd0077631814/vivarium/core/process.py#L411-L412

no-self-use: Good question.
There's a design decision to make on each method: make it a class method or an instance method? That decision goes well beyond whether it happens to refer to self, e.g. whether subclasses are allowed to override it (that's the point of is_deriver(self)), whether it's about the instance or the class, whether it's used to create an instance without deriving it from another one, etc.
pylint is in no position to detect that design decision.
So my recommendation is to disable this pylint check and then we don't need the comments to locally disable it.
(This is putting aside the question of whether to remove/deprecate the "deriver" feature. Also, one can override a Python class method but that'll have subtle semantic differences.)
In a library with a wide outside world of possible clients, we can't change design decisions like these without breaking other people's programs. Before publishing the Vivarium paper we have to:

finalize some decisions like which methods are class methods
hide names that are intended to be private via the __all__ technique or the _xyz name technique
hide modules that are intended to be private

no-self-use: Good question.
There's a design decision to make on each method: make it a class method or an instance method? That decision goes well beyond whether it happens to refer to self, e.g. whether subclasses are allowed to override it (that's the point of is_deriver(self)), whether it's about the instance or the class, whether it's used to create an instance without deriving it from another one, etc.
pylint is in no position to detect that design decision.
So my recommendation is to disable this pylint check and then we don't need the comments to locally disable it.
(This is putting aside the question of whether to remove/deprecate the "deriver" feature. Also, one can override a Python class method but that'll have subtle semantic differences.)
In a library with a wide outside world of possible clients, we can't change design decisions like these without breaking other people's programs. Before publishing the Vivarium paper we have to:

finalize some decisions like which methods are class methods
hide names that are intended to be private via the __all__ technique or the _xyz name technique
hide modules that are intended to be private

pull_data() what is this method for? It is called from vivarium/core/experiment.py.
With the limited number of library clients outside our team so far, can we find out if we can safely remove any particular method or feature?

pull_data() what is this method for? It is called from vivarium/core/experiment.py.
With the limited number of library clients outside our team so far, can we find out if we can safely remove any particular method or feature?

TypedDict was added in Python 3.8. I used it in process.py, which is why the tests for Python 3.6 and 3.7 are failing. Do we need to keep supporting 3.6 and 3.7? My usage of TypedDict was pretty minor, so I'm fine either way

TypedDict was added in Python 3.8. I used it in process.py, which is why the tests for Python 3.6 and 3.7 are failing. Do we need to keep supporting 3.6 and 3.7? My usage of TypedDict was pretty minor, so I'm fine either way

For anyone working on adding type annotations, I created some types you can use:
Path = Union[Tuple[str, ...], Tuple[()]]
Topology = NewType('Topology', dict)
Schema = NewType('Schema', Dict[str, Any])
State = NewType('State', Dict[str, Any])
Update = NewType('Update', Dict[str, Any])

class CompositeDict(TypedDict):
    processes: Dict[str, 'Process']
    topology: Topology

The code is here.

For anyone working on adding type annotations, I created some types you can use:
Path = Union[Tuple[str, ...], Tuple[()]]
Topology = NewType('Topology', dict)
Schema = NewType('Schema', Dict[str, Any])
State = NewType('State', Dict[str, Any])
Update = NewType('Update', Dict[str, Any])

class CompositeDict(TypedDict):
    processes: Dict[str, 'Process']
    topology: Topology

The code is here.

@1fish2 -- pull_data() is used to emit information about a Process if it is flagged with self.emit=True, though I don't think it is ever used. We put it in there for the wcecoli_process in the wcEcoli repo, but no longer use it there either. Now we are just getting all the relevant data within that process' next_update, which is emitted as Store values. I think we should keep it just incase anyone wants to call emit on a Process.

@1fish2 -- pull_data() is used to emit information about a Process if it is flagged with self.emit=True, though I don't think it is ever used. We put it in there for the wcecoli_process in the wcEcoli repo, but no longer use it there either. Now we are just getting all the relevant data within that process' next_update, which is emitted as Store values. I think we should keep it just incase anyone wants to call emit on a Process.

@U8NWXD -- can you put the type annotations in a library perhaps? I believe there are files that can't import from Process due to circular imports.

@U8NWXD -- can you put the type annotations in a library perhaps? I believe there are files that can't import from Process due to circular imports.

@1fish2 -- "can we find out if we can safely remove any particular method or feature?" -- it would be very useful if we could. There are several dependent libraries now, and I believe it is only us or close collaborators.

@1fish2 -- "can we find out if we can safely remove any particular method or feature?" -- it would be very useful if we could. There are several dependent libraries now, and I believe it is only us or close collaborators.

@U8NWXD -- can you put the type annotations in a library perhaps? I believe there are files that can't import from Process due to circular imports.

Done @eagmon! I also removed TypedDict for now

@U8NWXD -- can you put the type annotations in a library perhaps? I believe there are files that can't import from Process due to circular imports.

Done @eagmon! I also removed TypedDict for now

btw I am working on a fix for the documentation failures. I need to add some code to help Sphinx resolve type references

btw I am working on a fix for the documentation failures. I need to add some code to help Sphinx resolve type references

I've removed the autodoc stubs from doc/reference/api. They are now autogenerated by Sphinx whenever we build the docs

I've removed the autodoc stubs from doc/reference/api. They are now autogenerated by Sphinx whenever we build the docs

@eagmon I'm seeing the following lint errors from composition.py and composites/toys.py:
************* Module vivarium.core.composition
vivarium/core/composition.py:432:0: C0301: Line too long (84/80) (line-too-long)
vivarium/core/composition.py:385:4: W0612: Unused variable 'experiment' (unused-variable)
vivarium/core/composition.py:392:4: W0612: Unused variable 'experiment' (unused-variable)
vivarium/core/composition.py:10:0: W0611: Unused Composite imported from vivarium.core.process (unused-import)
************* Module vivarium.composites.toys
vivarium/composites/toys.py:348:8: R1725: Consider using Python 3 style super() without arguments (super-with-arguments)

-------------------------------------------------------------------
Your code has been rated at 9.95/10 (previous run: 10.00/10, -0.05)

Are you working on those files? I can go ahead and fix those errors if you aren't

@eagmon I'm seeing the following lint errors from composition.py and composites/toys.py:
************* Module vivarium.core.composition
vivarium/core/composition.py:432:0: C0301: Line too long (84/80) (line-too-long)
vivarium/core/composition.py:385:4: W0612: Unused variable 'experiment' (unused-variable)
vivarium/core/composition.py:392:4: W0612: Unused variable 'experiment' (unused-variable)
vivarium/core/composition.py:10:0: W0611: Unused Composite imported from vivarium.core.process (unused-import)
************* Module vivarium.composites.toys
vivarium/composites/toys.py:348:8: R1725: Consider using Python 3 style super() without arguments (super-with-arguments)

-------------------------------------------------------------------
Your code has been rated at 9.95/10 (previous run: 10.00/10, -0.05)

Are you working on those files? I can go ahead and fix those errors if you aren't

@U8NWXD -- go ahead and fix the lint errors, thanks!

@U8NWXD -- go ahead and fix the lint errors, thanks!

Re making types more specific: I think we're blocked by the fact that
mypy doesn't support recursive types
https://github.com/python/mypy/issues/731. Given that constraint, I
don't see how to make them any more specific. I'm open to doing that though
if you see a way!
Re NewType vs Class vs Alias: I agree with making these types into full
classes eventually. ... Therefore it should be really easy to replace the
Topology type with a full class later on if we want to. This is why I
used NewType instead of just a type alias.

Aha. I was confusing a topology spec (et al) that clients pass in with a
topology structure that the library deals with internally.
The latter can be an ordinary class, maybe subclassing dict or not, and we
use that class name. No mypy recursion problem. These types help us
understand and cross-check the library code. They can be NewTypes for now
or go ahead and define the classes soon, perhaps after the first pass of
this PR work.
The former types are important for users to learn, understand, and
type-check their code. These are the ones to have more details such as what
I wrote for Config.
Name them like Topology and TopologySpec? TopologyImpl and Topology? Or...?

Re making types more specific: I think we're blocked by the fact that
mypy doesn't support recursive types
https://github.com/python/mypy/issues/731. Given that constraint, I
don't see how to make them any more specific. I'm open to doing that though
if you see a way!
Re NewType vs Class vs Alias: I agree with making these types into full
classes eventually. ... Therefore it should be really easy to replace the
Topology type with a full class later on if we want to. This is why I
used NewType instead of just a type alias.

Aha. I was confusing a topology spec (et al) that clients pass in with a
topology structure that the library deals with internally.
The latter can be an ordinary class, maybe subclassing dict or not, and we
use that class name. No mypy recursion problem. These types help us
understand and cross-check the library code. They can be NewTypes for now
or go ahead and define the classes soon, perhaps after the first pass of
this PR work.
The former types are important for users to learn, understand, and
type-check their code. These are the ones to have more details such as what
I wrote for Config.
Name them like Topology and TopologySpec? TopologyImpl and Topology? Or...?

... and if TopologySpec wants to be recursive, just use Any or object in
that spot with a comment.

... and if TopologySpec wants to be recursive, just use Any or object in
that spot with a comment.

We now have a new core file, tree.py, for the Store object that was previously in experiment.py. This brings experiment.py down to about 500 lines -- so those tests can reasonably go back to experiment.py now... tree.py is about 1000 lines. I think these are more reasonably-sized, and within the pylon default limit. @prismofeverything -- I added tree.py to our spreadsheet, and added your name under what you had on experiment.py.

We now have a new core file, tree.py, for the Store object that was previously in experiment.py. This brings experiment.py down to about 500 lines -- so those tests can reasonably go back to experiment.py now... tree.py is about 1000 lines. I think these are more reasonably-sized, and within the pylon default limit. @prismofeverything -- I added tree.py to our spreadsheet, and added your name under what you had on experiment.py.

Aha. I was confusing a topology spec (et al) that clients pass in with a
topology structure that the library deals with internally.

The latter can be an ordinary class, maybe subclassing dict or not, and we
use that class name. No mypy recursion problem. These types help us
understand and cross-check the library code. They can be NewTypes for now
or go ahead and define the classes soon, perhaps after the first pass of
this PR work.

I'm not seeing what this distinction buys us. Take Topology for example, it needs to support key-value pairs of strings as well as arbitrary nesting. This means all of the following are valid topologies:
topo = {
    "a": "b",
}
topo = {
    "a": {
        "b": "c",
    },
}
topo = {}

We'd like to specify that the topology, both the "topology spec" and the "topology structure," should have strings as keys, and either strings or topologies as values. This requires recursive types.

The former types are important for users to learn, understand, and
type-check their code. These are the ones to have more details such as what
I wrote for Config.

@1fish2 I'm assuming you are referring to this type for Config: Config = Dict[str, Dict[str, Any]]. I don't think this config will work because it doesn't allow top-level values to be strings, which we often use. For example, this config wouldn't be allowed:
config = {
    'key': 'val',
}

Aha. I was confusing a topology spec (et al) that clients pass in with a
topology structure that the library deals with internally.

The latter can be an ordinary class, maybe subclassing dict or not, and we
use that class name. No mypy recursion problem. These types help us
understand and cross-check the library code. They can be NewTypes for now
or go ahead and define the classes soon, perhaps after the first pass of
this PR work.

I'm not seeing what this distinction buys us. Take Topology for example, it needs to support key-value pairs of strings as well as arbitrary nesting. This means all of the following are valid topologies:
topo = {
    "a": "b",
}
topo = {
    "a": {
        "b": "c",
    },
}
topo = {}

We'd like to specify that the topology, both the "topology spec" and the "topology structure," should have strings as keys, and either strings or topologies as values. This requires recursive types.

The former types are important for users to learn, understand, and
type-check their code. These are the ones to have more details such as what
I wrote for Config.

@1fish2 I'm assuming you are referring to this type for Config: Config = Dict[str, Dict[str, Any]]. I don't think this config will work because it doesn't allow top-level values to be strings, which we often use. For example, this config wouldn't be allowed:
config = {
    'key': 'val',
}

After discussion with @eagmon, I'm going to make my types type aliases instead of NewTypes to reduce the difficulty of this migration

After discussion with @eagmon, I'm going to make my types type aliases instead of NewTypes to reduce the difficulty of this migration

I'm not seeing what this distinction buys us. Take Topology for example, it needs to support key-value pairs of strings as well as arbitrary nesting. This means all of the following are valid topologies:
topo = {
    "a": "b",
}
topo = {
    "a": {
        "b": "c",
    },
}
topo = {}

To me, these look like specifications of networks to build, in contrast with run-time objects that would have methods to walk and edit the network of Processes and Stores. That's my conceptual distinction.
Maybe Vivarium doesn't need those run-time objects since it deals directly with the constructed Processes and Stores, or maybe those run-time objects are Compartments? Apologies for not having time to fully read the docs! This is why I'd like to discuss it in a meeting.

We'd like to specify that the topology, both the "topology spec" and the "topology structure," should have strings as keys, and either strings or topologies as values. This requires recursive types.

Type systems are limited, so one approach is to use Any (with a comment) in a nested slot that should be a recursive type reference.
Another approach is to use a named class which does support recursive types:
from __future__ import annotations

from typing import List, Optional

class Tree:
    def __init__(self, left: Optional[Tree], right: Optional[Tree]) -> None:
        super().__init__()
        self.left: Optional[Tree] = left
        self.right: Optional[Tree] = right
        self.subs: List[Tree] = []
        if left:
            self.subs.append(left)
        if right:
            self.subs.append(right)

(Without __future__ annotations, the arg types need to be Optional['Tree'] to handle forward references to the not-yet-defined class but the instance variable types needn't. You can see why this future is an improvement.)

The former types are important for users to learn, understand, and
type-check their code. These are the ones to have more details such as what
I wrote for Config.

@1fish2 I'm assuming you are referring to this type for Config: Config = Dict[str, Dict[str, Any]]. I don't think this config will work because it doesn't allow top-level values to be strings, which we often use. For example, this config wouldn't be allowed:
config = {
    'key': 'val',
}

Isn't a config a dict of process name -> process parameter name -> process parameter value? Or is that only a Composite config? Some of the types I put in were straw-mans for feedback.
Nominal types or type aliases could help document these things more clearly like maybe:
ProcessName = str
ProcessParameterName = str
ProcessParameterValue = Any
ProcessConfig = Dict[ProcessParameterName, ProcessParameterValue]
CompositeConfig = Dict[ProcessName, ProcessConfig]

I'm not seeing what this distinction buys us. Take Topology for example, it needs to support key-value pairs of strings as well as arbitrary nesting. This means all of the following are valid topologies:
topo = {
    "a": "b",
}
topo = {
    "a": {
        "b": "c",
    },
}
topo = {}

To me, these look like specifications of networks to build, in contrast with run-time objects that would have methods to walk and edit the network of Processes and Stores. That's my conceptual distinction.
Maybe Vivarium doesn't need those run-time objects since it deals directly with the constructed Processes and Stores, or maybe those run-time objects are Compartments? Apologies for not having time to fully read the docs! This is why I'd like to discuss it in a meeting.

We'd like to specify that the topology, both the "topology spec" and the "topology structure," should have strings as keys, and either strings or topologies as values. This requires recursive types.

Type systems are limited, so one approach is to use Any (with a comment) in a nested slot that should be a recursive type reference.
Another approach is to use a named class which does support recursive types:
from __future__ import annotations

from typing import List, Optional

class Tree:
    def __init__(self, left: Optional[Tree], right: Optional[Tree]) -> None:
        super().__init__()
        self.left: Optional[Tree] = left
        self.right: Optional[Tree] = right
        self.subs: List[Tree] = []
        if left:
            self.subs.append(left)
        if right:
            self.subs.append(right)

(Without __future__ annotations, the arg types need to be Optional['Tree'] to handle forward references to the not-yet-defined class but the instance variable types needn't. You can see why this future is an improvement.)

The former types are important for users to learn, understand, and
type-check their code. These are the ones to have more details such as what
I wrote for Config.

@1fish2 I'm assuming you are referring to this type for Config: Config = Dict[str, Dict[str, Any]]. I don't think this config will work because it doesn't allow top-level values to be strings, which we often use. For example, this config wouldn't be allowed:
config = {
    'key': 'val',
}

Isn't a config a dict of process name -> process parameter name -> process parameter value? Or is that only a Composite config? Some of the types I put in were straw-mans for feedback.
Nominal types or type aliases could help document these things more clearly like maybe:
ProcessName = str
ProcessParameterName = str
ProcessParameterValue = Any
ProcessConfig = Dict[ProcessParameterName, ProcessParameterValue]
CompositeConfig = Dict[ProcessName, ProcessConfig]

Two questions:

Processes support self-registering when given a _register key in their parameters. Do we still use this, or can it be removed?
Should generate_processes and generate_topology be private methods? I think we'd always call generate() instead of the 2 other functions, right?

It looks like from __future__ import annotations doesn't work in python 3.6 or 3.7. Should we drop support for those versions?

It looks like from __future__ import annotations doesn't work in python 3.6 or 3.7. Should we drop support for those versions?

@U8NWXD -- I think it's okay to drop support for 3.6 and 3.7.

@U8NWXD -- I think it's okay to drop support for 3.6 and 3.7.

@U8NWXD -- I dropped support for 3.6 and 3.7 in the GitHub workflows with c9f8257

@U8NWXD -- I dropped support for 3.6 and 3.7 in the GitHub workflows with c9f8257

@U8NWXD -- have we decided what to do about test coverage for items under if __name__ == '__main__':? It would be nice to keep them running, but they are not covered by tests. You mentioned the possibility of somehow marking them individually to be ignored.

@U8NWXD -- have we decided what to do about test coverage for items under if __name__ == '__main__':? It would be nice to keep them running, but they are not covered by tests. You mentioned the possibility of somehow marking them individually to be ignored.

Per pylint #1970, the tool to do PEP8 checks is pycodestyle. The fact that pylint checks some PEP8 details is historical.

Per pylint #1970, the tool to do PEP8 checks is pycodestyle. The fact that pylint checks some PEP8 details is historical.

I added "pragma: no cover" to the exclude_lines in pytest.ini. This can now be used to selectively ignore lines from the pytest coverage test by adding it in a comment, as is needed for anything under if __name__ == '__main__'::
test_composite_in_experiment()  # pragma: no cover

I added "pragma: no cover" to the exclude_lines in pytest.ini. This can now be used to selectively ignore lines from the pytest coverage test by adding it in a comment, as is needed for anything under if __name__ == '__main__'::
test_composite_in_experiment()  # pragma: no cover


Update core-runtime version

Update core version image.
Removes latest so we don't have to trigger build using blank commits

duplicate pr


github-sync setup for sigstore-js

Summary
Setting-up some of the github-sync config for the sigstore-js repo.
Release Note
NONE
Documentation
NONE

thanks!
closing in favor of https://github.com/sigstore/community/pull/84


ins function problems

Sometimes the ins function includes the head itself into the header and reloads all the scripts, firing double requests for scripts/styles. I can't precisely find the case but I saw it happening. I added break point on subtree modified in chrome and I could see that ins replaces the whole head.

This should be fixed in spin.js v3.0.


Qrda 5 1 errata

Pull requests into cqm-parsers require the following. Submitter and reviewer should :white_check_mark: when done. For items that are not-applicable, note it's not-applicable ("N/A") and :white_check_mark:.
Submitter:

[ ] This pull request describes why these changes were made.
[ ] Internal ticket for this PR:
[ ] Internal ticket links to this PR
[ ] Code diff has been done and been reviewed
[ ] Tests are included and test edge cases
[ ] Tests have been run locally and pass

Reviewer 1:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Reviewer 2:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Codecov Report

Merging #73 into cqm_reports_2_x will increase coverage by 0.03%.
The diff coverage is 100%.

@@                 Coverage Diff                 @@
##           cqm_reports_2_x      #73      +/-   ##
===================================================
+ Coverage             89.2%   89.23%   +0.03%
===================================================
  Files                   68       66       -2
  Lines                 1760     1747      -13
===================================================
- Hits                  1570     1559      -11
+ Misses                 190      188       -2

Impacted Files
Coverage Δ

lib/cqm_report.rb
100% <ø> (ø)
:arrow_up:

lib/qrda-import/patient_importer.rb
94.23% <100%> (+0.68%)
:arrow_up:

lib/util/code_system_helper.rb
87.5% <0%> (-1.39%)
:arrow_down:

lib/util/hqmf_template_helper.rb
95.65% <0%> (-0.19%)
:arrow_down:

lib/qrda-export/helper/frequency_helper.rb
100% <0%> (ø)
:arrow_up:

lib/qrda-export/helper/date_helper.rb
97.72% <0%> (+2.27%)
:arrow_up:

lib/util/qrda_template_helper.rb
55.55% <0%> (+5.55%)
:arrow_up:

Continue to review full report at Codecov.

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


IO Max, Read and Write meaning

Hello, i do not fully understand this meaning:
  Mem.:    4.50% -     1.43G/31.42G   | IO Max:    27580/s
  Swap:    0.40% -    33.59M/7.45G    | Read :      1.15M/s -    294/s
  Load:    2.05 2.20 2.15             | Write:      7.91K/s -      1/s

IO MAX -- is it "max IOPS (Read + Write) for all time?"
Read: 294/s -- is it mean 294 IOPS for Read Operations?
Write: 1/s is it mean 1 IOPS for Write Operations?
Could you please clarify and update documentation?

Explanations can be found in #213; I agree we should document them.

Fixed by #215, information will be available in the man page.


Please elaborate on decimal and Guid types passed as in arguments

This practice often improves performance for readonly value types that are larger than IntPtr.Size. For simple types (sbyte, byte, short, ushort, int, uint, long, ulong, char, float, double, decimal and bool, and enum types), any potential performance gains are minimal. In fact, performance may degrade by using pass-by-reference for types smaller than IntPtr.Size.
sizeof(decimal) == 16 which is double the IntPtr.Size on all 64bit platforms. Can you explain why is it listed having no to minimal performance gain?
On the contrary, also sizeof(Guid) == 16 but Guid is not in the list. Does the same apply?

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

ID: ac8804c7-6acd-ab2a-4e14-0b99265969a5
Version Independent ID: 183efcbd-a781-d303-f9cd-1c22da1676de
Content: Write safe and efficient C# code
Content Source: docs/csharp/write-safe-efficient-code.md
Product: dotnet-csharp
Technology: csharp-advanced-concepts
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Thanks for writing this @Slaviusz
The list of simple types doesn't include Guid because it's not named in the C# language spec. It is an unmanaged type of similar size, but it's not mentioned as such in the C# language spec.
In general, any low-level optimizations like this should be measured before making changes. I doubt that 16 bytes would make much of a difference unless it's in a method that's in a time critical hot path for your application.
I'll keep this open because I do want to make other changes to this article, and I'll address this at that time.

Thanks for writing this @Slaviusz
The list of simple types doesn't include Guid because it's not named in the C# language spec. It is an unmanaged type of similar size, but it's not mentioned as such in the C# language spec.
In general, any low-level optimizations like this should be measured before making changes. I doubt that 16 bytes would make much of a difference unless it's in a method that's in a time critical hot path for your application.
I'll keep this open because I do want to make other changes to this article, and I'll address this at that time.


Use history.createLocation in

Currently, there is an inconsistency between the pseudo-history used by the <StaticRouter> and the histories created by the history package because the history package creates locations with decoded pathnames, while the pseudo-history does not. This PR updates the <StaticRouter> to use the createLocation function from the history package to ensure consistent decoding between <StaticRouter> and the other routers.
Fixes #5296. #5359 is also partially fixed by this, but that also includes matchPath tests which are outside the scope of this PR.

Can this please get merged? This is a pretty serious issue for SSR.

Oh bother, I messed up that conflict fix.

Do you have contributor commits turned on? I can try and help you out.

Thanks for the offer, but I think I got it figured out. I had re-fetched the branch, but it was rebased onto a copy of the local master, which seems to behave differently than rebasing against master.
# what I had done
git checkout -b static-history
git pull origin static-history

# what I probably should have done
git fetch origin
git checkout origin/static-history
git checkout -b static-history

TMYK
Anyways, the build issue still seems to exist, so if you don't get to it, I can probably check it out later.

Weird. There were no recent changes on master and everything is locked, so the last chance of breakage was whenever the lockfiles changed.

It looks like the build issues have been sorted out.

In she goes!

Hi, any ideas when this will be released? Currently, I'm having to patch React Router locally in order to apply these changes.

Anytime between now and the future. I've been waiting on some release tooling from Michael, but he's been busy with a few other projects.


Only parse valid json

Closes #12

cc @TwitchBronBron

More than happy to do it that way. I've updated the PR.
Although I have to say I really disagree with the approach. Setting a flag to NOT parse json is counter intuitive, and kinda against the design of every requests lib in other languages.
Most languages (js, python, etc) with have an explicit json() method on the response that will trigger the parsing.
I understand that this is a breaking change, but since roku-requests is at version 0.2.0, which means it has not committed to a stable API yet, I think it should be acceptable (better yet encourage) to do the breaking change for the sake of better design. At least if we're following semantic versioning.
To justify what I did on my first attempt: I knew there will be concerns for breaking changes, that's why I opted for checking the content-type. In my opinion, any server returning invalid content type is non-compliant and it should be treated as a bug (and still, these are pretty rare anyway) so my attempt was to only parse valid json in most cases. But even on this first attempt, I still think it's better to rip the bandaid off and make the breaking change. The impact is so minimal anyway.
Users will have to change code from

I completely agree with your assessment. However, we inherited/rescued this project from another developer that wasn't able to maintain it anymore. The ropm published version 0.2.0 was because I didn't want to make it 1.0.0 until I figured out if the ropm version was functional. Then, I completely forgot to bump the version to 1.0.0. This library has been around for ages, and as such, I should go ahead and bump the version to 1.0.0 so that's clear.
If you're interested, we could start the process of working towards a v2 release, but I'd like to make sure we clearly thought through additional breaking changes so we could group them together.

@TwitchBronBron I'm fine with that, we can merge this as is, and figure out v2 as we go. Thanks!

Great! I just kicked off the v1.0.0 release. Then I'll merge this and cut a 1.1.0 release. Thanks!


ci: specify comparison level

@cristianmtr any context on this PR? Can you add the details on why this is needed?

@cristianmtr any context on this PR? Can you add the details on why this is needed?

Yes, thanks for noticing. Atm the Hub Updater is only testing if the minor versions match, but we want to also test on patch releases. See https://github.com/jina-ai/action-hub-updater/pull/1/files#diff-1243c5424efaaa19bd8e813c5e6f6da46316e63761421b3e5f5c8ced9a36e6b6R18


5.14.6

[x] I have followed (at least) the PR section of the contributing guide.

@siriwatknp Appreciate it if you could review and include this 🙏 https://github.com/mui/material-ui/pull/38597
(A small fix, minutes to review)


BN_clear_free vs BN_free inconsistency

It is expected behaviour of functions to be same except as is documented "BN_clear_free() additionally overwrites the data before the memory is returned to the system", quoted from https://www.openssl.org/docs/man1.1.0/crypto/BN_clear_free.html .
Unfortunately in 1.1.0 branch clear is performed even data is non fried. It seems to me issue is fixed in master.
I would like to request manual page to be updated to inform that BN_clear_free has bug in 1.1.0.
For instance following snipped could demonstrate defect.
d2 = BN_new();
BN_with_flags(d2, d1, 0);
BN_clear_free(d2);   <- error d1 is cleared as well

That's a bug and we should fix the code not the docs.  Thanks for reporting it.

Rich Salz wrote:

That's a bug and we should fix the code not the docs.  Thanks for reporting it.

Actually it is long standing bug.
BN_with_flags is added after 0.9.7g and BN_clear_free() is from SSLEay
code 0.9.1c.
So idea is to write that 1.1.1 is first version that allows
BN_clear_free() for number initialized by BN_with_flags().
Code correction by 5f2d9c4d26c923ece6ee04616a2d32a1afc124c8
Regards,
Roumen

Well using BN_with_flags() brings with it a set of restrictions which are clearly documented in the man page:
BN_with_flags creates a B<temporary> shallow copy of B<b> in B<dest>. It places
significant restrictions on the copied data. Applications that do no adhere to
these restrictions may encounter unexpected side effects or crashes. For that
reason use of this function is discouraged. Any flags provided in B<flags> will
be set in B<dest> in addition to any flags already set in B<b>. For example this
might commonly be used to create a temporary copy of a BIGNUM with the
B<BN_FLG_CONSTTIME> flag set for constant time operations. The temporary copy in
B<dest> will share some internal state with B<b>. For this reason the following
restrictions apply to the use of B<dest>:

=over 2

=item *

B<dest> should be a newly allocated BIGNUM obtained via a call to BN_new(). It
should not have been used for other purposes or initialised in any way.

=item *

B<dest> must only be used in "read-only" operations, i.e. typically those
functions where the relevant parameter is declared "const".

It seems clear to me that BN_clear_free() could not be classed as a "read-only" operation. So, I don't think this is really a bug - it's just another manifestation of the underlying restrictions of BN_with_flags(). The fact that you can do it in master is co-incidental - you shouldn't really be doing it there either. It just happens to work.

Closing as not-a-bug.


python38Packages.west: 0.11.0 -> 0.11.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.west is: "Zephyr RTOS meta tool"
meta.homepage for python38Packages.west is: "https://github.com/zephyrproject-rtos/west"
meta.changelog for python38Packages.west is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

/nix/store/4qygi8amv1k24lns11ffffxi6qngs7za-python3.8-west-0.11.1/bin/west passed the binary check.

/nix/store/4qygi8amv1k24lns11ffffxi6qngs7za-python3.8-west-0.11.1/bin/.west-wrapped passed the binary check.

2 of 2 passed binary check by having a zero exit code.

0 of 2 passed binary check by having the new version present in output.

found 0.11.1 with grep in /nix/store/4qygi8amv1k24lns11ffffxi6qngs7za-python3.8-west-0.11.1

found 0.11.1 in filename of file in /nix/store/4qygi8amv1k24lns11ffffxi6qngs7za-python3.8-west-0.11.1

directory tree listing: https://gist.github.com/2d3b55b2bf72c993910293523419a973

du listing: https://gist.github.com/bba5c67de1059fe38287954e97660222

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
python38Packages.west
python39Packages.west

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/4qygi8amv1k24lns11ffffxi6qngs7za-python3.8-west-0.11.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.west https://github.com/r-ryantm/nixpkgs/archive/8ab1b0ed66a993bd3dd4389df2ce5a592239e1ba.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/4qygi8amv1k24lns11ffffxi6qngs7za-python3.8-west-0.11.1
ls -la /nix/store/4qygi8amv1k24lns11ffffxi6qngs7za-python3.8-west-0.11.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python38Packages.west
python39Packages.west

Maintainer pings
cc @siriobalmelli for testing.

Result of nixpkgs-review pr 135370 at 8ab1b0ed run on aarch64-linux 1

2 packages built successfully:

python38Packages.west
python39Packages.west


iOS to Android Calls not connecting

Can you help me to resolve this issue ?

Hi! First of all, thank you for trying to run this project :)
Then, Could you tell me your environment? (Especially, for Android)
Does Android use some browser or not?


Avoiding regex problems with newest version of require-all

require-all does not play well with non-capturing groups regex in their latest version, which makes systemic not to work with it.
I've created this PR for require-all: https://github.com/felixge/node-require-all/pull/43
Regardless of whether it's accepted or not, this would fix the issue.

Thanks


Connecting to a node & blockscout

Pull Request Description
Connecting to a node & blockscout

Thankyou @alexandratran :)


Allow images to be bundled within the walkthroughs themselves

Currently images are included in a separate images directory which
is provided by the server. However, when users want to add their
own walkthroughs they won't be able to add images directly to this
repo. It'd also mean that their adoc wouldn't render correctly
locally as the image would be in a separate location.
A second issue also resolved by this commit is that, although you can
specify WALKTHROUGH_LOCATIONS it does not reflect in the web app.
The changes made in this commit provide a dynamic static route in
the server to allow for the files of each walkthrough to be served
using the same path as if you were previewing them locally. For
example: image::my.png will now work both locally and in the web app
(assuming that my.png is in the same directory as the adoc file).
The frontend has been updated to accomodate for these changes. Using
the new endpoint instead of the static /public endpoints from before.
Finally, the images from /public/images have been moved into their
respective walkthroughs and placed in an images/ subdirectory.

@pb82 Would you mind taking a look? Some verification steps:

Ensure that a default run yarn start:dev renders images correctly for each walkthrough.
Clone public/walkthroughs out to a temporary dir.
Restart the server, pointing at the temp dir e.g. WALKTHROUGH_LOCATIONS=/tmp/walkthroughs yarn start:dev.
Make a change to a walkthrough in the temp dir (add a new image for example) and ensure it's reflected in the web app after a refresh. This ensures the web app isn't just using the default walkthroughs.

👀


#13136: Consolidate all_gather and line_all_gather to common api

Tracking Issue : #13136
Merge line_all_gather into all_gather
Checklist

[x] Post commit CI passes - https://github.com/tenstorrent/tt-metal/actions/runs/11068535951
[x] TG frequent test - https://github.com/tenstorrent/tt-metal/actions/runs/11070625778
[x] T3K frequent test - https://github.com/tenstorrent/tt-metal/actions/runs/11066564444
[x] T3K nightly test - https://github.com/tenstorrent/tt-metal/actions/runs/11068495385
[ ] Blackhole Post commit (if applicable)
[ ] Model regression CI testing passes (if applicable)
[ ] Device performance regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

Please run the TG Frequent pipeline

Please run the TG Frequent pipeline

It has passed, updated in PR description

Thanks @SeanNijjar for topology arg, I have left it as cluster axis api will work with line by default, I will update it

Hey @Aswinmcw, I was looking through some other All-gather code and I saw that you'll also need to update create_all_gather_struct to accomodate the line topology (https://github.com/tenstorrent/tt-metal/pull/13148/files#diff-9c0e3c69ba3dfcf18147c98bbd7f82b9d0fd59f7c38a62c5ef5f05994588cbacR32)

Please also run model perf regression


Entity fails instance test after being restored from a mocked module.

Describe the bug
If module contains a declaration of a custom error, and that error is used in the test as a part of a mocked module, that error will fail an instance test
Reproduction
https://stackblitz.com/edit/vitest-dev-vitest-tycktq?file=src/consumer.test.ts
System Info
System:
    OS: macOS 12.6.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 85.42 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.18.1 - ~/.volta/tools/image/node/16.18.1/bin/node
    Yarn: 1.22.19 - ~/.volta/tools/image/yarn/1.22.19/bin/yarn
    npm: 8.19.2 - ~/.volta/tools/image/npm/8.19.2/bin/npm
  Browsers:
    Chrome: 107.0.5304.121
    Firefox: 107.0
    Safari: 15.6.1
  npmPackages:
    vitest: 0.25.3 => 0.25.3

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Well, it cannot be the same, because you are mocking ./api, and then using original CustomError. So, every instance of ./api is holding different references to the actual ./api.
When you import from ./api you are importing from mock:./api. When you import actual module, you are importing from ./api.
You would need to use vi.importMocked or import to get the same reference.

I turned it the other way round and do not get the mock then https://stackblitz.com/edit/node-26y25a?file=src%2Fconsumer.ts,src%2Fconsumer.test.ts
Well, I probably do not understand the concept of partial module mocking, as a person migrating from jest environment. There it is possible and exactly this way; I would, of course, not like to compare, because vitest has a different runtime, but is it possible at all (partial mocking)? And what am I doing wrong?
In which example would getResult be a proper mock and CustomError an original error constructor from a module?

I turned it the other way round and do not get the mock then https://stackblitz.com/edit/node-26y25a?file=src%2Fconsumer.ts,src%2Fconsumer.test.ts
Well, I probably do not understand the concept of partial module mocking, as a person migrating from jest environment. There it is possible and exactly this way; I would, of course, not like to compare, because vitest has a different runtime, but is it possible at all (partial mocking)? And what am I doing wrong?
In which example would getResult be a proper mock and CustomError an original error constructor from a module?

Automocking is implemented in a different way, so you might encounter some problems with it. But your issue looks more like "I'm testing a use of a local variable, but mocking it externally", which is not possible with Vitest, and only possible in jest when using ts-jest, because it transpires the wrong output.
With your example I don't think it's possible to keep both of these in the same file, but keep Error as "original", so I would put them in a separate file.

My example is simplified, in a real scenario a separate file would mean a separate package, extracting an error class from its own context (package) wouldn't be an option at all.

As I said before, what you are trying to achieve is not really possible without a major rewrite.


chore: disable `dedicated_config_processing by default

DO NOT MERGE | This patch exists only to simplify the switch-back to the old default

We have decided to go this route (turn it OFF by default). Rewording the PR request body, making it un-draft and rebasing as a result.

related test fails

fixed


Move alphalong toggle to developerpanel

Also fix two design errors in the developerPanel:
1 - the non release toggles would only disappear after ignition on the release branch;
2 - cars without longitudinal control could activate longitudinal maneuvers.

[x] test release mechanic
[x] test no and alphalong cars
[x] remove duplicated in settings

Can you split out any potential bug fixes from this PR?

Can you split out any potential bug fixes from this PR?

split in #34006

Can you reopen a clean version?


Function apps with headless chrome works in consumption plan but not in premium plan

We can't run headless Chrome in a function app hosted in a premium plan, but it works in consumption plan.
We have two function apps running on an elastic premium plan (EP1:1). One is using dotnet and Puppeteer Sharp library, and the other one Python and Pyppeteer library. Both are located in West Europe.
- C# dotnet function app
Throw the following error:
2021-05-19T07:26:42.342176771Z       Executed (Failed, Id=5687ac18-143f-4faf-a4e7-160b567a9a0c, Duration=103ms)
2021-05-19T07:26:42.342947961Z  ---> PuppeteerSharp.ProcessException: Failed to launch Base! [0519/072642.021600:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
- Python function app
Throws the following error:
2021-05-19T07:16:10.624 [Error] Executed (Failed, Id=9f65d621-67bd-4529-a877-059ebb87f1b9, Duration=30046ms)Result: FailureException: BrowserError: Browser closed unexpectedly
We learned that the base images were not updated with the right dependencies for launching headless Chrome and tried to change the property linusFxVersion in the function apps to these base images, which are supposed to have the dependencies needed, using az CLI:

Dotnet: mcr.microsoft.com/azure-functions/python:3.7
Python: mcr.microsoft.com/azure-functions/python:3.0-python3.7

We are still getting the same error as shown above.
We also tried running the dotnet function app as a custom container and adding the dependencies manually there but still got issues. These are the steps we tried and their outcome:
#####################################################################
When running with the Visual Studio auto generated Dockerfile + adding installed dependencies, function app itself is running but the function throws this error:
2021-05-06T16:34:11.404380645Z  ---> PuppeteerSharp.ProcessException: Failed to launch Base!
[0506/163411.280771:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported.
See https://crbug.com/638180.
#####################################################################
When adding a new non-root user:
"Failed to launch Base! [0506/181428.176134:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox!
Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md
for more information on developing with the SUID sandbox."
####################################################################
When adding this line at the end of the Dockerfile to enable namespace cloning as per suggested in the link above:
CMD["sudo sysctl -w kernel.unprivileged_userns_clone=1"]
The container logs shows this error:
"Docker API responded with status code=BadRequest, response={"message":"OCI runtime create failed:
container_linux.go:370: starting container process caused:
exec: "sudo sysctl -w kernel.unprivileged_userns_clone=1": executable file not found in $PATH: unknown"}"
Found this in a Stackoverflow thread related to this command:
"Since Docker containers share the host system's kernel and its settings, a Docker container usually can't run sysctl at all."
We have an open ticket with Microsoft with TrackingID#2104220050002234 and they suggested that we open a public issue here on GitHub.

Thank you! Our prior is to get the dotnet function app working though - the Python function app was only created as a plan B since it didn't work with dotnet.


openssl_random_pseudo_bytes is not used anymore

Just a code cleanup.
openssl_random_pseudo_bytes was replaced earlier by random_bytes (php7)

Good catch, thanks @Rotzbua.

@fettymkima I guess you posted your comment in the wrong place..


How can I change the font style to Times New Roman

Hi,
How can I change the font style to the Times New Roman in sumo?
Thanks

All the Sumo plotting tools have a --font option. In principle, using your favourite font is as simple as, e.g. --font='Times New Roman'.
In practice, the font name will be passed to Matplotlib. It is not always very obvious what name Matplotlib is looking for, and not all font formats are accepted (I think it needs to be TTF or OTF). Please look for information on how to use Times New Roman with Matplotlib for your operating system. (On Linux it is probably necessary to install the MS core fonts and refresh Matplotlib's cache.) You should then be able to pass the appropriate name as e.g. --font='Times New Roman'.
If you get the error message findfont: Font family ['sans-serif'] not found. Falling back to ... this means that the font name was not recognised. (It isn't really anything to do with being sans-serif, that's just the family we temporarily put user-requested fonts into.)
On my system I find "Nimbus Roman" is an acceptable substitute.

Dear Jackson,
I have tried all these but I could not get sucess.
Is there anyway to update the matplotlib in such a way that it import the Times New Roman (TNR) font when we execute sumo-bandplot?
I am sure, every user will face this issue who wish to use TNR.

Dear Jackson,
I have tried all these but I could not get success.
Is there anyway to update the matplotlib in such a way that it imports the Times New Roman (TNR) font when we execute sumo-bandplot?
I am sure, every user will face this issue who wish to use TNR.

Improving Matplotlib's font manager is way out of scope for this project, I'm afraid. Perhaps if you raise it with Matplotlib they can point you to more resources? https://github.com/matplotlib/matplotlib

If you are on linux, this is a recipe I use all the time for getting custom fonts to work.

Make the ~/.fonts directory if it doesn't already exist.
Copy your custom font into the ~/.fonts directory.
Run rm -rf ~/.cache.
Run sumo with --font "Times New Roman.

Interesting,
My font file name is "Times_New_Romance.ttf" and I kept it in the ~/.fonts directory.
and then run the sumo with --font "Times New Roman". But still, I am getting the default fonts with the warning "findfont: Font family ['sans-serif'] not found. Falling back to DejaVu Sans."
Could you please send me your font file?
Thanks

It doesn't say anything about the font name in the part you pasted. Can you please paste the full error message here?
Also, did you definitely run rm -rf ~/.cache?

Yes, I did that. I am always getting below message and the fonts are in default settings not in Times New Roman.
findfont: Font family ['sans-serif'] not found. Falling back to DejaVu Sans

Strange, normally the error is something like:
findfont: Font family ['sans-serif'] not found. Falling back to DejaVu Sans.
findfont: Generic family 'sans-serif' not found because none of the following families were found: Times New Roman

Can you paste the full sumo command you are running.
I just downloaded the times new roman font file from this page: https://www.fontmirror.com/times-new-roman And the steps above worked for me.

sumo-bandplot --font "Times New Roman"

Ok, I just tested your command on my system using the steps I outlined above and it worked fine. I'm afraid if it is still not working there must be an issue with your matplotlib installation/configuration.

Are you sure you have installed Times New Roman? Your font name is "Times_New_Romance.ttf" which is a different font: https://www.dafont.com/times-new-romance.font

I tried to install it but couldn't get success. Then I only found this file on Google and kept it in the ~/.fonts

Did you try using this font? https://www.fontmirror.com/times-new-roman

Thank you very much.
I will check it and update you. May be tomorrow as I left the office few minutes ago (its 2am) and I don't have the laptop with me.
Thanks for your all help.

Thank you So much. It worked for me.


GridFunctions on Interface spaces

In the intermittent series of 'theoretical physicist asks silly computational questions', if one has a GridFunction defined on an interface-only space, i.e.
coll = new DG_Interface_FECollection(Order, Dimension);
fes = new FiniteElementSpace( mesh, coll );
GridFunction gf( fes );
// do things that populate gf
How does one obtain the values of this GridFunction?
Nothing that eventually calls GetValues will work, because such finite element spaces always return NULL for fes->GetFE(i), as they only have 'face' elements, not 'base' elements.
I have whipped up a couple of functions to do this, but want to make sure i'm not duplicating functionality that's already there.

Hi @ianabel,
You are right, MFEM does not have methods to evaluate GridFunctions directly on faces. The methods GridFunction::GetFaceValues and GridFunction::GetFaceVectorValues evaluate values on a given face but they do it indirectly by mapping the point on the face to a point in one of the two adjacent elements and then performing the computation of the value at that point.

OK, my pull into the hdg branch adds these functions, and I think it's probably only useful for that case.
If this is needed  for non HDG algorithms, someone can reopen this and I'll make a PR into mainline.


Multiple maps, each with a slider, interfering with each other

I have a time-series choropleth that works well with the plugin. However, I'd like to do two of these side-by-side on a website. But I keep getting error messages and can see the slider, but can't click on it/slide it. Is there some kind of trick to using this work multiple maps?

Fixed in https://github.com/Falke-Design/LeafletSlider


Unable to get TCA9548A work

I am trying to use TCA9548A using zephyr. The following code returns error that "Device is not ready". I have connected the hardware properly i.e. SDA/SCL/GND/Vcc are connected properly between my processor and TCA9548A
Any help in what is not correct here?
const struct device *i2c_dev = device_get_binding(DEVICE_DT_GET(DT_NODELABEL(ch0)));
if (!device_is_ready(i2c_dev)) {
printk("Device is not ready.\n");
return;
}
The overlay file is as follows
&i2c0 {
status = "okay";
mux: tca9548a@70 {
compatible = "ti,tca9548a";
reg = <0x70>;
status = "okay";
label = "i2c_mux";
#address-cells = <1>;
#size-cells = <0>;
	ch0: mux_i2c@0 {
		compatible = "ti,tca9548a-channel";
		label = "mux_dw_0";
		reg = <0>;
		#address-cells = <1>;
		#size-cells = <0>;
	};

	ch1: mux_i2c@1 {
		compatible = "ti,tca9548a-channel";
		label = "mux_dw_1";
		reg = <1>;
		#address-cells = <1>;
		#size-cells = <0>;
    };
};

};

const struct device *i2c_dev = DEVICE_DT_GET(DT_NODELABEL(ch0));


BUG: beforeAll() with a page.goto with incorrect URL generates strange error: UnhandledPromiseRejectionWarning: Error: Protocol error (Runtime.callFunctionOn): Target closed.

Promise errors in beforeAll() gives some un-understandable errors, see below. I could not replicate this with just using Playwright standalone.
Code
beforeAll(async () => {
  await page.goto(`http://<IP_ADDRESS>:8080/`);
});

it('enter password', async () => {
  await page.type('#password', 'test');
});

Output
(node:102419) UnhandledPromiseRejectionWarning: Error: Protocol error (Runtime.callFunctionOn): Target closed.
    at /home/userA/code/projectA/node_modules/playwright-core/lib/chromium/crConnection.js:121:63
    at new Promise (<anonymous>)
    at CRSession.send (/home/userA/code/projectA/node_modules/playwright-core/lib/chromium/crConnection.js:120:16)
    at CRExecutionContext.evaluate (/home/userA/code/projectA/node_modules/playwright-core/lib/chromium/crExecutionContext.js:69:50)
    at FrameExecutionContext._evaluate (/home/userA/code/projectA/node_modules/playwright-core/lib/dom.js:35:35)
    at FrameExecutionContext.ExecutionContext.evaluateHandle (/home/userA/code/projectA/node_modules/playwright-core/lib/javascript.js:24:25)
    at RerunnableTask._task (/home/userA/code/projectA/node_modules/playwright-core/lib/dom.js:485:24)
    at RerunnableTask.rerun (/home/userA/code/projectA/node_modules/playwright-core/lib/frames.js:836:23)
  -- ASYNC --
    at Frame.<anonymous> (/home/userA/code/projectA/node_modules/playwright-core/lib/helper.js:54:23)
    at Page.type (/home/userA/code/projectA/node_modules/playwright-core/lib/page.js:374:33)
    at Page.type (/home/userA/code/projectA/node_modules/playwright-core/lib/helper.js:55:31)
    at Object.<anonymous> (/home/userA/code/projectA/tests/sample.e2e.test.js:6:14)
    at Object.asyncJestTest (/home/userA/code/projectA/node_modules/jest-jasmine2/build/jasmineAsyncInstall.js:102:37)
    at /home/userA/code/projectA/node_modules/jest-jasmine2/build/queueRunner.js:43:12
    at new Promise (<anonymous>)
    at mapper (/home/userA/code/projectA/node_modules/jest-jasmine2/build/queueRunner.js:26:19)
    at /home/userA/code/projectA/node_modules/jest-jasmine2/build/queueRunner.js:73:41
(node:102419) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:102419) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
 FAIL   E2E  tests/sample.e2e.test.js (10.538s)
  ✕ enter password (5003ms)

  ● enter password

    While navigating to http://<IP_ADDRESS>:8080/: net::ERR_INVALID_ARGUMENT at http://<IP_ADDRESS>:8080/

      1 | beforeAll(async () => {
    > 2 |   await page.goto(`http://<IP_ADDRESS>:8080/`);
        |   ^
      3 | });
      4 |
      5 | it('enter password', async () => {

      at throwIfError (../node_modules/playwright-core/lib/frames.js:330:19)
      at Frame.goto (../node_modules/playwright-core/lib/frames.js:307:9)
      at Object.<anonymous> (sample.e2e.test.js:2:3)
        -- ASYNC --
      at Frame.<anonymous> (../node_modules/playwright-core/lib/helper.js:54:23)
      at Page.goto (../node_modules/playwright-core/lib/page.js:224:33)
      at Page.goto (../node_modules/playwright-core/lib/helper.js:55:31)
      at Object.<anonymous> (sample.e2e.test.js:2:14)

  ● enter password

    : Timeout - Async callback was not invoked within the 5000ms timeout specified by jest.setTimeout.Timeout - Async callback was not invoked within the 5000ms timeout specified by jest.setTimeout.Error:

      3 | });
      4 |
    > 5 | it('enter password', async () => {
        | ^
      6 |   await page.type('#password', 'test');
      7 | });
      8 |

      at new Spec (../node_modules/jest-jasmine2/build/jasmine/Spec.js:116:22)
      at Object.<anonymous> (sample.e2e.test.js:5:1)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        10.836s
Ran all test suites matching /e2e/i.
Jest did not exit one second after the test run has completed.

This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.

Removing the beforeAll() and instead doing this:
it('enter password', async () => {
  await page.goto(`http://<IP_ADDRESS>:8080/`);
  await page.type('#password', 'test');
});

Instead gives a better error:
 FAIL   E2E  sample.e2e.test.js (5.565s)
  ✕ enter password (9ms)

  ● enter password

    While navigating to http://<IP_ADDRESS>:8080/: net::ERR_INVALID_ARGUMENT at http://<IP_ADDRESS>:8080/

Some research on it. Maybe we should add event listener for this?
        process.on('unhandledRejection', (reason) => {
            console.error(reason.message)
        });

I'm not sure that is right decision

I actually now noticed that While navigating to http://<IP_ADDRESS>:8080/: net::ERR_INVALID_ARGUMENT at http://<IP_ADDRESS>:8080/ is seen in the first sampe as well, but much further down after the test cases started. So at least the proper error is in there somewhere. But obviously all the obscure errors reported before that is a problem.
It would be interesting to see if this is solved with jest-circus, which looks like it might have better unhandled promise rejections, at least from the little I read up on the topic e.g. here https://github.com/facebook/jest/issues/1852.  Not sure that helps you know though, but maybe it is not worth fixing this if jest-circus is going to be the default in Jest 26, and also since Playwright is in beta.
In we also handle unhandledRejection as your proposal in order to hook up a logger (for proper logging functionality). But very few errors should end up there. The proper solution would be to handle it earlier, e.g. directly in beforeAll with a try-catch, but it's most probably users do not though this. So I assume the default catch logic for this would be best in beforeAll, and maybe that is what jest-circus does.
Not sure I helped in any way, but it's always good to add to the discussion.

Oh, and adding an even listener like you suggest would still give that un-understandable output.
I think the main problem is that the having a page.goto() error inside it() gives a proper error whilst having it in beforeAll() does not. Even though the error is exactly the same.
Again maybe this is a problem with Jest, that jest-circus solves? Or maybe it is even a promise with Playright?

Will close the issue for now if it's okay. For my understanding the issue comes up if Jest timeout < Playwright timeout. Thats why in the end no verbose error reporting will be generated which line timed out.
ref: https://github.com/mmarkelov/jest-playwright#error-reporting-with-jest


bug: swipable modals status bar color

Bug Report
Ionic version:

[x] 5.x
Current behavior:
The background of the statusbar (iOS) does not change when opening swipable modals
Expected behavior:
The background of the statusbar should be black.
Steps to reproduce:
Open a swipable modal on an iOS device.
Other information:
Here is an image:

Thanks for the issue. I am going to close this as a duplicate of https://github.com/ionic-team/ionic/issues/20501.

Oh, im sorry. Thanks for helping!


Add custom_options also for client.rb

There is no way to specify custom options for the client config, but there should be one.
E.x. there is reneg-sec (reneg-* in fact) value that should be the same on both client and server, but I can't pass it to the client using puppet.

Added support for this. Thanks for the heads up!


Feature/geode 53 edit homepage

Collaborative edit of the homepage index.html, merging changes from pull requests #36 and #38, which are now superseded by this edit.

Sorry, didn't mean to implicate 5 commits and 156 files. Will re-submit.


Transition Mixture Node

This PR implements a transition mixture node that models a mixture of discrete transitions under selected transition probability matrices.

Codecov Report

Merging #180 (2999a0e) into master (5d9110e) will increase coverage by 0.89%.
The diff coverage is 99.53%.

@@            Coverage Diff             @@
##           master     #180      +/-   ##
==========================================
+ Coverage   85.32%   86.21%   +0.89%
==========================================
  Files          83       86       +3
  Lines        3877     4274     +397
==========================================
+ Hits         3308     3685     +377
- Misses        569      589      +20

Impacted Files
Coverage Δ

src/ForneyLab.jl
100.00% <ø> (ø)

src/factor_nodes/transition_mixture.jl
96.87% <96.87%> (ø)

...c/engines/julia/update_rules/transition_mixture.jl
100.00% <100.00%> (ø)

src/update_rules/transition_mixture.jl
100.00% <100.00%> (ø)

src/factor_node.jl
12.50% <0.00%> (-1.79%)
:arrow_down:

src/engines/julia/generators.jl
97.05% <0.00%> (-1.07%)
:arrow_down:

src/factor_nodes/sample_list.jl
73.56% <0.00%> (-0.85%)
:arrow_down:

src/factor_graph.jl
94.33% <0.00%> (-0.61%)
:arrow_down:

src/edge.jl
66.10% <0.00%> (-0.57%)
:arrow_down:

src/factor_nodes/dirichlet.jl
87.65% <0.00%> (-0.51%)
:arrow_down:

... and 39 more

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 5d9110e...2999a0e. Read the comment docs.


Cannot customize aria-label for each checkbox/radiobutton that generated by datagrid when configured with clrDgSelected/clrDgSingleSelected

Describe the bug
A clear and concise description of what the bug is, and the conditions when it occurs.
There are checkboxes and radio buttons in the tables however the controls don't have any name associated with them and are announced with just the role and state information(aria-label="Select", it is hard-coded now)

<clr-checkbox-wrapper class="clr-checkbox-wrapper ng-star-inserted">
<input clrcheckbox="" type="checkbox" aria-label="Select" id="clr-dg-row-cb37" class="ng-untouched ng-pristine ng-valid">

</clr-checkbox-wrapper>

How to reproduce
It can be reproduce with datagrid that configured with 'clrDgSelected/clrDgSingleSelected' in version 4.x and 5.x
Please provide a link to a reproduction scenario using one of the Clarity Stackblitz templates. Reports without a clear reproduction may not be prioritized until one is provided.
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
All interactive elements should have a proper name that conveys the purpose of the elements to screen reader users.

As the checkbox / radio button controls are used here for selecting a row.
it can use the value in the Name column(or any other column) as the label for the checkbox / radio control so that they have a proper name that conveys their purpose to screen reader users. The value in the Name column can be associated with the controls using an aria-label or aria-labelledby.
Or expose a new input directive on datagrid row that user can use it to pass label value to it.

A clear and concise description of what you expected to happen.
Versions
4.x/5.x
Clarity project:

[ ] Clarity Core
[*] Clarity Angular/UI

Clarity version:

[ ] v3.x
[*] v4.x
[*] v5.x

Framework:

[*] Angular
[ ] React
[ ] Vue
[ ] Other:

Framework version:
ie: Angular 11
Device:

Type: [e.g. MacBook] mac
OS: [e.g. iOS]
Browser [e.g. chrome, safari] chrome
Version [e.g. 22] 90

Additional notes
Add any other notes about the problem here.

Clarity cares deeply about accessibility, and we work with our accessibility team to identify and triage issues. We have an internal tracking system to identify and verify accessibility issues, which has captured this already. Some issues with Clarity Angular are difficult to solve without causing side effects or breaking changes, and we have to balance concerns with fixing issues and breaking changes. As we build out Clarity Core, we are able to address these root cause accessibility issues and recommend adopting the Clarity Core implementations as they become available. We are closing this issue as we have the issues tracked internally. Please follow our development and releases to see when we release relevant Clarity Core components to make this possible.


Fix tuple unpack in conv2d NCHWc int8

follow up to https://github.com/apache/tvm/pull/13566

cc @jfromm

cc @jwfromm

@tvm-bot rerun

I know it's a miniature PR, but https://tvm.apache.org/docs/contribute/pull_request.html#commit-message-guideline

@tvm-bot rerun

Looks like this needs to be linted. I think its also worth throwing in a comment explaining this explicit unpacking helps improve flexibility with other incoming layouts.

@tvm-bot rerun

@tvm-bot rerun


Patches failing doesn't result in luarocks failure

if applying patches in luarocks fails, it is ignored and the build continues.
Please ensure you exit with a non-zero exit code.

Can't reproduce, for me when using install or build command patches are applied and when a patch fails, an error message is printed and exit code is not 0. However, it seems that patches are not applied by design when using make command (https://github.com/keplerproject/luarocks/blob/53e0c654af685b46a38548cca6d5df7bad30a7dc/src/luarocks/build.lua#L230-L235). Perhaps that could be changed?

However, it seems that patches are not applied by design when using make command

This is by design. Patches are applied once when you run luarocks unpack. The idea of luarocks make is to assist in development, so you don't want it to apply patches over and over again when you're hacking at the code.

Hmmm, I may have been using luarocks install http://mydomain/myfile-scm-0.rockspec
Would that trigger it?
I remember seeing in the output that applying the patch failed; but luarocks just kept going.

luarocks install, when given a rockspec, redirects into luarocks build.
If you can reproduce it consistenly, please re-run with --verbose and send us the full output. Thanks!

If you can reproduce it consistenly, please re-run with --verbose and send us the full output. Thanks!

I was configuring a new server when I ran into this issue; I ended up working around it.
However, while debugging, I did run with --verbose, and there was no interesting output around the patching. as patching happens in process I don't think there's much there?

I just wanted to know for sure that it was using the internal implementation of patch.
Turns out I just looked at the code and we're always using the internal implementation, the apply_patch function in unix/tools.lua is dead code. I'm ripping it out now.

I found that the result wasn't being tested, but only in unpack (which explains @mpeterv not catching it in his tests). @daurnimator, maybe that's how you triggered it?

Maybe :p
I'll reopen if it occurs again.


feat(cli): generate, add --no-hint argument

This PR aims to remove some of the bloat that's output everytime you run prisma generate by adding a --no-hint flag to the generate command:
Closes #22513
prisma generate --no-hint

prisma generate

I've also created a sister PR in the withfig/autocomplete repo: https://github.com/withfig/autocomplete/pull/2345

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@gutyerrez I've addressed your comments and the CI tests are now passing. It seems like someone has to add a milestone before the last check will pass but other than that it should be good to go :)

@Jolg42 I see that you removed the milestone. Is there something I need to do to get this added back?
It seems like that's the only check left for this PR.

@SevInf is there anything more I need to do to get this merged?

@SevInf thanks so much for the review, I believe I've addressed all of your comments.

Thank you, waiting for final CI run and merging


Thank you!

Hi there,
I know you're not the originator of the Archimedes mod, but I want to thank you for picking it up and carrying it forward.  I've been playing Minecraft with some friends on a private server for a while now, and I've always wished that we could load up a ship with resources in a far-away biome across the sea, and bring them home to our base, without having to do silly things like drag donkeys behind our boats.  I hadn't messed with Minecraft mods before, but I finally decided to give this a try, and it's really amazing how well it works!  This opens up a whole new world of adventures!  And I'm very glad that I'm able to use it with the current version of Minecraft.
Please keep up the great work!

Not really an issue but you're very welcome!


Make chunk_content_internal parallel

This switches the chunk_content_internal function from a sequential BFS to a parallel BFS (+ reverse topological sort at the end).
I expected this to make some difference in performance, as traversing references in parallel can lead to better CPU usage (see #3771), but in practice our benchmarks show no significant difference.
Real apps might be a different story, but I didn't notice any particular performance improvement on vercel.com either.
This implementation is not perfect (we're making more calls to get_children than strictly necessary), but I think it's enough to measure a potential performance improvement.
Marking this as a draft for now as it's more complicated than the current implementation and there's no clear win to adopting this.

Re: benchmarks, I'm not seeing any significant change between this PR and main when benchmarking locally for 100, 1000, and 10000 modules on the bench_hmr_to_commit/Turbopack SSR case. According to this PR's benchmark results, I should see a ~2ms difference.
I think this is fine to merge as is, and we might have to take another look at optimizing this later on if we think we're spending too much time in chunk_content_internal.

What I am seeing is a much more stable bench_hmr_to_commit/Turbopack SSR/10000 setup step. On my MBP, on main, it can take anywhere between 9s to 270s (likely because of the exponential backoff for HMR setup, which I might have to relax a bit).
On this branch, it takes a consistent 9s on every run.

Only failing test is test_crates_next_dev_tests_tests_integration_next_app_metadata but it's passing locally, it's just super flaky. Force merging now.


"pod deintegrate" not running after "gem install cocoapods-deintegrate"

probably dum or silly something I am missing
first I run on terminal
"sudo gem install cocoapods-deintegrate"
after that "pod deintegrate" , but I get error "pod: command not found" ..so

@GreenRidingHood apologies for the very late response - what version of CocoaPods do you have installed?
This plugin comes with CocoaPods by default, so you shouldn't have to install it manually.
Can you post the result of running pod env here?

Hey, I'm having this problem too.
When I run pod env  I get command not found: pod.
cocoapods-deintegrate (1.0.4) shows up in my gem list.
Any ideas?

does CocoaPods itself show up? ex which pod? if not, gem install cocoapods should do the trick


Resume state of Proskomma via proskomma-freeze

Developer should be able to import multiple docsets via single json file using proskomma-freeze.

Progress has been made with this via v1.6 where new hooks were created for serializing and loading a succinctDocSet. It hasn't addressed the issue of Proskomma-freeze with full export and resuming of all docSets.


Facing issue during compilations

Describe the bug
ERROR in ./node_modules/react-awesome-reveal/dist/module.js
Module build failed (from ./node_modules/source-map-loader/dist/cjs.js):
Error: ENOENT: no such file or directory, open 'C:test-app\node_modules\react-awesome-reveal\dist\module.js'

Failed to compile.

Expected behavior
Compiled properly and generate output
Screenshots

Desktop (please complete the following information):

OS: Windows
Browser - chrome(Brave)

Which bundler are you using?

Closing this due to inactivity.


ENH: differential_evolution can use Bounds object

Single change to allow differential_evolution to use a Bounds object to specify constraints.

refguide check is unhappy:
build/testenv/lib/python3.6/site-packages/scipy/optimize/_differentialevolution.py:scipy.optimize.differential_evolution:23: (ERROR/3) Unexpected indentation.::

the idea to allow using a Bounds object makes sense to me

w.r.t Unexpected indentation, am I supposed to increase indentation by 1, or ....?

@rgommers, I think this fixes it. The pypy3 fail is a CI that doesn't get off the ground even.

LGTM, merged. Thanks @andyfaff


Restored old xarray coord order inference behavior

In 1.10.0 the code that infers the coordinate order from an XArray Dataset changed, unintentionally changing the behavior. This PR restores the old behavior.

[x] Fixes regression described in https://github.com/ioam/holoviews/issues/2577
[x] Adds unit test

Looks good to me. Happy to merge once the tests are green.

The behavior of Dataset.coords seems to have changed in xarray>=0.10.0 and earlier versions do not seem to be predictable. Have to think a bit more about what to do about that. There was a reason that I had made the change originally.

Maybe have behavior conditional on the xarray version? Or is that too confusing?

@marcbernot convinced me this is the correct thing to do. So I would like to see this merged for 1.10.1

Tests are green. Merging.

@philippjfr  This issue has just bitten me a second time. I know that this is quite an involved topic for me to wade into, but one suggestion by @jsignell is to use the order of .dims on the DataArrays, allowing things like .transpose to work.
This makes more intuitive sense to me so I'm just wondering why we aren't using that approach?

Here's a visual example:

It's worth reading the linked issue, we had actually very briefly switched to dims ordering (by accident) in 1.10 and reverted the change in this PR. There are two main reasons for that, a) on a xr.Dataset the dims order can vary between the xr.DataArray objects it contains so dims do not provide a global ordering in that case, and b) since xarray is an memory representation of NetCDF data the coordinate order does reflect actual information and is generally not arbitrary. And holoviews as always tried to preserve the semantics declared by the data.
When loading a NetCDF dataset the coordinates are usually ordered something like lon x lat (x height) x time by (COARDS) convention. This happens to be particularly useful since it means that to explore a cube of data like this you can just do:
# holoviews
hv.Dataset(xr_obj).to(hv.Image)

# hvplot
xr_obj.hvplot.image()

and it will automatically deduce that you want a stack of images you can explore across height and/or time.
The problem is that tiffs loaded using xr.open_rasterio sometimes but not always invert the coordinates, which causes these headaches.
That all being said it's not quite clear to me yet what we should do, the xarrays data model does often give coordinates a semantic meaning but if that is not generally followed that becomes less useful. My first instinct would be to try to figure out why rasterio loads some tiffs with a non-convention confirming coordinate order before deciding that holoviews should conform to the dim ordering instead.

I think that how rasterio is loads the tiffs is definitely strange and worth looking into. But I think that the discussion of what holoviews should do is slightly different. There is no requirement that xarray objects even have coordinates.
>>> data = np.random.rand(4, 3)
>>> da = xr.DataArray(data)
>>> da
<xarray.DataArray (dim_0: 4, dim_1: 3)>
array([[0.169981, 0.950831, 0.825206],
       [0.242455, 0.056433, 0.346963],
       [0.052712, 0.359673, 0.710705],
       [0.139174, 0.244938, 0.284301]])
Dimensions without coordinates: dim_0, dim_1

>>> da.dims
('dim_0', 'dim_1')

>>> da.coords
Coordinates:
    *empty*

This works:
>>> hv.Image(da.data)

But this throws an error:
>>> hv.Image(da)
....
ValueError: kdims: list length must be between 2 and 2 (inclusive)

I think fundamentally we should be using dims but it is true that there is no global ordering for Datasets with dims. Each data_var in a Dataset is a DataArray which has its own dim ordering.

I'll make a PR.

We will at least have to come up with a slightly more nuanced policy than simply always using the dims, perhaps only when passing in DataArrays? When we accidentally switched to using dim ordering in 1.10, multiple users complained that it was breaking their workflows.

I would have thought that the current situation is that people have to end up specifying their kdims explicitly for it to behave in any reasonable way, and if they've done that then this change won't affect them.  Is that true?

In any case, maybe you could poll those users about this change?

We will at least have to come up with a slightly more nuanced policy than simply always using the dims, perhaps only when passing in DataArrays?

@philippjfr That is what I was suggesting above as one possible option. Of course, I would rather avoid special cases so if it is appropriate to always use dims, we should do that.
@jsignell I didn't know that DataArray's didn't have coords, thanks for pointing that out. If dims must be there (but coords don't) then it would seem appropriate for me for holoviews to use dims in order to support the more general case. A PR would certainly help us think more clearly about this issue!

I would have thought that the current situation is that people have to end up specifying their kdims explicitly for it to behave in any reasonable way, and if they've done that then this change won't affect them.

That is also what I was thinking/hoping!

I would have thought that the current situation is that people have to end up specifying their kdims explicitly for it to behave in any reasonable way, and if they've done that then this change won't affect them. Is that true?

No, it's worth reading my summary above. In most cases coords are in the appropriate order and at least for multi-dimensional datasets are often more informative than the dims since they have semantic meaning and follow certain conventions while dims simply describe the orientation of the array in memory.

I would have thought that the current situation is that people have to end up specifying their kdims explicitly for it to behave in any reasonable way

As I mention above the problem arises because for certain tiffs the xarray rasterio returns coordinates not following the convention which means you have to specify the key dimensions to orient the array correctly. In almost all other cases I have come across coordinates behave correctly and for multi-dimensional datasets in particular they result in preferable behavior which is why users complained when we switched to dims ordering.

As for objects without dims I suspect we might currently have much more general issues handling those, but at least in the DataArray case we definitely should fix that. I'm not entirely sure what it would mean for there to be an xr.Dataset without coords or if that's even possible since the coordinates specify how the DataArrays contained in the Dataset line up.

I guess my exposure is only to the tiff case which doesn't work well: I'll take your word that the default of using coords works well in most other cases.
That said (and I may be misremembering!) doesn't the geoviews Image.load_image helper classmethod now have geotiff support? And does this (or can it) compensate for the surprising way rasterio loads things?

In any case, maybe you could poll those users about this change?

The response was pretty emphatic at the time, it's also a major backward incompatible change. I really don't think we can just switch the behavior entirely, I'd be much happier with a more narrow and targeted fix.

That said (and I may be misremembering!) doesn't the geoviews Image.load_image helper classmethod now have geotiff support?

I implemented it as a separate method called Image.load_tiff since the signature was quite different. I'd have to look into whether it's possible to correct the issue in there. Could you send me a couple of tiffs by email to test on?

Having looked at the xarray piece of holoviews, I think there is an easy fix for the no coords case. We can assign coordinates based on dim names when no coords are specified:
data.assign_coords(**{k: range(v) for k, v in data.dims.items()})

this will add an int index for each dim same as what happens if you roundtrip an xarray object to pandas and back:
>>> data.to_dataframe().to_xarray()
<xarray.Dataset>
Dimensions:  (dim_0: 7, dim_1: 9)
Coordinates:
  * dim_0    (dim_0) int64 0 1 2 3 4 5 6
  * dim_1    (dim_1) int64 0 1 2 3 4 5 6 7 8
Data variables:
    z        (dim_0, dim_1) int64 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ...

Great, thanks @jsignell, that makes sense to me, just make sure to make a shallow copy before assigning the coords (if assign_coords doesn't already do that).

As for ordering of kdims based on dims, I don't think there is a good global way because the ordering of dims just isn't global.

just make sure to make a shallow copy before assigning the coords

Right the original object isn't mutated

Could you send me a couple of tiffs by email to test on?

Done for the tiff shown in the screenshot above...


Improve MlsGroup constructor

There are several problems with building an MlsGroup.

The consumer can't set the RequiredCapabilities of a group upon creation. This is already documented in #1213, but it should really only be possible for completely new groups, i.e. not for groups created from welcome or via external commits.
One can't set the LeafNode Extensions or LeafNode Capabilities when creating a group. This should be possible for fresh MlsGroups, as well as those created from external commits, but not those created from Welcomes.
Both underlying Group types (PublicGroup and CoreGroup) are implemented using a Builder pattern, while MlsGroup uses MlsGroupConfig, which isn't great. A builder pattern would be more ergonomic.
There should be different constructors (either builder of config patterns) for fresh groups, groups created from Welcome and groups created from external commits, as they should allow different sets of build options (see the examples above).
MlsGroupConfig contains a bunch of information that is really only necessary for creating the group, but even after creation it lives on in its own field in MlsGroup. In the end, we probably want both a config (to contain information that is persisted in the group) and a builder (to contain only information required for group creation).

[x] #1462
[x] Allow setting LeafNode extensions and capabilities when creating a new group
[x] Allow passing arbitrary GroupContextExtensions when creating a new group
[x] #1463

Fixed by #1477.


fix(@ngtools/webpack): HTML and style changes in libraries is not ref…

…lected in applications during VE AOT
During AOT compilations, apart from the d.ts and .js changes we need to handle summary changes and metadata depedencies for libraries.
NGC compiler doesn't allow us to purge known changed summaries, this change implements a workaround for this, which allows us to have incrementality for component resources in libraries.
Fixes #13588

See: https://github.com/angular/angular-cli/issues/17736#issuecomment-629995982