bug(@vtmn/react): Typescript warnings in the console when yarn build

Bug Report
Hello,
There are Typescript warnings in the console when yarn build on @vtmn/react package.

Steps to reproduce
yarn && cd packages/sources/react && yarn build
Thanks!

Hey @lauthieb !
So i checked a bit there is some parts that are a bit tricky, for example for the textarea you are trying to mix the event onChange from the textarea and the input wich are not the of the same types.
The best way to change that would be to have a VtmnInput and a VtmnTextArea to split up the differences and avoid having conditions like this for two different component and conditionnal types.
Or the other way around could look up like something
import * as React from 'react';
import clsx from 'clsx';

import<EMAIL_ADDRESS>import { VtmnIcon } from '../VtmnIcon';
import { VitamixId } from '@vtmn/icons/dist/vitamix/font/vitamix';

export interface BaseVtmnTextInputProps {
  /**
   * ID of the input
   * @type {string}
   */
  identifier: string;

  /**
   * Label text linked to the input
   * @type {string}
   */
  labelText?: string;

  /**
   * Helper text to help the user
   * @type {string}
   * @defaultValue undefined and therefore not displayed by default
   */
  helperText?: string;

  /**
   * Placeholder
   * @type {string}
   */
  placeholder?: string;

  /**
   * Icon to display inside text input
   * @type {VitamixId}
   * @default undefined and therefore not displayed by default
   */
  icon?: VitamixId;

  /**
   * Is a TextArea
   * @type {boolean}
   * @defaultValue false (Input)
   */
  multiline?: boolean;

  /**
   * Whether input is successful or not
   * @type {boolean}
   * @defaultValue false
   */
  valid?: boolean;

  /**
   * Whether input is in error or not
   * @type {boolean}
   * @defaultValue false
   */
  error?: boolean;
}

type VtmnTextInputProps<T> = T extends { multiline: true }
  ? React.ComponentPropsWithoutRef<'textarea'> & T
  : React.ComponentPropsWithoutRef<'input'> & T;

export const VtmnTextInput = ({
  className,
  disabled = false,
  error = false,
  helperText,
  icon = undefined,
  identifier,
  labelText,
  multiline = false,
  placeholder,
  valid = false,
  ...props
}: VtmnTextInputProps<BaseVtmnTextInputProps>) => {
  return (
    <React.Fragment>
      {labelText && (
        <label className="vtmn-text-input_label" htmlFor={identifier}>
          {labelText}
        </label>
      )}
      {multiline ? (
        <textarea
          className={clsx('vtmn-text-input', className, {
            'vtmn-text-input--error': error,
            'vtmn-text-input--valid': valid,
          })}
          id={identifier}
          placeholder={placeholder}
          disabled={disabled}
          {...(props as React.ComponentPropsWithoutRef<'textarea'>)}
        />
      ) : (
        <div className="vtmn-text-input_container">
          <input
            className={clsx(
              'vtmn-text-input',
              className,
              { 'vtmn-text-input--valid': valid && !disabled },
              { 'vtmn-text-input--error': error && !disabled },
            )}
            id={identifier}
            type="text"
            placeholder={placeholder}
            disabled={disabled}
            {...props}
          />
          {icon && <VtmnIcon value={icon} size={20} />}
        </div>
      )}
      {helperText && (
        <p
          className={clsx('vtmn-text-input_helper-text', className, {
            'vtmn-text-input_helper-text--error': error,
          })}>
          {helperText}
        </p>
      )}
    </React.Fragment>
  );
};

export default React.memo(VtmnTextInput);

As you can see i wrote a conditionnal type  wich kinda allow us to have two different types but on the props of the textarea we still need to cast the type because the magic of typescript have some limits :D
type VtmnTextInputProps<T> = T extends { multiline: true }
  ? React.ComponentPropsWithoutRef<'textarea'> & T
  : React.ComponentPropsWithoutRef<'input'> & T;

And for some others Components you just basicly need an Omit utility type on some property as you are using names that comes from the base HtmlElement type ie:
In VtmnToggleProps you are using the size property to handle the classname but size is also a property from the input so the TS compiler is warning about setting a string to a type that should be a number
You could change that by changing the name of the prop or adding the Omit utility
export interface VtmnToggleProps extends Omit<React.ComponentPropsWithoutRef<'input'>, 'size'> { ...YOUR_PROPS }

I can work on this when i have time (it's a bit complicated this month for me) otherwise to resolve this issue my comment should help the one who would like to work on it.

Hi @Wizyma, I would like to thank you a lot for you detailed answer. Your learnt me some key points about TypeScript.
As you can see on #651, @blemoine has already resolved this issue and it seems that he used the same solution that you have proposed just after.
Feel free if you still want to improve this!
Have a nice day :)
Laurent


[NFC] Add a regression test for SR-5252

For SR-5252, which was apparently fixed without direct intention.

@swift-ci Please smoke test


Remove the prompt for C# installation

This is now covered by extension recommendations.

// @chrisdias

verified


FIX: Fix example

Should fix https://app.circleci.com/pipelines/github/mne-tools/mne-python/13343/workflows/9eb5e49f-e9a2-4855-8579-6bbd9895532a/jobs/42679
cc @alexrockhill

I didn't realize we had an example that depended on mne-connectivity, thanks for fixing it!


Complete TCerts are no longer stored by TCA.

Relevant TCert data is stored in TCertificateSets table and TCerts are not being stored in Certificates table anymore
Description
TCertificateSets table is used to store relevant data (user enrollment id, timestamp, nonce value and TCA root key) when TCerts creation is requested to TCA.  TCA no longer stores entire certificates into Certificates table, and that code is unchanged so that other uses of that code (e.g. ECA) are unaffected.
Motivation and Context
This change was discussed and agreed in the context of issue #718.
How Has This Been Tested?
Unit and behave tests passed
New test cases have been created as part of this work
Checklist:

[x] I have added a Signed-off-by
[x] No new documentation is required by this change
[x] No new tests are required by this change
[x] I have run goimports, go vet, and golint. I have cleaned up all valid errors and warnings in code I have added or modified. The goal is clean, consistent, and readable code.

Signed-off-by: Diaper Wedger<EMAIL_ADDRESS>

reverify

reverify Travis

reverify jenkins

Behave test passed in both locally and Travis from our fork. Error message  ("close of closed channel") seems to be related to network connection. Could someone with permissions run behave test again?

Looking at this briefly too. Seems like the crypto_test.go is throwing a tantrum on Travis... as results are not reported back or so?

@diaperwedger, please, may you document the new design clarifying what is actually stored in DB and what the new information stored can be used for? This will help assess this PR.

reverify jenkins

reverify jenkins

@diaperwedger please provide a DCO sign-off with your true name and email. Thanks

@adecaro: Re:

please, may you document the new design clarifying what is actually stored in DB and what the new information stored can be used for?.
My 2 cents:

"please, may you document the new design clarifying what is actually stored in DB" ?

This change greatly reduced the amount of data/info stored in the DB, this is what's stored: "TCertificateSets table is used to store relevant data (user enrollment id, timestamp, nonce value and TCA root key) when TCerts creation is requested to TCA." instead of storing the entire set TCerts.

As for > "what the new information stored can be used for?"

I have asked that same question in #718. Trying to figure out, why full TCerts were stored in the first place? I could trace back some code from more than half a year back, but still could/can not really tell why it was designed this way.

While we don't know, how about at this point, we just store enough (=the required) information to generate/recover TCerts if need be. Happy to improve one thing at a time (as this will increase throughput, while still not losing critical recovery info) just to be on the safe side...
@adecaro: plausible?

@JonathanLevi thanks for the reply. What you say makes perfect sense to me and it is was I would expect to read in a README file or in a design document. So people knows what is done there and how the stored information can be used to regenerate the TCerts for auditing purposes, for example. Thanks again :)

@adecaro I agree we should have appropriate documentation, but having agreed that storing complete TCerts is not required, we would like to get this reviewed and committed as a separate item.  A new issue regarding documentation improvements in Membership Services will be created separately to avoid slowing down this PR acceptance.

@jeronimoirazabal @adecaro please update the PR comment to add a proper DCO signed-off-by from whomever is contributing this patch. It won't be merged until and unless it has a proper sign-off.

@JonathanLevi Could you please review this PR when ready? Thanks

@srderson: sure, on it now, thanks.
@diegomasini, @diaperwedger, @jeronimoirazabal: what @christo4ferris said. My understanding is that any of you can sign this PR.
@adecaro: what @jeronimoirazabal said, I personally don't think that the internals of the DB are in the README/Wiki at all (I believe (/suspect?) that the TCertPool is/was storing/loading all these TCerts into the database for optimization, or so). This is not exposed to the end user (hence I don't know if we really need this in the README/WIki, but sure we can look into where and how this might be documented).
@adecaro: Other than the request to update the README, is there anything else (in the code of this PR) you want to discuss?

@srderson: sure, on it, thanks.
@diegomasini, @diaperwedger, @jeronimoirazabal: what @christo4ferris said. My understanding is that any of you (3 code/patch committers) can sign this PR.
@adecaro: what @jeronimoirazabal said, I personally don't think that the internals of the DB are in the README/Wiki at all (I believe (/suspect?) that the TCertPool is/was storing/loading all these TCerts into the database for optimization, or so). This is not exposed to the end user (hence I don't know if we really need this in the README/WIki, but sure we can look into where and how this might be documented).
@adecaro: Other than the request to update the README, is there anything else (in the code of this PR) you want to discuss?

Signed-off-by: diegomasini diego.masini<EMAIL_ADDRESS>

The code certainly LGTM:  it does fix a real issue (#718), adds more tests, improves error messages and (other than unrelated issues) all tests have been passing continuously since last Friday.
Having said that, I feel that we missed a few testing cycles (due academic discussions about READMEs, etc.)  which would have otherwise, given us more confidence that there are no remaining (or newly-created) issues.
With the above in mind @srderson (& @binhn) this LGTM

The code certainly LGTM:  it does fix a real issue (#718), adds more tests, improves error messages and (other than unrelated issues) all tests have been passing continuously since last Friday (June 10th).
Having said that, I feel that we missed a few testing cycles (due academic discussions about READMEs, etc.)  which would have otherwise, given us more confidence that there are no remaining (or newly-created) issues.
With the above in mind@srderson (& @binhn), this LGTM.


Add Custom control server & fix serve command

This PR adds support for the environment variable TAILSCALE_CUSTOM_SERVER so custom control planes (Such as Headscale) can be used.
Also fixes the tailscale serve command always serving port 443, and not actually working if http is set as the TAILSCALE_SERVE_MODE` value

+1

Sorry this slipped my radar - I'll jump on it this weekend!

Sorry this slipped my radar - I'll jump on it this weekend! Looks like there are some conflicts I need to fix up too

Thanks, but I think at this point the project is abandonware waiting to be called as such.

+1, I would use the heck out of this docker mod if headscale was supported!


Black box defence

Description
Please include a summary of the change, motivation and which issue is fixed. Any dependencies changes should also be included.
Fixes # (issue)
Type of change
Please check all relevant options.

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

Testing
Please describe the tests that you ran to verify your changes. Consider listing any relevant details of your test configuration.

[ ] Test A
[ ] Test B

Test Configuration:

OS
Python version
ART version or commit number
TensorFlow / Keras / PyTorch / MXNet version

Checklist

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code
[ ] 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

Codecov Report

Merging #1 (11a3dc9) into main (478d67e) will decrease coverage by 44.12%.
The diff coverage is 13.38%.

@@             Coverage Diff             @@
##             main       #1       +/-   ##
===========================================
- Coverage   69.13%   25.01%   -44.13%
===========================================
  Files         232      240        +8
  Lines       18885    19013      +128
  Branches     3089     3093        +4
===========================================
- Hits        13057     4756     -8301
- Misses       5190    14173     +8983
+ Partials      638       84      -554

Impacted Files
Coverage Δ

...rt/defences/detector/evasion/black_box/__init__.py
0.00% <0.00%> (ø)

...ces/detector/evasion/black_box/contrastive_loss.py
0.00% <0.00%> (ø)

...rt/defences/detector/evasion/black_box/detector.py
0.00% <0.00%> (ø)

...defences/detector/evasion/black_box/knn_wrapper.py
0.00% <0.00%> (ø)

...efences/detector/evasion/black_box/memory_queue.py
0.00% <0.00%> (ø)

art/estimators/regression/pytorch.py
0.00% <0.00%> (ø)

art/estimators/regression/tensorflow.py
0.00% <0.00%> (ø)

art/estimators/encoding/pytorch.py
66.66% <66.66%> (ø)

art/estimators/encoding/__init__.py
100.00% <100.00%> (ø)

art/evaluations/evaluation.py
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 135 more


ORC-1753: Use Avro 1.12.0 in bench module

What changes were proposed in this pull request?
This PR aims to use Apache Avro 1.12.0 in bench module.
Why are the changes needed?
Apache Avro 1.12.0 is the latest feature release.
Since we are fixing this area recently, we had better keep it up-to-date in order to avoid re-validation in the future.

https://github.com/apache/orc/pull/1930
https://github.com/apache/orc/pull/1995

How was this patch tested?
Pass the CIs.
Was this patch authored or co-authored using generative AI tooling?
No.

cc @cxzl25

cc @williamhyun , too

Thank you, @williamhyun . Merged to main/2.0.


MIGA Installation error

Hi! I am trying to install MIGA using conda.
Everything goes nicely but when I do miga init i got an error:
Testing Ruby (Required version: 2.1+)... sh: 2: /home/jg/.miga_modules: source: not found
/usr/bin
Testing Python... sh: 2: /home/jg/.miga_modules: source: not found
/home/jg/anaconda3/bin
Testing R... sh: 2: /home/jg/.miga_modules: source: not found
/usr/bin
Testing SQLite3... sh: 2: /home/jg/.miga_modules: source: not found
/home/jg/anaconda3/bin
Testing NCBI BLAST+... sh: 2: /home/jg/.miga_modules: source: not found
Where can I find it? [.] >
I cannot find blastp sh: 2: /home/jg/.miga_modules: source: not found
Where can I find it? [.] >
I cannot find blastp sh: 2: /home/jg/.miga_modules: source: not found
Where can I find it? [.] > /home/jg/ncbi-blast/
I cannot find blastp sh: 2: /home/jg/.miga_modules: source: not found
Where can I find it? [.] > /home/jg/ncbi-blast/bin
Exception: undefined local variable or method `rc_fh' for #<MiGA::Cli::Action::Init:0x000055c3bf721248>
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:191:in `block in find_software'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:181:in `loop'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:181:in `find_software'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:160:in `block (2 levels) in check_software_requirements'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:155:in `each_line'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:155:in `block in check_software_requirements'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:154:in `open'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:154:in `check_software_requirements'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action/init.rb:51:in `perform'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli/action.rb:33:in `launch'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/lib/miga/cli.rb:197:in `launch'
DEBUG: /var/lib/gems/2.5.0/gems/miga-base-<IP_ADDRESS>/bin/miga:10:in `<top (required)>'
DEBUG: /usr/local/bin/miga:23:in `load'
DEBUG: /usr/local/bin/miga:23:in `<main>'

Any ideas?

Hello @Tato14
Please edit the file ~/.miga_modules, changing source activate miga -> conda activate miga
This is now updated in the manual.
I'll leave this issue open until we confirm the solution worked.

Thanks! It worked nicely now.


exp/ingest/adapters: Improve passing options to SingleLedgerStateReader

PR Checklist
PR Structure

[x] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[x] This PR's title starts with name of package that is most changed in the PR, ex.
services/friendbot, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[x] This PR adds tests for the most critical parts of the new functionality or fixes.
[x] I've updated any docs (developer docs, .md
files, etc... affected by this change). Take a look in the docs folder for a given service,
like this one.

Release planning

[x] I've updated the relevant CHANGELOG (here for Horizon) if
needed with deprecations, added features, breaking changes, and DB schema changes.
[x] I've decided if this PR requires a new major/minor version according to
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.

What
This commit changes a way maxStreamRetries (and other params in the future) are passed to SingleLedgerStateReader.
Why
I've recently shared a code snipped using SingleLedgerStateReader and realized that the last param of MakeSingleLedgerStateReader is confusing. You need to check the function godoc to understand what it really does. Also, there should be a default value (currently 3) that is suitable for most of the use cases. The new method is using variadic params to set options.
Before:
changeReader, err := historyAdapter.GetState(ctx, ledgerSequence, 3)

After:
changeReader, err := historyAdapter.GetState(ctx, ledgerSequence, io.MaxStreamRetries(10))
// or:
changeReader, err := historyAdapter.GetState(ctx, ledgerSequence) // defaults to 3

personally I don't think this is an improvement. I don't like how we are using interface{} types to represent the remaining parameters

I agree about interface{}. An alternative could be to use a struct with config values but devs would always need to pass it. Not bad, but a pain because most users are OK with default of 3 retries. Maybe we just set it to 3 and don't allow any configuration?

Maybe we just set it to 3 and don't allow any configuration?

I would be ok with that. Another solution would be to use functional options . I would be ok with any of the following solutions:

using a struct config
omitting the parameter and just setting the value to 3
keeping the int parameter as is
using functional options

I think all those solutions are preferable to using an interface type

@tamirms can you take a look again?


Add the gesture support

The code is as follows:
HUD.show(.labeledImage(image: nil, title: "test", subtitle: "hello world"))
PKHUD.sharedHUD.contentView .addGestureRecognizer(UITapGestureRecognizer(target: self, action: #selector(MyTableViewController.test)))

I want users to click on the screen, manually hide the hud, but i cant's get the maskView point,I don't have permission to access “container”  property

Sorry but I don't think this is necessary.


Remove dist files from the repo

I think we should discuss about doing this. They bloat the repo and its history a lot. And assuming we have a proper solution for releasing, which I think we do, we should be covered.
/CC @twbs/team

As you may read in how to publish your package on npm?, it's pretty easy to ignore dist/ folder from Git and still publish it to npm, by:

[ ] ignoring dist/ from Git in the .gitignore file,
[ ] adding dist/ folder to the npm package by adding it to the files entry in package.json.

I'm also thinking about this for our own fork (see Boosted #203) but haven't look further.
FWIW the first comment mentions publishing on Composer and NuGet, that may need dist files…

I think it's a good move to remove our dist files, we don't need to keep those files in our repositories.
So LGTM 👍

Removed from the v5 release for now.
Possibly dumb question, but does our test for bundle size need to have the dist files in the repo?

@mdo, in the github actions script bundle size runs after the dist files are generated (by npm test):
https://github.com/twbs/bootstrap/blob/aa95f6d618691a8e14770106bb9dc5e75ea4170c/.github/workflows/test.yml#L41-L48

My main concern is breaking any package managers that might expect the dist folder in the repo.

Composer needs the dist folder indeed.

What if we only include the dist files in the commits we're going to publish?

I don't think that makes sense.
Hence why I suggest dropping any package managers that don't make sense for our use case.

We could also drastically reduce the number of files we generate and track in the dist directory. At this point, there's no reason to be including bootstrap.css when we have bootstrap.min.css—the former should just be to start.
If we do that, we nix eight CSS files (CSS and their source maps, since those are duplicated for regular and minified CSS) and another six JS files (once again for source maps and regular/minified duplication).
I don't mind the files being there. I remember there being some issues with changing around our files strategy for package managers previously—including dropping Bower—and that was a bit of an issue.

Thoughts on the above comment for dropping the non-minified CSS files?

I think only composer is the problem here, only they rely on git. But:

Composer is a Dependency Manager for PHP, not for frontend assets
In many cases the vendor folder containing the packages is not accessible by web for security reasons, so the assets should be copied our symlinked, a setup which I think is very unlikely to have.

Imo, it's a good idea to drop composer support. We should encourage developers to use the right tools like npm

I don't mind the files being there.

I do 😛 It's annoying to see unrelated changes when I use git status or git diff.

It seems there's also something called Meteor (we mention this on our homepage). I think this refers to https://atmospherejs.com/twbs/bootstrap and it seems like we didn't update this since v3.
Related: https://github.com/twbs/bootstrap/issues/29431

FWIW, I can work around this for NuGet package. I'll just add a step to run npm dist to build to dist/ locally, then run scripts to build the packages from that. I agree that pattern makes more sense than tracking the dist/ folder in git.

I'll just add a step to run npm dist to build to dist/ locally, then run scripts to build the packages from that. I agree that pattern makes more sense than tracking the dist/ folder in git.

The thing is that this isn't safe. I mean, theoretically the builds should be reproducible, but the safest way would be to grap the release zip or use the npm package. Even if a single character is different, the integrity hashes will be different.

The only downside I see if we nuke the dist folder, apart from maybe breaking some package managers/integrations (which I'm going to be honest, I don't know for sure what will be), is that it can be handy to be able to see the dist file contents on GitHub.

Probably the best solution is to setup GH actions or some other tool to build, create a release, and then run all the deploy scripts to npm, nuget, etc. If any deploys fail, use the release zip to create the deploy. I don't know how much of this is automated currently but I am happy to work with the team on the nuget part.

Do we handle this in v5 or close as a won't fix?

Unfortunately, let's close it as won't fix for now. We need to drop some package managers if we want to go this way.


docs: fix wording related to route groups

Ah looks like the file is not formatted correctly. A quick deno fmt should resolve this.


Exec tachikoma update<PHONE_NUMBER>3331

:hamster::hamster::hamster:   Strategy none
Powered by Interval Pull Request as a Service - Tachikoma.io Announcement: 2015-06-28 Updated permissions - Tachikoma.io

Coverage remained the same at 67.647% when pulling 04dc6f20cf20ba3afe7f31e022f85186c1cdbf62 on pazjacket:tachikoma/update-20170806163331 into ec251e61adc687ae0589e5283f1773ece07521c0 on sanemat:master.

Coverage remained the same at 67.647% when pulling 04dc6f20cf20ba3afe7f31e022f85186c1cdbf62 on pazjacket:tachikoma/update-20170806163331 into ec251e61adc687ae0589e5283f1773ece07521c0 on sanemat:master.

Coverage remained the same at 67.647% when pulling 04dc6f20cf20ba3afe7f31e022f85186c1cdbf62 on pazjacket:tachikoma/update-20170806163331 into ec251e61adc687ae0589e5283f1773ece07521c0 on sanemat:master.


The script has an unsupported MIME type ('text/html')

Hi I've written a small project with create-react-app, it runs in the browser 'http://localhost:3000/' with 'npm start' but i'm seeing these two errors in the console:
The script has an unsupported MIME type ('text/html').  :3000/service-worker.js:1
GET http://localhost:3000/service-worker.js net::ERR_INSECURE_RESPONSE  :3000/service-worker.js:1

this is my package.json
{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "devDependencies": {
    "react-scripts": "0.4.1"
  },
  "dependencies": {
    "react": "^15.3.1",
    "react-dom": "^15.3.1",
    "react-redux": "^4.4.5",
    "redux": "^3.6.0"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "./node_modules/react-scripts/config/eslint.js"
  },
  "standard": {
    "globals": [
      "describe",
      "context",
      "before",
      "beforeEach",
      "after",
      "afterEach",
      "it",
      "expect"
    ]
  }
}

Can you please share your browser version and OS?

browser version: Version 53.0.2785.116 (64-bit)
os: OS X El Capitan version 10.11.6

Could you please show a screenshot? Thanks.

just created a new project from scratch, still getting this error.
screenshot here:
http://i.imgur.com/EjywosK.png

Interesting. Maybe some transitive dependency is doing something funny.
It’s not an error so you shouldn’t worry about it.
I’ll try to find what causes it when I’m back from vacation but feel free to jump in and investigate.

finally found the solution after days of 'googling' (ง'̀-'́)ง
run npm run prepublish inside the webpack-dev-server global library installed folder (/Users/bodaz/.npm-packages/lib/node_modules), and that seems fixed everything, the browser is back to normal and no more error messages at localhost:3000
for the record, the webpack version i had installed globally is webpack 1.13.2
and this is the link where i got my solution from: https://github.com/webpack/webpack-dev-server/issues/326

Why would a global webpack-dev-server matter? We don’t use the global version anywhere as far as I know.

Closing as it’s not clear how to reproduce this, and original author has resolved the problem.

i saw this message too. (chrome)
but the message wasn't reproduced during testing on safari and private mode chrome.
so it seems chrome's extension script error i installed.

I've been running in the same issue. The local version is<EMAIL_ADDRESS>Im running Windows 10, Chrome  56.0.2906.0 dev (64-bit).
At this point I'm clueless on what to do.

I got this issue after running npm run build on a new app, and moving the build folder to my express application which then served it.
It appears the helmet middleware was interfering with the client side caching, so if you have this issue on a node server, it may be worth checking this.

yes, I got this issue too, when I build my app and run it in a server side render application in express, the chrome show those two errors

Maybe I'm wrong, the error is about service worker has been register for localhost:3000.
Can you open Chrome Dev Tools -> Application -> Service Worker and see if you have a service worker has been registered? If yes click unregister and refresh the page again.

@n3tr  thanks, yes, you are right, I remember I test some app  before and register the service work, now as your step, I unregister the service work and it goes fine

Thanks, n3tr's trick definitely solves the problem 👍

testing this on firebase hosting still produces the same error..
but curious that it didn't do this for previous deploys.

me too!

If you have this problem and this discussion doesn't help please file a new issue and fill the template. Provide a project reproducing this.
Further +1's are not helpful so I am locking this.


Separate surround_obstacle_checker from hierarchical planning flow by using external velocity limit

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I've agreed with the maintainers that I can plan this task.

Description
The function of surround_obstacle_checker is to keep the stopped state when the vehicle is stopped and there are obstacles around the vehicle. In current implementation, the feature is achieved by inserting ZERO velocity into trajectory in the hierarchical motion planning flow.
On the other hand, the feature is also achieved by using external velocity limit with simpler implementation. (no need to insert stop point)
Purpose

separate surround_obstacle_checker from hierarchical planning flow.
simplify surround_obstacle_checker implementation. (not handling trajectory topic in the node)

Possible approaches

use external velocity limit in surround_obstacle_checker
insert ZERO velocity in motion_velocity_smoother

Definition of done

achieve the feature of surround_obstacle_checker by using external velocity limit

cc @TakaHoribe @yukkysaito


Changing the body of a response object after the baseplate tween has run causes no content to be returned

Between v1.4 and v1.5, Pyramid applications that map an exception to a view (@view_config(context=MyException)) lost the ability to control the body of the response. In fact, the body appears to be completely blank always in this case.
Minimal reproduction: https://github.com/reddit/baseplate.py/compare/develop...spladug:exception-body-disappears-when-streaming?expand=1
It appears to have been introduced in https://github.com/reddit/baseplate.py/pull/489

Spent some time digging into this today. It looks like HTTPException classes set their own body/app_iter after we've patched our app_iter wrapper on. This theoretically could happen with custom response objects too so it's not just specific to this case.
I'm looking at ways of patching the app_iter property so that writes to it are proxied through the wrapper object, but this is all quite brittle and attached to the guts of webob's response object.

Closed by #739


[Avocado] fails on "missing APIs in default tag" even if they have been deprecated and/or removed

Avocado fails on "missing APIs in default tag" even if they have since been deprecated:
https://github.com/Azure/azure-rest-api-specs-pr/pull/13388/checks?check_run_id=15510029187
Teams discussion here.

Another case:

https://github.com/Azure/azure-rest-api-specs/pull/24771#issuecomment-1660776189
Teams discussion


feat: enable Virtualization.framework and Rosetta

Issue #, if available: Closes #218
Description of changes:
Adds support for Lima's Virtualization.framework and Rosetta features, through the use of new finch.yaml configuration options (vmType and rosetta). vmType also sets the mountType to virtiofs, since that is only available when using Virtualization.framework.
To support this, a few things needed to be changed on our side:

Disk migration. Although https://github.com/lima-vm/lima/pull/1405 (which adds persistent disk support to vmType: vz in Lima) will auto-convert persistent disks from QCOW2 to RAW when they are attempted to be used with vmType: vz, because of the way our disks are persisted with symlinks, we also have to do this
Move some hardcoded lima config from finch.yaml to be programatically toggled in pkg/config/lima_config_applier

This allows things like the qemu user mode scripts to be installed only when they are needed. Installing them all the time, and then trying to use Rosetta as a binformat_misc handler causes conflicts
This also opens up possibilities of future customization based on Finch's config values

Currently, because https://github.com/lima-vm/lima/pull/1405 is not merged yet, this PR references a specific branch of my own finch-core repo which includes the Lima change already. It also edits the Makefile to do a build of Lima from the submodule directly, and overwrite the Lima downloaded from the archive. These changes will be removed once the Lima change is merged upstream.
Testing done:

unit tests

e2e tests

local testing on Intel and Apple Silicon machines

[x] I've reviewed the guidance in CONTRIBUTING.md

License Acceptance
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

All of the lint failures finally helped me fix my lint-on-save. Apparently I had to do a >Go: install/update tools in VSCode. It was throwing a very cryptic error before that https://github.com/golangci/golangci-lint/issues/3533.

Need e2e tests and README.md change

Need e2e tests and README.md change

Added some basic e2e tests for the two new scenarios and updated the README.

Merging, and will investigate the Rosetta test failure as a separate issue


Feat/early stop

Waiting for benchmarks.

Without .metric_valid_numeric(LossMetric::new()), it will disable the early stop:
2023-10-23T10:07:13.474593Z  WARN burn_train::learner::early_stopping: Can't find metric for early stopping.

However, it induces panic if I add .metric_valid_numeric(LossMetric::new()):
thread '<unnamed>' panicked at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/d263968/burn-train/src/logger/file.rs:26:14:
called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/d263968/burn-train/src/metric/store/client.rs:35:56:
called `Result::unwrap()` on an `Err` value: SendError { .. }
thread '<unnamed>' panicked at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/d263968/burn-train/src/metric/store/client.rs:142:40:
called `Result::unwrap()` on an `Err` value: SendError { .. }
stack backtrace:
   0:        0x100f3c698 - std::backtrace_rs::backtrace::libunwind::trace::h815672f5996c9e34
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:        0x100f3c698 - std::backtrace_rs::backtrace::trace_unsynchronized::h2e094b2d8c270437
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x100f3c698 - std::sys_common::backtrace::_print_fmt::hae24b71afea95695
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:67:5
   3:        0x100f3c698 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h6d4268b2ed62fb94
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:44:22
   4:        0x100f5b0b4 - core::fmt::rt::Argument::fmt::h835101b6de0df17f
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/fmt/rt.rs:138:9
   5:        0x100f5b0b4 - core::fmt::write::h5d55d44549819258
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/fmt/mod.rs:1094:21
   6:        0x100f3967c - std::io::Write::write_fmt::h1da98de0250c868b
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/io/mod.rs:1714:15
   7:        0x100f3c4d8 - std::sys_common::backtrace::_print::h5844dab5cfa39fca
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:47:5
   8:        0x100f3c4d8 - std::sys_common::backtrace::print::h2c300c1ebedfc73c
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:34:9
   9:        0x100f3e0e0 - std::panicking::default_hook::{{closure}}::h0aa9be5c44269370
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:270:22
  10:        0x100f3dd68 - std::panicking::default_hook::h2c0ef097934ee9e6
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:287:9
  11:        0x100d34f40 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hb681ba0e6970f985
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2021:9
  12:        0x100d34f40 - test::test_main::{{closure}}::h139556dd544e4d62
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/test/src/lib.rs:136:21
  13:        0x100f3e760 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h9b865254accc03e0
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2021:9
  14:        0x100f3e760 - std::panicking::rust_panic_with_hook::h84c8637cb6e56008
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:711:13
  15:        0x100f3e534 - std::panicking::begin_panic_handler::{{closure}}::h25482adda06c7b7f
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:599:13
  16:        0x100f3cb24 - std::sys_common::backtrace::__rust_end_short_backtrace::h0c6f3beb22324a29
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:170:18
  17:        0x100f3e298 - rust_begin_unwind
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
  18:        0x100f7b978 - core::panicking::panic_fmt::h9072a0246ecafd14
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
  19:        0x100f7bca0 - core::result::unwrap_failed::hd7600d03a3086be4
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/result.rs:1652:5
  20:        0x100d677c4 - <burn_train::metric::store::client::EventStoreClient as core::ops::drop::Drop>::drop::hac3de293bc98f87c
  21:        0x100cc20c0 - alloc::sync::Arc<T,A>::drop_slow::h4ad631dee4a040b0
  22:        0x100ceeed0 - burn_train::learner::train_val::<impl burn_train::learner::base::Learner<LC>>::fit::h68ffa49241ff58b3
  23:        0x100cca358 - fsrs::training::train::h5bb166eb7e87e2a1
  24:        0x100cd66a4 - core::ops::function::impls::<impl core::ops::function::FnMut<A> for &F>::call_mut::hdc95c68496afae6a
  25:        0x100d098cc - rayon::iter::plumbing::Folder::consume_iter::h212f6420163efdbc
  26:        0x100d08eec - rayon::iter::plumbing::bridge_producer_consumer::helper::h8e4caaae11adfbdb
  27:        0x100c09980 - rayon_core::join::join_context::{{closure}}::h6a27a073252e59e7
  28:        0x100d08f9c - rayon::iter::plumbing::bridge_producer_consumer::helper::h8e4caaae11adfbdb
  29:        0x100c56fd0 - <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::hb04848c2d7031caa
  30:        0x100f778a4 - rayon_core::registry::WorkerThread::wait_until_cold::hd933cbd892a425c5
  31:        0x100c09364 - rayon_core::join::join_context::{{closure}}::h5a47a8a9661a6cda
  32:        0x100d08bf4 - rayon::iter::plumbing::bridge_producer_consumer::helper::h6742b0a3a0de3f6b
  33:        0x100c56da8 - <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::hae76227955ff1fe8
  34:        0x100f778a4 - rayon_core::registry::WorkerThread::wait_until_cold::hd933cbd892a425c5
  35:        0x100f13854 - rayon_core::registry::ThreadBuilder::run::hac19021355221cc4
  36:        0x100f15b74 - std::sys_common::backtrace::__rust_begin_short_backtrace::h12f5dea2e54a2c2d
  37:        0x100f18b1c - core::ops::function::FnOnce::call_once{{vtable.shim}}::hac809be33ae58ba8
  38:        0x100f42344 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hee56534d4cc78b31
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2007:9
  39:        0x100f42344 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hf1a328a6507f3fa7
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2007:9
  40:        0x100f42344 - std::sys::unix::thread::Thread::new::thread_start::h6244aa8f646b01ac
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys/unix/thread.rs:108:17
  41:        0x1959a7fa8 - __pthread_joiner_wake
thread '<unnamed>' panicked at library/core/src/panicking.rs:126:5:
panic in a function that cannot unwind
stack backtrace:
   0:        0x100f3c698 - std::backtrace_rs::backtrace::libunwind::trace::h815672f5996c9e34
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:        0x100f3c698 - std::backtrace_rs::backtrace::trace_unsynchronized::h2e094b2d8c270437
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x100f3c698 - std::sys_common::backtrace::_print_fmt::hae24b71afea95695
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:67:5
   3:        0x100f3c698 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h6d4268b2ed62fb94
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:44:22
   4:        0x100f5b0b4 - core::fmt::rt::Argument::fmt::h835101b6de0df17f
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/fmt/rt.rs:138:9
   5:        0x100f5b0b4 - core::fmt::write::h5d55d44549819258
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/fmt/mod.rs:1094:21
   6:        0x100f39768 - std::io::Write::write_fmt::hc515897f91abd6cf
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/io/mod.rs:1714:15
   7:        0x100f3c4d8 - std::sys_common::backtrace::_print::h5844dab5cfa39fca
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:47:5
   8:        0x100f3c4d8 - std::sys_common::backtrace::print::h2c300c1ebedfc73c
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:34:9
   9:        0x100f3e0e0 - std::panicking::default_hook::{{closure}}::h0aa9be5c44269370
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:270:22
  10:        0x100f3de0c - std::panicking::default_hook::h2c0ef097934ee9e6
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:290:9
  11:        0x100d34f40 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hb681ba0e6970f985
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2021:9
  12:        0x100d34f40 - test::test_main::{{closure}}::h139556dd544e4d62
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/test/src/lib.rs:136:21
  13:        0x100f3e760 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h9b865254accc03e0
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2021:9
  14:        0x100f3e760 - std::panicking::rust_panic_with_hook::h84c8637cb6e56008
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:711:13
  15:        0x100f3e4f8 - std::panicking::begin_panic_handler::{{closure}}::h25482adda06c7b7f
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:597:13
  16:        0x100f3cb24 - std::sys_common::backtrace::__rust_end_short_backtrace::h0c6f3beb22324a29
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:170:18
  17:        0x100f3e298 - rust_begin_unwind
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
  18:        0x100f7b9a8 - core::panicking::panic_nounwind_fmt::ha4f6bbf8fe9fb5ae
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:96:14
  19:        0x100f7ba24 - core::panicking::panic_nounwind::ha756411eedbc9594
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:126:5
  20:        0x100f7ba94 - core::panicking::panic_cannot_unwind::h496677c8c27b4397
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:189:5
  21:        0x100ceeedc - burn_train::learner::train_val::<impl burn_train::learner::base::Learner<LC>>::fit::h68ffa49241ff58b3
  22:        0x100cca358 - fsrs::training::train::h5bb166eb7e87e2a1
  23:        0x100cd66a4 - core::ops::function::impls::<impl core::ops::function::FnMut<A> for &F>::call_mut::hdc95c68496afae6a
  24:        0x100d098cc - rayon::iter::plumbing::Folder::consume_iter::h212f6420163efdbc
  25:        0x100d08eec - rayon::iter::plumbing::bridge_producer_consumer::helper::h8e4caaae11adfbdb
  26:        0x100c09980 - rayon_core::join::join_context::{{closure}}::h6a27a073252e59e7
  27:        0x100d08f9c - rayon::iter::plumbing::bridge_producer_consumer::helper::h8e4caaae11adfbdb
  28:        0x100c56fd0 - <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::hb04848c2d7031caa
  29:        0x100f778a4 - rayon_core::registry::WorkerThread::wait_until_cold::hd933cbd892a425c5
  30:        0x100c09364 - rayon_core::join::join_context::{{closure}}::h5a47a8a9661a6cda
  31:        0x100d08bf4 - rayon::iter::plumbing::bridge_producer_consumer::helper::h6742b0a3a0de3f6b
  32:        0x100c56da8 - <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::hae76227955ff1fe8
  33:        0x100f778a4 - rayon_core::registry::WorkerThread::wait_until_cold::hd933cbd892a425c5
  34:        0x100f13854 - rayon_core::registry::ThreadBuilder::run::hac19021355221cc4
  35:        0x100f15b74 - std::sys_common::backtrace::__rust_begin_short_backtrace::h12f5dea2e54a2c2d
  36:        0x100f18b1c - core::ops::function::FnOnce::call_once{{vtable.shim}}::hac809be33ae58ba8
  37:        0x100f42344 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hee56534d4cc78b31
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2007:9
  38:        0x100f42344 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hf1a328a6507f3fa7
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/alloc/src/boxed.rs:2007:9
  39:        0x100f42344 - std::sys::unix::thread::Thread::new::thread_start::h6244aa8f646b01ac
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys/unix/thread.rs:108:17
  40:        0x1959a7fa8 - __pthread_joiner_wake
thread caused non-unwinding panic. aborting.
error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `/Users/jarrettye/Codes/open-spaced-repetition/fsrs-rs/target/release/deps/fsrs-b7858974c2ace16a` (signal: 6, SIGABRT: process abort signal)

@dae, @nathanielsimard, could you help me?

@dae, @nathanielsimard, could you help me?

Can you verify that the file actually exists, early stopping is reading the file logged at {{artifact}}/valid/epoch-1/Loss.log. The error message is missing information, I'll try to improve that!

Can you verify that the file actually exists, early stopping is reading the file logged at {{artifact}}/valid/epoch-1/Loss.log.

To speed up the training, dae disabled the logger. I think it's unsafe to read file during training. And the file would also induce other errors. For example, our project trains the model concurrently. So the log file will be written by multiple logger. It causes float number parsing error.

@L-M-Sherlock Early stopping involves using metrics collected through loggers with an event store. If you are using burn-train to collect metrics, there should be no concurrency errors, as each logger operates on its own thread and communicates through a channel. This setup makes it unlikely to slow down the training process. Parsing errors may occur, but they are generally only a concern if there is file corruption, which is rare since the file is always accessed by the same thread.
There is also an in-memory logger available, but it would consume a significant amount of RAM to store all events in-memory. However, it can be a viable option if your intention is to only use LossMetric.
I'm going to enable that option with the builder!

@L-M-Sherlock
In fact you can already enable it with the following:
builder
        .metric_loggers(InMemoryMetricLogger::new(), InMemoryMetricLogger::new())

Let me know if it helps!

@L-M-Sherlock we could probably solve the file corruption issue by using a separate artifact dir for each of the training runs we invoke, but I'd suggest we try the in-memory approach first, as I'd like to avoid file I/O if possible.

It improves the model slightly: https://github.com/open-spaced-repetition/fsrs-benchmark/commit/665a423744ce21576f9da8448ccdf3942abb5c01

Curiously, I get different results when I rebuild the result files on my machine:
dae@dtop:~/fsrs-benchmark% grep 'FSRS-rs ' ~/eval.1 # based on the files you checked in
FSRS-rs mean: 0.3851
FSRS-rs mean: 0.3324
FSRS-rs mean: 0.0577
dae@dtop:~/fsrs-benchmark% grep 'FSRS-rs ' ~/eval.2 # after removing the files and rebuilding them using latest burn-rs, THREADS=32 FSRS_RS=1
FSRS-rs mean: 0.3858
FSRS-rs mean: 0.3326
FSRS-rs mean: 0.0583

@dae If you use multiple threads to load the data, then the order in which the items are loaded isn't deterministic. It might explain the difference.

Sorry, I probably shouldn't have mentioned THREADS - we use that for processing different files in parallel, so it shouldn't affect things. But it does appear we have some non-determinism somewhere in our code, as back-to-back runs are producing different values.

If you use multiple workers for the dataloader, you have non-determinism!

We use a single worker for the dataloader. We're running multiple training runs in parallel, with separate data, and then determining the mean values of the outputs.
@L-M-Sherlock maybe it's caused by the use of a hashmap in filter_outlier?

maybe it's caused by the use of a hashmap in filter_outlie

It is only used by the pretrain.


chore(master): release 1.1.0

:robot: I have created a release beep boop
1.1.0 (2024-05-27)
Features

added build script for typewriter component (985f336)

Bug Fixes

updated the release please config (8cd0b27)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/iabu94/ngx-simple-typewriter/releases/tag/v1.1.0 :sunflower:


Fix NPE that occurs when getting topic fails

Motivation
NPE issue reported on Pulsar Slack.
NPE happens at https://github.com/streamnative/kop/blob/v<IP_ADDRESS>/kafka-impl/src/main/java/io/streamnative/pulsar/handlers/kop/KafkaTopicManager.java#L81
Modifications

reorder conditions in if statement so that a possible throwable is checked first. This prevents NPE
when a throwable is present and the persistentTopic is null

[x] no-need-doc

Oh I got it. whenComplete could returns null when it complete exceptionally. Good catch!


TestWindow is out of sync with SingletonFlutterWindow

TestWindow is supposed to implement the interface of SingletonFlutterWindow, but some methods are missing:  @override

onFrameDataChanged
onKeyData
computePlatformResolvedLocale
frameData
physicalGeometry

This should have been caught by the analyzer, but because of the presence of a noSuchMethod method, it wasn't, sadly.

Hi @goderbauer
Per TestWindow and SingletonFlutterWindow, they are deprecated and will be removed in a future version. So, will those methods still be implemented or not?

These properties have been added to the TestFlutterView and TestPlatformDispatcher classes, which are replacing the deprecated TestWindow class. So, there's nothing left to do here. Thanks for flagging!


Data catalog Tag module

Data catalog Tag module. This is a simple module. The main reason for creating a module is the Tag factory.

Checklist

I applicable, I acknowledge that I have:

[x] Read the contributing guide
[x] Ran terraform fmt on all modified files
[x] Regenerated the relevant README.md files using tools/tfdoc.py
[x] Made sure all relevant tests pass

This looks great! Thanks Lorenzo.

Thanks @wiktorn. From my experience, multiple Tag can be assigned to a resource (e.g. multiple tag on a dataset, less common for columns).
I think location can be different, but I am going to use this module in 2 customers really soon and I will check the structure of the module with reality of customer needs. I will update the module accordingly.


Week #2: Improving the classical GANs and start building an early QGANs.

[ ] Re-train the DijetGAN model with several GANs losses (Wasserstein loss, etc.).
[ ] Try several GANs metrics (chi-square, Wasserstein distance).
[ ] Build an early Quantum GANs model.

We should also rescale the data in the range[0,1].

We should also rescale the data in the range[0,1].

I think for the classical model, we can leave it as it is because it doesn't really matter which range we use.
But I will add it for the quantum case. Thanks!

I'll try to adjust the PyTorch model according to the DijetGAN approach


Error message for conflicting dep versions is confusing when VersionTypes are different

What version of dep are you using (dep version)?
++> dep version
dep:
 version     : devel
 build date  :
 git hash    :
 go version  : go1.9.1
 go compiler : gc
 platform    : darwin/amd64

What dep command did you run?
++> dep ensure
...
master: Could not introduce github.com/myorg/myproject@master, as it has a dependency on google.golang.org/grpc with constraint master, which has no overlap with existing constraint master from (root)

What did you expect to see?
The initial error I got was:
master: Could not introduce github.com/myorg/myproject@master, as it has a dependency on google.golang.org/grpc with constraint 1.6.0, which has no overlap with existing constraint master from (root)

Which made sense. In one place I was pinning to grpc's master branch and in another place I was pinning to the version 1.6.0.
So, not noticing that branch = and version = were different, I attempted to update my Gopkg.toml file so that both were on master, but did not switch to branch =:
[[constraint]]
  version = "master"
  name = "google.golang.org/grpc"

I expected to see an error message that indicated the actual issue (that I was using version = master instead of branch = master):
master: Could not introduce github.com/myorg/myproject@master, as it has a dependency on google.golang.org/grpc with constraint master (branch), which has no overlap with existing constraint master (revision) from (root)

What did you see instead?
What I got instead was a very confusing error message, telling me the I had conflicting versions master != master.
master: Could not introduce github.com/myorg/myproject@master, as it has a dependency on google.golang.org/grpc with constraint master, which has no overlap with existing constraint master from (root)

I am working on an easy fix for this!

Let me know if you like this approach and if yes where else we might want to improve the error messaging (just fixed it where I saw it being an issue).

ugh, yeah, this is definitely horribly confusing.
i got stuck on dealing with this about a year ago, as i wanted a more general solution for visually representing both version/constraint type AND the value itself - and, tbh, that hasn't changed. it would probably take a bit of time to grok the version system, then the constraint system (which undergird versions), but i'm worried that fixing it only in the one place would be harmful to the overall comprehensibility of error output by undermining its consistency.
if you're willing to dig in on grokking that bigger picture and trying to come up with a coherent, overall solution, i'm 💯 💯 happy to guide 🎉 😄

@sdboyer yeah i pushed that PR up as more of a POC of the issue. although the output code itself is pretty all over the place. would we wanna refactor that or just update all the places like I did in the original PR but just in every place?

@tylercloke my strong preference would be to introduce a more central abstraction and rely on that, then update it out at call sites as needed.
the balance here is between having a string output mode more tailored for this circumstance, while trying to minimize the amount of circumstance-specific method bloat we create. this is usually a difficult-to-resolve question in practice, but the process i generally take for it is looking at the set of cases where we use the existing stringification outputs of Versions, thinking about the new cases we have (i.e. this one, where it's really important to dump the underlying revision), and trying to decide on some criteria to use to decide if that case differs sufficiently from other outputs that we have to make a new method.
in other words, a very hand-wavy design process. what's blocked me from doing it thus far is mostly just doing the research on where all we stringify versions - if you were to undertake that part and report back a bit, then i think we could probably come to a reasonable agreement on the right design path pretty quickly 😄


Need to store Processes created by connect as instance variables if it is used within a ProcessModel of a Hierarchical Process.

Objective of issue:
State that currently, we cannot simply make use of lava-dnf's connect method to connect child Neural Processes of a Hierarchical Process without storing the Dense + 2 Reshape Processes as instance variables.
Background:
lava-dnf's connect method is supposed to be a high-lever helper method the user uses to create connections between two Neural Processes with connectivity matrix (synaptic weights) derived from a list of Operation objects given as argument.
Roughly, it does the following things :

Compute weights (connectivity matrix)
Create Dense Process

It returns the created Dense Process. The user chooses whether to use it (store it) or not.
That being said ;
Neural Processes currently available in the proc library (LIF Process) can by of any shape (N-D arrays).
The Dense Process from the proc library represent weights as 2-D arrays, which, implicitly, means the Neural Processes connected at both ends have to be 1-D arrays.
Ultimately, ReshapePort should be added either :

On the OutPort of Neural Processes to "virtually" reshape output with arbitrary shape to 1-D (N-D arrays to 1-D arrays), or
On the InPort and OutPort of the Dense Process to "virtually" reshape input with arbitrary shape to 1-D (N-D arrays to  1-D arrays) and "virtually" reshape output with 1-D shape to arbitrary shape (1-D arrays to M-D arrays).

As stated in #7, connect currently implement reshaping with dedicated Reshape Processes, i.e it additionally creates 2 Reshape Processes for each Dense Process created.

Lava version:

[x] 0.2.0

Lava-dnf version:

[x] 0.1.0

I'm submitting a ...

[x] bug report

Current behavior:

I want to create a Hierarchical Process (with ProcessModel inheriting from AbstractSubProcessModel).
Inside its __init__ definition, I want to connect connect child Neural Processes with the connect method.
Code snippet 1 contains the definition of an example of what I want to build.
Code snippet 2 contains the definition of a SourceProcess (created for testing purposes) that always sends an array full of ones.
When SourceProcess is connected to DNF, and the whole is run as is done in Code snippet 3, the ones sent from SourceProcess never reach the input_conn of DNF.
However ;

If the connect is tweaked so as to also return the created Reshape Processes, and
If the DNFProcessModel is tweaked so as to store the Reshape Processes as instance variables

Ones reach the Dense Process.
I suspect this has something to do with the way the Builder creates instances of AbstractSubProcessModel and their child Process at compile time.
I think when the overall network is compiled, if an instance of AbstractSubProcessModel defines child process, it has to store them as instance variables, otherwise they are discarded from compilation.
Namely, I suspect that is what happens for Reshape Processes created in the connect method in our case.
If the Reshape Process at the input side of the Dense Process created by connect doesn't get compiled, the data sent by SourceProcess never reaches the Dense Process.
Related code:

Code snippet 1 :

class DNF(AbstractProcess):
    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        shape = validate_shape(kwargs.pop("shape"))

        self.u = Var(shape=shape, init=np.zeros(shape))

        self.s_in = InPort(shape=shape)

        self.s_out = OutPort(shape=shape)

@implements(proc=DNF, protocol=LoihiProtocol)
class DNFProcessModel(AbstractSubProcessModel):
    def __init__(self, proc):
        shape = proc.init_args.get("shape")

        self.population = LIF(shape=shape, du=409, dv=2047, vth=200)

        self.input_conn = connect(proc.in_ports.s_in, self.population.a_in, [Weights(25)])
        kernel = MultiPeakKernel(amp_exc=83, width_exc=3.75, amp_inh=-70, width_inh=7.5)
        self.recurrent_conn = connect(self.population.s_out, self.population.a_in, [Convolution(kernel)])

        self.population.s_out.connect(proc.out_ports.s_out)

        proc.vars.u.alias(self.population.vars.u)

Code snippet 2 :

class SourceProcess(AbstractProcess):
    """
    Process that sends arbitrary vectors

    Parameters
    ----------
    shape: tuple, shape of the process
    """

    def __init__(self,
                 **kwargs: ty.Union[ty.Tuple, np.ndarray]) -> None:
        super().__init__(**kwargs)
        shape = kwargs.get("shape")
        data = kwargs.get("data")

        self.data = Var(shape=shape, init=data)
        self.a_out = OutPort(shape=shape)

@implements(proc=SourceProcess, protocol=LoihiProtocol)
@requires(CPU)
@tag("bit_accurate_loihi")
class SourceProcessBoolModel(PyLoihiProcessModel):
    data: np.ndarray = LavaPyType(np.ndarray, bool)
    a_out: PyOutPort = LavaPyType(PyOutPort.VEC_DENSE, bool)

    def run_spk(self) -> None:
        """Send data every timestep"""
        self.a_out.send(self.data)

Code snippet 3 :

def main():
    shape = (20, )

    run_cfg = Loihi1SimCfg(select_tag="bit_accurate_loihi",
                           select_sub_proc_model=True)
    condition = RunSteps(num_steps=10)

    source = SourceProcess(shape=shape, data=np.ones(shape, dtype=bool))
    dnf = DNF(shape=shape)

    source.a_out.connect(dnf.s_in)

    dnf.run(condition=condition, run_cfg=run_cfg)

    dnf.stop()

if __name__ == '__main__':
    main()

``I think my suspicions were correct :

In the _map_proc_to_model method of the Compiler class (in compiler.py), which corresponds to one of the "steps" of compilation, there is the following lines of code :

if issubclass(model_cls, AbstractSubProcessModel):
      # Recursively substitute SubProcModel by sub processes
      sub_map = self._expand_sub_proc_model(model_cls, p, run_cfg)
      proc_map.update(sub_map)

I think these lines take care of searching for nested child Processes of a Hierarchical Process to add them to the list of Processes to be compiled.

Later in the  _expand_sub_proc_model method, there is the following lines :

sub_procs = model.find_sub_procs()
proc.register_sub_procs(sub_procs)

These lines execute the find_sub_procs method of the instance of AbstractSubProcessModel to find the sub_procs and register them.

As expected, the find_sub_procs of AbstractSubProcessModel goes through the list of attr of the object and return those that are of type Processes.

    def find_sub_procs(self) -> ty.Dict[str, AbstractProcess]:
        """Finds and returns all sub processes of ProcessModel."""
        procs = OrderedDict()
        for attr_name in dir(self):
            attr = getattr(self, attr_name)
            if isinstance(attr, AbstractProcess):
                procs[attr_name] = attr
        return procs

This means that if a child Process to a Hierarchical Process is not stored as an instance variable (as an attr), it will not be returned by the find_sub_procs method and consequently would not be registered for compilation by the compiler.

@gkarray Could you please review this, check whether it is still an issue, and turn it into a user story?

Closing this issue as it seems that it was solved after changing the use of the Reshape Processes to ReshapePorts.


[ISSUE #2990] Add message tracing switch in sendMessage command of mqadmin

Make sure set the target branch to develop
What is the purpose of the change
Add message tracing switch in sendMessage command of mqadmin
Brief changelog
Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.06%) to 53.975% when pulling 2fe6dc3034f3d886227c0afbade7ad785e5f9edc on yuz10:develop4 into 52348b862c0dda897764c3b51fe1436c1a5ae0fe on apache:develop.

Codecov Report

Merging #2991 (2fe6dc3) into develop (52348b8) will decrease coverage by 0.21%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             develop    #2991      +/-   ##
=============================================
- Coverage      47.91%   47.69%   -0.22%
+ Complexity      4560     4538      -22
=============================================
  Files            552      552
  Lines          36628    36628
  Branches        4844     4844
=============================================
- Hits           17549    17470      -79
- Misses         16857    16927      +70
- Partials        2222     2231       +9

Impacted Files
Coverage Δ

...ain/java/org/apache/rocketmq/test/util/MQWait.java
43.24% <0.00%> (-10.82%)
:arrow_down:

...org/apache/rocketmq/common/stats/StatsItemSet.java
43.28% <0.00%> (-8.96%)
:arrow_down:

...org/apache/rocketmq/store/ha/WaitNotifyObject.java
71.15% <0.00%> (-7.70%)
:arrow_down:

...a/org/apache/rocketmq/logging/inner/SysLogger.java
28.57% <0.00%> (-5.72%)
:arrow_down:

...in/java/org/apache/rocketmq/test/util/MQAdmin.java
38.88% <0.00%> (-5.56%)
:arrow_down:

...apache/rocketmq/remoting/netty/ResponseFuture.java
85.00% <0.00%> (-5.00%)
:arrow_down:

...java/org/apache/rocketmq/logging/inner/Logger.java
51.67% <0.00%> (-4.31%)
:arrow_down:

...rocketmq/remoting/netty/NettyRemotingAbstract.java
46.86% <0.00%> (-4.06%)
:arrow_down:

...ava/org/apache/rocketmq/test/util/VerifyUtils.java
46.26% <0.00%> (-2.99%)
:arrow_down:

...ava/org/apache/rocketmq/filter/util/BitsArray.java
59.82% <0.00%> (-2.57%)
:arrow_down:

... and 9 more

Continue to review full report at Codecov.

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


0xC0000017 (Not enough virtual memory or paging file quota is available to complete the specified operation.)

Brief description of your issue
I caused Process Hacker 3.0.4600 to crash.
Steps to reproduce (optional)
Open this one xml file in Firefox while Process Hacker is running

ProcessHacker_HPYSHADOWUWTSZW_DumpFile.zip
.
Expected behavior (optional)
I expected Process Hacker to not crash.
Actual behavior (optional)
Process Hacker crashes.
Environment (optional)
Process Hacker 3.0.4600
Windows x64 10.0.19044.1586

0xC0000017 (Not enough virtual memory or paging file quota is available

VirtualAlloc failed to allocate 292KB of memory which is not possible:

Open this one xml file in Firefox

This DLL inserted hooks for the allocation functions and likely caused the failure:

I don't know why this page says that I added the "bug" and "needs investigation" labels, because I did no such thing.
But thank you for the response @dmex.  You're saying that it's Avast's fault, eh?

I don't know why this page says that I added the "bug" and "needs investigation" labels

The tags are automatically added for bug reports. Select blank issue from the new issue page when you don't want tags.

You're saying that it's Avast's fault, eh?

The system heap failed to allocate ~300KB which is not possible because Windows would have crashed or used the page file. The dump file made no sense so the only logical answer is faulty hardware or something hooking system functions.


Version 22+ breaks usage of module inside Azure DevOps pipeline when docker container with SQL server is used for integration testing

We are experiencing issues regarding connecting to db in v 22+.
We have Azure devOps pipeline that creates docker container with MsSQL server version 2019 as a pipeline resource. We then connect to server and try to create integration tests database. With version 22+ we have issue that pre-handshake failed.
Our Azure pipeline snippet :

Error that we get when running pipeline:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught)

Current workaround is not to use v 22+. So we had to request -RequiredVersion 21.1.18256 version in order for our pipeline to work as before.

Hi @crega,
This is the expected breaking change as per roadmap to secure-by-default.
The simple workaround in your case (since you trust your server certificate) would be to use -TrustServerCertificate at line 58 of your script.


Docker Hub repo emqttd/emqttd out of date

Description
Is the emqttd/emqttd repo at https://hub.docker.com/r/emqttd/emqttd/ maintained by this project? It appears to still be on version 0.17.

@Densaugeo No. We don't know who occupied the emqttd organization on docker hub;)
Download the latest docker image from: http://emqtt.io/downloads/latest/docker

Too bad someone took the name. Guess there's not much you can do about that, so I'll close this.


Allow more nodes to be discretely controlled

Currently only controlling Pump is supported for DiscreteControl. If I am not mistaken, the following node types need the option of being discretely control too.

[ ] FractionalFlow
[ ] LinearResistance
[ ] ManningResistance

To achieve this in the way it is currently implemented for Pump, the following is needed per AffectNodeType:

The AffectnodeType \ static table has to have a control_state column;
The node in question has to be allowed downstream of the DiscreteControl node in neighbortypes(::Val{:Control}) in validation.jl;
The AffectNodeType struct has to have a control_mapping field which has to be constructed in function AffectNodeType. Here I propose a separate function to handle this construction as in function Pump to reduce boilerplate code.

[ ] FractionalFlow : yes
[ ] LevelBoundary: no, in my opinion we should consider boundary nodes alwasy as externally fixed/forced and not influenced by the model
[ ] FlowBoundary: no, see LevelBoundary
[ ] LinearResistance: maybe, to be discussed/decided
[ ] ManningResistance: maybe, to be discussed/decided

LinearResistance and ManningResistance should be able to change over time to represent vegetaion differences in summer/winter.
We also should be able to open and close a connection via control, but I would think that Resistance connectors is not the type of connection to use at that moment.
I am missing:

[ ] TabulatedRatingCurve which is being addressed in #348

Controlling FractionalFlow needs to be done first.


composedClassLists order completely wrong on new Vite compiler

Describe the bug
Branching off https://github.com/vanilla-extract-css/vanilla-extract/issues/1424 since this is a separate issue.
Please check out the repro repo:
https://github.com/otaviomad/ve-bug-repro/tree/other-bug (with current version compiler)
https://github.com/otaviomad/ve-bug-repro/tree/other-bug-non-vite (with previous version compiler)
If you run pnpm run-many -t build && pnpm storybook you can get them started. (The readme is wrong, I was working on another bug with the same repo base)
We have a base class, which extends another class:

We have a button, which extends said base class:

Then we have a stepper container class, which also extends said base class:

And finally, we have a child of the stepper container which has a composite selector for both of the previous components:

This is the generated CSS:

As you can see, the base class is sandwiched between the stepper container and the button class, breaking the css.
I believe this issue occurs due to the new way that the class registration happens in the Vite compiler. After some investigation I have found the following:
This is how composedClassLists looked like in the old compiler, before being reversed by transformCss:

Notice how it goes from base -> button -> stepper, which is the correct order in the module graph.
This is how composedClassLists looks inside the new compiler, also before reverse ordering:

Notice how now stepper comes first, completely breaking the order. What's more, this is import order relevant. In our stepper, we're now importing "base" before "button", but if we change that order, the array order is also changed:

I've opened a PR with a possible fix.
Sorry for the images and lengthy issue, it's kinda deep ;)
Reproduction
https://github.com/otaviomad/ve-bug-repro/tree/other-bug
System Info
-

Used Package Manager
pnpm
Logs
No response
Validations

[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] The provided reproduction is a minimal reproducible example of the bug.

I've opened a PR: https://github.com/vanilla-extract-css/vanilla-extract/pull/1431
It works 100% on the repro with it.


[c&s] cmd-k doesn't work in fullscreen mode

promoting this to P0 as product-breaking for presentations


Release v1.10.2

Is this a new chart?
Yes
What this PR does / why we need it:
Which issue(s) is this PR associated with:

#Issue_Number
https://github.com/dell/csm/issues/1280

Special notes for your reviewer:
Checklist:
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] Chart Version bumped
[X] Variables are documented in the chart README.md
[ ] Title of the PR starts with the chart name (e.g. [charts_dir/mychartname]) if applicable

closing due to merge conflicts


portico: Correct spacing at footer bottom.

This corrects an undesired 5px open space beneath the portico footer, while improving the vertical alignment of legal footer elements on wider screens by putting flexbox in full control of vertical alignment. (Prior use of margin on individual flex items in the legal area were intended to keep the border-bottom borders adjacent the link text, but that was a poor pushback against flexbox's default stretch behavior.)
Screenshots and screen captures:

Before
After

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Merged, thanks @karlstolley!


fix(paeckchen-core): update paeckchen-sorcery

use 0.1.1 which fixes source-map generation

Belongs to #235


Symlink experiment for _shared folder

This is an experimental PR that is supposed to test whether symbolic links can be used to replace multiple copies of the _shared folder in Azure Communication Services.
Changes:

removed all copies of the _shared folder with the exception of one in communication-identity
added symlinks pointing to the _shared folder in communication-identity
updated to the latest version of the utlis.py file (from communication-rooms) - this file wasn't in sync with other modalities

TODOs:

replicate the changes for the tests _shared folder

@petrsvihlik appreciate your effort in removing multiple copies of the shared folder / same code.
The changes look good to me as we are marching towards 'Don't repeat yourself' (DRY) principle.
I will tag experienced Python SDK engineers (who has context on _share folder original decision] to comment on this PR.
Questions:
Where you able to run all communication test (including live tests), to validate the changes @petrsvihlik ?

/azp run python - azure-communication-identity - tests

/azp run python - azure-communication-networktraversal - tests

/azp run python - azure-communication-email - tests

@elavarasidc

Where you able to run all communication test (including live tests), to validate the changes @petrsvihlik ?

Yeah, the changes seems to work fine with - tests pipelines as well. I ran only those that were not failing previously - identity, chat, networktraversal, email.

@mikeharder it seems that no new symlink objects are added to this PR and the change is that the import has a relative path, which I guess was always supported

In the diff, I believe the files which only contain a path to another file are symlinks.

@petrsvihlik as we won't continue with this approach, can you pls close the PR?


Turn bounces off without removing the menu.

I was wondering if there was a way to turn bounces off in the tableView without stopping the Persei menu from appearing?

@ArthurU not sure I got your idea. Can you add some sort of image or some kind of a description?

There we go, there is a lot of space at the top, and I was just wondering if there was a way to avoid that stretch.

Oh, I got it. Let me make an update.

Update to the (https://github.com/Yalantis/Persei/releases/tag/1.1) version with new StickyHeaderView.contentViewGravity variable.
Usage:
let headerView = MenuView()
headerView.contentViewGravity = .Top


Server implemenation written in Go

Hi.
Great job on the official website for this project; https://altcha.org/
I've written a server implementation for the widget in Go.
Hope someone finds it useful.
https://github.com/k42-software/go-altcha/

Hi, and thank you for your contribution. The link is in the community integrations: https://altcha.org/docs/integrations


Gauge: show last run report fails on error "command 'vscode.previewHtml' not found"

Expected behavior
Show last run report command succeeds
Actual behavior
Show last run report command fails, a popup with an error appears in VS Code:
command 'vscode.previewHtml' not found
Steps to reproduce

Open a Gauge python project with VS Code
CTRL SHIFT P to open command palette
Hit on Gauge: Show Last Run Report
an error is shown, no report is shown <- here is the problem I think

VS Code and Gauge plugin versions
VS Code
Version: 1.33.0
Commit: 0dd516dd412d42323fc3464531b1c715d51c4c1a
Date: 2019-04-04T15:08:57.775Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.15.0-46-generic

VS Code plugin
V0.0.9

Gauge version

Gauge version: 1.0.4
Commit Hash: 3a9a647

Plugins
-------
csharp (0.10.5)
html-report (4.0.8)
java (0.7.2)
js (2.3.4)
python (0.3.5)
ruby (0.5.2)
screenshot (0.0.1)
spectacle (0.1.3)
xml-report (0.2.1)

Some analysis
Perhaps related to this:
Deprecating previewHtml #62630
I'm running this on Ubuntu 16.04.
Thank you!
Gustavo.

Should be fixed as part of https://github.com/getgauge/gauge-vscode/issues/354 and https://github.com/getgauge/gauge-vscode/issues/362.
Please install Gauge-VSCode nightly to avail the changes.

Please install Gauge-VSCode nightly to avail the changes.

Thank you.
I just installed the nightly version gauge-0.0.10.nightly-2019-04-09.vsix and the error about previewHtml goes away, however the command Show last run report command does not give me anything.
Perhaps I'm not doing things right, but when I hit Gauge: Show last run report, it opens a new VS Code window but it remains empty.
Any other ideas?
I did run a spec:
13:31:33.349 Plugin python is already installed.
13:31:33.350 Plugin html-report is already installed.
13:31:33.803 Checking updates...
13:31:37.258 # Specification Heading
13:31:37.258 ## my first test
13:31:37.259 * create configuration 1
13:32:25.807 * Create configuration 2

13:34:12.698 Plugin [Html Report] with pid [32427] has exited
13:34:12.798 Specifications:	1 executed	1 passed	0 failed	0 skipped
13:34:12.798 Scenarios:	1 executed	1 passed	0 failed	0 skipped
13:34:12.798
Total time taken: 2m35.363s

Thanks!

The behaviour of opening the report in VSCode editor has changed with this fix to open the report in browser.

13:34:12.698 Plugin [Html Report] with pid [32427] has exited

I see that html-report has exited and the reports are not generated as expected.
Is this happening consistently?
Steps to fallow:

Run spec from VSCode
Execute Gauge: Show last run report from command pallet

Note : Should open the report in the default browser.

Hi,
the html-report exits consistently like that ever since I installed Gauge for the first time (last week). Just went to the logs and double checked that it is the case. I'm on Ubuntu 16.04, in case it would matter.
From the fact that you are paying attention to it, I infer this is not normal.
Any way to figure out what is wrong?
However, it may be worth mentioning that if I open reports/html-report/index.html in a browser I'm able to see the report is generated properly and nicely.

Thank you!
Gustavo.

@gusgonnet As @Apoorva-GA mentioned we have removed support for inline html report inside vs code. Instead, we have added the feature to open the generated report in the default browser.
Could you try a few workarounds

Uninstall gauge-vscode extension
Just to make sure it is uninstalled properly delete ~/.vscode/extensions/getgauge.gauge*
Installed the latest nightly version of the extension again
Open the project, run and check if reports are generated properly

Hi @BugDiver
I did that already. However, I just did it again, with a reboot of my computer included, with same results:
run spec, then Gauge: Show last run report) opens a new VS Code window that remains empty
Anyhow, the issue I raised was about previewHtml and I know that you guys are aware of it and fixed it in an upcoming release so I'm happy.
Thank you for all the details!
Gustavo.


Quora search module added.

I have added Quora functionality. However, the main answer content isn't parsing properly. I will add another commit to fix that soon. In the meanwhile, if @nikhilrayaprolu  could review the existing work and suggest any changes.

@nikhilrayaprolu Could you please review?

Given the conflicts and the increasing rebases, I am closing this PR and opening a new one.


Add Velero 1.9.2 package.

Signed-off-by: Xun Jiang<EMAIL_ADDRESS>What this PR does / why we need it
Add Velero version v1.9.2 package into TCE.
Which issue(s) this PR fixes
Fixes: https://jira.eng.vmware.com/browse/TKG-13832
Describe testing done for PR

Special notes for your reviewer
None

Hope this patch can be merge ASAP!!~


Commit access request

Curious if you'd be open to granting me commit access on this project. I believe I've shown my skills and interest with the recent slew of PRs ;)
Been involved in open source a long time, here are a few of the projects I maintain:
https://github.com/vit-project/vit
https://github.com/thehunmonkgroup/luchia
And I've made significant contributions to these open source projects:

FreeSWITCH
Janus
Drupal

Would be happy to discuss further in real time as well. I've got a lot of momentum on this project, and it would reduce friction a lot for my continued contributions.

Done :)

I'd love to chat for 20 minutes though, my email is on my personal website (https://mahmoudmabrouk.com/)

Hm, the email link on your website isn't working, and I can't really make sense of the mailto: link, either!

it's<EMAIL_ADDRESS>


Code Problem

Hello author. We found that the state dimension is (5,12,7) in the code file, but (8,8,8) inside the paper. Also, we found that the test road network is incomplete. Can the author update the code, or provide a link to the original code file?

Hello,
Thank you for your interest in my work.
Regarding the discrepancy between the code dimensions and those mentioned in the paper, this is due to an upgrade in the simulation dependency library. As noted in Universal-Light Issue #7, I initially used Aiolos, which is an internal library developed by SenseTime. Therefore, I developed TransSimHub as a replacement for Aiolos. All the current code has been adapted to work with this new library.
This required adapting the original code to the new library, which involved making some modifications. For instance, in the initial version, I used (8,8,8) dimensions, which did not account for right turns. In the new version, I have expanded to 12 dimensions to include right turns for greater generality.
Regarding updates to the code, as I am currently interning, I have limited time to dedicate to updates. Therefore, unless there are convergence issues, there will likely not be significant updates to this repository.
Thank you once again for your support and understanding.

Hello,
Thank you for your interest in my work.
Regarding the discrepancy between the code dimensions and those mentioned in the paper, this is due to an upgrade in the simulation dependency library. As noted in Universal-Light Issue #7, I initially used Aiolos, which is an internal library developed by SenseTime. Therefore, I developed TransSimHub as a replacement for Aiolos. All the current code has been adapted to work with this new library.
This required adapting the original code to the new library, which involved making some modifications. For instance, in the initial version, I used (8,8,8) dimensions, which did not account for right turns. In the new version, I have expanded to 12 dimensions to include right turns for greater generality.
Regarding updates to the code, as I am currently interning, I have limited time to dedicate to updates. Therefore, unless there are convergence issues, there will likely not be significant updates to this repository.
Thank you once again for your support and understanding.

Thank you very much for your reply, we are using your code to produce very good results, and thank you for your open source work to bring great help to our work!

Thank you once again for your interest in our work.
As TransSimHub is still under development, there may be changes to the interface. If you encounter any issues with the code not running, please feel free to open an issue, and I will update it as soon as possible.
If you find our work helpful, please consider citing it.
@article{wang2024unitsa,
  author={Wang, Maonan and Xiong, Xi and Kan, Yuheng and Xu, Chengcheng and Pun, Man-On},
  journal={IEEE Transactions on Vehicular Technology},
  title={{UniTSA}: A Universal Reinforcement Learning Framework for V2X Traffic Signal Control},
  year={2024},
  volume={73},
  number={10},
  pages={14354-14369},
  doi={10.1109/TVT.2024.3403879}
}

@inproceedings{wang2022adlight,
  title={{ADLight}: A Universal Approach of Traffic Signal Control with Augmented Data Using Reinforcement Learning},
  author={Wang, Maonan and Xu, Yutong and Xiong, Xi and Kan, Yuheng and Xu, Chengcheng and Pun, Man-On},
  booktitle={2023 Transportation Research Board Annual Meeting (102nd TRB)},
  year={2023},
}

P.S. In the fine-tuning process, the learning rate significantly impacts the results. It's important to use different learning rates for fine-tuning and training.
Thank you for your understanding and support!


Is there a plan to integrate Kamailio with the SEMS project?

Hi herlesupreeth!
I am able to make VoNR calls using the current open source projects; however, I would like to integrate the media resource server SEMS. I am wondering if you have any plans to incorporate this part into future versions, as I would like to learn more about it.
Best  wishes!

I have another question,I wonder if you have the cfg file of the AS of the kamailio IMS module, which is the mmtel .
I want to use docker to build a complete IMS network element, and I hope to get your help.

Sadly, I dont have one but there are instances where Freeswitch is used an AS. You can find more information here - https://nickvsnetworking.com/freeswitch-as-an-ims-application-server/

hi @Helloworld1668 which model UE your tested vonr call.


update to bevy 0.5

Update dependencies to eliminate lib duplicates.

Thanks, there needs to be a bit more fixes though involved to get clippy and others to pass though :)

Actually, this might be an issue with a new clippy nightly lint and totally unrelated.


added documentation for ildg and imaginary mu

Hey everyone. I

changed the documentation author to LatticeQCD
added some documentation for imaginary mu to the RHMC
added some documentation about ILDG format to Gaugefield

Nothing else was changed.

It's looking good to me. But we need to wait for the ildg branch.

I just now also updated the documentation for the new testing scripts, including Lukas's single GPU one.


Add new setting autoOpenLinksInBrowser and implement it in login, reconsent. Closes #3118

Closes #3118
Adds new configurable setting autoOpenLinksInBrowser with default value false.
This setting will be used for commands that return a url and expect users to copy and paste that url into the browser.
Implemented the setting in the login and reconsent commands.

Awesome! We'll review it shortly 👍

Merged manually. Thank you! 👏


docs: Add ClickHouse integration to docs

@not-my-profile — FYI hyperlink saved me from merging something that missed a link, so thanks!


Bug Capitalize Headings: bug with accented letters

Hi ! Here is a but with  the "Capitalize Headings" fonction.
Describe the Bug
When Capitalize Headings is enabled, and a title begins with an accented letter, the first two letters of the title will be capitalized instead of just the first letter.
How to Reproduce
Steps to reproduce the behavior:

Just write a title starting with an accented letter
lint the file with Capitalize Headings a/ enabled ; b/ Style set to "First letter"

Unexpected Behavior
E.g
## état

will be replaced by
## ÉTat

and
## équilibre

will be replaced by
## ÉQuilibre

Expected Behavior
## état

should be replaced by
## État

and
## équilibre

will be replaced by
## Équilibre

Thanks for your work !
Michaël

Thanks for reporting this issue. I am pretty sure that I know what is causing this issue, I just need to figure out how to ignore numbers, whitespace, and punctuation and then I should be able to make this happen.

The fix is coming up for this. It was a simple change thanks to https://stackoverflow.com/a/62032796 which really helped out determining how to do this properly.

This issue should be accounted for in the next release and on master. Please let us know if the issue continues to exist in either of those.

Great, many thanks for your work !


Inconsistent behavior of Nil union introduction in a context that yields and rescues

Apologies if there is another issue that covers this - it is difficult to put this issue into search terms.
Example code
file_a.cr
require "./file_b"

class Example
  def test1
  end

  def test2
  end
end

def yields
  yield
end

yields do
  exa_local = Example.new
  yields { p(exa_local) }
  exa_local.test1
rescue
  exa_local.try(&.test2)
end

file_b.cr
# This is the same code from `file_a`.
yields do
  exb_local = Example.new
  yields { p(exb_local) }
  exb_local.test1
rescue
  exb_local.try(&.test2)
end

Issue
Attempting to compile crystal file_a.cr results in the following output:
Showing last frame. Use --error-trace for full trace.

In file_b.cr:4:13

 4 | exb_local.test1
               ^----
Error: undefined method 'test1' for Nil (compile-time type is (Example | Nil))

Changes that allow the code to run

In file_b.cr, remove the rescue branch. Both examples will run.
In file_b.cr, remove the inner yields line. Both examples will run.
In file_a.cr, remove require "./file_b", with no changes to the test code. The example in file_a.cr will run.

Expected behavior
I assumed the code in file_a.cr should run everywhere given. exa_local and exb_local should be Example | Nil in rescue, but I don't believe that union should leak elsewhere as it occurs in file_b.cr.
Any further insight would be appreciated!

FYI for context we encountered this by accident in a production web app setting, so this does happen.


Relative paths in less imports don't work

I'm having issues with importing external less files into styling parts of a .vue component file. I noticed that the README for vueify says Note that for CSS-preprocessor @imports, the path should be relative to your project root directory.
My problem is that my .vue file exists in a npm package (along with some LESS that I want to import). This package is then distributed uncompiled and used in other projects where compilation with browserify is performed, which means that the project root directory cannot be predicted when developing the npm package.
Is there any way I can get around this?

Relative imports are now supported in vueify 7.0+.


fix(wallet): better payment success/error handling

Description:
Use the sendPayment streaming API to send payments and update the app with details of successful/failed payment when we get the relevant response back from lnd.
Motivation and Context:
Remove arbitrary 60 second timeout.
How Has This Been Tested?
Manually - test successful and failed payments and ensure that UI updates correctly.
Types of changes:
Enhancement
Checklist:

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

Coverage increased (+0.02%) to 21.256% when pulling 4c999d2a9e2933661b8422075b1a1b78647d70f0 on mrfelton:fix/payment-timeout into 7f006cf792f44f709e942d62c5ab5975a7393d6b on LN-Zap:next.

@korhaliv  I've update the code to handle some of these potential error cases.


Determine if the application is running in Octane

Determine if the app is running in Laravel Octane calling
$this->app->runningInOctane()

or
app()->runningInOctane()

I think you can just check for that $_SERVER variable manually.