Rework handling of the pebble_ready event

Overview
We discovered that in cases where the workload container gets restarted on its own, only a pebble_ready event would be thrown by juju and the container would not be correctly re-planned.
This PR handles pebble_ready event correctly and adds a named function for each event we listen to. This is a step towards "managing charm complexity", allows us to have more fine grained logging and handling of events.
During the creation of the PR, it was noted that the redis_relation_changed handler didn't try to setup discourse as needed, so it was added.
Checklist

[x] The charm style guide was applied
[x] The contributing guide was applied
[x] The changes are compliant with ISD054 - Managing Charm Complexity
[x] The documentation is generated using src-docs
[x] The documentation for charmhub is updated.
[x] The PR is tagged with appropriate label (urgent, trivial, complex)

Out of curiosity: From the doc Lifecycle events, while deploying the charm, this happens: install -> config-changed -> start -> -pebble-ready
Would this make the set up discourse run twice?

Out of curiosity: From the doc Lifecycle events, while deploying the charm, this happens: install -> config-changed -> start -> -pebble-ready
Would this make the set up discourse run twice?

Yes, indeed. This is probably why it is subject to timeouts here. I need to fix this

While reading this I was thinking: "why not handle only pebble ready event?"

While reading this I was thinking: "why not handle only pebble ready event?"

The pebble ready event can occur when the relations don't exist or are not ready. So if we don't defer, it doesn't allow us to be sure that the charm will go through the setup


Seek Runfile if one isn't found

Often, it's convenient to have a Runfile in a central place, like the root folder of a repository. I think it would be nice if run could search upwards to try find a Runfile if one is not found in the present directory, to make working in a subdirectory more convenient in that case.
Suggested workflow:

if -r is found, then require that file to exist. Don't search any other path.
if not, then search for Runfile in the current directory, and if it does not exist, keep searching upwards until a Runfile is found

We could also apply some other bounding here, like not continuing upwards if a VCS directory (.git, etc) is found, but perhaps that isn't really needed?

Howdy !
OK so I got an idea today to work on a findup script to try to generalize the idea of looking up the path for a relevant file.
findup shell script
#!/usr/bin/env sh
set -Eeuo pipefail
if [ -z "${1:-}" ]; then
	printf "usage: findup <find-expression> [find-expression] ...\n" >&2
	exit 2
fi
path="${PWD:-}"
while [ -n "${path:-}" ]; do
	if found="$( find -H "${path}" -maxdepth 1 "$@" )"; then
		if [ -n "${found:-}" ];then
			printf "%s\n" "${found}"
			exit 0
		fi
		if [ "${path}" == "/" -o "${path}" == "." ]; then
			path=
		else
			path=$(dirname "${path}")
		fi
	else
		exit $?
	fi
done
exit 1

using the script
$ mkdir -p /tmp/dev/tekwizely
$ cd /tmp/dev/tekwizely

$ cat <<EOF >Runfile
> hello:
>     echo "Hello, world!"
> EOF

$ findup -name Runfile
/tmp/dev/tekwizely/Runfile

$ mv Runfile ../

$ findup -name Runfile
/tmp/dev/Runfile

$ mv ../Runfile ../../

$ findup -name Runfile
/tmp/Runfile

run alias
alias run='findup -name Runfile | xargs -I{} command run -r "{}"'

usage
$ pwd
/tmp/dev/tekwizely

$ findup -name Runfile
/tmp/Runfile

$ run hello
Hello, world!

This is just a proof-of-concept, but I think there's potential for a useful tool.
Give it a try and lemme know what you think!
-TW

I can see the value in a separate tool (I have something along those lines already), I guess the thought was more along the lines of "perhaps run should do this itself", since it seems like useful behaviour to me.

WARNING: Long Stream-Of-Consciousness Reply Ahead ...

I can see the value in a separate tool

I will admit I was hoping for more of a "cool abuse of find!" response ...
Although it does turn out its not fully unique:

find searching in parent directories instead of subdirectories

What Does Git Do
Using git as an example of a tool with this behavior, I discovered that:

GIT_CEILING_DIRECTORIES
GIT_DISCOVERY_ACROSS_FILESYSTEM

I don't know how much of that logic I want to worry about ...
--findup
I think git has to jump through these hoops because it has findup logic enabled by default.
I think if we make the behavior more of an opt-in, then we wouldn't need to feel so responsible for the edge cases (i.e the user takes responsibility when the opt in).
This could be accomplished via something like a --findup argument when invoking run.
I admit that --findup really isn't much shorter than -r ../../Runfile, but maybe supporting a short code (-f || -u) would be good enough?
RUN_OPTS
I was thinking of introducing something like a RUN_OPTS variable where the user could set options like --findup globally.
RUN_DIRS
Also instead of walking up the path, I'm wondering if there might be value in something like a RUN_DIRS variable that contains paths to Runfile root dirs.
ie. If there is a path element that is a parent to your current PWD, then we'll look at the path element folder for the Runfile.
RUN_DIR
Or maybe just a single folder in a RUN_DIR variable.  Git has this:

GIT_DIR

RUN_FILE
More useful than RUN_DIR would probably be pointing to specific file, ie RUN_FILE.
(although RUNFILE is probably better in this case)
DIRENV
One nice thing about variable based configuration is that it plays nicely with direnv.

direnv – unclutter your .profile

With it, you can configure RUNFILE when you cd into your root folder:
.envrc
export RUNFILE="${PWD}/Runfile"

direnv will set the variable when you cd into the folder, and reset the variable when you cd out of the folder.
My Preference
Of the ideas mentioned above, --findup/-u and RUNFILE are my favorite.
Interested in your thoughts?
As always, thanks for participating !
-TW


Consider depending on VSCode-YAML rather than directly on yaml-language-server

Hi,
from looking into your repository it looks like you use the yaml language server directly rather than relying on VSCode-YAML for the YAML support. I was wondering if there is any particular reason why you spawn up the language server yourself, rather than just using VSCode-YAML as an extension dependency and having that spawn it. If you are doing this because there are some API's missing that you need then please let me know.
The only reason I bring this up is this has been done before and it will eventually lead into multiple language servers running for a yaml file if the user has vscode-yaml and this extension installed. This can create several unintended results like duplicate completions, etc etc.

@egamma FYI

CC @fiveisprime


Delay compilation until fist use of the router

Summary of Changes
Delay the router compilation until the first actual use of the router.
By default each route is compiled in a standalone instance of the router, to check that it will actually compile. This behavior is controlled by the verify_route_on_add flag in the compiled router option.
By default this is set to true since it's impact is negligible unless thousands of routes are added.
The method add_route accepts a new keyword to make the router eagerly compile. This can be used to finalize the router when the last route is added, to avoid incurring a penalty on the first routing
The performance app setup to first response is this (in s)

routes
master
delayed router
verify_route_on_add=True

9
0.0034604
0.0014578
0.0043392

81
0.1205411
0.0094007
0.0329528

729
11.238887
0.0883184
0.3974814

6561
1144.1065
0.9569258
3.5786625

59049
slow
10.385946
36.764869

with the simple test
pathMatrix = [["foo", "bar", "baz"], ["oof", "rab", "zab"]]
paths = ["/" + "/".join(p) for p in itertools.product(*(pathMatrix * mult))]
start = time.perf_counter()
for i, p in enumerate(paths, 1):
    app.add_route(p, res)
T.TestClient(app).simulate_get(paths[0])

Edit: updated with new updated data that no longer has verify_route_on_add
Related Issues
fixes #1550
Pull Request Checklist
This is just a reminder about the most common mistakes.  Please make sure that you tick all appropriate boxes.  But please read our contribution guide at least once; it will save you a few review cycles!
If an item doesn't apply to your pull request, check it anyway to make it apparent that there's nothing to do.

[x] Added tests for changed code.
[x] Prefixed code comments with GitHub nick and an appropriate prefix.
[x] Coding style is consistent with the rest of the framework.
[x] Updated documentation for changed code.

[x] Added docstrings for any new classes, functions, or modules.
[x] Updated docstrings for any modifications to existing code.
[x] Added references to new classes, functions, or modules to the relevant RST file under docs/.
[x] Updated all relevant supporting documentation files under docs/.
[x] A copyright notice is included at the top of any new modules (using your own name or the name of your organization).
[x] Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.

[x] Changes (and possible deprecations) have towncrier news fragments under docs/_newsfragments/. (Run towncrier --draft to ensure it renders correctly.)

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!
PR template inspired by the attrs project.

I've added to the table the times with a very naive stand alone compile for every added route on a new router to check if the route it can actually compile
this is the check:
        if kwargs.get("_check") is not True:
            temp = CompiledRouter()
            temp._options = self._options
            temp.add_route(uri_template, resource, _check=True, **kwargs)

I've had another look at the compile functions of the route and I think that safest way to ensure that every route can compile on its own is to have another instance of the router that we use for this standalone compile. Doing otherwise may have unintended side effects of the router instance, but I'm not very familiar with the compiled router so I may be missing an easier / cleaner solution.
I'm not sure if this should be configurable or not. I guess an option in the router options would not hurt
Regarding the implementation, I think the delayed compilation could be the default and add_route could have a new kwarg compile that when set compiles the router, retaining the current behavior.
This allows users to compile the router when they add the last route if he prefer to avoid the penalty on the first request.
@kgriffs @vytas7 what do you think?

@kgriffs @vytas7 This should be ready for review.
I'm not sure about the name of the option verify_route_on_add. I'm usually not very good at naming things. If you came up with a better name I would be happy to change it.
I've updated the inital post table

Regarding the implementation, I think the delayed compilation could be the default and add_route could have a new kwarg compile that when set compiles the router, retaining the current behavior.
This allows users to compile the router when they add the last route if they prefer to avoid the penalty on the first request.

I'm cool with this approach. We just need the docs to mention the reason someone might use the param, as you outlined above.

I've added a lock to guard the router compile. While the compile itself may be thread safe, and python has the gil, this avoids wasting time compiling multiple times the router.
I've also update the documentation.
I'm not sure if we should mention that the router is "lazy" here https://github.com/falconry/falcon/blob/0d419ef49f26a41a335b67d5eeeed29365c35308/docs/api/routing.rst#default-router
Something along the lines of
By default the decision three is compiled only when the router receives the first request.
See :class:`.CompiledRouter` for more information on this

Moving here from the review comment.
I've had another look and I think we could avoid the standalone compilation step of every route, by trying to also instantiate the field converters in the _validate_template_segment.
https://github.com/falconry/falcon/blob/c3e91875f1030c68d17efa27cf8df3d18f337761/falcon/routing/compiled.py#L282
This is the only check that is not currently performed by the add_route that is left to the compile step.
I think with this the implementation would be a lot cleaner, since there would be no need for the internal router instance, the new router options, etc

I've updated the _validate_template_segment function to also verify that a converter can be instantiated with the provided params

Thanks for the review,
I've updated the documentation with the suggestions.

I would suggest to mention the new compile keyword argument in App.add_route(...) docs,

I've added a short documentation there, linking to the more complete one on the router implementation

I think that restarting the failed job should clear the failure


feature: add logic for send the notify to memnber who join/accept

Context

Notification should be sent to init member, when other members accept invitation, then join

Changes

Add the logic check for the route: /multigi/icp

Ticket

KERIA Multi-sig join notification handler

Here is the verification


Add support for consumer key

I don't find any key map in your code for consumer key, does karabiner-dsl support it, or some configs like below xml text?
<autogen>__KeyToKey__
    KeyCode::LAUNCHPAD,
    KeyCode::F4
</autogen>
<autogen>__ConsumerToKey__
    ConsumerKeyCode::BRIGHTNESS_DOWN,
    KeyCode::F1
</autogen>
<autogen>__ConsumerToConsumer__
    ConsumerKeyCode::KEYBOARDLIGHT_LOW,
    ConsumerKeyCode::BRIGHTNESS_DOWN
</autogen>

That's true. Personally I didn't remap these keys but it's a nice feature to support.
FYI: If you don't use that frequently, you can write it like:
item 'sample' do
  remap 'launchpad', to: 'F4'
  autogen '__ConsumerToKey__  ConsumerKeyCode::BRIGHTNESS_DOWN, KeyCode::F1'
  autogen '__ConsumerToConsumer__ ConsumerKeyCode::KEYBOARDLIGHT_LOW, ConsumerKeyCode::BRIGHTNESS_DOWN'
end


Consider supporting className instead of class on SVG elements similar to React

React allows using className on SVG elements.
Please consider supporting this with inferno-compat too.

<svg class="..."></svg> working for me instead className

Does it work for all svg elements?

@mstijak This should work on 1.0 – have you tested it there?. SVG elements can't actually use className, that's part of the reason why.

@trueadm I'm using<EMAIL_ADDRESS>I probably missed something. I'll check again...

Not working here too. I was using class for everything, but it's complicated when you want to use with destructuring etc. Then, I changed to className everything, but the SVGs stopped working. So, I switched back to class only the SVGs.
Actually, I think that class and className should work exactly in the same way,

className will give better performance, but svg don't support classname API. We could hide this behavior from user by internally using patchAttribute when className is sent to SVG

@Havunen That would be a great solution, imo.

class and className will now both work for SVG. Implemented in 1.0. https://github.com/trueadm/inferno/commit/aa17a5298a5a9592275b2e86a96ac806267c68a4
Closing this issue.

@Havunen not sure if this solves the issue. The className already worked for SVG, the only problem was when it was being patched to another value. The className property is readonly when talking about SVGs. None of those tests check that, and it doesn't seem that any of the file changes handle that too.
Am I missing anything?

It should work because it uses internally setAttribute('class', *) instead className API. See tests here: https://github.com/trueadm/inferno/blob/aa17a5298a5a9592275b2e86a96ac806267c68a4/src/DOM/tests/svg.spec.browser.js#L326-L331
Or maybe I missed something... :P

Removing implementation makes all tests fail with:
TypeError: Cannot assign to read only property 'className' of object '#<SVGSVGElement>'

Oh, great, thanks! So it will work starting from v1.0 :)


Store indices instead of geometries in STRtree + option to keep returning geometries

In context of the Shapely 2.0 RFC (https://github.com/shapely/shapely-rfc/pull/1/) we had some discussion about storing/returning integer indices instead of geometry objects, but didn't yet finalize the exact API how we want this to look like.
With this PR, I am testing one concrete option, and which can then also trigger some discussion about this, and if we agree on the API, I can also update the RFC text about that.
Generally, I think we can always store the indices in the GEOS tree, and then on the python level we can still return geometries or indices as we want (since we store the original geometries which are inserted into the GEOS tree).
Then specifically in this PR, I am keeping the existing query and nearest methods of the STRtree, but add a return_geometries keyword. Currently, I set it as default to True (to preserve existing behaviour). But then, we can also decide to raise a warning in Shapely 1.8 that this will switch to False, and have it set to False as default in Shapely 2.0 (so then by default return indices), as a way to have a deprecation cycle.
Some possible alternatives / discussion points (also based on aspects mentioned in the RFC discussion):

If we are fine with a keyword, is return_geometries=True/False good? Other ideas?
Keep a single class, but separate methods that return indices (eg query_index and query_geometries)
Separate class with the behaviour to return indices

Personally, I think a keyword option in a single method is the cleanest and easiest to implement (but certainly open to the other options as well). It's also similar to rtree's idx.intersection(..., objects=False).
Whichever option we choose, I think it will be straightforward to add it to the pygeos-based implementation for Shapely 2.0.

This PR obviously still needs more tests.
Also closes #615 (this PR is based on @snorfalorpagus's comment there)
cc @sgillies @mwtoews @caspervdw @brendan-ward

I like the simplicity and explicitness of a return_geometries kwarg being True or False. Being like rtree with the flag in the method is also a +1 for me, as a heavy user of that library.

I like the simplicity and explicitness of a return_geometries kwarg being True or False. Being like rtree with the flag in the method is also a +1 for me, as a heavy user of that library.

I also like the keyword solution. It is straightforward and effortless to understand.

I also like the keyword solution. It is straightforward and effortless to understand.

Using a keyword for this behavior seems reasonable.  I'd suggest adding a bit to the docstrings of query and nearest to make that output more clear.
Personally, I really like the index-oriented approach used by pygeos.STRtree.query because it enables spatial joins and in my specific usage, the identity of the result is more important than the geometry (which I can always join in later);  so I think that getting geometries back instead could be more of an opt-in instead of opt-out.  Thus I'd suggest having default return_geometries=True for existing behavior with a deprecation warning, and longer-term flip this to return_geometries=False.
Is there ever a case for returning both index and geometry?
It might be worth considering how this generalizes to a vectorized / bulk case as well, as in pygeos.STRtree.query_bulk where the left side of the query would always be returned as indices, but the right side would be either indexes (as now in query_bulk) or have an option like this keyword to return geometries instead, or perhaps both right side indexes and geometries depending on the above question.  If the bulk function meets the needs of spatial joins, then the default behavior for a singular query operation may not need to change, but does present a potential consistency issue.

Using a keyword for this behavior seems reasonable.  I'd suggest adding a bit to the docstrings of query and nearest to make that output more clear.
Personally, I really like the index-oriented approach used by pygeos.STRtree.query because it enables spatial joins and in my specific usage, the identity of the result is more important than the geometry (which I can always join in later);  so I think that getting geometries back instead could be more of an opt-in instead of opt-out.  Thus I'd suggest having default return_geometries=True for existing behavior with a deprecation warning, and longer-term flip this to return_geometries=False.
Is there ever a case for returning both index and geometry?
It might be worth considering how this generalizes to a vectorized / bulk case as well, as in pygeos.STRtree.query_bulk where the left side of the query would always be returned as indices, but the right side would be either indexes (as now in query_bulk) or have an option like this keyword to return geometries instead, or perhaps both right side indexes and geometries depending on the above question.  If the bulk function meets the needs of spatial joins, then the default behavior for a singular query operation may not need to change, but does present a potential consistency issue.

Thus I'd suggest having default return_geometries=True for existing behavior with a deprecation warning, and longer-term flip this to return_geometries=False

Yes, that's what I would advocate for as well and was planning to do (once we agree on the interface, and I still need to add docs and tests first).

It might be worth considering how this generalizes to a vectorized / bulk case as well, as in pygeos.STRtree.query_bulk

I don't think there is necessarily a need to add the keyword to query_bulk as well (unless someone comes up with a good use case, the only reason I can think of now would be for consistency, which in itself is not worth it IMO).
But you are right that with bulk_query returning indices, that can cover a large part of the use cases that need indices. Personally I would still prefer to (eventually, in Shapely 2.0) return indices in query as well, for consistency, but it's certainly a good argument.

Thus I'd suggest having default return_geometries=True for existing behavior with a deprecation warning, and longer-term flip this to return_geometries=False

Yes, that's what I would advocate for as well and was planning to do (once we agree on the interface, and I still need to add docs and tests first).

It might be worth considering how this generalizes to a vectorized / bulk case as well, as in pygeos.STRtree.query_bulk

I don't think there is necessarily a need to add the keyword to query_bulk as well (unless someone comes up with a good use case, the only reason I can think of now would be for consistency, which in itself is not worth it IMO).
But you are right that with bulk_query returning indices, that can cover a large part of the use cases that need indices. Personally I would still prefer to (eventually, in Shapely 2.0) return indices in query as well, for consistency, but it's certainly a good argument.

I dislike using functions that have different return types depending on a keyword argument. I would expect this to be a source of bugs.
I haven't seen it discussed yet, maybe because it's so obvious, but storing only indexes means that only geometries in a container can be indexed. Right? And storing only integers means only containers that are indexed with an integer can be used. Python is more flexible than this. Lists and arrays require integer keys, but mappings can use any immutable object as a key. What would you all think about allowing storage of any Python object? Not just geometries or integers. Then we'd have a very general purpose spatially-indexed container that could be used in many ways.
The GEOS API function https://github.com/libgeos/geos/blob/master/capi/geos_ts_c.cpp#L2979-L2988 takes a geometry and a void * pointer. Our tree constructor, now, takes only a geometry. We could extend it to take either a geometry or a geometry, object tuple and store the object if it is given, else the geometry.

I dislike using functions that have different return types depending on a keyword argument. I would expect this to be a source of bugs.
I haven't seen it discussed yet, maybe because it's so obvious, but storing only indexes means that only geometries in a container can be indexed. Right? And storing only integers means only containers that are indexed with an integer can be used. Python is more flexible than this. Lists and arrays require integer keys, but mappings can use any immutable object as a key. What would you all think about allowing storage of any Python object? Not just geometries or integers. Then we'd have a very general purpose spatially-indexed container that could be used in many ways.
The GEOS API function https://github.com/libgeos/geos/blob/master/capi/geos_ts_c.cpp#L2979-L2988 takes a geometry and a void * pointer. Our tree constructor, now, takes only a geometry. We could extend it to take either a geometry or a geometry, object tuple and store the object if it is given, else the geometry.

I think this is similar as what rtree does? It allows to insert, in addition to the integer id and bbox, also a generic (picklable) obj, and at query time, you can ask for the object instead of the id. See https://toblerity.org/rtree/tutorial.html#using-rtree-as-a-cheapo-spatial-database
Personally, I have never used this ability of rtree, so can't really judge about it. But it would be good to get some idea or feedback on whether and how this is used in rtree.
(to be fully correct, in geopandas we actually used to insert the index label of the Series as obj, but we never did anything with it afterwards).

I haven't seen it discussed yet, maybe because it's so obvious, but storing only indexes means that only geometries in a container can be indexed. Right? And storing only integers means only containers that are indexed with an integer can be used. Python is more flexible than this. Lists and arrays require integer keys, but mappings can use any immutable object as a key. What would you all think about allowing storage of any Python object?

I don't fully understand the logic here. Right now the STRtree in Shapely does not accept a geometry, but an iterable of geometries. The alternative would be to have an iterable of (geom, obj) tuples as input, I assume? (and the obj gets returned from the query)?
That's certainly more flexible for the user (the current behaviour of returning the geometry would be mimicked by (geom, geom) tuples, the proposal of returning integers by (geom, i) tuples). But I don't understand how that enables to store "any" python object.
To take the practical example of a mapping: assume you have a dict of {key: geom} structure, you still need to convert this to an iterable of (geom, key) tuples to be able to store it, which could be something like STRtree(zip(dict.keys(), dict.values())). So the interface doesn't allow to directly store the dictionary, you still have to do quite some manipulation to get to that. And this way you get the dictionary keys back from the query function. But with integer indices this is very easy to mimic as well: you pass the dict values (geoms) to the tree (STRtree(dict.values())), and can convert to integer index from the query to the dict key with list(dict.keys())[i].
Some other notes:

The current implementation of STRtree in pygeos actually stores the addresses of the geometry in the array of geometries, and doesn't store actual integer index objects (on suggestion of @dbaston)
The current implementation also releases the GIL for queries: this is something that I certainly would like to keep (or at least in case of integer indices as output), so that would probably be a complication for generic objects.
If we would like this generic interface of (geom, obj), I think this is still easily possible on the Python side and we don't need to actually store those obj inside the GEOS STRtree (even if it allows to do that).
We already store the input geometries on the python class, so we could also perfectly store the objects as an array/list as well. Assume that you have an iterable of (geom, obj) tuples as input. Then getting a list of geometries and corresponding objects is basically geoms, objs = list(zip(*input)); the geoms can be stored in the GEOS STRtree, and when doing a query and if we want to return the obj instead of the integer indices we get from the underlying GEOS query, we can return [objs[i] for i in idxs] (note for simplicity I showed python code, but this could also all be vectorized/optimized with numpy arrays).

I think this is similar as what rtree does? It allows to insert, in addition to the integer id and bbox, also a generic (picklable) obj, and at query time, you can ask for the object instead of the id. See https://toblerity.org/rtree/tutorial.html#using-rtree-as-a-cheapo-spatial-database
Personally, I have never used this ability of rtree, so can't really judge about it. But it would be good to get some idea or feedback on whether and how this is used in rtree.
(to be fully correct, in geopandas we actually used to insert the index label of the Series as obj, but we never did anything with it afterwards).

I haven't seen it discussed yet, maybe because it's so obvious, but storing only indexes means that only geometries in a container can be indexed. Right? And storing only integers means only containers that are indexed with an integer can be used. Python is more flexible than this. Lists and arrays require integer keys, but mappings can use any immutable object as a key. What would you all think about allowing storage of any Python object?

I don't fully understand the logic here. Right now the STRtree in Shapely does not accept a geometry, but an iterable of geometries. The alternative would be to have an iterable of (geom, obj) tuples as input, I assume? (and the obj gets returned from the query)?
That's certainly more flexible for the user (the current behaviour of returning the geometry would be mimicked by (geom, geom) tuples, the proposal of returning integers by (geom, i) tuples). But I don't understand how that enables to store "any" python object.
To take the practical example of a mapping: assume you have a dict of {key: geom} structure, you still need to convert this to an iterable of (geom, key) tuples to be able to store it, which could be something like STRtree(zip(dict.keys(), dict.values())). So the interface doesn't allow to directly store the dictionary, you still have to do quite some manipulation to get to that. And this way you get the dictionary keys back from the query function. But with integer indices this is very easy to mimic as well: you pass the dict values (geoms) to the tree (STRtree(dict.values())), and can convert to integer index from the query to the dict key with list(dict.keys())[i].
Some other notes:

The current implementation of STRtree in pygeos actually stores the addresses of the geometry in the array of geometries, and doesn't store actual integer index objects (on suggestion of @dbaston)
The current implementation also releases the GIL for queries: this is something that I certainly would like to keep (or at least in case of integer indices as output), so that would probably be a complication for generic objects.
If we would like this generic interface of (geom, obj), I think this is still easily possible on the Python side and we don't need to actually store those obj inside the GEOS STRtree (even if it allows to do that).
We already store the input geometries on the python class, so we could also perfectly store the objects as an array/list as well. Assume that you have an iterable of (geom, obj) tuples as input. Then getting a list of geometries and corresponding objects is basically geoms, objs = list(zip(*input)); the geoms can be stored in the GEOS STRtree, and when doing a query and if we want to return the obj instead of the integer indices we get from the underlying GEOS query, we can return [objs[i] for i in idxs] (note for simplicity I showed python code, but this could also all be vectorized/optimized with numpy arrays).

Further thoughts about this?

I dislike using functions that have different return types depending on a keyword argument. I would expect this to be a source of bugs.

BTW, I agree, in general, that a changing output type depending on a keyword is not always the nicest API design. In the RFC discussion, an alternative that was raised was to have two separate methods for this reason (eg query_index vs query_gemetry).
Personally, I see the return_geometries keyword mostly as a good compromise given the already existing STRtree query method. Since an integer or a geometry is quite different, and it's a very explicit keyword, I personally don't think it would cause many bugs in this case.
To also stress another point: for me, this is mostly a discussion for the API on the python side. IMO we can perfectly keep the STRtree code at the C level to only work with integers for simplicity, and at the python level we can provide wrappers to return other values than integer indices.

Friendly ping for this discussion.

From a user perspective it would be nice to have an explicit procedure for recovering some or other identifying id associated with a geometry.
Further, it would be nice if this id parameter could be set explicitly to concur with data structures created by the user outside of STRTree.
Use-case: when using various data structures, e.g.:

a node in a graph of nodes which has a 'geom' attribute pointing to a Point geometry;
a building element in a dictionary of buildings which has a geom attribute pointing to a building footprint.

Then I need to use an STRTree to recover nearby adjacent nodes or buildings etc., and it is not the geometry that I'm looking for, per se, but the id which I can then use to retrieve whatever attribute I need from my own data structures (which may or may not be a geom or an id.)
I realise this is bit of a hack, but at the moment (existing shapely versions) I overload the geometry object to contain a custom uid so that when STRTree returns the list of geoms I can parse these and pull out the identifying uid which I can then link back to the originating data structures.

@songololo one way to do this is to create two parallel numpy arrays: one of your id values, and one of your geometries.  Create the tree from your geometries, and query it to return indices of the geometries (as proposed here) instead of geometry objects.  The returned indices can then be used to index into your array of id values and return your original ids for the geometries that resulted from the query against the tree.

@songololo in #1112 I have a proposal for a tree that supports bringing your own integer identifiers. This is something I would like to have, too.

To be clear, also in this PR it would be easy to add the functionality to allow passing custom ids (without storing them in the actual underlying C tree, but just storing them in the python tree object).
I am personally certainly fine with adding such capability in general (it can indeed be more convenient than having to keep track of the mapping yourself).
But so, in my mind, the main question is not so much about capabilities, but the final API question about how to expose the different options to the user (as I listed several options in the top post):
using a keyword like return_geometries=True/False in a single method (current state of this PR) vs separate methods like query_geoms() and query_items() (as in https://github.com/Toblerity/Shapely/pull/1112)?
(personally, I have a slight preference for the keyword instead of the separate methods, but I can certainly live with the other options as well as a compromise)

😂 to muddy the waters a vote for @sgillies suggestion of keeping the return types distinct per method name as this keeps the mental abstractions cleaner and reduces potential downstream errors. By having distinct methods coupled to distinct return types my inclination is that discovery of functionality is also a bit easier for end users because it is sometimes easy to miss or otherwise gloss over the implications of keyword options.

Just to make it easier to compare and discuss both approaches / PRs, I quickly added the ability to store custom ids with a list of (geom, item) as input in this PR as well. This gives:
>>> from shapely.geometry import Point
>>> from shapely.strtree import STRtree
>>> geoms = [Point(i, i) for i in range(10)]

# passing list of geometries
>>> tree = STRtree(geoms)
>>> tree.query(Point(2, 2).buffer(1.0))
[<shapely.geometry.point.Point at 0x7fc3a21fc550>,
 <shapely.geometry.point.Point at 0x7fc3a21fc520>,
 <shapely.geometry.point.Point at 0x7fc3a21fc4c0>]
# this returns "default" (0..n) indices
>>>> tree.query(Point(2, 2).buffer(1.0), return_geometries=False)
[1, 2, 3]

# passing list of (geom, id) tuples
>>> tree = STRtree((g, i+1) for i, g in enumerate(geoms))
# this now returns the custom (user-provided) ids
>>> tree.query(Point(2, 2).buffer(1.0), return_geometries=False)
[2, 3, 4]

Just reading up on the discussions here. About the general API, I don’t think it is a good thing to change things unless awe have to. Also, a function should have a return type that is independent of its input parameters. So I like to take side with @sgillies and @songololo on that one. I’d opt for keeping the current method as is, and adding a “query_index” method.
User-supplied labels would be easy to make, but I’d stear clear of the list comprehensions and make the API like “STRTree(geometries, labels=None)” defaulting “labels” to “np.arange(len(geometries))”
Implementation-wise, the strtree will just contain primary keys, which can be mapped as a last step to geometries (or other labels). In pygeos, STRTree().geometries is already there and can be used for that purpose.

@caspervdw yes, I agree that we should disentangle geoms and values and use two input sequences (one optional). Thank you. I can see how this helps efficient implementations.

Coverage decreased (-0.1%) to 85.345% when pulling e62920068e636ed23e73da69603146c41931ab17 on jorisvandenbossche:strtree-return-indices into bd64faa5f064afc41a7e4f8255b20fd8bc013ab2 on Toblerity:master.

Sorry for the very slow follow-up here.

About the general API, I don’t think it is a good thing to change things unless awe have to.

For completeness, not changing the API here in Shapely will also mean a change in API for some users, as it will mean a change for people already using pygeos (and a change for users of geopandas' GeoDataFrame.sindex.query(..), unless we keep that as it is, but which gives an inconsistency with Shapely, which is also not ideal).
The question is also what we do with the query_bulk() method, which also returns integer indices (keep as is, or should we also add _items to that?)

Implementation-wise, the strtree will just contain primary keys, which can be mapped as a last step to geometries (or other labels).

Indeed, and that's what I am also already doing here.
I updated this PR to mimic the latest version of https://github.com/Toblerity/Shapely/pull/1112, but using the above approach just storing primary keys in the tree, and mapping that to custom items or geometries as a last step.

@sgillies I updated this PR after your merge of https://github.com/Toblerity/Shapely/pull/1112 (still need to fix some tests and the pickling). It doesn't change any user facing API now (after your refactor of that in #1112), but only refactors the implementation (how to store the items).
As mentioned in https://github.com/Toblerity/Shapely/pull/1112#issuecomment-875108728, this version is closer to what we would do in the shapely-2.0 branch on top of the C-based STRtree. IMO it is useful to already do this now.

I opened a new, clean PR with just the refactor on top of #1112 that remained in this PR -> https://github.com/Toblerity/Shapely/pull/1177. So closing this one which started as a different discussion (the exact API).


super-resolution before reconstruction?

I note that the resolution is limited to 256? Is it possible to apply a super-resolution model like tile-controlnet to obtain high-resolution images and then use neus resconstruction to get a much higher quality 3d generation?

Hi, the current version only uses a resolution of 256. Increasing the resolution by SR module could be a promising solution but I'm not sure if this would break multiview consistency or not. Maybe, I could give it a try after I clean and release the codes. Thanks for your advice!


PNPM failed to run dev script

Describe the bug
I have received the error below (see screenshot), after I ran pnpm i and then pnpm dev. Strangely enough, if it was npm or yarn, when executing the dev script, everything is running fine and dandy.
Steps to replicate
To replicate, I first ran:
pnpm create @quick-start/electron

Then, chose react with typescript, with all yes except to 'download mirror proxy` question.

Any assistance or clues to the understanding of this error, will be greatly appreciated 🙏
Electron-Vite Version
<EMAIL_ADDRESS>Electron Version
28.1.4
Vite Version
5.0.12<EMAIL_ADDRESS>Validations

[X] Follow the 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.

The installation was not successful and you need to clear the pnpm cache. Enable mirror proxy if you are in Chin and reinstall.

The installation was not successful and you need to clear the pnpm cache. Enable mirror proxy if you are in China and reinstall.

Thanks Alex, I've attempted your suggestion to run pnpm store prune.
The complete solution with your suggestion, are as described below steps:

pnpm store prune.
Next, (this is required step) run rm -rf node_modules to delete node_modules folder.
Perform fresh pnpm i.
Lastly, run pnpm dev to expect successful dev env launched.

Thank you @alex8088 !  🙌
FYI, for those who ran into this issue like mine, below are the versions of node & pnpm:

pnpm = 8.14.3
node = 21.5.0


Python vs C extension difference with large db

We have a custom built db with the following details:

record size: 32
node count: 542155119
file size:<PHONE_NUMBER>

The database works with python implementation. The latest maxminddb python library came with a vendored copy of libmaxminddb, and we noticed that the database doesn't work with the C extension.
Opening the database succeeds, but a query for an IP results in
maxminddb.errors.InvalidDatabaseError: Error looking up <IP_ADDRESS>. The MaxMind DB file's search tree is corrupt

Slightly smaller database works properly also with the C extension, so maybe the database size is the problem?

I sent you an email regarding the db file.
We have successfully created the db with the go driver, and will switch from the perl writer to that in the near future.

maxminddb 2.5.2 has been released with a fix for this.


Look into scss mixin for fade transitions

From Rachel regarding fade transitions:
"This is really cool. I would love to add this to the Tile component https://www.figma.com/file/471iS3QrpPtXZpS1xbsJ20/Components?node-id=5536%3A190
which isn't in the design system yet but we got a start on it in the app with the project builder start page.
https://user-images.githubusercontent.com/4008333/127717139-7e23efe8-a838-496a-a06c-c1fb4d4d50fd.png
Trying to think how we can make this reusable in both places. Right now this is a static html page so not totally sure the lift to do this in React.
Maybe a first step could be to extract it to a scss mixin to be able to be used multiple places? Perhaps taking in the initial offset height as a param?"

Moving away from Sass


Getting a blank page when using in create-react-app

I'm getting blank page, when I'm trying to render a CardElement using latest create-react-app(v2.1.1). Here it is the code I'm having:
import React from 'react';
import { StripeProvider, CardElement, Elements } from 'react-stripe-elements';

export default () => (
    <StripeProvider apiKey={'pk_test_key'}>
      <Elements>
        <form>
          <CardElement />
        </form>
      </Elements>
    </StripeProvider>
);

@aiven715 Is there any error on the page? I have a simple demo in create-react-app that seems to work ok.

@asolove-stripe no errors, just stripe form is not visible. I've fixed it by setting width of the form manually

Ah, glad you got it to work!


FiQA GoogleDrive download link broken.

Thanks for releasing the dataset!
However, it seems that the following google drive link provided in README is broken:
"Download the raw corpus FiQA_train_doc_final.tsv and question file FiQA_train_question_final.tsv into data/fiqa from https://drive.google.com/file/d/1BlWaV-qVPfpGyJoWQJU9bXQgWCATgxEP/view."
Could you please look into this problem?
Thanks!

Ok it seems that these links are from the official website of FiQA. I am sending out an email to the organizer about this issue.

Why close this issue? Its impossible to replicate without this dataset 😅


Display problems of session window in "Camillasso"

When switching from session to "Sessioninfo" or "Auswertung" as a user (tested on iPad and Mac) and then back to the session, the session no longer appears:

On the Macbook (as owner), session and evaluation screen appear again, but after a long loading time and with strange display problems. For example, the audio file in the session screen seems to be different from the one in the "Auswertung" screen:
Audio-File Session screen:

Audio-File "Auswertung" screen:

fixed with https://github.com/KoALa-MHF/koala-app/pull/317

Assigned to you since you provided the fix. Once we have our next release, we can close it.


when to support neo4j 3.0?

as title.

hi @dhcn , I had intended to have the alpha upgrade ready by this weekend just gone, but there is a lot of re-writing to do. I would say I'm about 60% the way through now, which I hope to finish evening/weekend this week. Then it goes to @nigelsmall to review.
Thanks,
Dave

Hi @the4thv ,
Do you have an ETD for this upgrade? Thanks!

Hi @dhcn , sorry for the delay on this, paid work is getting in the way... :(
I've got a few days off this weekend, so I intend to push on through this. I may well release forked version that is not backward compatible first on my own account. I will update here as soon as I do.

@the4thv Many Thanks.

Hi @the4thv,
Thank you for doing the job! Any news about this?

Hi @DanJourno, sorry for the delay, I'm still working on it, though nowhere as much as I'd hoped. I'm finishing on a project this week and I will have more time for this then.

@the4thv Thank you very much!

@the4thv any updates on expected time to get neomodel working with neo4j v3?

Hi @ahrennsiva, paid work has necessarily got in the way, but that should be ending Monday (should have last week!). Once that's the case I will be working on this regularly and hope to get something out within a month or so.

Just want to comment that I love neomodel and am using it in production, but we are eager to migrate to neo4j3.  At graph connect right now and am excited about all the new features.  Thanks for working on this, looking forward to the new release!

This is a duplicate of #209 which I opened.
Should I close mine to have only one issue as reference?

I've just pust to master support for neo4j 3 (using the neo4j_driver). I intend to push to pypi in a week or so after i have some feedback and fixed some bugs


Add reset_simulator action

This action is a wrapper around few xcrun simctl commands.
xcrun simctl erase <device> | all will fail if device is currently booted.
Additionally, if you have more than one Xcode app installed or more than one simulator runtime available, then running xcrun simctl erase "iPad Retina" will (for example) erase iPad Retina for iOS 8.4, while you actually want to reset iOS 9.1 device.
reset_simulator combines shutdown and erase actions and allows you to reset the same device you specify with destination option for xcodebuild, xctool, scan or other tool.

@samrobbins I've rebased it on top of master to have a green build. Let me know if there are other issues to address with the code. Thanks :+1:

Hey @mgrebenets, thanks for the PR, this looks great already. I added some more comments before it's ready to be merged :+1:

Thanks. I'll fix those up in this pr.
On Fri, 5 Feb 2016 at 12:32 PM, Felix Krause<EMAIL_ADDRESS>wrote:

Hey @mgrebenets https://github.com/mgrebenets, thanks for the PR, this
looks great already. I added some more comments before it's ready to be
merged [image: :+1:]
—
Reply to this email directly or view it on GitHub
https://github.com/fastlane/fastlane/pull/1126#issuecomment-180143227.

@KrauseFx fixed it up, should look better now :)

Looks good to me, added one last comment. Waiting for @samgreen for review :+1:

You have summoned me @krausefx? What can I do for ya buddy? Love fastlane, but I have no context for this.

Wups, really sorry for pinging you @samgreen, I meant a review from @samrobbins :+1:

@mgrebenets i like your idea for putting this into fastlane_core with a thin wrapper around it her in fastlane, would you want to make that change and reference the PR here?


Text tool completly broken

The text tool is completely broken:

The typing is always at the origin
The bounding box doesn't disappear when finishing typing
Text is only rendered properly after the document is panned
etc.

Regression introduced in #1946


Update to use better error message

Fixes #724
Verified that it works locally. We use repr in the test in order to see the error and allow pytest to catch

This looks good to me. Begs the question for me though, how are we handling these exceptions as they're thrown in tempo? And similarly, are we passing back to the client enough metadata that we would be able to properly translate the error messages on the UI side? How can we make that guarantee going forward. Food for thought. Looks good though!

@Cmancuso definitely agreed. Although I think this error in particular is more geared towards OS users/developers internally, it's definitely important for us to keep in mind that we need to pass enough information downstream to make useful messages and allow users/developers to take action upon the errors raised.


Add install guide for mac user

Fossligth scanner is not work just install with pip or pip3
After install with pip or pip3 I faced import error is as follow.
ImportError: failed to find libmagic. Check your installation
It can not fix pip install magic or pip install libmagic.
I fix it with brew.
Please add one line for mac user in install guide
brew install libmagic

@Sihan-Son ,
This link, https://fosslight.org/fosslight-guide-en/scanner/etc/guide_virtualenv.html , provides guidance on what to pre-install.
In the README, it is a page linked to the 'How to install' section.


nvidia_x11: 470.57.02 → 470.63.01 (backport to release-21.05)

Motivation for this change
This cherry-picks the commit
nvidia_x11: 470.57.02 → 470.63.01

to allow builds with linuxPackages_latest. Fixes #137507.
Should be tested somewhat before merge, hence draft.

Duplicate of https://github.com/NixOS/nixpkgs/pull/138132?

@r-burns Indeed, looks like it. Thanks for noticing!


Fixes #151

A couple of simple changes to reduce lock-time on a shared channel, and reduce lock-time accessing shared tracks field.
#151

Concurrent programming is hard. Thank you for your hard work fixing this bug!


Get API Key for weathrly

From https://www.wunderground.com/weather/api/
Don't forget to add API key to .gitignore file

Completed


Does the API in JSON format support CORS response header?

This is the output of my curl command:
~$ curl -Iv https://wttr.in/?format=j1
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to wttr.in (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=wttr.in
*  start date: Mar 19 03:08:07 2020 GMT
*  expire date: Jun 17 03:08:07 2020 GMT
*  subjectAltName: host "wttr.in" matched cert's "wttr.in"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> HEAD /?format=j1 HTTP/1.1
> Host: wttr.in
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.10.3
Server: nginx/1.10.3
< Date: Mon, 27 Apr 2020 13:22:00 GMT
Date: Mon, 27 Apr 2020 13:22:00 GMT
< Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
< Content-Length: 45355
Content-Length: 45355
< Connection: keep-alive
Connection: keep-alive

<
* Connection #0 to host wttr.in left intact
~$

I want to call this API in the JavaScript code of the HTML page, and I want to avoid the error No 'Access-Control-Allow-Origin' header is present on the requested resource, what should I do?

Please try now:
$ curl -I wttr.in/?format=j1
HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Mon, 27 Apr 2020 13:46:17 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 45432
Connection: keep-alive
Access-Control-Allow-Origin: *

It works well! Thank you very much 😁

I found that there will be a text at the end of the JSON API, which will result in an error when parsing JSON. Also, the Content-Type of the response header is not application/json, is this a feature or a mistake?

It was a bug of course; please try it now

It works wonderfully now, thank you very much!

If you are working on a public service that will use the data, you can send a link to it as soon as it will be ready

Actually, I just use it to create a personal GitHub Pages, which will be read by my iOS shortcuts App
https://fantasticmao.github.io/shortcuts/weather/

Looks cool. You can publish it as an opensource project, that could be useful for other developers

Yes, and it is in my plan 😁


Fix problem with empty line-chart

Sometimes the Line-Chart resets itself. Find a solution that this is not happening. Check database if really empty?

I think it is good.
I can't see the issue. maybe it is not code problem.

Unfortunately there's no better way to fix this. When Azure Backend is reloading or in a new pod the line chart is missing, but building up the next days.


Katacoda lab "Getting started with the flogo web UI" needs update

I'm submitting a ...  (check one with "x")
[] bug report => search github for a similar issue or PR before submitting
[] feature request
[X] support request
[] general question

Current behavior (how does the issue manifest):
The "Getting started with the flogo web UI" code lab on Katacoda (https://katacoda.com/retgits/scenarios/flogo-webui) contains a few errors that would make it difficult for someone new to the project to get around.
On Step 6: It says to "click on the large grey box called Flow params", but no such box exists on the current page. Clicking on "Input / Output" next to the trigger does cause a popover that says "Define params". Unclear how to add the params given current wording.
On Step 8: It says, "You can paste in string.concat("Hello ", $flow.name) and click the big blue save button to complete this step". When one cuts and pastes this directly - with backslashes intact - the final product responds with the exact code, not with the interpreted value. The backslashes are not only unecessary, they actively break the expected output.
Also Step 8: It says "Select the option for Trigger Reply on the left hand side..." No such option exists. Instead, there is a tab at the top that says "Map from Flow Output", which appears to be the correct one.
Expected behavior:
As mentioned above, the documentation does match the UI. I expect it to match.
Minimal steps to reproduce the problem (not required if feature enhancement):
See above.
What is the motivation / use case for changing the behavior?
This will stymie any new developers just trying to get familiar with the Web UI.
Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):
Mac OS X 10.13.5, Chrome Version 67.0.3396.99 (Official Build) (64-bit)
Flogo version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X
Whatever is in Katacoda
Additional information you deem important (e.g. issue happens only occasionally):

Hi Rob, thanks for letting us know! I've updated the scenarios and as soon as the builds are picked up by Katacoda you should see the updates.


The docker image is too large

Since the image contains whole Haskell environment, which is not necessary to run the executable of lamyuda, the image is so large that it takes too much time to pull it.

Before: >2GB After: <50MB


Zoom level is not maintained after Back navigation

Attach (recommended) or Link to PDF file here:
10.1093<EMAIL_ADDRESS>Configuration:

Web browser and its version: Google Chrome Version 64.0.3252.0 (Official Build) canary (64-bit)
Operating system and its version: Win 10 10.0.16299 Build 16299
PDF.js version: 1.8.557
Is a browser extension: Yes

Steps to reproduce the problem:

Open document
Click on a cross-reference (e.g., Barkow et al.[1992] on p.2)
Click on the Back arrow

What is the expected behavior? (add screenshot)
You're supposed to be taken back to p.2 with the original zoom

What went wrong? (add screenshot)
The zoom level is wrong (that of the reference)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Closing as fixed by PR #8775.


add riuvshyn to adm-list

add riuvshyn to adm-list

Can one of the admins verify this patch?

[test]


Link to Module Broken  +  Please link to what to do to get access to this command

On top of page shows Link to Module Exchange: 404 - Page not found
Please link to what to do to get access to this command "Get-OMEConfiguration".
I read somewhere there are parameters to this command, what are they?
Thank you
Bart

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

ID: 86ae2cba-8c1d-ebd1-9834-f5a4881830cc
Version Independent ID: 6134df0d-c336-4288-c704-63cf742c0c5e
Content: Get-OMEConfiguration (exchange)
Content Source: exchange/exchange-ps/exchange/encryption-and-certificates/Get-OMEConfiguration.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

@blouwagie:

Known issue; we're working on it. Technically, there is no "Exchange" module.

Interesting suggestion. The Exchange Online PowerShell connection instructions are in the conceptual area "above the line" in the section on the left side of the page: https://docs.microsoft.com/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/connect-to-exchange-online-powershell.

Normally, most cmdlets have some parameters. These would be visible in the SYNTAX section at the top of the topic, and explained fully and individually further down in the topic. But, there are no parameters available for Get-OMEConfiguration. Get- commands only allow you to view, not change properties. On the other hand the Set-OMEConfiguration has lots of parameters.

The Exchange module link issue was fixed this week. Thanks again, for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


go install command does not download the current version.

Hi team,
go install command does not download the current version.
example :
go install github.com/projectdiscovery/tlsx/cmd/tlsx@latest
normally it should download the released version 0.0.7 but it downloads version 0.0.6.
I tested it on different devices and it won't download the latest version. can you please check?
Best Regards.

@kylojsja it does download latest code, it's just the version number in banner were not updated in last release that is now fixed with https://github.com/projectdiscovery/tlsx/pull/91, thank you for pointing this out.


customer name is not displayed under item detail view

[x] transactions under detail page using some filter (sales order)

issue fixed !


add server name for secure_channel

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

Ping

@nathanielmanistaatgoogle Isn't server_host_override only for testing?

Closing as a duplicate of #5698 (itself awaiting discussion in #5697).


Acceptance testing with loading content from remote source

Hi there,
I followed issue 81 (https://github.com/miguelcobain/ember-cli-selectize/issues/81) to create a select dropdown with remote AJAX content. This works pretty well, but when writing an acceptance test, I can't seem to get this tested. Can I use click, fillIn or any other events to test this? Initially, my dropdown list is empty, then I want to type something in it and choose any result (first result, doesn't really matter). This result should be checked against a factory created by ember-cli-mirage.
Anyone who knows how to do this and maybe can show me in a fiddle? Thanks! :+1:

It's very difficult to simulate real user events in tests. I recommend trying to use Syn for that: https://github.com/bitovi/syn
Alternativaly, try triggering a mousedown event through jquery.
Ember.run(() => {
  this.$('.selectize-input').trigger(Ember.$.Event('mousedown'));
  this.$('.selectize-dropdown .option').first().trigger(Ember.$.Event('mousedown'));
});

$('.class').click() may also work.
As a last resort, try to pass in the filterText property to simulate a user type.
Take a look at selectize's tests. They use Syn and are really good.

Hi @philipdesmedt
How did that went?
I would like to know how to do the acceptance tests also, so if you already nailed it, it would be awesome if you could tell me how :D

Sorry for the late reply, but I haven't gotten any luck with acceptance testing this so far. We skipped tests using ember-selectize for now, unfortunately...
Let me know if you found a straightforward solution though! Syn might be the way to go after all..


pipeline-tools 0.1.15 update post 2.5.4 upgrade issue

What kind of request is this (question/bug/enhancement/feature request):
Updating to 2.5.4 updated pipeline-toole from 0.1.14 to 0.1.15 which encounters errors
Result:
2021-01-08T17:19:44Z k8-prod-cron-2 confd[15]: INFO /etc/nginx/nginx.conf has md5sum f7984934bd6cab883e1f33d5129834bb should be 86638ad3e507bdb73314b9ec2be59e5f
2021-01-08T17:19:44Z k8-prod-cron-2 confd[15]: INFO Target config /etc/nginx/nginx.conf out of sync
2021-01-08T17:19:44Z k8-prod-cron-2 confd[15]: ERROR "2021/01/08 17:19:44 [emerg] 582#582: host not found in upstream \"docker-registry.project-vmxs4-pipeline:443\" in /etc/nginx/.nginx.conf641723885:20\nnginx: [emerg] host not found in upstream \"docker-registry.project-vmxs4-pipeline:443\" in /etc/nginx/.nginx.conf641723885:20\nnginx: configuration file /etc/nginx/.nginx.conf641723885 test failed\n"
2021-01-08T17:19:44Z k8-prod-cron-2 confd[15]: ERROR Config check failed: exit status 1
2021-01-08T17:19:54Z k8-prod-cron-2 confd[15]: INFO /etc/nginx/nginx.conf has md5sum f7984934bd6cab883e1f33d5129834bb should be 86638ad3e507bdb73314b9ec2be59e5f

Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.5.4
Installation option (single install/HA): HA
Ingress (NGINX) daemonset limited to certain nodes using annotations

Cluster information

Cluster type Custom (vms in vsphere):
Machine type (vm)
Kubernetes version (use kubectl version):
kubectl version

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.16", GitCommit:"d88fadbd65c5e8bde22630d251766a634c7613b0", GitTreeState:"clean", BuildDate:"2020-12-18T12:07:12Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client: Docker Engine - Community
 Version:           19.03.12
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        48a66213fe
 Built:             Mon Jun 22 15:45:49 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.12
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       48a66213fe
  Built:            Mon Jun 22 15:44:20 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Not wholly clear what pipeline-tools is for as the repo-readme is empty.
Is it a left over from the CD pipeline before fleet? (i.e. can I just delete it)?

Not wholly clear what pipeline-tools is for as the repo-readme is empty.
Is it a left over from the CD pipeline before fleet? (i.e. can I just delete it)?


Simple embeds

Problem
Currently, embeds simply duplicate the entire loom editor.
And while the editor itself is cool and all, I really like editing those files – but in embeds, I want something like this:

obsidian-csv-table

I.e. cool syntax allowing to filter and sort, but end-goal is to have a basic md table.
Solution
Maybe it's possible to take the groundwork behind obsidian-csv-table and make it compatible with .loom format, – of course, though, it's hell lot of work.
For example:
```csvtable
source: my_loom_file.loom
filter: population < 100000000
```

Or like this:

```csvtable
source: my_loom_file.loom
sortBy: name
```

Would generate simple embedded «pure markdown» table like this:

name
population

Colombia
50340000

Russia
144400000

United States of America
328200000

Greate idea !


Bot crashes in DM

Describe the bug
In the event a user DMs the bot with a command that has some form of the isHighRoller() function. This is due to the fact that since the user is not considered part of a server at the time msg.members.role is equal to null.
To Reproduce
Steps to reproduce the behavior:

DM the bot with cc!kick
The bot will crash due to null variables.

Additional context
The bug is fixable by having the condition `if (!(msg.guild === null)) checked before the bot attempts to run commands.

Rather than having nested if blocks, it's probably best to just change the message listener in app.js to something like this:
client.on('message', (msg) => {
  if (message.channel.type === "dm") {
    return;
  }

  if (msg.content.substring(0, 3) === 'cc!' && !(msg.member === client)) {
    commandParser(msg);
  }
});

We could also put a response in before the return if we want.

Another example of how we might address this:
https://discordjs.guide/command-handling/adding-features.html#guild-only-commands
It's fairly similar to what's discussed above.


Doesn't work with System.Text.Json source generators

Describe the bug
Apparently this was reported in #565 and subsequently fixed in #587; but I'm still encountering the exact same problem on Vogen version 4.0.8 and .NET 8.
Steps to reproduce

dotnet new console
Put this in your Program.cs:

using System.Text.Json;
using System.Text.Json.Serialization;
using Vogen;

var foo = new Foo(Test.From("abc"));
Console.WriteLine(
    JsonSerializer.Serialize(
        foo
    )
);
Console.WriteLine(
    JsonSerializer.Serialize(
        foo,
        JsonContext.Default.Options
    )
);

public record Foo(
    Test Test
);

[ValueObject<string>]
public readonly partial struct Test;

[JsonSerializable(typeof(Foo))]
[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.KebabCaseLower)]
public partial class JsonContext : JsonSerializerContext;

dotnet run and look at the output:

{"Test":"abc"}
{"test":{}}

Expected behaviour
The second JsonSerializer.Serialize call that uses the source generator should work.

Hi @aradalvand - thanks for the bug report. I think the issue is with the documentation (or lack of!). You need to specify the converters in your options. The converters (or rather, a factory for converters, are generated by Vogen and are named VogenTypesFactory.
This snippet works:
using System.Text.Json;
using System.Text.Json.Serialization;
using Vogen;

var options = new JsonSerializerOptions
{
    WriteIndented = true,
    PropertyNamingPolicy = JsonNamingPolicy.KebabCaseLower,
    Converters =
    {
        new VogenTypesFactory()
    }
};

var foo = new Foo(Test.From("abc"));

var ctx = new JsonContext(options);
Console.WriteLine(JsonSerializer.Serialize(foo, ctx.Foo));

public record Foo(Test TestValueObject);

[ValueObject<string>]
public readonly partial struct Test;

[JsonSerializable(typeof(Foo))]
public partial class JsonContext : JsonSerializerContext;

Please let me know if this doesn't fix the issue and I'll reopen and investigate.
Thanks again!

@SteveDunn But JSON source generators are supposed to be able to pick up converters (provided that the types are annotated with the JsonConverter attribute) automatically. So having to do it like this is a little bit of a bummer.
Having investigated the problem a little more after creating this issue, I found out that this is due to the fact that the Vogen source generator would need to run before the JSON one, in order for this automatic pickup to happen — see this Stack Overflow answer.
The workaround for this would be putting the Vogen value objects in a separate project, and then referencing that project in the one that contains the JsonSerializerContext; this would've worked perfect had it not been for #613. Please take a look at that issue.

Ah, yes, separate projects is a good solution. As that answer says, source generators are completely independent of each other.
I should get a chance to look at the internal to public item tonight or over the weekend.
Thanks for the feedback!

@SteveDunn Thank you <3

@SteveDunn Thank you <3

Also, if it unblocks you in the meantime, you could add an InternalsVisibleTo in the project with the value objects


Followup to CAMEL-8072

This is a small followup to CAMEL-8072, which was fixed in e9dded769bff8e060c64e62c962cd552d24d4c70.
Yoshiki, Shinpei, Hideaki, and Mei

Thanks. The PR has been merged. Can you close this PR? :-)

Thank you for merging:)


Can i provide also the KeyId ?

Question
Is there a simple way to provide to ids4 also the key id instead of just the RsaKey ?
I'd like to use the same certificate to sign some other stuff, and since i'm already storing the public keys with their ids in the client i'd like to expose the public key with it's id also in the other service that do that (it is not sure that the key will be changed simultaneusly, it might take some time to get all the other services updated so i want to them to have their copy of the private key, and key id) ...
Or
Is there a way to generate the same key id (kid) that can be seen in the jwks starting from the certificate ?

We allow you setting a SecurityKey IIRC - this has a KeyId property.

Amazing! and shame on me for not realizing that!


canvas, capi: expose force update flag.

Changes:

Force flag is exposed to capi bindings. It is necessary to improve of
stability of thorvg clients. In some cases (after buffer change) it is
necessary to re-render shapes.
Fixed issue with stroke rle reset

@API-Changes:
from: tvg_canvas_update(Tvg_Canvas* canvas);
to: tvg_canvas_update(Tvg_Canvas* canvas, bool force);

I am not against this code change. I recommend splitting these two problems into two commits.


A12Z still got panic full

IPad Pro (11inch-2nd,A12Z) 128G,iPadOS 16.3.1,still got panic full and reboot.
Misaka ver: latest

On most occasions:
"panicString" : "panic(cpu 5 caller 0xfffffff010e6854c): Kernel data abort.

sooooorry, but 8.1.1 doesn't work on the ipad 😢 .Still reboot again and again.


Remove all page permission

Does the extension really need permission to view the pages?

Done! No permissions needed!


Remove references to GoBGP, which isn't present any more

Description

Sadly, it hasn't been updated to v3 yet but the docs still show it.
Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

None required

Deploy preview for calico ready!
Built with commit 4195f835539088959b09482e3cc7436d3f583ff7
https://deploy-preview-2316--calico.netlify.com

Deploy preview for calico ready!
Built with commit 7d29ec937e24a77c7cc40a9bdce7b90b1a6979a9
https://deploy-preview-2316--calico.netlify.com


cli: allow node status to work in unavailable/broken clusters

Dup of https://github.com/cockroachdb/docs/issues/2041.


Subclassing from GeoJSON creates invalid GeoJSON

Hello,
In base.py/GeoJSON, the line:
self["type"] = getattr(self, "type", type(self).__name__)
leads to the creation of invalid GeoJSON in subclassing from GeoJSON.
Here is an illustration:
from geojson import Point, Feature

class Vertex(Feature):
    def __init__(self, arr: [float]):
        Feature.__init__(self, geometry=Point(arr))

v = Vertex((1, 2))

print(isinstance(v, Feature), v)
# True {"geometry": {"coordinates": [1, 2], "type": "Point"}, "properties": {}, "type": "Vertex"}
# type="Vertex" is invalid geojson

Issue is of course using type(self).__name__ as a default value.
It is very anoying because it prevents other packages from not recognizing valid GeoJSON.
P.

Hugly workaround is to insert proper type when subclassing:
class Vertex(Feature):
    def __init__(self, arr: [float]):
        self["type"] = "Feature"
        Feature.__init__(self, geometry=Point(arr))

Hi @devleaks thanks for the issue. https://datatracker.ietf.org/doc/html/rfc7946#section-7 states that

GeoJSON Types Are Not Extensible

Implementations MUST NOT extend the fixed set of GeoJSON types:
FeatureCollection, Feature, Point, LineString, MultiPoint, Polygon,
MultiLineString, MultiPolygon, and GeometryCollection.

Sorry, I think I did not express myself clearly. I don't want to and I do not extend GeoJSON.
We are talking python here. I want to extend a python class. Does GeoJSON standard also prevent that??
The problem is that this statement:
self["type"] = getattr(self, "type", type(self).__name__)
sets the value of the GeoJSON type attribute to the name of any python subclass you may derive from a GeoJSON class, leading to invalid GeoJSON when printed, or when other libraries rely on this type attribute and expect a valid GeoJSON type attribute value.
Anyway, the proposed work around (which helps set the type attribute value to a valid GeoJSON value) is ugly but works perfectly. One extra line of code, and a comment with a link towards this issue do the work.
P.


limit ns-meal-carbs to 6 hours

Found out ns-meal-carbs asks 4 days of carb data from Nightscout each call...  That should be limited to ~ 6 hours (max theoretically carb's can live) similar to ns-temp-targets
as discussed on https://gitter.im/nightscout/intend-to-bolus?at=58cc08da1c040b8e0409465a and https://gitter.im/nightscout/intend-to-bolus?at=58cc194aa84f611959b6e668

We'll need to confirm whether this works for our Aussie and Kiwi friends if their treatments are in local time instead of UTC.  I think the "gte" comparison is on the raw string, not the actual date.
A better long-term fix would probably be to check the contents of the carbhistory.json when using it in determine-basal...

Based on @jmcrawford and @jelcrawford's testing, I'm thinking about merging this until we have a more complete fix.  Any objections?

Unless I'm mistaken, we would want to use date -d \\"6 hours ago\\" -Iminutes for this query (i.e. without the -u option for UTC). MongoDB uses a simple string compare on the date, so they both need to be in the same timezone. Treatments are stored in NS with created_at in local time, not UTC.

I copied the -u from this commit: https://github.com/openaps/oref0/commit/1ac8cb83e4dfe9de61eaede15ddb3a081a4dd4ea

@thebookins @scottleibrand
Did some further debugging into the issue with RoboMongo. Here are the queries I used:
db.getCollection('treatments').find({carbs: { '$exist' }, created_at : { '$gte': '2017-03-18'}})
showed indeed that carbs use a created_at in localtime, e.g. 2017-03-17T07:48:59+01:00
Temp targets use created_at in zulu/utc time, e.g. 2017-03-17T06:24:47.472Z. When I used the query:
db.getCollection('treatments').find({eventType: { '$regex' : 'Target'}, created_at : { '$gte': '2017-03-17'}})
I noticed that the carbs are created with mm://openaps/mm-format-ns-treatments/Meal Bolus, wheres the temp targets are set in NS.
So I think this is an oref0 bug and we should
change bin/mm-format-ns-treatments.sh or bin/oref0-normalize-temps.js so that created_at is converted to UTC before uploading it to NS.

I think the created_at in mm-format-ns-treatments.sh must be converted to UTC time. I can get the date/time converted, but am unable to integrated in to the mm-format-ns-treatments.sh. Help is appreciated.
The conversion can be done with
 date --utc +%Y-%m-%dT%H:%M:%SZ --date "2017-03-17T07:48:59+01:00"
where the date must be taken from created_at and stored in created_at

I've been wondering if NS treatments should start storing a date field like entries, we could set the field for new uploads if it's missing, only downside would be some index overhead

The amount of data in treatments is so small, a date index shouldn't be an issue. OTOH as discussed earlier, we should delete most of the indexes in the database that point to fields that are practically never used for querying and which contain a very large amount of entries. Current index set is:
api.indexedFields = [
    'created_at'
    , 'eventType'
    , 'insulin'
    , 'carbs'
    , 'glucose'
    , 'enteredBy'
    , 'boluscalc.foods._id'
    , 'notes'
  ];

Of which I'm not sure we actually should have anything but created_at (possibly a combined index of created_at with eventType). I'm near 100% certain the query optimizer cannot use the other indexes ever and/or we don't actually query by them and maintaining this amount of indexes is very heavy on the DB.

On the issue of created_at being in local time for treatments, I have found that my NS site reports do not show any OpenAPS treatments after 1 pm, while treatments uploaded by Loop are fine. I'm at UTC +11, which strongly hints that the date boundaries are getting messed up. See https://gitter.im/nightscout/public?at=58d0f8ae8fa1633954fe4384.
I suspect that converting created_at to be in UTC time would fix this issue too.

This should no longer be needed now that we're merging pumphistory.json and pumphistory-24h.json


[BUG] [DOCS] [IMPORT] XPOS

Running the xpos first example from the docs has an import erro:
ModuleNotFoundError                       Traceback (most recent call last)
[<ipython-input-14-f2a7ff6796e7>](https://localhost:8080/#) in <cell line: 2>()
      1 import torch
----> 2 from xpos import XPOS
      3
      4 # Create an instance of the XPOS module
      5 xpos = XPOS(head_dim=256)

ModuleNotFoundError: No module named 'xpos'

I checked the init in nn.embeddings, but it looks ok. Doing the full path in the example, resolves the issue:
import torch
from zeta.nn.embeddings.xpos_relative_position import XPOS

# Create an instance of the XPOS module
xpos = XPOS(head_dim=256)

# Generate a random input tensor
x = torch.randn(1, 10, 256)

# Apply the XPOS module to the input tensor
output = xpos(x)

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

It also appears that this import works:
from zeta import XPOS

So, the docs for zeta/nn/biases/xpos/ need to be fixed.

PR https://github.com/kyegomez/zeta/pull/109


[Exceptions] Fix Bug For Missing Callstacks With Eclipsing Exceptions

Summary
For context: https://github.com/dotnet/runtime/issues/91125

Release Notes Entry

Please add a second eclipsing test where the catch block calls another method that throws an exception. This appears to cause the thread stack to be updated as originally expected, but let's add this test to make sure we cover the scenario.


adding new name and hebrew translation

adding my name with optional translation.
hebrew translation for several names

thanks! merged #1


ValueError: Unable to create tensor, you should probably activate padding with 'padding=True' to have batched tensors with the same length.

code：video = image_processor.preprocess(video, return_tensors="pt")["pixel_values"].half().cuda()

Hi there! In case you still have this issue or someone else faces it, it is packages issue. In my case, I modified a few things before installation steps which created unnecessary mismatches that are hard to figure out. What worked for me is re-doing the installation without any modification.


pennylane demo integration

Hey! It's Guillermo, I will be in charge of the integration and review process of your demo. Thanks for waiting 🙂
I was wondering if you could do a PR to the qml repo with the demo integration. This would facilitate the review process. In the readme of the repo there are some instructions on how to do this. It shouldn't take long since you have it done in sphinx.
If you have any questions feel free to write me 🚀

Hey Guillermo,
Thanks for getting back to us!
I have now sent a PR to the qml repo (#606) 😃

There's a couple things I feel I should point out about the demo:

In the PR, there are three proposed demos. The main, most 'important' one is the one titled tutorial_embedding_generalization and it demonstrates desired generalization outcomes. The other two are sort of supplementary, as they illustrate poor generalization performance.
The code only works on versions of pennylane 0.18.0 and prior. I think it could have something to do with the mixed classical/quantum training paramaters not all being recognised as such, but I'm not 100% sure. The code works perfectly fine on version 0.18.0 though.

Thanks!

Hey @Rlag1998 ! Thanks for open the issue to the community demo integration!
In the case of directing to github it would be much more convenient to have a notebook instead of the .py format of sphinx. This way, it would render directly on the web and everyone could see it 😊 Could you make the change?

Hi @KetpuntoG, I've now put all three demos in Jupyter Notebook format. I've put them on a new repository. 😄

I will also update the issue to include the new repository link

I just saw it! Great, this is just what I was looking for! a good README and the 3 notebooks. Now it's my turn to work on it :)
I'll do some final checks and get it ready to be on the web. thank you @Rlag1998


Fixing security issues due to some node packages

Some security vulnerabilities are shown in the repo web-page when using current node modules. Checking if upgrading packages fixes the security vulnerabilities in node packages.
Signed-off-by: Sona Praneeth Akula<EMAIL_ADDRESS>

Also, I was wondering what is the need for node_modules directory in website as it can be
re-generated from package.json?

cc @sagarkrsd

Hi @sonapraneeth-a -- would you like to continue working on this PR?
cc: @sagarkrsd - do you have any suggestions on how to proceed with this PR?

Thank you @kmova.
@sonapraneeth-a I see this PR consists of two things, one is typo fixes and other is vulnerability fixes.
Regarding vulnerability fixes, have you tested all the basic functionalities locally after the docusaurus version upgrade?
Can you post a screenshot of the docs home page after this change?

/stale


[bug] The longest but not the latest css applied.

It doesn't make sense, that if you write mb3 then in some case margin bottom needs to be zero, so you write a conditional mb0, somehow it doesn't work.
I wrote a codesandbox, and it seems only the longest measure applies rather than the latest, which doesn't make any sense to me, since it is not how css supposed to work.

Ok, I understand it is pretty silly because ma0 class is written before ma3 in css, so that's exactly how css works. But this is a problem.


V3.2.1 Devops pipeline has been "not running" always with not admin account

Describe the Bug
admin account can run pipeline，but not admin account can not run pipeline，even admin role、project owner：not run

Environment
kubesphere 3.2.1
k8s 1.20.6

/kind support

Thanks for reporting this issue.
Please feel free to checkout the FAQ.
/close


add label smoothing for adaptive loss

Previously there is label smoothing for cross-entropy.  We want to add label smoothing for adaptive_loss.

refactored the adaptive_loss
added a LabelSmoothedAdaptiveLoss criterion.
add unit test

I am running on GPU, but the machine get restarted frequently.  It is probably easier to have this criterion implemented, and then use the workflow to test the model.


Is there any chance that prisma-filter will work with nestjs ^10.0.2?

Hi, before I dive into the code, is there any chance that prisma-filter will work with nestjs ^10.0.2?

yes, it definitely will, as we are still working with it :)

Looks like I forgot to update the readme when I added Nest 10 support in June last year - yeah, as Nkay said, it's fully supported and used internally by us as well :)
I've just updated the readme so there should be no more confusion.

Danke!


A new generated diff is ready to view: https://github.com/awslabs/aws-sdk-kotlin/compare/__generated-main...__generated-feat-cred-providers

A new generated diff is ready to view: https://github.com/awslabs/aws-sdk-kotlin/compare/__generated-main...__generated-feat-cred-providers
Originally posted by @github-actions[bot] in https://github.com/awslabs/aws-sdk-kotlin/issues/469#issuecomment-995231360

Invalid bot created issue.


Added tests which show how show_default=False has no effect

When I was writing my changes for the Prompt display of Choices, PR #496, I ended up discovering that passing show_default=False on an option has no effect. I've included two tests for this behaviour where the second one fails with the code currently on mitshuhiko/master.

I don't think this is a bug. show_default's documentation for options:

controls if the default value should be shown on the help page.

You're talking about the prompt. If you want to customize stuff like that, I'd rather suggest prompting manually.
I'm open to discussion about changing the behavior, but please open that discussion in a new issue. Also please understand that we can only change this in a major version.

Yup, seems like I misunderstood the function of the flag.


Added Organization to OAuth2.

Closes: https://github.com/Kong/insomnia/discussions/7209
This is an optional parameter on OAuth2 endpoints for 'Business Users' in OAuth2 applications.

This required affiliation with an organization, therefore requires this option to be specified on the request.

 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.

Thanks for your quick response; a custom values table would be great for the OAuth2 flow.

I saw in postman they have three phases with custom query params, would some like that satisfy your use case? Or am I misunderstanding something?

Absolutely, we're currently using the Auth Requests section to provide this context to our OAuth2 flow. Adding a table like this would be very powerful!
Thanks again for your response.

@jackkav What would be the next step here?

@subnetmarco we're tracking it in INS-3876 but it needs to be assigned.

Thanks for the PR.
To fully support this along with other parameters for OAuth2 we need to add a generic parameter editor.
Closing this for now as we will address it in an upcoming PR and is already planned internally


feat(icons): add more social media icons

https://lumapps.atlassian.net/browse/DSW-168
General summary
Added icons TikTok, TencentQQ, TencentVideo and Baidu

Test OK


Errors at compilation !

Hi,
I am a newbie with Android Studio. I donwloaded the project and tried to launch it.
I have fot the following errors:

Conflict with dependency 'com.android.support.test.espresso:espresso-idling-resource'. Resolved versions for app (2.0) and test app (2.2.1) differ. See http://g.co/androidstudio/app-test-app-conflict for details.
:android:prepareDebugAndroidTestDependencies FAILED
:android:prepareDebugAndroidTestDependencies (Thread[Daemon worker Thread 7,5,main]) completed. Took 0.008 secs.
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':android:prepareDebugAndroidTestDependencies'.

Dependency Error. See console for details.

Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

Anybody can help ?
Thanks !

I have same same problem about that, how to solve?

i have same problem about that, how to solve?

Solution: in build.gradle, change "androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'" to "androidTestCompile 'com.android.support.test.espresso:espresso-core:2.0'" Hope this helps !

Shouldn't be present in 2016 code drop. Please re-open if it is.


Set up npm workspaces

As a core developer, I want a simple way to simplify our build process to make it run more smoothly for easier development.
Please make sure to document the changes that will happen and what everyone needs to change in their processes.
Refer to:

https://earthly.dev/blog/setup-typescript-monorepo/
https://docs.npmjs.com/cli/v7/using-npm/workspaces

@tjcouch-sil is this done?

I think so! I didn't put much detail in here, but it looks at least on the surface as if we have done this. We implemented npm workspaces a long time ago. Thanks for noting!


What features are planned for future releases?

The SAP maintainer @tkowark mentioned planned feature for future releases. It'd be great to know which features are being planned and implemented. Is there information about this somewhere? Is it in the scoping docs, if so where? If not, please tell us what you're working on so that the community can give feedback.

Thanks for the pointer @ironjan . We're looking into both issues. But please note that main priorities right now are bug fixes and implementing planned features for the next releases. If we can reduce size along that path, we'll, of course, do that, but it is currently not a top priority.
Originally posted by @tkowark in https://github.com/corona-warn-app/cwa-app-android/issues/527#issuecomment-645258420

Thanks for bringing that up, @corneliusroemer. Unfortunately, there is no complete public backlog and to our knowledge such a public overview is currently neither planned nor possible due to several constraints. As you know we are working in a highly dynamic setup with a lot of different parties. Decisions are made pretty fast and could also change pretty fast. So thank you for your understanding that we can only communicate a few of these planned extensions where we more or less know that they are coming. But as it's also not sure to say with which release, we need to stick to the procedure as we do it right now. We are evaluating whether this can change, but it's currently very unlikely. Therefore, we need to close that issue here.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

Maintainers, please stop singling me out in responses. I may report issues, but I'm not the only person concerned. I'm part of a large community.
I consider it essential that the community, which is advertised as a big part of this project, knows at least in part what features are being considered so that they can give feedback.
This issue should only be closed if you regularly publish a list of features you are working on. What's so difficult about that? Surely you track features internally, your PMs must have access to something. You could just copy/paste that here.

Minimal Roadmap hier: https://www.rki.de/DE/Content/InfAZ/N/Neuartiges_Coronavirus/WarnApp/Warn_App.html unter der Frage „Wie die Corona-Warn-App weiterentwickelt wird“ wird über Erfassung des Symptombeginns und freiwillige statistische Meldung für wissenschaftliche Begleitung ans RKI gesprochen.

@cfritzsche thanks this is a good start! Based on this, I have a more general question re community involvement #301


SPgo stoped work, it don't find any commands.

Vscode just updated to Version: 1.45.1, and spgo stoped work, it don't find any commands.
Command 'SPGo: Configure workspace' resulted in an error (command 'spgo.configureWorkspace' not found)
Command 'SPGo: Reload Configuration' resulted in an error (command 'spgo.reloadConfiguration' not found)
Command 'SPGo: Retrieve folder' resulted in an error (command 'spgo.retrieveFolder' not found)
Command 'SPGo: Check out file' resulted in an error (command 'spgo.checkOutFile' not found)

Vscode just updated to Version: 1.45.1, and spgo stoped work, it don't find any commands.
Command 'SPGo: Configure workspace' resulted in an error (command 'spgo.configureWorkspace' not found)
Command 'SPGo: Reload Configuration' resulted in an error (command 'spgo.reloadConfiguration' not found)
Command 'SPGo: Retrieve folder' resulted in an error (command 'spgo.retrieveFolder' not found)
Command 'SPGo: Check out file' resulted in an error (command 'spgo.checkOutFile' not found)

I installed  previous version of spgo (1.6.2), end it worked again.

Hello @cryongen -
Can you respond with you spgo.json file? I am testing SPGo 1.6.3 against VSCode 1.45.1 and I am not able to replicate your issue.
Also, are there any other logs in either the Extension or SPGo output windows?

Closing as old. @cryongen if you are still seeing this issue, please reopen this issue.


Dev

Codecov Report

Merging #821 (2411b6d) into master (30519db) will increase coverage by 0.07%.
The diff coverage is 19.78%.

:exclamation: Current head 2411b6d differs from pull request most recent head bdc30d5. Consider uploading reports for the commit bdc30d5 to get more accurate results

@@             Coverage Diff              @@
##             master     #821      +/-   ##
============================================
+ Coverage     36.90%   36.97%   +0.07%
- Complexity    19473    19525      +52
============================================
  Files           910      912       +2
  Lines         66612    66661      +49
============================================
+ Hits          24583    24648      +65
+ Misses        42029    42013      -16

Impacted Files
Coverage Δ

src/MicroweberPackages/App/Exceptions/Handler.php
62.50% <ø> (ø)

...ckages/App/Http/Controllers/FrontendController.php
42.80% <ø> (ø)

src/MicroweberPackages/App/functions/other.php
16.78% <ø> (ø)

src/MicroweberPackages/App/functions/plupload.php
0.00% <0.00%> (ø)

...oweberPackages/App/tests/TemplateInstallerTest.php
0.00% <0.00%> (ø)

...rPackages/Blog/FrontendFilter/Traits/TagsTrait.php
27.65% <0.00%> (-3.30%)
:arrow_down:

src/MicroweberPackages/Import/Import.php
0.00% <0.00%> (ø)

src/MicroweberPackages/Media/MediaManager.php
24.31% <0.00%> (-0.07%)
:arrow_down:

src/MicroweberPackages/Media/helpers/media.php
8.82% <0.00%> (-6.97%)
:arrow_down:

...odule/Http/Controllers/Api/ModuleApiController.php
0.00% <0.00%> (ø)

... and 24 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 30519db...bdc30d5. Read the comment docs.


kube-aws caculator does not recognize t2.xlarge type

Error: failed to estimate cost for node pool #0 ValidationError: t2.xlarge is an invalid InstanceType value. Valid values are [c1.medium, c1.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge, c3.large, c3.xlarge, c4.2xlarge, c4.4xlarge, c4.8xlarge, c4.large, c4.xlarge, cc1.4xlarge, cc2.8xlarge, cg1.4xlarge, cr1.8xlarge, d2.2xlarge, d2.4xlarge, d2.8xlarge, d2.xlarge, g2.2xlarge, g2.8xlarge, hi1.4xlarge, hs1.8xlarge, i2.2xlarge, i2.4xlarge, i2.8xlarge, i2.xlarge, m1.large, m1.medium, m1.small, m1.xlarge, m2.2xlarge, m2.4xlarge, m2.xlarge, m3.2xlarge, m3.large, m3.medium, m3.xlarge, m4.10xlarge, m4.2xlarge, m4.4xlarge, m4.large, m4.xlarge, r3.2xlarge, r3.4xlarge, r3.8xlarge, r3.large, r3.xlarge, t1.micro, t2.large, t2.medium, t2.micro, t2.small]

New instance type is not recognized

Thanks for the report @andromedarabbit!
@gianrubio Any chance you could look into this? Perhaps we'd need to upgrade our aws-sdk-go to catch up with latest instance types or is it just a cloudformation restriction?

Yes @mumoshu, I'll do that during this weekend

@mumoshu upgrading the aws-sdk-go fix this error

I appreciate that.