Errors happen during loading llama 65B for tuning.

ValueError: Target modules ['dense_h_to_4h', 'dense', 'dense_4h_to_h', 'query_key_value'] not found in the base model. Please check the target modules and try again.
python qlora.py –learning_rate 0.0001 --model_name_or_path  decapoda-research/llama-65b-hf
which model can be used as base 65B llama for tuning?

load another model:
ValueError: Target modules ['dense_h_to_4h', 'dense', 'dense_4h_to_h', 'query_key_value'] not found in the base model. Please check the target modules and try again.
python qlora.py –learning_rate 0.0001 --model_name_or_path  huggyllama/llama-7b

what's wrong with my setting?

Hello, I tried the same command and it worked on my side.
python qlora.py –learning_rate 0.0001 --model_name_or_path huggyllama/llama-7b

Could you make sure you pulled the latest changes and try again? Also could you also ensure you installed the correct packages using  pip install -Ur requirements.txt?

Hello, I tried the same command and it worked on my side.
python qlora.py –learning_rate 0.0001 --model_name_or_path huggyllama/llama-7b

Could you make sure you pulled the latest changes and try again? Also could you also ensure you installed the correct packages using pip install -Ur requirements.txt?

I can load Llama-65B into 4 GPUs, 12.28GiB each, with 2.4-2.5GIB free in each GPU after model load. But as it starts running, it runs out memory. I have already set the batch size to 1. What other flags can I set to reduce VRAM use? Thanks.

@znsoftm How did you solve it?


update data list breakpoints to use sm instead of mobile

this will align with the grid breakpoint system that we are using and going ahead with until further notice.

:tada: This issue has been resolved in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Turbo.visit does not set window.location on cross origin links.

The reference docs for Turbo.visit says:

If location is a cross-origin URL, or falls outside of the specified root (see Setting a Root Location), Turbo performs a full page load by setting window.location.

However, when calling Turbo.visit with a URL outside of our root domain, we get a SecurityError:
SecurityError: Blocked attempt to use history.pushState() to change session history URL from <our app's URL> to <external url>. Protocols, domains, ports, usernames, and passwords must match.

Am I reading the documentation wrong, or is the documentation outdated, or is this a bug? 🤔
Using Turbo (via @hotwired/turbo-rails) 7.0.1.

cc @ParamagicDev

@foca what browser is this on? Do you have a minimal reproduction I can look at? It looks like it's trying to pushState on what's probably a cross-origin path, but hard to say.


pull request for e2e test at 12/31/2016 11:56:15

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


Feature: Use existing s3 backup buckets in firehose module

Hello!
In the firehose module there is a variable s3_backup_custom_name, would it be possible to update the function so that if the bucket already exists then to use that instead of trying to create a new bucket?
Or perhaps a new variable s3_backup_existing_bucket and an accompanying IAM role s3_backup_role_arn  to use to access the bucket?
In my case I want to use a centralized bucket for backups that is pre-existing but the module doesn't account for this scenario.

Thanks for the feedback, I've opened an enhancement request to review this option. If this is a critical requirement for your business, please follow up with your Support or Sales representatives so we can properly prioritize this ask.

No worries, more of a suggestion so take your time.

+1

Hi @stefancarlpeiser, took awhile but in Terraform 1.5 the import block seems useful as TF is declarative so a data block cant even be referenced if it is conditional. The following works but does have the danger of replacing your existing bucket.
variable "new_bucket_name" {
  type    = string
  default = "new-bucket-test"
}

variable "exisiting_bucket_name" {
  type    = string
  default = "existing-bucket-test"
}

import {
  for_each = var.exisiting_bucket_name != null ? [var.exisiting_bucket_name] : []
  to       = aws_s3_bucket.data_bucket
  id       = each.value
}

resource "aws_s3_bucket" "data_bucket" {
  bucket = var.exisiting_bucket_name != null ? var.exisiting_bucket_name : var.new_bucket_name
}

## Test referecing the bucket ID
resource "aws_s3_bucket_public_access_block" "firehose_bucket_bucket_access" {
  bucket = aws_s3_bucket.data_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

fixed with https://github.com/coralogix/terraform-coralogix-aws/pull/175


Improve type inference to avoid long number -> real conversion

Long numbers such as imeis fall into the same trap as excel in that they parse as doubles but end up discarding important digits.
This is undesirable behaviour and we should add an additional check on the string length perhaps to avoid it happening

done


Write down how we will support changes in Mastodon API from a Bigbone library perspective

Let's create a new wiki page "API Support" and put contents in there based on the discussion here: https://github.com/andregasser/bigbone/discussions/13

https://github.com/andregasser/bigbone/wiki/API-Support


docs(readme): fix typo in deploy introduction

This commit fixed a typo in a sentence in the introduction about "Deploying using Docker".

tyvm


Todo: support integers greater than 64 bit

ion_writer_write_int in ion_writer.c: doesn't support anything larger than 64-bit

#37 adds support for writing arbitrary-precision ints.


Browse-By links (in navbar and on community and collection pages)

The purpose of this PR is to add links to the already existing browse-by pages added by #283 as well as expanding and refactoring those pages.
Changes to Browse-By pages

Added the ability to pass a scope parameter in the url, so only items or metadata within the given community/collection is displayed
Refactored Browse-By-Author to Browse-By-Metadata to allow other metadata definitions
Improved the title to show what Community or Collection we’re browsing in (using the new scope parameter)
Display a message when no items/metadata is found
General code refactoring and JSDocs

Links

Added /browse links to title, author and subject in the global navigation menu
Added the same links on Community and Collection pages, but using the scopes of these communities and collections

Notes
These links are still hardcoded. They should be replaced by a configurable solution in the future.
Created an issue for this: #361

I'm going to merge this as-is.  I've logged the Community/Collection homepage redesign as a separate issue: https://github.com/DSpace/dspace-angular/issues/365


Rectangle Crop

wanna make a square crop, like whatsApp profile pic

check the FAQ page.

@ArthurHub  thanks for ur quick reply


Allow inspecting intermediate state of pub when an error occurs

I'm hitting a bug in one of my transformers from code generated by another transformer, but there's no easy way for me to inspect what that generated code looks like. Since pub outputs no files when an error occurs, I cannot browse the intermediate state.
It would be great if on error there were some way that I could have pub dump 'the current state of the world' from the viewpoint of where that error occurred.

This issue has been moved to dart-lang/pub#930.


Fix wrong exit code in the check_format.sh.

Fix #13

Codecov Report

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

@@             Coverage Diff              @@
##             master      #14      +/-   ##
============================================
+ Coverage     63.12%   63.14%   +0.01%
  Complexity      584      584
============================================
  Files           264      264
  Lines         11159    11159
  Branches       1849     1849
============================================
+ Hits           7044     7046       +2
+ Misses         3158     3156       -2
  Partials        957      957

Impacted Files
Coverage Δ
Complexity Δ

...pay/sofa/rpc/client/aft/InvocationStatFactory.java
82.92% <0%> (-4.88%)
15% <0%> (-1%)

...ay/sofa/rpc/client/AllConnectConnectionHolder.java
52.79% <0%> (+0.27%)
0% <0%> (ø)
:arrow_down:

...pay/sofa/rpc/transport/ClientTransportFactory.java
65.15% <0%> (+4.54%)
0% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


support failover

We must check master is down and do failover immediately to guarantee high availability.
Using zk to select a master proxy to do this, maybe.

We need to design for this feature.


handle the case when google authentication token expires.

It seems that google revokes the authentication token after a period of time. Observe.dev should prompt users to log in again to get a new token. This needs more investigation.

Observe.dev now gives an error message and asks the user to refresh the page.


fix(S-89): update assignment label to better support languages with long translation

:tada: This PR is included in version 2.29.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


stopifyArray the array from makeArray function in lib220

call stopifyArray on the array returned by makeArray function

makeArray is not necessary. Use Array.create


Unlinkify Enhancement Request

The ability to redact links would be a useful addition where you can pass a string of what a url should be redacted to.
e.g.:
if(linksAllowed){
$Item.linkify();
}
else{
$Item.linkify('unlink', '[link removed]');
}

This is now available via the format option. Example here.


Polkadot-API transactions make Nova-android crash

Attempting to sign a transaction with a DApp built with Polkadot-API (from within the DApps section) completely crashes the Nova android app.
AFAIK Polkadot-API is adhering to the SignerPayloadJSON defined by PJS and signing transactions with PAPI DApps works with all the other extensions that we have tested it with: talisman, polkadotjs, subwallet, polkagate and fearless.
It goes without saying that, from the polkadot-api team, we are more than willing to help at solving this issue.
If you need a DApp to reproduce this issue, I would recommend using Kheopswap, built by @0xKheops.

gm, actually kheopswap.eth.link url isn't good, it ignores updates despite the fact that it's an IPNS link..
Please use https://kheopswap.xyz
Would be great if you could look into this, thanks in advance.

Hey @josepot @0xKheops ! I've checked the logs and it seems like dapp is not passing blockNumber field as a part of SignerPayloadJson:
{
  "id": "1714632049986.4",
  "msgType": "pub(extrinsic.sign)",
  "request": {
    "signedExtensions": [
      "CheckNonZeroSender",
      "CheckSpecVersion",
      "CheckTxVersion",
      "CheckGenesis",
      "CheckMortality",
      "CheckNonce",
      "CheckWeight",
      "ChargeAssetTxPayment"
    ],
    "specVersion": "0x0f4a10",
    "transactionVersion": "0x0e",
    "genesisHash": "0x68d56f15f85d3136970ec16946040bc1752654e906147f7e43e9d539d7c3de2f",
    "era": "0x00",
    "blockHash": "0x68d56f15f85d3136970ec16946040bc1752654e906147f7e43e9d539d7c3de2f",
    "nonce": "0x05",
    "address": "123aanTyAyypSRVxEyRGB6ywfJByZVxX6vknixn6PqASwiR8",
    "method": "0x28020837030801000002043205011f204df10500000000000000000000000041ff00000000000000000000000000002e33c5e14a53e874caa8e7c6d30bd20f6c51cda7dafaad1c465ca004fe61a63e010a03009efc1e1a32d5d9773f777c9f424d9edb5c89770fcb1f5b0505082463db61325c824f1200",
    "version": 4
  },
  "url": "https://kheopswap.xyz/#/swap",
  "origin": "dapp-request"
}

My guess is that is is related to dapp using Immortal era. By the way, It is unsafe to replay attacks so I suggest to switch to mortal eras instead.

Hi @valentunn thank you so much for looking into this. You are absolutely correct about the fact that by default transactions should be created as mortal transactions. We actually noticed that yesterday while working on this and we were about to change that. So, thank you so much for pointing that out!
That being said, the developer has the last word and the developer can choose to create an inmortal transaction. My understanding is that in those cases the blockNumber is bogus, and thus it's not necessary to pass it in the payload. Nevertheless, if this fixes the issue and it doesn't cause problems anywhere else, then it's probably easier if we make that change in our end 🙂.

@josepot yes indeed in case of immortal era blockNumber is always equal to genesisHash so its effectively redundant. But it would be great to still have it for the sake of consistency and simplification of implementation especially considering that its not a default (and expected) case as you pointed out. Not sure how it works in PJS currently but we never experienced such an issue before though it might be because there is no pjs dapp that use mortal txs
That said closing the issue for now with the consensus that PAPI will always supply blockNumber. Feel free to re-open in case there is a continuation


added pet_grooming to shop

Refs:https://github.com/openstreetmap/iD/issues/4939

Thanks! If I'm reading the code correctly, all instances of name: Pet Grooming_store need changing to name: Pet Grooming Store (remove the underscore and capitalise the S).
Otherwise all looks good!


Glob issues with 4.2.2 and Prettier

Starting with lint-staged version 4.2.2 I have glob issues when using with husky and prettier. Here's my lint-staged config:
"lint-staged": {
  "{app,test,config}/**/*.js": [
    "prettier --single-quote --tab-width 4 --print-width 100 --no-bracket-spacing --write",
    "eslint --fix --max-warnings 0",
    "git add"
  ]
}

And here's the error from prettier:
husky > npm run -s precommit (node v6.11.3)

 ❯ Running tasks for {app,test,config}/**/*.js
   ✖ prettier --single-quote --tab-width 4 --print-width 100 --no-bracket-spacing --write
     → TypeError: patterns must be a string or an array of strings
     eslint --fix --max-warnings 0
     git add
✖ prettier --single-quote --tab-width 4 --print-width 100 --no-bracket-spacing --write found some errors. Please fix them and try committing again.

Unable to expand glob patterns: {app,test,config}/**/*.js 4 100 /home/user/dev/my-app/app/entity/myEntity.js !**/node_modules/** !./node_modules/**
TypeError: patterns must be a string or an array of strings

Anyways, thanks for making this awesome tool and if I have time this weekend I'd be glad to look into this problem myself, just wanted to get this out for others to look at ASAP.

Looks like it’s related to #295.

@ltegman Could you please share your package.json? I am guessing you have an prettier entry in your package.json scripts. Also, could you add console.log(res.bin, args) before the following return statement and share the output ?- https://github.com/okonet/lint-staged/blob/1dc3bd60f301f52cb2e96f441338837ae363131e/src/runScript.js#L38-L45
@okonet Maybe we should have an issue template?

I was able to reproduce the issue with the following package.json:
{
  "scripts": {
    "prettier": "prettier",
    "lint-staged": "lint-staged"
  },
  // ...
  "lint-staged": {
    "{app,test,config}/**/*.js": [
      "prettier --single-quote --tab-width 4 --print-width 100 --no-bracket-spacing --write",
      "eslint --fix --max-warnings 0",
      "git add"
    ]
  }
}

@okonet I am not sure about the solution for this. Right now, console.log(res.bin, args) prints this:
npm [ 'run',
  '--silent',
  'prettier',
  '--single-quote',
  '--tab-width',
  '4',
  '--print-width',
  '100',
  '--no-bracket-spacing',
  '--write',
  '--',
  'E:\\Projects\\experiments\\test-lint-staged-script\\test\\index.js',
  'E:\\Projects\\experiments\\test-lint-staged-script\\config\\index.js',
  'E:\\Projects\\experiments\\test-lint-staged-script\\app\\index.js' ]

The issue is fixed for this specific case if -- is added before --single-quote. However this can cause issues in other cases:
λ .\node_modules\.bin\jest --onlyChanged
 PASS  test\findBin.spec.js
 PASS  test\index.spec.js
 PASS  test\runAll.spec.js
 PASS  test\runScript.spec.js
 PASS  test\runScript-mock-pMap.spec.js
 PASS  test\runScript-mock-findBin.spec.js

λ .\node_modules\.bin\jest -- --onlyChanged
No tests found
In E:\Projects\repos\lint-staged
  38 files checked.
  testMatch: **/__tests__/**/*.js?(x),**/?(*.)(spec|test).js?(x) - 11 matches
  testPathIgnorePatterns: \\node_modules\\ - 38 matches
Pattern: --onlyChanged - 0 matches

I think the right solution would be to not have a prettier script.

Thanks for investigating! Yes, the right solution imo would be just removing the scripts section for the prettier.
I’m wondering if we should just drop support for implicit npm run behavior whatsoever. We looking for the locally installed packages either way. I saw some confusion with this kind of issue before.

@okonet I think you are right about this being a source of confusion. If I have a bin and a script, the user probably does not expect the npm script to take precedence. Should we just ask the user to write npm run script-name instead(in lint-staged commands)? This would be a breaking change. We should probably do all the breaking changes in 5.0 branch.

Yes I have been think about doing this for some time now and it’s seems to be a better thing to do. I’ll create the next branch next week when I’m back from conference.

Thanks guys you just saved me a lot of headaches. I had the same issue 👍

Thanks for looking into this so quickly -- I didn't even realize lint-staged supported referencing npm scripts without using npm run until I was reading through this thread. Renaming our prettier script definitely seems like the easiest way around this for now.

@aleburato @Itegman, Glad to help 😄. And sorry for the bug 😅

Hey @aleburato, @Itegman, We just released lint-staged v4.2.3. Do you mind checking if it fixes the issue? Hopefully it did not introduce any new ones.

Hi all, I'm not sure is the same problem, but I've upgraded from 4.1 to 4.2.3 and my configuration now lint ALL the files (staged && not staged).

@cloud-walker, Could you share your package.json?
}

could you try to rename those scripts for example to be
"scripts": {
  "lint:js": "eslint src/** tools/**",
  "lint:styles": "stylelint \"src/**/*.css\"",
}

after that, run npm run precommit again.
does lint-staged work as expected?

It seems to work with the @luftywiranda13 advice, but to me seems a bit odd this behaviour, is documented somewhere?

@cloud-walker See https://github.com/okonet/lint-staged#what-commands-are-supported

However, we are planning to remove this behavior as it seems to cause some confusion.

Thanks!

@cloud-walker

It seems to work with the @luftywiranda13 advice

glad it helps!

but to me seems a bit odd this behaviour, is documented somewhere?

hmmm maybe. Actually we have to know how lint-staged run tasks in precommit hooks.
This was taken from our readme:

considering you did git add file1.ext file2.ext, lint-staged will run the following command:
npm run my-task -- file1.ext file2.ext

You get why it didn't work like you expect before?

yes its all clear now I've switched to a different script naming, BTW I still think the feature is a bit confusing, maybe 🤔

Fine for me. Renaming the prettier script is indeed a good practice on my side. I also agree implicit running npm scripts hurts more than it helps.

I also had included options in the prettier script in my package.json so the fix in 4.2.3 didn't work for me. I think not running npm scripts implicitly (or having them take a backseat to similarly named bins) would be the only thing that would fix this use case for me. Renaming the script is an easy enough workaround though :)

@luftywiranda13 Thanks for that tip.


PMID:21892171.  increased chromatin assembly at euchromatin

PMID:21892171.  increased chromatin assembly at euchromatin

mlo3delta
comment analyses showed that loss of Mlo3 induces H3K9me at selected euchromatic genes (Fig. 7a), which show increased accumulation of antisense transcripts in mutant cells (Fig. 7b).

no outstanding term requests in this session


Invenio whitepaper

Originally on 2012-01-27
It would be nice to write a sort of white paper documenting the whole Invenio at least in a bird view. Such a paper that can then be put e.g. on CDS, would then be possibly cited in other papers building around Invenio technology.

What about getting DOIs from @zenodo?

I would close this issue as it is kind of a metaissue like "improve documentation"? If someone has the time and wants to write the paper they can reopen the ticket or create a new one.

Yes, this is a meta issue that we don't need to have open in the issue tracker.


⚠ Bofrost.de has degraded performance

In bb5a259, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1749 ms

Resolved: Bofrost.de performance has improved in a4ab6d6 after 14 minutes.


Function signature not detected if the last line is code

The given example:
def foo():
    pass

Won't detect a signature without a blank line at the end.

I can't reproduce this.

Doesn't look like an issue... Should this be closed?


WAF dashboard - Cannot filter results using nonTerminatingMatchingRules.action field

Describe the bug
I cannot filter results on the WAF dashboard using the nonTerminatingMatchingRules.action field.
Expected Behavior
Can filter based on this rule
Current Behavior
Cannot filter
Reproduction Steps
N/A
Possible Solution
No response
Additional Information/Context
No response
Solution Version
v1.0.3
AWS Region. e.g., us-east-1
No response
Other information
No response

fixed in v2 https://github.com/aws-solutions/centralized-logging-with-opensearch/releases/tag/v2.0.0


Laravel 11 error stack trace missing

I'm not able to get the pencil icon on error page to move on my IDE, also the settings icon also not visible.

That is not ignition's error page.
Ignition is not shipped by default anymore, starting in Laravel 11.
The Laravel built-in error page resembles it, but has a more constrained feature set.
You can install ignition on your project by using:
composer require --dev spatie/laravel-ignition

That is not ignition's error page.
Ignition is not shipped by default anymore, starting in Laravel 11.
The Laravel built-in error page resembles it, but has a more constrained feature set.
You can install ignition on your project by using:
composer require --dev spatie/laravel-ignition

It's working, thanks @rodrigopedra


ax-saasbo-crabnet

Brief description of your algorithm
Recently, SAASBO has been demonstrated to be a highly effect high-dimensional Bayesian optimization scheme. Here, we use Ax/SAASBO Bayesian adaptive design to simultaneously optimize 23 hyperparameters of CrabNet. 100 sequential design iterations were used, and parameters were chosen based on a combination of intuition and algorithm/data constraints (e.g. elemental featurizers which were missing elements contained in the dataset were removed). The first 10 iterations were based on SOBOL sampling to create a rough initial model, while the remaining 90 iterations were SAASBO Bayesian adaptive design iterations. For the innerloops (where hyperparameter optimization is performed), the average MAE across each of the five inner folds was used as Ax's objective to minimize. The best parameter set was then trained on all the inner fold data and used to predict on the test set (unknown during hyperparameter optimization). This is nested cross-validation (CV), and is computationally expensive. See automatminer: running a benchmark for more information on nested CV.
Included files

matbench.py running a Matbench fold and splitting these into separate jobs, collecting results
metric.py Average MAE for CrabNet to supply to Ax as "Metric"
parameterization.py interfacing CrabNet API with Ax API
plotting.py plotting code
search.py Ax SearchSpace for CrabNet

@ardunn

Sounds good! Thanks @ardunn


Update for https check

as on my environment $_SERVER['HTTPS'] is not set and purl return "http" also if the url is on https, i added a second check on the server port.

Thanks!


Offset for the diag function

In matlab, cvx enables one to set a matrix with an offset of k from the diagonal, ie by diag(v, k).
If I write, for example, the following code :
import cvxpy as cvx

v = cvx.Variable(10)
cvx.diag(v, 2)

then it returns

TypeError: diag() takes 1 positional argument but 2 were given

Same remark about extracting the k-th diagonal from a matrix X by diag(X, k).
Is it possible to add this feature ?

done with PR above :)


fix: add in css in class link

Title and Issue number

Title : Added font-size, border-Shadow, Padding, margins to make sure the that the header and the hotel.html page looks much better clear.
Issue No. : #1066
Code Stack : HTML, CSS, JS
Close :

Description

I have added a font size attribute so that to make the website detailing more enhanced and clearly make the header text visible.
I have also made changes in Hotel.html page where I have made form looks more better and made made that Home button look bigger so that it fits in the page much better.
Video/Screenshots (mandatory)

Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Checklist:

[x] I have performed a self-review of my code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x] I have gone through the  contributing.md file before contributing

Additional context:

##Are you contributing under any Open-source programme?

[x] I am contributing under GSSOC'24
[ ] I am contributing under VSOC'24

@apu52 hey, I have just made the header look better by increasing the font size I have no issue no. to it. I was just observing the website and I thought to change it so it looks better.

@YashMall I HAVE SEEN your changes . But if u haven't make any type of issue for this PR , I can't assign you this PR. As per the rule of this repo first u have to make a issue & then only after u get assigned , u can submit your PR. So despite your changes , I have to close this PR as unplanned, At first u have to go through the contributing.md file before contributing.

@apu52 Hello, i have added the issue no. Kindly check to it, if possible.


KAFKA-14595 ReassignPartitionsCommandArgsTest rewritten in java

This PR is part of #13247
It includes ReassignPartitionsCommandArgsTest rewritten in java.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Thanks. I'm busy with other priorities this week. Feel free to merge.

Hello @gharris1727 Thanks for the review. Are you ready to merge this PR?

Hello @gharris1727
Is there anything I can do to get this PR merged?

The test failures in CI appear unrelated, and tools:test passes for me locally.

Thanks @nizhikov for your patience, and thanks for keeping people notified about this PR. Too many PRs like this one are left stale due to limited committer bandwidth.

@gharris1727 Thank you very much!


Hot-reload mapping

Set up INotifyWatch to monitor changes to the mapping file, reload the file when a change is detected.

There's also Watchdog.


group toggle icon misleading

great stuff!
I think the group toggle icon (+ | - ) should be the other way round:

indicates the group can be expanded

indicates the group can be collapsed

That's true I just realized it! fixed on version v0.1.2


Update the error class

I should probably be using TypeError instead of just Error when referring to an improper type being used in the constructor or one of the methods. Overall review of this would be fine.

Implemented via v1.1.1.


Private JSON classes

HI,
I used to use JSONXX classes from scala-js-bundler, but I can't anymore since they are now private in jsdepencies. Would it be possible to make them public again ?
Thanks !
Mathieu

No, we won't make them public. They are not part of the public API of jsdependencies.
Feel free to copy the source code into your own sbt plugin if you need them. They're EOL anyway, so it's not like you'll have to keep up with upstream changes. ;)

FWIW: I think the only reason these are even here in the first place (rather than using a library) is that this project was born in Scala.js core, where we cannot depend on anything.

OK. Thanks.


[Feature Request] Alloy single quoted aliases for enabled strictSQL mode

When the strictSQL is disabled (so the old query parser) we can use more "complex" aliases like field AS 'My-Alias'. Is is conceivable to add this functionality in enabled strictSQL mode?

Hi @Fraternel
You can use back-tick quoting, eg.
SELECT `My-Alias` from `My-Class`

Thanks
Luigi

Thanks you (again) Luigi it works perfectly! Perhaps I missed this explanation in documentation.


fill 2darray or recarray by fields is 30 times faster than by row.

import numba as nb
import numpy as np
from time import time

t_point = np.dtype([('x', np.float32), ('y', np.float32)])

points = np.zeros(2, dtype=t_point)

@nb.njit
def fill_by_row(points):
    first = points[0]
    for i in range(102400000):
        points[i%2] = first

@nb.njit
def fill_by_attr(points):
    first = points[0]
    for i in range(102400000):
        points[i%2].x = first.x
        points[i%2].y = first.y

fill_by_row(points)
start = time()
fill_by_row(points)
print(time()-start)

fill_by_attr(points)
start = time()
fill_by_attr(points)
print(time()-start)

fill by row cost: 0.07s
fill by x, y cost 0.0025s
what 's the matter? Is there some way to improve the performance of fill by row?

I found an intresting way:

generate string code in python
use exec to inject to locals
use jit function to compile it

def build_func(dtype):
    namepair = [(i, i) for i in dtype.names]
    names = ['points[i%%2].%s = first.%s' % i for i in namepair]
    local = {}
    func = '''
    def fill_by_attr(points):
        first = points[0]
        for i in range(102400000):
            %s
    '''%('\n'+' '*12).join(names)
    print(func)
    exec(func.replace('\n    ', '\n'), local)
    return nb.njit(local['fill_by_attr'])

fill_by_attr = build_func(t_point)

fill_by_attr(points)
start = time()
fill_by_attr(points)
print(time()-start)

it could be written like a decorator，to generate some customized function from Template.

@yxdragon thank you for reporting this, I seem to get different results here, where fill-by-row is faster? Or did I miss something?
 💣 zsh» python issue_9547.py
0.14577174186706543
0.34764719009399414

numba.version is 0.59.0, Windows 11.

@yxdragon do you have access to try on a different system, like Linux or OSX?

If I change the benchmark so it does more work (not just operating on the same element all the time):
import numba as nb
import numpy as np
from time import time

t_point = np.dtype([('x', np.float32), ('y', np.float32)])

N = 102400000

points = np.zeros(N, dtype=t_point)

@nb.njit
def fill_by_row(points):
    first = points[0]
    for i in range(N):
        points[i] = first

@nb.njit
def fill_by_attr(points):
    first = points[0]
    for i in range(N):
        points[i].x = first.x
        points[i].y = first.y

fill_by_row(points)
start = time()
fill_by_row(points)
print(time()-start)

fill_by_attr(points)
start = time()
fill_by_attr(points)
print(time()-start)

$ python repro.py
0.05387234687805176
0.05723166465759277

Do you get similar performance with this example?

@gmarkall yes, I get similar performance. So that's because the cpu cache works when operating the same block?

My intuition here is that your original microbenchmark is doing too little to permit measurement of the execution speed of the workload, and other confounding factors will make up the majority of the measured time instead.

Thanks, another question:
how to fill one row in jit function:
@nb.njit
def fill_by_row(points):
    points[0] = np.void((1,1), dtype=t_point)

I try (x, y), np.array((x,y)), np.void((x,y)), all not works.
And I found another issue, fill row with tuple.
https://github.com/numba/numba/issues/9476.

My intuition here is that your original microbenchmark is doing too little to permit measurement of the execution speed of the workload, and other confounding factors will make up the majority of the measured time instead.

I also find cur.x, cur.y = first.x, first.y is as fast as points[i] = first.
@nb.njit
def fill_by_attr(points):
first = points[0]
for i in range(N):
cur = points[i]
cur.x, cur.y = first.x, first.y


Fix links in EventedFd doc

Fixes carllerche/mio#743
The issue reports that RawFd, Evented, and Poll links aren't working, but as of the latest master, Evented and Poll links already work.
This change converts two instances of RawFd in the EventedFd documentation into a link to the Rust std library documentation:
https://doc.rust-lang.org/std/os/unix/io/type.RawFd.html
The issue links to version 0.6.10 documentation of mio where RawFd was a broken link, but in master, RawFd was changed to simply an inline code. Nevertheless, I think it's still better to make it a link for the following reasons:

Providing the link makes it immediately clear which type it's referring to.
In the documentation for Poll, WouldBlock links to the Rust std library documentation so there's precedence.

The change also makes an instance of Evented into a link for consistency. The &RawFd in the documentation was not changed.
The only testing made with this change is to generate the docs locally, and verifying that the links are working.

Thanks so much for this and sorry for the delay. CI has not been a good state. We got CI working on master! would you be able to pull in the latest master?

@carllerche updated my branch to get latest master. CI looking good. Thanks.


BaseObject: Add eventKey for handling on/off events

Why?

Avoid using callback memory address for identifying event.

Good job @diegomarcon! Thanks!


When sharing a dashboard, it is possible to hide certain filter options.

When sharing a dashboard, add the option to hide certain filter selections. This feature is particularly important for cross-border operations involving multiple site data switching.

refer to: http://{{ip}}:{{port}}/public/dashboards/id?p_country=ghana&p_site=1&hide=p_country


Give information about not-automated rules

As user of Zalando's API Linter I'd like to know which rules are not yet automated. This would improve API design process because as an API provider I would know which rules I should read. Furthermore it would help API reviewers to know on which aspects to concentrate because they are not covered by Zally.
Server should deliver in api-violations response a simple description text about not yet automated rules. This text should be configurable. CLI should display this text as part of summary.

Nice idea, I like it!

Server should deliver in api-violations response a simple description text about not yet automated rules.

Should it be a list of rules instead?

I think it should be just a text field (to keep it as open as possible for other users of our API linter). You can also provide a bullet point list in this text field - it's up to you what you write in the configuration for this text field.
Server should deliver this extra text field by default. We can make displaying of this text optional in CLI tool or having a flag to disable it.

@fmueller, clear. Should we hard-code that message for now?

I would start with a simple text variable read from spring config files. No need for hard-coding I think.


Remove duplicate state fuel site from arcgis online

Summary
It looks like there are two state fuel site items. Please determine which is the maintained version and deprecate the other.

StateFuelSites (item id: bbad0291cb754be48ae91dc7d82f6f5c)
Utah State Fuel Sites (item id: 34fbc5c654ee44c4bfb14c8d9fc73fc5)

UPDATE
We have gotten new data from the fleet folks. This will be used to replace the existing layer's per @gregbunce's comment on 15 Dec.

Triage

[x] Data Team Triage (@gregbunce)
[x] Dev Team Triage (@steveoh)
~[ ] Cadastre Team Triage (@rkelson)~

Remove StateFuelSites from the following areas

[x] ArcGIS Online (@gregbunce )

Deprecate/brownout Utah State Fuel Sites from the following areas:

[x] Mark ArcGIS Online Item as deprecated (@gregbunce )
[ ] Brownout ArcGIS Online Item (@gregbunce )
[ ] Deprecate the ArcGIS Online item (@gregbunce )

Add new data to the following areas:

[x] SGID Internal (@jacobdadams )

Update information to reflect the new data in the following areas

[x] gis.utah.gov data pages (@gregbunce  )
[x] Stewardship doc and sgid-index (@jacobdadams )
[x] SGID.META.AGOLItems (@jacobdadams )
[x] AGRC_Shelved/AGOLItems_Shelved (in AGOL) (@jacobdadams )
[x] SGID.META.ChangeDetection (assigned to)

Verify the new data is live in the following areas:

[x] AGOL (@gregbunce )
[x] SGID Internal (@jacobdadams )
[x] Open Data (@jacobdadams )
[x] OpenSGID (@steveoh on 2021/01/07)

Notification

[x] Twitter (@steveoh)

It also looks like auditor hasn't updated the thumbnail for either? cc @jacobdadams

Utah State Fuel Sites is in the AGOLItems_Shelved table, which is why it's showing up in shelved, with an origin of SGID.SOCIETY.StateFuelSites. It doesn't look like StateFuelSites is in either metatable, and I'm not sure when/how it was uploaded to AGOL.
As of now, auditor doesn't update thumbnails for shelved items. Items that have been moved to the shelf since we started running auditor regularly may still have their old branded thumbnails.

@brigsz do you have a good contact for this layer? I think we'll need to reach out to them in order to determine the correct layer. it appears the unofficial layer is getting use, while the authoritative layer is not.

It seems like over the last 6 months they're both getting the same amount of use- about 5 requests/day.

@brigsz do you have a good contact (person/agency) for this layer? maybe fleet operations?
I think we'll need to reach out to the steward in order to determine the correct layer. it appears the unofficial layer is getting use, while the authoritative layer is not.

I'll start with Fleet Ops

I contacted Fleet Ops to see if they can help determine which layer is most accurate.

Robert Slade
Assistance Director & State Fuel Network Manager
Division of Fleet Operations

Below is the spreadsheet with the lat long of all state fuel sites with card readers. We have a new site in Milford, Utah that is not on the spreadsheet and the lat. long is 38.404014, -113.010081.
This should help to ensure the map is accurate as we discovered many locations were not exact or far off. I had my team pin drop and get lat. long coordinates at each location.

https://docs.google.com/spreadsheets/d/1er49qTwC5iE8PuA1psa74BcSlejHaWJDxhOr_e3gwtc/edit#gid=916419563

thanks, nathan.  i created a utm12 feature class from the table and put it here.  I'll do some comparison on it between the existing sgid data and see what i find.

a couple of immediate observations show that the new data they sent is focused on northern utah.  see the map below where the green stars are the new data and the black outlines is the existing agol data.  also, the new data seems to be more precise with location, but the schema is not as robust.  @nathankota is Robert Slade the best contact?  do you want to reach out to him or should I?  essentially, we need to know:

is this new data the complete list of sites in Utah (99 records - opposed to the existing 106)?
is this new data the official schema for the layer?
should we replace the existing data with this new data?

Okay, we can do better than screenshots.  here's a quick agol map with the new layer and the two existing layers.
http://arcg.is/9TPSK

here's a quick agol map

do you want to switch to the imagery base map before sharing that?

yeah, i could.  i went back and forth.  see what you think... can you see the symbols well enough?  i could also do imagery only (not the hybrid).
http://arcg.is/9TPSK

Thanks for taking the time to build the map - it will be helpful to show Robert the issue. I just heard from him about 20 minutes ago that "There should be a total of 124 card reader sites and 115 State Park sites that only DNR has access to.", but the list he provided only had 99 records (minus some sites that are being removed). I will get in touch with him tomorrow and try to get closer to the bottom of it.

i know it's been out there for some time, but should this info be public?  also, is it relevant to anyone outside of state agencies?  we could host it and make it private.

update:

Still in contact with Fleet Ops about relevance and/or restrictions about it being public, and obtaining the most updated and comprehensive data.

Contacted DFCM about them being possible source of existing fuel site data, but they deferred to Fleet.

/remind me to ding Robert on November 3, 2020 (this is a test of the reminder bot too)

/remind me to ding Robert on November 4, 2020 (this is a test of the reminder bot too)

/remind me again on November 9, 2020
Robert supplied a new list, but it has way more than we need. He is willing to pare it down to just the fueling sites.

Still working with Robert at Fleet to obtain updated data and compare to what we have.

/remind me to ding Robert again on November 19, 2020

conductor results for tasks - 72

check
status

@gregbunce has completed 0 out of 1 tasks
:no_entry:

@steveoh has completed 0 out of 2 tasks
:no_entry:

@rkelson has completed 1 out of 2 tasks
:no_entry:

/remind me to check in again with Robert on December 7, 2020
This is still blocked - Robert expects to have some time to look at their data after Thanksgiving.

New data set received late last week. About 30 more locations than current data set(s), and looks like some addresses won't geocode. Data triage planning is in the works.

nathan, jake, and I chatted about next steps:

remove the duplicate layer: we feel that "StateFuelSites (item id: bbad0291cb754be48ae91dc7d82f6f5c)" should be removed now (it's most likely a remnant of data before what jake has coined the 'great agol migration of 2019').  we feel like Utah State Fuel Sites (item id: 34fbc5c654ee44c4bfb14c8d9fc73fc5) is the one we need to replace.
add the new state fuel sites data - bring into Internal and proceed without the 'shelved' status - b/c it will be looked at annually.
notify via blog post and twitter that this exiting shelved agol layer will be replaced.  run both layers concurrently for one month and do brownout.
remove the old, agol shelved existing layer
done

Ok. Go!

StateFuelSites has been deleted from AGOL and a copy of the data has been backup in the sgid deprecated layers in google drive.

@jacobdadams and/or others - i noticed i was assigned "Deprecate/brownout Utah State Fuel Sites from the following areas".
do i need to do anything other than get a blog post going with the details and then mark the agol items as 'deprecated'?

also, i'm thinking i should wait to mark it as deprecated until we have the new layer in agol and blog post published. agreed?

agreed

I'd say go ahead and mark it as deprecated now—it doesn't change how people
use it beyond (I think) making it rank lower in search results. I'll try
and get the new stuff uploaded soon.
On Wed, Dec 16, 2020 at 2:13 PM Nathan Kota<EMAIL_ADDRESS>wrote:

also, i'm thinking i should wait to mark it as deprecated until we have
the new layer in agol and blog post published. agreed?
agreed
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/agrc/porter/issues/72#issuecomment-747028051, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AJDGLXQB35P2TULP63XKWFDSVEPHBANCNFSM4SYPUMCQ
.

marked Utah State Fuel Sites as deprecated in AGOL.

Ok, the new data is in SGID internal as SGID.SOCIETY.StateFuelSites. Meta tables and stewardship doc have been updated.
Question: There is a spurious SGID.TRANSPORTATION.StateFuelSites entry in the stewardship doc. Am I safe to delete this?

@jacobdadams I'm not familiar with the SGID.TRANSPORTATION.StateFuelSites entry.  From my perspective, it can be deleted.

I'm working on a blog post now.  @nathankota are we replacing our current-version of this layer b/c it was out of date?  just getting the story in-line for the post.

I'll nuke the transportation entry.
FYI, I forgot to set the permissions on the new SGID table. I'll fix that today.

I'm working on a blog post now. @nathankota are we replacing our current-version of this layer b/c it was out of date? just getting the story in-line for the post.

In short, yes. Once we started digging to try to find out which of the duplicate AGOL items was most correct, it was realized that they were both outdated.

also, @jacobdadams do you have a rough idea when the new layer will propagate to agol/opendata?

also, @jacobdadams do you have a rough idea when the new layer will propagate to agol/opendata?

If the permissions get fixed today, then it should be lifted tomorrow morning and pushed to AGOL tomorrow evening.

Permissions have been fixed.

I’ve not convinced this layer warrants a blog post.  To me, based on its usage, it's more of a tweet or newsletter mention. but if we want to do it I would say it goes something like this...
There's a new [State Fuel Sites](waiting for link) layer in the SGID. This dataset will replace the existing ArcGIS Online [hosted feature service](https://utah.maps.arcgis.com/home/item.html?id=34fbc5c654ee44c4bfb14c8d9fc73fc5). AGRC worked with the Utah [Division of Fleet Operations](https://fleet.utah.gov/) to update and improve this data.

A few things to note

- There has been a change to the schema
- The new dataset will receive periodic updates
- The old layer has been marked as deprecated but, as a courtesy, will remain available until 00/00/2021
- Additionally, we will conduct a brownout on the deprecated layer on 00/00/2121

We suggest migrating your maps and apps to the new layer as soon as possible.

Thoughts on if we need one?  If so, I can get that draft cleaned up.

I just want to know who'll be around in 2121 to finally nuke it 😆

I'll keep an eye for the new layer in AGOL/Open Data today (it's not showing yet), and then I'll update the data page with the new info - Rick you're off the hook.
Let's bail on the blog post.  I think it might make us look silly.  We can roll with a tweet based on the info above, but let's wait till the data is live in AGOL/Open Data.
I'll keep an eye on it.

The AGOL item is live and I've run auditor against it, so it is also live in Open Data with the appropriate info.
However, the metadata didn't seem to come across. I'll troubleshoot that bit.

@steveoh what do you think about tweeting some variation of this info out?  the data is now live.
There's a new State Fuel Sites layer in the SGID. This dataset will replace the existing ArcGIS Online hosted feature service. AGRC worked with the Utah Division of Fleet Operations to update and improve this data.
A few things to note

There has been a change to the schema (we went from 17 to now 5 fields)
The new dataset will receive periodic updates
The old layer has been marked as deprecated but, as a courtesy, will remain available until 00/00/2021
Additionally, we will conduct a brownout on the deprecated layer on 00/00/2121

We suggest migrating your maps and apps to the new layer as soon as possible.

I am happy to tweet but it is much too long. Do you want try to trim it down and then I can hack it to fit in a tweet?

maybe something like this...
There's a new State Fuel Sites layer in the SGID. This layer has replaced the existing ArcGIS Online hosted feature service, which will be officially deprecated on 01/23/2021. Please migrate your maps and apps to the new layer.

also, how can set a reminder here?
I need to set two reminders for this issue and also mark it as 'waiting'

brownout on Jan 20th
official deprecation on Jan 22nd.

i see how to add the label.  is everyone okay if I mark it 'waiting'?  I'll do that right after i update the data page.

i just sent 3 tweets.
Use the /remind slash command to set a reminder on any comment box on GitHub and you'll get a ping about it again when the reminder is due.

Use any form of /remind me [what] [when], such as:

/remind me to deploy on Oct 10
/remind me next Monday to review the requirements
/remind me that the specs on the rotary girder need checked in 6 months

this hasn't made it to the open sgid yet from my last check

/remind me to brownout deprecated layer on Jan 20

/remind me to officially deprecate/delete the older algo layer on Jan 22

@jacobdadams are you able to conduct the brownout on Jan 20th?  If not, just let me know your process and I'll take care of it.

after reading the github label descriptions it seems like 'blocked' describes the current status of this issue.  we're waiting till Jan 22nd to move forward and close this out.

just let me know your process and I'll take care of it.

i think you update sharing for the item and call it good.

i think you update sharing for the item and call it good.

that makes sense.  thx.  I can handle that.

meeting update
brownout on 20th
delete on the 22nd
fix cloudb to import new table correctly

meeting update
brownout on 20th
delete on the 22nd
fix cloudb to import new table correctly

Downloaded and backed-up in AGRC Projects > SGID > deprecated layers
Deleted February 4, 2021


Update hooks.rb and compatibility with redmine 5.0.2

I suggest to change module RedmineBaseStimulusJS to module RedmineBaseStimulusjs
Under Redmine 5.0.2 it doesn't work with the Zeitwerk loader:
/usr/local/bundle/gems/zeitwerk-2.6.0/lib/zeitwerk/loader/helpers.rb:127:in `const_get': uninitialized constant RedmineBaseStimulusjs::Hooks (NameError)

	parent.const_get(cname, false)

        ^^^^^^^^^^

from /usr/local/bundle/gems/zeitwerk-2.6.0/lib/zeitwerk/loader/helpers.rb:127:in `cget'

This change was integrated a while ago. We can close this PR. Thank you for your contribution.


pep8: Fix E128 violations

I fix the pep8 E128 errors for a GCI task here.

Automated message from Dropbox CLA bot
@reallyly, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here.

Automated message from Dropbox CLA bot
@reallyly, thanks for signing the CLA!

Hi @reallyly, this looks good but is failing continuous integration tests. I think this might be tests being flaky, rather than anything wrong with your code. Could you please:

run git commit --amend
save with no changes
run git push -f to force push the change to your branch

This will trigger the tests to run again on this PR and we can confirm everything is good.

Thanks @reallyly this is great!
@timabbott this looks ready to merge to me.

@mjec You're welcome! I'm happy to help :)

Merged, after changing a few line-wrappings to avoid large blocks of code being deeply indented.  Thanks @reallyly!!


feat(app & service release process): resume last edited page during release process

Description
Resume to the last edited page during App/Service release process.
Changelog entry:
- **App & Service Release Process**:
  - enabled resuming to the last edited page during App/Service release process. [#1376](https://github.com/eclipse-tractusx/portal-frontend/pull/1376)

Why
Currently if I stop the release process and then get back to the app/service I need to click through all the steps I fulfilled already, It should be automatically resume to the last page where user stop.
Issue
https://github.com/eclipse-tractusx/portal-frontend/issues/1335
Checklist
Please delete options that are not relevant.

[x] I have followed the contributing guidelines
[x] I have performed a self-review of my own code
[x] I have successfully tested my changes locally

@kunalgaurav-bmw its not registration process -> it is release process. Pls change the text in both title and description

@kunalgaurav-bmw could you pls confirm whether only mandatory fields are being checked to increment or decrement the step?

@kunalgaurav-bmw Is it possible to determine the step based on response in the first step itself?
Create a helper file and move all the step specific conditions to the respective places,
function determineStep() {
if(firstStep)
 -> increment(1)
if(secondStep)
 -> increment(2)
 }

 function firstStep() {}
 function secondStep() {}

 like this ...

component will have only one condition in first step to determine the actual step. All the step based condition will be hosted in the main method as shown above


Confusing version references

Why "Creators Update" in six places? That was three years ago.

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

ID: 0d66a7a3-2230-d907-5ff3-b3f7ed8c166a
Version Independent ID: e437b87d-0845-bb6f-3b0b-8d9fd2b3013a
Content: Upgrade Windows devices to Windows Pro Creators Update - Microsoft 365 Business
Content Source: microsoft-365/business/upgrade-to-windows-pro-creators-update.md
Service: o365-administration
GitHub Login: @Sirkkuw
Microsoft Alias: sirkkuw

I updated the topic - hopefully more consistent now.

It still says "Creators Update" in three places (including index).


Failed to load Python extension for LZ4 support. LZ4 compression will not be available

thanks for sharing your work.
when I try to run  rosrun allan_variance_ros cookbag.py --input workspace/imu_calibration.bag --output workspace/cooked_rosbag.bag
I get this error :Failed to load Python extension for LZ4 support. LZ4 compression will not be available.
I instaled lz4 and roslz4 package but it still occur.What is the mistake?

I have a same problem.
How can I solve that......?

Have you installed rosbag ? Try pip install rosbag
Also, this step is not strictly required. You can use a non pre-processed rosbag.

ROS1 depends on python2.7, then your env is python3.
I solve this by reinstalling roslz4 to python3.

delete roslz4 in /opt/ros/xxx/lib/python2.7/site-packages
downlaod roslz4 from https://rospypi.github.io/simple
pip install


chore: Add example for docker usage

Can you help me understand this change? Why would the user want to run the long, verbose docker run command instead of doing docker-compose up, which achieves the same thing?

Personally, I wanted to know how to do both. And I think a hello world tutorial that shows users how to do both is better than one that shows them a single way.
You already included a one-line docker run command for the sentimentalyzer app in the README. I could ask you the same thing: Why did you add an example on how to start sentimentalyzer with the docker run command in the README when you create the same service and run in on a different port in docker-compose? Why even include that?
But to answer your question directly, I wanted to know how to do both to better understand the different was Cypress can be used and configured.
And I have multiple docker-compose.yml files for multiple development environments. When I just want to spin up Cypress on demand now I can do that in a one-liner (after I have built the image) from the parent directory to my e2e tests.
But I don't think it should ever be necessary for learners to articulate a rationale about why they want to learn how to do something different before they do it. I think how to do things differently is an end in and of itself.

Thanks for the detailed feedback!
I understand where you're coming from, but I prefer to keep the instructions simple and minimal. I'd rather not add alternative methods for achieving the same thing.

You already included a one-line docker run command for the sentimentalyzer app in the README. I could ask you the same thing: Why did you add an example on how to start sentimentalyzer with the docker run command in the README when you create the same service and run in on a different port in docker-compose? Why even include that?

That command shows how to run sentimentalyzer as a standalone app without Cypress so that the user can play with it themselves before they see how Cypress performs automated interactions with it.


Wider gitignore file, change config.ini to config.ini.sample

Changed the gitignore to a template one, to catch all the files generated by virtualenv and many others generated by various IDEs.
Also for us people frequently pulling the master branch, I changed the config.ini to config.ini.sample (and the README accordingly) to not reset the config.ini changes each time.

+1 for .gitignore but there seem to be a few files in here that weren't part of PR description

I just committed another PR that had changes to the config file and readme. I would like to commit the gitignore file, though. I'm not very familiar with GitHub. If you can change the PR to just include the gitignore file, I'd happily commit it. Thanks for the help!

The main idea is that every file that has to be changed by the user, or gets changed at runtime by the program, should be added to the gitignore file, so people pulling your repo changes don't get a merge conflict everytime. I just noticed that there are more files that need changing

snipe.py should not be edited by the user to specify the encrypt lib, it should be read from the config.ini
static/catch_data.json should be added to gitignore
static/inventory.json should be added to gitignore
static/stats.json should be added to gitignore

I'll see if I can remove files from this PR (never done it)

Thank you for the explanation. If you're not able to remove files from the PR it's no problem - just submit a new one with the gitignore file and I will commit it.

Synced my repo and resolved the conflict. Sorry for the dashboard file but looks like my editor changed the indentation.


uiOnParamsChanged not fired if used with componentProvider

This is a (check one box):

[x] Bug Report
[ ] Feature Request
[ ] General Query

My version of UI-Router is: (type version)
1.0.5
Bug Report
Current Behavior:
Clicking the "1" and "2" links inside the stackblitz app does not change the displayed param value because component's uiOnParamsChanged method is never called. However, if you comment away the lines 22-24 and uncomment line 21 (i.e., use component instead of componentProvider in the state definition), everything works just as expected.
Expected Behavior:
Clicking the "1" and "2" links inside the stackblitz app should change the displayed param value to, respectively, "1" or "2", because the component's uiOnParamsChanged is called whenever a state param value changes.
Link to Plunker or stackblitz that reproduces the issue:
https://stackblitz.com/edit/ui-router-angularjs-budr1v

The reason for the issue seems to be lying in this check: https://github.com/angular-ui/ui-router/blob/5fb93d042d5833514357d6e7956a4cf85be26900/src/directives/viewDirective.ts#L434

@christopherthielen sorry to bother you, but are there any news regarding this issue?

@Maximaximum thanks for the nice bug report.  will be fixed in the next release.

@christopherthielen could you please give a hint on when a new version is going to be released?


feat(common): make CompletionQueueImpl mockable [1]

Remove all the template member functions from CompletionQueueImpl, so
it can be refactored to an abstract class in a future PR. Simplify the
timers for the fake version of CompletionQueueImpl.
Part of the work for #4718

This change is

The API baseline reported a removed function:
completion_queue.h
namespace google::cloud::v1
CompletionQueue::MakeDeadlineTimer ( std::chrono::_V2::system_clock::time_point
deadline )

This is a false positive, the function moved to the .h file where it became inline and thus appears as removed because it is no longer in the .so file.


Optimize SELECTs on measurements with a large number of fields

Feature Request
Proposal: Currently, InfluxDB does not handle queries for a large number of fields in a memory efficient way.
Current behavior:
In a SELECT * query, iterator construction will create all of the cursors for a single series key in one iteration. If there are 1000 fields, the query engine will create 1000 cursors in each iteration. This can quickly exhaust all memory available on an instance.
There also does not currently seem to be a mechanism in the results JSON output to return partial results for a subset of the queried fields.
Desired behavior:
The query engine should limit the number of cursors created when there are a large number of selected fields in a query.
 The typical use case is to handle cases where a large number of field keys were created by accident. Since field keys are not able to be deleted easily, any subsequent SELECT * query on a database with a high number of fields will use a large number amount of memory.

I think we will likely have to just have some way to forbid that type of query with wildcards. At least with influxql, I don't think there's any way to change the number of cursors it creates for fields in the manner described because selecting multiple fields is essentially running a join operation between fields within the same series key and measurement.
The join is implicit, but it's there.


Updating the README.md file of face_detection project.

[GSSOC 23] The README.md of face_detection project has some grammatical errors and is also not very clear, it is needed to be updated.

Hello @sakshid2706 , I'm a contributor in GSSoC, this is my first contribution to the programme, can you please assign this to me?

Hello @PrathmeshN99 , Actually I am also a contributor in GSSoC, I have created this issue for my own contribution.

Go Ahead @sakshid2706

Thank You @avinashkranjan for assigning this issue to me.


Spikeglx filesize check

I came across some pair of spikeglx imec output files that have different value of filesize (of the .bin) file than that retrieved from the .meta file.
While this may be a faulty .meta file, but I think an exception should be thrown while parsing such a file.

Hi Saksham,
I would put an option to control this and by default I would not for ce the checking.
very often we reduce the bin without changing the meta file.
And it is the case for the file on tests.

@samuelgarcia Is the file reduction only for test files or do you do this also for files that are used in analysis? In the first case I would still think that we should always assume the data and metadata info is compatible, i.e. we should update the test files according to the file reduction.

@Saksham20 can you rebase on master? The failing tests should be fixed now.

@JuliaSprenger : some people reduce the file itself when it is too long. Sometimes just to try sorting.
Forcing the check of file size will be annoying. And this will lead to lot lot github issue.

@JuliaSprenger : some people reduce the file itself when it is too long. Sometimes just to try sorting. Forcing the check of file size will be annoying. And this will lead to lot lot github issue.
I would prefer a warning rather than a eroor for this.

But if a different file size, then it will construct wrong dimensions of the raw array from the .bin file no?

No because it use the size from the memmap not from the meta.

@samuelgarcia I changed the error to a warning. Do you think we can merge this?

I still think that forcing this check is a bad thing.
Very often the bin file is manually cut.
We should had this test as an option False by default.
I think using size from the real data (memmap) is better that the one from meta file.

Hi Sam,
for exactly these reasons there is only a warning when .meta and .bin contain inconsistent information and not an error. If the user works on cut files than this warning would be expected, but for complete sessions it can still detecting flawed recording sessions.


Convert scrambles to WCA Standard

Convert the scrambler for each puzzle to the standard provided by WCA, i.e. https://github.com/cubing/tnoodle
Help would be appreciated.

Has this been merged into master? Why is the issue still open?


delete the datasets in my account

i cannot delete the datasets which i don't need any more in my account

Great point! Yes, this feature is missing. It would be a good thing to have.


Support for documenting params with named types

Search Terms
@params params named types function
Problem
When documenting functions, it happens that params use named types. If this type is used only once in the while code, it is fine, but if this type is reused multiple times, it would be handy to document it within the function using it:
/**
 * Docs on the options Type
 * @property a - Nice ! But there would be cases when it is not enough
 * @property b - If the type is reused, then defaultValues would be wrong, for instance
 */
type MyOptions ={
  a: number;
  b: string;
};
/**
 * A function using named options
 * @param options Okay this comment is picked up
 * @param options.a This is absent
 * @param options.b This is absent too
 */
function fn1(options: MyOptions){
  return options
}
/**
 * A function using unnamed options
 * @param options Okay this comment is picked up
 * @param options.a With unnamed types it works
 * @param options.b With unnamed types it works
 */
function fn2(options: {a: number, b: string}){
  return options
}

export {fn1, fn2, MyOptions};

Here the comments for fn1 wont be picked up, nor in HTML or  JSON output.
Suggested Solution
Include all the @params tags within the function comments in the result JSON.

I did not try to clone the code yet and run it, but it seems to me that somewhere around here we look for comments which have @param paranName comment with paramName matching the name in the code. I guess we could return all comments which start by paranName. . And then it would be for the users to implement their own way of dealing with it while processing the JSON output.
I have attached a little example project (with the same code I pasted up in the issue, and commands etc)
tsdoc-param-functions.zip
What do you think ?

Copying this in from #2456:

Duplicate of #2147, which apparently I never pressed comment on my response to...
TypeDoc doesn't do this today as parameter display is tied to the type display. There's a proposed fix for the linked issue which I don't much like because it essentially hacks around this by adding extra @param tags on the parameter.
It also needs more design consideration for edge cases:

What happens if you specify a property that doesn't exist on the linked type? What if there's an index signature on the linked type?

What happens if you don't specify every property on the linked type?

What happens if the linked type doesn't actually exist as far as TypeDoc is concerned? (Marked with @ignore, present in some declaration file that's excluded with --excludeExternals)

What if the linked type isn't an object? What if it's an intersection of objects? A union?

I have come across this too. Any update?
I get warnings (similar to #2483):
[warning] The signature hooks/use-websocket-events.useWebSocketEvents has an @param with name "props.onlineCallback", which was not used.
/**
 * A hook to trigger callbacks on WebSocket API state changes.
 * @param props The hook's callback props
 * @param props.onlineCallback Called when the websocket service is done syncing with the controller.
 * @param props.offlineCallback Called when the websocket is disconnected.
 * @param props.connectCallback Called when the websocket is connected.
 */
export function useWebSocketEvents({
  onlineCallback,
  offlineCallback,
  connectCallback,
}: UseWebSocketEventsProps): void {

Granted the output provides a link to the interface and the interface is documented, however VSCode with eslint-plugin-jsdoc issues warnings if the destructured @param parameter.property style tags are missing, so I'm stuck with warnings in VSCode or Typedoc either way.
Perhaps an option to suppress these warnings when there is a link to the interface is enough?

Just switched from eslint-plugin-jsdoc to eslint-plugin-tsdoc and now I can remove the @param parameter.property style tags and VSCode no longer issues warnings.

+1

What do you think about the integration of this feature after the current release, @Gerrit0 ?

It is still planned to happen at some point, that's why the issue is still open.


Instructions discrepancy

Challenge http://beta.freecodecamp.com/challenges/waypoint-target-the-children-of-an-element-using-jquery has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
In this waypoint, the initial instructions request the user to modify the children of #right-well with the color of green.  I correctly entered the code: $('#right-well').children().css('color', 'green'); which changes the text of the children elements of #right-well.
The advice window states:
Your "target6" element should have green text.
And as shown in the screenshot, #target6 does have green text.

The test for colors was incorrect. I have fixed it in https://github.com/FreeCodeCamp/freecodecamp/pull/1706


⚠ Thumbnails API Endpoint has degraded performance

In 91698c1, Thumbnails API Endpoint (https://thumbnails.roblox.com/v1/assets?assetIds=82738847&format=Png&isCircular=false&size=30x30) experienced degraded performance:

HTTP code: 200
Response time: 4744 ms

Resolved: Thumbnails API Endpoint performance has improved in 3992057 after 24 minutes.


Install Jenkins plugins with password not working due changes in Ansible

Ansible now doesn't allow to pass the url_password as param to the jenkins_plugin task. Instead, url_password is passed as task parameter.
I don't know where this was changed in Ansible, but you an see a commit where doc is updated here:
https://github.com/ansible/ansible/commit/863fcb5aced55fd9ce3080905bd6405c8bfd0511.

The error message from Ansible is "Do not specify url_password in params as it may get logged".

Updating tasks/plugins.yml by setting url_password as a task parameter, and it works.
Do you need a PR for this ? (I'm an ansible padawan so maybe there are good reasons for not updating it yet)

There's already a PR for this issue: https://github.com/geerlingguy/ansible-role-jenkins/pull/171

Fixed via #171 — thanks!


Use relative path in main field

Fixes #65

Hi, sorry, but this is exactly the same thing. The problem is that src/index.js does not exist.

Sorry, I thought this was about #62 specifically. Will merge, but it has no effect either way


Permissions are not requested, correctly anymore

Basic Information
Device type: Galaxy S8
EasyPermissions version: 2.0.0 / 1.3.0
Describe the problem
What happened?  What did you expect to happen?
We discovered the same Problem as #255 after upgrading from compileSDK 26 to 27/28. (Permissions always return false, and no Dialog appears)
Because of that an our application is to big to get a good example i started a test with a fresh project.
https://github.com/ItsReddi/permissiontest
In the above Project mostly anything is doing right.
But the following problems i have found:

@AfterPermissionGranted(PERMISSION_TEST) is not called after permission was granted
If you restart the app you will see permission is granted in the log.
if i go to appsettings and disable the permission
Permission is not granted, requesting it is logged, but nothing happens

if i go to appsettings and disable the permission
Permission is not granted, requesting it is logged, but nothing happens

onRequestPermissionsResult is not called if permissions are disabled via appsettings and you trigger requestPermissions

@ItsReddi thanks for providing the sample project!  I was able to reproduce and fix your issue.
In your sample project you had this:
    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        Log.v(TAG, "onActivityResult");
        permissions();
    }

But you need to add a line:
    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        // ** ADD THIS LINE **
        super.onActivityResult(requestCode, resultCode, data);
        Log.v(TAG, "onActivityResult");
        permissions();
    }

In general you always want to call super when using onActivityResult or you can get strange behaviors.


translating       TaskSpec to Pod: error getting image manifest

version: v0.17.2
taskrun:
  podTemplate:
    dnsConfig:
      nameservers:
      - <IP_ADDRESS>
      - <IP_ADDRESS>
      - <IP_ADDRESS>
    imagePullSecrets:
    - name: demo-registry
  resources:
    inputs:
    - name: demo
      resourceRef:
        name: demo
    outputs:
    - name: resourceImage
      resourceRef:
        name: demo-resource-image
  serviceAccountName: demo
....

service account:
secrets:
- name: demo
- name: demo-git-token
- name: demo-git-privatekey
- name: demo-registry
- name: demo-token-gzcjp

secrets:
apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJyZWd...
kind: Secret
metadata:
  annotations:
    tekton.dev/docker-0: https://demo.myregistry.com
type: kubernetes.io/dockerconfigjson

@ycyxuehan Does this remain an issue for you?

Hello, i'm still having this issue as of
gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.29.0@sha256:72f79471f06d096cc53e51385017c9f0f7edbc87379bf415f99d4bd11cf7bc2b
installed from tektoncd/operator and only when the task's step args key is defined, if I add the command key too, it goes flawlessly.
Relates to:

https://github.com/tektoncd/pipeline/issues/2707
https://github.com/tektoncd/pipeline/issues/3105
There's a workaround when you're running without the operator installing the pipelinescontroller:
https://github.com/tektoncd/pipeline/issues/1539#issuecomment-640457021
How would one do it with the operator installing the pipelinescontroller ?!

If the image is private and requires credentials, those credentials must be available to the tekton-pipelines-controller SA (the SA that runs the Tekton controller) as an imagePullSecret. The Tekton controller uses this to get image metadata to determine what command to run when a step starts, which it only needs to do when the step spec doesn't explicitly specify it.

I'm having the same error after adding imagePullSecret to tekton-pipelines-controller service account. Guess I'll need to define every command from now on.

Reverting to 0.23.0 works too

I think this will prevent from using our credentials via an imagePullSecret: https://github.com/tektoncd/pipeline/commit/49a7fa2db63fc633190da260d7167c05a8a7a91d
It's still there as of today: https://github.com/tektoncd/pipeline/blob/main/config/controller.yaml#L99
But commit message says it's needed Oo
I'm lost. Would there be a way to delete those environment variables from the operator ? Asking for a friend :)

Same issue here, related to #2707.
We're running v0.30.0 on EKS and are running into this issue with ECR. Prior to this we were on v0.19.x.
I've currently managed to work around the issue by copy-pasting entrypoint commands. Deleting the dummy env vars from our (custom) Helm chart seemed kind of a big risk to me with the Go AWS SDK not being updated yet / no structural fix known yet for #4087.
A structural solution would be nice.

If you're running in AWS I would expect (tho can't confirm) that removing the env vars should be fine. We're slowly making progress on #4087 but I'm having a bit of trouble compiling and testing with the update that brings in the newer go aws sdk.


Changed the price variable to expect a float. Mission Control issue #86

Description

The price variable in Mission Control was a string and being converted to float in Missions. I changed this so that Missions expects price to be a float already. This goes along with the change I made to mission control in this pull request https://github.com/DAVFoundation/missioncontrol/pull/108#discussion_r158684336.
Related Issue

https://github.com/DAVFoundation/missioncontrol/issues/86
Motivation and Context

It fixes an issue in which the price variable was a string but should be a float.
How Has This Been Tested?

I tested by opening the app and ordering a drone. The price displays 2 decimal points unless it ends in a 0. For example something with the price 3.60 would display as 3.6. For some reason I couldn't call toFixed(2) where the price is being displayed in the UI.
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Great stuff!
Just two very minor comments because we are so close to perfection here, so why not push a bit more :)


[Bug] Firefox crashes when setting the itemStyle while using the SVG renderer

Version
5.5.1
Link to Minimal Reproduction
https://echarts.apache.org/examples/en/editor.html?c=bar-stack-normalization
Steps to Reproduce

Use Firefox (latest version 132.0.1)
Go to the official bar chart example (https://echarts.apache.org/examples/en/editor.html?c=bar-stack-normalization)
Add the following definition to the series definition:

itemStyle: {
    shadowColor: '#000000',
    shadowBlur: 0,
    shadowOffsetX: 0,
    shadowOffsetY: 1,
  },

Switch to the SVG renderer
Firefox crashes

Current Behavior
Firefox crashes when setting the itemStyle options
Expected Behavior
Firefox should not crash
Environment
- OS: macOS 15.1 (happens in Windows too)
- Browser: Firefox 132.0.1
- Framework: Official ECharts website

Any additional comments?
No response

Hi! I just tried this with a fresh install of Firefox and my browser didn't crash or give any issue. Have you tried this with another computer (if you can)? This is my setup:

Hi! I just tried this with a fresh install of Firefox and my browser didn't crash or give any issue. Have you tried this with another computer (if you can)? This is my setup:

Sorry. I made a mistake with the steps. The crash happens when you add the code to the series definition.

cannot reproduce with next (current) version 132.0.2 - Demo

cannot reproduce with next (current) version 132.0.2 - Demo

I retried it with the new version but the browser still has some problem in my case. The page can blank out for some time or crash (the page, not the browser). Thank you for trying on your system @helgasoft


METRON-435 Create Stellar REPL

Created this for debugging some issues I was having in running Stellar functions are on a live cluster.  Thought this would be generally useful on its own.
METRON-435
Create a REPL (Read Eval Print Loop) for the Stellar language that helps in debugging, troubleshooting and learning Stellar. The Stellar DSL (domain specific language) is used to act upon streaming data within Apache Storm. It is difficult to troubleshoot Stellar when it can only be executed within a Storm topology. This REPL is intended to help mitigate that problem by allowing a user to replicate data encountered in production, isolate initialization errors, or understand function resolution problems.

did you mean to title this METRON-435?

Oops, yes.  Let me fix.

Also, added a doc string type functionality.  I couldn't help myself.
>>> ?PROTOCOL_TO_NAME
PROTOCOL_TO_NAME
 desc: Convert the IANA protocol number to the protocol name
 args: IANA Number
  ret: The protocol name associated with the IANA number.

What, no autocomplete? ;)

+1, we can iterate from here.  I think this is going to be super useful.

Ha, trust me, I wanted to do it.

Bonus points if you had used https://github.com/qmx/jreadline and given us emacs and vi mode as well as a hook for autocomplete :)


fix(form): method 'validate' unable to complete execution properly

It seems that this bug already fixed in v2.37.1, great~


Unable to setup any Redirection Host

Checklist

Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?

Yes

Are you sure you're not using someone else's docker image?

Yes

Have you searched for similar issues (both open and closed)?

Yes

Describe the bug
On version 2.12.1 (which I updated to yesterday), seem to rendered setting up any new Redirection Host broken.
No matter what domain I put in in "Domain Names" or in "Forward Domain". Kept getting the message "data/forward_scheme must be equal to one of the allowed values".
Nginx Proxy Manager Version
v2.12.1
To Reproduce
Steps to reproduce the behavior:

Go to 'Redirection Hosts'
Click on 'Add Redirection Host'
Add any new "Domain Names" and "Forward Domain"
Error in red pops up - "data/forward_scheme must be equal to one of the allowed values"

Expected behavior
New Redirection Host get added without any errors.
Screenshots

Operating System
Hosted in Debian 12. Standard Docker install.
Additional context
Tried it on multiple NPM instances running 2.12.1. Ran on a NPM running version "v2.11.3" and it's working fine.

I have the same problem

Same for me on version 2.12.1

Same for me also version 2.12.1
also existing hosts cannot be altered, same error.
seems like SSL certs for the redirection hosts cannot be renewed due to this error.

Can confirm v2.12.1

Can confirm v2.12.1

Having the same issue

Same issue
in my case, setting "Scheme" field to "http" or "https" fixes the problem. (It seems like there is a problem with processing the "auto" value for Scheme in the backend).

Sure, though the issue is now that it now forces you to pick http or https, instead of just keeping whatever you want.

I'm also encountering this issue on the lastest docker version of 2.12.1

And resolved the same problem by changing the Scheme option to http from auto.
The message points out that the issues with the scheme


Client: New command overrideAllFalsePositives

Hi :)
Please add a new command overrideAllFalsePositives that awaits the same file as markFalsePositives. But in contrast to markFalsePositives the new command should throw away all previously marked false positives and should then add all the new false positives from the provided file.
Why?
Like we discussed in the meeting, we would like to have a false positive file as a single source of truth in our repository and plan to use the new command overrideAllFalsePositives in our pipeline to update the false positives prior to executing the scan.

The action will be called defineFalsePositives.
Closing this issue in favor of #2077.  Please check there for the details of the implementation.


chore: don't show null bc registry ids

Card: https://app.zenhub.com/workspaces/climate-action-secretariat-60ca4121764d710011481ca2/issues/bcgov/cas-cif/870
Only show bcRegistryId if it exists for legal operators.

Looks like the 'edit contact' e2e test broke? The contact is not set anymore


RGB10 global hotkey not working in latest release

Before submitting your issue or feature request.  DO NOT REQUEST ASSISTANTS FOR PRELOADED IMAGES.  I do not support or condone the use of preloaded ArkOS images.  Preloaded meaning images that come with copyrighted roms preincluded.  Look for support from the creator or supplier of those preloaded images, not from here!  If a ticket is submitted for assistance for such images or if there's an indiciation that a preloaded image is what the support request is for, the issue ticket will be closed with no further response.

This is not the Stock OS that comes with your device, AmberElec, JelOS, or UnOfficialOS.  ArkOS is a different distribution from those systems and will have differing features.  The only somewhat similarity is that they both use EmulationStation as a frontend.  Even with that, the versions of EmulationStation that's used in between ArkOS and these other distributions is different with different capabilities.  If there are features you prefer with the other available distributions, just use those distributions instead.  The choice is yours.

Have you reviewed the Frequently Asked Questions section available for your supported device in the wiki?

If your issue is related to being able to run certain emulators or ports, have you reviewed the Emulators and Ports section available at https://github.com/christianhaitian/arkos/wiki/ArkOS-Emulators-and-Ports-information for needed bios files and supported rom extensions?

Have you reviewed the known issues section available at https://github.com/christianhaitian/arkos/wiki/Known-issues ?

Describe the Issue (If applicable)
Global hotkey not working in latest release
How can the issue be reproduced? (If applicable)
Always happen
What device are you using?
RGB10
What version of ArkOS are you on?

You can find this during the initial boot process right before the Emulationstation loading screen
09292023

Anything else you'd like to include that may help to review this issue or feature request?

I just tested this and the global hotkey works fine on my end.  Try going to Options>Advanced>Fix Global Hotkeys and see if that fixes the issue on your end.

Any update on this?


chore: add a log on the parentId set null

Let's measure how many users are impacted by this bug and experiencing the data linking issue.

adding a error creation upon parentId set null (this should not happen now)
adding error stack capturing by Sentry

Closes INS-3301

@gatzjames this change is irrelevant to the cause of the test failure here. Even in develop it fails when you run
npm run test:bundled-inso --verbose

@gatzjames this was a tricky to find the root cause and fix. I currently added a temporary hack around in the database module that is used in both inso-cli and insomnia desktop client. In my opinion, this is not a great architectural choice made. Maybe I am missing out something here, but why is inso-cli relying on NeDB? Why is it relying on a persistence? Shouldn't the cli tool to be fire and forget if it was designed to be run in the CI/CD pipeline? CLI and the electron app is so coupled, and this decoupling should be in place ESPECIALLY if Insomnia product wants to revamp the testing feature in my opinion.

I added a HACK to bypass this. Please go ahead if you find a better fix on this.

We are adding the sentry log to measure the data loss issue under the pressure, but ideally we should log the case happening here and fire them in batch outside of the database context.

nedb is required by inso cli because running requests and tests requires reading context from the db, inso also allows you to point it at different db folders. we have yet to find a good high level solution to this, i would advise leaving some breadcrumbs for someone to undo your hack incase it blocks some upgrade or feature in the future

Not sure if there is more thing to give as breadcrumb. Future contributor should be able to learn the context in this PR description and threads. They can remove the following functions introduced by this PR: assertModelWithParentId(), registerCaptureException()


Support embedded toml config

There's currently no way to parse a toml string and initialize the logger using the log4rs public API. Internally, log4rs has the PrivateTomlConfigExt::unpack method which returns a config::Config that can be passed to init_config.
This could be accomplished in a number of ways -

Implement Clone for config::Config so that toml::Config::config() can be used to produce an owned config::Config.
Implement From<toml::Config> for config::Config
Change init_config to take a borrowed config::Config instead of taking ownership of it
Make the PrivateTomlConfigExt::unpack method part of the toml::Config public API.

This seems pretty reasonable. I'm in the middle of a pretty big overhaul over on the breaks branch and I'll work this in there.

Thanks for the update! I ended up making a branch in the mean time where the toml::Config::config() method consumes self and returns an owned config::Config instead of a reference.

Released!

\o/ Thanks for all the work you've put into this recently!


path/filepath: filepath.Abs("") returned different results in windows and other systems

What version of Go are you using (go version)?
1.10.3
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
darwin,amd64 and windows,amd64
What did you do?
abs, err := filepath.Abs("")

example code
What did you expect to see?
filepath.Abs("") returns same results in all systems.
What did you see instead?
In windows, filepath.Abs("") returned an error which is The filename, directory name, or volume label syntax is incorrect.
And in macOS, filepath.Abs("") returned current working directory.

This is #24441 and it should be fixed on tip (to be released as Go1.11 soon).

Closing as duplicate. Please let us know if this isn't fixed in go1.11beta2.


Replace 'bpf_get_stackid'

The native bpf_get_stackid function is broken by design.
First, stacks can suffer from hash collisions and we can lose stacks.
We receive collision errors in userspace b/c we do not set
BPF_F_REUSE_STACKID.
Second, there is not a great way to reduce the frequency of collision
(other than increasing map size) b/c multiple probes can be sharing
the same stack (remember they are hashed). As a result, we cannot
delete entries in this map b/c we don't know when all the sharers
are gone.
This diff implements our own get_stack_id function utilizing the
quick hash function murmurhash2:
https://github.com/aappleby/smhasher/blob/92cf3702fcfaadc84eb7bef59825a23e0cd84f56/src/MurmurHash2.cpp
This involves:

creating a scratch map (the stack is too large as a stack var)
calling bpf_get_stack to populate the stack
calling murmur_hash_2_func_ to get the stack id
storing the stackid and stack as a key/value in a hash map

More details:
https://github.com/bpftrace/bpftrace/issues/2962

Checklist

[ ] Language changes are updated in man/adoc/bpftrace.adoc
[ ] User-visible and non-trivial changes updated in CHANGELOG.md
[ ] The new behaviour is covered by tests

I think I need some help here. I was running into a similar verifier error that @Birch-san ran into here: https://github.com/bpftrace/bpftrace/pull/241
Specifically this:
invalid access to map value, value_size=1016 off=1016 size=8
R2 min value is outside of the allowed memory range
processed 2557 insns (limit 1000000) max_states_per_insn 4 total_states 30 peak_states 30 mark_read 5

Which only happens on llvm-12. It works fine on llvm-17.
The problem is in the get_stack_id function. If I hard-code the "len" param then it works just fine but obviously, this is not what we want.
I've tried so many different variations and if/else additions to try and bound the value of len to be above 0 and below 127 but nothing seems to work.
Any advice would be greatly appreciated.

Ok, I think this is ready for a look (cc @javierhonduco to make sure I implemented the hash function correctly).

One thing I was curious about is whether the scratch stack should be memset'd. I could not find the code for this, but perhaps I have missed it. This would be important to avoid corrupted stacks, as data from the previous stored stacktrace might be there.

Good call. I forgot to do this. I think we should just memset as that's the most straightforward. But I don't feel strongly.

did you consider sending up the stacks synchronously via the ring buffer? basically instead of pulling out a map key we pull out the actual stack here.  I think it should be possible -- was there an issue with that approach?

TBH, I didn't consider this option as I was mostly focused on just resolving the bad stack id generation in bpf_get_stackid but let's talk it through. For cases when we're synchronously printing the kstack or ustack, I think it makes sense to put it in the ring buffer and not store it in a map at all. For the cases when we're aggregating stacks in a map (e.g. @m[ustack] = count();, then I think we need to keep them in a map and use the kernel-space generated id because the raw stack as a key would be too large (at least for older kernels). How about I look into the first part for synchronous printing as an optimization in a later PR?

Ah yeah I see in the issue that pre 5.11 kernels have key size limitation of 512B. That's unfortunate. Part of me wants to say that on older kernels we'll just have to eat the 64 frame limitation. And on newer kernels the issue goes away. IMHO it's worth it for the reliability and predictability. Would be nice to not have to look over our shoulders for this issue.
If @javierhonduco says this approach has worked well in the past, then I'm willing to accept that on faith :) . Seems like a strict improvement for now.

Part of me wants to say that on older kernels we'll just have to eat the 64 frame limitation. And on newer kernels the issue goes away.

Meaning we try to check the host kernel version and set the stack limit to 64 in user space? How much do we have to "worry" about different distros backporting patches that would support larger keys on older kernel versions? Looking at some Meta data (get it?) it seems like even symbolicated stacks, which include inline functions and both user and kernel frames rarely break 80 frames. So maybe 64 is ok.

We would probably do a feature probe for 513 bytes or something. Better to test functionality itself rather than look at a proxy like version number
On Thu, Mar 21, 2024, at 6:32 PM, Jordan Rome wrote:

Part of me wants to say that on older kernels we'll just have to eat the 64 frame limitation. And on newer kernels the issue goes away.

Meaning we try to check the host kernel version and set the stack limit
to 64 in user space? How much do we have to "worry" about different
distros backporting patches that would support larger keys on older
kernel versions? Looking at some Meta data (get it?) it seems like even
symbolicated stacks, which include inline functions and both user and
kernel frames rarely break 80 frames. So maybe 64 is ok.
—
Reply to this email directly, view it on GitHub
https://github.com/bpftrace/bpftrace/pull/3060#issuecomment-2013965068,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGJKJ7RILEQHTGUOSRUE4TYZNNXNAVCNFSM6AAAAABEWJPXDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJTHE3DKMBWHA.
You are receiving this because your review was requested.Message ID:
@.***>

--
Daniel Xu
@.***

@danobi So how do you feel merging this as is or would you rather me dig into the storing of stacks as keys.

Yeah, let's go with this approach for now. Another thought I had was it might be tricky to use raw stacks as keys. Would probably need to size the key to at least kernel.perf_event_max_stack sysctl?
Btw, had not gotten a chance to review PR yet. Not that necessarily you need to wait for my review

Another thought I had was it might be tricky to use raw stacks as keys. Would probably need to size the key to at least kernel.perf_event_max_stack sysctl?

That's what I thought you meant above. But yeah, that's what I'm currently trying to work on.

BTW, I think we can do away with this logic for ustacks: https://github.com/bpftrace/bpftrace/blob/master/src/ast/passes/codegen_llvm.cpp#L163
I don't understand why we're including the pid and probe id for the stack id. Aren't we doing all the things to prevent ASLR issues in the usym cache logic in user space via UserSymbolCacheType ?

Thinking again, what about BPF_MAP_TYPE_LRU_HASH? Over BPF_MAP_TYPE_HASH. In the event the map fills up, it'd be strictly better to drop the oldest entries rather than drop the newest ones, right?

Thinking again, what about BPF_MAP_TYPE_LRU_HASH?

Ah good idea. I guess my only concern is the possible perf hit from checking the global LRU list. There is also BPF_F_NO_COMMON_LRU flag but I haven't done any benchmarking with any of these things.

I'm curious what the overhead would be. But I think I'd still choose (more) correctness over performance in this case. Cuz the reliability of stack collection is pretty important and we've had issues in the past

But I think I'd still choose (more) correctness over performance in this case.

Fair. I'll update the map type.

Gonna merge soon unless there are any other issues I missed.

@danobi - Just wanted to post an update. I looked into using the stack as the map key and got a mostly working version but I came to realize that in the case of aggregation functions e.g. count, sum where folks aggregate on the stack e.g. @map[kstack()] = count(); these maps are of the PER_CPU variety so we'd be storing a lot of duplicate stacks. We could go with something like what I first proposed in this issue: https://github.com/bpftrace/bpftrace/issues/2962 Or perhaps different strategies depending on the context of the kstack or ustack. Anyway, I think this requires a bit more thought.


Entries with downloaded chapters disappear from the library

Steps to reproduce

select an entry
download any chapter
notice entry disappearing from library

Expected behavior
Entries shouldn't disappear
Actual behavior
Entries disappears after downloading any chapter
Crash logs
No response
Mihon version
1.16.5
Android version
13
Device
Samsung S20FE
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have gone through the FAQ and troubleshooting guide.
[X] I have updated the app to version 0.16.5.
[x] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

No downloads

Downloaded 1 chapter

After restsrting app it disappeared

Do not show source names
Settings > Advanced > Invalidate Download Index

You have filters on. Make sure you're not filtering out downloaded series