Arguments of type array cannot be access via index

Expected Behavior
When using a parameter of type Array and trying to access access a specific index, the variable substitution does not occur. Assuming the following pipeline spec, I would expect the tasks generated to have the value 'false' be substituted.
apiVersion: tekton.dev/v1beta1
kind: Pipeline
...
spec:
  params:
    - disabled:
        - 'false'
        - 'false'
        - 'false'
        - 'false'
...
  tasks:
    - name: ...
      params:
        - name: disabled
          value: '$(params.disabled[2])'

Actual Behavior
As can be seen here once the pipeline is run (seen through dashboard) , the variable is not substituted.

Steps to Reproduce the Problem
Outlined above
Additional Info

Kubernetes version:
Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.8", GitCommit:"211047e9a1922595eaa3a1127ed365e9299a6c23", GitTreeState:"clean", BuildDate:"2019-10-15T12:11:03Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.12-gke.2", GitCommit:"fb7add51f767aae42655d39972210dc1c5dbd4b3", GitTreeState:"clean", BuildDate:"2020-06-01T22:20:10Z", GoVersion:"go1.12.17b4", Compiler:"gc", Platform:"linux/amd64"}

Tekton Pipeline version:
Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

Client version: 0.11.0
Pipeline version: v0.14.3
Triggers version: v0.7.0

Hey @jtestard, thx for the issue. I think it's not clearly documented in here, but we do not currently support accessing array values by index.
/cc @skaegi @bobcatfish

I noticed a typo indeed: the pipeline parameter name is disabled and matches that of the task parameter.

@vdemeester We are using Tekton in production at our startup, pretty eager on the tech. However, this (among other things) is a blocker to get us where we want to be. Is this the kind of issue an external contributor could easily tackle?

@vdemeester We are using Tekton in production at our startup, pretty eager on the tech. However, this (among other things) is a blocker to get us where we want to be. Is this the kind of issue an external contributor (us) could easily tackle could get things going faster?

@jtestard sure :wink: I wonder if this needs a TEP or not (my guess is that we may not but… it's kinda user-facing :thinking:)

I wonder if this needs a TEP or not

I think it's probably a good idea.  We've had other proposals for this problem that suggest a more wide-ranging solution (see the JSONPath work @skaegi started for instance here and, related, here).  And we've had similar requests asking for CEL.  So there's been some different proposals.  It seems like a good idea, if we're going to expand our variable access features, to write something up and talk it through as a community.
WDYT?

@sbwsg So only adding index-based array access would be too incremental a change. I don't know if we have the resources on our end to assist with adding support for a whole new language such as JSONPath/CEL. Let us know if/how we can help

So only adding index-based array access would be too incremental a change.

Ah, that wasn't quite what I was trying to suggest, sorry.  I agree with what @vdemeester suggested: this is a user-facing change.  And this is an area that's had people propose changes to it in the past.  So, given it's user-facing and we've got other folks in the community who are interested in this area, I think that writing up a short TEP to declare the change you're proposing is the way to go.
For what it's worth I think the incremental improvement is a good idea.  But I just want to make sure it gets surfaced to the right folks before we commit to it getting implemented and merged.

/remove-lifecycle rotten
Keeping this one alive because I think array params could still use some improvements like this to make them far more useful.

/remove-lifecycle rotten
Keeping this one alive because I think array params could still use some improvements like this to make them far more useful.

CEL Custom Tasks is now available and can be used for indexing and other array functions on parameters: https://github.com/tektoncd/experimental/tree/master/cel
Taking this example PipelineRun with contains and indexing:
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: pr-indexing-
spec:
  pipelineSpec:
    params:
      - name: alpha
        type: string
    tasks:
      - name: indexing
        taskRef:
          apiVersion: cel.tekton.dev/v1alpha1
          kind: CEL
        params:
          - name: c-exists
            value: "'c' in $(params.alpha)"
          - name: at-index-1
            value: "$(params.alpha)[1]"
  params:
    - name: alpha
      value: "['a', 'b', 'c']"

When executed, the CEL Custom Task produces evaluation Results that can be used in subsequent tasks:
Name:         pr-indexing-d47gj
Namespace:    default
API Version:  tekton.dev/v1beta1
Kind:         PipelineRun
Metadata:
  Creation Timestamp:  2021-01-22T16:13:22Z
  Generate Name:       pr-indexing-
# […]
Status:
  Completion Time:  2021-01-22T16:13:22Z
  Conditions:
    Last Transition Time:  2021-01-22T16:13:22Z
    Message:               Tasks Completed: 1 (Failed: 0, Cancelled 0), Skipped: 0
    Reason:                Succeeded
    Status:                True
    Type:                  Succeeded
  Pipeline Spec:
    # […]
  Runs:
    pr-indexing-d47gj-indexing-2t9vr:
      Pipeline Task Name:  indexing
      Status:
        Completion Time:  2021-01-22T16:13:22Z
        Conditions:
          Last Transition Time:  2021-01-22T16:13:22Z
          Message:               CEL expressions were evaluated successfully
          Reason:                EvaluationSuccess
          Status:                True
          Type:                  Succeeded
        Extra Fields:            <nil>
        Observed Generation:     1
        Results:
          Name:      c-exists
          Value:     true
          Name:      at-index-1
          Value:     b
        Start Time:  2021-01-22T16:13:22Z
  Start Time:        2021-01-22T16:13:22Z
Events:
  Type    Reason     Age   From         Message
  ----    ------     ----  ----         -------
  Normal  Started    12s   PipelineRun
  Normal  Running    12s   PipelineRun  Tasks Completed: 0 (Failed: 0, Cancelled 0), Incomplete: 1, Skipped: 0
  Normal  Succeeded  12s   PipelineRun  Tasks Completed: 1 (Failed: 0, Cancelled 0), Skipped: 0

@jtestard if you use this, please share any feedback on your experience and how we can make it better 😄
TEP: https://github.com/tektoncd/community/pull/314
(note: CEL Custom Tasks is currently an experimental project)

CEL Custom Tasks is now available and can be used for indexing and other array functions on parameters: https://github.com/tektoncd/experimental/tree/master/cel
Taking this example PipelineRun with contains and indexing:
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: pr-indexing-
spec:
  pipelineSpec:
    params:
      - name: alpha
        type: string
    tasks:
      - name: indexing
        taskRef:
          apiVersion: cel.tekton.dev/v1alpha1
          kind: CEL
        params:
          - name: c-exists
            value: "'c' in $(params.alpha)"
          - name: at-index-1
            value: "$(params.alpha)[1]"
  params:
    - name: alpha
      value: "['a', 'b', 'c']"

When executed, the CEL Custom Task produces evaluation Results that can be used in subsequent tasks:
Name:         pr-indexing-d47gj
Namespace:    default
API Version:  tekton.dev/v1beta1
Kind:         PipelineRun
Metadata:
  Creation Timestamp:  2021-01-22T16:13:22Z
  Generate Name:       pr-indexing-
# […]
Status:
  Completion Time:  2021-01-22T16:13:22Z
  Conditions:
    Last Transition Time:  2021-01-22T16:13:22Z
    Message:               Tasks Completed: 1 (Failed: 0, Cancelled 0), Skipped: 0
    Reason:                Succeeded
    Status:                True
    Type:                  Succeeded
  Pipeline Spec:
    # […]
  Runs:
    pr-indexing-d47gj-indexing-2t9vr:
      Pipeline Task Name:  indexing
      Status:
        Completion Time:  2021-01-22T16:13:22Z
        Conditions:
          Last Transition Time:  2021-01-22T16:13:22Z
          Message:               CEL expressions were evaluated successfully
          Reason:                EvaluationSuccess
          Status:                True
          Type:                  Succeeded
        Extra Fields:            <nil>
        Observed Generation:     1
        Results:
          Name:      c-exists
          Value:     true
          Name:      at-index-1
          Value:     b
        Start Time:  2021-01-22T16:13:22Z
  Start Time:        2021-01-22T16:13:22Z
Events:
  Type    Reason     Age   From         Message
  ----    ------     ----  ----         -------
  Normal  Started    12s   PipelineRun
  Normal  Running    12s   PipelineRun  Tasks Completed: 0 (Failed: 0, Cancelled 0), Incomplete: 1, Skipped: 0
  Normal  Succeeded  12s   PipelineRun  Tasks Completed: 1 (Failed: 0, Cancelled 0), Skipped: 0

@jtestard if you use this, please share any feedback on your experience and how we can make it better 😄
TEP: https://github.com/tektoncd/community/pull/314
(note: CEL Custom Tasks is currently an experimental project)

Keeping this one alive because I think array params could still use some improvements like this to make them far more useful.

@sbwsg another alternative we could consider, if CEL custom tasks is promoted from experimental, is deprecating array params and supporting string params only for simplicity and flexibility (avoiding to implement our own expression syntax)

Keeping this one alive because I think array params could still use some improvements like this to make them far more useful.

@sbwsg another alternative we could consider, if CEL custom tasks is promoted from experimental, is deprecating array params and supporting string params only for simplicity and flexibility (avoiding to implement our own expression syntax)

@sbwsg another alternative we could consider, if CEL custom tasks is promoted from experimental, is deprecating array params and supporting string params only for simplicity and flexibility (avoiding to implement our own expression syntax)

Very interesting!  I agree this would solve a lot of different problems we have with the existing array syntax's complexity and offer flexibility on syntax choice / behaviour.  I wonder how we could handle situations where a user passes an array of varying length and this needs to be merged / appended to a Step's command or args list.

@sbwsg another alternative we could consider, if CEL custom tasks is promoted from experimental, is deprecating array params and supporting string params only for simplicity and flexibility (avoiding to implement our own expression syntax)

Very interesting!  I agree this would solve a lot of different problems we have with the existing array syntax's complexity and offer flexibility on syntax choice / behaviour.  I wonder how we could handle situations where a user passes an array of varying length and this needs to be merged / appended to a Step's command or args list.

@jtestard have you tried the CEL custom task that @jerop mentioned above?  It doesn't directly handle tekton's concept of "array params" but you can pass it a stringified array and process it with CEL.

I'm creating a proposal to add specifically support for indexing into arrays; however I'm limiting the proposal to that so if we want to talk about full JSONPath (or even CEL) support that would have to be a separate proposal.
/remove-lifecycle rotten

Still happening I promise! 🙏
/remove-lifecycle stale


BatchingBolt which is volume-based, not time-based.

The current BatchingBolt implementation is based on the number of ticks. A variant could accumulate tuples (or even values contained in those tuples) until a certain threshold is hit (e.g. every 100 tuples). This would be useful when e.g. batching to an upstream/downstream service that is rate-limited, as to send a full request.
This would likely need some time-delay featured in which the threshold is ignored after a certain wait, as to avoid holding onto values indefinitely if the threshold is never hit.

This would be pretty easy to setup.  We'd just need to split the check on this line out into its own method called BatchingBolt.is_batch_ready() (or something like that).  We could then just have the default implementation be:
def is_batch_ready(self):
    return self._tick_counter > self.ticks_between_batches and self._batches

Then in your ThresholdBatchingBolt subclass you would just need to override that one method as:
def is_batch_ready(self):
    if self._batches:
        num_tuples = sum(len(batch) for batch in itervalues(self._batches))
        return (num_tuples >= self.batch_threshold or
                super(ThresholdBatchingBolt, self).is_batch_ready())
    else:
        return False

That'll give you an implementation that will fallback on time if the size threshold isn't met, so you just need to make sure you set ticks_between_batches high enough.

This issue was moved to pystorm/pystorm#2


sqlpbi problem

sqlpbi - steram analytics job
Encountered error trying to write 1 event(s): Cannot insert the value NULL into column 'Deleted', table 'pidibiDB.dbo.POIs'; column does not allow nulls. INSERT fails. The statement has been terminated.
I added default value (0) for this column to fix this issue, I will see next trip if it's OK

PR created


testCheck the lock with mtmv life and table

Proposed changes
testCheck the lock with mtmv life and table

The execution time of the case is very long. Merge it into the "selectdb cases" project. Run it by myself.


Delete headers

A body is allowed in HTTP DELETE, we're missing adding the header in the client convenience method

I knew this would create ripples! haha! I've actually thought of a better way to implement what I needed this for, so it's no longer required. That said, there is nothing in the specification preventing a DELETE request from containing a body.


remove clearing of ._{element,placeholder} on unload

this was causing issues as eg when nodes are reordered, unload will fire and then onload. then, this._element would be null but it's actually there, in the DOM.

5.0.1


bonsai feature gate to use rustls

Can you provide more details on this issue? If you could provide use cases, reproduction examples, and expected results that would help out a lot.

hi @flaub sorry for missing use cases, I was trying to build a static linked binary and rustls sounds better in this case.

Switched to rustls in https://github.com/risc0/risc0/pull/1200


resnet50 code has bug?，the first stack1' first block don't use 1*1 conv

https://github.com/keras-team/keras/blob/2c48a3b38b6b6139be2da501982fd2f61d7d48fe/keras/applications/resnet.py#L453
https://github.com/keras-team/keras/blob/2c48a3b38b6b6139be2da501982fd2f61d7d48fe/keras/applications/resnet.py#L271
https://github.com/keras-team/keras/blob/2c48a3b38b6b6139be2da501982fd2f61d7d48fe/keras/applications/resnet.py#L213
the first stack1' first block should be conv_shortcut=False  (but the function block1' paramerer default value conv_shortcut=True)
Here are my previous discussions about restnet with other teams:
https://github.com/d2l-ai/d2l-en/pull/1839

Hi @chenying99
In the ResNet Paper they said

(B) The projection shortcut in Eqn.(2) is used to
match dimensions (done by 1×1 convolutions)

This doesnt mean 1x1 convolution is there only to solve the problem of dimensionality increase. As a matter of fact Table 1 in the paper explicitly lays out the architecture and there is a 1x1 convolution in the first stack too.

1x1 Conv is not present in ResNet18 and ResNet34 but is present in ResNet50, ResNet101 and ResNet152. The discussion you provided is maybe about ResNet18 and ResNet34. And to quote @goldmermaid from the said discussion

I see what you were saying. The TF code is used for modelling Resnet50, Resnet101 and Resnet152, which may not be a good reference for Resnet18.

I think this helps you out.

Thank you for your explanation. The reason is probably that the number of output channels of resnet50 in the last convolutional layer is 4 * filter
x = layers.Conv2D(4 * filters, 1, name=name + '_3_conv')(x)
https://github.com/keras-team/keras/blob/2c48a3b38b6b6139be2da501982fd2f61d7d48fe/keras/applications/resnet.py#L249


typo

missing colon

Coverage remained the same at 92.5% when pulling 6aa13170aade84a191ae8f1411beb11f0808919c on mabuelhagag:patch-1 into ede636e661d0fe2de337c2f524a757899148189c on escaped:master.

Thanks a lot :)


Add script for migrating old subject colors to new subject colors

Summary
This pull request adds a script to migrate all old subject colors to new subject colors (Gray, Red, Orange, Green, Blue, Purple). Since we got rid of Gray, I migrated it to Ithaca Winter. This migration will make changes to color values in the user-subject-colors collection, but won't affect the colors of courses already added to the semesters. For now, I have only run single user dry-runs on dev.

[x] added color migration script

Extends #573
Reference from #593
Test Plan

npm run ts-node -- src/requirements/admin/color-migration <user email> to dry-run on a single user.
npm run ts-node -- src/requirements/admin/color-migration --run-on-db to run on the entire database.

Can you push the console logs that you have in that screenshot? It's hard to tell what's happening without them

LGTM - feel free to run on the dev db instance and check if everything looks good after it!

Ran on dev db instance successfully.


For Unicode, Atom doesn’t have a concept of canonical equivalence and or compatibility.

The underlying error for this issue causes multiple bugs, as outlined below.
Canonical Equivalence Issue
When using soft wrap, one can confirm that this is true. For example, consider the following two canonically equivalent code sequences:

N = (U+0061, U+0301)
O = (U+00E1,)

In the following snippet of text, the first line uses N but not O, and the second line uses N, but not O.
asdfasdfasdf ááááááááááááááááááááááááááááááááááááááááááá
asdfasdfasdf ááááááááááááááááááááááááááááááááááááááááááá

If one enables soft wrap and sizes the window appropriately, they’ll notice that the first line wraps before the second line wraps, as shown in the following image. It seems as though Atom naïvely calculates N as two separate characters. I would expect Atom to treat it as a single character.

Additionally, if one resizes the window appropriately, they can see that the second code point in N can be separated and wrapped independent of the first code point, as shown in the following image. Obviously, Atom does not do this for O.

This lack of canonical equivalence can also be demonstrated via the search feature, as shown in the following images. Neither N is considered a match for O nor vice-versa. In regard to the third following image, I do not currently have a guess as to what could cause the depicted result. Atom should either match all characters that has that code point in the code sequence or only the characters whose entire code sequence matches.

In regard to a fix for this bug, note that the following code sequences, though visually Q = S ≠ R = T = U, are in fact all considered canonically equivalent.

Q = (U+0061, U+0301, U+0307) should render as ā̇
R = (U+0061, U+0307, U+0301) should render as ǡ
S = (U+0101, U+307) should render as ā̇
T = (U+0227, U+0301) should render as ǡ
U = (U+01E1,) should render as ǡ

Note that R does not render correctly, as shown in the following image. Upon initial research, this seems to occur for all characters in which the subsequent code points in the corresponding code sequence are not in ascending order.

Compatibility Issue
Compatibility comes into play for characters that might have distinguishable appearances but have the same meaning. Compatible characters are not necessarily canonically equivalent, but canonically equivalent characters are always compatible (as I understand).
Consider the typographic ligature “ﬀ” (code sequence (U+FB00,)). The string “ff” (code sequence (U+00FF, U+00FF) is compatible with the ligature. However, in this particular case, care should be taken to not consider them compatible if the latter one is followed by a combining character.
Note that compatible sequences shouldn’t always necessarily be treated the same way. It depends on the situation.
Similar Issues
This appears to be related to #1783, but based on my findings, these appear to be separate bugs. #1783 appears to be caused by inconsistent character widths in the font. This issue differs in that code points are not being properly combined. It appears that there are many duplicates of #1783 that are unrelated to this issue. Some of the duplicates even initially appear similar to this one.
At first glance, this appears related to #1894, but I do not believe that they are related in any way.
There seem to be many issues related to this, but none touch on the underlying problem of this one: Unicode equivalence.
Closing Remarks
A partial solution would be to normalize the underlying representation of the text. Users might expect the code sequences to not be modified, so that would introduce a challenge in terms of memory or efficiency.
A fix should only be effective for Unicode codings. At the time of this writing, the only supported Unicode encodings are UTF-8, UTF-16 BE, and UTF-16 LE.
Since this is a silent, semantic issue, there are no error reports to include.
All of the screenshots and described behavior are from Atom 1.0.15 on OS X Yosemite 10.10.5. No changes to the UI (e.g. switching themes, directly modifying the theme, etc.) seem to affect any of the aforementioned issues.
More information in regard to the Unicode aspect can be found in “Chapter 3” of The Unicode Standard: Version 7.0 – Core Specification. Additionally, an overview can be found on the “Unicode equivalence” article on Wikipedia.

I'm not familiar with the internal structure of Atom and only have very basic understanding of Coffeescript. I tried browsing the source to figure out where a good starting point would be. Perhaps this issue belongs in atom/text-buffer? I'm not sure.


Q: In the option.php example, are both orderedQuantity and quantity needed? And what's their different meanings?

In the option.php example, are both orderedQuantity and quantity needed? And what's their different meanings?
<orderAction>BUY_OPEN</orderAction>
                  <orderedQuantity>1</orderedQuantity>
                  <quantity>1</quantity>

Thanks.

They are defined in the ETrade API:
https://apisb.etrade.com/docs/api/order/api-order-v1.html#/definition/orderPlace
I've always set them to the same, you can contact ETrade support to find out when these might be different.
BTW, you will probably find the orderticket.php examples more useful.  It shows how to setup a one, two, three, or four legged option order w/o worrying about the underlying XML order format.


Note on 6th April

seven wonders in t5
get all t1 cards at beginning
kill xinyang

There will be only three cards for each type.


[feature] Change the docker base image to nvidia/cuda, add docker-compose.yml

Hi @utkuozdemir, thanks for your great work!
I noticed #110 #112 talking about how docker accessing the gpu, I thought using nvidia/cuda as the base image might be a good choice for less configuration to run in the docker, to I made this PR.
I added a file named docker-compose.yml and updated the document so that everyone can make everything fine and easy.
And also remote accessing from arm64 like rapberrypi-3b or later would still work because nvidia/cuda support arm64. (but not tested because I don't have such a device)
Feel free if there is any question or something wrong. :)
Best regards!
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] I have read the CONTRIBUTING document.
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Thanks for the contribution - Just I am not sure if cuda's license allows us to use it as a base image - Nvidia's licenses are tricky. Need to look into that. If you have any findings, I'd appreciate if you share them here.

The plain Ubuntu 24.04 image can access nvidia-smi if you have installed NVIDIA Container Toolkit (which is the suggested way for using Docker and NVIDIA GPUs), as shown in this simple example found from NVIDIA's documentation

sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

So I guess you can avoid nvidia/cuda and just update the example to:
 docker run -d -p 9835:9835 --runtime=nvidia --gpus all utkuozdemir/nvidia_gpu_exporter:1.2.0

Which is much simpler. But of course this won't work with machines that have Docker but cannot install the NVIDIA Container Toolkit.


Attempt to address remaining blockers for 0.8 - RFC/Review

I want to apologize in advance for the big funky PR and the length of the description here. There are a number of chewy issues outstanding in edge that I consider to be blockers and this is my attempt to address them. There are a few somewhat overlapping things combined here:
Rebinding
This moves from view-based rebinding to model-based rebinding, meaning that instead of the shuffle telling the view that everything in the view needs to rebind, the model that is shuffling tells all of its deps that its value is moving to a new model. It also supplies the target model so that the deps can make sure that it matches so that deps on the absolute path list.0.bar don't accidentally get shuffled to list.1.bar on an unshift. This is a good deal faster than having everything in the view re-resolve and has the added bonus of catching things that aren't view-related, like observers, mappings, and resolvers.
There are a handful of outstanding shuffle bugs, particularly on observers, that are resolved by this type of rebinding along with the next change...
Mappings
This also takes the mapping and link constructs and merges them using a new type of model. The LinkModel is simply a model that points to another model, which may be a plain data model or another link itself. When a link model is mutated, it triggers the mutation on its source model and lets it filter back to the link, so there's still a single source of truth at the origin. That creates something like a parallel namespace for the link that manages its own deps, resolvers, etc. The separate namespace makes changing the root source of the link much simpler, since now it doesn't have to try to comb through combined deps and figure out which ones should be shuffled off to the new source and which ones should remain on the model.
Side Note: Since there was a ton of overlap between Model and LinkModel, I rebased them both on a new ModelBase. I'm not crazy about the name, but it DRYs up a good bit of code.
Any regular model may now be turned into a link by having a LinkModel installed on it at _link. The ModelBase.link method takes care of creating a link on a model, transferring (rebinding) the model's deps to the new link, and making sure everything updates. Linking on an already linked model simply updates the source of the link.
The issues with shuffling under a mapping e.g. {{#each list}}<component foo="{{.}}" />{{/each}} and observers are much easier to address, and I think they're all covered here. Conditional mappings also have their corner cases addressed when combined with the rebinding changes.
Since the method to generate aggregate root data on instance.get() changed to accommodate links, I also added an options object for get that allows you to control whether or not you want the aggregate or the source data directly. The root model defaults to providing the virtual data on get, and child models default to providing the source data so as not to be a breaking change. You can now call instance.get({ virtual: false }) to get the actual root object and instance.get('some.path', { virtual: true }) to get some.path including any children that may be links.
Since mappings and links are the same thing, this would open up the possibility to have nested mappings for components. It would also make cross instance links equivalent to mappings. I haven't addressed either of those here, but it looks like they'd be easy to achieve.
Expressions
Expressions in edge are composed of a proper Computation and an ExpressionProxy that manages the computation. The problem with that is that the computation is registered with the root of the model based on its signature and signature can, and with expressions often do ,overlap. They also create a giant map to deal with in the root model if there happen to be a few expressions in a large iterative section. I was originally going to try to reuse the computations, but then I realized that expressions with object and array literals in them can't be safely reused.
This takes the ExpressionProxy and detaches it from a computation to let it stand as its own full model somewhat mirroring what Computation does. There is probably more that could be shared between them, but I'll address that later if this works out. Now realistically, there was no way to interact with an expression model outside of the template before, but there is definitely not a way to do so here where the expression is not registered anywhere in the model tree (other than as a dep). So to address that, I extended the context methods to resolve to actual models and perform their operations instead of resolving to keypaths and just calling the appropriate instance method. That adds a bit of code to the context methods, but it also opened up an opportunity to share more code as generalized helpers among the instance methods, notably handling * keypath resolution and maps of paths to values.
So, you can now cause an update in an expression as long as you have an anchoring event or node info object from an element where the expression is part of the context. To be clear, if you want to call any instance methods from an expression context, you will need to use the context method on the event object to do so, as the keypath can no longer be resolved e.g. {{#foo()}}click{{/}} as opposed to {{#foo()}}click{{/}}. I think that's an overall improvement anyways, and it has the added benefit of not updating the wrong section if the expression keypath happened to overlap somewhere else in the template. I also added reverse and sort to the context methods, as they were missed the first time around.
if/elseif/else in edge use a clever negation and stacking of their expressions to split each branch into its own section. The downside to that is that side-effecting or expensive computations with be run an additional time for each successive branch. This PR drops the expression duplication and adds a flag on elseif and else sections that marks them as subordinate. When a subordinate section binds, it looks up its nearest sibling and links it with itself. Then when any of the siblings updates, it notifies its subordinate siblings to update as well, and each of them checks to see that none of the prior siblings is truthy before checking their own condition. This effectively emulates the usual branching method of most languages. This is technically a breaking template change, but the new code can still manage an old template, so I don't think a template bump is necessary since there's already one in edge.
Epilogue
If you have some time to look over the code, I'd really appreciate some review. If you have some more time to build it and try it out with a project, that would be great too! I'm thinking about publishing some scoped Ractive experiments on npm, and this would probably be a good place to start considering that if it passes review I'd still like to get some mileage on it before merging.
Thanks!
TODOs

[x] Implement and test rebinding for decorators
[x] Implement and test rebinding for transitions

No, that's definitely not intended. In fact, I don't even see where it's happening, as there's nowhere that sets el other than render, which isn't called on teardown. I'll see if I can track it down :smile:

If understand correctly @keypath cannot longer be used inside e.g an {{#each}} section.
Is this correct? Isn't this a breaking change?

@kouts you can still use @keypath in any context as long as it's not an expression, so {{#each lists[whichList]}}{{#some.child}}<button on-click="@this.set(@keypath + '.foo', 'whatever')">click me</button>{{/}}{{/each}} is still fine. Having {{#each someExpression()}}<button on-click="@this.set(@keypath + '.foo', 'whatever')">click me</button>{{/each}} will no longer work with this changes as it exists, but there were already template constructs wherein that would fail because of the overlap, making only the last instance of the expression update.
So yes, this is a breaking change in that regard. Is that a frequently used construct? I have it some as a workaround, but I'm migrating to the much less painful equivalent that is already available in edge and better here: {{#each someExprsession()}}<button on-click="event.set('.foo', 'whatever')">click</button>{{/each}}. I can rig a deprecation cycle if this is going to land and it would help.
Vote here for your preference on deprecation: thumbs up yes add in a deprecation cycle for using @keypath in an expression context, thumbs down no.

Oh, ok it's a thumbs up on deprecation from me then.
Thanks for the detailed explanation @evs-chris.

Read through novel and it all made sense to me. Scanned through code, looks good too. Outside of the large number of added tests, I think you're close to a net 0 in added code 😀

TL;DR faster rebinding, more complete (decorators and transitions are handled), magic arrays are painful
Decorators and transitions now have proper rebind handlers, so their params don't get confused if they happen to be shuffled. There are now also tests to cover more weird cases.
Rebinding is now considerably faster, though I suppose it's more the post-rebind update that's faster. While profiling I discovered that every dep in a shuffled tree was getting updated after the shuffle,   which can be quite painful for large iteration counts and complex templates with expressions. All that updating is really unnecessary with a shuffle, because the underlying values don't change - they just move around a bit. To remedy that, I split the post-shuffle update into two stages: early and mark. The early stage runs immediately after the rebinding for the tree is complete. The mark stage runs immediately after the mark towards the end of the shuffle method.
Mustaches and expressions will now wait until the mark stage to register with their new dep, so that they do not get called on to update during the mark. They do so by checking the new safe flag on rebinding, which is true for shuffling models, but not for keys, indexes, and keypaths or during remapping. The end result is that expressions and mustaches no longer are dirtied and updated during a shuffle unless they actually need to. If you avoid index or key (non-shufflable) based deps, shuffling is super fast, and it's even sped up considerably if you do have those deps. Expressions also recompute much less.
Magic arrays are painful as an aggregate wrapper consisting of separate magic and array adaptors, really weird things go on with them. When the array side is doing a splice operation, each index has its setter called, which in turn triggers a set through the magic side. Naturally this can lead to some really weird behavior when shuffling. I've temporarily address this by adding a way to lock the magic side from the array side so that the setters aren't called during shuffles, thus avoiding the weirdness with updates. To be clear the weirdness would be the view getting completely out of sync as it updates against an already spliced array and is then shuffled with the new splice info afterwards. I hope to get these fully handled in an adaptor overhaul PR at some point.

@JonDum I haven't been able to reproduce the issue with the element not being set on teardown. If you've got a few minutes to spare could you put together a demo that I can step through?

Also forgot to mention that there is now deprecation in place for calling methods with @keypath derivations within an expression context. It'll throw out a warning in debug mode each time it happens, and the deprecation and support will be removed in 0.9. It will also fall over in the same way as current edge if there happens to be a duplicate expression keypath.

I haven't been able to reproduce the issue with the element not being set on teardown. If you've got a few minutes to spare could you put together a demo that I can step through?

Can't repro anymore after latest merge of dev into this branch. Whatever it was seems to be fixed now. 👍 🐋

Right on! If there are no objections, I shall merge this tomorrow so I can deal with any bugs that shake out this week.


Typo "Azure Blob storage"→"Azure Blob Storage"

https://docs.microsoft.com/en-us/windows/uwp/monetize/python-code-examples-for-the-windows-store-submission-api

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

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

Matches the current style guidance; thanks @hyoshioka0128.

Matches the current style guidance; thanks @hyoshioka0128.


Running CppSharp /wo VS(only build tools)

We are trying to run application that uses Cppsharp on our build server where only BuildTools are installed. No VS. When I run the bindings generator.exe that is using cppsharp I get following error:
System.Exception: Could not find a valid Visual Studio toolchain. (pointing towards MSVCToolchain.GetVSToolchain(VisualStudioVersion version)).
Is there any way to run this app without need to install VS?
Thanks.
OS: Windows 7 x64
Target: MSVC/GCC/Clang

Which VS version are we talking about?

Preferably none :). We cannot install VS on our build machine based on some restrictions we have. We are using only MS BuildTools 2015 Update 3 currently to run our .NET and cpp builds there.

My bad, my "VS" I meant which build tools version. So, for versions up to 2015, we look up the include paths in the registry.
If you could help with tracking down the issue, we have helper code that would probably give some insight into what is happening on the machine: https://github.com/mono/CppSharp/blob/master/src/Core/Toolchains/MSVCToolchain.cs#L62
Just write a very simple C# project that references CppSharp.dll and calls MSVCToolchain. DumpSdks and paste the result here.

The output from DumpSdks():
Visual Studio SDKs:
Windows SDKs:
(8) C:\Program Files (x86)\Windows Kits\8.0
(8) C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A
(8.1) C:\Program Files (x86)\Windows Kits\8.1
(8.1) C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A
(10) C:\Program Files (x86)\Windows Kits\10\
Windows Kits SDKs:
(1) C:\Program Files (x86)\Windows Kits\8.1
(8) C:\Program Files (x86)\Windows Kits\8.0
(10) C:\Program Files (x86)\Windows Kits\10\
.NET Framework SDKs:
MSBuild SDKs:
(2) C:\Windows\Microsoft.NET\Framework\v2.0.50727
(3.5) C:\Windows\Microsoft.NET\Framework\v3.5
(4) C:\Windows\Microsoft.NET\Framework\v4.0.30319
(14) C:\Program Files (x86)\MSBuild\14.0\bin\

As expected there seems to VS SDK found by the registry lookup.
@MichalPolaczyk Can you confirm if you're installing "MS Build Tools 2015" or "Visual C++ Build Tools 2015"? The first only seems to install managed toolchains, while the latter installs C++ build tools.
The only reason we try to look up the VS version is to look up the Windows SDK version that we should be relying on to parse the code.
You can find the code here: https://github.com/mono/CppSharp/blob/master/src/Core/Toolchains/MSVCToolchain.cs#L165
We already have some fallback code is we cannot find the VS version: https://github.com/mono/CppSharp/blob/master/src/Core/Toolchains/MSVCToolchain.cs#L185
So what we need to do here is to improve the robustness of the existing code (GetSystemIncludes) so that it works even if no VS version is found on the system.
Want to give it a try?

Hi,
I attached screen from the machine where you can see installed SDKs and MS and C++ Build tools.

So what exactly do You have in mind? To make the check not depend only on VS?

Yeah, the existing lookup code needs to be reworked a little to not fail early if a VS version is not found on the system.

@MichalPolaczyk we have long switched to looking system headers up with Clang so both VS and MS Build are skipped now as Clang is significantly more reliable. In other words, while, of course, one still needs the headers themselves, VS is no longer required to be installed.


Real Time doesn't work?

Hey,
Would you please share the codes?

Also have trouble with this.. Just can't get it to work..


Add Proxy support

Added Proxy authentification to use with Invoke-RestMethod. The
parameters are define with Set-MSRCApiKey function.

@NicolasBn,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.
It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

@NicolasBn, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, Microsoft Pull Request Bot


dartdevc: Static requirements on type annotations for initializing formals

This is the dartdevc specific issue for #30816, which has the details.
In case this is handled by the analyzer it may be a no-op.

yup, we will not need to do anything for this in DDC. Yay for sharing front ends :)

;-)


Fix deeplinks don't work when signing in with a new account

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/48475
PROPOSAL: https://github.com/Expensify/App/issues/48475#issuecomment-2336832176
Tests

Go to https://dev.new.expensify.com:8082/
Sign out
Navigate via deeplink or open this url in browser https://dev.new.expensify.com:8082/concierge
Sign in with a new account
Complete the onboarding
Verify that the concierge page opens

Offline tests

QA Steps

Go to https://staging.new.expensify.com/
Sign out
Navigate via deeplink or open this url in browser https://staging.new.expensify.com/concierge
Sign in with a new account
Complete the onboarding
Verify that the concierge page opens

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/user-attachments/assets/787389f5-82db-473f-9e91-4abafddf5cbd

Android: mWeb Chrome
https://github.com/user-attachments/assets/8ce1524a-094d-46f9-9a87-b42e8eed00ad

iOS: Native
https://github.com/user-attachments/assets/7c8cb2c9-39d7-4229-846d-01276b423b88

iOS: mWeb Safari
https://github.com/user-attachments/assets/4d175135-2b0a-4dbd-ae27-9e638df59e08

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/bd61427a-5d1c-4c45-b697-779f46f490c5

MacOS: Desktop
https://github.com/user-attachments/assets/9994f01a-06eb-46c6-9c86-71553661446f

@allroundexperts ready for review

I rewrote the code using a different approach than proposed since the main branch has changed, and hasCompletedGuidedSetupFlowSelector is no longer used here. @allroundexperts bump on a review

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@CyberAndrii Can you please resolve the conflicts?

@CyberAndrii Can you please resolve the conflicts?

@allroundexperts done, ready for review

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.


Feature/hipp 199

initial basic test for api hub

A more recent pr including this is used instead


feat: add DeNA/unity-meta-check/gh-action-yaml-gen

DeNA/unity-meta-check/gh-action-yaml-gen: A cli tool to automatically generate action.yaml for DeNA/unity-meta-check
Check List

[x] Read CONTRIBUTING.md

[x] Read OSS Contribution Guide

[x] All commits are signed

This repository enables Require signed commits, so all commits must be signed

[x] Avoid force push
[x] Do only one thing in one Pull Request

How to confirm if this package works well
Reviewers aren't necessarily familiar with this package, so please describe how to confirm if this package works well.
Please confirm if this package works well yourself as much as possible.
Command and output
root@cbfc696b6d27:/workspace# gh-action-yaml-gen --help
usage: gh-action-yaml-gen <path>

If files such as configuration file are needed, please share them.
Reference

https://github.com/DeNA/unity-meta-check/blob/master/README.md

v4.180.0 is out 🎉
https://github.com/aquaproj/aqua-registry/releases/tag/v4.180.0


fix for sm row count and z flag

From https://github.com/CU-DBMI/set-intake/issues/6
Disclaimer: I really have no background on this subject and don't know what this code is supposed to do, so please make sure you test the affected parts very thoroughly.

I am approving under the assumption that they have been tested.

I say in the original comment that I did not test this beyond making sure the error went away. @JessMurphy or @hendriau should test this to make sure it produces the expected results still.


Support multipart file uploads for interaction responses via webhook builder

Summary
Currently, if you wish to attach a file to an interaction via the webhook builder it does not work, ie:
file = File.open('/Users/robherley/Pictures/photo.png')

event.respond(content: 'photo') do |builder|
  builder.file = file
end

The above will only send the content, and not the file as intended.
This is because the methods defined in the webhook API don't support a file parameter and the interaction data is only serialized for a json payload:
https://github.com/shardlab/discordrb/blob/dc27fe18463da3ccfd0f0266030aa7ad51b2c2b9/lib/discordrb/data/interaction.rb#L97-L100
This PR adds support for file uploads via the interaction methods that support it. To avoid breaking changes and compatibility with the current method signature, I added an additional nil-by-default param. However, it would be nice to move these all to keyword arguments eventually.
I also added some specs for the modules that were missing them. They don't have complete coverage of the module, but cover the changes introduced in this PR.

Added

Discordrb::Webhooks::Builder#to_payload_hash: returns relevant hash depending on the presence of @file
spec for Discordrb::API::Interaction
spec for Discordrb::Interaction

Changed

Discordrb::API::Interaction

added file as a parameter to #create_interaction_response

Discordrb::API::Webhook

added file as a parameter to #token_edit_message

Discordrb::Interaction

for #respond, #update_message, #edit_response, #send_message, #edit_message:

using #to_payload_hash instead of #to_json_hash for webhook builder
passing file param from webhook builder to relevant API method

Deprecated
None
Removed
None
Fixed

Uploading file in interaction methods via webhook builder
The unrelated failing Channel#delete_all_emoji_reactions test, it was a small mistake with the emoji encoding

@swarley is this PR good to merge as is? or would you prefer support for attachments vs. the existing single file implementation

@robherley If you're up to the task we can get the multi file upload going here, otherwise I can take care of expanding it in a separate PR. I'd like to get it working with multiple files before we tag a new release 🙂. Let me know what you want to do

@swarley I can add the multi-file attachments in this PR! Just a couple impl questions:

would you prefer removing file from the webhook builder altogether? or should I just mark it as deprecated and append the single file to attachments
a lot of the ::Interaction methods use positional args instead of keyword args which makes invocation a bit awkward like this. are you opposed to changing those func signatures to use keyword arguments instead?

I would mark as deprecated, and I'd like to change the API methods to use kwargs in the next major release but currently they need to stay as positional for consistency and semver reasons.
I'm actively working on the API portion of v4 now and rest assured we won't have positional stacks like this

@swarley multi-file attachments should be supported now:
fileA = File.open('/Users/robherley/Pictures/photoA.png')
fileB = File.open('/Users/robherley/Pictures/photoB.png')

event.respond(content: 'photos!') do |builder|
  builder.attachments = [fileA, fileB]
end

file will log out as deprecated and if a user supplies both it just falls back to the deprecated behavior until they switch completely to attachments. I thought about appending the file to the attachments list but that'll probably just create more confusing behavior 😅
also noticed the rubocop complaining about unchanged files 🤷 I can fix those if you want


Fix Typo in README.md

Hi Alignedlayer, was following the steps in the README.md. Found a small typo in there, rectified it. Do check on it. Thanks!

thank you for the correction. Unfortunately we don't accept typo fix PRs, but we will fix it


Variable Name adjusted

Small change. Not really important but should be changed I think.

This pull request is now managed with CodeReviewHub. Refresh.


diesel print-schema > foo.rs fails without error message if database url not set

Setup
Versions

Rust: 1.77
Diesel: cli version 2.1.1
Database:
Operating System

Feature Flags

diesel: postgres, no default

Problem Description
What are you trying to accomplish?
Output schema file and see why exit status is 1
What is the expected output?
The --database-url argument must be passed, or the DATABASE_URL environment variable must be set.

What is the actual output?

Are you seeing any additional errors?
Steps to reproduce

diesel print-schema --config-file=diesel.toml > tmp.schema

diesel.toml:
[print_schema]
file = "crates/db_schema/src/schema.rs"
patch_file = "crates/db_schema/src/diesel_ltree.patch"

Checklist

[x] I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

[x] This issue can be reproduced on Rust's stable channel. (Your issue will be
closed if this is not the case)
[x] This issue can be reproduced without requiring a third party crate

Thanks for reporting.
I can reproduce the problem with the latest release, but not with the latest version from master. It was likely fixed with https://github.com/diesel-rs/diesel/pull/3897
Closed as this issue is already fixed


Web-console: add Supervisor statistics table and show json query manager

-Adds query manager to show-json.
-Adds supervisors-statistics-table that displays supervisor statistics

Looking good, thank you for addressing my feedback so promptly. 👍


lang.error module does not have an object called "StackFrame"

The spec says the lang.error / error.bal has a object called StackFrame .
# Type representing a stack frame.
# A call stack is represented as an array of stack frames.
# This type is also present in lang.runtime to avoid a dependency.
public type StackFrame readonly & object {
   # Returns a string representing this StackFrame.
   # This must not contain any newline characters.
   # + return - a string
   public function toString() returns string;
};

But in the current master of swanlake implementation, that object is missing. Instead it has a different class
# Represents an error call stack.
#
# + callStack - call stack
public class CallStack {
    public CallStackElement[] callStack = [];
}

This affects the following langlib function also. It has to return an array of StackFrame, not a CallStack object.
# Returns an array representing an error's stack trace.
#
# + e - the error value
# + return - an array representing the stack trace of the error value
# The first member of the array represents the top of the call stack.
public isolated function stackTrace(error e) returns CallStack = external;

Affect version: slbeta3

Fixed in https://github.com/ballerina-platform/ballerina-lang/pull/33542


Reduce rerendering caused by resize observations

Context
When a component's state changes, React will rerender it and its children. useBreakpoints uses useState internally to manage the observed breakpoints. For most breakpoints value types, I can rely on React to skip rerendering children if I update the state to the same value. However, useBreakpoints allows objects to be a returned value type, so these would trigger potentially unnecessary rerenders.
Changes

findBreakpoint now returns the key of the matching breakpoint rather than its value.
Update state only if matched key is different than current state.

Based on observations (pun intended) by @gbakernet and after reasoning and exploration with @bensmithett I'm closing this PR. It seems reasonable to remove the use of state entirely from useBreakpoints.


Filter service does not use common entity returning functions

https://github.com/amosproj/amos-ss2021-project2-context-map/blob/b7f259cc03dda39a5dcabc654763c2e395d4201f/backend/src/filter/filter.service.ts#L89
https://github.com/amosproj/amos-ss2021-project2-context-map/blob/b7f259cc03dda39a5dcabc654763c2e395d4201f/backend/src/filter/filter.service.ts#L138
should use functions from src/config/commonFunctions.ts. This will reveal unwanted behaviour if the common functions are changed.

Done in 0c4a04b11cd4edcc5830a0f6c1bd93b4533ff5cb


Bug Report: Can't enter the charting state

Please check for duplicates, similar issues or closed issues with the same problem, as well performing simple troubleshooting steps (such as deleting the export folder if it's an issue with compiling, reinstalling Kade Engine) before submitting an issue.
If you are playing a downloaded version of the game, what operating system are you using?
Windows (x86), Windows (x86_64), Linux, or macOS? Specify below.
What version of the game are you using? Look in the bottom left corner of the main menu.
1.7
Have you identified any steps to reproduce the bug? If so, please describe them below. Use images if possible.
Press 7 to enter the charter when playing a song
Please describe your issue. Provide extensive detail and images if possible.
The game crashes when trying to open the chart menu. It does the fade to black, and then it stops responding. The instrumental of the song continues to play.

I figured it out. I had to remove <haxedef name="SKIP_TO_PLAYSTATE" if="debug" /> from the project.xml. It also disables error messages. Might want to remove that little line...
/closing


importer: add TDE support for upload sst

What problem does this PR solve?
Problem Summary:
Add TDE support for the upload method, so the ingest sst by tikv-importer should be encrypted.
What is changed and how it works?
What's Changed:
Related changes
Check List
Tests

Unit test
Integration test

Side effects
Release note

No release note

cc @yiwu-arbug  @hunterlxt


Add Favicon on site for easier identification in Browser

It's difficult to identify which tab is My Life aka HRP when browser has multiple tabs open.
Favicon is put on the site so that the site feels branded and it is easy to return to tab to resume usage of the site without opening an additional tab.
No alternatives are known at this time.
Currently the default world icon is shown as part of my Chrome browser.

now where oh where did my favicon go... there used to be one, should be easy to remediate, incorporating in .13


Bug: Exporting Resultset to new table in Oracle

When attempting to export data via the Oracle driver, the following error is generated when any fields with the number datatype are in the resultset.
CREATE TABLE TEST_TABLE(
FIELD1 NUMBER(39,0),
FIELD2 VARCHAR2(50) NOT NULL,
FIELD3 VARCHAR2(7));

Error starting at line : 2 in command -
Error report -
ORA-01727: numeric precision specifier is out of range (1 to 38)
01727. 00000 -  "numeric precision specifier is out of range (1 to 38)"
*Cause:
*Action:

If the table creation query is manually modified and run using a value within the range specified, the table is created successfully.
CREATE TABLE TEST_TABLE(
FIELD1 NUMBER(38,0),
FIELD2 VARCHAR2(50) NOT NULL,
FIELD3 VARCHAR2(7));

Table TEST_TABLE created.

You can change target DDL manually (click on Column Mappings button and then change target data type by clicking on column type name)

Awesome, thanks for the tip!
Is there a way to have the DDL default to NUMBER(38, 0) instead of NUMBER(39, 0) instead of having to manually modify the DDL each time?
According to their documentation, the number data type supports up to 38 significant digits.

The bug fixes and improvements in v5.0.6 seem to have resolved this issue. Thank you!


"failed to lookup address information" exception on index download

I'm seeing this exception when I either run pack-manager cache pdsc or directly call Cache.cache_descriptors(). I've tried running pack-magager cache rm prior to attempting again, to no avail.
Io(Custom { kind: Other, error: StringError("failed to lookup address information: nodename nor servname provided, or not known") })
Traceback (most recent call last):
  File "/Users/creed/projects/pyOCD-flit/venv/mac37/bin/pack-manager", line 10, in <module>
    sys.exit(main())
  File "/Users/creed/projects/pyOCD-flit/venv/mac37/lib/python3.7/site-packages/cmsis_pack_manager/pack_manager.py", line 235, in main
    args.command(args)
  File "/Users/creed/projects/pyOCD-flit/venv/mac37/lib/python3.7/site-packages/cmsis_pack_manager/pack_manager.py", line 94, in thunk
    return command(cache, **argv)
  File "/Users/creed/projects/pyOCD-flit/venv/mac37/lib/python3.7/site-packages/cmsis_pack_manager/pack_manager.py", line 134, in command_cache
    cache.cache_descriptors()
  File "/Users/creed/projects/pyOCD-flit/venv/mac37/lib/python3.7/site-packages/cmsis_pack_manager/__init__.py", line 287, in cache_descriptors
    pdsc_index = self._call_rust_update(progress_fn)
  File "/Users/creed/projects/pyOCD-flit/venv/mac37/lib/python3.7/site-packages/cmsis_pack_manager/__init__.py", line 259, in _call_rust_update
    pdsc_index = lib.update_pdsc_result(poll_obj)
  File "/Users/creed/projects/pyOCD-flit/venv/mac37/lib/python3.7/site-packages/cmsis_pack_manager/__init__.py", line 35, in __exit__
    raise Exception(ffi.string(maybe_err))
Exception: b'\nfailed to lookup address information: nodename nor servname provided, or not known'

Oh weird. I don't know what would cause this off the top of my head.


Add dataframe windowed operations

This creates aggregations that can operated over time windows

Codecov Report

Merging #124 into master will decrease coverage by 2.7%.
The diff coverage is 88.77%.

@@            Coverage Diff             @@
##           master     #124      +/-   ##
==========================================
- Coverage   93.56%   90.86%   -2.71%
==========================================
  Files          12       12
  Lines        1430     1335      -95
==========================================
- Hits         1338     1213     -125
- Misses         92      122      +30

Impacted Files
Coverage Δ

streamz/dataframe/__init__.py
77.77% <100%> (ø)

streamz/dataframe/core.py
95.6% <100%> (ø)

streamz/dataframe/aggregations.py
86.85% <86.85%> (ø)

streamz/compatibility.py
66.66% <0%> (-33.34%)
:arrow_down:

streamz/collection.py
86.09% <0%> (-1.61%)
:arrow_down:

streamz/core.py

streamz/tests/__init__.py

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 5aa0f38...3eb8d8f. Read the comment docs.

That's fine too (and to be clear, this was just for making the example
simplier; the base class is already useful in the code if a user just wants
to do something like isinstance(., Aggregation)).
On Thu, Nov 16, 2017 at 11:14 AM, Matthew Rocklin<EMAIL_ADDRESS>wrote:

@mrocklin commented on this pull request.
In docs/source/dataframe-aggregations.rst
https://github.com/mrocklin/streamz/pull/124#discussion_r151479783:

+Aggregations
+------------
+
+Streaming Dataframe aggregations are built from three methods
+
+-  initial: Creates initial state given an empty example dataframe
+-  on_new: Updates state and produces new result to emit given new data
+-  on_old: Updates state and produces new result to emit given decayed data
+
+So a simple implementation of sum as an aggregation might look like the
+following:
+
+.. code-block:: python
+

class Mean(Aggregation):

I'm inclined to instead add the import from streamz.dataframe import
Aggregation to the line above. Even though we don't use the baseclass for
anything at the moment I suspect that we might in the future.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mrocklin/streamz/pull/124#discussion_r151479783, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABQHInf4IgU3exPzp-2ha9aIx_M5AhM8ks5s3G2BgaJpZM4QcK2k
.


tetragon: improve how we handle TIDs and GetProcessCopy()

Goes on top of https://github.com/cilium/tetragon/pull/1254

So the argument here is exit should always be associated with the same TID as the execve?

So the argument here is exit should always be associated with the same TID as the execve?

Yes this is the intention, so to sum up  at execve tid==pid at our current hook time (late) there is only one single thread, then:
We improved how to track last threads https://github.com/cilium/tetragon/blob/main/bpf/process/bpf_exit.c#L10  so technically we can report during exit TID != PID (TGID)
But we still report TID==PID: https://github.com/cilium/tetragon/blob/main/bpf/process/bpf_exit.h#L59
So if you see some value in reporting TID != PID at exit, we can make it and drop the last patch of this PR?
tid != pid at exit has some value but maybe only to expert users, plus the tid field is new!  in the other hand if users start to correlate the exceve and exit with PID and TID better have them equal, and that's it (simple).
For the related GetProcessCopy(): the long term goal is during kprobe if TID != PID then internally we just copy the shared fields during GetProcessCopy(), but for all the rest we have to set it at real time from BPF... this should reduce data copied during GetProcessCopy() but may add more cpu cycles for decoding non shared fields which we have to do anyway... and we already have an answer by masking some fields with --enable-process-cred --enable-process-ns flags to not decode nor report everything...
So here I will start incrementally isolating fields and making it clear in the code what fields we share and what not and assert that execve==exit events have some equal fields, but for other events we do case by case... to improve process cache handling and make it easy for us to remember :-D ...

@kkourt @olsajiri opinion on above?

Its not clear to me how to create "shared" fields until we rip the protobuf structs out of the core codes. I think we want to do this regardless though.

@kkourt ProcessInternal can be mutable but *process can not be changed while being handled by JSON/GRPC writers or else we risk corrupting the output.

I merged the patch 1 from the other PR as we discuss this.

@kkourt ProcessInternal can be mutable but *process can not be changed while being handled by JSON/GRPC writers or else we risk corrupting the output.
And (not sure we do this now) ProcessInternal really shouldn't be written/read without using some atomic, read_once, or locking primitive because multiple go routines might be working on it. Or if its a new object not pushed into a cache yet its safe because it has just a single go routine with access to it.

Makes sense. Might worth reviewing the code and verifying that things work as above. ProcessInternal does have a mu sync.Mutex so all accesses need to be done with the mutex held.

@kkourt ProcessInternal can be mutable but *process can not be changed while being handled by JSON/GRPC writers or else we risk corrupting the output.
And (not sure we do this now) ProcessInternal really shouldn't be written/read without using some atomic, read_once, or locking primitive because multiple go routines might be working on it. Or if its a new object not pushed into a cache yet its safe because it has just a single go routine with access to it.

Makes sense. Might worth reviewing the code and verifying that things work as above. ProcessInternal does have a mu sync.Mutex so all accesses need to be done with the mutex held.

@jrfastab @kkourt so that mutex is used to serialize:

retry / update processinternal.process.pod
get copy of processinternal.process to stream it to gRPC
annotate processinternal.process with namespace and capabilities

So not for processinternal but for the embedded protobuf process struct.
We have to do several things here:

Add another simple process struct inside processinternal and use it as the real holder instead of the protobuf one https://github.com/cilium/tetragon/blob/main/pkg/process/process.go#L42
Always collect process credentials and namespace during exec/clone and store directly in this new simple form (caps as int64...) inside process cache, get rid of of these protobuf capabilities and namespaces https://github.com/cilium/tetragon/blob/main/pkg/process/process.go#L44  too. When exporting events we chose what fields we export... --enable-process-creds etc or have better fields filters...

Decoding events to protobuf only when exporting events may add cpu overhead as now we decode once and use for both execve / exit , kprobes , etc, this also may do unnecessary GetProcessCopy() on all fields since we have to update the copies anyway for non main threads... (this is still in progress). so I think the schema below could work:

We may end up with:
// ProcessInternal is the internal representation of a process.
// nolint:revive // This is an acceptable case of "stuttering" since the name "Internal"
// wouldn't make much sense by itself.
type ProcessInternal struct {
        // internal process simple representation holder of the possible non shared information
        // that is the per thread info
        mainThread processSimple

	// muproto protects the modifications to cached proto process.
	muproto sync.Mutex
        // decoded protobuf fields externally visible process struct, decode once and serve many
	process *tetragon.Process

	// garbage collector metadata
	color  int
        refcnt uint32
}

The per thread fields are stored in the mainThread object. When we operate on the main thread, execve/exit, kprobe, tracepoints etc we compare the thread ID, if main thread use the cached protobuf fields. If not main thread then decode the rest (non shared) and return.

This could make processInternal somehow immutable as pointed by @kkourt until we start to hook in the sensors call sites that may change those fields...
@jrfastab I see you say it can be mutable is there some other reasons?

issue here: https://github.com/cilium/tetragon/issues/1290

@kkourt ProcessInternal can be mutable but *process can not be changed while being handled by JSON/GRPC writers or else we risk corrupting the output.

@jrfastab what are the scenarios where processInternal can be mutable? just ensuring I didnt miss any. IIRC the matchCapabilitiesChange updates the bpf execve_map and that's part of kprobe not a main sensor.
I think if we want to reflect this we have first to hook by default the setuid() family and update the credentials on the bpf execve_map then reflect this on the user space process cache too... we do it step by step, so we don't get tricked by some exploits etc...

I'm probably missing something, but I'm getting bit lost on how the TID works now ;-)
IIRC we have following events flow:
- fork      (TID == PID)
- exec      (TID == PID)
- [ku]probe or tracepoint (we record TID and create extra copy of Process in user space with this TID for report)
- exit      (TID == PID)

could we have comment like that somewhere explaining the current situation?
also maybe we could remove some of the tid fields from the kernel->user events,
that gets initialized as pids anyway, seems confusing

I'm probably missing something, but I'm getting bit lost on how the TID works now ;-)
IIRC we have following events flow:
- fork      (TID == PID)
- exec      (TID == PID)
- [ku]probe or tracepoint (we record TID and create extra copy of Process in user space with this TID for report)
- exit      (TID == PID)

could we have comment like that somewhere explaining the current situation?
also maybe we could remove some of the tid fields from the kernel->user events, that gets initialized as pids anyway, seems confusing

indeed will do

Its not clear to me what the issue created is about? In general IMO we rely to heavily on protobufs in lower edges of stack, but that is about optimizing performance and json encoder.
The mutex in processInternal is there to serialize writers/readers of processInternal. Somehow the 3 bullets above were lost on me.

I'm probably missing something, but I'm getting bit lost on how the TID works now ;-)
IIRC we have following events flow:
- fork      (TID == PID)
- exec      (TID == PID)
- [ku]probe or tracepoint (we record TID and create extra copy of Process in user space with this TID for report)
- exit      (TID == PID)

could we have comment like that somewhere explaining the current situation?

@olsajiri I did extensively last patch with commit log, please have a look

also maybe we could remove some of the tid fields from the kernel->user events, that gets initialized as pids anyway, seems confusing

I agree that we should remove it as some point, but for now it is useful as it helps debug things and ensure our model is right, and we are still not finished with handling all threads please take a look at the last patch commit log and to this comment https://github.com/cilium/tetragon/pull/1256#discussion_r1278296380

Ok @olsajiri updated based on all comments, and yes it turned more work with documenting all the stuff that it is still missing as you suggested. so basically we are not finished with all per thread transition hence some extra debug and warning messages... here and there.

I find this commit message to be confusing,
 We want to correlate the exit and exec events, for this the final TID
of the exit event _must matches_ the PID and TID of exec / clone events
since we handle all these by the main thread.

The tetragonEvent.Process of the exit event is constructed either:

  1. When looking up the process by its PID from user space cache
     then we get the process that was pushed during exec or clone.

  2. Out of order exec event, and this is same as (1).

For all these cases the TID of the exit should be _automatically set_ to
the TID and PID of the exec/clone event. To achieve this we ensure that
clone and exec events have their TID also set to PID.

* clone events must store the TID in the process cache directly and
  we ensure that it is the PID as we generate only one event that
  is the thread leader.

* exec event we ensure and automatically set TID to PID too and insert it
  into the process cache as it is the main thread doing the execve call.

However from bpf side:
We also ensure that exit events on their own must send bpf PID == TID,
if not let's print a warning that is useful to bisect things.

This helps to assert the different variants of tetragon and that
sensors or bpf part did not change on behalf of user space and cache
handling, as again we handle only one main thread in the bpf side and
also in process cache, and we still did not complete all the per-thread
fields transition.

My sort of understanding is something like,
Exit events should have TID==PID and the {TID,PID} in the exit event must match the {TID,PID} pair from the exec event. They must match because its how we link the exit event to the exec event. If TID!=PID or the Exit{TID,PID} pair does not match an Exec{TID,PID} pair then there is a bug.

This patch adds extra logic to WARN on conditions where TID!=PID to aid debugging and catch this unexpected case. Typically this indicates a bug either in BPF or userspace caching logic. When this condition is encountered we attempt to correct it by setting the TID=PID.

I find this commit message to be confusing,
 We want to correlate the exit and exec events, for this the final TID
of the exit event _must matches_ the PID and TID of exec / clone events
since we handle all these by the main thread.

The tetragonEvent.Process of the exit event is constructed either:

  1. When looking up the process by its PID from user space cache
     then we get the process that was pushed during exec or clone.

  2. Out of order exec event, and this is same as (1).

For all these cases the TID of the exit should be _automatically set_ to
the TID and PID of the exec/clone event. To achieve this we ensure that
clone and exec events have their TID also set to PID.

* clone events must store the TID in the process cache directly and
  we ensure that it is the PID as we generate only one event that
  is the thread leader.

* exec event we ensure and automatically set TID to PID too and insert it
  into the process cache as it is the main thread doing the execve call.

However from bpf side:
We also ensure that exit events on their own must send bpf PID == TID,
if not let's print a warning that is useful to bisect things.

This helps to assert the different variants of tetragon and that
sensors or bpf part did not change on behalf of user space and cache
handling, as again we handle only one main thread in the bpf side and
also in process cache, and we still did not complete all the per-thread
fields transition.

My sort of understanding is something like,
Exit events should have TID==PID and the {TID,PID} in the exit event must match the {TID,PID} pair from the exec event. They must match because its how we link the exit event to the exec event. If TID!=PID or the Exit{TID,PID} pair does not match an Exec{TID,PID} pair then there is a bug.

This patch adds extra logic to WARN on conditions where TID!=PID to aid debugging and catch this unexpected case. Typically this indicates a bug either in BPF or userspace caching logic. When this condition is encountered we attempt to correct it by setting the TID=PID.

Thanks @jrfastab I changed the commit log to what you suggested and also inside the code ;-)

My comments aside looks good to me. Few small cleanups and I think we can get this merged.

@olsajiri I did all you changes, plus last requests from @jrfastab too! so I will merge this one if it's green ;-)


Install borg using Pip

The borg packages in the alpine repos aren't up-to-date (except edge). Therefore, we should install borg manually (e.g. using pip) while building the docker container.

:tada: This issue has been resolved in version 1.5.0-rc.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Azure text-to-speech is not accessable in Windows 2012 r2 (again !!!)

The full description of bug is in issue #811
It was reemerged after a year just before the holidays season
Also for other developers, just be prepared. If you choose Azure service - you will be that unlucky person who spend the Christmas implementing workaround for the bug from Microsoft.

Same here!

@yulin-li Are you aware of any service issues related to this?

Sorry for the inconvenience, this is a service regression introduced recently. Service team is working on fixing. We will update here when it finished.

related https://github.com/Azure-Samples/Cognitive-Speech-TTS/issues/221

This bug were fixed and deployed.


Pip install failed.

The pip install failed, because the python dev kit was not installed on my system. Perhaps one could mention in the readme that the python dev kit is required, so the next person might not have the same problem:
The install of python dev kit for Ubuntu eg:
sudo apt-get install python3-dev

from this Stackoverflow answer.
The error message is not clear about why it fails, an intensive google search is needed to fix the error.

Thanks for the information. python3-dev is indeed required by nuscenes-devkit.


I should be on the list of developers and

@klauer :  I should be on the list of maintainers for projects for which I am the principal author.  I am absolutely certain that the epic mistakes in the pyepics feedstock must be avoided.
I will write to conda-forge maintainers if this mistake is continued.  I am not pleased and I am not kidding.

Thanks!
On Mon, May 17, 2021 at 1:23 PM Ken Lauer @.***> wrote:

Closed #3 https://github.com/conda-forge/xraydb-feedstock/issues/3 via
#4 https://github.com/conda-forge/xraydb-feedstock/pull/4.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/xraydb-feedstock/issues/3#event-4756202417,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKI6ZRMNCGERREGE3BXGLTOFNJJANCNFSM44LQ7TXQ
.

--
--Matt Newville<PHONE_NUMBER>


Datagram no recent network activity error

Don't know why Quic connection aways get disconnected after some seconds to minute with "no recent network activity error" report while using Datagram along with Stream.
Even the KeepAlivePeriod is not helpful it just add latency to keep dead connection for long
quic.Config{
   		MaxIdleTimeout:  1500,
   		KeepAlivePeriod: 1000,
   		EnableDatagrams: true,
   	}

How do you expect us to respond this? "Oh yes, with this config, it's expected that your QUIC connection drops!"?
If you want help with your issue, you'll need to give us enough information to actually see what's going on.

When a connection gets disconnected the other party waited till the default 30secs before getting noticing the other peer has disconnected when the MaxIdleTimeout is set to default or higher value.
I think no issue with that i think that is the logic. i leave the MaxIdleTimeout and KeepAlivePeriod to default values then using another method to track ungraceful disconnection, because the app need to tracks disconnected services at very low latency

When a connection gets disconnected the other party waited till the default 30secs before getting noticing the other peer has disconnected when the MaxIdleTimeout is set to default or higher value.

Not if you correctly configure Stateless Resets.


[bug]  | updates to demo page linked from ux.redhat.com

Describe the bug
There are a few inconsistencies that should be corrected in the demo/kitchen sink link that is linked from the footer component page on ux.redhat.com: https://ux.redhat.com/components/footer/demo/.
**These updates should be made to any documentation we have for the rh-footer. Potter is working on taking down the codepen demos and application demos, so this may be all that's remaining to be updated. The visuals/screenshots on ux.redhat.com seem to be updated to show the latest.

(This screenshot from ux.redhat.com shows the current, updated content and design to use as reference)
On the demo page, https://ux.redhat.com/components/footer/demo/, these updates should be made:

The list order in the global footer region should be updated to match the correct list order. "Cool Stuff Store" and "Diversity, equity, and inclusion" should be swopped.
Red Hat Summit should be added as a text link to the end of the list.  see #534 for reference
Should we remove the statement about the privacy statement update (*We’ve updated our privacy statement effective December 30, 202X.) since this isn't a default / out-of-the-box section of content?

Which Component?
rh-footer
Steps to reproduce

Go to https://ux.redhat.com/components/footer/
Click on "View this component in action" CTA

Expected behavior
The demo link is updated to reflect the latest design and content updates to the footer menu
Testing Instructions

Visit https://deploy-preview-491--red-hat-design-system.netlify.app/components/footer/demo/

[x] Verify that the links in the footer demo match those listed in the spreadsheet

Visit https://deploy-preview-491--red-hat-design-system.netlify.app/components/footer/demo/global-footer/

[x] Verify that the links in the footer demo match those listed in the spreadsheet

Visit https://github.com/RedHat-UX/red-hat-design-system/blob/fix/footer/rhdc-bugs/elements/rh-footer/README.md

[ ] Verify that the links contained in these instructions match those listed in this spreadsheet

Notes for Reviewers
The "Cookie Preferences" link is not displayed in the examples.  This is because of the was trustarc works.  I have a note in the readme that says the following:

Updated the docs on:

[x] ux.redhat.com
[x] removed rh-footer related Codepen.io exampes

@methomps This is ready for review.

@methomps My bad, I've updated the links to reflect the most recent change.
https://github.com/RedHat-UX/red-hat-design-system/blob/fix/footer/rhdc-bugs/elements/rh-footer/README.md

Buy online (Japan) should be removed
Red Hat Shares should have the updated url

[x] Rollup demo updated and screenshot updated https://github.com/heyMP/rollup-rhds-demo


feat: landing page

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
This PR:

implement Landing page flow
modify IconBox to make icon props optional

Fixes # (issue)
Screenshots/Screen Recording of Implementation
see Slack

The screenshots / implementation say see slack but I don't see anything there.


[Backport 2.12] Fixes password assignment for integTest when using remote cluster (#1091)

Backports #1091
(cherry picked from commit 027509e3c7ca25fd3f910d48dbd3456597d0a9e1)
CheckList:

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@r1walz @bowenlan-amzn not sure if CI checks need to be successful for merging this but, can you re-run failed checks. Seems like a connection issue.


Consider Supporting "Type Safe Enum" Pattern

Describe the feature
A "Type Safe Enum" is basically a ValueObject with slightly different usage pattern. You'd want to assign public static properties using a private constructor and a From factory method would only produce values generated.
[TypeSafeEnum]
public partial struct Meridiem
{
   public static Meridiem AM = new Meridiem("AM");
   public static Meridiem PM = new Meridiem("PM");
}

// ...

var meridiem = Meridiem.From("AM"); // OK
var meridiem = Meridiem.From("am"); // Failure

I realize this is not the focus of Vogen, but the generated code is so close between the two, that I think this might be a worthwhile addition.

An interesting idea - thank you @wekempf ! This kinda fits in with another change I'm thinking about: https://github.com/SteveDunn/Vogen/issues/221

Hi @wekempf - I'm now looking to create at a spin-off library more geared towards smart enums. If you have any ideas, I'd appreciate hearing them! https://github.com/SteveDunn/Intellenum/discussions
Thanks in advance.


⚠ MorethanTV has degraded performance

In db45a14, MorethanTV ($MTV) experienced degraded performance:

HTTP code: 502
Response time: 3871 ms

Resolved: MorethanTV performance has improved in 799c813 after 35 minutes.


Task :react-native-iap:compilePlayDebugKotlin FAILED

Please use the Discussion board if you want to get some help. Please use issues to report bugs.

Description

Expected Behavior

Screenshots

Envir

onment:

react-native-iap:
react-native:
Platforms (iOS, Android, emulator, simulator, device):

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Press '...'
Error '...' is shown

[Optional] Additional Context

YES!, I was having this issue a few minutes ago, I traced the last update of this library and I found out that the Kotlin version has changed due to the release of Google Play Billing Library 5.2 increase here
gradle.properties#L9 on last version 12.10.7
Apply this patch to your project
use patch-package
steps:

create folder named patches on the root of your RN project
under patches folder create a file react-native-iap+12.10.7.patch and pase code below
run command npx patch-package

diff --git a/node_modules/react-native-iap/android/gradle.properties b/node_modules/react-native-iap/android/gradle.properties
index e76bb7c..afc8cdd 100644
--- a/node_modules/react-native-iap/android/gradle.properties
+++ b/node_modules/react-native-iap/android/gradle.properties
@@ -6,7 +6,7 @@ RNIap_buildToolsVersion=30.0.2
 RNIap_ndkversion=21.4.7075529
 RNIap_playServicesVersion=18.1.0
 RNIap_amazonSdkVersion=3.0.3
-RNIap_playBillingSdkVersion=5.2.1
+RNIap_playBillingSdkVersion=5.1.0

 android.useAndroidX=true
 android.enableJetifier=true

Then try to build your project :'D

@ahmedrowaihi Brother I simply updated the kotlin version to "1.8.0" in project/build.gradle and it worked :)

ext {
buildToolsVersion = "33.0.0"
minSdkVersion = 21
compileSdkVersion = 33
targetSdkVersion = 33
// We use NDK 23 which has both M1 support and is the side-by-side NDK version from AGP.
ndkVersion = "23.1.7779620"
kotlinVersion = "1.8.0"
androidXAnnotation = "1.1.0"
androidXBrowser = "1.0.0"
}

Nice, project's React Native version is 0.69, and using expo modules with version 46..
So updating my kotlin version hits everywhere conflicting with others libs :'(