make sense of input to PoST initialization

Description
current input to PoST initialization is the hash of 72B:

bytes [0-32] is commitment
bytes [32-40] is label index
bytes [40-72] are always zero

and pass empty salt to scrypt (nullptr and 0 length).
below is Iddo's response:
in an old discussion we said that because there are would be at least 3 input args
(miner_id, network_id, label_index) that we need to feed to scrypt, it's natural to just
use the input (a.k.a." password") arg and concatenate those 3 params (or more) to
be the input.

The 72B input size is weird, PoW miners use 80B, and they use salt equal to the input
(rather than salt==0), but that 80B number is arbitrary too.
It seems that we do the worse of all worlds? We create commitment=hash(miner_id,network_id,..),
and concatenate label_index to it? And to make it even worse we then concatenate 32
zero bytes for no good reason.

What we should do is either of these 3 options:
1. commitment=hash(miner_id,network_id,..) as the input and label_index as the salt.
2. (miner_id,network_id,...,label_index) as one concatenated index and then the salt can be empty.
3. (miner_id,network_id,...) as one concatenated index and label_index as the salt.

If "commitment" is an identifier that we make use of in the protocol anyway then option 1 is best.

It's impossible to tell for sure, but it seems that bits 40-72 were reserved for additional commitment information. It was, however, squeezed into bits 0-32 by hashing commitment_atx_id with node_id with blake3: https://github.com/spacemeshos/post/blob/d94f9aace7d00f7176ed247520ecadc61c878912/oracle/util.go#L5-L11.
Closing as there is nothing to do.


[c++] Addition of SOMAObject

Issue and/or context:
https://github.com/single-cell-data/TileDB-SOMA/issues/1356
Separated out from PR #1449.
Changes:
Addition of SOMAObject which is an ABC for all public SOMA API data structures.
Notes for Reviewer:
N/A

Codecov Report
Patch coverage has no change and project coverage change: +27.49 :tada:

Comparison is base (c20584b) 64.05% compared to head (dc05237) 91.55%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1475       +/-   ##
===========================================
+ Coverage   64.05%   91.55%   +27.49%
===========================================
  Files          99       30       -69
  Lines        8219     2498     -5721
===========================================
- Hits         5265     2287     -2978
+ Misses       2954      211     -2743

Flag
Coverage Δ

python
91.55% <ø> (ø)

r
?

Flags with carried forward coverage won't be shown. Click here to find out more.
see 69 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Danbooru Api Key Login throws Key 0

Describe the bug
Using the Api key and the user_id to log into danbooru will not work
the error:
Traceback (most recent call last):
File "test.py", line 10, in
asyncio.run(main())
File "C:\anaconda\envs\bot\lib\asyncio\runners.py", line 43, in run
return loop.run_until_complete(main)
File "C:\anaconda\envs\bot\lib\asyncio\base_events.py", line 616, in run_until_complete
return future.result()
File "test.py", line 6, in main
res = await dan.search(query="cat_girl", limit=1)
File "C:\anaconda\envs\bot\lib\site-packages\booru\client\danbooru.py", line 130, in search
self.not_random = Danbooru.append_obj(self.final)
File "C:\anaconda\envs\bot\lib\site-packages\booru\client\danbooru.py", line 38, in append_obj
if "id" in raw_object[i]:
KeyError: 0
To Reproduce
Intitialize Danbooru exactly like the documentation instructs.
using the username or number only user ID will not work
Gelbooru works however
Expected behavior
A clear and concise description of what you expected to happen.
Desktop (please complete the following information):

OS: Windows with Anaconda
3.8.5

Additional context

Hi, thanks for reporting and fixed already. It is because danbooru:docs required parameter login instead user_id
also i have tests stuff without api auth so login properties may not same it all, If you encounter this misleading in another booru please open an issue again


[cinder-csi-plugin] make capacity check consistent

What this PR does / why we need it:
Which issue this PR fixes(if applicable):
fixes #1201
Special notes for reviewers:

Release note:

NONE

/hold
please check my comment on the issue , #1201

/close


Adjusting the placement of header menu carets

CATEGORY
Choose one

[X] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY
Just a quick/tiny CSS tweak to move the carets up and over, and make sure they actually fit within their container. This also adds a LESS file for the menu, so we can make other tweaks in the future.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:

After:

REVIEWERS
@mistercrunch

Codecov Report

Merging #8618 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8618      +/-   ##
==========================================
+ Coverage   65.78%   65.78%   +<.01%
==========================================
  Files         482      482
  Lines       23797    23805       +8
  Branches     2587     2589       +2
==========================================
+ Hits        15654    15661       +7
- Misses       7974     7975       +1
  Partials      169      169

Impacted Files
Coverage Δ

superset/assets/src/components/Menu/Menu.jsx
87.5% <ø> (ø)
:arrow_up:

...t/assets/src/dashboard/reducers/getInitialState.js
0% <0%> (ø)
:arrow_up:

superset/jinja_context.py
76.69% <0%> (ø)
:arrow_up:

...ets/src/SqlLab/components/TemplateParamsEditor.jsx
85.29% <0%> (ø)
:arrow_up:

superset/views/core.py
71.85% <0%> (+0.05%)
:arrow_up:

superset/utils/core.py
88.08% <0%> (+0.06%)
:arrow_up:

...uperset/assets/src/SqlLab/components/SqlEditor.jsx
52.05% <0%> (+0.33%)
:arrow_up:

Continue to review full report at Codecov.

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


Any string-expression can be used as key in struct/map/json initializer

Keys of struct/map/json initializers are supposed to be static.
Below program works without errors. ideally, it should fail at compilation time.
function main (string[] args) {
    map j = { foo(): "supun"};
    system:println(j);
}

function foo() (string) {
  return "name";
}

Above issue is fixed, and it now prints the below error message.
error: mainFunction.bal:4:16: invalid field name in 'struct' literal, identifier or string literal expected

However, in the error message it says 'struct' literal, but it should be 'map' literal


Added goog.structs.Map.prototype.findValue and findKey

Added goog.structs.Map.prototype.findValue and goog.structs.Map.prototype.findKey to add functionality missing when converting an Object<K, V> to a Map<K, V>.
These are simply modified versions of goog.object.findValue and goog.object.findKey.
See discussion here
cc @concavelenz

I don't see how my change could have made testExistingImage timeout

@ghosttie I think that's a known failure not related to your change.

@ghosttie I think these API additions would be better off as a general structs utility. That is, a method in https://github.com/google/closure-library/blob/master/closure/goog/structs/structs.js. This may be more than you'd like to take on though.

OK I only did it that way because Map seemed to use member functions rather than utility functions e.g. goog.array.forEach vs goog.structs.Map.prototype.forEach

@MatrixFrog Do you recall why goog.structs.forEach was slated for deprecation and Map has its own implementation?

goog.structs.forEach is just a bit weird. It's handling maps, sets, arrays, and any collection that happens to have a method called 'forEach', all in one function. It's rare that you want to iterate over something but have no idea what the thing is. If you know it's a map, use the map's own forEach method. Likewise with goog.structs.get{Keys,Values}.

I'm not sure we actually want to be encouraging the use of goog.structs.Map at all.  Now that the compiler supports ES6 Map, that's really a better option in basically every situation.  goog.structs.Map has a number of fundamental problems (primarily around non-string keys) and gives users a false sense of confidence that it will "do the right thing" when it really won't.  I'm hopeful that it will be officially deprecated Any Day Now™.

Mainly for the reasons expressed in the previous comment, I'm closing this out.


api error that occur during testing

[ ] data = await puppet.contact_alias(id='token', alias='mylove')

grpclib.exceptions.GRPCError: (<Status.INTERNAL: 13>, 'CacheManager getContact() has no cache.', None)

[ ] data = await puppet.contact_self_q_r_code()

grpclib.exceptions.GRPCError: (<Status.INTERNAL: 13>, 'Wechaty Puppet Unsupported API Error. Learn More At https://github.com/wechaty/wechaty-puppet/wiki/Compatibility', None)

contact_self_q_r_code() looks wired...
https://github.com/wechaty/python-wechaty-puppet/blob/master/src/wechaty_puppet/puppet.py#L391

@huan I kept the name consistent with chatie-grpc.  contact_self_q_r_code  is a function name of the chatie-grpc.wechaty.PuppetStub class. Should I rename it ?

Interesting. Our grpc code are auto generated.
I'll have a review on the generator script later, please let me know if you get something new.

I just have an idea that the self_q_r_code might comes from SelfQRCode: the auto-generating script adds _ before every CAPiLIZED letter.
We can keep it before we have a better generator script to replace the current one.


apply-all should error if TERRAGRUNT_SOURCE is specified

I caused a MAJOR production outage across a set of tenants because I accidentally had the TERRAGRUNT_SOURCE environment variable set when I performed an "apply-all" across our tenants.  This caused more than 800 resources across 6 customers to be deleted because TG attempt to apply the source from TERRAGRUNT_SOURCE against a set of terragrunt.hcl files that were for different modules.
TERRAGRUNT_SOURCE is incompatible with apply-all unless all modules being applied are for the same source.  apply-all should have prevented this from happening either by erroring or prompting me to confirm specifically about TERRAGRUNT_SOURCE.

Sorry to hear you hit this issue. That sounds really painful 😕
FWIW, we use TERRAGRUNT_SOURCE quite regularly with apply-all, especially when spinning up totally new environments. That said, there are a number of limitations / gotchas with TERRAGRUNT_SOURCE, and we've captured a proposal for a better replacement in #1138. Let's continue the discussion in there. I'll close this issue for now.


url-parse security vulnerability

Motivation
url-parse security vulnerability
Proposed solution
upgrade the url-parse version to > 1.5.7
Additional context

Thanks @cdhawke, I've updated deps and will release new update soon.


Add a load_data() method

Display an image using an existing np.array, instead of going through a file. May exist but my observational powers are limited.

The  view() method exists for looking at numpy or nddata arrays:
import imexam
import numpy as np
a=imexam.connect()  #start ds9 by default on X systems
data=np.random.rand(100,100)
a.view(data)
a.zoomtofit()

See my observational powers failed. Thanks!

So, I was looking for another 'load_***' method. Conversely, looking at the documentation for view, it has "view(img,...", and being mono-minded, I would have clued in on "view(array,...)" instead. "img" carries too many connotations, such as a FITS HDUL, or HDU, or jpeg/gif/png, etc. So, yes, probably a renaming/redocumenting, but definitely not based on this one datapoint.


Add function that returns all valid shipping methods

I want to merge this change because...

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Codecov Report

Merging #8418 (3ed2432) into main (4311433) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #8418   +/-   ##
=======================================
  Coverage   92.99%   92.99%
=======================================
  Files         493      493
  Lines       37560    37562    +2
  Branches     4299     4299
=======================================
+ Hits        34929    34931    +2
  Misses       1774     1774
  Partials      857      857

Impacted Files
Coverage Δ

saleor/checkout/fetch.py
97.77% <100.00%> (+0.02%)
:arrow_up:

Continue to review full report at Codecov.

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


Wiki community link file migration tool

Hi guys, I know this is not a proper issue but I don't really where to post it.
At Meetic we made a small tool, in PHP, that migrate files from parse.com to a private AWS S3 bucket and updates files names in your private mongoDB.
I think this can useful for someone out here and it be found here : https://github.com/Meetic/parse-files-migration-tool.
I also think this could be a "good" link to add to wiki community link list.
Regards

Probably we could add it to the docs :)

What would be the tableName here: https://github.com/Meetic/parse-files-migration-tool/blob/master/src/ParseServerMigration/Console/PictureRepository.php#L188

Hi,
The "table name" here is the mongoDB collection name that you had files links saved to.

Yeah but usually that table doesn't exist or is not a single table.

Ok I get the point.
Expected workflow is to migrate S.A.A.S parse DB to your own private mongoDB instance and then run the tool.
If you have several file location to migrate you can run the tool as many time as you collections you want to migrate just by editing your configuration.
Ill add a part on readme.md about the parse data migration requirement.

Closing as a non-issue, feel free to continue commenting here to coordinate though.

@flovilmart So is everything ok for you ?

I'll add it :)

Greats thanks ! Feel free to point out if everything is not crystal clear for you.

here: https://github.com/ParsePlatform/parse-server/wiki/Files-Migration

Great! I didn't see that there was an existing tool :D


Add support for uprobes

Hi,
This PR adds supports for tracing uprobes.
It includes some new functions used to query the symbol cache for the location (file and offset) of function within userland code; and to retrieve a list of matching symbols (functions) from a given module (library or binary) to allow attaching to all symbols that match a certain pattern. (Both these ideas borrowed heavily from the Python implementation).
It also adds functions to the Module type to allow adding of uprobes, uretprobes, and all those that match a pattern.
Finally an example, strlen_count.go, of how to use these new functions.
I do have a query/problem that I could do with some advice on, regarding the example:
I have used a Table without a PerfMap (in contrast to the other example which is given). The tracing happens until the user hits Ctrl-C,and then we iterate over the table entries with the Table.Iter() function.
The problem I have is that results are returned as an Event{Key: string, Value: string} where Key and Value appear to be string representations of C *char strings, like:
"[ 0x66 0x76 0x33 0x0 ]" - i.e. this is a string, not a series of chars. The only (ugly) way I could figure out to extract the actual string was to remove the 0x, concatenate each value and then use hex.DecodeString.
Is there a better way?
Many Thanks
Louis

Great!
For the string/hexa thing, it seems that bcc has some automatic introspection mechanism via C.bpf_table_key_snprintf() to see how to print the key according to its type but I don't know how it works.

Sorry for delay, been uber-busy. Readline example to follow.

@schu all requested changes have been implemented. Cheers.

Thanks @louism517 - we have been busy as well :)
I meant to drop the drop the strlen_count example app entirely in favor of bash_readline (to avoid the adventurous string conversion + lib problem with strlen_count) but YMMV.
Can you squash the commits into one with a clean message? Otherwise ok for merge I think :+1:
@alban please take a look.

@louism517 Sorry for the delay! I added my review.

@alban - changes made as requested.

@louism517 thanks for the fixups!
We have changed examples and each tool has its own sub directory now (https://github.com/iovisor/gobpf/tree/master/examples/bcc). Could you move examples/strlen_count.go to examples/bcc/strlen_count/strlen_count.go and examples/bash_readline.go to examples/bcc/bash_readline/bash_readline.go. Also, please squash everything into a single commit bcc: add support for uprobes. Happy to finally merge after :+1:

@schu Changes as requested, and squashed commits. Thanks!

Thank you :sparkles:


changes to grammar, wording

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

fixed grammar, wording

Hi
As there has been no response from your end for a while, we are closing this PR.
Feel free to request this PR to be reopened, if you still wish to make the changes you originally added.  Also, remember to update your fork, so you have the latest version of master in case it has changed significantly.
Happy Coding! ✈


python311Packages.napari-npe2: fix the build

Description of changes
tomli-w dependency was missing.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-linux 1

2 packages failed to build:

napari (python311Packages.napari)
napari.dist (python311Packages.napari.dist)

2 packages built:

python311Packages.napari-npe2
python311Packages.napari-npe2.dist

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 284140 run on x86_64-linux 1

2 packages failed to build:

napari (python311Packages.napari)
napari.dist (python311Packages.napari.dist)

2 packages built:

python311Packages.napari-npe2
python311Packages.napari-npe2.dist

First step to fix naparibuild is done in https://github.com/NixOS/nixpkgs/pull/284199


Feat/delete block

Comments you make in GitHub show up in DiffPlug.

And, you can take "liveshots" in DiffPlug and embed them into the discussion on GitHub.
Why did we delete this block again?

TMATS_Library/Lib_Cntrl_CorrectedGasFlow_TMATS.slx/Corrected Gas Path Flow

In GitHub, these are just screenshots.

And comments you make in DiffPlug show up in GitHub. But!
You can also add "liveshots", which link directly to the diff inside of DiffPlug.
Why did we delete this?

TMATS_Library/Lib_Cntrl_CorrectedGasFlow_TMATS.slx[simulink]Corrected Gas Path Flow

DIffPlug adds the ability to create "liveshots", deep links into a diff or view.

8f3dbfe4687b328ddd4a17250a88589879d755fe:/Trunk/TMATS_Library/Lib_Cntrl_CorrectedGasFlow_TMATS.slx

In DiffPlug, you can always double-click on of these liveshots to recreate the exact view or diff, including commit, comparison settings, etc.
But in GitHub, it just looks like an image.

ABC

"image" (https://raw.githubusercontent.com/test-repo/dp-images/185eb489da2e1eef687397edf2eeaf5a79a4e24f.png)

123


Fixed some bugs with AwaitObservable

The original implementation of AwaitObservable doesn't perform well when the workflow is cancelled before the observable produces a result. This was fixed in this PR on the fsharpx project. However this implementation would call multiple continuation functions for hot observables. Details on stack overflow. The implementation here fixes the issue, although I'm not sure it's optimal.

This looks good to me - although I have not tested it. I guess starting an agent adds some overhead, but I'm not sure if there is a better implementation - so I'd be OK with that. Also, I think the symbol NET40 is not actually defined anywhere in the project - or is it?
Also, the latest version of the code now lives here: https://github.com/fsprojects/FSharpx.Async. Really sorry for a 3rd redirect! The code from this repo moved around quite a bit - but the fsprojects repo is the most recent place for them (also, much better one).
I'll edit README for this repo to avoid any future confusions!

Ah, ok thanks. I just googled FSharp.Async and this project was the first result. I'll get back to it on the weekend. I see that project also has a tests project there so I will also transfer the unit tests I have.


Read COCO dataset from ZIP file?

For large datasets on e.g. university clusters, where your data storage is an NFS mount, reading individual files can be slow. It also doesn't support reading ahead. In the cloud, you typically have SSD storage, but unzipping the dataset still takes time.
Would you be open to receiving a pull request that reads the COCO dataset from its zipped version? It adds around 10 lines in the COCO Detection class, and adds another Python file for reading ZIP files in a fork-safe manner (so it works with distributed training).

You mean that all the images are in a zip file?
And how would the structure of the reading be? Does it unzip it all locally, or read the zipped file without uncompressing it all?
In general, I don't see why this would be something specific to the COCO dataset. But finding a generic way of supporting this for all datasets is something that would be great to have.

Yes, all the images are in a zip file and they are read without unzipping. With the constraint (added by me) that the ZIP file shouldn't use compression (which is the case for COCO).
Note that ZIP files are suited for this because they have an index. For tar files, it isn't very efficient because you need to walk over the entire file first to build an index.
I'll first create something just for COCO, and then we can look at which other datasets are stored as ZIP files.

This could easily apply to the following datasets as well (because they are stored as ZIP files):

celeba
omniglot
phototour (though not really, because it does postprocessing on the files after extraction)


Access the Webpage over Internet

Hi @MoffKalast ,
Thanks rot sharing this package.
By using ngrok or tailscale through forwarding, is it possible to access the web page with port of 5000 via Internet?
If yes, is it a need to forwarding the rosbrige port of 5001?
Thanks.
David

Yeah that should work as long as the two ports are being forwarded, it's set up to listen on <IP_ADDRESS> by default. I've never tested with those two but it works with zerotier out of the box.


Optional chaining syntax error in the first example

Hi, thanks for the great course, enjoying it a lot!
I just wanted to share a little confusion I encountered. For the first example, I copied the code from the slides. I ran into issues with the optional chaining syntax:
Server running at http://localhost:1234
🚨  .../fem_xstate/src/00/index.js:37:4: Unexpected token (37:4)
  35 |   return machine
  36 |     .states[state]?
> 37 |     .on?.[event]
     |    ^
  38 |     || state;
  39 | }

I soon found out that the issue is the formatting here: The syntax doesn't seem to support line breaks after the question mark. After I put it all on one line, it worked just fine. However, having not worked with this new syntax in JS before, I first suspected some misconfiguration of Babel and went off to try and change that. Perhaps, to provide more clarity, the formatting on the slides could be adjusted, or a comment could be added.

I fixed it!


docs: 404 page shows wrong "Last Revision"

Go to https://gohugo.io/what
Notice below:
Last revision: January 1, 0001

For pages automatically generated by Hugo, like the 404 page, that don't rely on content files it would make more sense to default to build time of the website.

I suggest to add a check for .LastMod.IsZero, if true fallback to .Site.LastChange.

@bep I'm new to Hugo and Go. Let me know in which file the change is required, I'll make an attempt to fix it.

@chankeypathak https://github.com/spf13/hugo/blob/master/docs/layouts/partials/footer.html#L3

@bep Thanks. Just submitted the fix.

@chankeypathak we plan to switch to a new version of the docs that feature a new design. In the current state the 404 page doesn't show any revision date.
@budparr if you plan to add the last revision to your new design please let new know so we can incorporate @chankeypathak's submitted fix in the design.

Hey, @digitalcraftsman I removed that data from the theme for this request: https://github.com/gohugoio/gohugoioTheme/issues/8

The of the new design is nearly around the corner which doesn't make use of Git to show the date of the last revision. Should this issue then be closed?

Sounds OK to me. This can be closed.

Thank you anyway for your submission @chankeypathak.


Titles are not sanitized in Image Slider Edit

Adding an <a> tag to an image title breaks output when editing the image slider later.

Ill add this to my list of fun