Add ability to run injectJs

I found injectJs heavily important because it allows to use polyfills in the code. I'm working on it now

Thanks @asiniy. I'd be interested in seeing this implementation. There's a few things that are important to consider. It seems like injectJS is specific to phantom. Currently our only communication to phantom is through ghostdriver (the phantomjs webdriver implementation). If we're going to allow for injection of polyfills and other scripts we'll also have to make sure that it works with other drivers in the future. For now that would mean making sure your changes only impact the current phantom driver.
At a higher level, I'm curious as to why you would opt to inject the polyfill directly into phantom instead of including it as part of your asset compilation step.

@keathley phantomjs doesn't support promises - that's it. So, I need this support, because I'm writing in ES6. I tried to inject this polyfill to the webpack build (it changes output.path depending on the ENV), but haven't understand how to do it. Maybe you can help me with that instead (and you'll save me tons of hours btw)?

@asiniy did you manage to get this resolved. IMO I think this is something that should be handled outside of wallaby in your specific asset setup. I'd rather focus on finishing up selenium support which will help with a lot of these issues anyway.

@keathley yeah, I set up my build properly, everything works. I'm closing the issue


add Card page

implemented Card page.
Live: https://poshui-card.netlify.app/pages/card.html

Thanks for reviewing.


Added Czech translation

Thank you very much for your time!
I will merge this as soon as i'm done with the other translations. :+1:


Exception swallowing in refresh token handler

The RefreshTokenDelegatingHandler exposes this event:
https://github.com/IdentityModel/IdentityModel2/blob/409f2493d333d3921586a20fce88971e4d019041/src/IdentityModel/Client/RefreshTokenDelegatingHandler.cs#L77-L80
But when I implement an event subscriber, I'll never now that my subscriber is buggy, because my exceptions will be swallowed (empty catch all statement) and nobody will know about it:
https://github.com/IdentityModel/IdentityModel2/blob/409f2493d333d3921586a20fce88971e4d019041/src/IdentityModel/Client/RefreshTokenDelegatingHandler.cs#L259-L266

OK - good point. IIRC i wanted to shield the handler from errors in the subscriber...

@damianh OK to change?

This is run on a background non-awaited task though https://github.com/IdentityModel/IdentityModel2/blob/409f2493d333d3921586a20fce88971e4d019041/src/IdentityModel/Client/RefreshTokenDelegatingHandler.cs#L257 . Removing the try-catch here would mean the task just dies if the subscriber throws and nobody will know about it either (and any subsequent del's from the invocation list will not be called until next refresh).
Also there is a possibility of race conditions for subscribers whereby even though there is a lock to synchronize token refreshing https://github.com/IdentityModel/IdentityModel2/blob/409f2493d333d3921586a20fce88971e4d019041/src/IdentityModel/Client/RefreshTokenDelegatingHandler.cs#L242 the the lock may be released at https://github.com/IdentityModel/IdentityModel2/blob/409f2493d333d3921586a20fce88971e4d019041/src/IdentityModel/Client/RefreshTokenDelegatingHandler.cs#L275 while the background task is still 'running'. Concurrent events may be raised where a subscriber may not expect to have to handle re-entrency.
I am of the opinion event and EventHandler<T> is not the right mechansim for async fire'n'forget signalling / notifications and dealing with subscribers erroring in multi-threaded async components. As an example of alternative design for subscriptions, you can take a look at https://github.com/SQLStreamStore/SQLStreamStore/blob/master/src/SqlStreamStore/IReadonlyStreamStore.cs#L161-L168 where the caller registers two callback delegates, one for the event StreamMessageReceived and one for when the subscription goes wrong SubscriptionDropped which can be for multiple reasons. The implementation behind this uses a TaskQueue to serialize notifications from async & concurrent sources. (Also this is a richer subscription interface for functional reasons...).
So I don't think changing this will be of any benefit. Instead I would suggest a redesigned component. Actually, I have a need for such a component to handle multiple Access/Refresh Tokens with a single HTTP Client and multiple endpoints / hosts...

Working on v4 right now - there'a a v4 branch as well. Now's the time for a new design..


pydantic schema validator for wallet instance request

pyeudiw.opeid4vp

Closed by https://github.com/italia/eudi-wallet-it-python/pull/71


Ensure Laravel config preset passes for fresh laravel install

It looks like we can remove NoMethodVisibilityInTests from the Laravel presets. It's been in the default ExampleTest file and the generator for a while now.

What do we want to do in the case where the Laravel repo doesn't follow the Laravel preset?

@josecanhelp I believe the Laravel preset should be modified to pass on the latest stable version of the Laravel Repo


Typo "@ReportName"→"@ReportName"

bold with escape characters
https://docs.microsoft.com/en-us/sql/reporting-services/subscriptions/e-mail-delivery-in-reporting-services?view=sql-server-ver15

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

Thanks.


Field Manipulator - Displacement feature immediately desyncs MP lobby

The new reworked Field Manipulator's Displacement ability, when used, prompts every player in the lobby where to target the cast. This will immediately desync the game for all players.

I really like the new sub and not sure how to make displacement work under MP. Unfortunately won't fix.

Is there a way to make it so that the targeting prompt only asks the casting player for a target?

This will break the entire idea behind the class. Ideally a brand new cursor that allows one target and one location needs to be coded. Which is a bit above my knowledge.

Good news. I believe I found a workaround that won’t require that.

Hopefully fixed here. Otherwise won't be able to fix..


ci: fix the path to the build script

Lucky for me the ci/kokoro/readme and ki/kokoro/install scripts are very
similar in this project.
Part of the work for #56

This change is

Codecov Report

Merging #60 into master will increase coverage by 0.07%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #60      +/-   ##
=========================================
+ Coverage   92.52%   92.6%   +0.07%
=========================================
  Files          53      53
  Lines        1311    1311
=========================================
+ Hits         1213    1214       +1
+ Misses         98      97       -1

Impacted Files
Coverage Δ

...cloud/grpc_utils/internal/completion_queue_impl.cc
81.96% <0%> (+1.63%)
:arrow_up:

Continue to review full report at Codecov.

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


debug configuration button missing

VSCode Version: 1.9.1
OS Version: Windows 7 SP1

Steps to Reproduce:

install VSCode 1.9.1 and install plugin: Lua 5.3 Debugger
debug lua code, select Lua Debugger, but no debug configuration button and no response for running debug, how can i do ?

Is there a .vscode/launch.json file in this workspace?

No folder vscode (purple status bar) debugging does not support launch configurations.
For that please open a folder and everything will be nicely supported.

got it,thanks


Performance when pulling large data sets

I benchmarked pulling 100 000 simple documents using datastore.pull(). It took 146 seconds in the iOS simulator.
By comparison, inserting 100 000 documents (batches of 1000) takes 12 seconds. Querying them back at once by calling /_all_docs?include_docs=true takes 19 seconds. The remote database in /opt/couchdb/data weighs 16 Mb. The local SQLite database in my_datastore.touchdb similarly weighs 18.8 Mb.
The pull replication seems to be either disk or CPU bound, as it is writing to the disk at 50 MB/s and uses 75% of the CPU in TDReplicator. I have not profiled this further.
I have tried changing the following settings without success:

initialRevsCapacity: 1000
kInboxCapacity: 1000
initWithCapacity: 2000
kChangesFeedLimit: 1000u
kMaxRevsToGetInBulk: 500u
kMaxNumberOfAttsSince: 500u

I guess that these settings are only related to the network performance, which is good enough, and not the writing to disk of the many documents.
What can be tweaked on the remote CouchDB database or in my iOS app to improve the pull replication?
Or should I just switch to Core Data?

I guess that these settings are only related to the network performance

Yes, in general CouchDB's replication protocol is chatty- there is a lot of back and forth between the client and server. Initial replications are often slow because there are usually more docs to pull - later replications go from a checkpoint (clearly this depends on circumstance, if your initial pull is from a DB with 0 docs and it then gets populated with 100000 before your second pull having the checkpoint isn't going to help).
Typically speeding up replication performance is done by reducing the number of request round trips needed (e.g. increasing the bulk batch size and/or changes feed limit - which it sounds like you've tried) and/or reducing the set of documents that need to replicated (e.g. using filters to only pull the necessary documents to any single device).
There is a fair amount of CPU work involved in processing the response bodies, breaking them down into the individual docs and extracting the necessary metadata for the SQL tables and so on. The local datastore maintains a revision tree so it also has to run through checks for new winning revisions etc. The documents are written into the local SQLite datastore in batches, but there is still transactional overhead around those. I've not seen these things be slower than the network before.

By comparison, inserting 100 000 documents (batches of 1000) takes 12 seconds. Querying them back at once by calling /_all_docs takes 4 seconds.

I guess these numbers are talking directly to the remote from the device without the local datastore. This sync library's primary use-case is keeping local and remote datastores in sync. I think the questions for the sync use case are:

Do you need to make offline document modifications and replicate them back to the server?
Do you need to resolve conflicts on device?
Do you need offline "mango" style queries?
Do you later want to pull updates only for documents that have changed remotely?

If the answers to these questions are "no" then some variation of pulling documents from the remote _all_docs (or a remote view or query) and caching them on device may well perform better than using the sync solution.

Thank you very much!
I now benchmarked indexing the 100 000 simple documents. It took 30 seconds.
With large datatsets is it correct that it is more efficient to have just one big index than many smaller indexes? At least that is what the performance example in query.md seems to imply. For example the following would be more efficient:
datastore.ensureIndexed(["type" "test" "other"], withName: "everything_index")

And the following would be slower:
datastore.ensureIndexed(["type"], withName: "type_index")
datastore.ensureIndexed(["test"], withName: "test_index")
datastore.ensureIndexed(["other"], withName: "other_index")

Right?
Alternatively, is it possible to defines views in CDTDatastore and generate indexes only on these views?

With large datatsets is it correct that it is more efficient to have just one big index than many smaller indexes?

Yes, because from the perspective of building or updating the index it effectively reads each document once instead of 3 times (for your example).

Alternatively, is it possible to defines views in CDTDatastore and generate indexes only on these views?

No, we don't have either local MR views or partial indexes in our sync libraries.

Is it correct to put all the field names together? For example, will the first index above be used when querying only on test or only on other?
From my tests, the following SQLite queries are made:
INSERT INTO _t_cloudant_sync_query_metadata (index_name, index_type, field_name, last_sequence) VALUES ('everything_index', 'json', '_id', 0);
INSERT INTO _t_cloudant_sync_query_metadata (index_name, index_type, field_name, last_sequence) VALUES ('everything_index', 'json', '_rev', 0);
INSERT INTO _t_cloudant_sync_query_metadata (index_name, index_type, field_name, last_sequence) VALUES ('everything_index', 'json', 'type', 0);
INSERT INTO _t_cloudant_sync_query_metadata (index_name, index_type, field_name, last_sequence) VALUES ('everything_index', 'json', 'test', 0);
INSERT INTO _t_cloudant_sync_query_metadata (index_name, index_type, field_name, last_sequence) VALUES ('everything_index', 'json', 'other', 0);
CREATE TABLE "_t_cloudant_sync_query_index_everything_index ( "_id" NONE, "_rev" NONE, "type" NONE, "test" NONE, "other" NONE );
CREATE INDEX "_t_cloudant_sync_query_index_everything_index_index" ON "_t_cloudant_sync_query_index_everything_index" ( "_id", "_rev", "type", "test", "other" );

Therefore, is the order of the field names important?

I did a DROP INDEX on this table and it does not seem to be relevant for performance as all the queries still take < 10 ms. What seems very relevant though is that this table should contain all the field names used in queries in order to avoid the worst case scenario of having to iterate on all documents. Is that correct?

Is it correct to put all the field names together?

Sorry I should have been more explixit about this. It depends on the queries. If you need to query them independently then you may want 3 separate indexes.

For example, will the first index above be used when querying only on test or only on other?

The multi-field index would be used if you were querying:

type alone
type and test
type and test and other

If you queried test or other alone, or $or queries of the fields then the multi-field index won't help.

Therefore, is the order of the field names important?

Yes, the field order is important for index creation because it controls which queries will be able to utilize the index.
At query time the order of the fields doesn't matter, but the indexes that are available does. Basically you need to create indexes that match the queries you need to do most often.

If you need to query the fields independently then a separate index for each field will perform better at query time (at the expense of slower index builds ofc)
If you need to query using $and of all 3 fields then the multi-field index will be better
If you need to do both then you could create the 3 indexes:

type test other
test
other

The SQLite query planner itself will choose only a single index to answer a query. Our translation between Cloudant style queries and SQL allows us to break a query apart to utilize multiple indexes to answer a query (e.g. if using $or conditions with multiple fields) so for those cases indexing the fields independently works better.

What seems very relevant though is that this table should contain all the field names used in queries in order to avoid the worst case scenario of having to iterate on all documents. Is that correct?

You definitely want to avoid it falling back to reading all documents - it logs a warning if it does that. Hopefully my answers above address the ordering situation.

If you queried test or other alone, or $or queries of the fields then the multi-field index won't help.

The index on the _t_cloudant_sync_query_index table would not help but the table itself would still be used to do a linear scan in SQLite, right?
If that is correct having a monster index with all the field names would allow to query in O(log n) on type, type and test, type and test and other and in O(n) on all the other combinations... which can still be fast enough for 100 000 elements (< 10 ms).

The index on the _t_cloudant_sync_query_index table would not help but the table itself would still be used to do a linear scan in SQLite, right?

Yes, quite right, I was not clear about the distinction between the SQL index vs CDTDatastore index. As you point out, creating the CDTDatastore index does create an additional table with columns of extracted field values. If all the fields in a query are available from a CDTDatastore index then that table (and ofc the associated SQL indexes where possible) will be used.

having a monster index with all the field names

I think this should be OK for simple documents. The down-side of the monster index is that because it contains all fields it will be able to answer every query so there is no flexibility to gain performance on the "other combination" queries. It sounds like you are comfortable with the _O_(n) performance there though.


Authorizer: anonymous user error message

As of now, if a user who is not in Streamline db logs on, they get the following error message,

Improve the error message by posting a friendly message with email address of the super-user/admin for getting access.

I'll ask Houshang to provide error screens

UI changes are done, waiting on my change on server side


Vue 3 support

Are you planning to do a vue 3 version?
thank you

Also question, Why is it returning the object and not only the value from option-key? like a regular select
is it a way to do that?
is it anything like @change where i can catch the change and do something after?
thank you

I think we are facing same issue

This is my temporary solutions
First
Wrap vue-single-select with DIV
.

จังหวัด

Second
Create custom function
.
changeLocation(){
let dom = document.getElementsByName('single_selected');
if(dom.length == 1){
this.selectedLocation = this.locations.find(item => item.name === dom[0].value)
}else{
this.selectedLocation = this.locations.find(item => item.id === 1)
}
},


emotecraft doesnt work

People who connected can see my emotions, but I can’t see their emotions
Is it possible to fix this?

sorry, the reason was that I did not install the necessary mod to display emotions


Bitcoin Panel

Trying to change the "Use A Bitcoin Price Index?" or "BIP32 Extended Key" throws this error
An uncaught Exception was encountered
Type: InvalidArgumentException
Message: Unsupported magic byte

Filename: /var/www/html/shop/vendor/bitwasp/bitcoin-lib/src/BIP32.php
Line Number: 414

Backtrace:

File: /var/www/html/shop/application/libraries/MY_Form_validation.php
Line: 779
Function: import

File: /var/www/html/shop/application/controllers/Admin.php
Line: 331
Function: run

File: /var/www/html/shop/index.php
Line: 282
Function: require_once

confirmed

@jvli0 could do a test now ? I should have solved the problem in one of the previous commits!


Add support for multidimensional histograms with dask.array.histogramdd

This draft is an attempt to add the equivalent of numpy.histogramdd to Dask (which should make it easy to support numpy.histogram2d, the NumPy version of histogram2d is dependent on histogramdd). It's very clear that I'm taking a lot of inspiration from dask.array.histogram.
This initial attempt is quite narrow in supported inputs; bins required to be tuple of total number of bins and ranges to be tuple of (min, max) pairs)

Hi folks! Thanks for working on this important feature. I just thought I would share that we have a standalone package called xhistogram that implements ND histograms for dask arrays: https://github.com/xgcm/xhistogram/
Perhaps there is something in our implementation that could be useful here.
However, a key difference in xhistogram is that we support an axis argument, which allows you to take the histogram only over particularly axes. This is great if you have a big dask array and you want to see how the distribution evolves over some dimension, e.g. time.

Hi @rabernat, thanks for the pointer to xhistogram! I've been giving the implementation a read.
In the mean time, I posted a small update on where I'm a bit stuck on this PR right now, for anyone following along.

Closing and moving to https://github.com/dask/dask/pull/7387 because of broken rebase


Remove Satellite Assemblies

We are a US company that due to our business only supports English speaking users and as such we do not have any need for all the satellite assemblies installed with this Nuget package. Is there a en only version of this library or any way to configure it such that these assemblies are not included in each referenced project? Or do we need to manually do this with some scripting via deployment?

Thanks for the comment @toddca. There is no currently no alternative to getting only the locale you want other than removing it yourself.
This has already been captured in #59 and there is also a workaround mentioned there.
HTH.


Textures are always referanced as a local file

At some point we will need to test textures that are:

[ ] A web URL
[ ] Packaged in the binary

This is better tracked by the Future Tests issue


'RNSkiaModule.h' file not found with  include; use "quotes" instead

simple patch for ios native module

Same problem with version 2.1.0. This is strange because user @relaxxxpls encounters the same problem here but seems to get it work by installing the latest version...

Can anyone of you please provide a reproduction repository for that issue? Much appreciated, thanks! 😊

Here you are.

I'm having this too in latest version. Downgraded to 2.0.4, also still have it. With Skia 0.1.230 and 0.1.237.

@hannojg any luck with the repo I provided?

Hey, just checked your reproduction. The issue seems to arise due to the usage of use_frameworks.
Will check if we can get that fixed 😊

use_frameworks is now mandatory if we want to use Firebase, so I need that. Thanks @hannojg

I also use Firebase, so use_framework is needed unfortunately.

@hannojg  is there any fix for use_frameworks?

I'm having the same issue and also use Firebase

@hannojg I've tried to fix it, but it looks like a linking problem because Firebase requires linkage static. Do you think we can use angled symbols for both situations?

Is using angle brackets fixing the issue for you? When I tested it fixed this particular build error but then caused a bunch of others.
Is using react-native-skia with Firebase / use_frameworks possible?

https://github.com/Shopify/react-native-skia/issues/652#issuecomment-1280278930
Can anyone try this?

@hannojg Yes the workaround that @idrakimuhamad mentionned is the one that allows to install skia without errors. The podfile I gave you already includes this workaround

Yeah i think we don't actually need the workaround as it's already being part of the pod-spec now(?)
https://github.com/Shopify/react-native-skia/pull/1400

@idrakimuhamad I've tried without it and it doesn't work but maybe I did something wrong. Please make a new project and install react native skia and if it works then provide a repository for us thanks

I'm also running into this same issue:
Running expo:
"@shopify/react-native-skia": "0.1.241",
"expo": "50.0.8",
"react-native-skottie": "^2.1.0",
...

I'll have to fall back to react-native-lottie until I can upgrade to skottie when this is resolved. If anyone is working on it, LMK if you need anymore info. I don't have bandwidth to attempt to find the issue at the moment but can't help test or give feedback.

xdddd

i mean... this error is here for a good moment now, did they abandon the project or what xdd

@hannojg 🥺

Also seeing this. Would be great with a fix asap!

Can someone help with any workaround for this issue for now?
Thanks

Is there any progress on this issue?

Thank you very much @hannojg

Should be fixed in version https://github.com/margelo/react-native-skottie/releases/tag/v2.1.1
Thank you
I've tried but unfortunately still the same for me, maybe that's just me...
@idrakimuhamad have you tried?
I'll try to provide a repo for @hannojg

Thanks. I'm able to build the app as of v2.1.1, though I'm getting some other crashes related to my lottie file. I will open another ticket.

Thank you very much @hannojg (building ok with<EMAIL_ADDRESS>+<EMAIL_ADDRESS>and<EMAIL_ADDRESS>- I mentionned this because updating skia was very important also)


Container image build validation successfull but build failed

Summary
The pipeline run, triggered on PRs, for the workflow container-image-build-validation ends successfully if one of the jobs-chain ends successful.

Expected behaviour
The run fails if any of the jobs runs fails.
Example
https://github.com/cybcon/modbus-server/pull/31
https://github.com/cybcon/modbus-server/actions/runs/7789913852?pr=31

Another discussion on GitHub facing a similar issue: https://github.com/orgs/community/discussions/57724
The solution here is to set the parameter permissions: write-all inside the job definition.
This will be inside the .github/workflows/container-image-build-validation.yaml pipeline definition in job function-test-preparation:


struct tags "autoincrement"

PostgreSQL
Don't use serial

For new applications, identity columns should be used instead.

We probably should add a separate tag ,identity and use for PostgreSQL and MSSQL.

I would like to implement this, but I have some concerns.
Brief reminder on the current implementation:

Both MSSQL and PG dialects support the autoincrement tag.
PG does this simply by mapping the data type to SMALLSERIAL, SERIAL, BIGSERIAL respectively.
MSSQL does this by implementing the Identity feature, which adds the IDENTITY keyword on column creation.

So I see 3 solutions:

Comply with the current implementation. This means adding the Identity feature to the PG dialect. The problem is that this would case a breaking change, because I don't see a way to both support the data type mapping and the usage of the IDENTITY keyword. So I guess we would have to choose to only support the later.
Add an independent identity tag. This means that for the PG dialect the autoincrement tag works the same, we implement the use of the IDENTITY keywork only with the identity tag present. Also I guess both tags would need to be mutually exclusive. For the MSSQL the identity tag would have to work the same as the autoincrement tag or it would be ignored completely, which would be a bit confusing imho.
Add the identity tag as an additional tag for the autoincement tag. This means for the PG dialect with only the autoincrement tag present it would work the same. If there are both tags (autoincrement and identity) present, then we use the IDENTITY keyword. For the MSSQL both cases would work the same or the identity tag would be ignored completely, which would also be a bit confusing imho.

Another concern is that PG and MSSQL have different syntax for the IDENTITY keyword.

PG requires the following statement column_name type GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
While MSSQL only requires just a single IDENTITY keyword

As I see it, this could be implemented by implementing an additional interface (something like an IdentityAppender) by the dialects.
@vmihailenco would love to here your thoughts on this.

@oGi4i I think we need a separate feature-flag for PostgreSQL called feature.GeneratedBy or something. You can check for that flag here and append GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY as required.
Models can use the same ,autoincrement,identity tag to enable this behavior on PostgreSQL / MSSQL.

@oGi4i I think we need a separate feature-flag for PostgreSQL called feature.GeneratedBy or something. You can check for that flag here and append GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY as required.

OK, so we add a new feature-flag for PostgreSQL.
But the place that you suggest we should append the IDENTITY statement will be in conflict with the data type mapping done here. We will get a statement like BIGSERIAL GENERATED BY DEFAULT AS IDENTITY which is invalid because you can't mix SERIAL and IDENTITY.

Models can use the same ,autoincrement,identity tag to enable this behavior on PostgreSQL / MSSQL.

Currently ,autoincrement is enough to use IDENTITY for MSSQL. But you would need ,autoincrement,identity to use it for PostgreSQL?

statement will be in conflict with the data type mapping done here

We will need to disable that behavior as well when identity is enabled.

Currently ,autoincrement is enough to use IDENTITY for MSSQL. But you would need ,autoincrement,identity to use it for PostgreSQL?

I am open for suggestions, but let's not break current behavior. Perhaps just ,identity should be enough for PostgreSQL?

I am open for suggestions, but let's not break current behavior. Perhaps just ,identity should be enough for PostgreSQL?
In PostgreSQL, when using NewInsert(), if only ,identity is used and it is missing from the model, it tries to save the field as 0. If ,autoincrement,identity is used, then it tries to save the field as DEFAULT, which works. So, ,identity alone is not working.

	github.com/uptrace/bun/dialect/pgdialect v1.1.8 // indirect
	github.com/uptrace/bun/driver/pgdriver v1.1.8 // indirect
	github.com/uptrace/bun/extra/bundebug v1.1.8 // indirect
	```


Support automatic apply on merge queue

Today TACOs require changes to be applied manually.
This was a deliberate choice as silently apply potentially large changes upon merge was considered too scary (@bukzor / @ellisonmarks , this is my understanding of the rationale, please correct me if I am wrong).
While this approach may be desirable for some large changes, it is counterproductive in several scenario like the Kafka Control Plane where the terraform changes are automatically generated and forgetting to apply has worse consequences.
Examples:

the system will be used from people across different teams who are used to changes being applied after merging the PR and are not used to deal with the drift problem.

We should enable merge queues and support automatic apply of TACOs changes while allowing for manually apply of critical changes.
Ideas on how to select slices or changes that would be applied automatically:

the apply label should still work to enable the PR based workflow as per TACOs requirements. In this case the operation on the merge queue will be a noop.
Default auto-apply. By default a tacos plan is applied on the merge queue.
Label to flag a PR for manual apply only. In this scenario we expect people to apply manually the PR will not be applied on the merge queue, for the PR to merge the change must have been applied manually. If not the queue action fails. (I am not even sure we would want this feature).

Am -1 to the idea of requiring a PR label to opt out of auto apply from master, too easy to forget to apply, or there is a case where something changed after the plan was posted on the PR but before merge.
Terraform will happily destroy things that could have severe consequences for our production infrastructure.
Eg. Someone sees a disk space ticket and scales up the snuba errors cluster. I merge my PR adding a COGS label to the errors cluster (should be safe to auto apply right)? Terraform deletes all 30 data disks in about 15s because the only way to shrink a GCP disk is to destroy it and then recreate it.
Similar story for adding a label to a boot disk, the GCP provider has currently decided that requires recreating the disk to update.
If possible I would recommend that TACOS should support different flows depending on the slice being applied, then Kafka control plane, Datadog monitors, ops workflows, root account workflows, etc can all be handled in the way that fits them best.
Or switch to spacelift which supports this kind of configuration out of the box.


Unable to update VS Code

Please include more details about exactly what you are trying to do and what is happening.


Fix missing unlink icon

Fixes missing unlink icon (in my case it was for link popup)
Before & after: https://imgur.com/a/OJtapxF

Great!

I bumped it to 0.1.1, thanks.


Add ConnAck message builder method to handle the creation of related properties

Motivation:
The CONNACK message builder ConnAckBuilder doesn't provide a smooth way to assign the message properties. This PR try to provide an simpler way to create them, in a lazy way.
Modification:
This PR permit to store properties in the ConnAck message, collecting them and inserting during the build phase. The syntax this PR introduces is:
 MqttMessageBuilders.connAck().properties(new MqttMessageBuilders.PropertiesInitializer<MqttMessageBuilders.ConnAckPropertiesBuilder>() {
        @Override
        public void accept(MqttMessageBuilders.ConnAckPropertiesBuilder builder) {
            builder.assignedClientId("client1234");
            builder.userProperty("custom_property", "value");
         }
 }).build()

The name of the properties are defined in the ConnAckPropertiesBuilder so that is can be easily used by autocompletion tools.
This PR adds the builder class ConnAckPropertiesBuilderwhich is used by newly introduced method properties inside the message builder class ConnAckBuilder.

@netty-bot test this please

Hi @normanmaurer is this PR good to be merged, there is anything I should do to make it progress?

@netty-bot test this please

@andsel thanks a lot


Boolean v-model doesn't default to undefined when not set

Vue version
3.3.13
Link to minimal reproduction
https://play.vuejs.org/#eNp9UstugzAQ/BXLF1opj0NuEYnUVDm0Uh9qevSFwIaSGtuyF5oK8e9dm0BTNeLE7O4wO7PQ8DtjZnUFfMljl9rCIJOJyleCoxOcOcDKrIVKtXLI3JPOQLIVy+BQKAhV7NAWKl/fRB2Ibnv2/hp7r7WERBH9jDw/nneraREVCKWRCQJVjMVZUQdA0BvxgLFdWMXqaRlWKE3eAJesaRh+G9CH3mrbsimLqD3U0Vls7tX+CW86U2PK51iD8lD/UfbPzno8vwjEJ3RXOs+hyGdHpxWdvfFkwVNdmkKCfTFY0PkEp52doOCJlPrrMfTQVjDp++kHpJ9X+kd38j3BXy04sDUIPswwsTlgN97unuFEeBhS6EoSe2T4Bk7LynvsaJtKZWT7ghfcPpRGW6SP9O62JwTl+lDeqGe2gS84/Xv3I9F/7S5mi/CeUC1vfwBRQuR4
Steps to reproduce

Define a model with boolean type in a component
Do not specify the v-model when using the component in the template of a parent component

What is expected?
Since all other types have undefined value when they're not set, I would expect a boolean v-model to behave the same.
I assume the root cause of this  problem is that normal boolean props are converted to false when not set.
I can see why this behavior might be desired for props in certain situations. However, it creates issues in detecting whether a v-model has been set. Therefore, I think it would be better to have consistency in prop behavior.
What is actually happening?
A v-model of boolean type has a value of false when not set, instead of undefined.
System Info
No response
Any additional comments?
No response

This is documented behavior so 1) it's not a bug and 2) will not be changed in Vue 3.

The Boolean absent props will be cast to false. You can change this by setting a default for it — i.e.: default: undefined to behave as a non-Boolean prop.

I know it's documented but I think the use-case for boolean props is different than boolean v-model. Wouldn't you at least consider adding the default value of undefined to the defineModel() macro so that it is consistent with other types of v-model?

You can define a default in defineModel() just like you can for the normal Boolean prop. I don't think it's desirable to switch the behavior for defineModel<boolean>() only, that will only cause more confusion.


Notifications: logic behind non-latest version

It seems there is some hidden logic in the old implementation of this feature. This comment called my attention regarding branches vs. tags: https://github.com/fabric/fabric/issues/2255#issuecomment-1553256375. There is a link to https://github.com/readthedocs/readthedocs.org/issues/3268 which explains a little bit of the history here.
We should clearly define what's the logic behind our semver comparisons.

At this point, I think we should implement "the most basic and strict version of semver" first and then allow people to write their javascript function to replace this basic logic. We will never cover all the cases and, in fact, I found that a lot of cases are edge cases:

calver
tags have priority over branches
versions with prefixes like release/2.0 or v3.1, etc

I think this will give users something that works in a reliable way for specific use case, but also the flexibility to customize it as they want if they have a particular use case.

The logic I have in mind would be similar to:
The simple case, is the ✅  valid version: (semver.valid). They look like 1.2.1 and v3.1.6 and =4.1.1. However, the ❗ invalid version is more complex and we need to loose it a little here:

it has to have / on its name:

release/2.1
rel/2.1
development/release/4.1.1

it has to have at least a "minor" part on the name (release-1 is not valid)
the "major" part of the version has to be isolated (between / or - or .)

release-candidate-2.1 ➡ 2.1.0
project-name-1.6/release ➡ 1.6.0
test-404-page ➡ invalid (otherwise it gives us 404.0.0 when calling semver.coerce)

While writing this down, I found it's not super accurate nor easy to explain, but I think this implementation could cover most of the use cases. We can tweak it a little as we go.
However, people with strict/different needs (like calver), they should write their own logic for this.

@stsewd @agjohnson @ericholscher do you have a better and simpler idea for this?

Hrm, honestly I'm not sure. Comparing versions that are already semver makes sense, but coercion looks like the wrong tool to rely on here. For every case we get right using coercion, I'm sure there will be plenty others that we get wrong.
I'd say if it isn't obviously a semver version, we can't support it with this warning. At least not right now. I still think there is more was could do to give the user the ability to tell us what is latest, instead of us using some amount of magic to guess. We've talked about surfacing this sort of behavior in automation rules, perhaps related to latest/stable rules, which I still think is a really good idea.

What about a pretty simple logic to start with?

if there are the latest and stable versions active, we show "you are reading the development version, the stable version is at ..." when reading latest
if there are stable and more active versions, when navigating other versions we show "you are not reading the stable version, read it..." if the version people is reading is not the stable one

I think this simple approach can work to start with. In the end, the most accurate approach would be a customized one by the user.
Also, the implementation looks pretty simple.
However, I think we can start by using simple logic we know and control like stable and latest versions.

I still think there is more was could do to give the user the ability to tell us what is latest

I like this idea if we can allow them to tell this us in an automated way. Otherwise, I think it will become "another tool to update each time a new release is done" and make the process a little more tedious. Making this automated somehow is one of the Read the Docs features that I don't want to loose.

issues stemming from the application being not super transparent with how we determine latest/stable

(from https://github.com/readthedocs/readthedocs.org/issues/5319#issuecomment-1701468885)
This makes me think again about the logic behind this addon. Maybe making our logic latest/stable dependent is not a good idea if users have problem understanding how we determine those. This is a good point to avoid this pattern maybe.

These are all good points.
Does offering a configuration option help at all here?
I don't quite have a strong opinion here yet, but so far I feel:

An explicit option is best, but agreed we're not there yet
Semver (without coercion) probably works for most/many cases
We could fall back to using latest/stable when semver doesn't work
If the user can configuration this or at least disable the notifications easily, this seems like maybe enough until we do get an explicit option on Version objects

Does offering a configuration option help at all here?

Yes and no. Ideally, the user should be the one that specify "what's the logic behind this". Originally, I thought this feature in a way the user can "overwrite the javascript function" to tell us what's the highest version to decide whether or not show the notification. However, we are not there yet.
I thought a little about this considering "a simple configuration option" but I didn't come up with a great answer that's easy to understand for users. That's why I asked to the user from https://github.com/readthedocs/readthedocs.org/issues/5319#issuecomment-1706297154 for ideas.

Semver (without coercion) probably works for most/many cases

Yes and no. The library we are using doesn't consider 3.1 as valid since it requires the patch version to be present:
$ semver --valid "3.1"
$ echo $?
1

$ semver --valid "3.1.0"
3.1.0

So, we would need to add extra-logic here for these cases and I'm not sure I want to jump into that path 😅

We could fall back to using latest/stable when semver doesn't work

After reading your comment in the other issue, I'm not 100% convinced that I want to use stable/latest if the users are already confused about those terms. However, those are pretty specific to Read the Docs and the whole platform is built on top of them. So, probably worth following those concepts and fix the root confusion issue by clearly document what they mean and how they are defined. Related issues:

https://github.com/readthedocs/readthedocs.org/issues/10674
https://github.com/readthedocs/readthedocs.org/issues/9572
https://github.com/readthedocs/readthedocs.org/issues/6415
https://github.com/readthedocs/readthedocs.org/issues/8789
https://github.com/readthedocs/readthedocs.org/issues/8476
https://github.com/readthedocs/readthedocs.org/issues/7219
https://github.com/readthedocs/readthedocs.org/issues/6096

Yes and no. The library we are using doesn't consider 3.1 as valid since it requires the patch version to be present

Oooh, yeah that is very annoying then.

Originally, I thought this feature in a way the user can "overwrite the javascript function" to tell us what's the highest version to decide whether or not show the notification. However, we are not there yet.

Agreed. This seems like quite advanced usage too, and requires the author customize both JS and HTML to override the version comparison logic. A simple approach would be great here, but it does feel really hard to make something generally useful here.

Overall, I feel like automatic (or at least manual to start) flagging of Version objects as outdated feels like the best UX. I don't yet see a good path between what we have now and that UX though. That is, if we implemented a Version.is_outdated tomorrow, I wouldn't build any of the other features for version comparison into the addons library.

Also, I think this idea of following core Read the Docs feature's like stable and latest versions is important here. @agjohnson, following your example, I image we could create an automation rule to define stable based on a custom logic the user can define using the WebUI. Example, following CalVer.
If we ever implement something like that, this logic behind the addons will keep working fine since it's just based on well-known definitions like stable and latest versions 👍🏼

I really like the idea of making these automation rules. The UX would be better even if these were fairly hardcoded automation rules to start.
If we consider the latest and stable additions separate, do you think we also want something like Version.is_outdated? I could see exposing an addons configuration option "Show a warning for all versions except stable". But I could also see users wanting more configuration options or granular control over which versions the warning is displayed on too.

If we consider the latest and stable additions separate, do you think we also want something like Version.is_outdated?

I thought about this and I'm not sure. I'm not clearly visualizing the exact workflow for this yet. We should probably talk more about this and define the workflow together.

I could see exposing an addons configuration option "Show a warning for all versions except stable".

This is basically the logic that I just implemented. Besides, my implementation shows a warning on latest as well to warn them about features that may not be released yet.

But I could also see users wanting more configuration options or granular control over which versions the warning is displayed on too.

This use case is the one I would like to not implement (right now, at least) and point users to more advanced configuration using JavaScript on their own. I'm saying this because Version.is_outdated may not be enough for those cases, so I prefer if they can define their own logic as they want.

This use case is the one I would like to not implement (right now, at least) and point users to more advanced configuration using JavaScript on their own

Yeah, this is definitely a later feature either way. I'm not super convinced yet on making users do this JS logic on their own, that definitely makes it harder for us to build this into a feature later. That's to say maybe we don't mention anything about customization just yet.
But otherwise I agree and we should continue talking here about next steps. I think starting with basic logic for now is the best place to start, and is an improvement over relying on logic outside our native versioning.

Would be nice if this was a bit smarter. For example https://docs.kedro.org/en/0.19.0/ is (at the time of writing) exactly the same as https://docs.kedro.org/en/stable/, but the former shows the "This may be an old version" banner.

Should I open a new issue?


Feature/customize registry

There reasons is to have flex way to add or remove wallets, blockchains and upstreams with no code changes.
It must not break current deploy and installation process and be compatible with opendax

Hello @dapi. Thank you for this suggestion but we are not going to create more .yml files for our configs.

Hello @dapi. Thank you for this suggestion but we are not going to create more .yml files for our configs.

Hi @mnaichuk!
Do you have any other solutions how to manager registry with no code changes?


In the Manual we say at the beginning of Vol. 2 that for WIS we mean WIS 2.0. We should do the same in (the introduction section of?) the Guide.

@efucile / @hhaddouch - for action.

Simple but important issue.  Further questions:

should/do we name everything "WIS" and jettison "WIS 2.0", "WIS2", "WIS 2", etc.?
if yes, do we put "WIS means WIS 2.0" in the introduction

What we decide here should also cascade into the Manual, Transition Guide,  WCMP2, WNM, and WTH.

Superseded by #76


Utxo package refactoring

It seems that for the short files, like <10-15 lines, idea and git don't want to treat it like renaming and always say it's delete-create changes

Applied the remaining fixes


change from sysregistries to sysregistriesv2

We want to start supporting the registries.conf format.
Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>

@vrothberg PTAL
But I have one issue.
		registryPath := sysregistries.RegistriesConfPath(&types.SystemContext{SystemRegistriesConfPath: systemRegistriesConfPath})

There does not seem to be a replacement for this?

There does not seem to be a replacement for this?

I think it's sufficient to tell that "no search registries are defined in the registries config". We can export the variable sysregistriesv2 in the future but how the code in pull.go is a bit exotic as the variable will not change after line 249.

@vrothberg Ok removed the RegistryConfPath.
Also added in blocked registries to podman info command.

@mheon @baude @giuseppe @TomSweeneyRedHat @vrothberg PTAL

Test failures are network flakes

LGTM pending green tests

/lgtm


Undefined reference to '_gfortran_concat_string'

Hi developers,
I am trying to link my binary statically (i.e. with the -static flag in gcc) to OpenBLAS, but I get the following error (among others):
/home/john/local/OpenBLAS/install/lib/libopenblas.a(sgesvd.o): In function sgesvd_': sgesvd.f:(.text+0x35f): undefined reference to_gfortran_concat_string'
I'm compiling with the following linking flags:
"-static-libgfortran -static-libgcc -static-libstdc++ -lpthread -Wl,--whole-archive -libverbs -Wl,--no-whole-archive -ldl"
I've tried everything I can think of, and hav been stuck on this issue for days. If I simply remove -static-libgfortran and replace it with -lgfortran, everything works fine. So, it seems like the dynamic version of libgfortran is linked to some other libraries.
I have verified that I have the static version of the libraries listed in the above linking command, so that shouldn't be the issue. Also, this only seems to effect the LAPACK routines, not BLAS.
Do you have any idea what might be going on or suggestions for me to try?
I'm compiling with gcc 4.8.1 un Ubuntu 14.04, if that helps.
Thank you for your time!

maybe gcc/gfortrian version not match openblas needed? gcc-8 is work for may case.


[Question]V5.1.4 Publisher pipeline does not deploy APIM changes

Release version
v5.1.4
Question Details
The publisher pipeline run successfully, but when i check the APIM instance, the changes is not actually deployed.
Expected behavior
API artifacts extracted from the "lower" environment (aka Dev) should be deployed to the "higher" environment (aka Prod). After running the publisher pipeline, both Dev and Prod APIM instance should be the same.
Actual behavior
Changes not deployed to Prod APIM instance despite the publisher pipeline run successfully.
Reproduction Steps
Run extractor pipeline to extract APIM settings from "Dev" environment.
Merge pull request into main/master branch.
Run publisher pipeline to publish to "Prod" APIM instance. (publisher pipeline run successfully, but changes not deployed)

Please post the logs here (make sure you scrub). Sounds like the git is not picking any changes.

@waelkdouh , i managed to resolve the issue from the hint you mentioned. i have a couple of other commits not related to APIM so git it is not picking up any changes from the latest commit. instead i need to choose to publish all the artifacts in the repo.
Thanks.

Keep in mind it's usually better to allow the publish to pick the commit, which has the changes only on otherwise you are publishing everything which is more resource intensive process not to mention that it takes longer. Of course, there are situations where you republish everything if you see fit.


Create shipleyschool.txt

School Website: https://www.shipleyschool.org/
Curriculum Overview: https://shipleyschool.myschoolapp.com/ftpimages/724/download/download_8509969.pdf

@Anti-Apple4life First stage of verification passed, official domain is shipleyschool.org as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@Anti-Apple4life Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Remove deprecated wrangler version command

https://github.com/cloudflare/workers-sdk/pull/5069 marked the wrangler version command as deprecated since wrangler --version is the recommended approach and having this command may cause confusions with the upcoming wrangler versions ... commands

Can it add an option to print only the version? It has too much unnecessary format around, making it difficult to use it with some scripts.

Closed by #7352


[Security Issue] Remove API Keys

The API Keys are visible in the code. Its not advised to store it openly.
Shall I send a PR after removing the API Keys ?

The API Keys are visible in the code. Its not advised to store it openly .
Damn , totally forgot .
@leovarmak sure go ahead!

I am unable to send a pull request. It says I don't have enough permissions 🤔

you need to :

fork
make changes to your fork
send in a PR here

Haha. I know how to send a PR 😅 . There was a issue with my account
Sent now!

#10


Cannot parse MathML

Hello,
First of all, congratulations for Math.Net. It's a wonderful project. You've done a great job.
I'm trying to use Symbolics in a project where I need to parse a standard syntax in order to import expressions.
I didn't find anything about LATEX parsing, but I found a method for parsing MathML: SymbolicExpression.ParseMathML. I tried to use it with some wellformed MathML code, but it always return undefined. What is the matter? Is something wrong in what I do?
Here is an example of MathML code I used
<math display="block">                 <mrow>                   <munderover>                     <mo>∑<!-- ∑ --></mo>                     <mrow>                       <mi>n</mi>                       <mo>=</mo>                       <mn>1</mn>                     </mrow>                     <mi mathvariant="normal">∞<!-- ∞ --></mi>                   </munderover>                 </mrow>                 <mrow>                   <mfrac>                     <mn>1</mn>                     <msup>                       <mi>n</mi>                       <mn>2</mn>                     </msup>                   </mfrac>                 </mrow>                 <mo>=</mo>                 <mrow>                   <mfrac>                     <msup>                       <mi>π<!-- π --></mi>                       <mn>2</mn>                     </msup>                     <mn>6</mn>                   </mfrac>                 </mrow>               </math>
Thanks in advance for any help.

For now abilities of Math.Net Symbolics pretty limited. May I ask what are you trying to do?
I'm not familiar with MathML language, so may you add some examples of input, which you want to parse, in naive or latex format?

I have a client side tool that can handle either latex or mathml syntax to represent math functions. Therefore I need  to handle such functions in the backend: recognize them, recognize variables and finally evaluate them.
Latex syntax would be better but mathml would be ok.

Any kind of functions should be available to the user that can write them and then save them as template.

Indeed, the problem in this particular case is that we don't even support series yet, nor the concept of locally-scoped symbols (the n in this case, which could be unrelated to an n outside of the series).

Technically we could easily support them in the new visual expressions only, but supporting them in the (semantic) expressions will need some thoughts on design.

Ok thank you for the answer. May I ask you the list of allowed mathml tags I can use in order to be parsed?


Added support for ImageMagick in php images

This PR just adds support for ImageMagick in PHP images
Checklist

[x] Affected Issues have been mentioned in the Closing issues section
[x] Documentation has been written/updated
[x] PR title is ready for changelog and subsystem label(s) applied

Some customers wanted to use ImageMagick PHP libraries instead of GD for image's management.
Changelog Entry
Improvements: added ImageMagick support for PHP
Closing issues
closes #361

@vincenzodnp can you work on the requested changes?


Add -v and --version flags to ch to print ChakraCore version.

Partially addresses #109 and #2472
ch /v
ch /version
ch -v
ch --v
ch -version
ch --version

The above all display the version in a simple <major>.<minor>.<patch> format, e.g.:
1.4.1

This flag is available in all flavors (including Release).

@bterlson @liminzhu We could probably merge this before the 1.4.1 release, so at a minimum 1.4.1 and 2.0.0 binaries can be distinguished at this point.
/cc @mathiasbynens @obastemur @ThomsonTan @ianwjhalliday
What do you think?

What is an xplat alternative for wcsnlen?

Linux has wcslen. The build problem is probably about const conversion.

In reply to: 278212465 [](ancestors = 278212465)

We could probably merge this before the 1.4.1 release, so at a minimum 1.4.1 and 2.0.0 binaries can be distinguished at this point.

🎉

should we include this into -? list?

This sounds pretty useful. Is there a way for any embedder (not just ch) to programmatically know ChakraCore version #?

This sounds pretty useful. Is there a way for any embedder (not just ch) to programmatically know ChakraCore version #?

We intend to ship "ChakraCoreVersion.h" file, and embedder knows it by including that header.

Yes, additionally, the file info of the compiled binaries already contains information about the version (that's how these macros were being consumed before):
Here's the info for some binaries I built locally:
ch.exe:
        Verified:       Unsigned
        Link date:      6:27 PM 2/7/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core Host (Private)
        Product:        Microsoft « Chakra Core Host
        Prod version:   <IP_ADDRESS>
        File version:   <IP_ADDRESS>
        MachineType:    64-bit

ChakraCore.dll:
        Verified:       Unsigned
        Link date:      5:57 PM 2/7/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core (Private)
        Product:        Microsoft « Chakra Core
        Prod version:   <IP_ADDRESS>
        File version:   <IP_ADDRESS>
        MachineType:    64-bit

And from the preview package I recently published to myget:
microsoft.chakracore.vc<IP_ADDRESS>-preview-00010-42060\lib\native\v140\x64\debug\ch.exe:
        Verified:       Signed
        Signing date:   7:17 PM 1/30/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core Host
        Product:        Microsoft « Chakra Core Host
        Prod version:   <IP_ADDRESS>
        File version:   <IP_ADDRESS> (users/doilij/nufeed:3e2e2f353d71d8e3e8522fa04b9789cf1b5c35ac.00010.42060.170130-1858)
        MachineType:    64-bit

microsoft.chakracore.vc<IP_ADDRESS>-preview-00010-42060\lib\native\v140\x64\debug\ChakraCore.dll:
        Verified:       Signed
        Signing date:   7:15 PM 1/30/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core
        Product:        Microsoft « Chakra Core
        Prod version:   <IP_ADDRESS>
        File version:   <IP_ADDRESS> (users/doilij/nufeed:3e2e2f353d71d8e3e8522fa04b9789cf1b5c35ac.00010.42060.170130-1858)
        MachineType:    64-bit

It looks like the problem is that the signature of main for xplat specifies:
#ifndef _WIN32
static char16** argv = nullptr;
int main(int argc, char** c_argv)

Instead of the Windows version which uses:
int _cdecl wmain(int argc, __in_ecount(argc) LPWSTR argv[])

Note LPWSTR is typedef'd to wchar_t.
Additionally, I confused things initially by using wchar instead of wchar_t -- apparently not a problem on Windows but it is for xplat.

Apparently we have PAL_wcslen but not PAL_wcsnlen

I'm going to look into using HostConfigFlags instead to avoid introducing the PAL dependency in ch. If that works, I'll update the PR away from the current approach.

Additionally, I confused things initially by using wchar instead of wchar_t -- apparently not a problem on Windows but it is for xplat.

We shouldn't use wchar_t I had cleaned up that one. Its size can be 4 bytes on one platform and 2 on another..

LGTM. Thanks @dilijev for taking care of this!

@jianchun re: shipping ChakraCoreVersion.h -- the NuGet packages do not include this file since it's so minor. Would it be worth including it? For, say, .NET projects which might want to report the ChakraCore version without hardcoding is there any kind of solution that would work that doesn't involve exposing a new API that reports the version info? Should we consider implementing such an API for the benefit of hosting? Is there some other approach that could work?
/cc @liminzhu

I'm going to look into using HostConfigFlags instead to avoid introducing the PAL dependency in ch. If that works, I'll update the PR away from the current approach.

From my investigation so far, this seems like a bit of a rabbit hole. There seems to be good reason (at least, it was thought about before) not to initialize the HostConfigFlags in release builds. Working around it to enable these specific parameters seems silly and difficult, so if we went this way, it would involve enabling all HostConfigFlags.
I agree that taking a dependency on PAL for this may be a bit extreme. One workaround is to copy a definition of PAL_wcslen to support taking length of char16 strings to avoid the dependency problem, but I'd like to avoid doing something like that if it's not totally necessary. Any suggestions?
Think it's safe to merge this as-is and follow-up later if the dependency becomes a problem?

Updating the help message. Also enables -h and -help for non-release builds, and -?, -h, and -help for release builds, as per request in https://github.com/Microsoft/ChakraCore/issues/2472

@tcare Believes that this is potentially misleading as the version being reported is really just the version of ch, not the version of ChakraCore that ch loads. At a minimum, we should report at this time:
ch version 1.4.1

We could read the ChakraCore.dll binary information (see above), but the ChakraCore binaries produced in xplat builds don't seem to contain this info at this time, so we would be unable to do the same for xplat right now. It may be reasonable to make this a separate work item for later.
Assuming that in the common case ch will only be used with the ChakraCore library that was built at the same time, the version of ch can be used as a proxy for the version of ChakraCore it will load, and this could mostly resolve the common scenarios that @bterlson @mathiasbynens and others are interested in.
Will discuss with others on the team for opinions about how to proceed before merging this.

https://stackoverflow.com/questions/940707/how-do-i-programatically-get-the-version-of-a-dll-or-exe-file/940743#940743 shows how to do this.
Used this to prototype a solution. Output of ch -v etc. is now:
ch.exe version <IP_ADDRESS>
chakracore.dll version <IP_ADDRESS>

Or, because it reads the DLL info, when the DLL built from a different version, that is reflected in the output as well:
ch.exe version <IP_ADDRESS>
chakracore.dll version <IP_ADDRESS>

/cc @tcare

Windows x86_release error:
warning C6388: 'verHandle' might not be '0':  this does not adhere to the specification for the function 'GetFileVersionInfoA'.

DWORD
APIENTRY
GetFileVersionInfoSizeA(
        _In_        LPCSTR lptstrFilename, /* Filename of version stamped file */
        _Out_opt_ LPDWORD lpdwHandle       /* Information for use by GetFileVersionInfo */
        );

BOOL
APIENTRY
GetFileVersionInfoA(
        _In_                LPCSTR lptstrFilename, /* Filename of version stamped file */
        _Reserved_          DWORD dwHandle,          /* Information from GetFileVersionSize */
        _In_                DWORD dwLen,             /* Length of buffer for info */
        _Out_writes_bytes_(dwLen) LPVOID lpData            /* Buffer to place the data structure */
        );

What? Seems like a warning that should be suppressed because clearly the value of &verHandle output from GetFileVersionInfoSizeA is supposed to be passed into GetFileVersionInfoA...

dwHandle is reserved and is ignored. Just pass in nullptr. https://msdn.microsoft.com/en-us/library/windows/desktop/ms647003(v=vs.85).aspx

@tcare Thanks for confirming, I was thinking that might be the right thing to do but I couldn't find info about it.

LGTM, please run by @curtisman.


fix(syncing): add link to support site when resyncing

Description:
Add a link to the support site when a wallet is resyncing, as per mockups.
Motivation and Context:
Fill in the big gap in the page design.
How Has This Been Tested?

In the storybook - use knobs to change app state
Open up a local wallet that has synced all the way at last once.

Screenshots (if appropriate):

Types of changes:
Enhancement
Checklist:

[x] My code follows the code style of this project.
[x] I have reviewed and updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes where needed.
[ ] All new and existing tests passed.
[x] My commits have been squashed into a concise set of changes.

tested ACK 86252ba


string objects seem not be supported in host_vector/device_vector

I wrote this piece of code for testing,but it crashed when push_back the 2nd string to a host_vector.
int main()
{
    ifstream input_subset("subset.txt");
    thrust::host_vector < string > h_output_subset;

    string s;
    while (getline(input_subset, s)) {
        h_output_subset.push_back(s); //crashed when put the second string into it.
    }
    cout << h_output_subset.size() << endl;
    return 0;
}

The input data's format is below:

TGCCACAGGTTCCACACAACGGGACTTGGTTGAAATATTGAGATCCTTGGGGGTCTGTTAATCGG
GTTCACGGGCCTCACGCAACGGGGCCTGGCCTAGATATTGAGGCACCCAACAGCTCTTGGCCTG
TGCCACAGGTTCCACACAACGGGACTTGGTTGAAATATTGAGATCCTTGGGGGTCTGTTAATCGA

Is that a bug? If not, how to store strings as elements in a host_vector/device_vector?

Thanks for the report. It looks like a bug. Here's a smaller reproducer:
#include <thrust/host_vector.h>
#include <istream>
#include <iostream>

int main()
{
  thrust::host_vector<std::string> h_output_subset;

  std::string s = "s";
  h_output_subset.push_back(s);
  h_output_subset.push_back(s);

  return 0;
}

The problem is that the copy_construct_range dispatch process is not being conservative enough when dispatching T's (in this case std::string) copy constructor. The less conservative path dispatches a simple copy intended for types with trivial copy constructors, but we need to dispatch the uninitialized_copy path which correctly uses T's copy constructor because std::string has a non-trivial copy.
Changing the implementation of needs_copy_construct_via_allocator to the following seems to fix the problem:
// we need to use allocator_traits<Allocator>::construct() to
// copy construct a T if either:
// 1. Allocator has a 2-argument construct() member or
// 2. T has a non-trivial copy constructor
template<typename Allocator, typename T>
  struct needs_copy_construct_via_allocator
    : integral_constant<
        bool,
        (has_member_construct2<Allocator,T,T>::value || !has_trivial_copy_constructor<T>::value)
      >
{};

// we know that std::allocator::construct's only effect is to call T's
// copy constructor, so we needn't consider or use its construct() member for copy construction
template<typename U, typename T>
  struct needs_copy_construct_via_allocator<std::allocator<U>, T>
    : integral_constant<
        bool,
        !has_trivial_copy_constructor<T>::value
      >
{};


Path issues in 0.15

detox==0.15, tox==3.5.2
Traceback (most recent call last):\
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/py/_path/local.py", line 152, in __init__
    path = fspath(path)
TypeError: expected str, bytes or os.PathLike object, not tuple

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/eventlet/hubs/hub.py", line 460, in fire_timers
    timer()
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/eventlet/hubs/timer.py", line 59, in __call__
    cb(*args, **kw)
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/eventlet/event.py", line 175, in _do_send
    waiter.switch(result)
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/eventlet/greenthread.py", line 219, in main
    result = function(*args, **kwargs)
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/detox/proc.py", line 151, in runtests
    if self.toxsession.installpkg(venv, sdist):
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/tox/session.py", line 551, in installpkg
    self.resultlog.set_header(installpkg=py.path.local(path))
  File "/Users/david.jetelina/.local/share/virtualenvs/kzlib-lvViDtZ5/lib/python3.7/site-packages/py/_path/local.py", line 154, in __init__
    raise ValueError("can only pass None, Path instances "
ValueError: can only pass None, Path instances or non-empty strings to LocalPath

Tried rolling back to 0.13, which is incompatible with tox 3.5.2, so I froze my project at tox 3.2.1 and detox 0.13 for now (works perfectly).

Hi @iScrE4m, thanks for reporting this. This is anincompatibility introduced by changes in tox (starting here: https://travis-ci.org/tox-dev/detox/builds/437378523). I will see if I can fix it over the weekend and cut another release.


supplier-order-3-0-0 GET listing functions dont support offset even though the description indicates so

 '/delivery-instructions':     # GET /delivery-instructions     # None => ListOfDeliveryInstructions     get:       summary: Listdelivery-instructions      description: Get a **paginated** list of alldelivery-instructions.
see https://github.com/papinet/papiNet-API/blob/feature/supplier-order-3-0-0/3.0.0/papiNet-API.yaml
Paginated list is mentioned in the description.

Indeed. Thanks! I have forgotten to add the offset and limit query parameters (as defined in release 2.0.0) for the list/collection API endpoints:

GET /supplier-orders
GET GET /logistics-delivery-notes
GET /delivery-instructions

Done, see commit 1846819.


[0.10.0-rc1] Cannot restart node with -join args specified

When creating a cluster, nodes that are restarted while still specifying -join args get stuck and won't boot until the are started without them.

This is not fixed when using the default provided configuration file (/etc/influxdb/influxdb.conf).
E.g., it does NOT work when starting with
node1$ influxdb -config /etc/influxdb/influxdb.conf
node2$ influxdb -config /etc/influxdb/influxdb.conf -join node1:8091

but does work with:
node1$ influxdb
node2$ influxdb -join node1:8091

After few test & trial, it seems that the issue is the "dir" option:
# directory where server ID and cluster metaservers information will be kept
dir = "/var/lib/influxdb"

When commented or left to empty string, it working.
Just changing the value is not enough to be in working or not-working case. I had to remove /var/lib/influxdb/* between run.
Step to reproduce:

All node are fresh, just recreated.

node1# ls -la /var/lib/influxdb
total 8
drwxr-xr-x  2 influxdb influxdb 4096 Feb  2 08:03 .
drwxr-xr-x 27 root     root     4096 Feb  2 09:39 ..
node1# env | grep INFLUXDB_
INFLUXDB_META_BIND_ADDRESS=node1:8088
INFLUXDB_META_HTTP_BIND_ADDRESS=node1:8091
INFLUXDB_HTTP_BIND_ADDRESS=node1:8086

node2# ls -la /var/lib/influxdb
total 8
drwxr-xr-x  2 influxdb influxdb 4096 Feb  2 08:03 .
drwxr-xr-x 27 root     root     4096 Feb  2 09:39 ..
node2# env | grep INFLUXDB_
INFLUXDB_META_BIND_ADDRESS=node2:8088
INFLUXDB_META_HTTP_BIND_ADDRESS=node2:8091
INFLUXDB_HTTP_BIND_ADDRESS=node2:8086

Start the cluster for the first time:

node1# influxd -config /etc/influxdb/influxdb.conf
2016/02/02 11:12:30 InfluxDB starting, version 0.10.0.n1454400035, branch master, commit fd85ae5b7fada9142aac66603200e6cc124f9aed, built 2016-02-02T08:01:46.972758
2016/02/02 11:12:30 Go version go1.4.3, GOMAXPROCS set to 4
2016/02/02 11:12:31 Using configuration at: /etc/influxdb/influxdb.conf
[meta] 2016/02/02 11:12:31 Starting meta service
[meta] 2016/02/02 11:12:31 Listening on HTTP: <IP_ADDRESS>:8091
[metastore] 2016/02/02 11:12:31 Using data dir: /var/lib/influxdb/meta
[metastore] 2016/02/02 11:12:31 Node at node1:8088 [Follower]
[metastore] 2016/02/02 11:12:32 Node at node1:8088 [Leader]. peers=[node1:8088]
[...]

node2# influxd -config /etc/influxdb/influxdb.conf -join influxdb1:8091
2016/02/02 11:13:42 InfluxDB starting, version 0.10.0.n1454400035, branch master, commit fd85ae5b7fada9142aac66603200e6cc124f9aed, built 2016-02-02T08:01:46.972758
2016/02/02 11:13:42 Go version go1.4.3, GOMAXPROCS set to 4
2016/02/02 11:13:42 Using configuration at: /etc/influxdb/influxdb.conf
[meta] 2016/02/02 11:13:42 Starting meta service
[meta] 2016/02/02 11:13:42 Listening on HTTP: <IP_ADDRESS>:8091
[metastore] 2016/02/02 11:13:42 Using data dir: /var/lib/influxdb/meta
[metastore] 2016/02/02 11:13:42 Node at node2:8088 [Follower]
[...]
2016/02/02 11:13:52 updated node metaservers with: [node1:8091 node2:8091]

shutdown node2 then node1.
Restart node1 then node2:

node1# influxd -config /etc/influxdb/influxdb.conf
2016/02/02 11:15:06 InfluxDB starting, version 0.10.0.n1454400035, branch master, commit fd85ae5b7fada9142aac66603200e6cc124f9aed, built 2016-02-02T08:01:46.972758
2016/02/02 11:15:06 Go version go1.4.3, GOMAXPROCS set to 4
2016/02/02 11:15:06 Using configuration at: /etc/influxdb/influxdb.conf
[meta] 2016/02/02 11:15:06 Starting meta service
[meta] 2016/02/02 11:15:06 Listening on HTTP: <IP_ADDRESS>:8091
[metastore] 2016/02/02 11:15:06 Using data dir: /var/lib/influxdb/meta
[metastore] 2016/02/02 11:15:06 Node at node1:8088 [Follower]

<no more message, even after node2 startup>

node2# influxd -config /etc/influxdb/influxdb.conf -join node1:8091
2016/02/02 11:15:41 InfluxDB starting, version 0.10.0.n1454400035, branch master, commit fd85ae5b7fada9142aac66603200e6cc124f9aed, built 2016-02-02T08:01:46.972758
2016/02/02 11:15:41 Go version go1.4.3, GOMAXPROCS set to 4
2016/02/02 11:15:41 Using configuration at: /etc/influxdb/influxdb.conf
[meta] 2016/02/02 11:15:41 Starting meta service
[meta] 2016/02/02 11:15:41 Listening on HTTP: <IP_ADDRESS>:8091
[metastore] 2016/02/02 11:15:41 Using data dir: /var/lib/influxdb/meta

Stop both node.
Drop data and update config:

node1##rm -vfr /var/lib/influxdb/*
removed directory: '/var/lib/influxdb/data/_internal/monitor/1'
removed directory: '/var/lib/influxdb/data/_internal/monitor'
removed directory: '/var/lib/influxdb/data/_internal'
removed directory: '/var/lib/influxdb/data'
removed directory: '/var/lib/influxdb/hh'
removed '/var/lib/influxdb/meta/raft.db'
removed '/var/lib/influxdb/meta/peers.json'
removed directory: '/var/lib/influxdb/meta/snapshots'
removed directory: '/var/lib/influxdb/meta'
removed '/var/lib/influxdb/node.json'
removed '/var/lib/influxdb/wal/_internal/monitor/1/_00001.wal'
removed directory: '/var/lib/influxdb/wal/_internal/monitor/1'
removed directory: '/var/lib/influxdb/wal/_internal/monitor'
removed directory: '/var/lib/influxdb/wal/_internal'
removed directory: '/var/lib/influxdb/wal'

node2# rm -fr /var/lib/influxdb/*

node1# sed -i 's@^dir = "/var/lib/influxdb"$@#dir = "/var/lib/influxdb"@' /etc/influxdb/influxdb.conf
node2# sed -i 's@^dir = "/var/lib/influxdb"$@#dir = "/var/lib/influxdb"@' /etc/influxdb/influxdb.conf

Redo previous step:
Start cluster for first time:

node1# influxd -config /etc/influxdb/influxdb.conf
node2# influxd -config /etc/influxdb/influxdb.conf -join node1:8091

Stop cluster
Restart both node:

node1# influxd -config /etc/influxdb/influxdb.conf
2016/02/02 11:20:32 InfluxDB starting, version 0.10.0.n1454400035, branch master, commit fd85ae5b7fada9142aac66603200e6cc124f9aed, built 2016-02-02T08:01:46.972758
2016/02/02 11:20:32 Go version go1.4.3, GOMAXPROCS set to 4
2016/02/02 11:20:32 Using configuration at: /etc/influxdb/influxdb.conf
[meta] 2016/02/02 11:20:32 Starting meta service
[meta] 2016/02/02 11:20:32 Listening on HTTP: <IP_ADDRESS>:8091
[metastore] 2016/02/02 11:20:32 Using data dir: /var/lib/influxdb/meta
[metastore] 2016/02/02 11:20:32 Node at node1:8088 [Follower]

< node 2 started >
[metastore] 2016/02/02 11:20:57 Node at node1:8088 [Leader]. peers=[node2:8088 node1:8088]
[meta] 2016/02/02 11:20:57 <IP_ADDRESS> - - [02/Feb/2016:11:20:57 +0000] GET /?index=0 HTTP/1.1 200 170 - Go 1.1 package http 07bd0cdd-c99f-11e5-8001-000000000000 1.401581ms
[store] 2016/02/02 11:20:57 Using data dir: /var/lib/influxdb/data
[tsm1wal] 2016/02/02 11:20:57 tsm1 WAL starting with 10485760 segment size
[...]

node2# # influxd -config /etc/influxdb/influxdb.conf -join node1:8091
2016/02/02 11:20:55 InfluxDB starting, version 0.10.0.n1454400035, branch master, commit fd85ae5b7fada9142aac66603200e6cc124f9aed, built 2016-02-02T08:01:46.972758
2016/02/02 11:20:55 Go version go1.4.3, GOMAXPROCS set to 4
2016/02/02 11:20:55 Using configuration at: /etc/influxdb/influxdb.conf
[meta] 2016/02/02 11:20:55 Starting meta service
[meta] 2016/02/02 11:20:55 Listening on HTTP: <IP_ADDRESS>:8091
[metastore] 2016/02/02 11:20:55 Using data dir: /var/lib/influxdb/meta
[metastore] 2016/02/02 11:20:55 Node at node2:8088 [Follower]
[meta] 2016/02/02 11:20:57 <IP_ADDRESS> - - [02/Feb/2016:11:20:57 +0000] GET /?index=0 HTTP/1.1 200 170 - Go 1.1 package http 07c29ea2-c99f-11e5-8001-000000000000 1.005385ms
[store] 2016/02/02 11:20:57 Using data dir: /var/lib/influxdb/data
[...]

Note: the only change I see was where "node.json" is:

With dir="/var/lib/influxdb", node.json is /var/lib/influxdb/node.json
Without dir, node.json is /var/lib/influxdb/meta/node.json

It is now fixed also with default /etc/influxdb/influxdb.conf file. Probably by PR #5515


DSD-244: Adding textarea element to the TextInput component

Fixes DSD-244
This PR does the following:

Adds the ability to pass in TextInputTypes.textarea into the TextInput component to render a textarea element.

Front End Review:

[ ] View the example in Storybook

Cool, updated.


ethstats access!?

How to get ethstats access so we can participate in the extension too?

ping me on Matrix - https://matrix.to/#/#goerli_chat:gitter.im


Another case for allowing PHP 8 in composer.json

Considering the previous six conversations about this topic have been closed as won't fix, I was reluctant to bring this up again. But not all facts have been brought up in the previous discussions and I believe explicitly disallowing PHP 8 is not the right decision. Please let me explain.
It's true the version constraints on Guzzle 5 and 6 were wrong, they unintentionally allow PHP 8. Guzzle 5 does not work on PHP 8 and the version constraints have been updated [1] accordingly. Guzzle 6 is in security-only mode so did not receive the PHP 8 fixes Guzzle 7 had and PHP 8 is not officially supported. But accidentally, it does work. Looking at the changes done to Guzzle 7 to support PHP 8 [2], they only touch annotations and tests.
While nobody will guarantee every part of the library works on PHP 8, in practice Guzzle 6 runs fine on PHP 8, including the async functions used by this adapter. Also, Drupal 9.1 officially supports PHP 8 and they do that using Guzzle 6.5.5.
So, yes it's good advice to tell people to upgrade to Guzzle 7. A warning about using Guzzle 6 on PHP 8 might be appropriate too. But I don't see why people depending on Guzzle 6 should be forced to fork this repository if they have a depedency on this adapter.
If there actually is an incompatibility I'd appreciate it if someone could point out what part is incompatible.
[1] https://github.com/guzzle/guzzle/pull/2834
[2] https://github.com/guzzle/guzzle/pull/2715/files
Related issues: #76 #77 #78 #80 #81 #82

i understood that guzzle 6 has failures on php 8. maybe it depends on which guzzle 6 minor version, in addition?
given how simple the adapter is, what is the problem with using guzzle7-adapter?

That's preferrable of course, but if for some reason you must use Guzzle 6 (in my case, Drupal doesn't yet support Guzzle 7) then you must use the Guzzle 6 adapter.

@sagikazarmark do you have inputs on the topic of guzzle 6 on php 8? my understanding was that there are issues - but if there are none, @jorissteyn arguments convinced me that we should allow installation of this adapter on php 8

merged PHP 8 support in #86, will tag a release shortly.


Errors in sample_entropy and higuchi_fd on a small vector

Hi, is this supposed to be?
import antropy as ant

print(ant.sample_entropy([-1, 2, 1, 3, 3]))

C:\ProgramData\Anaconda3\lib\site-packages\antropy\entropy.py in sample_entropy(x, order, metric)
663     x = np.asarray(x, dtype=np.float64)
664     if metric == "chebyshev" and x.size < 5000:
--> 665         return _numba_sampen(x, order=order, r=(0.2 * x.std(ddof=0)))
666     else:
667         phi = _app_samp_entropy(x, order=order, metric=metric, approximate=False)
IndexError: getitem out of range

print(ant.higuchi_fd(x))

C:\ProgramData\Anaconda3\lib\site-packages\antropy\fractal.py in higuchi_fd(x, kmax)
297     x = np.asarray(x, dtype=np.float64)
298     kmax = int(kmax)
--> 299     return _higuchi_fd(x, kmax)
300
301
ZeroDivisionError: division by zero

Hi,
I think that it doesn't really make sense to calculate the entropy or fractal dimension on such small arrays. That said, I haven't formally tested what should be the minimum sample size for these functions. It would be helpful to add a more explicit error message when the sample size is too low.
Thanks,
Raphael

I just ran into this as well when benchmarking the old and the new kernel. The old kernel works fine from 6 samples onwards for order=2. My guess is that the old kernel accessed the samples in blocks of a certain length (perhaps 2*(order+1)?) and thus needs at least one window/block worth of data to operate.
The new kernel doesn't have this limitation and will work happily with any array length. That said, @raphaelvallat comment still stands: sample_entropy is not reliable on small sample sizes so results should be taken with a grain of salt.

Should be fixed in https://github.com/raphaelvallat/antropy/releases/tag/v0.1.6 since we are now using the new kernel


Secure comparator is broken

The attack is send g2a or g2b as the zero point "(0, 2^255-19+1)"
unsigned char zero[32] = {0xee, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
                          0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
                          0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
                          0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f};

These won't match this zero point: https://github.com/cossacklabs/themis/blob/50fd35d987c5fcde55954e2ccc645bca721be50c/src/themis/secure_comparator.c#L168 and https://github.com/cossacklabs/themis/blob/50fd35d987c5fcde55954e2ccc645bca721be50c/src/themis/secure_comparator.c#L241

Oh that's funny https://github.com/cossacklabs/themis/issues/83.
P.S. You should also test after scalar point multiplication for the zero point or "8*input == zero" because I can give you a point of order 8 for g2a or g2b and achieve the same as a zero point. I pretty sure Ed25519 only has points that are of order 1, 2, 4, 8, and 2^252+27742317777372353535851937790883648493.

Thank you for pointing this out. We are considering it as part of #83 . Maybe it doesn't make sense to verify g2a or g2b at all, but rather to check the final g2. What do you think?

That is what I was suggesting. Well g2, g3, Rab, and R but I don't think checking g3, Rab, and R{a,b} is necessary. But I'm too drunk to understand what you are even doing... besides a PAKE algorithm.
Have you heard of SPAKE2 (or SPAKE2-EE)? There's also the client-server augmentation: PAKE2+ and PAKE2+EE. Both are much faster and have security proofs.

Actually, we were considering it for other use-cases we are having from the industry. So far these are more like handling personal data than PAKE or authentication. This is just a building block we want to try out and see whether it will fit their needs. So it is not a full-featured protocol but rather a potential piece in a bigger security structure/protocol.

... So you don't want to use an algorithm that's better and faster because it covers more use cases? 0_o

Thank you for your feedback and attention to detail. Shortly, my colleague will return after investigation and you will be able to get back to technical detail.
I can answer about general choice and reasoning, however don't think github issue is the right place to discuss such things and my discourse is going to be obvious and boring :) If password auth and speed was the only considerations, there would be much better choices than either SC or PAKE.  SC's threat model is seen around 'no possible leakage' both in transport and on verifier side - for some use cases we need mutual authentication, which by design has nothing to leak even to dishonest party (this is the main use case for us, password authentication is just something that came along the way and could be developed from current SC state).
When we were planning SC a year ago as a part of larger research, we were not aware of ECC-based SPAKE implementation, and I am still not aware of publicly available security proofs (although seeing work of Mike Hamburg makes me think he knows what to do, @secumod might comment better on that). Moreover, at that point, non-EE SPAKE2 is discrete log problem class with obvious future repercussions to that.
We're quite lazy, and remember Schneier's law well, so if there was an instrument, which would fit us - we'd implement it in the first place.

tl;dr We would like to choose an algorithm for our particular use-cases. It doesn’t make much sense to hammer nails with a screwdriver.
Regarding SPAKE “better” is very questionable. The basic description does not recommend any choice of specific fields (even size of the field), so implementations might end-up having “simple common DH params”. We know where it goes: https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf . Also, as noted in above paper, it feels that proposing non-ECC protocols today is similar to advertising video tapes in today’s world of digital online media.
On the other hand, unfortunately, today’s choice of an algorithm is determined not only by security or speed, but potential applicability and adoption as well. If I see SPAKE-EE description, it mentions NIST curves. Even if one does not consider http://safecurves.cr.yp.to/rigid.html , just enabling such ECC in a new protocol might cause a lot of patent trouble. Many argue that basic ECC is not patented, but unfortunately most efficient computations are. So you may end up using only “basic schoolbook scalar multiplier” to avoid any patent fuzz and loose all your speed benefits and introduce a timing attack. That’s why you still don’t see much ECC around, except for TLS, which was considered safe from patents because of “explicit Certicom royalte free grant”: https://www.certicom.com/pdfs/FAQ-TheNSAECCLicenseAgreement.pdf. However, even TLS is not safe anymore: http://www.theregister.co.uk/2015/12/01/cryptopeak_sues_/ . That’s why many big enterprises are known to explicitly avoid ECC-based crypto, because the risks are too high, unless they are sure they can safely adopt it. Also, that’s why even today many new security technologies still prefer RSA.
P.S. We pushed a fix to the problem and would greatly appreciate your comments.

I assume you are referring to a54f2fe.
I think it is still exploitable, however it depends on internals of how ed25519 is implemented, and I have not looked much at that yet.
The check for Qa == Qb is useless, because an attacker might make Qa - Qb an element that simply has order 8, which would still make rand3 * R == 0. Alternatively an attacker could choose Ra to be of low order, so rand3 * Ra == 0.
The bottom line is that Rab could still be zero and the check does nothing to prevent that.
This would not be a problem in itself, if not for another problem: I think it should be possible to make Pa - Pb == 0 without having Pa == Pb. It would at least be possible for curve25519 by choosing Pb = (-Pa) | 2 ** 255
My advice:

Either remove the check for Pa == Pb or replace it with a check for Pa - Pb == 0.
Either remove the check for Qa == Qb or replace it with a check for rand3 * (Qa - Qb) == 0.
Insert a check for Rab == 0.

I think that the last one would be sufficient to make the implementation secure against these kinds of attacks however there is not much lost by doing all of them.
P.S. You should probably make ge_is_zero constant-time.

Hmmm. There are more attacks, which libotr protects against, but this implementation does not. One attack is to try and make Ra = base and Pa_Pb == g3a. I do not think that this is possible in the current implementation, but only a slight change would make it possible.

Thanks for your valuable feedback. Good catch for ge_is_zero: somehow I had g2a in mind, but then moved check to g2 which should be done in constant-time. As for the rest, I will try to expand test cases to test all of the above: we would still like to try to minimize the checks, especially ones with point-scalar multiply. Or we might replace rand3 * (Qa - Qb) == 0 with 8 * (Qa - Qb) == 0 and check it with point addition instead.

Well, you are already computing Ra = rand3 * (Qa - Qb), so why do the extra point multiplication?
In any case: Consider the case where Bob sends Rb == base and Pb == g3a - Pa in step 4. This would make Rab == rand3 * base == g3a and Pa_Pb == g3a, so the authentication would succeed.
You have no way of detecting this, that would not simply be adding a lot of special-cases everywhere. I would think that there are more similar attacks possible, which would mean you would require many such special-cases.
The way OTR solves this is by having every value include a ZK-proof that it is valid. For instance g2a is checked using a Schnorr signature.

Hmm. After more detailed look I see they use Schnorr signatures everywhere as ZK-proofs. Since ed25519 is a EC variant of Schnorr signature maybe we should just reuse their approach. Will take a look in that direction.

You will need to design a few primitives yourself, as they also use ZK-proofs for e.g. "I know a y such that g3a = y * base and Ra = y * R".
But yes, I think it should be doable. If you haven't already, I would suggest reading the first 8 pages of https://www.win.tue.nl/~berry/papers/dam.pdf

I've ported all ZK-proofs from OTR to ed25519. If you have time, would really appreciate your feedback for #89

These lines are broken:
    if (!ge_cmp(&(comp_ctx->Pp), &(comp_ctx->P)))

More generally:
There are only three types of checks in the OTR implementation and in the original paper:

That a send value is valid. In ECC terms this would mean, 1 <= n < SM_ORDER and x is a valid point different from 0.
That a ZK-proof is valid.
That the final result is correct.

So almost all of the ge_cmps are superfluous, if we assume that the other checks are inserted correct.
It turns out that they are not. For instance signature[63] & 224 is insufficient to check if signature[32:64] is a valid.
I have not yet verified whether that check is actually necessary, but I think it is. In any case: Either the check should be there and be done correctly, or it should be removed to reduce complexity.

So far I removed some of the checks which are probably indeed excessive. The idea behind that is the following:

we initially check two DH values g2, g3 are non-zero
we rely on ZK-proofs for other parameter validations
we explicitly prohibit Rab to be zero. This makes the match possible only for real case or g2 being zero, but we checked that before

Would appreciate your comments on #92

Closed by #92 (hopefully...)


Cache improvements

Is your feature request related to a problem? Please describe.
Getting multiple values from the cache involves lots of copy pasta.
Describe the solution you'd like
Methods to get/set multiple cache values Cache::many() etc.
Describe alternatives you've considered
Loops are a bit ugly.
Additional context
Laravel has (poorly documented) multiple methods to handle many cache keys. many, putMany
The ability to add a prefix to cache keys would also be cool:
Cache::prefix('users')->putMany([
  'ben'   => User::find(1), // users.ben
  'jerry' => User::find(2), // users.jerry
]);

$ben = Cache::get('users.ben');
$jerry = Cache::prefix('users')->get('jerry');

Reopened as the prefix idea wasn't implemented

To be consistent with Laravel, the cache prefix should be set in the config rather than when calling the class

Reopened until the config has been implemented.