How to adjust the gap between icon and title in item, thank you

@BeingCode hey!) You can take a look at UITabBarItem variable titlePositionAdjustment. But it will adjust both icon and title position (Apple do the same)
If you want to change space you can use this constants. Hope it will help 🤞🏻
public static let defaultTitleVerticalOffset: CGFloat = 10
public static let defaultIconVerticalOffset: CGFloat = -5

@igork-ramotion The middle picture is large. I want to move the raised display upward without blocking the text below

@BeingCode Currently library doesn't support that functionality, but if you want you can add it by yourself
The starting point may be the function func layoutContainers()  there all layout items calculation happen

@igork-ramotion I adjusted the position of the icon, but the raised part of the item in the middle couldn't respond, thank you￼￼￼￼￼

@igork-ramotion

@BeingCode you need to handle interaction on that item separately (maybe by using custom button or by gesture recogniser). Library doesn't support this functionality


feat(wallet): integrate with keystone

Description
Hi Caravan team, This PR adds Keystone Wallet support.
Including changes:

Add Keystone Extended Public Key importer, Signature Importer.
Add basic QRScanner, FileScanner components for Keystone.
Cooperating PR to add data encoding and decoding methods in unchained-wallets

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Does this PR fix an open issue?

[ ] Yes
[x] No

Apologies for the delayed response, @soralit. We've been working for the past few months on shipping our own QR code integration in caravan; once those changes have been QA'd and merged, I'll comment on this PR again and ask that you refactor it to import our QR code implementation instead of importing and shipping one specific to Keystone.

Generic device support is going to be a priority for this project very soon I hope. Ongoing development is moving to the monorepo (which will be ideal for this type of project as it will be able to leverage updates to the underlying libraries as well)


Ubuntu 18.04 linux stuck on test 3

hi, I'm first time testing this repo,
just cloned, cmake . , make -j
running make tests gets stuck on test 3:

FP16$ make test
Running tests...
Test project /mnt/store/devel/FP16
Start 1: ieee-to-fp32-bits
1/7 Test #1: ieee-to-fp32-bits ................   Passed    0.01 sec
Start 2: ieee-to-fp32-value
2/7 Test #2: ieee-to-fp32-value ...............   Passed    0.01 sec
Start 3: ieee-from-fp32-value
^CMakefile:106: recipe for target 'test' failed
make: *** [test] Přerušení (SIGINT)

This test checks all 2**32 possible input values, so most likely you just need to wait for longer.


Bump to 5.5.1

What changes were proposed in this pull request?
5.5.1 is the latest version of CP

Closing in leu of https://github.com/confluentinc/cp-helm-charts/pull/477


derive FromSqlRow for Ewkb

Am new to both geozero and diesel, but for the queries I was trying to write, I needed to add this derive to execute the following (truncated) code:
The diesel errors were kind of inscrutable, but from what I could surmise, the general issue is that while st_union_agg (which is a SQL function I defined to wrap the aggregate version of PostGIS' ST_Union) returns a geozero::postgis::diesel::sql_types::Geometry, an Ewkb cannot be obtained from the select statement without explicit conversion, selecting the Geometry column itself, or without this trait implementation.
Sorry I can't provide a better explanation.
#[derive(Queryable)]
struct CollectionDiff {
    pub start: DateTime<Utc>,
    pub end: DateTime<Utc>,
    pub updated: DateTime<Utc>,
    pub footprint: Ewkb,
}

stac::table
    .select((
        min(stac::observed).assume_not_null(),
        max(stac::observed).assume_not_null(),
        max(stac::updated).assume_not_null(),
        st_union_agg(stac::geometry),
    ))
    .get_result::<CollectionDiff>(&mut conn)?;

I don't use diesel, but I'm a little surprised that you'd build an Ewkb from an entire row. I'd expect just a single field of the row to be the ewkb.

@myaple ?

Sorry, complete oversight on my implementation. FromSqlRow allows you to use the FromSql implementation to convert a single value in a row (tuple) selection into the type. So, because all of my tests for this just used a struct instead of explicitly calling select on a tuple like @sunny-g did, I forgot to add the derive macro. My apologies @pka and thank you @sunny-g for putting this in.

Thanks @sunny-g (and @myaple for checking)!

Thank you both! @pka @myaple

@michaelkirk I'm not, this example is getting an Ewkb from the union of the individual column.


Flow Metrics: Link state and withdraw events are not working without events notification enable

As per the model, the description says events enable True is to enable notifications . If user doesn't want notification he can still go and Link state down or withdraw event. This is my understanding, we can discuss and close it

config.events.enable = True
link_state = api.link_state()
link_state.state = link_state.DOWN
link_state.port_names = ['rx']
api.set_link_state(link_state)

Issue should not present in latest snappi_ixnetwork (v0.4.11)


1442-properly log and count metrics

Before submitting pull request:

[x] Check if the project compiles by running sbt compile
[x] Verify docs compilation by running sbt compileDocs
[x] Check if tests pass by running sbt test
[x] Format code by running sbt scalafmt

Closes #1442

Thanks! :)


artifact publish fails

Artifact publish fails
Publishing a large artifact (>20GB) seems to hang. After a while (an hour or so) the upload progress froze around 33% - I kept it running as I could see something was still being uploaded due to network activity. After a few more hours with the client still frozen showing no progress I CTRL-C'ed it which gave the reported error. In my setup I've published artifacts of 1GB and 4GB with no problems. It could be related but in a different organisation I've managed to get a large artifact published but downloading it via the CLI fails: https://developercommunity2.visualstudio.com/t/azure-artifacts-download-of-large-package-fails/1308520
Edit: I've tried a second time and this time it seems to have got stuck on:
| Uploading:<PHONE_NUMBER>/25479483028 bytes: 34.11% ..
which is roughly where it got to last time.
Task manager shows ArtifactTool with low cpu high (4GB) memory and using 22Mbps upload (my max) despite the progress stalled. I'll leave it in this state in case it completes.
Command Name
az artifacts universal publish Extension Name: azure-devops. Version: 0.18.0.
Errors:
_sigint_handler() takes 1 positional argument but 3 were given
Traceback (most recent call last):
Temp\pip-unpacked-wheel-pwfpui04\knack\cli.py, ln 233, in invoke
cli\core\commands\__init__.py, ln 659, in execute
cli\core\commands\__init__.py, ln 722, in _run_jobs_serially
cli\core\commands\__init__.py, ln 714, in _run_job
azext_devops\dev\common\exception_handler.py, ln 31, in azure_devops_exception_handler
    reraise(*sys.exc_info())
Local\Temp\pip-unpacked-wheel-s5x_2dzp\six.py, ln 703, in reraise
...
    proc = self._tool_invoker.run(command_args, new_env, initial_progress_message, _process_stderr)
azext_devops\dev\common\external_tool.py, ln 75, in run
    line = bline.decode('utf-8', 'ignore').strip()
TypeError: _sigint_handler() takes 1 positional argument but 3 were given

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az artifacts universal publish --organization {} --project={} --scope {} --feed {} --name {} --version {} --description {} --path {}

As far as I can tell you just need to publish a large artifact - in my case I'm using one around 24GB.
Expected Behavior
I would expect anything up to 1TB to be able to be published given sufficient time (depending on upload speed).
Environment Summary
Windows-10-10.0.19041-SP0
Python 3.6.8
Installer: MSI

azure-cli 2.18.0

Extensions:
azure-devops 0.18.0

Additional Context

Trying a second time gives:
TF400813: Resource not available for anonymous access. Client authentication required.
redoing az login and trying again - if this doesn't work I'll use a PAT

Ok my bad - this was in a second organisation which didn't have billing setup hence the large upload wasn't allowed. I was doing this as I have an issue with the cli doing a download which I wanted to retest from scratch. I'll close this issue and reopen a new one about the download when I've completed testing


Support subtite

Dear support,
I want add to player a subtitle.
Please help me

@giaule currently the player does not support subtitles.
It's in our roadmap to add a basic implementation, but for now there's no way to add subtitle support. Actually, even hls.js currently doesn't support WebVTT text tracks, so we wouldn't be able to add full support until then.


AB#6348 xm config item to store Page title and start date of main event

This is ready to go
portal instance:
https://get-dev.sitecoredemo.com/instances/details/1980

Small change request - it looks like I never pushed the Config item through the workflow so it won't in the Web DB when we switch to using it.
Can you push it through. Otherwise it looks good.


Warn and handle missing get in computed (fix #5265)

What kind of change does this PR introduce? (check at least one)

[X] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[X] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[X] It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
[X] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[X] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[X] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
I ran all test locally. I'm having some failures related to SSR and selenium which appear to be completely unrelated. I've confirmed the new test works by reverting my change and adding it back in.
I am using noop for the getter if one does not exist to avoid exceptions when calling functions on the getter.

#5265

Here is the change that changed the behavior. Notice on this line that noop is used if get is falsy. Does anybody think that this original behavior is preferable to the warning?
const getter = typeof userDef === 'function' ? userDef : (userDef.get || noop)

This would be consistent with how defineComputed() is defined here when the get is undefined.
IMO this is better because it would not cause errors in production mode, avoid a new warning, keep the 2.1.* behavior, and make the behavior between production and non-production modes consistent.


Mass deletion, Automated deletion, Reaping tombstones

In Riak deletion is difficult.
The default setting for delete, will replace an object in the backend with a new object in the backend, an object that is from the perspective of Riak a tombstone.  It will then set a timer, and then on triggering the timer, the tombstone will be reaped (in essence deleted from the backend - which in turn might use a backend tombstone to defer the deletion).  The temporary tombstone is a replicable object so other clusters can be informed of the deletion and perform the same deletion to reach a consistent state.
There have traditionally been two problems here:

If all stages of the process are not completed successfully the original object may re-appear, which may itself present data loss risks (if the re-appearing object appears to be an update on an object which replaced a non-existing object) not just a data retention issue.
Deletes are often done in batches by applications, and there are overheads with triggering many timers concurrently, so the time between tombstone creation and reaping is kept short (when due to the other problem it would be better to keep it long).

These problems can be avoided by having a delete_mode of keep (which is considered to be the safe way to run riak - but isn't the default way), which makes the tombstones permanent.  However making the tombstones permanent has a cost in terms of uncollected garbage.  That cost is an impact on disk space consumption, but also on operations which depend on object folds (e.g. key-listing full-sync, handoffs, or AAE tree rebuilds).  This uncollected garbage is an issue both in the primary store and any AAE store (tombstones are objects and exist as such in AAE).
Further information on deletes:

Riak Docs
Original post explaining delete mode

So deletion of individual objects is hard, what about mass deletion?  Can we delete without discovering objects which need deletion in the application, and deleting them one at a time using batch jobs?
There has has traditionally two mechanisms for mass deletion in Riak:

Use a backend TTL (potentially with multi-backend so that only certain buckets are subject to the TTL);
Use multi-backend with on-disk deletion (i.e. set a bucket you intend to delete to a specific backend, and wipe the backend from the disk when it is no longer required).

There are some problems with these approaches though:

Backend TTLs are clunky, there is a single TTL for the whole backend and the TTL concerns themselves with the Timestamp which the object was added to the backend (which might be different to the timestamp which the object was added to Riak).  The Backend TTL of this type is only available in the bitcask and memory backend.
Deletion of this sort is not co-ordinated with the AAE store.  The data may have gone from the vnode store, but is still referred to in the AAE store.  This doesn't cause an immediate problem, but eventually AAE stores are rebuilt from the vnode store and at this point a rebuilt AAE store for one vnode might now have a huge discrepancy from an AAE store for an overlapping preflist which is pending a rebuild.  That can lead to significant activity related to false repair, which may have overheads, or mask a genuine need for repair.
The AAE coordination issue has led to some customers co-ordinating AAE tree rebuilds across the cluster, which runs against the principle of AAE rebuild design (which tries to reduce concurrency of rebuilds due to the overhead of rebuilds).  This has led to various issues.
Testing of multi-backend and TTL is sketchy, our test cycles are focused almost exclusively on testing with a single backend.  There are some backend capabilities which are lost when running in multi-backend, even where the backend with the capability is used

There are some new tools available for solving these problems:

The Leveled backend has a TTL solution that is not yet implemented within Riak, but allows TTL to be set at object insertion time, which would allow for more flexible arrangements without multi-backend and TTL based on last modified times.
Tictac AAE and NextGen REPL has some improved per-bucket capability for per-bucket configuration of anti-entropy and replication.
Tictac AAE uses leveled as a backend and so would have the TTL as a feature.
There is an unimplemented feature on the discontinued develop branch riak_kv_sweeper to implement lower-cost ways of discovering objects to be changed (i.e. tombstones to reap, objects to expire).
Leveled backends adds a fold_heads feature that allows for discovery of objects to be changed based on metadata-only without the need to lift the object values off disk.  The fold_heads feature is available to non-Leveled backends via Tictac AAE parallel stores, folding with the aae_fold feature.
With leveled we have the control to add Riak specific intelligence, in particular per-bucket intelligence (as keys are not arbitrary terms) to support per-bucket storage rules that might facilitate a drop-bucket feature.
Previously tombstone reaping would also be subject to dangerous race conditions (e.g. if a client was managing a PUT when two vnodes had reaped the tombstone, but one had not).  However, the work on KV679 means that permanency of deletion is no longer critical to safety.  It would now be safe to have tombstones partially reaped within a cluster.

There is a general set of superficial nice-to-haves, features that now seem to be possible to implement:

Auto-expiring tombstones concurrently in backend and AAE, so that tombstones can be long-lived at low overheads, without existing forever.
Per-bucket AAE exclusion rules, where some buckets are considered temporary (e.g. because they are mapped to TTL backends) and so are excluded from AAE entirely (as AAE is primarily concerned with protection agains long-term data entropy).
Flexible auto-expiring object rules using the leveled backend.
A drop-bucket feature (preferably, for simplicity of implementation, a permanent drop bucket feature where writing to a bucket after a drop would not be supported).

There are some general problems though with making such improvements:

There are already "too many" supported options in Riak, adding more options causes further confusion about how Riak will behave, especially as features are inter-connected.  For example, Leveled TTL may be "better" than Bitcask TTL, but the fact that it is different is confusing and that confusion is multiplied by the interconnected impact on AAE, repl behaviour (especially as with 2.9.1 there are now multiple forms of both AAE and repl).  Then one must further overlay confusion with datatypes, legacy and non-legacy configurations (e.g. typed and non-typed buckets), additional features (e.g. maintaining coordination with Solr via AAE).
Some features may directly contradict.  For example, the addition of Tictac AAA and aae_fold provided a key-counting, object-size monitoring feature - but AAE exclusion will then mean this will give false results.
Features are enabled for testing on a per-test basis, so it is hard to get assurance from running regression tests that new features have not had unexpected side effects on old features.  This is particularly true of Solr integration.
The majority of Riak customers are "legacy" users (they have a large established cluster where stability is valued is valued as a feature), so features that depend on migration to Leveled/TictacAAE/NextGenRepl eco-system have limited impact.  However, funding for change has in recent times come largely from organisations committed to that migration - and although those organisations see long-term value in maintaining the community, they are constrained by their economic self-interest in the extent to which they are prepared to accept increased change costs in the features they desire in order to prove that those changes don't impact other customers' configurations.
Coupling between Solr and the original hashtree AAE implementation makes retirement very hard.  There is also an AAE dependency within cluster metadata management, and an alternative AAE implementation in riak_ensemble.

Change here is going to be a difficult balancing act.  I think we need to consider change in two contexts:

Minimal short-term change which comes at a cost of minimal short-term confusion an risk;
Longer-term change which ultimately may enforce hard decisions about deprecation.

Proposal 2.
The second proposal is to have a bucket property that can set a TTL for keep tombstones.  That is to say we can ask for tombstones to expire eventually.
This wouldn't use a direct timer method as in existing delete, but would allow for a long timer to be set (e.g. 30 days), far beyond a point of which we might expect any tombstone to have not been fully replicated by one mechanism or another.
The implementation of this, could be:

restricted to Leveled and native AAE and using Leveled TTL applied to Riak tombstones only.  This would require some extra work to track next expiry time by segment within kv_index_tictactree, simply enabling TTL would lead to load associated with false results (although it might be that the existing partial rebuild on discovery of delta might handle this OK as-is).
similar to proposal 1 being prompted by a new per-node actor, using the extended aae_keyfold, and by implementing a reap_fsm.

For those with an interest in the problem from a theoretical perspective - this is an interesting piece of research and well worth a read.
This is not implementable for Riak (too radical a change).  It isn't a perfect answer (it makes an assumption that persisted data is not lost from disk - which is not something we like to assume in Riak).  It is though, a very interesting change in overall approach.

The current draft branch for 2.9.1 includes:
riak_kv_reaper;
riak_kv_eraser;
new aae_folds to trigger reaps and erases.
This allows an application to run aae_folds to either delete reap a set of tombstones, or delete a range of keys that have not bene modified since a given date.  The former is intended to provide a mechanism to reduce the long term cost of running a cluster in the keep mode.  The latter is proposed as an alternative to backend TTL - in that it allows the expiry of objects to be managed without creating a discrepancy with AAE stores.  This is similar to the original Bahso 2.2.5 proposal for riak_kv_sweeper - only in our case efficiency is gained through folding over only heads using the TictacAAE store rather than performing multiple fold actions per fold.

https://github.com/basho/riak_kv/pull/1749


contextmenu events on touch don't reset properly

Hi!
Touch support seems to be broken on latest leaflet rc3. I can reproduce the bug on http://leafletjs.com/examples/quick-start-example.html
Here's a small screencast to show you the problem:
https://youtu.be/7_9zwz1bz3k
My Steps:
0. Open Developer Console in Chrome, select a device (Nexus 6 in my example)

Set a listener to contextmenu which adds a marker to event.latlng
Do left click (everything ok)
Do long press left click (everything is ok, marker is added to map on position event.latlng)
Do right click on the position of the first marker.

After 4 you see that the (new right click) marker is being placed somewhere else.

Maybe this bug is related to this one: https://github.com/Leaflet/Path.Drag.js/issues/5

Can you publish a fiddle/codepen/playground that displays this behaviour?

Sure: https://playground-leaflet.rhcloud.com/hebi/1/edit?html,output
Don't forget to enable device mode.

Weird. Looks like the contextmenu hack is forgetting to send a mouseup event, so when I try to drag, I pinch-zoom instead.

Maybe the refactoring of @perliedman lead to this behaviour?

Is that two-fingers/right click ever worked? At least, I can see the same (broken) behaviour when using beta1: https://playground-leaflet.rhcloud.com/pewe/edit?html,output

@yohanboniface It worked at revision 4460bd74ad745efe23ff1d68bc4de2041a15b746.

I may be missing something, but I'm seeing the exact same behaviour at this revision, i.e. when doing a right click the marker is always added to the same position but not where I've made the right click.

Hm, yeah, you're right :o

So, this looks like a bug, but I would say it's not a blocker since:

I can reproduce it even in 1.0.0-beta.1
I can't reproduce it in 0.7.7, but a right click actually brings up the browser's context menu, it doesn't add a marker

So, we should fix this, but perhaps not high priority.

This bug is pretty old. Could someone to reproduce it with modern browser?
I failed, but that can depend on numerous factors, including buggy Chrome touch simulation, or buggy tap handler..
Please reopen if it is still reproducible.


Adapt gem to new CocoaPods master spec repo structure

CocoaPods master specs repository had a structure change 2 weeks ago (you can read more about it here), this PR adapts the gem to handle the new structure and also keeps it compatible with the old one (in case you're using Old-Specs for instance).
To discuss: there's probably a better way to traverse the new structure, but during my tests I didn't find any huge performance drawback on doing it this way.

@q231950 @pietbrauer this might be interesting for you guys.

Coverage increased (+0.4%) to 82.584% when pulling cdf3e87bd56b239ba9b470d8c76c24dbcf9fbaf2 on the_sharding into 07954f10cf8d77897dc4e93222cdb631e94fe952 on master.

during my tests I didn't find any huge performance drawback

What happened to letters after f? https://github.com/xing/XNGPodsSynchronizer/pull/8/files#diff-f7c155444c51db45dde52d9216822446R33

@pietbrauer I could be wrong, but as far as I understand (I wish this was documented better) that'll never happen (or at least I didn't see it yet) because they're using 16 as max length of a shard: https://github.com/CocoaPods/cocoapods-repo-shard/blob/master/lib/cocoapods_repo_shard/command/repo/shard.rb#L92-L105

awesome @Ruenzuo 👍


Wifi-2690. ipq807x:Enable bridge-mgr to control port mac address lear…

Merging from uCentral-trunk.
The switch in the IPQ807x/IPQ60xx devices will automatically learn the mac
addresses behind a port. But it will not unlearn this entry when some mac
switches from the ethernet port to the CPU port. This will for example
happens when a device roams from on AP to another AP. At least when both
are APs are bridging the wifi traffic directly or indirectly (mesh) to the
same ethernet broadcast domain.
As result, the roaming device can no longer receive any ethernet packets
which the AP is expected to receive on the ethernet port. This state will
be kept for a couple of minutes until the entry in the FDB is dropped
automatically. But it is still possible for the wifi device to send data
via the ethernet during this whole time.
One solution is to just disable learning on all ports. The other option
would be to enable the qca bridge-mgr which takes care of gathering the
events from the bridge and forwards it to the qca-ssdk (to manipulate the
state of the switch). The latter option was chosen to follow the approach
which QCA is also using in their QSDK.
Signed-off-by: ravi vaishnav<EMAIL_ADDRESS>

Merged 05469546, thanks.


Hosting for the Github Release Plugin

Repository URL
https://github.com/jcustenborder/github-release-plugin
New Repository Name
github-release
Description
This plugin is used to create and list Github releases from a Jenkins Pipeline.
GitHub users to have commit permission
jcustenborder
Jenkins project users to have release permission
jcustenborder
Issue tracker
GitHub issues

Security audit, information and commands
The security team is auditing all the hosting requests, to ensure a better security by default.
This message informs you that a Jenkins Security Scan was triggered on your repository.
It takes ~10 minutes to complete.
Commands
The bot will parse all comments, and it will check if any line start with a command.
Security team only:

/audit-ok => the audit is complete, the hosting can continue :tada:.
/audit-skip => the audit is not necessary, the hosting can continue :tada:.
/audit-findings => the audit reveals some issues that require corrections :pencil2:.

Anyone:

/request-security-scan => the findings from the Jenkins Security Scan were corrected, this command will re-scan your repository :mag:.
/audit-review => the findings from the audit were corrected, this command will ping the security team to review the findings :eyes:.
	It's only applicable when the previous audit required changes.

Only one command can be requested per comment.

(automatically generated message, version: 1.26.17)

The Jenkins Security Scan discovered 4 finding(s) :mag:.
For each of them, either apply the recommended correction, suppress the warning or provide a justification.
Once you're done, either re-run the scan with /request-security-scan or request the Security team to review your justifications with /audit-review.

Jenkins: Missing permission check on a form fill web method with credentials lookup
You can find detailed information about this finding here.
ListReleasesStep.java#120
doFillSortByItems should perform a permission check before calling #includeEmptyValue

Stapler: Missing POST/RequirePOST annotation
You can find detailed information about this finding here.
AbstractReleaseDescriptor.java#13
Potential CSRF vulnerability: If AbstractReleaseDescriptor#doFillCredentialIdItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

ListReleasesStep.java#120
Potential CSRF vulnerability: If DescriptorImpl#doFillSortByItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

Stapler: Missing permission check
You can find detailed information about this finding here.
ListReleasesStep.java#120
Potential missing permission check in DescriptorImpl#doFillSortByItems

/request-security-scan

/hosting re-check

The Jenkins Security Scan discovered 3 finding(s) :mag:.
For each of them, either apply the recommended correction, suppress the warning or provide a justification.
Once you're done, either re-run the scan with /request-security-scan or request the Security team to review your justifications with /audit-review.

Jenkins: Missing permission check on a form fill web method with credentials lookup
You can find detailed information about this finding here.
ListReleasesStep.java#121
doFillSortByItems should perform a permission check before calling #includeEmptyValue

Stapler: Missing POST/RequirePOST annotation
You can find detailed information about this finding here.
AbstractReleaseDescriptor.java#13
Potential CSRF vulnerability: If AbstractReleaseDescriptor#doFillCredentialIdItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

ListReleasesStep.java#121
Potential CSRF vulnerability: If DescriptorImpl#doFillSortByItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

/request-security-scan

The Jenkins Security Scan did not find anything dangerous with your plugin, congratulations! :tada:

:bulb: The Security team recommends that you are setting up the scan in your repository by following our guide.

/hosting re-check

Hey @jcustenborder,
I took a brief look over your hosting request and have some feedback for you:

Create a .github folder within the repository root including the following files and directories: https://github.com/jenkinsci/archetypes/tree/master/common-files/.github
Create a .mvn folder within the repository root including the following files: https://github.com/jenkinsci/archetypes/tree/master/common-files/.mvn
https://github.com/jcustenborder/github-release-plugin/blob/a4aef861fa9ce89215fca4329b2b971a499c7059/pom.xml#L15-L16 is wrong and should be removed. The plugin has no prior release it could declare incompatibility with.
https://github.com/jcustenborder/github-release-plugin/blob/a4aef861fa9ce89215fca4329b2b971a499c7059/pom.xml#L39 should always match your jenkins.version specified.
https://github.com/jcustenborder/github-release-plugin/blob/a4aef861fa9ce89215fca4329b2b971a499c7059/pom.xml#L99 The <compile> scope is obsolete for Jenkins plugins and should be removed.
https://github.com/jcustenborder/github-release-plugin/blob/a4aef861fa9ce89215fca4329b2b971a499c7059/pom.xml#L109-L132 should be simplified to https://github.com/jenkinsci/archetypes/blob/282d79c14f8453bdffe1c74d5010dfdcf776ed9f/empty-plugin/src/main/resources/archetype-resources/pom.xml#L53-L64
https://github.com/jcustenborder/github-release-plugin/blob/a4aef861fa9ce89215fca4329b2b971a499c7059/pom.xml#L134-L140 ssh as scm connection is deprecated for removal. Rather, point the connection and developerConnection to use https, like in https://github.com/jenkinsci/console-column-plugin/blob/bb152d70547e3906218869011072f744e6a0b03a/pom.xml#L63-L64
https://github.com/jcustenborder/github-release-plugin/tree/main/src/main/java/org/jenkinsci/plugins/ uses the wrong class path. Please move your classes and files to io.jenkins.plugins.
There are a few issues left to address within the codebase. You can generate a list via mvn clean verify package.
Please update your Jenkinsfile matching the content of https://github.com/jenkinsci/archetypes/blob/master/common-files/Jenkinsfile

@NotMyFault Thank you for looking into this. Your effort is much appreciated. I believe I have addressed all of the issues you've raised.

https://github.com/jcustenborder/github-release-plugin/blob/main/.github/release-drafter.yml Looks like something went wrong here. The placeholder to fill out in the CODEOWNERS file is left too.

/request-security-scan

The Jenkins Security Scan did not find anything dangerous with your plugin, congratulations! :tada:

:bulb: The Security team recommends that you are setting up the scan in your repository by following our guide.

/hosting re-check

/hosting host


[WIP]Changes to use the new insights-dev Jenkins

Changes to use the new insights-dev Jenkins

@lgalis Did you run the migrate.sh script to convert this repo?

@lgalis See question above: https://github.com/ManageIQ/service_portal-ui/pull/10#issuecomment-437137839
@Fryguy Is there anything other changes needed here?

@Fryguy, @gmcculloug - no, I did not use the script


bestmotherfucking.website

Domain name: https://bestmotherfucking.website
GTMetrix results: too lazy to get some other softw, probably checks out :)
Uncompressed page size: 5.44kB

Note: Please fill in the uncompressed size on line 1 (--data-size) AND line 2

  5.44 KB
  bestmotherfucking.website

I think we're probably safe that this gem of a site is under 512KB, but I went ahead and checked anyway, 5.4KB confirmed. :-)
https://gtmetrix.com/reports/bestmotherfucking.website/hy2Y8rcd/
Added.


Upkeep/change json keys to snake case

Codecov Report

Merging #2 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master       #2   +/-   ##
=======================================
  Coverage   93.52%   93.52%
=======================================
  Files          16       17    +1
  Lines         170      170
  Branches        2        2
=======================================
  Hits          159      159
  Misses         11       11

Impacted Files
Coverage Δ

src/main/scala/models/AlertLevel.scala
100.00% <ø> (ø)

src/main/scala/models/CheckFrequency.scala
100.00% <ø> (ø)

src/main/scala/checker/StatusChecker.scala
100.00% <100.00%> (ø)

src/main/scala/models/AlertLevels.scala
100.00% <100.00%> (ø)

src/main/scala/models/Group.scala
100.00% <100.00%> (ø)

src/main/scala/models/GroupStatus.scala
100.00% <100.00%> (ø)

src/main/scala/models/GroupStatusSummary.scala
100.00% <100.00%> (ø)

src/main/scala/models/Job.scala
100.00% <100.00%> (ø)

src/main/scala/models/JobStatus.scala
100.00% <100.00%> (ø)

src/main/scala/models/JobStatusSummary.scala
100.00% <100.00%> (ø)

... and 4 more

Continue to review full report at Codecov.

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


Reduce Log.Trace calls in IB brokerage and StatisticsBuilder

Expected Behavior
We should avoid logging the same information repeatedly.
Actual Behavior
In live mode, depending on the algorithm and brokerage, two methods are called very often causing the syslog to grow faster than it should.
Potential Solution
Reduce the calls to Log.Trace in these methods:

IBB.IsWithinScheduledServerResetTimes(): call Log.Trace only when the return value changes
StatisticsBuilder.EnsureSameLength(): call Log.Trace only once

Reproducing the Problem

Deploy this algorithm to IB in QC cloud:

    public class TestIBFutures : QCAlgorithm
    {
        public override void Initialize()
        {
            SetStartDate(2019, 5, 14);  //Set Start Date
            SetCash(100000);             //Set Strategy Cash

            SetBenchmark(t => 0);

            var future = AddFuture("ES", Resolution.Minute);
            future.SetFilter(u => u);
       }

Stop the algorithm after a couple of days
Inspecting the syslog shows too many repeated lines:

2019-12-25T00:13:26.7865510Z TRACE:: StatisticsBuilder.EnsureSameLength(): Padded Benchmark
2019-12-25T00:13:27.0400810Z TRACE:: InteractiveBrokersBrokerage.IsWithinScheduledServerResetTimes(): False
2019-12-25T00:13:27.1955600Z TRACE:: StatisticsBuilder.EnsureSameLength(): Padded Benchmark
2019-12-25T00:13:27.5404300Z TRACE:: InteractiveBrokersBrokerage.IsWithinScheduledServerResetTimes(): False
2019-12-25T00:13:27.5835520Z TRACE:: StatisticsBuilder.EnsureSameLength(): Padded Benchmark
2019-12-25T00:13:28.0407520Z TRACE:: InteractiveBrokersBrokerage.IsWithinScheduledServerResetTimes(): False
2019-12-25T00:13:30.8889420Z TRACE:: StatisticsBuilder.EnsureSameLength(): Padded Benchmark
2019-12-25T00:13:31.0916320Z TRACE:: InteractiveBrokersBrokerage.IsWithinScheduledServerResetTimes(): False
2019-12-25T00:13:31.1247460Z TRACE:: StatisticsBuilder.EnsureSameLength(): Padded Benchmark
2019-12-25T00:13:31.5919090Z TRACE:: InteractiveBrokersBrokerage.IsWithinScheduledServerResetTimes(): False

System Information
QC cloud
Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching issues
[x] I have provided detailed steps to reproduce the issue

Closed by https://github.com/QuantConnect/Lean/pull/3960


refactor: implement agreed upon changes based on discussion (#266)

Description
Based on discussion #266, implement the changes agreed upon there as seen in the task list below.
Tasklist

[ ] create new class MathUtilities
[ ] implement proposed change to create isPowerOfTwo(int) boolean check inside MathUtilities
[ ] create new class Preconditions
[ ] implement proposed change to create requirePowerOfTwo(int) strict precondition inside Preconditions
[ ] implement proposed change to create isBlank(String) boolean check inside StringUtilities
[ ] implement proposed change to move StringUtilities#requireNotBlank(String) to Preconditions

@ata-nas could you confirm if this is still pending or is already completed?

@ata-nas could you confirm if this is still pending or is already completed?

@AlfredoG87 this is pending, I will be including it in one of my PRs soon


feat: add aot option to jest

PR Checklist
Please check to confirm your PR fulfills the following requirements:

[X] The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
[X] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?
Tests run in JIT only.
What is the new behavior?
Tests can run in AOT, using the new aot option.
Does this PR introduce a breaking change?

[ ] Yes
[X] No

Other information

Cf. https://github.com/angular/angular-cli/pull/28854 first


test: testing import and export records

Adds a test to load all demo records and then export them to the
available formats. (related to invenio-records/#169)

Test won't pass until invenio records is released (due to inveniosoftware/invenio-records#180).


Bracket glow and closing bracket matcher not working

On initial install, it was working as designed. For some reason, it no longer is. I've uninstalled/reinstalled, still not working. Is there anything I can try?
To be more specific, I do see a change in the line highlight, but the glow effect and 'matching' bracket highlighter is not working.
https://screencast.com/t/yP1vJtF8

To be more specific, I do see a change in the line highlight, but the glow effect and 'matching' bracket highlighter is not working.
https://screencast.com/t/yP1vJtF8

Thanks for reaching out. I'll take a look at it.
Em 16 de mai de 2017 13:42, "Ryan Gadd"<EMAIL_ADDRESS>escreveu:

To be more specific, I do see a change in the line highlight, but the glow
effect and 'matching' bracket highlighter is not working.
https://screencast.com/t/yP1vJtF8
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/augustovictor/atom-like-brackets-editor/issues/5#issuecomment-301842019,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5QQ4FInGOMcvc4Exjxota8IRTmZFccks5r6dIGgaJpZM4NcxWY
.

Thanks for such a quick reply - here is another video, hope it's helpful. I don't think it's package conflict since I haven't changed anything, and did have it working prior.
https://screencast.com/t/WWkfCKN4O7

It's working now, don't know if that's due to an Atom update or what, but we good. Cheers.


fix spot dir nan again

Objective
fix error with shadow shader's spotlight direction calculation when direction.y ~= 0
fixes #7152
Solution
same as #6167: in shadows.wgsl, clamp 1-x^2-z^2 to >= 0 so that we can safely sqrt it

bors r+

bors retry

bors retry

ubuntu package mirrors are not feeling good right now...

bors r+

bors r+


Patch to fix linking against QScintilla with XCode8

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

This PR adds a patch that fixes issues I've seen when linking against QScintilla 2.9 using XCode. The patch was originally developed by Alan Garny and others, and posted to the QScintilla mailing list in October, 2016. It was used to fix issues building sqlitebrowser, opencor, and was used in Homebrew for the 2.9 release series. It isn't included as a patch in Homebrew for the 2.10+ releases (see commit for 2.10 update), as the relevant sections have been modified, and I suspect it won't be needed.
I was hoping to simply upgrade this recipe to 2.10.8 (as with the other PR), but I can't pull in a version of Qt from conda-forge that uses SIP 4.19 and the 2.10 releases require SIP 4.19.
Here's a build log for QGIS that shows the error, which I'll also post below. QGIS builds fine when linking against my local copy of QScintilla (also up on my ceholden channel).
QScintilla linking error
FAILED: src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditor.cpp.o
$BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-clang++  -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_GUI_LIB -DQT_MACEXTRAS_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_QML_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_UITOOLS_LIB -DQT_WEBKITWIDGETS_LIB -DQT_WEBKIT_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -DWITH_BINDINGS -DWITH_QML -DWITH_QTWEBKIT -Dqgis_gui_EXPORTS -I. -I../src/gui -I../src/gui/symbology -I../src/gui/attributetable -I../src/gui/auth -I../src/gui/editorwidgets -I../src/gui/editorwidgets/core -I../src/gui/effects -I../src/gui/layertree -I../src/gui/layout -I../src/gui/ogr -I../src/gui/processing -I../src/core -I../src/core/annotations -I../src/core/auth -I../src/core/fieldformatter -I../src/core/geometry -I../src/core/layertree -I../src/core/layout -I../src/core/locator -I../src/core/metadata -I../src/core/processing -I../src/core/mesh -I../src/core/providers/memory -I../src/core/raster -I../src/core/scalebar -I../src/core/symbology -I../src/core/effects -I../src/core/expression -I../src/native -Isrc/core -Isrc/gui -Isrc/ui -Isrc/native -I../src/native/mac -isystem $PREFIX/lib/qca-qt5.framework/Headers -isystem $PREFIX/include/qt5keychain -isystem $PREFIX/include -isystem /Library/Frameworks/Mono.framework/Headers -isystem $PREFIX/include/qt -isystem $PREFIX/include/qt/QtCore -isystem $PREFIX/./mkspecs/macx-clang -isystem $PREFIX/include/qt/QtGui -isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers -isystem $PREFIX/include/qt/QtMacExtras -isystem $PREFIX/include/qt/QtXml -isystem $PREFIX/include/qt/QtWidgets -isystem $PREFIX/include/qt/QtSvg -isystem $PREFIX/include/qt/QtPrintSupport -isystem $PREFIX/include/qt/QtNetwork -isystem $PREFIX/include/qt/QtWebKitWidgets -isystem $PREFIX/include/qt/QtWebKit -isystem $PREFIX/include/qt/QtSql -isystem $PREFIX/include/qt/QtConcurrent -isystem $PREFIX/include/qt/QtSerialPort -isystem $PREFIX/include/qt/QtPositioning -isystem $PREFIX/include/qt/QtUiTools -isystem $PREFIX/include/qt/QtQuickWidgets -isystem $PREFIX/include/qt/QtQuick -isystem $PREFIX/include/qt/QtQml -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -I$PREFIX/include -fdebug-prefix-map==/usr/local/src/conda/- -fdebug-prefix-map==/usr/local/src/conda-prefix -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wno-return-type-c-linkage -Wno-overloaded-virtual -Wimplicit-fallthrough -Qunused-arguments -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.9 -fPIC -fvisibility=hidden   -F$PREFIX/lib  -fPIC -std=gnu++11 -Wno-deprecated-declarations -MD -MT src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditor.cpp.o -MF src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditor.cpp.o.d -o src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditor.cpp.o -c src/gui/moc_qgscodeeditor.cpp
In file included from src/gui/moc_qgscodeeditor.cpp:9:
In file included from src/gui/../../../src/gui/qgscodeeditor.h:22:
In file included from $PREFIX/include/qt/Qsci/qsciapis.h:33:
In file included from $PREFIX/include/qt/Qsci/qsciabstractapis.h:33:
$PREFIX/include/qt/Qsci/qsciscintilla.h:2138:25: error: implicit instantiation of undefined template 'QPointer<QsciLexer>'
    QPointer<QsciLexer> lex;
                        ^
$PREFIX/include/qt/QtCore/qmetatype.h:1333:1: note: template is declared here
QT_FOR_EACH_AUTOMATIC_TEMPLATE_SMART_POINTER(QT_FORWARD_DECLARE_SHARED_POINTER_TYPES_ITER)
^
$PREFIX/include/qt/QtCore/qmetatype.h:209:7: note: expanded from macro 'QT_FOR_EACH_AUTOMATIC_TEMPLATE_SMART_POINTER'
    F(QPointer)
      ^
src/gui/moc_qgscodeeditor.cpp:79:27: error: cannot initialize object parameter of type 'QsciScintilla' with an expression of type 'QgsCodeEditor'
    return QsciScintilla::qt_metacast(_clname);
                          ^~~~~~~~~~~
src/gui/moc_qgscodeeditor.cpp:84:26: error: cannot initialize object parameter of type 'QsciScintilla' with an expression of type 'QgsCodeEditor'
    _id = QsciScintilla::qt_metacall(_c, _id, _a);
                         ^~~~~~~~~~~
3 errors generated.
[3016/4858] Building CXX object src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditorcss.cpp.o
FAILED: src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditorcss.cpp.o
$BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-clang++  -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_GUI_LIB -DQT_MACEXTRAS_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_QML_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_UITOOLS_LIB -DQT_WEBKITWIDGETS_LIB -DQT_WEBKIT_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -DWITH_BINDINGS -DWITH_QML -DWITH_QTWEBKIT -Dqgis_gui_EXPORTS -I. -I../src/gui -I../src/gui/symbology -I../src/gui/attributetable -I../src/gui/auth -I../src/gui/editorwidgets -I../src/gui/editorwidgets/core -I../src/gui/effects -I../src/gui/layertree -I../src/gui/layout -I../src/gui/ogr -I../src/gui/processing -I../src/core -I../src/core/annotations -I../src/core/auth -I../src/core/fieldformatter -I../src/core/geometry -I../src/core/layertree -I../src/core/layout -I../src/core/locator -I../src/core/metadata -I../src/core/processing -I../src/core/mesh -I../src/core/providers/memory -I../src/core/raster -I../src/core/scalebar -I../src/core/symbology -I../src/core/effects -I../src/core/expression -I../src/native -Isrc/core -Isrc/gui -Isrc/ui -Isrc/native -I../src/native/mac -isystem $PREFIX/lib/qca-qt5.framework/Headers -isystem $PREFIX/include/qt5keychain -isystem $PREFIX/include -isystem /Library/Frameworks/Mono.framework/Headers -isystem $PREFIX/include/qt -isystem $PREFIX/include/qt/QtCore -isystem $PREFIX/./mkspecs/macx-clang -isystem $PREFIX/include/qt/QtGui -isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers -isystem $PREFIX/include/qt/QtMacExtras -isystem $PREFIX/include/qt/QtXml -isystem $PREFIX/include/qt/QtWidgets -isystem $PREFIX/include/qt/QtSvg -isystem $PREFIX/include/qt/QtPrintSupport -isystem $PREFIX/include/qt/QtNetwork -isystem $PREFIX/include/qt/QtWebKitWidgets -isystem $PREFIX/include/qt/QtWebKit -isystem $PREFIX/include/qt/QtSql -isystem $PREFIX/include/qt/QtConcurrent -isystem $PREFIX/include/qt/QtSerialPort -isystem $PREFIX/include/qt/QtPositioning -isystem $PREFIX/include/qt/QtUiTools -isystem $PREFIX/include/qt/QtQuickWidgets -isystem $PREFIX/include/qt/QtQuick -isystem $PREFIX/include/qt/QtQml -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -I$PREFIX/include -fdebug-prefix-map==/usr/local/src/conda/- -fdebug-prefix-map==/usr/local/src/conda-prefix -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wno-return-type-c-linkage -Wno-overloaded-virtual -Wimplicit-fallthrough -Qunused-arguments -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.9 -fPIC -fvisibility=hidden   -F$PREFIX/lib  -fPIC -std=gnu++11 -Wno-deprecated-declarations -MD -MT src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditorcss.cpp.o -MF src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditorcss.cpp.o.d -o src/gui/CMakeFiles/qgis_gui.dir/moc_qgscodeeditorcss.cpp.o -c src/gui/moc_qgscodeeditorcss.cpp
In file included from src/gui/moc_qgscodeeditorcss.cpp:9:
In file included from src/gui/../../../src/gui/qgscodeeditorcss.h:19:
In file included from ../src/gui/qgscodeeditor.h:22:
In file included from $PREFIX/include/qt/Qsci/qsciapis.h:33:
In file included from $PREFIX/include/qt/Qsci/qsciabstractapis.h:33:
$PREFIX/include/qt/Qsci/qsciscintilla.h:2138:25: error: implicit instantiation of undefined template 'QPointer<QsciLexer>'
    QPointer<QsciLexer> lex;
                        ^
$PREFIX/include/qt/QtCore/qmetatype.h:1333:1: note: template is declared here
QT_FOR_EACH_AUTOMATIC_TEMPLATE_SMART_POINTER(QT_FORWARD_DECLARE_SHARED_POINTER_TYPES_ITER)
^
$PREFIX/include/qt/QtCore/qmetatype.h:209:7: note: expanded from macro 'QT_FOR_EACH_AUTOMATIC_TEMPLATE_SMART_POINTER'
    F(QPointer)
      ^
src/gui/moc_qgscodeeditorcss.cpp:79:27: error: cannot initialize object parameter of type 'QgsCodeEditor' with an expression of type 'QgsCodeEditorCSS'
    return QgsCodeEditor::qt_metacast(_clname);
                          ^~~~~~~~~~~
src/gui/moc_qgscodeeditorcss.cpp:84:26: error: cannot initialize object parameter of type 'QgsCodeEditor' with an expression of type 'QgsCodeEditorCSS'
    _id = QgsCodeEditor::qt_metacall(_c, _id, _a);
                         ^~~~~~~~~~~
3 errors generated.
ninja: build stopped: subcommand failed.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Thanks for your contribution!

I was hoping to simply upgrade this recipe to 2.10.8 (as with the other PR), but I can't pull in a version of Qt from conda-forge that uses SIP 4.19 and the 2.10 releases require SIP 4.19.

I've been working on this upgrade too (see https://github.com/conda-forge/qscintilla2-feedstock/pull/17), but left it because there were too many problems I didn't have time to solve.
The strange thing is that the pkgs/main or anaconda channels do provide a newer version of Qt (5.9.7) than conda-forge (5.6.2), with the accompanying newer sip version. I don't know why conda-forge does not update Qt anymore, but I remember it had something to do with Windows compatibility.
It's really difficult to build QScintilla with dependencies from both channels, so I hope the conda-forge crew decides to update Qt packages on their channel too sometime soon.

@conda-forge/core, there are so many CI scripts now. The traditional ones pass for this build, but 3 newly added ones fail. Do they all need to pass before merging this commit into the master branch, or are some checks experimental?

My commit 6426e21 doesn't actually do anything -- the tests fail on Azure because find is interpreted as the *nix file search program, and not the batch one. Test passes on both AppVeyor and my local test VM and I'm not immediately sure how we'd be able to make it work in both environments.
For providers it looks like we can force one or the other in the conda-forge.yml using the provider field. Elsewhere it mentions Azure is default on Linux and OSX, which are both passing there. I tried rerendering with win: appveyor set explicitly but none of my files were modified, and the azure-pipelines-win.yml is set not to upload packages (on all platforms, too). Not exactly sure what will happen though

You can ignore windows on azure

So this can be merged?

@dschreij I think so! Thanks for your attention to this, and feel free to ping me when the conda-forge Qt stack updates (I think 5.12 is next) and we can update to a newer version of QScintilla that won't need the patch (fwiw the changes in your PR were still good when I tried latest release).


Only check for moly_path if moly_point=True

Is your feature request related to a problem? Please describe.
The current tiling and tma notebooks require a path to a moly FOV even if the user isn't planning on including a moly FOV.
This creates problems for users who don't know what this is.
Describe the solution you'd like
Only check for valid moly paths if the user has indicated they plan on using a moly FOV

duplicate of #90


Make an intro

Make an intro (introduction), where in 2-4 sentences describe what you do, what you like to do, what you want to do better, what is important to do, why you are here.

done


Chanduthedev

Checklist

[x] I ran npm test locally and it passed without errors.

[x] I only edited the _data/pixels.json file.

[x] I entered the username in the pixels.json that I'm also using to create this pull request.
[x] I acknowledge that all my contributions will be made under the project's license.

hi @chanduthedev, it looks like this is a duplicate as you've already claimed this pixel in another pr. Thanks for your contribution. Going to go ahead and close this one out. 😄


Is it possible to register a notification callback when using tx_trace_user_event_insert?

Is it possible to register a notification callback when using tx_trace_user_event_insert?

I don't see an easy way to do this without modifying the code in tx_trace_user_event_insert.c or the macro TX_TRACE_IN_LINE_INSERT.  Could you share a bit more on what you are trying to accomplish in the callback?


Remove Shard Semaphores

Changes Introduced
Having Semaphores around the shards was not necessary as using Ref.update is atomic on its own. This just introduced more performance overhead.
Applicable linked issues
N/A
Checklist (check all that apply)

[X] This change maintains backwards compatibility
[ ] I have introduced tests for all new features and changes
[ ] I have added documentation covering all new features and changes
[X] This pull-request is ready for review

Codecov Report

Merging #113 (4f79587) into main (f0bd7ad) will decrease coverage by 0.05%.
The diff coverage is 81.48%.

@@            Coverage Diff             @@
##             main     #113      +/-   ##
==========================================
- Coverage   89.11%   89.05%   -0.06%
==========================================
  Files          86       86
  Lines        2829     2797      -32
  Branches       77       89      +12
==========================================
- Hits         2521     2491      -30
+ Misses        308      306       -2

Impacted Files
Coverage Δ

...in/scala/kinesis/mock/api/MergeShardsRequest.scala
100.00% <ø> (ø)

...ain/scala/kinesis/mock/api/SplitShardRequest.scala
100.00% <ø> (ø)

...ala/kinesis/mock/api/UpdateShardCountRequest.scala
100.00% <ø> (ø)

src/main/scala/kinesis/mock/models/Streams.scala
50.00% <9.09%> (+8.33%)
:arrow_up:

...n/scala/kinesis/mock/api/CreateStreamRequest.scala
84.00% <100.00%> (-1.72%)
:arrow_down:

...n/scala/kinesis/mock/api/DeleteStreamRequest.scala
93.93% <100.00%> (-0.51%)
:arrow_down:

...main/scala/kinesis/mock/api/PutRecordRequest.scala
97.14% <100.00%> (-0.08%)
:arrow_down:

...ain/scala/kinesis/mock/api/PutRecordsRequest.scala
100.00% <100.00%> (ø)

src/main/scala/kinesis/mock/cache/Cache.scala
78.06% <100.00%> (-0.42%)
:arrow_down:

...rc/main/scala/kinesis/mock/models/StreamData.scala
100.00% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

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


Ignite WAL reader dev tool and related changes

Please do not merge, this PR is only for testing
IGNITE-6235: Add ability to handle CacheObject from DataRecord in sta…
IGNITE-6225: Improve tests of WAL iterator with checking DataRecord entries and TxRecords
IGNITE-6014 Added possibility to configure Tx Records on prepare and commits
IGNITE-6277 Convert WAL to human readable form

Features were merged already as part of other PRs


Feature: network use native system stores

By default, a bundle of SSL certificates is used, through certifi. This PR allows QDT to use the system certificates store.
In this PR:

add truststore as dependency to use new Python APIs (3.10) to deal with native system certs stores
add a new QDT_SSL_USE_SYSTEM_STORES environment variable to enable this feature as an opt-in
add related documentation

Related documentation: https://guts.github.io/qgis-deployment-cli/guides/howto_behind_proxy.html#id1
cc @DeCiZoR and @Niarolf

Codecov Report
Attention: Patch coverage is 45.45455% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 68.39%. Comparing base (f546ab6) to head (4f913a5).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #444      +/-   ##
==========================================
- Coverage   71.52%   68.39%   -3.14%
==========================================
  Files          45       45
  Lines        2634     2645      +11
  Branches      566      568       +2
==========================================
- Hits         1884     1809      -75
- Misses        572      655      +83
- Partials      178      181       +3

Flag
Coverage Δ

unittests
68.09% <45.45%> (-2.83%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

qgis_deployment_toolbelt/utils/file_downloader.py
75.00% <50.00%> (-3.95%)
:arrow_down:

qgis_deployment_toolbelt/utils/journalizer.py
69.01% <40.00%> (-5.23%)
:arrow_down:

... and 4 files with indirect coverage changes


concurrency: use current revisions for election

Watching from the leader's ModRevision could cause live-locking on
observe retry loops when the ModRevision is less than the compacted
revision. Instead, start watching the leader from at least the store
revision of the linearized read used to detect the current leader.
Fixes #7815

lgtm

the fix looks good to me.
i am thinking:

if we can merge the two watch code path in observe func.

do we really need to return ANY historical proposals. or just observe from current is good enough for users.

yeah, that should be do-able.
most recent is probably good enough. Relying on historical election data seems like broken app logic.

@xiang90 I gave the watch path merging another thought. The most obvious way to do it would be to open a watch on the prefix, but that will cause extra traffic from events that can be ignored (e.g., campaigner leaves before ever winning election). Not sure what should/would be simplified exactly.

Not sure what should/would be simplified exactly.

OK. I am not super worried about it. Just one random thought. I am OK with merging this pr as it is. We need to put some thought into my second point though.

OK merging since failures are unrelated.


TypeError: Cannot handle this data type: (1, 1, 1200), |u1

I want to train the melgan model with LJSpeech datasets.
When I follow the readme file, this error occured.
Anyone get the same error with me and know the solution of the error?
Thank you

I solved this error by changing the conda virtual environment.


Fails when running against a draft build definition

I've added this task to our build, and tested it out with a draft build.  It fails when attempting to retrieve the build definition:
2016-05-04T15:25:11.1750165Z ##[debug]Getting build number [MyProduct_Dev_1605.01.DRAFT] using definition ID [119 180]
2016-05-04T15:25:11.1750165Z ##[debug]GET  http://teamserver2:8080/tfs/MyCollection//ProductX/_apis/build/builds?api-version=2.0&definitions=119 180&buildnumber=MyProduct_Dev_1605.01.DRAFT with 0-byte payload
2016-05-04T15:25:21.0141995Z ##[error]The remote server returned an error: (400) Bad Request.
The error is that "119 180" is not an integer.  Is this build number the format used for a draft build definition?
Full log here:
7_Generate release notes.txt

Yes I can repo that, I will have a look to see what is happening

See of the new V 1.1.1 task I just published fixes the problem

Updated to V 1.1.1 (which TFS doesn't make easy, but that's not your problem :smile:). V 1.1.1 fixed the draft build issue.

Good, glad it was a quick fix. Turns out I did not need to pass the parameter that was causing the issue at all.
As to you second point ,hopefully there will be an easier way to manage the updates in the future


Move 'aws-serverless' components down into 'aws'

Not ready for review.  Will ping when so.
There are many components to this change.  So it's worth outlining all of them:

Moving 'EventSubscription' down to aws.lambda.EventSubscription.
Move 'createLambdaFunction' down to aws.lambda.createLambdaFunction.  Note: this should perhaps just be called .createFunction.
Deprecate aws.serverless.Function (and all corresponding types it exports), with documentation saying to use the corresponding functions and types in aws.lambda instead.
Make the helpers/types surrounding creating aws.lambda.Functions strongly typed.
Move Bucket-Subscription code down from aws-serverless into aws.s3.
Use mixins to add that subscription functionality onto aws.Bucket itself.

All of the above has been done in a backward compatible fashion. i.e. we have deprecated, but kept around, all existing types/functions/classes.  Though, to ensure we don't have massive duplication, the old code sits on top of the new code now.
I will also add a bunch of review comments to help explain what's going on.

Cool -- definitely eager to hear what @jen20 thinks!

Note: i've only moved one set of subscriptions down as i'd like to get consensus on what people see here first.  Once i do, i can move the rest of https://github.com/pulumi/pulumi-aws-serverless/pull/31 down into this (or do it in an immediately following PR).

@lukehoban You had an open question about how things like 'Roles' would be parented in this new formalization (where we deprecate aws.serverless.Function).  THere are two answers, depending on which part of the API you call into.

If you call directly into aws.lambda.createFunction(name, handler, opts) then the Role created will be parented by whatever 'parent' is set by 'opts'.  This is somewhat unsatisfying if opts is not provided, as that means it will be parented by the stack.  However, this is alleviated by:
If you are creating the lambda for something like an event-subscription (like a BucketEventSubcription).  IN this case the subscription itself is the parent resource as it is the component that logically creates and owns the Lambda and connects it to hte bucket.  You can see that in this representation:

     Type                                Name                          Status      Info
 +   pulumi:pulumi:Stack                 bucket-cybucketawstest        created     1 warning
 +   ├─ aws:s3:Bucket                    testbucket                    created
 +   │  └─ aws:s3:BucketNotification     test-object-created           created
 +   └─ aws:s3:BucketEventSubscription   test-object-created           created
 +      ├─ aws:iam:Role                  test-object-created           created
 +      ├─ aws:lambda:Function           test-object-created           created
 +      ├─ aws:iam:RolePolicyAttachment  test-object-created-32be53a2  created
 +      └─ aws:lambda:Permission         test-object-created           created

In general, our advice should be that those component that actually end up causing the lambda to be created should pass a reasonable parent for that lambda (often themselves).

@jen20 @lukehoban Can you guys take a look?  My primary PR concern here is if anything stands out to you as "oh no... i don't like that".  This is less about the core implementation and more about if the design/shapes for the API we'll be exposing feel appropriate.
On a personal level, i like it a lot.  I've been using it both here and in https://github.com/pulumi/pulumi-aws/pull/328 and it feels much better and much more natural.  But i want some separate eyes here before proceeding.
Note: i would very much like the reviews done today if possible.  That would make it possible for me to do the whole work of moving all of 'serverless' down to 'aws' and to get 'cloud-aws' ported over onto this this weekend.
Thanks!


Increase resource dependencies & visibility

We expose the associated resources created via the flow framework workflow, but do not show other resources that may be used within such flows. We should add these if found:

[ ] models (via ML processors)
[ ] connectors (via models)
[ ] indices (if "skip ingest" is selected, and a specified index is set on the search flow)

Additionally, we can have visual helpers to show the dependencies somewhere.

Tentatively setting to 3.0 while priority's determined.


Unit Tests

Unit tests need to be added for all available components.

And integration with Travis CI FTW


Add Sonatype download stats

This PR adds data about circe-core downloads that I've exported from Sonatype. This data could potentially be useful for making decisions about Scala version support (e.g. 2.10 now makes up only ~6% of downloads, and it's falling), whether bug fixes should be backported to earlier circe versions (I learned that a lot of people still seem to be using circe 0.4), etc. It's also just generally kind of interesting (to me, at least).

Downloads by Scala version.
Downloads by circe version.

The plan would be to add new data as it comes out every month. As far as I know Sonatype doesn't provide a way to export monthly data that's more than a year old, so we'll have to start with June 2016.
I've only added circe-core data for now, but could include other modules.

Codecov Report

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

@@            Coverage Diff             @@
##           master     #675      +/-   ##
==========================================
- Coverage   85.17%   84.88%   -0.29%
==========================================
  Files          70       70
  Lines        2131     2131
  Branches      137      138       +1
==========================================
- Hits         1815     1809       -6
- Misses        316      322       +6

Impacted Files
Coverage Δ

...o/circe/generic/util/macros/DerivationMacros.scala
78.43% <0%> (-9.81%)
:arrow_down:

...re/shared/src/main/scala/io/circe/KeyDecoder.scala
43.24% <0%> (-2.71%)
:arrow_down:

Continue to review full report at Codecov.

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


fixed Django 1.8 complain about related name

Django 1.8 complains because of invalid regex. So, I tried to to remove . (dot) character and it worked.

Hi! Thanks for the PR!
I've merged the source_expressions commit.
The related_name issue was addressed in a better way in #127, I've merged that PR instead.


arm64 version of asserts

status:
libunwind: 1.1 -> 1.5 , 1.2 and later start support aarch64

things might change:

libunwind: 1.1 -> 1.5 , 1.2 and later start support aarch64

openssl: should use  ./config no-afalgeng, or error with: error: '__NR_eventfd' undeclared

brpc:

compile fail: config_brpc.sh 默认都加了 -msse4 & -msse4.2 option
performance issue: https://github.com/apache/incubator-brpc/issues?q=is%3Aissue+is%3Aopen+aarch64

LLVM: build on target AArch64

zetasql

bazel: 1.0.0 -> 3.7.2 ? 1.0.0 have no arm64 binary
patch abseil version: fix the compile error:abseil/abseil-cpp@2e94e5b

the aarch64 thirdparty consider experimental

upgrade package only for aarch64
check libunwind  is needed for aarch64


⚠ Bofrost.de has degraded performance

In 7966131, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1708 ms

Resolved: Bofrost.de performance has improved in 3c8a436 after 312 days, 5 hours, 58 minutes.


Improve Stairs Pieces

Proposed Changes

Makes my stairs not look terrible
Some stairs still have chests under them

Small Preview

Really wish I got this in sooner but I was hella busy.


Sort flags alphabetically

Signed-off-by: Wiard van Rij<EMAIL_ADDRESS>Relates to https://github.com/thanos-io/thanos/issues/4034
It sorts the flags alphabetical

[ ] I added CHANGELOG entry for this change.
[x] Change is not relevant to the end user.

Changes
The latest release of the kingpin package is from 17 Dec 2017. It was missing any method to do some funky stuff to get this done. That is, unless we want to manually order all flags in the code.  Open for review anyway, LMK.
Verification

Locally tested.
Will update further if this is the way to go...

Nice!
Can we try running make docs to update our docs? 🤗

Yea, I wanted to review this first and discuss it before making it final :)

I don't know why the test is failing.
Local:
make docs
all modules verified
>> building Thanos binary in /Users/wiard/go/bin
 >   thanos
>> generating docs
msg=success
>> cleaning white noise

->
 make check-docs
all modules verified
>> building Thanos binary in /Users/wiard/go/bin
 >   thanos
>> checking docs generation
msg=success
>> checking links (DISABLED for now)

Now all works, just flaky test, retried

Now all works, just flaky test, retried

It's because I cannot access /tmp locally - non-root (:  It makes up some funky /var directory. I manually fixed this (:
Also I'm taking over your smiley behaviour..

Thank you! LGTM!
cc @idoqo

Right, looks great! Will update the docs in #3993 and see how that goes. Thanks @wiardvanrij


refactor yubihsm: drop curl & pkgconfig build deps; libusb runtime dep

Change Description

In 1.7 libyubihsm was integrated in to eosio's keosd making it significantly easier to use compared to tracking down a shared lib and placing it in the correct location. This also meant building eosio required a few new dependencies like pkgconfig, libusb, and libcurl. But these are very common packages so no problems, right?
Unfortunately yes, there has been some grief. For example, there was recently some pkgconfig+libcurl issues with our macos builds due to something in homebrew going awry. The way libyubihsm pulls in OpenSSL forces dynamic linking of it thus causing problems with macos hardened builds. libusb is LGPL which means if we ever wanted a "standalone" binary we couldn't static link libusb.
This PR resolves these issues and reduces the build and runtime depencies of eosio.

pkgconfig: no longer used. Instead, typical cmake constructs are used to find dependencies
libcurl: no longer used. the http code has been completely refactored to use boost beast instead of libcurl
libusb: Now optional at build time. If it's not found at build time a warning message is displayed via cmake and libyubihsm is built without usb support. If it is found at build time, USB support is enabled but eosio will not link to libusb. Instead, at runtime, a dlopen() is performed on libusb and it's used that way. This allows, for example, a standalone binary that doesn't balk at the absence of libusb on startup.

I constructed the changes such that upstream's repo can still be used without a fork. This means upstream's CMakeLists.txt is completely ignored and "reimplemented" locally. I realize there are advantages and disadvantages to this approach but it seemed the best fit to me.
I've removed libcurl and pkgconfig from cicd & script dependency installs. But for Ubuntu I needed to replace it with build-essential (which we probably should have been installing anyways).
Leaving as draft until I decide what to do about lack of unit testing. At a point ready for feedback though.
Consensus Changes

[ ] Consensus Changes

API Changes

[ ] API Changes

Documentation Additions

[ ] Documentation Additions

Have you considered using http_client from fc library in implementation? it is based on boost beast as well.
You can add it to the struct state  and make all calls through it. We don't have tests for it either. However it is something already in use.
P.S.
FYI: There are plans for unified http(s) solution. During BlockVault work I was working on https server and client plugins based on boost beast. Than it was moved to SQL solution but server is ready for about 50-60%. And it does have tests. Actual plans to finish that and to make existing http_server_plugin as a proxy to new plugin or library. And if we will have enough reasons to do the same with http_client there are chances we will do same for client.


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from  to before v5.15.12",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cb6c99aedd2c843056a598a8907a6128cb07603b"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "cb6c99aedd2c843056a598a8907a6128cb07603b",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "hamradio: defer ax25 kfree after unregister_netdev\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15.12 by commit cb6c99aedd2c843056a598a8907a6128cb07603b. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2021-1002845


v1.0  led_buitin

Hi,
Missing  #define LED_BUILTIN  2
in v1.0
Apart this everything runs ok in platformio.
Regards
JPD

Hi Jean-Pierre,
This is a constant predefined by the arduino-esp32 core for the doitESP32devkitV1 board ;-)


Feature Request: Shorten long lines in Grep Search

Hi Tadashi!
problem
I noticed that the grep search always shows the full line where a search hit occurs. In some cases, I have very long paragraphs, like this one:

While some context is useful, displaying the full line here takes up so much space that the other search hits are pushed out of view.
suggested solution
Therefore, I'd like to suggest some sort of automatic trimming when a search result is too long. I am not sure what a good value for this might be. Maybe everything beyond 100 characters before/after the matching word could be trimmed? If there are multiple matches in one line (e.g. If I had another "growth" in that line) this would become a bit more tricky. Maybe the 100 character limit could be applied to before the first and after the last match then?

Hi, @chrisgrieser :)
The ripgrep doesn't have such a feature, but I understand there may be use cases where it's needed. I will consider adding an option 👍

LGTM

@chrisgrieser
Released in v8.14.0 🚀

thank you 😊


Update solid queue to 0.7.1

coverage: 93.434%. remained the same
when pulling 8c6d6e77d8121413609d5989c1700bf25caca89e on solid-queue-0.7.0
into eb2d28ca8afd8bf05e49bd7f313ba7bfeebcc235 on main.


Allow creation and edition of text-files with google drive.

Not perfect yet, but still figuring out things.

Ok, reworked a bit.
I have some edge cases, when passing upload to drive, if not passing metadata, mimetype is set to NOTEBOOK_MIMETYPE. I went around by not setting metadata.
But now I have an issue with observe, where the comparison is bad, and it tells me something has replaced the file while I was working on it....

Actually I'm having the same issues with observe on master.  Maybe the original logic was wrong and had race conditions.
I like the new version.  It wasn't what I had in mind, but what you've done is better because you create the entire contents model in files_resource_to_contents_model.  I was thinking of creating all of the contents model except for the actual contents field in files_resource_to_contents_model.

AS far as I can tell, even if I re-do a get just after the save, I get the same head revision ID.
.... I'm not sure what's happening.

could it be that Drive is simply slow in updating head revision ID?

This may be a bug in Drive.  I didn't notice this behavior before.  When I log the resource object before and after save (i.e. at the same points in save where that.last_observed_revision[resource['id']] and that.observe_file_resource(resource); are called) it is exactly the same.  Since the second point is where we get the response from Drive from saving the file, this seems very wrong.

Yep, agreed. Sometime it's the same, soemetime it is not for me.
if I try to chain a few get_resource_for_path(path, drive_utils.FileType.FILE) I think it might change in the middle

Bingo !

Thanks for confirming that this really is the bug.
I don't think our current strategy is wrong.  What we are doing is creating non-pinned revisions for each autosave, and pinned revisions for each checkpoint.  This approach has some advantages because it makes maximal use of Drive's revision system.  Updating revisions would lose information.  But it also wouldn't make a difference either way for this bug (probably) because there is only one API call that can upload data to a file, whether you choose to update an existing revision or create a new one.

But I have a solution anyway.  Right now we rely on data that we get back from Drive after a save (revisionId).  Instead, we can attach data of our own to the file, when we save.  You can attach arbitrary key-value pairs as file metadata.  So when we save, we write a unique id with key last_save_uuid.  If this property is changed, we know someone else wrote to the file

Ok, maybe we can delay on that, and in any way have a periodic timer that checks revision ID and content hash to warn if content on drive did actually change ? Plus change the text that file on drive may have change ? It could be sufficient for now.

But I have a solution anyway. Right now we rely on data that we get back from Drive after a save (revisionId). Instead, we can attach data of our own to the file, when we save. You can attach arbitrary key-value pairs as file metadata. So when we save, we write a unique id with key last_save_uuid. If this property is changed, we know someone else wrote to the file

Seem reasonable also.

I can write up my solution pretty quick, I've written something similar for colab.

I can write up my solution pretty quick, I've written something similar for colab.

Sure.
I also made you collaborator on my branch, so you should even be able to push thing directly on my repo if needed. I'm going to make diner now, and be back after.

ok thanks, I'll start work on the fix now.

Re-added ability to create folders.

is this ready for merging?  Seems to work for me now.  Also the Drive problem seems to have gone away.

is this ready for merging? Seems to work for me now. Also the Drive problem seems to have gone away.

Sure sorry was traveling with pretty bad internet, will be off again for a few hours today (in train wit no internet)

Great.
Computer just died. Battery refuse to change. Hopefully just charger. Closest apple store is 70miles from here, and will be closed by time I get there... Will look at that back tomorrow from not-my-phone.
I think I am cursed.
Envoyé de mon iPhone

Le 29 janv. 2015 à 16:00, Kester Tong<EMAIL_ADDRESS>a écrit :
Merged #56.
—
Reply to this email directly or view it on GitHub.


Review: NavBars

(Delete all text in parentheses when filling out this template, including this text.)
Overview
For this review, we're going to take a look at the Navbar Home and Navbar Landing components.
Review Branch
review-#5
Files to review

NavBarMain.jsx
NavBarLanding.jsx

Checklists
(Please edit the following list if necessary to indicate the actual checklists to be used.)

Architecture
Design
JS

Due date
March 1, 2021
For more information
The review process is documented at: http://courses.ics.hawaii.edu/ics414s21/morea/review/reading-idpm-review.html

NavbarMain.jsx
JS-01: Name constructs appropriately.

Line 76 the name "NavBar2Containter" does not match the class name. It should be something like NavBarMainContainer.
The name for the userstyling could be more descriptive.

NavBarLanding.jsx
Design-09: Ensure reusable code is exported or made available in the appropriate place.

Some of the css styles should be places in the style sheet, so it is made available to edit later when trying to fix the styling for mobile.

JS-01: Name constructs appropriately.

Line 76 the name "NavBar2Containter" does not match the class name. It should be something like NavBarLandingContainer.

NavBarHome.jsx
Design-05: Ensure comments are appropriate.
Design-07: Ensure code is readable.
There are certain areas where the code could be reorganized to be read better
JS-01: Name constructs appropriately.
Maybe rename it so that the it is used
NavBarLanding.jsx
Design-05: Ensure comments are appropriate.
Some areas could have comments
Design-07: Ensure code is readable.

NavBarLanding.jsx:
Design-05: Ensure comments are appropriate
This navbar is only used on the landing page but the comment says that it appears on top of every page. Also is not rendered by the App component.
NavBarHome.jsx:
JS-01: Name constructs appropriately
Consider changing the file name since this navbar is not only used on the home page.
Design-05: Ensure comments are appropriate
This navbar is not rendered by the App component.
Design-07: Ensure code is readable
Some in-line styling are defined as consts at the top while others are defined in the component. Might want to make them all consts so components are easier to read.

NavBarMain.jsx
Design-05: Ensure comments are appropriate.
More comments should be used throughout the code.
Design-09: Ensure reusable code is exported or made available in the appropriate place.
Stylings like navbarVerticle and userstyling could be placed in the css style sheet.
NavBarLanding.jsx
Design-05: Ensure comments are appropriate.
More comments should be used throughout the code.
Design-09: Ensure reusable code is exported or made available in the appropriate place.
Stylings like menuStyle, loginButton, and logo could be placed in the css style sheet.

NavBarMain.jsx
Design-05: Too few.
I do not see any other errors.

NavBarLanding.jsx:
JS-01: Name constructs appropriately
Line 76 NavBar2Container could be changed to NavBarLandingContainer to be more consistent with file name
Design-09: Ensure reusable code is exported or made available in the appropriate place
loginButton and logo styling could be placed in stylesheet so that other files that use buttons/logo can consider using the same styling
NavBarMain.jsx:
JS-01: Name constructs appropriately
Line 95 NavBar2Container could be changed to NavBarMainContainer to be more consistent with file name

NavBarMain.jsx
JS-01: Name constructs appropriately
Line 95, you could change the name NavBar2Container to be consistent with the file name
Design-07: Ensure code is readable
There are portions where the code can be organized
NavBarLanding.jsx
JS-01: Name constructs appropriately
Line 76, ditto as in NavBarMain.jsx

NavBarMain.jsx:
Design-07: Ensure code is readable, comments on Menu Items?
NavBarLanding.jsx:
Design-09: Ensure Reusable code is exported or made available in the appropriate place, constants with css style can actually be placed in style.css

NavBarMain.jsx
React-09: L13 prefer function since doesn't have state.
JS-08: L15, 94, 99 replace /** with //
ESLint: L38 can't we add a key to the menu?
NavBarLanding.jsx
React-09: L13 prefer function since doesn't have state.
JS-08: comments


Handle long-running computations in tECDSA DKG states

Refs: #3041
Here we are refactoring tECDSA DKG states that perform long-running TSS computations. As those computations may take longer than the state's lifetime, we need to set up a proper timeout signal to avoid resource leaks. The state's context passed as an argument of the state.Initiate function would be a good candidate, but it works as expected only if state.Initiate returns before the state's end block is reached.
So far, we were using a simple fixed timeout based on state block duration though this solution is not sufficient for the long term as the average block time can change and lead to weird corner cases.
Instead of that, we are now triggering long-running computations and message broadcasting in a separate goroutine upon state initiation and use the state's context as the timeout signal. In order to handle the state logic's outcome, we are using the success and errors channels that pipe the outcome to the state.Next function which is invoked at the end of the state. If state's computations were successful, we're proceeding to the next state. Otherwise, a state error bubbles up and breaks the entire state machine instance.
The aforementioned mechanism requires some changes in the state machine logic and state.State interface that are also part of this changeset.

Tested it locally with a group size of 20 given the problems from #3161. ECDSA DKG completed successfully.


Add github repo link in footer

Add the repository link of GitHub in the footer.

Hello, @stefangarces , go ahead try to solve this issue. And create a PR.

I think @hkbertoson you will not mind as he had asked for the assign first and we should follow the ethics of open- source. Though you can work on manu open issues.

No worries at all! I understand.

Sure! I will get it updated and
PR opened.


Can we have different icons for Filter transactions?

Describe the bug
Currently we have similar icons for Coinbase, Poison-microblock and Token transfer in Filter Transaction. I think we can have different icons for each one of them.
To Reproduce
Steps to reproduce the behavior:

Go to 'https://explorer.hiro.so/transactions?chain=mainnet'
Click on 'filters'

Screenshots

If this enhancement is desired:
I would like to take up the issue.
Maintainers please suggest the icons that can be added here.
Thanks!

@andromeda995 Can you suggest icons, please?

Yup I can work on this - I will post an update here for the Figma mocks once it's finished.

@andromeda995 Any update on this ?

@shamim-io

https://www.figma.com/file/31q1g27k69z1yXb6r6vrRD/Explorer-(will-be-deprecated)?type=design&node-id=4978%3A24133&t=kVbFIQVQutk0iDOB-1
@shamim-io  please use these two icons at 16x16px to replace what we currently have for coinbase (on left) and poison microblock (on right)

@andromeda995 @andresgalante @He1DAr Added a PR of new icons addition. [Feature: Added transaction icons #1181]. Kindly review it. Thanks!

@shamim-io Thanks for another great PR! 🎉

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


Prettify files

This gives and keeps consistent formatting

Closing this in favor of https://github.com/GetStream/stream-js/pull/200


Validate user before trying to create it on API

There are no validation for the API mandatory fields, also, the API response is not very clear on what's missing.
I can contribute on that if you agree with the change.

Hi @flaviamissi, there is infact no validation in any of our SDKs, partly to keep things as simple as possible.
As for the response giving the info that is required, the exception given always includes a part "Errors" which details each field and the error associated with this. If you feel this isn't clear enough, feel free to  make a pull request and we'll see if we can incorporate it in the next release.
Thanks!


the regen effect used for damage negation can heal the player for more than the damage dealt from an unarmed zombie

Haven't tested it with other difficulties yet

here's the command for the shield used give @p minecraft:carrot_on_a_stick{display:{Name:'{"translate":"","italic":false}',Lore:['""','{"translate":"item.modifiers.blocking","color":"gray","italic":false}','[" ",{"translate":"attribute.modifier.equals.0","color":"blue","italic":false,"with":["4",{"translate":"attribute.name.shield.block"}]}]','[" ",{"translate":"attribute.modifier.equals.time","color":"blue","italic":false,"with":["60",{"translate":"attribute.name.shield.block_time"}]}]','[" ",{"translate":"attribute.name.shield.decay.low","color":"blue","italic":false}]','[" ",{"translate":"attribute.name.shield.angle.wide","color":"blue","italic":false}]']},CustomModelData:0,shield:{default_model:0,blocking_model:0,block_value:4,minimum_block_value:0,player_block_effect:1,entity_block_effect:1,max_time:1200,cooldown:20,durability:5,bash_effect:0,x_angle:90,y_angle:120,can_reflect_arrows:1b,disable_time:50}} 1

any difficulty has the issue apparently

The effects supplied are examples and are not intended to be balanced.


checker(dm): support concurrent check

What problem does this PR solve?
Issue Number: close https://github.com/pingcap/tiflow/issues/3974
What is changed and how it works?

support concurrent check table_structure and table_consistency
the checker thread follows the change of MydumperConfig.Threads

Check List
Tests

Unit test
Manual test

10000 tables with default dumpconfig.thread

added delay
spend time

10 ms
31s

20 ms
56s

50 ms
130s

100 ms
175s

Code changes

Has interface methods change

Related changes

Need to update the documentation

Release note
Please add a release note.
If you don't think this PR needs a release note then fill it with `None`.

/run-dm-integration-test

/run-dm-integration-test

/run-dm-integration-test

/run-dm-integration-test

test passed all. /cc @Ehco1996 @GMHDBJD

/run-dm-integration-test

/run-verify

/run-dm-integration-test

/run-all-tests

/run-all-tests

Codecov Report

Merging #3975 (b1220b2) into master (08da001) will decrease coverage by 0.0534%.
The diff coverage is 49.6915%.

Flag
Coverage Δ

cdc
58.7180% <62.2369%> (+0.0732%)
:arrow_up:

dm
52.0661% <40.2823%> (-0.1885%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.


Enhancement/boundaryconditions

This updates puts in the infrastructure for non periodic boundary conditions. It implements 3 options: static, sommerfeld and reflective boundaries, or any mixture of these in each direction.
! ! NOTE THAT THIS UPDATE REQUIRES USERS TO INHERIT THEIR SIMULATIONSPARAMETERS.HPP CLASS FROM EITHER SIMULATIONPARAMETERSBASE.HPP OR CHOMBOPARAMETERS.HPP ! !
Assuming that inheritance is used to create the SimulationParameters class, then activating the boundary conditions is done by simply amending the parameters file. See the ScalarField Example params.txt file as an example of what needs to be specified, or check the ChomboParameters.hpp file in the GRChomboCore folder.

As far as I'm concerned, I'm happy for this pull request to be merged now but I won't approve it in case @mkunesch still wants to look.

Hey,
thanks a lot and sorry it took me so long to look into this. I think the changes are really good! Regarding the compulsory inheritance from ChomboParams there would be several solutions but none of them are perfect. I think we should just go for it and require users to inherit. In the long term we may want to look at the parameter classes again and reorganise it with something that's nicer but I don't think that's urgent and definitely shouldn't stop us from merging this PR.
While reading through the code I have made a few cosmetic changes and pushed them to enhacement/boundaryconditions_markus. Take a look and merge/cherry-pick whichever commit you like there :-).
Thanks a lot!

So yeah, I approved just now - feel free to pick whichever changes you like from enhacement/boundaryconditions_markus and merge (they are all cosmetic so I approved without them).

I like all of Markus' changes.

I like all of Markus' changes.

Me too! They really improve the readability.
Thanks very much for this Markus :-) I'm going to merge your changes into this branch and then merge the pull request. Thanks also Miren for fixing the ghost cell swap! I'm very happy that we now have a proper boundary conditions class, and we should be able to easily add other types of boundaries as needed.