AGIC generating random listener names since last week.

Describe the bug
AGIC used to generate meaningful listener names such as "fl-<hostname>-<portno>-<public/privateip>". This is what everyone wants. but for the past two weeks AGIC has been generating random listener names such as "fl-5222170d53815f835f3b17c2c8904019". This behavior is seen exactly from the date Azure released a new feature for App gateway whose details can be found in the below link.
https://docs.microsoft.com/en-us/azure/application-gateway/multiple-site-overview
however this has so far not affected the base functioning of AGIC. Ingress yaml I'm using is very normal and not anything new which I'm posting below.
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
  name: myingress
  namespace: mynamespace
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/use-private-ip: "true"
spec:
  rules:
    - host: mydomain.com
      http:
        paths:
          - path: /
            backend:
              serviceName: my-service
              servicePort: 80

Kubernetes Version: 1.15.11

Hi @akshaysngupta ,
This naming changes between 1.0.1-rc1 and 1.0.1-rc2, in this commit https://github.com/Azure/application-gateway-kubernetes-ingress/commit/2105e9e7ca00c6e40aeb7d83636996865e49a8e5.
I suppose that the reason is that is written in the commit message. If wildcard is allowed in hostname, using the hostname in the listener name lost its importance.
Am I right?

@JorTurFer Well okay then atleast make listener name something more meaningful such as listerner1,listerner2, etc.... Meaningful names is definitely a lot better than some random number. I'm sure this is easily doable. I would suggest this format f1-listener<1>-portno-<public/private>

Hi @vishal8k ,
Sorry but I started my contributions in this repo 2 or 3 weeks ago, I don't have the context of the previous changes before.
Maybe @akshaysngupta or @3quanfeng  can give you more information about this and have more strong opinion about the listener's naming rules.

@vishal8k Thanks for the feedback. I think it will definitely make more sense to show readable names.
Please feel free to contribute to the repo if you want this earlier. We will try to take this up in some future sprint.

+1
I have 30 or so listeners x2 (http redirect and https) and very hard to find the correct one

+1
Just as Marcel wrote, my situation is similar. It is really difficult to debug issues with cryptic names.

Proposed solution: could we specify a name for the listener in the deployment file?

@MarcelT-NL I think it might be easier to name the listener using the older convention.
This is the place where listener name is generated.
https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/pkg/appgw/internaltypes.go#L146
Since AppGW started supporting multiple hostnames on a listener which may have a wild card (*, ?) which are not allowed in listener names, Naming logic will have to accommodate this fact.
https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/pkg/appgw/internaltypes.go#L64

@MarcelT-NL I think it might be easier to name the listener using the older convention.
@akshaysngupta Either way is fine, just as long as the names are readable and do not change for every release. E.g. adding a random number to the name would kill some of our scripts (like the random names do now).

But to make things more flexible to the future, a bespoke name as an annotation would be great!

Handling 100 listeners who's name is a GUID is guid or a random number makes troubleshooting more difficult.

FWIW: We gave up on this and switched to NGINX ingress.
It handles the rollout deployments much better too.


chore: Release 1.2.4

Fixed

Allow multiple calls to Action.setEntity and Action.setCollection
Check socket state before accessing it

Added

Updated File transport schema to latest spec
Return a new empty Param when asking for a missing one
Add return context for Service.action()
Implement action tags
Implement Api.hasVariable()

Closes #46

Coverage remained the same at 80.476% when pulling a37c090238bbdbe3c41a9c67430472b1d2e2c773 on orestes:master into 0b96f6a35c3fec3c4dc50b301a4098c588ae43d1 on kusanagi:master.

@fcastilloes when's a good time to review this? It'll take 5min tops.


support ks3 objstore 9-23

About ks3
The website links：https://www.ksyun.com/nv/product/KS3.html
Changes
add ks3 object driver
Verification
e2eTest pass

thanks. Seems another pr https://github.com/thanos-io/thanos/pull/4635 still in review，could you push the last git branch?
contribute guide: https://github.com/thanos-io/thanos/blob/main/CONTRIBUTING.md#pull-request-process


unable to calibrate with up to 6 lasers.

trying to align with up to 6 lasers as well as less produces garbage outputs when calibrating.
after IR area suddenly comes UV again?
Sometimes calibration asks for unknown and not set wavelengths?

Specifically what wavelengths are you attempting to calibrate with? Also can you please copy and paste the entire console output here as well.


FrameShader system ideas

Have a more direct description of the render-frame as code. Directly inline the required state in the frame-shader-description instead of having the state only "externally" in shaders.
Some ideas how it could look like, the following would execute as python and generate C++ source when executed during the build process:
if FrameShader(name='default'):
  RenderTarget(name='NormalDepthBuffer', relWidth=1.0, relHeight=1.0, format='RGBA8', depth='D24S8')
  RenderTarget(name='LightBuffer', relWidth=1.0, relHeight=1.0, format='RGBA8', sharedDepth='NormalDepthBuffer')

  if Pass(name='NormalDepthPass') :
    ApplyRenderTarget('NormalDepthBuffer')
    Clear(color=[1.0,1.0,1.0,1.0], depth=1.0, stencil=0)
    ColorMask(True, True, True, True)
    DepthMask(True)
    Enable(DepthTest)
    DepthFunc(LessEqual)
    Disable(Blend)
    DrawBatch(tag='Solid')
    DrawBatch(tag='AlphaTest')
  if Pass(name='LightPass') :
    ApplyRenderTarget('LightBuffer')
    DepthMask(False)
    DepthFunc(Equal)
    DrawGlobalLight()
    DepthFunc(Greater)
    DrawPointLights()
...

Closing, too old and no longer relevant.


Missing data source for management zone v2

Is your feature request related to a problem? Please describe.
I'm assigning a management zone by name to my metrics. Internally this get mapped to a management zone id, the consequence of which is that every time we run the terraform pipeline, there is some change to apply to map back to a management zone name.
The solution would be to use the data source and then reference the id of the zone in the metrics resource.
The data source only exists for the old management zones, which require a different token scope called ReadConfig (I'm guessing it's the old scope, the one I normally use is settings.read).
Describe the solution you'd like
The management zone v2 has a resource but no data source. Would it be possible to add this data source so we don't need two different scopes to handle management zones?
Describe alternatives you've considered
Add double scope (both ReadConfig and read.config)
Additional context
Add any other context or screenshots about the feature request here.

Hello @alsofr,
Can you provide an example for what you're applying?
Off the top of my head, when reading "assigning a management zone to a metric" I was thinking about dynatrace_calculated_service_metric. I just cannot reproduce any non-empty plans using that resource.
thanks,
Reinhard

HI @Dynatrace-Reinhard-Pilz , sure here is an example
resource "dynatrace_metric_events" "response_time" {
  for_each                   = var.enabled_features.metric_events ? toset(var.services) : []
  enabled                    = true
  event_entity_dimension_key = "dt.entity.service"
  summary                    = "[${var.team_name}] A metric event that checks response times for service ${each.key}"
  event_template {
    description = "[${var.team_name}] Response time is increasing for service ${each.key}"
    davis_merge = true
    event_type  = "SLOWDOWN"
    title       = "[${var.team_name}] Response time is increasing for service ${each.key}"
  }
  model_properties {
    type               = "STATIC_THRESHOLD"
    alert_condition    = "ABOVE"
    alert_on_no_data   = false
    dealerting_samples = 3
    samples            = 5
    violating_samples  = 3
    threshold = 300
  }
  query_definition {
    type            = "METRIC_SELECTOR"
    metric_selector = "builtin:service.request.response_time_service_aggregation:filter(in(\"dt.entity.service\",entitySelector(\"type(service),entityName.equals(${each.value})\"))):splitBy(\"dt.entity.service\"):percentile(95.0)"
    management_zone = var.management_zone
  }
}

This gets reapplied every time I run the terraform pipeline
      ~ query_definition {
          ~ management_zone = "12312312321321" -> "My management zone"
            # (3 unchanged attributes hidden)
        }

Which is why I would like to use this instead
data "management_zone_v2" "management_zone" {
  name = "My management zone"
}
...
resource "dynatrace_metric_events" "response_time" {
  ...
      management_zone = data.management_zone_v2.management_zone.id
}

Hello @alsofr,
If I'm not mistaken the existing datasource dynatrace_management_zone is all you need.
Take a look at the example below.
data "dynatrace_management_zone" "my_management_zone" {
  name = var.management_zone
}

resource "dynatrace_metric_events" "response_time" {
  for_each                   = var.enabled_features.metric_events ? toset(var.services) : []
  enabled                    = true
  event_entity_dimension_key = "dt.entity.service"
  summary                    = "[${var.team_name}] A metric event that checks response times for service ${each.key}"
  event_template {
    description = "[${var.team_name}] Response time is increasing for service ${each.key}"
    davis_merge = true
    event_type  = "SLOWDOWN"
    title       = "[${var.team_name}] Response time is increasing for service ${each.key}"
  }
  model_properties {
    type               = "STATIC_THRESHOLD"
    alert_condition    = "ABOVE"
    alert_on_no_data   = false
    dealerting_samples = 3
    samples            = 5
    violating_samples  = 3
    threshold          = 300
  }
  query_definition {
    type            = "METRIC_SELECTOR"
    metric_selector = "builtin:service.request.response_time_service_aggregation:filter(in(\"dt.entity.service\",entitySelector(\"type(service),entityName.equals(${each.value})\"))):splitBy(\"dt.entity.service\"):percentile(95.0)"
    management_zone = data.dynatrace_management_zone.my_management_zone.legacy_id
  }
}

For the next release of the provider I updated the documentation for the attribute management_zone. I guess he current documentation for that attribute
management_zone (String) Management zone

leaves plenty of room for confusion.

Just drop a comment in case you have further question and we will re-open this ticket.

You're correct, your API Token requires the permission Read Configuration (ReadConfig) for the data source dynatrace_management_zone.
The reason for that is related with this attribute legacy_id. It's a bit complicated to explain, but the data source is required to reach out to the Config V1 REST API in order correctly resolve that ID. Management Zones (and a couple of other resources) are available via Config V1 REST API and via Settings 2.0 REST API. To make matters even worse, other resources sometimes refer to management zones via the ID as known by Config V1 and sometimes refer to them as known by Settings 2.0. These IDs are however different.
That's essentially the origin of the attribute legacy_id - and it requires the Terraform Provider sometimes to take a couple of detours.
We're regularly  revisiting our data sources as soon as the need for that legacy_id doesn't exist anymore. For Management Zones it's unfortunately not the case yet.
Makes sense?

Thanks for the explanation. It's a bit unfortunate.
Is your proposal still to update the document to explain that the legacy_id should be provided when defining a metric event?
management_zone = data.dynatrace_management_zone.my_management_zone.legacy_id
What is confusing here is that it also accepts a management zone name, which is how I create the metric.
And since you are trying to get rid of the legacy id, maybe it makes sense that the API returns the Management zone name instead of the legacy id, that would actually solve my problem since there wouldn't be a difference anymore between the stored terraform state and what the API returns.

Hello @alsofr,
I just verified things, you should be good with using data.dynatrace_management_zone.my_management_zone.id with the current data source.
But I also have additional news. The upcoming release of the provider will introduced the data source dynatrace_management_zone_v2 (essentially what you were asking for). That one will only require settings.read as the scope for the API Token - the data source is using the Settings 2.0 API.
When using that new data source you WILL however have to use ``data.dynatrace_management_zone.my_management_zone.legacy_id`.

Looking forward to the new release then! Do you have an approximate release date yet by any chance?

We usually push out releases every Thursday. Sometimes we skip a week or two because we've found some show stoppers. Not the case this week so far, so you can expect to use the new data source by the end of the week.


Wrong documentation page is opened when clicking on ConfigFile.load()

Godot version
v4.0.alpha2.official [79077e6c1]
System information
Windows 10 64bit - Vulkan API 1.2.141 - GeForce GTX 1660 SUPER
Issue description
When you Ctrl + click on load in ConfigFile.load() you are redirected on GDScript documentation and not on ConfigFile documentation.
Only 4.0 is affected (tested on 4.0-dev.20210727 and 4.0-alpha2).
Steps to reproduce
From documentation:
var config = ConfigFile.new()
var err = config.load("user://scores.cfg")

Ctrl + left click on load
It open GDScript.load() documentation, not ConfigFile.load()

Minimal reproduction project
See 2 lines of code in "Steps to reproduce" section.

In method : https://github.com/godotengine/godot/blob/d3a6b6daaab4c8dfb7bdf35cc2fe2145ae6c22a1/modules/gdscript/gdscript_editor.cpp#L2969
Before parsing the file, it looks for method with the same name in base @GDScript builtin function :
https://github.com/godotengine/godot/blob/d3a6b6daaab4c8dfb7bdf35cc2fe2145ae6c22a1/modules/gdscript/gdscript_editor.cpp#L2986-L2991
As load method exists in @GDScript; it doesn't even check further.
_lookup_symbol_from_base() isn't call and correct class_name isn't found.
@GDScript method is used as a result.

I also note that # load() in a comment is Ctrl clickable and redirect into documentation. Is that an expected behavior ?

I also note that # load() in a comment is Ctrl clickable and redirect into documentation. Is that an expected behavior ? I don't find this behavior in major IDEs.

I'm neutral about it, as you may want to be able to click on it if the code was temporarily commented out. This can also be useful when referencing a function name within a comment.


Script cannot fetch Unity

I have this for a while and my game update as it should, but my friend cannot build it, got this error: "Unity version not found in archive".
I've tried it in new folder and get same error.

I'm getting this as well.

As a workaround, I was able to fix it by manually installing Unity 2021.3.40f1 through UnityHub.

same, thanks to @sepiatonal for a workaround


Pipes should fail after an exception

In my opinion, pipelines should fail when a Job's function raises an exception. For example, I imagine a Pipe with [Job(build_a_thing), Job(test_a_thing), Job(deploy_a_thing)]. If the test fails, we should never get to the deploy step. That's not now it works now, though:
from pypette import Pipe, Job

def func1():
    1/0

def func2():
    print('in func2')

pipe = Pipe('Simple pipe')
pipe.add_jobs([
    Job(func1),
    Job(func2),
])

pipe.run()

In this case, func2 will be executed even though func1 explodes. If the two run in parallel, then func2 should be allowed to finish (that is, don't say "oh, func1 died! time to kill all the other Jobs!"). But given this scenario:
def func3():
    print('in func3')

second_pipe = Pipe('Simple pipe')
second_pipe.add_jobs([
    Job(func1),
    Job(func2),
], run_in_parallel=True)
second_pipe.add_jobs([Job(func3)])

pipe.run()

I don't think func3 should ever be called because one of the Jobs in the first step of the pipeline failed.

@kstrauser: I have a different view to present here. I don't think it should fail. The reason I think so is one of the jobs might be a cleanup job which is quite needed in a lot of places. If failure of a stage compels the next stage to fail, we may end up in a situation where the cleanup jobs are not executed.
Having said that I believe we should have control over dependency and choice. So since some time I have been thinking of Job having an optional parameter called gate. This gate is a callable of some sort which returns a boolean which would decide whether the job needs to be executed or not.
j1 = Job(job1)
# Lets assume job1 pushes its state into a queue or some variable x.
def gate_method():
    flag = True
    # flag value is set to variable x or popped value from queue
    return flag
j2 = Job(job2, gate=gate_method)

When job 2 is being run it will check for value returned by gate_method and only if it is true will execute job2.
That will introduce the notion of dynamic decision in pipeline. What do you think?

That’s a really good point about cleanup jobs! I think the gate idea sounds wonderful, though. What if there was also a function like last_job_succeeded() that returns true if and only if the previous job completed without raising an exception. Perhaps that could even be the default value, like gate=last_job_succeeded, so that by default a failure stop execution but that it would be trivially easy to turn it off for cleanup jobs?

@kstrauser : Have added a bunch of new stuff including exception handling modes and dependency. Look at examples/ for the usage. Still testing a couple of things after which will release officially. Give it a whirl and let me know.

v0.0.9 should resolve this issue.

I'll take a look. Thanks for following up!


Add note about accessibility settings for macOS Mojave

Info: https://electronjs.org/docs/api/global-shortcut#globalshortcutregisteraccelerator-callback
#3 is not obvious to find

Or, is it better to add this notice in error message?

Thanks!


config: update directory_nodes

Updates config property directory_nodes as per https://github.com/JoinMarket-Org/joinmarket-clientserver/commit/ebdbac7e9855bedc2627fc5ad71630973901202d

Blocked till it becomes officially released with a new upstream version (probably v0.9.9).

Adhere to merged config changes:

https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1374
https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1422

Unblocked as v0.9.9 has been released.


Add tests for outline-accordion-panel

https://github.com/phase2/outline/tree/next/src/components/base/outline-accordion-panel

addressed by https://github.com/phase2/outline/pull/276


Overlay appear below a modal

Even with the biggest zIndex react loading Overlay keep appearing bellow a modal. what could be the sollution

Hey @pagolina! No worries about the slow response.
I'm glad you're using the react-loading-overlay-ts library!  That'll help me better understand the issue and assist you better. Thanks a bunch!

all i needed is how to set zindex using style props, so overlay will appear
above a modal and not behind as it is currently
On Tue, Sep 5, 2023 at 10:48 AM Achmad Kurnianto @.***>
wrote:

Hey @pagolina https://github.com/pagolina! No worries about the slow
response.
I'm glad you're using the react-loading-overlay-ts library!  That'll
help me better understand the issue and assist you better. Thanks a bunch!
—
Reply to this email directly, view it on GitHub
https://github.com/achmadk/react-loading-overlay-ts/issues/6#issuecomment-1706297445,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC3H42TTQSZKGWV6RWAR3RTXY3YPLANCNFSM6AAAAAA4GTRWIE
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Paago Samuel
Software Developer


Libp2p Standardization Update

Overview
Currently there are a few suggestions about how Ethereum 2 clients should implement the RPC in the context of libp2p as well as various encoding/decoding and formats. Specifically,  #1158 proposes segregating protocol Ids for each RPC request.
Furthermore, the current RPC specification has implementation issues (some of which are discussed in #1158) and does not primarily focus on libp2p implementations.
This PR consolidates #1158, #1100 and the RPC specification into a libp2p-specific context into libp2p_standardization.md. This document is aimed for client implementations to discuss and come to consensus on the final libp2p framework used in all implementations.
I'm also happy to help maintain this iterative specification.

Thank you for continuing the work on this, Age.
One small nitpick: I see the use of varint length prefixes as something specific to the negotiated encoding. The SSZ encoding requires it, but other serialization schemes may have a built-in record length information. I would create a dedicated section within the document detailing the SSZ encoding with examples of exchanged messages.

@zah - Thanks!
I agree. I'll add a dedicated example for SSZ encoding.
I've extracted the varint from the encoding as I envisaged it as part of the libp2p framework. By this, I mean that a requester always reads the varint, regardless of encoding, then proceeds to read the exact amount of bytes specified by the length. Once the bytes are read, the stream is closed and the arbitrary encoding is used to decode the received content. In retrospect, I think this train of thought is primarily based on how my implementation works, and if an encoding already defines a length-prefix, it may be duplicated in this scenario.
In the case of SSZ, SSZ-encoded objects do not have an overall length-prefix. Given the initial part of an SSZ-encoded object, a receiver does not have a way of telling how many more bytes will be sent by the sender. If we know the schema, and the object only has fixed-length fields, we could know the length of the payload, but this is in general not true. By length-prefixing the payload, a receiver can always know how many bytes need to read, and can reject the stream if the length is too large.
To be clear, is your suggestion, that we only allow encodings that apply some length prefix, and for each encoding implement in the libp2p logic to read that length and control the stream based on that encoding?

The document doesn't need to use too abstract terms at the moment, but the encoding is generally responsible for implementing a framing scheme that divides the stream into individual messages.
With SSZ in particular, we can say that the records are wrapped in a SSZ envelope which consist of adding a varint length prefix to the serialized bytes. I guess we need some feedback from the community in order to decide whether we want anything fancier such as including the length prefix only for variable-sized records. In our own implementation, it would be relatively easy to implement this.

@zah - Yep agree with everything you're saying.
My suggestion was to keep the framing static across all encodings. The reason for this, is that in the RPC implementation we are opening a stream sending a request and receiving a response then closing the stream. I figured a standard single frame which allows for all encodings to provide a max-size to be sent per stream would be applicable.
I'm happy to change this also and leave it up to the encoding and ensure all encodings allow us to size a single-framed response.

@zah - Agree with you and have updated to shift the length-prefix in the encoding.
I've added a small example with SSZ, let me know if you think it needs further details.
Things still to consider:

RPC_MAX_SIZE - what should be the maximum size of RPC payloads a client should accept
Gossipsub encoding - Gossipsub sends data via protobuf - but the data within this is up to us. Should we add an <Encoding> string to the gossipsub protocol id or specify a specific compression algorithm. I expect we want to compress the bytes rather than just send ssz-encoded objects over gossip

Gossipsub encoding - Gossipsub sends data via protobuf - but the data within this is up to us. Should we add an  string to the gossipsub protocol id or specify a specific compression algorithm. I expect we want to compress the bytes rather than just send ssz-encoded objects over gossip

We should certainly compress in gossipsub.
Options:

specify encoding via the gossip sub protocol id. gives us flexibility to add/change
specify it across the board singularly for gossipsub without using the protocol id

I'm not certain we should support a non-compressed encoding here, but specifying the compressed encoding via the protocol ID seems to be in the spirit of libp2p and gives us flexiblity in upgrading down the line if needed

A gossipsub encoding tag on the end of the protocol-id does seem in the spirit of libp2p.
The implementation could be tricky when supporting multiple encodings, depending on logic.
If Node1 supports encoding A, Node 2 supports A, B and node 3 supports B. I think there will be two subnets for A, and B and then should Node 2 route packets from the B subnet to A?
Whereas if we specify the encoding as some prefix in the data, all nodes would be on the same subnet but the message propagation properties of gossipsub would be modified depending on the percentage of nodes supporting the same protocol (as nodes that can't decode a block won't propagate it).
@raulk - Do you have thoughts on the best way to handle multiple encodings/compression for gossipsub?
I guess we just keep all nodes segregated on their own subnets based on the encodings they support and therefore a protocol id including encoding/compression makes sense?

Initially, I though that it would be a problem to specify the encoding in the Gossipsub topic name, but now I think it's reasonable. Each client will broadcast on a single topic using the preferred (e.g. latest) encoding. The client will also subscribe to all other topics/encodings that it can support.
Thus, when we upgrade the network, newer clients will see the traffic from older clients, but the older clients will quickly become unusable. This is only slightly different from having a single pre-determined topic where the encoding is specified in the message content. The pros and cons go like this:

With multiple topics, the clients will always get only messages relevant to them.
With a single topic, the client will know that it's out of date and it can notify the client operator somehow. This seems like a minor benefit, because there are other possible heuristics to detect this and the operator is not that likely to miss such major news such as an upcoming network upgrade.

@AgeManning

The reason for this, is that in the RPC implementation we are opening a stream sending a request and receiving a response then closing the stream.

Note that this is currently a bit costly in libp2p due to multistream 1.0 being chatty and stateless. multistream 2.0 will introduce 0-RTT negotiation by way of shared protocol tables and session resumption. So you'll be able to open streams with zero negotiation cost, as long as that protocol has been negotiated in that session/in the recent past with that peer.
I acknowledge that the Multistream 2.0 conversation in https://github.com/libp2p/specs/pull/95#discussion_r250016821 is arguably hard to follow, so @marten-seemann and I are putting together a document summarising the current thinking and technical design.

@AgeManning

@raulk - Do you have thoughts on the best way to handle multiple encodings/compression for gossipsub?

Let me think about this and discuss this with a bunch of people. Will get back to you soon.

@AgeManning

@raulk - Do you have thoughts on the best way to handle multiple encodings/compression for gossipsub?

A priori, the suggested approach of embedding the encoding and compression in the topic name appears reasonable. It enables selective consumption based on one's own capabilities. A few questions:

Are you intending for nodes in the network to "translate" between serialisation formats and compression algorithms?
How do you guarantee that a piece of data emitted by peer P in a specific encoding/compression combination can be effectively disseminated and understood by the entire network, despite the heterogeneity?
Or is the setup such that nodes can safely ignore messages they don't understand, yet the network can come to consensus?

Suggestion: may be worthwhile to develop a small-scale PoC (e.g. 100 nodes) and capture metrics on write amplification, memory usage, network bandwidth, and control message piggybacking efficiency. The libp2p core team can help with that.

@zah - I was originally considering an encoding in the protocol-id, but I agree it seems to make more sense having multiple topics segregating the encodings and a single protocol id.
@raulk

Are you intending for nodes in the network to "translate" between serialisation formats and compression algorithms?

This is of course a possibility, but in my opinion I don't think we should add this complexity. As @zah mentions, if the network upgrades to a new format, perhaps we have a mechanism that newer nodes can notify other nodes that their format is out of date. We may introduce nodes that do translation on older topics (so older clients can still receive blocks/attestations, albeit slower), but I don't think we should include it in this document.

How do you guarantee that a piece of data emitted by peer P in a specific encoding/compression combination can be effectively disseminated and understood by the entire network, despite the heterogeneity?

I guess we don't. In such an upgrade perhaps we stress that clients should all be updated. In reality, it is probably reasonable to have a few clients do the translation from topic/encoding to another. As long as one client does this translation, the data should propagate on both topics. We would have to test how quickly this works for consensus however. Perhaps others have more thoughts on this, @djrtwo?

Or is the setup such that nodes can safely ignore messages they don't understand, yet the network can come to consensus?

We are using gossipsub to propagate new blocks/attestations. It would not be good to lose these, consensus should still work depending on the % of validators split across topics. As above, technically this is solveable using translating nodes, whether we do this or require all clients to update is a separate question imo. But I don't see the design choice of using topics to separate encodings to be a prohibitive design choice when updating encodings.

Suggestion: may be worthwhile to develop a small-scale PoC (e.g. 100 nodes) and capture metrics on write amplification, memory usage, network bandwidth, and control message piggybacking efficiency. The libp2p core team can help with that.

Absolutely. This is something I'm interested in, and we (lighthouse) will be doing version's of this with our client, but more granular tests for specific libp2p protocols should also be done (we would like to help when/where we can, just may not have the time/manpower). Perhaps other parties are interested in this also?

We should certainly compress in gossipsub.

has anyone looked into the gains here, and algorithms? hashes compress poorly, not sure about the rest.

multiple topics segregating the encodings

+1 for multiple topics I think :) during transition periods it's also easy for clients to publish to multiple topics and keeping it separate at this level should allow the topic listening mechanisms to adapt to new-vs-old client ratios so there's a natural ramp-up/down as people upgrade. One thing necessary for this to work well: that topic subscription is used as a propagation filter meaning that not everyone receives all data on all topics - is this the case with libp2p? Also in this scenario, how is peer connectivity handled? If I'm not listening to a topic, can I publish to it?
ping @raulk

We opted for a forward-looking design, where we assume that multistream-select2 is adopted and the overhead is minimized.

as a thought experiment, let's say we opt for an optimal solution given the capabilities of today and use a single stream to not burden multiselect 1. What and how difficult would the steps be to change the protocol to use multiple streams later?

that topic subscription is used as a propagation filter meaning that not everyone receives all data on all topics - is this the case with libp2p?

Yes. Gossipsub/floodsub will only publish/propagate to node subscribed to the topic.

Also in this scenario, how is peer connectivity handled? If I'm not listening to a topic, can I publish to it?

Yes. This is the fanout peers in gossipsub.

as a thought experiment, let's say we opt for an optimal solution given the capabilities of today and use a single stream to not burden multiselect 1. What and how difficult would the steps be to change the protocol to use multiple streams later?

I think this may be implementation specific. I understand this is not too difficult for nimbus to change to. It's not too difficult for us (Lighthouse) to support either. In a single stream scenario we add back complications such as tracking of method_ids and request/response id's (unless we assume ordering).
I'm not opposed to this btw.

as a thought experiment, let's say we opt for an optimal solution given the capabilities of today and use a single stream to not burden multiselect 1. What and how difficult would the steps be to change the protocol to use multiple streams later?

I think this may be implementation specific. I understand this is not too difficult for nimbus to change to. It's not too difficult for us (Lighthouse) to support either. In a single stream scenario we add back complications such as tracking of method_ids and request/response id's (unless we assume ordering).
I'm not opposed to this btw.

From my experience, using a single stream requires quite a lot of additional code for tracking the requests that are in flight. In Nimbus, our codebase is structured in a way such that the low-level details of the protocol are abstracted away and there is shared high-level code that holds only the application logic needed for responding to a particular request. Here is an example:
https://github.com/status-im/nim-beacon-chain/blob/0a2d09e7fe3ff556201b569f19c11dd1bcf337df/beacon_chain/sync_protocol.nim#L270-L282
I implemented a single-stream back-end for this code only because the older spec required it. The multi-stream back-end is quite a bit simpler.

Leaving aside for a moment the code implications, how would the upgrade look from a network perspective of running clients? How.. difficult.. would a negotiated upgrade be?
From a code perspective, I read that as going from ms1 to ms2 is a simplification, thus trivial.

Well, it will be trivial only if you have planned for it. I shared our implementation approach as a tip.
Otherwise, migrating to a new protocol is not hard. The clients will just negotiate and select different stream types in libp2p.

We would have to test how quickly this works for consensus however. Perhaps others have more thoughts on this, @djrtwo?

I don't expect to have much mismatch on gossiping the high throughput items on validating nodes. Coordinating network upgrade (even if outside of hardfork) is certainly likely. To force everyone's hand, can just couple network upgrades at same time as hard fork so there isn't much option to not upgrade the software.

Should be noted that the additional latency in negotiating streams in ms1 for RPC calls will likely not hinder the protocol too much, especially in early deployments. The thing we would be most concerned about is latency wrt pubsub gossiping algs.

Forward compatibility principle described in EIP-8 is a very nice feature. It preserves network liveness during various updates by keeping ability of old peers to speak with upgraded ones.
In order to be forward compatible devp2p has a negotiation process that includes protocol version exchange. Peers are sending highest supported version to each other and starts communication with minimal version supported by both ends.
We could leverage Discovery v5 ENRs to get a list of capabilities supported by remote peer before establishing a connection with it. To get to that in our case nodes will need to advertise a couple of lists:

supported schema versions
supported encodings

Using this data node could build protocol id before it starts to communicate with remote peer. Node picks schema version and encoding according to its own preferences and remote peer capabilities.
For example, if encoding would be updated to e.g. xml we would have following scenario:

upgraded nodes start sending new ENRs with eth2_codecs: ssz, xml and xml takes preference over ssz
if remote peer supports xml then to establish connection upgraded node builds protocol id with new encoding /eth2/beacon_chain/rpc/1.0.0/hello/xml
otherwise, it uses old one /eth2/beacon_chain/rpc/1.0.0/hello/ssz

Schema version could be updated in the same fashion.
This approach has a drawback. There will be time gap between restarting a node and spreading updated ENRs across the network. In particular it means that two nodes will have to be restarted twice in order to start communicate with updated capabilities.
Possible workarounds to that:

exchange capabilities during negotiation process (Eth1 approach)
send updated ENR before establishing connection with remote peer

What others think about forward compatibility and this particular approach?

Using this data node could build protocol id before it starts to communicate with remote peer. Node picks schema version and encoding according to its own preferences and remote peer capabilities.

This is what multistream-select does for us. Given a set of encodings/versions of an RPC message, we can locally order these in preference when multistream negotiates which protocol to use.
For upgrading, we would preference newer protocols over older protocols.

I'm currently working with Raul and others to incorporate feedback given here and will be updating this in the coming days.

Closing in favor of #1328


Test Support

[x] Test case
[x] Travis CI Support
[x] ~Codecov Support~

Codecov has been removed for its unstablity to Rust project


Issues with the new interface

https://blue-thought-f63.notion.site/Bugs-Issues-3-10-a187adadb7bb4dca8fdfc699f68a4fab

Project
https://github.com/orgs/GeoGateway/projects/5/views/1?layout=board


Add TextAlignment to DataGridNumericUpDownColumn

Closes #3547

@ahmedflix25 your changes have been merged, thanks for your contribution 👍


Add CLI command for the injector

We need to create a command so that the contract injector is used from the CLI
It should be something like:  aeproject inject --ownable
Additional params like path may apply which can specify the path to the file we need to inject

cleaning up old issues. feel free to re-open if still relevant


Add the Adaptive Random Forest Classifier

This PR covers the Adaptive Random Forest classifier

Refactor ARF
Protects the pdf method against TypeError and OverflowError

Note: Tests in Travis are failing due to a corner case for the classification matrix. The fix to this issue is in the SRP PR.

Wonderful work, @jacobmontiel! I finished a first pass in the code, and it is looking pretty good!
I really enjoyed the restructuring you did in the internal organization of ARF. It is looking much simpler and clear now!
We are almost there :D
Please, let me know if you need any assistance.

Codecov Report

Merging #374 into the-merge will increase coverage by 0.44%.
The diff coverage is 86.84%.

@@              Coverage Diff              @@
##           the-merge     #374      +/-   ##
=============================================
+ Coverage      85.50%   85.95%   +0.44%
=============================================
  Files            270      272       +2
  Lines          12479    12742     +263
=============================================
+ Hits           10670    10952     +282
+ Misses          1809     1790      -19

Impacted Files
Coverage Δ

river/test_.py
95.91% <ø> (ø)

river/tree/arf_hoeffding_tree_regressor.py
78.78% <0.00%> (+45.45%)
:arrow_up:

river/ensemble/adaptive_random_forest.py
86.40% <86.40%> (ø)

river/ensemble/test_adaptive_random_forest.py
100.00% <100.00%> (ø)

river/proba/gaussian.py
92.30% <100.00%> (+1.13%)
:arrow_up:

river/tree/arf_hoeffding_tree_classifier.py
92.00% <100.00%> (+56.00%)
:arrow_up:

river/tree/_base_tree.py
66.41% <0.00%> (+0.74%)
:arrow_up:

river/utils/skmultiflow_utils.py
48.86% <0.00%> (+2.27%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

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

Thanks for all the nice work, @jacobmontiel! This PR brought a lot of improvements to the current structure.


LGSVL

We appreciate you go through Apollo documentations and search previous issues before creating an new one. If neither of the sources helped you with your issues, please report the issue using the following form. Please note missing info can delay the response time.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 18.04):
Apollo installed from (source or binary):
Apollo version (3.5, 5.0, 5.5, 6.0):
Output of apollo.sh config if on master branch:

Steps to reproduce the issue:

Please use bullet points and include as much details as possible:

Supporting materials (screenshots, command lines, code/script snippets):

打算用LGSVL与apollo做联合仿真并用LGSVL来绘制apollo支持的高精地图，请问大家有知道电脑配置需求吗？官网的配置说是NVIDIA 1080的显卡，但是这款显卡已经停售了，是只有这款显卡可以还是说配置比这个高就可以?谢谢大家

打算用LGSVL与apollo做联合仿真并用LGSVL来绘制apollo支持的高精地图，请问大家有知道电脑配置需求吗？官网的配置说是NVIDIA 1080的显卡，但是这款显卡已经停售了，是只有这款显卡可以还是说配置比这个高就可以?谢谢大家

You means which side, apollo or lgsvl?

You means which side, apollo or lgsvl?

你好，我是说lgsvl的配置要求

你好，我是说lgsvl的配置要求

Since lgsvl uses Unity engine, I think other types of graphics cards are also feasible, I suggest you go to lgsvl to ask some advice

Since lgsvl uses Unity engine, I think other types of graphics cards are also feasible, I suggest you go to lgsvl to ask some advice

这个高就可以?谢谢大家

Apollo  can support  GPU cards with compute capability ranging from 5.0 to 8.6 now. I am now running Apollo on an RTX 3090 machine.

这个高就可以?谢谢大家

Apollo  can support  GPU cards with compute capability ranging from 5.0 to 8.6 now. I am now running Apollo on an RTX 3090 machine.

这个高就可以？谢谢大家

Apollo现在可以支持GPU，其计算能力范围从5.0到8.6。我现在在RTX 3090机器上运行Apollo。

这个高就可以？谢谢大家

Apollo现在可以支持GPU，其计算能力范围从5.0到8.6。我现在在RTX 3090机器上运行Apollo。

您好，我的意思是lgsvl支持比1080高的显卡配置吗？官网说的是1080
------------------ 原始邮件 ------------------
发件人: "Liu<EMAIL_ADDRESS>发送时间: 2021年1月14日(星期四) 下午3:18
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [ApolloAuto/apollo] LGSVL (#13311)
这个高就可以?谢谢大家
Apollo  can support  GPU cards with compute capability ranging from 5.0 to 8.6 now. I am now running Apollo on an RTX 3090 machine.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

您好，我的意思是lgsvl支持比1080高的显卡配置吗？官网说的是1080
------------------ 原始邮件 ------------------
发件人: "Liu<EMAIL_ADDRESS>发送时间: 2021年1月14日(星期四) 下午3:18
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [ApolloAuto/apollo] LGSVL (#13311)
这个高就可以?谢谢大家
Apollo  can support  GPU cards with compute capability ranging from 5.0 to 8.6 now. I am now running Apollo on an RTX 3090 machine.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

您好，我的意思是lgsvl支持比1080高的显卡配置吗？官网说的是1080

Maybe you could ask this in LGSVL repo.

您好，我的意思是lgsvl支持比1080高的显卡配置吗？官网说的是1080

Maybe you could ask this in LGSVL repo.

Closed due to inactivity. If the problem persists, pls feel free to reopen it or create a new one and refer to it.


footer added at about us and also margin settled for about us section from top and bottom

footer added at about us and also margin settled for about us section from top and bottom
Accept this PR .

screenshot??

issue no??

Issue No 556


GraphNetwork model checkpointing method?

How do I checkpoint a GraphNetwork model? I tried using tf.train.Checkpoint but the GraphNetwork class doesn't seem to be trackable object. tf.train.Checkpoint throws the following exception:
ValueError: Checkpoint was expecting a trackable object (an object derived from TrackableBase), got <attention.GNGlobal object at 0x7f206c71a438>. If you believe this object should be trackable (i.e. it is part of the TensorFlow Python API and manages state), please open an issue.
Thanks!

See #83


Pass consentBoxes to the inquiry form

REQUIRES: https://github.com/parameter1/base-cms/pull/409

 Adding Inquiry Form to product pages and adding back in our custom consent language.


REstore credentials now in two steps

The alert design and text has been updated
Pin code is needed

Recovery phrase and file upload are now splited in two steps

@hawkbee1 you mean BackupCredential right?

@hawkbee1 Nevemind, I got your point


Maintainer.

So who is the maintainer of our group then? @Mosaddeq107 @sharmistharanit

I am the maintainer of the group.

okay, got you. thanks

okay, got you. thanks

What do you need, man? Please let us know.


v1.0.0 Crashes My Mac

Running OSX 10.9.3.  Downloaded and installed v1.0.0 today fine.  But when I run boot2docker for the first time, it brought up my terminal, a bunch of messages flew by, and my system literally crashed.  I am not sure where the log file is, but more than happy to provide it if someone points me in the right direction.
I have never installed docker before today.
Thanks,
Ben

Sorry, this repository is long-since deprecated in favor of Docker Toolbox (whose usage is now also discouraged in favor of Docker for Windows and Docker for Mac).


Update index state to 2020-10-01

description

[ ] Updating the index state to something more recent

checklist

[x] compiles (cabal v2-build or stack build)
[x] tests run successfully (cabal v2-test or stack test)
[ ] documentation added
[ ] link to an issue
[ ] add milestone (the current sprint)

bors r+


Separate methods for raw SQL that leverage interpolated strings

Currently the behavior is different if you call FromSql or ExecuteSqlCommand with an inline interpolated string (parameterization happens) or if you assign the interpolated string to a variable and then pass it to the method (the string is formatted with the arguments).
In some cases customers expect parameterization but it doesn't happen: #10080
In other cases customers expect parameterization not to happen, but it does happen: #10956
This is very confusing and hard to explain. Interpolated strings in C# were simply not designed in a way that works well with having two overloads of the same method in which one works with interpolated strings and the other one with a regular string.
I think we should separate the methods, but we can only do this in major release because it is a breaking change.
This would also imply removing the RawSqlString type.

Absolutely agree with this move. If it helps, I wrote up some more test cases on how this is confusing (and sometimes dangerous) when it first came up here: https://github.com/NickCraver/EFCoreInjectionSample/blob/master/Program.cs

@NickCraver thanks. We are going to try to address #10080 in the shorter term with a a Roslyn analyzer. I think we can probably leverage your tests as tests cases for the analyzer.
cc @anpete

And remove or modify the analyzer?

I believe modify. I haven’t thought through all the details but I believe it can still provide value on the string overload.

Please take into consideration cases like this:
var tablename = dbcontext.Model.FindEntityType(typeof(ABC)).Relational().TableName;
delete from {tableName} where a=123;
How to create a raw sql in such case? Is there currently any workaround?

I'm glad this is to be improved. One request is being able to opt-into raw strings when using the interpolated string arguments/methods, something like:
var tablename = dbcontext.Model.FindEntityType(typeof(ABC)).Relational().TableName;
$"select * from {Sql.Raw(tablename)} where date between {from} and {to}"

from and to would be parameterized and tablename would not. This idea could be reused if Sql.Raw returns an implementation of IRawSql and if something implements IRawSql then its IRawSql.Value will be inserted and not parameterized. Taken further, the above example could be shortened to the following C# if IRelationalEntityTypeAnnotations extends IRawSql which when evaluated would return a string like "[someSchema].[SomeTable]".
var table = dbcontext.Model.FindEntityType(typeof(ABC)).Relational();
$"select * from {table} where date between {from} and {to}"

IRelationalPropertyAnnotations could also extend IRawSql and its IRawSql.Value in this example could return "[date]":
var table = dbcontext.Model.FindEntityType(typeof(ABC)).Relational();
var column = dbcontext.Model.FindEntityType(typeof(ABC)).FindProperty("Date").Relational();
$"select * from {table} where {column} between {from} and {to}"

Implementations of IRawSql for entity types and properties would need to be specific to each database provider so that identifiers are properly escaped with brackets, double-quotes, back ticks, etc.

I would also suggest providing arguments that take an IEnumerable<FormattableStrings> to enable composing interpolated strings without losing parameterization. Here's a slightly contrived example:
public IQueryable<Post> PublishedPosts(FormattableString filter = null)
{
    return this.Posts.InterpolatedSql(new FormattableString[] {
        $"select * from dbo.Posts where Published = 1 and ",
        filter ?? $"1=1"
    });
}

You could also imagine building a List<FormattableString> and passing that in.
But perhaps there is a better way I am not thinking of.

Jumping in really late on this, as I just stumbled into this nuance of EF today. I personally would prefer your "plan (a)" as well. It would nudge developers who rely on the library into the right path. The current API is quite dangerous, as you can go from safe parameterization straight to dangerous concatenated SQL by a simple refactoring.
A suggestion on naming might be "FromUnsafeSql", to make it clear that anyone using that overload needs to be careful about its use, and possibly point out the SQL Injection dangers right in the XML comments (I'm surprised in 2019 that the majority of devs I run into still don't know what SQL Injection is, or why it can be dangerous).

@KeithJRome I'm not completely sure FromUnsafeSql would be accurate since certain uses of the string interpolation API can also be unsafe. I do think it is helpful to make people aware of the risk through naming conventions, if at all possible. FromUnsafeSql just seems like to strong of an assertion in the other direction. The security of your code very much depends on how you use each API and understanding that. That can't easily be summed up in a name.

@divega +1 for FromCodingHorrorSql or FromParameterizedSql if I'm being somewhat serious. I still think FromRawSql is the best name thus far. Although FromParameterizedSql might lead folks to read the intellisense docs in the if they don't know what parameterized means.

@jeremycook FromParameterizedSql is a cool name. I just don't know which version of the method it would be a better fit for :smile:

One pretty extreme option is to not have any method at all that accepts regular strings, under any name - this would force people to only specify raw SQL via interpolated strings. This would make it really difficult to introduce SQL injection, and it only makes life it a bit harder in scenarios where users compose SQL together.
Otherwise, +1 for removing the overload of FromSql(string) (leaving that name for interpolated only) and adding FromSqlUnsafe(string) - this should at least give users pause before using it.
@jeremycook

I'm not completely sure FromUnsafeSql would be accurate since certain uses of the string interpolation API can also be unsafe.

Can you be more specific/provide an example? It seems like a method accepting FormattableString should be as safe as reasonably possible, which is why it seems right to me to label the other one "unsafe"...

One possible objection to having Unsafe in the name is that it's associated with C# unsafe (i.e. pointers). There are also some places in the .NET API where the word "dangerous" is used in method names; this may be a bit extreme, but to be honest I'm leaning towards this kind alarmist naming in the context of SQL injection.

My thinking around the "unsafe" naming is that it conveys a sense of warning to the API consumer. Essentially letting them know that the training wheels are off if they choose that option, and they need to exercise additional caution.
There are indeed some cases where you don't want an interpolated string to automagically convert into parameterized SQL. Here is a perfect example (which is actually what led me to this discussion thread in the first place):
context.Database.ExecuteSqlCommandAsync($"set IDENTITY_INSERT {tableName} ON")
It looks like reasonable code, but in reality, that statement converts to "set IDENTITY_INSERT @p0 ON", which fails because the set statement doesn't play nice with parameters that identify db objects.
To be totally honest, I kind of feel that this API should not convert FormattableString to parameterized SQL at all. It is doing so in a way that isn't obvious, and which has real consequences - including behavior that breaks otherwise legitimate code such as the above example. We already could use parameterized SQL very explicitly and clearly, so this feature feels like mostly a gratuitous use of a technical capability. If anything, the overload which supports FormattableString should have been designed as its own signature, so we could opt-in when it makes sense. But alas, this can of worms is already open now.

@divega Would it be possible for you to bring an API proposal to the design meeting next week?

@roji I think you are right. I can't think of a use of FormattableString being unsafe, generating invalid SQL that will error, yes, but being unsafe, no. Below is what I was thinking would be a problem, but of course the entire sql parameter would get parameterized, and so my assumption was wrong.
var sql = $"SELECT * FROM dbo.Records WHERE Name = {name}";
// Safe but invalid SQL
Database.FromInterpolatedSql($"{sql} AND Id = {id}")
// And this won't compile
Database.FromInterpolatedSql(sql + $" AND Id = {id}")

To that end I am fine with UnsafeSql especially if debating RawSql vs UnsafeSql vs SomeOtherSql would some how prevent this change being made to the API. I'd rather see this change made because it will at least prevent erroneous use of string interpolation where you think you are safe but in fact nothing gets parameterized:
var sql = $"SELECT * FROM dbo.Records WHERE Name = {name}";
Database.FromSql(sql + $"AND Id = {id}")

Design meeting decision (short version):
FromRawSql & FromInterpolatedSql
ExecuteRawSql & ExecuteInterpolatedSql

To elaborate on what @smitpatel wrote above:
We discussed this extensively in the EF design meeting today. For a while I have been inclined to adopt option A, which would keep FromSql as the version that takes FormattableString and come up with a name that conveys danger for the version that works directly with strings.
But after reading many of the comments on this thread, I began to realize that this would not address a couple of important concerns:

What the interpolated string version of the method is doing is actually very special and can be pretty surprising if you come from the expectation that you are just using the language feature to build a string

There are actually many ways to use the version that works with plan strings safely. In other words, this version of the method is not really a more dangerous API than CommandText (for which there is an off-the-shelve fxcop rule) or similar APIs on Dapper. Things only became dangerous when we conflated the interpolated string version and the compiler could switch between the two versions without you realizing.

So, we agreed to go with option B:

Deprecate both flavors of the APIs
Come up with the new naming pattern. As @smitpatel mentioned FromRawSql, FromInterpolatedSql, ExecuteRawSql, ExecuteInterpolatedSql.

The (relatively) big disadvantage of this approach is that we can no longer use the simplest name, "FromSql".

I can't think of a use of FormattableString being unsafe, generating invalid SQL that will error, yes, but being unsafe, no

I just wanted to point out here for anyone else finding later: this isn't accurate...it's still unsafe. Strings are very dangerous and as long as they are in play anything that gets turned into a string in fair game for input exploitation. I added some ways this is exploitable in the repo at the start of the issue: https://github.com/NickCraver/EFCoreInjectionSample/blob/master/Program.cs

@NickCraver can you point to which example you are talking about here?
I think @jeremycook was referring to the method that only accepts FormattableString.
From the examples in https://github.com/NickCraver/EFCoreInjectionSample/blob/17fa99c2d1a46933755ba477f65090b6b4805e6d/Program.cs#L20-L50, I think the only one that would compile against such method is the first one. All the other ones use strings.
BTW, I am not pushing back on the fact that there is always going to be some way to do something unsafe with interpolated strings or without them. I just want to understand if you are referring to something that separating the methods doesn't address.

Agree with @divega, I'd be interested in seeing a case where a method accepting only a FormattableString could be used in an unsafe way. No casts are possible between string and FormattableString, you can't concatenate FormattableStrings... It basically seems like the only way to integrate user input is to go through parameterization, which is safe...

@NickCraver I can understand how future onlookers could misunderstand my point. So I reworded my comment, replacing "FormattableString" with "FromInterpolatedSql".

@jeremycook my apologies - you wrote FormattableString and my brain read it as IFormattableString even after a few passes. I completely agree on the concrete type: there's no way I can think of to break that approach. If we allowed the interface anywhere...oh yeah, lots of fun. Sorry about that!

Closing since this is now done and the break is documented.


fix: Use transform instead of margin for improved performance

What it solves
Uses css transform instead of margin to move the blocks around. This results in better performance because it only affects the composite layer instead of repainting the DOM (see https://web.dev/articles/rendering-performance?hl=en#the_pixel_pipeline).
How to test
Open the app and observe that your device is quiet and doesn't heat up anymore.

Love it, thanks!


Add adamsbridge RDL

TODO 'external mem' inside RDL needs to be translated into a register array.

The order of RDL files included does matter and the adamsbridge needs to be before caliptra_reg.rdl and after soc_ifc_reg.rdl...

These external mem blocks are actually register arrays in mldsa. However this unblocks https://github.com/chipsalliance/caliptra-sw/pull/1747


Syntax Error: var client = new CommunicationIdentityClient(ConnectionString); // should be var client = new CommunicationIdentityClient(connectionString);

[Enter feedback here]

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

ID: a29430c6-fd84-c423-db14-4f87853dc5d6
Version Independent ID: 99605c52-055e-8361-4540-2527fd0ad342
Content: Quickstart - Create and manage access tokens - An Azure Communication Services quickstart
Content Source: articles/communication-services/quickstarts/access-tokens.md
Service: azure-communication-services
GitHub Login: @tomaschladek
Microsoft Alias: tchladek

@ANKGITDEMOS That is correct, thank you for catching that error in the docs! I have submitted a PR to fix the issue, the change is merged internally and will go-live in the public docs shortly.


Update dependencies

Contains #1607, #1610, #1611, #1612, #1613.

Updated to include #1619.

This one will need merge conflict resolving, afterwards, we can merge

Rebased, and I've added two extra commits bumping the versions of tokio-util and jsonrpsee.


Receiving a CAN in response to an ACK messes up the retransmission

21:15:49.313 DRIVER » [Node 013] [REQ] [SendData]                                        [P: Normal]
                      │ transmitOptions: 0x25
                      │ callbackId:      118
                      └─[MultiChannelAssociationCCGet]
                          group id: 1
21:15:49.314 DRIVER   workOffSendQueue > skipping because a transaction is pending:
21:15:49.315 DRIVER » [Node 013] [REQ] [SendData]                                        [P: Normal]
                      │ transmitOptions: 0x25
                      │ callbackId:      118
                      └─[MultiChannelAssociationCCGet]
                          group id: 1
21:15:49.319 SERIAL « [ACK]                                                                   (0x06)
21:15:49.320 DRIVER   ACK received from controller for current transaction
21:15:49.320 SERIAL   The receive buffer is empty, waiting for the next chunk...
21:15:49.326 SERIAL « 0x0104011301e8                                                       (6 bytes)
21:15:49.328 DRIVER « [RES] [SendData]                                                [confirmation]
                        wasSent: true
21:15:49.327 SERIAL   Buffer := 0x0104011301e8                                             (6 bytes)
21:15:49.328 SERIAL » [ACK]                                                                   (0x06)
21:15:49.329 SERIAL   The receive buffer is empty, waiting for the next chunk...
21:15:49.332 DRIVER   CAN received - scheduling transmission attempt (2/3) in 100 ms...
21:15:49.331 SERIAL « [CAN]                                                                   (0x18)
21:15:49.332 SERIAL   The receive buffer is empty, waiting for the next chunk...
21:15:49.388 SERIAL « 0x01070013760000079a                                                 (9 bytes)
21:15:49.390 DRIVER « [REQ] [SendData]                                                [confirmation]
                        callbackId:     118
                        transmitStatus: OK
21:15:49.389 SERIAL   Buffer := 0x01070013760000079a                                       (9 bytes)
21:15:49.390 SERIAL » [ACK]                                                                   (0x06)
21:15:49.391 SERIAL   The receive buffer is empty, waiting for the next chunk...
21:15:49.391 DRIVER   ACK received from node for current transaction. RTT = 75.74 ms
21:15:49.433 DRIVER » [Node 013] [REQ] [SendData]                                      [attempt 2/3]
                      │ transmitOptions: 0x25
                      │ callbackId:      118
                      └─[MultiChannelAssociationCCGet]
                          group id: 1
21:15:49.434 SERIAL » 0x010a00130d038e0201257636                                          (12 bytes)
21:15:49.437 SERIAL « 0x010b0004000d058e0301070073                                        (13 bytes)
21:15:49.441 CNTRLR   [Node 013] [~] [Multi Channel Association] maxNodes[1]: 7 => 7      [internal]
21:15:49.443 DRIVER « [Node 013] [REQ] [ApplicationCommand]                                  [final]
                      └─[MultiChannelAssociationCCReport]
                          group id:           1
                          maximum # of nodes: 7
                          node ids:
                          endpoints:
21:15:49.438 SERIAL   Buffer := 0x010b0004000d058e0301070073                              (13 bytes)
21:15:49.438 SERIAL » [ACK]                                                                   (0x06)
21:15:49.444 SERIAL   The receive buffer is empty, waiting for the next chunk...
21:15:49.442 CNTRLR   [Node 013] [~] [Multi Channel Association] nodeIds[1]:  =>          [internal]
21:15:49.443 CNTRLR   [Node 013] [~] [Multi Channel Association] endpoints[1]:  =>        [internal]
21:15:49.444 DRIVER   no ACK received yet, remembering response
21:15:49.446 SERIAL « [CAN]                                                                   (0x18)
21:15:49.447 SERIAL   The receive buffer is empty, waiting for the next chunk...
21:15:49.446 DRIVER   CAN received - scheduling transmission attempt (3/3) in 1100 ms...
21:15:50.467 CNTRLR   [Node 013] Node 13 did not respond to the current transaction after 3 attempts
                      , it is presumed dead
21:15:50.468 DRIVER   resuming send queue
21:15:50.467 CNTRLR   [Node 013] The node is now dead.
21:15:50.469 CNTRLR   [Node 013] Interview attempt (1/5) failed, node is dead.

fixed by #902


Accessing page's content not as a component

Hey,
Nice work!
I'd like to calculate the reading time of a markdown page, for this I need access to the markdown content,
What would be the appropriate way to read the markdown content? currently using  await import(../${params.slug}.markdoc); as stated in the slug example produces .default which is a component and access to the frontmatter but not the content itself.
Thanks,
Asaf.

Hey 👋🏻
You can call the render() function on the components default, which will return an object containing the html, css and head. If you now strip the html of the HTML tags itself, you are left with only the text.
import.default.render() returns something like this:
{
   "html":"

Hello World

",
   "css":{
      "code":"",
      "map":null
   },
   "head":""
}

You could also import the component in its raw Markdoc form, doing import('../slug.markdoc?raw');.

Hey,
Invoking import.default.render() on the +page.ts causes TypeError: article.default.render is not a function
It looks like the load function is invoked twice, one in the backend and one time on the frontend (not sure why), in the second time the render function does not exist.

Running into the same issue 🤔 Not sure why it happens, must be a svelte thing.
My first thought would be to try an additional ?raw import and use the raw markdown for it.
During this week I'll also add support for SvelteKit data exports. That might make this whole thing alot easier 👍🏻

I think that the issue is more of a Svelte Kit issue with the imports. Closing this for now.