Show funding updates

Host a file at funding.html and funding.atom (RSS feed) that shows the last 20 funding updates. It should include company name, current funding amount, previous funding amount, date it was recorded changing, link to the landscape organization and a link to the Crunchbase page showing the funding.
git log --date=iso -p -W processed_landscape.yml | GREP_COLOR='01;36' egrep -B18  --color=always "(\+ +funding:)|Date:" | less -r
git log --date=iso -p -W | GREP_COLOR='01;36' egrep -B18  --color=always "\+ +funding:" | less -r

I checked this for last 10 days,
[ { name: 'BuzzFeed',
    currentAmount: 496300000,
    previousAmount: '',
    date: 'today',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/buzzfeed' },
  { name: 'Alcide',
    currentAmount: 12300000,
    previousAmount: 5300000,
    date: 'test',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/alcide' },
  { name: 'Bocloud',
    currentAmount: 15265600,
    previousAmount: undefined,
    date: 'test',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/bocloud' },
  { name: 'Bocloud',
    currentAmount: 15265600,
    previousAmount: undefined,
    date: 'test',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/bocloud' },
  { name: 'Tidu Information Technology',
    currentAmount: 2880000,
    previousAmount: '',
    date: 'today',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/tidu' } ]

date and link are still wrong, and I handle cases when previousAmount was empty just because the organization itself was not in our processed_landscape.yml at all. Do you want to hide such entries, i.e. when 'X Company' just appeared in our list?

Yes, I want to hide new entries. But I do want to capture situations where
the old entry was null and the current entry has a funding value.
Dan Kohn<EMAIL_ADDRESS>Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com
On Fri, Nov 30, 2018 at 7:14 AM Andrey Kozlov<EMAIL_ADDRESS>wrote:

I checked this for last 10 days,
[ { name: 'BuzzFeed',
currentAmount: 496300000,
previousAmount: '',
date: 'today',
link: 'todo',
url: 'https://www.crunchbase.com/organization/buzzfeed' },
{ name: 'Alcide',
currentAmount: 12300000,
previousAmount: 5300000,
date: 'test',
link: 'todo',
url: 'https://www.crunchbase.com/organization/alcide' },
{ name: 'Bocloud',
currentAmount: 15265600,
previousAmount: undefined,
date: 'test',
link: 'todo',
url: 'https://www.crunchbase.com/organization/bocloud' },
{ name: 'Bocloud',
currentAmount: 15265600,
previousAmount: undefined,
date: 'test',
link: 'todo',
url: 'https://www.crunchbase.com/organization/bocloud' },
{ name: 'Tidu Information Technology',
currentAmount: 2880000,
previousAmount: '',
date: 'today',
link: 'todo',
url: 'https://www.crunchbase.com/organization/tidu' } ]
date and link are still wrong, and I handle cases when previousAmount was
empty just because the organization itself was not in our
processed_landscape.yml at all. Do you want to hide such entries, i.e. when
'X Company' just appeared in our list?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/cncf/landscape/issues/988#issuecomment-443186354, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC8MBkcbwGKuMNZemNUGnR7fNaS7EMPiks5u0SESgaJpZM4YrBsp
.

Latest progress:
[ { name: 'Bocloud',
    currentAmount: 15265600,
    previousAmount: undefined,
    date: '2018-11-26',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/bocloud' },
  { name: 'Alcide',
    currentAmount: 12300000,
    previousAmount: 5300000,
    date: '2018-11-21',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/alcide' },
  { name: 'Pilosa',
    currentAmount: 3671889,
    previousAmount: undefined,
    date: '2018-11-19',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/pilosa' },
  { name: 'Banzai Cloud',
    currentAmount: 2500000,
    previousAmount: undefined,
    date: '2018-11-18',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/banzai-cloud' },
  { name: 'Pachyderm',
    currentAmount: 12120000,
    previousAmount: 2120000,
    date: '2018-11-16',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/pachyderm' },
  { name: 'HashiCorp',
    currentAmount: 174175000,
    previousAmount: 74175000,
    date: '2018-11-01',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/hashicorp' },
  { name: 'Neo4j',
    currentAmount: 160100000,
    previousAmount: 80100000,
    date: '2018-11-01',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/neo-technology' },
  { name: 'Pulumi Corporation',
    currentAmount: 20000000,
    previousAmount: 5000000,
    date: '2018-10-22',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/pulumi-corporation' },
  { name: 'Docker',
    currentAmount: 272855439,
    previousAmount: 334702133,
    date: '2018-10-18',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/docker' },
  { name: 'WhiteSource',
    currentAmount: 46000000,
    previousAmount: 11000000,
    date: '2018-10-17',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/white-source' },
  { name: 'Snowflake Computing',
    currentAmount: 928899110,
    previousAmount: 478899110,
    date: '2018-10-11',
    link: 'todo',
    url:
     'https://www.crunchbase.com/organization/snowflake-computing' },
  { name: 'Netlify',
    currentAmount: 44100000,
    previousAmount: 14100000,
    date: '2018-10-09',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/netlify' },
  { name: 'PureSec',
    currentAmount: 10000000,
    previousAmount: 3000000,
    date: '2018-10-05',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/puresec' },
  { name: 'JFrog',
    currentAmount: 226500000,
    previousAmount: 61500000,
    date: '2018-10-04',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/jfrog-ltd' },
  { name: 'Robin Systems',
    currentAmount: 51200000,
    previousAmount: 48200000,
    date: '2018-09-29',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/robin-systems' },
  { name: 'Datica',
    currentAmount: 14845000,
    previousAmount: 12820000,
    date: '2018-09-28',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/datica' },
  { name: 'Gremlin',
    currentAmount: 26750000,
    previousAmount: 8750000,
    date: '2018-09-28',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/gremlin-inc' },
  { name: 'Instana',
    currentAmount: 57000000,
    previousAmount: 27000000,
    date: '2018-09-26',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/instana' },
  { name: 'Snyk',
    currentAmount: 32000000,
    previousAmount: 10000000,
    date: '2018-09-25',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/snyk' },
  { name: 'Contino',
    currentAmount: 68150000,
    previousAmount: 28150000,
    date: '2018-09-25',
    link: 'todo',
    url: 'https://www.crunchbase.com/organization/contino' } ]

Really nice. Please make links to this subsection:
https://www.crunchbase.com/organization/pachyderm#section-funding-rounds
Dan Kohn<EMAIL_ADDRESS>Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com
On Fri, Nov 30, 2018 at 11:33 AM Andrey Kozlov<EMAIL_ADDRESS>wrote:

Latest progress:
[ { name: 'Bocloud',
currentAmount: 15265600,
previousAmount: undefined,
date: '2018-11-26',
link: 'todo',
url: 'https://www.crunchbase.com/organization/bocloud' },
{ name: 'Alcide',
currentAmount: 12300000,
previousAmount: 5300000,
date: '2018-11-21',
link: 'todo',
url: 'https://www.crunchbase.com/organization/alcide' },
{ name: 'Pilosa',
currentAmount: 3671889,
previousAmount: undefined,
date: '2018-11-19',
link: 'todo',
url: 'https://www.crunchbase.com/organization/pilosa' },
{ name: 'Banzai Cloud',
currentAmount: 2500000,
previousAmount: undefined,
date: '2018-11-18',
link: 'todo',
url: 'https://www.crunchbase.com/organization/banzai-cloud' },
{ name: 'Pachyderm',
currentAmount: 12120000,
previousAmount: 2120000,
date: '2018-11-16',
link: 'todo',
url: 'https://www.crunchbase.com/organization/pachyderm' },
{ name: 'HashiCorp',
currentAmount: 174175000,
previousAmount: 74175000,
date: '2018-11-01',
link: 'todo',
url: 'https://www.crunchbase.com/organization/hashicorp' },
{ name: 'Neo4j',
currentAmount: 160100000,
previousAmount: 80100000,
date: '2018-11-01',
link: 'todo',
url: 'https://www.crunchbase.com/organization/neo-technology' },
{ name: 'Pulumi Corporation',
currentAmount: 20000000,
previousAmount: 5000000,
date: '2018-10-22',
link: 'todo',
url: 'https://www.crunchbase.com/organization/pulumi-corporation' },
{ name: 'Docker',
currentAmount: 272855439,
previousAmount: 334702133,
date: '2018-10-18',
link: 'todo',
url: 'https://www.crunchbase.com/organization/docker' },
{ name: 'WhiteSource',
currentAmount: 46000000,
previousAmount: 11000000,
date: '2018-10-17',
link: 'todo',
url: 'https://www.crunchbase.com/organization/white-source' },
{ name: 'Snowflake Computing',
currentAmount: 928899110,
previousAmount: 478899110,
date: '2018-10-11',
link: 'todo',
url:
'https://www.crunchbase.com/organization/snowflake-computing' },
{ name: 'Netlify',
currentAmount: 44100000,
previousAmount: 14100000,
date: '2018-10-09',
link: 'todo',
url: 'https://www.crunchbase.com/organization/netlify' },
{ name: 'PureSec',
currentAmount: 10000000,
previousAmount: 3000000,
date: '2018-10-05',
link: 'todo',
url: 'https://www.crunchbase.com/organization/puresec' },
{ name: 'JFrog',
currentAmount: 226500000,
previousAmount: 61500000,
date: '2018-10-04',
link: 'todo',
url: 'https://www.crunchbase.com/organization/jfrog-ltd' },
{ name: 'Robin Systems',
currentAmount: 51200000,
previousAmount: 48200000,
date: '2018-09-29',
link: 'todo',
url: 'https://www.crunchbase.com/organization/robin-systems' },
{ name: 'Datica',
currentAmount: 14845000,
previousAmount: 12820000,
date: '2018-09-28',
link: 'todo',
url: 'https://www.crunchbase.com/organization/datica' },
{ name: 'Gremlin',
currentAmount: 26750000,
previousAmount: 8750000,
date: '2018-09-28',
link: 'todo',
url: 'https://www.crunchbase.com/organization/gremlin-inc' },
{ name: 'Instana',
currentAmount: 57000000,
previousAmount: 27000000,
date: '2018-09-26',
link: 'todo',
url: 'https://www.crunchbase.com/organization/instana' },
{ name: 'Snyk',
currentAmount: 32000000,
previousAmount: 10000000,
date: '2018-09-25',
link: 'todo',
url: 'https://www.crunchbase.com/organization/snyk' },
{ name: 'Contino',
currentAmount: 68150000,
previousAmount: 28150000,
date: '2018-09-25',
link: 'todo',
url: 'https://www.crunchbase.com/organization/contino' } ]
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/cncf/landscape/issues/988#issuecomment-443260343, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC8MBhw_RhCgPIHOeU-yGp0EyfRKjuW-ks5u0V3VgaJpZM4YrBsp
.

Please make the org name a link to the Landscape. Crunchbase column should just show the Crunchbase org name with a link to the Crunchbase funding section. Please show Current funding in black formatted as $1.25 M. Please make third column as funding change with increase ($500 K) in green and decrease (which should almost never occur) in red.

I'm adding the rendering to every branch just to make a PR preview. After that I'll limit it to the master branch


version / framework console print

minor console print for version and which framework is used and how to change if both are available :)
We can enable doctr logging explicit by setting export USE_DOCTR_LOGGER=[1, True, ON, YES] (default is OFF)
We stick to PEP8 and do not overwrite a logger instance by default
Any feedback is welcome :)

Hi @felixdittrich92 :)
Thanks for the PR! I'm having mixed feelings about this feature:

perhaps it's best that the output of the environment collection script doesn't change according to env variables :thinking:
using doctr.file_utils, users can easily know which backend they are running

What do you think?

@fg-mindee
So normally you don't have both frameworks running in one environment. 😅
But if that should be the case, I would generally be in favor of giving the user information about which one is being used (the default on tf in particular is difficult for a user to understand without looking at the code).
However, this is not that easy to implement, since we cannot simply write something to the console or overwrite a possible root logger.
If you have another idea I would be happy 🤗
Another thing we could do is document this better ! For example use from doctr.file_utils -> is_xyz_available or setup a basic logger to log informations from doctr

Considering that the env collection script may be run in another window with different env var, I think it's not useful to display it there. The script shows whether TF or PyTorch can be used, which usually gives us all the necessary information.

Another thing we could do is document this better ! For example use from doctr.file_utils -> is_xyz_available or setup a basic logger to log informations from doctr

That might be a good idea actually, to log the enabled backend. For now, without any env var set, file_utils with return True for both PyTorch and TF if both libraries are installed. The priority is only given in __init__ (cf. https://github.com/mindee/doctr/blob/main/doctr/datasets/generator/init.py) but this might complicate things a little.
Perhaps the best option would be to edit the bug report template? (ask user to specify which backend they are running, and how to check that)

@fg-mindee
ftm i agree that this would be the easiest way i have totally forgot this templates :sweat_smile: :+1:


handle trailing slash in host URL

https://github.com/tedsuo/rata/issues/4
Signed-off-by: Maria Shaldibina<EMAIL_ADDRESS>

I like it. Thanks @mariash!


Experimental Results on Gowalla dataset

Hello,
Thank you so much for your very useful work.
I have a question about results on Gowalla dataset, based on the log in https://github.com/openbenchmark/BARS/tree/master/candidate_matching/benchmarks/SimpleX/SimpleX_gowalla_x1
How do you divide training data into training and validation sets? From the log, test set is currently treated as validation set and reported results are selected as the best iteration on test set, which causes test data leakage. A similar problem was reported in this paper https://arxiv.org/pdf/2005.09683.pdf?
Look forward to hearing from you soon,
Thank you so much.

Yes, we follow the original data split with only train/test subsets and thus the results can be seen as validation accuracy.

Got it, thanks!


Make max incoming streams configurable

The max number of incoming streams is currently fixed in https://github.com/lucas-clemente/quic-go/blob/master/protocol/server_parameters.go#L66, we should make it configurable via quic.Config.

This would be pretty useful for the integration tests. At the moment, we have a very slow test downloading a huge number of files (> 100), just to run into that limit. This test can be sped up a lot by making this configurable.


Kako Kai 2 image is missing

I finished training my Kako to Kai 2 just now and found out this :smile:

ah yes I didn't notice

Add takanami kai and shouhou kai icons


BUG

Once below commands are executed for pass the ticket error occurs at the final stage.
mimikatz.exe "privilege::debug"
"kerberos::ptt GTnuckc.kirbi"
is returning with below error

File: 'GTnuckc.kirbi': ERROR kuhl_m_kerberos_ptt_File ; kull_m_file_readData (0x00000002)

A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
below required to be executed in the same environment
mimikatz.exe
privilege::debug
kerberos::ptt GTnuckc.kirbi
Screenshots
If applicable, add screenshots to help explain your problem.

Version

OS: [e.g. Win10]

Additional context
Prerequisites for the above command was successfully executed.

I believe the error code you are seeing is Error code 2 "file not found". Have you tried passing in the full path to the kirbi file?


Reference consolidation numeric types

This contributes to #10728 (The next PR will do the same with the floating point types.)
Notes for reviewers:
docs/csharp/language-reference/builtin-types/integral-numeric-types.md is the only new file.  The redirection file and the Language Reference TOC are the only other files with major changes. The other changed files were updated for links to files that have been removed.
Internal review link
Other changes to test:

The Language reference TOC should have "displayName" attributes for all integral types.
Build warnings for redirects and updated links.

I also checked for any issues reported for removed content. There were none.

closing and reopening to test a build.


eosiocpp generates broken skeleton code

The skeleton generated by eosiocpp -n ${contract} is broken in the following ways:

it generates a cast using eosio::name for which there is no matching constructor (occurs in two places)
the apply method that is generated is impossible to call through cleos
the abi file that is put there doesn't match the code being copied

New skeleton code merged onto the slim branch and smart contract wiki documentation updated on the staging site.


Old betas in the list show up as newer than their stable counterparts

$sbj.
Actual behavior
Just look at the log below:
$ mist list installer 12.5 --include-betas --compatible -q
Identifier │ Name                │ Version │ Build    │ Size     │ Date       │ Compatible
───────────┼─────────────────────┼─────────┼──────────┼──────────┼────────────┼───────────
012-37355  │ macOS Monterey beta │ 12.5    │ 21G5063a │ 12.26 GB │ 2022-07-07 │ True
012-42714  │ macOS Monterey      │ 12.5    │ 21G72    │ 12.41 GB │ 2022-07-20 │ True

$ mist list installer 12.5 --include-betas --compatible -q --latest
Identifier │ Name                │ Version │ Build    │ Size     │ Date       │ Compatible
───────────┼─────────────────────┼─────────┼──────────┼──────────┼────────────┼───────────
012-37355  │ macOS Monterey beta │ 12.5    │ 21G5063a │ 12.26 GB │ 2022-07-07 │ True

12.5 beta is preferred over 12.5 stable even though the stable version is newer (2022-07-20 > 2022-07-07, and 012-42714 > 012-37355, and 21G72 > 21G5063a).
Expected behavior
I expected all the table entries to be sorted by the release date but it seems that the betas take precedence for some reason (I haven't yet checked the source code to see why).
Proposed solution
I think that --include-betas shouldn't behave like this. If one wanted betas to be preferable, why not have a --prefer-betas or --only-betas for that use-case?
I'm convinced that this is a bug in sorting with --include-betas set, and it needs to be corrected by fixing the ordering. As for other use-cases — they are probably valid and could be implemented with extra CLI options, although that would be out of the scope of the current bug report (being rather a feature request).

I don't see any code specifically prioritizing betas and quick grepping suggests that the problem is in the sorting logic at https://github.com/ninxsoft/mist-cli/blob/41c60ed/Mist/Helpers/HTTP.swift#L161 with a similar mechanizm for firmwares at https://github.com/ninxsoft/mist-cli/blob/41c60ed/Mist/Helpers/HTTP.swift#L78.
Unfortunately, I don't know Swift nor do I have a dev env for experimentation so I won't be sending a PR to fix this :(
I hope this analysis helps someone to come up with a patch, though. Have a nice day!

@webknjaz thank you for the detailed analysis! 🙌
For some strange reason, the current logic is as follows:

Compare versions
If versions are not the same, sort from highest to lowest
If versions are the same, compare builds
If the builds are of the same length, sort from highest to lowest
If the builds are not of the same length, sort from longest to shortest <-- 🤯

If the sorting ever reaches Step 5, betas will always be sorted higher due to the length of the build string!
At first glance it seems like the easy fix is to just sort build strings letter by letter, which is just as simple as sorting the entire string from highest to lowest.
Updating from:
https://github.com/ninxsoft/mist-cli/blob/41c60eda5b461c7afd67bcbfe5b87aa702c8f8f7/Mist/Helpers/HTTP.swift#L161
To:
products.sort { $0.version == $1.version ? $0.build > $1.build : $0.version > $1.version }

Yields the following results:
➜ ~ mist list installer "12.5" --include-betas --quiet
Identifier │ Name                │ Version │ Build    │ Size     │ Date       │ Compatible
───────────┼─────────────────────┼─────────┼──────────┼──────────┼────────────┼───────────
012-42714  │ macOS Monterey      │ 12.5    │ 21G72    │ 12.41 GB │ 2022-07-21 │ True
012-37355  │ macOS Monterey beta │ 12.5    │ 21G5063a │ 12.26 GB │ 2022-07-08 │ True

Which works great for macOS Monterey 12.5, but not so great for all installers, eg. macOS Catalina 10.15.7:
➜ ~ mist list installer "10.15.7" --include-betas --quiet
Identifier │ Name                   │ Version │ Build    │ Size     │ Date       │ Compatible
───────────┼────────────────────────┼─────────┼──────────┼──────────┼────────────┼───────────
001-57224  │ macOS Catalina         │ 10.15.7 │ 19H4     │ 08.75 GB │ 2020-10-28 │ False
001-51042  │ macOS Catalina         │ 10.15.7 │ 19H2     │ 08.75 GB │ 2020-09-25 │ True
001-68446  │ macOS Catalina         │ 10.15.7 │ 19H15    │ 08.75 GB │ 2020-11-12 │ True

It appears the numerical digits after the letter in the build string should determine the sort order, which is possibly why the current rudimentary logic assumes a longer string will have a higher number at the end of the build string.
The build number suffixes also coincide with the release date.

Easy fix: sort by date
Slightly harder (more robust?) fix: sort by build strings up until the first letter, then compare and sort the remaining integer values (and also factor in an optional lowercase letter for betas)

Slightly harder (more robust?) fix: sort by build strings up until the first letter, then compare and sort the remaining integer values (and also factor in an optional lowercase letter for betas)

Have you considered using the first (identifier) column it seems to be monotonous. I'd assume that splitting it by the dash and turning into tuple of integers would make the comparison easier, no?

Simply sorting by identifiers will not work, and sorting by the 2nd half of the tuple as you suggested might work, but there doesn't seem to be any documented I am aware of that explains what the identifiers actually mean.
I am definitely leaning towards the approach of sorting by version, then by date for each version.


Visual indicator for locked stage

What feature do you want to see added?
Hi, It would be amazing to have a visual indicator when a pipeline stage is locked in the blue ocean. Maybe color-coded or some other way.
Upstream changes
No response

On a similar note, it would be nice for time accounting ("This build took X hours") to deduct known waiting time from the build CPU load.
Regarding UI interaction, I believe Blue Ocean is on hold, but there are other visualization efforts co CCing @timja as he might know better how to craft that interaction and whether there is any work needed in this plugin (report some special state, etc.), or if the ball is on UI plugins' side completely?..

the easiest way would be to attach a paused action I think, this would set the paused status in blue ocean and in the pipeline graph view plugin

Thanks! Now hoping that someone would pick that up practically and contribute a PR ;)


feat: mocha only two bootstrappers

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

Project coverage is 44.72%. Comparing base (2469e7a) to head (db810b3).
Report is 69 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3402      +/-   ##
==========================================
- Coverage   44.83%   44.72%   -0.12%
==========================================
  Files         265      272       +7
  Lines       14620    15269     +649
==========================================
+ Hits         6555     6829     +274
- Misses       7313     7658     +345
- Partials      752      782      +30

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Closing this as @smuu and I will coordinate on upgrading those bootstrappers to using pruning once v0.14.0 comes out.


Update TCD and Lero logos

Screenshot of the new logos on the page:

Hey @direnakkoc
Is it possible to make the LERO logo a bit bigger?

Hey @CiaraFlanagan,
Yes, it's possible when the logo is resized otherwise I cannot change the CSS for any specific logo. CSS is automated at the top level for all logos.

Hey @CiaraFlanagan, Yes, it's possible when the logo is resized otherwise I cannot change the CSS for any specific logo. CSS is automated at the top level for all logos.

Thanks for explaining.


WatchList: option to 'not Trash' after watching

Hi there,
please consider implementing an option to not delete files to the Trash after watching them, if desired.
(I often want to keep the files i watch, and would prefer to remove them manually when needed.)
Thank you for creating the great workflow(s)!

Done.

Thank you so much!


The "setuptools" requirement should be explicitly defined (ModuleNotFoundError: No module named 'pkg_resources').

Due to the usage of the "pkg_resources" module, the "setuptools" requirement should be explicitly defined (in this project, it is runtime requirement as well as installation time requirement). Because there are tools (such as Pants) that, after installing the library, do not maintain the installation time requirements, hence, this error is given:
ModuleNotFoundError: No module named 'pkg_resources'

which raises this exception on the Flake8:
flake8.exceptions.FailedToLoadPlugin: Flake8 failed to load plugin "E8" due to No module named 'pkg_resources'.

@AlirezaRoshanzamir PR is welcome!

@sobolevn The pull-request is created.

Thanks for accepting the pull request.
Is there a specific timeline for the next release? Or can this change be released as version 1.2.1?

1.2.1 is released.


tf.quantization.fake_quant_with_min_max_vars crashes

Click to expand!
Issue Type
Bug
Source
source
Tensorflow Version
tf 2.8
Custom Code
Yes
OS Platform and Distribution
Linux Ubuntu 20.04
Mobile device
n/a
Python version
3.9
Bazel version
n/a
GCC/Compiler version
n/a
CUDA/cuDNN version
n/a
GPU model and memory
n/a
Current Behaviour?
Session crashes when run the code below.
The code is buggy in that the argument `min_value` and `max_value` of `tf.quantization.fake_quant_with_min_max_vars` should be scalars instead of tensors of shape `(2,)`.
However, we expect the buggy code to be handled with `Exception` instead of just crashes.

Standlone code to reproduce the issue
import tensorflow as tf
import numpy as np
input_data = np.random.rand(1,3,3,2).astype(np.float32)
min_value = tf.constant([0.0, -1.0], dtype=tf.float32)
max_value = tf.constant([1.0, 0.0], dtype=tf.float32)
input_tensor = tf.constant(input_data)
output = tf.quantization.fake_quant_with_min_max_vars(input_tensor, min_value, max_value)

Relevant log output
abort (core dumped)

Hello @MThalberg ,
I request you please take a look at this issue #46910 where a similar issue has been raised and it is still open. Can you please follow that issue, since it is already being tracked there? Thanks!

Thank for pointing to the other issue and indeed it is the same bug. I will close this issue.


Undefined bahviour in RocResult::into_payload

I just started skimming this repo and found this line in roc_std (comment mine):
let mut value = MaybeUninit::uninit();
let ref_mut_value = unsafe { &mut *value.as_mut_ptr() }; // UB!

From the MaybeUninit::as_mut_ptr docs:

Reading from this pointer or turning it into a reference is undefined behavior unless the MaybeUninit is initialized.

I believe to do this safely, self.payload has to be copied directly:
fn into_payload(self) -> RocResultPayload<T, E> {
    let mut value = MaybeUninit::uninit();

    // copy the value into our MaybeUninit memory
    unsafe {
        core::ptr::copy_nonoverlapping(&self.payload, value.as_mut_ptr(), 1);

        // don't run the destructor on self; the `payload` briefly has two owners
        // but only `value` is allowed to drop it (after initialization)
        core::mem::forget(self);
    }

    unsafe { value.assume_init() }
}

This is my first issue on this (very exciting) project so I wanted to get some feedback before submitting a PR.

@folkertdev

yes that looks good. maybe move the forget outside of the unsafe?

@folkertdev I'll defer to you but I kept it in the unsafe block to indicate that it only becomes safe again once self is forgotten and can't drop payload anymore. Otherwise one might think it's okay to arbitrarily keep working with self between the copy and the forget even though it's not.


[SMALLFIX]Update Configuring-Alluxio-with-GCS.md

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/17469/
Test PASSed.

@gpang Thanks, I just update the docs.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/17479/
Test PASSed.

@gpang I update the Configuring-Alluxio-with-GCS.md, please check it~


Problem obtaining dependencies to com.sun.media:jai-codec:jar:1.1.3, javax.media:jai-core:jar:1.1.3

Hello, I'm trying to use this plugin (0.5.2) with Grails 2.4.3 and I'm getting this error:
Error |
Resolve error obtaining dependencies: The following artifacts could not be resolved: com.sun.media:jai-codec:jar:1.1.3, javax.media:jai-core:jar:1.1.3: Could not find artifact com.sun.media:jai-codec:jar:1.1.3 in grailsCentral (http://repo.grails.org/grails/plugins) (Use --stacktrace to see the full trace)
When trying to install older version (0.5.1) there is no error, but older version probably isn't compatible with newer versions of Grails.

Fixed by adding
mavenRepo "https://repository.jboss.org/maven2/" to my BuildConfig
Inspired by ca4c9f331d836d48e65f5e0f94383f622e00be77

Thanks! Saved my life! :+1: :grinning:

Thanks!!  it works for me!


diff ui: replace is as dangerous as destroy - so should be in red

Adding an attribute to Cognito user group destroys the old one (with manually added users) with no warning..
Diff show's replace against the top level, but that's not as clear as when I remove an attribute and it has destroy in red!
I didn't realise it was replacing the whole thing, not just the schema change I'd made.. maybe : change it to replace (e.g. destroy/create) on the diff output? and have it in red?

Yes, that seems appropriate. Thanks for the report.


Update Ubuntu Base Image

Update Ubuntu Base Image to Include:

document image in containers.md
Github Scaffolding Script (Users should be able to build from this image alone and scaffold a hosted git project)

README.md config / creation
Base CI-CD config for Github (GitLab as option, not required to implement)

manage-pull-request.yml

devcontainer.json
docker-compose.yml
.vscode/settings.json
template /docs/
template .gitignore

Decided to use Github Repo Templates for project initialization.


Question about the MLM masking

Hi,

10% of the time, we replace masked input tokens with random word

    indices_random = torch.bernoulli(torch.full(input_ids.shape, 0.5)).bool() & masked_indices & ~indices_replaced

Here is the code you use to replace a token with a random word. Is it correct to use 0.5 as the parameter here?
Thank you for your answer.

Thanks for your interest in our work.
As shown in this Line, there is ~indices_replaced to make sure only 10% are replaced by random word.
You can reorder this line as:
indices_random = torch.bernoulli(torch.full(input_ids.shape, 0.5)).bool() & ~indices_replaced & masked_indices
Please let me know if you might have any other questions.


Pipe will never be connected in debug mode

If you run afl-fuzz with "-debug" you will never be able to connect to the named pipe.
afl-fuzz.c will try to ConnectNamedPipe in create_target_process().
but winafl.dll will:
if(!options.debug_mode) {
    setup_pipe();
    setup_shmem();
} else {
    winafl_data.afl_area = (unsigned char *)dr_global_alloc(MAP_SIZE);
}

(in dr_client_main, winafl.c)
so if you pass "-debug" - winafl will never connect the pipe. And that happens to cause me timeouts and "cannot kill process -1" message.
Thats because afl-fuzz will extract the pid after ConnectNamedPipe will finish, so I guess what happens is that meanwhile another thread realize there is timeout and try to kill it with the global var child_pid which is still "-1".
I temporary changed it to:
setup_pipe();
setup_shmem();
if(!options.debug_mode) {
} else {
    winafl_data.afl_area = (unsigned char *)dr_global_alloc(MAP_SIZE);
}

And that solved it

Correct, with -debug flag, winafl.dll will never connect to the pipe.
the -debug flag is only meant to be used with drrun.exe and should never be used in combination with afl-fuzz.


Deprecate stopAll

done, now you can use Core.stop() to stop all moduels. but still can use Core.stopAll()


Release cardano-api-<IP_ADDRESS>

Changelog
- description: |
    Release cardano-api-<IP_ADDRESS>
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  # - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  # - refactoring    # QoL changes
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
   - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context
n/a
Checklist

[ ] Commit sequence broadly makes sense and commits have useful messages
[ ] New tests are added if needed and existing tests are updated. See Running tests for more details
[ ] Self-reviewed the diff

https://github.com/IntersectMBO/cardano-haskell-packages/pull/933


Experimental - Quick load

Using Experimental, loading a save game, size 400 homeworld, when I load in - I appear to be inside the planet. Cannot move, etc...
Using non-experimental I can at least load in and play.
FYI

Should be fixed in latest experimental


Minitest/EmptyLineBeforeAssertionMethods false positive when assertion has return value

Expected behavior
No offence for the following code
def test_something
  e = assert_raises(StandardError) { do_something }
  assert_match("Error", e.message)
end

Actual behavior
Minitest/EmptyLineBeforeAssertionMethods: Add empty line before assertion.
def test_something
  e = assert_raises(StandardError) { do_something }

  assert_match("Error", e.message)
end

RuboCop version
$ [bundle exec] rubocop -V
1.56.4 (using Parser <IP_ADDRESS>, rubocop-ast 1.29.0, running on ruby 3.2.2) [x86_64-linux-musl]
  - rubocop-erb 0.3.0
  - rubocop-factory_bot 2.24.0
  - rubocop-minitest 0.32.2
  - rubocop-performance 1.19.1
  - rubocop-rails 2.21.2

Yeah, that was annoying - https://github.com/rubocop/rubocop-minitest/pull/273.


Add tests for benchmarks

Pulled out of #1323, this is everything from that PR without nlohmann-json and flag changes

Add test framework comparing the benchmark output against a reference

Have you looked into https://json-schema.org/? This is a way to validate json objects, so it could be used instead of the manual checking currently done.

We don't have a fixed schema, because the input object can contain information from different benchmarks (matrix_statistics, spmv, solver, ...) and we only check for what is necessary.
However, I am not doing any validation in here (only sanitation to make the output deterministic), are you talking about the other PR?

You are validating the benchmark output by comparing it to some predefined output. I think this is exactly the use case for this schema validation. Of course we would have different schemas for the different benchmark types. Here is an example  for the blas schema (it might not be complete since I'm missing the other operations):
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "n": {"type": "integer"},
      "blas": {
        "type": "object",
        "patternProperties": {
          "^copy|axpy|scal": {
            "type": "object",
            "properties": {
              "time": {"type": "number"},
              "flops": {"type": "number"},
              "bandwidth": {"type": "number"},
              "repetitions": {"type": "integer"},
              "completed": {"type": "boolean"}
            },
            "required": [
              "time",
              "flops",
              "bandwidth",
              "repetitions",
              "completed"
            ]
          }
        }
      }
    },
    "required": [
      "n",
      "blas"
    ]
  }
}

@MarcelKoch Schemas might be more resilient to change, but requires significantly more work in adapting to changes (we can't just regenerate the output) and doesn't allow checking whether we left other parts of the input unchanged. On top of that, we have multiple types of output sections (text, DEBUG logger output, JSON arrays, JSON objects) that would need to be parsed.

@MarcelKoch Schemas might be more resilient to change, but requires significantly more work in adapting to changes (we can't just regenerate the output)

Not generating the expected output can also be a good thing, because we would keep errors from incorrect benchmarks otherwise. IMO changing the schema would not be too much in most cases. And I think the schema would be a more common approach to the test.

and doesn't allow checking whether we left other parts of the input unchanged. On top of that, we have multiple types of output sections (text, DEBUG logger output, JSON arrays, JSON objects) that would need to be parsed.

The schema would only be for the JSON arrays and objects. The other parts would be tested as it currently is. Although thb I'm not sure what the value is of testing the debug logger output. But I need to think about that a bit more.

Having the reference output be part of the repository and checking stderr and stdout is a really fundamental goal of this approach, because it lets us notice when something in the output changes, either because we changed something on purpose or because we caused an accidental change. Either way the test fails, and we need to explicitly change the reference outputs. The change also gets preserved in git, so you see in the code review which parts of the benchmark (and its internals in the DEBUG case) changed how.
Also JSON schemata can't check questions like: does the benchmark preserve parts of the input that were ignored? does the order of the output entries stay consistent?

nlohmann-json and RapidJSON both support preserving the order of objects in the output, and a change in the order is usually the side-effect of a change in the code. Whether the side-effect was intended or accidental, it's still useful to be notified of it.
Preserving the input as much as possible can matter if we have a workflow running through multiple benchmarks operating on the same JSON array, e.g. [{"filename":"file.mtx"}] -> [{"filename":"file.mtx", "problem": {"rows":1, "columns":1, ...}}] -> [{"filename":"file.mtx", "problem": ..., "optimal": {"spmv:" "csr"}}].

From our offline discussion, the schema based approach will be put on the backlog, and, for now, the purely text based approach is sufficient. Perhaps after #1323 would be a good point to reevaluate the usage of schema.

Could that be summarized somehow? Or is it only the previous points?  Either here or in notion. I've also recently seen fruitful usages of the JSON schema, the more info on the topic the better.

The important bullet points for me were

JSON schemas can do almost all we need to do here, including handling the different ways typenames get mangled between different compilers.
To me, the other outputs (banner, status messages, DEBUG logger output, ...) are at least as important as the JSON output, so I didn't want to put too much effort into this yet.
One thing JSON schemas can't do is check the order in which entries were added to the JSON object. This is an important descriptor of the execution control flow though, since it tells us when the order that different operations in the benchmark were run changes.
The tooling around text diffs is really convenient, is there something similar for JSON schema violations?

Regarding the json-schema discussion: https://pypi.org/project/jsonschema/ might be an option.

The output (especially stderr, but also to a degree stdout) describes the control flow of the benchmark execution: What order do we execute sub-benchmarks in, what kernels get called (in the profiler case). If that control flow changes accidentally, we want to know about it. These tests will help us with that, as they require us to explicitly mark changes by running benchmark_test_regenerate and make them part of the review process.

In the context of benchmarking, I disagree that a change in control flow is relevant if it preserves the final output. But I think you are assuming that the cause for that change is a deeper issue somewhere unrelated to the benchmark. So this test is not to check that the benchmarks produce the correct result file, but instead to check for changes in an integration test that can't be detected by unit tests. And for me, framing this as a benchmark test is confusing.

Summarizing the results from our offline discussion on this topic:

The benchmarks are currently not being tested, we need to change that (also to enable some necessary refactoring)
The debug profiler output was originally intended to test that the profiler actually gets attached to the executor, the fact that it observes internal control flow was an unintended, but (to me) happy side-effect. I agree with Marcel's point that the benchmarks are not the right place to test this behavior, maybe we should be attaching debug profilers to examples or integration tests instead.
The order of objects doesn't really matter that much in the JSON output, since we will transform it anyways. So we don't really need to handle the JSON differences via text diff.
Currently, we write JSON output both to stderr and stdout. The stderr output is pretty verbose with inline JSON objects, instead we could be moving the JSON output to stderr exclusively, leave stderr for status messages only (except for maybe error cases, but we don't test them ATM)

So my suggestion based on these points would be

merging this PR
merging the refactoring PR #1323
stripping all JSON output from stderr, replacing it by the output of the describe functions, together with
keep validating the stderr output textually, and moving to JSON Schema validation for the stdout output


Compiled regex should be a private global variable to avoid being recompiled

https://github.com/sethgrid/multibar/blob/4bf4cf7b87d60bfaf4b4ec40fc7aabf376d0be37/multibar.go#L166

ah, good call. I'm not actively maintaining this. I'll merge PRs still if
you submit any :)
Cheers.
On Fri, Oct 30, 2020 at 9:22 PM Wes McNamee<EMAIL_ADDRESS>wrote:

https://github.com/sethgrid/multibar/blob/4bf4cf7b87d60bfaf4b4ec40fc7aabf376d0be37/multibar.go#L166
https://urldefense.com/v3/__https://github.com/sethgrid/multibar/blob/4bf4cf7b87d60bfaf4b4ec40fc7aabf376d0be37/multibar.go*L166__;Iw!!NCc8flgU!PBUyXv9VusdBDUdTM-I6Bo-Y3isseLrSUg1um6WqxUwYmJR3XozmTxaPg70E5MIRtw$
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/sethgrid/multibar/issues/20__;!!NCc8flgU!PBUyXv9VusdBDUdTM-I6Bo-Y3isseLrSUg1um6WqxUwYmJR3XozmTxaPg71_WXo1Cg$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAHRU7AOUJRMBG7OET65EW3SNN7H5ANCNFSM4TFUL7YA__;!!NCc8flgU!PBUyXv9VusdBDUdTM-I6Bo-Y3isseLrSUg1um6WqxUwYmJR3XozmTxaPg71ItX3HhQ$
.


function dicussion[list the augmentations when you start training]

is it necessary to list the augmentations you applied to the dataset when you start to run the training?
I find it necessary, especially when you use "RandomResize" augmentations.
because you cannot easily validate it via  "--view" flag in semantic segmentation tasks.

You can always write print in your code if you like. I don't see why this would become a problem


v3: scope not highlighted with go

Don't know why because the scope works with C, Lua, Python but with Go no scope is shown and no indent shown
Config:
    {
        "lukas-reineke/indent-blankline.nvim",
        event = { "VeryLazy" },
        branch = "v3",
        config = function()
            local highlight = {
                'RainbowDelimiterRed',
                'RainbowDelimiterYellow',
                'RainbowDelimiterOrange',
                'RainbowDelimiterGreen',
                'RainbowDelimiterBlue',
                'RainbowDelimiterCyan',
                'RainbowDelimiterViolet',
            }
            require('ibl').setup({
                indent = { char = "│" },
                exclude = { "help", "alpha", "dashboard", "neo-tree", "Trouble", "lazy", "mason" },
                scope = {
                    enabled = true,
                    highlight = highlight,
                    show_start = false,
                    show_end = false,
                }
            })
            local hooks = require "ibl.hooks"
            hooks.register(hooks.type.SCOPE_HIGHLIGHT, hooks.builtin.scope_highlight_from_extmark)
        end,
    },

NVIM v0.9.1
Build type: Release
LuaJIT 2.1.1692616192
with Go's treesitter + language servers installed and updated.

You probably don't have list set?
The logic currently is, for tabs use config.indent.tab_char if set, if not use listchars. But if you have neither, it displays nothing.
I guess it should probably fall back to the normal config.indent.char instead :thinking:

I guess it should probably fall back to the normal config.indent.char instead

I pushed a new commit to do this

commit works perfectly, thanks :)


Doctrine Hydrator Strategies - Wrong field names

When I open the modal to add a new hydrator strategy, entity fields are populated as
<column_name> => <field_name>
This cause to save the follow configuration:
return array(
    'doctrine-hydrator' => array(
        'UserAPI\\V1\\Rest\\User\\UserHydrator' => array(
            'strategies' => array(
                'insert_time' => 'Zend\\Stdlib\\Hydrator\\Strategy\\DateTimeFormatterStrategy',
            ),
    ),
);

but, in my case, the field is named insertTime.
The problem is at this line

@jguittard can you look this issue? Thanks!

@thomasvargiu The field name is retrieved from Doctrine Metadata API, not from your entity implementation.
Plus, strategies are bound to the hydrator. So you may either use ClassMethods hydrator, or if you use another hydrator, add a Zend\Stdlib\Hydrator\NamingStrategy\UnderscoreNamingStrategy to your hydrator.
That could be something like:
use Zend\Stdlib\Hydrator\NamingStrategy\UnderscoreNamingStrategy;

...

public function __construct()
{
    parent::__construct();
    $this->addStrategy('insertTime', new UnderscoreNamingStrategy());
}

I'm sorry, maybe the issue was incomplete.
I know that field name is retrieved from Doctrine Metadata API, but I think from the wrong field.
The problem with my entity is that property is defined something like this:
...
class Foo {
    /**
     * @var \DateTime
     * @ORM\Column(name="insert_time", type="datetime", nullable=false)
     */
    protected $insertTime;
}

where property name is insertTime and column name is insert_time. The default hydrator strategy use the property name and not the column name, but the value you are retrieving from metadata to write configuration is the column name (if I am right).

@jguittard can you review the PR provided by @thomasvargiu? Thanks!


use System.currentTimeMillis instead of new Date().getTime

to avoid Date() object creation thus faster.

Coverage increased (+0.04%) to 87.333% when pulling 1cdf4eda2273473a9e046d0f0f9e3a984fedb63a on XenoAmess:use_System_currentTimeMillis_insteadof_Date_getTime into 18fb261d0bbbb8cc52483267213e0d2ef4c43de7 on apache:master.

LGTM. Thank you.


add allow_non_local option

This piece in templates/default/35-server-per-host.conf.erb was causing issues for my setup:
:fromhost-ip,!isequal,"<IP_ADDRESS>" ~

Specifically, I was trying to access the rsyslog server from within a logspout Docker container on the same host (different IPs).
Added the 'allow_non_local' option to make that line optional. Merge if you wish!

Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.
GitHub Users Who Are Not Authorized To Contribute
The following GitHub users do not appear to have signed a CLA:

@jdolitsky

Please sign the CLA here.

Hi. Your friendly Curry bot here. Just letting you know that all commit authors have become authorized to contribute. I have added the "Signed CLA" label to this issue so it can easily be found in the future.


Comply with the Google Cloud impersonate library

Update code to comply with the must-use Google Coud impersonate library.

I couldn't find any integration tests to test this new way of using Google impersonation. Could you help me please? Is there any Google Cloud project that I could use? Not that on the one I'm using, it's working fine but it's relatively subjective.
Thanks for the help.

Hi,
I think it will be helpful to create a test for this, maybe create service accounts and try to impersonate, GCP project is defined during tests execution through env variable GOOGLE_CLOUD_PROJECT

@denis256 @yorinasub17 @fgateuil GCS double impersonation is still big sore thumb :( can I assist you in writing tests to make this pass? Just couple pointers and I'll be happy to speed up this PR.

Hello,
CI job passed so there is regression after changes, local test with impersonate_service_account also worked, I will look if will be possible to enable impersonation for the service account used in integration tests

Hi,
I was thinking about basic test like: https://github.com/gruntwork-io/terragrunt/compare/denis-gs-test to track in future that impersonate_service_account will continue to work

Hi, I was thinking about basic test like: https://github.com/gruntwork-io/terragrunt/compare/denis-gs-test to track in future that impersonate_service_account will continue to work

Hmmm, @denis256 it's not that simple. To test the impersonate mechanism, some prerequisites are necessary.
Test 1:

Prerequisites:

main_sa_1 owns a single basic (testable) permission/role, let's say roles/editor role for instance to be allowed to create a new GCS bucket;
principal_sa_1 owns the Service Account Token Creator permission over main_sa_1 (as explained here);

Test:

Set impersonate_service_account value to principal_sa_1's email;
Create a GCS bucket ==> it must succeed.

Test 2:

Prerequisites:

main_sa_2 doesn't own any permission/role so that he isn't allowed to create any GCS bucket;
principal_sa_2 owns the Service Account Token Creator permission over main_sa_2;

Test:

Set impersonate_service_account value to principal_sa_2's email;
Create a GCS bucket ==> it must fail.

Thus, I need few service accounts and roles preconfigured to be able to test the impersonate mechanism and I'm not convinced it's already the case here.

Hi @fgateuil , @denis256.
I modified the implementation slightly based on this pull request.
I also implemented the test code.
Could you please check this pull request? #2550

Hey @fgateuil
We're going through stale PRs and closing them out. If you would like to propose this functionality again in the future, please submit another pull request.
If possible, submit an issue first in order to make sure that the problem is well understood, and try to prioritize adding good documentation and testing with your feature so that we are confident in our review.
Thanks!


arch, include, sched : Refactor ARCH_GLOBAL_IRQDISABLE related code

Summary

ARCH_GLOBAL_IRQDISABLE was initially introduced for LC823450 SMP
At that time, i.MX6 (quad Cortex-A9) did not use this config
However, this option is now used for all CPUs which support SMP
So it's good timing for refactoring the code

Impact

Should have no impact because the logic is the same for SMP

Testing

Tested with board: spresense:smp, spresense:wifi_smp
Tested with qemu: esp32-core:smp, maix-bit:smp, sabre-6quad:smp
Build only: lc823450-xgevk:rndis, sam4cmp-db:nsh

Hi @patacongo,
I've just refactored ARCH_GLOBAL_IRQDISABLE related code.
Because the config is used for all CPUs which support SMP.

LGTM.

LGTM


os: TestReadWriteDeadlineRace failure on linux-amd64-clang builder

There was a single failure of TestReadWriteDeadlineRace on the linux-amd64-clang builder at head:
--- FAIL: TestReadWriteDeadlineRace (0.00s)
    timeout_test.go:498: Read returned non-timeout error read |0: not pollable
FAIL
FAIL	os	0.638s

I've only seen this failure once, but recording it here in case it becomes a pattern.
2019-11-20T22:38:34-39a9cb4/linux-amd64-clang
CC @ianlancetaylor

This means that epoll returned EPOLLERR as an event for the file descriptor in question.  I don't really see how that is possible here.


bump deps to fix node 18 dev compatibility

Please use node 16.x for development. We've added it to package.json and .nvmrc now.
Updating the project and it's deps to v18 is something we're planning for next year.


Rename kube-master => kube-master-1 in README

Rename kube-master => kube-master-1 in README

This change is

CLA signed.

/lgtm
/approve

Thanks


Rspec 3 update, use expect-style asserts

This PR is the same as https://github.com/wardencommunity/sinatra_warden/pull/19

@jsmestad Glad to have nudged you to merge your better changes! .rspec_status etc, all good things. And, some refactorings, v. nice.


fix-fluent-bit-alert-description

This PR:

fixes the fluent bit down alert description (missing the instance labels)

Checklist

[x] Update changelog in CHANGELOG.md.
[ ] Add Unit tests
[x] Request review from oncall area, as well as team (e.g: oncall-kaas-cloud GitHub group).

I agree Herve :) I'll try to add some if I do not forget ;)


Hi，Can you share your source videos matched with the calibration parameter in this project?

No description provided.
Hi! Unfortunately I don't have video and no longer have access to the platform.

Hi! Unfortunately I don't have video and no longer have access to the platform.

ok, thanks for your reply. by the way, When can I read your thesis paper about this amazing project?

好的，感谢您的回复。顺便说一句，我什么时候可以读到你关于这个惊人项目的论文？

Hello, have you implemented this project？

已收到，我会尽快回复。


Protobuf compilation: schema and protocol

Given a proto file, we wanted to generate of Scala code, and this PR does this.
Included goodness:

Proto3 and proto2 compatible
Infers messages across imported protos
Infers services
Deleted ScalaPB dependency.
Infers nested types
Map types
Coproducts
Add unit test to prove the generation of scala code
Update the docs to show an example

This is the example:
Protobuf
Parsing nested .proto files and converting into Scala code
Given these proto files below:
author.proto
syntax = "proto3";
package com.acme;

message Author {
    string name = 1;
    string nick = 2;
}

book.proto
syntax = "proto3";
package com.acme;
import "author.proto";

message Book {
    reserved 4, 8;
    reserved 12 to 15;
    int64 isbn = 1;
    string title = 2;
    repeated Author author = 3;
    BindingType binding_type = 9;
}

message GetBookRequest {
    int64 isbn = 1;
}

message GetBookViaAuthor {
    Author author = 1;
}

message BookStore {
    string name = 1;
    map<int64, string> books = 2;
    repeated Genre genres = 3;

    oneof payment_method {
        int64 credit_card_number = 4;
        int32 cash = 5;
        string iou_note = 6;
        Book barter = 7;
    }
}

enum Genre {
    option allow_alias = true;
    UNKNOWN = 0;
    SCIENCE_FICTION = 1;
    SPECULATIVE_FICTION = 1;
    POETRY = 2;
    SCI_FI = 1;
}

enum BindingType {
    HARDCOVER = 0;
    PAPERBACK = 1;
}

service BookService {
    rpc GetBook (GetBookRequest) returns (Book) {}
    rpc GetBooksViaAuthor (GetBookViaAuthor) returns (stream Book) {}
    rpc GetGreatestBook (stream GetBookRequest) returns (Book) {}
    rpc GetBooks (stream GetBookRequest) returns (stream Book) {}
}

We can parse and convert them into Scala code as:
val source = ParseProto.ProtoSource("book.proto", "resources")
val nativeDescriptor: NativeFile = parseProto[IO].parse(source).unsafeRunSync()

val parseNative: NativeFile => Protocol[Mu[ProtobufF]] = Protocol.fromProto(_)

val parseProtocol: Protocol[Mu[ProtobufF]] => mu.Protocol[Mu[MuF]] =
{ p: Protocol[Mu[ProtobufF]] => mu.Protocol.fromProtobufProto(p) }

val printProtocol: mu.Protocol[Mu[MuF]] => String = { p: mu.Protocol[Mu[MuF]] =>
  higherkindness.skeuomorph.mu.print.proto.print(p)
}

(parseNative andThen parseProtocol andThen printProtocol)(nativeDescriptor))

It would generate:
package com.acme

object book {

  @message final case class Author(name: String, nick: String)
  @message final case class Book(isbn: Long, title: String, author: List[Author], binding_type: BindingType)
  @message final case class GetBookRequest(isbn: Long)
  @message final case class GetBookViaAuthor(author: Author)
  @message final case class BookStore(name: String, books: Map[Long, String], genres: List[Genre], payment_method: Cop[Long :: Int :: String :: Book:: TNil])

  sealed trait Genre
  object Genre {
    case object UNKNOWN extends Genre
    case object SCIENCE_FICTION extends Genre
    case object POETRY extends Genre
  }

  sealed trait BindingType
  object BindingType {
    case object HARDCOVER extends BindingType
    case object PAPERBACK extends BindingType
  }

  @service(Protobuf) trait BookService[F[_]] {
    def GetBook(req: GetBookRequest): GetBookRequest
    def GetBooksViaAuthor(req: GetBookViaAuthor): GetBookViaAuthor
    def GetGreatestBook(req: GetBookRequest): GetBookRequest
    def GetBooks(req: GetBookRequest): GetBookRequest
  }
}

@rafaparadela probably it's a typo in the PR description, but shouldn't be the output something like the following?
// ...
@service(Protobuf) trait BookService[F[_]] {
    def GetBook(req: GetBookRequest): F[Book]
    def GetBooksViaAuthor(req: GetBookViaAuthor): Stream[F, Book]
    def GetGreatestBook(req: Stream[F, Book]): F[Book]
    def GetBooks(req: Stream[F, Book]): Stream[F, Book]
  }

Few questions:
sealed trait Genre
  object Genre {
    case object UNKNOWN extends Genre
    case object SCIENCE_FICTION extends Genre
    case object POETRY extends Genre
  }

Why not use scala enum instead?
How do you define an option on proto3?
Should the scala generated code have some imports?
Is this supporting bigdecimal?

@juanpedromoreno Interesting. I barely haven't changed the printer, but yes, I should have detected this issue. I'm on it.

@AdrianRaFo

Do we want to replace the ADT by scala Enumeration? @pepegar @juanpedromoreno
In proto3, all fields are "optional"
Yesterday at some point I was printing the imports in the Scala representation:
No BigDecimal at the moment.

  def dependency: Printer[String] = konst("import ") *< string >* konst("._")

But it was adding an extra level of complexity dealing with packages, so I decided to follow another approach (similar that Avro's) and I merged the dependent messages in one single protocol.

@rafaparadela I know all fields in proto3 are optional but if you are translating them to non-optional scala fields how actually can I set a field as optional, on proto2 is easy because you have the keyword optional but on proto3 you haven't

@juanpedromoreno Solved printer of the operations at https://github.com/higherkindness/skeuomorph/pull/66/commits/769ff31d377aa522da32bab16f7339a005165979

@AdrianRaFo The long debate about the lack of optional and required in proto 3, of course, affect our implementation. I don't think that we should, by default, translate all the fields into scala Options. As has been implemented, it supposes that all the fields are required and in the case that you want to have an Option in the scala result, you should set as a coproduct with only one value. Thanks to the optimization made by @paco, will be converted into an Option[T]. I hope this answers your question.

Thanks, rafa just make sure to include into the doc :wink::clap:

I'd avoid the Enum, I prefer having a proper ADT. @rafaparadela

Regarding https://github.com/higherkindness/skeuomorph/pull/66#issuecomment-463334573, I'd prefer ADT for enums too.

@juanpedromoreno Finally the intermediate NativeDescriptor has been removed with the great help of @pepegar . I think this is ready to be merged (once we got a green from CI)


python 3 compatibility

It seems like the last dependency vobject is now with version 0.9.0 python 3 compatible. Are there any plans on making pycarddav python 3 compatible? I would like to help with porting, but wanted to coordinate before starting to hack :)

pycarddav development is currently on hold (from my side), when I find the time I want to remove the syncing part and use vdir's instead (see #92). But I'll gladly accept any pull requests (including python 3 support).

I created a branch python3, that works for me with python3. I was able to do a
# pycardsyncer
# pc_query

with this modifications. Unfortunately I cannot run the testsuite at the moment. Maybe someone else can try my changes.


do not request a shell on the remote host

starting a remote command is not used or necessary for a forward-only connection
plus the SSH_HOSTUSER@SSH_HOSTNAME is not even guaranteed to have this permission,
in which case the server will always close the link after authentication,
leading to an infinite retry loop

Rebase please.

You can actually set the environment variable SSH_MODE: -Ng -L to accomplish the same result

@qmnonic : That's a really ugly hack, IMNSHO - although it works and you could use any of the user-supplied variables to pass in arbitrary options, it mixes up the forwarding mode with any arbitrary option. (With your suggestion, the forwarding modes are: L, R, or "some weird string that has nothing to do with forwarding at all").
More to the point, the container does not need a shell at all - why keep it open and unneccesarily increase the attack surface?

@jnovack : Rebased.

@qmnonic : And even worse, your suggestion does NOT "accomplish the same result": the -g option opens the forwarded ports to the whole world ("globally"); I do understand you personally might have some use-case to add that in, but claiming "same result" while opening the forwarded ports to the whole world is a) misleading at the very best or b) ignorant of the -g's function. Please clarify.

Ugly - maybe.
There is an SSH_MODE environment variable, which is defaulted to -R.  For my test case, i changed the default direction, -R to -L.
-g i might have added by accident during testing.
Shell - I thought the -N flag ensured the connection doesn't open a shell, which i thought addressed your question.  Perhaps not.  But it seems like a SSH_MODE option, so i added it there.
Feel free to ignore my suggestions.

I appreciate all suggestions, let's be civil about this.  We're all trying to make the world a better place.


Stopping Model Mid-generation

Is there a way to stop the generation process (bot.respond) midway? I was wondering because low parameter models (in my experience) tend to easily get stuck and generate nonsense for a long time and the only way to "stop" the model is by restarting the app.

good point. i just implemented the functionality(v1.2.4).
you can now call LLM.stop() function anytime and it will stop inferencing.


Add pranavarora1895

Kindly Add my profile to the main project.
Account - pranavarora1895
Name - Pranav Arora

@pranavarora1895 Changes in package-lock.json file are not required! So please revert the changes from package-lock.json file! Let us know if you need any help!
__
  Summary: :hammer_and_wrench: This code needs a fix

Hey, The package-lock.json file is still in the PR. If you need any help, feel to ping us.
__        Summary: 🛠 This code needs a fix

Hi. I am not able to revert the changes and put it back to this PR. Kindly let me know how to do it. Thanks.

Hey, The package-lock.json file is still in the PR. If you need any help, feel to ping us.
__        🛠 This code needs a fix

Hi. I am not able to revert the changes and put it back to this PR. Kindly let me know how to do it. Thanks.

Just copy the contents from the original package-lock.json, paste them into your package-lock.json branch, commit, then push. You might have to revert the changes first if you're using a service such as Gitpod or running NPM each time you start the editor. Let us know if you need any help. 🙂

Do you need any help with this @pranavarora1895 !?

Since there is no answer on this for a while I will close it. Please feel free to make a new pull request adding your portfolio without the package-lock file.
__
  Tags: Not reusable


perf: Improve vLLM backend performance by using a separate thread for responses

What does the PR do?

Triton's output token throughput for generate endpoint increases by 18% for concurrency 50. There is still a small gap between vLLM-only and vLLM + Triton solution.
The model is llama-2-7b.
Changes:

Use add_request instead of generate for vLLM backend. It appears that with generate , the token generation is delayed until the next iteration of the loop.
Delegate response sending to a separate thread.

Next steps:

In the long term it might be better to have an async_send API to avoid creating a separate thread for sending the responses.

Checklist

[x] PR title reflects the change and is of format <commit_type>: <Title>
[x] Changes are described in the pull request.
[x] Related issues are referenced.
[ ] Populated github labels field
[ ] Added test plan and verified test passes.
[ ] Verified that the PR passes existing CI.
[x] Verified copyright is correct on all changed files.
[ ] Added succinct git squash message before merging ref.
[ ] All template sections are filled out.
[ ] Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:
Check the conventional commit type
box here and add the label to the github PR.

[ ] build
[ ] ci
[ ] docs
[ ] feat
[ ] fix
[x] perf
[ ] refactor
[ ] revert
[ ] style
[ ] test

Related PRs:

N/A
Where should the reviewer start?

N/A
Test plan:

This is a performance improvement, existing test cases should be sufficient at covering any possible issues.

CI Pipeline ID: 16917857

Caveats:

N/A
Background

N/A
Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
N/A

@Tabrizian  Can you add description for the code changes in the PR? Also including the performance improvement you observed and in what cases?

@tanmayv25 I updated the PR description.

@kthui So you've received close to Iman's perf results after sync?

@kthui So you've received close to Iman's perf results after sync?

yes

I test Qwen2-7B-chat whith a A100*80G，The pr did not work, The gap compared to vllm deployments is nearly 40% for concurrency 50
vllm
============ Serving Benchmark Result ============
Successful requests:                     64
Benchmark duration (s):                  15.35
Total input tokens:                      14970
Total generated tokens:                  15304
Request throughput (req/s):              4.17
Input token throughput (tok/s):          975.53
Output token throughput (tok/s):         997.30
---------------Time to First Token----------------
Mean TTFT (ms):                          1222.87
Median TTFT (ms):                        1168.27
P99 TTFT (ms):                           2284.71
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          55.58
Median TPOT (ms):                        55.96
P99 TPOT (ms):                           56.88
---------------Inter-token Latency----------------
Mean ITL (ms):                           53.51
Median ITL (ms):                         51.57
P99 ITL (ms):                            78.99
==================================================

triton+llm+stream
============ Serving Benchmark Result ============
Successful requests:                     64
Benchmark duration (s):                  24.85
Total input tokens:                      14970
Total generated tokens:                  15178
Request throughput (req/s):              2.58
Input token throughput (tok/s):          602.44
Output token throughput (tok/s):         610.81
---------------Time to First Token----------------
Mean TTFT (ms):                          1762.53
Median TTFT (ms):                        1687.10
P99 TTFT (ms):                           3342.62
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          91.16
Median TPOT (ms):                        91.76
P99 TPOT (ms):                           93.63
---------------Inter-token Latency----------------
Mean ITL (ms):                           138.93
Median ITL (ms):                         93.49
P99 ITL (ms):                            368.58
==================================================

triton+llm+no stream
============ Serving Benchmark Result ============
Successful requests:                     64
Benchmark duration (s):                  18.48
Total input tokens:                      14784
Total generated tokens:                  15232
Request throughput (req/s):              3.46
Input token throughput (tok/s):          801.91
Output token throughput (tok/s):         826.32

I test Qwen2-7B-chat whith a A100*80G，The pr did not work, The gap compared to vllm deployments is nearly 40% for concurrency 50
vllm
============ Serving Benchmark Result ============
Successful requests:                     64
Benchmark duration (s):                  15.35
Total input tokens:                      14970
Total generated tokens:                  15304
Request throughput (req/s):              4.17
Input token throughput (tok/s):          975.53
Output token throughput (tok/s):         997.30
---------------Time to First Token----------------
Mean TTFT (ms):                          1222.87
Median TTFT (ms):                        1168.27
P99 TTFT (ms):                           2284.71
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          55.58
Median TPOT (ms):                        55.96
P99 TPOT (ms):                           56.88
---------------Inter-token Latency----------------
Mean ITL (ms):                           53.51
Median ITL (ms):                         51.57
P99 ITL (ms):                            78.99
==================================================

triton+llm+stream
============ Serving Benchmark Result ============
Successful requests:                     64
Benchmark duration (s):                  24.85
Total input tokens:                      14970
Total generated tokens:                  15178
Request throughput (req/s):              2.58
Input token throughput (tok/s):          602.44
Output token throughput (tok/s):         610.81
---------------Time to First Token----------------
Mean TTFT (ms):                          1762.53
Median TTFT (ms):                        1687.10
P99 TTFT (ms):                           3342.62
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          91.16
Median TPOT (ms):                        91.76
P99 TPOT (ms):                           93.63
---------------Inter-token Latency----------------
Mean ITL (ms):                           138.93
Median ITL (ms):                         93.49
P99 ITL (ms):                            368.58
==================================================

triton+llm+no stream
============ Serving Benchmark Result ============
Successful requests:                     64
Benchmark duration (s):                  18.48
Total input tokens:                      14784
Total generated tokens:                  15232
Request throughput (req/s):              3.46
Input token throughput (tok/s):          801.91
Output token throughput (tok/s):         826.32

llm+triton gpu utilization is significantly lower than vllm


namespaces

Is there any particular reason that namespaces are not used in the project ? It seems that there is no C API and code is written in pure C++. Using namespace would allow the user to avoid a potential conflicts with the names and doing workarounds for that problem like writing wrappers for the lib and hide included headers in one translation unit.

yes, this is a valid request. Please let us know if you already have experienced such conflict.

Yes, I experienced it when I wanted to use it in project where I'm contributor: https://github.com/oneapi-src/oneDNN/blob/master/tests/benchdnn/README.md. Unfortunately, now I don't remember what exact names conflicted with ours, but there was not one but several issues with naming.


Fixing SourceMod installation

There's a stable way to install SourceMod for Open Fortress:

Use a stable tested SourceMod build (anything <= 6488): https://sm.alliedmods.net/smdrop/1.10/sourcemod-1.10.0-git6488-linux.tar.gz
Install DHooks for SourceMod 1.10: https://forums.alliedmods.net/attachment.php?attachmentid=190123&d=1625050030
Disable adminmenu.smx plugin since calling sm_admin segfaults the server

It may not have all the latest features, but I personally tested it and it works

Sorry for the late reply, busy with other things. Yes this would create a stable SM install similar to previous versions, however the OF devs are pushing for their own fork which I need to and preferably use over the old versions. However, when I get the chance I'll take a look at potentially providing the older version as an option in another tag, perhaps?


"voicefixer" is not recognized as an internal or external command

Hello!
I plan to use voicefixer from the command line. In accordance with the instructions, I produce the following commands on the command line:

pip install voicefixer==0.1.1
git clone https://github.com/haoheliu/voicefixer.git
cd voicefixer

all these commands run without any error, ok.
But then, as soon as I try to run the «voicefixer» command (for example, this command):
voicefixer --infile /path/to/input.wav --outfile /path/to/output.wav
a message is displayed:
“voicefixer” is not recognized as an internal or external command…and so on
even when I just write one word “voicefixer” on the command line, the same message is displayed
As I understand it, this executable file cannot be found for some reason.
How to fix it? I use Windows 10, I also installed the recommended WGET.

You are correct, there is no executable to run. But you can still use voicefixer without one.
By the way, I don't think cloning the repository is required for command line testing. I cloned it like you, but I later deleted the files and it still runs fine.
To run it, I did the following:
Go to your Python scripts folder, it should be something like AppData\Local\Programs\Python\Python39\Scripts
You should see a file called voicefixer with no extension. This is the python script for the executable.
I renamed this file to vf.py. Any name will do, just don't use the name voicefixer.py as you'll get circular references and it won't run.
Now in the command prompt, just do something like:
vf.py --infile input.wav --outfile output.wav
And processing should commence.

Thank you for your reply, musicalman! I finally managed to run the VF script. But the following error occurred (picture):

By the way, I am not strong in programming, and I use only those instructions that have been described on the main page. I'm a musician and I was going to use the VM to restore the voices. It is a pity that this program does not have a convenient graphical user interface.

@Scudoxx Sorry for the inconvenience. Now the bug on the windows machine should be fixed. Hope you enjoy it.
And Thanks @musicalman for the comments!

Sorry to bother you, but apparently I'm not too lucky as nothing worked for me again:

As for the second method (streamlit), which for me was the most simple and preferred, also refuses to work:

If any of these methods ever work, I'll be happy :D


router.use not called as expected

const router1 = new Router();
const router2 = new Router();
const router3 = new Router();

// never called
router1.use(async (ctx, next) => {
  console.log(111)
  await next();
})

// never called
router2.use(async (ctx, next) => {
  console.log(222)
  await next();
});

router3.get('/', async (ctx, next) => {
  ctx.body = 'hello';
});

app.use(router1.routes());
app.use(router2.routes());
app.use(router3.routes());

access http://localhost/ will not get router1.use or router2.use called

It seems a decent workaround for this issue is to add one final catch-all handler to the router that does nothing except "trigger" the route's middlewares.
const app = new (require('koa'))();
const KoaRouter = require('koa-router');

const router = KoaRouter();

router.use((ctx, next) => {
  console.log('Router middleware');
  return next();
});

router.get('/method', (ctx, next) => {
  ctx.body = 'Routed method';
});

router.all('*', (ctx, next) => {
  console.log(`Don't do anything, just "trigger" the route`);
  return next();
});

app.use(router.routes(), router.allowedMethods());

app.listen(3000);

Output when calling '/not-there':
Router middleware
Don't do anything, just "trigger" the route

The /method also works fine, as well as adding nested router, middlewares before the router and after.
I'll be trying this approach for my project.

Any progress on internally resolving this issue?

Problem line
https://github.com/ZijianHe/koa-router/blob/master/lib/router.js#L670
This bug prevents the use of nested routes

const productsRouter = require('@project/app/routes/v1/products')

/*!
 * Init route
 */

const ordersRouter = new Router()

ordersRouter.param('orderId', ordersController.loadOrder)

ordersRouter.use('/orders/:orderId', productsRouter.middleware)


Add Pablo's charts to ChartsHolder, plumbing in the API datasets.

This is minimal, but a starting point for iteration (we need to deal with missing data, tweak the end date for charts, etc.).

merged


Which meta-meta model is the OpenAPI specification built on?

Hi,
Just researching for a university presentation and could not find the meta-model the OpenAPI specification is built on. I am relatively sure that JSON / YAML is not the correct answer as  for me these would be the platform specific models. The specification as in the Markdown file here on Github is for me the platform independent model.
So any clue which meta-meta model is used to create the description of the specification?

The meta model is not formalized.  It consists mainly of maps, lists, strings, bool, urls, and the notion of Any.

I wouldn't be that pessimistic: the subsections of section "Schema" pretty much describe the entity types of the meta-model, and the "Fixed Fields" table in each subsection lists the attributes and relationships of the corresponding entity type.
Btw: good job! I like the consistent structure and concise wording of the 3.0.0 specification.


Fatal error FRPKSIG - Dev Assert DSP PSQ overflow

hello,
I have been running though your Quick Start and grabbed a Shannon firmware to emulate (CP_G930FXXS5ESF1_CP12893112_CL14843133_QB24085562_REV00_user_low_ship.tar.md5) this was taken from the data set (https://zenodo.org/record/6516030#.YncQV3VByEI) kindly  provided on ticket #6 by @mariusmue; I think this was the first Shannon baseband on this list.
I have had success emulating other Shannon basebands but this one causes a FATAL ERROR due to (reason:Dev Assert DSP PSQ overflow) when running under normal emulation, I have attached a log of the output that dumps stack and register state. To understand more about your tool, I attempted to debug this problem dynamically using GDB watchpoints, however this is causing an exception in /avatar2/plugins/gdbserver.py (I should probably raise a separate issue here?)
My question is - have you seen this DSP PSQ overflow as a common issue whilst developing support for Shannon firmwares? If so can you suggest an approach to fix the crash?
Update - I have tested a large sample of CP_G935F* and CP_G930F* firmwares and they all produce this fatal error after ~1min of emulation, in contrast CP_G973FXXUCFUH3_CP19998134_CL22340597_QB42324606_REV01_user_low_ship.tar seems to run indefinitely ...
firmwire_log.0.txt

Hi!
The uploaded firmware images in the data set are meant to replicate our results from the paper - as such, they are indeed not supposed to work all out of the box. We are still in the process of preparing the raw data of these experiments to a separated repository. During the large-scale study, we did not look into the individual bugs/issues - but instead wanted to provide insight on the images were FirmWire runs out of the box without additional modification.
It's likely that with a couple of fixes, these errors are gone, but I don't have a solution ready out of the top of my head without investigating this issue a bit more.
For more context, here is the relevant Figure from the paper: As visible, FirmWire has better support for G950+ firmware.

thanks for the reply; I have read the paper a while back so forgive me for forgetting this table ! I will look into the crashing on S8 and see if I can figure out what might be causing it.


Tables look odd on mobile

Table are causing responsiveness a bit hard to work well, and in academic/calendar tables are overflowing, and needed to be fixed.

Close according to inactivity.


ATWHO can't filter

IN http://ichord.github.io/At.js/
After I type @ it can hint and do filter when I type a
But I can't.
What did I miss

I can't get your point.


Data Dashboard: Merge Hispanic race categories with non-Hispanic counterparts

Currently, we make the distinction between Hispanic/non-Hispanic ethnicity with two different racial categories, "x" & "x (Non-Hispanic)".
We want to combine these two categories.
Backend is working on creating a binary "Hispanic?" category, but in the meantime let's combine these two in visualizations on the frontend.

I don't think it's worth making a workaround for this, given limited time till launch. Once schema changes happen, the frontend will need to switch from using race_and_ethnicity to using just race

We also need to make sure that if we're merging data across states that report differently, that we have a footnote indicating this

Completion time estimate: < 2 weeks

Is this issue still valid? I agree with Aaron that I don't think we should make a workaround in the frontend if the backend is providing the wrong data format given the tight launch time

Also wanted to make note of these two issues dealing with how we handle hispanic vs non-hispanic data in frontend:
https://github.com/SatcherInstitute/health-equity-tracker/issues/475
https://github.com/SatcherInstitute/health-equity-tracker/issues/307

The latest on this after the discussion with Ebony is to not alter the race/ethnicity labels that we show (and so not have the footnote explaining that all categories include/exclude hispanic), and instead just add a static footnote at the bottom explaining what hispanic/latino means per dataset. What the footnote is going to say & how it's going to vary exactly per dataset is not totally clear right now

I'm going to close this issue. We will open a separate issue to define whatever footnote we add for hispanic/latino. But we aren't consolidating any groups or altering labels per Vansh's most recent comment


Implement UI Toolkit API documentation

Description
FEDX-3
This change uses JSDox to automatically generate Markdown files from the UI Toolkit's JavaScript doc strings. I then build a Jekyll-based static site from these raw files, ready to be published to GitHub Pages. Use gulp doc to generate the documentation and to serve it using browserSync along with file watchers on all of the inputs. It also supports a build-preview task that will upload the site to S3 for folks to preview.
You can view the generated documentation here: http://ux-test.edx.org/andya/api-doc/
Manual Test Plan
I've manually verified that each test class is being rendered reasonably, and I've cleaned up the documentation to match.
Testing Checklist

[ ] Manually test responsive behavior.

Post-review

[ ] Squash commits into discrete sets of changes with descriptive commit messages.

Reviewers

[ ] @pdesjardins
[ ] @bjacobel

If you've been tagged for review, please check your corresponding box once you've given the :+1:.
We'll also automatically suggest reviewers for this PR based on the code it touches.
FYI @AlasdairSwan @dsjen @dan-f @cahrens

Coverage remained the same at 92.874% when pulling 5f919a080f7d81fbc6fad050373bb8a4d0af75b4 on andya/api-doc into 2b9ee85b131f27e12429ed9c6100e4e7049837dd on master.

 Makes things a little more readable.

Nice work @andy-armstrong. I noticed an a11y issue in that the contrast ratio between the light blue text and the grey background is only 2.25.

@bjacobel the font errors are a known problem just with the preview. It is not correctly using the new base URL that the site is being hosted at. I don't think it is a showstopper since it doesn't affect the local Jekyll build, and hence I don't think it will affect GitHub Pages. I will look into it again and see if I can pin it down.

Thanks @AlasdairSwan. I was having second thoughts about the gray background, even though that is our edX pattern. Maybe I should do something more like ReadTheDocs:
http://edx-developer-guide.readthedocs.org/en/latest/
@chris-mike what would you recommend?

@bjacobel @AlasdairSwan @pdesjardins - thanks for the great feedback. I've fixed the bug with the preview fonts, and I've cleaned up the styling to be cleaner and not have a11y issues. I've pushed up the preview again:
http://ux-test.edx.org/andya/api-doc/utilities/string-utils/
Please re-review.

Coverage remained the same at 92.874% when pulling 02e140f1384208a94fb271136ecb75573c64e8a6 on andya/api-doc into 2b9ee85b131f27e12429ed9c6100e4e7049837dd on master.

It looks like (something? Jekyll?) is tokenizing and wrapping in <span>s the code blocks for syntax highlighting, but our presentation isn't able to do anything with it because it's lacking CSS to style it. Could we look into adding that CSS? I think all we need is this file (but I'm not sure where it comes from).

Some sort of rule along the lines of pre.highlight {background-color: grey} might increase the code readability as well.

Good point @bjacobel. I intended to look into how the code rendering was meant to work. I'll investigate...

@bjacobel I've pushed up changes to support the code styling (I borrowed them from the Pattern Library).

Coverage remained the same at 92.874% when pulling bf41104e3f4414e5d01f83692b22cc8be59c825e on andya/api-doc into 2b9ee85b131f27e12429ed9c6100e4e7049837dd on master.

@andy-armstrong, this looks great. Please merge. What I see at http://ux-test.edx.org/andya/api-doc/ is excellent!

:thumbsup:

Coverage decreased (-0.2%) to 93.478% when pulling 31b11ba9707b452498db493e1a534134c6727f07 on andya/api-doc into e2d42dc49515447d62b06149922247822d767058 on master.

Coverage decreased (-0.2%) to 93.478% when pulling 83bf03cb9add031aa49e082e607e20a4b07276c3 on andya/api-doc into e2d42dc49515447d62b06149922247822d767058 on master.

Coverage decreased (-0.2%) to 93.478% when pulling 8c50c20a496430411207f9d60a9aee39a21fbdaf on andya/api-doc into e2d42dc49515447d62b06149922247822d767058 on master.

Coverage decreased (-0.4%) to 93.356% when pulling 2fa520ac813b6c5bbf9de80b68803b0d2a5b7cc5 on andya/api-doc into e2d42dc49515447d62b06149922247822d767058 on master.


Mirror traffic management works with 1.7.6 but not working with 1.8.2 nor 1.8.1

Bug description
Following the Istio documentation on traffic management with mirroring with Istio version 1.7.6 the mirroring works as described. Following the same steps with Istio version 1.8.2 (and 1.8.1) and the mirror features does not work. When broken, the traffic is sent randomly to either the v1 or v2 httpbin service. The mirror declarations in version 1.8.x appear to be ignored.
To make replication easy you can run this Katacoda scenario Istio Traffic Management and flip the installation of istio between 1.7.6 and 1.8.1 (or any other version desired) found in step 3. I'm just reporting the versions where I confirmed the alleged defect.
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[X] Virtual Machine
[ ] Multi Control Plane
Expected behavior
When the VirtualService and DestinationRules are applied, the v1 and v2 logs for the httpbin pods should match the documentation. When broken, the curl commands through the sleep service appear randomly in the v1 and v2 logs rather than following the declarations in the VirtualService and DestinationRule.
Since it works correctly with 1.7.6 and not with 1.8.1 suspicion points to the Istio release 1.8.x and not this example scenario's environment or configuration. Nothing was noted in the 1.8.x release notes related to changes in the mirror feature. The diagnosis and experimentation for finding the problem can be done in the provided katacoda scenario.
Steps to reproduce the bug

Run the provided Katacoda scenario Istio Traffic Management. Complete steps 1, 2, 3 then skip to the last step 11 for exercising the mirror feature. In step 3, change the istio version setting to version 1.7.6 to show mirroring working.  Start a new scenario and leave as 1.8.2 and follow same steps to see mirroring not working.

Follow the steps in step 11. The only difference between the Istio documentation on traffic management with mirroring and these steps, is the experiment is run in the namespace mirror. (Running it in the default namespace causes other problems related to proxy injection when using istoctl inject conflicting with namespace label injection)

Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
istioctl version --remote
client version: 1.8.2
control plane version: 1.8.2
data plane version: 1.8.2 (10 proxies)

kubectl version --short
Client Version: v1.18.0
Server Version: v1.18.0

helm version --short
v3.1.2+gd878d4d

How was Istio installed?
Per istio readme:
curl -L https://istio.io/downloadIstio | sh -
export PATH="$PATH:/root/istio-${ISTIO_VERSION}/bin"
istioctl install -y --set profile=demo

In the referenced Katacoda scenario Istio Traffic Management see shell script: /usr/local/bin/start-istio.sh
Environment where the bug was observed (cloud vendor, OS, etc)
Full and open environment is available here for diagnosis and experimentation: Katacoda scenario Istio Traffic Management.

I went through it, and got caught up by the istioctl kube-inject thing multiple times. Once I finally resolved all of those, it seemed to work fine. At some point I had no sidecar for the sleep pod, causing it to not follow the rules

I went through it, and got caught up by the istioctl kube-inject thing multiple times. Once I finally resolved all of those, it seemed to work fine. At some point I had no sidecar for the sleep pod, causing it to not follow the rules

To inject or not inject, that is the question.  =)
@howardjohn you pointed right to it. In the sleep deployment a line snuck in that was not part of the documentation:
sidecar.istio.io/inject: "false"
Even with kube-inject this annotation with override as expected. In turn Istio produced this helpful message:
===> Skipping injection because "sleep" has sidecar injection disabled
And as you said the sleep Pod was missing the envoy sidecar. Once that uninvited annotation was removed, the Envoy sidecar was added and the mirror rule worked as expected and as you reported. I'm not sure why the problem did not appear to exist with 1.7.6, but it could have been my testing.
(The scenario has been corrected.)
Thank you.

To inject or not inject, that is the question.  =)
@howardjohn you pointed right to it. In the sleep deployment a line snuck in that was not part of the documentation:
sidecar.istio.io/inject: "false"
Even with kube-inject this annotation with override as expected. In turn Istio produced this helpful message:
===> Skipping injection because "sleep" has sidecar injection disabled
And as you said the sleep Pod was missing the envoy sidecar. Once that uninvited annotation was removed, the Envoy sidecar was added and the mirror rule worked as expected and as you reported. I'm not sure why the problem did not appear to exist with 1.7.6, but it could have been my testing.
(The scenario has been corrected.)
Thank you.

btw, I found this super hard, even as someone who just spent months working on the injector code. I opened https://github.com/istio/istio.io/issues/8810 to hopefully make the docs better. Thanks!

btw, I found this super hard, even as someone who just spent months working on the injector code. I opened https://github.com/istio/istio.io/issues/8810 to hopefully make the docs better. Thanks!


Implement shared custom data

Implements #427

Will write tests and documentation either when I get home or later tonight!

Opening this up for review. I can add tests if they're desired.

Hey @1c3t3a thanks for the review! I'll take a look at the comments made sometime Thursday or Friday due to exams over the next two days (I apologize for the late response).
Both custom_data and shared_data sound good to me, I didn't think about how data could be misleading, thanks for pointing that out. If I think of something better I'll be sure to bring it up!

No worries, there is absolutely now need to apologize! I am super happy you work on this in your free time :)
Good luck with the exams! And in that case I'd personally prefer custom_data, but feel free to come up with something different.

@1c3t3a  Took a look at most of what you said, let me know if I missed anything big you'd like to go over. Only thing I believe I haven't looked into yet is using generics on Client and ClientBuilder and accepting a fat pointer on set_data, I'll try and look over this in the next day or two when I have a chance. Apologies for going over this so late haha.

Any chance?


Get rid of unnecessary versioned includes for kubernetes performance

The entire reason for originally using the include was to avoid
duplicating the material. If we're going to be duplicating the material
anyway, there's no benefit to putting it in _includes files.
I'd be happy to keep this in a _includes file if we're still open to
versionless includes, but it sounds like we want to avoid them as a
general rule.
Cleans up after #3366.
The text has just been directly copied with no modifications.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/450c1cb66a939e0673adbb5bad8066092d8b9f2e/


Allow overriding default mixins

Really love the project but I would like to override the box mixin with some of my homegrown properties on my projects, This would allow for that behavior!
it also means you can provide more default mixins and let people override them if they want to use their own, no name collision!
Your project, your call on if you want to merge it up!

deleted and redid the PR at https://github.com/joe-bell/stitches-mixins/pull/4 with proper semantic commit, didn't want to go out of bed to the computer to squash commits!


Make the hover effect better

Hi @DhanushNehru,
I would like to work on this, also can you elaborate a bit on the result you expect?
Thank you

Noted, thanks for the response.


Problems importing native modules (for Electron app)

OS?

Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

Windows 10 x64
Versions.

Please run ng --version. If there's nothing outputted, please run in a Terminal: node --version and paste the result here:

>ng --version
angular-cli: 1.0.0-beta.22-1
node: 6.9.1
os: win32 x64

Repro steps.

Was this an app that wasn't created using the CLI? What change did you do on your code? etc.

I am building an electron app, but I am having trouble importing the "child_process" core module. Each of the follow result in a compile time "can't resolve 'child_process'" error (see error 1 below).

import * as childProcess from 'child_process';
import { exec } from 'child_process';
const exec: any = require('child_process').exec;

However, the following don't result in a compile time error, but it results in an uncaught type error at run time.

import { ipcRenderer, remote } from 'electron'; (see error 2 below)
import * as fs from 'fs'; (see error 3 below)

This workaround/hack works but 1) uses eval and 2) doesn't have type system support:

const exec: any = eval("require('child_process').exec");
const fs: any = eval("require('fs')");
const ipcRenderer: any = eval('require(\'electron\').ipcRenderer');

The log given by the failure.

Normally this include a stack trace and some more information.

Compile time error when importing "child_process."

ERROR in ./src/app/shared/services/shell.service.ts
Module not found: Error: Can't resolve 'child_process' in 'C:\path\to\app\shared\services'
 @ ./src/app/shared/services/some.service.ts 10:0-46
 @ ./src/app/shared/shared.module.ts
 @ ./src/app/app.module.ts
 @ ./src/app/index.ts
 @ ./src/main.ts
 @ multi main

Run time error when importing "electron."

"Uncaught TypeError: fs.readFileSync is not a function"

When importing "fs"

Uncaught TypeError: __WEBPACK_IMPORTED_MODULE_0_fs__.lstatSync is not a function

Mention any other details that might be useful.

Thanks! We'll be in touch soon.

We will not support universal or electron officially until addon themselves are supported.
You're better off using a seed or implementing your own webpack config for Electron builds. Sorry.