terminal-flat-theme 2.0.0

It was the time to push some new updates in this project! :hourglass:
In this pull request I'm adding multiple terminal compatibility, provided by this nice tool. :star2:
This also fixes #6–adding compatibility with the latest changes (and maybe latest bugs) in gconftool2. Now it creates a new profile (at least in Gnome Terminal) which you have to manually select and then automagically enjoy. :smile:
@iRaul Can you please test the iTerm theme (schemes/iterm.xml)? Thanks! :green_apple:

@iRaul Can you please give feedback on this? :bell:

@iRaul I investigated why the previous version didn't work for you. I speculate it was because of the tabs vs spaces thingy. Now the iTerm scheme contains tabs and should work for you too. :smile:

Sound`s good @IonicaBizau! Now we can test this theme without no hacks :smile:

@iRaul Yeah! :grimacing: If you like to improve the colors, there is always something to improve. Contributions are more than welcome! :sparkle:

@IonicaBizau Sure, I would love to!


[GAMELIST] Cheevos Icons

For theme developers who have planned a special display for the RetroAchievements Cup, I would suggest an option to hide/show the cheevos Icons in gamelists as we already have for flag, savestate icon and manual icon.
SHOW RETROACHIVEMENTS ICONS                              On / Off

That would be great, wouldn't it?
Thank's for all you do.

Yes it would be great 😇

Yes, this feature would be cool. Thanks in advance.

totally agree

For sure, you are right, we have choice for all icons, i think it is logic that this one too would be possible to hide ...

@fabricecaruso if you ever pass by here 🙏

Done for a while now

merci chef, t'es au top :)


Explicitly declare and isolate dependencies

Reference ios-factor

By specifying the exact dependencies you can re-trigger a build from 6 months ago, knowing that it will succeed as it will use the same version of Xcode, CocoaPods and Swift.

Today DeliTodo build failed because dependencies after bumping Gradients version 0.1.4 to 0.2.1
CHANGELOG
// 0.1.4
Gradients.nightSky.layer()

// 0.2.x
Gradients.nightSky.layer

Explicitly declare and isolate dependencies for

Carthage
CocoaPods

@cruisediary I agree with what you are talking about in PR.
If no version issue and build succeed, It merging.
Thanks for your contributions.

Codecov Report

Merging #4 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #4   +/-   ##
=======================================
  Coverage   44.06%   44.06%
=======================================
  Files          50       50
  Lines        2610     2610
=======================================
  Hits         1150     1150
  Misses       1460     1460

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 5c73b79...e27bbc2. Read the comment docs.


Adding CobbleStone Connector to CSS_Connector

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.
Please note that we are experiencing a significant delay due to a high volume of connector submissions. It may take 1-2 weeks for us to provide comments for your connector.

[ ] I attest that the connector works and I verified by deploying and testing all the operations.
[ ] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[ ] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[ ] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[ ] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process:

[ ] I have named this PR after the pattern of "Connector Name (Independent Publisher)" ex: HubSpot Marketing (Independent Publisher)
[ ] Within this PR markdown file, I have pasted screenshots that show: 3 unique operations (actions/triggers) working within a Flow. This can be in one flow or part of multiple flows. For each one of those flows, I have pasted in screenshots of the Flow succeeding.
[ ] Within this PR markdown file, I have pasted in a screenshot from the Test operations section within the Custom Connector UI.
[ ] If the connector uses OAuth, I have provided detailed steps on how to create an app in the readme.md.

Hi @nizarhandal can you please confirm if this is a custom connector or a verified connector that you would like to publish and already registered? Thanks

Hi Amjed,
Yes it is Custom connector.
Thank you

Hi @nizarhandal I hope you are doing well. I am following up with you to see how things are going with updating your connector artifacts.
Please let us know if you have any questions.
We look forward to getting your connector certified.
Thank you very much.

Hi @nizarhandal, I hope you are doing well.
Can you please let me know how you would like to proceed? If you would like to have an internal custom connector or you would like to publish a certified connector?
I look forward to hearing from you.
Thank you again for working with us.

Hello @nizarhandal,
I hope you are doing well.
I am following up with you to see how things are going with preparing your connector.
Please let us know if you have any questions.
Thank you.

Hello @nizarhandal,
I hope you are doing well.
I am following up in my messages below to see if you need any help with updating your connector artifacts.
Please do not hesitate to reach out to me if you have any questions as we are always here to help.
I look forward to hearing from you.
Thank you very much.

Hi @nizarhandal!
There are missing operationId properties in apiDefinition.swagger.json file that need to be fixed:
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1{entityName}~1Add/post/parameters/0/x-ms-dynamic-values/operationId
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1{entityName}~1Get/post/parameters/0/x-ms-dynamic-values/operationId
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1{entityName}~1Schema/post/parameters/0/x-ms-dynamic-values/operationId
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1{entityName}~1Update/post/parameters/0/x-ms-dynamic-values/operationId
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1{entityName}~1Schema/get/parameters/0/x-ms-dynamic-values/operationId
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1PollTriggers~1{entityName}~1NewRecords/post/parameters/0/x-ms-dynamic-values/operationId
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1PollTriggers~1{entityName}~1UpdatedRecords/post/parameters/0/x-ms-dynamic-values/operationId
##[error]The 'operationId' could not be found in this swagger document. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1PollTriggers~1{entityName}~1NewAndUpdated/post/parameters/0/x-ms-dynamic-values/operationId
##[warning]certified-connectors/CobbleStone - Contract Insight/apiDefinition.swagger.json(,): warning : The operation 'CSSAPIQueryEntity' has more than one response with specified schema, only one schema will be used in the designer. ValuePath: /paths/~1CSSAPI~1v2~1{entityName}~1Get/post/responses
##[warning]certified-connectors/CobbleStone - Contract Insight/apiDefinition.swagger.json(,): warning : The operation 'CSSAPIEntityList' has more than one response with specified schema, only one schema will be used in the designer. ValuePath: /paths/~1CSSAPI~1v2~1EntityList/get/responses
##[warning]certified-connectors/CobbleStone - Contract Insight/apiDefinition.swagger.json(,): warning : The operation 'CSSAPIEntityListSelect' has more than one response with specified schema, only one schema will be used in the designer. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1EntityListForSelect/get/responses
##[warning]certified-connectors/CobbleStone - Contract Insight/apiDefinition.swagger.json(,): warning : The operation 'CSSAPIEntityListUpdate' has more than one response with specified schema, only one schema will be used in the designer. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1EntityListForUpdate/get/responses
##[warning]certified-connectors/CobbleStone - Contract Insight/apiDefinition.swagger.json(,): warning : The operation 'CSSAPIEntityListInsert' has more than one response with specified schema, only one schema will be used in the designer. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1EntityListForInsert/get/responses
##[warning]certified-connectors/CobbleStone - Contract Insight/apiDefinition.swagger.json(,): warning : The operation 'CSSAPIEntitySchemaAttributeDefinitionSelectPurpose' has more than one response with specified schema, only one schema will be used in the designer. ValuePath: /paths/~1CSSAPI~1v2~1PowerAutomate~1{entityName}~1Schema/get/responses
Please let me know if you need help or have any question!

Hello @nizarhandal,
I hope you are doing well.
Congratulations, your pull request is approved and merged. Please submit the files to ISV Studio using your latest commit id, please allow us up to 1-2 weeks to review your submission, and our Engineers will notify you in the “Activity Control” area in ISV Studio. Please make sure that the icon meets all the requirements, that it’s size is 230x230, icon background is not white or transparent and it matches the iconBrandColor property in apiProperties.json file.
After making the submission in ISV Studio, please attach an intro.md file in the activity control section. This file is required and it's different from readme.md. You can find an example of intro.md file on this page at step 6.
Please Create an environment in the Preview region. You will use this environment later to test your connector after Microsoft is done with the functional verification for your connector.
We expect all tests to be completed within 1-2 weeks.
If your connector passes all tests, the deployment process begins, and it typically takes up to 3 to 4 weeks to deploy your connector to all of our regions.
Please let me know if you have any questions.
Thank you very much for working with us.


Add density_profile_plot

Add a little placeholder for

Coverage remained the same at 100.0% when pulling 1150d80df8ed7da64706ee7f4463e00755a7853a on add_density_profile_plot into b691b3fc52791fdbdc3a4a6611a97f8148140480 on master.


Binding GUID to query string does not work when adding ApiController attribute

After adding the [ApiController] attribute to my controller, parameters passed through the query string cannot be bound to GUIDs.
For example:
public async Task<IActionResult> Get(Guid id, CancellationToken token) { (...) } always returns:
{
    "": [
        "The input was not valid."
    ]
}

Any idea why? Did I miss something obvious?

@seroche looks like a dup of https://github.com/aspnet/Mvc/issues/7546 \ https://github.com/aspnet/Mvc/issues/7982. You're likely missing specifying the compat version in your Startup:
var mvcBuilder = services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);

Feel free to use the other open issue for further discussions


Typo baseUrl10

baseUrl10 should be baseUrl0 I believe

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

ID: 5dbbdd70-5068-9e54-b797-7a32ea45672f
Version Independent ID: 8719249a-face-cf09-04a2-57d7cde082a9
Content: Build a Teams messaging extension - Teams
Content Source: msteams-platform/build-your-first-app/build-messaging-extension.md
Product: msteams
GitHub Login: @heath-hamilton
Microsoft Alias: lajanuar

Cannot find baseUrl10 anywhere in the referenced document. Please check and let me know.


[VCDA-4558] Update clusterctl, templates and CRS definitions, add v1.21, v1.22 template flavors

Description
Please provide a brief description of the changes proposed in this Pull Request

Update fields in clusterctl
Removed useOneArm in templates
Added v1.21.8, v1.22.9 templates

Tested both with and without CRS
CRS: Added labels to generated template cni: antrea, ccm: external, csi: external after applying CRS definitions
Non-CRS: Deployed a cluster successfully in VCD, with no CPI/CSI.

Checklist

[x] tested locally
[ ] updated any relevant dependencies
[ ] updated any relevant documentation or examples

API Changes
Are there API changes?

[ ] Yes
[ ] No

If yes, please fill in the below

Updated conversions?

[ ] Yes
[ ] No
[ ] N/A

Updated CRDs?

[ ] Yes
[ ] No
[ ] N/A

Updated infrastructure-components.yaml?

[ ] Yes
[ ] No
[ ] N/A

Updated ./examples/capi-quickstart.yaml?

[ ] Yes
[ ] No
[ ] N/A

Updated necessary files under ./infrastructure-vcd/v1.0.0/?

[x] Yes
[ ] No
[ ] N/A

Issue
If applicable, please reference the relevant issue
Fixes #

This change is

templates/cluster-template-v1.21.8.yaml line 28 at r1 (raw file):

kind: Secret
metadata:
  name: capi-user-credentials

Should we parameterize the name of the secret as well? We can see some unusual cases if more than one cluster exists in the same namespace


quantizer documentation

Thanks for the amazing work.
I am reading the documentation and it says : 8-bit quantization: Quantile, Linear, and Dynamic quantization
In the code i also observe block wise quantization.
Can you please share some documentation or pointer to these quantizers . Also curios if these quantizer preserve not just multiplication of matrices but also distance metrics like euclidean , ip, cosine . This would be helpful for ANN (approx nearest neighbour ) techniques as well.

You can read more about these quantization methods in the 8-bit optimizer paper. You can find quantile quantization in the appendix.
None of the block-wise quantization methods preserve distances or multiplication of matrices since they are block-wise dependent.
You can use bnb.functional.double_quant for this which performs linear quantization for the full row and column of an input 2D tensor. As such, linear operations like distance or matrix multiplication preserve their values if you dequantize them after the operation.


VARBINARY not supported and issue with BINARY

Hello,
the following case does not work with cassandra-jdbc-driver:

// create table atable(id blob primary key)
Connection c = DriverManager.getConnection(DB, null, null);
PreparedStatement s = c.prepareStatement("INSERT INTO atable (id) VALUES (?)");
final byte[] ID1 = new byte[] {
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1
};
s.setObject(1, ID1, Types.VARBINARY);
s.executeUpdate();

throwing the errror:
java.sql.SQLException: Unsupported SQL type: -3
	at com.ing.data.cassandra.jdbc.CassandraPreparedStatement.setObject(CassandraPreparedStatement.java:662)
	at com.ing.data.cassandra.jdbc.CassandraPreparedStatement.setObject(CassandraPreparedStatement.java:538)

I think the issue is in setObject()
https://github.com/ing-bank/cassandra-jdbc-wrapper/blob/5f9fda7ddf4a28e7ca5270610542dd1984653e1d/src/main/java/com/ing/data/cassandra/jdbc/CassandraPreparedStatement.java#L543
In particular, in the block handling Types.BINARYY
https://github.com/ing-bank/cassandra-jdbc-wrapper/blob/5f9fda7ddf4a28e7ca5270610542dd1984653e1d/src/main/java/com/ing/data/cassandra/jdbc/CassandraPreparedStatement.java#L556-L564
As per the JDBC documentation, the method should perform a conversion taking into account multiple cases for the input type. However I agree to take a simpler approach at least to start with, but I see to main issues with the current implementation:

it does not handle Types.VARBINARY (therefore the exception); this can be easily fixed handling it as a synonym of BINARY
it assumes the object to be an InpuStream while instead it can be any type. Leaving apart handling Ref, Blob, Clob, NClob, Struct, java.net.URL, and Array, it should support at least the case the object is a byte array.

I would propose something like this:
case Types.BINARY:
case Types.VARBINARY:
    byte[] array = null;
    if (x instanceof ByteArrayInputStream) {
        array = new byte[((ByteArrayInputStream) x).available()];
        try {
            ((ByteArrayInputStream) x).read(array);
        } catch (final IOException e) {
            LOG.warn("Exception while setting object of BINARY type.", e);
        }
    } else if (x instanceof byte[]) {
        array = (byte[])x;
    } else {
        throw new SQLException("Unsupported parameter type: " + x.getClass());
    }
    this.boundStatement = this.boundStatement.setByteBuffer(parameterIndex - 1, ByteBuffer.wrap(array));
    break;

I won't be able to provide a PR due to the need of a dockered Cassandra... :(

Hello @stefanofornari,
Thank you for reporting this issue.
You're right, VARBINARY and LONGVARBINARY aren't handled properly.
If you can, alternatives exist to execute this prepared statement until the setObject() method is fixed:
s.setBytes(1, ID1);

or
s.setBlob(1, new SerialBlob(ID1));

or transforming the byte array passed to setObject() into a ByteArrayInputStream (I admit this is neither really optimal nor elegant).
I will take a closer look at this point to provide a solution as complete as possible (the one you suggested is a good basis), but I cannot guarantee a release date for this. As workarounds exist to get similar results, I'll probably include this fix in the next minor version (4.11.0) to release at the end of this year or beginning of 2024.
NB: regarding the tests, you just need a running docker, the image is provided through Testcontainers. But it's ok if you can't run docker for some reason. Using this solution for testing is the more convenient to run tests in an environment as close as possible of real conditions.

Hi @maximevw, thanks for taking care of this. Let me first disclaim I have little/no control on the actual JDBC calls because I am using a ORM which then use cassandra-wrapper.
The proposal solution unfortunately does not work because VARBINARY is currently not supported at all. It would be great if we could have just an hot fix with case Types.VARBINARY: added.
Regarding docker, I do not want to open a debate, but IMHO unit tests of the driver should not relay on the presence of a real server (for multiple reasons, not just the added complexity).

@stefanofornari, since you can't apply the workaround in your case, I'll try to provide a quick hotfix for VARBINARY handling in setObject() as soon as possible (I'm a little busy at the moment).
Regarding the tests, I agree pure unit testing, in general, shouldn't rely on servers/containers. However, for a JDBC implementation, we are closer to integration testing because we want to be sure the driver is able to connect to a database and to execute queries properly. Mocking the database is not easier in my opinion and error prone. If you look at how JDBC drivers for MS SQL Server (https://github.com/Microsoft/mssql-jdbc/) or PostgreSQL (https://github.com/pgjdbc/pgjdbc) are tested, they are against a real database. So, this is just two examples (but not the least), but it seems that is a good manner to test a JDBC driver.
Feel free to discuss it in a separate topic if you have ideas or proposal to improve that.

Hello @stefanofornari,
I just released the version 4.10.2 including a fix for this issue. The version will also be available in Maven Central in next hours.
A review of types potentially not handled by setObject() methods will be performed before releasing version 4.11.0 of the JDBC wrapper.

Great stuff! I will give it a try in the tomorrow and let you know.

I confirm it work for me.


test: Increase unit test code coverage in pkg/api

Description
MGDSTRM-7983
Files changed:

before %
after %

cluster_types.go
61.7
78.3

json.go:
0
100

leader_lease_types.go
0
100

quota_service_types.go
0
100

semverutil.go
90
96.8

error.go
adder to ignore coverage

metadata.go
added to ignore coverage

Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has created for changes required on the client side

@VanillaSpoon thanks for the PR. The CI failure does not look related, it is something that has been fixed in https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/932. Can you rebase to get the fix?

Thanks for all the feedback @ziccardi
You've been very helpful :)


Update dependencies

Type

maintenance

Description
Routine update of dependencies. Required a lot of mechanical changes of storybook files.
List of notable changes

Major version change for Typescript (v3 -> v4)
Major version change for Storybook (v5 -> v6)

removed typescript from custom webpack config (Storybook now has zero-config typescript support)
changed stories from using the storiesOf function to the "component story format" (considered best practice now)
changed the way we were using addon-actions to the one recommended by the docs (i.e. using the args api)
removed addon-notes (it's deprecated)

Major version change for postcss-loader

postcss now has to be an independent peer dependency
syntax for postcss-loader options has changed

Major version change for D3 (v5 -> v6) — upgrade went smoothly and didn't require any code changes

Checks

npm run check-types — ✔
npm test — ✔
npm audit fix — 0 vulnerabilities
development build — 👌
production build — 👌

I'm not sure if it is related to this PR but UnsplicedTranscripts looks a bit broken:

Found out some issues with links to apps like species selector and download manager. I can't recall if we opted to stop using /app for apps.

@imransl We did. Can you remember where the broken links are?
Doesn't look like it's related to this PR, so we can fix them in a separate one. I'll soon create one that changes the /browser path to /genome-browser; we can address the broken links problems there.

I'm not sure if it is related to this PR but UnsplicedTranscripts looks a bit broken:

@msmanoj yes, it already is this way in the current deployment of the storybook, so this regression wasn't introduced in this PR.

If you notice closely, the component seems to expand beyond the wrapper:

Currently on live:

@imransl I think I have addressed your concern regarding routes still containing the /app/ segment in this PR: https://github.com/Ensembl/ensembl-client/pull/345

I actually wonder whether we need this story anymore (this, and the one about proteins). It helped us develop the respective components in isolation, before any backend was ready; but since we have already moved these components into EntityViewer, and since they are non-repeating, maybe there isn't any point for keeping them in the storybook.

I don't have a strong opinion on this but it is nice to see all these components in an isolated view.

@imransl I think I have addressed your concern regarding routes still containing the /app/ segment in this PR: #345

I've already approved that PR :simple_smile:


Buttons do not vertically align with inline form elements in Firefox

Using a simple mdl-textfield followed by a button inline, they align properly in Chrome and Edge, but not in Firefox. I have setup a codepen to demonstrate the issue.
The included CSS is a fix to the problem which is only applied to the second mdl-cell. I haven't checked if this breaks something else, but if not I'd be more than happy to submit a PR.

I'm also including a couple of screenshots of how it looks like (Firefox) and how it should look to match the other browsers.

Duplicate of #1885 it looks like.


Occasionally, names appear to be white in light mode

Firefox Linux
Not sure if it affects Chromium.

I have also been facing this same issue on Microsoft Edge (chromium) for quite a while but it has never bothered me enough to mention it.

Is this project unalived? ;-;


Add tests for words.py and fix a couple of bugs

This PR adds a tests folder and a set of unit tests for the words.py functions. Many tests are based on the docstring examples. There should be at least a couple of tests for every function there.
Writing tests uncovered one bug and one optimisation:

The code was attempting to convert "th" in "9th" instead of "9" in numbersToWords()
When getting stresses for a title, one more loop was taking place than necessary under certain conditions. If the stresses reached 8 and we were going into the while title_words loop again then we must have more than 8 stresses in total, so we can throw this title away rather than confirm there are more than 8.

I should note that this code was tested using the dependency version numbers in https://github.com/catleeball/tmnt_wikipedia_bot/pull/14.

Sorry for my very slow reply here! I think I had my github notifications going to a filter, oops.
This is amazing, thanks for all the hard work you put into this! With all this wonderful test coverage, I should go back and clean up the bot a little more and add CI to this repository. Thank you again! 😄

No problem at all! Thanks :)


fix: error loading scaleway template URL

fixes an error with setting complianceURL for scaleway when using "template" URL
optimizes pinning services sorting (less mapping)

When running npm start I got the following error:

this was pushed directly to main cause it was blocking other things: https://github.com/ipfs/ipfs-webui/commit/7a3388e3d17560d3e376e57361dd78b8c7fdf8e9


This isn’t the right change but seems to fix it

Issues
This seems to fix the upgrade from 1.1.1 -> 1.2.3 - this is totally not the right way to do it but just wanted to get something on paper
Changelog

[ ] List your changes here
[ ] Make a changie entry

Tophatting

This is not the right way to fix it


[BugFix] Fix refresh materialized view by partition using random distribution

Fixes #23962
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.0
[ ] 2.5
[ ] 2.4
[ ] 2.3

[FE PR Coverage Check]
:heart_eyes: pass : 7 / 8 (87.50%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMaterializedViewRefreshProcessor.java
7
8
87.50%
[1033]


⚠ Bofrost.lu has degraded performance

In 6f89b3d, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1355 ms

Resolved: Bofrost.lu performance has improved in 00194f3 after 38 minutes.


[fix] #3690: Fix C++ musl docker build

Description
Problem

I used wasm-opt crate in #3635
This crates uses wasm-opt tool written in C++
In fact it compiles this tool from source and links with it
In Dockerfile we use musl build. It's a minimalistic libc implementation
Turns out musl doesn't support C++ out of the box, only C

Fix
Download musl pre-built toolchain which supports C++ from thier site and make Rust use it.
Additional changes

Bumped version of wasm-opt crate
Updated toolchain in the wasm_builder. That should have been done in #3655
Added more suitable pattern to ignore target directories to .dockerignore

Linked issue

Closes #3690

Benefits

Checklist

[x] I've read CONTRIBUTING.md
[x] I've used the standard signed-off commit format (or will squash just before merging)
[x] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

Waiting until there will be a new version of iroha2-ci docker image with nightly-2023-06-25 toolchain

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
955 unchanged lines in 27 files lost coverage.
Overall coverage decreased (-0.06%) to 59.375%

Files with Coverage Reduction
New Missed Lines
%

client_cli/src/main.rs
1
0%

client/src/http_default.rs
1
0%

cli/src/main.rs
1
0%

core/src/smartcontracts/isi/asset.rs
1
29.79%

data_model/src/transaction.rs
1
47.66%

derive_primitives/src/lib.rs
1
0%

macro/derive/src/lib.rs
1
94.59%

wasm_codec/derive/src/lib.rs
1
90.68%

config/base/src/lib.rs
2
91.94%

tools/kagami/src/main.rs
3
2.01%

Totals

Change from base Build<PHONE_NUMBER>:
-0.06%

Covered Lines:
19858

Relevant Lines:
33445

💛  - Coveralls


Update documentation regarding Merge actions

Expected Behavior
In this web page: https://docs.mergify.com/actions/merge/
I expect to have the method replaced by merge_method following this changelog
Actual Behavior
method is present in the documentation
Steps to Reproduce the Problem
Website
Specifications

Pull Request URL:
Mergify Config URL:

👋  @SpenderJules
We actually only renamed the queue action and not the merge action.
In the queue action it seemed too confusing to have only method as the name.
OTOH it seemed quite clear that method in the merge action is the merge method.


[stable/burrow] Update README.md, fix script url error

Signed-off-by: hello2mao<EMAIL_ADDRESS>What this PR does / why we need it:
Update README.md, fix script url error.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] title of the PR contains starts with chart name e.g. [stable/chart]

/ok-to-test
/lgtm

/test pull-charts-e2e

you need to bump the patch version in Chart.yaml

/lgtm


SW-3993 Facility-only filtering on facilityInventories

You should be able to ask for inventories of specific facilities using the
facilityInventories search table, but it was only allowing searches to be
narrowed by species ID.

Current dependencies on/for this PR:

main

PR #1326   👈

This comment was auto-generated by Graphite.


Having trouble with import/no-extraneous-dependencies rule with monorepo using yarn v1 workspaces

Hello eslint-plugin-import team,
I'm working on a monorepo using yarn v1 with a package structure like the diagram below. The root index.js file imports a single export from packages/module-a/index.js. This import generates a import/no-extraneous-dependencies error with my current config.
From reading issues here https://github.com/import-js/eslint-plugin-import/issues/1174 and here https://github.com/import-js/eslint-plugin-import/issues/1650 I see there is a packageDir option to handle monorepos but as far as I can tell it is not the right choice for my case where a package.json that defines a workspaces property uses one of the modules in workspaces itself.
When I do add a file:./packages/module-a dependency to my package.json, the eslint error is removed but my app behaves differently because yarn has now cached the current version of module-a in node_modules as of yarn install instead of having a simple symlink. This means my changes to packages/module-a/index.js changing the exported value are not reflected when I run the node index.js command from root. This is not the behavior I want, so adding a file:.. dependency to make this rule happy is not a good option.
Is it possible to get import/no-extraneous-dependencies working with this case? Since the module is coming from a folder in workspaces, the dependency is not truly extraneous ie it is defined in the package.json. It just isn't in dependencies et al. I see that later versions of yarn have a workspace: type dependency which might help out here, do I need to upgrade to a later version of yarn perhaps?
root
+- package.json
+- index.js
+- packages
  +- module-a
  |  +- package.json
  |  +- index.js

I have put together a minimal repro of the problem here in a standalone repo https://github.com/kepeterson/no-extraneous-with-workspaces

.eslintrc.js
'use strict';

module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:import/recommended',
  ],
  env: {
    node: true
  },
  plugins: ['import'],
  root: true,
  rules: {
    'import/no-extraneous-dependencies': 'error',
  }
};

@kepeterson 👋 same folder structure and I had the same issue happening after upgrading to anything above 2.22.1, didn't have the error before. I'm sure I'm missing something but for now I'll stay on 2.22.1.
Another small note, in the rule I had to specify the packageDir to "./" otherwise it wouldn't work 🙂

The same issue。

Is there an update on this? I am seeing the same issue even though https://github.com/import-js/eslint-plugin-import/issues/1174 has been closed.

Is there an update on this? I am seeing the same issue even though #1174 has been closed.

Yes it's the same for me.

To me it was resolved with following package eslint-import-resolver-typescript with following settings.
settings: {
    "import/resolver": {
      typescript: {
        project: "packages/*/tsconfig.json",
      },
    }
}

That seems to answer it.
@kepeterson if not, i'm happy to reopen.


PDF.js renders degraded bars on Chrome

Link to PDF file (or attach file here):
Example PDF from official PDF.js viewer.
Configuration:

Web browser and its version: Chrome 54.0.2840.87 (64-bit)
Operating system and its version: Mac OS X El Capitan 10.11.6
PDF.js version: 1.6.313
Is an extension: No

Steps to reproduce the problem:

Go to https://mozilla.github.io/pdf.js/web/viewer.html with Google Chrome.
Scroll up and down and zoom in/out until bars appear. It's pretty easy to reproduce.

What is the expected behavior?
It should render the PDF
What went wrong?
The PDF is rendered wrong

This seems to have been fixed in v1.6.414 or Chrome v55.0.2883.95 (64-bit).
Anyone can confirm this?


Implement filter.

[x] Test on Linux with libpcap
[ ] Test on Linux with pfring
[x] Test on Windows with WinPcap or npcap
[x] Test on macOS

I can't make pfring work.
sudo ./target/debug/examples/filter
Opening packet capturing library
Library opened, version is pfring 7.5.0
Opening the lo interface
Interface opened, data link: ethernet
./target/debug/examples/filter: symbol lookup error: /usr/local/lib/libpfring.so.1: undefined symbol: pcap_open_dead

Seems that libpfring doesn't dynamic link with libpcap.
ldd -r /usr/local/lib/libpfring.so.1
        linux-vdso.so.1 (0x00007ffeca397000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd96b223000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd96b01b000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd96ae17000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd96aa26000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd96b6de000)
undefined symbol: pcap_compile_nopcap   (/usr/local/lib/libpfring.so.1)
undefined symbol: pcap_close    (/usr/local/lib/libpfring.so.1)
undefined symbol: pcap_open_dead        (/usr/local/lib/libpfring.so.1)
undefined symbol: pcap_compile  (/usr/local/lib/libpfring.so.1)
undefined symbol: pcap_freecode (/usr/local/lib/libpfring.so.1)
undefined symbol: bpf_filter    (/usr/local/lib/libpfring.so.1)

Finally I find out I can make it work with this command:
LD_PRELOAD=/usr/local/lib/libpcap.so.1.8.1 ./target/debug/examples/filter
I think we need to load libpcap before set_filter. How can we load libpcap by code?

@spacemeowx2 Hi! Thank you for your contribution. I am dead tired today because I had 2 hours of training. I will review your changes tomorrow, when I have more time. Cheers!

@spacemeowx2 When it comes to loading a pcap library, I think it should be delayed as long as possible. Many users may not need to perform filtering and it is pointless to use to much resources when not needed. You are right - the best place to do it is probably in the set_filter() function. My guess would be that you need to add it to the Library instance:
pcap: Mutex<Option<dlopen::raw::Library>>

and add a prefetch_pcap() function :
pub (crate) fn prefetch_pcap(&self){}

Then call prefetch_pcap() from set_filter()
I haven't tested it though and I am curious if it is possible to load pcap library in this way...

Ok, I'll fix it by myself.

@szymonwieloch After many attempts, I found that calling dlopen with RTLD_GLOBAL | RTLD_LAZY or RTLD_LOCAL | RTLD_NOW allows pcap to be loaded and used by pfring. However, dlopen crate uses the flag RTLD_LOCAL | RTLD_LAZY and cannot be changed at runtime.
I guess I will leave this problem to you to solve.

It seems that set_filter not support in version 0.3.0, maybe the new interface is not merged in the release crate?


Don't try to add jsonapi_serialize as helper unless it's possible to do so

Description
From: https://github.com/plataformatec/devise/pull/3732

Currently Devise::Controllers::Helpers depends on #helper_method, which is defined inside AbstractController::Helpers. This module is included in ActionController::Base, but it is not included by default in ActionController::Metal.

#helper_method is not essential to the functionality of the methods inside Devise::Controllers::Helpers, so this PR wraps all Devise #helper_method calls with respond_to?(:helper_method) checks.

This console output elucidates the issue:
[14] pry(main)> ActionController::Base.ancestors.map(&:to_s).grep(/Helpers/)
=> ["ActionDispatch::Routing::RouteSet::MountedHelpers", "ActionController::Helpers", "AbstractController::Helpers"]
[15] pry(main)> ApplicationController.ancestors.map(&:to_s).grep(/Helpers/)
=> ["ActionDispatch::Routing::RouteSet::MountedHelpers"]

@tiagopog updated with description

Good one, @mecampbellsoup 👍


Cleaning up makefiles.

Checklist

[x] Math issue #954

[x] Copyright holder: Generable
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[x] the code base is stable

[x] the changes are maintainable

[x] the changes are tested

[x] the changes adhere to the Math library's C++ standards

Summary
This pull request simplifies the build and gets the makefiles in order. The makefiles got tangled up through a few recent changes. It also allows the builds to be more extensible in the Math library.
Here are some of the highlights:

CXX is the only compiler setting used. In develop, both CXX and CC have to be set

Windows: removed the uname: not found message

CXXFLAGS are now broken into smaller components that can be set by the user:

CXXFLAGS_LANG for language-specific flags
CXXFLAGS_WARNINGS for ignoring warnings
CXXFLAGS_BOOST for boost-specific flags
CXXFLAGS_SUNDIALS for sundials-specific flags
CXXFLAGS_EIGEN for eigen-specific flags
CXXFLAGS_GTEST for google-test-specific flags
CXXFLAGS_OS for a catch-all and any os-specific flags.

CPPFLAGS are broken into components (CPPFLAGS are the C preprocessor flags):

CPPFLAGS_BOOST for boost-specific flags
CPPFLAGS_SUNDIALS for sundials-specific flags
CPPFLAGS_EIGEN for eigen-specific flags
CPPFLAGS_GTEST for google-test-specific flags
CPPFLAGS_OPENCL for opencl

breaking apart the flags this way makes it clearer how to extend the flags for MPI and GPU.

each of the flags can be set within make/local and it will take precedence over the default values

the dependency generation now generates with dummy targets for each file. This means more robustness in that -- this fixes problems where a header file is removed from the source tree. This caused a lot of trouble with stability of make.

it also cuts the size of the makefiles in roughly half (while having all the same behavior)

Tests
Run tests from a clean checkout without setting anything in make/local
By that, I mean:

A few unit tests. This should test enough things:

./runTests.py test/unit/math_include_test.cpp test/unit/multiple_translation_units_test.cpp test/unit/math/rev/mat/functor/cvodes_ode_data_rev_test.cpp test/unit/math/rev/mat/functor/map_rect_mpi_test.cpp test/unit/math/gpu/opencl_context_test.cpp

Check that test-headers works. If you're impatient:

make stan/math/prim/scal/fun/abs.hpp-test

Check that one of the prob tests work. This will not work on Windows.

./runTests.py test/prob/normal/normal_00000_generated_v_test.cpp

Side Effects
The upstream tests will fail: both Stan and CmdStan rely on these makefiles. I will update those appropriately, but after we're ok with the proposed changes here.
Before merging, we need to update the Math wiki for building with MPI and GPU because flags would have changed.
Additional Notes
Thanks to everyone helping out!
Final TODOs

[ ] Update math wiki / doc with instructions on build
[x] Update stan-dev/stan repo with new build. There's an open PR stan-dev/stan#2601.
[ ] Update stan wiki / doc with instructions on build
[ ] Update stan-dev/cmdstan repo with new build
[ ] Update cmdstan wiki / doc with instructions on build

Just found out that the updates to the dependency generation makes the build process a little faster! (Just a little, but I'll take it.)

For anyone tracking this, can you help me check it again? I've made some more changes.
@wds15, thank you for looking at it in depth. That was helpful.

The GPU stuff succesfully builds and passes all tests on both Ubuntu and Windows.
I now tried the 2. and 3. in the "Testing" and neither work on Windows.
For the test-headers I get the following:
 make stan/math/prim/scal/fun/abs.hpp-test
make/tests:30: no file name for `-include'
g++ -std=c++1y -Wno-unused-but-set-variable -Wno-unused-variable -m64 -Wall -Wno-unused-function -Wno-uninitialized   -I lib/opencl_1.2.8  -O3 -I . -I lib/eigen_3.3.3 -I lib/boost_1.66.0 -I lib/sundials_3.1.0/include    -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION  -DSTAN_OPENCL -DOPENCL_DEVICE_ID=0 -DOPENCL_PLATFORM_ID=1   -c -O0 -include stan/math/prim/scal/fun/abs.hpp test/dummy.cpp -o nul

So this actually looks ok, apart from the "no file name" in the first line.
For the prob tests I get the following:
python ./runTests.py test/prob/normal/normal_00000_generated_v_test.cpp
------------------------------------------------------------
make -j1 generate-tests -s
make/tests:30: no file name for `-include'
make: *** No rule to make target `test/prob/bernoulli/bernoulli_ccdf_log_00000_generated_v_test.cpp', needed by `generate-tests'.  Stop.
make -j1 generate-tests -s failed

Thank you!
Arg. It looks like the dependency is not being generated properly. That
gives me a lot of info, though!
On Mon, Jul 30, 2018 at 11:43 AM Rok Češnovar<EMAIL_ADDRESS>wrote:

The GPU stuff succesfully builds and passes all tests on both Ubuntu and
Windows.
I now tried the 2. and 3. in the "Testing" and neither work on Windows.
For the test-headers I get the following:
make stan/math/prim/scal/fun/abs.hpp-test
make/tests:30: no file name for `-include'
g++ -std=c++1y -Wno-unused-but-set-variable -Wno-unused-variable -m64 -Wall -Wno-unused-function -Wno-uninitialized   -I lib/opencl_1.2.8  -O3 -I . -I lib/eigen_3.3.3 -I lib/boost_1.66.0 -I lib/sundials_3.1.0/include    -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION  -DSTAN_OPENCL -DOPENCL_DEVICE_ID=0 -DOPENCL_PLATFORM_ID=1   -c -O0 -include stan/math/prim/scal/fun/abs.hpp test/dummy.cpp -o nul
So this actually looks ok, apart from the "no file name" in the first line.
For the prob tests I get the following:
python ./runTests.py test/prob/normal/normal_00000_generated_v_test.cpp
make -j1 generate-tests -s
make/tests:30: no file name for -include' make: *** No rule to make target test/prob/bernoulli/bernoulli_ccdf_log_00000_generated_v_test.cpp', needed by `generate-tests'.  Stop.
make -j1 generate-tests -s failed
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-408909669, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_FypEukTBlW1GX64KyRAfcqqwuZtgks5uLyl0gaJpZM4Vk2Sm
.

Thanks! Do we need all the CXXFLAGS for the C build? That's the part that's
the most dubious for me. I'll update it either way, but it would help to
know that.
On Mon, Jul 30, 2018 at 12:52 PM wds15<EMAIL_ADDRESS>wrote:

@wds15 commented on this pull request.
In make/libraries
https://github.com/stan-dev/math/pull/956#discussion_r206245292:

-STAN_CVODES_HEADERS := $(shell find stan -name cvodes.hpp)
-$(STAN_CVODES_HEADERS) : $(LIBSUNDIALS)
+STAN_SUNDIALS_HEADERS := $(shell find stan -name cvodes.hpp) $(shell find stan -name idas.hpp)
It does compile, but all those extra flags we set are being ignored,
because we setup the C++ compiler and not the C compiler. So in order:

It compiles, but only with the vanilla C compiler. None of our
additional flags are set. Thus things will probably fail on windows 32 or
64 bit, because this stuff is setup for the C++ compiler - not the C
compiler.
2.
Not sure what you mean. Do you refer to CXXFLAGS_SUNDIALS? Those will
probably be only needed for the sundials build, yes. Maybe we rename this
to CFLAGS_SUNDIALS? It's C after all.
3.
The clean way is to use COMPILE.c as you did it... but we are
carefully configuring the C++ compiler! It is easier for us to use the
COMPILE.cxx with the -x c flag. The super clean way is (I think) to
also setup carefully the C compiler (just as the C++ compiler) and then use
COMPILE.c. The thing is that the -x c stuff is supported by gcc and
clang (and I think Intel as well), but I am not aware of that this is
commonly agreed on standard. So the -x c seems to be a pragmatic
solution here instead of setting up C++ and a C compiler.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#discussion_r206245292, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F_qyLHC6E4JbkDpup9a_4FzwIdRaks5uLznFgaJpZM4Vk2Sm
.

I'd say all the flags which are language independent need to go to CFLAGS and CXXFLAGS (pthread, the -m32 thing). You could abuse the CPPFLAGS as this one is passed to the C and the C++ compiler.
Note, that with this setup the user has to specify CC and CXX in make/local. I don't see a way around that.
Disclaimer: I am suggesting what I think is sound, but I don't have some doc I could point you to which can be considered as a reference.

Here's what I don't understand... why do the flags need to be the same? It's a library that's linked. There's no requirement that the same compiler be used, let alone the same settings. The only thing that's required is that it's ABI compatible, right?
So... do we need to force these to be the same? What do we gain by doing that? What do we lose? I don't think the flags you mentioned matter: pthread and m32. If we're using the C compiler, that does its own thing, right?

Ah. pthread may not be needed, ok, but I would expect that the m32 / m64 is needed. Otherwise the bitness of the code is potentially messed up on windows.

Yes, I think you're right. I think m32 / m64 is needed, but I haven't
checked. I'll update it anyway.
On Mon, Jul 30, 2018 at 3:52 PM wds15<EMAIL_ADDRESS>wrote:

Ah. pthread may not be needed, ok, but I would expect that the m32 / m64
is needed. Otherwise the bitness of the code is potentially messed up on
windows.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-408988496, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_FwBSgogR3iZLzr2mTRV-_UTHb817ks5uL2PmgaJpZM4Vk2Sm
.

I ran into a problem trying to just use the COMPILE.cpp macro. It includes the -std=c++1y flag, which kills the build.

found a workaround.

@rok-cesnovar, thank you! I learned even more craziness about make. A few things to note:

make on Windows is at v2.79
we can't have a directive in the makefile that's -include without a filename following it. It works everywhere else.
this version can't do secondary expansions. The way we build our current distribution tests won't work. That's won't block this, but it won't allow us to do the last test.

Anyway, I think I've gotten enough of the key features done so that this will work with Math. I'm going to update the top-level comment and work on Stan and CmdStan to match this.

Glad I could help!

Thanks! Sorry, I was too quick and staring at the too long. Yes, it should
all be cxx. I'll switch that (or if you have access, please do).
On Tue, Jul 31, 2018 at 3:01 AM wds15<EMAIL_ADDRESS>wrote:

@wds15 requested changes on this pull request.
just some remaining sundials things to sort out, I think.
In make/compiler_flags
https://github.com/stan-dev/math/pull/956#discussion_r206413244:

endif

MPI_TARGETS ?= $(addsuffix $(BOOST_LIBRARY_SUFFIX),$(BOOST)/stage/lib/libboost_serialization $(BOOST)/stage/lib/libboost_mpi) $(MPI_TEMPLATE_INSTANTIATION)
CPPFLAGS_MPI ?= -DSTAN_MPI

BOOST_LIBRARY_ABSOLUTE_PATH = $(abspath $(BOOST)/stage/lib)

LDLIBS_MPI ?= -Wl,-lboost_mpi -Wl,-lboost_serialization -Wl,-L,"$(BOOST_LIBRARY_ABSOLUTE_PATH)" -Wl,-rpath,"$(BOOST_LIBRARY_ABSOLUTE_PATH)"

+endif
+
+
+
+CXXFLAGS += $(CXXFLAGS_LANG) $(CXXFLAGS_OS) $(CXXFLAGS_WARNINGS) $(CXXFLAGS_BOOST) $(CXXFLAGS_EIGEN) $(CXXFLAGS_OPENCL) $(CXXFLAGS_MPI) -O$(O) $(INC)
+CPPFLAGS += $(CPPFLAGS_LANG) $(CPPFLAGS_OS) $(CPPFLAGS_WARNINGS) $(CPPFLAGS_BOOST) $(CPPFLAGS_EIGEN) $(CPPFLAGS_OPENCL) $(CPPFLAGS_MPI)
+CFLAGS += $(CFLAGS_SUNDIALS)
Is it now CFLAGS_SUNDIALS or ...
In make/libraries
https://github.com/stan-dev/math/pull/956#discussion_r206413381:

$(sort $(SUNDIALS_CVODES) $(SUNDIALS_IDAS) $(SUNDIALS_NVECSERIAL)) : %.o : %.c
@mkdir -p $(dir $@)

$(COMPILE.c) -x c -O$(O) -include $(SUNDIALS)/include/stan_sundials_printf_override.hpp -isystem $(SUNDIALS)/include $< -o $@

$(COMPILE.cpp) -x c -include $(SUNDIALS)/include/stan_sundials_printf_override.hpp $< $(OUTPUT_OPTION)

... CXXFLAGS_SUNDIALS. Looks to me you went with CXX.
In makefile
https://github.com/stan-dev/math/pull/956#discussion_r206413575:

@echo '  - GTEST                       ' $(GTEST)

@echo '  - OPENCL                      ' $(OPENCL)

@echo '  - STAN_OPENCL                 ' $(STAN_OPENCL)
@echo '  - STAN_MPI                    ' $(STAN_MPI)
@echo '  Compiler flags (each can be overriden separately):'
@echo '  - CXXFLAGS_LANG               ' $(CXXFLAGS_LANG)
@echo '  - CXXFLAGS_WARNINGS           ' $(CXXFLAGS_WARNINGS)
@echo '  - CXXFLAGS_BOOST              ' $(CXXFLAGS_BOOST)
@echo '  - CXXFLAGS_EIGEN              ' $(CXXFLAGS_EIGEN)
@echo '  - CXXFLAGS_OS                 ' $(CXXFLAGS_OS)
@echo '  - CXXFLAGS_GTEST              ' $(CXXFLAGS_GTEST)
@echo '  - CXXFLAGS_OPENCL             ' $(CXXFLAGS_OPENCL)
@echo '  - CXXFLAGS_MPI                ' $(CXXFLAGS_MPI)
@echo '  - CFLAGS_SUNDIALS             ' $(CFLAGS_SUNDIALS)

again.. C or CXX?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#pullrequestreview-141821727,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F5JZRIfZedlKt6zWe7V9oNmUs73cks5uMACogaJpZM4Vk2Sm
.

looks like there are a number of more changes... where do you think are we now, @syclik ? Do I need to review again? Right now I would probably dismiss my last review as it I am not sure if that was complete enough.
The makefiles need this update, so I am just wondering how we can make this PR earlier in rather than later.
Yet, I have to say that it would be good if others look into this as. I don't consider myself as makefile guru.

@wds15 or anyone else tracking this PR, mind checking if it still works on your configuration? I had to make updates in order to get it to play nicely with Stan.
No worries if you don't get to it immediately. I might have to make minor adjustments to deal with CmdStan.

P.S. no one should consider themselves a makefile guru. The tricky thing isn't actually make; the tricky part is actually understanding the C++ compiler and how it generates dependencies.

hey all, after some more struggling, I have it all working! It passes Jenkins fully! Can anyone who's tracking this issue take a look to see if their normal workflow works in Math? (There will be similar requests in Stan and CmdStan.)
cc: @rok-cesnovar @wds15 @yizhang-cae @seantalts
If no one finds an issue, I can start working on the documentation so it's ready before we merge.

Looks good, things I noticed:

CC is no longer how we set the default compiler; now we use CXX
Now whenever I run a make clean-all, much less stuff is printed (like it doesn't say that it's cleaning out lib)
And after that, I see dependency files (the *.d files) being generated when I didn't before. They get regenerated if I make clean or make clean-all but not otherwise.

All seems to work for me. Was just testing GPU stuff on a mac.

I will try the new makefiles out to compile MPI binaries on our cluster... which are a hard case since outdated boost libraries in in the system path's which make it rather hard to get it right.

On Windows I had to change the -M flag to -MM. Before that it kept compiling the test over and over to no end. Do not ask me why this works tho :) I saw that it started occuring with this commit so I played around a bit.
The good news is that after that change everything works fine on Windows (1. and 2. from the first post above) as well as all the GPU tests.

I experienced the looping test behavior when I modified my make/local to be:
export CXX=clang

Adding -MM to make/dependencies did not fix the issue.
Is there a way to control the optimization level? When I'm writing tests I turn off the optimizations a lot so the debuggers work better. The line I tried was export CXXFLAGS_LANG=-g.
Is there any way to control linker flags?
When I make clean/make, it seems to rebuild Sundials. Is there a huge reason to make clean and clean-all separate? Sundials doesn't take that long to build.

The looping thing sounds bad, not sure how that works... but I can help with the other two!
in make/local:
O=0
CXXFLAGS+=-g

make/local is a makefile, not a bash script - does export mean something in makefile language too?
There are linker flags in e.g. LDFLAGS (if we're still using the standard ones for Stan stuff): https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

does export mean something in makefile language too?

Lol, definitely my mistake. I just saw a blank file and typed things in without really thinking. But it did switch to clang.
Maybe the doc for how to use make/local should go in comments in make/local?

And what does In develop, both CXX and CC have to be set mean?

Thanks, all, for checking! Sorry, responding on my phone and it's hard to
directly quote, so I'll just respond the best I can (in the order of
comments).
@seantalts: yes, CC is no longer used! We're now all consistent with the
use of CXX. If that wasn't in the top-level comment, that's an oversight
and I'll put a note there. (this helps because setting CC instead of CXX
has prevented us from using some of the default rules)
I'll update the clean targets. Do you want messages saying what it's
cleaning? I think that'd be useful and if that's what you think is natural,
that sounds good.
Yes, dependency files are in. That's what'll help keep our rebuild times
low from here on now! If you would rather the files aren't included next to
the source, we can move them to a different directory. I think a natural
place is in test (the place where we build targets, but of course it moves
it far from the header that it's supposed to go with). But this is about
making it easier for the user. If you think it's too cluttered, I can
implement and you can let me know if that's good.
@wds15, thanks. I copied your change from the latest PR. Would you do me a
favor? Can you paste the exact compiler invocation you use to build an
executable or rest with it's dependencies? Right now, develop on CmdStan
doesn't build MPI on my Mac, so I don't actually trust that the compiler
call is right. It'd just help to know what you pass as compiler and linker
flags.
@rok-cesnovar: argh. Thanks! And I'll look into it. I went back and forth
for some reason that I don't remember. At the worst case, we'll need to
conditionally use M vs MM based on OS. What version of make and g++ are you
using? (make -v, g++ -v) The loop has to be coming from make. I'm not sure
what's different in the file generated from the -M vs -MM that could cause
it to loop. What ends up happening is that the .d file is generated using
the compiler with those flags. Make then includes that file. Inside the
file are all the dependencies of the targets. That's how make knows what it
needs to rebuild, but it uses timestamp to understand which has been
updated. I'll dig on the Windows box when I have a chance.
@bbbales2: you want CXX=clang++, not clang. I don't know what the export
does in make. I think if you use the C compiler, it may not recognize all
the compiler flags. I've seen that with gcc and also with g++ -x c.
Optimization level is easy! O=X.
Linker flags also easy. LDFLAGS is what you're looking for. I haven't
doc'ed everything yet, but check out make/compiler_options. There's a bunch
of split out LDFLAGS_* that should make it easy to overwrite different
flags for different parts of the build. You don't want to overwrite LDFLAGS
wholesale in the way this PR works. We could change that, but I felt that
wasn't quite natural. When you're good and know you want to whack all the
LDFLAGS, you should be able to do it. Btw, LDFLAGS is different than LDLIBS
and CPPFLAGS and CXXFLAGS.
make clean should definitely not rebuild Sundials. Can you send over
exactly what you did and I'll dig?
@seantalts: thanks for responding to @bbbales2.
@bbbales2: the remaining items is to redo the doc. That last comment is no
longer correct. I think where it needs to be doc'ed: wiki (old one lives,
but we state that with develop as of hash XYZ in 2.18.0++, there are new
directions) and the user guide, if it still is in there. And the same for
the other two repos.
On Wed, Aug 22, 2018 at 4:14 AM Ben Bales<EMAIL_ADDRESS>wrote:

And what does In develop, both CXX and CC have to be set mean?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-414950435, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F-S9dhTcGb_rw5-ugIKfHIai72ozks5uTRLFgaJpZM4Vk2Sm
.

@bbbales2, I meant that on develop now, in order to use a different compiler, you actually have to set both CC and CXX. With this PR, we only need to set CXX.

@syclik clang++ doesn't fix the issues in math. I get the same looping output:
~/cmdstan-make/stan/lib/stan_math$ ./runTests.py test/unit/math/rev/arr/fun/sum_test.cpp
------------------------------------------------------------
make -j1 test/unit/math/rev/arr/fun/sum_test
clang++ -std=c++11 -stdlib=libc++ -std=c++1y -Wno-sign-compare      -O3  -I . -I lib/eigen_3.3.3 -I lib/boost_1.66.0 -I lib/sundials_3.1.0/include -I lib/gtest_1.7.0/include -I lib/gtest_1.7.0     -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION    -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0  -c -MT test/unit/math/rev/arr/fun/sum_test.o -MT test/unit/math/rev/arr/fun/sum_test.d -M -MG -MP -MF test/unit/math/rev/arr/fun/sum_test.d test/unit/math/rev/arr/fun/sum_test.cpp
clang++ -std=c++11 -stdlib=libc++ -std=c++1y -Wno-sign-compare      -O3  -I . -I lib/eigen_3.3.3 -I lib/boost_1.66.0 -I lib/sundials_3.1.0/include -I lib/gtest_1.7.0/include -I lib/gtest_1.7.0     -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION    -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0  -c -MT test/unit/math/rev/arr/fun/sum_test.o -MT test/unit/math/rev/arr/fun/sum_test.d -M -MG -MP -MF test/unit/math/rev/arr/fun/sum_test.d test/unit/math/rev/arr/fun/sum_test.cpp
clang++ -std=c++11 -stdlib=libc++ -std=c++1y -Wno-sign-compare      -O3  -I . -I lib/eigen_3.3.3 -I lib/boost_1.66.0 -I lib/sundials_3.1.0/include -I lib/gtest_1.7.0/include -I lib/gtest_1.7.0     -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION    -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0  -c -MT test/unit/math/rev/arr/fun/sum_test.o -MT test/unit/math/rev/arr/fun/sum_test.d -M -MG -MP -MF test/unit/math/rev/arr/fun/sum_test.d test/unit/math/rev/arr/fun/sum_test.cpp
clang++ -std=c++11 -stdlib=libc++ -std=c++1y -Wno-sign-compare      -O3  -I . -I lib/eigen_3.3.3 -I lib/boost_1.66.0 -I lib/sundials_3.1.0/include -I lib/gtest_1.7.0/include -I lib/gtest_1.7.0     -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION    -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0  -c -MT test/unit/math/rev/arr/fun/sum_test.o -MT test/unit/math/rev/arr/fun/sum_test.d -M -MG -MP -MF test/unit/math/rev/arr/fun/sum_test.d test/unit/math/rev/arr/fun/sum_test.cpp

This is the setup on the windows machine:
make 3.79.1
g++ 4.9.3
I dont really update the Windows toolchain much, I use my Windows boot mainly to test if my code works on Windows.
Here are the generated .d files in both cases. Hope this helps.
Fails with loop  math_include_test_fail.d.txt
Works fine:
math_include_test.d.txt
Let me know if I can help with any other details.

Oh, and I forgot. GPU tests on Ubuntu all build & pass.

@bbbales2, quick check again? I reverted the change I made... I don't even remember why it doesn't follow the doc any more (based on what I wrote as a comment). If it doesn't work, can you get me a login? It'll be a lot easier to debug on a system that's already configured.

@rok-cesnovar, thanks! I keep forgetting that Windows is on make 3.79.

@bbbales2, thanks for flexing the makefiles. You've got configuration issues on that machine, my friend. That said, it was a good use case to debug.
Try this:
echo CXX=clang++ > make/local
echo LDFLAGS_OS= >> make/local

Then try what you need.
The problem you have is that your version of clang++ isn't compatible with -stdlib=libc++ on that machine. Fun, right? I put the -stdlib=libc++, which should be the right default for clang++, in the LDFLAGS_OS variable, so by setting it to empty explicitly in make/local, you're able to control it. Every other compiler flag is ok on that machine.

@syclik : I just learned that we can let boost build hard-code the dll paths by invoking it like this:
cd $(BOOST); ./b2 --user-config=user-config.jam --layout=system --with-mpi --with-serialization -j$(BOOST_PARALLEL_JOBS) variant=release link=shared threading=multi runtime-link=shared hardcode-dll-paths=true dll-path="$(BOOST_LIBRARY_ABSOLUTE_PATH)"

Maybe that makes even the install_* calls obsolete on Mac, I don't know yet - need to find out later today.
In any case, the above change is a good one for Linux as then libboost_mpi.so has hard-coded ties to the serialization library which makes it more safe to use.
Do you want me to push that change to the branch?

@wds15, mind opening up an issue describing what the problem you're trying
to solve is? If you push to the branch, can you reference that issue so we
can keep a record that it was addressed somehow? It'd be great to have a
clean description of what we're trying to solve (I still don't understand
the issue with hard-coded vs not).
If that change is made, will it work for: Linux, windows, Mac x math, Stan,
CmdStan x MPI, GPU. This stuff is tricky and non-obvious, as you already
know. (Btw, I'm testing a lot of those configurations by hand for Mac and
Windows. Our testing doesn't have things like checking for when
dependencies are updated.) If it's sufficiently complicated, it makes sense
to treat it separately. If it's not, then we can roll it in.
On Thu, Aug 23, 2018 at 8:02 AM wds15<EMAIL_ADDRESS>wrote:

@syclik https://github.com/syclik : I just learned that we can let
boost build hard-code the dll paths by invoking it like this:
cd $(BOOST); ./b2 --user-config=user-config.jam --layout=system --with-mpi --with-serialization -j$(BOOST_PARALLEL_JOBS) variant=release link=shared threading=multi runtime-link=shared hardcode-dll-paths=true dll-path="$(BOOST_LIBRARY_ABSOLUTE_PATH)"
Maybe that makes even the install_* calls obsolete on Mac, I don't know
yet - need to find out later today.
In any case, the above change is a good one for Linux as then
libboost_mpi.so has hard-coded ties to the serialization library which
makes it more safe to use.
Do you want me to push that change to the branch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-415390168, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_Fy1rj2rQ0hoOqA1TqrNpK5Q9IEn1ks5uTpm9gaJpZM4Vk2Sm
.

Ok. See #1002 and the PR going along with it. The change I am proposing makes things safer to use. Right now everything works, because we provide the -rpath argument. With this change the dll's from boost are themselves build with rpath so that they are safer to use to my understanding.

I am happy to look at this and do a test-drive for MPI stuff (which is usually a good torture of the thing). If that runs fine I am happy to approve, but probably someone else should have an eye on this. I have never dealt with this dependency generation thing of gcc/make, for example.

Wow. Can you try something quick? Type:
make print-RM
The doc says that it always includes an -rf flag. But maybe not on your
version.
On Mon, Sep 10, 2018 at 2:26 PM wds15<EMAIL_ADDRESS>wrote:

I am starting to go through this and the first make clean-all results in
the error:
rm: lib/boost_1.66.0/stage/lib: is a directory
rm: lib/boost_1.66.0/bin.v2: is a directory
rm: lib/boost_1.66.0/tools/build/src/engine/bootstrap/: is a directory
rm: lib/boost_1.66.0/tools/build/src/engine/bin.macosxx86_64: is a directory
make: *** [clean-mpi] Error 1
I do have MPI enabled... the rm command does not have a -rf option which
makes it fail for these directories. I will continue anyways...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-420012836, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F27Xu8NPdG33tbArTeREELjbz0Ppks5uZq6ygaJpZM4Vk2Sm
.

Not on my version, yes:
[20:28:23][sebi@sebastians-macbook-pro-1:~/work/math]$ make print-RM
RM = rm -f
[20:28:37][sebi@sebastians-macbook-pro-1:~/work/math]$ which make
/usr/bin/make
[20:29:15][sebi@sebastians-macbook-pro-1:~/work/math]$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin11.3.0

This is a standard macOS High Sierra

+1 for having the print trick in our makefiles now. I kept adding and deleting this thing. Super convenient.

Thanks. I'll fix that problem. I won't get to the rest until later this
week.
On Mon, Sep 10, 2018 at 2:33 PM wds15<EMAIL_ADDRESS>wrote:

+1 for having the print trick in our makefiles now. I kept adding and
deleting this thing. Super convenient.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-420015300, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_FyLe0OzF_lknvJ9gS83-9doB-Duiks5uZrB7gaJpZM4Vk2Sm
.

Is it possible to make the printout of the help in such a way modular so that you do not need to repeat that code in stan-math/stan/cmdstan? Unless there is a good reason to keep it separate, fine; but it looks to me like a future source of inconsistencies. Just a thought (I hope it is easy to add this modularity).

@wds15, thanks for the suggestion! I didn't think of that earlier. I pulled it out so it's handled at the math level.

I was wrong about the RM flags. It uses -f by default, but not -r.

Ok. I think it's really ready to go this time.

Alright I went to double check this pull this morning (math/makefiles if you're reading via e-mail).
I checked that the -stdlibc++ stuff was still there, and was about to begrudgingly accept that clang just wasn't going to work for me and it was misconfigured on my OS, but then I Googled libc++ vs libstdc++ and got this: https://libcxx.llvm.org/
This says libc++ is the clang library. Why are we trying to link it to the gnu library?

Yup. It should be removed.
I don't know how it was snuck in in the first place. I was just following
what we had.
I'll take care of that in the morning. Thanks!
Anything else?
On Thu, Sep 13, 2018 at 1:42 AM Ben Bales<EMAIL_ADDRESS>wrote:

Alright I went to double check this pull this morning (math/makefiles if
you're reading via e-mail).
I checked that the -stdlibc++ stuff was still there, and was about to
begrudgingly accept that clang just wasn't going to work for me and it was
misconfigured on my OS, but then I Googled libc++ vs libstdc++ and got
this: https://libcxx.llvm.org/
This says libc++ is the clang library. Why are we trying to link it to the
gnu library?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-420890069, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F5YXnBq_t3MZ11WzjhzT9HbuffgYks5uafAhgaJpZM4Vk2Sm
.

Still gotta check the other two. Eating mah breakfast

Cool. I'm gonna sleep.
In case you missed it: the test header has a different target now. Drop the
src/ in front.
On Thu, Sep 13, 2018 at 1:50 AM Ben Bales<EMAIL_ADDRESS>wrote:

Still gotta check the other two. Eating mah breakfast
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-420891456, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F4ojFjeMFHQ-tVlifR0QK2cP7p8qks5uafILgaJpZM4Vk2Sm
.

Oh wow I read this backwards. The way you have it is correct.
I guess I'll just give up using clang++ without futzing with the makefiles. If g++ is the default that's fine. I'd still prefer axing -stdlib=libc++ cause it breaks Ubuntus.
@sakrejda you were among the other people affected by this, do you care?

Let's just talk about this at the meeting. I'll put it on the list.

@bbbales2 I looked into this more on another thread and there's an underlying mess that's bigger than this one flag... It comes down to a (reported) bug that makes the compiler crash if you do things "right" and it's with a glibc version that is on its way out so... it seems like we can hide it whatever way we want until the last glibc version with the bug passes out of the dinosaur distros and then there's an easy and correct fix.

Oh okay, that's nice to know. So defaulting to g++ seems good enough for me then. I guess someone determined to use clang will probably find one of the various discussions on this and can remove the flag or whatnot.

Or wait... Were you saying we should drop the -stdlibc=c++ flag as a fix until this bug disappears?

@bbbales2, I just tried on your machine and it worked. There is probably an
issue with the dependency files being generated from within the Stan
subdirectory and then using those in CmdStan. For the time being, can you
update CmdStan, type: make clean-deps, then try rebuilding bernoulli?
On Thu, Sep 13, 2018 at 6:53 AM Ben Bales<EMAIL_ADDRESS>wrote:

Or wait... Were you saying we should drop the -stdlibc=c++ flag as a
fix until this bug disappears?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-420966656, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F0bym398_B-gYWiTAHAUsBZugKY7ks5uajkDgaJpZM4Vk2Sm
.

I can run tests tests on some linuxes too if it's straightforward, is this just pull and make test?

The math repo is pretty solid now. The issues we're having are at the
language level.
If you don't mind, can you grab CmdStan. Update

CmdStan's branch to: bugfix/issue-639-make
Stan's submodule to branch: bugfix/issue-2593-make
Math's submodule to branch: bugfix/issue-954-make

Make sure everything's clean.
Then from CmdStan, build the example: make examples/bernoulli/bernoulli
(you can add -j8 or whatever to speed it up).
The test we're interested in is if we change something in the parser, will
it propagate? So...
touch stan/src/stan/lang/function_signatures.h
make examples/bernoulli/bernoulli

If that rebuilds bin/stanc, generates a new
examples/bernoulli/bernoulli.hpp, and the compiles the executable, then
we're good. If it fails to do that, then it doesn't work.
Mind running that and seeing if it works?
On Thu, Sep 13, 2018 at 9:00 AM Krzysztof Sakrejda<EMAIL_ADDRESS>wrote:

I can run tests tests on some linuxes too if it's straightforward, is this
just pull and make test?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-420997746, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F-_xJbgWBEfeS4EnK3ufYu-C863zks5ualbfgaJpZM4Vk2Sm
.

To play with clang, you can make a make/local file in any of the repos with the line:
CXX=clang++

Also with the cmdstan testing I touch one of the stan-dev math src files and see if the dependencies work. Something like:
touch stan/lib/stan_math/stan/math/rev/scal.hpp
make examples/bernoulli/bernoulli

Should cause the binary to get built again.

OK, will do today and post here.  Prob end-of-day. K

Anyone want to take a look? @wds15, any other comments?
After this is in, I'm going to try to get everything building on Windows again. @rok-cesnovar had made some great progress. I'm convinced we can get it done soon.

I can confirm that on Windows 1. and 2. work as well as all the GPU tests. The GPU part also works on Ubuntu.
Other than the minor comment I posted, I have no other. But I am far from a makefile expert :)

Yes! We should add that compiler flags.
I'm away from a computer right now. Want to make that change?
The most important thing is that it works on all the platforms we support.
The next thing is asking if it's more functional and maintainable than the
existing. I know most people won't know how to validate that, except maybe
@wds15. Your comment already shows that it's a little easier to navigate
and separate flags!
On Wed, Sep 19, 2018 at 5:01 AM Rok Češnovar<EMAIL_ADDRESS>wrote:

I can confirm that on Windows 1. and 2. work as well as all the GPU tests.
The GPU part also works on Ubuntu.
Other than the minor comment I posted, I have no other. But I am far from
a makefile expert :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-422718004, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F_sdtTrzQWhNL_ltV5evV324Wd9wks5ucgfRgaJpZM4Vk2Sm
.

Sure, I will add it right now. Yeah it definitely is easier to navigate. Thanks!

Interesting. Yes, I am ok with that. As long as we're not linking with the
prebuilt MPI libraries, it's consistent.
But, if you think it's disruptive in some way, we could change it.
On Sat, Sep 22, 2018 at 4:24 AM wds15<EMAIL_ADDRESS>wrote:

Hmm... here is one new behavior which I am not sure on if we want to keep
it. The issue is that MPI binaries are not cleaned when I do this:

put STAN_MPI=true in make/local
build some MPI tests
take STAN_MPI=true out of make/local
make clean-all will then NOT remove the MPI libraries

Cleaning of MPI libraries only happens whenever its turned on. This is a
side-effect of if-defing out all of the MPI things.
Are we fine with this behavior?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/956#issuecomment-423726938, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F2JSl_UzWEIkBCFmN83u5zqUNHhHks5udfOtgaJpZM4Vk2Sm
.

Ok. Then this can go in from my end. Thanks... this was a lot of work.
@rok-cesnovar ... are u good?

All good on my end! Thanks @syclik


Multi-level co-signing transfer transaction is unsuccessful

Scenario：2-level multisig account

4-of-4 multisignature account  （multisig account：M    cosigners：A、B、C、D）
1-of-1 multisignature account  （multisig account：D     cosigner：E）

steps：

A initiates a transfer transaction for M.
B and C both completed signing normally.
D can see the partial transactions of the M account, after entering the password to confirm, there is no feedback and the signing is not successful.
E can't view M's partial transaction, nor sign.
This transfer transaction was unsuccessful.

Nice catch!
This issue is on the SDK side
https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/417


Subject: Issue with Changing Password for OAuth2 Accounts

Hello PocketBase Team,
I hope this message finds you well. I am encountering an issue with my application and I wanted to bring it to your attention.
When attempting to change the password for a user who has logged in via an OAuth2 provider (such as Google or GitHub), I receive an error, as shown in the attached screenshot. The root of the problem seems to be that, since the OAuth2 account does not have a password saved in the database, the application cannot update it.
I am looking to provide an option for users to switch from OAuth2 login to a password-based login. However, this functionality is currently blocked due to the issue above.
I hope this explanation is clear, and I appreciate your attention to this matter. I appreciate your support.
Best regards,
Hugo Abdou
Please feel free to adjust any personal details or specificities you need.

Please see https://github.com/pocketbase/pocketbase/discussions/5068.

I also forgot to mention that an alternative if the user has an email is to send a password reset request.

@ganigeorgiev  thank you it seams like this how i should do it


Test files require update to accommodate recent changes

Recreate the test files

This is addressed by PR #78


Resource temporarily unavailable

Bug Description
From time to time, our users are seeing this error.

Steps to Reproduce
run mirrord to connect to a service
Backtrace
No response
Relevant Logs
io failed: Resource temporarily unavailable (os error 35)
Assertion failed: (!"unknown EAI_* error code"), function uv__getaddrinfo_translate_error, file getaddrinfo.c, line 90.

### Your operating system and version

Mac OS

### Local process

running yarn process

### Local process version

_No response_

### Additional Info

_No response_

@trs can add more context here if requested

Is the remote pod restarted in this case?

@trs could you please help us debugging this issue?

I don't believe it is

@trs Does it still happen? Is there something you do that helps you reproduce it?

Hi @trs - we need more information to investigate this


Add missing def_delegator for constructor_inputs

constructor_inputs when creating a contract from_file was missing.
We should probably enable passing constructor params with something like this:
    def encode_constructor_params(contract, args)
      types = contract.constructor_inputs.map { |input| input.type }
      Util.bin_to_hex(Eth::Abi.encode(types, args))
    end

as well, and appending it to data in deploy and transact.
Be happy to extend this PR if that's a direction we'd want to go.

Be happy to extend this PR if that's a direction we'd want to go.

Please do if you are on it already! :)

Codecov Report

Merging #96 (41f5838) into main (854a7bc) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #96      +/-   ##
==========================================
- Coverage   99.73%   99.71%   -0.03%
==========================================
  Files          67       67
  Lines        3801     3802       +1
==========================================
  Hits         3791     3791
- Misses         10       11       +1

Impacted Files
Coverage Δ

lib/eth/contract.rb
100.00% <100.00%> (ø)

lib/eth/client/ipc.rb
93.33% <0.00%> (-6.67%)
:arrow_down:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Bivariate mapping not working as a recipe

This needs add SimpleSDMLayers#interfaces-iteration to work
@mkborregaard, following your advice in #120, I tried to put the bivariate plot to a recipe. When I do this, it "works" (I get no error message), but the plot is what you get when only calling plot().
Any idea? Can it be because there is a plot(x, y) method for two layers already defined?
using Plots
using RecipesBase
using SimpleSDMLayers
using Colors, ColorBlendModes

layer1, layer2 = SimpleSDMPredictor(WorldClim, BioClim, [1,12]; left=-20.0, right=55.0, top=42.0, bottom=-36.0)

q1 = rescale(layer1, collect(LinRange(0.0, 1.0, 25)))
q2 = rescale(layer2, collect(LinRange(0.0, 1.0, 25)))

@shorthands bivariate

@recipe function f(::Type{Val{:bivariate}}, plt::AbstractPlot; classes=3, p0=colorant"#e8e8e8", p1=colorant"#64acbe", p2=colorant"#c85a5a")

    # Get the palettes
    c1 = palette([p0, p1], classes)
    c2 = palette([p0, p2], classes)
    breakpoints = LinRange(0.0, 1.0, classes+1)

    xlims --> extrema(longitudes(x))
    ylims--> extrema(latitudes(x))
    legend --> false
    aspectratio --> 1
    frame --> :box
    subplot --> 1
    seriestype --> :heatmap

    for i in 2:length(breakpoints)
        m1 = broadcast(v -> breakpoints[i - 1] <= v <= breakpoints[i], x)
        for j in 2:length(breakpoints)
            m2 = broadcast(v -> breakpoints[j - 1] <= v <= breakpoints[j], y)
            m = reduce(*, [m1, m2])
            replace!(m, false => nothing)
            replace!(m, nothing => NaN)
            @series begin
                color --> BlendMultiply(c1[i - 1], c2[j - 1])
                longitudes(m), latitudes(m), convert(Matrix{Float64}, m.grid)
            end
        end
    end
end

bivariate(q1, q2)

Cool - is that the ifnal recipe?


Can we define minor and major grid lines
with specification like (line color, line thickness, on/off )?

I have following requirement related to grid lines in line char graph -

Define minor and major grid lines
We have to give them specification like line grid line color, line thickness and on/off control
3)Tracing graph lines to provide detailed information
4)Range highlight to provide summary information
5)Set the number of decimal place for scale label

Can you please give the inline comment , what can we achieve or not ?
Kindly help me out
@PhilJay  @danielgindi @liuxuan30, @petester42 and @AlBirdie

first please don't "@" every one. We manage the issues on regular basis as possible as we can.
for the questions, please walk through the code carefully, you will find answer there.
For grid lines, what we support is already coded in ChartAxisBase, like:
    public var gridColor = NSUIColor.grayColor().colorWithAlphaComponent(0.9)
    public var gridLineWidth = CGFloat(0.5)
    public var gridLineDashPhase = CGFloat(0.0)
    public var gridLineDashLengths: [CGFloat]!
    public var gridLineCap = CGLineCap.Butt

Ok sry for tht.
I have put some more features on comment box. Please have a look on it .
BR,
Anurag
Sent from my iPhone

On Mar 9, 2016, at 12:24, Xuan<EMAIL_ADDRESS>wrote:
first please don't "@" every one. We manage the issues on regular basis as possible as we can.
for the questions, please walk through the code carefully, you will find answer there.
For grid lines, what we support is already coded in ChartAxisBase, like:
public var gridColor = NSUIColor.grayColor().colorWithAlphaComponent(0.9)
public var gridLineWidth = CGFloat(0.5)
public var gridLineDashPhase = CGFloat(0.0)
public var gridLineDashLengths: [CGFloat]!
public var gridLineCap = CGLineCap.Butt

—
Reply to this email directly or view it on GitHub.


Revise range of observable:partitionID to be string

This patch implements the Change Proposal attached to Issue 160, except
for providing migration guidance for prior adopters of the property.
https://github.com/ucoProject/UCO/issues/160
Signed-off-by: Alex Nelson<EMAIL_ADDRESS>

I've updated this branch against the current state of develop, checked its diff, and believe it is as ready for merging as it was before the last develop merge.


Merge master into live-based

Docs Build status updates of commit 89bd50d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[CodingStandard] Add tests naming rule

Move here
https://github.com/rectorphp/rector/pull/4114

I've created PR https://github.com/symplify/symplify/pull/2228 for it.


The release should update the website adding the new version

At the moment, the release add the documentation to the website but it doesn't add the new version in the available releases.
Note that the process of adding a new version to the website change slightly when we add a new minor.

Examples of releases file to add to the website  are available in the commit history of the hibernate/hibernate.org project

Closing this for now, in the end I don't think it's worth the additional complexity to the build. Might reopen it later after I've thought more about it


Add separation between the current week and following week

Is it possible to add separation between the current week and following week when the calendar is displayed in weeks? I would like to add some space between the bottom and top of the calendars see attached image with red arrow mark.
"system": {
"show": ["weeks"]

Are, you just put the "space", not "border"... Hmmm.. the html structure is table so It cannot be separated physically. but what you want is giving attentional look to this week, you can add more decoration.
Try this code in your custom.css (not tested but you can get an idea)
.CALEXT  tr.thisweek td {
    border-bottom: 2px solid #FFF
}

Thanks!! the code you recommended works perfectly.


Stop magic tags from being indexed

Content API adds two "magic tags" to artefacts when requesting an artefact over the API. Prevent these tags from ending up in Rummager. These are not tags that the user has chosen, but automatically added things that cause an extra navigation to show up on the page. For reference:
https://github.com/alphagov/govuk_content_api/blob/b74a48dd9c43f56120893e5b2000c1da2c473da0/govuk_content_api.rb#L686-L691
When we initially started indexing links from the content-api, we started inadvertently indexing these tags too. This caused initial problems on the browse pages, which we solved by excluding the format from the browse pages (https://github.com/alphagov/collections/pull/170).
This commit solves the original sin and removes these rogue tags from the search-index at indexing time.
We need this now because we want publishing-api to be in sync with rummager.
https://trello.com/c/UidTGyou

Looks good to me. 👍


Renaming first folder restarts extension host

Issue Type
Bug
Description
Testing #42195
Shouldn't be necessary to restart the extension host when only the name of the first folder changed, should it?
VS Code Info
VS Code version: Code - Insiders 1.20.0-insider (010de7da99e63841dfe5bc5a45ce1509f9fd1479, 2018-01-31T09:45:32.303Z)
OS version: Linux x64 3.13.0-108-generic
Reproduces without extensions

This is actually the same as https://github.com/Microsoft/vscode/issues/42639


Public files without an extension are assumed to be folders

Describe the bug
I'm trying to add an Apple App Site Association to our site. To do this, I'm just adding an apple-app-site-association file under public/.well-known.
This seems to work for vite and vite preview but isn't working when deployed with vite build. I get a 404 when trying to access the file.
I've noticed that adding a .json to the file name fixes the issue, unfortunately this is not an option as Apple specifically says to not do this.
Reproduction
https://github.com/Billzabob/vite-public-bug
Steps to reproduce
Here is the reproduction repo deployed with AWS Amplify:
https://main.d2uxx8kdes6brv.amplifyapp.com/.well-known/apple-app-site-association
Notice that this works, since it ends in .json.
https://main.d2uxx8kdes6brv.amplifyapp.com/.well-known/assetlinks.json
System Info
System:
    OS: macOS 13.5.1
    CPU: (12) arm64 Apple M2 Max
    Memory: 7.48 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.15.0 - ~/.nvm/versions/node/v18.15.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.15.0/bin/yarn
    npm: 9.6.6 - ~/.nvm/versions/node/v18.15.0/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 116.0.5845.187
    Safari: 16.6
  npmPackages:
    @vitejs/plugin-react-swc: ^3.3.2 => 3.3.2
    vite: ^4.4.5 => 4.4.9

Used Package Manager
yarn
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Turns out this was actually an AWS Amplify issue:
https://github.com/aws-amplify/amplify-hosting/issues/1209


v0.0.19-Alpha1 : untrusted publisher

Running a script using the v0.0.19-Alpha1:
Do you want to run software from this untrusted publisher?
File \modules\Transferetto\Transferetto.psm1 is published by CN=Przemysław Kłys EVOTEC, O=Przemysław Kłys EVOTEC, L=Mikołów, C=PL and is not trusted on your system. Only run scripts from trusted publishers.
 Help (default is "D"):

Install-Module Transferetto -Force -AllowPrerelease -Force -SkipPublisherCheck
The certificate is ok. If you have older version of Transferetto installed about 6 months ago I've changed certificate so new updates with this new certificate will trigger this warning.


Linted and fixed(?)

I did various style-related and conventional fixes to the code. Mostly inspired and hinted by JSHint
I also believe I fixed a couple of buggish or non-intuitive lines:

for (var v in array) will iterate over length and other prototypal properties as well, so it should be accompanied by array.hasOwnProperty(v)

expressions like
!array.length < 1

look hackish (though they work) - the negation is 1st applied to the length transforming 0 into true, and 1 into false, then this boolean value is compared to 1
The much clearer form would be
if (a.length) or even if(a)

I also replaced new Array() with literal [] which is the recommended form

Ah, and I forgot to thank you for the module itself - it works, and I extremely didn't want rolling out MySQL for this single project (it looks soooo greedy on my low-end box, and less intuitive)


Styling

styling changes, dark mode toggle added, updates to db, styling changes to calendar component

styling changes, dark mode toggle added, updates to db, styling changes to calendar component


Better import scope marker

resolves #371
The magic comments are replaced with more readable markers.
/*___wenyan_import_<module_name>_start___*/
/*___wenyan_import_<module_name>_end___*/
Also in the IDE

Replaced block with comments to note the code is been hidden.
Make Hide Imported Code checked by default.

Nice! It's great that you have /* ... is hidden */, very thoughtful!
However, could you please make sure that if the imported module also imported a module, the nested structure doesn't confuse the regex? Please correct me if I'm wrong, it seems that your regex doesn't require the start and end comments to match, and could be problematic if one pair of them encloses another?
Or perhaps we can use the regex to just fetch the names of the modules and put them in a Set, and throw away everything before the last end_module comment, and finally put the list of names in its place.
Thanks a lot!

Sure! I just discovered the same. Will have a fix tmr!

It's done! I also add npm scripts ide:dev and site:dev for better development experiences. By running this command, it will auto rebuild every time you make changes. Hope you find it useful.
And sorry I saw you saying not to commit the built ide.html file, but it's already included in some early commits and it's hard to remove it from the history. So I rebuild a latest one I won't include it in the future PRs.

Awesome, thanks a lot!
Don't worry too much about the ide.html file, I can simply delete everything in it when there's a conflict, and rebuild it locally :)


Finish and release frictionless@4 in Python

From our note for the Frictionless Framework users:

please note that<EMAIL_ADDRESS>version's API, we're working on at the moment, is not stable
we will release<EMAIL_ADDRESS>by the end of 2020 to be the first SemVer/stable version

Acceptance

[ ] version 4 of the framework is released

Please preserve this line to notify @lwinfree (lead of this repository)

DONE


spotify api fields int to double type changes

spotify changed the types of fields of some classes

AlbumFull.Popularity has not changed, it should remain as int.


Using the old filetree format gives long file pathes and this is always a pain in Windows

Is there any consideration for moving this to Tonel format?

We have moved to Tonel in the meantime.


Convert app module to Kotlin

I did some minor testing, I found some issues that I haven't solved but I'm pretty sure are not related to the port, rather to recent Android changes:

MainActivity.onItemClick(): File.mkdirs() is not creating any directories even after granting the permission
MainActivity.onStart(): It appears that we're not allowed any more to start services when the app is not in focus (i.e. you launch the app from Android Studio with the phone's screen off)

Other than that I did some additional kotlinization, converted a bunch of stuff to lateinit or vals to improve null safety.

ahh man Kotlin ist just so much nicer :D


Having a "bad LoRA name layer" issue.

Hey. So when I try to generate an image with lora:asianGirlLohaRiriz_v10:1 I get this issue:
activating extra network lora with arguments [<modules.extra_networks.ExtraNetworkParams object at 0x000001A87223C8E0>, <modules.extra_networks.ExtraNetworkParams object at 0x000001A87223C2E0>]: AssertionError
Traceback (most recent call last):
File "C:\AI\stable-diffusion-webui\modules\extra_networks.py", line 75, in activate
extra_network.activate(p, extra_network_args)
File "C:\AI\stable-diffusion-webui\extensions-builtin\Lora\extra_networks_lora.py", line 23, in activate
lora.load_loras(names, multipliers)
File "C:\AI\stable-diffusion-webui\extensions-builtin\Lora\lora.py", line 214, in load_loras
lora = load_lora(name, lora_on_disk.filename)
File "C:\AI\stable-diffusion-webui\extensions-builtin\Lora\lora.py", line 185, in load_lora
assert False, f'Bad Lora layer name: {key_diffusers} - must end in lora_up.weight, lora_down.weight or alpha'
AssertionError: Bad Lora layer name: lora_te_text_model_encoder_layers_0_mlp_fc1.hada_w1_a - must end in lora_up.weight, lora_down.weight or alpha
How can I fix that?
Also, suddenly I started to have broken results with the other LoRAs.
Helps are appreciated. Thank you.

use this extension for lora https://github.com/kohya-ss/sd-webui-additional-networks, it's got better handling of all types

I installed that extension, but still with a  LoHa which is trained on 768px and the default values and proposed network dimensions, over base SD1.5 model, I'm getting this in the Web UI:
LoRas, at least those trained 512px, work fine. So it's something with the LoHa? The training was done with the Dreambooth method, Kohya's trainer.
loading Lora /content/gdrive/MyDrive/sd/stable-diffusion-webui/models/Lora/porcelain3-768-loha.ckpt: AssertionError
Traceback (most recent call last):
  File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/extensions-builtin/Lora/lora.py", line 215, in load_loras
    lora = load_lora(name, lora_on_disk.filename)
  File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/extensions-builtin/Lora/lora.py", line 185, in load_lora
    assert False, f'Bad Lora layer name: {key_diffusers} - must end in lora_up.weight, lora_down.weight or alpha'
AssertionError: Bad Lora layer name: lora_te_text_model_encoder_layers_0_self_attn_k_proj.hada_w1_a - must end in lora_up.weight, lora_down.weight or alpha

https://github.com/KohakuBlueleaf/a1111-sd-webui-lycoris redo with this

i did the steps but the lycoris's extra network won't show.
i installed it then restarted the webui (closed it then opened it again and refreshed stable diffusion) is this how to refresh it or am i doing something wrong?

I had a similar issue with a couple of Lycoris files I downloaded from Civitai. I had just been placing them in the Lora folder and never noticed any messages in the log window.
The ones that gave me a similar error I moved to the Lycoris folder and the message now no longer appears in the log window. I don't know why others work fine in that folder and these particular ones didn't.