Create Tekton Hub Logo

Hello from Hub, can we have a logo for tektoncd/hub
Tekton hub is a web based platform for developers to discover, share and contribute tasks and pipelines for Tekton
Can we have a logo for Hub
Hub Preview : https://hub-preview.tekton.dev/

One "idea" I have would be a can in front of a library or on top of a bunch of books or papers (:thinking:)

One "idea" I have would be a can in front of a library or on top of a bunch of books or papers (🤔)

This should say "cat" right?

I've added this to agenda for TOC meeting tomorrow, under 'pending project requests'
https://docs.google.com/document/d/1uBHar55fTInWF9Li4t0lyG3tTC8BRLU0FfBfsgk_Jrs/edit?ts=5c9580be#
We just need to know what design ideas to move forward with and any deadlines to be aware off so let's discuss tomorrow then get the ball rolling on this.

Ticket submitted to LF creative services to get process started
-G

(Internal reference: https://jira.linuxfoundation.org/browse/LP-6893)

tekton_hub_logoconcepts_V1.pdf
Hi team - please find attached a draft from our creative services team, and let me know your thoughts.
-G

@PuneetPunamiya @dlorenc do either of you have feedback on this? We'd like to get feedback over to the creative services team by Monday, 7 December. Thank you!

Sounds good to me! although it describes more a catalog or a library than a hub, I think it look good to me!

I agree with @chmouel that the icon might be more suited for the catalog concept, as opposed to a hub which is a central place to pull content from multiple catalogs.
Nitpicking here but regardless of the icon used for the hub concept, it might be worth to consider moving it to the left or right side of the cat to make sure the icon doesn't become vertically too long which is usually problematic on slides.

Thanks team! I've shared this feedback with our creative services team and will keep you posted.

@chmouel @siamaksade @dlorenc @PuneetPunamiya - do we have consensus on whether to keep the logo as designed or to move the cat to one side?
Thanks!
Gale

@galemccommons my vote to move it to one side

@dlorenc - do you have any final feedback on the logo before we submit these change requests to creative services? thank you!

how about a drooling cat, with cans of cat food around (or in hands). :nerd_face:
or a cat with boots, batman's utility belt, chewbacca's cross belt. and a magic wand

@dlorenc - do you have any final feedback on the logo before we submit these change requests to creative services? thank you!

No opinions from me!

@siamaksade @dlorenc please see revised logo attached. thank you!
tekton_hub_logo_v2.pdf

@siamaksade @dlorenc please see revised logo attached. thank you!
tekton_hub_logo_v2.pdf

Thanks everyone! I will let the creative team know this logo is accepted, and close out this issue.
@jsalinas29 the Tekton Hub logo is finalized.
Thanks all!

Thanks everyone! I will let the creative team know this logo is accepted, and close out this issue.
@jsalinas29 the Tekton Hub logo is finalized.
Thanks all!

Same question as https://github.com/cdfoundation/foundation/issues/198#issuecomment-774217616, can we get dashboard and hub image assets on https://github.com/cdfoundation/artwork/ 🙏🏼
/cc @danlopez00

@vdemeester the new logos are here https://github.com/cdfoundation/artwork/tree/main/tekton/additional-artwork/tekton-hub

@galemccommons  Thank you for adding Hub logo :hugs:

@PuneetPunamiya you're welcome!


Nesting image layers in groups for navigation

🚀 Feature
Following discussion here. It could be beneficial to group image planes from the same image. For instance, group multi-channel images together and allow a collapsible view of the channels. Right now, the system assigns a numerical index to the name of a multi-channel image so that My MC image becomes My MC image(1), My MC image(2), etc. in the side bar. It would also be beneficial here to have naming in the arguments of a nested layers, so that one could have like below where both the modality and the channels can be optionally named.
Modality 1
   - DAPI
   - Cool antibody 1
   - Cool antibody 2

Modality 2
   - DAPI
   - Cool antibody 3
   - Cool antibody 4

Motivation
Improve navigation in large datasets with many image planes. One can imagine a scenario where there is a multi-channel image composed of 10s or 100s of images, perhaps different processing of the original plane. Loading them all as single entries in the sidebar without individual naming could be very cumbersome.
Alternatives
Not sure.
Additional context
Here is an image of what that may look like, out of context. Of course, maybe hierarchy can be limited to only so many depths.

I like this idea!
If layers are nested, should there be some layer properties that are synced between the layers? For example, it seems like it should be possible to show/hide all of the layers in the group with a single click/command. I could also see it being useful to set opacity for all layers in a group together as well. Or maybe it would be better if the LayerGroup (or whatever we call it) can set the visibility/opacity for all child layers, but the child layers cannot set the layer properties of their "siblings". What do you all think?
In terms of API, I think it could make sense to add a group kwarg to the Viewer.add_* methods. If a group name is provided, the layer is added to the group if it exists and if the group does not exist, the group gets created and the layer gets added to it. Thoughts?

I think grouped layers will be very useful. I think it's also important to be able to support groups of groups as well (so people can have more complicated hierarchies if that's what they need as well).

I really like this idea - here is another example where I am running into this, using some multiview tracking data from @lambdaloop and https://github.com/lambdaloop/anipose where there are 3 cameras, each one contributing an image layer, a points layer, and a vectors layer. It would be nice to be able to group those three layers all together for each camera. I think this matches what is being requested here nicely.
The main tricky thing I can see is the design -, making it easy to navigate, intuitive to understand, and look nice, though theres is definitely lots of prior art here in other tools.
One additional thing I see is that we can then use these "Groups" for features like our grid view and multicanvas mode (see #760 say) where say I want to easily be able to assign an entire group to a different canvas. We might want to have some idea of how that will be done before implementing anything here.

Hi,
I work on correlated microscopy and have so far been using a tool from Zeiss called ZEN Connect to overlay images from different microscopes. I have been desperate for an open-source tool to do this job and napari looks super promising.
This feature would be fantastic for this kind of data as one quickly builds a up a hierarchy of images. This is a typical example:
Light Microscope
|
|----5x
|    |----Brightfield
|    |----GFP
|
|----10x
|    |----Brightfield
|
|----100x
     |----Feature 1
     |	  |----GFP [Z-stack]
     |	  |----RFP [Z-stack]
     |	  |----Reflection
     |
     |----Feature 2
          |----GFP [Z-stack]
          |----RFP [Z-stack]
          |----Reflection

Scanning Electron Microscope
|----100x
|    |----SE detector
|
|----500x
|    |----SE detector
|
|----1000x
     |----Feature 1
     |    |----SE detector
     |    |----In-lens detector
     |
     |----Feature 2
          |----SE detectore
          |----In-lens detector

Transmission Electron Microscope
|----135x
|----2250x
|----81000x
     |----Feature 1
     |----Feature 2

I think it would be great if any node of this tree could have settings that trickle down to all children, such as opacity. It would be awesome if any node could have an associated transformation matrix. Then every data plane could be transformed into the world coordinate system ( #763 ) by chaining the transforms as one climbs the tree. Since many elements of the transformation are shared between children (rotation between microscopes, scale between magnification, translation between features of interest) this would be a very efficient way of aligning a lot of images.

That's great that you're excited about napari @jojoelfe. Those suggestions for the layer groups and chaining transforms / passing down properties sound like really good ones. I think we might be able to do something like make a new object - a LayerGroup that subclasses the base Layer so it has all the properties that are common for all the Layers and a list of the layers / layergroups it contains and methods that allow it to do the propagation.
Probably worth waiting till  #885 goes in, but then is something we should definitely work on

Summary of meeting discussion
I've summarized our discussion from the meeting today about layergroups.
There are two halves to the problem of how we handle layergroup properties:

Getting attributes
Setting attributes

1. Getting attributes

This is a little philosophically tricky, because we need to work out what a LayerGroup property should be.
For example .opacity (float), .visible (boolean), and .data (array) are all layer properties. What should
It was initially suggested that maybe we disallow getting attributes from layergroups, but this breaks the composite design pattern & would likely cause other issues down the track. So we won't do that.
@royerloic suggests we treat layergroup properties as another node on a tree of transforms. Any time you want to retrieve a property, you need to run through all the parents to that node.
There are two things (sometimes at odds) that we need to support here:

Allowing properties to have relative scaling. Example: a multichannel image where each channel looks best with a different opacity, but we also want to use the opacity slider for the whole layergroup to change all the opacities at once (without losing the relative proportions between them).
Allowing properties to set absolute values, no relative scaling. Example: we have many images but want to make sure they are all using the same contrast/brightness display settings.

2. Setting attributes

The goal is for LayerGroups to propagate their attributes/properties to children without a lot of code duplication
@kne42 suggests we use subclass init instead of metaclasses to achieve this

Next steps:

Try experimenting with subclass init
Try experimenting with Loic's tree of transforms idea

@royerloic, @kne42, @jni, @tlambert03, please add anything you think I've forgotten here.

Notes from the meeting:
Attributes on layergroup nodes should not propagate downwards, all nodes & leaves should get/set attributes as normal. But, there needs to be a hidden "effective attribute" method that is calculated purely for display/rendering.

Ok, here is a thought experiment I need people to weigh in on.
This is the most succinct way I can describe the larger problem, by using an example about a specific attribute. Last time I brought this up in the group meeting we shelved that discussion, but it really does need an answer.
What should the .data property of a layergroup be?

Should it be None?
Should it be a list of all child .data results? A generator?
I can't really stack all the child .data results along a new array axis, because
Also
Should the .data attribute just not exist at all for layergroups?

None of these possible answers seem any good. Juan wants a composite design pattern, where a layergroup can be handled in an identical manner as any single layer.
The worry is that lots of things will break if unexpected things are returned from properties (or if an expected property doesn't exist). Right now, we don't have a clear answer to how much stuff breaks either.

To summarize the different aspects that need covering, layergroups have:

Properties/attributes related to the positioning of the layer(group) eg: scale, translate, transform chains, etc., or related to the vispy canvas display. Eg: visible, opacity, plus properties specific to certain types of layers.

Our current approach is that it makes sense for these properties to exist independently on the layergroup. At runtime these properties can be calculated, which allows parent layergroups to modify and return some "effective" value that is actually used by Qt/Vispy.

Properties/attributes that may not necessarily make sense. Eg: data(which is

We don't have a good answer for this yet.

Methods that don't return anything. Eg: refresh(), etc.

This is easy: we should probably just iterate through the whole layergroup tree and

Methods that do return something. Eg: get_value(), etc.

This is the same problem as in (2), we have no good answer for this yet.

interesting / helpful points @GenevieveBuckley!

None of these possible answers seem any good. Juan wants a composite design pattern, where a layergroup can be handled in an identical manner as any single layer.

I was thinking we don't need the composite to have every characteristic of single layers, just the ones that make sense and that we need for the layerlist tree.  I do think it's going to a specific decision for each property... I agree that .data can't be combined really, (I like the generator idea the most I think).
I think my main question would be: If you just punt on the layer group data attribute issue, at what line exactly in the napari codebase does it become a problem, and why?  I think the answer  to that might help to inform what (if anything) we need from a composite data attribute.
Our current LayerList has no methods that get a value for every layer in the list.  So we're moving in to new territory here.  But that also means that there really isn't anywhere in the codebase yet that demands it.  So if there are properties where it's easy to figure out (scalars or bools like opacity, visibility) great... but I think each method is going to take some thought and there may not be universally applicable strategies.  For instance, maybe get_extent gives you a single outer bounding box of of all the other ones, whereas other methods might just iterate over the children?

Thanks for your thoughts @tlambert03!

I think my main question would be: If you just punt on the layer group data attribute issue, at what line exactly in the napari codebase does it become a problem, and why? I think the answer to that might help to inform what (if anything) we need from a composite data attribute.

The .data property setter is marked as an abstract method on the base layer, so it requires some kind of implementation (even if that implementation is just "raise NotImplementedError"). The other base layer abstract methods are: _get_extent(), _get_ndim(), _get_state(), _set_view_slice(), _update_thumbnail().
It's very difficult to tell at which line in the napari codebase these things become problems, because the problems tend to crop up in the emitter event interactions between Qt and Vispy with the python model. The full scope of these interactions isn't clear to me, and I can't continue trying "poke it and see what breaks" without building in more stuff involving Qt/Vispy. That approach was discouraged at our last meeting (it was preferred that we get clear on the python model first), but it's starting to feel like a chicken & egg problem.

For instance, maybe get_extent gives you a single outer bounding box of of all the other ones, whereas other methods might just iterate over the children?

This approach to _get_extent() becomes tricky when mixing children with different dimensions (2D, 3D, 2D+time might have a _get_extent() we can't distinguish from the spatial 3D case). I can hack something that kinda works here, but it feels like a code smell to me.

... but I think each method is going to take some thought and there may not be universally applicable strategies.

Yeah, at this point I'm worried that most things will need some kind of special handling. (But maybe that's ok if we don't plan on adding any other layer class types?)

What should the .data property of a layergroup be?

Should it be None?
Should it be a list of all child .data results? A generator?
I can't really stack all the child .data results along a new array axis, because they all have very different shapes. Also, this is much more work to refresh/update on data changes for any of the layers (this criticism also applies to the list/generator idea above, too)
Should the .data attribute just not exist at all for layergroups?

Thanks for raising this @GenevieveBuckley. Maybe @royerloic can weigh in on this before the meeting today. I'll give it some thought too.

I can't see a reason to have a .data field for layer groups. Perhaps that is the definition of a layergroup, a layer that does not have data but that groups layers that do, recursively.  It is fine to have the .data property in the layergroup base class return None. The question is what client code would need that and for what? My gut feeling is there is no client code that would need that field.
Perhaps the real solution is to have a base class above the level of layers that does not have some fileds (such as .data) and from which the layer base class derives. So: 'a layer is a layer group that has data'  (and a few other things that groups don't need). This feels like the correct OO solution to this problem.
About @GenevieveBuckley concerns on the 'chicken & egg problem'. I understand your concerns here, but I believe we can eventually solve the UI issues but only after we have a clear conceptualisation for the model. For example, for _get_extent() it is perfectly fine to return the bounding box with the 'bounding number of dimensions'. I am pretty confident that we will find a mathematically sound and elegant solution for all of these questions as we have done with opacity etc... We can go through each method together and discuss what should happen. I am not too worried. The model needs to make sense and be consistent, the connecting the wires with the UI will be easier...

Thank you for those helpful comments, @royerloic

The idea of groups sounds very interesting.  One additional thought regarding generic grouping would be to allow layers to belong to multiple groups.  For example, a layer could have multiple attributes, and visibility could be toggled by attribute.  In email client parlance, instead of a "folder" approach, it would be an "label" approach.
The label approach is more expressive and flexible -  but it would not be hierarchical, so it loses the benefits of propagating characteristics up or down a hierarchy.

Hi all, thankfully @sofroniewn pointed me to this issue & pull request in https://github.com/napari/napari/issues/2202. I'm not sure about the state of this, so I just would quickly like to share my thoughts here (also working on multiplexed imaging data), at the risk of stating the obvious/describing what's already implemented:

A tree structure for images (hierarchically) contained in one file would be amazing to have, thanks for working on this!
However, I would go a step further and propose to - in nomenclature - strictly separate between:

Files, i.e. collections of images sharing a coordinate system
Images, i.e. TZCYX0 image stacks, possibly with xarray-style axis labels (e.g. channel names)
Channels, i.e. user-friendly names (not indices!) to the C coordinate, possibly shared among images
Layers, i.e. shown 2D planes/3D volumes corresponding to a TZC combination

IMHO, following up on @kevinyamauchi's comment and unlike in the original proposal, the tree structure should only cover file and image data items and channels shared among these items should be listed separately (not a tree structure!). This would allow the user to apply layer properties such as color, contrast, etc to channels (i.e., layers grouped by channel label). One could retain the Layers panel to still be able to apply properties to individual layers.

Having such a tree structure as well as a separation between files/images/channels/layers is essential for efficiently working with highly multiplexed imaging data with 50+ channels, with multiple images sharing the same (physical/machine) coordinate system. Adding full support for named channels would make napari immensely useful to the highly multiplexed imaging community! I described a use case for this in https://github.com/napari/napari/issues/2202 (Imaging Mass Cytometry).
I understand that the core of napari should be kept as generic as possible. To support this, one could e.g. employ a tree model in which file reader plugins can either populate a default node model, or provide their own custom one for specialized use cases.
In the long run, I think that having a separate channels list is crucial - is there a feature request already for this/should I open a new one separate from this discussion? If you feel like this is an issue, one could even think of making this as generic as possible, by replacing the concept of "channels" with a more general concept of "tree items grouped by one of their properties" (e.g. channel label), for which napari could then show list-like interfaces (e.g. in a tabs widget, one tab per group, or a combo box to select the grouping key).
Again, I'm not sure about the current state of this issue (sorry for being late to the conversation - I just started using/developing for napari and I love it!), but I think this proposal might help maturing napari to a fully fledged multi-channel analysis platform.

Thanks for chiming in @jwindhager! Love the data and plugin you showed in #2202. Very cool stuff, and this kind of data that challenges how we think about layers is actually really important to making napari as generic as possible!
Until now, we've definitely conflated channels and layers, and I see the distinction now. :joy: One thing I would say though, is that channel is just one of many attributes that you might want to group layers by. For example, you might want to group all segmentation layers together and process them together, or group all mask layers. So I guess what I'm trying to say is that layergroups should not be strictly hierarchical but rather be flexible in some other ways — so that you could use it for channels but someone else could use it for a different purpose — say, treatment.
The UI/UX considerations are interesting to say the least though. :sweat_smile:

Thank you very much, @jni!

One thing I would say though, is that channel is just one of many attributes that you might want to group layers by. For example, you might want to group all segmentation layers together and process them together, or group all mask layers.

I fully support this! That's precisely what I meant with "tree items grouped by one of their properties", where I referred to images as "tree items" - apologies for the confusion!

So I guess what I'm trying to say is that layergroups should not be strictly hierarchical but rather be flexible in some other ways — so that you could use it for channels but someone else could use it for a different purpose — say, treatment.

I would like to emphasize that I see the grouping and the tree structure inherent to some image formats as two orthogonal things: The tree structure is required for organizing images within a (hierarchical) file such as in the case of #2202, whereas the (flat) grouping of layers (that correspond to images in that tree structure) is required to jointly apply settings to the same channel, condition, etc

I would like to emphasize that I see the grouping and the tree structure inherent to some image formats as two orthogonal things: The tree structure is required for organizing images contained in a (hierarchical) file such as in the case of #2202, whereas the (flat) grouping of layers (that correspond to images in that tree structure, e.g. one per image and channel) is required to jointly apply settings to the same channel, condition, etc

While agreed they can be treated orthogonally, I think we were imaging a tree pattern where modifying a node attribute can modify all the properties of its children. What i realize now though is that you actually might want to "group" nodes that aren't heirachically related in the tree - i.e. you have three plates, each plate has red/ blue channel children and then you want to set the clims on all the blue channels in all three plates, but not the red channels. I don't think this would be easily supported with the API we were currently imagining, right @tlambert03? Or can you see a way?

nope, #970 and #1502 are literal groupings of layers, and not so much "binding" of certain layer attributes.  However, it's not so hard to imagine, a relatively simple API for binding the attributes of two layers:
from itertools import combinations

def link_layers(layers: List[Layer], attributes List[str]):
    for combo in combinations(layers, 2):
        for attribute in attributes:
            # e.g. layer_a.events.attribute.connect(_update_layer_b_attribute)
            connect_events_without_recursion(*combo)

What i realize now though is that you actually might want to "group" nodes that aren't heirachically related in the tree - i.e. you have three plates, each plate has red/ blue channel children and then you want to set the clims on all the blue channels in all three plates, but not the red channels.

Precisely what I wanted to say! Sorry, it's really hard to explain these concepts. Maybe, with this realization in mind, https://github.com/napari/napari/issues/970#issuecomment-772433644 makes more sense now.

nope, #970 and #1502 are literal groupings of layers, and not so much "binding" of certain layer attributes. However, it's not so hard to imagine, a relatively simple API for binding the attributes of two multiple layers:

In this case, should I open a new issue for discussing this separately (as proposed above)? I think having both a tree-structure for representing more complex file formats and an option to group layers would be key to multiplexed imaging use cases (meanwhile, for IMC data, the plugin mentioned in #2202 fulfills this requirement). Also happy to discuss this offline to avoid misunderstandings.

As I realized that my request is somewhat different/more general than this issue, I created a new feature request for this in #2229. Apologies for hijacking this conversion with partially unrelated input!

Heads up that I'm planning to look into layer groups work from a user experience and design perspective! I'm currently planning to add updates to this issue, and I'll let you know here if that changes.


Templates

Issues affected/resolved
(See https://github.com/blog/1506-closing-issues-via-pull-requests)
Resolves #XXXX
Description:
Current templates are annoying, they are shouty especially the issues one, and they don't have a file extension.
The PR template should have the description at the top of the file since that's the most important info. And the note / github blog url is only needed at creation time, so we wrap it in an html comment so its not rendered.

This change is

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

Comments from Reviewable


SRE-144 Containerize Dewey

First go at running dewey in a containerized form. We still need to finish setting this up as a salt state, but I wanted to get some feedback before doing that work. There is a PR in dewey as well for generating the container.

If we move towards containerizing apps, I wonder if we shouldn't simplify/drop these formulas and push the docker configuration into the app repo? With docker, all of these salt formulas begin to seem a little overly complicated. Running docker compose up (is that the right command?) in the dewey repo and getting the same thing we have in production on a developers machine would be great.

Hey @egh while I agree with you in the grand scheme of things we still gain a lot out of salt using it as a sort of container orchestrator so we can handle things like secrets and varying configurations (while having them identical for each env would be ideal it is not where we are) from env to env, as well as managing the containers themselves to handle upgrading/downgrading/monitoring state. That isn't to say that there aren't methods of handling these things other than salt, but it is currently our most widely deployed tool for it, and make sense to keep using it.
In the longer term we would prefer to move to a proper orchestrator like k8s which would then manage all of those variables for us and we could more easily deploy an app the same way from dev up through to prod.
If you'd like to chat more about it (always enjoy dreaming of greener pastures) we should sit down and discuss more!

I hear you, I see that salt should be our configuration system at least in the near term. I guess I worry about code duplication if salt is managing docker-compose.yml files, though. I feel like those could be closer to the core dewey repository, so that devs could bring up a containerized version of dewey in a local environment without needing to go to the formula to find it. Maybe this isn't worth the effort, though. I'm not sure what our docker strategy looks like.

@heschlie My concern here is setting a pattern that I think is going to be awkward for devs and for testing. Setting aside dewey, I'm concerned that developers may not even know there is a docker compose file available. And if they do, it does add an additional step of downloading it. Or, if we want to set up integration testing, we might want to use docker compose to bring up an instance, and it would be awkward to have to get it from the salt formula. But maybe we can set up a curl command to download the docker-compose.yml

Conversely, if the docker-compose file resides in the app repo instead of the formula then the burden is on the salt state to pull the compose file.  I would prefer this, as then the burden is on an automated process rather than a manual process.
I'm also open to keeping files in both the repo and the formula. It's possible that the setup will be different enough between local docker and docker-in-vm that we'd feel more pain from trying to maintain a file that handles both environments.


drivers: pinctrl: sam: Add wake-up source support

This add the pin wake-up source configuration capabilities to the SAM pinctrl driver. It add the SUPC functions at SoC and update gpio and pinctrl drivers to allow user configure the wake-up core power supply functionality.
depends on #63961

Nice! Looking good already :)

@bjarki-trackunit ,
Do you know if there is a sample that we can validate poweroff and then wake-up using gpio?

@nandojve I'm doing this currently
#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/sys/poweroff.h>
#include <zephyr/drivers/rtc.h>
#include <zephyr/dt-bindings/power/atmel_sam_supc.h>
#include <soc.h>

static const struct device *rtc = DEVICE_DT_GET(DT_ALIAS(rtc));

int main(void)
{
	printk("Wakeup\r\n");

        /* VERY IMPORTANT SLEEP
         * debugging becomes unavailable while sleeping,
         * so it can't be erased, keep this timeout to give you
         * 10 seconds to connect the debugger before it sleeps :)
         */
	k_msleep(10000);

	/* Set RTC alarm */
	struct rtc_time alarm_time = {
		.tm_sec = 0,
	};

	ret = rtc_alarm_set_time(rtc, 0, (RTC_ALARM_TIME_MASK_SECOND), &alarm_time);
	soc_supc_enable_wakeup_source(SUPC_WAKEUP_SOURCE_RTC);
	printk("Powerdown\r\n");
	sys_poweroff();
	return 0;
}

selecting
CONFIG_RTC=y
CONFIG_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_RTC_ALARM=y
CONFIG_POWEROFF=y

You just need to enable the wakeup source and flip a pin to see if it wakes up again :)

Hi @bjarki-trackunit ,
Let's add the samples to make it easy to people test these options.
I create a place to add mine and you can add your there too.

Hi @bjarki-trackunit ,
Let's add the samples to make it easy to people test these options. I create a place to add mine and you can add your there too.

Neat :) I will base my sample on the RTC driver once it and the supc component is merged :)

Hi @gmarull ,

I voiced quite a few times now: NO to vendor-specific wake-up schemes, less to adding yet another wake-up from GPIO sample. There's some common ground that can be found as many if not all SoCs support waking up from GPIOs.

I understand your concern but as you already stated in Originally posted by @gmarull in https://github.com/zephyrproject-rtos/zephyr/issues/63961#issuecomment-1772489247 there is no standard way to do it. This PR DO NOT introduce any new API. This is a simple mechanism that can leave in parallel with the GPIO API and I think it make sense for PM use cases.
IMHO, I don't see why this can not be used since it uses the standard pinctrl mechanism which is somehow always an extension of GPIO itself and the GPIO mechanism can be implemented after this. So, on my view this is just a convenient and standard way to extended the Wake-Up use case from GPIO itself.

Hi @gmarull ,

If this PR does not add new APIs, then please, do not add new platform-specific samples. There should be a single sample to demonstrate how to wake-up from GPIO.

I don't understand exactly what you want. I was wondering if you could point out what is the current in tree sample that you would like this PR be in.

Hi @gmarull ,
I was wondering if it is possible establish a direction that the wake-up by GPIO should be used by the compatible = "gpio-keys"; as the missing standard you mentioned. I would be happy to rework the example here to be generic in another PR.
As should be already clear, I've been using what is already well defined by Linux. The current proposal only update the pinctrl API which should be consumed, I hope, in near future by the gpio-keys driver.
As reference, the below is from the Linux master branch:
https://github.com/torvalds/linux/blob/750b95887e567848ac2c851dae47922cac6db946/arch/arm/boot/dts/microchip/at91-sama5d2_xplained.dts#L708-L720
In this case, since the gpio-keys is a well defined way to provide this functionality in Linux and, it can uses pinctrl, this tells me that this model could be a good candidate to establish a de facto standard for the wake-up use case. If it is the case, I would like know if the PR can be moved forward without the sample and gpio-keys at this moment. Once this is in in tree, I can start to work to add the pinctrl details for the gpio-keys driver. This will keep things simpler instead blow a PR with such many things.
I hope I made my intentions clear so we can move forward and be closer to a possible standard for the wake-up feature in Zephyr.

@nandojve Have you seen this gpio-keys.yaml?

Yes, but I don't have a functional version yet.

Hi @gmarull , @kartben ,
This PR is ready now and all concerns should be addressed in #64538.

This PR is ready now and all concerns should be addressed in #64538.

Actually after seeing #64538 I'm also unconvinced about this approach, let's sort it in that comment before maybe.

This PR is necessary to get encoded info from pincfg in regards of wake-up functionality for a specific pin. Without this, it is not possible to add wake-up pin functionality to Atmel SAM SoC's, unless a custom implementation be defined. The pincfg have an index necessary to set at SUPC block.
In the below image is signaled an extra function of this pin which needs to be encoded using pincfg. The SUPC index is defined by the number x in the right of WKUPx which does not have any relation with the pin or the port in question and can vary between families.

@nandojve will you return to this before the 3.6 merge window closes this week?


FFI plugins

Add support for flutter create --template=plugin_ffi and flutter run support for ffiPlugin: true in pubspec.yaml.
This addresses 2 issues:

Currently, the way to do FFI with Flutter is to use flutter create --template=plugin. However, this generates boilerplate for plugin registration and example code for method channels which go unused.
We've see dozens of issues with building, linking, and bundling native code. The FFI plugin template should be the sample that works for all platforms for users to reference or use as a starting point.

Design doc.
NDK versioning doc.
Some relevant issues:

https://github.com/flutter/flutter/issues/78819
https://github.com/flutter/flutter/issues/77790

Included in this PR:

Building shared C source code as part of the native build for platforms Android, iOS, Linux desktop, MacOS desktop, and Windows desktop.
Sample code doing a synchronous FFI call.
Sample code doing a long running synchronous FFI call on a helper isolate.
Use of package:ffigen to generate the bindings.

Not included in this PR:

Bundling closed source libraries. (MacOS, iOS, and Android require copying to the right place. Linux and Windows require referencing from CMake files.)
Building closed source libraries with the right compiler options (most notably rpath and include path).
Support for flutter test. This requires a bin/setup.dart to invoke a native build outside flutter run or flutter build.
Support for using the generated package as Dart standalone. This requires a bin/setup.dart to invoke a native build.
Linking against dart_api_dl.h to be able to invoke functions from dart_api.h.
Sample code doing an asynchronous callback through native ports form dart_api.h.
Compatibility between the plugin and plugin_ffi templates. The example apps (example/lib/main.dart) are different.

Test this PR locally without building Flutter by running the Flutter commands from source (replace platforms for your host OS).
$ dart <PATH_TO_FLUTTER_CHECKOUT>/packages/flutter_tools/bin/flutter_tools.dart create -t plugin_ffi --platforms=macos,ios,android my_ffi_plugin
$ cd my_ffi_plugin/example/
$ dart <PATH_TO_FLUTTER_CHECKOUT>/packages/flutter_tools/bin/flutter_tools.dart run -d macos

For context, previous PR (reverted):

https://github.com/flutter/flutter/pull/94101

If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

Will support for prebuilt libraries be added in the future? It's not only important for closed-source libraries but also if the compiler is too difficult to setup on the users machine (for example for Rust libraries)

Will support for prebuilt libraries be added in the future? It's not only important for closed-source libraries but also if the compiler is too difficult to setup on the users machine (for example for Rust libraries)

It is the intention to support that use case as well. At this point we're not entirely sure whether that warrants a new template, or whether a sample and documentation is enough. (Some pointers based on the source template: add the precompiled dl path to Windows Linux CMakeLists.txt in _bundled_libraries, copy the dl to MacOS iOS Frameworks folder, copy the dl to jniLibs.)
Also, it would require package authors to upload the binaries for all (18) target platforms (hardware * OS combination) to pub. We're exploring if there are any obstacles for doing that.

Building the binaries for all platforms is no problem but. More documentation would be very helpful. Especially how to:

put shared libraries in the correct place to be found at runtime
add multiple binaries for the same os (ios_arm64, ios_arm64_sim etc.)
make sure the binaries don't get stripped

Lots of small comments, but overall this is looking really good!

@stuartmorgan I've addressed all of them. PTAL.
@christopherfujino I've replied to your comment above. Please let me know if you have any further comments.

Thanks Stuart!

Thanks for all the work here :)

Let's make our users happy!
@christopherfujino waiting on your approval (or delegation) as flutter_tools owner.

I have actually just ran into the issue @leisim prophesied; I am trying to build a Flutter library wrapping around a Rust library. Seeing as I cannot expect users of the library to have rustup installed, I plan on distributing precompiled versions of the library for all the targets.
For macOS/iOS, my best attempt was to create an XCFramework from the compiled rust static libraries (quite a few .a files!). After lipo-ing a the simulator and macOS static libs together, I was able to create the full XCFramework. For future reference, perhaps if someone is making some Rust/Flutter library documentation, I have this process thrown together in a build script. This takes care of all Apple platforms in one framework, which is very handy. However, when I go to include this Framework in my plugin, I run into linker errors as seen in this SO post.
@dcharkes mentions:

(Some pointers based on the source template: add the precompiled dl path to Windows Linux CMakeLists.txt in _bundled_libraries, copy the dl to MacOS iOS Frameworks folder, copy the dl to jniLibs.)

I'm most interested in the macOS/iOS part here. Could you please provide a brief working example of how to go about this for macOS/iOS? I have tried for hours and cannot get the XCFramework & podspec file to work properly.

100 MB package version limit
@jonasfj We have our first user hit the 100 MB limit.
Precompiled static libraries on MacOS/iOS in a xcframework

I'm most interested in the macOS/iOS part here (for now). Could you please provide a brief working example of how to go about this for macOS/iOS? I have tried for hours and cannot get the XCFramework & podspec file to work properly.

I've got something slightly working for precompiled static libraries in an xcframework:
mylib_staticlib/macos/mylib_staticlib.podspec
#
# To learn more about a Podspec see http://guides.cocoapods.org/syntax/podspec.html.
# Run `pod lib lint mylib_staticlib.podspec` to validate before publishing.
#
Pod::Spec.new do |s|
  s.name             = 'mylib_staticlib'
  s.version          = '0.0.1'
  s.summary          = 'A new flutter plugin project.'
  s.description      = <<-DESC
A new flutter plugin project.
                       DESC
  s.homepage         = 'http://example.com'
  s.license          = { :file => '../LICENSE' }
  s.author           = { 'Your Company' =><EMAIL_ADDRESS>}
  s.source           = { :path => '.' }
  s.source_files     = 'Classes/**/*'
  s.dependency 'FlutterMacOS'

  s.platform = :osx, '10.11'
  s.pod_target_xcconfig = { 'DEFINES_MODULE' => 'YES' }
  s.vendored_libraries = 'Frameworks/libmylib_staticlib.a'
  s.pod_target_xcconfig = { "OTHER_LDFLAGS" => "-force_load $(PODS_TARGET_SRCROOT)/Frameworks/mylib_staticlib.xcframework/macos-arm64_x86_64/libmylib_staticlib.a" }
  s.swift_version = '5.0'
end

mylib_staticlib/macos/Classes/dummy_file.c
// A dummy file so that the mylib_staticlib.framework is created.

Path of the framework with static libraries: mylib_staticlib/ios/Frameworks/mylib_staticlib.xcframework/ios-arm64_x86_64-simulator/libmylib_staticlib.a
One issue with doing it like this is that the ios_arm64 is compiled either against the iossimulator or against ios, and I wasn't able to figure out how to make that both work.

Check out the Isar podspec and the build script for Rust.
It works really well even without -force_load.  Ideally allowing static compilation into the Flutter native lib.

Check out the Isar podspec and the build script for Rust.
It works really well even without -force_load and supports all cpu/simulator configurations.  Ideally allowing static compilation into the Flutter native lib.

As the end goal, we would like static compilation into the compiled Dart code, that means we can use the native linker to get rid off all native code not referenced. Tracked in:

https://github.com/dart-lang/sdk/issues/49418

@leisim Thanks for that! I didn't think of using a regular plugin package instead of an FFI plugin to actually integrate everything but it looks like it works smoothly. Also, thank you both for the speedy response!
Static Linking w/ Dart
This would be absolutely fantastic, as the generated static libraries I am dealing with are quite large (~100-200 mb per platform & architecture) and I am sure they have plenty of dead code not needed by my Dart library in them (caused by a large number of dependencies in the Rust library I am wrapping).
100 MB Limit
As I mentioned in the previous paragraph, the static libraries I am dealing with are exceedingly large, and the entire upload could easily be above 1 GB. If you do consider changing the pub limit, perhaps it would be worth considering having a separate upload for static/native libraries and then link to them in the main upload (or perhaps a different way to handle them altogether)? Maybe, if Dart does get static linking, the theoretical separate upload could just be for native libraries that are statically linked automatically by Flutter/Dart? That could be a really elegant solution.

@GregoryConrad 100-200MB sounds incredibly large. Did you check the steps to reduce Rust binary size? It's quite expensive to load such a fast binary at runtime.

In case anyone else stumbles into this, I got FFI working with my cross-platform XCFramework using ffiPlugin: true (thanks to @leisim's great example with Isar!). I can't believe I didn't realize this, but my XCFramework was getting tree-shaken. Here's how I fixed it (same exact code for macOS and iOS, but cannot be symbolically linked unfortunately):

my_package.podspec

Pod::Spec.new do |spec|
  spec.name          = 'my_package'
  spec.version       = '0.0.1'
  spec.license       = { :file => '../LICENSE' }
  spec.homepage      = ''
  spec.authors       = { 'Your Name' =><EMAIL_ADDRESS>}
  spec.summary       = 'Some summary'

  spec.source              = { :path => '.' }
  spec.source_files        = 'Classes/**/*'
  spec.public_header_files = 'Classes/**/*.h'
  spec.vendored_frameworks = 'Frameworks/MyPackage.xcframework'

  spec.ios.deployment_target = '11.0'
  spec.osx.deployment_target = '10.11'
end

Classes/binding.h

void enforce_binding();

Classes/EnforceBinding.swift

public func dummyMethodToEnforceBundling() {
    enforce_binding() // disable tree shaking
}

Frameworks/MyPackage.xcframework needs to have a void enforce_binding() {} function. I did this in Rust with:

/// Enforce the binding for this library (to prevent tree-shaking)
#[no_mangle]
pub extern "C" fn enforce_binding() {}

I'm not sure we should tweak the 100MB limit.
If you're things are really this big, then maybe:

You should download platform specific binary blobs in the build step (@dcharkes this certainly makes sense if binary blobs are 200mb per platform).
Work to make your package smaller,
Split the package into multiple packages, if this makes sense, so that users don't have to download all at once.


Model with 'ManyToManyField' and 'TaxedMoneyField' raise error

Steps to reproduce the problem

Clone saleor (branch master)
install requirements (pipenv install)
docker-compose build
docker-compose up
add two fields saleor/order/models.py Order
i.e.

sped_label = models.FileField(upload_to="sped_label", blank=True)
xaxa = models.CharField(max_length=255, default="", blank=True)

run manage.py
i.e. ./manage.py migrate

Traceback
Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/management/base.py", line 323, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/management/base.py", line 361, in execute
    self.check()
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/management/base.py", line 390, in check
    include_deployment_checks=include_deployment_checks,
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 65, in _run_checks
    issues.extend(super()._run_checks(**kwargs))
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/management/base.py", line 377, in _run_checks
    return checks.run_checks(**kwargs)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/checks/registry.py", line 72, in run_checks
    new_errors = check(app_configs=app_configs)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/checks/urls.py", line 40, in check_url_namespaces_unique
    all_namespaces = _load_all_namespaces(resolver)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/core/checks/urls.py", line 57, in _load_all_namespaces
    url_patterns = getattr(resolver, 'url_patterns', [])
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/utils/functional.py", line 80, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/urls/resolvers.py", line 579, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/utils/functional.py", line 80, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/django/urls/resolvers.py", line 572, in urlconf_module
    return import_module(self.urlconf_name)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/Users/kswiatek/workspace/saleor/saleor/saleor/urls.py", line 16, in <module>
    from .graphql.api import schema
  File "/Users/kswiatek/workspace/saleor/saleor/saleor/graphql/api.py", line 3, in <module>
    from .account.schema import AccountMutations, AccountQueries
  File "/Users/kswiatek/workspace/saleor/saleor/saleor/graphql/account/schema.py", line 6, in <module>
    from ..descriptions import DESCRIPTIONS
  File "/Users/kswiatek/workspace/saleor/saleor/saleor/graphql/descriptions.py", line 4, in <module>
    from .order.resolvers import ORDER_SEARCH_FIELDS
  File "/Users/kswiatek/workspace/saleor/saleor/saleor/graphql/order/resolvers.py", line 10, in <module>
    from .types import Order
  File "/Users/kswiatek/workspace/saleor/saleor/saleor/graphql/order/types.py", line 255, in <module>
    class Order(CountableDjangoObjectType):
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/graphene/utils/subclass_with_meta.py", line 52, in __init_subclass__
    super_class.__init_subclass_with_meta__(**options)
  File "/Users/kswiatek/workspace/saleor/saleor/saleor/graphql/core/connection.py", line 56, in __init_subclass_with_meta__
    super().__init_subclass_with_meta__(*args, connection=countable_conn, **kwargs)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/graphene_django/types.py", line 83, in __init_subclass_with_meta__
    construct_fields(model, registry, only_fields, exclude_fields), _as=Field
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/graphene_django/types.py", line 22, in construct_fields
    _model_fields = get_model_fields(model)
  File "/Users/kswiatek/.pyenv/versions/3.6.7/envs/saleor/lib/python3.6/site-packages/graphene_django/utils/utils.py", line 39, in get_model_fields
    list(model._meta.fields) + list(model._meta.local_many_to_many)
TypeError: '<' not supported between instances of 'ManyToManyField' and 'TaxedMoneyField'

Hi,
Could you provide more steps and information about what you did so we can understand better what's wrong. It looks like there is an issue with your Order GraphQL object but I couldn't say what is causing it and the line you are providing us seems unrelated.
Also, to make code readable you can use:

```
your code...
```

sorry about formatting.
About what I did

Cloned saleor
Install requirements
build docker image
run docker image
add 2 fields to Order model
run  /manage.py makemigrations

Issue fixed in https://github.com/mirumee/django-prices/pull/75


The playhead is not lined up with the frames in the Time Sequence Editor (Firefox on Windows and Linux)

There are no errors in the console.
Details

OS
Firefox version
Other Specs/Comments

Windows  10 (19041.1415)
97.0.1 (newest)
Old, low-spec laptop, no dedicated GPU or anything fancy like that

Manjaro Linux
97.0
Has a GPU: NVIDIA GeForce RTX 2060 SUPER

Picture about the issue
This is how the issue looks like on the Windows machine:

@fulopkovacs if you are able to re-test this, I have modified the way keyframes are offset from the left. It is possible it is related to this issue and may have made a difference.

:+1:  Nice, it works on Linux! Will check this out on Windows, once I got my hands on it...

Hi, I think we can close this issue. https://github.com/theatre-js/theatre/commit/ca5b2685bb340875ebf68092f6cb8e82cf9e674c fixes this and it's already included in versions 0.4.8-dev.3 and up.

Hi, I think https://github.com/theatre-js/theatre/commit/ca5b2685bb340875ebf68092f6cb8e82cf9e674c fixes this and it's already included in versions 0.4.8-dev.3 and up.

Yes, will close then. Thanks @Ichsam!


Compute overall accuracy using number of correct predictions

@abhinavnmagic After this is approved, before merging can you also use the fix here to do at least a full training with the model you're working on? I'd like to make sure we won't see anything unexpected.


Disable blank issues

Hide the  Don’t see your issue here? Open a blank issue. option when users create an issue in the repo.
See https://github.blog/changelog/2019-10-28-new-issue-template-configuration-options/

Codecov Report

Merging #10678 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #10678      +/-   ##
==========================================
- Coverage   60.64%   60.62%   -0.02%
==========================================
  Files         583      583
  Lines       31551    31551
  Branches     4487     4487
==========================================
- Hits        19133    19127       -6
- Misses      11446    11450       +4
- Partials      972      974       +2

Impacted Files
Coverage Δ

src/datascience-ui/react-common/arePathsSame.ts
75% <0%> (-12.5%)
:arrow_down:

src/client/common/utils/platform.ts
64.7% <0%> (-11.77%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0%> (-2.23%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0%> (-1.57%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0%> (-0.73%)
:arrow_down:

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 e725dd8...f3237cb. Read the comment docs.


chore(EMS-696): Update all controllers to have the same template/export pattern

This PR tidies up all controllers to have the same structure/pattern for template definitions and exports.
All controllers now:

Define a single TEMPLATE constant instead of defining it in multiple places for GET and POST.
Export on the function level instead of exporting everything at the end of the file.

@Zainzzkk I can't forsee a page/controller having multiple templates. Any page differences should be a different route/URL and therefore would have their own controller? To be accessible and semantic.


DSCS-2464 fixes a problem with the join used for restoring sessions (…

…without both s_id and id, state from different sessions was being used when restoring)
@scoen @ninhnguyen @weijunnla @jrixon @sjacob @adityaburra

💯

SonarQube analysis reported 1 issue

 AmberQueryBase.java#L17: Define a constant instead of duplicating this literal "select * \n" 4 times.

Build finished.


Update homepage layout

Changes proposed in this pull request
Update homepage structure ready for content design
Real content to follow...
Guidance to review
View the root_path and ensure nothing is broken

Code looks OK, are we sure we want to merge this with Lorem Ipsum text though?


Is it possible to increase feature_name_length?

 pub fn feature_name(&self) -> Result<Vec<String>> {
        let num_feature = self.inner_num_features()?;
        let feature_name_length = 32;

32 is relatively small... I have some features that have longer name..
I am not sure if the C API has max limit on length?

Yes, for sure. Just upgrade to the latest version of the crate


support Swift 3

Support Swift 3

Convert from swift 2 to swift 3 with Xcode converter
Add LSApplicationQueriesSchemes to info.plist
Merge the difference between the original project and the project which I created with Xcode 8.1

Thanks


Change a logic for controlling accessible member on OGNL

I've added tests for checking the behavior of parameter mapping and result mapping using various access scope(private, package private, protected and public).
As a result, parameter mapping and result mapping feature allows all scope members, but the OGNL expression can only access public member. (See #1258)
I will propose changing become same behavior with reflection processing(Reflector) provided by MyBatis on OGNL expression.
@harawata WDYT?

Thank you, @kazuki43zoo !
I didn't check all tests, but it looks OK.
I might add some @SuppressWarnings on the test class later to comply with my compiler settings (unused and synthetic-access).

@harawata Thanks for your comment!
I've added @SuppressWarnings on the test case class. I will merge this at later.

Hi @kazuki43zoo ,
I have accidentally committed the first two commits when committing another change (I seemed to forget switching branch when reviewing this PR).
Please let me know if I should reverse those commits. I'm sorry!

Hi @harawata, No need revert it! I will apply 3rd commit into master branch using cherry-pick.

This changes already merged.

Thank you, @kazuki43zoo ! =)


Hide/Filter element

Hello. How i can hide or filter specific element.

Where i use print_control_identifiers() it is print all child_window including Table with 600 rows it is take a long time for print.

Please help me

@xor0x , print_control_identifiers doesn't have built-in filtering functionality as it supposed to dump all visible controls. The only option for you is to play with depth parameter, if it can help. Otherwise, you may opt out to iterate manually through window descendants. Notice that descendants methods for both backends (UIA and win32) accept control_type and class_name filtering options. Here a basic example for win32 backend.
import pywinauto.application
app = pywinauto.application.Application()
app.start(cmd_line='notepad.exe')
top_win = app.top_window()
for w in top_win.descendants(class_name='Edit'):
    print(str(w))

Thnx


[WIP, DONOTMERGE] NLFG + Manifold Demo

This is my attempt on combining #37 and #34 . Thanks to @marcrasi and @dan-zheng (kudos!), all tests are running good with the generic PriorFactor and BetweenFactor.
Next steps:

[x] Test Pose3SLAM
[ ] ... other stuff, please comment :)

Very cool!

So now the Pose3SLAM test is working, but it is indeed extremely slow (Not only in time, but also in iterations). Need to debug what is happening:
error = 0.005291152028057079
error = 0.005291150688696615
error = 0.0052911506878240335
error = 0.005291150687709195
error = 0.00529115068769014
error = 0.0052911506876862505
error = 0.005291150687684503
error = 0.0052911506876833925
error = 0.005291150687682579
error = 0.005291150687681873
error = 0.005291150687681252
error = 0.005291150687680697
error = 0.005291150687680208
error = 0.005291150687679765
error = 0.005291150687679377

Could be a bug of CGLS, need also check #42

@marcrasi  I think I found the problem: jacobian() for Vector6 is wrong, its first part is empty (always zero). Is this related to the fact that Vector6 is a combination of two Vector3s?

Test:
  func testPose3SimplePriorFactor() {
    let P = Vector3(3.5,-8.2,4.2)
    let R = Rot3.fromTangent(Vector3(0.3, 0, 0))
    let t12 = Vector6(Tensor<Double>(repeating: 0.1, shape: [6]))
    let t1 = Pose3(R, P)
    let t2 = Pose3(coordinate: t1.coordinate.global(t12))
    let prior_factor = PriorFactor(0, t1)

    var vals = Values()
    vals.insert(0, AnyDifferentiable(t1)) // should be identity matrix,
    // but is not (upper left is zero)
    // Change this to t2, still zero in upper left block

    print(prior_factor.linearize(vals))
  }

It looks like an AD bug. Here's a workaround: https://github.com/borglab/SwiftFusion/pull/47

@marcrasi Thanks!

Can confirm Pose3SLAM example is working as expected :) Kudos to @marcrasi and @dan-zheng  for the help!

Can confirm Pose3SLAM example is working as expected :) Kudos to @marcrasi and @dan-zheng for the help!

That's awesome! 🎉

Just a side note: adding @differentiable constraints to the init(scalars: [Double]) triggers this ICE:
Assertion failed: (newAdjointValue.getType() == getRemappedTangentType(originalValue->getType())), function addAdjointValue, file /Users/danielzheng/swift-debug/swift/lib/SILOptimizer/Differentiation/PullbackEmitter.cpp, line 244.

Yeah, I just ran into that. I think it's the same one that you have been running into every time you do some differentiable stuff with structs that have custom tangent vectors (https://bugs.swift.org/browse/TF-969). I'll try to prioritize fixing that soon, so that it doesn't keep happening :)
In the meantime, I know how to work around it, so I think I'll have a fix pretty soon.

Assertion failed: (newAdjointValue.getType() == getRemappedTangentType(originalValue->getType())), function addAdjointValue, file /Users/danielzheng/swift-debug/swift/lib/SILOptimizer/Differentiation/PullbackEmitter.cpp, line 244.

I'm happy to take a look at this now, since I've encountered similar errors in the past.
@marcrasi: could you please 👍 if this is cool with you?

@ProfFan, I have pushed a commit to this PR that fixes it. It was basically adding some @differentiable annotations plus working around some of the known AD issues.

Oh, it seems like a test is still broken. (It didn't run for me locally on Linux because Linux requires registration in XCTestManifests and some of the tests aren't registered there).
I'll investigate the test and add it to XCTestManifests.

(It didn't run for me locally on Linux because Linux requires registration in XCTestManifests and some of the tests aren't registered there).

oooo, I can get automatic test discovery on Linux with swift test --enable-test-discovery (https://oleb.net/2020/swift-test-discovery/)! I'll use that instead of manually registering all the tests! I'll also eventually send a cleanup PR cleaning up all the manual test registrations.

@marcrasi Oh I didn't know that! If that is the case I think yeah, let's nuke these :)

Ok, just pushed a fix for the test. All the tests pass for me on Linux so I'm quite hopeful that the macos CI will also pass.

@marcrasi I migrated the Rot3 impl to the new Matrix implementation, but it seems we are missing some derivative workarounds for Matrix. I pushed the WIP to feature/new_matrix_for_pose3 , if you have time can you take a look? Thanks in advance!

@marcrasi I migrated the Rot3 impl to the new Matrix implementation, but it seems we are missing some derivative workarounds for Matrix. I pushed the WIP to feature/new_matrix_for_pose3 , if you have time can you take a look? Thanks in advance!

Yep, will do! It might be a few hours because I have some meeting soon.
Note: Because Rot3 uses a fixed-size matrix, a fixed sized Matrix3x3 struct would be much more efficient than the dynamically-sized Matrix struct. (This is because the array in the Matrix requires a heap allocation. This is related to the heap allocation stuff we talked about in the meeting on Friday. I have some ideas about this that I will write up soon.). So we should probable generate some fixed-size matrix structs eventually. But for now, Matrix is a good intermediate step.

@marcrasi I migrated the Rot3 impl to the new Matrix implementation, but it seems we are missing some derivative workarounds for Matrix. I pushed the WIP to feature/new_matrix_for_pose3 , if you have time can you take a look? Thanks in advance!

I took a look and discovered that it would require tons of boilerplate right now, boilerplate that would be reduced by other work (https://bugs.swift.org/browse/TF-982 + the DifferentiableVector mentioned here: https://github.com/borglab/SwiftFusion/pull/37#discussion_r421730219). Therefore, I propose that we leave the Rot3 matrix operations as Tensor for now and revisit them when some of that other work is done. Since the Tensor doesn't leak out of Rot3's API, the only consequence is that Rot3 will be a bit slow until w get around to fixing it. Other parts of SwiftFusion should be unaffected.

What do you think about just squash n' merging this into master and then addressing any comments as additional small PRs into master? We're all basically already doing all our work off this branch, so it would be convenient to have it in master so all our work can be small PRs into master.
Let me know if you'd like any help resolving the conflicts and fixing up calls to changed APIs.

@marcrasi Yeah that's cool with me! I can resolve the conflicts and squash, then we can move on from this and close the other stale PRs. @marcrasi @dan-zheng @dellaert Please comment :)

@marcrasi Done :)


🐛 Tried to synchronously call function {nonPromiseMethodWrapper} from a different thread

What were you trying to do?
I was trying to follow https://www.react-native-vision-camera.com/docs/guides/frame-processors-plugins-overview#async-frame-processors-with-event-emitters and by placing an EventEmitter within useFrameProcessor raises the "tried to synchronously call function from another thread" I find this interesting because https://reactnative.dev/docs/native-modules-ios#export-a-native-method-to-javascript states that RCT_EXPORT_METHOD creates asynchronous functions, so Im not sure why Im having this error
Reproduceable Code
EventEmitter.h

#import <React/RCTBridgeModule.h>
#import <React/RCTEventEmitter.h>

@interface LabelEventEmitter : RCTEventEmitter <RCTBridgeModule>
@end

EventEmitter.m
#import <Foundation/Foundation.h>
#import <React/RCTBridgeModule.h>

@implementation EventEmitter

RCT_EXPORT_MODULE(LabelEventEmitter);
RCT_EXPORT_METHOD(process:(NSString *)frame){
  NSLog(@"Hello from the otherside");
}
@end

ReactNative
import { NativeModules } from 'react-native';
import * as React from 'react';
import { NativeEventEmitter, StyleSheet, View } from "react-native";
import Reanimated, { runOnJS, runOnUI, useAnimatedStyle, useSharedValue } from 'react-native-reanimated';
import { Camera, Frame, useCameraDevices, useFrameProcessor} from "react-native-vision-camera";
import { useIsFocused } from '@react-navigation/native';

export default function CameraPage(){

    const devices = useCameraDevices()
    const focused = useIsFocused()

    const device = devices.back
const { eventEmitter } = NativeModules;

    const frameProcessor = useFrameProcessor((frame)=>{
        'worklet';
        eventEmitter.process(frame) // this fails

        //@ts-ignore
        console.log("Running on the UI thread") // this workds

    }, [])
       return(
            <>
                {typeof device !== 'undefined' &&
                <>
                <Camera
                    style={StyleSheet.absoluteFill}
                    device={device}
                    isActive={focused}
                    frameProcessor={frameProcessor}
                    fps={5}
                    />

                <Reanimated.View style={boxOverlayStyle} />
        </>
        }
            </>
        )
}

What happened instead?
The app crashes with [native] Tried to synchronously call function {nonPromiseMethodWrapper} from a different thread.
Possible solutions are:
a) If you want to synchronously execute this method, mark it as a Worklet
b) If you want to execute this method on the JS thread, wrap it using runOnJS
2023-08-25 10:13:13.375430-0400 kc_mobile[463:7630] [javascript] Running on the UI thread
2023-08-25 10:13:13.772573-0400 kc_mobile[463:7822] [native] Tried to synchronously call function {nonPromiseMethodWrapper} from a different thread.
EDIT: Added Additional library versions
"@react-native-community/cli-platform-ios": "^11.3.7",
"@react-navigation/native": "^6.1.7",
"react": "18.2.0",
"react-native": "^0.71.3",
"react-native-reanimated": "^2.14.4",
"react-native-vision-camera": "^2.15.4"
Relevant log output
No response
Device
iPhone XR (iOS 16.6)
VisionCamera Version
2.15.4
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Closing as this is a stale issue - this might have been fixed with the full rewrite in VisionCamera V3 (🥳) - if not, please create a new issue.
If your issue has been fixed, consider sponsoring me on GitHub to say thanks 💖


Flutter 3 upgrade

The current flutter_webview dependency version is 2.0.13.
Flutter has been announced as version 3 and its webview_flutter is ^3.0.4.
When will webviewx release the next version?
Thanks.

+1

Flutter seems to be building a webview for web as well https://pub.dev/packages/webview_flutter_web
perhaps join forces?

we want updates

@fisforfaheem  how did u resolve this?


Change npm bin field to Object type to fix merging deserialization issue

Found two extra deserialization exceptions when doing group package metadata merging on stage, it needs to add additional deserialization for the bin field in VersionMetadataDeserializer, to simplify, just use Object for bin field to support multiple(Map) and single(String) value.
https://issues.redhat.com/browse/MMENG-4038

LGTM.


Make infrastructure explicit in module structure

PR Description
Rearranges a lot of stuff to introduce a clearer infrastructure layer in the module structure.  These modules live under the infrastructure directory and form the bottom of our module architecture.  As such they only depend on other infrastructure modules and can be used from anywhere else in the codebase.
Specific changes made:

Move logging to infrastructure
Move events to infrastructure.
Split subscribers into a separate infrastructure:subscribers module.
Move ChannelInterface and VoidReturningChannelInterface to infrastructure:events and remove dependency on util
Move LoggingDestination to :infrastructure:logging and remove dependency on util
Move metrics to infrastructure.

Documentation

[x] I thought about documentation and added the documentation label to this PR if updates are required.

 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.


feat: simplify new app setup by reducing areas that need modification

Intro
Hello! Just wanted to say I'm using this for a new project and I'm super pumped to have found this. Thank you to all contributors for everything you've done to make this great.
As I was getting my project bootstrapped, I noticed a few things that could help speed up getting up and running and this PR covers one of them.
If any of the changes are undesirable or don't follow conventions, please let me know and I can adjust accordingly!
Summary
Moves all instances of Epic Notes to a single file so new Epic Stack users can modify a single line and have it propagate to all instances where that constant is used.
Note: In root.tsx, I split the APP_NAME value on spaces and then try to render the first word and all remaining words so there is one less place for developers to modify, at least early on.
Test Plan
I didn't add any additional tests, but I can if helpful. search.test.ts was checking for the string Epic Notes, and that test is still passing.
Checklist

[x] Tests updated
[x] Docs updated (no changes needed)

Screenshots
Screenshots showcase no regressions in the UI:

Behavior For 1-Word And 3+ Word App Name

Ok, sounds good. I'll close this out.
Thanks again for the great starter app, it's been a lot of fun to work with.

This is actually it's a SUPER simple one-time change to replace Epic Notes with your app name - and you can use this same approach for any build-time substitution you would like :
Create ./types/vite-env.d.ts with the following content:
/// <reference types="vite/client" />

interface ImportMetaEnv {
	readonly VITE_APP_NAME: string
	readonly VITE_APP_DESCRIPTION: string
}

interface ImportMeta {
	readonly env: ImportMetaEnv
}

Add the VARS to GH Actions secrets as well as locally.
The you can update meta functions to use the variable. e.g. This is from root.tsx
export const meta: MetaFunction<typeof loader> = ({ data }) => {
	return [
		{
			title: data
				? import.meta.env.VITE_APP_TITLE
				: `Error | ${import.meta.env.VITE_APP_TITLE}`,
		},
		{ name: 'description', content: import.meta.env.VITE_APP_DESCRIPTION },
	]
}

Or signup.tsx
	const response = await sendEmail({
		to: email,
		subject: `Welcome to ${import.meta.env.VITE_APP_TITLE}!`,
		react: <SignupEmail onboardingUrl={verifyUrl.toString()} otp={otp} />,
	})

Or forgot-password.tsx
	const response = await sendEmail({
		to: user.email,
		subject: `${import.meta.env.VITE_APP_TITLE} Password Reset`,
		react: (
			<ForgotPasswordEmail onboardingUrl={verifyUrl.toString()} otp={otp} />
		),
	})


Bug: Fix result messages

Resolves: https://github.com/AY2324S2-CS2103T-T17-3/tp/issues/188

@RyanNgWH good idea, ive added them


NXDOMAIN

I'm getting an NX error when contacting https://api.statdns.com/, is this part of the shutdown?
It would be nice if you would allow queries for statdns.net, it's useful for debugging.

Indeed, the free public API has been discontinued and the statdns.net zone too.

@fcambus Is it too late to keep statdns.net zone open?  I'm working on the IETF DNS JSON spec and was hoping to create a JSON DNS comparison zoo....

I currently have no plans to put the statdns.net zone back online. One of the reason I put it offline is the DNS workbench project, which offers a much better alternative :-)
The zone served there has more RR types and it is served by several different implementations.

Thank you!


hhblits: Neutralized tag at position XXX

Does hhblits ignore protein tags when computing the structure? How are protein tags treated when alphafold predicts the protein structure?

HHBlits and AlphaFold don’t treat protein tags in any special way, you would have to modify your sequence (and/or the sequences in the genetic databases) to remove the tags manually.


pageserver: make wal_source_connstring: String a separate type

Now it is wal_source: tokio_postgres::Config.
In the future the connection string will include password, which should not be dumped into logs. Using a structured type allows such customization: tokio_postgres::Config does not implement Display, and its Debug implementation hides the password.
Performance hits are not measured, but we rarely manipulate configs.

Kind of continuing #2724

After some consideration I concluded that I don't like Url either. Reasons are mostly the same: Url is hard to validate, it can contain much more that our connection string actually needs in this case. But the main problem is postgres connection string looks awful in URL.
As we don't manipulate connection strings in Pageserver much (only one place for creation and one place for consumption), I'd continue the trend with simple strings.
@funbringer WDYT?

I agree that whether Url is suitable or not hugely depends on the context. But the point is, I didn't suggest to use bare Url: the key idea is to create your own type and be in full control of what's inside. If you like strings for storing the underlying info: go ahead and use them, I don't mind! Just make sure they're wrapped in a 1st class type with proper parsing, validation and accessors.

PS: it just so happens -- at least in my practice -- that strings fall short as soon as you try to add more sophisticated accessors.

Agree. I think in this specific case we don't need any accessors at all. Create something in one place (from structured data), alter it slightly and use immediately in another place.
The only reason for this PR is to sanitize logs. Making the next step and actually storing connection parameters separately is not worth it at this moment, I think, we only have two places that handle them: one creates connection string, and one uses. A proper (de)serializer will take another 50-100 lines of code (including tests), and it won't make the code easier. At least now.


fix: change logic to separate functions from layers in mock

*Issue #4992 *
Description of changes:

Changed the logic to mock functions with layers when dependency on a function

Added tests for the same

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

Hi, @akshbhu just wondering when will this be available on taking npm update


I train waveglow use logmel, but loss is nan after epoch 9?

all audio time is longer than 2s, fs is 24K, segment_length is 16000,

https://github.com/NVIDIA/waveglow/issues/123
https://github.com/NVIDIA/waveglow/issues/95


Test Android back button is functional

We should add a regression test that verifies that we don't break the back button on Android.

This is likely possible with Android java integration tests.  @jason-simmons wrote one as part of:
https://github.com/flutter/flutter/tree/master/examples/hello_services/android/app/src/androidTest/java/com/example/flutter
but we don't currently run them anywhere.

cc @yjbanov do we have anything like this?

Kind of.


Move the definitions of coudclient.datamodel to the Django back-end

Acceptance:

[ ] References to other existing objects are nested (lists in other models) or implemented with foreign keys
[ ] A fixture for the current case is implemented (mvp.py)
[ ] Datamodels are defined in scenarios (which on itself are related to a case)
[ ] Default energy assets can be added (much like the current gridconnections implementation)

From the datamodel plan


Added QUANTILE agg function to Calcite

Added the interpolation parameter, datetime data is also supported, the test passes - https://github.com/modin-project/modin/pull/6528/files#diff-924b045aa089c05b3a717bc9cea19dc8581e2b8351fcc3c0568a54a27ce8a146R1284


[all] Update to gophercloud 1.4.0

What this PR does / why we need it:
Bumps the gophercloud dep to the latest release
Release note:
NONE

/lgtm
/approve


Accepting integers of type long that fit in 64 bits.

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[ ] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[x] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[ ] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

r: @charlesccychen I've tested this with mvn clean verify and all tests. Run properly. Should I add a test case?

Added a test case ; )

Thanks, LGTM.  I've tested that this works on Windows.

Addressed comments.

Thanks, LGTM, after that extra large integer test.

@robertwb can you merge this please? This should fix the broken build on Windows.


chore: add sql return to retrieval service

retrieval service to return results and sql query. Sql query will be used to display tracing at the frontend.
This PR only add sql return for postgres and alloydb provider. Other providers will be added in a separate PR.

/gcbrun

/gcbrun


Unused project and files are created: .HttpModels

There's a folder and files that get created but never used:
.HttpModels
This project isn't added to the solution file and the files look like duplicates in the Modules project.

I noticed the same. That project is a leak from the Blazor template. v1.1.0 will address this.


Fixed panic when egui fails to return window

This seems to be a regression of https://github.com/Plonq/bevy_panorbit_camera/issues/79

Thanks!


⚠ Bofrost.es has degraded performance

In a29511d, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1700 ms

Resolved: Bofrost.es performance has improved in fb9590d after 4 hours, 28 minutes.


Stackoverflow assigning to struct member

Expected behavior
Assigns values to member of struct
Actual Behavior
Stack overflow
Code
struct { int x; int y; } s;
int main() {
        s.x = 0;
}
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted

AST
declaration: extern  s: <anonymous struct>;
declaration: extern  main: int() {
((s).x) = ((int)(0));
}

Crashes before generating ASM.

Introduced in 51019a1bb6ef3f72e956d74fa49b890656a09182, it worked before.


"No such comm" again

ALL software version info

holoviews 1.13.2
notebook 6.0.3
Python 3.7

Description of expected behavior and the observed behavior
Not getting errors and warnings for holoviews use in a notebook.
Complete, minimal, self-contained example code that reproduces the issue
This code cell is all what one currently needs to trigger errors and warnings after a restart of the notebook:
import holoviews as hv
hv.notebook_extension('bokeh')

So, procedure to trigger the error and warning in the console is

execute code cell
restart notebook
executing code cell again

Stack traceback and/or browser JavaScript console output
[I 13:48:32.046 NotebookApp] Replaying 7 buffered messages
[IPKernelApp] ERROR | No such comm target registered: hv-extension-comm
[IPKernelApp] WARNING | No such comm: hv-extension-comm

it's intriguing though that different to the older stories, now there's also ERRORs being created.

@philippjfr Does the suggestion that they are now ERRORs as opposed to warnings concern you or do you still think these messages are safe to ignore?

No, it's really just the log level that was changed it still doesn't indicate any real error condition.

In that case do you think this will ever be fixed (in which case this issue can stay open) or maybe this is an unfortunately case of wontfix?

aand they are back... :(
\[IPKernelApp] ERROR | No such comm target registered: jupyter.widget.control
[IPKernelApp] WARNING | No such comm: ad3fae9f-d861-4a71-8bf7-e466009b0650
|[IPKernelApp] ERROR | No such comm target registered: jupyter.widget.control
[IPKernelApp] WARNING | No such comm: 151ed4eb-7939-4789-aec9-552998478b1b
[IPKernelApp] ERROR | No such comm target registered: jupyter.widget.control
[IPKernelApp] WARNING | No such comm: a1f8aa4a-1358-40b4-9b34-cab7ddc665d9
[IPKernelApp] ERROR | No such comm target registered: jupyter.widget.control
[IPKernelApp] WARNING | No such comm: 6f7a646d-01ab-4f85-99a6-83d292c2429a
[IPKernelApp] ERROR | No such comm target registered: jupyter.widget.control
[IPKernelApp] WARNING | No such comm: 42dc6bd9-8e6d-48f5-8b96-498e3b88e3d5
[IPKernelApp] ERROR | No such comm target registered: jupyter.widget.control
[IPKernelApp] WARNING | No such comm: fb59eda0-c563-4360-9585-3afa6f42e1aa

My $500 USD bounty for anyone who can make those messages go away is still open...

My $500 USD bounty for anyone who can make those messages go away is still open...


Infinite Loop in Directive

Versions

vee-validate: 3.0.3
vue: 2.6.10

Describe the bug
Error using an infinite loop directive
To reproduce
Steps to reproduce the behavior:

Press F12 to Developer Tools.
Type some characters
You will see the infinite loop on the console.

Expected behavior
Apply uppercase characters to strings.
Demo link
Codesandbox.
Desktop (please complete the following information):

OS: Windows 10
Browser Chrome
Version 76.0.3809.100

Well, this is related to your directive implementation, it does not have a condition to skip the update hook which is recommended in the Vue.js docs.
Avoiding unnecessary updates is always preferable:
const newVal = vnode.elm.value.toUpperCase();
if (el.value === newVal) {
  return;
}

el.value = newVal;
el.dispatchEvent(new Event("input"));

https://codesandbox.io/s/vue-template-urip9


Only 3 Heading levels?

The exposed commands of the extension list Heading levels 1-6, but the Authoring Guide says only levels 1-3 are rendering correctly - not sure which is right? Can we use 1-6?

@jeffchasin - Only levels 1-3 are rendered with formatting, but there's nothing preventing you from using headings 4-6 if you have a reason. Headings 4-6 are rendered with body text formatting by default.


Confused about the weight of SE-Unet

Great job! Your contribution to the field of image forgery localization is impressive. Apologies for the interruption. I'm a bit puzzled—does the pretrained weights of the Unet imply training it on the ImageNet dataset or specifically on a manipulation dataset?

Thanks for your interest. The SCSE-UNet weights released on this link is trained on a manipulation dataset. While the UNet weights from this link is trained on Facebook transmission dataset. Both of the above weights are trained based on an ImageNet initialization weights.

Thank you for your response! I wish success for your most recent work's acceptance this year!


Add Secret key renewal azure app info

Add info regarding Azure AD app renewal for secret key and expiry date
This is importan as there´s lack of information about it and is emerging issue
Fixes #1103

@MSBeatriz : Thanks for your contribution! The author, @aczechowski, has been notified to review your proposed change.

@MSBeatriz : Thanks for your contribution! The author, @aczechowski, has been notified to review your proposed change.

Thanks @MSBeatriz for the updates. A couple more small items, and we should be good to go.

@MSBeatriz : Thanks for your contribution! The author, @aczechowski, has been notified to review your proposed change.

Microsoft authors of articles need to make updates through the private repository so the updates can be staged and validated by the current validation rules. After you review staging and fix all validation issues, you can add the sign-off comment to let the PR reviewers know the updates are ready to be merged.It's easy to access the private repo version of your articles in GitHub. Just add -pr to the URL, as follows:
Public repo URL: https://github.com/Microsoft/azure-docs/blob/master/articles/azure-portal-overview.md
Private repo URL: https://github.com/Microsoft/azure-docs-pr/blob/master/articles/azure-portal-overview.md
We have closed this pull request. Please resubmit the updates through the private repo. If you need perms to the private repo, see the contributor guide instructions

Automation bug, reopening

Reviews and publishing aren't happening this week. I'll #sign-off but don't expect any further action (especially publishing live) until 2 January. No further action necessary from you.


How do you get the depth maps of RGB images like LLFF

Hi, thanks for the great work!
I want to know how you got the depth maps in your datasets.
As far as I know, some original datasets like LLFF do not provide depth information.
Thanks!

Hi @tmpss93172, for the ECCV submission, we used a pre-trained nerf to obtain the depth. We're also working on improving the framework to work with monocular depth estimators. Thanks!

Got it. Thank you so much!


Not showing in modules zabbix 6.4.1

Hi,
I have upload this modules in /user/share/zabbix/modules/zabbix-module-sqlexplorer/ but in GUI zabbix modules menu not show SQL Explorer module. Could you please help me ?

You should modify manifest.json property manifest_version to 2, to module be discoverable by Zabbix version 6.4+. As is written in module README, current version is compatible with version 5.x - 6.2.

Support for Zabbix version 6.4 and newer is added to module version 1.8