can not set device

I use set_device() to run a model on a device,but it does not work!

Can you show where set_device() comes from?

The set_decice function is in src/targets/gpu/hip.cpp

@causten ,I have read the source code,and I find that the gpu::context set the  device_id to 0,so the model will always run in 0 device

I have read the source code,and I find that the gpu::context set the device_id to 0,so the model will always run in 0 device

Ah yes, we probably need a way to specify a different device when loading/running a model.

@qianqing13579 we don't have a way to set GPUs in MIGraphx currently, but for now if you have a multi-GPU machine, you can compile and run MIGraphX on a specific GPU by setting the ROCR_VISIBLE_DEVICES environment variable.
For example:
ROCR_VISIBLE_DEVICES=1 ./migraphx-driver run --model alexnet

This will pin MIGraphX to run on GPU 1.

@kahmed10 ,I have solved the problem. I modified the src/targets/gpu/target.cpp and src/program.cpp:

Great. Would you like to open an PR for this change?

@kahmed10 ,ok

@kahmed10 ,do I need to create a new branch?

@kahmed10 ,do I need to create a new branch?
I believe you can fork the repository and then create the PR. I don't think you will be able to create any new branches in the official repo.

@kahmed10, @pfultz2 , I have made a commit for this change.the link:https://github.com/qianqing13579/AMDMIGraphX/commit/94df31b9a62398405d6c52f098923d607d470dce

@kahmed10 , MIGraphX does not need to have this functionality. The functionality is developed by users in  theirs program. the demo is as follows:
// read device id from the configuration file
FileStorage configurationFile;
configurationFile.open("myconfig.xml", FileStorage::READ);
FileNode netNode = configurationFile["mymodel"];
int device_id=(int)netNode["device_id"];

// set device id
migraphx::compile_options options;
options.device_id=device_id;
net.compile(migraphx::gpu::target{},options);

Hi, @kahmed10 @qianqing13579
Is allocating model to a specific gpu implemented now? I am trying to run data-parallel that needs each GPU hosting 1 complete instance of model.

Yes, this was fixed by #1561.


fix radio column bug

hi, in use crud,i found radio column not working. $entry['attributes'] is undefined. hope helpful.

Hi @lloy0076,
Nope, no tests at the moment for visual components. Those will be done as part of the integration tests, which have not been started.
I guess you can manually test the radio buttons functionality in the backpack demo for this PR.

Hi @lucksevenl7 - thank you for the PR, mergin it into the dev branch now - it will be available publicly by the end of the week.
I see this was the only column getting the entry using $entry['attributes'][$keyName];, not $entry->{$keyName} so you shouldn't have this issue again ;-)
Thanks, cheers!

ok thanks


ValidationError 'ManagementForm data is missing or has been tampered with' when using an intermediate page

When trying to use an intermediate page to handle additional data required to complete an action, I'm getting the following error:
ManagementForm data is missing or has been tampered with
I modified the test project as follows to test this issue:
# blog/admin.py
[...]
class UnPublishActionsMixin(object):
    [...]

    def publish(self, request, obj, parent_obj=None):
        return render(request, 'admin/publish.html', context={})

[...]

# templates/admin/publish.html
{% extends "admin/base_site.html" %}

{% block content %}
<form action="" method="post">
    {% csrf_token %}
    <input type="hidden" name="action" value="publish" />
    <input type="submit" name="apply" value="Go"/>
</form>
{% endblock %}

And a full stack trace can be found here:
Environment:

Request Method: POST
Request URL: http://localhost:8001/admin/blog/author/1/change/

Django Version: 2.2.2
Python Version: 3.7.3
Installed Applications:
('django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'inline_actions',
 'test_proj.blog')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware')

Traceback:

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/core/handlers/exception.py" in inner
  34.             response = get_response(request)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/core/handlers/base.py" in _get_response
  115.                 response = self.process_exception_by_middleware(e, request)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/core/handlers/base.py" in _get_response
  113.                 response = wrapped_callback(request, *callback_args, **callback_kwargs)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/contrib/admin/options.py" in wrapper
  606.                 return self.admin_site.admin_view(view)(*args, **kwargs)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/utils/decorators.py" in _wrapped_view
  142.                     response = view_func(request, *args, **kwargs)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/views/decorators/cache.py" in _wrapped_view_func
  44.         response = view_func(request, *args, **kwargs)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/contrib/admin/sites.py" in inner
  223.             return view(request, *args, **kwargs)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/contrib/admin/options.py" in change_view
  1637.         return self.changeform_view(request, object_id, form_url, extra_context)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/inline_actions/admin.py" in changeform_view
  283.             request, object_id, form_url, extra_context)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/utils/decorators.py" in _wrapper
  45.         return bound_method(*args, **kwargs)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/utils/decorators.py" in _wrapped_view
  142.                     response = view_func(request, *args, **kwargs)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/contrib/admin/options.py" in changeform_view
  1522.             return self._changeform_view(request, object_id, form_url, extra_context)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/contrib/admin/options.py" in _changeform_view
  1560.             if all_valid(formsets) and form_validated:

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/forms/formsets.py" in all_valid
  448.         valid &= formset.is_valid()

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/forms/formsets.py" in is_valid
  301.         self.errors

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/forms/formsets.py" in errors
  281.             self.full_clean()

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/forms/formsets.py" in full_clean
  322.         for i in range(0, self.total_form_count()):

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/forms/formsets.py" in total_form_count
  110.             return min(self.management_form.cleaned_data[TOTAL_FORM_COUNT], self.absolute_max)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/utils/functional.py" in __get__
  80.         res = instance.__dict__[self.name] = self.func(instance)

File "/Users/mattelwell/projects/sandbox/django-inline-actions/.venv/lib/python3.7/site-packages/django/forms/formsets.py" in management_form
  92.                     code='missing_management_form',

Exception Type: ValidationError at /admin/blog/author/1/change/
Exception Value: ['ManagementForm data is missing or has been tampered with']

Thanks for pointing out that forms on intermediate pages are not supported. Will have a look how this could be changed in a future release :)

@melwell89 I just pushed version 2.3.0, which includes support for intermediate forms. Please have a look and report back if you encounter any issues :)
The implementation is very basic but fixes your use case.  This whole feature will be much easier to use, when the next major version has been released.

Great, thanks @escaped. I'll give it a try and let you know!


'The location property is required for this definition' error in examples/101/azurefirewall-create-with-zones

Bicep version
Bicep CLI version 0.3.126 (a5e4c2e567)
Describe the bug
When deploying examples/101/azurefirewall-create-with-zones this error is logged:
 (Code: DeploymentFailed)  - {   "error": {     "code":
     | "LocationRequired",     "message": "The location property is required for this definition."   } } (Code:BadRequest)

To Reproduce
deploy sample from above folder in a resource groups

PR fixed the problem


columns are getting improperly assigned to tables

I've noticed that sometimes, columns are assigned to a table that belongs to another.

This is now fixed.
We are assigning columns to a table without aliases when only one table is selected. This was happening at the end of the extract function, but we hit the end of this function quite often causing the other function to run too often. Instead, I've moved this to fire after the extract is completely done.


Ignore rubocop Layout/AlignHash in default config

If ruby calls span multiple lines, the extracted ruby code
doesn't have the original indentation, so the Layout/AlignHash
cop will give wrong reports
Example:
 $('#modal').html("#{escape_javascript(render(partial: 'submit_request_dialog',
                                              locals: { project: @project, package: @package,
                                              revision: @revision, target_project: @tprj, target_package: @tpkg,
                                              description: @description, cleanup_source: @cleanup_source }))}")

Becomes extracted:
escape_javascript(render(partial: 'submit_request_dialog',
                                             locals: { project: @project, package: @package,
                                             revision: @revision, target_project: @tprj, target_package: @tpkg,
                                             description: @description, cleanup_source: @cleanup_source }))

And rubocop would complain about 'Align the elements of a hash literal
if they span more than one line.'

Thanks @coolo. Failure seems unrelated.


Cache verification key in CLI [Do Not Merge Until New Published Version of SnarkyJS is Added]

Description
Addresses #158
Background
Currently every time the zk deploy command is run, the contract is compiled to generate a verification key which takes 10-30s. This leads to a poor experience when a developer goes through the deploy flow multiple times.
Approach
A hash of the contract's circuit can be quickly computed using the SmartContract.digest() method from SnarkyJS. This digest hash, along with the corresponding verification key that is generated, is stored in a cache the first time 'zk deploy' is run on a contract. When zk deploy is run in the future, if the contract digest matches the stored digest, the cached verification key is used. The contract is only recompiled if the digest changes. See the discussion here for more details.
Status
Currently SmartContract.digest() isn't available on the published version SnarkyJS. Don't merge this PR until the new version of SnarkyJS is published with SmartContract.digest().

Looks great! Assuming it all works whether build dir exists or not, like Gregor mentioned.


Update witx to 0.9

This pulls in the new witx 0.9 crate which notably includes
WebAssembly/wasi#395. This is a large refactoring of how witx signatures
are processed and a large update to the actual syntax of the witx ABIs
themselves.
This commit adjusts to all the new witx APIs and also tweaks idioms in
a few locations as well. Code generation is now less custom to Rust and
instead tries to match almost exactly what the witx crate tells us to
generate. Additionally the representation of types is chosen to more
closely align with interface types in the future where it's impossible
to pass invalid values to the outside world. Notable changes here are:

enum-like values are now newtype wrappers around integers to prevent
invalid values from flowing out.
Error traits are now implement directly for the Errno wrapper.
The module containing the raw functions now exclusively uses i32/i64
types and doesn't try to use convenience types in Rust.

It should be worth pointing out, however, that https://github.com/WebAssembly/WASI/pull/395 should block this and this should wait probably until that's published on crates.io.

Ok should be good for review now!

The Error changes are weird. Previously Errno was used for raw results and included "success" state (i.e. code 0). It got then mapped to Result<(), Error>, where Error was a transparent wrapper around NonZeroU16. Now you return Result<(), Errno>, which takes 4 bytes instead of the previous 2. Also the new code does not provide any way of creating Errno from raw codes, which for example is used by getrandom to return error descriptions defined in wasi.


Feedback for User provisioning

There's no documentation about what happens when user is being deleted by upstream source (Entra ID) or user license is set to (No Selection) by rules. The customers often have questions about that.

When user license is set to (No Selection) by rules we remove the user's license and set both "IsPersonRetired" and "Deleted" flags,
When a user is deleted from Microsoft Entra ID: After you delete a user, the account remains in a suspended state for 30 days. When this happens Entra ID sends update on the user to our SCIM API which sets "active" property on the user to "false".  For these users SCIM sets license to (No Selection) no matter what license is assigned by matching rules.
After 30 days user is deleted in Entra ID and it sends DELETE command to SCIM API. When this happens SCIM API executes NetServer's DeleteUser API.

Document Details
⚠ Do not edit this section. It is required for docs.superOffice.com ➟ Docs Team processing.

Content Source: user_provisioning

Commited update.


IoU results

Have you by any chance compared this to the original implementation with regards to the mean IoU?
If so, what implementation of IoU did you use and what were your results?

Sorry, I have not done that, mostly because it would be pretty useless without the context module.

Are you saying that purely because training of the context_module has not been implemented? In the original paper they still show that using the front end alone produces a mean IoU of 67.6% for the VOC-2012 dataset.

Ah thanks, I forgot that they also show results without the context module.

This is what I came up with to determine the confusion matrix, meanIOU and IOU.
def calculate_iou(y_pred_batch, y_true_batch):
    conf_m = np.zeros((20, 20), dtype=float)
    for i in range(len(y_true_batch)):
        flat_pred = np.ravel(y_pred_batch[i]).astype(int)
        flat_label = np.ravel(y_true_batch[i]).astype(int)
        for p, l in zip(flat_pred, flat_label):
            if l == 0:
                continue
            if l < 20 and p < 20:
                conf_m[l, p] += 1
    I = np.diag(conf_m)
    U = np.sum(conf_m, axis=0) + np.sum(conf_m, axis=1) - I
    IOU = I/U
    meanIOU = np.mean(IOU)
    return conf_m, IOU, meanIOU


[Feature Request] Search function in Schema Explorer

It's difficult to scroll and search for specific Graphql requests with the current Schema explorer. It would be great if there's a search function similar to Altair:

Duplicate of #1620


invalid association account in schema Project.Feature, associated schema Project.Account does not exist

I am using ecto many_to_many relationship for 2 tables Accounts and Features. It works on my dev  MacBook. However, when I push my code to circleci, it always complain invalid association ...,the associated schema does not exist while it works on my local machine. Then it failed with CompileError :Project.Account.struct/1 is undefined. I spent a few hours to figure out the issue but I am still stuck. Have anyone experienced this issue? Thanks,

Got it. Thanks.


Endpoint Updates

Back end updates incoming.. need to update the front end to match

There is a new properties.json file which we'll use to update the website without re-compiling.

https://github.com/FreeLoaderz/rwd-frontend/pull/77


Adding anchor link to list of documented links in the editor manual

Anchor links are another option included by Wagtail by default now ( I believe?) . I had some editors who were not aware of that, and noticed this missing from the docs.
Thanks for contributing to Wagtail! 🎉
Before submitting, please review the contributor guidelines https://docs.wagtail.io/en/latest/contributing/index.html and check the following:

Do the tests still pass? (https://docs.wagtail.io/en/latest/contributing/developing.html#testing)
Does the code comply with the style guide? (Run make lint from the Wagtail root)
For Python changes: Have you added tests to cover the new/fixed behaviour?
For front-end changes: Did you test on all of Wagtail’s supported environments?

Please list the exact browser and operating system versions you tested.
Please list which assistive technologies you tested.

For new features: Has the documentation been updated accordingly?

Thank you @easherma-truth! Good to keep this up to date.


fix(curriculum): external comma external link in CIP

Checklist:

[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 main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

127 in #40749
Sorry Jeremy, I should have added waiting update label, or took minute to update the challenge

I don't understand why we are changing the instructions here so significantly. It is straying from the original rosetta challenge quite a bit.

@moT01 Oh, I changed it, because they were similar to this https://rosettacode.org/wiki/Comma_quibbling.
But this doesn't change that I missed the original intent, if it's possible to elaborate more, because I am still missing it.😅

I changed it because they were similar to this https://rosettacode.org/wiki/Comma_quibbling

I still don't understand, these challenges are supposed to be taken from those rosetta challenges. Is it cause of license/copywriting? So you're thinking that we can't copy it directly like that because of licensing? That may be the case, I'm not sure.

They are under https://www.gnu.org/licenses/old-licenses/fdl-1.2.html
Got it from https://rosettacode.org/wiki/Rosetta_Code:Privacy_policy
So I AM worried for nothing I revert back them? Should I keep the variables names?

I would have preferred to keep the original, as it aligns with what's on the rosetta site.

The issue is to remove external links - I would have only changed line 11

You are right, I will open another issue later with better alternative.

I still don't get why we are changing this up

I had difficultiy understanding it, and it didn't feel fair because it wasn't the logic that I didn't understand but the wording itself.

Some other reviewers didn't seem to have a problem with it so I am going to defer to them to finish reviewing this.

there is no reason to defer, if I have issue with the wording and how it's unfair for the logic, I should open new issue. instead of taking people time and attention from the original issue.


Material design icons - integration

Version History
Version 1

initial pull request used as a RFC

Version 2

Brake open the relavent pieces in comparison to version 1.
Since this is already in the developmant branch, this one did rebase the commits. It should help to ease the review.

Version 3

incorporate a python script to generate all glyphs and corresponding static consts from a  baseline.css.
all icons are now available
update the code to make use of all available Material-Icons font names
update the core widgets code to reference correct font and glyph constant
update example widgets code to make use of new material-icons-font
cleanup the documentation part

Material Design Icons
Since the Google Code doesen't see any updates anymore, the is this OS Github project, that has taken over and improved quite a bit. Beside the woff2 support, they also cleaned up the other font variants.
While digging into it, i did realize, that the usage of icon fonts in general is depreciated in a longer run. All major platforms are now support SVG's much better over the last years. So we might be able to just rely on SVG-Icons.
Nevertheless, having an up to date icon font available will be handy inside the Toolkit.
Glyph Integration
The new Glyphs are are coded as codepoints, and not as single characters. These codepoints are common inside the ttf and the woff2 variants. As a consequence just one rust mapping code is needed. More documentation is placed inside the source code. You can view the Glyphs and its parameters quite nicely with FontForge.
Testing
To verify the correct handling, example source of 'widgets.rs' has been updated to use the new font and new Glyphs. API code for the core "check_box" and "combo_box" widgets have been adopted as well. The code-base compiles it without errors. Glyphs are rendered as expected.
best regards
Ralf

I've added the base line wof font to the window_adapter (api crate). And used one of the base line glyphs. Unfortunately the icon is not displayed. The current backend that is used to diplay font glpyhs is RustType https://crates.io/crates/rusttype. I checked it and apparently it supports only ttf and otf 🙈. We need RustType because it also supports Redox.

I don't know, if it is worth a try to ask for woff2 integration in rusttype.

russtype has now a successor project but it does also not include woff2.
SVG rendering should be possible but I have experiment with it in OrbTk. I think it could be a great alternative for the icon fonts.

SVG rendering should be possible

Fine. Let me know, if i can help on that. Right now i need to conentrate an the app ....

Hey,
this PR is continued with commits incorporting icons for Letter "B" and "C". will contiune with the next letters if time and courage will let me go ....

Here are
the continued Glyphs commits incorporating icons for Letter "D" and "E". will contiune with the next letters if time and courage will let me go ....

Update Version 3
michal w. sieron<EMAIL_ADDRESS>took over the final job. He wrote a python script (gist url in source),
that is taking fonts baseline.css and generates the needed const variable beside the rust readable uni-codes.
Usage
Since the glyphs have the same codepoints in all 'Material _Icons' fonts, we don't need seperate source files to describe the variants. Commit 6535191 is taking care to clean up the code base.
To use the varients/different look in orbtk, just adjust the font name. The const (MD_<icon_name>) will be the same.

@rzerres is there a file missing? material_icons_font.rs?

@FloVanGH sometimes it is git magic. Don't know, why the file was missing. I could see it in my local branch so ...

Thank you!!!


[windows] - Fix permissions for GetProcessMemoryInfo

As per https://learn.microsoft.com/en-us/windows/win32/api/psapi/nf-psapi-getprocessmemoryinfo, GetProcessMemoryInfo doesn't need windows.PROCESS_VM_READ. Hence, remove it and only use windows.PROCESS_QUERY_LIMITED_INFORMATION

@andrewkroh I'll open a follow-up PR to fix CI for this repo.

@andrewkroh CI looks good, can you please take a look when you have moment (and possibly merge it if looks good 😅)?


ssh keys backup refactor

see #2818 & # #2819 - merged for final testing
TODO: create a v1.7.1 Blitz - then insert a RC1 sd card and check if same SSHd key (no changes keys warning) and backup and conversion worked correctly (already before starting setup)

having an issue with the ssh connection during a failed setup:
if the disk fails to mount (due to hardware issues) the raspiblitz restarts automatically and the ssh service fails to start afterwards.

thanks, the above is fixed in e66848a

Had a tough time on Ambian (Odroid HC2) after recovering my old disk:
Permission denied (publickey).

It did not get solved when placed the ssh.reset file in the /boot/ dir on the sdcard.
The only way to get in was to create a file on the SDcard at /home/admin/.ssh/authorized.keys and paste my laptop's ssh pubkey to it.
It was still asking for password A so there are some quite tough default values on the ssh server.
Would like to find out how to improve this, but until then this is a note for other Armbian users.

@openoms If I check on the sdcard image rc1d with bullseye the /etc/ssh/sshd_config there is no entry for AuthenticationMethod
Should we set it explicitly? Or what are the measures to take here?

@openoms this is one of the last things to address before building a new RC - whats the best direction here from your perspective?

I think the problem is that if key-auth only was set the setting file is restored, but the .ssh/authorized_keys directory is not.
Should use cp -ra instead of just cp -a in the backup and restore function.


[5.1] Drastically reduce overhead in Blade comment matching

See #12505
Prior to this change, a capture group was being created for every single character in the comment.
For any comments over 1024 characters (not uncommon when commenting out a chunk of markup), PHP 7 would fail to match the regex due to hitting a JIT stack limit, causing the entire template to render as an empty string.
Adding the s modifier tells the regex engine to include newline characters when matching the dot character and allows us to remove the inner capture group. This drastically reduces the amount of memory the regex uses and keeps it well within the JIT stack limit for typical uses.
This increases the limit for comment length up to approximately 1 million characters, instead 1024.

:+1:

:+1:

btw, non-capturing groups exist, e.g. (?:.|\s) – though, your solution is much better.

the line numbers seem to always be off by a couple anyway, if you're trying to match up the view with its compiled version.


new buffer() is deprecated

new buffer() is deprecated.
Any plan to fix it??
thank you!!!

updated in v0.7.0


Refresh token when signing into Microsoft account?

Like the access token (https://github.com/firebase/firebase-ios-sdk/issues/3076), is it possible to get the OAuth refresh token when signing into a Microsoft account using Firebase Auth? Thanks,
Chris.

Ok, forget it! :). Digging around I see that property on FIRUser.

I just did an update to all my FB pods.
Is this accessToken not in the authResult anymore?
I can's seem to find the newly exposed token in the authResult or user (Auth.auth().currentUser)


If a malformed setup/settings_user.json is passed, no settings are loaded in the database creation

Check the integrity of setup/settings.json and setup/settings_user.json and, if setup/settings_user.json is invalid or nonexistent, load the settings only with setup/settings.json and throw a warning. If setup/settings_user.json is invalid, throw an error.

Resolved!

Resolved!


I've already generated the local condition for each phoneme, but it doesn't work for training.

Hi, all. I already extracted the linguistic features from the text, and the log F0 from extraction tools.
Then I made the discrete features to be one-hot features(like the current phoneme, the previous phoneme etc.), and compressed log F0 to [0 , 1].
And concatenate the discrete features and continuous features as the final local condition feature vector. The dimension is 1000+.
My question is how to use this feature vector?
I tried to concatenate the each sampling point level (256 one-hot vector) and the local condition feature vector as the input vector for each training sampling point, but it didn't work.
Anyone can provide some ideas? Thanks

Concatenation of 1k+ conditioning features with 256 quantisation classes is not likely to work. What did you use for alignment and extracting the linguistic features? If https://github.com/CSTR-Edinburgh/merlin, you might want to use a reduced question set to get smaller conditioning vectors.
For local conditioning in WaveNet, you could try to:

Embed the conditioning stream to something lower dimensional (optional)
Upsample from frame rate to sample rate
In each dilation module, multiply with a weight matrix and add the conditioning to the streams going into tanh and sigmoid

For figures, see the appendix of https://arxiv.org/pdf/1702.07825.pdf

@ljuvela Thanks for your reply. In classical text to speech processing, I usually train F0 and LSP CDHMM model for each state of phoneme with context, and use the minimum description length algorithm to build the decision tree to cluster the thousands of HMM models. Question sets can be used for splitting tree. So the linguistic features are all from the the question sets, phonemes and prosodies. For example, there are 126 kinds of phonemes for Chinese, so the current phoneme needs 126 one-hot vector to represent it, and the previous and next one also need 126, it cause the dimension is  1k+. I'm trying to use the linguistic features in a different way, thank you again.


xtl dependency has required nlohmann json dependency

The xtl dependency has required nlohmann json dependency which is not mentioned in the documentation. Could you please update docs on how to build xtensor from source? It used to be very simple and now with dependencies it's cumbersome. Thank you!

@yury-kh the nlohmann_json is not a required dependency. A warning is displayed if it is not installed when running cmake.

@SylvainCorlay, thank you, I see this now. Will close the issue then.

Don't hesitate to hop on the gitter chat if you have any question!
Cheers


run command via ssh slow.

My simple task - actual called pwd - takes 10-14 seconds.
if i chain them with && it takes 2-3 seconds.
Anyone experienced the same problem?
Composer.json
{
  "require-dev": {
    "deployer/deployer": "^6.7",
    "deployer/recipes": "^6.2"
  }
}

Steps to reproduce:
// Configuration
set('ssh_type', 'native');
set('ssh_multiplexing', true);
set('writable_mode', 'chmod');

task('pwd', function () {
    $start = microtime(true);
    run('cd xxxxx');
    run('touch test123');
    $result = run('pwd');
    writeln("Current dir: $result");
    writeln(microtime(true) - $start);
});

@antonmedv why you closed my issue?

Nope.


Unable to resolve module ./Text

Describe the bug
A clear and concise description of what the bug is.
i guess Text was removed
To Reproduce
Steps to reproduce the behavior:

install galio-framework
run your app
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):

Device: [e.g. iPhone 6]
Type of device: [e.g physical/simulator]
OS: [e.g. iOS8.1]
React-Native version: [e.g. 0.57]
Expo version: [e.g. 2.9.0]

Additional context
Add any other context about the problem here.

@william-levi it has been fixed in the 0.7.1 release...kindly check it out...


Add a persistent API for adding additional known keywords to those where subresources are searched

I.e. someone will want to write some new Specification where there's an additional foo keyword with subschemas in its values, and therefore it'd be nice to offer referencing.jsonschema.DRAFT202012.subresources_of + "foo" as a way to get "all the draft 2020 behavior plus this new extra keyword".

I wrote this twice apparently, will keep #24 as it contains an extra note about specifications_with.


ci: add doc test for stable & nightly

Pull Request Test Coverage Report for Build 3997
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 80.36%

Totals

Change from base Build 3995:
0.0%

Covered Lines:
4370

Relevant Lines:
5438

💛  - Coveralls


[release-1.11] Update ConsumerGroup status on finalization for better error reporting (#3415)

Cherry-pick of #3415

/cherry-pick release-1.10


Refuses to connect to android devices

I find this project somewhat amazing – there are at least three sets of instructions, all different:

https://thanhle.me/make-raspberry-pi3-as-an-emulator-bluetooth-keyboard/, this contains a link to this project as part of the code.
The README for this project.
https://thanhle.me/emulate-bluetooth-mouse-with-raspberry-pi/

The name of the project has also been changed, fortunately Github works around that. After entering tmux a, I find there are only three panes, so there's nothing to use to run bluetoothctl. It's possible that there's another session that I haven't worked out how to connect to.
So after splitting one of the panes to get a bluetoothctl session, I can get all the parts working. However, both android devices I have tested can see the ThanhLe_Keyboard_Mouse device, and to manage to get paired with it, but they won't connect. The bluetoothctl output shows them connect and then immediately disconnect. I have no idea why and no idea how to find out.
I only investigated using a Raspberry Pi 3 as a bluetooth keyboard because I've got one, and a spare keyboard and a user raised the idea of keyboard shortcuts for my android Editor app. I found that most of the implementations online can't possibly work because the BlueZ project made fundamental changes to the API that, AFAICS, make certain that any previous projects won't work.
I found that it does work with a Windows desktop
So, having wasted about a day attempting to get this to work on android, I have given up.

Sorry for you feeling, since things change day by day, so the video was not get updated. When I have time I will remake it. Now we dont need bluetoothctl any more. Did you try to reboot raspberry after install ?


Use Firestore struct tags for field mapping

The Firestore client can use a firestore struct tag to map between Firestore documents and Go structs. We should use it!
For example, this is (now) how we map the Recurser struct (just like the standard library's json tag):
type Recurser struct {
	ID                 int64           `firestore:"id"`
	Name               string          `firestore:"name"`
	Email              string          `firestore:"email"`
	IsSkippingTomorrow bool            `firestore:"isSkippingTomorrow"`
	Schedule           map[string]bool `firestore:"schedule"`
	CurrentlyAtRC      bool            `firestore:"currentlyAtRC"`

	// IsSubscribed really means "already had an entry in the database".
	// It is not written to or read from the Firestore document.
	IsSubscribed bool `firestore:"-"`
}

Relevant docs:

DocumentSnapshot.DataTo
DocumentRef.Create

Tasks
These are the structs that form our interface to Firestore:

[x] FirestoreRecurserDB: #81
[x] FirestoreAPIAuthDB: #82
[ ] FirestorePairingsDB: TODO
[x] FirestoreReviewDB: #93

I think this refactor is a great first task for someone looking to get starting working on Pairing Bot. It should be possible to copy-paste from existing code and get quite far. And I would be also be glad to help out at any point (maybe even pair on it :wink:)!
Let me know (here or elsewhere) if you'd like to claim a struct :slightly_smiling_face:

Was this supposed to be closed? The PairingsDB refactor is still mentioned in the checklist, and I'd like to work on it

Was this supposed to be closed? The PairingsDB refactor is still mentioned in the checklist, and I'd like to work on it

Good catch, thanks! And extra thanks for taking on PairingsDB!

Thanks @pjg11 for finishing this up!


Include quotes

I think it'll be great if we can display a motivational quote at each new tab. We can start start by adding a quotes.txt file which would contain about 50 quotes. This is because I think we should keep DarkSite an offline extension.  Once we have the file ready, we can randomly read a quote from it and display it on the page. It should be ensured that a new quote is read every time the user opens a new tab.
To claim this issue, please mention the source from where you will be using the quotes.

Hi @sudo-rgorai , I am willing to work on this issue. Please assign it to me.
I will use this source : https://instagramcircus.com/positive-quotes-captions-phrases/

Hey @vinaysrivastava273. Go ahead. The quotes look good.


Add speed testing for writing recordings

Motivation
Hidden behind some recent changes to control over electrical series writing of RecordingExtractor objects (and some future DataChunking changes as well) was an assumed speed increase. This adds a conversion tool that anyone can use to confirm it, but more usefully returns the estimated amount of time the entire conversion will take - which is nice to have for hefty conversions that can take on the order of hours.
How to test the behavior?
Basic tests for the function have been added to ensure it runs without error, but truly useful information would come from more extensive local testing that I don't want to force the CI to do every single push.
Here's an all-encompassing code block that tests the speed differences of some of the recent changes.
import numpy as np

from spikeextractors import NumpyRecordingExtractor
from nwb_conversion_tools.utils.conversion_tools import estimate_recording_conversion_time

num_channels = 384
sampling_frequency = 30000
num_frames = sampling_frequency * 5
timeseries = np.random.randint(low=-32768, high=32767, size=[num_channels, num_frames], dtype=np.dtype("int16"))
recording = NumpyRecordingExtractor(timeseries=timeseries, sampling_frequency=sampling_frequency)

_, estimated_write_speed = estimate_recording_conversion_time(recording=recording)
_, estimated_write_speed_no_iter = estimate_recording_conversion_time(
    recording=recording,
    write_kwargs=dict(iterate=False)
)
_, estimated_write_speed_no_comp = estimate_recording_conversion_time(
    recording=recording,
    write_kwargs=dict(compression=None)
)
_, estimated_write_speed_no_iter_or_comp = estimate_recording_conversion_time(
    recording=recording,
    write_kwargs=dict(iterate=False, compression=None)
)

which reveals, on my own system, the following differences:

Basic: ~4.7 MB/s
No iteration: ~39 MB/s
No compression: ~58 MB/s
No compression or iteration: ~105 MB/s

Checklist

[X] Have you checked our Contributing document?
[X] Have you ensured the PR description clearly describes the problem and solutions?
[X] Have you checked to ensure that there aren't other open or previously closed Pull Requests for the same change?

Just leaving this here for relative benchmarking - for actual SpikeGLX data (memmapable), I see the following speeds with the old DataChunkIterator

Basic: ~62 MB/s
No iteration: ~76 MB/s
No compression: ~109 MB/s
No compression or iteration: ~142 MB/s


Typescript language server died 5 times in June 2020 version

Log of the bug below
Issue Type: Bug
[Info  - 01:00:39.510] Starting TS Server
[Info  - 01:00:39.510] Using tsserver from: /Users/ythakker/Documents/GitHub/philosoraptor/node_modules/typescript/lib
[Info  - 01:00:39.512] <syntax> Forking...
[Info  - 01:00:39.515] <syntax> Starting...
[Info  - 01:00:39.517] <semantic> Forking...
[Info  - 01:00:39.520] <semantic> Starting...
[Error  - 01:00:39.873] TSServer exited with code: 1
[Info  - 01:00:39.874] Starting TS Server
[Info  - 01:00:39.874] Using tsserver from: /Users/ythakker/Documents/GitHub/philosoraptor/node_modules/typescript/lib
[Info  - 01:00:39.874] <syntax> Forking...
[Info  - 01:00:39.877] <syntax> Starting...
[Info  - 01:00:39.877] <semantic> Forking...
[Info  - 01:00:39.880] <semantic> Starting...
[Error  - 01:00:40.129] TSServer exited with code: 1
[Info  - 01:00:40.129] Starting TS Server
[Info  - 01:00:40.129] Using tsserver from: /Users/ythakker/Documents/GitHub/philosoraptor/node_modules/typescript/lib
[Info  - 01:00:40.129] <syntax> Forking...
[Info  - 01:00:40.132] <syntax> Starting...
[Info  - 01:00:40.133] <semantic> Forking...
[Info  - 01:00:40.135] <semantic> Starting...
[Error  - 01:00:40.374] TSServer exited with code: 1
[Info  - 01:00:40.374] Starting TS Server
[Info  - 01:00:40.374] Using tsserver from: /Users/ythakker/Documents/GitHub/philosoraptor/node_modules/typescript/lib
[Info  - 01:00:40.374] <syntax> Forking...
[Info  - 01:00:40.377] <syntax> Starting...
[Info  - 01:00:40.377] <semantic> Forking...
[Info  - 01:00:40.380] <semantic> Starting...
[Error  - 01:00:40.623] TSServer exited with code: 1
[Info  - 01:00:40.623] Starting TS Server
[Info  - 01:00:40.623] Using tsserver from: /Users/ythakker/Documents/GitHub/philosoraptor/node_modules/typescript/lib
[Info  - 01:00:40.623] <syntax> Forking...
[Info  - 01:00:40.626] <syntax> Starting...
[Info  - 01:00:40.627] <semantic> Forking...
[Info  - 01:00:40.629] <semantic> Starting...
[Error  - 01:00:40.866] TSServer exited with code: 1
[Info  - 01:00:40.866] Starting TS Server
[Info  - 01:00:40.866] Using tsserver from: /Users/ythakker/Documents/GitHub/philosoraptor/node_modules/typescript/lib
[Info  - 01:00:40.866] <syntax> Forking...
[Info  - 01:00:40.869] <syntax> Starting...
[Info  - 01:00:40.870] <semantic> Forking...
[Info  - 01:00:40.872] <semantic> Starting...
[Error  - 01:00:41.116] TSServer exited with code: 1

VS Code version: Code 1.47.2 (17299e413d5590b14ab0340ea477cdd86ff13daf, 2020-07-15T18:18:50.054Z)
OS version: Darwin x64 19.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz (6 x 3000)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
8.00GB (0.28GB free)

Process Argv
.

Screen Reader
no

VM
0%

Extensions (18)

Extension
Author (truncated)
Version

better-comments
aar
2.1.0

color-info
bie
0.5.1

npm-intellisense
chr
1.3.0

path-intellisense
chr
2.2.1

vsc-material-theme
Equ
32.8.0

vsc-material-theme-icons
equ
1.2.0

Angular2
joh
9.1.2

vscode-styled-components
jpo
0.0.29

vscode-scss
mrm
0.9.0

python
ms-
2020.7.96456

color-highlight
nau
2.3.0

material-icon-theme
PKi
4.2.0

vscode-graphql
Pri
0.2.14

vscode-yaml
red
0.9.1

sass-indented
rob
1.5.1

mdx
sil
0.1.0

autoimport
ste
1.5.3

vscode-mdx-preview
xyc
0.3.0

(14 theme extensions excluded)

Does this reproduce in the latest VS Code insiders build with all extensions disabled?

Also, it looks like you are using a local TypeScript version. Which TypeScript version do you have locally? Has it been modified in any ways, such as by yarn 2?


Ibc coins

Support SendTx to other chains with addresses like test_chain_2/deadbeef
Add new basecoin relay command for relaying IBC packets between chains

The relayer could probably use more work as currently it just connects to one node from each chain. If that node goes down the relayer is stuck.

Okay, I see nothing fundamentally wrong with it. And it seems to work. And for demoing the functionality it is great. But if Basecoin wasn't already in such a sorry state, I would send it back for cleanup.
Here are some comments:
The loop in relay contains lots of untestable logic. It also creates keys for IBC queries, without using the functions in IBC.go which do the same.
In general there is way too much logic in the commands. Not just relay.
Also, relay is a client command, doesn't need to run on a full node.  I would move it to basecli. But next release.
There is no way to update validator sets. But that is a known limitation.
Design question:
If I send eg. BTC from peg1 and btc from peg2 to the hub, they both are stored as btc. And there is no way to distinguish them. Thus, I could send btc from peg1 to the hub and cash out on peg 2, and there would be no info that there is a net debt between peg1 and peg2. I think the source chain should be stored somehow.
Also, there is no control of issuing. I could attach a random chain to hub and issue 1000 btc and 5000 eth and they would be just as valid as a trusted peg zone.
In short, I think it works for a prototype and if that is clear along with no promise of backwards compatibility with this implementation, I would approve a merge.
We kept pushing back the design discussion of ibc at the retreat and I realize now how important it would have been. Oh well...

The loop in relay contains lots of untestable logic. It also creates keys for IBC queries, without using the functions in IBC.go which do the same.

In general there is way too much logic in the commands. Not just relay.

Agreed. Let's try and get more of this logic into the packages. This was just a first draft to get things working.

Also, relay is a client command, doesn't need to run on a full node. I would move it to basecli. But next release.

It doesnt need to run on a full node but it is a long running service like a full node, so I wouldn't put this in the basecli. I think the basecli should be for commands, not for starting processes. Correct me if I'm wrong.

If I send eg. BTC from peg1 and btc from peg2 to the hub, they both are stored as btc.

There should only be one peg to BTC, so this shouldn't be a problem.

Also, there is no control of issuing. I could attach a random chain to hub and issue 1000 btc and 5000 eth and they would be just as valid as a trusted peg zone.

Nah, the hub handles this. There's only one "source" zone for each currency, so zones can run amok minting coins. We haven't implemented this logic yet of course.

In short, I think it works for a prototype and if that is clear along with no promise of backwards compatibility with this implementation, I would approve a merge.

Cool. I think we should merge so we can get a testnet going with it. But we should also refactor and add tests :)

Thanks for the explanations.
We currently have an rpc proxy in basecli that came out of discussions with Jae and matt. It is a long running process that validates all rpc responses before forwarding them.
The relay is similar. Yes, we should find a place for that


Issue with launch.json args containing Ampersand character

VSCode Version: 1.30.1
OS Version: Windows_NT ia32 6.1.7601

Steps to Reproduce:

Have your launch.json file look like this:

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "Debug Main Process",
			"type": "node",
			"request": "launch",
			"cwd": "${workspaceRoot}",
			"osx": {
				"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron"
			},
			"windows": {
				"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd"
			},
			"args": [
				"test://update?v=2&id=4&param=16",
				"arg2"
			],
			"program": "${workspaceRoot}/js/app/main/main.js",
			"protocol": "inspector"
		}
	]
}

On Windows (there is no issue on Mac), launch the app using VS Code and check the process.argv array.  The fourth parameter is "test://update?v=2", which is incorrect.  There is no fifth parameter (but there should be, and the value should be "arg2").  Anything past the first ampersand character is cut off, even the second argument of "arg2".

I've tried to use:

"test://update?v=2^&id=4^&param=16",
"\"test://update?v=2&id=4&param=16\"",
"\"test://update?v=2^&id=4^&param=16\"",

but I'm unable to get anything to work.  Is there a way to pass command line arguments containing ampersand characters on Windows?

This issue also happens with the # character

Does it make a difference if you configure your launch config to use VS Code's integrated terminal, by adding a "console": "integratedTerminal"?

Does it make a difference if you configure your launch config to use VS Code's integrated terminal, by adding a "console": "integratedTerminal"?

I have the same issue, and integratedTerminal does not help - I was already using it to work around an earlier debugger attach issue. For the time being I'm just hardcoding the args in the program under test.

I realize that this issue is about a node script, but I had the same problem with python and I found this bug report for the python extension: https://github.com/microsoft/vscode-python/issues/8432. The diagnosis in that ticket was that the URL needs to be enclosed in quotes or escaped properly. I'm thinking that actually that was the problem here, too.
I can't tell if @weinand actually inspected the argument passed into his node script or just looked at the command that was executed. For my python script, the full URL was indeed part of the command Visual Studio Code executed, but everything after the ampersand was missing inside python.
Like @BryanWallin, I could not find a work around.

Work around for URLs: use semicolons instead of ampersands as the separator.


number of installed packages not taken into account on ArchLinux

Hi,
Since version 5.1 of pacman (early June), Neofetch (verison 4.0.2-1) no longer lists installed packages.
The problem does not arise with Screenfetch which uses the variable
pacman -Qq | wc -l
to list the total number of installed packages.
Is that a known bug??
This is related to the new version of pacman because with pacman 5.0, the problem disappears.
I purged and reinstalled neofetch but no change.
By downgrading pacman to 5.0, neofetch lists the installed packages again.
And there's also a bug with Optimus technology.
For graphics cards, only the Intel chipset is taken into account.
But the Nvidia isn't.
It is replaced by the Ethernet card...
As you can see on the screenshot.

For your information, I use ArchLinux Cinnamon.
Thank you.
cheers.

Fixed in master already, a new release will be made soon.

Open a new issue for the GPU 👍


Updating Readme file

I would like to work on this issue. Please assign this to me under LGM SOC.

Can I work on this issue?

I made this logo for the website.

please include this in readme file.


feat: ownable sysstia

Please read contributing guidelines and remove this line.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#9399
#9398  👈
#9328
#9297
#9296
#9247
#9246
#9084
#8942
#8941
#8940
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @LHerskind and the rest of your teammates on  Graphite


Compilatior error

Hi, I'm trying to compile the library, but I got stuck in this step.
DO you have any clue to solve this? is the cuda version? have you experienced something similar?
[ 90%] Linking CXX shared library libcpu_bbs3d.so
[ 90%] Built target cpu_bbs3d

/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not expanded with ‘...’:
  435 |         function(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:435:145: note:         ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not expanded with ‘...’:
  530 |         operator=(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:530:146: note:         ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not expanded with ‘...’:
  435 |         function(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:435:145: note:         ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not expanded with ‘...’:
  530 |         operator=(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:530:146: note:         ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not expanded with ‘...’:
  435 |         function(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:435:145: note:         ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not expanded with ‘...’:
  530 |         operator=(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:530:146: note:         ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not expanded with ‘...’:
  435 |         function(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:435:145: note:         ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not expanded with ‘...’:
  530 |         operator=(_Functor&& __f)
      |                                                                                ^
/usr/include/c++/11/bits/std_function.h:530:146: note:         ‘_ArgTypes’
CMake Error at gpu_bbs3d_generated_calc_score.cu.o.Release.cmake:280 (message):
  Error generating file
  /ws/3d_bbs/build/CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/./gpu_bbs3d_generated_calc_score.cu.o

make[2]: *** [CMakeFiles/gpu_bbs3d.dir/build.make:84: CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/gpu_bbs3d_generated_calc_score.cu.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CMake Error at gpu_bbs3d_generated_voxelmaps_io.cu.o.Release.cmake:280 (message):
  Error generating file
  /ws/3d_bbs/build/CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/./gpu_bbs3d_generated_voxelmaps_io.cu.o

make[2]: *** [CMakeFiles/gpu_bbs3d.dir/build.make:105: CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/gpu_bbs3d_generated_voxelmaps_io.cu.o] Error 1
CMake Error at gpu_bbs3d_generated_voxelmaps.cu.o.Release.cmake:280 (message):
  Error generating file
  /ws/3d_bbs/build/CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/./gpu_bbs3d_generated_voxelmaps.cu.o

make[2]: *** [CMakeFiles/gpu_bbs3d.dir/build.make:91: CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/gpu_bbs3d_generated_voxelmaps.cu.o] Error 1
CMake Error at gpu_bbs3d_generated_bbs3d.cu.o.Release.cmake:280 (message):
  Error generating file
  /ws/3d_bbs/build/CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/./gpu_bbs3d_generated_bbs3d.cu.o

make[2]: *** [CMakeFiles/gpu_bbs3d.dir/build.make:77: CMakeFiles/gpu_bbs3d.dir/bbs3d/src/gpu_bbs3d/gpu_bbs3d_generated_bbs3d.cu.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:110: CMakeFiles/gpu_bbs3d.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

My device：
Ubuntu 20.04
eigen 3.4.0
pcl 1.12
cmake 3.29.3
cuda 11.5
cudnn 8.4.1

Hi! Thank you for trying 3D-BBS.
I think cuda version affects the build of cuda
Could you update cuda version to 12.0 or more?
According to the claude3.5, changing c++  version in CMakeLists.txt is also effective.
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

Can confirm that the cuda version was the culprit. Thanks


Add client to builder

This PR gives user the possibility to provide their own client to use (Client<HttpsConnector<hyper::client::HttpConnector>>).
Note that this PR includes commit af3bafbca26fc3871af8e0f39728ccbdc141ca64 added in PR #18.
I need to provide my own client so that can modify TLS/SSL options. I need to:

Trust a specific self-signed certificate: The REST server (not under my control) is using a self-signed certificate. I need to be able to trust this one from the code (not from the OS).
I connect to the server through its IP, not through its hostname, which requires another option to the TLS config (since the certificate is self-signed for the hostname, not the ip)

Here's how I setup my client so that it accepts the self-signed certificate:
let dns_workers = 4;
let mut http = hyper::client::HttpConnector::new(dns_workers);
http.enforce_http(false);

let mut tls_connector_builder = native_tls::TlsConnector::builder();

// Read the certificate to a slice of bytes
const SELF_SIGNED_CERT: &[u8] = include_bytes!("/path/to/certificate.crt");

// Create a `native_tls::Certificate`
let certificate = native_tls::Certificate::from_pem(SELF_SIGNED_CERT).unwrap();

// Adds the certificate to the set of roots that the connector will trust.
// See https://docs.rs/native-tls/0.2.2/native_tls/struct.TlsConnectorBuilder.html#method.add_root_certificate
tls_connector_builder.add_root_certificate(certificate);

// Disable host name verification
// See https://docs.rs/native-tls/0.2.2/native_tls/struct.TlsConnectorBuilder.html#method.danger_accept_invalid_hostnames
tls_connector_builder.danger_accept_invalid_hostnames(true);

// // Accept all certificates, even if invalid
// // See https://docs.rs/native-tls/0.2.2/native_tls/struct.TlsConnectorBuilder.html#method.danger_accept_invalid_certs
// tls_connector_builder.danger_accept_invalid_certs(true);

let tls_connector = tls_connector_builder.build().unwrap();
let https = hyper_tls::HttpsConnector::<hyper::client::HttpConnector>::from((http, tls_connector));

// Build the hyper client
let client = hyper::Client::builder().build(https);

// Build the restson::Client
let client = restson::Builder::default()
    .send_null_body(false)
    .with_client(client)
    .timeout(std::time::Duration::from_secs(5))
    .build(server.as_ref())?;

Dependencies:
hyper = "^0.12.14"
hyper-tls = "^0.3.1"
native-tls = "^0.2"

The changes look solid. While I'm not a big fan of the idea that internal implementation details are exposed to the public API (Hyper client), being able to work with self-signed certificates is a valid use case. The alternative approach would probably be to duplicate the necessary hyper and native-tls interfaces to Builder. From these two, I do prefer the approach you have selected. Furthermore, providing special functionality through the Builder does not affect the basic usage which should be easy-to-use.


[Feature Request] Add color config to project

What kind of request is this (question/bug/enhancement/feature request):
feature request
Feature Request

Add a color config to project
Project should be highlighted with its color when switched to

Request Reason

Test and production are different project
Sometimes users operate in wrong project by mistake
A highlighted color is useful to avoid this mistake
Software NoSQL Booster have this feature, and it's very useful (as below)

Duplicate of https://github.com/rancher/rancher/issues/15838


kani: fix Amount overflow test

Our Kani CI job is currently failing. See https://github.com/rust-bitcoin/rust-bitcoin/actions/runs/7770495422/job/21190756253
This fixes one of the issues; the other is that we're hitting a multiplication assertion in the test we added in https://github.com/rust-bitcoin/rust-bitcoin/pull/2393 which I'm unsure how to deal with.
For reference, testing this was a bit of a PITA. I needed to
# Ok, these steps are easy/obvious
cargo install kani-verifier
cargo kani

This will give you an error located in core/panic.rs or something with the description This is a placeholder message; Kani doesn't support message formatted at runtime which is not super helpful. To get the actual failure, you need to write
cargo kani --enable-unstable --concrete-playback=inplace

which will add a weird unit test which calls into Kani to exercise the original test with a specific input value. Because it calls into Kani you can't just run it with cargo test. You need to run
RUST_BACKTRACE=1 CARGO_INCREMENTAL=0 cargo kani playback -Z concrete-playback -- kani_concrete_playback_check_div_rem_8626518785677487871

where CARGO_INCREMENTAL=0 disables incremental compilation (this was causing rustc to flame out with a "filename too long" error because it was trying to create some intermediate file with multiple hashes and crate names in it), and the kani_concrete_playback_123456789 thing is the name of the test that gets added (which you can easily find by reading git diff).

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 84.147%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
19326

Relevant Lines:
22967

💛  - Coveralls

I'm sorry, this did not actually fix the test. It is possible for kani to access both the true and the false variants and I need to reason about it more carefully.
There is also a "loop depth too high" issue which doesn't reproduce for me locally, but I haven't investigated that yet.
See https://github.com/rust-bitcoin/rust-bitcoin/actions/runs/7823167852/job/21343635156


Update getting-started.md

doc update :
Github codespace is in preview and can only be used by Microsoft Github organization member.
Customers won't be able to use it for this project.

Customers won't be able to use it for this project

Customers have to fork the repo to work on it anyway, so any customer forking this into a GitHub org should be able to use it.
I don't think we want to remove this tip. The link takes the reader to the relevant information and can help them determine If Codespaces is an option, or not.


kcc: init at 5.5.1

Motivation for this change
Added Kindle Comic Converter
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

Is wrapQtAppsHook necessary with mkDerivationWith?

I am getting a warning about missing kindlegen. Could you add that thing to PATH too?

Is wrapQtAppsHook necessary with mkDerivationWith?

It's not, that was my bad :(. Updated review.

Sorry for the mixed signals, didn't see the libsForQt5.callPackage when i first reviewed.
It's because I changed it from python3Packages.callPackage.

Thank you.


Is it possible to add a breakline

I was wondering if its possible to add a break line between the text and the link so the link would appear in a new line

No, this is not possible right now: https://github.com/kriskbx/whatsapp-sharing/issues/16

did it become possible ?


GMRES Fails Silently and Frequently from Stagnation

Description
jax.scipy.sparse.linalg.gmres often fails to converge when restart is less than the problem dimension, but will return without indicating failure. This happens in both batch and incremental mode (the below code only tests batch.)
This failure (likely due to stagnation) seems to depend on the absolute difference between the problem dimension and the Krylov subspace dimension (restart.) ie. roughly 90% of the time GMRES will fail silently on a problem of dimension 25 if restart = 20, and will still fail 90% of the time with a problem of dimension 100 and restart = 95. The failure rate jumps as high as 30% with even a 1 dimensional difference between the problem and Krylov subspace.
In addition to the dangerous silent failure, this has some major implications for the implementation of the algorithm as a whole. It implies 30% of the time an incremental solve with restart >= problem dim may require computing the Kyrlov subpsace all the way to problem_dim, and 90% of the time to within 5 dimensions of it.
Reproducing code:
import jax
import jax.numpy as jnp
import jax.random as jr
import jax.scipy as jsp

import random

def randomkey():
    return jr.PRNGKey(random.randint(0, 2**31 - 1))

# very loose tolerance
tol = 1
absolute_difference = (0, 1, 5)
problem_dims = (25, 100)
for dim in problem_dims:
    for excess_dim in absolute_difference:
        succeeded = 0
        # the failure rate is dependent upon the asbolute difference between
        # the dimension of the problem `dim` and the size of the Krylov subspace
        # `restart`. ie. the failure rate depends on `excess_dim` only.
        restart = dim - excess_dim
        for _ in range(100):
            # force an acceptable condition number. Lower condition numbers will exhibit
            # the same phenomenon.
            cond = jnp.inf
            while cond > 1000:
                matrix = jr.normal(randomkey(), (dim, dim))
                cond = jnp.linalg.cond(matrix)

            true_vector = jr.normal(randomkey(), (dim,))
            b = matrix @ true_vector

            gmres_jit = jax.jit(jsp.sparse.linalg.gmres, static_argnames="restart")
            jax_solution, info = gmres_jit(matrix, b, restart=restart)

            # info == 0 when jax.scipy believes there was no failure.
            assert jnp.all(info == 0.0)

            succeeded = succeeded + (
                jnp.sqrt(jnp.sum((jax_solution - true_vector) ** 2)) < tol
            )

        print(
            f"Number which succeeded for dim = {dim}"
            f" and restart = {restart}: {succeeded}"
        )
@RaderJason

What jax/jaxlib version are you using?
jax v0.4.6, jaxlib v0.4.6
Which accelerator(s) are you using?
CPU
Additional system info
python 3.10.9
NVIDIA GPU info
No response

So, there's a couple bits I've noticed here:

The floating point precision makes no difference for this issue.
Scipy also fails in the test above but detects this failure and reports it via info, but info in JAX doesn't return this information. This seems to have been brought up before https://github.com/google/jax/issues/7909 but info still only signals failure when the output is nan, meaning it doesn't capture this failure mode.
As an addition to 2., BiCGStab still doesn't have any info! It doesn't capture any failure mode. This could be (should be?) risen as its own, separate issue.
GMRES(k) has two big failure modes: breakdown and stagnation. For dense matrices as above, we will usually encounter a breakdown. Stagnation seems to be the more common issue in practice though. Theoretically, JAX's GMRES has a check for breakdown, but this check is v_norm_1 == 0, which we almost never hit in floating point arithmetic. Really this should be v_norm_1 < tol for an appropriate tolerance. (Also, breakdown will stop the loop but isn't reported anywhere.)
There is no check for stagnation. Admittedly, this is not standard and I haven't seen an autodifferentiable implementation of GMRES(k) which has a check for this. If the goal is to match Scipy, this could be omitted.

The goal is definitely to match SciPy. So if possible, it would be great to accurately report info! PRs to improve the situation would be gratefully accepted here.

For anyone coming across this issue: we recommend using Lineax instead.
This solves the various issues discussed here.


Improved Currency Precision

Today, the network assumes a certain precision when reading integer values of currency. OpenBazaar should allow each currency to be represented as an int with varying amounts of precision.
Considerations for BigInt representation (replace instances of json.Number in the Scope below with whatever solution we pick):

json.Number
https://github.com/shopspring/decimal

Scope
Protobuf Schema

create pb.CurrencyValue proto to track high-precision value of a currency

(smallest known precision is 1e-18)

proto CurrencyDefinition {
  string      code
  json.Number divisibility
}
proto CurrencyValue {
  CurrencyDefinition currency
  json.Number        value
}

restrict prior schema version to BTC, BCH, LTC, ZEC as accepted currencies for transactions (recommend creating non-proto type pb.Listing to manage version-specific marshal/unmarshal of JSON contracts and proper mapping of changing fields between current v4 and future v5 Listings.... Ex: pb.Listing.Price() can return a valid price regardless of source being v4 or v5.)
bump Listing to new schema v5

update pb.Listing.Metadata.Coin[Type|Divisibility] to use pb.CurrencyDefinition
update pb.ListingItem.Price to use pb.CurrencyValue
merge pb.Listing.Metadata.PricingCurrency with pb.Listing.ListingItem.Price into pb.CurrencyValue
in pb.Listing.BuyerOrder update pb.Order_Payment.Amount and pb.Order_Payment.Coin to use pb.CurrencyValue

replace ModeratorInfo.Price usage with pb.CurrencyValue
replace CoinType and pb.CoinDivisibility to use pb.CurrencyDefinition

update pb.ListingItem.Skus.Quantity to use json.Number (to support larger inventory requirements in CRYPTOLISTING listings)
update pb.Listing.BuyerOrder.RefundFee to use pb.CurrencyValue
in pb.Listing.BuyerOrder.Items collapse Quantity and Quantity64 ito json.Number

properly represent that < v2 schema expects Quantity and >= v3 requires Quantity64
>= v5 requires json.Number to support (now) larger inventory requirements for Cryptocurrency listings

in pb.Listing.BuyerOrder update Amount and Coin to use pb.CurrencyValue
update BuyerOrder schema version?
update pb.VendorOrderConfirmation.RequestedAmount to pb.CurrencyValue
update pb.VendorOrderFulfillment.Payout.PayoutFeePerByte to pb.CurrencyValue
update pb.Dispute.Outputs[].Value to pb.CurrencyValue
update pb.TransactionRecord.Value to pb.CurrencyValue
in pb.ShippingOption.Service update Price and AdditionalItemPrice  to pb.CurrencyValue
update pb.Coupon.PriceDiscount to pb.CurrencyValue

*Note: I know there is redundant data with the currency type being expressed in every place where a value is represented. This was done intentionally so that knowledge of implicit relationships between fields aren't required to make sense of the data. Denormalizing data here also doesn't hurt us as we can ensure the implicit relationships are intact more easily with tests and validations.

Other Data Models

Notifications

New Order Notification

in ListingPrice merge Amount, CurrencyCode, and CoinDivisibility into pb.CurrencyValue

Profile

ModeratorInfo needs to be migrated to use the new proto schema

does prior ModeratorInfo schema needs to be handled for other clients when selecting a Moderator who hasn't migrated?

SQLite data

cases

migrate buyerOutputs and vendorOutputs which contain serialized sets of values:   [{"hash":"85499ec9b053772fc9ce95b695de1aa1fe83ea7daf44cda52ab27aac13a679d6","value":386091}]

inventory

migrate count from type integer to text?

notifications

migrate serializedNotification to new model schema

purchases/sales (consider merging these into one table and add a type column to differentiate?)

migrate total from type integer to text?
migrate transactions which contain serialized sets of values: [{"Txid":"85499ec9b053772fc9ce95b695de1aa1fe83ea7daf44cda52ab27aac13a679d6","Index":0,"Value":386091,"Address":"prv2kgx6m8ynestdmvhlndm237hhqgr4yce9q0a090","Spent":true,"Timestamp":"2019-01-23T22:36:37.141428851-05:00"},{"Txid":"dde5a08c860faf7bd1b56d1528640fdbefd659ef798cfddb33e77b8b187fec4b","Index":0,"Value":-386091,"Address":"prv2kgx6m8ynestdmvhlndm237hhqgr4yce9q0a090","Spent":true,"Timestamp":"2019-01-23T22:50:58.659452463-05:00"},{"Txid":"dde5a08c860faf7bd1b56d1528640fdbefd659ef798cfddb33e77b8b187fec4b","Index":0,"Value":-386091,"Address":"prv2kgx6m8ynestdmvhlndm237hhqgr4yce9q0a090","Spent":false,"Timestamp":"2019-01-24T04:07:23.949652851Z"}]

stxos/txns/utxos (consider merging these into one table with a type differentiator?)

migrate value from integer to text?

API changes
The JSON representation of the pb.CurrencyValue type above should be used in place of int usages for amount. The typical transformation will look similar to the following other indicated otherwise:
A value of 0.12345678 BTC might be represented like this before:
{
    "data": "value",
    "amount": 12345678, // this key is inconsistent across calls
    "coin": "BTC", // this key is inconsistent across calls
    "otherdata": "othervalue"
}

This value would be represented in scientific notification using value for all significant digits and magnitude for the exponential. Thus 0.12345678 BTC, or 12345678e-8 BTC would be represented as:
{
    "data": "value",
    "amount": { // this key would match the replaced key in the BEFORE case
        "value": "12345678",
        "magnitude": -8,
        "currency": {
            "code": "BTC", // this key would always be `code`
            "divisibility": 8
        }
    },
    "otherdata": "othervalue"
}

POST /ob/purchase (POSTPurchase) response

wallet-interface changes
Note: Some objects (like pb.CurrencyValue and pb.CurrencyDefinition) will need to be defined within the interface's package. Recommend that ob-go abstracts the wallet-interface's version of these type with it's own to cast into as the value returns from a wallet-interface call. wallet.Type indicates a defined Type local to the package wallet.

create wallet.CurrencyValue and wallet.CurrencyDefinition which mirrors the data of the above protobufs
move CurrencyCode() string response into broader CurrencyDefinition() wallet.CurrencyDefinition
update IsDust(amount int64) bool to IsDust(amount wallet.CurrencyValue) bool
update Balance() (unconfirmed, confirmed int64) to Balance() (unconfirmed, confirmed wallet.CurrencyValue)
update ChainTip() (uint32, chainhash.Hash) to ChainTip() (uint64, chainhash.Hash) - Note: won't overflow until the year 4743 assuming 20-second ETH blocks which is our 'fastest' supported coin today, but would support even faster blocks in the future. None of the above scope considers a change of the ChainTip representation and must be scoped in addition to this.

update GetConfirmations(txid chainhash.Hash) (confirms, atHeight uint32, err error) to have same size uint as ChainTip
update TransactionCallback.Height to match type

update GetFeePerByte(feeLevel FeeLevel) uint64 to GetFeePerByte(feeLevel FeeLevel) wallet.CurrencyValue
update Spend(amount int64, addr btc.Address, feeLevel FeeLevel, referenceID string) (*chainhash.Hash, error) to use wallet.CurrencyValue
update EstimateFee([]TransactionInput, []TransactionOutput, feePerByte uint64) uint64 to EstimateFee([]TransactionInput, []TransactionOutput, feePerByte wallet.CurrencyValue) wallet.CurrencyValue
update EstimateSpendFee(amount int64, feeLevel FeeLevel) (uint64, error) to EstimateSpendFee(amount wallet.CurrencyValue, feeLevel FeeLevel) (wallet.CurrencyValue, error)
update CreateMultisigSignature(ins []TransactionInput, outs []TransactionOutput, key *hd.ExtendedKey, redeemScript []byte, feePerByte uint64) ([]Signature, error) to use wallet.CurrencyValue instead of uint64 on feePerByte
update Multisign(ins []TransactionInput, outs []TransactionOutput, sigs1 []Signature, sigs2 []Signature, redeemScript []byte, feePerByte uint64, broadcast bool) ([]byte, error) to use wallet.CurrencyValue instead of uint64 on feePerByte
change TransactionCallback

update Value to use wallet.CurrencyValue

update TransactionOutput.Value to use wallet.CurrencyValue
update TransactionRecord.Value to use wallet.CurrencyValue

wallet-interface dependencies

update each wallet implementation to support new wallet-interface changes

BTC
BCH
LTC
ZEC
ETH

auxiliary system dependencies

update inventory to support ETH precision (whenever we support ETH/ERC-20 cryptolisting trades) (scope?)
update search crawler/index (scope?)

After discussing the suggestion in private, @amangale is on board with the plan as originally described above. The primary points are outlined below:

Some thoughts after reviewing Ashwin's proposal:
(TL;DR)

Ashwin’s proposal doesn’t reduce scope much compared to the original plan of inlining divisibility within the contract. (See 3.)

The main delta appears to be rejecting the custom type in favor of big.Int and implicitly defined data. The difference between supporting big.Int and custom types:
Cons: Minor risk in implementing MarshalJSON and accessor functions. More complex structure.
Pros: A type which can answer IsValid() no matter what version it is. Access ambiguously defined data in the wire based on version without the consumer knowing how. Cleans up existing debt.

There are aspects of Ashwin's approach which does increase risk/tech debt. (See 1, 2)

Does not consider transient or legacy data support.
Requires a piecemeal logic in specific areas than something more holistic to the app's ecosystem

If we do the wallet-only fix first as we have suggested doing, Ashwin’s proposal causes bigger tech debt than just inlining the currency divisibility into the contract. (See 1.)

This proposal does not address in-flight contracts and our ability to support them. Providing a proper abstraction (repo.RicardianContract) which is version-aware and can be a place to hang validation/business-logic/etc is going to be needed sooner or later. If we avoid this abstraction, we're simply sprinkling copies of this logic throughout the codebase which we'll need to later reconcile (more debt).
I would personally prefer to see:
(repo.RicardianContract).contract.BuyerPayment().Definition.Divisibility or
(repo.RicardianContract).contract.BuyerPayment().Divisibility
than having this sprinkled across our codebase:
if contract.Metadata.Version > 5 {
  divisibility = wallet.GetWalletForCurrencyCode(coin).CoinDivisibility()
} else {
  divisibility = MagicDivisibilityIntThatIsNotLinkedToContractData
}

Considering this will be a two-step approach in which the first step allows ETH contracts containing "satoshi-wei" to be used on the network, there is no explicit divisibility data associated with the amounts to know the correct magnitude when we eventually implement full precision support in step two. Assuming we did this, in step two we'd need a new field with explicit divisibility or a different name with yet more logic in the server. It would seem that adding divisibility in the first place would be prudent.
And if we're already going down the path of including this explicit data, good engineering would be to properly represent this data instead of injecting string arguments throughout our interfaces and requiring the engineer to digest and understand the code body in order to understand what the "string" is. Beyond semantics, it's poor because  there's no place to hang your behavior specific to CurrencyValues without writing and creating helpers all over your code. This is not only debt, but it's high-interest.

Responses for your arguments of overkill for a wallet.CurrencyValue and wallet.CurrencyDefinition type:

Till the time that Openbazaar does intend to support multi coin contract with varying divisibility, the proposed solution adds a lot more complexity for little mileage.

I'll start here as it's most important. I'm not sure what complexity we're avoiding in your proposal. The only main delta that I can see (forgive me if I'm wrong here as it was hard to compare them) is that you rejected the custom type usage in favor of a string representation throughout the app. All of the same data points are being touched to change the type to a more basic representation (to use big.Int with implicit data instead of a descriptive type). Objectively, the only added complexity I see is writing MarshalJSON for the Currency* types and accessor methods.

The coin does not change for a contract
Like the coin, there is no change in the divisibility of a coin in the contract.

If you're suggesting that one expression of the coin metadata is enough for an entire contract, I disagree. When we describe a Cryptocurrency Listing, the coin can be represented as a product of purchase as well as a means of payment. This necessitates independant representation of these values. If we're expressing the same data in both places, a consistant representation of the data would be preferred.
Here's an example listing:
{
	"vendorListings": [{
		"slug": "bch-eth",
		"vendorID": {
			"peerID": "QmbweQKGWNqjoPqBjePVqnTCrFsK62oWYeVe8WeqXwwyS8",
			"handle": "",
			"pubkeys": {
				"identity": "CAESIM8hU+iL8iGmlzAIMI1OGqRMWXRwNGcbW8nXOZh0eurL",
				"bitcoin": "A/n06c7eeuBo9/mWLgXQGacFI7+gnAXBlLkquCfv0srk"
			},
			"bitcoinSig": "MEUCIQCftGYX8xF+oGEZ+scMqvEasqLvh0JQ92KO81ZNg3bfMAIgIQNOpyW7eIfR50YefdF/aj9jofL491PRgFvdYHUBT24="
		},
		"metadata": {
			"version": 4,
			"contractType": "CRYPTOCURRENCY",
			"format": "MARKET_PRICE",
			"expiry": "2037-12-31T05:00:00.000Z",
			"acceptedCurrencies": ["BCH"],
			"pricingCurrency": "",
			"language": "",
			"escrowTimeoutHours": 1,
			"coinType": "ETH",
=>			"coinDivisibility": 100000000,   // payment or inventory?
			"priceModifier": 5
		},
		"item": {
			"title": "BCH-ETH",
			"description": "Cheap cryptos!",
			"processingTime": "",
			"price": 0,
			"nsfw": false,
			"tags": [],
			"images": [{
				"filename": "786a.gif",
				"original": "zb2rhn3zyAYj17JenXKGpJPBTRn68g8PJ6ZMXWFvRr7BTLLib",
				"large": "zb2rhh2BLagyb4yG8kSCTtrChHS45JAE2rLp92Zi3RwdZKK1B",
				"medium": "zb2rhnppMGkZYp6Zg7Qf2irDH9z1ZM5jc2VcAXfy6mEnifoEy",
				"small": "zb2rhfMZFaaWZxZGvkqAPCMUbmdxNHhAaCby5XCkRrV13bew8",
				"tiny": "zb2rhfN4RQyNP6eZszvEBfwBRMZxaysoqF72MYWPKoofV5AQr"
			}],
			"categories": [],
			"grams": 0,
			"condition": "",
			"options": [],
			"skus": [{
				"productID": "",
				"surcharge": 0,
				"quantity": 0
			}]
		},
		"shippingOptions": [],
		"coupons": [],
		"moderators": [],
		"termsAndConditions": "",
		"refundPolicy": ""
	}],
	"buyerOrder": {
		"refundAddress": "qreeeu24nq4f3pc5wel4ucwaxpg3ug35lg5t33566e",
		"refundFee": 0,
		"shipping": {
			"shipTo": "",
			"address": "",
			"city": "",
			"state": "",
			"postalCode": "",
			"country": "NA",
			"addressNotes": ""
		},
		"buyerID": {
			"peerID": "Qmb8CvXLDChhU5YBApLKbs8ixfWh9X6dmPHbp6B5tjFqB1",
			"handle": "",
			"pubkeys": {
				"identity": "CAESIHh9uLUPanFQVVIFkYsypxCezy/JYAx/pqu2cjUYIDZo",
				"bitcoin": "A0/wPzw14M6i/l+INxQY3JdvVOkV2lLNev+TxVjGBxS6"
			},
			"bitcoinSig": "MEQCIEx4s0UxxMK44+6KZhJAyQE64DtH9IJg0u38bkXbvfJxAiAGy6iVzHJwaMB3Njaq73+RrQ91VQnhqyc26o4GGi9XSg=="
		},
		"timestamp": "2019-01-31T21:12:20.170965750Z",
		"items": [{
			"listingHash": "zb2rhgg9mdHRub6DaBKBTu8Akg9UYYdz4azpBpdVKKNhTqMFB",
			"quantity": 0,
=>  		"quantity64": 1,        // 1 what?
=>			"preciseQuantity": "1", // future field inclusion makes these quantity fields ambiguous
			"memo": "",
			"paymentAddress": "Addresss"
		}],
		"payment": {
			"method": "ADDRESS_REQUEST",
			"moderator": "",
			"amount": 0,
			"chaincode": "",
			"address": "",
			"redeemScript": "",
			"coin": "BCH"
		},
		"ratingKeys": ["Ar1GMyRSUfS+rVZ7k8SOktFPISgU1wBu3jJkQ2Sci2eP"],
		"alternateContactInfo": "",
		"version": 2
	},
	"vendorOrderConfirmation": {
		"orderID": "QmVMf7iXQxvgbo1r6JoiT22Zyz334mV6xoQmN5bLfB5LVY",
		"timestamp": "2019-01-31T21:12:21.258215870Z",
		"paymentAddress": "qpf0sv9d5q9rurg40z3es9270j7hktv9fsncfegvlk",
		"requestedAmount": 0
	},
	"signatures": [{
		"section": "LISTING",
		"signatureBytes": "ga81iV5H6UnFQ1d8HVBjLapNCvLkgFSBd2ziNMQ2Bez7DHXcrL5+qynPeT2TbqPIUvqySAUQleNDSRTEEWRWDA=="
	}, {
		"section": "ORDER",
		"signatureBytes": "FzXD5GmxHgdzSL9FkgHeSs4BLApG3t8dOTulJEwCKEdP9tOWIZU8ZWLf5veiuw/Rn9OtSVgBAzz6pHeI8K4pCw=="
	}, {
		"section": "ORDER_CONFIRMATION",
		"signatureBytes": "m/mOeypWiz9epxwrmcENJjSVQF6ITpaGnvCCtNzF7k/YO8eTSMKr45ZqitAznhZsQbKl4O99mgAakqlODGlzAw=="
	}]
}

If you're suggesting that the coin will never change over time (as in from the time that contract is created), I disagree for two reasons. Contracts have technically infinite lifetime as new orders may be executed at any time in the future. While there's precedent for us to void old versions of contracts with new versions of the server, this has been in extreme scenarios and is avoided at all costs. (And is really just a cost of not paying the debt outlined in point (1) above.) More importantly, is the case I outlined in point (2) above. If the wallet is accepting satoshi-wei now and later actual-wei and there's no way to differentiate that in the contract, the contract suddenly becomes a lie (for the value spent) because the relationship between the contract and the server API are non-existent and there's no way to resolve that.
Not to mention the cases where a coin would hardfork to create a larger supply (particularly in the case of utility coins).

There are no intermediate values being stored for a coin. All the amounts are stored in the finest granularity.

No argument from me there. I agree less complexity is preferred over more complexity. But (2) describes why we need a more complex representation. This is an obvious technical case we need to support if we decided to take a two-step approach.

Will prepare planning out the above epic into executable steps for planning and discussion.

Additionally, we briefly discussed the plan of attack for this large scope w/ @drwasho and @amangale. The idea was raised to begin in the ETH wallet implementation as it is the highest risk and could be nice to have the chance to abort the plan if something comes up. I agree with this and with this thought in mind, here's my thinking about how to execute the beginning:

wallet interfaces for CurrencyValue and CurrencyDefinition. Prefer these types to be separate so a wallet-interface could deliver func Definition() *wallet.CurrencyDefinition in place of func CurrencyCode() string
Support serializing new data into the datastore (for ETH only right now, keeping in mind how this must work for all wallet implementations)
datastore migrations which support the wallet interface (stxos/txns/utxos contain balance whose type needs to be updated)
Update wallet-interface to use new data types

Let's plan to talk through this scope today.


document: add guide for using props as a key of query

As of https://github.com/TanStack/query/pull/7608. You no longer need an intermediate computed statement for props. You can just use the getter syntax () => props.foo directly. It would probably be worth documenting this as using a computed ref for a simple property access is less efficient than using a getter.

As of #7608. You no longer need an intermediate computed statement for props. You can just use the getter syntax () => props.foo directly. It would probably be worth documenting this as using a computed ref for a simple property access is less efficient than using a getter.

you mean I should do like this?
<script setup>
  const props = defineProps([todoId])
  const queryKey = ['todos', ()=>props.todoId]
  const result = useQuery(queryKey, () => fetchTodoById(todoIdValue.value))
</script>

but it didn't work for me.
are these changes merged with the main branch?

@TkDodo i've fixed the problem with prettier.

I’ve fixed the problem with prettier.

you’ve worked around prettier. Now prettier runs again and it automatically re-formats again.
see: https://github.com/TanStack/query/pull/8088/commits/9b9c095147eeae6dc2d4f7da1bfcc3b17bc32cf4

I've done it in another way, recheck it @TkDodo .

please use prettier locally; it re-formatted again; gonna close this as it kinda wastes my time, sorry.