Modify time first, round after (and strip additional precision).

DO NOT MERGE. Let's discuss this change first.
I've noticed that TestDo_rateLimit_noNetworkCall test fails on Go master with the following error:
--- FAIL: TestDo_rateLimit_noNetworkCall (0.00s)
	github_test.go:549: rateLimitErr rate reset = 2017-02-25 01:49:01 +0000 UTC, want 2017-02-25 01:49:01 +0000 UTC m=+60.206993003

(Source: https://travis-ci.org/google/go-github/jobs/205180544.)
This is due to changes in Go 1.9 to perform monotonic elapsed time measurements. See https://github.com/golang/go/issues/12914 and https://golang.org/design/12914-monotonic for full details.
Make the test pass by modifying time first, round after, and strip the monotonic clock reading by using AddDate(0, 0, 0). Doing that eliminates the unwanted additional monotonic precision from wanted time, making the expected time equality true.
This is also related to an open issue https://github.com/golang/go/issues/18991. Depending on the outcome there, this PR could be simplified not to need AddDate(0, 0, 0).
I just wanted to get this PR created for visibility. We can discuss the potential fix, and wait on Go 1.9 to get closer to release before actually merging this, because there may be additional changes that would render this change overly complex or unnecessary.

Worth noting, the reorder of Round(time.Second) and Add(time.Minute) actually has no effect at all, I did it just because the new order seemed more readable and logical to me. It was also more consistent with the comment.
The addition of AddDate(0, 0, 0) is the only thing that has an effect (in current Go master only, not in Go 1.8).

After https://github.com/golang/go/commit/6c85fb08c27c0346125567573e0f0a2b8124bc3b, this change to use AddDate(0, 0, 0) is no longer neccessary.
I still like the re-order of Round(time.Second) and Add(time.Minute), so maybe we can keep that. I'll update the PR.

I like the reorder too.

Actually, I think it's better to just close this PR, since the scope has changed too much. I'll just open a new PR for the small refactor, and reference this. We can close this PR since it's no longer needed.


Chart display switches

I have a suggestion.
First of all, I wanted to ask. Is it supposed to be that the options "Force charts to show in landscape" and "Charts use full height in portrait" can be enabled simultaneously? In this case, only one function will work.
I would like to make them mutually exclusive, meaning that turning on one of them turns off the other and vice versa, to avoid confusion.

v<IP_ADDRESS> Android 13

@TenchMaviatorius2759 I see what you mean. The thing is you need to see it that way:

you always enable chart use full height
sometimes you want to enable auto landscape.
It was exclusive then everytime you enable auto landscape it would disable full height. So if you were to disable auto landscape you would have to enable full height. So it would require 2 taps instead of one.

I do understand your point though as indeed as a matter of fact they cant be both used together (well auto landscape will take over and thus the other one is useless), however i dont think it hurts to have both enabled at the same time, and as i mentioned before it prevents unwanted behaviors.
is that ok with you? I am open to still change the behavior


update langchain to nougat to extract pdf in example

nit: there are still some PyPDFLoader in each notebook, can you remove them?


fix: resolve fontawesome conficts in uPortal by adopting a pure scope…

…d svg strategie

Checklist

[x] Resolve issue/feat. n° #28
[ ] tests are included
[ ] documentation is changed or added
[x] existing message properties have been updated with new phrases
[ ] new (i18n) language set have been added
[ ] improvement to make view conforms with WCAG 2.1 AA

Description of change
fix: resolve fontawesome conficts in uPortal by adopting a pure scoped svg strategie

add icons in svg [fontawesome-svg (free)] 5.5.0 set
remove all dependencies from css/js fontawesome lib
reduce ajax call to external lib
improve rendering performance
there will have no more conflict with uPortal/portlet fontawesome whatever version libs
the webcomponent is more self-contained

@ChristianMurphy 👋 ,
instead of using a JS strategie to solve icons issue conflict, i try to reduce conflict by avoiding them... 😄
🤔 ❓  insights?


Log is not capturing from commands or queues

Consider an example to update a book price ,in my books model i am using trait and getActivitylogOptions() it was working fine.i will mention which scenario it was working and which scenario it was not working.
working scenario

when ever i update any price by using ORM level either Web or API.

Not working scenario

if i want to update a book price in sale time ,for that i am using queue-jobs or schedulars(CLI) concept in this command file or job class  also i will update through ORM(model based) but it's not creating any log activity in my table

I am using like this in my queue class
Books::where('id',$id)->update(['price'=>2354]);
Versions

PHP: 8.0.23
Database:  10.6.11-MariaDB
Laravel: 8.83.27
Package: 4.1

You are running the SQL update on query builder and not model level. That's why there's no event to capture.


Error: Pairing Code Spam

So I used the pairing code for connection but the pairing code actually created spam. So I can't see the pairing code because it's drowning in spam and the pairing code doesn't work.
Code here

dongo gw, state nya belum di hapus :v

aduhai

dongo gw, state nya belum di hapus :v

smart😹


Deleting cells wont update Gather's dependency tree

When you execute cells in a notebook but then delete cells that have been run, Gather doesnt update its dependencies and when you run Gather, it will put back in those deleted cells into the "gathered notebook"

Uh this is by design? If they are dependency, they have to be there.


enh(swift) Add support for closure arguments (#2871)

Resolves #2871
Changes

Added a new mode to handle closure arguments such as $0 or $1
This new mode has also been added as a submode inside STRING because of the following reason

Checklist

[x] Added markup tests, or they don't apply here because...
[x] Updated the changelog at CHANGES.md
[ ] Added myself to AUTHORS.txt, under Contributors

Hi @il3ven
I kinda fixed this already 😅 I'm trying to redo the entire grammar and am working on a PR that will include a complete grammar for identifiers, which will handle not only closure arguments, but also property wrapper projections.

@svanimpe That's great if you have fixed it. 😅
I saw your PR and it mentioned issues #2819 and #2820 so that is why I picked this.
Anyway, can I assume that all the other issues related to swift that was opened by you will be covered in your PR?

@il3ven I hope to tackle most of them yes 🙂 But some are pretty tricky. For example, to fix #2895 I will have to be able to fully parse function declarations, so I can detect a complete declaration, excluding the body (as there is no body in a protocol). But that means first parsing types, identifiers, attributes, operators, etc, which I what I'm working on now.

@il3ven @joshgoebel An interesting question here is: Do we want to highlight implicit paramters ($0, $1, etc) as variables? According to the grammar, they're just identifiers, so should we highlight them separately? If so, should we also highlight normal identifiers, or just the ones that start with a dollar sign?

@svanimpe I chose to highlight implicit parameters ($0, $1, etc) as variables because in code they are used as variables and it made the most sense visually.
I don't know much about swift and I am getting started with open source. But I think we should only highlight the ones that start with a dollar sign or else we will end up highlighting a lot of words.

Xcode does highlight a lot of identifiers, but that highlighting is based on information from the compiler, which can tell the difference between different types of variables. That's not possible with a regex highlighter, so I'd also opt for only highlighting 'special' identifiers like this.
Here's the grammar I have ready to go for an upcoming PR (but I think I'm flooding @joshgoebel a bit now 😅):
  // https://docs.swift.org/swift-book/ReferenceManual/LexicalStructure.html#ID412
  const identifierHead = either(
    /[a-zA-Z_]/,
    /[\u00A8\u00AA\u00AD\u00AF\u00B2–\u00B5\u00B7–\u00BA]/,
    /[\u00BC–\u00BE\u00C0–\u00D6\u00D8–\u00F6\u00F8–\u00FF]/,
    /[\u0100–\u02FF\u0370–\u167F\u1681–\u180D\u180F–\u1DBF]/,
    /[\u1E00–\u1FFF]/,
    /[\u200B–\u200D\u202A–\u202E\u203F–\u2040\u2054\u2060–\u206F]/,
    /[\u2070–\u20CF\u2100–\u218F\u2460–\u24FF\u2776–\u2793]/,
    /[\u2C00–\u2DFF\u2E80–\u2FFF]/,
    /[\u3004–\u3007\u3021–\u302F\u3031–\u303F\u3040–\uD7FF]/,
    /[\uF900–\uFD3D\uFD40–\uFDCF\uFDF0–\uFE1F\uFE30–\uFE44]/,
    /[\uFE47–\uFFFD]/
  );
  const identifierCharacter = either(
    identifierHead,
    /\d/,
    /[\u0300–\u036F\u1DC0–\u1DFF\u20D0–\u20FF\uFE20–\uFE2F]/
  );
  const IDENTIFIER = {
    keywords: SWIFT_KEYWORDS,
    begin: `${identifierHead}${identifierCharacter}*`
  };
  const QUOTED_IDENTIFIER = {
    begin: `\`${IDENTIFIER.begin}\``
  };
  const IMPLICIT_PARAMETER = {
    className: 'variable',
    begin: /\$\d+/
  };
  const PROPERTY_WRAPPER_PROJECTION = {
    className: 'variable',
    begin: `\\$${identifierCharacter}+`
  };

Do we want to highlight implicit parameters ($0, $1, etc) as variables? According to the grammar, they're just identifiers, so should we highlight them separately?

That was my first instinct... we don't [generally] tend to highlight "just an identifier"... it needs to have more semantic context... variable, title, function name, built-in, etc...  If you look at the higher fidelity #2500 issue it's possible that more categories could be added to extend nuance in some cases, but we'd have to agree on exactly what those things were in order for their support to really be meaningful.

@joshgoebel In my upcoming PR, I'll only highlight $identifiers as variables. Highlighting other identifiers may be tricky, because I've noticed that keywords can stop working because they match the same regexs as identifiers.
Or maybe I don't fully understand how keywords are matched yet.

MODEs are matched first and then keywords are found inside the "buffer" of content that a mode includes. So modes (done wrong) can definitely break keywords.


feat: DIA-1384: Estimate cost for an inference run

Hi @robot-ci-heartex!
This PR was automaticaly generated via Follow Merge.
Please ensure that all linked upstream Pull Requests are merged before proceeding with this one.

https://github.com/HumanSignal/label-studio-sdk/pull/330 linked by Workflow Run

/git merge develop

/git merge develop

/git merge develop


Unable to get validation logs on tensorboard

Hi, I trained 3D classification network using highres3dnet as a backbone, but I'm unable to get validation logs, Is there any specific flag in a config file for populating validation logs on tensorboard?

Thanks got it


Bug 95671: Send Zap Adaptive Card rains Open

Description
After sending the Sats, the adaptive card gets blocked, and only information about the sent Sats remains.
Two bugs in one PR, because logic is connected to both of them:

To send the next Sats to another person, we need to create a new request, as the previous adaptive card is blocked (Bug 95671)
The adaptive card remains blocked, and information about the sent Sats (Receiver, Message, and Amount) stays visible (Bug 95994)

Screenshot/video

Related workitems

Bug 95671: Send Zap Adaptive Card rains Open
Bug 95994: Previous zap info is lost

Fixes # (issue)
Type of Change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

Test Instructions
To test this PR:

Open Zapp.ie (local) bot
Select prompt "Send Zap"
Fill out the form and submit the request.
Check if the adaptive card is blocked and ensure that the correct information remains visible.

Checklist:

[x] My code follows the style guidelines of this project (see "Contribute" in the wiki)
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] Any dependent changes have been merged and published in downstream modules
[ ] New and existing unit tests pass locally with my changes

Can you confirm I can still see the adaptive card details of what was sent? @EdiWeeks / @BogdanBrat

Doesn't seem to be deploying correctly @BogdanBrat


synchronize schema spec

What
APM agent json schema automatic sync
Why
Changeset

https://github.com/elastic/apm-server/commit/a72e46181 Fix typo in {span,transaction}.service.origin.id (https://github.com/elastic/apm-server/pull/7794)

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-04-19T18:08:16.152+0000

Duration: 49 min 58 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
2845

Skipped
20

Total
2865

:green_heart: Flaky test report
Tests succeeded.
:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

run benchmark tests : Run the benchmark tests.

run jdk compatibility tests : Run the JDK Compatibility tests.

run integration tests : Run the Agent Integration tests.

run end-to-end tests : Run the APM-ITs.

run windows tests : Build & tests on windows.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)


Updated chai to version 3.3.0

:rocket:
One of your dependencies has just updated, so this PR bumps the corresponding version number in your package.json.
You can now check that the dependency update doesn't break your code, and then release the new version of your software safe in the knowledge that it will stay in this working state, regardless of when your users do $ npm install.
Have a good day!

This pull request was created by greenkeeper.io.
It keeps your software, up to date, all the time.

Tired of seeing this sponsor message? Upgrade to the supporter plan!
You'll also get your pull requests faster :zap:

Current coverage is 100.00%

Merging #6 into master will not affect coverage as of d265a74

@@            master      #6   diff @@
======================================
  Files            1       1
  Stmts           40      40
  Branches         0       0
  Methods          0       0
======================================
  Hit             40      40
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of d265a74

Powered by Codecov. Updated on successful CI builds.


Update "Tesoro-y-Gloria-1E" character sheet to the latest version

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description
Following the instructions of the creator of the game (Telmo Arnedo) I'm updating the character sheet of the first edition to the latest version.

Character Sheet Info Roll20 Internal Use only.


Add KubeGems to adopters

Q
A

Bug fix?
no

New feature?
no

API breaks?
no

Deprecations?
no

Related tickets
N/A

License
Apache 2.0

What's in this PR?
Adds KubeGems as an adopter

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


fix: missing backend repo url, type

Fixes:
Description of what your PR accomplishes:
fixed type and missing backend server URL

LGTM!


A few E2E Conformance test cases have failed on the OpenShift cluster.

What happened?
We ran the E2E Conformance test cases on OpenShift cluster OCP 4.12.13. Some of the below-highlighted tests Failed.

[It] [sig-network] DNS should provide DNS for the cluster [Conformance]
[It] [sig-network] DNS should provide DNS for pods for Subdomain [Conformance]
[It] [sig-network] DNS should provide DNS for services [Conformance]
[It] [sig-network] Services should be able to change the type from ClusterIP to ExternalName [Conformance]
[It] [sig-network] Services should be able to change the type from NodePort to ExternalName [Conformance]

While investigating, we observed that the dns-querier-n pod was unable to resolve a DNS name, despite the DNS record being available.
root@dns-querier-1:/# dig +notcp +noall +answer +search kubernetes.default.svc.cluster.local A
We made some tweaks to the dig command, specifically by removing the +search option, and it worked fine.
As a reference, please see the output of the below command, it was able to fetch the service name.
root@dns-querier-1:/# dig +notcp +noall +answer kubernetes.default.svc.cluster.local A
kubernetes.default.svc.cluster.local. 5    IN A    <IP_ADDRESS>
Note:
We experienced this behavior on the OpenShift cluster only NOT on any other KubeADM setup.
What did you expect to happen?
The +search option in the dig command is used to append domains from the local domain search list;
Since we are specifying the FQDN I think +search can be skipped.
As we did notice after removing the +search option from the dig command it worked.
Or
We can have the option to try resolving the DNS with/without the +search option.
How can we reproduce it (as minimally and precisely as possible)?
On the OCP cluster run the E2E conformance test for [It] [sig-network] DNS should provide DNS for the cluster [Conformance]
you will notice that the pods will be deployed and once the dig command starts it fails to resolve it.
tweak the dig command by removing +search option and then exec into the dns-query pod to manually run the command it will work.
Anything elese we need to know?
No response
E2E Provider Used
kind
e2e-framework Version
v1.25.8
OS version

# On Linux:
$ cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.6 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.6"
PLATFORM_ID="platform:el8"
$ uname -a
Linux master-0 4.18.0-372.51.1.rt7.208.el8_6.x86_64

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

@Rouf111 Thanks for reaching out to us here with a bug report.
I went through the report and couldn't really identify how the reported issue relates to the e2e-framework.

We can have the option to try resolving the DNS with/without the +search option.

Would you be able to explain the requirements a bit more

you'd have to talk to openshift about this.
log a ticket in the product support issue tracker and they will handle it, by replying to you and/or even sending fixes to kubernetes/kubernetes/test/... where the active framework of kubernetes is in use. the framework in this repo is the new framework, which is still not used in k/k.
/close
/kind support


Implementation of multiple scenes example

Hello,
This PR is an implementation of this example from threejs:
https://threejs.org/examples/webgl_multiple_scenes_comparison.html
I found it useful to work through this for my own understanding, so figured I'd share. If you'd like to merge, please do. I won't be offended if not, however.
Thanks.

Thanks, I will consider adding it. However, this PR seems to have uncovered a bug related to lights that I need to find time to investigate. Changing to a non MeshBasicMaterial leads to black mesh or segfault depening on how the lights are added (or not added).

Seems clone() was not implemented for lights. The segfault remains a mystery, but adding clone resolves the issue.

Thanks, I will consider adding it. However, this PR seems to have uncovered a bug related to lights that I need to find time to investigate. Changing to a non MeshBasicMaterial leads to black mesh or segfault depening on how the lights are added (or not added).

I noticed this too with a standard material, though I was unsure if it was intentional or not.

I made some minor changes, but for some reason I am not allowed to push to this branch.

That's odd, I wonder if it's because I created the fork under my organization's account. Let me know if you'd like me to recreate the PR under my personal account.

Yeah, that's definitely the issue and I don't know how to solve it. I pushed the branch to my personal github account:
https://github.com/fagg/threepp/tree/multiple-scenes-example
That should work. Let me know if you want me to recreate the PR.

The example should be added as it uses previously unused features. I can either add the changes directly, or you may re-create the PR.

The example should be added as it uses previously unused features. I can either add the changes directly, or you may re-create the PR.

Recreated. :)


fixed issue with struct keys getting converted to strings

This is a small fix for an issue where struct keys (such as %Plug.Upload{}) are being stringified when used as params in a changeset.

Just realized you already have a PR with a fix for this.


Fix for non-contingent RAM acquisition

This will fix the random seg fault which would happen if
you would touch a memory location starting from 0x200000 onwards.
In HW, there are two strips of RAMs. We cannot sequentially increase Heap alocations
for example. bss and data+uVisor stays in RAM1 and stack+heap goes into RAM2.

Should fix #4
@mjs-arm @bogdanm @AlessandroA

+1 LGTM. In the absence of relevant support in the linker, this seems like a reasonable work around to me.

I'm not sure if linker support can fix this, since it looks like the compiler is the one who needs to be ultimately aware of this limitation. In any case, +1. I would release at least a new minor for this, although I'm inclined to make it a new major.


Add assign_[plugin]_to_extension methods on plugin_manager.

Description
One part of #2686.  @goanpeca have a look.  Happy to change any of the API wording or implementation but this is what I was picturing... This allows:
from napari.plugins import plugin_manager as pm

pm.assign_reader_to_extensions('builtins', '.png', '.jpg')
pm._extension2reader  # {'.png': 'builtins', '.jpg': 'builtins'}

pm.get_reader_for_extension('.png')  # 'builtins'

... and dragging a png onto the viewer should now use builtins no matter what else is installed.
Type of change

[ ] Bug-fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

ok, this is updated and these are supported:
pm.assign_reader_to_extensions('builtins', extensions=['.png'])
pm.assign_reader_to_extensions('builtins', ['.png'])
pm.assign_reader_to_extensions('builtins', '.png')

Also added to SETTINGS.  ready for re-review

Code looks nice @tlambert03, we've got a pydantic.error_wrappers.ValidationError: error causing all the tests to fail.
I also get a
  File "pydantic/main.py", line 400, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 2 validation errors for PluginsSettings
extension2reader
  none is not an allowed value (type=type_error.none.not_allowed)

error on launch, but once that clears up, will be happy to test this again and get this in.
I'll look for this when I test it, but is there now a dialog in the setting's panel that allows this to be customized from there? Would be pretty sweet

I'll look for this when I test it, but is there now a dialog in the setting's panel that allows this to be customized from there?


Allow AccountInfo to be absent for read-only instruction accounts

Problem
With direct mapping, we no longer want to depend on the execute bit in accounts.
Some programs on mainnet do not pass an AccountInfo for programs. So, make this slightly more generic and allow AccountInfo to be missing for any read-only instruction account.
Summary of Changes
Fixes #

This change seems unrelated to direct mapping - what's the reason for wanting to ship it with dm?
We're aiming to enable dm in 2.1. DM is already a large change. We've done a lot of testing with the existing code. The change to on-chain API use allowed by this change is non trivial, and as far as I can tell we have 0 tests for it. Unless I'm missing something this shouldn't be lumped with dm?

Yes, should probably get its own feature gate and SIMD.
Also, the invoke_context.get_check_aligned() changes could be a separate PR.


replace settings variables in debugger config #8042

Hi @DonJayamanne, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@DonJayamanne, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, MSBOT;

@DonJayamanne thanks for the PR however we are currently in the endgame. So I will review this first week of july -> july milestone

Cheers

@isidorn , I'll resubmit a pull request for this later today. Closing this as there were some problems in the way I created the changes at my end.
Also, there are some more changes to be made:

Error handling
Tests

Great - looking forward to the PR. Thanks!


Update to kotlin-1.7.20 and gradle-7.5

PR: https://github.com/sicpa-dlab/peer-did-jvm/pull/33

Done


SyntaxError: Unexpected token export

configure:
plugins: [
["babel-plugin-root-import", {
"rootPathPrefix": "~",
"rootPathSuffix": "../src"
}]
]
code:
base.js
'use strict';

import Base from '~/common/controller/';

export default class extends Base {
  // async getAction() {
  //   let ret;

  //   ret = await super.getAction();
  //   this.success(ret);
  // }
}

controller/index.js
'use strict';

/**
 *  Base Restful controller
 */

export default class extends think.controller.rest {

error message:
[2017-02-14 11:11:28] [Error] /Users/luncher/work/admin-plus/src/common/controller/index.js:8
export default class extends think.controller.rest {
^^^^^^
SyntaxError: Unexpected token export

This is because this plugin does not support es6?

Seem's like you've not installed the babel-preset-es2015, since the import feature is not implemented in the default babel-preset (it's not a confirmed standard yet)
Install / add this package and try again :)

I have already loaded the plugin, but it is still suggesting that this error.

Just as a workaround, you could try to change export default to module.exports =.

i have recently resolved a similar issue. Please take a look of my solution here


Sign up page returns "invalid rounds" error

/cc @menardorama

This is fixed in Alerta server version 4.7.12 which is available for download immediately.


Periodically trying to send calls to the contract 0xAf379C844f87A7b47EE6fe5E4a9720988EaEA0AF

can you show me the swap code your trying to do please

export async function pancakeSwapSimple(asset, assetOne, buyAmount) {
try {
const fromTokenContractAddress = asset.id
const toTokenContractAddress = assetOne.id
const pancakeswapPair = new PancakeswapPair({
  fromTokenContractAddress: fromTokenContractAddress,
  toTokenContractAddress: toTokenContractAddress,
  ethereumAddress: ethereumAddress,
})

const pancakeswapPairFactory = await pancakeswapPair.createFactory()
const trade = await pancakeswapPairFactory.trade(buyAmount.toString())
trade.quoteChanged$.subscribe((value: TradeContext) => {

})

const price = buyAmount / trade.expectedConvertQuote

if (assetOne.symbol === 'USDC') {
  const priceUsd = Number(trade.expectedConvertQuote).toFixed(2)
  // trade.destroy()
  return priceUsd
}
// trade.destroy()
return price

} catch (e) {
console.log('PancakeErrorTrade', e)
}
}
`
I assume this happens when trade.destroy() is commented.

@joshstevens19 Any update?

I am on vacation till next Monday will look once back from holidays. Sorry about the delay.

Hey sorry just getting round to looking at this can you tell me your fromTokenContractAddress and toTokenContractAddress is which causes this to fail also your ethereumAddress so I can recreate this. I can not recreate this locally so I think it could be your parameters. Thanks @yanis7774

Inactivity will reopen once I get the details I need to recreate! Thanks


[NTR] Thymic nurse cell

Preferred term label: Thymic nurse cell
Synonyms: -
Definition: "Thymic nurse cells are large epithelial cells found in the cortex of the thymus and also in cortico-medullary junction. They internalize thymocytes through extensions of plasma membrane. The cell surfaces of thymic nurse cells and their cytoplasmic vacuoles express MHC Class I and MHC Class II antigens. The interaction of these antigens with the developing thymocytes determines whether the thymocytes undergo positive or negative selection." [https://en.wikipedia.org/wiki/Thymic_nurse_cell]
Parent cell type term: epithelial cell of thymus (CL:0002293)
What is the anatomical structure that the cell is a part of?:
cortex of thymus (UBERON:0002123)
thymus corticomedullary boundary (UBERON:0003988)
Your nano-attribution (ORCID): 0000-0002-0819-0473
Any additional notes or concerns: According to Wikipedia: "The thymic nurse cells in the cortico-medullary junction express cytokeratin 5 (K5) and cytokeratin 8 (K8), whereas the ones in the cortex express only cytokeratin 8." Seems this is a mix of two populations. Should terms be created for these two populations? Many thanks

Any additional notes or concerns: According to Wikipedia: "The thymic nurse cells in the cortico-medullary junction express cytokeratin 5 (K5) and cytokeratin 8 (K8), whereas the ones in the cortex express only cytokeratin 8." Seems this is a mix of two populations. Should terms be created for these two populations? Many thanks

Given the different expression profiles and locations, it may make sense to create separate classes for cortical TNC and cortico-medullary TNC.
PMID:20035931 also makes the connection specifically between the cortico-medullary TNCs and thymic epithelial progenitors:
"...  All TNCs, whether in culture or in vivo, were found to express the pH91-specific antigen (Figure 3) [13]. A subset of these pH91+ cells expressed the transcription factor p63 (Figure 4). Using freshly isolated cells, we also showed that nearly a quarter of TNCs are pH91+K8+K5+ cells (Figure 2). Our in vivo studies show that the K8+K5+ double positive cells with the unique structure of TNCs to be located in the cortico-medullary junction. The thymic epithelial progenitor cell type has been reported to reside in the cortico-medullary junction and to express both K8 and K5 cytokeratins and p63 [25; 26]. Several studies show thymic epithelial progenitor cells to be able to regenerate an entire functional thymus when transplanted under the kidney capsule [23; 30; 31]. Our data show a subset of TNCs located in the cortico-medullary junction express the reported characteristics of thymic epithelial progenitors. ..."

Hi, @bvarner-ebi
You would create "Thymic nurse cell" and the two cell types "TNC cortico-medullary junction K5/K8" and "TNC cortex K8" as child of "Thymic nurse cell" or only the two child terms?
According to PMID:20035931 "TNC cortico-medullary junction K5/K8" are "thymic epithelial progenitor cells"? May be this cell type is related to corticomedullary thymic epithelial cell (CL:0009070) ?

Hi @paolaroncaglia, since you have been involved in creating new terms related to thymus cells, do you have any comments on this request? Particularly, do you have a comment on whether a 'thymic nurse cell' should be one new class or broken into separate classes for cortical and corticomedullary types? I think a case could be made for either option, but would one approach be preferred?

Hi @addiehl ,
Would you be able to provide feedback on this please? We can take care of the edits. Thanks in advance!

@bvarner-ebi and @paulacalipho one thing I recall from working on thymus cell types for the ASCT+B tables is that e.g. for subtypes of double-negative thymocytes there were significant differences in markers between human and mouse. The parent cell type for this request ('epithelial cell of thymus') is, rightfully, species-agnostic. The Wikipedia entry that Paula referenced, based on its bibliography, includes a mix of human and mouse studies. The paper that Bradley quoted is based on mouse cells only. Unless unequivocal evidence is available that the same markers (human/mouse homologs) are found in each population, I'd keep that information in definition gloss or rdfs:comment, rather than use it to support subclasses. As for using the thymus location to support subclasses or not, at a quick glance again that partly depends on the balance between having a single term that's more broadly applicable (to other mammalian species for example) vs. having two granular terms as long as you can support them adequately. It's not even clear to me if nurse cells are always part of both thymus cortex and cortico-medullary junction, so the less risky option would be to have one class of TNC as part of thymus, but I haven't delved into the literature.

Thanks for the insight, @paolaroncaglia! Based on your feedback, it seems like creating a single new class for TNC seems appropriate. We can get more granular in the future as needed and if more specific literature is found.

Hi @paolaroncaglia , Hi @bvarner-ebi , many thanks for your input and creating this term, Paula


Fix startup defaults

The default rpc ports for mainnet, testnet and signet were wrong. Set the up correctly.
Furthermore, return a more friendly error message when the rpc username or password is incorrect.

@meryacine can you give a look to this one? Should be quite trivial (yet I completely missed it on the first go).

Double checked. These are the correct default rpc ports.


Automator: update<EMAIL_ADDRESS>in<EMAIL_ADDRESS>

Generated by Automator - 2023-12-20T01:45:22+00:00

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-ambient_istio_release-1.18
d8721e5a4eef38483dd5e5368a4b0d4189547f8b
link
unknown
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-ambient


[ICD] kICDMonitoringBufferSize is too small to handle full "full width" node ID

Reproduction steps
When using "full width" node ID, for example, 0xffff000000000000, We cannot registerClient successfully using the lit example app, it would complain the buffer is too small,
https://github.com/project-chip/connectedhomeip/blob/17f25a1772f7ba7535d57cd4dfa43ac1fc295843/src/app/icd/server/ICDMonitoringTable.h#L37C25-L37C49
[1727120175.806454][15188:15188] CHIP:SVR: debug 63
0x08, tag[Fully Qualified (6 Bytes)]: 0xd973::0xffa3::0xff, type: Octet String (0x10), length: 0, value: hex:
[1727120175.806476][15188:15188] CHIP:SPT: debug>>>152701000000000000FFFF270201000100FDFFFFFF300310D0E9EB3B00000000
[1727120175.806486][15188:15188] CHIP:SPT: debug>>>0000000000000000300410D0E9EB3B00000000000000000000000024050018
We may do TLV::EstimateStructOverhead(sizeof(uint64_t), sizeof(uint64_t), sizeof(xxxx), etc) * 3 / 2
Bug prevalence
always
GitHub hash of the SDK that was being used
8750c55
Platform
core
Platform Version(s)
1.4
Anything else?
No response

Why * 3 / 2?

we need slack of at least 50%  to make sure we can grow and then if there is a firmware upgrade/downgrade, that it doesn't brick

Where is the "50%" coming from?  What if the new firmware grows by more than that in terms of what it's storing (since presumbly it's the "downgrade" case that needs the extra space)?


Visual Studio for Mac Preview - Crossplatform ASP.NET Core 1 not working

I'm attempting to get an ASP.NET Core 1 solution to work on both Mac/Windows, but I am having issues with it. I am working with Mac Visual Studio Version Preview 1 (7.0 build 347) and Windows Visual Studio Version 4.6.01586.
When I attempt to open/compile the ASP.NET Core 1 application from Windows to Mac it tells me to "Please build the project and retry, or set the OutputPath and AssemblyName properties appropriately to point at the correct location for the target assembly" but when I try to build it doesn't work (it skips).
Vice versa, when I try it from Mac to Windows it doesn't even open and it comes up with the error message "Error while trying to load the project '.../ASPNETCoreWindows.xproj': Unknown solution item type.
Not sure if the different version types plays any role in this, but I also noticed that the Mac version doesn't include a project.json. For reference, I have two blank ASP.NET that can be used for testing:
https://github.com/ChristianRRL/ASPNETCoreWindows/
https://github.com/ChristianRRL/ASPNETCoreMac/

I get the same "Unknown solution item type" error trying to open any Core 1 solution in VS for Mac

maybe the same error.
dotnet --info
.NET Command Line Tools (1.0.0-preview2-1-003177)

Runtime Environment:
 OS Name:     Mac OS X

but the project options show
Target framework: .NetCoreApp 1.0(Not installed)

Same error here, solution and projects created with Visual Studio 2015 Community Edition
dotnet --info
.NET Command Line Tools (1.0.0-preview4-004233)

Runtime Environment:
OS Name:     Mac OS X
OS Version:  10.12
OS Platform: Darwin

I've also tried to open a Visual Studio 2017 RC migrated solution and I get the same error but now the error message mentions the new csproj project files :
{filename}.csproj: Unknown solution item type

@barrytang , Anything you can add here? Do you know who the right people are to pull in to help out?

I'm getting the same issue, I saw somewhere that you might need to do a dotnet migrate command. https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/dotnet-migrate

I did the migration when I opened the project in Visual Studio 2017 RC but still got the same problem. I also noticed that when creating a new ASP.NET Core solution in Visual Studio for Mac Preview, the solution version is marked as Visual Studio 2012.

yep, I did the same thing, so, I think maybe is a problem with the version for mac. Because it's too old.

VS for Mac supports the new .NET Core csproj format introduced in VS 2017 RC. It does not support the old xproj format. As mentioned earlier you can migrate xproj to csproj on the commandline using dotnet migrate.
An update to the VS 2017 RC made further simplification to project files using a new MSBuild concept called SDKs, as explained here:
https://blogs.msdn.microsoft.com/dotnet/2016/12/12/updating-visual-studio-2017-rc-net-core-tooling-improvements
You can identify csproj projects that use the SDK feature by the Sdk attribute in the toplevel Project attribute and a lack of <Import> elements. VS for Mac (as of Preview 2) does not yet support MSBuild SDKs, but we're working on adding it.

@mhutch thanks. csproj also not working now on VS for Mac (Alpha channel), hope it will working next update.

I miss the project.json file because it was easy to perform a build and release on a Mac using terminal or with Azure and Visual Studio Team service builds/release.

dotnet restore
publish -c Release --version-suffix $(Build.BuildId)

and viola I would have a build done in VSTS and get the build id into my ASP.NET core assembly.  Now, with VS 2017 and Visual Studio for Mac ASP.NET Core web application projects no longer have a project.json file and are using MSBuild instead.  How do I run msbuild on a Mac Terminal?  I shouldn't have to rely on my IDE to always perform a build and deploy.

@evermeire yes, Mono ships msbuild on Mac, which can be used from the command-line, and VS for Mac and the dotnet command-line both use MSBuild to build projects.
We don't currently ship Azure deployment support in VS for Mac, what screenshot are you seeing this in? We do have support for integrating mobile apps with Azure connected services but that's something different.

Thanks for the quick reply.  On this page, https://www.visualstudio.com/vs/visual-studio-mac/, I was looking at this screenshot.
<EMAIL_ADDRESS>but now that I look closer at it, it is the Azure App Service and not Azure WebApp Service
I quickly realized that msbuild does execute on a Mac via terminal after I posted the above comment, so I am good there.

Latest Preview 3 now opens the new csproj based projects, but I'm getting the following error when building any project.
Error MSB4057: The target "Build" does not exist in the project. (MSB4057)
I have updated the  .NET Core SDK 1.0.0-rc4 as instructed in the release notes.

cc @mrward

You need a recent Mono 4.8 which should fix that build error:
https://dl.xamarin.com/MonoFrameworkMDK/Macx86/MonoFramework-MDK-<IP_ADDRESS>9.macos10.xamarin.universal.pkg

Thanks, that fixed the issue!

when i upgrade to the latest version of vs for mac, everything working well. woo~

I made a .NETCore app in VS for Mac and tried to open the project in VS Enterprise 2015 for Win, but the one-way project upgrade dialog appears in VS for Win. After accepting the dialog my Program.cs file does not appear in the Project Explorer and when debug-building: "Project not selected to build for this solution configuration" and when release-building: "error MSB4040: There is no target in the project."

@erikmartinessanches - Visual Studio 2015 does not support .NET Core projects. You will need to use Visual Studio 2017.

@mrward @erikmartinessanches Visual Studio 2015 does support DotNetCore, if you install the Dot Net Core tools for it. I've had no issues doing so.
https://www.microsoft.com/net/core#windowsvs2015 (step 2)

@iBeizsley - Sorry to be more clear I mean Visual Studio 2017 does not support the new sdk style MSBuild projects. As far as I am aware the .NET Core support in Visual Studio 2015 uses the xproj project file format.

@mrward Ah, yep, this is correct.

@ChristianRRL,  @mhutch, it sounds like this issue has been addressed. I'm going to close. Please reopen if that is not the case.

brand new mac, brand new install of VS
Visual Studio for Mac Preview
Version Preview 3 (7.0 build 1077)
Installation UUID: ceb38681-66a2-4bcc-a307-ae740919b339
Runtime:
Mono 4.8.0 (mono-4.8.0-branch/cd26828) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 408000459
latest version of mono
Mono JIT compiler version 4.8.0 (mono-4.8.0-branch/cd26828 Fri Jan 13 14:32:29 EST 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS:           normal
SIGSEGV:       altstack
Notification:  kqueue
Architecture:  x86
Disabled:      none
Misc:          softdebug
LLVM:          yes(3.6.0svn-mono-master/8b1520c)
GC:            sgen
latest version of dotnet
.NET Command Line Tools (1.0.0-rc4-004793)
Product Information:
Version:            1.0.0-rc4-004793
Commit SHA-1 hash:  6091a4704c
Runtime Environment:
OS Name:     Mac OS X
OS Version:  10.12
OS Platform: Darwin
RID:         osx.10.12-x64
Base Path:   /usr/local/share/dotnet/sdk/1.0.0-rc4-004793
I still have the
Target framework: .NetCoreApp 1.0(Not installed

This is an error you are getting from VS for Mac?

@smnbss - Visual Studio for Mac does not correctly report the .NetCoreApp target framework as being installed in the project options. The 'Not installed' message can be ignored if you have a recent .NET Core SDK installed, which you have.

Petermarcu commented 2 hours ago
This is an error you are getting from VS for Mac?
Yes
It was compiling and running the app though.


coinb.in/api

Just noticing your site performance dying atm - and reqs to your api https://coinb.in/api/ failing --- But got me thinking, were you ever thinking of opensourcing the backend for your api? Be cool to make this entirely self hostable.
Amazing work with it, thank you.

Should say - for anyone else running into this problem -- Going to the broadcast page -> press the cog above the textarea and change the Network,Broadcast, Unspent outputs sources from the dropdowns. to eg. blockchair bitcoin-mainnet


Grouping data functionality

Hi,
Is there any plan to add grouping functionality?
regards
Marcin

@diskman Nope. Someone has already attempted on this feature on vuetable-2 though. You can find it here. But as I commented in the thread that it will not work correctly in every situation and vuetable itself was not built for that purpose.


[GH-57] add autocomplete

Summary
This PR adds autocomplete to the confluence plugin.
A new endpoint is added to handle the dynamic retrieving of subscription aliases for the edit and unsubscribe commands.
Ticket Link
Fixes #57

Codecov Report

Merging #62 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #62   +/-   ##
=======================================
  Coverage   29.48%   29.48%
=======================================
  Files           8        8
  Lines         234      234
=======================================
  Hits           69       69
  Misses        153      153
  Partials       12       12

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 05cc4cf...def2363. Read the comment docs.


Temporary fix for bug #449

Temporary fix for a bug (#449) in scheduler that could result in systems running concurrently when they shouldn't.

parallel_executor.rs:207 - This looks like a pre-existing bug that put duplicate systems in self.system_dependents
parallel_executor.rs:223 - This is a bug in the new code that would allow the same CountdownEvent to be inserted into the ready_events_of_dependents multiple times
parallel_executor.rs:344 - This assert detects the resulting bad setup where a dependent already has their sync primitive that ought to be blocking its execution triggered

The "temporary" aspect of this fix is that it does not address the duplication in self.system_dependents which was likely pre-existing to the scheduler rework.

thanks for the fast response time on this!

Nice catches on both, it also fixes the failed unit test. I think this would be a reasonable permanent fix now.


fix/connection_states: simple_deo exception and hanging issue on Windows

Windows doesn't allow using different token to registration to the same socket.
Windows doesn't suppot socket try_clone

This change is

r? @vinipsmaker
(maidsafe_highfive has picked a reviewer for you, use r? to override)


Parser allocates so much you'd think it's a python interpreter

Currently, everything is allocated into a String; it may not matter much for the size of TOML files, but I'd still like to move to Cow or similar where possible.

Closed by #15


bad content-length default

In werkzeug's WSGIRequestHandler, CONTENT-LENGTH defaults to an empty string ('') if the client did not provide a Content-Length header.
This is causing me problems in my flask web service, which is trying to proxy requests.  The user creates a request without Content-Length, flask gives it to me and then I pass it along to another server, which then returns HTTP 400 due to the bad Content-Length that werkzeug has inserted.  According to RFC 2616, Content-Length must be a number.
Initially I thought this should be considered a werkzeug bug but maybe the empty string was intended to be werkzeug's signifier for a non-existent Content-Length, rather than an actual Content-Length value that could be used directly.  If that's the case, then I would modify flask so that Content-Length isn't included in the incoming request's headers if it is the empty string.
Bottom line, I believe that a client request that is missing a Content-Length header should not result in an incoming flask request with the Content-Length equal to the empty string.

The beginner friendly tag might be too generous, but I'm trying to tag some stuff besides documentation and this seems like a reasonably self contained fix. That is, if we can get to a consensus on whether we actually want to change Werkzeug's behavior as you suggested @untitaker.

Is it the way you are creating the response? I have tested it by generating a response header without a Content-Length and then running it through flask which routes it through nginx.
Result: When you throw the response just in flask its fine (follows PEP-333).
But when you try to send it through nginx it'll crash because it does not like what is passed, the empty content-length (follows RFC 2616). For compatibility, I would agree with @untitaker that Flask omit empty Content-Type and or Content-Length. It also states in RFC 2616 that services should take priority.

We should let this @mitsuhiko decide... maybe Werkzeug's current behavior is also due to other software's behavior.

And what did he decide? I'd be glad to start contributing with some code.

We did not yet contact him.
I'm glad that you want to help @omarkhd -- feel free to ping mitsuhiko on the #pocoo IRC channel!

For anyone seeking a quick fix solution to this error, take a look at the Proposed Solution section under Issue #1289.
Link to Proposed Solution

I'm fine with the proposed solution, but please let @mitsuhiko confirm it, on the unlikely off-chance that this behavior is actually intended.

@KWinston can I take this solution? Its the better way to solve the problem?

@matheuspoleza yes, you can use the solution I provided. The proposed solution should stop your application from crashing if you are having issues with CONTENT-LENGTH not being a number.

@KWinston ok, I'll do that

@mitsuhiko : Is the proposed solution ok to implement?
@KWinston  : May I use your solution?

I do not understand the proposed solution. Where do we generate an empty content length string?

In werkzeug's WSGIRequestHandler, CONTENT-LENGTH defaults to an empty string ('') if the client did not provide a Content-Length header.<

When used with other applications that default to an empty string or a non-number passed through flask. It is more a compatibility issue with other apps.
Probably more of a documentation addition to incorporate this when using other apps while running flask?

I'm not sure I follow. Surely an empty string is a valid value for CONTENT_LENGTH so should this not be reported against whatever application fails?

Can someone make a minimal test case of what is wrong and what is expected? I'm at a loss here. WSGIRequestHandler handles incoming data only. So that should be irrelevant here, no?

@mitsuhiko according to my reading of rfc2616, you can either (1) have a content-length header, in which case it must be a number, or 2) if the header is not provided, it explains how to compute it. The situation here has the client does not provide the header ... but then flask/werkzeug artificially creates a header that is the empty string, which is not legal according to rfc 2616. I am traveling this weekend but can make a test case next week.

The HTTP RFC is irrelevant here. An empty WSGI environ value is to be treated as nonexistent according to the WSGI PEP.

However, if you find an abstraction over the WSGI env (within Flask/Werkzeug or outside) whose behavior differs when given an empty string instead of a nonexistent value, it's totally a bug.

@reteptilian as @untitaker mentioned the rfc does not matter here because this is an internal header on the incoming side and we hide it. This really needs a clear testcase.

echoheaders.py:
import flask
app = flask.Flask(__name__)

@app.route('/')
def echo_headers():
    return flask.jsonify(dict(flask.request.headers))

Run it:
$ FLASK_APP=echoheaders python -m flask run
 * Serving Flask app "echoheaders"
 * Running on http://<IP_ADDRESS>:5000/ (Press CTRL+C to quit)

Test:
$ curl http://localhost:5000
{
  "Accept": "*/*",
  "Content-Length": "",    <-----------   THIS IS MY COMPLAINT  ------------
  "Content-Type": "",
  "Host": "localhost:5000",
  "User-Agent": "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
}

The client did not provide a Content-Length header, but flask creates one that is set to an illegal empty string.
This is problematic for us, because my team made the (questionable) decision to use flask as a kind of smart proxy service, so it forwards all the client headers along to the destination, which then rightly complains (per RFC 2616) that it cannot parse the value from the Content-Length header.  So we had to write our own code to overwrite flask's version with a correct Content-Length.  It would be nicer if flask did not artificially create this header, or at the very least, set it to a valid value (zero in this case).

That is clearer. Your previous comments were about the WSGI Value, not the header abstraction.

I see. So unfortunately this is something that's not actually up to Flask. You would have to file this against Werkzeug. However there is a limit to what we can do with the EnvironHeaders (which is what drives this).
I could imagine skipping over empty content-length and content-type headers however then you can't tell a client actually sending an empty header apart. This is because this is really a limitation in the underlying WSGI protocol.

Closing this for now, because this is definitely a Werkzeug issue.

@untitaker Do you agree that I should open it against Werkzeug?  It sounded to me like you were arguing this was a flask issue not werkzeug.
My apologies for the confusion, I guess I had debugged it down to werkzeug and was trying to be helpful about the root cause but should have stuck with the simple flask example at the start.

Yes it is a Werkzeug bug!

OK, all set.
PS, thanks for the great work on these projects.  They really are fantastic.


Add 'plotly_noembed' cargo feature

This adds a new plotly_noembed feature that can be used to reduce the sizes of binaries by not embedding plotly.min.js.
Since askama can not handle compile-time flags, we had to duplicate the plot.html and static_plot.html templates, where the new *_noembed.html version only contains the CDN-variant.
The use_local_plotly option has been feature-gated such that it is not available when using the new feature.
I verified that this works by building an application that depends on plotly.rs (including optimization and LTO in all cases):
no plotly:   4.96 MiB (5,201,920 bytes)
master:      8.96 MiB (9,400,320 bytes)
this branch: 5.44 MiB (5,701,632 bytes)

The difference between this branch and master is 3,698,688 bytes, which is very close to the size of plotly.min.js (3,686,400 bytes). Just as expected.
closes #176

@sharkdp , thank you for submitting the PR.
I need a bit more time to review it.

Hi @sharkdp,
I had a chance to look into the PR today.
Indeed, duplicating the template files is annoying. I have looked into what alternatives we have. TBH, I thought about  it and I think the embedding of the plotly.min.js should be an opt-in feature and not an opt-out since it blows up the library size. Although I might risk upsetting some users, I am going to propose that we make it an opt-in .
Also using the if/else in the template as it was originally implemented causes this issue of not being able to use the Rust compile time configuration as you pointed out in the #176 . We might be able to bypass that now since thanks to @GuillaumeGomez , we switched to rinja in #277, which comes with some really cool features and integrations of templates with Rust code.
I propose for the moment a simpler approach, where we always use CDN and we bake in directly the local version only with the opt-in flag.  Would be interested to hear your opinion.

Awesome. I just tested it and it still works as expected. I'll integrate it into Numbat as soon as the release is out. Thank you :+1:

I'll make a new release tomorrow.

Awesome. I just tested it and it still works as expected. I'll integrate it into Numbat as soon as the release is out. Thank you 👍

FYI, released 0.10.0 version just now.

Thank you! It's not integrated into Numbat :+1:


Fix log messages

Removes info and debug log messages from commons packages
add spinner for waiting until finetuning job is started
remove envelops in stream log messages
move console related functions and configuration into new module

[x] This PR references an open issue
[x] I have added a line about this change to CHANGELOG

Cleaned up loggs:

Spinner which shows up before logs are available:


acseo_typesense.yml : l48 TYPESENSE_URL => DATABASE_KEY

I think in acseo_typesense.yml example, copy and paste was made too fast.

Hello @etienneleba and thank you for this PR :)

No worries, thank you for this bundle :D


Easier way to skip binary files.

While using gulp-file-include, I think we must set src with !*.{jpg,png,jpeg,gif,bmp,woff,eot,tff...} to make the process skip compile binary files.
Maybe it will be better if add a param in options just like some others plugins . { skipBinary : true }
Or is there anyway to do this but I didn't find it in documentation ?

Do you use a single gulp task to copy all resources?
If so, the best answer IMHO would be to have gulp tasks with their own src, pipe, and dest pipeline for each major file type. That way you can control which files are sent through gulp-file-include (and other plugins) and which ones aren't. Then create a default gulp task to do them all (using the dependency parameter). Example:
gulp.task("html", function () {
	return gulp.src("*.html")
	.pipe(fileInclude({ prefix: "@@", basepath: "./templates/"}))
	.pipe(gulp.dest(destFolder));
});

gulp.task("styles", function (callback) {
	return gulp.src("*.css").pipe(minifyCSS()).pipe(gulp.dest("output/"));
});

gulp.task("scripts", function (callback) {
	return gulp.src("*.css").pipe(uglify()).pipe(gulp.dest("output/"));
});

gulp.task("binary", function() {
	return gulp.src("*.{jpg,png,jpeg,gif,bmp...}").pipe(gulp.dest("output/"));
});

gulp.task("default", ["scripts","styles","html","binary"], function (callback) {});


 with marker class for the whole template content

Remark wraps a template for a given slide with <p> tag(s). It is placed before a slide content and can by default a margin which move the header of that given slide away from the top border (see here).
As <p> is created for every element (an therefore first-of-type can be tricky) it would be good to have a <div> with a marker class (or anything else you think will be appropriate) for the whole template content to be used to remove a margin (or do anything else) from a template content.

Things look fixed in the other issue.
I personally find my way with CSS, with any kind of trick like b:first-child or a > b or even removing all margins then re-adding them when needed.
If you have trouble implementing the trick, let me know then we'll have a look and document that in the wiki.
Cheers,


ISPN-7513 AbstractClusteredWriteSkewTest can fail randomly still

Tries inserting different keys if first set fails

https://issues.jboss.org/browse/ISPN-7513

Created #4894 as well to do evict.

Please upgrade to 2.4. There was a rare race condition that I overlooked, but the Solr guys helped track it down.
I also put a slide deck together. Of interest might be the idea of using a timer wheel for per-entry expiration.

@ben-manes Sounds good.  I will check it out, thanks!


Inscriptions not getting sent to mempool

Issue has been plaguing me while inscribing. Not sure what causes it but on some inscriptions iIsend, the txns ever get broadcasted to the mempool. Have lots of funds just locked up because of this :/

When you do ord wallet transactions, do you see the transactions that haven't been relayed to the mempool?

Yes it gives me the txn hash but confirmations = 0. When I looked for the specific txn hash in the mempool, it returns as it not been sent yet.

How are you looking for the transaction in the mempool?

I have. It says transaction not found. Here's an example of one of these txns. I'm running on windows
https://mempool.space/tx/bcfff2bdef3d41c5b8a5abaf48e45b7f3936822018c58bde2fea8ace38281e1a

The mempool is currently quite full, so if you are paying a very low fee rate other nodes won't let your transaction into the mempool. At the moment there is not much you can do until either the mempool clears or we implement RBF. You can probably also try to cancel the transactions with bitcoin-cli but I would not recommend that because you might lose your already made inscriptions.

The problem is that I've not been using any low fees. For all the stuck txns, I used a fee rate between 15-20

Can you find the transactions in your local mempool?
bitcoin-cli getrawmempool | grep <TXID>

I know this is old AF, but I'm in the same boat (but linux). Fees have been in the 50s for hours and I set mine to 65 about 4 hours ago. It does show the tx in that local mempool when I tried that command you suggested. What does that indicate?

This could mean that your local node is not sending out your transaction for some reason. Try restarting bitcoind. You can also check if you have peers that are connected to you by doing bitcoin-cli getpeerinfo

Thanks heaps mate, I'll look in that direction. Cheers for taking the time.


PDS removal, Maintainer tools

List of improvements in this PR:

[x] PDS tooling is removed, since we just decided to archive with Astromat instead of PDS. This will be much easier.
[x] Maintainer tools to update pgdtools with a new release have been added. This should allow us to create new releases fast in a semi-automatic way.

Create techniques file
Create references list
Create db.json file for databases

[ ] Tests for the maintainer tools

Codecov Report

Merging #3 (047526d) into main (2fcb152) will increase coverage by 6.95%.
The diff coverage is 19.44%.

@@            Coverage Diff             @@
##             main       #3      +/-   ##
==========================================
+ Coverage   53.04%   60.00%   +6.95%
==========================================
  Files          13       11       -2
  Lines         756      560     -196
==========================================
- Hits          401      336      -65
+ Misses        355      224     -131

Flag
Coverage Δ

unittests
60.00% <19.44%> (+6.95%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

noxfile.py
0.00% <0.00%> (ø)

pgdtools/maintainer/excel_tools.py
15.38% <15.38%> (ø)

pgdtools/__init__.py
100.00% <100.00%> (ø)

pgdtools/maintainer/__init__.py
100.00% <100.00%> (ø)


Release 0.7

Version 0.7 will include at least:

Dependency updates: Tonic 0.4, Tokio 1.0, Bytes 1.0
Introduction of pre-vote phase
Change the internal serializer

done.

done.


Remove GCP Dependencies via Pulumi

Is your feature request related to a problem? Please describe.
In order to deploy in non-GCP environments the following variables need to be set in several of the deployment yaml manifests:
        - name: ENABLE_TRACING
          value: "false"
        - name: ENABLE_METRICS
          value: "false"

Describe the solution you'd like
Use a transformation in the __main__.py file for the Bank of Anthos deployment to check for this variable, set it to false if it exists, and add it if it does not exist.
Describe alternatives you've considered
Currently, the files are edited manually in the repo. This is not ideal, as it's a step that will need to be performed each time Google updates the BOA deployment.
Additional context
None.

Files needing to be modified:

balance-reader.yaml
ledger-writer.yaml
frontend.yaml
user-service.yaml
transaction-history.yaml

Closing; the forking of Bank of Anthos --> Bank of Sirius as obsoleted this request. We now have full control over the manifests.


Request Workset not working

Clicking the "Request Workset" button provides no response - no new workset is provided on campaigns that still have work to be done, campaigns that previously would provide a message on how there are no more worksets do not.

Thanks for reporting!  Which campaign did you observe this bug with?

Edit type (5k revisions) which still has worksets, and Edit type IRR (200 revisions) which I was expecting some kind of message on like I'd gotten previously as the worksets were all completed there.
On Sunday, May 29, 2016 11:34 AM, Aaron Halfaker<EMAIL_ADDRESS>wrote:

Thanks for reporting! Which campaign did you observe this bug with? —
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I've been able to confirm the issue.  I am working on this now.  It looks like we are half-way converted to a new and better method for communicating with the server and that has caused this breakdown.
I'll report back when I have a plan for solving the issue.  Thanks again.  Stay tuned!

See https://phabricator.wikimedia.org/T136520 for my work on this issue.  I've been making a lot of progress.

OK!  All seems to be working.  please re-open if you have any problems.

Great, thank you!
On Sunday, May 29, 2016 1:32 PM, Aaron Halfaker<EMAIL_ADDRESS>wrote:

OK! All seems to be working. please re-open if you have any problems. —
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


[SPARK-7219] [MLLIB] Output feature attributes in HashingTF

This PR updates HashingTF to output ML attributes that tell the number of features in the output column. We need to expand UnaryTransformer to support output metadata. A df outputMetadata: Metadata is not sufficient because the metadata may also depends on the input data. Though this is not true for HashingTF, I think it is reasonable to update UnaryTransformer in a separate PR. checkParams is added to verify common requirements for params. I will send a separate PR to use it in other test suites. @jkbradley

Merged build triggered.

Merged build started.

Test build #33202 has started for   PR 6308 at commit 2194703.

Test build #33202 has finished for   PR 6308 at commit 2194703.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class AttributeGroup (
class HashingTF(override val uid: String) extends Transformer with HasInputCol with HasOutputCol

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/33202/
Test FAILed.

Merged build triggered.

Merged build started.

Test build #33212 has started for   PR 6308 at commit e82a68a.

Test build #33212 has finished for   PR 6308 at commit e82a68a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/33212/
Test PASSed.

Merged build finished. Test PASSed.

@mengxr Small comments.  The 2 larger comments aren't critical and could be changed later.

Merged build triggered.

Merged build started.

Test build #33297 has started for   PR 6308 at commit b22faf0.

Merged build triggered.

Merged build started.

Test build #33300 has started for   PR 6308 at commit 9bd2922.

Test build #33297 has finished for   PR 6308 at commit b22faf0.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class HashingTF(override val uid: String) extends Transformer with HasInputCol with HasOutputCol

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/33297/
Test PASSed.

Test build #33300 has finished for   PR 6308 at commit 9bd2922.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class HashingTF(override val uid: String) extends Transformer with HasInputCol with HasOutputCol

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/33300/
Test PASSed.

Merged build finished. Test PASSed.

LGTM, merging with master and branch-1.4


feat: update the echo newsletter page

This PR brings an updated version of the eCHO newsletter page
TODO:

[x] fetch issue data from hubspot

@k8isdead Feel free to merge the pull request once you add the fixes. I think the rest is good to go.
Well done! 👍


OneDrive delta token-based incrementals

Tracking issue for enabling delta token-based incrementals in OneDrive

[ ] #1535
[x] #2120
[x] #2242
[x] #2243
[x] #2121
[x] #2122
[x] #2123
[x] #2124
[x] #2125
[ ] #2333
[ ] #2459
[x] #2532
[x] #2559

Testing

[x] #2264
[ ] unit tests with mocks
[ ] integration tests

Refactoring

[x] #2517

Bugs

[x] #2558

need some integration tests at the operations level prior to merging


Using App Studio

It would be worthwhile mentioning on here that the config url in the format 'https://{teamSiteDomain}{teamSitePath}/_layouts/15/TeamsLogon.aspx?SPFX=true&dest={teamSitePath}/_layouts/15/teamshostedapp.aspx%3FopenPropertyPane=true%26teams%26componentId=aa3fecf0-1fd0-4751-aba0-12314dc3a22f%26forceLocale={locale}' can´t be added into App Studio as it says it´s an invalid url format

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

ID: 10039675-218b-bd24-3b48-c95becf367fa
Version Independent ID: 4186095d-c6d3-8773-4855-3c5d0e59bfb1
Content: Create Microsoft Teams manifest manually for a web part and deploy it to Microsoft Teams
Content Source: docs/spfx/web-parts/guidance/creating-team-manifest-manually-for-webpart.md
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

Thanks for the heads up.  I'll pass that along to the AppStudio folks.

I'm experiencing a similar issue with the config url in App Studio:
Error while reading manifest.json: Invalid value(s) specified for validDomains[0]: "{teamsitedomain}{teamsitepath}"
My full URL is:
"configurationUrl": "https://{teamSiteDomain}{teamSitePath}/_layouts/15/TeamsLogon.aspx?SPFX=true&dest={teamSitePath}/_layouts/15/teamshostedapp.aspx%3FopenPropertyPane=true%26teams%26componentId=d162bc8b-93a4-4bb9-97c1-bc06d4ff975b%26forceLocale={locale}"
Any updates on this issue?

This is an issue even outside the app studio. it's not resolving the {teamSiteDomain}{teamSitePath}. When I attempt to load the web part to a tab, the url does not resolve and just fails the network request, so it's https://_layouts/15/TeamsLogon.aspx.
Any update on this?

I believe you need to install the app, then load it. You can't do both at the same time. Try going to ... => Manage Team > Apps > upload and install the app package. Once you've done that, try adding it as a tab.

it's almost impossible to actually complete this. the solution fails to sync from sharepoint so trying to install via app studio doesn't work b/c the urls.

Has anyone actually successfully installed a teams app using this method? from the invalid wildcard domain issue and this issue with the {teamsitePath} invalid urls, this is impossible. Why even have this documentation up?

I am still facing the issue mentioned by @cfitzsimonds . Not able to create a App from App Studio as well i see "Sync to teams" greyed out, even after mentioning "TeamsTab" under supported host in SPFx solution.  Webpart manifest


chore(release): v0.9.2 🎉

:robot: I have created a release beep boop
0.9.2 (2024-04-24)
Bug Fixes

omit: ensure omit satisfies Omit standard type (90552cc)
pick: ensure pick satisfies Pick standard type (cc4fd3d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ehmpathy/type-fns/releases/tag/v0.9.2 :sunflower:


Master Server and NAT consumes a lot of processing time

Version Number and Operating System(s):
Master Server and NAT from develop branch, Hosting: Windows Server 2012 / Ubuntu / Windows 7
Expected behavior:
Dont consume so much processing power
Actual behavior:
100% core load
Steps to reproduce:
Run.
[Optional] Discord Username:

Seems like a threading issue, need to make sure to relieve the CPU on the various threads.

Fixes on develop


Setup - Need S3 object read permission

As per instructions, I was trying to copy the file and errors out.
aws s3 cp s3://public-qubole/lambda/spark-2.1.0-bin-spark-lambda-2.1.0.tgz s3://myBucket-xxx/spark-on-lambda/spark-2.1.0-bin-spark-lambda-2.1.0.tgz --acl bucket-owner-full-control
Error:
fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden
Could you provide appropriate access for the users to access the neccesary files.
Thanks
Vali

Can you try running aws s3 ls s3://public-qubole/lambda/spark-2.1.0-bin-spark-lambda-2.1.0.tgz? I tried with a different set of keys and the copy worked.

Yes, certainly i am able to list the object and infact many other objects
under that hierarchy. But the copy doesn't work. I checked with AWS support
and they confirmed that the owner object permission is not properly set for
it to be copied. Let me know if you have any questions.
Thanks
Mahaboob Vali Shaik
On Thu, Dec 7, 2017 at 2:36 PM, Venkata krishnan Sowrirajan <
<EMAIL_ADDRESS>wrote:

Can you try running aws s3 ls s3://public-qubole/lambda/
spark-2.1.0-bin-spark-lambda-2.1.0.tgz? I tried with a different set of
keys and the copy worked.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/qubole/spark-on-lambda/issues/1#issuecomment-350071575,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMmZZJm7aWczsoz4OVv2hUA3xUAXamKOks5s-D4lgaJpZM4Q55fM
.

Alright, that was an issue from our side, the keys owner didn't allow public to do GET operation. I think now it should be fine, we changed the owner permissions. Can you please try again and let us know if that fixes the issue?


[cinder-csi-plugin] Update debian-base image

What this PR does / why we need it:
The PR updates the base image with us.gcr.io/k8s-artifacts-prod/build-image/debian-base-amd64:v2.1.0 as minimal base - ref https://github.com/kubernetes/kubernetes/tree/master/build/debian-base
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

/ok-to-test

@ialidzhikov Thanks for updating . Could you update .zuul.yaml to run cinder job when dockerfile is updated, so that we can make sure latest update doesnt break anything?
https://github.com/kubernetes/cloud-provider-openstack/blob/master/.zuul.yaml#L59 , just add the line
cluster/images/cinder-csi-plugin/.* , that should run required jobs

@ramineni, I force-pushed. Did the run the required jobs?

/retest

@ramineni, I force-pushed. Did it run the required jobs?
Did a retest , triggered the jobs now

/lgtm

/lgtm
/approve


Add accept and validate methods

this PR is needed in order to complete the task

Add validate and accept functions to support acceptance of transfers

defined in LNP-BP/rgb-sdk#2
N.B. this is a draft because first LNP-BP/rust-lnpbp#146 needs to be merged and then rust-lnpbp will need a new release
N.B to merge this we need to do a release of rgb-node (containing LNP-BP/rgb-node#99)

Consignment serialization as string is a very bad idea: the file can be of many tens of megabytes in binary form and will grow x10 with JSON/YAML. That's why serde serialization is not needed and it must be passed as a binary data using strict encoding format (i.e. from integration point of view, it is just a byte slice/array, read by the app from either file on network)

@dr-orlovsky I've changed the code to construct the Consignment object directly reading the file (using rgb::util::file::ReadWrite). I hope it's what you meant

@zoedberg sorry for poorly explaining the idea. I meant that we just need to pass consignment as a byte array. It will be up to a wallet to read it from a file or receive from network.

sorry for poorly explaining the idea. I meant that we just need to pass consignment as a byte array. It will be up to a wallet to read it from a file or receive from network.

I am sorry, I didn't understand that the consignment can also come directly from the network as a byte array. if so, it makes sense to receive bytes in the sdk

This indicates that the length of the consignment is less than the actual consignment data. Which is strange. The other possibility is that the consignment bytes got modified, which is even less probable

trying to validate the same consignment via cli I receive: Server returned error: Failure { code: 3, info: "ServiceError { domain: Stash, service: Contract(\"fungible\") }" }
also, I don't know if it's expected, but the last 6 bytes of the consignment are zeroes

Where the consignment is coming from? Can you try to generate a new one or take the one from the latest RGB Node master?

Where the consignment is coming from? Can you try to generate a new one or take the one from the latest RGB Node master?

The consignment should come from rgb-node v0.1.1.
I've generated a new one from master and I'm still receiving the StrictEncoding(Io(UnexpectedEof)) error. Also in this case the last 6 bytes of the consignment are zeroes

I'm afraid the consignment is too old; it's not a part of the release and just a sample file which was probably generated with some prev version with a breaking changes afterwards (I made few just before 0.1 release and probably after 0.1 and before 0.2). You may try the new consignments from https://github.com/LNP-BP/rgb-node/tree/master/sample but they might also not work and in that case we need to generate a new consignment with the latest version

I'm afraid the consignment is too old; it's not a part of the release and just a sample file which was probably generated with some prev version with a breaking changes afterwards (I made few just before 0.1 release and probably after 0.1 and before 0.2). You may try the new consignments from https://github.com/LNP-BP/rgb-node/tree/master/sample but they might also not work and in that case we need to generate a new consignment with the latest version

I think you've misread me. I'm not recycling some old or pre-generated consignment, I've generated my self a new one using rgb-node built from latest commit on master (c689dcb). So I think there's some bug at consignment creation or at validation time.

Hm, v0.1.1 is not the latest master though... Can you check the consignment locally with rgb-cli accept ...?

Hm, v0.1.1 is not the latest master though... Can you check the consignment locally with rgb-cli accept ...?

I think you're still misreading me, or I'm not explaining my self well. so this is a recap of my tries:

the first consignment I've tried was coming from v0.1.1
the second consignment I've tried was coming from master which at the time was on commit c689dcb (which is way after the v0.1.1 tag)
the third and last consignment I've tried is coming from v0.2.0-beta.3

with consignment created from v0.1.1, validation, from both cli and sdk, was not working.
with consignment created from v0.2.0-beta.3, both validation and acceptance work from cli (but not from sdk)

Ok, thank you for all details! Not it is clear. With this information the important part is that we have a situation where the consignment is correct (since it is validated by the RGB Node), but SDK fails to process it. I am talking about this case:

with consignment created from v0.2.0-beta.3, both validation and acceptance work from cli (but not from sdk)

The rest is not important, clearly the bug is in SDK. May be it links the wrong RGB node version? Does not seem so, but let's try to clean target dir, do cargo update and try again. If this will not work it means something is wrong in the code with length parameter, and I wil look into the implementation once again trying to find out what it could be

Can you pls also check that the per-byte value of the consignment after all conversions matches file data?

yep ;) done since the beginning:

currently the call to strict_decode returns a StrictEncoding(Io(UnexpectedEof)) error, but the logged consignment_bytes seems to match correctly the bytes of the consignment file (retrived by hd)

The rest is not important, clearly the bug is in SDK. May be it links the wrong RGB node version? Does not seem so, but let's try to clean target dir, do cargo update and try again. If this will not work it means something is wrong in the code with length parameter, and I wil look into the implementation once again trying to find out what it could be

IMO it's not an issue related to dependencies or to length either, since all bytes match the ones in the file.
are we sure this is not a bug in the strict_decode method?
Calling validate
[2020-11-26T14:42:24Z TRACE rgb] consignment bytes: [4c, 82, bf, 53, 0, 0, 2c, f, 28, 29, 4, 33, 16, 41, 9, 61, 3a, bf, 55, ae, a8, 1c, 4c, 7d, a8, e4, 1a, 2d, 2, c7, 26, 82, 78, ec, 53, 95, 48, 3e, 1, 0, 99, 0, 43, 49, 7f, d7, f8, 26, 95, 71, 8, f4, a3, f, d9, ce, c3, ae, ba, 79, 97, 20, 84, e9, e, ad, 1, ea, 33, 9, 0, 0, 0, 0, 7, 0, 74, 65, 73, 74, 6e, 65, 74, b, 11, 9, 7, 4, 0, 74, 65, 73, 74, 2, 0, 74, 62, 9d, 47, 9c, 47, 1, 0, 0, 0, ec, 1, 1c, 0, 0, 22, 2, 0, 0, 0, 0, 0, 0, 4, 0, 74, 42, 54, 43, c, 0, 54, 65, 73, 74, 20, 42, 69, 74, 63, 6f, 69, 6e, c, 0, 54, 65, 73, 74, 20, 73, 61, 74, 6f, 73, 68, 69, 0, e1, f5, 5, 0, 0, 0, 0, 43, 49, 7f, d7, f8, 26, 95, 71, 8, f4, a3, f, d9, ce, c3, ae, ba, 79, 97, 20, 84, e9, e, ad, 1, ea, 33, 9, 0, 0, 0, 0, 0, 1, 1, 5, 0, 0, 0, 1, 0, 21, 4, 0, 55, 53, 44, 54, 1, 0, 1, 0, 21, a, 0, 55, 53, 44, 20, 54, 65, 74, 68, 65, 72, 3, 0, 1, 0, 0, 0, 4, 0, 1, 0, b, dc, e3, b8, 5f, 0, 0, 0, 0, a0, 0, 1, 0, 3, e8, 3, 0, 0, 0, 0, 0, 0, 1, 0, a1, 0, 1, 3, 1, 0, 1, 0, a0, 5, 4f, b8, b8, 9c, a8, e7, 9b, 9e, a4, 1d, a0, ba, a5, 36, 59, f6, 8a, 25, 41, 73, 63, de, a2, e6, ff, 43, 9f, b5, b4, 12, ee, 71, 83, 9, a8, d0, a2, 5a, 0, 0, 0, 0, 3, e8, 3, 0, 0, 0, 0, 0, 0, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, d9, ad, e3, 5f, f8, 75, 7b, a6, 30, 27, 76, cb, ad, 20, 32, 5, 93, c4, 80, 88, 10, 5c, 82, 10, 28, 1a, d5, d7, 13, 7a, 5d, 44, 83, 3a, 99, 40, 7, 51, ff, 7e, d7, 39, ef, ec, 6b, 4e, b9, 12, a, 47, d7, 2a, 29, 77, 88, 3d, b0, 14, 7f, c6, 43, ea, d3, d0, 1, 0, f0, a9, b9, 94, ee, 3, 84, d9, f, 30, 9a, 6d, 6a, 59, 93, 3, 1a, 43, ef, bb, 1a, 78, 7e, f2, c8, c3, 13, 49, a3, 5a, 8a, 4d, 3, 0, 1, 2a, 90, c2, 14, c8, 24, fa, b, 60, f0, 45, 4c, 30, 59, e9, c3, fd, 92, 40, a8, cb, de, a, 31, bd, fe, f0, 73, 25, 8b, ef, 82, d9, ad, e3, 5f, f8, 75, 7b, a6, 30, 27, 76, cb, ad, 20, 32, 5, 93, c4, 80, 88, 10, 5c, 82, 10, 28, 1a, d5, d7, 13, 7a, 5d, 44, 0, a1, fa, 31, b6, c4, 7b, a3, 97, 79, 16, e7, f8, f2, 4f, 1f, c, 70, 23, fd, ce, cb, db, 22, 66, 59, 4d, 10, a7, 0, c, 89, 5e, 0, 5, eb, 85, a1, a2, 52, c9, 5e, 65, 77, 3d, ea, 65, f7, dc, a8, b4, c7, 25, f, 4f, cd, ca, 78, 12, 8c, ae, 9d, 29, de, d5, d9, 1, 22, 7b, 15, 62, 9b, d3, ae, 9e, 3, 9e, ff, 1f, 54, 7a, 1d, 5f, 92, df, a2, ba, 7a, f6, ac, 97, 1a, 4b, d0, 3b, a4, a7, 34, b0, 31, 56, a2, 56, b8, ad, 3a, 1e, f9, 0, 0, 0, 0, 0, 1, 0, 2a, 90, c2, 14, c8, 24, fa, b, 60, f0, 45, 4c, 30, 59, e9, c3, fd, 92, 40, a8, cb, de, a, 31, bd, fe, f0, 73, 25, 8b, ef, 82, 1, 0, a1, 0, 1, 0, 0, 0, 1, 0, a1, 0, 1, 3, 2, 0, 3, 0, fd, 66, a, 1e, e6, e, a4, fc, 1a, 94, e4, 8, de, 6, 8f, 3b, 2, 9c, 5b, f2, 2f, 2e, 7f, 47, ea, e7, 22, d6, 26, 6a, ed, 16, 7d, ca, f, 8d, a8, ce, 5, c, 1, 0, 0, 0, 21, 0, 8, 92, 69, 5d, 33, b3, 9c, 2b, f, 5d, 4, 92, 21, b7, 4e, 9b, 1, e8, 34, 3d, 4, 93, d2, 1, 71, 10, fa, f5, 29, 18, 69, fc, 18, a3, 2, b2, 9f, d8, d3, 2b, 18, 51, 12, c6, 42, 5, be, 27, 17, ac, 63, d2, 2b, 3, 50, 5f, b8, 72, 42, 17, 27, 96, 21, ad, 82, 19, 74, 33, 8f, 44, 39, e7, fd, e0, 81, 18, 6f, 9e, 4c, 31, 2a, dd, 82, 76, 81, 36, e4, fe, 16, 9c, af, 91, b6, 80, bc, bc, 12, 38, 65, 2, 38, 40, 43, 5, 75, 7c, 15, 50, d3, 23, 9d, 91, c8, 9a, 8e, 6a, da, 8d, 4a, f1, 36, 97, 66, f3, a2, c5, 32, a, a0, 1c, ac, 8c, 3f, c, c4, b4, 8d, 8e, fd, 54, b2, 3c, 97, ea, c, 59, 50, 6f, ef, d, d2, 23, 7b, cd, 6f, 3b, 93, c5, 3, 9a, ed, c3, 68, 43, 45, 28, 83, f3, ef, 17, 1c, 69, 70, ea, 13, 94, 5b, d3, 1, 6d, 28, f6, 8b, 90, f6, 7e, 73, ae, 4b, da, d0, 4, 2c, 7c, d8, 59, fc, c8, a8, f5, 4e, 87, 2e, 26, 9f, 9f, 0, e5, bf, 1c, 91, de, 40, 70, 5a, c, 37, ad, 7b, 6c, 86, d1, 94, e1, 96, f6, b, e2, ba, 90, 1, 47, 67, 49, 82, 9e, 23, ca, 19, aa, 8c, c3, d9, 8, 50, 96, 26, ed, f9, a5, 4a, e5, d, 29, 31, 49, 5, a9, 91, c9, 8f, c8, 9f, 27, 9c, 9b, 4f, c2, d6, 36, d3, 6b, 8e, 86, f2, 18, ff, eb, d3, 4, 32, e7, ff, 81, 30, eb, d, 1, 49, e5, 93, d, f, 35, a5, e0, 1b, 62, c3, ed, 45, ae, 22, 79, b1, a8, 47, 40, e7, fa, 4c, c4, fe, cb, ae, c8, 94, c0, bc, 5c, 41, a3, 30, 74, 55, 7a, 63, c0, 48, e5, 8a, 38, ac, 96, 3b, fc, 0, b5, fe, 8d, 58, 75, dc, f5, a6, 1c, b8, e2, 5d, 97, e, 64, c8, 2c, 2b, 8d, 8a, 6d, 8f, 75, 59, a1, 70, d1, 9d, 1c, 43, d4, e8, 8, 91, f4, 38, d5, 21, 9c, ce, bb, a7, 11, c6, 11, 7a, 6f, f0, 4, 41, f8, 9e, 2, 25, f0, 2d, dd, 3d, 15, e7, 99, 80, ae, bc, 60, 3c, 70, 58, ae, b6, 9, 73, c6, 67, b1, c6, fb, b6, 1, e6, e6, 5b, cb, 79, b3, 78, e2, 54, 14, c2, af, 8e, 5b, db, 38, 2e, 4e, e3, e2, bf, 7a, 35, b5, 15, 5f, 51, 25, b, c7, 16, f1, c3, 32, b8, 54, bb, ae, c7, be, 4e, d6, 79, 9d, e4, 44, 99, 86, 5b, d, 6f, 5, 20, 28, 9, a9, cb, eb, 14, 6b, 73, 15, 8d, db, c5, 47, 5c, d8, 4c, 98, c2, 50, 8f, 3c, 3a, e5, 98, 88, d6, ec, 76, 19, da, 56, dc, 24, fd, 9e, fc, c5, f4, e, 74, 2d, a, 80, c9, d6, 4d, 77, 44, 18, 87, 46, 8b, fb, 84, 24, 4b, 23, 61, 27, 0, 3e, f3, 14, b, 59, fd, 5f, 65, 5b, df, b, ed, fa, f3, cd, 3, 3b, c6, 9c, 5e, 26, 46, 8b, b0, f0, fc, 2, e4, 4a, 84, 86, 48, 54, fe, 75, e1, 5b, e8, a9, 34, 83, 70, 5f, 79, 98, 30, 87, 20, a, d2, 5, 6b, 79, d7, 37, 4d, b8, 9, d7, 6b, 9f, bc, 20, c5, 5b, 60, 55, 63, 7f, fc, b0, 8f, f8, 1e, 40, d1, 3c, 7a, e7, 69, b, 0, 50, f2, 4d, 33, 63, 46, 29, 1d, 42, 70, 47, 82, 79, 3a, d2, 74, 7a, e6, fb, 23, 93, f9, be, c5, fe, 89, 6a, 72, 1a, 4c, 38, 66, 49, 7b, df, 14, 75, f0, bb, 5c, 62, 80, c7, 2c, 3f, b, 6f, fb, e0, 42, 3c, 46, 3f, ae, 68, 1f, 3c, 96, f8, 68, 68, 3a, 93, dc, fa, 5a, 55, b6, a0, ca, a0, 86, 66, d2, e6, 77, c2, 8b, d9, ee, e6, 72, de, a7, 7b, e5, 25, d7, 97, 45, 23, 40, d9, 42, d7, f6, d, 7d, 97, 2, 83, 3a, 99, 40, 7, 51, ff, 7e, d7, 39, ef, ec, 6b, 4e, b9, 12, a, 47, d7, 2a, 29, 77, 88, 3d, b0, 14, 7f, c6, 43, ea, d3, d0, 3, 64, 0, 0, 0, 0, 0, 0, 0, 20, 0, 88, ef, 87, ee, f7, fb, 1b, f3, 5c, d2, fc, 1d, 1d, bd, 13, c2, 68, 1a, 4a, 41, 43, cd, 95, b5, 21, 8, e8, 89, a3, d1, 1c, 63, 0, 0, 0, 0, 0, 0]
ERR: StrictEncoding(Io(UnexpectedEof))

Well, we can't be sure in anything, but we have a plenty of unit tests for strict encoding, so probably not. Anyway I see no other solution then to investigate the issue myself

Well, we can't be sure in anything, but we have a plenty of unit tests for strict encoding, so probably not. Anyway I see no other solution then to investigate the issue myself

Why so? I can debug it myself without any problems.
I asked if you were sure because you seemed pretty convinced when you wrote "clearly the bug is in SDK". I didn't want to focus on the wrong thing, wasting time (strict_decode is on the rust-lnpbp side, not on the sdk side). And yes, I understand we cannot be sure about anything, I'll take you less literally next time.

My original estimate that its and SDK bug comes from the point that it does not work in SDK but works with RGB Node. If it's true, then it's clearly an SDK bug. But the bug seems strange. If the consignment is created with the same procedure as in the demo, trying different versions, it means that something is not working which before was working/was working on other machines and passed a lot of tests. Since I know the internal structure of the consignment and can read it in binary form it seems I need to go through the debugging since it will take much more of your time then me.

Can you pls rebase since #22 got merged and add/uncomment transfer part of the demo?

Can you pls rebase since #22 got merged and add/uncomment transfer part of the demo?

I've rebased it. But this is not ready to be merged since we need to fix consignment decoding first
About the transfer part, I've already answered to this request here: https://github.com/LNP-BP/rgb-sdk/pull/22#discussion_r536812668

@zoedberg can you pls point me out which part of the code / demo app fails with the consignment validation error?

@zoedberg can you pls point me out which part of the code / demo app fails with the consignment validation error?

currently the call to strict_decode returns a StrictEncoding(Io(UnexpectedEof)) error

or do you want me to check which line inside the strict_decode method is failing?

Call from where? Can you point me the line where it fails — if it fails in external repo, the line in this repo which calls the external one and fails?

This app has a dozen of executables, which one you have tested with the transfer?

Call from where? Can you point me the line where it fails — if it fails in external repo, the line in this repo which calls the external one and fails?

this call fails: https://github.com/LNP-BP/rgb-sdk/pull/21/files#r536818906 (don't know which line of that method is failing, since I've stopped debugging this to let you do it)

This app has a dozen of executables, which one you have tested with the transfer?

I'm not sure what do you mean by executables, are you referring to demos? If so, you can see from the changes introduced by this PR that I've changed the swig interface only for node.js (as I told you, I wanted to be sure you liked the array solution before applying it to all bindings)

Of course it will not work! The consignment file is not the same as binary consignment serialization: it has 4-byte "magical number" prefix preventing from re-interpreting file date into other wrong type. That's why all RGB data structures that can be written/read from files implement read_file method, which should be used instead of using strict_decode directly when reading from a file.
https://github.com/LNP-BP/rgb-node/blob/master/src/cli/fungible.rs#L281
Also it's a bad idea to pass consignment data in-memory, since they may be up to gigabytes. They must be always passed as a file

File interface implementations: https://github.com/LNP-BP/rgb-node/blob/master/src/util/file.rs

Fix: https://github.com/zoedberg/rgb-sdk/pull/1/files

The consignment file is not the same as binary consignment serialization: it has 4-byte "magical number" prefix preventing from re-interpreting file date into other wrong type.

can't we just add the prefix in order to fix this?

Also it's a bad idea to pass consignment data in-memory, since they may be up to gigabytes. They must be always passed as a file

this confuses me. I was reading the consignment from file, but then here (https://github.com/LNP-BP/rgb-sdk/pull/21#issuecomment-727928794) you told me:

sorry for poorly explaining the idea. I meant that we just need to pass consignment as a byte array. It will be up to a wallet to read it from a file or receive from network.

which for me was a good reason to pass it as a byte array. what made you change your mind?
moreover I can't understand the reason "since they may be up to gigabytes". those bytes will end up in a variable read/manipulated by the code anyway, it doesn't matter if you receive a file path or directly an array of bytes

Can we start with accepting my fix so I can merge this PR and start using the code? Long discussions explaining everything are good, but we need code to be done/completed first

can't we just add the prefix in order to fix this?

Sorry add prefix to where?
About consignments: my point was that they can be large so once they are in the memory we definiitely should not transform them into/from JSON, or even copy them byte by byte, and we had a long discussions on the matter. Later I found that I already had a direct API for reading consignments from files in RGB Node and that it was created with the future in mind (and it's not the case that you always need to read the whole file into the memory instead of seeking through it). Since I wrote more then 200k of lines of rust code for RGB over last year it is hard to remember everything that you have already done, that's why I have not just said to you "use the file interface" since I have not remembered that it's there already. However this was discovered while I was fixing the issue you had with consignment reading and which wasn't solved for weeks - it was solved by simply looking into the code in RGB Node cli which does the same task (and which you pointed out that "is working").

Sorry add prefix to where?

you said:

The consignment file is not the same as binary consignment serialization: it has 4-byte "magical number" prefix preventing from re-interpreting file date into other wrong type.

so my question was: is it possible to add this 4-byte "magical number" prefix to the array of bytes that we receive from the sdk user? but the correct question should have been: isn't it just possible to skip those 4 bytes when reading the file?

About consignments: my point was that they can be large so once they are in the memory we definiitely should not transform them into/from JSON, or even copy them byte by byte, and we had a long discussions on the matter.

actually I don't recall a long discussion on the matter, you told me that JSON serialization of Consignment was a bad idea and so (an hour later) I changed this PR in order to retrieve it from file (my comment: https://github.com/LNP-BP/rgb-sdk/pull/21#issuecomment-727913484). but then you told me that the consignment could also have come from the network, not only from a file, so it would be better to pass it as a byte array. therefore I did so, using the strict_decode method you suggested me here
so I'm asking you, what made you change your initial consideration? I think it was good and we should stick to that.

Later I found that I already had a direct API for reading consignments from files in RGB Node and that it was created with the future in mind (and it's not the case that you always need to read the whole file into the memory instead of seeking through it). Since I wrote more then 200k of lines of rust code for RGB over last year it is hard to remember everything that you have already done, that's why I have not just said to you "use the file interface" since I have not remembered that it's there already. However this was discovered while I was fixing the issue you had with consignment reading and which wasn't solved for weeks - it was solved by simply looking into the code in RGB Node cli which does the same task (and which you pointed out that "is working").

actually, the direct API for reading consignments from files that you are mentioning, is the same API I initially used for this PR. but I understand you cannot remember everything, that was not my point. my point is: days ago you gave me a good reason to not read the consignment file, now you're saying that it's the correct thing to do. was "Maxim of 21 days ago" wrong?

Can we start with accepting my fix so I can merge this PR and start using the code? Long discussions explaining everything are good, but we need code to be done/completed first

I've requested some changes to your fix, after applying those I will accept it so you can merge this PR.
I still think that passing the byte array is the best solution, since, as you pointed out, the consignment could come directly from the network. and I would like to understand the reason for your change of mind.
I understand and agree we cannot do everything in the best way, and if currently strict_decode is bugged and requires too much time to be fixed, it's faster to keep the solution that reads it from file.

applied some minor fixes to node.js demo and linted code, ready to be merged


fix(shim-sev): Max physical memory determined by C-Bit

Handling of physical addresses > 1 << C-Bit would be tricky,
so just limit the maximum.
Signed-off-by: Harald Hoyer<EMAIL_ADDRESS>

@haraldh This needs a rebase.