Clarify behavior of :tags and :metadata options on metadata function

This is an attempt at updating the docs to try to clarify the resulting behavior of the returned metadata function when :tags and :metadata are both set.
I found myself confused while working on handling aggregation with the map returned by passing the event metadata to the metadata function when both were set with different keys or :metadata was set to all or a function that returned a map with different keys (for instance - changing :repo to :db in a function). Since I would use the resulting map to identify unique time series to report, I feel users would be equally confused about how setting each option affects which tag:value results are produced in the end.
I couldn't think of a code change that would alleviate this aside from unifying the behavior under just the tags option and eliminating metadata as an option altogether. The more I work with it, the more I think an API change may be warranted here. If we want to have a broader discussion on a possible API change, I will create an issue.

Thanks @bryannaegele!
I am sorry but I am not quite sure what is the issue, which makes sense, since everything seems to be confusing. :D
From my understanding, :metadata controls which metadata is taken from the event, tags is always a subset of the metadata. Where am I off? How can this be confusing?
To be clear, I am not denying there is a confusion, I am rather trying to "see it".

That is what I expect, as well - a map of tags with values for the aggregations, the tags defining the subset to be used. :)
Let's make sure my understanding of the intended functionality matches yours.
Assumption: The metadata function is intended to generate the aggregations to be used as intended by the user. Passing the event metadata to the metadata function on the struct should return a map containing values from the event metadata mapped to keys to be used as tags for aggregation (this could be a point of misunderstanding).
This makes it very easy for users to understand when writing their definition and for reporters to handle. For the user - if I identify tags that are present in the event metadata my time series will be aggregated on those values. For the reporter - the combination of the event name + the map returned by the metadata function - {"event.name", %{repo: :users}} - identifies a unique time series to report.
Ecto Example
Let's say we have the following event metadata (abbreviated) for our example:
%{repo: :roles, source: :users, query: "raw query"}
Only tags set 👍
tags: [:repo], metadata: []
expected: %{repo: :roles}
actual: %{repo: :roles}
Tags and metadata match 👍
tags: [:repo], metadata: [:repo]
expected: %{repo: :roles}
actual: %{repo: :roles}
Tags is a subset of metadata 🤔
tags: [:repo], metadata: [:repo, :source]
expected: %{repo: :roles}
actual: %{repo: :roles, source: :users}
Metadata is set to all 🤔
tags: [:repo], metadata: :all
expected: %{repo: :roles}
actual: %{repo: :roles, source: :users, query: "raw query"}
Remapping event metadata to a different name (only way I could think of to do mapping) 👍
tags: [:db], metadata: fn meta -> %{db: meta.repo} end
expected: %{db: :roles}
actual: %{db: :roles}
Remapping with a tags subset 🤔
tags: [:db], metadata: fn meta -> %{db: meta.repo, source: meta.source} end
expected: %{db: :roles}
actual: %{db: :roles, source: :users}
I would expect (and maybe this is my misconception) that whatever is set out in tags defines the set of tags to aggregate on and that the metadata function would return a map of those keys which are present in the event metadata with their corresponding values. Simply put: the intersection of keys in :tags with the keys present in the metadata (original or remapped by function) should define the shape of the map returned by the metadata function.
The current behavior though is that the the metadata function is outputting returning that subset in some cases, but not in others. This difference in behavior is what I found confusing.
Along these lines, I do not understand the point of the metadata option except to remap event metadata to another shape if the tags are intended to define the metadata to aggregate on. What purpose does defining a list of metadata keys or the :all function by the user serve the reporter?
Hopefully this explains my thought process better. My head is a little cloudy today, so I hope this makes sense. :)

@bryannaegele I think the confusion seems to stem from

For the reporter - the combination of the event name + the map returned by the metadata function - {"event.name", %{repo: :users}} - identifies a unique time series to report.

While currently the true statement is

For the reporter - the combination of the event name + tags from the map returned by the metadata function - {"event.name", %{repo: :users}} - identifies a unique time series to report.

metadata, as you noticed, is used only to remap the event metadata, while tags suggest the reporter that metric values should be broken down by metadata values under these keys (or as you said it, to create a unique time series for each unique set of values under these key).
metadata function is not enough for the reporters, because they also need to take the metadata values under tag keys. When a reporter updates a metric, it should probably do something like
event_metadata |> metric.metadata.() |> Map.take(metric.tags)

Yes, precisely. But in the case where the user only provides tags, this is effectively what happens by using the :tags value for the :metadata value. If the reporter is still required to perform the subsetting from what is set in :tags (which is fine) then what value comes from accepting the list of keys or :all option?
The intention of :metadata is to remap event_metadata., therefore I propose we only accept a remapping function for the metadata option (default implementation of &(&1)). This makes the purpose of the :metadata option very explicit (to remap the event metadata), removes a potential user error case (providing a list of metadata keys which has a subset of tags keys). What do you think?

@bryannaegele if the user sets only tags, then this library should normalize and set those as the metadata. For the reporter, it doesn't matter, the logic should be always the same (i.e. fetch all metadata and tags are a subset of that).

@josevalim I understand @bryannaegele’s reasoning here - we always want to fetch the tags, regardless of what :metadata is set to. Hence, the only purpose of :metadata is to transform the event metadata to something else (like extracting a controller name from conn). In this case, it makes sense to enforce that :metadata is a function.

So the question is: why do we have metadata in the first place? Why not just have tags?
My understanding is that some APM tool would use the metadata as well as tags but pushing all metadata would be expensive, hence the option to choose a subset of the metadata. @binaryseed, any thoughts here? Would NewRelic use any sort of metadata?

Yes, exactly @arkgil. We know at the time of definition what the eventual shape of the event_metadata will be with no additional work by the reporter. This simplifies the API on both sides very nicely, imho.
If this is not done by Telemetry.Metrics it is left to the reporter to do additional wrapping and validation on their end since the reporter has no knowledge of what the metadata function is doing internally. If the function is going to be opaque to the reporter, we should make it predictable.
event_metadata |> metric.metadata.()

If we can agree that this is the way to go, I am happy to change this PR to implement the change.

Wait a second. If you are proposing that the metadata should always be a function or the reporters, then I pretty much agree with it, because that's how I thought it works today. :D

@josevalim exactly. There is definitely a user requirement of being able to remap keys to different names. :repo to :db could be an example. There may be organizational conventions that require a standardized set of tags to which they must conform. The question is if the metadata option is the proper place.

@josevalim today it is a function, but the users can also provide :all atom (which stands for identity function basically) or a list of keys (which is Map.take(...)).
@bryannaegele's concern is that today a user may provide a [:controller] metadata and [:controller, :action] tags, which is very confusing, because tags are supposed to be a subset of metadata.
But since the only useful scenario for :metadata option is to transform the event metadata before the tags are extracted from it, then we can drop the option to set :metadata as :all or list of keys altogether, and enforce that it is always a function. This way it's clear that its purpose is to apply some last-minute transformations to event metadata.

So maybe we should just decouple tags from metadata altogether. Perhaps even remove :metadata and make :tags have the same API that metadata has today.

the only useful scenario for :metadata option is to transform the event metadata before the tags are extracted from it, then we can drop the option to set :metadata as :all or list of keys altogether, and enforce that it is always a function.

We can also keep the default behavior we have now of creating a function that uses the tags option as default. The reporter just needs to execute the function to get the user's desired aggregations. Very simple.

@josevalim that's not possible, :tags needs to be a known list of keys - for example, Prometheus requires this information when defining the metric.

The reporter just needs to execute the function to get the user's desired aggregations. Very simple.

I think this is already what is happening today: https://github.com/arkgil/telemetry_metrics_statsd/blob/master/lib/telemetry_metrics_statsd/event_handler.ex#L28.

But anyway, I like the idea of enforcing the :metadata to be a function. This way it's clear what is its purpose. Although we might want to rename the option

:+1: for making the metadata default to :all internally and always be a function from the user perspective. It is the simplest approach for now, we can relax it later if necessary.

So maybe we should just decouple tags from metadata altogether. Perhaps even remove :metadata and make :tags have the same API that metadata has today.

We still need to allow the user to remap metadata keys. I'm fine with keeping it under this option or creating an explicit one.
Here's my implementation proposal:
@spec metadata_spec_to_function(tags()) ::
        (:telemetry.event_metadata() -> :telemetry.event_metadata())
defp metadata_spec_to_function([]), do: fn _ -> %{} end
defp metadata_spec_to_function(keys) when is_list(keys), do: &Map.take(&1, keys)
defp metadata_spec_to_function(fun), do: fun

For NewRelic, we'll generally be doing 2 types things with an event:

Aggregating the metric, using tags to determine the dimensions of the metric

db.query.latency host=example.net controller=UserController

Possibly reporting a Trace event, including all relevant metadata (subject to sampling)

{
  type: "db.query"
  latency: 123
  host: "example.net"
  controller: "UserController"
  query: "SELECT * FROM users"
  account_id: 456
}

👍 for making the metadata default to :all internally and always be a function from the user perspective. It is the simplest approach for now, we can relax it later if necessary.

I propose it to return an %{} or even moving this to a keyword list [] by default. Using :all would result in default aggregations on things like :query in ecto which would be really bad. I would say aggregations should be explicitly opted into.
@tsloughter do you have any thoughts on this discussion?

Possibly reporting a Trace event, including all relevant metadata (subject to sampling)

Shouldn't this use case be done outside of Metrics definitions though? I've been doing something similar in other code for logging slow queries but I do that as a separate handler outside the context of metrics reporting.

I believe tags (ie: dimensions of a metric) are a first class part of the puzzle.
I suggested previously this taxonomy https://github.com/beam-telemetry/telemetry_metrics/issues/21#issuecomment-455813904 :

event (name)
measurements (map of values)
tags (dimensions for aggregating)
info (metadata, extra details about the event)

I suggested previously this taxonomy
I think this is where we're at now with with the api change to :telemetry core, with info in your proposal being the event_metadata still, so that is good. The question now is to the behavior of the generated metadata function on the metric definition and metadata:tags mapping.

Shouldn't this use case be done outside of Metrics definitions though?

Perhaps? I hadn't considered that.. Upon first thought it seems like it'd make sense..
As long as the reporter can easily determine the proper tags to aggregate upon based on the metric definition, I'm not sure I see a need to make changes to the telemetry core structure

Using :all would result in default aggregations on things like :query in ecto which would be really bad.

@bryannaegele by :all, I mean that all metadata will be available for tags but we will only send the fields listed in :tags, because as @arkgil said, those fields have to be defined upfront.
In other words, we will limit :metadata to only be a function and the goal is to transform it before we select certain tags out of it. If we need to include more data, we will either include a trace thing like @binaryseed mentioned or an explicit :infofield. I don't think we have to worry about it right now.

Trying to read through this and yea, I don't even know why there is both :metadata and :tags :).

all metadata will be available for tags

Hmm. I believe this is already the case since we get the metadata unadulterated from the event in our handler, correct? Metrics definitions will not change that case since it doesn't change the behavior of telemetry itself, so the purpose of the metadata function should be to have a single function created at definition by Metrics which will have the tags mapped to the values. If no tags are defined and no function is provided, we can assume for the purposes of metrics reporting that nothing should be returned by the metadata function.
I do not think tracing concerns should be mixed with this library. If we want a standard definition for tracing or APM, I would propose we do that in another library and try to conform to OpenTrace or something of that nature. I started down this road in one of our applications for slow query logging (which was convenient) but the mixing of concerns wasn't ideal. A separate handler was more appropriate.

I should clarify my comments a little... It makes sense to me that the metric definition could drop :metadata and only concern itself with selecting which values are to be treated as :tags
I was expressing that New Relic would want to use all the metadata in the emitted event itself, but I don't see a need for the :metadata spec on the metric definition...

Just to put everyone on the same page, I will describe the requirements:

tags MUST be a list of atoms because some systems require the tags to be specified upfront.

Therefore, if you want a tag value to be computed dynamically, this dynamic value has to be computed separately.

Per the above, we need two options. Today, those options are tags and metadata. tags is option 1 and is pretty much self-explanatory, but we need the name for the other option which has, as its main goal, to compute the value for each tag.

Maybe the second option should be just called :tag_values? This way it's quite self-explanatory, although the name doesn't suggest that it's a function.

@josevalim we're on the same page. It's just a matter of how to accomplish 2 :)

We know at definition what the tags are, so we're covered there. No change.
To compute the values for the tags we know two things are required: which properties of the event_metadata to take and if any transformation must be done.

If we know that the tag atoms are keys on the metadata (whether they are present on the raw event or after a transformation in a custom function), then we get this all at once at definition time.
I am proposing no changes to the struct itself, only the behavior of the metadata function, which should probably be renamed. Perhaps @arkgil's suggestion or something similar. If you refer back up to my examples above, you can see an example of a user-defined remapping function and proposed behavior.

:tag_values - a function that receives the metadata and returns a map
with the tags as keys and their respective values. Defaults to returning
the metadata itself.

Sounds good to me.
José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

:tag_values - a function that receives the metadata and returns a map
with the tags as keys and their respective values. Defaults to returning the metadata itself.

Just to make sure we're on the same page, does this clarification work for you?
Defaults to returning keys defined in ':tags' and their respective values from the metadata itself.

@bryannaegele I think this clarification is not necessary - since :tag_values can be an arbitrary function, reporters will need to do
metadata |> metric.tag_values.() |> Enum.take(metric.tags)

anyway. So by default it might return all metadata just as well.

I can live with that. :)
I'll make the necessary changes and update the PR.

I have updated the PR to remove the :metadata option and add the :tag_values option.
This feels like a good solution. Thanks for talking this through!  😃

Gonna close and reopen to trigger CI

Codecov Report

Merging #26 into master will increase coverage by 4.01%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master     #26      +/-   ##
=========================================
+ Coverage   94.28%   98.3%   +4.01%
=========================================
  Files           1       1
  Lines          70      59      -11
=========================================
- Hits           66      58       -8
+ Misses          4       1       -3

Flag
Coverage Δ

#1_5_otp18
98.3% <100%> (+4.01%)
:arrow_up:

#1_5_otp20
98.3% <100%> (+4.01%)
:arrow_up:

#1_8_otp19
98.3% <100%> (+4.01%)
:arrow_up:

#1_8_otp21
98.3% <100%> (+4.01%)
:arrow_up:

Impacted Files
Coverage Δ

lib/telemetry_metrics.ex
98.3% <100%> (+4.01%)
:arrow_up:

Continue to review full report at Codecov.

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

Thanks @bryannaegele! 💛💛💛 (Am I doing this hearts thing right?)


Implementing the same thing with different markets, indices or stocks

The same code can be implemented with different stocks exchange of the world or different pairs of stocks

Hi! I would be interested in implementing the same code with the NY stock exchange. I can get started on trying to implement that

Yeah That's good, You can start implementing  it using NY stock exchange.If you have any queries,Please feel free to ask

I implemented your code with banking stocks in the New York Stock Exchange. I just created a separate jupyter notebook for the NYSE stocks. I can submit a pull request to add the new notebook
Your project is really interesting! I was thinking it would be fun to test it out with some different sector stocks too and maybe play around with the trade signal threshold too.

That's good, Please submit the pull request of it by creating a new folder of NYSE, and I will merge it. Talking about this project, It also fascinating for me.Yeah, your idea to test it out with some different sector stocks too is also a good idea to work on .Thanks again for working on this project. If you have any queries, please feel free to ask.


Added the logic for Japannese search pages for description limiting t…

…o 1 line
Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after), along with a short summary of changes:
#537
Fixes #537
Changelog:
Please enter each change as a new bullet point
Test URLs:

Original: https://www.sunstar.com/jp/search?s=従事者
Before: https://main--sunstar--hlxsites.hlx.page/jp/search?s=従事者
After: https://issue537-search-jp-pages--sunstar--hlxsites.hlx.page/jp/search?s=従事者

Library

[ ] New Blocks introduced in this PR
If yes, please provide details below
Block Name : For e.g. cards

[ ] Documented in sidekick library

[ ] New variations introduced in this PR
Variation Name :  For e.g. cards (grid)

[ ] Documented in sidekick library

[ ] New mixins introduced in this PR
Mixin Name :  For e.g. compact, white

[ ] Documented in sidekick library

Hello it looks good to me. Thanks.


Aquarea Zone 1 climate max temperatur

Currently Aquarea Zone 1 climate max temperature is 25'C. As it is temperature of water going to underfloor heating, this setting is too low. It should be max 45'C
This also is relevant to Aquarea Zone 2 climate, but in my setup zone 2 is not used

https://github.com/kamaradclimber/heishamon-homeassistant/releases/tag/0.9.9 should help.
Thanks for the report

see also #57


Update permissions required in subscription

Missing required permissions at subscription level. This is specially important when the workspace is in a subscription (owned by security team) and the monitored subscription is different (owned by a department team).
If the permission is missing, this error is produced:
Failed to connect 'Dev subscription' to Activity logs. Please verify you have access to this subscription. Error: The client<EMAIL_ADDRESS>with object id 'aabf66b7-6638-485b-817c-ff30809a4243' has permission to perform action 'Microsoft.OperationalInsights/workspaces/datasources/write' on scope '/subscriptions/a65f6a6c-a0a7-49c3-91a9-960b74a442c1/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/myLA/datasources/a65f6a6ca0a749c391a9960b74a442c1'; however, it does not have permission to perform action 'read' on the linked scope(s) '/subscriptions/e35f6a6c-a0a7-49c3-91a9-960b74a442c1/providers/microsoft.insights/eventtypes/management' or the linked scope(s) are invalid.

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

@smed1na : I have edited the document in accordance with your proposal.  Thank you for your contribution!

#please-close


Path condition per step

Run a step only if the git changeset contains files from the paths defined for a given step.

General support added by #174 and #235


HackerEarth Website Clone

Description
Hii I'm a GSSoc22 contributor and I'm willing to make a pull request in this repository on my project which is Clone Of Hacker Earth Website
Stack:

[x] Html
[x] CSS
[x] JavaScript
[x] ReactJS

Code of Conduct

[X] I follow Contributing Guidelines of this project.

Assigned u @SupriyaGembali


Change u₀ to u0

Related to https://github.com/SciML/ReactionNetworkImporters.jl/issues/104
This is highly breaking though.

If we want to add this there needs to be an overload so the old notation works and returns u0 too. Then this isn’t breaking anything.

Is that possible (without simultaneously supporting both fields)? I am only familiar with overloads for functions, so would be unsure how to do this.

See getproperty and setproperty.

But both u₀ and u0 which are given to these would have the same type (Symbol). Or you mean create new version of these functions on ParsedReactionNetwork that first check if the input is u₀, and if so calls it again with input u0?

Updated. These overloads added:
# Ensures that `prnbng.u₀` works.
function Base.getproperty(prnbng::ParsedReactionNetwork, name::Symbol)
    if name === :u₀
        return getfield(prnbng, :u0)
    else
        return getfield(prnbng, name)
    end
end

# Ensures that `prnbng.u₀ = ...` works.
function Base.setproperty!(prnbng::ParsedReactionNetwork, name::Symbol, x)
    if name === :u₀
        return setfield!(prnbng, :u0, x)
    else
        return setfield!(prnbng, name, x)
    end
end

Given that parsed reaction networks are immutable, I don;t think the other one is needed though?
I have also added a couple of tests in the tests file to check that (for some loaded network)
@test isequal(prnbng.u0, prnbng.u₀)

This one should be ready now.


Pagination for Track Requests

Issue Addressed
This PR makes significant progress on #858 .
Description
We move Track Requests filter, search, and sort logic from the frontend to the backend.  In the process, we introduce a new table study_request_items as a combined index of bulk and non-bulk requests, and integrate upsert / delete hooks into StudyRequestDAO and StudyRequestBulkDAO to ensure study_request_items is kept up-to-date with changes to study_requests and study_requests_bulk.
To address location searching, we also switch from the old MidblockDescription.get approach to one backed by location_search.centreline, which uses a port of MidblockDescription.get to pre-populate midblock names.  CentrelineDAO is also updated to use this, and we get rid of the JavaScript MidblockDescription module.
Finally, we add a new script generate-study-requests.js to generate a bunch of test requests at once, making it easier to test this functionality out.
Tests
Tested filter, search, sort operations in frontend on a set of 1000 test requests generated via generate-study-requests.js.  Tested study_request_items hook integration by running generate-study-requests.js, which in turn runs these hooks.  Still need to add database tests for StudyRequestItemDAO.

Note that these are all failing test coverage checks on lib/db (internal only) right now.  (That's fine; we just have to make sure we add tests in a follow-up PR.)


Bind PhysicsServer*D::body_set_state_sync_callback

Currently if you want to implement your own RigidBody*D-like physics nodes from the script side of things, whether that's GDScript, C#, C++, Rust or any other scripting language, you're forced to hack the state synchronization (i.e. pulling the latest state from the physics server) by using the callback passed to body_set_force_integration_callback, which can sort of serve the same purpose as the callback passed to body_set_state_sync_callback.
This is a hack though, and body_set_state_sync_callback should rightfully be exposed/bound, so this PR does exactly that.

@akien-mga Done.

Thanks!


About: who we are page getting start link does not work

The link at the bottom of the page, entitled "Getting started with CHIPS Alliance" gives a '404' error, page not there.

Also the 'becoming members' and 'our projects link yield the same error

fixed


Archive

Issue #25
Able to archive text channels into a long text log. Attachments are saved into the archive as well, and the .png filetype is appended for images. Other types of media such as gifs may need special attention to reconstruct but the content_type information is stored in the text log.
The bot is unable to differentiate between like-named channels from different servers (and server names lack the same filepath-safe validation that channel names have), so care should be taken to not overwrite another server's archive.

Great job, me


Pull-requests created by github api aren't triggering CI builds

e.g. gha-update-js run https://github.com/silverstripe/silverstripe-mfa/pull/505
There was no CI build automatically triggered
Likely the same issue seen in gha-merge-up where a CI build wasn't triggered after merging up a branch

Trigger using the GITHUB_TOKEN will prevent further actions from being triggered
https://github.com/peter-evans/create-pull-request/issues/48#issuecomment-536204092
It's an intention design decision from github to prevent infinite loop situations
https://github.com/peter-evans/create-pull-request/issues/48#issuecomment-537478081

On this pull-request https://github.com/silverstripe/silverstripe-totp-authenticator/pull/132 - Using the UI I manually triggering a CI build against the pull-request branch https://github.com/silverstripe/silverstripe-totp-authenticator/actions/runs/5884330658 - however the builds don't show up automatically above the merge button
Possibly we could add in a link to the CI build with some all caps text saying CHECK CI BUILD HERE BEFORE MERGING and some more text explaining why the workaround exists

On this pull-request https://github.com/silverstripe/silverstripe-tagfield/pull/254 - I closed it first, then started the CI build and then re-opened the pull-requests - this time builds did show up automatically
While this is good, in this context however both the pull-request and the CI is created using API calls so there's no guarantee about which ordered they'll get created, meaning that probably sometimes the builds would show and other times they wouldn't

I did a third test on this pull-request https://github.com/silverstripe/silverstripe-login-forms/pull/150 - I manually triggered the ci build, then I closed and re-opened the pull-request.  The builds showed up automatically.  This implies we can provide instructions on the pull-request to close and re-open the pull-request to get the builds to show

Reassigned to @emteknetnz to check (if there's an easy way to do so) that the merged PRs have resolved the problem.

Have manually updated the v1 tag. Going forward this should be solved by https://github.com/silverstripe/.github/issues/94


Baseline Implementation Section Style Guide

💡 Summary
Came up a style guide for baseline implementation section
Motivation and context
Inconsistency for implementation section for baseline, recommended to came up with a style guide to keep the baseline language consistent
Implementation notes
Acceptance criteria
How do we know when this work is done?

[ ] came up with style guide for the Implementation Section

For consistency across the baseline products the style guide for the implementation will be the following:

[ ] One implementation section per policy group
[ ] Each policy will have its own implementation steps
[ ] Each policy implementation will begin with the Policy ID followed by ", to [VERB] _____ follow the instructions below:"
EXAMPLE: MS.AAD.1.1v1, to block legacy authentication follow the instructions below:

NOTE: the above checklist will be added to #212 as a final check to ensure the implementation sections are consistent
With the following updates the implementation section, it will look like the following:
Policies
MS.PRODUCT.1.1v1
Blah blah blah
MS.PRODUCT.1.2v1
Blah blah blah
MS.PRODUCT.1.3v1
blah blah blah
Implementation
MS.PRODUCT.1.1v1, to block XXX follow the instructions below:
MS.PRODUCT.1.2v1, to enable XXX follow the instructions below:
MS.PRODUCT.1.3v1, to restrict XXX follow the instructions below:

Tagging the baselines POCs below for awareness on the way forward in regards to the the implementation section:
@Dylan-MITRE @schrolla @tkol2022 @adhilto @buidav @amart241 @nanda-katikaneni @ssatyapal123 @Sloane4

Will the implementation sections still be moved to a wiki? Or will they be in-line in the baseline docs themselves?

@adhilto current plan is still to migrate them to a wiki but having one implementation section per policy group will help with that lift and shift and minimize human and structural errors.


sensor creates new free channel

Hi.
Me again. I want to trigger a notification every time de free licenses drop below a certain point. But everytime the free amount changes, it creates a new channel. Can the script be changed so the channels stay the same?

Hey, you should be able to just change the channel limit and it should not create any new channels after that.
Could you please recreate the sensor an try it again.
If it's not working could you make a screenshot and show the parameter you use.


radar42585636-demangling requirements for swift-5.0-branch

Cherry picks from the upstream LLVM required for https://github.com/apple/swift-lldb/pull/812
Thanks @JDevlieghere for pointing out that we need this also on the swift-5.0-branch

Thanks, I will delay till https://github.com/apple/swift-lldb/pull/812 is ready.


Crackling sound after a non-looped OGG file stops playing.

Godot version:
3.0 build 0ead6b3.
OS/device including version:
Ubuntu Linux 17.10 64-bit.
Issue description:
I've noticed that a non-looped OGG file, when it stops, results in noticeable crackling sounds that carry on indefinitely.
Minimal reproduction project:
https://www.dropbox.com/s/prlc2t8kqqdjcol/14866_demonstrator.webm?dl=0 is a video of the issue.
https://www.dropbox.com/s/ag6wav8m6fbuunh/14866_demonstrator.7z?dl=0 is a project with the issue.

I can reproduce the issue in 3c7f06a0e on Mageia 6 64-bit (pulseaudio driver).

Can anyone confirm this on Mac or Windows, or Linux not using Pulseaudio?


Add distinct aggregate tests to sqllogictest

Which issue does this PR close?

Relates to #2411, #2410, #2408
Rationale for this change

Datafusion already supports these use cases. Just locking them into the test suite
What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

FYI we don't support this
> select median(distinct "1"), median("1") from '/home/jeffrey/Downloads/data.csv';
This feature is not implemented: MEDIAN(DISTINCT) aggregations are not available

But maybe can tackle as separate issue from those original issues :thinking:

FYI we don't support this
> select median(distinct "1"), median("1") from '/home/jeffrey/Downloads/data.csv';
This feature is not implemented: MEDIAN(DISTINCT) aggregations are not available

But maybe can tackle as separate issue from those original issues 🤔
See #10159 (comment)

If it hasn't been implemented yet, we should add them to sqllogictest and return an error first.

Done. Also I'll keep the original issues open.

Thanks @Jefffrey  and @Weijun-H and @jayzhan211  🚀


CatalogTypes should not use ugly reflection hacks

Currently all CatalogTypes' catalogs statically set everything to null, and have the implementation access check suppressing reflection on a static final field and add in the objects.
This is very bad way of doing things because:

Our IDEs paint our code yellow screaming at us complaining: "Potential NullPointerException:  must be null here!" This may distract the developer and delay the development, or if these warnings are turned off, lead to crashes and a waste of time debugging actual NPEs.
This will cause SecurityExceptions when porting Sponge to platforms that have tight security, and let users relax when downloading plugins from random websites.
It is a bad idea to use reflection to do things Java prevents you from doing on purpose. Java, a programming language used by a much larger community, including non-Minecraft users, must have a good reason for every aspect of its design. Even when Forge mods had to force something to change, they used access transformers, a (only slightly) better way to do things. But the target code was Mojang's, which they have no control over, and we are dealing with code that we are developing right here. This give us even less reason to use these reflection hacks.

Possible solutions are:

✘ Remove the static final modifiers. A malicious plugin (see the first answer's example here) could change them to whatever it likes, using the exact same way as how Sponge implementation do this currently. This is a bad solution however, because this makes it harder to change the values by mistake. See the next solution for the proper fix.
✔ Properly initialize the fields in the static constructor. A way to do this is getting the GameRegistry and asking it for each type. If the implementation doesn't have them ready, have passthrough proxy classes that have their target set using a package private way.

I've been meaning to bring this up - the most annoying thing for me, and others I'm sure, is that my IDE throws warnings at me (as you've mentioned). I'm :+1: if a solution comes up that always works.

Having them initialize to something referencing the game registry is just asking for strange errors due to when the class is loaded, better to initialize them to some dummy object and replace them in the same way as we currently do.

I also thought about this one.
Using Proxy Objects has the drawback of not been equal using ==. Or if you require it for all instances to be proxies then you have extra memory consumption and extra performance loss for wrapping/unwrapping them.
I thought about tricking the IDE compiler so it does not complain about the potential null.
public static final FooType BAR_VALUE = CatalogType.fake();

private static Object fake = new Object();

public <T> T fake() {
    return (T) fake;
}

And then this method is overwritten at runtime by Mixins to just return null.

I had the same thought, @ST-DDT, and I like it if it'll work.  :+1:

@CrystalMageX:

Our IDEs paint our code yellow screaming at us complaining: "Potential NullPointerException: must be null here!" This may distract the developer and delay the development, or if these warnings are turned off, lead to crashes and a waste of time debugging actual NPEs.

This isn't really much of an issue, especially because of our use of Optional. Any method or field which has a non-Optional type should never return null. While having the fields initialized to null may be slightly confusing for new users, this is easily rectified by reading the docs.

This will cause SecurityExceptions when porting Sponge to platforms that have tight security, and let users relax when downloading plugins from random websites.

Given that the entire Sponge + Forge ecosystem not only transforms classes through the LaunchWrapper classloader, but dynamically builds and classloads new classes (event handlers), security exceptions from reflection are pretty much the least of our concerns.

It is a bad idea to use reflection to do things Java prevents you from doing on purpose. Java, a programming language used by a much larger community, including non-Minecraft users, must have a good reason for every aspect of its design. Even when Forge mods had to force something to change, they used access transformers, a (only slightly) better way to do things. But the target code was Mojang's, which they have no control over, and we are dealing with code that we are developing right here. This give us even less reason to use these reflection hacks.

See above.

@Aaron1101 Regarding your first point.
This might be true for the Sponge API but others such as the Java API are not that  well defined because they are too old.

From what I'm gathering from this discussion is that the REAL issue is the null checks in IDEs. Some ideas are being discussed, some as far as generating dummy implementations of the catalog types where by default they throw a form of UnsupportedOperationException unless the fields are replaced as we are currently replacing them.
@Aaron1011 I know it's very well possible to do such a thing, either to adapt the event generation to expand it to generate these catalog classes as necessary, and have simple static methods that simply take the catalog class itself.

@gabizou:

From what I'm gathering from this discussion is that the REAL issue is the null checks in IDEs.

For some, the IDEs being annoying might be the worst thing they use there CatalogTypes. For others, they want a better way to write their ported Sponge's initializers. Some might wonder why we need to use reflection to catalog something as simple as TextColors!
A solution that would satisfy both kinds of implementations that need to initialize stuff later in the loading process, and implementations that don't, and also fix the IDE warnings would be:

Create a GameRegistry.staticInitializeType(Class<? extends CatalogType> clazz, String id) method, and call it from all catalogs.
In implementations that require initializing the types at runtime, simply return null; and keep using reflection, with absolutely no other changes required, and with the same results as before.
In implementations that do not require initializing, and when implementations that do require doing so, initialize something more simple than a TextColor, things like BanTypes, they can initialize it cleanly, and without reflection there.

@Aaron1011:

Given that the entire Sponge + Forge ecosystem

The Sponge + Forge ecosystem can continue to do what they're doing with the above solution. GlowstonePlusPlus, a non-API project, does not require the use of setAccessible(true) reflection like SpongeAPI forces right now. That means that a security-conscious server owner can enforce a tight security policy without it breaking. SpongeAPI, a project that is an API, should never be the limiting factor of anything, including but not only, the security of peoples' Minecraft servers.

For some, the IDEs being annoying might be the worst thing they use there CatalogTypes. For others, they want a better way to write their ported Sponge's initializers. Some might wonder why we need to use reflection to catalog something as simple as TextColors!

Why does it even matter to plugin developers whether we use reflection in the first place? It seriously doesn't matter whatsoever.

A solution that would satisfy both kinds of implementations that need to initialize stuff later in the loading process, and implementations that don't, and also fix the IDE warnings would be:

A majority of the initialization takes places prior to plugin classloading. In effect, this is why there was the initial registry rewrite to the system we use now versus the mess that existed before. There's little reason to initialize a great many things later in the game lifecycle when 99.9% of all catalog instances are available during the static initialization of plugins (minus mod added blocks, but those aren't exposed through the API directly anyways).

Create a GameRegistry.staticInitializeType(Class<? extends CatalogType> clazz, String id) method, and call it from all catalogs.

Not gonna happen, a majority of the id's are either generated at runtime and/or self defined by the implementation. There's absolutely no reason to expose the string constants in the API whatsoever.

In implementations that require initializing the types at runtime, simply return null; and keep using reflection, with absolutely no other changes required, and with the same results as before.

I don't think you understand what setting a field once does. It sets the field and that's it. There's no extra reflection calls performed, there's no additional strain on the system, it's just plain old java.

In implementations that do not require initializing, and when implementations that do require doing so, initialize something more simple than a TextColor, things like BanTypes, they can initialize it cleanly, and without reflection there.

Again, of everything in the API, trying to avoid using reflection to set catalog fields in the implementation is retarded. It's the LEAST worrisome aspect of Java that you should be caring about at length, let alone complain that implementations have it difficult to change the fields. Hell, just pipe everything through a clone of the RegistryHelper and be done with it, maybe have to add some force removal of the final modifier on the field, and then re-assign it after setting it, but that's literally the most rudimentary magical aspect of practically our entire implementation.

The Sponge + Forge ecosystem can continue to do what they're doing with the above solution.

The solution I'm suggesting is the solution I'm going with, unless someone comes up with a better option in the future.

GlowstonePlusPlus, a non-API project, does not require the use of setAccessible(true) reflection like SpongeAPI forces right now. That means that a security-conscious server owner can enforce a tight security policy without it breaking. SpongeAPI, a project that is an API, should never be the limiting factor of anything, including but not only, the security of peoples' Minecraft servers.

You know there are ways to write security managers that forcefully check the callers to validate that the reflection setting is performed by the implementation and no one else. Complaining that allowing setting fields with reflection in this way is the least of your worries when it comes to security in Java, let alone in running a Minecraft server. Seriously, you're getting annoying trying to point out that requiring the use of reflection to set some fields on our own API through our own implementation (Which as I said already is entirely controllable) is a leak in security. If you want to complain about security in Java, go stand in line.

Ok, so my 2nd and 3rd points (both about security) are resolved. @gabizou has decided that reflection will be the only way to initialize the catalogs. Third-party implementations of SpongeAPI can only hope that that platform's security allows them to reflect their own packages, or else they will need to include a modified API with their custom static initializers, or the final modifier removed. This leaves us with the 1st point.
The 1st point is about IDEs complaining about NullPointerExceptions. It seems there is an even simpler way than @ST-DDT 's adding of a method. We can just extract the assignments to a static constructor, and they won't complain anymore. (tested with IntelliJ Community 2016.1, # IC-145.256).
Change this:
public class BanTypes {
    public static final BanType PROFILE = null;
    public static final BanType IP = null;

    private BanTypes() {
    }
}

to this:
public class BanTypes {
    public static final BanType PROFILE;
    public static final BanType IP;

    private BanTypes() {
    }

    static {
        PROFILE = null;
        IP = null;
    }
}


Add An Introduction to C & GUI Programming from Raspberry Pi Press/Simon Long

What does this PR do?
Adds An Introduction to C & GUI Programming from Raspberry Pi Press
closes #3230
For resources
Description
An Introduction to C & GUI Programming by Simon Long from Raspberry Pi Press
Short resource guide for programming in C and GTK2
Why is this valuable (or not)
Free Raspberry Pi resource
How do we know it's really free?
(CC BY-NC-SA 3.0)
For book lists, is it a book?
Yes
Checklist:

[X ] Not a duplicate
[X ] Included author(s) if appropriate
[X ] Lists are in alphabetical order
[X ] Needed indications added (PDF, access notes, under construction)

thanks!


Support Koalas DataFrame in verify_temp_column_name.

Addressing a comment https://github.com/databricks/koalas/pull/1394#discussion_r403775995.

Otherwise, LGTM.

Codecov Report

Merging #1400 into master will decrease coverage by 2.18%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1400      +/-   ##
==========================================
- Coverage   95.16%   92.97%   -2.19%
==========================================
  Files          34       34
  Lines        7859     7875      +16
==========================================
- Hits         7479     7322     -157
- Misses        380      553     +173

Impacted Files
Coverage Δ

databricks/koalas/indexing.py
95.09% <100.00%> (+0.07%)
:arrow_up:

databricks/koalas/series.py
96.87% <100.00%> (+<0.01%)
:arrow_up:

databricks/koalas/utils.py
95.21% <100.00%> (+0.15%)
:arrow_up:

databricks/koalas/usage_logging/__init__.py
24.32% <0.00%> (-70.28%)
:arrow_down:

databricks/koalas/usage_logging/usage_logger.py
50.00% <0.00%> (-50.00%)
:arrow_down:

databricks/koalas/__init__.py
78.72% <0.00%> (-14.90%)
:arrow_down:

databricks/conftest.py
88.67% <0.00%> (-7.55%)
:arrow_down:

databricks/koalas/frame.py
93.62% <0.00%> (-3.19%)
:arrow_down:

databricks/koalas/namespace.py
87.36% <0.00%> (-1.38%)
:arrow_down:

databricks/koalas/plot.py
93.33% <0.00%> (-0.96%)
:arrow_down:

... and 1 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 fc061e8...70eacd7. Read the comment docs.


Faster Peek

From #519

:shipit:

But before I merge, did you run any benchmarks on this change?

Its one of the hot spot changes from the xmas combo #519 (i.e. worked each method until it was no longer a top hotspot then moved onto the next); was planning to benchmark each one in isolation though; just haven't looped back round to it.


Google authentication fails in new project

I'm trying to get Google authentication to work on a new project created with Visual Studio 2015 RC.
To reproduce, create a new project from VS, in ConfigureServices add the following lines:
services.Configure<GoogleAuthenticationOptions>(options => {
  options.ClientId = "xxx.apps.googleusercontent.com";
  options.ClientSecret = "xxx";
});

and then the Configure method, add the following line:
app.UseGoogleAuthentication();

This is how I have configured OAuth for Google:

This is my dependencies in project.json:
"dependencies": {
  "EntityFramework.SqlServer": "7.0.0-beta5",
  "EntityFramework.InMemory": "7.0.0-beta5",
  "EntityFramework.Commands": "7.0.0-beta5",
  "Microsoft.AspNet.Mvc": "6.0.0-beta5",
  "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta5",
  "Microsoft.AspNet.Authentication.Cookies": "1.0.0-beta5",
  "Microsoft.AspNet.Authentication.Facebook": "1.0.0-beta5",
  "Microsoft.AspNet.Authentication.Google": "1.0.0-beta5",
  "Microsoft.AspNet.Authentication.MicrosoftAccount": "1.0.0-beta5",
  "Microsoft.AspNet.Authentication.Twitter": "1.0.0-beta5",
  "Microsoft.AspNet.Diagnostics": "1.0.0-beta5",
  "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta5",
  "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta5",
  "Microsoft.AspNet.Server.IIS": "1.0.0-beta5",
  "Microsoft.AspNet.Server.Kestrel": "1.0.0-beta5",
  "Microsoft.AspNet.Server.WebListener": "1.0.0-beta5",
  "Microsoft.AspNet.StaticFiles": "1.0.0-beta5",
  "Microsoft.AspNet.Tooling.Razor": "1.0.0-beta5",
  "Microsoft.Framework.Configuration.Abstractions": "1.0.0-beta5",
  "Microsoft.Framework.Configuration.Json": "1.0.0-beta5",
  "Microsoft.Framework.Configuration.UserSecrets": "1.0.0-beta5",
  "Microsoft.Framework.Logging": "1.0.0-beta5",
  "Microsoft.Framework.Logging.Console": "1.0.0-beta5",
  "Kestrel": "1.0.0-beta5"
}

The error message in the console gives me a 403 even though I successfully login with my Google account. Are there any configuration I'm missing?
error   : [Microsoft.AspNet.Authentication.Google.GoogleAuthenticationMiddleware] Authentication failed
System.Net.Http.HttpRequestException: Response status code does not indicate success: 403 (Forbidden).
   at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
   at Microsoft.AspNet.Authentication.Google.GoogleAuthenticationHandler.<GetUserInformationAsync>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.AspNet.Authentication.OAuth.OAuthAuthenticationHandler`2.<AuthenticateCoreAsync>d__8.MoveNext()

It works when I use the API-key from the sample project so I guess it's my configuration that is wrong, can you show me how your account is configured?

You probably didn't turn on API/Google plus access or something like that, there's some other detailed setting that you need to enable for google auth to work.

Oh embarrassing, it was the Google+API, thanks for your help

Because I had the very same problem and was a bit puzzled by the answer, here's a guide:

In the Google Developers Console, select your project
go to APIs & auth, Social APIs, Google+ API
enable that one

After that, the application defined under Credentials should be able to login with the openid profile email scopes.

Thanks!!!

Had the same thing after I changed from our staging google's project to the production's one.
@HaoK is it possible to make the error clearer?


unify nuttx and posix Device/CDev + ms5611 linux port

This PR merges the posix and nuttx Device and CDev classes. I also started disentangling Device/CDev, but ultimately maintained the current hierarchy. They're mostly separate now, but the IOCTL usage is so tangled between Device, CDev, I2C, SPI that will likely need to touch every driver.
With this PR the Navio2 Raspberrypi is now using the main ms5611 driver (I2C).
@nicolaerosia FYI

@dagar Could you look into CI fails?

A large portion of this was merged with https://github.com/PX4/Firmware/pull/8300 and in https://github.com/PX4/Firmware/pull/8317.
I'll take another pass at porting the remaining drivers soon.


react.development.js:1357 Uncaught TypeError: ctor is not a function

when I am connecting node js backend application and retrivating route data from my backend it shows error

I waste my lot of time but I can't able to fix this bugs.

How to reproduce this problem❓

I solved this by writing my own permissions logic.  This  repo is great solution for all cms project.

I solved this by writing my own permissions logic. This repo is great solution for all cms project. Thank buddy.

for your problem, perhaps the deconstruction of the routing object you returned does not match the slash admin
last, thank you for your affirmation！


BERT model support

Add embedding models to use primarily with /api/embeddings

instructor-xl
bge-large
all-MiniLM-L6-v2

See the full leaderboard

Yes, please! Any of these embedding models above text-embedding-ada-002 would be a great addition.
I've tried LLam2 and Mistral model with the /api/embeddings as is, and I'm getting poor-quality similarity scores.
Even with almost identical queries, It fails to retrieve results. Are there some prompting technics to improve the embedding quality?
Anyway, in comparison, I've tried Xenova/gte-small with transformers and it is much faster and yields better results.

jinaai/jina-embeddings-v2-base-en (and other variants) also look promising.

Hi, is there an update on this issue? I would love to contribute

I've been playing with https://github.com/nlpodyssey/cybertron which is pure Go (but I guess CPU only?) and at least supports all-MiniLM-L6-v2, e5-*-v2, bge-*-en-v1.5 and ember-v1.
I did some testing with the STS-2016 dataset and got accuracies (Pearson correlation with the gold answers):

Ollama

llama2: 0.23431
mistral:instruct: 0.5656

Cybertron

all-MiniLM-L6-v2: 0.80344
e5-small-v2: 0.82318
e5-base-v2: 0.83845
bge-small-en-v1.5: 0.84514
bge-base-en-v1.5: 0.85297

So I agree with the previous comment that the embeddings generated by the completion models are pretty bad!

That is interesting. For GPU support, I guess we will need to use: https://github.com/skeskinen/bert.cpp ?
I think the implementation would be something similar to llama.cpp?

I found this issue: https://github.com/ggerganov/llama.cpp/issues/2872
I think they plan to implement it in llama.cpp. So maybe we will just need to update the llama.cpp when it's done?

I also found this https://github.com/ml-explore/mlx-examples/blob/main/bert/README.md, which we can use to run inference on M1 mac. Is it possible to support mlx with Ollama?

Any update on this or plan to allow Bert Models?

Any update on this issue?

Do you have any updates so far? very interested to contribute

Plans to support BERT models in llama.cpp stalled out when the dev who had assumed the task ended up focusing on something else. In the last few days it looks like the project management artifacts were updated to acknowledge this, so maybe there will be some action soon. Actually, it looks like there has been some activity. Maybe there will be working code soon:
https://github.com/ggerganov/llama.cpp/issues/2872

BERT support was merged 3 days ago into llama.cpp

Looks like there are still kinks being worked out.

Looks like there are still kinks being worked out.

Link to check the progress https://github.com/ggerganov/llama.cpp/pull/5500

Looks like there are still kinks being worked out.

Link to check the progress ggerganov/llama.cpp#5500

It is merged now

@jmorganca just wanted to follow up and see if this topic is on your roadmap. Since llama.cpp added support for BERT models, this seems like a great low-hanging fruit, no?
Initial support for BERT models has been merged with ggerganov/llama.cpp#5423 and released with b2127. Some kinks related to embedding pooling were fixed with ggerganov/llama.cpp#5500. Batch embedding is supported as well.
There has been a new bug related to the tokenizer implementation but that's it as far as I can tell.

@AndreBerzun it absolutely is – working on it!


Update repositories.txt

@ArduinoBot

Hello @Solo-FL. The automated system here only operates on open pull requests. Since your submission was already accepted and the pull request merged, the bot won't pay any more attention to this pull request.
But this human is happy to provide assistance. Was there something you needed from the bot?


fixed a typo

lol im so bored i fixed a typo lol
i changed yoy to you

Not even in the UI, a typo in a comment! That is a new level of bored 😀
Thanks, merged


Warning: Accessing non-existent property ‘INVALID_ALT_NUMBER’ of module exports inside circular dependency

This is a problem with package solidity-parser-antlr with is a dependency of sol-merger which flattener depends on.

Should test this with the latest version since sol-merger now depends on https://github.com/tunnelvisionlabs/antlr4ts

Should test this with the latest version since sol-merger now depends on https://github.com/tunnelvisionlabs/antlr4ts


Keep used NioIoOps and SelectionKey in sync

Motivation:
As the user is able to retieve the underlying SelectionKey via the NioRegistration we need to ensure we always keep this and the current used NioIoOps in sync.
Modifications:
Remove the local stored NioOps and just always reconstruct using the underlying SelectionKey. This is not a concern in terms of performance and object creation as we pre-construct them.
Result:
Keep current used NioIoOps and SelectionKey always in sync

@chrisvest I realized that there can be some issues when not doing this. PTAL


Adds initial Kubebuilder scaffolding

Scaffolds the project with Kubebuilder using projectcontour.io as the domain, Contour as the kind and v1alpha1 as the version.
/assign @jpeach @Miciah

Sorry about this @danehans; this PR was closed when I switched the default branch to "main", could you please re-post it?


.Alert.Vars cann't eval string

Issue
influxdb Data

bosun alert define
$status = last(influx("telegraf", '''select last(status) from healthz group by dc, "name", service ''', "10m", "", "1m"))
$msg = last(influx("telegraf", '''select last(msg) from healthz group by dc, "name", service ''', "10m", "", "1m"))

the question is
when i use {{.Eval .Alert.Vars.msg }} in template i get
NaN

when i use {{.Alert.Vars.msg }} in template i get
last(influx("telegraf", '''select last(msg) from healthz group by dc, "name", service ''', "10m", "", "1m"))

but i expect result is the msg string: '-',
so, the question is what's the right way to eval the msg value, or just is a bug?
i dig the document cann't find answer, please help.
Work Environment:
bosun-linux-amd64-0.5.0

I'm not familiar with influx, but, is there a method in the query dsl to cast the results?  You're doing select last(msg) and bosun somehow is thinking that is a number.  Does last(msg) in influx normally return a number?  Is it possible that influx is pasting a '-' in your results because there's actually no data there?


lib: use explicit name imports in lib/systems

Description of changes
Using with at a top-level scope is an anti-pattern. The tracking issue is https://github.com/NixOS/nixpkgs/issues/208242. This is a pure refactor: there is no functional change contained in this PR.
The tests found issues when I intentionally introduced them and obviously continue to pass.
Related:

https://github.com/NixOS/nixpkgs/pull/293901
https://github.com/NixOS/nixpkgs/pull/294906

Things done

[x] Tested, as applicable:

[x] nix-instantiate --strict --eval lib/tests/misc.nix
[x] lib/tests/modules.sh

[x] Fits CONTRIBUTING.md.

Just a quibble (PR is fine), but most of it doesn't seems to be getting rid of with? I think explicit lib.<name> is fine? Sometimes "qualified name" style like that is easier to read because you don't need to remember what comes from where: "oh, it is calling some lib function" is immediately obvious.

Just a quibble (PR is fine), but most of it doesn't seems to be getting rid of with? I think explicit lib.<name> is fine? Sometimes "qualified name" style like that is easier to read because you don't need to remember what comes from where: "oh, it is calling some lib function" is immediately obvious.

Following advice, I also preferred to inherit names from lib instead of builtins where there was a choice. I also preferred to inherit from lib in one place, rather than to have a mixture of lib.thing and inherit (lib) thing.
The PR did used to include other things and have a description referring to those other things, but I dropped them following feedback.
Still learning how to scope and describe refactor PRs that will get speedy acceptance and merging. This is one of my first ones from a few weeks ago. I appreciate your feedback!

others might disagree with me on this, but I think I prefer lib.<name> unless it is used so many times let inherit (lib) name; in ... really makes things briefer.

others might disagree with me on this, but I think I prefer lib.<name> unless it is used so many times let inherit (lib) name; in ... really makes things briefer.

I wonder if I can construct a re-writer that would follow this preference...
My preference is the opposite (as you can see) but that's mostly because I like consistency of the thorough variety (the notable hob-goblin of small minds).


Add category additional description column during upgrade

Questions
Answers

Description?
Adds database column for related change - https://github.com/PrestaShop/PrestaShop/pull/27292

Type?
new feature

BC breaks?
no

Deprecations?
no

Fixed ticket?
-

How to test?
To be tested at the same time as PrestaShop/PrestaShop#27292

Possible impacts?
-

Hi @Hlavtox,
Could you please check the Conflicting files?
Thanks!

@khouloudbelguith Rebased

Awesomeeeee!!!! Thank you @khouloudbelguith 🎉

Thanks @Hlavtox & @khouloudbelguith


Using withSchema on DML statements such as del, insert, and update?

I started using knex.withSchema(x).select().from(y), but I couldn't figure out a way to use it in something like an insert statement where the table name is passed via knex(tablename).
For those statements, I'm continuing to use string interpolation.  Just wondering if there is a better way.

Is this what you are looking for https://runkit.com/embed/ai907osl2dzp ? Maybe I didn't get the question right?

I didn't see the specific case I was looking for, but what I did see in there was the syntax knex.table("bar").insert()...
If this example below works, then it would be fine:
knex.withSchema("foo").table("bar").insert(stuff)
but I think I tried that and it didn't work.  I might be misremembering though.

Seems to work https://runkit.com/mikaelle/59514b213dcf2e0012b72093


Add CNI-plugin tests

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm
/approve


feat: route groups + ssr not-found page

Single PR version of the entire stack https://github.com/hi-ogawa/vite-plugins/pull/511
The diff looks fine (mostly test and examples change and the main one is only packages/react-server/src/features/router/tree.ts), so we'll probably merge this one.

closes https://github.com/hi-ogawa/vite-plugins/pull/505
closes https://github.com/hi-ogawa/vite-plugins/pull/507
closes https://github.com/hi-ogawa/vite-plugins/pull/509
closes https://github.com/hi-ogawa/vite-plugins/pull/511
closes https://github.com/hi-ogawa/vite-plugins/pull/513
closes https://github.com/hi-ogawa/vite-plugins/pull/514
closes https://github.com/hi-ogawa/vite-plugins/pull/516

#517 : 2  dependent PRs (#518 , #519 ) 👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @hi-ogawa and the rest of your teammates on  Graphite

Oops, I messed up the merge with graphite sync. I fixed it by copying local commits directly on this PR

https://github.com/hi-ogawa/vite-plugins/pull/519

Merge activity

Jul 8, 8:14 PM EDT: @hi-ogawa started a stack merge that includes this pull request via Graphite.


Discrepancy in mhpmevent bits for Sscofpmf

The ratified sscofpmf extension spec[1][2] had bits 56:57 marked as reserved but the integrated priv spec mentioned only 6 bits.
However, the Smcntrpmf extension CSRs (mcyclecfg, minstretcfg) have 8 bits with bits 56:57 marked as reserved citing sscofpmf.
Is this an integration issue or the definition bits actually changed after ratification ?
[1] https://drive.google.com/file/d/1-3rp7Fw69aH26wbRkvwd4lBHangiVRMN/view
[2] https://github.com/riscvarchive/riscv-count-overflow/blob/main/content.adoc
@gfavor @bcstrongx

I'll leave this one for @gfavor, Smcntrpmf was simply emulating the Sscofpmf spec.  Either those bits should be reserved in both mhpmeventX and mcyclecfg/minstretcfg, or in neither.

See the linked PR that removes that sentence.

@gfavor : I could not find anything about "Bits 57:56 are Reserved in any case" in the latest integrated priv spec. Please let me know if I missed something ?

To take this a step further, I'm not sure how we managed to define 63:58 in Sscofpmf, or how we can ever define any bits in future standard extensions, given the current definition:

The event selector CSRs, mhpmevent3-mhpmevent31, are 64-bit WARL registers that control which event causes the corresponding counter to increment. The meaning of these events is defined by the platform, but event 0 is defined to mean "no event."

I read that as the entire register is reserved for custom use.

I read that as the entire register is reserved for custom use.

My interpretation is that when Sscofpmf is implemented, that is true. When Sscofpmf is implemented the 63:58 are provided by Sscofpmf. So user of mphmevent* has to discover availability of Sscofpmf and interpret 63:58 per Sscofpmf only if the extension is present.

Yes. That's what software is implemented with that assumption. But the ratified Sscofpmf marked 63:56 while the latest integrated spec 63:58. If the bits 57:56 are marked reserved somewhere else we should point that out in sscofpmf section. Otherwise, an implementation would use those bits for custom event encoding as well.

At the time of developing Sscofpmf, the view by the ICs was the following:
The hpmevent bits are officially (in the ISA spec) simply WARL without any specific further definition (other than to say that "the meaning of these events is defined by the platform") - which leaves the door open to future extensions further defining and/or constraining values for fields of these registers.  Maybe that's arguable, but the more practical observation was that it would be best for Sscofpmf to stay as far away as possible from the lower bits of these registers, i.e. from the bits that have more likely been used by existing implementations.
For RV32 this was guaranteed, but was only statistically very likely true for RV64.  Which arguably establishes a little bit of a precedent for introducing definitions of some hpmevent bits.
Practically speaking it is comparably safe to use some number more of the highest bits in RV64, with the odds of a conflict slower growing the lower one goes in these registers.
From this perspective just reserving two high bits for the future would have been very short-sighted if it was felt that that needed to be explicitly done (which wasn't really the case).
So, going forward, using the high byte or two of the hpmevent registers is reasonably fair game for new extensions.  And past that slowly gets more dangerous.
There's also the possibility of a future arch extension standardizing a format and structure to the low many bits of these registers.  Existing and future implementations would/could not implement this, while other future implementations could choose to implement this if they so chose.  For example, standardizing a format that directly mirrors the format that OpenSBI uses in its API.  Although OpenSBI already largely accomplishes this in guiding or suggesting (without forcing) implementations to implement a format that matches the OpenSBI API format.

Thanks @gfavor.

After discussion by the ARC, the resolution is that the integrated spec is correct in not explicitly calling out bits [57:56] as specially reserved for future new priv modes (and correct in not overriding the default for these bits).  In general RISC-V arch only has the defined general and unqualified concept of Reserved.  Any future definition of any of the upper mhpmeventX bits by a new arch extension is subject to the same considerations, as mentioned in https://github.com/riscv/riscv-isa-manual/issues/1578#issuecomment-2278901424, that applied to Sscofpmf.
So no change to the current integrated spec and @bcstrongx's corresponding correction to the Smcntrpmf spec stands.

@gfavor : The ARC notes email says the opposite to what you described here. Am I misunderstanding something ?
"The ratified version of the Sscofpmf specification documents bits 57:56 of mhpmevent as Reserved. The current documentation somehow lost this Reserved status. After a brief discussion, it was concluded that the current documentation should be corrected (i.e. to once again document bits 57:56 as Reserved)."

I read it as 57:56 are 0, which means they are reserved for any future standard use, not just for future priv modes.  As opposed to 55:0, which are custom.

The ARC minutes didn't capture the stuation accurately.  The issue was that the original spec reserved bit 57:56 for a specific potential (but unlikely) purpose, versus just generally reserving them.  The ARC judged that to be improper and inconsistent with the RV arch at large - and hence that the integrated spec was correct and in line with standard practice within the overall architecture.  The writer of the minutes also didn't quite capture properly (and this mistake was missed) that the spec should simply not do what the original spec did, i.e. the curent spec should remain silent regarding these bits.  Which means any future standard (overriding) definition of these bits (or any lower bits) faces the same considerations that applied for Sscofpmf providing an overriding definition of bits 63:58.

Also note that the mhpmeventN bits are NOT "custom" - otherwise it would not have been allowable for RVI to redefine the upper bits (or any other bits in the future) of these registers.  They are WARL.

Thanks again @gfavor for the clarification.

Wait, now I'm confused.  So are bits 57:56 0 or WARL?

Setting aside what the original spec "inappropriately" said, the default definition of all 64 bits of the mhpmevent registers is WARL and not Reserved.  So even Sscofpmf was either defining or overriding/redefining (depending on one's perspective) the pre-existing definition of the high register bits.  Whether one "officially" reserves certain bits or not doesn't really make a difference.   Whenever a new extension comes along that defines/redefines any bits of these registers, the same considerations will apply that applied to Sscofpmf when it was being developed.  (Put differently, the original "reserved for future priv modes" was both anachronistic wrt the general architecture and reserving of bits, and was reserving bits for a highly unlikely and hence flawed purpose.  So then the question was whether the current integrated spec represented the more appropriate handling of bits 57:56 or not.)

Sorry, still not sure of the answer.  I understand the history, and that Sscofpmf redefined 63:58.  I'm less sure where we landed on 57:56.  Are they now 0 (reserved) or WARL?

By the integrated spec continuing to say nothing about these bits, the pre-existing definition of WARL applies for these bits.

Got it, thanks!

Sorry for the churn, but the ARC discussed this issue some more and came to a final slightly different conclusion (wrt the last ARC minutes about this issue and more so different wrt what I described above).  As a result, some small changes will need to be made by @wmat to the integrated Sscofpmf spec and by @bcstrongx to the Smcntrpmf spec.
First, for context for Bill, the original ratified unintegrated Sscofpmf spec defined bits [57:56] of the mhpmeventN CSRs as "Reserved for future modes".  And the integrated Sscofpmf spec completely lost any definition of these two bits.
The final resolution is that the explicit definition of bits [57:56] as Reserved should be added back in, BUT without the addiitonal words about "for future modes", i.e. these bits should simply be defined as "Reserved".  Further, in the register diagram these two bits should be shown as being WPRI.  This correction is for Bill to make.
The correction for Beeman to make to the Smcntrpmf spec is to mirror the preceding resolution.

The Smcntrpmf github has been archived, since the extension has been integrated into the priv spec.  So it probaby makes sense for @wmat to duplicate his Sscofpmf changes in the Smcntrpmf chapter.  But let me know if for some reason you need me to do it.

Just curious, why WPRI rather than 0?

WPRI foremost is a directive to software (although also a directive to hardware).  Here's the spec definition of WPRI:
Some whole read/write fields are reserved for future use. Software should ignore the values read from these
fields, and should preserve the values held in these fields when writing values to other fields of the same
register. For forward compatibility, implementations that do not furnish these fields must make them
read-only zero.

So the old version of the spec is significantly different.  There's a whole section called Machine Level Additions that doesn't exist in the integrated chapter.  Can someone please let me know what exactly from the old version should be added to the integrated chapter and where?  Here's the old content.adoc:
https://github.com/riscvarchive/riscv-count-overflow/blob/main/content.adoc

The original spec for Sscofpmf defined bits [63:56] of the mhpmevent registers (CSRs).  The integrated version of the spec "lost" the definitions of bits [57:56], i.e. the integrated spec says nothing about these two mhpmevent bits.
The original spec defined bits [57:56] as "0 - Reserved for possible future modes".  In the integrated spec a definition of these two bits should be added back in.  In the register figure and associated table, these two bits should each be marked as "WPRI" and as Reserved, i.e. Field is "WPRI" and Description is "Reserved".
Per Beeman's post, the same should be done in the Smcntrpmf chapter for the mhpmevent register descriptions there.

Closing this issue now that @wmat has created a PR for updating both extensions to reflect the final ARC resolution as described in the last post.


Providing Higher Order Functions for common getServerSideProps scenarios

I had this idea with this package providing higher-order functions to provide extended context to the wrapped getServerSideProps function to simplify common scenarios.
An example using such approach with HTTP env headers and Prezly API client:
function withHttpEnv<Context extends GetServerSidePropsContext, Props>(
    getServerSideProps: (
        context: Context & { env: Env },
    ) => Props | Promise<Props>,
) {
    return function (context: Context) {
        const env = getEnvVariables(context.req);

        return getServerSideProps({ ...context, env });
    };
}

function withPrezlyApi<Context extends GetServerSidePropsContext, Props>(
    getServerSideProps: (
        context: Context & { api: PrezlyApi },
    ) => Props | Promise<Props>,
) {
    return withHttpEnv(function (context: Context) {
        const { PREZLY_ACCESS_TOKEN, PREZLY_NEWSROOM_UUID } = context.env;
        if (!PREZLY_ACCESS_TOKEN) {
           throw new Error('"PREZLY_ACCESS_TOKEN" is not set in env variables.');
        }
        if (!PREZLY_NEWSROOM_UUID) {
           throw new Error('"PREZLY_NEWSROOM_UUID" is not set in env variables.');
        }

        const api = new PrelzlyApi(PREZLY_ACCESS_TOKEN, PREZLY_NEWSROOM_UUID);

        return getServerSideProps({ ...context, api });
    });
}

and then the usage will be something like this:
export const getServerSideProps: GetServerSideProps<BasePageProps> = withPrezlyApi(async (context) => {
    const api = context.api;
    const env = context.env;
    // use API and env
});

what do guys you think about this approach?

So basically it's just about converting the utility functions (getPrezlyApi and getEnvVariables) into HOC functions?
From what I see it would make the getNewsroomServerSideProps function a bit simpler, since it wouldn't need to initialize and return the api object anymore, using it from the context instead.
Are there any other improvements to the DX that we can make with these? 🤔

Are there any other improvements to the DX that we can make with these?

Anything. For example, typically fetched page props can be done with a HOF and passed to the wrapped function as a second argument (or alternatively within the context object):
export const getServerSideProps: GetServerSideProps<BasePageProps> = withStoryPageProps(async (context, props) => {
    const { story, translations, languages, newsroom, theme, preset } = props;
    const discourseUrl = ...;

   return {
      props: {
          ...props,
          discourseUrl,
      };
   };
});

This was kind of addressed in https://github.com/prezly/theme-kit-nextjs/pull/31 (although not in a HOF way).
We'll need to see if the approach made in that PR would be good enough. If not, we can convert it to the proposed HOF approach, which should be a bit cleaner code-wise.


[SUPPORT] Problems in SparkRDDWriteClient.upsert

Hudi version : 0.8.0
Spark version : 3.1.2
I tried to upsert hudi by client.
Found the HoodieJavaWriteClient API only support COW tables (why not support MOR).
So I used SparkRDDWriteClient API.
But Faced with such error.
Can anybody help with it?
22/05/17 02:43:21 ERROR ApplicationMaster: User class threw exception: java.lang.VerifyError: Bad return type
Exception Details:
Location:
org/apache/hudi/table/action/commit/BaseSparkCommitActionExecutor.getUpsertPartitioner(Lorg/apache/hudi/table/WorkloadProfile;)Lorg/apache/spark/Partitioner; @34: areturn
Reason:
Type 'org/apache/hudi/table/action/commit/UpsertPartitioner' (current frame, stack[0]) is not assignable to 'org/apache/spark/Partitioner' (from method signature)
Current Frame:
bci: @34
flags: { }
locals: { 'org/apache/hudi/table/action/commit/BaseSparkCommitActionExecutor', 'org/apache/hudi/table/WorkloadProfile' }
stack: { 'org/apache/hudi/table/action/commit/UpsertPartitioner' }
Bytecode:
0x0000000: 2bc7 000d bb00 9a59 12ca b700 9dbf bb00
0x0000010: 8f59 2b2a b400 0f2a b400 052a b400 03b7
0x0000020: 00cb b0
Stackmap Table:
same_frame(@14)
at org.apache.hudi.table.HoodieSparkMergeOnReadTable.upsert(HoodieSparkMergeOnReadTable.java:82)
at org.apache.hudi.table.HoodieSparkMergeOnReadTable.upsert(HoodieSparkMergeOnReadTable.java:74)
at org.apache.hudi.client.SparkRDDWriteClient.upsert(SparkRDDWriteClient.java:154)

It turns out that
when your project's dependencies contains both hudi-java-client and hudi-spark-client, this error will happen


Add ERC: Blob Transactions Metadata JSON Schema

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

The PR edits only existing draft PRs.
The build passes.
Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
If matching on email address, the email address is the one publicly listed on your GitHub profile.

@abcoathup @eip-review-bot Hi, all required feedback have been addressed and are ready for a review.

@gavfu needs to be reviewed by an editor (which I am not).

@gavfu needs to be reviewed by an editor (which I am not).

Thanks Andrew. @Pandapip1 Hi Gavin, could you kindly help review this EIP proposal please? Thanks.

All required feedback have been addressed and are ready for a review.

All required feedback have been addressed and are ready for a review.

All required feedback have been addressed and are ready for a review.


feature: custom prefix for steam & discord

Description
Custom prefix for steam and discord configured in options.json

options.miscSettings.prefixes.steam
options.miscSettings.prefixes.discord

Changes

Updated schema validation for prefixes options
Updated logic for custom prefixes
Updated all messages with static fixed prefix to custom prefix

To do

Update wiki
Test cases for safety

Tested locally and worked what I could see, but rather new to the system so should test everything to see it works as intended

Extra
Fixes: #1354
Wanted to create %prefix% for messages on bptf.

Thank you for the PR. I will look into this.

Interesting to see this. When I was implementing Discord interface from scratch, there were some discussions about differentiating bots by their prefixes, but that time we decided to manage it by differentiating Discord channels bots have access to.
I have some vague ideas about OOP-reworking command interface to make managing commands easier for programmers, as well as moving to slash-commands in Discord. Howewer, your PR might be good for some users for now.

Interesting to see this. When I was implementing Discord interface from scratch, there were some discussions about differentiating bots by their prefixes, but that time we decided to manage it by differentiating Discord channels bots have access to.
I have some vague ideas about OOP-reworking command interface to make managing commands easier for programmers, as well as moving to slash-commands in Discord. Howewer, your PR might be good for some users for now.

I thought about making a whole module for commands and extensions for it but I'm selfish and don't need it. But hopefully it will in the future since the current way of handling commands scares me, would be easier to have them into classes and have a CommandHandler containing all the commands.

Wouldn't it be better to refactor the whole command system, using if statements to check what command the user is using is too much bloat code, wouldn't it save more time to create a Command class with a CommandHandler getting our message if it's a command request and find our command in a map/array to which have been cached on bootstrap?
Would be easier to handle issues like this prefix issues because going around finding where ! is used will be too much repeating process, to avoid DRY so to say.

If you're able to do that, sure, but let this PR get merged first, and I'll give you a write permission on the main repository so that you'll be able to create another branch for that.


Fix template to use new SNAX GEMM signal barrier

This PR is a small fix because last time the barrier was only working for the MAC engine because we needed the update from the SNAX GEMM repo.
@xiaoling-yi made the update to add the snax_barrier_o signal already so this is just an upgrade to that.
The modifications are:

Use latest snax-gemm repo
Change template to default one
Modify the wait_batch_gemm() function to use the SNAX barrier.

Hallo! I vote we push this in for now and we can make modifications later anyway 😄


OptionParser fail to match for non-dashed flags

According to docs dash is optional Flags can (but don't have to) start with a dash.
In my case I want to have create flag that would behave as sub-command.
Minimal case to reproduce:  https://play.crystal-lang.org/#/r/1lvk
require "option_parser"

parser = OptionParser.new do |p|
  p.on("-c NAME", "--create NAME", "build something") do |name|
    puts "creating #{name}"
  end

   p.on("create NAME", "build something") do |name|
    puts "creating #{name}"
  end
end

#Output should be the same by second case fail to match
parser.parse %w(--create awesome)
parser.parse %w(create awesome)

I would expect that that dash is optional in all forms of flag.
@luislavena  thanks for help on code example.

Related to #3357

The docs are wrong, arguments must have dashes


[WIP] Compiler refactor 2.0

This is very much a WIP, but I am creating the PR now to check with Travis every now and then and get early feedback.

Could you provide a description on the new compiler design on this PR? This would be really helpful. Besides of my comments this looks really nice. Really looking forward to this.

Thanks a lot for your comments. I will respond to your comments above, and write a design summary in the weekend. Although the design is still partly being figured out!

I have added a design summary above. Please let me know if something is not clear or if you want to squeeze more work in this PR.

Thanks for the effort! I'll have a close look at the PR next week.

So while looking further into the type stability of Turing, I thought it may be necessary to de-scope this PR a little to avoid bloating it too much when it doesn't really have to. So I will consider this PR camera-ready if it provides at least the same features we had before, with at least the same speed we had before but without the global scope issue, which means that the @model macro can be used in other modules and even inside of functions. Currently, the features are on par IIUC, but the speed has worsened on my local benchmark. So I will look into it. Other big tasks to be done in other PRs include:

Making AD mostly type stable (started working on that). This involves encoding the AD type and parameters in the algorithm's type to push the type instability up and allow the user to fully eliminate it. However, it gets a little tricky when deciding the chunk size in ForwardDiff. I am saying mostly type stable because VarInfo's type instability infects the AD functions.
Making VarInfo type stable. This one is very critical as it touches most of the code in Turing.jl so I am taking my time thinking about and making thought experiments with potential solutions as I am improving the other bits. I don't really have a feasible solution yet, but a few half-baked proposals which all seem to fail at least one use case in my head. If you have ideas, you can comment in https://github.com/TuringLang/Turing.jl/issues. While I don't have a full-fledged solution, I have a few incremental improvements which are easier to do and should improve the performance IIUC.

Sounds like a good idea to me. I'll check the PR soon and then we should be ready to go.
Regarding the VarInfo type instability. I agree that this is very crucial, we (Hong, Kai and me) had already some discussions on this and I'm happy to jump if I'm of any help. As you said, we should have a good plan for this first. VarInfo currently also contains lots of unnecessary fields that we should get rid of.

Design description updated above.

sample(gdemo()) # gdemo()()

@cpfiffer may you please take care of updating the docs after this is merged? The main update I can think of is that there is no need for a section on avoiding the @model macro, since it will be perfectly usable in other modules or functions after this PR is merged. You can perhaps rename it to Turing internals or something. I will remove item from the checklist above for now.

This is ready for one more review.

Can do. Excellent work!

This is ready for one more review.

Thanks, @mohamed82008. I'll take a review this PR soon.

Thanks. Btw, this is for you @yebai and @willtebbutt. I hope that's what you meant by phase-based compiler.
https://github.com/TuringLang/Turing.jl/blob/0ecf959b1554cf6df970458d22807e4cf24bda2e/src/core/compiler.jl#L256

Thanks for the review @willtebbutt. I will fix it up.

Thanks. Btw, this is for you @yebai and @willtebbutt. I hope that's what you meant by phase-based compiler.

This is the general idea. We'll need a mechanism to allow people to add passes that aren't hard-coded into the compiler though. I'm not sure what that would look like, and we can leave it for another PR.

Changes look good to me. Great work @mohamed82008

Thanks, @mohamed82008. Could you add a test for https://github.com/TuringLang/Turing.jl/issues/544?

Sure, I can do that.

Look good to me. The only comment I have is that the sample function parametrisation is currently inconsistent. Sometimes you changed it to expect a model::Model and sometimes a model. Maybe it would be good to unify this so that all the sample functions expect a model::Model?

Maybe it would be good to unify this so that all the sample functions expect a model::Model?

Sure I can do that.


Question on aft-account-suspend-close-solution

Hi,
We were looking into potentially using the solution for account decommissioning for AFT as in https://github.com/aws-samples/aft-account-suspend-close-solution and notice that it seems to be missing steps for cleaning up the Terraform state in the S3 Backend.
Is there a reason for this, or should it be added as an additional step when adopting the solution?
Also does it matter if the account customisation is removed and resources in the account terminated before kicking off the account closure workflow? You can close an AWS Account with existing resources normally but will be charged if the account is brought back from suspension - https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html

I missed from the original question, but the pipeline for the account wouldn't appear to be removed by this solution from the control tower deployment account, is this correct or is there some logic that removes it outside of the lambda function?


Line blocks

[x] Find out what constitutes a line block (is it just the part in the screenshot with the grey text + grey line to the left, or is it also / or the top part that says "This is a line block...") + what we need a design for
[x] Design for "block quotes"

Here's a screenshot of the "Line Block" section of the Kitchen Sink:

@codemonkey800 I am trying to figure out what counts as a "line block" in this PyData theme... in the screenshot above, right below "Line blocks" it says "This is a line block." and then "This is a second line block." a little further down. But both look just like normal text to me. But then further below, it has the grey chunk of text with the grey line next to it.
So what is a line block? Is it the grey text with the grey line next to it? Or the text above it (that looks like normal text to me)? Or are both different varieties of line block?
Just curious if you can tell from the code?

a line block is a single line of text where each line is determined by the pipe character |, so users can write manually write really lines of text without the browser causing a line break.
| This is a line block.  It ends with a blank line.
|     Each new line begins with a vertical bar ("|").
|     Line breaks and initial indents are preserved.

Here, each new line corresponds with a beginning pipe character, and empty spaces are preserved.
| Continuation lines are wrapped portions of long lines;
  they begin with a space in place of the vertical bar.
|     The left edge of a continuation line need not be aligned with
  the left edge of the text above it.

Finally, if you indent a line block by 4 spaces, it'll wrap it in a block quote:
    | A one, two, a one two three four
    |
    | Half a bee, philosophically,
    |     must, *ipso facto*, half not be.
    | But half the bee has got to be,
    |     *vis a vis* its entity.  D'you see?
    |
    | But can a bee be said to be
    |     or not to be an entire bee,
    |         when half the bee is not a bee,
    |             due to some ancient injury?
    |
    | Singing...

Here's a link to the design for block quotes:
https://www.figma.com/file/ahjEJjeaFL6oTjeQaueGDQ/napari-Sphinx-Theme?node-id=33%3A512

Just needs to be updated so that there's 25px horizontal spacing between the black line on the left and the edge of the text. Now it has 17px spacing, and on both sides of the text (but should be 25px, and only on the left side of the text.)

The block quotes (with the black line to the left edge) look great to me now! But now I am realizing the "line blocks" (above the block quotes in the demo site) are the wrong size and color. They are 16px and #333333, but should be 17px and black. Other than that, this looks good to me!

Looks great!


fix(runtime-core): correctly infer TypeEmits with both tuple and function syntax

fix #11836

/ecosystem-ci run

I think this can't resolve the error.
https://github.com/zcf0508/volar-defineModel-tsx

It works on my machine.

It works on my machine.

I update vue-tsc from 2.1.2 to 2.1.6, and it works. Thank you.


Manage Html in Report engine

Add html as chunk to the document
Fix html insertion crash

Please check Codefactor issues


Create tutorial describing how to analyze data

This tutorial should guide you from sample selection to viewing your data using Qiita.

Already deployed: https://qiita.ucsd.edu/static/doc/html/analysisguides/index.html


Can't create custom types with Ant Task

I don't think it's possible to create custom types using AntMetaDataExporter, because there is no way of using an array of strings as a property. You are kind of stuck:
<queryDSLTask jdbcDriver="${db.driver}"
                  jdbcUrl="${db.url}"
                  jdbcUser="${db.username}"
                  jdbcPassword="${db.password}"
                  packageName="${package_name}"
                  targetFolder="${target}"
                  schemaPattern="${schemaPattern}"
                  <!-- customTypes="my.custom.types" throws unknown attribute exception -->
                  >
         <!-- Impossible to add custom types here. None of the following works: -->
         <!-- <customTypes></customTypes> throws unknown nested element exception -->

    </queryDSLTask>

I believe the solution is simple though: Use the same workaround as typeMappings, numericMappings and renameMappings. These all use ArrayLists and nested elements, which makes them work just fine.
    /**
     * custom type mappings to use
     */
    private List<TypeMapping> typeMappings = Lists.newArrayList();

    /**
     * Adds TypeMapping instance, called by Ant
     */
    public void addTypeMapping(TypeMapping mapping) {
        typeMappings.add(mapping);
    }

I would have fixed this myself, but I can't seem to create a new remote branch due to a 403.

I created a pull request for this:
https://github.com/querydsl/querydsl/pull/2054