Prevent Triggers overlapping

Azure documentation issue guidance
Thanks for opening an issue in the Azure technical documentation repository.
We use GitHub issues as the primary channel for customer and community feedback about the Azure documentation.
Creating an issue
We prefer that you create documentation feedback issues using the Feedback link on the published article - the feedback control on the doc page creates an issue that contains all the article details so you can focus on the feedback part.
You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
[ ] A link to the published documentation article that you have feedback about.
[ ] Clear, specific feedback that the author can act on.

Pull requests and article contributions
If you know the change that is needed in an article, we encourage you to submit the changes directly using a pull request. If the change is large, or if you want to contribute an entire article, follow these guidelines:

[ ] Don't surprise us with a big pull request or a pull request with a new article! Submit an issue that describes the details of the proposed large change or new article.
[ ] Include the service or technology area.

We'll route the issue to the appropriate content team for review and discussion.
Tech support and product feedback
If you would like to contact Microsoft about other things, such as product feedback or tech support, please review these guidelines:

If you need technical support using Azure, the paid and free support options are described here: https://azure.microsoft.com/support/options/.

Each article in the Azure technical documentation contains a product feedback button - it's best to submit product feedback directly from a relevant article. Otherwise, you can submit product feedback for most Azure products in the following product feedback forum: https://feedback.azure.com/forums/34192--general-feedback.

How do you prevent a trigger from starting if there is trigger still running?

@avfc1982, Thanks for leveraging Azure docs feedback channel to raise this question! Could you please share the document that this feedback is applicable to?

It’s for any pipeline created, when there is Trigger applied to it and let says it is scheduled to run every 10 minutes but one of the pipeline runs takes longer that 10 minutes it will automatically trigger off another run. You would not have this issue for a scheduled SQL Job as it knows there is already a schedule running.

@avfc1982, Thanks for sharing more details on your scenario.
Since this channel is reserved for ‘Azure docs’ questions, we recommend posting technical questions on the technical forum where one of our specialized engineers in the subject or the Azure community members can provide the best possible answer to your scenario or question.
We will now close this issue in GitHub but hope to engage with you via our technical forums shared above.


Adding typing for creating a pyspark dataframe from a list of dicts

What changes were proposed in this pull request?

Add so that a python dict can be typed as RowLike
Why are the changes needed?

In the examples for creating a pyspark dataframe using spark.createDataFrame there is an example code snippet for passing a list of dicts:
https://github.com/apache/spark/blob/3d063a01d7c2a6d9613e11dec882739daa7eeb71/python/pyspark/sql/session.py#L1404-L1412
Though in the typing of this method it accepts an iterable of "RowLike" objects
https://github.com/apache/spark/blob/3d063a01d7c2a6d9613e11dec882739daa7eeb71/python/pyspark/sql/session.py#L1245-L1251
Where a dict is not a RowLike object
https://github.com/apache/spark/blob/3d063a01d7c2a6d9613e11dec882739daa7eeb71/python/pyspark/sql/_typing.pyi#L60
Creating a dataframe from a list of dicts works fine, but the typing of it doesn't (using mypy)
Does this PR introduce any user-facing change?

Yes, users would correctly test for typings when passing a list of dicts in the createDataFrame method.
At the moment, users would get
error: Value of type variable "RowLike" of "createDataFrame" of "SparkSession" cannot be "dict[str, Any]"  [type-var]
when using mypy for static type checking the following code snippet
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("SimpleApp").getOrCreate()

d = [{"name": "Alice", "age": 1}]
spark.createDataFrame(d).show()

while the expected result would be
Success: no issues found in 1 source file
How was this patch tested?

Haven't setup a local environment for testing the repo. Can do this if I get a heads up that I am on the right track.
Was this patch authored or co-authored using generative AI tooling?

No

Can we file a JIRA, and add it into the PR title?

I'm not a member of Jira, could I get help with filing a new JIRA?


Add drive setup

We have another subdomain on twolfson.com for hosting static files. It would be nice to add that to this repo as well.

This has been completed in 1.8.0 :tada:


Automated cherry pick of #4791

Cherry pick of #4791 on release-5.21.

#4791: wip

/cc  @Willyfrog

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.


pom.xml is not able to recognize 2.0 version and getting null pointer except in TimeUtil.java

I am using below dependency for influx db java connector but pom.xml couldn't find it.

org.influxdb
influxdb-java
2.0

then I try to take the source code and compile it locally and generated influxdb-java-2.0-SNAPSHOT.jar but this is giving the null pointer exception which I believe already resolved in https://github.com/influxdb/influxdb-java/issues/63 but some how it is not available in the head.
Can you please help how to resolve this ?
Exception in thread "main" java.lang.NullPointerException
at org.influxdb.impl.TimeUtil.toTimePrecision(TimeUtil.java:21)
at org.influxdb.impl.InfluxDBImpl.write(InfluxDBImpl.java:155)
at com.relcy.analytics.influxdb.InfluxDbHelper.insertUserMetrics(InfluxDbHelper.java:55)
at com.relcy.analytics.kafka.consumer.SystemUserAnalyticsConsumer$4.call(SystemUserAnalyticsConsumer.java:95)
at com.relcy.analytics.kafka.consumer.SystemUserAnalyticsConsumer$4.call(SystemUserAnalyticsConsumer.java:1)

2.0 is not published
http://search.maven.org/#search|gav|1|g%3A"org.influxdb" AND a%3A"influxdb-java"

How do I workaround the null pointer exception ?

@majst01 any suggestion ? I am bit stuck at this point.

Hi,
you are not using the latest version, try to clone this repo and build it in you environment.
Publishing to maven is currently going further.

Thanks @majst01. with the latest build null pointer exception is gone and I see below logs in influx db log file.
[wal] 2015/10/27 00:32:06 WAL writing to /var/opt/influxdb/wal/metric/default/165
[http] 2015/10/27 00:32:06 <IP_ADDRESS> - admin [27/Oct/2015:00:32:06 +0000] POST /write?consistency=all&db=metric&p=%5BREDACTED%5D&precision=ms&rp=default&u=admin HTTP/1.1 204 0 - okhttp/2.4.0 2694ee30-7c42-11e5-81b0-000000000000 12.838617ms
[wal] 2015/10/27 00:32:11 Flush due to idle. Flushing 492 series with 492 points and 30081 bytes from partition 1
[wal] 2015/10/27 00:32:11 write to index of partition 1 took 55.341207ms
[wal] 2015/10/27 00:32:12 Flush due to idle. Flushing 1 series with 1 points and 56 bytes from partition 1
[wal] 2015/10/27 00:32:12 write to index of partition 1 took 3.990452ms
[wal] 2015/10/27 00:32:18 Flushing 1 measurements and 1 series to index
[wal] 2015/10/27 00:32:18 Metadata flush took 1.222764ms
[wal] 2015/10/27 00:32:20 Flushing 1 measurements and 1 series to index
[wal] 2015/10/27 00:32:20 Metadata flush took 1.329047ms
[wal] 2015/10/27 00:32:21 Flush due to idle. Flushing 495 series with 495 points and 30258 bytes from partition 1
[wal] 2015/10/27 00:32:21 write to index of partition 1 took 60.292042ms
[wal] 2015/10/27 00:32:26 Flushing 1 measurements and 1 series to index
[wal] 2015/10/27 00:32:26 Metadata flush took 1.304345ms
[wal] 2015/10/27 00:32:31 Flush due to idle. Flushing 495 series with 495 points and 30276 bytes from partition 1
[wal] 2015/10/27 00:32:31 write to index of partition 1 took 62.045692ms
[wal] 2015/10/27 00:32:41 Flush due to idle. Flushing 495 series with 495 points and 30285 bytes from partition 1
[wal] 2015/10/27 00:32:41 write to index of partition 1 took 59.612456ms
[wal] 2015/10/27 00:32:51 Flush due to idle. Flushing 495 series with 495 points and 30285 bytes from partition 1
[wal] 2015/10/27 00:32:51 write to index of partition 1 took 79.522433ms
[wal] 2015/10/27 00:32:58 Flushing 1 measurements and 1 series to index
[wal] 2015/10/27 00:32:58 Metadata flush took 1.430121ms
[wal] 2015/10/27 00:33:01 Flush due to idle. Flushing 495 series with 495 points and 30285 bytes from partition 1
[wal] 2015/10/27 00:33:01 write to index of partition 1 took 66.396521ms
[wal] 2015/10/27 00:33:02 Flushing 1 measurements and 1 series to index
[wal] 2015/10/27 00:33:02 Metadata flush took 1.228731ms
how ever I don't see any data is being persisted on influx db. I am quite puzzled now. any thoughts would help.


Reddit thread is closed to new comments

The Reddit thread posted in the README section is now closed to new comments.

thanks for letting me know!


Make excluded_exceptions look at the exception cause

When any exception occurs in a template, Rails will raise a ActionView::Template::Error:
https://github.com/rails/rails/blob/a0277a974ce881d975b13634bcc7da17bc906844/actionview/lib/action_view/template.rb#L156-L163
These errors aren't filtered out by excluded_exceptions because it doesn't look at the cause of the error. Which means we get a lot of errors reported that we intended to filter.
We could change this behaviour by changing this:
https://github.com/alphagov/raven-ruby/blob/f4338fb64bb86e1ea58e0863f03223e7650e8607/lib/raven/configuration.rb#L330-L332
Into something like:
def excluded_exception?(exc)
  excluded_exceptions.any? do |x|
    exception_class = get_exception_class(x)
    exception_class === exc || exception_class === exc.cause
  end
end

Before I make a PR, can we think of unintended consequences of a change like this? Are there other reasons to just look at the raised exception?

can we think of unintended consequences of a change like this?

Well it's a major change in which exceptions are captured. I would only do this in the next major. I'll have to think about it.

Would you be open to a pr implementing something like this, with the behavior being toggled by a new configuration option that defaults to off? That way it wouldn't impact any current users, so I'm hoping that means it wouldn't need to wait for a major version change. Thanks!


Update README.md to reflect the current situation

There are several changes:

Announce that Clang 3.9 is the new default
Update the install steps for 3.9
Add installing steps for Windows
Update stylo's usage of bindgen

@bors-servo delegate+

:v: @upsuper can now approve this pull request

@bors-servo r=emilio

:pushpin: Commit a65e825 has been approved by emilio

:hourglass: Testing commit a65e825 with merge d49bae2...

:sunny: Test successful - status-travis


[Event Hubs] Partition load balancer implementation in Event Processor

The goal is to implement an algorithm that would (almost) evenly distribute ownership of Event Hub partitions among all the active Event Processors registered for a given Event Hub + consumer group combination. Each event processor is responsible for processing events from the partition it owns.
Use https://gist.github.com/srnagar/7ef8566cfef0673288275c450dc99590 algorithm to implement partition load balancer.

Done with https://github.com/Azure/azure-sdk-for-js/pull/4839


Add Morpho Safe Apps (2 apps: morpho-aave, morpho-compound)

Revision checks

[x] Used smart contracts were audited.
[x] Your Safe App include a manifest.json file at the root with the required data. (It is here for morpho-aave and here for morpho-compound
[x] The app can be loaded as a custom Safe App in the Apps section of https://app.safe.global.
[x] The app auto-connects to the Safe.
[x] You are able to trigger and execute one transaction with a Safe.
[x] RPC requests are optimized (not triggering many requests in a very short time period).

Name/Description

Type

2 New additions

Compatible Networks

- Mainnet

Audit document
Link to smart contracts audit.
Code for review
https://github.com/morpho-labs/morpho-dapp
IPFS hash/App URL
https://aave.morpho.xyz
https://compound.morpho.xyz
Desired date
We don't have a precise date in mind. We plan to do a stealth launch for this version, we are releasing a more UX-friendly version, but some users already asked us for a safe app. Thus as soon as possible would be our date, but no blocker.

Hey @tomrpl good work there. I'm just curious on why you created a specific tab for the Safe App. Wasn't it working directly with the normal sections or you had to apply some patches specific for the Safe?
In case you are going via the specific tab for the Safe, wouldn't it make sense to hide the normal sections from the app? There is some kind of redundancy there. Although, for your convenience I would skip the specific Safe tab and try to make it work with the normal sections.
As feedback, I'm not able to scroll in the normal sections when I have content out of the view space.

Hi @dasanra, I'm the one working on the safe app. The idea is to have the same application as on the classic dapp, but with a tx builder in addition. The other pages work as on the classic app.
And if we remove the other pages, the user loses his global vision of the markets or of his dashboard. What do you think?

@dasanra any idea on that?

Now I understand. I see it's difficult to unify the composability UX in the normal dashboard. Would be interesting to see if you would be able to add it directly to the normal sections to be more transparent to the user 😉
Do you have also on your roadmap to unify both deployments into an unique interface that can switch protocols using some selector?

Hey guys, safe apps QA here. I have been playing with the apps for a bit and they look good to me 😄 As señor dasanra says I think it could make sense to have them both as one safe app but other than that, all good.
Cheers!

@dasanra @JagoFigueroa Thank you for your feedbacks! We are discussing on that for our new dapp version, but will probably not be included in the short term. (maybe in 2 months)
I can suggest you to only list morpho-aave app for now since morpho-compound is not really more attractive than compound now (peer to peer matching is disabled on all markets except for USDT market, due to Compound constraints)
We will keep you in touch when the refactored safe app is going to be live. on our side (probably with a dedicated url)
Is it clear and is it right for you?

@julien-devatom apps are already available in the list.
Feel free to ping us if you create a joint interface


Electrical.Machines.Sensors do not provide sensible unit but just Real instead

Reported by dietmarw on 12 Oct 2012 15:51 UTC
I noticed that the Sensors in Electrical.Machines.Sensors do not provide any kind of unit. E.g., it would be nice to also get the currents displayed as Amperes and not just as a real number.

Migrated-From: https://trac.modelica.org/Modelica/ticket/872

Comment by dietmarw on 12 Oct 2012 15:52 UTC
FIXED in aab9fac8133d0560657ea0c4356961d49e7eab44 by adding the different unit definitions to the outputs.

Modified by dietmarw on 12 Oct 2012 15:53 UTC

Comment by anonymous on 15 Oct 2012 07:22 UTC
Why not using proper quantity types instead of reals having a unit?

Comment by dietmarw on 15 Oct 2012 07:31 UTC
Because that would mean defining additional connectors for each unit one would like to use which I think is introducing an unnecessary level of complexion.

Comment by anonymous on 15 Oct 2012 07:57 UTC
I see. Thanks for clarification.
But please make it consistent throughout the entire MSL

Majority of sensor outputs is unitless. See e.g. Modelica.Mechanics.Rotational.Sensors, Modelica.Mechanics.Translational.Sensors or Modelica.Thermal.HeatTransfer.Sensors
Sensors of Modelica.Mechanics.MultiBody.Sensors have both final quantity and unit modification, e.g.

Blocks.Interfaces.RealOutput r[3](each final quantity="Position", each final unit = "m")

Comment by dietmarw on 15 Oct 2012 08:33 UTC
The units for Electrical.Machines.Sensors are now more consistently defined since 520235f19ea869ca96e30160888a3c25001ebc09. For the rest look individual ticket #876


Get-DbaAgentJob fails to write out to data table

Writing result out to database table results in an error using the function Get-DbaAgentJob. I use similar commands with many of the dbatools functions but normally together with Get-SqlRegisteredServerName and it works generally.  This works with with for example Get-DbaRunningJob, Test-DbaJobOwner and many more.
When running the following command:
$result = Get-DbaAgentJob -SqlInstance INSTANCENAME  | Out-DbaDataTable  Write-DbaDataTable -InputObject $result -SqlServer INSTANCENAME -Table SqlManagementRepository.dbo.SqlAgentJobs -AutoCreate -Confirm:$false
It results in following error.

Exception calling "WriteToServer" with "1" argument(s): "The given value of type Guid from the data source cannot be converted to type varchar of the specified target column."
At line:356 char:4

        $bulkCopy.WriteToServer($InputObject)

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
FullyQualifiedErrorId : InvalidOperationException

Actually there is nothing wrong with Get-DbaAgentJob.
We could add a property with the GUID as string, but I don't feel that's the right decision.
@ctrlbold @wsmelton
@peturgretars you can either change the datatype of your destination column to Uniqueidentifier, or put a Select-Object between Get-AgentJob and Write-DataTable to cast the Guid to a string, which will be imported into a varchar().
In the near future it may be necessary to do the same for existing functions, since we have some that are now returning PSCustomObjects (containing strings and numbers), but will return the original objects when we rewrite them.

@PowerDBAKlaas
Thanks for this update. It works when selecting columns.


[SonyLiv]Fix key extraction and add series key.

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Bug fix
[x] Improvement
[ ] New extractor
[ ] New feature

Description of your pull request and other information
Explanation of your pull request in arbitrary form goes here. Please make sure the description explains the purpose and effect of your pull request and is worded well enough to be understood. Provide as much context and examples as possible.
Previously it was appending the Series name and Episode title.
Now title is episode title and series title is separate.
title = metadata['episodeTitle'] this works for movies as well.

Please confirm that the title gets extracted correctly for all types of URLs
https://www.sonyliv.com/shows/bachelors-delight-1700000113/achaari-cheese-toast-1000022678?watch=true
https://www.sonyliv.com/movies/tahalka-1000050121?watch=true
https://www.sonyliv.com/clip/jigarbaaz-1000098925
https://www.sonyliv.com/trailer/sandwiched-forever-1000100286?watch=true
https://www.sonyliv.com/sports/india-tour-of-australia-2020-21-1700000286/cricket-hls-day-3-1st-test-aus-vs-ind-19-dec-2020-1000100959
https://www.sonyliv.com/music-videos/yeh-un-dinon-ki-baat-hai-1000018779

https://www.sonyliv.com/trailer/sandwiched-forever-1000100286?watch=true
https://www.sonyliv.com/sports/india-tour-of-australia-2020-21-1700000286/cricket-hls-day-3-1st-test-aus-vs-ind-19-dec-2020-1000100959

It's working for all but these 2, not bcoz there's problem with edits i made, but with ytdlp or sony itself...maybe it's bcoz the match was live and now url changed and the trailer is removed as movies was released.
IMO my commit is okay to be merged but if you want me to test for trailer and sports then lemme know.

Those are just URLs from the test. You don't need to test for them specifically, but just any trailer and sports video

Those are just URLs from the test. You don't need to test for them specifically, but just any trailer and sports video

works for this
https://www.sonyliv.com/sports/abu-dhabi-t10-league-2021-1700000666/cricket-hls-devils-vs-qalandars-29-jan-2021-1000106285?watch=true


Initial work on LoRa ACKs

These are inital changes to the dev branch in order for LoRa to support ACK packets.   It is not yet totally working.  Sender and Receiver CRCs do not match and there is some work to be done to test bad CRC and adding ability to disable ACK replies on sensor side.
I've tested my code in Arduino 1.8.19 both the FDRS_Sensor and FDRS_Gateway and it should compile in both.
Todo:
Figure out why Sender and receiver CRC does not match
Confirm sensor receives ACK from gateway
Test scenario where CRC does not match
Add sensor functionality to disable ACKs from gateway

Not sure how to associate this with #54.  I see DBGLN so I'll have to create another commit to change those back to DBG.  Ugh.


completed exposed current todolist

this will expose the current todolist in the todo component

hey @akinolu52 my task was blocked by this and once i jumped into it i started tweaking other things to make my life easier and then added in some other fixes for other components i needed too.
its all on this PR => https://github.com/web3ui/web3uikit/pull/412
Sorry you spent time on this, its all great code. TY for the hard work


Improve ODK-X Services Test Coverage: Write Test for service class in the Application package

The Services class in the org.opendatakit/services/application package extends ToolAwareApplication and implements IToolAware. This class manages Firebase Analytics initialization and logging upon app creation, and includes a deprecated method to get a context instance.
Tasks for this issue:

Write unit tests to ensure the correct initialization and logging of Firebase Analytics events.
Test the singleton implementation and ensure the _please_dont_use_getInstance() method behaves as expected, even though it is deprecated.
Verify that the getApkDisplayNameResourceId() method returns the correct resource ID.

This issue aims to improve code coverage and ensure the stability of the Services class functionality.

@wbrunette  @Lamouresparus
am working on this ticket

The Services class in the org.opendatakit/services/application package extends ToolAwareApplication and implements IToolAware. This class manages Firebase Analytics initialization and logging upon app creation, and includes a deprecated method to get a context instance.
Tasks for this issue:
* Write unit tests to ensure the correct initialization and logging of Firebase Analytics events.

* Test the singleton implementation and ensure the _please_dont_use_getInstance() method behaves as expected, even though it is deprecated.

* Verify that the getApkDisplayNameResourceId() method returns the correct resource ID.

This issue aims to improve code coverage and ensure the stability of the Services class functionality.

@Agaba-derrick
I will suggest we work on #507  first, as that is more beginner friendly, before working on this. But if you feel confident, you can go ahead :)


test on lts and pre

Julia 1.11 changes the random streams. Unfortunately, that means basically all ref tests broke. Not sure how to prevent this in the future without cluttering the examples with explicit stable rng code and pass it to the layout kw of every single plot command...

We're facing the same issues in our tests. Besides passing around a StableRNG the other alternative I could think of is having version-dependent reference images, i.e. store one set of images for Julia 1.10, one for Julia 1.11, etc. (I'll do that for now since the StableRNGs.jl approach requires https://github.com/JuliaGraphs/NetworkLayout.jl/pull/65 but I'm not sure how automated it will be, i.e. it will be annoying to have to generate new images for now versions so that ideally should be automated).


[HTTP API] Can queries that return partial transaction payloads be trusted?

There are currently many open issues, that wish to provide queries via the HTTP API on certain aspects of transactions, such as assets, and owners (public keys). Such issues propose to return partial chunks of a transaction payload.
How can an API consumer trust such responses?
Transaction payloads that use the ed25519 signature scheme can be verified to be authentic, provided one has the entire payload. It is important to note that the message used to form the signature is the entire transaction payload, except for the fulfillment uri(s). Thus, in order to verify the authenticity of a transaction payload one needs the entire transaction.
Why does this matter?
It seems that the structure and content of the transaction payload has been and is being influenced by the idea of querying it. But of what value is a response coming from a BigchainDB federation that cannot be verified to be authentic?
If we think of applications that may depend on the data they read, and make critical decisions based on that data. If the data cannot be trusted, we put these applications at risk.
Moreover one could as well dump all of BigchainDB data in whatever data store one prefers, and build the querying layer on top of it. At least they could be controlling the machines on which the querying is happening against, and also have the freedom to choose the querying/searching engine they are most comfortable with.
Basically: should BigchainDB provide querying beyond transactions. blocks and votes at all? These three main components have the possibility of being verified, whereas partial constructs do not.
Also, should we sacrifice the simplicity of the transaction payload for the sake of being able to query chunks of it that cannot be trusted?
What is BigchainDB's main purpose?
Could querying be offloaded to add-on layers? Different applications may need different types of queries, for which different data stores may be better than others. So why limit users to a particular type of querying? More concretely, some applications may need to establish interconnections between different transactions, or characteristics, in such a way that a graph database will be best suited. Others may need to perform information retrieval tasks, such than a search engine like elasticsearch is best suited.
We also need to keep in mind that by offering a metadata field, the possibilities are more or less infinite.
Proposal

Keep querying capabilities of BigchainDB simple, such that responses preserve the level of authenticity that can be provided via cryptoconditions.
Identify the type of querying that may potentially be relevant: graph, text search, relational, etc.
Think of ways of how data could be piped into different data stores dedicated to specific types of querying.
Ask whether we really need to implement one or more of the ways, defined in 3, above.

If for whatever reason, the above 4 points are rejected. Then the question that remains, would be "How can we make querying trusted in the context of a decentralized architecture?"
We have to keep in mind that many organizations make critical decisions based on data. Hence reading data, is one thing, trusting it is another.
What is the value of data that cannot be trusted?

Good point, thanks for bringing this up.
I think the problem your outlining can be split into multiple sub problems. I'll try to answer some of them. Could be that I'm forgetting some though.
1. How can I validate that was I requested is what I get
For transactions and blocks, the answer is easy:
You take the id if the object, hash the message again and compare the two values. If they're equal you've retrieved the right thing.
OK, but what if we just return partial payloads as was proposed in #830?
Obviously there it becomes tricky. When making a request like:
/transactions?fields=id,conditions&fulfilled=false&owners_after={owners_after}
you cannot validate against the provided transaction id anymore.
What you can validate though is the validity of the condition, as it's uri is provided.
So how to resolve this?
One approach I could imagine, is to hash the transaction as a merkle tree and then follow the branch that was returned upwards. I'm not an expert on this, but here is how this could potentially look like:

In fact, IPLD does exactly this kind of thing with JSON, which helps solve this use case quite well I believe.
2. How can I validate that something should be there?
Now, providing some hash/id and retrieving something that is known already seem to be rather straight forward. What about retrieving something that the user it not aware of?
Lets compare the two use cases to highlight the differences once again:

Retrieve object by id/hash and validate if return value is according to id/hash
Retrieve or rather search for things that are unknown.

Examples of this could be something like:

Give me all conditions that correspond to a certain public key
Give me all assets that match a certain uuid (which is not a hash, meaning I cannot verify against it).

For this, I currently have no ideas. It's probably a whole different ticket/concern.

Thanks @TimDaub !
Regarding the first part, the Hash Tree approach: good idea! But don't you need more than what you query in order to verify the authenticity of what you retrieved?
Considering the graph you gave above. If one retrieves conditions. In order to verify the authenticity one would still need other data, namely:

hash(fulfillments), with which one can calculate the hash(hash(condition) + hash(hash(fulfillments)
hash(hash(asset) + hash(metadata))
txid

It's true that one needs less, for instance one does not need to retrieve the asset and metadata, nor their individual hashes, but one still needs the right hand side node leading up to the root of the tree.

follow the branch that was returned upwards

So yes, but one needs each sibling of each node on the path of that branch.
Hash trees make membership verification more efficient, than a list, but we still would need to return more than what was queried, it seems.
Some useful references:

http://bitcoin.stackexchange.com/a/38399/36231
https://www.quora.com/Cryptography-How-does-a-Merkle-proof-actually-work

It's true that one needs less, for instance one does not need to retrieve the asset and metadata, nor their individual hashes, but one still needs the right hand side node leading up to the root of the tree.

Exactly.
We would have to send this information about the merkle tree with the JSON.
Hence in #830, I decided to remove ?fields until we implement a merkle-tree inspired approach.

@sbellem Would you be OK if we create a ticket outlining how a concept like?fields (partial payloads essentially) should be implemented using merkle tree and close this ticket as its formulated more as a question and not as an actual task?
I can create the other ticket if you want.

@TimDaub You can create the ticket for the fields approach, and I can create the other tickets because this issues raised more than one question I think, so I will create tickets accordingly.

Why adding complexity to the system if the client can just:

retrieve the transaction.
ignore everything and get just the payload.

What's the use case?

Why adding complexity to the system if the client can just:
retrieve the transaction.
ignore everything and get just the payload.

What's the use case?

Yes, transactions are atomic objects in that sense, and the server returns only these atomic objects. Consumers interested in parts are responsible to pick the transaction apart for what they need.


[FR] Support for classic markdown links

It would be nice to add support for standard markdown links for files: [text](link). I did not find similar requests, perhaps my proposal has already sounded before.
Main reason: classic formatting is supported by all markdown editors and in this case there are no difficulties in portability of notes

I also feel that, sometimes, writing a description instead of just a link is a good way to keep in mind the « how and why is this link related to the note ? », but I'm not a long time zetel guru, so I don't know if it's a good practice :-)

Yes, this is definitely something we should support.
This was already discussed here: https://github.com/renerocksai/telekasten.nvim/discussions/56#discussioncomment-1977177

Is someone working on this right now?

Having the option to use standard markdown links [link name](filename) feels essential. I'm looking stop using Vimwiki and Telekasten looks like a great solution, but being required to use a non-markdown link format might be a dealbreaker.
A couple considerations regarding links...

One trouble with Vimwiki is in its linking and filepath recognition. There's no support for ~/dir (relative to home) style links, so if you're in a deep subdirectory you've got to count: should this be ../../../../dir or ../../../../../dir? for example.
path-based autocompletion when typing the link (completing the paths and filenames) would be so excellent :)

Right now I'm using another note-taking plugin that supports both kinds of links + some other features (wiki.vim). Together with the telescope, the functionality is more than satisfied

Is someone working on this right now?

Unfortunately, I have very little time to work on TK at the moment. Same for renerocksai. This FR is a massive task I beleive, so I'd rather focus the few hours I have for fixing urgent bugs instead. It will have to wait a bit more or have someone else step in.

* One trouble with Vimwiki is in its linking and filepath recognition. There's no support for `~/dir` (relative to home) style links, so if you're in a deep subdirectory you've got to count: should this be `../../../../dir` or `../../../../../dir`? for example.

IMO normal markdown links should either work with relative paths (to zettelkasten home) or with absolute ones.

* path-based autocompletion when typing the link (completing the paths and filenames) would be so excellent :)

Path autocompletion can be acheived with other plugins (nvim-cmp for instance). However, telekasten has a very cool insert_link function that makes it even much simpler to insert a link to a note (as long as it is in you ZK home or a subdir of it). With that function, you do not even need to bother with its actual path.

Path autocompletion can be acheived with other plugins (nvim-cmp for instance).

Agreed! The appropriate way to solve.

IMO normal markdown links should either work with relative paths (to zettelkasten home) or with absolute ones.

I'm not clear on your thoughts here...

do you mean telekasten should be able to work with both of those?
how about recognizing ~/Docs as /home/user/Docs? (does that wall within 'absolute ones'?)

This FR is a massive task I beleive,

Do you have much of an idea about how it should be done, like if someone shows up here eager to implement this... can you suggest the way forward with it?
Thank you!

I just noticed this https://github.com/renerocksai/telekasten.nvim/pull/120 and so I suppose my last question of "how to proceed" might vary a bit based on before/after refactoring.

* do you mean telekasten should be able to work with _both_ of those?
* how about recognizing `~/Docs` as `/home/user/Docs`? (does that wall within 'absolute ones'?)

Yes it should work on both. This should not be that difficult with Plenary. We already use Plenary for lots of stuff so eventually it is just a matter of manipulating paths properly. This is the "easy" part :smile: .

Do you have much of an idea about how it should be done, like if someone shows up here eager to implement this... can you suggest the way forward with it?

No particular idea. The code base is a bit of mess at the moment. As you mentioned, I started refactoring it a bit in #120, but I had lots of stuff happening at work and crazy deadlines to met for the following weeks/months, so I cannot even go further on that. Basically what is difficult is that:

TK currently relies on link type (markdown vs wiki) to determine if something is a file or a media, if I recall correctly. So this logic should be changed as well.
TK is relies heavily on regex for lots of stuff. These regex are much too complex IMO (#135) and would likely need to be modified to support the other types of links.
Probably other stuff that I cannot think like that on the top of my head.

These make it very difficult to do the changes in all the correct spot. It will also likely considerably lengthen and complicate the code with big if/else statements for the various cases. This is why I wanted to do a proper refactoring before adding more complex features.
In my opinion, the refactoring should clearly help separate:

the config and initial setup of the plugin
the pickers
the link parsing and formatting logic
the tag parsing logic
the templates
various small utilities functions
(LSP stuff)

Once this is done, it will become much simpler to simply amend the link parsing stuff to allow different types of links.

Nice. Thanks for explaining!!!
On 22/07/07 04:56AM, lambtho wrote:

* do you mean telekasten should be able to work with _both_ of those?
* how about recognizing `~/Docs` as `/home/user/Docs`? (does that wall within 'absolute ones'?)

Yes it should work on both. This should not be that difficult with Plenary. We already use Plenary for lots of stuff so eventually it is just a matter of manipulating paths properly. This is the "easy" part :smile: .

Do you have much of an idea about how it should be done, like if someone shows up here eager to implement this... can you suggest the way forward with it?

No particular idea. The code base is a bit of mess at the moment. As you mentioned, I started refactoring it a bit in #120, but I had lots of stuff happening at work and crazy deadlines to met for the following weeks/months, so I cannot even go further on that. Basically what is difficult is that:

TK currently relies on link type (markdown vs wiki) to determine if something is a file or a media, if I recall correctly. So this logic should be changed as well.
TK is relies heavily on regex for lots of stuff. These regex are much too complex IMO (#135) and would likely need to be modified to support the other types of links.
Probably other stuff that I cannot think like that on the top of my head.

These make it very difficult to do the changes in all the correct spot. It will also likely considerably lengthen and complicate the code with big if/else statements for the various cases. This is why I wanted to do a proper refactoring before adding more complex features.
In my opinion, the refactoring should clearly help separate:

the config and initial setup of the plugin
the pickers
the link parsing and formatting logic
the tag parsing logic
the templates
various small utilities functions
(LSP stuff)

Once this is done, it will become much simpler to simply amend the link parsing stuff to allow different types of links.
--
Reply to this email directly or view it on GitHub:
https://github.com/renerocksai/telekasten.nvim/issues/126#issuecomment-1177492426
You are receiving this because you commented.
Message ID: @.***>

Waiting for this to switch to telekasten

Would be awesome to have this supported!  Navigation of notes in wiki form would be a amazing feature : D

I've done some work on the refact branch for the refactor, and it's definitely nowhere near complete, but as this is the only real missing critical feature for me, I think it's time I step away from that process and address this.
The current state of the refact branch is that main has been merged in, and a lot of the easier changes, like moving functions to more appropriate modules, some elucidating comments, etc., have been made. There's a lot of work to be done still, and I hope to come back to it, but I also don't super want the headache of doing this in main and then merging it back into refact when most of the functions I have to modify have been rehomed in other files. Since this is going to be an in-demand feature, it will probably necessitate some extra work to clean up the current refactoring progress. It's not quite where I'd like it to be for that, but I personally need the feature, so it's about time I address it.
I gave all the different functions a quick skim and took note of any that seemed to be directly working with links. It's possible something is missing from this initial assessment, but this to-do list should cover the vast majority of the work that needs to be done. Note that in a few places, primarily in functions dealing with images, I've marked that they appear at a glance to be already working with markdown links, but they will need a more careful analysis before they're officially considered done.

[ ] telekasten.lua

[ ] imgFromClipboard seems to generate properly, but verify this
[ ] InsertLink's attach_mappings replaces actions.select_default with a function that assumes wiki-style links
[ ] FindFriends's live_grep's default_text clearly assumes wiki-style links
[ ] YankLink assumes wiki-style links
[ ] InsertImageLink seems to automatically assume markdown links, but verify this
[ ] ShowBackLinks's live_grep's default_text assumes wiki-style links
[ ] FollowLink's check on kind needs to differentiate between a wiki link and a markdown link. I think? Even if not, check_for_link_or_tag probably should in its return

[ ] telekasten/config.lua

[ ] New config option needed to allow users to determine default link type, wiki or markdown

[ ] telekasten/pickers.lua

[ ] picker_actions.paste_img_link seems to use markdown image links, but verify this
[ ] picker_actions.paste_link assumes wiki-style links
[ ] picker_actions.yank_img_link seems to use markdown image links, but verify this
[ ] picker_actions.yank_link assumes wiki-style links

[ ] telekasten/utils/links.lua

[ ] generate_backlink_map's innermost for loop uses gmatch based on wiki-style links
[ ] rename_update_links assumes wiki-style links

[ ] telekasten/utils/taglinks.lua

[ ] is_tag_or_link_at needs logic reworked to differentiate between wiki-style (always internal links) and both internal markdown-style (i.e., linking to another note in the vault) and external markdown-style (e.g., a website link) links
[ ] _testme needs additonal entries to cover markdown-style link testing

All in all, this doesn't seem that huge. Kind of significant for sure, but relatively simple to fix in most of these cases. I'm wondering if I can do this somehow so that I can make a function or small group of functions that's called in all these different situations so that if we ever need to address the link structure again, say to implement issue #295, it doesn't require digging into all these different pieces again. If not, though, this should provide a good record for the future so that I or whoever comes next knows loosely what needs to be done to get it implemented.

Looking into this more, there seem to be only a couple things being done with links. Most functions that directly interact with links, the ones duplicating code and/or effort, either generate a link or generate a pattern for a link so they can parse it. I should be able to make a function to handle each of these two tasks, probably in telekasten/utils/links.lua, and have other functions call them to handle these things. That should make things a little easier to change if they ever need to, and it should also help the refactor effort.
The rest of the relevant ones do the actual work. Identifying types of links, resolving them, etc. There's not too much here, so I think it should be pretty manageable to get this handled soon. This will be going into the refact branch first since it both depends on and contributes to the refactor, but I'm hoping we can get refact merged into main soon afterwards.

That would be awesome! I cannot thank you enough for all the work you are currently doing on Telekasten. Keep it up!


on release, checksum file is "csstool" not "css"

see https://github.com/client9/csstool/releases
looks weird

normalized


Write README.md file

Write README file. It contains of:

introduce
goals
functions
technologies

Perhaps, mark the correct web browser and version number whereon running without problems.


[Event Request] Page 344 "Navigate" - New Event “OnAfterNavigateFindExtRecords”

Could we please have a new publisher “OnAfterNavigateFindExtRecords” at the end of the function “FindExtRecords” of Page 344 "Navigate"?
// >>>>>>>
OnAfterNavigateFindExtRecords(Rec,ContactType,ContactNo,ExtDocNo,FoundRecords);
// <<<<<<<
if not FoundRecords then begin
SetSource(0D, '', '', 0, '');
Message(Text001);
end;
// >>>>>>>>
[IntegrationEvent(false, false)]
local procedure OnAfterNavigateFindExtRecords(var DocumentEntry: Record "Document Entry"; ContactType: Enum "Navigate Contact Type"; ContactNo: Code[250]; ExtDocNo: Code[250]; var FoundRecords: Boolean)
begin
end;
// <<<<<<<<

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Create build pipeline

Create a build pipeline to create a docker image, push to Amazon ECR and trigger deploy.
TISNEW-3848

@Judge40 you'll need the aws task definition JSON file to go along with this build pipeline

@Judge40 you'll need the aws task definition JSON file to go along with this build pipeline

This is currently just the ECR part as a first step, I don't think it's needed until I work on deploying via the pipeline?


Hugo: more padding so search icon does not get cut off

Added more padding to the searchbar so the input part doesn't move over the search icon

For https://linear.app/usmedia/issue/CUE-272

Imported as https://review.gerrithub.io/c/cue-lang/cuelang.org/+/1167683.

Closed via 89478c1c44f88920efb60f6d11e2096b1c08f1d0.


Update the Documenation

The documentation needs a update.

All links are referenced to the old documentation.
The layout and design is very outdated.

Maybe a additional branch for a GitHub Page would be useful, to host the documentation and the examples #5?

Shall we start with a wiki or a jekyll page in gh-pages? Wiki would be easy to start, but we can't add any examples. Maybe something like this http://mistic100.github.io/jekyll-bootstrap-doc/?

I prefer the jekyll variant.

Any good theme you know of? I'd prefer something simple on one page with a TOC and just some links for examples. Did some research, but my favourite is still the one above. If someone feels bored it would also be easy to change due to its simplicity.

http://mistic100.github.io/jekyll-bootstrap-doc/
https://tangerine-lemon.cloudvent.net/
http://wiredcraft.github.io/carte/
http://www.tuicode.com/article/5747d65b6f6491c54812c20f
http://dbtek.github.io/dbyll/
http://idratherbewriting.com/documentation-theme-jekyll/
http://bruth.github.io/jekyll-docs-template/
http://digitalmind.ch/themes/docster-jekyll-theme/demo/

I like the design of http://mistic100.github.io/jekyll-bootstrap-doc/

I've set up the basic structure and copied some content. It's not something I want to show the world, just the foundation.
https://gmaps-marker-clusterer.github.io/gmaps-marker-clusterer/

Look awesome @Remo

Thanks! Just some examples missing and then we already have what google had. I left the links in the README till we have the advanced examples in our documentation.

It's not perfect, but I think it's already better than the old documentation. Going to close this.


Multiple improvements

Hi!
I want to say thank for your wonderful project and bring some useful improvements.

move project to go modules
remove vendor
use go embed instead of go-binary and remove all about old assets (go 1.16 feature)
pin cockroach version in tests
remove golang.org/x/tools/cmd/cover (not maintained and moved to standart library)
pin gox version (go 1.16 feature)
update ci to go 1.16

If some changes (as removing vendor) don't fit project, just say it.

@sosedoff, i have 2 questions:

can you update go to 1.16 in https://github.com/sosedoff/actions/blob/master/golang-build/Dockerfile
should i squash commits in this PR?

i see you're dropping support of earlier versions of go, whats the main reason for such a change?

(i think) it's acceptable to this project, because this is a binary, not a library.
main reason- go embed - you don't need to use out of box tools and have a lot of generated code: https://golang.org/pkg/embed/
it's also useful for use go install with pinned version of tooling (gox) - you can see at makefile.

Yes, this is primarily a binary tool, tho i want to have an option to support older go versions when it comes to building it from source (backwards compatibility).  Right now the project is still go-get'able, hence the assets included in the code.

Go Modules: I dont have any objection to switching to go modules, just didn't really have any time to get that done.
Go Embed: It looks promising, however I haven't switched to the latest 1.16 yet and will have to heck out the embed stuff first.

You might be packing way too many changes into a single PR, i would prefer to deal with scoped PRs, like dep -> go mod change as a separate isolated PR, the static assets change separately, etc etc.

I will made separate PRs. But they will depent on each other.
First will be go modules with remove vendor (with fixes) and will include

pin cockroach version in tests
remove golang.org/x/tools/cmd/cover (not maintained and moved to standart library)

Second will be with go 1.16 features

use go embed instead of go-binary and remove all about old assets (go 1.16 feature)
pin gox version (go 1.16 feature)
update ci to go 1.16

Ok?


feat(label): add "MultiPolyline2DSubcatalog" & "LabeledMultiPolyline2D"

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

52 of 54 (96.3%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 82.707%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

tensorbay/label/label_polyline.py
18
20
90.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
5132

Relevant Lines:
6205

💛  - Coveralls


Docker and licenced 3rd party packages

Investigate legality of sharing docker image with 3rd party packages

Can we mark this as done, did you reach any conclusions?

This can be marked as done. We're not redistributing libraries or dependencies, we're distributing a use-case of those libraries.


Adding sq translation

Hello!
Here you are a translations for sq locale.
TIA
Besnik

Here you are a translations for sq locale.

Can use this flag 🇦🇱 (Albania) for the icon in the languages?

Here you are a translations for sq locale.

Can use this flag albania (Albania) for the icon in the languages?

Here you are a translations for sq locale.

Can use this flag albania (Albania) for the icon in the languages?

Yes, you can. That’s the one. :) Thank you!

Yes, you can. That’s the one. :) Thank you!

Thanks to you for the translation 🙏🏾


[QA-245] Add SPoT permissions to CodeBuild policy

QA-245
What?
Adding permissions to the CodeBuild policy to allow the agent to call SQS queues and lambdas in the SPoT Build environment
Changes:

Added a mapping for the SPoT Build environment AWS ID
Added policy to access KMS keys relating to Request and Output SQS Queues in the SPoT Build environment
Added policy to interact with Request and Output SQS Queues in the SPoT Build environment
Added policy to allow invoking of lambdas in the SPoT Build environment
Picked up some file formatting changes

Why?
To support testing of SPoT scenarios, and directly creating/reading SQS events and lambda

Related:

#174

I don't think we should be executing cross-account from the performance testing stack.

I don't think we should be executing cross-account from the performance testing stack.

The performance test stack is designed to make calls to other non-production environments in order to simulate load


Support tuple of int for axis argument in average function

Currently average function supports int axis only. We need to support tuple axis.
numpy.mean supports tuple axis: https://docs.scipy.org/doc/numpy/reference/generated/numpy.mean.html
Thank you Satoshi Tsutsui!

fixed via #3118


BigPanda Plugin Developer Permissions

GitHub repositories
This repo
https://github.com/jenkinsci/bigpanda-plugin
GitHub users to have permission
@julioguereca
@goodwinjeremyr
@JuanDCardozo
@cjcrist
@lukej7
@PaulBaker27
@shikha-gaur
Justification
Hello,
We need to update the developers for the bigpanda plugin in the permissions/plugin-bigpanda-jenkins.yml

Removeerikzaadi
My user has changed from jguereca to julioguereca. I have since deleted the jguereca user

@lukej7 FYI

Hey,

Remove erikzaadi

You can do that yourself if you file a pull request to this repository and remove them from your permission file: https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-bigpanda-jenkins.yml

My user has changed from jguereca to julioguereca. I have since deleted the jguereca user

Same process applies like above.
I invited the users mentioned to the team associated with the repository.

@NotMyFault I did try creating a PR but was denied when attempting to push my local branch to the repo. The other user that we have in this project robstemen is currently on paternity leave

@NotMyFault I did try creating a PR but was denied when attempting to push my local branch to the repo. The other user that we have in this project robstemen is currently on paternity leave

Make sure you configured your fork as remote repository, instead of this repository because the latest change I can spot on your fork is from 2019.

@NotMyFault I might be misunderstanding the process I was trying to create a PR for this repo to update the developers for the plugin.
Your comment about the fork, is that for this repo or for the plugin?

Your comment about the fork, is that for this repo or for the plugin?

It targets this repository. There is no up-to-date branch on your fork of this repository from where you could file a PR which delivers the desired change. Hence, I mentioned the configuration above.

@NotMyFault Got it. This was my confusion. Thanks for the clarification

Glad it worked out for you!


Add the ability to pass your own PostCSS plugins

What are you trying to accomplish with this PR?
https://github.com/Shopify/slate/issues/540
This will allow the ability to pass Postcss plugins to the postcss-loader in the Webpack config.
This is a very simple version to start with, it could be improved by moving the Autoprefixer & CSSNano parts in to the slate.config.js so the user can control the order of them.
I opted to put the custom plugins before the Autoprefixer and CSSNano plugins as i think 99.2% of use cases will want their plugins before any of these so for the initial version it would make sense.
Happy to be pointed towards a relevant place to detail this change somewhere for people.
Checklist
For contributors:

[ ] I have updated the docs to reflect these changes, if applicable.

For maintainers:

[ ] I have :tophat:'d these changes.

I've long been unhappy with Slate's current implementation of its config -- thus I haven't moved forward with documenting it properly, expanding it, and reviewing PRs on it. I've been refactoring how we approach config with Slate (mostly internal) and it will affect this PR.
I will keep this PR open come the time I am able to look at it closer and potentially do a follow PR for it to work with the new config setup. Will keep you posted!

Sounds good to me @t-kelly, looking forward to see what you come up with.

Replaced by https://github.com/Shopify/slate/pull/753


Add spm workflows to AppCheck GHA

[ ] Re-enable cron
#no-changelog

I had the scheme names wrong. This latest commit should do the trick


UseHttps is inaccessible

ConfigureHttpsDefaults  operates with HttpsConnectionAdapterOptions type.
Whereas UseHttps extension method is defined for Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions type.
[Enter feedback here]

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

ID: 312df0ba-e769-c904-40b2-733c291704a0
Version Independent ID: fd9cc0c2-3ea3-f437-e0ac-8789fb96faf7
Content: Configure endpoints for the ASP.NET Core Kestrel web server
Content Source: aspnetcore/fundamentals/servers/kestrel/endpoints.md
Product: aspnet-core
Technology: aspnetcore-fundamentals
GitHub Login: @tdykstra
Microsoft Alias: riande

Associated WorkItem - 132844

Where in the article is the code you are referring to?

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
serverOptions.ConfigureHttpsDefaults(listenOptions =>
{
// ...
});
});
I think this is just unfortunate naming that confused me. I thought listenOptions is listenOptions indeed, so it must have UseHttps(). Which it doesn't.

It looks like this issue is resolved, so I'm closing it. Feel free to reopen if you want to continue the discussion.


catalog-backend: mark permission-related exports as alpha

Hey, I just made a Pull Request!
Marks all strictly permission-related exports in catalog-backend as alpha. There are permission-related properties on other exports, so this doesn't entirely protect us from future breaking changes, but it will certainly reduce the number.
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

For discussion - I think all permission- packages can be left as-is because they're inherently alpha packages, but what about @backstage/plugin-catalog-common? That only has permissions in it today, but it's a catalog package. Should we mark them as alpha too?

Related - I think all permission- packages can be left as-is because they're inherently alpha packages, but what about @backstage/plugin-catalog-common? That only has permissions in it today, but it's a catalog package. Should we mark them as alpha too?

Yes I think it still make sense to mark these as alpha even though it's the only exports currently 👍

@mtlewis could you make sure that the catalog-backend/package.json also gets these changes? :) https://github.com/backstage/backstage/pull/9820/files

@mtlewis could you make sure that the catalog-backend/package.json also gets these changes? :) https://github.com/backstage/backstage/pull/9820/files

Ah yep, thanks for flagging @jhaals! Done in e02960f30f.

Related - I think all permission- packages can be left as-is because they're inherently alpha packages, but what about @backstage/plugin-catalog-common? That only has permissions in it today, but it's a catalog package. Should we mark them as alpha too?

Yes I think it still make sense to mark these as alpha even though it's the only exports currently 👍

Cool cool - will open a separate PR for that.


Improve mill build

add integration-tests to mill, which has already been added in sbt.
use object v to record ivy dependencies for simplicity.
remove deprecated testFrameworks API in mill.

Contributor Checklist

[ ] Did you add Scaladoc to every public function/method?
[ ] Did you add at least one test demonstrating the PR?
[ ] Did you delete any extraneous printlns/debugging code?
[ ] Did you specify the type of improvement?
[ ] Did you add appropriate documentation in docs/src?
[ ] Did you state the API impact?
[ ] Did you specify the code generation impact?
[ ] Did you request a desired merge strategy?
[ ] Did you add text to be included in the Release Notes for this change?

Type of Improvement
None

API Impact
None
Backend Code Generation Impact
None
Desired Merge Strategy

Squash: The PR will be squashed and merged (choose this if you have no preference.

Release Notes
None
Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (Bug fix: 3.3.x, [small] API extension: 3.4.x, API modification or big change: 3.5.0)?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you mark as Please Merge?

@jackkoenig ask to review.


Add link to index.md

I add some more link for learning reference

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

Hi,
Thanks for this pull request (PR).
Unfortunately, we are closing this PR, because we do not believe it adds a significant improvement.
Feel free to submit another PR though.
Thank you


Accept calculateChangedBits as a prop on Context.Providers

Per a suggestion from Dan Abramov: this RFC proposes allowing a Context.Provider instance to accept a calculateChangedBits function as a prop, in addition to the current implementation of accepting them as an argument to React.createContext.
View rendered RFC

Thanks for writing this up. It's a well written RFC.
I'd like to add some context about this API though. The calculateChangedBits API is a bit sketchy, likely to change. The context API in general is optimizing for things that rarely change and when it changes, isn't all that high priority. If you care about fine grained updates enough to care about calculate changed bits, maybe you should just use subscriptions instead? Just because there's a new API doesn't mean it's better.
Being in the niche of having to use calculateChangedBits is a very small niche in the first place. Being in the niche of needing specific features out of calculateChangedBits is even less likely to being the best solution to the problem. If everyone needs such features to use it, then maybe we should just rip it out completely. It's already adding an uncomfortable amount of code and execution in hot paths. So that's the lens I'm viewing this RFC through.
A few points:

How does this relate to the global context API? https://github.com/facebook/react/pull/13293 The idea there is that you shouldn't have to take on a dependency of a provider in most cases. How would your solution work there?

What happens when you change the calculateChangedBits function from one function to another gets a bit weird. We've found that it's often not bad to have two contexts. One "implementation context" which is essentially dependency injection and one "state context" which is the current value. The implementation context can be the specific one you generate per store and never changes. If it does change, the semantics are clear. It clears the tree.

How are you planning to use this in practice? We imagined that this would more likely be used by mutable/change tracking based stores that can generate a list of changed values from that. Then that list can be used to compute the bits. If you have to diff the tree to get the changed values, only to then rerender the React tree again, you're in dangerous territory of just spending more time diffing than it would take to rerender.

In the case of React-Redux, we already use per-component-instance subscriptions up through the current version.  The Redux store is currently passed down through legacy context, and every connected component instance is a separate subscriber to the store.
We're currently attempting to transition to using createContext as a core change for a version 6 (per a couple potential reimplementations in PR 995 and PR 1000 ).
Since createContext is capable of correctly propagating updates to deeply nested components (which legacy context could not do), there's no reason to have separate per-component subscriptions any more.  That involves passing down the current Redux store state via context and having connected components consume that store state value instead of directly retrieving it themselves.  In addition, we hope that this would solve any potential "tearing" issues with async React, as all components would be seeing the same Redux store state during a render tree calculation.
Our current rough performance benchmarks indicate that the createContext approach is a bit slower than the original v5 implementation in an artificial stress test scenario, but still competitive (see related discussion and numbers in React issue 13456 ).  However, a very quick proof-of-concept using the current calculateChangedBits API (and relying on the state structure of our benchmark app) was actually significantly faster than v5.  So, it's a promising approach that we would like to make use of if possible.
Answering your comments specifically:

How does this relate to the global context API? facebook/react#13293 ?

Assuming I'm reading that correctly, 13293 would allow an end user to globally update the current value for a given Context instance using a sort of static function, without ever having to render a Context.Provider and "manually" pass down some sort of this.updateTheContextValue method to its descendants.
I don't think this RFC changes anything related to that PR.  The change I'm proposing only matters if you are actually rendering a MyContext.Provider.  If you're skipping rendering a MyContext.Provider and just calling MyContext.set(), then it would still be able to use whatever calculateChangedBits function was provided when you called createContext.

Changing the provided calculateChangedBits function

Implementation-wise, I think the example reimplementation code I wrote should work if the user either switches from giving a function to not giving one, or vice-versa.
Your example of using separate "implementation context" and "value context" instances sounds like what I described in the "Alternatives" section of the RFC.  To me having to use two separate Context instances like that feels really hacky, but I guess it could potentially work.

How are you planning to use this in practice? We imagined that this would more likely be used by mutable/change tracking based stores that can generate a list of changed values from that. Then that list can be used to compute the bits.

That sounds like exactly how I would want to use it :)
In the RFC, I wrote this hand-waved function:
function calculateChangedBitsForPlainObject(currentValue, nextValue) {
    // magic logic to diff objects and generate a bitmask
}

Here's how I imagine an un-hand-waved implementation would work.
Let's say we've got a Redux store whose top-level state looks like {a, b, c, d}.  The contents of those state slices is irrelevant - we can assume that the values are being updated immutably, as you're supposed to do with Redux.
A standard shallow equality check loops over the keys for two objects , and for each key, checks to see if the corresponding values in the two objects have changed.  If any have changed, it returns false ("these objects are not equal").  I would want to implement a similar function that returns an array of all keys whose values have changed in the newer object (such as ["a", "c"]).
From there, I would run each key name through a hash function of some sort, which hashes the key string into a single bit.  I briefly experimented with using a "minimal perfect hashing" library a while back as an early proof of concept.
So, every time the Redux store updated, the React-Redux <Provider> component, as the sole subscriber to the store, would determine which keys had their values changed and generate the changedBits bitmask accordingly.  It wouldn't be a "deep" comparison of the state trees, but rather a quick and simple "top level" list of changes, at least as a default implementation.
Connected components would by default still subscribe to all updates, but we would provide a way for the end user to indicate that a connected component only cares about updates to certain state slices (hypothetical example: connect(mapState, null, null, {subscribeToStateSlices: ["a", "d"]})(MyComponent).

So, every time the Redux store updated, the React-Redux  component, as the sole subscriber to the store, would determine which keys had their values changed and generate the changedBits bitmask accordingly. It wouldn't be a "deep" comparison of the state trees, but rather a quick and simple "top level" list of changes, at least as a default implementation.

I agree with this. I have thought about this(the hash solution, like immutable) before the new context api, to be honest I think even this irrelevant with the context api, even in old context api we could do this. But this is not about react-redux perf, it's just about reducer logic. Just some rough thought, we could provide a new api to allow developer update one deeper object/array, such as allow return a string(or return a object array, or provide a individual api) when use a reducer like foo.bar.baz, it means we only depend on foo.bar.baz to update. We could hash this string to avoid destruct in reducer.

Connected components would by default still subscribe to all updates, but we would provide a way for the end user to indicate that a connected component only cares about updates to certain state slices (hypothetical example: connect(mapState, null, null, {subscribeToStateSlices: ["a", "d"]})(MyComponent).

But I think maybe this is not a idea, if we do this, we will put the complexity to the developer, this implementation(subscribeToStateSlices) of  dependencies collection is terrible(the read is complex, and you have to write many times in many components), we need think about another way(maybe put the dependences to reducer like createReducer(func, [myComponentA, myComponentB]), but this is not a good idea, I don't know), otherwise use something like immer/immutable maybe a good choice.
Finally, IMO, I don't think we could do something like this rfc to perf react-redux. Because redux is unaware of the relationship between component state dependencies and redux store. So, even we add a wrap like react-redux, we also can't get it, no matter how we do in react-redux. Once enter a normal world(redux) we will lost any specific info no matter how where you from(react-redux or something else).

@NE-SmallTown : I'm not quite sure what point you're trying to make, and it doesn't exactly seem relevant to this RFC.
The primary use case I'm describing in the RFC is indeed for use with React-Redux, largely because A) I do want to use it in React-Redux, and B) that's what I know the most about.  I already provided examples of how React-Redux could benefit from this.  But, I can see it being useful for other state handling libraries as well.
The subscribeToStateSlices thing was just a hypothetical example of how a connected component might ultimately decide how to set the unstable_observedBits value, but the actual mechanism doesn't matter for now.
The rest of the comments about reducers and stuff aren't on topic for this discussion - if you've got other suggestions, please file an issue on the Redux repo.

Ufff :slightly_smiling_face:, this is really hard discussion…
Context is global thing and if not, then it should live in state.
Distinguishing carefully of this will save your business I hope :grimacing:
Even in one application you can use different context, but this should be rare;
like preview of component at different landscapes (English, Czech, Norway… Chinese) or bright/dark theme…
———
I really like new createContext API too, but if you want provide it safely for usackers (I can use it, I'm hacker so — really, not funny :sweat_smile:), you must care about misusing… Unfortunately there are no simple metrics nor linter rules for telling me that something is wrong, seriously…
———
So, like shouldComponentUpdate can take CPU more busy when somebody do a little change, this may have even more impact.

@sebmarkbage

We've found that it's often not bad to have two contexts. One "implementation context" which is essentially dependency injection and one "state context" which is the current value. The implementation context can be the specific one you generate per store and never changes.

Hi. For a while i'm thinking for similar approach. Is there any example implementation like this? Thanks

Maybe it's just me but I feel like the same use-cases enabled with this change to Context.Provider could be supported without breaking anything if the Context API simply checked for and called a lifecycle function (let's say... shouldApplyContext) on each Consumer with the new and previous contexts, and only continues calling render/other lifecycle hooks with the new context if true is returned?
Wrapping components in nested Context.Consumers becomes incredibly cumbersome with data structures that need to be shared across a wide range of components where each component only cares about a couple of properties.
The alternative of setting contextType and context on your component classes is much cleaner, but restricts you to using a single context per component, which encourages people to use a singleton context that will cause all components consuming it to re-render upon any change regardless of whether the values that changed in the context are actually used by the consuming component.
Consider the following example of the common pattern of using a global state singleton to populate context:
import React, { createContext } from 'react';

const defaultContext = {
  video: {
    stream: undefined,
  },
  userData: {
    id: 1,
    name: 'Bob',
  },
};
const Context = createContext(defaultContext);

export class Main extends React.PureComponent {
  state = {};

  constructor(props: any) {
    super(props);
    this.state = defaultContext;
  }

  async componentDidMount() {
    const stream = await navigator.mediaDevices.getUserMedia({});
    this.setState(
      {
        video: {
          stream,
        },
      },
      async () => {
        // dummy fetch method, imagine it returns a user with ID and name
        const userData = await fetchUserData();
        this.setState({
          userData,
        });
      },
    );
  }

  render() {
    return (
      <Context.Provider value={this.state as any}>
        <HelloWorld />
      </Context.Provider>
    );
  }
}

export class HelloWorld extends React.PureComponent {
  static contextType = Context;
  context!: React.ContextType<typeof Context>;

  shouldApplyContext(prev, next) {
    return prev.userData.name !== next.userData.name;
  }

  render() {
    return (
      <div>
        Hello, {this.context.userData.name} <Video />
      </div>
    );
  }
}

export class Video extends React.PureComponent {
  static contextType = Context;
  context!: React.ContextType<typeof Context>;
  ref: HTMLVideoElement;

  shouldApplyContext(prev, next) {
    return prev.video.stream.id !== next.video.stream.id;
  }

  componentDidMount() {
    this.ref.srcObject = this.context.video.stream;
  }

  render() {
    return <video ref={(el) => (this.ref = el)} />;
  }
}

Currently, both child components above would render multiple times due to the Main component updating context multiple times in response to some async actions. If the Context API checked the result of each component's shouldApplyContext (if present) prior to applying updates, each component would only re-render when the fragment of context it's actually interested in has changed.
Essentially I should be able to prevent the Video component from re-rendering in response to context changes it doesn't care about. Currently it will re-render again after the userData property is updated, even though it does not use or care about that value.
Having a singleton store that gets fractally consumed is a pattern/use-case that is common and trivial in MobX (because MobX observers subscribe to properties they consume instead of changes to the entire store), but does not work well when porting to the Context API.
I haven't looked at how the internals of the Context API work around here, but I imagine it could be implemented by adjusting the code that applies changes to consumers to inspect the class of the given consumer for a shouldApplyContext method and if found, check the result of calling that to determine whether a component should be updated instead of relying purely on changes to observedBits

Closing in favor of #119 .


schedule doc update as cronjob

Related issue(s) and PR(s)
This PR closes #123 .
Description
This will run the doc aggregation workflow weekly as a cronjob while keeping the option to run it manually if needed.
The workflow at the sensitive data archive that triggers the aggregation  becomes obsolete and will be removed from that repo.
How to test
Run manually or wait until Monday morning at 07:00.

On https://neic-sda.readthedocs.io/en/latest/ it says Build Date UTC : 2024-08-01 10:21:24.624857+00:00, but maybe that's because there were no changes after that..?


TF1 wat.tv  "HTTP Error 403: Forbidden" No video found

Checklist

[x] I'm reporting a broken site support
[x] I've verified that I'm running youtube-dl version 2021.01.16
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar issues including closed ones

Verbose log

PASTE VERBOSE LOG HERE

~ $ youtube-dl --format best  -o '/media/lgb/Linux/%(title)s.%(ext)s' https://www.tf1.fr/tf1/doc/videos/doc-s01-e01-memoire-enfouie-10495093.html --verbose
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'--format', u'best', u'-o', u'/media/lgb/Linux/%(title)s.%(ext)s', u'https://www.tf1.fr/tf1/doc/videos/doc-s01-e01-memoire-enfouie-10495093.html', u'--verbose']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2021.01.16
[debug] Python version 2.7.12 (CPython) - Linux-4.10.0-38-generic-x86_64-with-LinuxMint-18.3-sylvia
[debug] exe versions: ffmpeg 2.8.17, ffprobe 2.8.17
[debug] Proxy map: {}
[TF1] doc-s01-e01-memoire-enfouie-10495093: Downloading webpage
[wat.tv] 13758789: Downloading JSON metadata
[wat.tv] 13758789: Downloading JSON metadata
[wat.tv] 13758789: Downloading m3u8 information
WARNING: Failed to download m3u8 information: HTTP Error 403: Forbidden
[wat.tv] 13758789: Downloading f4m manifest
WARNING: Unable to download f4m manifest: HTTP Error 403: Forbidden
[wat.tv] 13758789: Downloading m3u8 information
WARNING: Failed to download m3u8 information: HTTP Error 403: Forbidden
[wat.tv] 13758789: Downloading f4m manifest
WARNING: Unable to download f4m manifest: HTTP Error 403: Forbidden
[wat.tv] 13758789: Downloading MPD manifest
WARNING: Failed to download MPD manifest: <urlopen error [Errno -2] Name or service not known>
[wat.tv] 13758789: Downloading MPD manifest
WARNING: Failed to download MPD manifest: <urlopen error [Errno -2] Name or service not known>
[wat.tv] 13758789: Checking http-264 URL
[wat.tv] 13758789: http-264 URL is invalid, skipping: <urlopen error [Errno -2] Name or service not known>
[wat.tv] 13758789: Checking http-464 URL
[wat.tv] 13758789: http-464 URL is invalid, skipping: <urlopen error [Errno -2] Name or service not known>
[wat.tv] 13758789: Checking http-664 URL
[wat.tv] 13758789: http-664 URL is invalid, skipping: <urlopen error [Errno -2] Name or service not known>
[wat.tv] 13758789: Checking http-1264 URL
[wat.tv] 13758789: http-1264 URL is invalid, skipping: <urlopen error [Errno -2] Name or service not known>
[wat.tv] 13758789: Checking http-1864 URL
[wat.tv] 13758789: http-1864 URL is invalid, skipping: <urlopen error [Errno -2] Name or service not known>
[wat.tv] 13758789: Checking http-2564 URL
[wat.tv] 13758789: http-2564 URL is invalid, skipping: <urlopen error [Errno -2] Name or service not known>
ERROR: No video formats found!; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 805, in wrapper
return func(self, *args, **kwargs)
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 837, in __extract_info
return self.process_ie_result(ie_result, download, extra_info)
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 871, in process_ie_result
return self.process_video_result(ie_result, download=download)
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 1559, in process_video_result
raise ExtractorError('No video formats found!')
ExtractorError: No video formats found!; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Description

WRITE DESCRIPTION HERE
I use the same request 2 day ago without any error.
To day any request on any file on TF1 site (wat.tv) stop with an error

Same here, even after updating to the latest version (2021.01.16).

Same here, even after updating to the latest version (2021.01.16).

Why request closed ????
Problem is always pending to day!!!

Why request closed ????
Problem is always pending to day!!!

Appears to only pull SD videos.  Maybe the 720p stream URLs are moved, as I can pull them when logged in (georestricted), but not from the fixes.  It appears that I can find the 720p mpd URL by accessing https://delivery.tf1.fr/mytf1-wrd/{video_id} and 720p hls at https://delivery.tf1.fr/mytf1-wrd/{video_id}?format=hls, but those are georestricted.

Appears to only pull SD videos.  Maybe the 720p stream URLs are moved, as I can pull them when logged in (georestricted), but not from the fixes.  It appears that I can find the 720p mpd URL by accessing https://delivery.tf1.fr/mytf1-wrd/{video_id} and 720p hls at https://delivery.tf1.fr/mytf1-wrd/{video_id}?format=hls, but those are georestricted.

update with last release today : release 2021.01.24.... and.... I can Download TF1 (wat.tv)  again
Thanks a lot

update with last release today : release 2021.01.24.... and.... I can Download TF1 (wat.tv)  again
Thanks a lot


Tomhaile/ch10379/notifications shows eth transfer when should

Clubhouse Story
refactor how transfers funds uses notifications.
fix withdraw form reset.
Submitter checklist

[ ] Test covering functionality added/fixed in
Check the linked story includes the following:

[x] Steps to reproduce
[ ] Screenshot (If applicable)

Reviewer Checklist

[ ] Test/lint pass

This pull request introduces 1 alert when merging fffa42601cde91d01375166b6ba5b7294b4a3830 into dd109743fb301a8fe348f1203b76aeecfae90831 - view on lgtm.com
new alerts:

1 for Potentially inconsistent state update

Comment posted by lgtm.com


Add js image selector

After merging https://github.com/mirumee/saleor/pull/470 it's possible to attach images to particular variants. But images should also change, when user is selecting another variant from variant selector.

[ ] switch active image (do not hide other images) when a variant is selected
[ ] in cart display an image specific to a variant if one is available

@benekex2  Our variant picker is implemented in React and uses MobX store to track the selected variant. It should be possible to implement another React component that would render images and update them respectively based on changes in the store.
Displaying proper images in cart will probably require some backend changes so we can implement it later.

Is this issue still underway, or are most of the front-end improvements in the old saleor project getting deferred for work on the PWA storefront? No worries either way, just curious :)


How to specify a configuration flag? Not shown in the docs.

Hi, need an ability to specify configuration flag (--with-jemalloc), is it possible?

Hi @heaven
You should be able to pass in script_flags to the installer LWRP according to this line provided you also use the 0.9.4 version.

Hi, this is about ruby configuration flags, not rvm. I would expect something like:
"rubies": [
  "ruby-1.9.3-p448",
  "ruby-2.1.0",
  {
    "version": "2.2.1",
    "options": "-C --with-jemalloc"
  }
]

Can you please reopen this? I need to pass --disable-binary option when installing ruby, there's no way to do so as I can see.


Refactoring to message a map of teams their flags

Refactoring to send a simple message to each maintaining team of the flags that they own. Huge shoutout to @fergusmcdonald for cleaning up our LaunchDarkly system to make this possible.
I wanted to get a working version out with the new team based messaging but I left a TODO to better inform each team of the status of their flags as outlined in this Slack thread: https://procurify.slack.com/archives/C025FR4PL/p1606175232039700
I did a test deploy this evening with the new messaging, the results for ditto can be seen in #eng-ditto on Slack. I also added another webhook URL for error messaging when a team is misconfigured. I misconfigured platform and you can see the error message here in #eng-ditto-ld-test.
The new configuration relies on a JSON object of a list of team emails mapped to webhook urls for the flag update channels for each team. The structure is described in the README.
Right now we're making one API call to LaunchDarkly but N+1 calls to Slack. This could be improved by creating an actual Slack App whose credentials are used to message channels but for now we can just use a webhook url configured for each team.
TODO (among others)

Add more teams to the map when we deploy, I will add Platform next
Change the main count to go to a wider channel like #team-engineering
Create a better channel for the error messages

I also added Arrow to bring in an Either type for better error handling https://arrow-kt.io/docs/0.10/apidocs/arrow-core-data/arrow.core/-either/index.html


mailnag: 1.3.0 -> 2.0.0

Notable changes:

Switch to Python3 by default.
Format inputs and arguments.
Use wrapGAppsHook.
Use libsecret (replaces libgnome-keyring) by default
Add @doronbehar as maintainer.
Remove overridden phases.

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/issues-with-gnome-keyring-and-libsecret/8370/2


Using HttpClient

https://docs.microsoft.com/en-us/dotnet/standard/async-in-depth
https://docs.microsoft.com/en-us/dotnet/standard/async-in-depth#deeper-dive-into-tasks-for-an-io-bound-operation
Deeper Dive into Tasks for an I/O-Bound Operation
In Code Snippet
var client = new HttpClient();
However, according to the documentation about HttpClient it is not correct usage:
https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-5.0

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors. Below is an example using HttpClient correctly.
C#
public class GoodController : ApiController
{
private static readonly HttpClient HttpClient;
static GoodController()
{
    HttpClient = new HttpClient();
}

}

Did I miss something?

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

ID: 88cc5f21-0b4b-f33c-b7fc-96bb9c95ddcf
Version Independent ID: 46697309-d4fd-1cd9-f8ff-e4577be08003
Content: Async in depth
Content Source: docs/standard/async-in-depth.md
Product: dotnet-fundamentals
GitHub Login: @cartermp
Microsoft Alias: wiwagn

Hi 👋 @albertly
Thank you so much for posting this issue. We really appreciate it.

Did I miss something?

No, you did not miss something. You are correct, this article does go against the guidance for HttpClient, but this article is a bit dated and the sample source code could use a bit of clean up in that regard. If you're interested in updating this article and sample source code, I'd be happy to review it. I'm marking this issue as up-for-grabs - thanks again.


Set permission on the HDFS web-IU to directly modify the files.

The solution, though not elegant, was to temporary give write permissions to all users.


fix imports with nested enums

schema definitions that reference enums in structs in imports fail with errors like this:
log.capnp.ts:833:23 Cannot find name 'CarParams_SafetyModel'.
log.capnp.ts:834:27 Cannot find name 'CarParams_SafetyModel'.
log.capnp.ts:898:53 Cannot find name 'RadarData_Error'.
log.capnp.ts:899:50 Cannot find name 'RadarData_Error'.
log.capnp.ts:900:34 Cannot find name 'RadarData_Error'.
log.capnp.ts:902:49 Cannot find name 'RadarData_Error'.
log.capnp.ts:903:38 Cannot find name 'RadarData_Error'.
log.capnp.ts:1226:22 Cannot find name 'CarControl_HUDControl_AudibleAlert'.
log.capnp.ts:1227:26 Cannot find name 'CarControl_HUDControl_AudibleAlert'.
log.capnp.ts:833:23 Cannot find name 'CarParams_SafetyModel'.
log.capnp.ts:834:27 Cannot find name 'CarParams_SafetyModel'.
log.capnp.ts:898:53 Cannot find name 'RadarData_Error'.
log.capnp.ts:899:50 Cannot find name 'RadarData_Error'.
log.capnp.ts:900:34 Cannot find name 'RadarData_Error'.
log.capnp.ts:902:49 Cannot find name 'RadarData_Error'.
log.capnp.ts:903:38 Cannot find name 'RadarData_Error'.
log.capnp.ts:1226:22 Cannot find name 'CarControl_HUDControl_AudibleAlert'.
log.capnp.ts:1227:26 Cannot find name 'CarControl_HUDControl_AudibleAlert'.
Error: CAPNPC-TS009 Failed to transpile emitted schema source code; see above for error messages.
    at transpileAll (/home/batman/capnp-ts/packages/capnpc-js/lib/index.js:77:15)
    at /home/batman/capnp-ts/packages/capnpc-js/lib/index.js:39:21
    at tryCatcher (/home/batman/capnp-ts/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/home/batman/capnp-ts/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/home/batman/capnp-ts/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/home/batman/capnp-ts/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/home/batman/capnp-ts/node_modules/bluebird/js/release/promise.js:693:18)
    at Async._drainQueue (/home/batman/capnp-ts/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (/home/batman/capnp-ts/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/home/batman/capnp-ts/node_modules/bluebird/js/release/async.js:17:14)
    at processImmediate (internal/timers.js:461:21)
./node_modules/.bin/capnpc-js: plugin failed: exit code 1

example schema definition with the issue (which generated the above output):
https://github.com/commaai/cereal/blob/122c3719108d640e5ae296959cdf32a1c2c49284/log.capnp#L358
this fix recursively adds structs and enums that are in imports

Managed to integrate your patch and it should be fixed as of v0.7.0; closing.


Can the server be hosted on a different machine to that of the clients?

if so how?

Hi,
You can use ngrok to give your server a public address:
ngrok.exe tcp 9000

Where 9000 is your port number.
For more options run ngrok.exe -h.
Best regards,
Ivan.


ci: increase timeout for top-up wallet test

Closes https://github.com/FuelLabs/fuels-ts/issues/2541

Closing in favour of https://github.com/FuelLabs/fuels-ts/pull/2542


ManyToMany Association + Repository

Hello,
Would you like please to show us how to add a ManyToMany association in Ebean 4.0.0 ++ with repository (Update / Delete) ?
This is an example of my model :

@Entity
public class Sysuser extends BaseModel {

   @Constraints.Required
    public String username;

    @ManyToMany(cascade=CascadeType.ALL)
    public List<Role> roles;

Thank you in advance

Hi @HannahJSwystun,
this is an issue tracker. If you are looking for help, I suggest you ask in our discourse community. See for example this similar topic: https://discuss.lightbend.com/t/looking-for-sample-with-manytomany-repository-completion-stage/6532
Cheers,

Hello,
I've been looking so long of an example that cover @ManyToMany in Repository but i did not find!!


Add labeling v1alpha3

What type of PR is this?

What this PR does / why we need it:
This is WIP. We want to push the images to our giantswarm quay registry and add the label filtering.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
TODOs:

[ ] squashed commits
[ ] includes documentation
[ ] adds unit tests

Release note:

Let's do that. I'll see if i can add it to the app.

@anvddriesch now that the Hive Sprint is over, should we take over this PR in Celestial?

@anvddriesch now that the Hive Sprint is over, should we take over this PR in Celestial?

Antonia is on vacation this week, but yes - do it :rocket:

@MarcelMue Do you know if there's anything missing from here?

This should be working as intended right now. The PR isn't merged to make updating with upstream easier (so we can get new commits in master and then merge into this branch)

This should be working as intended right now. The PR isn't merged to make updating with upstream easier (so we can get new commits in master and then merge into this branch)

Currently release-0.4 branch in our fork matches the upstream release v0.4.13, so it's almost ideal point for merging this PR, because then we get "clean" upstream v0.4.13 + watch label filtering.
Then we can continue syncing our releases with upstream and have e.g. our v0.4.14 to match upstream v0.4.14 etc.

:) If it's okay I'll leave it to celestials judgement to merge this PR.


FIxing build and adding test on the schema.

@jfclere you can't merge typo changes in released schemas :(

@ehsavoie Note really, the test is wrong, the idea that the schemas are immutable is wrong.

Hum having released schemas changing can lead to a nightmare. Also I need  a fix version upgrade so it is better to put those in there

Could you please elaborate on what the nightmare would be? Just to make sure, the changes we are talking here are only changing xs:documentation, so in no way are affecting validation.

Hum having released schemas changing

Needless to say, we change schemas delivered in WildFly releases. The schemas are delivered with every release.

The are not. Schemas are published. Once published can never be changed anymore.

http://www.jboss.org/schema/jbossas/
Tools are allowed to download and cache those schemas. Similar to maven central artifacts.


Security: STG_PanelPaymentMapping_CTRL.cls doesnt seem to enforce user profile permissions or user field level security

Critical Changes
Changes
A user will now be required to have READ, CREATE, UDPATE, and DELETE access to the Payment_Field_Mapping_Settings custom setting object before the user can manage payment mapping settings in the Payment Mappings section of NPSP Settings.
Issues Closed
Community Ideas Delivered
New Metadata

Apex Class

STG_PanelPaymentMapping_CTRL_TEST

Deleted Metadata

@dfuller114 Should this be lurched to a Work Item?

**lurch: attach W-041513

Tracking W-041513


Data model - initial idea

Describe data model as JSON Schema (https://json-schema.org/)
Slack threads:

https://cesko-digital.slack.com/archives/C0311K8LHFX/p1658429489221509
https://cesko-digital.slack.com/archives/C0311K8LHFX/p1660243119102349

It looks that ajv is supporting code generation - https://ajv.js.org/packages/ajv-cli.html#ajv-options - --code-es5
Example is validated with:
ajv validate --verbose -s kalkulacka.schema.json -d example-senatni.json -r candidate-answers.schema.json -r candidate.schema.json -r contact.schema.json -r election.schema.json -r party.schema.json -r question.schema.json

I have created new branch based on naming convention - https://github.com/KohoVolit/volebni-kalkulacka-2022/pull/27