nixos/buildbot-master: support reporters, migrate away from status

Since Buildbot 0.9.0, status targets were deprecated and ignored.
There's a very small line on startup explaining that, and status simply
isn't reported. Avoid others the same headaches, and do it right in the
NixOS module.
As there might have been changes in the way reporters are organized, and
configuration might need to be migrated remove the old option, and not
just provide an alias.
Motivation for this change
Things done

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

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

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

Umm, the key is actually called services`. I'll test another configuration here in will get back to it shortly.

So, while this should go into the services key, it's labelled in the docs as "Reporters", so IMHO the attribute should be called reporters too.
If upstream some day decides to put more than Reporters in services, we can still do this transparently, but if we call this services now I'd assume it'd become a mess.
I gave this a spin, and Buildbot successfully picked up the reporter I defined in services, so LGTM.

@GrahamcOfBorg test buildbot

It seems that buildbot does not even build on master:
ERROR: No matching distribution found for botocore<1.17.0,>=1.16.23 (from boto3==1.13.23)
At least this is the error i get when running nix-build nixos/tests/buildbot.nix

That's another failure, which should be covered by the boto* bumps in staging-next.
This PR was based on a previous version of master, and running the tests by checking out this specific commit does work.

That is good enough for me, i trust you :)


Improve the Footer of Chines  Restaurant

Description
Enhance the footer section of Chines Restaurant.
Fixes:  #658

Type of change
Improvement

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[ ] I have made this from my own
[ ] I have taken help from some online resourses
[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

@arpit456jain Would appreciate to have a look on this pull request.Thanks:)

@AsmaIbrahimButt merge conflicts

@arpit456jain I resolved.Kindly review it.Thanks:)

https://deploy-preview-676--cool-front-end-templates.netlify.app/chinese restaurant/

@AsmaIbrahimButt ??? Updates

@astha2412 When i improve the footer section of chines restaurant the changes on my local seems perfect .Do I have to fix the all issues that occur now?

@astha2412 When i improve the footer section of chines restaurant the changes on my local seems perfect .Do I have to fix the all issues that occur now?

@VidhiBhatt01 I would like to fix it properly.Thanks:)

Awesome 🙌

@AsmaIbrahimButt make a new PR when ready

@arpit456jain ok


deps: Upgrade to Postgres 15

Key changes:

Update table permissions since schema default permissions changed in PG 15 (see https://github.com/opencollective/opencollective-api/pull/10534#discussion_r1877553542).
Update CI jobs to ubuntu-24.04 (which is supposed to become the default in the next coming days) to install postgres-client-16 and make sure we use the latest tooling for restoring.

Should we go to 16.4 to match production?

Should we go to 16.4 to match production?

It's the next step, but I want to make it incremental to easily rollback if it's not working for some in the team.


Fix sway formatting turns += into + = which breaks the build command because it is not a valid expression

closes #1945
Until we are ready to switch to formatter v2, I am pushing a quick fix as this seems fairly easy to fix and the bug is breaking the build process.

I wasn't sure whether we should have a test or not since:

Handling of = sign part does not have one too
We are going to be removing the v1 formatter soon (wasn't sure if we should add more noise)

But I think we can add one so that we are sure it does not touch += as it used to do (if you also think that would be a better approach to follow)
Does something like this seem good?:
    #[test]
    fn test_plus_equal() {
        let correct_sway_code = r#"script;
fn main() {
    let mut a = 1;
    a += 1;
}
"#;
        let sway_code = r#"script;
fn main() {
    let mut a = 1;
    a += 1;
}
"#;
        let result = get_formatted_data(sway_code.into(), OPTIONS, None);
        assert!(result.is_ok());
        let (_, formatted_code) = result.unwrap();
        assert_eq!(correct_sway_code, formatted_code);
    }

Shouldn't we also do the same for other operators: -=, *=, etc.? I suspect hey suffer from the same problem.

Yes, that seems correct, I can see that this happens with:

'-='
'*='
'/='

but <<= and >>= seem to be formatted correctly.


deprecate materialization overrides from imported packages

resolves https://github.com/dbt-labs/dbt-core/issues/9981

Problem

We are deprecating the ability for installed packages to override built-in materializations without explicit opt-in from the user.
Users should still be able to wrap the built-in materialization in their root project to avoid this deprecation warning. e.g:
{% materialization view, default %}
 {{ return(my_cool_package.materialization_view_default()) }}
{% endmaterialization %}

Solution

When the materializations are resolved at execution-time, if the chosen materialization has a possible 'global' (core / built-in) candidate, raise a deprecation warning indicating that an installed package has won over a built-in one.
This would be overly-complex to do at parse-time (would need to link materializations together based on their name, and reuse (if possible) or reimplement a bunch of code that is run during execution at parse-time. This doesn't seem worth it for something that will become legacy behaviour.

However, it should be more straightforward to raise a warning at parse-time for regular macros (in a separate issue / follow-on PR)

🎩

Invoking dbt with ['run']
20:23:19  Running with dbt=1.8.0-b2
20:23:19  Registered adapter: postgres=1.8.0-b4
20:23:19  Unable to do partial parsing because saved manifest not found. Starting full parse.
20:23:19  Found 1 model, 412 macros
20:23:19
20:23:20  Concurrency: 4 threads (target='default')
20:23:20
20:23:20  1 of 1 START sql view model test17134717990861067406_test_custom_materialization.model  [RUN]
20:23:20  [WARNING]: Installed package 'view_default_override' is overriding the
built-in materialization 'view'. Overrides of built-in materializations from
installed packages will be deprecated in future versions of dbt.
20:23:20  1 of 1 ERROR creating sql view model test17134717990861067406_test_custom_materialization.model  [ERROR in 0.01s]
20:23:20
20:23:20  Finished running 1 view model in 0 hours 0 minutes and 0.49 seconds (0.49s).
20:23:20
20:23:20  Completed with 1 error and 0 warnings:
20:23:20
20:23:20    Compilation Error in model model (models/model.sql)
  intentionally raising an error in the default view materialization

  > in macro materialization_view_default (macros/default_view.sql)
  > called by model model (models/model.sql)

Checklist

[x] I have read the contributing guide and understand what's expected of me
[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[ ] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX
[x] This PR includes type annotations for new and modified functions

(WIP) Manual backports:
1.6: https://github.com/dbt-labs/dbt-core/pull/10008
1.7: https://github.com/dbt-labs/dbt-core/pull/9998


GUI!

Here's you go.
My next project will be getting linefeeds and other special characters working in the Lua script.
But that's a task for later...

This is amazing thanks!!


NotImplementedError: unknown node: mermaid

Hi,
Is it possible to add  sphinxcontrib.mermaid as a supported module for confluencebuilder?
extensions = [
'sphinx.ext.todo', 'recommonmark', 'sphinxcontrib.mermaid','sphinxcontrib.confluencebuilder'
]
Publishing in confluence is not working due to the following error:
Running Sphinx v3.5.1
running in headless mode, starting Xvfb
Xvfb is running on display :0
WARNING: html_static_path entry '_static' does not exist
building [mo]: all of 0 po files
building [confluence]: all source files
updating environment: [new config] 8 added, 0 changed, 0 removed
...
Exception occurred:
File "/usr/local/lib/python3.6/site-packages/sphinxcontrib/confluencebuilder/translator/init.py", line 132, in unknown_visit
raise NotImplementedError('unknown node: ' + node_name)
NotImplementedError: unknown node: mermaid
The full traceback has been saved in /tmp/sphinx-err-0jftiuxo.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at https://github.com/sphinx-doc/sphinx/issues. Thanks!

The last investigation to support sphinxcontrib.mermaid was discussed in #159. At that time, it appeared that there was not a way to gracefully support this extension (without introducing a maintenance dependency on that project).
There have been updates to that extension since it was last looked at, so it can be investigated again to see if any new changes might improve the integration between these two extensions.

It is possible to use sphinxcontrib.kroki which converts mermaid to svg image.

@hason sphinx + mermaid works fine for me. I even able to push the stuff to GitLab pages.
I get this error on the  Confluence pushing  stage (via confluencebuilder). With all other types of documents  confluencebuilder works good for me.

Reviewing the implementation again, there currently exists no stock support between these two extensions. At this time, confluencebuilder still only supports direct extension implementation for extensions found in the internal Sphinx repository.
It is possible to use confluencebuilder with sphinxcontrib-mermaid with the following modification to a documentation's configuration file:
from sphinxcontrib.mermaid import MermaidError
from sphinxcontrib.mermaid import logger as mermaid_logger
from sphinxcontrib.mermaid import mermaid
from sphinxcontrib.mermaid import render_mm

def generic_visit_mermaid(self, node):
    try:
        fname, _ = render_mm(
            self, node['code'], node['options'], 'png', 'mermaid')
    except MermaidError as exc:
        mermaid_logger.warning('mermaid code %r: ' % node['code'] + str(exc))
        raise nodes.SkipNode

    img_node = nodes.image(uri=fname, alt=node.get('alt', ''))
    if 'align' in node:
        img_node['align'] = node['align']
    node.replace_self(img_node)
    self.visit_image(img_node)

def generic_depart_mermaid(self, node):
    pass

def setup(app):
    app.add_node(mermaid,
        confluence=(generic_visit_mermaid, generic_depart_mermaid),
        override=True)

The above will work by converting the mermaid diagrams to pngs, replace the node to an image type, which in turn will allow this extension to handle the image asset. Using svg may work as well, but has not be tested. Conversion does require configuring the mermaid_cmd option to be set.
As discussed in #159, raw (default) mermaid diagrams cannot be supported since (stock) Confluence publish events do not support injecting Javascript into a page/instance.

I added all above in the config file.
Also added one more import:
from docutils import nodes
get the following error:
WARNING: command 'mmdc' cannot be run (needed for mermaid output), check the mermaid_cmd setting
Exception occurred:
File "/usr/local/lib/python3.6/site-packages/sphinxcontrib/confluencebuilder/translator/storage.py", line 2186, in _escape_sf
data = data.replace('&', '&')
AttributeError: 'NoneType' object has no attribute 'replace'
The full traceback has been saved in /tmp/sphinx-err-3pk490_0.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at https://github.com/sphinx-doc/sphinx/issues. Thanks!

@kmitro,
You are correct that the above example will also need from docutils import nodes as well. Thanks for pointing it out, and I have updated the previous comment to reflect this (just in case someone else may stumble across this thread).
There is a change on the main branch which will prevent the use case where incomplete image nodes provided by mermaid (or any other extension) will now be suppressed (see #490). This should prevent the AttributeError exception noted.

WARNING: command 'mmdc' cannot be run (needed for mermaid output), check the mermaid_cmd setting

To ensure images are generated for the confluencebuilder extension to use, mermaid-cli must be installed for the host to build these images (since JavaScript rendering is not supported). The installation of this command will vary per host, but an example configuration for a Windows environment may be as follows:
mermaid_cmd = './node_modules/.bin/mmdc.cmd'
mermaid_output_format = 'png'

Although, it is best to consult the mermaid-cli's README for the most recent/helpful information.

Support for this has been added in this extension with the idea that it might be easier for users; and hopefully does not become a maintenance issue. Support for sphinxcontrib.mermaid have been added in #522; currently on the development branch and should be available next release (v1.7+).
Note that users will still need to configure mermaid_cmd to properly render mermaid images on a Confluence instance.

v1.7 is now available on PyPI -- marking as closed.


Rerun argument is not recognized

Question:
Do we support the rerun feature from Cucumber in Serenity-JS?
If not, are there plans to support it? (maybe in version 2)
I'm trying to replay the failing tests by using this feature, which is supported by protractor-cucumber-framework (used by Serenity-JS for the cucumber flavor) but for some reason, the argument is not being recognized.
When I switch from Serenity to protractor-cucumber-framework as the custom framework in the protractor configuration file it does recognize it (but I lose the Serenity features):
From
    framework: 'custom',
    frameworkPath: require.resolve('serenity-js'),

to
    framework: 'custom',
    frameworkPath: require.resolve('protractor-cucumber-framework'),

it works
These are the details of my package.json:
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^1.6.0",
    "@typescript-eslint/parser": "^1.6.0",
    "cucumber": "1.3.2",
    "eslint": "^5.16.0",
    "eslint-config-airbnb-base": "^13.1.0",
    "eslint-plugin-import": "^2.14.0",
    "glob": "7.1.2",
    "npm-failsafe": "^0.4.1",
    "protractor-cucumber-framework": "5.0.0",
    "rimraf": "^2.6.3",
    "serenity-cli": "^0.11.1",
    "ts-node": "^8.0.2",
    "typescript": "^3.2.4"
  },
  "dependencies": {
    "@serenity-js/rest": "^1.1.1",
    "@types/chai": "4.0.0",
    "@types/chai-as-promised": "0.0.31",
    "@types/cucumber": "1.3.1",
    "@types/node": "7.0.31",
    "axios": "^0.18.0",
    "chai": "4.0.2",
    "chai-as-promised": "7.0.0",
    "js-yaml": "^3.13.0",
    "module-alias": "^2.2.0",
    "moment": "^2.24.0",
    "protractor": "5.3.2",
    "serenity-js": "^1.10.13"
}

This will help you #101

Closing as duplicate of #101


Some concrete files in the test suite fail (printing issues?)

Some tests are failing even though they are equivalent. Here is an example:
### Failure in: 6:RoundTrip:3:5:dup
    haskell\Tests\TestTools.hs:90
    expected:
    x1 <~ normal(nat2real(0), nat2prob(1))
    x0 <~ normal(nat2real(0), nat2prob(1))
    return (x1, x0)
    but got:
    x15 <~ normal(0, 1)
    x03 <~ normal(0, 1)
    return (x15, x03)

Possibly the result of incorrect pretty printing?

Is the 'got' program now correct Hakaru?  @zaxtax ?  If so, then that is indeed better and should be accepted as the new expected.

The got one looks fine.
On Tue, Jun 20, 2017 at 4:39 PM, Jacques Carette<EMAIL_ADDRESS>wrote:

Is the 'got' program now correct Hakaru? @zaxtax
https://github.com/zaxtax ? If so, then that is indeed better and
should be accepted as the new expected.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hakaru-dev/hakaru/issues/89#issuecomment-309884464,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAhUWCXDbObJqryw4m6rZ0QHZpMyjQCks5sGC3_gaJpZM4OAHXJ
.

This seems like an error with alpha equality. If the latter program contains LProb 1 while the former contains CoerceTo HProb (LNat 1) then those should be considered equal.

Yes, but I don't want to reproduce the coercion logic in alpha equality.  So, until this becomes a real pain, I think we should just accept the 'got' program as the new, nicer, 'expected'.
Furthermore, this does represent a real improvement, so it is actually good that we were forced to look at it.  If things had moved in the opposite direction, it should have been a regression.

I agree about that suggestion.
On Tue, Jun 20, 2017 at 5:12 PM, Jacques Carette<EMAIL_ADDRESS>wrote:

Yes, but I don't want to reproduce the coercion logic in alpha equality.
So, until this becomes a real pain, I think we should just accept the 'got'
program as the new, nicer, 'expected'.
Furthermore, this does represent a real improvement, so it is actually
good that we were forced to look at it. If things had moved in the
opposite direction, it should have been a regression.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hakaru-dev/hakaru/issues/89#issuecomment-309893273,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAhUQ4Uik4Tyg04RP_BL49d6uxNGX5uks5sGDXPgaJpZM4OAHXJ
.

In reality, the issue is that the pretty printer is throwing away information. A change to alpha equality may fix some of these, but not all. This failure (and about 30 others) begin happening as a result of having moved the RoundTrip tests to concrete syntax.
As a simpler example, RoundTrip.t82' is
syn (Lam_ :$ ((bind (Variable "" (Nat 0) SReal) (syn (Literal_ (LProb (1 % 1))))) :* End))

whereas reading this same program from concrete syntax (i.e. fmap parseAndInfer (IO.readFile "tests/RoundTrip/t82.expected.hk")) is
syn (Lam_ :$ ((bind (Variable "x0" (Nat 0) SReal) (syn (Literal_ (LNat 1)))) :* End)))

There is no way for alphaEq to ever decide these are the same program, because they have different types. Even worse, the latter program is the result of pretty printing the former program. In other words, the pretty printer has discarded type information.
I'm pretty sure that #90 is the same issue, but manifested in a slightly different way.

I think we should just accept the 'got' program as the new, nicer, 'expected'.

There is no new program. This program is just the old one with an additional roundtrip through parseAndInfer . pretty. It turns out this operation is not idempotent but I feel confident that it should be.

So the issue is that parsing adds coercions that pretty than preserves. For
example,
$ echo "uniform(0,1)" | pretty
uniform(nat2real(0), nat2real(1))
So maybe Pretty/Concrete should throw away coercions, or we should start
with coercions.
On Tue, Jun 20, 2017 at 5:26 PM, yuriy0<EMAIL_ADDRESS>wrote:

In reality, the issue is that the pretty printer is throwing away
information. A change to alpha equality may fix some of these, but not all.
This failure (and about 30 others) begin happening as a result of having
moved the RoundTrip tests to concrete syntax.
As a simpler example, RoundTrip.t82' is
syn (Lam_ :$ ((bind (Variable "" (Nat 0) SReal) (syn (Literal_ (LProb (1 % 1))))) :* End))
whereas reading this same program from concrete syntax (i.e. fmap
parseAndInfer (IO.readFile "tests/RoundTrip/t82.expected.hk")) is
syn (Lam_ :$ ((bind (Variable "x0" (Nat 0) SReal) (syn (Literal_ (LNat 1)))) :* End)))
There is no way for alphaEq to ever decide these are the same program,
because they have different types. Even worse, the latter program is the
result of pretty printing the former program. In other words, the pretty
printer has discarded type information.
I'm pretty sure that #90 https://github.com/hakaru-dev/hakaru/issues/90
is the same issue, but manifested in a slightly different way.
I think we should just accept the 'got' program as the new, nicer,
'expected'.
There is no new program. This program is just the old one with an
additional roundtrip through parseAndInfer . pretty. It turns out this
operation is not idempotent but I feel confident that it should be.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hakaru-dev/hakaru/issues/89#issuecomment-309896719,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAhUZz-hQTTw4BzpHIoX9pHgB_T5iCXks5sGDkPgaJpZM4OAHXJ
.

First of all, a Hakaru program is an abstract syntax tree that may contain coercions. For example, the program nat2prob(5) + nat2prob(30) is different from the program nat2prob(5 + 30) (even though both have the type prob only), and running the two programs through the hakaru command produces slightly different outputs.
Sometimes parsing a concrete syntax file that contains no explicit coercions nevertheless produces a Hakaru program (i.e., an abstract syntax tree) that contains coercions. Rob's program uniform(0,1) is a fine example. That program (i.e., that abstract syntax tree) is the result of parsing an infinite number of different concrete syntax files:

uniform(0,1)
uniform(nat2real(0), nat2real(1))
uniform(0, nat2real(1))
uniform(nat2real(0), 1)
uniform(0,             00001)
etc.
Let's call this program P.

If we take a Hakaru program (i.e., an abstract syntax tree), pretty-print it, then parse the resulting text, we should get back the same Hakaru program (i.e., an alpha-equivalent abstract syntax tree). In particular, we should get back a Hakaru program with exactly the same coercions in the same places. For example, the result of pretty-printing P can be any of the infinite number of texts listed above, because they all parse back to P. In contrast, pretty-printing nat2prob(5) + nat2prob(30) and pretty-printing nat2prob(5 + 30) must give different results, because the results must parse back to different programs (i.e., different abstract syntax trees, with different coercions in different places). The easiest way to ensure that coercions don't interfere with this roundtripping is for pretty-printing to make all coercions explicit and for parsing to add no implicit coercions as long as the explicit coercions are enough to make the program type-check. That's what we currently do, right?
The problem Yuriy demonstrated is that the programs syn (Literal_ (LProb (1 % 1))) and syn (Literal_ (LNat 1)) break this roundtripping: pretty-printing them gives the same result, so it's impossible for the result to parse back to different programs. To fix this problem, we should introduce concrete notation for prob literals distinct from nat literals (and similarly for real and int literals), and make sure that the pretty-printer and the parser agree on this notation.

If you think we need literals for prob and nat, add an issue about it.
On 20 Jun 2017 20:15, "Chung-chieh Shan"<EMAIL_ADDRESS>wrote:

First of all, a Hakaru program is an abstract syntax tree that may contain
coercions. For example, the program nat2prob(5) + nat2prob(30) is
different from the program nat2prob(5 + 30) (even though both have the
type prob only), and running the two programs through the hakaru command
produces slightly different outputs.
Sometimes parsing a concrete syntax file that contains no explicit
coercions nevertheless produces a Hakaru program (i.e., an abstract syntax
tree) that contains coercions. Rob's program uniform(0,1) is a fine
example. That program (i.e., that abstract syntax tree) is the result of
parsing an infinite number of different concrete syntax files:

uniform(0,1)
uniform(nat2real(0), nat2real(1))
uniform(0, nat2real(1))
uniform(nat2real(0), 1)
uniform(0, 00001)
etc.
Let's call this program P.

If we take a Hakaru program (i.e., an abstract syntax tree), pretty-print
it, then parse the resulting text, we should get back the same Hakaru
program (i.e., an alpha-equivalent abstract syntax tree). In particular, we
should get back a Hakaru program with exactly the same coercions in the
same places. For example, the result of pretty-printing P can be any of the
infinite number of texts listed above, because they all parse back to P. In
contrast, pretty-printing nat2prob(5) + nat2prob(30) and pretty-printing nat2prob(5

must give different results, because the results must parse back to
different programs (i.e., different abstract syntax trees, with different
coercions in different places). The easiest way to ensure that coercions
don't interfere with this roundtripping is for pretty-printing to make all
coercions explicit and for parsing to add no implicit coercions as long as
the explicit coercions are enough to make the program type-check. That's
what we currently do, right?

The problem Yuriy demonstrated is that the programs syn (Literal_ (LProb
(1 % 1))) and syn (Literal_ (LNat 1)) break this roundtripping:
pretty-printing them gives the same result, so it's impossible for the
result to parse back to different programs. To fix this problem, we should
introduce concrete notation for prob literals distinct from nat literals
(and similarly for real and int literals), and make sure that the
pretty-printer and the parser agree on this notation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hakaru-dev/hakaru/issues/89#issuecomment-309926823,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAhUYl0teOelvLWFrAvIdz8WCLWGbt_ks5sGGCYgaJpZM4OAHXJ
.

Between this and #89, we have an accumulation of failing tests now stuck on parsing/pretty-printing issues.  These tests do not seem outlandish to me -- so this seems like a fairly serious issue. @yuriy0 is working on fixing issues on the Maple side (also causing failures of tests we would really like to pass); could perhaps @zaxtax or @ccshan look at the Haskell-side of things?

(Just to clarify, between what and #89? This is #89.)

I've lost track.  I'll get @yuriy0 to update the test failure classification (it should be in the repo) to make that clearer.

This change (1d40bdebd84fd293622e1f2ed632037213c994db) will make sure a program isn't pretty printed in a way which throws away type information (although, 1 and 1.prob and 1.real should all 'unify' anyways). It still isn't strong enough to make all the new failures go away. Note that #90 is unaffected by any of these recent changes - it seems based on the discussion there that that is an issue with type checking/inference, whereas this one is an issue with representation of equivalent programs.

update the test failure classification

This will help to identify what still needs to be done.

To fix this problem, we should introduce concrete notation for prob literals distinct from nat literals (and similarly for real and int literals), and make sure that the pretty-printer and the parser agree on this notation.

This would help the problem; but I'm not certain it would completely fix it.
If we did do this, I would propose the following syntax:

0, 1 have type nat
+0, +1, -1 have type int. This would change the parsing of -1 from Negate (LNat 1) to LInt (-1).
0.0, 1.0, 1/1 have type prob. This would change the parsing of 1/1 from Prod (LProb 1) (Recip (LProb 1)) to LProb 1.
+0.0, +1.0, -1.0, +1/1, -1/1 have type real. This would again change the parsing of -1.0.

One example of something not fixed by such a change is RoundTrip/mhPriorProp (bb418973d2afdfaa14d6f28489c5a4a4f17ce87e), which simplifies to the expected output, but for one difference:
expected:
... * int2real(-1) * prob2real(recip(nat2prob(2)))
got:
... * -1/2

If we had a distinct syntax for each literal type, then expected would contain ... * -1/1 * recip(+2/1); got would still contain ... * -1/2.
Another thing to consider: this issue arose as the result of moving tests from Haskell syntax to concrete syntax. All the issues seem to arise from the interpretation of literals. While the programs in question were written in Haskell syntax, literal polymorphism was taken care of by the Haskell type system, using the same mechanism that Haskell uses - the literal 0 is interpreted as fromIntegral 0 :: Num a => a. The Hakaru typechecker uses a different implementation of polymorphism for literals - the literal 0 is alternatively interpreted as a subset of {nat, int, prob, real} depending on the context in which it appears; and upon completion of typechecking, a single type of the remaining possible types is chosen for the literal. If we wanted to ensure that a Hakaru program could just as easily be written in concrete syntax as in Haskell syntax, we could ensure that these typechecking algorithms agree - if not in implementation, at least in results.
Yet another thing to consider: it may be the case that alphaEq should be comparing terms for semantic equality, and not for type-directed syntactic equality. In the case of a syntactic equality, CoerceTo c0 x0 is only equal to CoerceTo c1 x1 if x0 and x1 are equal; the coercions are ignored because there should be a single inhabitant of a coercion at a particular type. If the equality was instead semantic, it could take two terms of differing types, say LInt 1 and LReal 1 and prove they represent equal values (that is, these programs are identical when sampled from) even if their types don't agree. Such an equality, being heterogeneous, would be free to ignore coercions altogether - that is, CoerceTo c0 x0 and x1 are equal if x0 and x1 are equal. The old 'type-directed syntactic' equality could be recovered simply by instantiating the heterogeneous equality to takes two terms of equal type.

I like the literal syntax you propose, except I'm worried that / also means division, so how do we express the division of 1 by 2 in concrete syntax? I hope it's not just by putting spaces around / in 1 / 2. Maybe by putting parentheses in (1)/2 or 1/(2)? Whatever disambiguation we use would need to be generated by the pretty printer, of course.
I also hope spaces would be allowed around not only / but also + and - in this literal syntax.
Due to precedence, I'm not sure that ... * -1/2 should be allowed, even if -1/2 is parsed as a literal.
Regarding your "another thing to consider": It's probably too big a change for now, because

it would be a significant change in interface -- for example, the user would have to insert an explicit coercion in the following addition of a nat to a real:

i <~ poisson(42)
x <~ normal(0,1)
return (i+x)

it would be a significant change in implementation -- in particular, type-class resolution calls for type variables and unification.

Regarding your "yet another thing to consider": You seem to be talking about making our testing use a coarser notion of equality. If I understand you correctly, the reason to do it is, if a test currently produces A (and passes) and the result changes to B in the future, and we don't care about the difference between A and B, then a coarser notion of equality that equates A and B would save us from the bother of updating the expected test result. I get the impression that the current test failures are due to the move to concrete syntax, so I haven't seen examples of A and B, and I would wait for them.

I'm worried that / also means division, so how do we express the division of 1 by 2 in concrete syntax?

In my mind, that term would become inexpressible with such a change. Is there a need to be able to express it? That is, is there any situation where the literal 1/2 doesn't serve the same purpose as division of 1 by 2?

Due to precedence, I'm not sure that ... * -1/2 should be allowed, even if -1/2 is parsed as a literal.

Due to precedence .. * -1/2 is parsed as Prod (.., -1, Recip(2)). But that term (... * -1/2 in the got of mhPriorProp) comes from parsing Maple, not parsing concrete syntax. I believe that the Maple parser is what produces Prod(.., -1/2) - the Maple parser receives the result of ToInert, which picks its own association of operations. That association may not agree with what the Concrete parser would pick if it parsed the pretty printed program. Maybe that's a part of the problem!
If -1/2 were a literal according to the scheme I mentioned, I think that precedence would no longer apply once parsing -1/2 because it would be a single 'atom'. However, .. * -1/2 could still be parsed as Prod(.., -1, Recip(2)), if the parser entered a different context upon parsing a * (or another operator). I'm not sure this would be necessary - do we lose anything by treating -,/,+ differently when they are applied to literals? Treating them differently was part of my goal in proposing the new syntax; by doing so, we could ensure a canonical form of literals right in the parser.

It's probably too big a change for now...

I agree with both reasons. I did not even consider the first, and can't see off-hand how it could be solved (that is, to not place additional burden on the user); as for the second, it was evident, but I had hoped there may be a way to implement something of the sort without having to implement type variables in the internal syntax, and without having to implement a unification algorithm (i.e. an implementation which emulates type class unification "not in implementation, [but] at least in results.").

If I understand you correctly, the reason to do it is, if a test currently produces A (and passes) and the result changes to B in the future, and we don't care about the difference between A and B, then a coarser notion of equality that equates A and B would save us from the bother of updating the expected test result.

This isn't my reason, although it would be a nice side effect! To clarify my goal there: currently, some equivalent programs (and not just equivalent in the sense that every simplified program is equivalent to the original; equivalent up to a very trivial amount of differences) are emitted by different parts of Hakaru (e.g. the Maple parser and concrete parser) and we should not have to ensure every single part of Hakaru emits the 'same' program in identical internal syntax. Such equivalence classes of programs are very apparently the same program to the human eye, and they almost certainly are equally as efficient as samplers (if there is a discrepancy, I think it would be absolutely insignificant; multiplying by -1 then dividing by 2 is basically the same as multiplying by -1/2).
The only time a machine needs to determine two programs are the same program is inside alphaEq. So it is alphaEq that should ensure the equivalence of morally equivalent programs - all of the parsers, pretty printers, and any other part of Hakaru, should not have to work in perfect harmony just to "prove" a trivial equivalence.

save us from the bother of updating the expected test result

To put it another way, it is not simply a bother to update the expected result; for some results, it is impossible to write that result in concrete syntax. We could expand the parser to allow the user to write all programs in concrete syntax (that is, every possible equivalent variation of a particular program should have a syntax which parses to that exact variation); or we could change alphaEq to judge all such equivalent programs equal. The latter seems like a better choice to me, because there are many parsers, but one alphaEq.

The coarser our equivalence relation on programs, the more we have to worry that a transformation might behave differently on two equivalent programs.  For example, I'm not 100% sure offhand whether disintegration treats a fractional literal and a division of two literals identically.  We already have this worry given that we compare programs modulo renaming variables and permuting n-ary operands, so the worry is not new, but it can get worse.
I still stand by what I wrote above:

If we take a Hakaru program (i.e., an abstract syntax tree), pretty-print it, then parse the resulting text, we should get back the same Hakaru program (i.e., an alpha-equivalent abstract syntax tree).  In particular, we should get back a Hakaru program with exactly the same coercions in the same places.

This requirement entails that no term be inexpressible, because the job of the pretty-printer is to find a way to express every term.  Of course we could shrink the AST data type to rule out terms we don't feel like expressing, but I don't see how to do that in this case.
I'm ok with literals that look like compound expressions (such as -1/2), as long as the syntax of these literals is consistent with the usual precedence and associativity of the operators involved (+, -, /) and remains insensitive to whitespace and comments.  So 1 / 2 / 3 / 4 should be parsed as the literal 1/2 divided by 3 then divided by 4, not as the literal 1/2 divided by the literal 3/4, which would yield a different number.  And ... * -1 / 2 should not be parsed as multiplying ... by the literal -1/2, because * and / have the same precedence are left-associative.  Actually, I'd rather ... * -1 / 2 not parse at all, because I don't like unary - in the non-leftmost operand of * -- it's not standard math and it's not allowed by Haskell (see lexp⁶ → - exp⁷ in https://www.haskell.org/onlinereport/exps.html).
Parentheses, such as in -(1)/2, can be used (in particular, by the pretty-printer) to make non-literals expressible.

the more we have to worry that a transformation might behave differently on two equivalent programs

Indeed; it seems that changing alphaEq would be at least somewhat burdensome, and wouldn't obviate the other necessary changes to the parser/pretty printer. I'm now convinced this isn't the way to go.
To summarize, I see this issue as the following distinct issues:

The concrete parser and pretty-printer should implement the new syntax for literals. This should include a way of specifying e.g. division of two literals which would normally be parsed as a single literal. I agree that parentheses would be a good way to do that. I also agree that non-indentation whitespace should not have an effect on parsing, in general, but in particular 1/2 and 1  /  2 should denote exactly the same term.

The pretty printer and parser should handle precedence correctly. I would also rather not have ... * -1/2 parse; but it currently does. This includes making sure the 'overloading' of +, -, / in the new literal syntax agree with the precedences of existing operators. This issue may also include other precedence related problems (https://github.com/hakaru-dev/hakaru/commit/3f2f7e47e66f22d54fbd522f2717431e4bede4bc#commitcomment-22789801); or that particular one might also be a separate issue.

The Maple parser should agree with the concrete parser on how a program is parsed. In particular, if the simplifier does not change a particular program, then hk-maple prog.hk should produce a program alpha-equivalent to prog.hk.

The change I implemented (e25c1eb3cf6a401b550bce60fa07c67d3752f61b) to make sure literals were not pretty printed with the incorrect type should be reverted. If each literal type has its own syntax, that change is no longer necessary, and it creates a lot of syntactic noise in the output of pretty, and it would (currently does) defeat the goal of having every program be expressible in concrete syntax.

Maybe this is done as of e214cbe9d34fa7a43eedd104b9a5e1b4f33b191c?

As of 5e6067ff442c351769ebfacf679018c122c69f3b it is really done. Thanks for the fixes!


Fix that --explain panics

This commit fixes a bug accidentally introduced in 6cf770a6924e6c2b00f53a52492bdffe80015552,
which resulted every ruff --explain <code> invocation to fail with:
thread 'main' panicked at 'Mismatch between definition and access of `explain`.
Could not downcast to ruff::registry::Rule, need to downcast to &ruff::registry::Rule',
ruff_cli/src/cli.rs:184:18

We also add an integration test for --explain to prevent such bugs from going by unnoticed in the future.

Thank you for following up, and for adding a test here.


Added missing backtick

What's this PR do/fix?
A typo present in the current documentation.
Are there unit tests? If not how should this be manually tested?
N/A
Any background context you want to provide?
I noticed the typo as I was reading the documentation, I figured I'd make a PR to fix it.
What are the relevant issues?
None

Thank you for catching that @TwinProduction


Put quotes around variable to avoid shell expansion

If someone uses /me in minecraft, it will print all files inside the current directory in discord.

Oh the things that little errors can do.... I'll merge this.


Single node cluster down after restart

I restarted a single node via sudo shutdown -r now and after reboot it won't come up. Logs from /var/log/upstart/flynn-host.log are below. Any guidance would be appreciated!
INFO[08-26|12:55:48] request started                          component=host req_id=ef386519-4ea1-4196-9427-ff4fa1d69ed7 method=GET path=/host/jobs client_ip=<IP_ADDRESS>
INFO[08-26|12:55:48] request started                          component=host req_id=fede05bb-1a68-4678-a664-622b8ea9307f method=GET path=/host/jobs client_ip=<IP_ADDRESS>
INFO[08-26|12:55:48] request completed                        component=host req_id=fede05bb-1a68-4678-a664-622b8ea9307f status=200 duration=50.061954ms
now=2016-08-26T19:55:48+0000 fn=unbind_mounts job.id=flynn-96d84d2a-19f2-4077-a614-3c690a41c6b9 backend=libvirt-lxc at=start
now=2016-08-26T19:55:48+0000 backend=libvirt-lxc fn=unbind_mounts job.id=flynn-96d84d2a-19f2-4077-a614-3c690a41c6b9 at=finish
now=2016-08-26T19:55:48+0000 fn=watch_container job.id=flynn-96d84d2a-19f2-4077-a614-3c690a41c6b9 at=cleanup_mounts status=finish backend=libvirt-lxc
INFO[08-26|12:55:53] request completed                        component=host req_id=ef386519-4ea1-4196-9427-ff4fa1d69ed7 status=200 duration=5.000100379s
INFO[08-26|12:55:53] request started                          component=host req_id=8006e1d7-cc00-4c03-9e95-ec6d7a163310 method=GET path=/host/jobs client_ip=<IP_ADDRESS>
EROR[08-26|12:55:57] scheduler is not up                      component=cluster-monitor fn=checkCluster
EROR[08-26|12:55:57] cluster is unhealthy, setting fault      component=cluster-monitor fn=checkCluster
INFO[08-26|12:55:58] request completed                        component=host req_id=8006e1d7-cc00-4c03-9e95-ec6d7a163310 status=200 duration=5.000141565s
INFO[08-26|12:55:58] request started                          component=host req_id=61e2bbe4-e5b8-4fca-b2d1-baaaae4b609b method=GET path=/host/jobs client_ip=<IP_ADDRESS>
INFO[08-26|12:56:03] request completed                        component=host req_id=61e2bbe4-e5b8-4fca-b2d1-baaaae4b609b status=200 duration=4.999867031s
INFO[08-26|12:56:03] request started                          component=host req_id=34b8e925-ca31-4d1c-92f7-ef5965b1f79d method=GET path=/host/jobs client_ip=<IP_ADDRESS>

Give it a few more minutes and then check if there is anything new in the logs.

Will do, thanks!

It looks like the content of this gist is just repeating every few minutes.
https://gist.github.com/kevinob11/d1c0aae004927bb3b04f57920700cc85

Looks like the scheduler is having trouble starting, can you collect the debug logs with flynn-host collect-debug-info so we can take a look.

Here you go!
https://gist.github.com/b067e4778dc08685a26f1120bebf7de6

@kevinob11 you are hitting against a bug in the scheduler which I pushed a fix for just yesterday (#3329).
To get things running, you will need to purge your flynn-host state database so it doesn't have so many stopped jobs. I have written a Go program which will do this, you can find instructions for running it in the following gist (follow the instructions in the shell script, the Go code is just for reference so you know what the compiled program does):
https://gist.github.com/lmars/cfb46fe104d1c17be8f22acf41c907e9
If this brings your cluster back up ok I would suggest taking a backup and restoring into a newer version of Flynn (you are currently running v20160218.0 whereas the latest stable is v20160814.0).

The Go program ran successfully, but the cluster still didn't start.
now=2016-08-27T17:54:58+0000 fn=watch_container job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e at=change state=exited backend=libvirt-lxc
now=2016-08-27T17:54:58+0000 backend=libvirt-lxc fn=watch_container job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e at=exited status=1
now=2016-08-27T17:54:58+0000 backend=libvirt-lxc at=start fn=waitExit job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e
now=2016-08-27T17:54:58+0000 at=done backend=libvirt-lxc fn=waitExit job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e
now=2016-08-27T17:54:58+0000 job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e backend=libvirt-lxc fn=cleanup at=start
now=2016-08-27T17:54:58+0000 job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e backend=libvirt-lxc fn=unbind_mounts at=start
now=2016-08-27T17:54:58+0000 backend=libvirt-lxc fn=unbind_mounts err="invalid argument" at=unmount file=.containerinit status=error job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e
now=2016-08-27T17:54:58+0000 backend=libvirt-lxc fn=unbind_mounts job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e at=unmount file=resolv.conf status=error err="invalid argument"
now=2016-08-27T17:54:58+0000 fn=unbind_mounts job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e backend=libvirt-lxc at=finish
ERRO[0266] Removing active id tmp-flynn-fc11e28a-5732-4e92-9c5e-5044a711588e
now=2016-08-27T17:54:58+0000 job.id=flynn-fc11e28a-5732-4e92-9c5e-5044a711588e backend=libvirt-lxc fn=cleanup at=finish
EROR[08-27|10:55:07] scheduler is not up                      component=cluster-monitor fn=checkCluster
EROR[08-27|10:55:17] scheduler is not up                      component=cluster-monitor fn=checkCluster
EROR[08-27|10:55:27] scheduler is not up                      component=cluster-monitor fn=checkCluster
INFO[08-27|10:55:29] request started                          component=host req_id=eadf349d-f1d8-4449-9674-9a5bcf23d79d method=GET path=/host/jobs client_ip=<IP_ADDRESS>
INFO[08-27|10:55:29] request completed                        component=host req_id=eadf349d-f1d8-4449-9674-9a5bcf23d79d status=200 duration=37.91903ms
INFO[08-27|10:55:31] request started                          component=host req_id=dce9f954-f200-4c11-aff8-952e52ec9c25 method=GET path=/host/jobs client_ip=<IP_ADDRESS>
INFO[08-27|10:55:31] request completed                        component=host req_id=dce9f954-f200-4c11-aff8-952e52ec9c25 status=200 duration=34.384887ms
INFO[08-27|10:55:33] request started                          component=host req_id=4b43a415-96b0-496e-bbf0-327235dbf0f3 method=GET path=/host/jobs client_ip=<IP_ADDRESS>
INFO[08-27|10:55:33] request completed                        component=host req_id=4b43a415-96b0-496e-bbf0-327235dbf0f3 status=200 duration=31.145143ms
EROR[08-27|10:55:37] scheduler is not up                      component=cluster-monitor fn=checkCluster

This is my old cluster, I've already moved to Flynn 1.0, but I brought it back up to do some testing on my old apps to diagnose an issue I'm having.

@kevinob11 it's probably best to just boot a fresh cluster, the version is pretty old and we have fixed quite a few resurrection bugs since then.

Ok, fair enough. Thanks!

Quick follow up, the reason I brought this up is I moved to a new cluster on Flynn 1.0 recently, when I did my users started noticing more issues with requests failing. I looked in the router logs on a tip from @lmars and found quite a few net/http: request canceled errors. I wanted to bring this old machine back up to see if I had those same errors in my router there. I wasn't able to bring the machine back up, but I grepped the /var/log/flynn directory for the same error and didn't see any instances of it. I also added per request logging to my app, I see those requests begin, but then they never complete, and act as if they've been canceled.
Can you think of anything that could be causing this or point me to a good next step in troubleshooting?
Thanks!

Are you using HTTPS? Is the client that has this issues Safari?

Yes to HTTPS and the client is iOS, so yes on Safari.

This might be #3261. What version of Flynn are you running? (flynn-host version)

Also, are the canceled requests for image files? That's another indicator for this issue.

v20160721.2, so definitely before that went in.
They were just requests to a data api, should have returned json. Requests are GET requests to a simple path + query. Eg/api/user?ids=1234,12351,1234512,12341,12341234

Hmm, can you see if this happens with the latest stable release (v20160814.0) or a nightly? It's still likely that this is the same pipelining bug or something along similar lines.

Sure, we were going to spin up a new cluster next weekend anyway, I'll let you know if this works!

Great, if you're still having trouble on the latest version, please open a new issue.

Will do.


Add CycleFreeFluxes

https://academic.oup.com/bioinformatics/article/31/13/2159/195895

implementation hint: try to re-use as much of the parsimonious tooling as possible (maybe we should rename those to something like 2stage or postprocessing or so)

@stelmo hey this is actually "just" the linear parsimonious FBA but with extra boudns on the exchanges, right?
BUT since the exchanges in the FBA are kinda free-floating, the normal linear parsimonious FBA would basically provide a compatible and correct CFF solution as well, right?


Added imagePullPolicy to some addon services for istio.

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

@gyliu513: Adding do-not-merge/release-note-label-needed because the release note process has not been followed.

One of the following labels is required "release-note", "release-note-action-required", or "release-note-none".
Please see: https://github.com/kubernetes/community/blob/master/contributors/devel/pull-requests.md#write-release-notes-if-needed.
Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/release-note-none

sync with master

@gyliu513: you cannot LGTM your own PR.

In response to this:

/lgtm
/approve

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/cc @rshriram can you help add lgtm label?

/lgtm
/approve


android: Update auth callbacks and URLs to follow convention

Update callbacks and URLs according to #1868
Use SecureRandom, not Random to generate cryptographic tokens
Minor app manifest cleanup
Redirect with client_platform=android instead of dest

@pratikvelani The AppLinkHandler doesn't seem to be called, because the AuthActivity is still the one that's launched when the Sign In button is clicked. Does it make sense to combine those two features into one, or is it better to keep them separate? I'm not an Android developer (obviously), but it seems like there's a lot of boilerplate being duplicated across the two features just to receive an AppLink intent.

The applink is verified using the key used to build the app with the SHA1 mentioned on the https://domain.name/.well-known/assetlinks.json.
Please get your SHA1 key using this task:

Once your key is added to the assetlinks.json, applink should work on the build you create too.

Once your key is added to the assetlinks.json, applink should work on the build you create too.

Ah, this makes sense! I've added my sha256 fingerprint to this PR.

@pratikvelani This PR also removes the AppLink stuff since it seems we don't need it. The intent is not being captured by the Auth feature -- still working on handling that.

@pratikvelani This is ready for final review -- I'll fix the connlib issues in another PR

@pratikvelani I've fixed the callbacks. The issue was that the JNI method signatures were missing the return type codes. Unfortunately I'm not able to test with your branch, so YMMV. We did see crashes with CONNLIB_MOCK=1 but this may have been due to the lifetime of the Activity view we were abusing to load libconnlib.so and call connect, since this doesn't seem to be actually wired up anymore on main.


exclusiveContent looks that are not applied

Based on Gradle 7.0 doc looks that now is possible declare an exclusive repository content, for example:
repositories {

    // This repository will _not_ be searched for artifacts in io.quarkus
    // despite being declared first
    mavenCentral()

    exclusiveContent {
         forRepository {
            jcenter ()
        }
        filter {
            // this repository *only* contains artifacts with group "io.quarkus"
            includeGroup "io.quarkus"
        }
    }
}

However, I still get the following log trace:
Attempting to resolve component for io.quarkus:quarkus-resteasy-jackson:2.1.0.Final using repositories [MavenRepo, BintrayJCenter]

Please find on this link a reproducer: https://github.com/pjgg/gradle-exclusiveContent-reproducer
You can run the following command: ./gradlew quarkusDev --debug | grep "io.quarkus:quarkus-resteasy-jackson"
Expected Behavior
Log trace:
Attempting to resolve component for io.quarkus:quarkus-resteasy-jackson:2.1.0.Final using repositories [BintrayJCenter]

I've checked and it is just logs being slightly misleading - the log entry mentions all available repositories; the filtering is applied later.

It's a bit misleading, maybe there should be another log entry to say that filtering was applied.


Fork and add react-native-web's benchmarks

These are the results I got. Just leaving them here for my records.


Difficulties implementing custom fonts

Version of embedded-graphics in use (if applicable): 0.6.0-alpha.2
Target: Simulator
If using real hardware: N/A

I'm attempting to implement my own custom font using the FontBuilderConf trait. Firstly, this is much simpler than earlier versions, which is great to see!
However, I'm having some difficulty understanding how it actually works. I know i need to implement the char_offset function, but it's not obvious what it's doing. What is this index that it returns? How is that translated into byte array in the conf?
Essentially I'm having difficulty translating the layout of fonts in the data files into an implementation of char_offset. Each of the existing fonts seems to have a different layout and char_offset implementation, so unfortunately I couldn't glean much from them.
I think the documentation here needs to be improved. I'd be happy to contribute there, but I would need some assistance in understanding it.

The char_offset function converts a Unicode char to the position where that glyph is stored in the font image. For example: If the first glyph in the upper left corner of the font image is an 'A' calling char_offset('A') would return 0. And if the next glyph to the right is 'B' it would return 1.
The translation to indices into the FONT_IMAGE array is done in FontBuilderIterator::next. The glyphs in the font image are stored starting width glyph 0 in the top left corner and ascending indices to the right and bottom. The rows of glyphs are wrapping after FONT_IMAGE_WIDTH pixels.
I'm not sure this description was clear enough, but comparing the font images in embedded_graphics/data/font*.png with the return values of the char_offset methods should make it clearer how this works is practice.

I think the documentation here needs to be improved. I'd be happy to contribute there, but I would need some assistance in understanding it.

Yes, the documentation isn't great. I'm not sure if the code will change in the future but help with better documentation is always appreciated. This could also make a great code example in the simulator, like a simple seven segment font.

This could also make a great code example in the simulator, like a simple seven segment font.

That's a great idea. I'd like to create a short guide in the Rust docs and a longer, tutorial-style article on my blog at some point, maybe after the release of 0.6.0. I think implementing a 7 segment font would be a good target for the guide. Plenty of pictures to explain the index offsets too!
If nobody else wants to write that guide up I'm happy to have a go. I'd open a PR to review so I'm not missing anything from @lukesutton's point of view.

@jamwaffles While I was looking at the code to write my reply I thought that it might be simplified by removing the wrapping feature. Having only one row of glyphs would simplify the code and also make the relation of char index and glyph position inside the font image clearer. What is your opinion on this?

I'd prefer to keep it:

Existing fonts like those on the Uzebox wiki can still be used.
It (IMO) doesn't add much complexity.
Font glyph maps are easier to view/debug/inspect due to their squarer proportions
I don't think performance is an issue - happy to be corrected

OK, fair points.

@rfuest Thank you for that explanation. That makes sense to me. I'll have another go at my implementation.
@jamwaffles Based on that I'm happy to have a go at writing a short guide for the docs.

While I was looking at the code to write my reply I thought that it might be simplified by removing the wrapping feature.

That would make it easier to understand, but I do agree with @jamwaffles' points.

@rfuest added an example of a custom seven segment font here a while ago. Like all the examples, it needs some better documentation in the header, but it might be enough to get you started.
I still want to do a walkthrough blog post at some point as well. Just haven't got round to it yet :sweat_smile:

I'm gonna close this issue as there's a custom font example in the simulator, and I have a custom font tutorial on my personal blog posts TODO anyway, so I'll pick that up... at... some point.


[CONTINT-3380] Make sure every SBOM has a repodigest

What does this PR do?
This PR ensures that every SBOM has a repodigest.

Motivation
Skip images without RepoDigest because:
1- Back-end does not process images without repodigest
2- For a given image, it is possible to have multiple Create/Update events. It is possible that the first event the scanner processes does not have a repodigest. In that case SBOM will not have a RepoDigest, it won't be updated later and image scans will be ignored by the back-end.

Additional Notes
I guess that an image can have multiple repodigests. In that case we keep only one. Changing this behavior would require triggering a new scan everytime an event is observed which can be a bit costly, even with the cache, considering that a scan involves many serializations/deserializations.

Possible Drawbacks / Trade-offs
N/A

Describe how to test/QA your changes
There are two different things to test. Both require to run the agent with container image collection enabled and sbom collection enabled. These env variables can enable SBOM collection:
    - name: DD_SBOM_ENABLED
      value: "true"
    - name: DD_CONTAINER_IMAGE_ENABLED
      value: "true"
    - name: DD_SBOM_CONTAINER_IMAGE_ENABLED
      value: "true"

Run the agent with images that do not have a repodigest and make sure that those without repodigest do not get scanned agent workload-list -v. Some kind images do not have a repodigest. registry.k8s.io/coredns/coredns:v1.10.1 for example.
Make sure every SBOM emitted has the field aquasecurity:trivy:RepoDigest. You can use agent stream-event-platform --type container-sbom for that. However, it might be difficult to reproduce the issue because it depends on the order of creation event received. In that case, it is also possible to deploy it internally and look at the logs (check associated jira card).

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

Closed because we are working on another solution


Deploying to redis via an ssh tunnel

My team has a deployment process very similar to ember-cli-deploy's default, but our redis server isn't directly accessible from our local machines due to firewall rules. The options I see are:

Just remind devs to have a tunnel set up between their machine and redis. It's simplest, but I don't love having local machines with always-on direct access to our production redis servers.
Some combination of ember-deploy-ssh-index and ember-deploy-redis to ssh to the redis machine and run redis commands. This is what we do currently via a homegrown script but it's kind of a mess to pipe redis commands through bash.
Use ember-deploy-redis and wrap then-redis to set up an ssh tunnel from an ephemeral port to the redis port on the remote server for the duration of the deploy. I'm favoring this option, but am curious if you think it's better as its own deploy plugin or if it could be merged into ember-deploy-redis.

The extra options could look like:
  development: {
    store: {
      type: 'redis', // the default store is 'redis'
      host: 'remoteHost',
      port: 6379,
      ssh: {
        localPort: 38596, // if not set, one is randomly chosen between 32768 and 65535
        username: 'deploy',
        privateKey: ...,
      }
    }

(I opened the issue here since I know there are a lot of big changes coming to the plugin system, but I can move it to the ember-deploy-s3 repo if that is a better place for it.)

Seems to me that having this as an option for ember-(cli-)deploy-redis makes sense, but I'd like to hear @LevelbossMike's input.

As we migrate to ember-cli-deploy(-redis) we will need to resolve this exact same problem because our production Redis servers are limited similarly to @mnutt 's environment. I'm in favor of the last bullet point of supporting opening a tunnel for the duration of the deploy and merging into ember-deploy-redis.

this seems like a useful addition to ember-deploy-redis. And like a use-case that should be supported by the plugin because it's annoying for everyone to set this up themselves and there are definitely a lot of people that need it.

:+1: for this. This is exactly what Im looking for.

:+1: from us, too. To our interests, this is indeed relevant.

Since this is Redis specific, the issue is now here . @LevelbossMike think it's OK to close this issue and track with the ember-deploy-redis issue?

yup. closing in favor for https://github.com/LevelbossMike/ember-deploy-redis/issues/4


Backend misha

Added backend support of trails with sqlite database can create and fetch trails. Added image support and display of all trails. Followed lab code for setup of database. -- DO NOT MERGE RN

constants should be fine now


1K data transmission

how to enable 1K data transmission in Xmodem libarary.

The XModem protocol allows an arbitrary number of data packets to be sent using the send method. If what you mean is that you want 1K packets (assuming you can afford to reserve that much RAM for it) that can also be configured in this library through the setDataSize method, however if you do this then more tuning is probably required since with so much data getting sent at once your likely to run into a few issues:

first your receiving device could run out of buffer space for the incoming data and drop bytes
second your probability of transfer errors goes up quickly as you increase your data size, requiring multiple retransmissions
These can be mitigated by slowing down your baud rate (aka transfer speed) and by using a stronger (and longer) checksum or other error correcting code at the end of the packets.
You can see full documentation on these methods in the README file and look in the 'examples' folder for some basic send/receive programs.

I would like to transmit 1024 blocks at a time; however, when I attempt to increase the buffer size, I encounter an error. The library only supports sending a maximum of 128 blocks at a time. How can I transmit 1024 blocks at once using this library?
This library currently supports only two modes: XMODEM and CRC_XMODEM, both of which have a data byte size limit of 128. Is it possible to implement an additional mode that supports 1024 data bytes?
case ProtocolType::XMODEM:
      _id_bytes = 1;
      _chksum_bytes = 1;
      _data_bytes = 128;
      _rx_init_byte = NAK;
      calc_chksum = XModem::basic_chksum;
      break;
    case ProtocolType::CRC_XMODEM:
      _id_bytes = 1;
      _chksum_bytes = 2;
      _data_bytes = 128;
      _rx_init_byte = 'C';
      calc_chksum = XModem::crc_16_chksum;
      break;

Right these are defaults based on the standard XMODEM and CRC_XMODEM protocols if you change them you need to update them to be the same on both the sender and receiver otherwise the receiver will error out the connection since it won't be receiving control signals when it expects to.


Modify mc.replace_fragment to accept a multi-cid selection for the argument atom_selection

As a string of CIDs divided by "||".

Implemented in https://github.com/pemsley/coot/commit/722be7e725a5f2bb85c4bccfd597e8a83fa086ef


Under windows using CPython >3.7 RDKit import fails due to missing dll(s)

Describe the bug
Under windows using CPython >3.7 RDKit import fails due to missing dll(s).
To Reproduce
Build RDKit under windows using CPython >3.7. Under python "import rdkit" fails with "ImportError: DLL load failed while importing rdBase: The specified module could not be found."
Expected behavior
RDKit is successfully imported.
Configuration (please complete the following information):

RDKit version: ANY
OS: Windows 10
Python version (if relevant): CPython >3.7
Are you using conda? NO
If you are using conda, which channel did you install the rdkit from? N/A
If you are not using conda: how did you install the RDKit? Built from source

Additional context
Under windows with CPython >3.7 the way dll(s) are searched has changed (see: https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew).  Among other things environmental variable PATH is not used causing the RDKit to fail due to missing dll(s), mainly python, boost, etc.
One needs to specifically add dll search paths via os.add_dll_directory. I could submit a PR fixing this issue but I'm afraid it will not be pretty, mind you.

Ugh.
Thanks for pointing out the problem @SPKorhonen
I will take a look at this and try and come up with something over the next couple of days.

I have several extension modules which had the same problem. I made a small utility DllImport.py which is called within extension init.py and adds relevant paths to so.add_dll_directory. I could implement similar solution for rdkit if you like.
The only problem is that dynamically adding paths is a bit hackish but what can you do...

Sorry to bother you, but any progress on this issue @greglandrum?
I'm currently using a slightly hackish workaround which just forcibly adds relevant paths when importing modules. I could submit it as a pull request if you want to take a look at it.

Sorry to be a pest but do you have any work on how to resolve this issue going forward @greglandrum?

@SPKorhonen I'll trave and have a look over the next few days: I'll get back to you before Monday.

@SPKorhonen : I can't reproduce the problem; I regularly use my own rdkit builds on a windows 10 machine and just need to be sure that the directories containing the RDKit dlls and the boost dlls are in my PATH.
I'm using the conda python binaries... I wonder if that makes a difference

I think it might be due to Conda. Either I'm reading too much into this comment, or Conda has rolled back this new security feature. See: https://github.com/conda-forge/python-feedstock/issues/307#issuecomment-576040344

@SPKorhonen confirmed using Python from https://www.python.org/ and compiling my own Boost. This is indeed due to the security enhancement introduced with Python 3.8. I would not attempt to address this in RDKit, as it depends on how the libraries and Python modules are packaged/installed.
A simple way not to incur in the problem is to put all Boost and RDKit DLLs into the same directory where the python.exe binary lives. This removes the need for calling os.add_dll_directory().

Fair enough. I can appreciate that you do not want to touch that can of worms even with a 10 feet pole...
I need to juggle between different versions of rdkit and boost so copying everything into python install directory is not really a viable solution for me. That said I use modified version of rdkit anyways and can continue using the modified version which automatically adds the PATH via os.add_dll_directory().
So, if you want to close this I have no problems.


add function to also queue local tasks from a job

To make sure you can see that a task is kicked of from a different job.

thanks


MWPW-127223 | Adding video play on image with link

Add video play button in linked image if | :play: is added in alt text.
Provide option to add large medium or small button variations via | :play-large: or '| :play-medium: or | :play-small:. As per consonant design default is large variation.
Inherit button style and positioning for cards from CAAS.

Resolves: MWPW-127223
Test URLs:

Before: https://main--milo--adobecom.hlx.page/drafts/mathuria/genericvideobtn/demovideomodal?martech=off
After: https://videoplay--milo--aishwaryamathuria.hlx.page/drafts/mathuria/genericvideobtn/demovideomodal?martech=off

Validation has been done from QA side on the below urls:
https://videoplay--milo--aishwaryamathuria.hlx.page/drafts/tat28144/genericvideobtn/combine-video

Validation has been done the marquee, figure, media, aside, z pattern, carosuel, no block, cards block
Validation has been done in CC as well below are the urls :
https://main--cc--adobecom.hlx.page/drafts/Anupama/cc-videoplayicon?milolibs=videoplay--milo--aishwaryamathuria
https://main--cc--adobecom.hlx.page/drafts/Anupama/cc-videoplayicon-caas?milolibs=videoplay--milo--aishwaryamathuria

Looking good, there are a few minor css selector things to address. Thanks

@ryanmparrish I have made the suggested changes in the CSS.

Found a few small things.

@auniverseaway Thanks for sharing the review comments. I have made the suggested changes. Could you re-review the PR?

@auniverseaway I have made the suggested changes. Could you re-review the PR?


Nightlies

2 separate config files because the Android upload to the servo-rust bucket in the Rust account, and the everything-else upload to the servo-developer-preview bucket in the Servo account, require different credentials. @aneeshusa, could you remind me of the right way to salt the near-identical files which end up with different pillar data and different names?
Windows nightly requires:

Appropriate package command
Either refactoring the DynamicServoYAMLFactory to handle how all windows commands need to be run in their own bash shells (correct solution) or writing a new custom Windows factory (fast but bad solution)

This change is

Just woke up and haven't looked at this yet, but you must be psychic  @edunham - I was about to open an issue/PR for this last night! This should also fix servo/servo#10339.

I would prefer to use environment variables + logEnviron: false to pass the AWS IAM Key Id and Secret Access Key. Using a config file implies it's readable by any process running as servo, and we don't have any user isolation yet (e.g. IIRC Homu also runs as servo). Using environment variables limits the scope to which these credentials are exposed.
In the future I'd even like to see us using https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html to generate temporary session tokens so even if a token gets leaked it's NBD.
This can be done by modifying the make_step functions and adding a new heurisitic for s3cmd. By the way - any reason we are using s3cmd instead of the AWS CLI?

It may also be nice to set up a MailNotifier so Buildbot sends emails when a nightly build fails, but that can be saved for a follow-up.

Is there a reason to continue to upload android builds to a Rust controlled bucket? Why don't we just dump everything in the servo bucket?

servo-master1 builds get:
[ FAIL ] Buildbot master config check failed:

         Configuration Errors:

           Unknown builder 'linux-nightly' in scheduler 'Nightly'

           Unknown builder 'mac-nightly' in scheduler 'Nightly'

           Unknown builder 'linux-nightly' in scheduler 'force'

           Unknown builder 'mac-nightly' in scheduler 'force'

I think they need to be added here:
https://github.com/edunham/saltfs/blob/281a9e39d65248a0e681b81086aa45330d1892cc/buildbot/master/files/config/master.cfg#L171

I would rather not rush this PR too much, since we have some time before release and we can always make a build manually for release. @edunham if you want I can make a PR to your branch to implement passing credentials as environment variables.

I'm not super excited about manual builds from user machines and would rather hold off on releasing binaries until we do it from machines that were at least originally installed from a clean state with only the dependencies we've documented & listed in salt. Maybe manual builds from those machines would make me feel less stressed, but publishing bits to the world from laptops the team has taken through security checkpoints in all sorts of interesting countries seems dubious :-)

This will need servo/servo#11943 at the least.

:umbrella: The latest upstream changes (presumably #410) made this pull request unmergeable. Please resolve the merge conflicts.

Filed #413 and #414 as follow-ups. Closing in favor of #410 (and #411).


Drag n' drop editor tabs with weird behavior on ChromeOS (with videos)

Environment:

Version: 1.54.1
Commit: f30a9b73e8ffc278e71575118b6bf568f04587c8
Date: 2021-03-04T22:38:50.094Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.4.74-10576-gb6cc41974db3

Steps to Reproduce:

Download  and install VSCode .deb from main download page.
Run it straight through .desktop file launcher.
Open any other Linux app (including VSCode)
Try to use drag n drop with editor tabs

Does this issue occur when all extensions are disabled?: Yes
Description
I've made 4 videos to describe the problem, for each situation.

Drag n drop with correct behavior (only VSCode as open Linux apps)
Unfocused VSCode "stealing" the drag n drop tab  (2 VSCode as open Linux apps)
Even if  VScode windows dont overlap, the "stealing" still occurs   (2 VSCode open side by side)
Drag n drop not working when exists other Linux app running  (1 VSCode + random Linux app open)

Likely duplicate of https://github.com/microsoft/vscode/issues/109176 then unless it reproduces without wayland.

Likely duplicate of #109176 then unless it reproduces without wayland.

All these vídeos were recorded without Wayland flags, just a deb install from VSCode download page.

@MatheusZabin weird indeed, do you see the same using Chrome browser and VSCode from https://vscode-web-test-playground.azurewebsites.net/?enter=true ?

@MatheusZabin weird indeed, do you see the same using Chrome browser and VSCode from https://vscode-web-test-playground.azurewebsites.net/?enter=true ?

No. On web-test drag n drop works properly, even with multiple windows open (overlapping and side by side).
This issue doesn't occur on code-server PWA either.

@deepak1556 fyi maybe you have heard about these issues before (see the videos).

Can someone remove "needs more info" and reopen?

Fixed with wayland flags on 1.56.0 release.


stackit_ske_cluster module not useable anymore

Hey,
since the new version 0.25.0 the module stackit_ske_cluster is not useable anymore. I tested the same configuration successfully in 0.24.0 and 0.21.0.
While creating the cluster the following error always appears.
Calling API to enable SKE: 403 Forbidden, status code 403, Body:
{"status":403,"message":"Unauthorized"}

Hi @Slaizer007,
thanks for reaching out to us.
SKE team has deprecated their service enablement endpoints and that is why we have switched to the Service Enablement API. It might be that Service Enablement API does different permission checks than the SKE endpoints. Could you please verify, if you have the correct permissions for the project you are using?
Currently I can only reproduce this issue, if I try to create a cluster in a project where I am not a member.

hi @GokceGK,
the service account i am using is owner in the STACKIT Project. Also the same terraform code worked as soon as i switched to ver 0.24.0.

Hi @Slaizer007 ,
can you check if you can call the service enablement endpoints with your service account out of the Terraform Provider (like using Postman)? In the meantime, I will try to verify the issue with Service Enablement team as 403 is coming from their endpoint.

Hi @Slaizer007,
The fix was released in v0.26.2


[WIP] :penguin: Add Ubuntu flavors for RPi

What this PR does / why we need it:
Ubuntu flavors which support raspberrypi
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #645
supersedes #816

Sizes needed to be expanded in order to build the images, but now I can finally do. Pending QA

Codecov Report

Merging #1170 (99049f8) into master (7bb9af9) will increase coverage by 0.05%.
The diff coverage is 30.43%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##           master    #1170      +/-   ##
==========================================
+ Coverage   22.79%   22.85%   +0.05%
==========================================
  Files          22       15       -7
  Lines        1610     1199     -411
==========================================
- Hits          367      274      -93
+ Misses       1179      878     -301
+ Partials       64       47      -17

Impacted Files
Coverage Δ

internal/agent/agent.go
43.10% <ø> (ø)

internal/agent/interactive_install.go
0.00% <ø> (ø)

internal/agent/notify.go
0.00% <ø> (ø)

internal/agent/recovery.go
0.00% <ø> (ø)

internal/agent/reset.go
0.00% <ø> (ø)

internal/agent/upgrade.go
0.00% <ø> (ø)

pkg/config/config.go
51.35% <ø> (ø)

internal/agent/install.go
5.28% <30.43%> (+5.28%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@mauromorales, I take it you can't actually get into the system to see any logs to help there, based on the video, yeah?

@sdwilsh yeah indeed, I'll try to have a better setup for it next week and give it another shot

For faster iteration I wanted to try using the generic arm image. It builds successfully, startups and shows the grub menu, but then it gets stuck here quite quickly

https://user-images.githubusercontent.com/433958/236797895-9ee08ea4-0945-48d4-a99c-66e83d87f779.MOV

Generic image booting properly you can try this out by building it locally from the branch via: earthly -P +all-arm-generic --FLAVOR=ubuntu-arm-rpi

Ok, finally have a better setup, so I was able to SSH into the machine and the first issue I see is this. Will continue investigating:
kairos@localhost:~$ sudo systemctl list-units --failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
● polkit.service            loaded failed failed Authorization Manager
● rpi-eeprom-update.service loaded failed failed Check for Raspberry Pi EEPROM updates

The video problems are now fixed. The overlay files were not properly being copied so the vc4 module was enabled which is not supported in RPi. This is the same we do on other RPi flavors so maybe it should really be refactored to be copied whenever the module is rpi64

Just thinking out loud, but maybe we should drop to bootargs for rpi and during building add the vc4.conf to /etc/modprobe.d with a blacklist vc4 line to not even have to worry about the vc4 module and stop adding it to the cmdline?

Just thinking out loud, but maybe we should drop to bootargs for rpi and during building add the vc4.conf to /etc/modprobe.d with a blacklist vc4 line to not even have to worry about the vc4 module and stop adding it to the cmdline?

good point, added a new issue https://github.com/kairos-io/kairos/issues/1407
very cool that you can create issues from comments, wasn't aware of this


metrics: Remove duplicate and racy flush on reporting thread exit

Problem
https://github.com/anza-xyz/agave/pull/718 introduced a reporting of the accumulated metrics at during the termination of the upload thread.
It is actually both unnecessary and racy.
Summary of Changes
Removes the unnecessary upload and clarifies the expectations.
Reverts https://github.com/anza-xyz/agave/pull/842, which was a previous attempt at fixing this, but was effectively a noop.

I think this is a better solution, compared to what is proposed in https://github.com/anza-xyz/agave/pull/997.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 82.0%. Comparing base (23905c0) to head (18198c5).
Report is 13 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master    #1039     +/-   ##
=========================================
- Coverage    82.0%    82.0%   -0.1%
=========================================
  Files         859      859
  Lines      232799   232798      -1
=========================================
- Hits       191010   190971     -39
- Misses      41789    41827     +38


[web-ui] running npm in build.rs is not ideal

Currently we build the web-ui in the build.rs, and this requires npm to be setup in the environment.
This means that a node environment is required to be setup to build the vn which can be annoying when running the VN from a different shell (like intelij run) leading to confusing build failures.
I suggest rather that we have to manually run npm to build the web-ui to be included in the binary.
There are a few options from here:

Let that be that, if you dont build the webui, it will display a blank page.
add an optional cli flag --webui-root ./whatever that overrides the content served on the web-ui port.
Only run npm if a certain env is set

For production builds, we add the npm build to the process (build script or whatever).

is simpler, we'll have to allow CORS in development because you may want to dev on the web-ui using npm serve
allows the updated content to be served directly from the VN, making dev easier

Both are fine for me, but 2 is a feature that needs to be added that may/may not be generally useful.

Yeah, push it up to a build.sh that does all the steps including cargo build


[share] Polish

The docs here should show an example that includes passing a subject.

/cc @collinjackson


[EPC and postcode/API key request]

Please fill in the following information:
Base URL:
Name: EPC datas and address datas
Description:
Documentation URL: https://content-api.publishing.service.gov.uk/
Maintainer: Huseyin Omer Guray
Provider: Government Digital Service
Area Served: house searching
Start Date: 2024-08-19
**End Date:**2026-08-19
Alternate Name: Freetold
Provider URL: freetold.com
Hello,
This is a software engineer from London. I am building an app for house rental searching.
This is the link so far: freetold.com
Can I have access to endpoints please? I willl need for address and epc datas. from postcodes.
Best regards

@zeldox258 The catalogue is a listing of available APIs. We do not maintain the APIs themselves.
There is a support section of Content API you've linked to. The Support section details how to contact the team managing the system for help:
https://content-api.publishing.service.gov.uk/#support


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_5d47ct4yny/clone/recipe/meta.yaml:22: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_5d47ct4yny/clone/recipe/meta.yaml:24: python_build_tool_in_run: The python build tool setuptools is in run depends
Errors were found


Add Bigtable quickstart

https://github.com/jabubake/nodejs-bigtable/blob/master/samples/README.md#quickstart
Please see expected quickstart for Bigtable here :
https://github.com/jabubake/nodejs-bigtable/blob/master/samples/quickstart.js
(Read a row from an existing table)
@sduskis FYI

This bug should likely be on https://github.com/GoogleCloudPlatform/cloud-bigtable-client rather than the examples repo.

I was trying to keep them together with the java samples that currently exist. We should ideally look at moving them to https://github.com/GoogleCloudPlatform/java-docs-samples.
Also, this repo is already referenced https://github.com/GoogleCloudPlatform/cloud-bigtable-client#using-the-java-client

Quickstarts should also be on top-level client README pages.  Is there a good way to manage that from github?

I wish this was easier :
we do use https://github.com/campoy/embedmd for community articles (I'll look at doing that for the Node.js client and the Java HBase client as examples).


Make Bookstack more Awesome

Describe the feature you'd like
Hello
First of all, thanks for developing, and maintaining such a nice artifact.
I have used bookstack and use it and now I'm able to organize my knowledge.
2 suggestions:

It will be awesome, if we could have Vim keybindings in Markdown mode of page editors.
it will be near perfect, if we could have pen support (drawing support) for Bookstack. something like tiddlywiki images that we can also touch and draw on them.

Thanks
Describe the benefits this would bring to existing BookStack users

Vim keybindings are getting more popular these days, and it is wide spread between many editors.
drawing is direct way to express our ideas so we can have a fast draft and work with it later.

Can the goal of this request already be achieved via other means?
Yes, many editors have vim keybindings, such as Google colab, to Pycharm, Jupyter, ...
and tiddlywiki also has the ability to add pictures and draw on it.
Have you searched for an existing open/closed issue?

[X] I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?
0 to 6 months
Additional context
I love the idea behind bookstack and like to see it improving.
As medium level Python developer, ready to help.

Hi @Shahin-rmz, Thanks for the feedback!
Multi-issue comments like this are hard for us to manage, so I'm going to close this off but, if needed, you can re-open them as their own requests.

It will be awesome, if we could have Vim keybindings in Markdown mode of page editors.
Vim keybindings are getting more popular these days, and it is wide spread between many editors.

Vim bindings is probably not something I'd look to include in the core project. This hasn't really had any demand before and the inclusion would then result in a wider scope, of providing key binding control in the editor.
Our editor, Codemirror, has vim bindings available although they are not actively maintained. We do expose our Codemirror config for the markdown editor via our custom editor events. It may be possible to combine these to add vim bindings yourself, by loading the vim bindings code externally then adding to config via our provided events.
If there are issues in script loading I'd be happy to look to see what we can do.

it will be near perfect, if we could have pen support (drawing support) for Bookstack. something like tiddlywiki images that we can also touch and draw on them.

This would be very tricky for us to achieve within the direct scope of our own platform and the existing page content.
It does look possible though to perform freehand drawings via the diagrams.net integration. It looks like they support pen input in a bunch of different ways.

Thanks for the reply.
Yes, diagrams.net solution for handwriting is what I meant.
For the Vim Keybinding part, Maybe I should take a look at the API and think of a client for sending and seeing the Books/Shelves etc which supports Vim Keybinding.


"de.perdoctus.streamdeck.ha.entity" isn't recognized after re-install

Heya!
Just re-installed Windows and installed the Stream Deck software again, then added this Home Assistant plugin again. However, I noticed that none of the Home Assistant keys would show up anymore and only displayed a question mark.
After manually opening all the "manifest.json" files in the profiles folder and bulk-replacing de.perdoctus.streamdeck.ha.entity with de.perdoctus.streamdeck.homeassistant.entity it worked again. I only knew about this possibility since I've done it quite a few times whenever Windows would have bigger updates and replace audio hardware IDs, so no sound effects would play anymore on a specific device.
Would it somehow be possible to add a feature that checks for both config entries and if it detects the old one to replace it with the newer version?
Thanks!

Hello,
i am currently working on new features which result in different configuration files. Because i know how painful lost button configurations can be, i added a simple versioning scheme to the configuration files.
Starting with the current version of the plugin (2.0.1 from elgato store), configurations will be automatically migrated to newer versions (as far as possible) so updates of the plugin do not destroy your existing settings.
However, de.perdoctus.streamdeck.ha.entity looks like you are one of the first users of my plugin (before it got to the official store?). Those old settings will unfortunately not be migrated.


Update documentation for sql repo.

The documentation currently spends quite a lot of effort explaining the data tree. This needs to be replaced.

PR #1158


Add support for Bandwidth Manager config for Cilium

Summary

Fixes: #10049.
Internal Reference: SURE-7195
Occurred changes and/or fixed issues

Added support for Bandwidth Manager config for Cilium
I have tested it when enabled Bandwidth Manager.
$ kubectl -n kube-system get cm cilium-config -o json | jq '.data."enable-bandwidth-manager"'
"true"

$ kubectl -n kube-system delete pod cilium-xxxxx

$ kubectl -n kube-system exec ds/cilium -c cilium-agent -- cilium status | grep BandwidthManager
BandwidthManager:                                   EDT with BPF [CUBIC] [ens5]

I have tested it when disabled Bandwidth Manager.
$ kubectl -n kube-system get cm cilium-config -o json | jq '.data."enable-bandwidth-manager"'
null

$ kubectl -n kube-system delete pod cilium-xxxxx

$ kubectl -n kube-system exec ds/cilium -c cilium-agent -- cilium status | grep BandwidthManager
BandwidthManager:        Disabled

Technical notes summary

Areas or cases that should be tested

Areas which could experience regressions

Screenshot/Video

@masap This will need a rebase from master too?

@richard-cox I rebased it, fixed a conflict and retested it.

Fixed conflict because Basics.vue has been moved.

Closed in favour of https://github.com/rancher/dashboard/pull/10320 which adds tests and updates with latest code changes for the ipv6 setting.


fix: Add a null check for actions during Context Switching

Description
Add a null check
Fixes #21307
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

none

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=d8f00f6


updated react to 16.10.1 && updated react-dom to 16.10.1 changed all …

…components to functional components and hooks

@connerj70 sorry for the delay. Thanks for putting time into this!


fix e2e test pipeline

Codecov Report

Merging #45 (aba6dbb) into main (fa3f605) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #45   +/-   ##
=======================================
  Coverage   33.07%   33.07%
=======================================
  Files          13       13
  Lines         127      127
  Branches       30       30
=======================================
  Hits           42       42
  Misses         80       80
  Partials        5        5

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 fa3f605...aba6dbb. Read the comment docs.


Komga script install error

Please verify that you have read and understood the guidelines.
yes
A clear and concise description of the issue.
Ran the script, seemed to set up dependancies just fine then ended the following error
What settings are you currently utilizing?

[ ] Default Settings
[X] Advanced Settings

Which Linux distribution are you employing?
Debian 12
If relevant, including screenshots or a code block can be helpful in clarifying the issue.
 ✓ Installed Dependencies
 - Installing Komga
[ERROR] in line 25: exit code 0: while executing command RELEASE=$(curl -s https://api.github.com/repos/gotson/komga/releases/latest | grep "tag_name" | awk '{print substr($2, 2, length($2)-3) }')

Please provide detailed steps to reproduce the issue.
run the script, as far as I can tell

Problem with DNS Server.
If you cant curl github, you cant access the following sections.


feat(Algebra/Lie): Killing Lie algebras are semisimple

[x] depends on: #13217
[x] depends on: #13366
[x] depends on: #13367
[x] depends on: #13370
[x] depends on: #13384
[ ] depends on: #13387

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#13265  👈
#13391
master

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

Join @jcommelin and the rest of your teammates on  Graphite

bors r+


Create a unique page view ID on page load, and send this event as context with each subsequent event

This will make it easy at analysis time to tie events that happened in-page back to the specific page view they were part of.
The ID should be sent as part of an 'ancestry context' that might also include a session index and user id(s) fields.

Closing as duplicate of #369


Debug console has light green background color

Theme: Quiet Light

@sandy081 looking into your status I see that you are deep into themes and editors, thus you might investigate into this. The issue is that I am currently taking a theme from the editor here. I want the theme but not the current line highlight.
One option would be to overwrite that css on my side, but that might be a bit ugly

@isidorn I am looking into creating a boolean option for this

@alexandrudima that would be lovely!

@isidorn I will track the work in #7942

@isidorn Option is renderLineHighlight

@alexandrudima works like a charm!