text:
using getResourceEntry()

I'm trying to get all the resources of an app..
https://github.com/caoqianli/apk-parser/blob/master/src/main/java/net/dongliu/apk/parser/struct/resource/Type.java#L30
the getResourceEntry method requires an $id argument...
I'm wondering what ID is this... is this the resource id or package id?
and how are we able to get the Resource ID list?
Can I recommend?
is it possible for you to add a getAllResourceEntries() method that we can use to fetch all resources under that specific type?

The id of Type.getResourceEntry argument is the resource entry index, which is the last two bytes of resource id:
resourceId(4 byte) = packageId(1byte) + typeId(1byte) + entryIndex(1byte)

All entries of a type can be get by:
        long[] offsets = type.getOffsets();
        for (int i = 0; i < offsets.length; i++) {
            ResourceEntry resourceEntry = type.getResourceEntry(i);
            if (resourceEntry != null) {
                // ...
            }
        }

Thanks!
I really have no proper understanding yet with the arsc file structure that's why I can't do byte by byte operation.
By the way, I found another package same as yours but this one is pretty much concise and it has what I need... the getting of all resources of a package.
https://github.com/WisdomSky/soot-infoflow-android/tree/develop/src/soot/jimple/infoflow/android/resources

authors: WisdomSky caoqianli

repo: caoqianli/apk-parser


text:
Update Logging Operator

Logging Operator did quiet evolve in the last few months.
Releases
https://github.com/banzaicloud/logging-operator/releases/tag/3.1.0
Discussion

Update of existing CRD might be tricky, because the CRD Version was kept

covered in #188 to 3.2.0

source: gharchive/issue

authors: fforootd stebenz

repo: caos/orbos

license_type: permissive

license_source: github-api


text:
What's the difference between yours and L3C?

Most modules are the same. I can't figure out.

The difference is in how we autoregressively predict blocks of pixels for each lossless SR step. The details are in the method section of our paper. Feel free to let me know if you have more questions.

repo: caoscott/SReC

license: MIT


text:
Issue with action execution in case when we have the same Decimal fields

I have this entity with virtual fields and bound action
entity User                 as projection on db.User {
*,
virtual null as cost                            : Decimal(10, 2),
} actions {
action Pay(
cost : Decimal(10, 2)
);
}
I am trying to execute POST request to this endpoint /User_Pay?cost=5454m
and it fails with this error

If I rename some of these fields then it works well. But I really don't want to rename them.
Do we have some solution for this?

If I put "else" here then it works but I don't know about the details. It is just a hotfix

Thanks, I will have a look.

Then it works. I will make the other case more robust, that it does not create an type error...

As it is a bound function, you need to provide the key of the User. Don't know what it is in your case, because I don't see the db.User, but you need to call the URL something like this, incase you have an ID (UUID):
User_Pay?ID=guid'<uuid>'&?cost=5454m

Thats right. I have provided the id of the User in the request

I think your fix is valid, I applied it. Next release available:
https://github.com/cap-js-community/odata-v2-adapter/releases/tag/v1.12.5
Can you check?

I think your fix is valid, I applied it. Next release available: https://github.com/cap-js-community/odata-v2-adapter/releases/tag/v1.12.5
Can you check?

Now it works. Thank you


text:
pg: add more reserved words

Postgres keywords, used for smart quoting.
Taken from https://www.postgresql.org/docs/current/sql-keywords-appendix.html

I tried out some of the claimed to be reserved words and some of them worked fine without quoting. Probably make sure that this list is aligned with the reserved words of the cds compiler.

I tried out some of the claimed to be reserved words and some of them worked fine without quoting. Probably make sure that this list is aligned with the reserved words of the cds compiler.

I forgot to mention, this is exactly the list from the cds-compiler

source: gharchive/pull-request

authors: BobdenOs patricebender

repo: cap-js/cds-dbs


text:
Update plugin to support multiple plugins in the same project

In short this pull request includes:

Support multiple plugins in the same project
Some refactoring on the web plugin to simplify the code and prepare for code reuse among all firebase plugins.

That's a very useful feature 👍🏻

Hi @mic345 Thanks for the PR! I'd prefer to see this broken into several PRs, e.g., one for TS2794, one for the script loading issue, and one for your new functionality (I've added some more comments to the pr regarding these). Can you also add a description of the use case that you are solving for?

authors: brownoxford markxoe mic345

repo: capacitor-community/firebase-analytics


text:
when we try to hot-reload and it fails, it damages the dependency tree

and the subsequent reloads can't traverse the dependency tree, failing to hot reload properly. Observed with cyclic dependencies so far.

I think this has been resolved by properly deleting the modules on failed hot reload here https://github.com/capaj/systemjs-hot-reloader/commit/0a9f98c7c60d3a018a6c263b49affa2e259d249d

repo: capaj/systemjs-hot-reloader

license: mit

license_source: bigquery


text:
seed_db task is missing

The README lists a laravel:seed_db task, but it doesn't actually exist.
Easy to work around with the laravel:artisan command, but worth noting all the same.

Happy to provide PR, but I wasn't sure if it was desired to have separate flag variables for the db:seed command, like for the db:migrate command.

I'm not necessarily against having a seed_db task, but I'm not really sure it's necessary. Migrations are something that will be run again and again over the course of an application's lifetime, whereas seeding is supposed to be used for "seeding" data into a database and usually only happens once, and in fact could even lead to more harm than good if accidentally run in a production environment.

My main reason is for seeding in a staging or test environment, but I can understand the hesitation as well.

I'm updating the documentation to reflect the lack of seed_db. I think for the time being its best not to include it as an actual task. If you ever do need to seed the database, you can just use laravel:artisan "seed:db".

repo: capistrano/laravel


text:
Azure - Errors Running Event Grid Functions

Description:
Errors appear when attempting to run the default example of Event Grid Function on the Azure documentation page. The documentation surrounding this could be more robust, it doesn't indicate what items from 'mode' from the other example templates using functions can be used with event grid functions (are all inherited?). I have tried the default policy as well as running a policy where I specify the appInsights, and StorageAccount, both custodian runs fail pointing to async_abc.py:
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/msrest/universal_http/async_abc.py", line 34
    async def __aenter__(self):

Details below.
New Virtualenv setup:
pip install c7n
pip install c7n_azure

Policy 1 being run:
policies:
    - name: tag-key-vault-creator
      resource: azure.keyvault
      mode:
        type: azure-event-grid
        events: [{
            resourceProvider: 'Microsoft.KeyVault/vaults',
            event: 'write'
          }]
      filters:
        - "tag:CreatorEmail": null
      actions:
        - type: auto-tag-user
          tag: CreatorEmail
          days: 10

Policy 2 Terminal Output:
(currentDirectory) ➜   git:(master) ✗ custodian run --output-dir=. eventgridtest.yml
2018-10-23 08:50:36,839: custodian.azure.session:INFO Creating session with Azure CLI Authentication
2018-10-23 08:50:36,840: custodian.azure.session:INFO Session using Subscription ID:subscriptionID
2018-10-23 08:50:37,990: custodian.azure.function_app_utils:INFO Found Web Application "cloud-custodian-tag-key-vault-creator".
2018-10-23 08:50:37,990: custodian.azure.AzureFunctionMode:INFO Building function package for cloud-custodian-tag-key-vault-creator
2018-10-23 08:50:39,874: custodian.commands:ERROR Error while executing policy tag-key-vault-creator, continuing
Traceback (most recent call last):
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/c7n/commands.py", line 232, in run
    policy()
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/c7n/policy.py", line 870, in __call__
    resources = mode.provision()
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/c7n_azure/policy.py", line 225, in provision
    super(AzureEventGridMode, self).provision()
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/c7n_azure/policy.py", line 171, in provision
    archive.build(self.policy.data)
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/c7n_azure/function_package.py", line 151, in build
    modules, so_files = FunctionPackage._get_dependencies(entry_point)
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/c7n_azure/function_package.py", line 270, in _get_dependencies
    finder.run_script(entry_point)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 133, in run_script
    self.load_module('__main__', fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 305, in load_module
    m = self.load_package(fqname, pathname)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 468, in load_package
    self.load_module(fqname, fp, buf, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 453, in scan_code
    self.scan_code(c, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 453, in scan_code
    self.scan_code(c, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 305, in load_module
    m = self.load_package(fqname, pathname)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 468, in load_package
    self.load_module(fqname, fp, buf, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 453, in scan_code
    self.scan_code(c, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 453, in scan_code
    self.scan_code(c, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 208, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 305, in load_module
    m = self.load_package(fqname, pathname)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 468, in load_package
    self.load_module(fqname, fp, buf, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 208, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 305, in load_module
    m = self.load_package(fqname, pathname)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 468, in load_package
    self.load_module(fqname, fp, buf, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 420, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 146, in import_hook
    m = self.load_tail(q, tail)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 223, in load_tail
    m = self.import_module(head, mname, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 305, in load_module
    m = self.load_package(fqname, pathname)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 468, in load_package
    self.load_module(fqname, fp, buf, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 305, in load_module
    m = self.load_package(fqname, pathname)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 468, in load_package
    self.load_module(fqname, fp, buf, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 324, in load_module
    self.scan_code(co, m)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 443, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 342, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 145, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 201, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 293, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/usr/local/Cellar/python@2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/modulefinder.py", line 309, in load_module
    co = compile(fp.read()+'\n', pathname, 'exec')
  File "workingDirectory/eventgridtests/lib/python2.7/site-packages/msrest/universal_http/async_abc.py", line 34
    async def __aenter__(self):
            ^
SyntaxError: invalid syntax

#3024

@stefangordon
I switched to python3 virtualenv and got better results. I see that function_binding_resources is not copying to the virtualenv path, whether I do a fresh install of the cloud-custodian repo (with the file present) and do pip install ./cloud-custodian and pip install ./cloud-custodian/tools/c7n_azure or If I pull from pypl pip install c7n and pip install c7n_azure
FileNotFoundError: [Errno 2] No such file or directory: '/home/custodian/lib/python3.5/site-packages/c7n_azure/function_binding_resources/extensions.csproj'
When I copy over the function binding resources folder from the custodian project to the virtualenv path it want it at, the function app builds successfully. Is this expexted behavior for that folder to not copy over?

We need to update the setup.py to bring these files over.

PR out for it: https://github.com/capitalone/cloud-custodian/pull/3033

The fix is in @jdogg89 - you should be able to install from github (pypi doesn't have latest changes)! Let me know if you see any other weird behaviors around the dlls.

Btw, 3.5 may not work either, it may have to be 3.6 (the python version Azure functions uses) - due to the current way we package native assemblies.

3.5 definitely does not work - your function will deploy but the function will fail at runtime. I ran into this last week when I accidentally used 3.5.

authors: aluong erwelch jdogg89 stefangordon

repo: capitalone/cloud-custodian


text:
Custodian #550 s3 encryption policy filter

Here's the filter and test code.    The filter's name is 's3-encryption-missing'
Can be used with a policy like so:
policies:

name: find-buckets_missing_encryption
resource: s3
filters:

s3-encryption-missing
actions:
type: no-op

pull request #1050 addresses the same thing, and also is a bit better on impl/tests/style, going to close this one and go with that one.

authors: gfranxman kapilt


text:
resource metadata - add missing names for a few resources, and add a test to catch futures

fixes #2133

we're starting to get alot of test failures out of travis because worker processes dying.. i suspect some sort of oom setup or cgroup control on their infrastructure given its shared and over reporting core count.


text:
Less restrictive license?

Thanks for making this awesome library available! Unfortunately, the GPL license under which the code is published is very restrictive, prohibiting users from actually being able to use warrant for certain scenarios.
Has this decision been made on purpose, or is there any chance to switch to a less restrictive license, like Apache 2 license [1], or MIT license [2], for example? Thanks!
[1] https://www.apache.org/licenses/LICENSE-2.0
[2] https://opensource.org/licenses/MIT

Seconded, I started contributing before I noticed the license (dumb of me I know) but now I realize I can't use this. I've got nothing against GPL but for small utility libraries it's very restrictive. I'll probably see if I can make a wrapper around https://github.com/cocagne/pysrp

Fixed in 65160646ae0ef4418a15a9dcca240d5bd14516b7 🥂

authors: balloob pshendry whummer

repo: capless/warrant


text:
Document how to install

Request
The documentation has a Getting Started section that specifies how to integrate Carapace, but does not specify how to install Carapace.
Proposed solution
Document how to install Carapace.
Anything else?
Would love to see HomeBrew formula for this
brew install carapace

I think it's best to remove it from the readme completely and just direct people to Installation.
I've got a homebrew tap.

authors: electriquo rsteube

repo: carapace-sh/carapace-bin


text:
March release prod deployment

Merge

[ ] https://github.com/carbon-design-system/carbon-platform/pull/406

Clean up

[x] All catalog items take you to asset detail pages (because from there we link to external docs)
[x] Fix breadcrumb

Update

[ ] Asset LP release copy for 0.2 with us accomplishing:

Indexed charts, dotcom
Collection to view only charts
New data:

External docs links
Demo sites
Issue counts

Navigation (page tabs, footer) and catalog improvements (more performant filtering, type tags)

[ ] Also update roadmap beyond 0.2

@alisonjoseph I removed "Coming soon" pages per page tab task as that will be more than a couple minute effort. IMO it's okay that the tabs don't navigate to placeholder pages yet, as we have other "Coming soon..." content on the page still.

repo: carbon-design-system/carbon-platform


text:
Pattern:  Develop Lead Space pattern, default (left aligned) - final

hahnrob created the following on Aug 15:

User Story

As a [user role below]:
DDS adopter

I need to:
access to the best patterns from teams

so that I can:
execute the highest quality patterns

Additional information

Lead space designs included in Issue 1540

Acceptance criteria

[ ] Lead space patterns included in Issue 1540

Original issue: https://github.ibm.com/webstandards/digital-design/issues/1471

On Oct 01, hahnrob commented:
alpha version is included in ibm.com Library v1.0.0

On Sep 20, Anna-Wen commented:
Wonhil's comments from Alpha Leadspace PR to be addressed:

A few comments towards the final version:

needs max width (1584px per 2x grid) and max height (640px?) specs
need to allow different icons for the buttons
the two buttons need to be the same size (match the wider)
the gradient overlay needs to be optional
the gradient overlay feels a bit too strong

on sm breakpoint:

break text early instead of spanning the full width, around 3.

Lara's comments:

One thing we need to agree on is what we're calling the variation. They can't be expressive and productive because it's confusing. Can we change that easily enough?
Is it possible to have the gradient overlay layer as a knob? In some cases people may have a well-produced image that doesn't need the gradient overlay. Maybe we could turn the gradient show by default but have a knob to hide?

repo: carbon-design-system/ibm-dotcom-library


text:
feat(Datagrid): remove filter tags individually from FilterSummary

Contributes to #3402
This PR adds functionality to remove individual filter tags from the filter summary component used in the Datagrid. This change works with both the flyout and panel variants.
What did you change?
packages/ibm-products/src/components/Datagrid/Datagrid/DatagridContent.js
packages/ibm-products/src/components/Datagrid/Datagrid/addons/Filtering/FilterProvider.js
packages/ibm-products/src/components/Datagrid/Datagrid/addons/Filtering/constants.js
packages/ibm-products/src/components/Datagrid/Datagrid/addons/Filtering/hooks/useFilters.js

How did you test and verify your work?
Storybook

As a follow up enhancement, the user won't be able to close filters if it's in the dropdown

@matthewgallo Everything else looks great 🎉 🚀 Nice job on this!

authors: AlexanderMelox matthewgallo

repo: carbon-design-system/ibm-products


text:
search + select bug

Found a very reproducible error when combining a search and selection. Demoed below. To reproduce, type an ID in the search, and then click on a project that's not in the returned search results. My guess is we're indexing outside of a bounded list. Whatever the case, we should catch and handle this. The right behavior is probably just to do nothing when clicking on a project that's not in the current list of returned results.

Fixed this bug as part of https://github.com/carbonplan/forest-offsets-web/pull/87

repo: carbonplan/forest-offsets-web


text:
Black Plague NFTs

Name: Black Plague NFTs
Description: 100 Black plague NFT’s in form of art to preserve history on the Cardano blockchain.
Link:   https://darknfts.net
Source: null
Tags:
nft

Thank you for your contribution and for building on Cardano. This PR has been open for quite a while and I would like to give you a little feedback. Projects need 3 reviewer approvals and it seems the project didn't get enough "traction" among the reviewers.
Please note that showcase projects need to provide a unique value from existing showcase items - which is especially difficult with many tokens and FT/NFT or FT/NFT platforms. Feel free to join the discussion here: #243 (or in case you prefer to discuss this not in GitHub please join https://discord.gg/Exe6XmqKDx)
Suggestion: you can add your project to https://github.com/input-output-hk/essential-cardano

authors: EhtishamSabir katomm

repo: cardano-foundation/developer-portal


text:
Update package.json

Description

A clear and concise summary of the change and which issue (if any) it fixes. Should also include relevant motivation and context.
Resolved or fixed issue:
Affirmation

[x] My code follows the CONTRIBUTING.md guidelines

updated sanitize-html to v2.13.1 - critical vuln

committ

repo: caren-apiiro/juice-shop


text:
Does Carla Plugin in CarlaUnreal Project on ue5-dev branch is complete ?

dev not complete, but you can run it, still WIP

repo: carla-simulator/carla


text:
Task: Bump lnd_tonic to 0.5.1

Description
Update tonic_lnd dependency to the latest release so that we don't have to point to a specific commit (this realease includes https://github.com/Kixunil/tonic_lnd/pull/33, which we need for #16).
Steps to Complete

Bump to v0.5.1 in Cargo.toml

Hello, I will like to work on this issue. I will be creating a PR with the latest release of lnd_tonic.

authors: carlaKC ismaelsadeeq

repo: carlaKC/lndk


text:
Question: unreliable behavior spawning on threadpool

Hello,
I've been using thread pool on one of my project. However, I came across an unreliable behavior. A detailed description of what I observed is depicted here on stackoverflow
Maybe I'm not using the lib correctly, can someone give me a hand?

Oops. I posted on the wrong place. Sorry

repo: carllerche/futures-threadpool


text:
Implement ToSocketAddrs for TcpStream just like in std::new::TcpStream

ref in mio: https://github.com/carllerche/mio/blob/master/src/net/tcp.rs#L119
ref in std: https://doc.rust-lang.org/nightly/std/net/struct.TcpStream.html#method.connect
I understand that there is some logic that is private to std that cannot be re-used and
must be duplicated... bit this would be really useful when dealing with urls and domains.

One thing to keep in mind here is that the ToSocketAddrs impl for str does DNS lookup by calling gettaddrinfo(), which blocks the calling thread, possibly waiting on network I/O. So you would need to be careful when using this in eventloop-style code.

There's Rust bindings for c-ares which could solve the blocking part of this issue.
Whether this feature belongs in mio is another discussion. So far, mio has exclusively been a provider of the event loop and utilities for managing loop state (eg, Slab). At the point mio starts doing DNS resolution, it's going to be a consumer of the event loop as well.
I'm generally against it. On one hand, nearly everything I use mio for needs name lookup. However, incorporating this into mio has some drawbacks. Mio would either need to perform some allocations internally, or it could expose additional API surface in the handler and make the application deal with state for DNS lookup. I personally don't want either of those things. It's also outside the scope of what mio aims to be which is a low level event loop abstraction.
It's not too difficult for applications to do async lookup.There's an example in c-ares  for doing lookups using epoll directly; this example is pretty short, and using mio instead would shorten it further. A reusable lookup component based on c-ares could even be added for applications using rotor (allegedly rotor makes it easy to compose state machines, but I haven't tried it myself).

@jwilm awesome, thanks for the info! I agree with you
I can go ahead and close this if @carllerche agrees. Since it seems to have been added to the v1.0 milestone, I don't want to rush to close this without more feedback

On dev.

awesome! although I have kind of put a hold on my rust work recently, I am stoked this made it in. thanks for the follow-up @carllerche!

So, I should have paid more attention.. but @dwrensha  is right. ToSocketAddrs implies blocking DNS resolution. As such, it probably shouldn't be something that Mio encourages.
I reverted the patch. 7b4a7ce9a691895f146d3bb14be1ba5a7cf631ba
Sorry about that.

authors: carllerche dwrensha jwilm talevy

repo: carllerche/mio


text:
feat(bot discord): Polls

This pr introduces the following commands:
/admin poll create
Summons the poll creation modal and creates an open poll. Open polls register votes in the database.
/admin poll close
Closes a poll. Closed polls do not accept votes. Closing a poll reveals the results in a Discord message and deletes all related data stored in the database, to both preserve space and prevent keeping more data than necessary.
/admin poll votes
Gets the current votes of a poll.

Things to do before merging this pr

[x] Improve user-facing error messages
[x] Format user-facing messages
[x] Consider adding some kind of poll votes visualization (i.e. plotting bars with unicode characters, or generating an image with satori)
[x] Add a guard in the /admin poll create command for preventing the creation of polls in the same channel with the same name.

[x] When showing the poll name to a user (i.e. on autocomplete options), also show the channel name

[x] Add a guard in the /admin poll create command for invalid hex color codes
[x] Fix a bug with long poll durations automatically closing the poll on creation
[x] Fix a bug when trying to vote in poll when the bot is rebuild with the file watcher
[x] Add 🗳 Poll as message text to poll messages
[x] Add visualization to poll result ██████░░░░░░ 50% OptionName https://www.npmjs.com/package/figures

Closes #12

:shipit:

repo: carloitaben/artists-together


text:
[DOCS] adding visnights example to documentation

I Introduced a familiar example in Hyndman's book using visnights data that is already on scikit-hts-examples repo, but I really think that is more evident when at least one simple example is in documentation page so people do not need to open multiple sources to check how we apply things with scikit-hts.

I'd prefer to keep the JN in the scikit-hts-examples repo. We can keep the visnigths link as well as some minimal code samples, but the notebook should be in the other repo

authors: carlomazzaferro vtoliveira

repo: carlomazzaferro/scikit-hts


text:
TypeError: Cannot read property 'indexOf' of undefined

Hey guys,
this is my very first attempt to get Zenbot to run. I am pretty new to it and I don't understand all concepts. I am using this docker image: barnumd/zenbot
I left the config.js as it is (well I copied and renamed it of course).
This is the output I get:
02/17/2017 11:12:06 PM UTC [    launcher] cmd `launch` booting
02/17/2017 11:12:06 PM UTC [    launcher] cmd `launch` booting
02/17/2017 11:12:06 PM UTC [    launcher] cmd `launch` booting
02/17/2017 11:12:08 PM UTC [    launcher] cmd `reduce` booting
02/17/2017 11:12:08 PM UTC [    launcher] cmd `run` booting
02/17/2017 11:12:08 PM UTC [    launcher] cmd `map` booting
02/17/2017 11:12:08 PM UTC [      runner] starting
/usr/src/zenbot/utils/get_products.js:6
      if (c.assets.indexOf(product.asset) === -1) return false
                  ^

TypeError: Cannot read property 'indexOf' of undefined
    at /usr/src/zenbot/utils/get_products.js:6:19
    at Array.filter (native)
    at get_products (/usr/src/zenbot/utils/get_products.js:5:23)
    at mapper (/usr/src/zenbot/plugins/gdax/backfiller.js:12:20)
    at /usr/src/zenbot/node_modules/run-parallel/index.js:41:7
    at Array.forEach (native)
    at module.exports (/usr/src/zenbot/node_modules/run-parallel/index.js:40:11)
    at mapper (/usr/src/zenbot/node_modules/zenbrain/core/mapper/mapper.js:9:5)
    at Object.<anonymous> (/usr/src/zenbot/node_modules/zenbrain/core/launcher/launcher.js:76:11)
    at Immediate.<anonymous> (/usr/src/zenbot/node_modules/sosa/api.js:15:12)
02/17/2017 11:12:08 PM UTC [    launcher] cmd `map` exited with code 1, respawning now.
02/17/2017 11:12:08 PM UTC [    launcher] cmd `server` booting
02/17/2017 11:12:08 PM UTC [      server] zenbot/3.5.16 booted!
02/17/2017 11:12:08 PM UTC [      server] open http://localhost:3013/?secret=xxx to see a live graph.
02/17/2017 11:12:10 PM UTC [    launcher] cmd `map` booting

To me it looks like it chokes on this bit from the config:
// watch these exchanges
c.watch_exchanges = [
  //"bitfinex",
  "gdax",
//  "kraken",
//  "poloniex",
]

But why?

I'm getting the same error. Fresh install.

the config.js requires to define currencies and assets
c.assets = [
"BTC"
]
c.currencies = [
"ETC"
]

Cleaning up 3.x issues

authors: carlos8f carlosfvp levibe nicolinux


text:
Update sbt-tpolecat to 0.4.1

Updates io.github.davidgregory084:sbt-tpolecat from 0.4.0 to 0.4.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.github.davidgregory084", artifactId = "sbt-tpolecat" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "io.github.davidgregory084", artifactId = "sbt-tpolecat" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-patch, commit-count:1

Codecov Report

Merging #62 (ffa8eb9) into main (d235323) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #62   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines          316       316
  Branches         6         6
=========================================
  Hits           316       316

Help us with your feedback. Take ten seconds to tell us how you rate us.

authors: codecov-commenter scala-steward

repo: carlosedp/scalautils


text:
Index page for the lessons

It tries to add an index page for the lessons to make it easier to browse.
Maybe something similar could be done too for the downloads page.

Hi @dpshelio - we'd definitely welcome this over in offlinedata. Open an issue over there if it's helpful to chat while you're working on it.

authors: dpshelio ethanwhite


text:
QRCode fixes

adds double click on receiving address tab to show qr code
sanitized qr code window (removed the address which was spilling over width)

Looks good and merged into the master branch

authors: carsenk enkayz

repo: carsenk/denarius


text:
🛑 Data Manager is down

In db59b47, Data Manager (https://data-manager.cartelmatic.com/) was down:

HTTP code: 503
Response time: 438 ms

Resolved: Data Manager is back up in 3ef9ea6 after 5 minutes.

repo: cartelmatic/upptime


text:
🛑 Data Manager is down

In 0a1816b, Data Manager (https://data-manager.cartelmatic.com/) was down:

HTTP code: 503
Response time: 436 ms

Resolved: Data Manager is back up in dbef97b.


text:
Images/Version Tagging for Individual Carvel Tools

Currently, Carvel tools are offered in a single image without much provided into what versions of tools are available in each tag. Additionally, there are not unique images for each tool. When trying to use Carvel tools with a tool like Tekton, which allows users to specify what image(s) to run CI/CD steps in, it can be challenging to figure out how to use specific tools/versions of tools in the process.
I am wondering if there have been discussions about supporting images for individual tools and having tagging that corresponds to tool versions (k14s/ytt:v0.30.0). Additionally, it would be helpful to provide more clarity around what versions of individual tools are part of the image that supports all the Carvel tools.

I am wondering if there have been discussions about supporting images for individual tools and having tagging that corresponds to tool versions

there hasnt been any discussion around this topic afaik. current state is driven by existing use cases where multiple tools are used together (ytt + kapp, or kbld + kapp, etc.). would like to hear more about workflows that will benefit from a dedicated image that contains one tools vs just all of them.

Additionally, it would be helpful to provide more clarity around what versions of individual tools are part of the image that supports all the Carvel tools.

what kind of "interface" you are imaging for that? may be in release notes for each time new image is released.

there hasnt been any discussion around this topic afaik. current state is driven by existing use cases where multiple tools are used together (ytt + kapp, or kbld + kapp, etc.). would like to hear more about workflows that will benefit from a dedicated image that contains one tools vs just all of them.

kapp on it's own I think would make sense to support with a separate image corresponding with a specific version tag.
My original example of ytt by itself is maybe not perfect, but an image with it along with kubectl I believe would have a lot of use cases. Maybe it would make sense to wait to see if others come forward with this as well though.

what kind of "interface" you are imaging for that? may be in release notes for each time new image is released.

Release notes would be really great as a starting point. I am also wondering if there would be a non verbose way to tag the images for users that makes it simple for users to declare what versions of each tool are used. Which versions to release together and how frequently I think would need to be further refined.

I just stumbled upon the same issue, as I've desribed here before I saw this issue:

https://github.com/carvel-dev/docker-image/issues/10#issuecomment-1729992169

current state is driven by existing use cases where multiple tools are used together (ytt + kapp, or kbld + kapp, etc.).

We, too, use kapp and kbld together. While I would be happy to see separate images for each of these tools where the image-tags conform to the tool version, this is probably not really necessary anymore since kapp-controller is a thing.
The image ghcr.io/carvel-dev/kapp-controller is probably a good replacement for the docker image built by this project. I only wish ghcr.io/carvel-dev/kapp-controller would have proper image tags that follow the versions of kapp-controller. The current image tags make it hard to use tooling such as renovate for automatic update management:
$ skopeo list-tags docker://ghcr.io/carvel-dev/kapp-controller
{
    "Repository": "ghcr.io/carvel-dev/kapp-controller",
    "Tags": [
        "rand-1675057777567790718-46346116232-kapp-controller",
        "rand-1675058931368617744-1271351746218-kapp-controller",
        "rand-1675163778348920726-812368450122-kapp-controller",
        "rand-1675193814572979956-253282113186-kapp-controller",
        "rand-1675244127333236169-10210068214167-kapp-controller",
        "rand-1675245774317316042-2464820015738-kapp-controller",
        "kbld-rand-1675401201382102428-62255187123160",
        "kbld-rand-1675402840339791567-23310489178160",
        "kbld-rand-1675407352309901886-7717417023141",
        "kbld-rand-1675439880404786302-1241851372172",
        "kbld-rand-1675452368289632941-17711916793109",
        "rand-1675781866138377603-621713572123-kapp-controller",
        "rand-1675792914553031285-55133160193248-kapp-controller",
        "rand-1678460282626099075-13914813387188-kapp-controller",
        "rand-1680590094810685620-2483821750128-kapp-controller",
        "rand-1680592068259360587-2923224245119-kapp-controller",
        "rand-1681926566974979929-20313523818122-kapp-controller",
        "rand-1683901464977327408-1796785129221-kapp-controller",
        "rand-1686140184663267382-180232123394-kapp-controller",
        "rand-1686726827567580141-452638127244-kapp-controller",
        "rand-1686727096520192185-229118199458-kapp-controller",
        "rand-1686728436715212662-1451085142-kapp-controller",
        "rand-1687286425569287071-23911111561217-kapp-controller",
        "rand-1687287211927885042-24712624661102-kapp-controller",
        "rand-1689069528378621476-8918624717676-kapp-controller",
        "rand-1692209005806725957-24418352143201-kapp-controller",
        "rand-1692289561907427951-191219866131-kapp-controller",
        "rand-1692290847083382201-9613217015964-kapp-controller",
        "rand-1692291184261679450-149351989157-kapp-controller",
        "rand-1692863946420967110-245564812994-kapp-controller"
    ]
}

It's impossible to see which version of kapp-controller is included just by reading the tags.

authors: ChristianCiach cppforlife danielhelfand

repo: carvel-dev/docker-image


text:
Why "access_token" is named "token" in the implicit flow?

According to the RFC6749 section 4.2.2 (Access Token Response), the token returned should be named "access_token", but in casdoor, it is named "token"

So some clients like Swashbuckle.AspNetCore can't get the token automatically.
Is it possible to rename this parameter to "access_token" or provide a feature that the user of casdoor can customize the name?

@joezhang-sh hi, can you make a PR to fix it?

Hi @hsluoyz , sure, but from my point of view, the implementation should  comply with the specification, so I tend more to rename the token to "access_token", but that will be a breaking change for the applications already integrated with casdoor. What do you think?

@joezhang-sh no worry about breaking change. We need to follow the standard, so have to do this

authors: hsluoyz joezhang-sh

repo: casdoor/casdoor


text:
reset password with email  error

but email code is correct ,then next input password and confirm .
then I click change password again  show Missing parameter

@arrow2012 if you keep creating such simple question, I suggest you asking at Discord: https://discord.gg/5rPsrAzK7S instead of here. The github issues are for more complicated questions, bug reports, etc.

输入手机号码
手机号码无效

phone number is correct ,but invaild

please invite me disacord again

old password in db is 123456, how can I reset password ?


text:
How can I integrate casdoor and minio?

I have installed Casdoor (v1.40.0) and minio, and set it up according to this page: https://casdoor.org/zh/docs/integration/minio/  (same as https://casdoor.org/docs/integration/minio/ ) . The article prompts me to set "tag: readwrite", but the field is not available in Casdoor's admin console and cannot be set. Skip this step and continue to set up, it seems to be smooth, but finally after clicking "Login With SSO" on the minio console, an error is reported: Error from IDP
An error occurred, please try again
None of the given policies (staff) are defined, credentials will not be generated

Done, modify the user's "tag" and change the default value of "staff" to "readwrite".

@Abingcbc do we need any fix on our side like code or docs?


text:
give users convenient way to do for loops

Add something like range generatore so they can do
for (_ in range(10)) {
}

instead of for loop bullshit.

Done in #352

authors: casey terror

repo: casey/degenerate


text:
Using variables in recipe parameters

I noticed it's not currently possible to do something like:
first_path := "foo"
second_path := "bar"

copy file:
    cp {{file}} /tmp

setup: (copy {{first_path}})
    some_cmd

setup-dev: (copy {{second_path}})
    other_cmd

Is this by design or just something that no one has added support yet? In my real life example I have two top level commands that currently take string values for file names.  I would like to define those file names as a variable that I can reuse.

Outside of recipes, you don't need {{…}} to do interpolation:
first_path := "foo"
second_path := "bar"

copy file:
    cp {{file}} /tmp

setup: (copy first_path)
    some_cmd

setup-dev: (copy second_path)
    other_cmd

Let me know if that works for you!

That works! Thanks, I should have realized that was the case.
Is the namespace global?  For example if one defines the foo variable at the top of a justfile and then makes a recipe like do_stuff foo:.  Will that overwrite the variable set or is it scoped to just that recipe? Thanks again.

Is the namespace global? For example if one defines the foo variable at the top of a justfile and then makes a recipe like do_stuff foo:. Will that overwrite the variable set or is it scoped to just that recipe? Thanks again.

You bet! The namespace is global, but if you try to redefine a variable with a function parameter, it actually complains:
error: Parameter `foo` shadows variable of the same name
  |
3 | j foo:
  |   ^^^

authors: casey papertigers

repo: casey/just


text:
Add quick-and-dirty justfile inclusion

Users have wanted to be able to include other justfiles for a long time, and I've wanted to support this. However, I've been worried about implementing something hacky that would bring problems and be hard to support and debug. I've had a design in my head for a module system, but it's complicated enough that I'm unlikely to implement it any time soon.
As a compromise, I think that we should add a simple include statement, similar to @MadBomber's justprep.
I'm unlikely to implement this myself, because I have other projects which are taking all my time, but if someone wants to pick this up, I can review and help them get it over the line.
The design is this:

Add include statements of the form include "PATH_TO_JUSTFILE"
When the parser hits an include statement, it passes the PATH_TO_JUSTFILE to the loader, which returns the text with 'src lifetime
The parser then invokes the lexer on the returned text, and inserts those tokens into its own token stream, replacing the include statement with those tokens
Parsing then continues as normal
Users can use the allow-duplicate-recipes and OS attributes to override recipes in includes and select recipes for the current OS

The idea behind using the word include instead of use or import is that we want to express that we're doing quick-and-dirty inclusion of the tokens. Later, if someone is feeling super motivated, or I get around to it, we can implement a module system, and users can migrate to the module system if they want to.
Additions and improvements that shouldn't block the initial PR:

Show correct filename in error messages
Add attributes to include statements, so that which file is included can depend on the OS.
Allow duplicate settings, exports, and assignments, so that you can override anything

@MadBomber what do you think of this design?

Later on we can add some extensions:

Add attributes to include statements, so that which file is included can depend on the OS.
Allow duplicate settings, exports, and assignments, so that you can override anything

@casey The advantage is that you do not need both justprep and just with this design - its just just :)  Reducing the number of utilities is generally a good idea.
OTOH if you do not implement a way to isolate the errors to the place they came from, you can get into a little bit of trouble.  The justprep utility does indicate in the final justfile created from the included files via comments which section of the file comes from which included file so that any errors discovered by just are easily traced to the actual cause.
justprep also supports the fake module convention which of course can be easily implemented manually within a justfile but it is som much nicely to just say module followed by the path to the justfile.

Thanks for the feedback!
Yeah, we definitely eventually want proper error messages. I think that can wait for a follow-up PR, since it won't be a breaking change to add error messages.

The company I work for replaced our command runner use of make with just a while back for a large company-wide monorepo. We have a private fork of just that does exactly this naive include (this is the only difference from upstream).
If you're interested, I could put in a PR with those changes. The implementation is about as basic as it gets, but it seems to work really well and has drastically cleaned up our just usage.
Essentially, at the very beginning of parsing we look for #include "path/to/file.just" which includes the contents of that file at the point of #include which as it turns out is kind of what many people tend to expect anyways. Being so early in the process allows just to function exactly as it already expects without change.
The #include syntax is totally changeable if you'd prefer say @include or perhaps set include := "path/to/file.just" that'd just be a simple change. I believe the set ... syntax happens later in parsing from my last looking at the source which is why we didn't go that route ourselves. Additionally we used #include because to upstream just it appears as a comment, although to upstream this change that might be a downside which could create confusion?
If this got upstreamed we'd be able to move back to upstream just which would be great for us too!

@kbknapp Nice! Definitely open a PR with the changes, I’ll probably tweak a bit, but it will be a good starting point, and allow me to make sure what eventually gets merged works for your use case.

I want to express concern about potentially including malicious code from other justfiles.
I understand we are discussing pre-PoC here but I would love to help with at least also specifying an optional hash checksum for the included Justfile. That way the inclusion fails if there is a hash mismatch when the file has been changed:
!include /tmp/Justfile dc34e068f11efee830d5676f12b5e2dbc059d45e08f6e5c8880ed208676ab6d4

That's because the main Justfile might belong to the current user (Linux/MacOS permissions 400) and potentially cannot be modified, but the included one might not.

I think it's outside the scope of this feature to protect against including untrusted input. If you don't trust the file, you shouldn't include it, and an easy workaround it to move the file to the same location/same permissions as the current justfile.

That's a simple workaround, I like it.

If you don't trust the file, you shouldn't include it.

This is a strong statement. Also, URLs still affected.

I've always viewed the justfile concept as being local within the context of my own workstation - most likely coming from a repository.  Including from a URL is a little over-board IMO - coming from a file server its either mine or my team's.  With this context, having the hash of the included file causes more trouble than its worth.

The lack of an include feature is a significant limitation of the tool in my opinion.
In terms of hash validations, local includes are already quite powerful. Remote includes (via http/https) would be a fantastic feature because they would allow you to centralize certain reusable code blocks.
Remote includes, in my opinion, should be used by pointing to a raw file stored in git. If security is a concern, a very specific commit could be used: https://raw.githubusercontent.com/casey/just/66993e874d877e9326de14fbc68c41726567d528/examples/kitchen-sink.just
A similar solution is used, for example, in github actions.

I found this tool just the other day and it looks incredibly cool and a near perfect fit but the lack of an includes capability is a deal breaker when considering a migration away from makefiles.
We have a large number of services which all have a Makefile but they import a substantial amount of functionality from a common makefile to avoid a ton of copy pasta.
+1 for this capability!

Implemented in #1470, and released in 1.12.0. Binaries should be up shortly. Try it out and let me know what you think!

Thanks to @neunenak for implementing this!

Implemented in #1470, and released in 1.12.0. Binaries should be up shortly. Try it out and let me know what you think!

I have a justfile that I'd like to decompose a bit. Unfortunately, the restriction that "!include directives are only processed before the first non-blank, non-comment line" is stopping me from using it as I intended. There may be workarounds, but this is the way I was planning to do it:
var1 := "..."
var2 := "..."

_list:
   just --list

run:
   /usr/local/bin/theruncommand --option1 {{var1}} --etc --etc

# Include receipes which can reference var1 and var2
!include src/just/database.just
!include src/just/setup.just

I read your comment https://github.com/casey/just/pull/1470#issuecomment-1368703458, about !include appearing inside a multiline string. I understand that this could create trouble, but I guess we have to trust the script? A bit like https://github.com/casey/just/issues/1407#issuecomment-1368713655, perhaps. If required, I would prefer having a setting similar to set fallback and set dotenv-load.

@elygre Justfiles are actually insensitive to order, so you can refer to variables at the top of a justfile that aren't defined until later in the file.

@casey Huh, I did not realize that. OK, that solves my problem :-)
When you revisit the documentation, perhaps add a small comment to this effect in https://just.systems/man/en/chapter_52.html. Perhaps add this sentence:

Note that justfiles are insensitive to order. This means that the included justfiles have access to variables defined in the parent justfile, even if these variables are defined after the !include directive.

(There is also a typo in that chapter, saying "beginning of a line. line.")

Good addition to the docs, just opened #1529, and thanks for finding the typo!

authors: MadBomber casey dhendry elygre jakubsacha kbknapp mihaigalos


text:
Offers

This doesn't need to be done for mainnet, but we need to make sure that it can be done eventually.
Ask: Offer to sell sats
Inputs

A: Zero-value dummy output, provided by taker
B: Value M output containing ordinals to be sold, provided by maker
C: Value N output containing cardinal sats to be used for payment, provided by taker

Outputs

X: Value M output with taker's address
Y: Value N output with maker's address

Steps

Maker creates PSBT providing a signature for B, which commits to Y, using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. Due to A, B and Y have same index
Maker broadcasts PSBT
Taker adds inputs A and C and output Y and finalizes transaction
Taker broadcasts transaction
When transaction is mined, maker receives cardinal sats in Y for payment, taker receives ordinal sats in X

Bid: Offer to buy sats
Inputs

A: Zero-value dummy output, provided by taker
B: Value N output containing ordinal sats to be bought, provided by taker
C: Value M output containing cardinal sats for payment, provided by maker

Outputs

X: Value N output with maker's address
Y: Value M output with taker's address

Steps

Maker creates PSBT providing a signature for C, which commits to A, B, C, and X, using SIGHASH_SINGLE
Maker broadcasts PSBT
Taker adds output Y
Taker signs and broadcasts transaction
When transaction is mined, maker receives ordinal sats in Y for payment, taker receives cardinal sats in X

Notes:

Offer to buy is wrong but can be fixed.

In offers to buy, can people include change so they an use input uxos of any size?

This but also for inscriptions

@cryptoquick This actually covers inscriptions! Since inscriptions are on sats, which transfer using the ordinals protocol, offers to buy and sell individual sats work for inscriptions. (UX obviously needs to be there too!)

One of the things I think is critical for the design of this feature is that 3rd-parties can be optionally designated as recipients in the transaction. Most notably:

a fee for the exchange (e.g. OpenSea) and
a fee for the artist (royalties)

Ordinals will have the same issues as Ethereum in enforcing these, but both of those fees are massive forces for good and we should design offers to support them from the get-go
Because if tool-builders and artists know they can participate in the ongoing economy, you'll see an incredible amount of work poured into the ecosystem

@cryppadotta As far as I can tell, there is no way to implement royalties in an inforcable, technically reasonable way. See https://github.com/casey/ord/discussions/773 for some discussion we've been having on the topic.

Offers could certainly include a "tip" output to a third-partty, and venues (marketplaces, artist home pages, discords), etc could require that an offer file contain a tip in order to show it one the homepage, etc. I think this would be great. Offers are simple and flexible enough that we can add this in a v2 version. So I think no need to worry about it in the MVP. Offers are off-chain, and easy to upgrade!

What are the options for writing more protocols around Ordinals - bitcoin script only? Or is it possible to use sapio, stacks/clarity? (or anything else like that). Thanks!

I know you've taken a look at Chia and ChiaLisp @casey but not sure if you've dived into how Offers are implemented there that may offer some ideas: https://chialisp.com/offers/
The defined NFT1 standard also enforces royalties on-chain via the transfer function part of the standard NFT1 program @cryppadotta
There are differences between Chia's coin set model vs Bitcoin's UTXO namely Chia's use of BLS enables signature aggregation in a better way than Schnorr but I'm not sure if there are other shortcomings in Bitcoin Script that makes a similar implementation not possible...

What are the options for writing more protocols around Ordinals - bitcoin script only? Or is it possible to use sapio, stacks/clarity? (or anything else like that). Thanks!

Stacks is has a separate token, and is only thematically related to Bitcoin, so it and clarity will never be supported.
Sapio is an excellent project, and although I believe that @JeremyRubin is no longer working, it is open source and someone dedicated could pick up the torch. Sapio would be a great fit for filling in the gaps in Bitcoin Script for markets and services related to ordinals.

I know you've taken a look at Chia and ChiaLisp @casey but not sure if you've dived into how Offers are implemented there that may offer some ideas: https://chialisp.com/offers/

Thanks for the link! I have looked at offers, and they definitely seem similar to what we want to do here.

The defined NFT1 standard also enforces royalties on-chain via the transfer function part of the standard NFT1 program @cryppadotta

Royalties cannot be enforced on-chain, because the buyer and the seller can simply use another channel to perform the actual transfer of funds, and lie on chain about the actual sale price. Until I see a good implementation proposed that does not have this and other problems, I do not plan to add any royalty related functionality to ord.

There are differences between Chia's coin set model vs Bitcoin's UTXO namely Chia's use of BLS enables signature aggregation in a better way than Schnorr but I'm not sure if there are other shortcomings in Bitcoin Script that makes a similar implementation not possible...

Offers as sketched out don't really use script, only input and output selection, but I would be curious if something is missing. The coin set model and the UTXO model are pretty much the same, so I often actually use the "coin set" terminology when describing bitcoin, because "output" is a pretty unfamiliar term to most people 😅

Royalties cannot be enforced on-chain, because the buyer and the seller can simply use another channel to perform the actual transfer of funds, and lie on chain about the actual sale price. Until I see a good implementation proposed that does not have this and other problems, I do not plan to add any royalty related functionality to ord.

Well of course one can always get around royalties if you are okay with some level of trust. At the extreme I can sell you my private key to my wallet containing the NFT in exchange for cash and no information will take place on chain. The point with on-chain royalties (on Chia) is to create a standard where royalties are enforced when trustless Offer Files are used to exchange assets that follow that standard.

Offers as sketched out don't really use script, only input and output selection, but I would be curious if something is missing. The coin set model and the UTXO model are pretty much the same, so I often actually use the "coin set" terminology when describing bitcoin, because "output" is a pretty unfamiliar term to most people 😅

Fair point. BLS aggregation also opens the door to things like aggregation of Offers so multiple can be taken simultaneously.
A bit off topic but I heard your interview on Bankless and was intrigued by how you think tokens (like ERC-20 or CAT1 on Chia) can be implemented in a similar way. I think that's what would make Offers very exciting if its utility can go beyond just BTC for ordinal trades (or ordinals for ordinals).

Well of course one can always get around royalties if you are okay with some level of trust. At the extreme I can sell you my private key to my wallet containing the NFT in exchange for cash and no information will take place on chain. The point with on-chain royalties (on Chia) is to create a standard where royalties are enforced when trustless Offer Files are used to exchange assets that follow that standard.

Someone can probably figure out trustless atomic swaps to remove trust and still use offer files. I want to avoid a scenario where we advertise that we have royalties to artists, but then as the amount of the value in the system increases, it becomes a confusing and chaotic race to the bottom like we're seeing in Ethereum.

A bit off topic but I heard your interview on Bankless and was intrigued by how you think tokens (like ERC-20 or CAT1 on Chia) can be implemented in a similar way. I think that's what would make Offers very exciting if its utility can go beyond just BTC for ordinal trades (or ordinals for ordinals).

I think there's an issue open for fungible ordinals. I'm not sure how to support that, but we could add a metadata field to an inscription that said "the next N sats after this inscription" are fungible tokens. Support in ord would be hard, because special tracking for all those sat ranges would be difficult, but it's such a simple protocol-level extension that I would be open to adding it, if only so that others could experiment with it in other repos.

@SlowestTimelord Check out #787, I just copied my last comment there.

Sapio would only need minor changes to support basic ord functionality, but the biggest issue would be convention around fees probably.

question about incentives:
if i'm selling a rare sat, i set a price in my Ask offer
isn't there now an interesting dynamic where two buyers may compete with each other to fulfill it, and the one who pays a higher mining fee will win?

question about incentives: if i'm selling a rare sat, i set a price in my Ask offer isn't there now an interesting dynamic where two buyers may compete with each other to fulfill it, and the one who pays a higher mining fee will win?

Yup, that is correct. Seller should set the price such that it's close to what sellers are willing to pay. If it's below what sellers are willing to pay, then they will increase their "bid" by adding fees, which will go to miners. There are probably a bunch of different auction mechanism, where the value is split in different ways between miners and sellers.
On the one hand, you have the #1611 method, where miners get all bids. On the other hand, you have a descending price auction where the seller continually releases PBSTs with lower and lower prices until someone takes it and pays EV - FEE to the seller, where EV is expected value, and FEE is what's required to get it mined, which goes to the miner.

Something like this:?
const bitcoin = require("bitcoinjs-lib");
const bip32 = require("bip32");
const bip39 = require("bip39");
const mnemonic = "a random mnemonic phrase used as seed for BIP32";
const seed = bip39.mnemonicToSeed(mnemonic);
const node = bip32.fromSeed(seed);
const keyPairB = node.derivePath("m/44'/0'/0'/0/1").keyPair;
const keyPairC = node.derivePath("m/44'/0'/0'/0/2").keyPair;
const network = bitcoin.networks.testnet;
const p2pkhB = bitcoin.payments.p2pkh({ pubkey: keyPairB.publicKey, network });
const p2pkhC = bitcoin.payments.p2pkh({ pubkey: keyPairC.publicKey, network });
const p2pkhMaker = "the address for the maker";
const p2pkhTaker = "the address for the taker";
let psbt = new bitcoin.Psbt({ network });
psbt.addInput({
hash: "the hash of transaction A",
index: 0,
nonWitnessUtxo: Buffer.from("00", "hex"),
});
psbt.addInput({
hash: "the hash of transaction B",
index: 0,
witnessUtxo: {
script: p2pkhB.output,
value: N,
},
});
psbt.addInput({
hash: "the hash of transaction C",
index: 0,
witnessUtxo: {
script: p2pkhC.output,
value: M,
},
});
psbt.addOutput({
address: p2pkhMaker,
value: N,
});
psbt.signInput(2, keyPairC, null, bitcoin.Transaction.SIGHASH_SINGLE | bitcoin.Transaction.SIGHASH_ANYONECANPAY);
const partiallySignedPsbt = psbt.toBase64();
console.log("Partially signed PSBT:", partiallySignedPsbt);
// Maker broadcasts PSBT
psbt = bitcoin.Psbt.fromBase64(partiallySignedPsbt);
psbt.addOutput({
address: p2pkhTaker,
value: M,
});
psbt.signAllInputs(keyPairB);
const signedTransaction = psbt.finalizeAllInputs().extractTransaction().toHex();
console.log("Signed transaction:", signedTransaction);
// Taker broadcasts transaction
// When transaction is mined, maker receives ordinal sats in Y for payment, taker receives cardinal sats in X

I think the script should use "p2tr" because ordinals are inscribed in the p2tr scripts.

In offers to buy, can people include change so they an use input uxos of any size?

@casey, one way to support this is for the maker to include output Y, paying to the same address as the desired ordinal UTXO, output Z paying themselves change, and sign with SIGHASH_ALL. If the taker doesn't want to reuse the address, they can respond with an updated PSBT paying their preferred destination, also signed with SIGHASH_ALL. The added interactivity in that case isn't ideal, but I haven't thought of a better way to do it without SIGHASH_GROUP.

This actually covers inscriptions!

@casey does that mean an inscription can be created in the same "sell offer" PSBT so that it's zero-cost for a maker to create and sell inscriptions?

In the "Ask: Offer to sell sats", I fail to see how it is possible to guarantee these two:

that the buyer pays a minimum value (otherwise transaction wont fulfill)
and at the same time, that the buyer can be anyone (not specified in the transaction itself, so that anyone can buy)

It does make sense if you assume that:

Buyer signs first
Maker take a look at the payment partially signed by the taker/buyer and if they like it, they sign as well to send the ordinal sat

This way you can enforce both a minimum payment value AND that you know the buyer public key beforehand

Just created a topic on Discord #tech-support https://discord.com/channels/987504378242007100/1076920008065679500 in case we wanna discuss in a real time chat environment

@kevinfaveri the seller's signature commits to (only) the input spending the ordinal and the output paying himself the desired price, via SIGHASH_SINGLE|ANYONECANPAY. Anyone in possession of that PSBT can add an input spending at least the already-committed output's value and an output sending the ordinal to themselves, sign their input, and broadcast.
Having trouble verifying on Discord but will get in the chat when possible.

It occurs to me there's an odd dynamic that arises with miners and fees in a hot inscription market. Since a miner can always break the transaction apart and try to snipe the purchase from the buyer, the incentive is to pay a fee premium equal to the expected appreciation of the NFT over whatever timescale a miner is likely willing to stay illiquid for.
It's not a dealbreaker but will be interesting to observe how this plays out in practice.

@kevinfaveri the seller's signature commits to (only) the input spending the ordinal and the output paying himself the desired price, via SIGHASH_SINGLE|ANYONECANPAY. Anyone in possession of that PSBT can add an input spending at least the already-committed output's value and an output sending the ordinal to themselves, sign their input, and broadcast.
Having trouble verifying on Discord but will get in the chat when possible.

Thank you so much sir! So, in the "Ask: Offer to sell sats" theoretical algo, anyone can buy. Makes sense, but how to enforce that the buyer will pay the specific price of cardinal sats? e.g. will not try to pay less? Because maker only signs for the ordinal sat in the theoretical algo from @casey.
I think it is possible to workaround this (enforce a listing price) using OP_CODES that will validate the second input (from the taker, the payment) against a specific min price, right?

@casey What is the A: Zero-value dummy output, provided by taker for?

@orenyomtov just released an open source NFT marketplace base layer protocol.
Let's hack and validate it.
https://twitter.com/orenyomtov/status/1628106067119833107
https://github.com/orenyomtov/openordex
Congrats on the release and thanks on the choice of going OSS @orenyomtov, wish you good luck on your endeavor

Thanks! Would also love to cleanly abstract and export the capability as a library down the road
I'm also looking forward to creating a V2 that accomplishes this without the need for dummy UTXOs

I'm also looking forward to creating a V2 that accomplishes this without the need for dummy UTXOs

Have you looked into the psbtv2 protocol update yet? Curious is this solves the problem (i suspect it'll require more rounds of communication tho)

I'm also looking forward to creating a V2 that accomplishes this without the need for dummy UTXOs

Have you looked into the psbtv2 protocol update yet? Curious is this solves the problem (i suspect it'll require more rounds of communication tho)

Do you know which wallets support psbtv2?

The latest version of libwally has it, if iiuc.  https://github.com/ElementsProject/libwally-core/releases/tag/release_0.8.8

Oh that's not consumer grade wallets tho. Yeah no, it'll probably be a good bit before they update.

If you wanted to play around with it though, that'd be a decent way to try it out.

There's a really bad bug in the Bid flow fyi, cc @casey.
This line is problematic.

Maker creates PSBT providing a signature for C, which commits to A, B, C, and X, using SIGHASH_SINGLE

Given
Inputs
A: Zero-value dummy output, provided by taker
B: Value N output containing ordinal sats to be bought, provided by taker
C: Value M output containing cardinal sats for payment, provided by maker
Outputs
X: Value N output with maker's address
Y: Value M output with taker's address

SIGHASH_SINGLE on C is equivalent to SIGHASH_NONE. Yikes...
The transaction should instead be constructed as follows:
Inputs
C: Value M output containing cardinal sats for payment, provided by maker
B: Value N output containing ordinal sats to be bought, provided by taker
A: Zero-value dummy output, provided by taker

Outputs
X: Value N output with maker's address
Y: Value M output with taker's address

This makes the original instruction correct.

Taker adds inputs A and C and output Y and finalizes transaction

In the Asks sections for this shouldn't it say that : Taker adds inputs A and C and output X and finalizes transaction?
Being that:
X: Value M output with taker's address
Y: Value N output with maker's address
Also, could  someone please explain why the Dummy UTXO is needed and why it needs to be empty or have less than 1000 Sats?
Any help great appreciated!

Also, could someone please explain why the Dummy UTXO is needed and why it needs to be empty or have less than 1000 Sats?

Dummy UTXO is required for SIGHASH_SINGLE, so the inputs/output indexes of the maker get lined up/covered for their signature (B + Y have same index position in their respective lists)

Thank you but I still don't understand this, need to study this more; some diagrams would help!

Did an inscription swap without dummy UTXO: https://mempool.space/signet/tx/1e34d8c00eae244a725ca0beecb9ff63f42d70072c49908ca17b9f98df08463d

Created PSBT 1 using createpsbt in which input is inscription UTXO and output is sell amount
cHNidP8BAF4CAAAAAf6QBbK23/kX2b6+TwOMD+5K/3f/jev+O2ISBwUFJkjpAAAAAAD9////AUANAwAAAAAAIlEgggRYhIl33bjKgdv+G5AXrcTRKGyWQXBY/93IME8F4EYAAAAAAAAA

Created PSBT 2 using createpsbt in which input is some UTXO from wallet (cardinal) and output is change left after deducting fees and output amount used in 1
cHNidP8BAIkCAAAAAXm7jKQnPdFALnyfAMZ/4LktlmM2ae/x1zClF3eZFHh3AQAAAAD9////AvgqAAAAAAAAIlEgmeAiGFUfme2tsJ+HAT89PjkFYrYsn37nwN/Uckj23wpgrgoAAAAAACJRIObgyCXaE9gvj1wPqzq/SO1DVitTmnl2XYV3Y4dK8N0bAAAAAAAAAAA=

Joined both PSBTs using joinpsbts RPC
cHNidP8BAN0CAAAAAv6QBbK23/kX2b6+TwOMD+5K/3f/jev+O2ISBwUFJkjpAAAAAAD9////ebuMpCc90UAufJ8Axn/guS2WYzZp7/HXMKUXd5kUeHcBAAAAAP3///8D+CoAAAAAAAAiUSCZ4CIYVR+Z7a2wn4cBPz0+OQVitiyffufA39RySPbfCkANAwAAAAAAIlEgggRYhIl33bjKgdv+G5AXrcTRKGyWQXBY/93IME8F4EZgrgoAAAAAACJRIObgyCXaE9gvj1wPqzq/SO1DVitTmnl2XYV3Y4dK8N0bAAAAAAAAAAAAAA==

Signed PSBT using walletprocesspsbt and finalized using finalizepsbt

Broadcasted the transaction using sendrawtransaction: https://mempool.space/signet/tx/1e34d8c00eae244a725ca0beecb9ff63f42d70072c49908ca17b9f98df08463d

Note: Order of inputs and outputs is important however joinpsbts RPC randomizes the order to improve privacy. So I had to keep trying until I get the right order. This can be fixed by either compiling core and remove the changes made in #16512 or open a pull request in bitcoin core to add another argument in joinspsbts RPC that is true by default and could be change to false for not shuffling inputs and outputs.

@niftynei
Does this not work (for the "buy sats" case discussed above)?
0v = zero value dummy utxo
Inputs:
A: N, ordinal, taker
B: M, cardinal, maker

Outputs:
X: 0v
Y: N, ordinal, maker
Z: M, cardinal, taker.

Then maker can SINGLE|ACP sign over input B with safety right?

PSBTv2 and +1 round trip fixes this iiuc; you separate the compose phase from the sign phase, which lets you use SIGHASH_ALL to sign. This prevents anyone from outbidding you once broadcast.

Yeah I haven't thought it through at all but I could well imagine all this "jigsaw piece" stuff with single|acp is academic if you start thinking about markets.

Yeah I think that works nicely. You'd want to use just SIGHASH_SINGLE as originally suggested though, otherwise anyone could swap out the other ordinal input, and change what you're buying.
(I hadn't realized it til I saw this tweet, but the ordinal input/output needs to go at the top to make it work out)
You can make SIGHASH_ALL work for it and remove the 0v dummy output if the maker's pay-to address is known at the time you're constructing the offer to buy.

You'd want to use just SIGHASH_SINGLE as originally suggested though, otherwise anyone could swap out the other ordinal input, and change what you're buying.

Oh yes, good catch! Huh, interesting that it's different this way round, because the "special" ordinal input isn't owned by the signer at the start.
It's interesting how many dimensions these setups have.

You can make SIGHASH_ALL work for it and remove the 0v dummy output if the maker's pay-to address is known at the time you're constructing the offer to buy.

Still struggling with this one :smile: Did you mean taker, not maker there (i.e. the guy who has the ordinals and is accepting the offer to buy them?). I guess in case where all inputs and outputs are known in advance then none of this shenanigans is necessary right? You just ALL all of it in the usual way like a traditional coinjoin (except, where the ordering is fixed and no privacy is achieved).

in case where all inputs and outputs are known in advance then none of this shenanigans is necessary right?

Yeah exactly :D

I am trying to write a spec for PSBT to be used in any inscription swap:

openordex works best
my alternative makes UX bad although no dummy UTXO
coinswap sucks

Let me know if you have any feedback or opinions
Cc: @casey @rot13maxi @niftynei @AdamISZ @JeremyRubin

https://gist.github.com/1440000bytes/a7deeb3f1740bc533a61fbcc1fe58d77

Also, could someone please explain why the Dummy UTXO is needed and why it needs to be empty or have less than 1000 Sats?

Dummy UTXO is required for SIGHASH_SINGLE, so the inputs/output indexes of the maker get lined up/covered for their signature (B + Y have same index position in their respective lists)

I don't understand why this is required.
Ask: Offer to sell sats
Inputs

    A: Zero-value dummy output, provided by taker
    B: Value M output containing ordinals to be sold, provided by maker
    C: Value N output containing cardinal sats to be used for payment, provided by taker

Outputs

    X: Value M output with taker's address
    Y: Value N output with maker's address

Why not just reorganize to be
Inputs
    B: Value M output containing ordinals to be sold, provided by maker
    C: Value N output containing cardinal sats to be used for payment, provided by taker
Outputs
    Y: Value N output with maker's address
    X: Value M output with taker's address

Now B and Y are sharing the same index (0) which should be valid for SINGLE|ANYONECANPAY. This  allows the taker to add his input C at index 1 to fund the payment for the ordinal?

Am i missing something?

iiuc you're missing how ordinals flow/are reassigned to the outputs from the inputs. The person buying the ordinals needs their address to be at output 0, so they get the sat that the inscription is associated with.

@niftynei has it. Sats get assigned to outputs in the same order that they are provided as inputs. So if the first sat of the first input is an inscription or otherwise desirable sat (rare/exotic?), then it will go to the first sat of the first output. If the seller provides the first input and the first output with SINGLE|ANYONECANPAY, they will just be sending that sat to themselves.

@rot13maxi thanks for the helpful answer...
did you get the answer to your earlier question re. zero-value dummy output? Could we actually put a zero-value input in A? Currently I'm using a non-zero dummy output (1000 sats) to get around the same index position requirement.

Yes, 0 value OP_RETURN outputs are valid and standard.

Hey folks. What's the safest way to parse out sats without messing up dummy utxo for ordinals ? So that you can inscribe a specific art to a specific sat and sell it eventually. What's the best known method for creating dummy UTXO's today?

@ep150de you should create a Discussion or a new Issue for that. Sounds related but separable

PSBTv2 and +1 round trip fixes this iiuc; you separate the compose phase from the sign phase, which lets you use SIGHASH_ALL to sign. This prevents anyone from outbidding you once broadcast.

Could you offer the detailed solution, hard for me to understand. Thanks!

I have started working on a marketplace which uses multisig instead of SIGHASH_SINGLE | ACP and there is no conceot of dummy UTXO
https://github.com/1440000bytes/zordex

A: Zero-value dummy output, provided by taker

In practice, how do you create a zero-value output? I understand that OP_RETURNs can be created, but OP_RETURNs are not spendable right?
It seems instead a practical path is to use two small dummy utxos, like they do here: https://github.com/magiceden-oss/msigner
So that the final transaction looks like this:
Inputs:

600 sat dummy output, provided by taker
600 sat dummy output, provided by taker
Value M output containing ordinal to be sold, provided by maker
Value N output containing cardinal sats to be used for payment, provided by taker

Outputs

Value 1200 sat dummy output to taker's address, provided by taker
Value M output with taker's address, provided by taker
Value N output with maker's address, provided by maker

authors: 0xWhiteleaf 0xankylosaurus 1440000bytes AdamISZ AlexanderPavlenko Christewart JeremyRubin MuffinsThaCat SlowestTimelord casey cryppadotta cryptoquick cyclomancer dajuguan dannydeezy ep150de gnoblin kevinfaveri niftynei orenyomtov roadbuilder rot13maxi

repo: casey/ord


text:
Error in Testing Documentation

On this page: https://cashapp.github.io/tempest/guide/testing/ there is this line of code:
.addTable(TestTable.create<MusicItem>())
I think it needs the table name specified as well?
.addTable(TestTable.create(MusicItem.TABLE_NAME, MusicItem::class.java))

This was fixed in https://github.com/cashapp/tempest/pull/47. I will release it today.

authors: chris-ryan-square zhxnlai

repo: cashapp/tempest


text:
Python/relative_import

Relative import the entire project.

Codecov Report
Patch coverage: 81.01% and no project coverage change.

Comparison is base (87f9241) 52.41% compared to head (012f9c6) 52.41%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #186   +/-   ##
=======================================
  Coverage   52.41%   52.41%
=======================================
  Files          36       36
  Lines        2902     2902
=======================================
  Hits         1521     1521
  Misses       1381     1381

Impacted Files
Coverage Δ

cashu/mint/app.py
0.00% <0.00%> (ø)

cashu/mint/main.py
0.00% <0.00%> (ø)

cashu/mint/router.py
0.00% <0.00%> (ø)

cashu/mint/startup.py
0.00% <0.00%> (ø)

cashu/wallet/cli/nostr.py
41.55% <87.50%> (ø)

cashu/mint/ledger.py
31.70% <92.85%> (ø)

cashu/core/base.py
95.38% <100.00%> (ø)

cashu/core/crypto.py
100.00% <100.00%> (ø)

cashu/core/helpers.py
35.71% <100.00%> (ø)

cashu/core/migrations.py
86.66% <100.00%> (ø)

... and 10 more

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

authors: callebtc codecov-commenter

repo: cashubtc/cashu