Annotation of SCMS Metric

Following discussion in the Value working group on July 30, 2020, and review of comments we agreed to proceed with releasing an annotated version of the metric that reflects the discussion, and itemizes candidate atomic metrics that need to be developed. That list is possibly neither complete, nor correct in the end. Continued development of the SCMS may occur as a metric, or a CHAOSS project.
SCMS has great potential for providing widespread benefit to countless open source communities, and the effort placed into its development to date warrants recognition.

Soooo to start with...
Can we have permission to quote this until everyone's sick of hearing it?
"SCMS has great potential for providing widespread benefit to countless
open source communities, and the effort placed into its development to date
warrants recognition."
Just wow, that comment blew us away. Anyway, though, we took some time to
think about the future of the SCMS with CHAOSS, and we love all of the
annotations and changes we're seeing.
While fitting the SCMS into a "metric" rather than the "system" we
originally defined it as was shoving it into a square hole, it was also
forming the system into something new and we are excited to see where it
goes.  Additionally, the social currency metrics we identified to build the
system were intended to make concrete measurements out of vague concepts.
This new opportunity seems to be the next step in that iterative process
and this time we're grateful we have a community to help us do it. Making
these more definable was always the goal, and we'd love it if we can follow
that process with CHAOSS to make the system more useful.
So, in short, yes, absolutely, we are in alignment with this and in
agreement that moving the SCMS from a metric to a group of metrics in a
defined system is the way to go.  And we are over the moon excited to hear
that has the potential to become a full project in its own right.
Both Dylan and I have been thrilled to see this system we've dedicated so
much to, get picked up by a beautiful and brilliant community, and we can't
wait to learn more about what this will become and how we can foster the
SCMS’ growth in the CHAOSS community.
We do, however, want to ask what this change would mean for the SCMS'
current status as a metric?
Samantha Venia Logan
Co-Founder of SociallyConstructed.Online
307-274-5516  |<EMAIL_ADDRESS>6715 Autumn Ridge Dr. Unit 2, Fort Collins CO., 80525
On Thu, Jul 30, 2020 at 4:23 PM Sean P. Goggins<EMAIL_ADDRESS>wrote:

Following discussion in the Value working group on July 30, 2020, and
review of comments we agreed to proceed with releasing an annotated version
of the metric that reflects the discussion, and itemizes candidate atomic
metrics that need to be developed. That list is possibly neither complete,
nor correct in the end. Continued development of the SCMS may occur as a
metric, or a CHAOSS project.
SCMS has great potential for providing widespread benefit to countless
open source communities, and the effort placed into its development to date
warrants recognition.
You can view, comment on, or merge this pull request online at:
https://github.com/chaoss/wg-value/pull/110
Commit Summary

Merge pull request #2 from chaoss/master
comments.
Comprehensive Goggins Comments on Social Currency.
Annotations of SCMS following working group discussion on July 30,
2020
removed single comment document shared during review period, as it
is reflected in the annotated metric and discussion of SCMS as possibly a
future CHAOSS project 'system'.

File Changes

M focus-areas/communal-value/social-currency-metric-system.md
https://github.com/chaoss/wg-value/pull/110/files#diff-4d4fd65fe6e7722d1dca5ce806b6a043
(43)

Patch Links:

https://github.com/chaoss/wg-value/pull/110.patch
https://github.com/chaoss/wg-value/pull/110.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/chaoss/wg-value/pull/110, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANBRVR6RJRFNJHBGWYKUDL3R6HXGDANCNFSM4POZJGJQ
.

The current status would not change. SCMS will be a metric in this week’s release.
I would aim to make the changes we are discussing for the next release.

Per @mbbroberg's suggestion, I removed the remaining "Atomic"

Looks good, but I would like to see the metrics for SCMS as called out in the definition changes I suggested.

Hey all,
I wanted to follow up as I did a detailed edit of the SCMS metric working document a few weeks ago and haven't heard back on it at all.  Did y'all receive that? I may have done it incorrectly so I want to make sure.

@sgoggins do you have comments on this?

Hi Venia,
Do you have a link to the document you worked in?
Once the metric lives in the repository as a markdown file, we tend to work
in the repository and I don't remember seeing any edits there.
Best,
Georg

I was working here and clicked "edit this file" which asked me to branch
off of it with a different pull request in order for me to submit my review
but it seems it's not there :/. I will do it again I guess. That explains
the crickets for the past few weeks XD
Samantha Venia Logan
Co-Founder of SociallyConstructed.Online
307-274-5516  |<EMAIL_ADDRESS>6715 Autumn Ridge Dr. Unit 2, Fort Collins CO., 80525
On Mon, Aug 24, 2020 at 8:02 AM Georg J.P. Link<EMAIL_ADDRESS>wrote:

Hi Venia,
Do you have a link to the document you worked in?
Once the metric lives in the repository as a markdown file, we tend to work
in the repository and I don't remember seeing any edits there.
Best,
Georg
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chaoss/wg-value/pull/110#issuecomment-679145154, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ANBRVR4WYDCC3XVKKLGF3KTSCJXG3ANCNFSM4POZJGJQ
.

Hi Venia,
Thanks, that explanation helps.
Are these the changes you referred to?
https://github.com/chaoss/wg-value/compare/master...samanthavenialogan:patch-1 https://github.com/chaoss/wg-value/compare/master...samanthavenialogan:patch-1
Best,
Georg

On Aug 24, 2020, at 4:10 PM, Samantha Venia Logan<EMAIL_ADDRESS>wrote:
I was working here and clicked "edit this file" which asked me to branch
off of it with a different pull request in order for me to submit my review
but it seems it's not there :/. I will do it again I guess. That explains
the crickets for the past few weeks XD
Samantha Venia Logan
Co-Founder of SociallyConstructed.Online
307-274-5516 |<EMAIL_ADDRESS>6715 Autumn Ridge Dr. Unit 2, Fort Collins CO., 80525
On Mon, Aug 24, 2020 at 8:02 AM Georg J.P. Link<EMAIL_ADDRESS>wrote:

Hi Venia,
Do you have a link to the document you worked in?
Once the metric lives in the repository as a markdown file, we tend to work
in the repository and I don't remember seeing any edits there.
Best,
Georg
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chaoss/wg-value/pull/110#issuecomment-679145154, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ANBRVR4WYDCC3XVKKLGF3KTSCJXG3ANCNFSM4POZJGJQ
.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/chaoss/wg-value/pull/110#issuecomment-679368157, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDTSRJVZWWPAP2UIJRU7QDSCLJMPANCNFSM4POZJGJQ.

--
Georg Link
(he/him)

yes actually :) it seems these are the edits I made.
Samantha Venia Logan
Co-Founder of SociallyConstructed.Online
307-274-5516  |<EMAIL_ADDRESS>6715 Autumn Ridge Dr. Unit 2, Fort Collins CO., 80525
On Mon, Aug 24, 2020 at 3:30 PM Georg J.P. Link<EMAIL_ADDRESS>wrote:

Hi Venia,
Thanks, that explanation helps.
Are these the changes you referred to?
https://github.com/chaoss/wg-value/compare/master...samanthavenialogan:patch-1
<
https://github.com/chaoss/wg-value/compare/master...samanthavenialogan:patch-1

Best,
Georg

On Aug 24, 2020, at 4:10 PM, Samantha Venia Logan <
<EMAIL_ADDRESS>wrote:
I was working here and clicked "edit this file" which asked me to branch
off of it with a different pull request in order for me to submit my
review
but it seems it's not there :/. I will do it again I guess. That explains
the crickets for the past few weeks XD
Samantha Venia Logan
Co-Founder of SociallyConstructed.Online
307-274-5516 |<EMAIL_ADDRESS>6715 Autumn Ridge Dr. Unit 2, Fort Collins CO., 80525
On Mon, Aug 24, 2020 at 8:02 AM Georg J.P. Link <
<EMAIL_ADDRESS>wrote:

Hi Venia,
Do you have a link to the document you worked in?
Once the metric lives in the repository as a markdown file, we tend to
work
in the repository and I don't remember seeing any edits there.
Best,
Georg
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chaoss/wg-value/pull/110#issuecomment-679145154,
or
unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ANBRVR4WYDCC3XVKKLGF3KTSCJXG3ANCNFSM4POZJGJQ

.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <
https://github.com/chaoss/wg-value/pull/110#issuecomment-679368157>, or
unsubscribe <
https://github.com/notifications/unsubscribe-auth/ACDTSRJVZWWPAP2UIJRU7QDSCLJMPANCNFSM4POZJGJQ
.

--
Georg Link
(he/him)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chaoss/wg-value/pull/110#issuecomment-679376909, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ANBRVRYCPSLE5NFYKGRBVHLSCLLZHANCNFSM4POZJGJQ
.


⚠ GitHub has degraded performance

In e147e27, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 149 ms

Resolved: GitHub performance has improved in 4086e16.


shell: backend: uart: Fix POSIX name conflict

If CONFIG_POSIX_API is enabled, the read() and write() function names will conflict.

Not enough reviewers, please take a look. Would be nice to get this to 3.7.


Error "struct.error: i format requires -xxx <= number <= xxx" solved by split FASTQ, but how to combine results?

Got the following error while trying to run an ADT (protein) library with ~170 million reads:
struct.error: 'i' format requires -2147483648 <= number <=<PHONE_NUMBER>
Per issue 75 (https://github.com/Hoohm/CITE-seq-Count/issues/75), I assumed that the error was due to having too many reads in the library. This made sense since my other library that had only ~100 million reads ran fine.
I split the library into two sets of ~85 million reads using Unix split, and each set ran fine after that.
My question is, how should I combine the results of CITE-Seq-Count run on each half of the FASTQs? I was just going to sum them, but I realize that this could result in overestimating UMI counts. If a given cell barcode has the same UMI counted once each in the first half of the FASTQs and the second half, summing would result in double counting.
So maybe it would make more sense to randomly downsample the FASTQ down to ~100 million, and just run the downsample through CITE-Seq-Count?
Obviously the ideal thing wold be to just run everything at once, but not sure how simple a fix it would be to get it running without subsetting the reads. If it helps, we have access to a cluster with a good amount of memory if needed.

Hello @heathergeiger
This might be a bigger issue depending on where the error pops up. Could you paste the whole error in here?
You are right, you will see an overinflation of the umi counts, so that is not the best solution.
Now that CSC allows for multiple lanes, ie, running multiple subset of one library together, maybe you can split it even further in 4 ?
I'm afraid of memory issues though.
First paste the whole error here and I will check if I can change part of the code to help.

Process ForkPoolWorker-1:
Traceback (most recent call last):
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/pool.py", line 127, in worker
put((job, i, result))
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/queues.py", line 367, in put
self._writer.send_bytes(obj)
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/connection.py", line 203, in send_bytes
self._send_bytes(m[offset:offset + size])
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/connection.py", line 396, in _send_bytes
header = struct.pack("!i", n)
struct.error: 'i' format requires -2147483648 <= number <=<PHONE_NUMBER>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/process.py", line 297, in _bootstrap
self.run()
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/pool.py", line 132, in worker
put((job, i, (False, wrapped)))
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/queues.py", line 367, in put
self._writer.send_bytes(obj)
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/connection.py", line 203, in send_bytes
self._send_bytes(m[offset:offset + size])
File "/nfs/sw/citeseqcount/citeseqcount-1.4.2-dev2/python/lib/python3.7/site-packages/multiprocess-0.70.7-py3.7-linux-x86_64.egg/multiprocess/connection.py", line 396, in _send_bytes
header = struct.pack("!i", n)
struct.error: 'i' format requires -2147483648 <= number <=<PHONE_NUMBER>
These errors are repeated for ForkPoolWorker-2, ForkPoolWorker-3, and ForkPoolWorker-4 (since I ran CITE-Seq-Count with -T 4).

For the record I was able to run successfully on a random downsample down to ~110 million reads from the 171 million.
I'm also going to try running now on the full set of reads, simply increasing the number of cores from 4 to 8 so that each core only has to handle <22M reads instead of over 42M.

Edit: 8 cores worked great!

So seems like the problem comes when you try to run too many reads all on the same node?

Yes, there might be a way to calculate this and propose a good number of cores to users

Realize I forgot to close this issue before. Sorry about that.


Fix slither CI errors - II

This workflow https://github.com/ubiquity/ubiquity-dollar/blob/6e891801df973a6613b43c899381cdd244ad3fdb/.github/workflows/slither-analysis.yml produces some errors
You can find the failed CI run here: https://github.com/ubiquity/ubiquity-dollar/actions/runs/4065041113/jobs/6999216155
What should be done:

update contracts to fix slither errors and make CI action pass

We already have this one by the way so looks like its not complete?
https://github.com/ubiquity/ubiquity-dollar/pull/302

We already have this one by the way so looks like its not complete? #302
Maybe cleaner to just move on and consider this issue part 2.

I guess some errors were fixed by https://github.com/ubiquity/ubiquity-dollar/pull/302, but there are still slither errors, so you can keep the current issued open

A lot of these were already fixed in my previous PR but reintroduced at some point. A current run passes without error but investigating the files shows plenty of //slither-disable-next-line comments.
Slither is a useful tool but a more thorough investigation of which flags actually present a problem may be necessary. Pretty much all of the reentrancy flags are for external calls to our own contracts. To compromise those they'd need to be changed by the admin address and if that's compromised it won't matter anyways.

reentrancy flags are for external calls to our own contracts

I'm surprised that Slither doesn't have a config to accomodate for this. We certainly are not the only protocol with external calls to our own contracts, right?

No, and it's not that there's external calls at all, it's that we're not following Checks Effects Interactions pattern which creates the opportunity for reentrant calls.
------- Original Message -------
On Tuesday, February 14th, 2023 at 6:34 PM, アレクサンダー.eth @.***> wrote:

reentrancy flags are for external calls to our own contracts

I'm surprised that Slither doesn't have a config to accomodate for this. We certainly are not the only protocol with external calls to our own contracts, right?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

I would be interested to work on this.To be precise all the errors do not include the compilation warnings, but only errors from line 296 to 352 on the slither test? also the url workflow is unavailable https://github.com/ubiquity/ubiquity-dollar/blob/development/.github/workflows/slither.yml Let me know if you keep on with this bounty, and how urgent it is, i'm not sure to be able to finish in one day.

Sorry I refactored and renamed the CI files to decrease ambiguity. I updated the url to a permalink of the latest CI file. https://github.com/ubiquity/ubiquity-dollar/blob/6e891801df973a6613b43c899381cdd244ad3fdb/.github/workflows/slither-analysis.yml
@rndquu @zgorizzo69 I was thinking that since we are still doing some major changes to the diamond, we should exclude it from this Slither bounty. Please let me know here if you have other thoughts.

i'm not sure to be able to finish in one day.

Hard for me to say how long it should take but as long as you continue to work on it and nobody else is bidding on it, it should be okay if it takes you several days.

Are we planning on redeploying these contracts before deploying the diamond? If not then we should take some time to identify which contracts won’t be within the diamond, and only those need to have their slither flags addressed
On Wed, Feb 15, 2023 at 3:04 PM, アレクサンダー.eth @.***> wrote:

I would be interested to work on this.To be precise all the errors do not include the compilation warnings, but only errors from line 296 to 352 on the slither test? also the url workflow is unavailable https://github.com/ubiquity/ubiquity-dollar/blob/development/.github/workflows/slither.yml Let me know if you keep on with this bounty, and how urgent it is, i'm not sure to be able to finish in one day.

Sorry I refactored and renamed the CI files to decrease ambiguity. I updated the url to a permalink of the latest CI file. https://github.com/ubiquity/ubiquity-dollar/blob/6e891801df973a6613b43c899381cdd244ad3fdb/.github/workflows/slither-analysis.yml
@.(https://github.com/rndquu) @.(https://github.com/zgorizzo69) I was thinking that since we are still doing some major changes to the diamond, we should exclude it from this Slither bounty. Please let me know here if you have other thoughts.

i'm not sure to be able to finish in one day.

Hard for me to say how long it should take but as long as you continue to work on it and nobody else is bidding on it, it should be okay if it takes you several days.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

No deployments scheduled yet. Ideally looking to deploy when things are in a good spot from a security (and upgradability) perspective, as well as when market is in a clear uptrend.

I would be interested to work on this.To be precise all the errors do not include the compilation warnings, but only errors from line 296 to 352 on the slither test? also the url workflow is unavailable https://github.com/ubiquity/ubiquity-dollar/blob/development/.github/workflows/slither.yml Let me know if you keep on with this bounty, and how urgent it is, i'm not sure to be able to finish in one day.

Sorry I refactored and renamed the CI files to decrease ambiguity. I updated the url to a permalink of the latest CI file. https://github.com/ubiquity/ubiquity-dollar/blob/6e891801df973a6613b43c899381cdd244ad3fdb/.github/workflows/slither-analysis.yml
@rndquu @zgorizzo69 I was thinking that since we are still doing some major changes to the diamond, we should exclude it from this Slither bounty. Please let me know here if you have other thoughts.

i'm not sure to be able to finish in one day.

Hard for me to say how long it should take but as long as you continue to work on it and nobody else is bidding on it, it should be okay if it takes you several days.

I would put a "blocked" label on this issue for now until we have a stable contracts/diamond/UI

I would put a "blocked" label on this issue for now until we have a stable contracts/diamond/UI

I was wondering earlier today if its better to simply unassign @ubiquity-bounties vs using a BLOCKED label

@pavlovcik  So this task won't be available until you will be able to discern which errors need to be addressed and which need to be ignored, if i understood correctly? Fine, i'll try to keep track of the future updates.

@pavlovcik So this task won't be available until you will be able to discern which errors need to be addressed and which need to be ignored, if i understood correctly? Fine, i'll try to keep track of the future updates.

Just exclude anything Diamond related.

@hashedMae @zgorizzo69 can we just exclude diamond and @zorglob21 could start? Please provide your inputs here! Thanks.

Hello, is this bounty open for anybody?

Hello, is this bounty open for anybody?

Hi! Yes, I think we can remove the "blocked" label. It's up to @pavlovcik to decide.

@rndquu hello so um faild CI run giving "The logs for this run have expired and are no longer available."

/assign @AnakinSkywalkeer

/wallet

/assign

/wallet 0x2bBc6a8314044d70684C74CfA0E117eb75E3708c

@rndquu hello so um faild CI run giving "The logs for this run have expired and are no longer available."

you can run slither locally and get the same output as in the expired logs

@rndquu hello so um faild CI run giving "The logs for this run have expired and are no longer available."

you can run slither locally and get the same output as in the expired logs

oh okay sure thanks for the reply

@rndquu hello so um faild CI run giving "The logs for this run have expired and are no longer available."

you can run slither locally and get the same output as in the expired logs

oh okay sure thanks for the reply

Notice that this issue might be bigger than we expect. So if there are too many errors and >1 day required to fix all of the errors then we can break up this issue into smaller tasks.

@rndquu hello so um faild CI run giving "The logs for this run have expired and are no longer available."

you can run slither locally and get the same output as in the expired logs

oh okay sure thanks for the reply

Notice that this issue might be bigger than we expect. So if there are too many errors and >1 day required to fix all of the errors then we can break up this issue into smaller tasks.

oh i see also btw "yarn workspace @ubiquity/contracts run test:slither" giving slither command not found even when i did install it using pip3 whats up with that?

@rndquu hello so um faild CI run giving "The logs for this run have expired and are no longer available."

you can run slither locally and get the same output as in the expired logs

oh okay sure thanks for the reply

Notice that this issue might be bigger than we expect. So if there are too many errors and >1 day required to fix all of the errors then we can break up this issue into smaller tasks.

oh i see also btw "yarn workspace @ubiquity/contracts run test:slither" giving slither command not found even when i did install it using pip3 whats up with that?

I guess slither should be added to your PATH env variable

its working i see there are many Detectors am i supposed to resolve them?

working on that

one of them got resolved btw there is _holderBalances and __totalSupply which is in the ERC1155Ubiquity also these are private but these are again defined in src/dollar/core/StakingShare.sol causing start variable shadowing error what should i do make them public in ERC1155Ubiquity or i should ignore this warning? @rndquu

could you post a full slither report here?

one of them got resolved btw there is _holderBalances and __totalSupply which is in the ERC1155Ubiquity also these are private but these are again defined in src/dollar/core/StakingShare.sol causing start variable shadowing error what should i do make them public in ERC1155Ubiquity or i should ignore this warning? @rndquu

could you post a full slither report here?

sure
also what should i do about the errors about dead code?

INFO:Detectors:
StakingShare._holderBalances (src/dollar/core/StakingShare.sol#28) shadows:
- ERC1155Ubiquity._holderBalances (src/dollar/core/ERC1155Ubiquity.sol#23)
StakingShare._totalSupply (src/dollar/core/StakingShare.sol#31) shadows:
- ERC1155Ubiquity._totalSupply (src/dollar/core/ERC1155Ubiquity.sol#24)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing
here is the error about that state variable shadowing

some of them are about dead code
INFO:Detectors:
CollectableDust._addProtocolToken(address) (src/dollar/utils/CollectableDust.sol#22-29) is never used and should be removed
CollectableDust._removeProtocolToken(address) (src/dollar/utils/CollectableDust.sol#31-38) is never used and should be removed
CollectableDust._sendDust(address,address,uint256) (src/dollar/utils/CollectableDust.sol#40-57) is never used and should be removed
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#dead-code

@rndquu can u take a look and tell what should i do about these
thanks

@rndquu hello so um faild CI run giving "The logs for this run have expired and are no longer available."

you can run slither locally and get the same output as in the expired logs

oh okay sure thanks for the reply

Notice that this issue might be bigger than we expect. So if there are too many errors and >1 day required to fix all of the errors then we can break up this issue into smaller tasks.

Also it can be done in 1 day even else then that no need to break it up seems like

@rndquu
INFO:Detectors:
StakingShare._holderBalances (src/dollar/core/StakingShare.sol#28) shadows:
- ERC1155Ubiquity._holderBalances (src/dollar/core/ERC1155Ubiquity.sol#23)
StakingShare._totalSupply (src/dollar/core/StakingShare.sol#31) shadows:
- ERC1155Ubiquity._totalSupply (src/dollar/core/ERC1155Ubiquity.sol#24)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing
INFO:Detectors:
CollectableDust._addProtocolToken(address) (src/dollar/utils/CollectableDust.sol#22-29) is never used and should be removed
CollectableDust._removeProtocolToken(address) (src/dollar/utils/CollectableDust.sol#31-38) is never used and should be removed
CollectableDust._sendDust(address,address,uint256) (src/dollar/utils/CollectableDust.sol#40-57) is never used and should be removed
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#dead-code
INFO:Detectors:
Pragma version0.8.19 (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (scripts/deploy/dollar/solidityScripting/01_Diamond.s.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (scripts/deploy/dollar/solidityScripting/02_UbiquityDollarToken.s.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (scripts/deploy/dollar/solidityScripting/03_UbiquityGovernanceToken.s.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (scripts/deploy/dollar/solidityScripting/04_UbiquityCredit.s.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/Diamond.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/DirectGovernanceFarmer.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/access/AccessControlInternal.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/core/CreditClock.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/core/CreditNft.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/core/ERC1155Ubiquity.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/core/ERC20Ubiquity.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/core/StakingShare.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/core/UbiquityCreditToken.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/core/UbiquityDollarToken.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/core/UbiquityGovernanceToken.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/AccessControlFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.16 (src/dollar/facets/BondingCurveFacet.sol#2) allows old versions
Pragma version^0.8.19 (src/dollar/facets/ChefFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/CollectableDustFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/CreditNftManagerFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/CreditNftRedemptionCalculatorFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/CreditRedemptionCalculatorFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/CurveDollarIncentiveFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/facets/DiamondCutFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/facets/DiamondLoupeFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/DollarMintCalculatorFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/DollarMintExcessFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/facets/ManagerFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/facets/OwnershipFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/StakingFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/StakingFormulasFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/facets/TWAPOracleDollar3poolFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.Pragma version^0.8.19 (src/dollar/facets/UbiquityPoolFacet.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IAccessControl.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.3 (src/dollar/interfaces/IBancorFormula.sol#2) allows old versions
Pragma version^0.8.16 (src/dollar/interfaces/IBondingCurve.sol#2) allows old versions
Pragma version0.8.19 (src/dollar/interfaces/ICreditNft.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ICreditNftManager.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ICreditNftRedemptionCalculator.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ICreditRedemptionCalculator.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ICurveFactory.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IDepositZap.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IDiamondCut.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IDiamondLoupe.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IDollarMintCalculator.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IDollarMintExcess.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IERC1155Ubiquity.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IERC173.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IERC20Ubiquity.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IIncentive.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IJar.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IMasterChef.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IMetaPool.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IPickleController.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ISablier.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IStableSwap3Pool.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IStaking.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version^0.8.19 (src/dollar/interfaces/IStakingShare.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ISushiBar.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ISushiMaker.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ISushiMasterChef.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ISushiSwapPool.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/ITWAPOracleDollar3pool.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IUbiquityChef.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IUbiquityDollarManager.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IUbiquityDollarToken.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IUbiquityFormulas.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/IUbiquityGovernance.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version>=0.8.19 (src/dollar/interfaces/IUbiquityPool.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/interfaces/utils/ICollectableDust.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/upgradeInitializers/DiamondInit.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/utils/CollectableDust.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (src/dollar/utils/SafeAddArray.sol#3) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
Pragma version0.8.19 (scripts/task/dollar/MigrateMetapool.s.sol#2) necessitates a version too recent to be trusted. Consider deploying with 0.8.18.
solc-0.8.19 is not recommended for deployment
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-versions-of-solidity
INFO:Detectors:
StakingFormulasFacet (src/dollar/facets/StakingFormulasFacet.sol#7-96) should inherit from IUbiquityFormulas (src/dollar/interfaces/IUbiquityFormulas.sol#6-36)
UbiquityPoolFacet (src/dollar/facets/UbiquityPoolFacet.sol#12-105) should inherit from IUbiquityPool (src/dollar/interfaces/IUbiquityPool.sol#6-48)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#missing-inheritance
INFO:Detectors:
DollarScript.run() (scripts/deploy/dollar/solidityScripting/02_UbiquityDollarToken.s.sol#11-41) uses literals with too many digits:
- IManager.deployStableSwapPool(curveFactory,basePool,curve3PoolToken,10,5000000) (scripts/deploy/dollar/solidityScripting/02_UbiquityDollarToken.s.sol#30-36)
StakingShareScript.slitherConstructorVariables() (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#6-24) uses literals with too many digits:
- lpAmounts =<PHONE_NUMBER>000000000,3500000000000000000000,9351040526163838324896,44739174270101943975392,74603879373206500005186,2483850000000000000000,1878674425540571814543,8991650309086743220575,1111050988607803612915,4459109737462155546375,21723000000000000000000,38555895255762442000000,5919236274824521937931,1569191092350025897388,10201450658519659933880,890339946944155414434,5021119790948940093253,761000000000000000000,49172294677407855270013,25055256356185888278372,1576757078627228869179,3664000000000000000000,1902189597146391302863,34959771702943278635904,9380006436252701023610,6266995559166564365470,100000000000000000000,3696476262155265118082,740480000000000000000,2266000000000000000000,1480607760433248019987,24702171480214199310951,605000000000000000000,1694766661387270251234,14857000000000000000000,26000000000000000000) (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#57-94)
DiamondInit.init(DiamondInit.Args) (src/dollar/upgradeInitializers/DiamondInit.sol#36-100) uses literals with too many digits:
- poolStore.dollarFloor =<PHONE_NUMBER>000000000 (src/dollar/upgradeInitializers/DiamondInit.sol#99)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#too-many-digits
INFO:Detectors:
CollectableDust (src/dollar/utils/CollectableDust.sol#11-58) does not implement functions:
- ICollectableDust.addProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#9)
- ICollectableDust.removeProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#11)
- ICollectableDust.sendDust(address,address,uint256) (src/dollar/interfaces/utils/ICollectableDust.sol#13)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unimplemented-functions
INFO:Detectors:
Constants.shareAmounts (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#8) is never used in StakingShareScript (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#6-24)
Constants.ids (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#9) is never used in StakingShareScript (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#6-24)
Constants.uri (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#11) is never used in StakingShareScript (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#6-24)
DiamondScript.IDollar (scripts/deploy/dollar/solidityScripting/01_Diamond.s.sol#76) is never used in StakingShareScript (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#6-24)
DiamondScript.incentive_addr (scripts/deploy/dollar/solidityScripting/01_Diamond.s.sol#78) is never used in StakingShareScript (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#6-24)
DiamondScript.facetAddressList (scripts/deploy/dollar/solidityScripting/01_Diamond.s.sol#80) is never used in StakingShareScript (scripts/deploy/dollar/solidityScripting/05_StakingShare.s.sol#6-24)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unused-state-variable
INFO:Detectors:
Constants.admin (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#16) should be constant
Constants.deployerPrivateKey (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#15) should be constant
Constants.uri (scripts/deploy/dollar/solidityScripting/00_Constants.s.sol#11) should be constant
DiamondScript.IDollar (scripts/deploy/dollar/solidityScripting/01_Diamond.s.sol#76) should be constant
DiamondScript.incentive_addr (scripts/deploy/dollar/solidityScripting/01_Diamond.s.sol#78) should be constant
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#state-variables-that-could-be-declared-constant
INFO:Slither:. analyzed (226 contracts with 65 detectors), 99 result(s) found

most of them about dead code and unused variables can i remove those or lets just ignore these?

also the first error about state variable shadowing those variables are private we are needing to create new ones that again producing error what to do about it

@AnakinSkywalkeer simply put this workflow should pass (right now it returns errors)
you are free to refactor code as you see fit

most of them about dead code and unused variables can i remove those or lets just ignore these?

If removing those makes the CI build pass then we should remove those unused variables along with dead code

also the first error about state variable shadowing those variables are private we are needing to create new ones that again producing error what to do about it

I'm sure there is a way to refactor, perhaps we should simply remove the top most variable in the inheritance tree
P.S. there are way less errors than I'd expected

@AnakinSkywalkeer simply put this workflow should pass (right now it returns errors)
you are free to refactor code as you see fit

most of them about dead code and unused variables can i remove those or lets just ignore these?

If removing those makes the CI build pass then we should remove those unused variables along with dead code

also the first error about state variable shadowing those variables are private we are needing to create new ones that again producing error what to do about it

I'm sure there is a way to refactor, perhaps we should simply remove the top most variable in the inheritance tree
P.S. there are way less errors than I'd expected

oh sure

@rndquu there is like damn big list of errors about using Pragma version0.8.19  they say its too new to be trusted and suggest 8.18? should i do it? its not gonna break anything right?

i tried putting 0.8.18 but leading to more errors

hm should we just go with 0.8.19 ?

also um there is like one file with unimplemented functions because of that its throwing error what should i do about this hm
CollectableDust (src/dollar/utils/CollectableDust.sol#11-58) does not implement functions:
- ICollectableDust.addProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#9)
- ICollectableDust.removeProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#11)
- ICollectableDust.sendDust(address,address,uint256) (src/dollar/interfaces/utils/ICollectableDust.sol#13)

ohhh sure

@rndquu there is like damn big list of errors about using Pragma version0.8.19 they say its too new to be trusted and suggest 8.18? should i do it? its not gonna break anything right?

As far as I understand this error is thrown by the solc-version slither detector. This detector's severity is information + by the time we would have deployed to production the 0.8.19 should be the default one so I think it's ok to exclude this detector in slither config.

also um there is like one file with unimplemented functions because of that its throwing error what should i do about this hm
CollectableDust (src/dollar/utils/CollectableDust.sol#11-58) does not implement functions:

ICollectableDust.addProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#9)
ICollectableDust.removeProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#11)
ICollectableDust.sendDust(address,address,uint256) (src/dollar/interfaces/utils/ICollectableDust.sol#13)

Try to remove src/dollar/utils/CollectableDust.sol and run the tests, nothing should be broken. As far as I understand we don't use src/dollar/utils/CollectableDust.sol anymore because we moved to https://github.com/ubiquity/ubiquity-dollar/blob/development/packages/contracts/src/dollar/facets/CollectableDustFacet.sol

@rndquu there is like damn big list of errors about using Pragma version0.8.19 they say its too new to be trusted and suggest 8.18? should i do it? its not gonna break anything right?

As far as I understand this error is thrown by the solc-version slither detector. This detector's severity is information + by the time we would have deployed to production the 0.8.19 should be the default one so I think it's ok to exclude this detector in slither config.

also um there is like one file with unimplemented functions because of that its throwing error what should i do about this hm
CollectableDust (src/dollar/utils/CollectableDust.sol#11-58) does not implement functions:

ICollectableDust.addProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#9)
ICollectableDust.removeProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#11)
ICollectableDust.sendDust(address,address,uint256) (src/dollar/interfaces/utils/ICollectableDust.sol#13)

Try to remove src/dollar/utils/CollectableDust.sol and run the tests, nothing should be broken. As far as I understand we don't use src/dollar/utils/CollectableDust.sol anymore because we moved to https://github.com/ubiquity/ubiquity-dollar/blob/development/packages/contracts/src/dollar/facets/CollectableDustFacet.sol

removing the collectable dustfile made the error go away cool

@rndquu there is like damn big list of errors about using Pragma version0.8.19 they say its too new to be trusted and suggest 8.18? should i do it? its not gonna break anything right?

As far as I understand this error is thrown by the solc-version slither detector. This detector's severity is information + by the time we would have deployed to production the 0.8.19 should be the default one so I think it's ok to exclude this detector in slither config.

also um there is like one file with unimplemented functions because of that its throwing error what should i do about this hm
CollectableDust (src/dollar/utils/CollectableDust.sol#11-58) does not implement functions:

ICollectableDust.addProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#9)
ICollectableDust.removeProtocolToken(address) (src/dollar/interfaces/utils/ICollectableDust.sol#11)
ICollectableDust.sendDust(address,address,uint256) (src/dollar/interfaces/utils/ICollectableDust.sol#13)

Try to remove src/dollar/utils/CollectableDust.sol and run the tests, nothing should be broken. As far as I understand we don't use src/dollar/utils/CollectableDust.sol anymore because we moved to https://github.com/ubiquity/ubiquity-dollar/blob/development/packages/contracts/src/dollar/facets/CollectableDustFacet.sol

removing the collectable dustfile made the error go away cool

@rndquu seems like we can't really remove the _holderbalances and _totalSupply its gettting used in the contract hmm
StakingShare._holderBalances (src/dollar/core/StakingShare.sol#28) shadows:
- ERC1155Ubiquity._holderBalances (src/dollar/core/ERC1155Ubiquity.sol#23)
StakingShare._totalSupply (src/dollar/core/StakingShare.sol#31) shadows:
- ERC1155Ubiquity._totalSupply (src/dollar/core/ERC1155Ubiquity.sol#24)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing

@rndquu hm well if it that state variables are supposed to be different for different contracts may be we can ignore this error or do u have any other idea?

should we try like internal visibility modifier, combined with inheritance
example ;-
contract ContractA {
uint private myVariable;
function getMyVariable() internal view returns (uint) {
    return myVariable;
}

}
contract ContractB is ContractA {
function accessMyVariable() public view returns (uint) {
return getMyVariable(); // Access the private variable from ContractA
}
}

so i made like these function to access the totalSupply then used them instead of making a new private state variables they work hm should we with them then? or not
        return _totalSupply;
    }
    function incrementTotalSupply() internal {
        _totalSupply += 1;
    }
    function dcremenetTotalSupply() internal {
        _totalSupply -= 1;
    }

If this seems okay may be i should try commit now there is not really any errros now

If this seems okay may be i should try commit now there is not really any errors now

If there are no any errors then pls create a PR

so i made like these function to access the state variables then used them instead of making a new private state variables they work hm should we with them then? or not

Hard to say, need to see the code in the PR

sure

⧗   input: resolve the slither errors
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]
✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
umm why that slither errors ughh i did put the
"detectors_to_exclude": "naming-conventions,different-pragma-directives-are-used,external-function,assembly,incorrect-equality,incorrect-versions-of-solidity,unused-return",
to avoid the version errors hm

This whole conversation should have been on your pull request because it clutters the discussion around the specification with your work's problems @AnakinSkywalkeer @rndquu


Read a Customer

As a customer service representative
I need to be able to read a customer's information
So that I can view the customer's details for support and verification purposes.
Details and assumptions:
-We will store customer details in a PostgreSQL database.
-Each customer has a unique customer_id, first name, last name, email, and at least one address (can be a long string).
-The customer information is retrieved based on their customer_id.
Acceptance criteria:
If a customer exists in the database
If I request to read the customer's information using the customer_id
Then I should get the first name, last name, email and address details for that customer.


Blog. Beginning...

Ok, looks like you need to merge from master, I don't see any of your commits (unless you're a PM, then we're good to merge)


Write a Dart program to find the largest three elements in an array

Description
Write a Dart program to find the largest three elements in an array
Input  : arr[] = {10, 4, 3, 50, 23, 90}
Output : 90, 50, 23

Input  : arr[] = {10, 4, 3, 50, 23, 90, 1, 100, 49}
Output : 100, 90, 50

How to contribute

Comment !assign to assign this issue to yourself
Fork this repository
Create a new branch
Save the solution in program/program/find-the-largest-three-elements-in-an-array/find_the_largest_three_elements_in_an_array.dart
Commit the changes
Create a pull request

!assign


Some songs refuse to download. (403)

I have no idea why this happens, but the problem seems to be getting worse.
for example, could not download this song both locally and on the server:
https://www.youtube.com/watch?v=nMwLbAZMdV4

Update, it's a 403 error on presumably copyrighted songs for which youtube prohibits external streaming.
Will try to find workaround

Ooh, that's a really nice catch. It would be cool to find a workaround, but at least we know what the issue is.

stopped happening, actually probably a trash issue with the IS&T blocking youtube stuff that we can't really control


Scenarios are not running: GrpcPingPongStreaming-1MB-GrpcCore, GrpcPingPongStreaming-1MB-GrpcNetClient, GrpcPingPongStreaming-1MB-GrpcNetClient, GrpcPingPongStreaming-1MB-GrpcNetClient, GrpcPingPongStreaming-GrpcCore ...


VM randomly looses network

Using lima on a mac m1 to run ubuntu I experience a random loss of networking. Ssh shell (lima shell) stops reacting and new connection cannot be initiated.
Connecting minicom to serial port I see that the VM is alive and well - but cannot connect to any outside network.
This can be fixed by restarting, but it's obviously a huge nuisance.
It works fine usually for a few hours/days. But sometimes it breaks after as little as few minutes making lima unusable.
I can't see anything useful in logs...

Internet6:
Destination                             Gateway                         Flags           Netif Expire
default                                 fe80::1%en0                     UGcIg             en0
default                                 fe80::%utun0                    UGcIg           utun0
default                                 fe80::%utun1                    UGcIg           utun1
default                                 fe80::%utun2                    UGcIg           utun2
default                                 fe80::%utun3                    UGcIg           utun3
default                                 fe80::%utun4                    UGcIg           utun4
default                                 fe80::1%en8                     UGcIg             en8
::1                                     ::1                             UHL               lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI               lo0
fe80::1%lo0                             link#1                          UHLI              lo0
fe80::%anpi1/64                         link#4                          UCI             anpi1
fe80::b434:14ff:fe6c:2239%anpi1         b6:34:14:6c:22:39               UHLI              lo0
fe80::%anpi0/64                         link#5                          UCI             anpi0
fe80::b434:14ff:fe6c:2238%anpi0         b6:34:14:6c:22:38               UHLI              lo0
fe80::%en0/64                           link#11                         UCI               en0
fe80::1%en0                             18:de:d7:72:da:e0               UHLWIr            en0
fe80::6f:be67:640b:5efc%en0             18:3e:ef:d5:66:83               UHLI              lo0
fe80::225:36ff:fe61:a089%en0            0:25:36:61:a0:89                UHLWI             en0
fe80::87e:64b7:ecd0:f3f5%en0            32:94:99:d9:65:1e               UHLWIi            en0
fe80::%awdl0/64                         link#12                         UCI             awdl0
fe80::cbd:42ff:fea7:6b6d%awdl0          e:bd:42:a7:6b:6d                UHLI              lo0
fe80::%llw0/64                          link#13                         UCI              llw0
fe80::cbd:42ff:fea7:6b6d%llw0           e:bd:42:a7:6b:6d                UHLI              lo0
fe80::%utun0/64                         fe80::f4b4:2ecd:14f9:dd98%utun0 UcI             utun0
fe80::f4b4:2ecd:14f9:dd98%utun0         link#15                         UHLI              lo0
fe80::%utun1/64                         fe80::56c:5d1e:5198:63d7%utun1  UcI             utun1
fe80::56c:5d1e:5198:63d7%utun1          link#16                         UHLI              lo0
fe80::%utun2/64                         fe80::ce81:b1c:bd2c:69e%utun2   UcI             utun2
fe80::ce81:b1c:bd2c:69e%utun2           link#17                         UHLI              lo0
fe80::%utun3/64                         fe80::4ce6:1cc6:a0fe:d5f6%utun3 UcI             utun3
fe80::4ce6:1cc6:a0fe:d5f6%utun3         link#18                         UHLI              lo0
fe80::%utun4/64                         fe80::5b54:2c4d:2a19:9faa%utun4 UcI             utun4
fe80::5b54:2c4d:2a19:9faa%utun4         link#19                         UHLI              lo0
fe80::%en8/64                           link#20                         UCI               en8
fe80::1%en8                             18:de:d7:72:da:e0               UHLWIr            en8
fe80::6e:f638:e37a:5e00%en8             f0:18:98:43:48:7a               UHLWI             en8
fe80::225:36ff:fe61:a089%en8            0:25:36:61:a0:89                UHLWI             en8
fe80::87e:64b7:ecd0:f3f5%en8            32:94:99:d9:65:1e               UHLWI             en8
fe80::c76:6c2:9bfe:dddd%en8             34:99:71:d5:1c:61               UHLI              lo0
ff00::/8                                ::1                             UmCI              lo0
ff00::/8                                link#4                          UmCI            anpi1
ff00::/8                                link#5                          UmCI            anpi0
ff00::/8                                link#11                         UmCI              en0
ff00::/8                                link#12                         UmCI            awdl0
ff00::/8                                link#13                         UmCI             llw0
ff00::/8                                fe80::f4b4:2ecd:14f9:dd98%utun0 UmCI            utun0
ff00::/8                                fe80::56c:5d1e:5198:63d7%utun1  UmCI            utun1
ff00::/8                                fe80::ce81:b1c:bd2c:69e%utun2   UmCI            utun2
ff00::/8                                fe80::4ce6:1cc6:a0fe:d5f6%utun3 UmCI            utun3
ff00::/8                                fe80::5b54:2c4d:2a19:9faa%utun4 UmCI            utun4
ff00::/8                                link#20                         UmCI              en8
ff01::%lo0/32                           ::1                             UmCI              lo0
ff01::%anpi1/32                         link#4                          UmCI            anpi1
ff01::%anpi0/32                         link#5                          UmCI            anpi0
ff01::%en0/32                           link#11                         UmCI              en0
ff01::%awdl0/32                         link#12                         UmCI            awdl0
ff01::%llw0/32                          link#13                         UmCI             llw0
ff01::%utun0/32                         fe80::f4b4:2ecd:14f9:dd98%utun0 UmCI            utun0
ff01::%utun1/32                         fe80::56c:5d1e:5198:63d7%utun1  UmCI            utun1
ff01::%utun2/32                         fe80::ce81:b1c:bd2c:69e%utun2   UmCI            utun2
ff01::%utun3/32                         fe80::4ce6:1cc6:a0fe:d5f6%utun3 UmCI            utun3
ff01::%utun4/32                         fe80::5b54:2c4d:2a19:9faa%utun4 UmCI            utun4
ff01::%en8/32                           link#20                         UmCI              en8
ff02::%lo0/32                           ::1                             UmCI              lo0
ff02::%anpi1/32                         link#4                          UmCI            anpi1
ff02::%anpi0/32                         link#5                          UmCI            anpi0
ff02::%en0/32                           link#11                         UmCI              en0
ff02::%awdl0/32                         link#12                         UmCI            awdl0
ff02::%llw0/32                          link#13                         UmCI             llw0
ff02::%utun0/32                         fe80::f4b4:2ecd:14f9:dd98%utun0 UmCI            utun0
ff02::%utun1/32                         fe80::56c:5d1e:5198:63d7%utun1  UmCI            utun1
ff02::%utun2/32                         fe80::ce81:b1c:bd2c:69e%utun2   UmCI            utun2
ff02::%utun3/32                         fe80::4ce6:1cc6:a0fe:d5f6%utun3 UmCI            utun3
ff02::%utun4/32                         fe80::5b54:2c4d:2a19:9faa%utun4 UmCI            utun4
ff02::%en8/32                           link#20                         UmCI              en8

Klements-MacBook-Air:default ksekera$ ifconfig | grep "inet"
	inet <IP_ADDRESS> netmask 0xff000000
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	inet6 fe80::b434:14ff:fe6c:2239%anpi1 prefixlen 64 scopeid 0x4
	inet6 fe80::b434:14ff:fe6c:2238%anpi0 prefixlen 64 scopeid 0x5
	inet6 fe80::6f:be67:640b:5efc%en0 prefixlen 64 secured scopeid 0xb
	inet <IP_ADDRESS> netmask 0xffffff00 broadcast <IP_ADDRESS>
	inet6 fe80::cbd:42ff:fea7:6b6d%awdl0 prefixlen 64 scopeid 0xc
	inet6 fe80::cbd:42ff:fea7:6b6d%llw0 prefixlen 64 scopeid 0xd
	inet6 fe80::f4b4:2ecd:14f9:dd98%utun0 prefixlen 64 scopeid 0xf
	inet6 fe80::56c:5d1e:5198:63d7%utun1 prefixlen 64 scopeid 0x10
	inet6 fe80::ce81:b1c:bd2c:69e%utun2 prefixlen 64 scopeid 0x11
	inet6 fe80::4ce6:1cc6:a0fe:d5f6%utun3 prefixlen 64 scopeid 0x12
	inet6 fe80::5b54:2c4d:2a19:9faa%utun4 prefixlen 64 scopeid 0x13
	inet6 fe80::c76:6c2:9bfe:dddd%en8 prefixlen 64 secured scopeid 0x14
	inet <IP_ADDRESS> netmask 0xffffff00 broadcast <IP_ADDRESS>

On VM I see:
ksekera@lima-default ~> ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:55:55:a9:77:b3 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global dynamic eth0
       valid_lft 69468sec preferred_lft 69468sec
    inet6 fec0::5055:55ff:fea9:77b3/64 scope site dynamic mngtmpaddr noprefixroute
       valid_lft 85525sec preferred_lft 13525sec
    inet6 fe80::5055:55ff:fea9:77b3/64 scope link
       valid_lft forever preferred_lft forever

ksekera@lima-default ~> ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:55:55:a9:77:b3 brd ff:ff:ff:ff:ff:ff

ksekera@lima-default ~> ip route show
default via <IP_ADDRESS> dev eth0 proto dhcp src <IP_ADDRESS> metric 100
<IP_ADDRESS>/24 dev eth0 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS> dev eth0 proto dhcp scope link src <IP_ADDRESS> metric 100

ksekera@lima-default ~> ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
^C
--- <IP_ADDRESS> ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms

Perhaps this is an issue of QEMU or libslirp?
https://gitlab.com/qemu-project/qemu/-/issues
https://gitlab.freedesktop.org/slirp/libslirp/-/issues

same issue here on Intel macbook.
ha.stderr.log
.. this was fine...
{"level":"info","msg":"Forwarding TCP from <IP_ADDRESS>:52285 to <IP_ADDRESS>:52285","time":"2022-01-24T15:15:56+01:00"}
{"level":"info","msg":"Forwarding TCP from <IP_ADDRESS>:7001 to <IP_ADDRESS>:7001","time":"2022-01-24T15:15:56+01:00"}
..until...
{"level":"debug","msg":"guest agent event: {Time:2022-01-26 06:21:35.140068883 +0000 UTC LocalPortsAdded:[] LocalPortsRemoved:[{IP:<IP_ADDRESS> Port:52285} {IP:<IP_ADDRESS> Port:7001}] Errors:[]}","time":"2022-01-27T12:04:32+01:00"}
{"level":"info","msg":"Stopping forwarding TCP from <IP_ADDRESS>:52285 to <IP_ADDRESS>:52285","time":"2022-01-27T12:04:32+01:00"}
{"level":"info","msg":"Stopping forwarding TCP from <IP_ADDRESS>:7001 to <IP_ADDRESS>:7001","time":"2022-01-27T12:04:32+01:00"}
{"level":"debug","msg":"guest agent event: {Time:2022-01-26 06:22:08.139752749 +0000 UTC LocalPortsAdded:[{IP:<IP_ADDRESS> Port:60043} {IP:<IP_ADDRESS> Port:7001}] LocalPortsRemoved:[] Errors:[]}","time":"2022-01-27T12:05:05+01:00"}
{"level":"info","msg":"Forwarding TCP from <IP_ADDRESS>:60043 to <IP_ADDRESS>:60043","time":"2022-01-27T12:05:05+01:00"}
{"level":"info","msg":"Forwarding TCP from <IP_ADDRESS>:7001 to <IP_ADDRESS>:7001","time":"2022-01-27T12:05:05+01:00"}
{"error":"unexpected EOF","level":"warning","msg":"connection to the guest agent was closed unexpectedly","time":"2022-01-27T13:30:22+01:00"}
{"error":"EOF","level":"debug","msg":"sftp server for /tmp/lima exited with EOF (negligible)","time":"2022-01-27T13:30:22+01:00"}
{"error":"EOF","level":"debug","msg":"sftp server for /opt/lima exited with EOF (negligible)","time":"2022-01-27T13:30:22+01:00"}
{"error":"EOF","level":"debug","msg":"sftp server for /Users/bapt exited with EOF (negligible)","time":"2022-01-27T13:30:22+01:00"}
{"level":"info","msg":"Forwarding \"/run/lima-guestagent.sock\" (guest) to \"/Users/bapt/.lima/docker/ga.sock\" (host)","time":"2022-01-27T13:30:32+01:00"}
{"error":"exit status 255","level":"warning","msg":"Failed to set up forward from \"/run/lima-guestagent.sock\" (guest) to \"/Users/bapt/.lima/docker/ga.sock\" (host)","time":"2022-01-27T13:30:32+01:00"}
{"error":null,"level":"warning","msg":"Failed to clean up \"/Users/bapt/.lima/docker/ga.sock\" (host) after forwarding failed","time":"2022-01-27T13:30:32+01:00"}
{"error":"stat /Users/bapt/.lima/docker/ga.sock: no such file or directory","level":"warning","msg":"connection to the guest agent was closed unexpectedly","time":"2022-01-27T13:30:32+01:00"}
... then shutting down the VM
{"level":"info","msg":"Received SIGINT, shutting down the host agent","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Shutting down the host agent","time":"2022-01-27T13:58:32+01:00"}
{"level":"debug","msg":"Stop forwarding unix sockets","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Stopping forwarding \"/run/docker.sock\" (guest) to \"/Users/bapt/docker.sock\" (host)","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Stopping forwarding \"/run/lima-guestagent.sock\" (guest) to \"/Users/bapt/.lima/docker/ga.sock\" (host)","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Unmounting \"/Users/bapt\"","time":"2022-01-27T13:58:32+01:00"}
{"level":"debug","msg":"killing ssh server for remote sshfs: /usr/bin/ssh [ssh -F /dev/null -o IdentityFile=\"/Users/bapt/.lima/_config/user\" -o IdentityFile=\"/Users/bapt/.ssh/id_rsa\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o Ciphers=\"^aes128-gcm<EMAIL_ADDRESS>-o User=bapt -o ControlMaster=auto -o ControlPath=\"/Users/bapt/.lima/docker/ssh.sock\" -o ControlPersist=5m -p 60006 <IP_ADDRESS> -- sshfs :/Users/bapt /Users/bapt -o slave -o ro -o allow_other]","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Unmounting \"/tmp/lima\"","time":"2022-01-27T13:58:32+01:00"}
{"level":"debug","msg":"killing ssh server for remote sshfs: /usr/bin/ssh [ssh -F /dev/null -o IdentityFile=\"/Users/bapt/.lima/_config/user\" -o IdentityFile=\"/Users/bapt/.ssh/id_rsa\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o Ciphers=\"^aes128-gcm<EMAIL_ADDRESS>-o User=bapt -o ControlMaster=auto -o ControlPath=\"/Users/bapt/.lima/docker/ssh.sock\" -o ControlPersist=5m -p 60006 <IP_ADDRESS> -- sshfs :/tmp/lima /tmp/lima -o slave -o allow_other]","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Unmounting \"/opt/lima\"","time":"2022-01-27T13:58:32+01:00"}
{"level":"debug","msg":"killing ssh server for remote sshfs: /usr/bin/ssh [ssh -F /dev/null -o IdentityFile=\"/Users/bapt/.lima/_config/user\" -o IdentityFile=\"/Users/bapt/.ssh/id_rsa\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o Ciphers=\"^aes128-gcm<EMAIL_ADDRESS>-o User=bapt -o ControlMaster=auto -o ControlPath=\"/Users/bapt/.lima/docker/ssh.sock\" -o ControlPersist=5m -p 60006 <IP_ADDRESS> -- sshfs :/opt/lima /opt/lima -o slave -o allow_other]","time":"2022-01-27T13:58:32+01:00"}
{"level":"debug","msg":"shutting down the SSH master","time":"2022-01-27T13:58:32+01:00"}
{"level":"debug","msg":"executing ssh for exiting the master: /usr/bin/ssh [ssh -F /dev/null -o IdentityFile=\"/Users/bapt/.lima/_config/user\" -o IdentityFile=\"/Users/bapt/.ssh/id_rsa\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o Ciphers=\"^aes128-gcm<EMAIL_ADDRESS>-o User=bapt -o ControlMaster=auto -o ControlPath=\"/Users/bapt/.lima/docker/ssh.sock\" -o ControlPersist=5m -O exit -p 60006 <IP_ADDRESS>]","time":"2022-01-27T13:58:32+01:00"}
{"error":"failed to execute `ssh -O exit -p 60006 <IP_ADDRESS>`, out=\"Control socket connect(/Users/bapt/.lima/docker/ssh.sock): No such file or directory\\r\\n\": exit status 255","level":"warning","msg":"failed to exit SSH master","time":"2022-01-27T13:58:32+01:00"}
{"error":"2 errors occurred:\n\t* failed to run [ssh -F /dev/null -o IdentityFile=\"/Users/bapt/.lima/_config/user\" -o IdentityFile=\"/Users/bapt/.ssh/id_rsa\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o Ciphers=\"^aes128-gcm<EMAIL_ADDRESS>-o User=bapt -o ControlMaster=auto -o ControlPath=\"/Users/bapt/.lima/docker/ssh.sock\" -o ControlPersist=5m -T -O cancel -L /Users/bapt/docker.sock:/run/docker.sock -N -f -p 60006 <IP_ADDRESS> --]: \"\": exit status 255\n\t* failed to run [ssh -F /dev/null -o IdentityFile=\"/Users/bapt/.lima/_config/user\" -o IdentityFile=\"/Users/bapt/.ssh/id_rsa\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o Ciphers=\"^aes128-gcm<EMAIL_ADDRESS>-o User=bapt -o ControlMaster=auto -o ControlPath=\"/Users/bapt/.lima/docker/ssh.sock\" -o ControlPersist=5m -T -O cancel -L /Users/bapt/.lima/docker/ga.sock:/run/lima-guestagent.sock -N -f -p 60006 <IP_ADDRESS> --]: \"\": exit status 255\n\n","level":"warning","msg":"an error during shutting down the host agent","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Shutting down QEMU with ACPI","time":"2022-01-27T13:58:32+01:00"}
{"level":"info","msg":"Sending QMP system_powerdown command","time":"2022-01-27T13:58:32+01:00"}
{"error":null,"level":"info","msg":"QEMU has exited","time":"2022-01-27T13:58:45+01:00"}

limactl version 0.8.0
Happy to share more system info as requested

just happened to me, not sure it was the same situation, but I saw that I lost the default routes on the Lima VM:
$> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>     U     0      0        0 docker0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>     U     0      0        0 br-f7f671e292e9
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 eth0
<IP_ADDRESS>   <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 lima0

so I've just added it back and it worked:
sudo ip route add default via <IP_ADDRESS> dev eth0


Problem with multiple cursors, doesn't add comments for all functions.

Description
When I create multiple cursors before 2 or more functions using Alt+Click, it doesn't put help comments before them. Instead, it creates help comment before the first function when I create a cursor and then move down in file to create another cursor. It doesn't create any help comment if I move up to create second cursor, after creating first cursor.
Example

void first(){}

void second(){}

If I press Alt+Click before void first(), then before void second() and type /** <enter> the output comes as
/**
 * @brief
 *
 */
void first(){}
/**
 *
void second(){}

If I press Alt+Click before void second(), and then before void first() and type /** <enter> the output comes as
/**
 *
void first(){}
/**
 *
void second(){}

Expected result in either case is
/**
 * @brief
 *
 */
void first(){}
/**
 * @brief
 *
 */
void second(){}

Hi @80avin ,
this is a great feature request!
I took a quick look at it and the reason for that behavior is mostly because the runtime of VS Code sends different data when there are multiple cursors instead of one.
The internal processing of VS Code with multiple cursors does first the action of updating the cursor position and the triggering the addons whereas with a single cursor it's done the other way around (the addon currently relies on the second way).
I think it should be fairly simply to have the addon check also the next line for a comment trigger sequence but it will take some time to make sure it doesn't break the functionality of a single cursor.


Fix wrong format of column in specs of MiqExpression

before column is always "-"
cc @imtayadeway
@miq-bot assign @gtanzillo

👍 LGTM


Non-Video Ads Showing Up

Is anyone seeing non-video ads that you have to skip manually?

Yea, I assume it's Youtube trying to fight a losing battle to claw extra pennies. I've gotten ones for Opera and Google Survey ones

can you add auto skip for this kind of adds
skip manually was not good!

To resolve the issue for non-video ads, modify the following line:
video.currentTime = video.duration;

Change it to:
video.currentTime = video.duration || 0;

To resolve the issue for non-video ads, modify the following line:
video.currentTime = video.duration;

Change it to:
video.currentTime = video.duration || 0;

Thank you!

solution doesnt work for me, any idea why?

solution doesnt work for me, any idea why?

Because Youtube added a number of more overlay ads that this doesn't cover or when you edited the line you forgot to click save to make it stick or both


MLFlow dataset with modern kedro dataset breaks

Description
Using mlflow datasets that wrap a modern dataset results in an error
Context
Cannot run the pipeline successfully. Breaks on saving the data (possibly on loading too?)
Steps to Reproduce

Wrap json.JSONDataset with MLFlowArtifactDatasetmy_dataset:
  type: kedro_mlflow.io.artifacts.MlflowArtifactDataset
  dataset:
    type: json.JSONDataset
    filepath: data/08_reporting/my_dataset.json
  artifact_path: model

Run the pipeline

Expected Result
Should save successfully.
Actual Result
Errors while trying to save on that dataset

 /Users/project/.venv/lib/python3.10/site-packages/kedro/io/core.py:270 in save

   267
   268          try:
   269             self._logger.debug("Saving %s", str(self))
 ❱ 270             save_func(self, data)
   271          except (DatasetError, FileNotFoundError, NotADirectoryError):
   272             raise
   273          except Exception as exc:

 /Users/project/.venv/lib/python3.10/site-packages/kedro_mlflow/io/artifacts/mlflow_artifact_dataset.py:68 in _save

    65             if getattr(super().save, "__savewrapped__", False):  # modern dataset
    66                super().save.__wrapped__(self, data)
    67             else:  # legacy dataset
 ❱  68                super()._save(data)
    69
    70             if self._logging_activated:
    71                if self.run_id:

AttributeError: 'super' object has no attribute '_save'

---

DatasetError: Failed while saving data to dataset
MlflowJSONDataset(filepath=/Users/project/data/08_reporting/my_dataset.json, protocol=file).
'super' object has no attribute '_save'

Workaround
Experimented with changing __savewrapped__ to __wrapped__ and it gets rid of the error
Your Environment

kedro and kedro-mlflow version used (pip show kedro and pip show kedro-mlflow): 0.19.9 and 0.13.1
kedro-datasets: 5.0.0
Python version used (python -V): 3.10.14
Operating system and version: MacOS M2 Pro 15.0.1

Does the bug also happen with the last version on master?

Yes

can confirm, happens also with various other datasets

(@deepyaman FYI)
Hi, just to confirm, are you both using kedro-datasets==5.0.0 released a couple of days ago? Very likely, the faulty PR has been merged on October, 5th : https://github.com/kedro-org/kedro-plugins/pull/829.
Not sure about your fix @stroblme, does it solve it for you? This looks like a bug but I'm afraid the problem is deeper than this unfortunately. I'll have a look very quick.

@Galileo-Galilei , yes, this fixed it for me.
Package versions are as follow:
kedro==0.19.8
kedro-datasets==5.0.0
kedro-mlflow==0.13.1

https://github.com/kedro-org/kedro/blob/0.19.7/kedro/io/core.py#L259 should set __savewrapped__. My understanding is that super() should refer to json.JSONDataset, and this should have it set.
Trying to think through this, is it possible __init_subclass__ is never getting called?
It's interesting that changing it to __wrapped__ does work, since it's the same part of the code in Kedro core that wraps (setting __wrapped__) and manually sets the __savewrapped__ attribute...
It will be hard for me to prioritize looking into this in the next few days, but let me see if I get a chance.

Can you make a PR? I am on my phone so it's not easy but I can release it immediately if someone submits the PR

@ deepyaman it's intellectually interesting to understand why, but if the fix works, don't worry and don't bother wasting time to investigate unless you really want it ;)

if getattr(super().save, "__wrapped__", False):  # modern dataset
    super().save.__wrapped__(self, data)
else:  # legacy dataset
    super()._save(data)

If want to go with this fix, I think it should be ideally:
if hasattr(super().save, "__wrapped__"):  # modern dataset
    super().save.__wrapped__(self, data)
else:  # legacy dataset
    super()._save(data)

(as __savewrapped__ should be a bool, while checking __wrapped__ is testing function presence)

Some follow up :

In debugging mode, the cls.save has the __savewrapped__ attribute and __init__subclass is properly called, but super().save does not have the attribute.
Many tests fails with the most recent version of kedro-datasets, but all passes with above fix ✅

➡  I release the fix and won't investigate more for now


Channel pages are missing proper meta descriptions

See: https://www.facebook.com/lbryio/posts/1866472090336219

what should it be saying? my last PR that i closed to clean it up i added some facebook and twitter cards to the metadata that might have what your looking for

currently the meta descriptions for channel pages are set to:
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@lbryio">
<meta property="og:title" content="spee.ch">
<meta property="og:site_name" content="spee.ch">
<meta property="og:type" content="website">
<meta property="og:image" content="https://spee.ch/assets/img/content-freedom-64px.png">
<meta property="og:url" content="http://spee.ch/">
<meta property="og:description" content="Open-source, decentralized image and video hosting.">

A few of these are wrong:
og:url should be spee.ch/@channel (right?)
og:description should be something referencing the channel. Maybe something like "Free images and videos published by @channel". This could still be better.
og:title should just be @channel or "@channel on spee.ch"
I'm not sure what twitter:site should be.

yea i can fix this in my next PR that adds social charing buttons since this would tie into the facebook share button ill do this after billbit does some css changes he told me to hold off on my old PR and i want to clean it up a lot.
about the twitter stuff i think i have proper cards setup for this instance already just need to test it while its live for sizing and some other things that are clearly described or usage example in twitter dev docs,
for the twitter:site that should be the twitter account name for the provider like @speech or @lbryio on twitter, heres where i added twitter cards all fields are correct formatted except the video post functions https://github.com/lbryio/spee.ch/pull/158/commits/d2c4ce8b923cdccc2b94cb7e019693f9daee3209
all the meta data description and site stuff we want to be linked to provider site for twitter
i can change it up a little with suggestions you have for description and title ect. shouldnt be hard just twitter has to be live to test not sure if facebook has a test option since twitter discontinued there offline tester thing

reference:
https://developer.twitter.com/en/docs/tweets/optimize-with-cards/guides/getting-started
https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/player-card
https://developers.facebook.com/docs/sharing/webmasters


fix(pagination): rename componet -> component

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our
guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Which package are you modifying?

[ ] accordion
[ ] alert
[ ] alert-dialog
[ ] aspect-ratio
[ ] avatar
[ ] badge
[ ] button
[ ] calendar
[ ] card
[ ] checkbox
[ ] collapsible
[ ] combobox
[ ] command
[ ] context-menu
[ ] data-table
[ ] date-picker
[ ] dialog
[ ] dropdown-menu
[ ] hover-card
[ ] icon
[ ] input
[ ] label
[ ] menubar
[ ] navigation-menu
[x] pagination
[ ] popover
[ ] progress
[ ] radio-group
[ ] scroll-area
[ ] select
[ ] separator
[ ] sheet
[ ] skeleton
[ ] slider
[ ] sonner
[ ] spinner
[ ] switch
[ ] table
[ ] tabs
[ ] textarea
[ ] toast
[ ] toggle
[ ] tooltip
[ ] typography

What is the current behavior?

component is spelled as "componet"
Closes #
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Ups not sure why I missed that when creating the compone(n)ts 😄
LGTM!


unable to recognize "deploy/1.8+/metrics-server-deployment.yaml“

Hi! i am a newbie, when i exec "kubectl create -f deploy/1.8+/" from the top-level directory of this repository, it made an error: unable to recognize "deploy/1.8+/metrics-server-deployment.yaml": no matches for kind "Deployment" in version "extensions/v1beta1".

Hi @yhxjack ,
I'm guessing you are running kubernetes 1.16 correct?
Could you try with the change from https://github.com/kubernetes-incubator/metrics-server/pull/311 please?
Thanks,
Joseph

hi，thank you very much! you are so excellent and you are right, i use the kubernetes version is 1.16. I have already solved the problem three days ago.  The link of #311 is so admirable, thanks for your helping!
------------------ 原始邮件 ------------------
发件人: "Joseph<EMAIL_ADDRESS>发送时间: 2019年9月7日(星期六) 凌晨3:55
收件人<EMAIL_ADDRESS>抄送: "杨宏兴（HongXingYang）"1328914062<EMAIL_ADDRESS>主题: Re: [kubernetes-incubator/metrics-server] unable to recognize "deploy/1.8+/metrics-server-deployment.yaml“ (#309)
Hi @yhxjack ,
I'm guessing you are running kubernetes 1.16 correct?
Could you try with the change from #311 please?
Thanks,
Joseph
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


v1.2

This new version is having pwa bug fixes,responsive web design,improved storage performance(pouchdb),easy to use settings in mobile without using keyboard,saved settings for some features(beta)

Nice impovements

Nice impovements


Specify TLS cert as a path

Currently a user should copy contents of a cert and paste into form.
This should be fine if you are using a self signed cert but if a user uses LetsEncrypt to issue a real cert then instead we need a path to cert/key.
Ideally the TLS configuration should be simplified to avoid mistakes.
For example instead of two cert and key paths a user may just select a folder and internally we can check for fullchain.pem or privkey.pem.
Also by default the /etc/letsencrypt/live/ can be scanned on start and all certs loaded and then they can be used depending on a Host header.
Another one place to check is /etc/ssl/private/.
I'm not sure if the LE can be runned in Windows but for Linux and Mac this should work

Initial thoughts:
I agree that we should make it possible to pick a cert file instead of needing to paste in the string. Probably just adding a button to pick from a file, but still storing it as a string rather than a filepath.
I don't think we could scan that directory for certs because we wouldn't have permission to without prompting the user to "open" a directory in the filepicker.

You'll need to specify a dir because the certbot renews certs. And also on the reneweal it need a hook to restart a web server


Setting to filter/ignore drives within the same geofence (or according to certain user-set parameters)

Is your feature request related to a problem? Please describe.
With the new Streaming API, every single and smallest drive is being recorded (which is great!) but it also records/counts the tiniest drives (for example coming in or out of a garage that has to be opened manually) as a drive entry (and destination). This means that for every coming in or out of garage (for example) will generate a single "0km" drive and essentially render some stats (median distance, top destinations...) null and void in the long run.
Describe the solution you'd like
It would be great to have a setting to "not record" (as in "not really count") drives which are within the same geofence (providing of course they meet other time. or distance-based criteria. This setting could be turned on on either the "settings" page or even within the geofence page; with maybe the time- or distance-based being set/customizable by the user.
It would either not count that data as a drive OR merge that data with the preceding or next drive (provided it started/ended within x time-frame).
Describe alternatives you've considered
Might be possible to filter out this data in Grafana in some way (as in "not show up drives less than x km" for example), but I think the data would still pollute other stats (top destinations, median drive length...)
Additional Context
Example of these "0 km" drives.

After seeing this, I checked my Drives and don't see any like those you're showing.  I'd have expected a few (I've been running 1.19-dev and now latest for a couple weeks).  Wonder what the difference is.  I moved my car yesterday from one side of the driveway to the other.  No drive was recorded for that.  Anything unique about your short drives?

I get the same problem, it loggs small trips in my garage.

I'd say:

if less then 5 minutes from end of last trip, append to the last trip
if shorter than 500m (and not above), ignore
start new trip

These are sensible defaults, but should preferably be configurable from settings page.

Anything unique about your short drives?

I don't think so, these are really short 4-5 meters trip out of the garage. If it can help narrow it down I am on a S with MCU1 and also using TeslaFi.

These are sensible defaults, but should preferably be configurable from settings page.

I agree, and also I would say the setting should purely be on the report side not on the data storage side. But if that's the case, maybe just editing the chart personally within grafana is a viable option instead?

I absolutely agree that this should be implemented purely be on the report side. This requires only minimal adjustments to the queries.

@fetzu BTW you can simply update your grafana and just add to set a min of 1 km or change to however you feel best. He wasn't exaggerating when @adriankumpf  said minimal :) All you need to do is go to grafana, click edit from the drop down of the panel to edit /w admin login.
WHERE distance > 1;

I'd say:
1. if less then 5 minutes from end of last trip, append to the last trip
2. if shorter than 500m (and not above), ignore
3. start new trip

Second point should be doable on Grafana, but what about the first one? I think it's a valid point and as was said before, being able to configure it in the Settings page would be great.

@Dulanic Thank you for the quick tip, but this does not solve the scope of the problem at all: changing how drives are shown on the dashboard will not refrain these "end destinations" to be recorded and shown in other dashboards such as "Locations" or "Drive stats".
I understand I could manually change the settings of each of these dashboards in Grafana to show the data the way I want to; but this is not in any way a permanent solution (ie: that modified dashboard might become obsolete with every release).
I am in no way proficient nor comfortable enough to code and implement this, so I don't know what exactly could be done in Grafana or not (user-set settings for example), or if this need to be taken care of upstream.

So I don't have the time to do much with this.,.. but here is a function that would adjust the drives to a custom rounded minute range,.....
rounded_drive.zip
@MaxG88 Here is a quick function I made and an example of how to use it.,... this would start times to the nearest 30 minutes. I set the where to show specific examples where it would combine the drives. So I don't think we need to change the data storage method as we can do it on the report side. It's also changeable via the function variable.

@Dulanic Thanks! Looks interesting, I'll have a look at it some time soon.


add Insulet OmniPod

WIP - don't merge.
Opening the PR for ease of conversation with @mgranberry

@kentquirk I did the work to merge in updates from master and resolve conflicts. That included what we discussed before about replacing the addition of annotations in the builder with the common util I had here. So I did that for the PX and Dexcom in commit 62e32d87d90ea6fb34fe6b6135cfd1707c6cd7f8. Want to take a look at just that now (and test if you're able) to make sure all is well?

@kentquirk I believe this is now pretty much ready for review. I'm still working on some additional simulator tests, but we should probably start the review process. I'm going to call out a few things myself inline, so look for that.

I've completed my review. I don't think anything is really major but I'd like to see a few changes, please.

Thanks @kentquirk. I'm compiling a list of TODOs; will respond in more detail to specific issues if there's need.

Approved. Merge when ready.


pass on empty string result with jq raw output mode

This changes fixes a bug in the jq processor when in raw output mode. Previously, if a query resulted in an empty string, it was treated as an empty message and dropped. Empty strings however are intentional and should not be coalesced into empty messages.
For example:
input:
  generate:
    mapping: root = {"test":""}
    interval: ""
    count: 1

pipeline:
  processors:
    - jq:
        output_raw: true
        query: '.test'
    - log:
        message: 'message is `${! content() }`'

output:
  drop: {}

Should output a log message like this:
{"@timestamp":"2022-01-19T22:12:44Z","@service":"benthos","component":"benthos.pipeline.processor.1","level":"INFO","message":"message is ``"}

Currently, the message is dropped and no log message is printed
Background
This was originally detected by @Jeffail in #1048 (source)

Thanks @disintegrator, looks good!


Add option to disable Websocket UTF-8 validation

While UTF-8 validation should be enabled by default (as it is a requirement of the standard), disabling it can speed up Cowboy immensely, making it 4 times faster than normal.

Done locally. Push soon.


Memory allocation issue with setComponentRam() assigned between 192 - 256 MB

setting up a topology results in an error within heron
com.twitter.heron.api.Config.setComponentRam(conf, "sentence", ByteAmount.fromMegabytes(192));

the problem only seems to be with memory range 192-256MB .
heron_internals.yaml --override_config_file=./heron-conf/override.yaml --ckptmgr_port=58984 --ckptmgr_id=ckptmgr-1
[2018-03-22 14:42:05 -0700] [INFO]: container_1_split_2 stdout: Invalid maximum heap size: -Xmx0M
[2018-03-22 14:42:05 -0700] [INFO]: container_1_split_2 stdout: Error: Could not create the Java Virtual Machine.
[2018-03-22 14:42:05 -0700] [INFO]: container_1_split_2 stdout: Error: A fatal exception has occurred. Program will exit.
[2018-03-22 14:42:05 -0700] [INFO]: container_1_split_2 stdout:
[2018-03-22 14:42:05 -0700] [INFO]: Logging pid 94266 to file stmgr-1.pi

this seems to be a problem with ResourceCompliantRRPacking , instances with ram config between  192 - 256 MB generate 0xmx for the instance plan , the problem seems to be with PackingUtils.java
                                                    Map<String, Integer> componentChanges,
                                                    Resource defaultInstanceResources,
                                                    ScalingDirection scalingDirection) {
    double cpu = 0;
    ByteAmount ram = ByteAmount.ZERO;
    ByteAmount disk = ByteAmount.ZERO;
    Map<String, ByteAmount> ramMap = TopologyUtils.getComponentRamMapConfig(topology);
    Map<String, Integer> componentsToScale = PackingUtils.getComponentsToScale(
        componentChanges, scalingDirection);
    for (String component : componentsToScale.keySet()) {
      int parallelismChange = Math.abs(componentChanges.get(component));
      cpu += parallelismChange * defaultInstanceResources.getCpu();
      disk = disk.plus(defaultInstanceResources.getDisk().multiply(parallelismChange));
      if (ramMap.containsKey(component)) {
        ram = ram.plus(ramMap.get(component).multiply(parallelismChange));
      } else {
        ram = ram.plus(defaultInstanceResources.getRam().multiply(parallelismChange));
      }
    }
    return new Resource(cpu, ram, disk);
  }```

This issue is not caused by RCRR packing.
I launched a topology with 192 ram allocated to a bolt counter. I found the following in the executor logs.
[INFO]: component name: counter, ram request: 201326592, total jvm size: 192M, cache size: 64M, metaspace size: 128M

The executor correctly received ram size. Which means packing worked as expected.
However the issue still exists, because the process fails to launch:
[INFO]: container_1_counter_3 stdout: Invalid maximum heap size: -Xmx0M

The culprit is https://github.com/twitter/heron/blob/master/heron/executor/src/python/heron_executor.py#L562
    # TO DO (Karthik) to be moved into keys and defaults files
    code_cache_size_mb = 64
    java_metasize_mb = 128
...
      total_jvm_size = int(self.component_ram_map[component_name] / (1024 * 1024))
      heap_size_mb = total_jvm_size - code_cache_size_mb - java_metasize_mb
      Log.info("component name: %s, ram request: %d, total jvm size: %dM, "
               "cache size: %dM, metaspace size: %dM"
               % (component_name, self.component_ram_map[component_name],
                  total_jvm_size, code_cache_size_mb, java_metasize_mb))

@kramasamy may know more about the reason.
@jerrypeng @nwangtw, you may want look at this issue before adding any new configs to correctly estimate jvm size.


[HNC-556] - Update the Citadel action script to include extra placeholders

Update the Citadel action script to modify the Citadel JSON file with the following values:

Branch (should this match the code being scanned?)
Org
RepoPathsandBranch (repo_name, repo_branch)
RepoPathsIncludes (plugin_names that received builds)
ArtifactURL (Generated Artifactory Zips for build plugins)

It will only update the value if it contains a placeholder '$'. If it does not have the '$' placeholder, it will keep the original value the default.

Here is the workflow link, which runs the Citadel scan by passing build artifact URLs and plugin names to the Citadel JSON file.
Here is the action-common script, which reads the build artifact URLs and plugin names and passes them to the Citadel scan step.
here citadel-config.yaml file used for testing.

Note - For testing purposes, fetching the already present build information on Artifactory (i.e., build.number=347) and running the Citadel scan

Update the Citadel scan script to fetch plugin names from the manifest file and determine the artifact zip URL for those plugins.
The script will only update the values if the Citadel config YAML file contains the specific placeholder mentioned below for each particular key

branch: '$branch'
org: '$org'
repoPathsandBranch: '$repoPathsandBranch'
repoPathsIncludes: '$repoPathsIncludes'
artifactURL: '$artifactURL'

Here is the workflow link, which fetches plugin names from the manifest file and fetches URLs for those plugins, passing them to the Citadel scan.
Here is the Citadel scan step in action common, which runs the Citadel scan.
Here is sample artifact-manifest.yaml file used for testing.