Field position is being removed

Using hast-util-raw directly from this package or thru rehype-raw removes position fields when using a combination of proc.runSync(proc.parse(text))
Initial checklist

[x] I read the support docs
[x] I read the contributing guide
[x] I agree to follow the code of conduct
[x] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions: v6+
Steps to reproduce

Use unified with remark-parse, remark-rehype and  hast-util-raw to create a processor.
Use the processor to create a tree with parse and pass it to runSync.

Here is a failing test case using the same data from the tests suite in the repo:
Link to code example:
When using unified with remark-parse, remark-rehype and hast-util-raw (and rehyper-raw) the position is removed as noted in the next test case. I added a first check to ensure position is present after the transform to rehype.
1..3
# tests 3
# pass  1
# fail  2

I used the data in the current test suite to create a failing case:
test('runSync position removed', function (t) {
  const text = [
    'Some title',
    '',
    '
Hello, world!',
    '',
    '*   This',
    '*   Is',
    '*   A',
    '*   List',
    '',
    'A mix of *markdown* and HTML.',
    '',
    '***',
    '',
    '![an image](https://example.com/favicon.ico "title")',
    '',
    '<svg><rect/></svg>',
    '',
    '
alfred
',
    '',
    '
Hello, world!',
    ''
  ].join('\n')

  const expected = {
    type: 'root',
    children: [
      {
        type: 'element',
        tagName: 'p',
        properties: {},
        children: [
          {
            type: 'element',
            tagName: 'i',
            properties: {},
            children: [
              {
                type: 'text',
                value: 'Some title',
                position: {
                  start: {line: 1, column: 4, offset: 3},
                  end: {line: 1, column: 14, offset: 13}
                }
              }
            ],
            position: {
              start: {line: 1, column: 1, offset: 0},
              end: {line: 1, column: 18, offset: 17}
            }
          }
        ],
        position: {
          start: {line: 1, column: 1, offset: 0},
          end: {line: 1, column: 18, offset: 17}
        }
      },
      {type: 'text', value: '\n'},
      {
        type: 'element',
        tagName: 'p',
        properties: {},
        children: [
          {
            type: 'text',
            value: 'Hello, world!\n',
            position: {
              start: {line: 3, column: 4, offset: 22},
              end: null
            }
          }
        ],
        position: {
          start: {line: 3, column: 1, offset: 19},
          end: {line: 5, column: 1, offset: 37}
        }
      },
      {
        type: 'element',
        tagName: 'ul',
        properties: {},
        children: [
          {type: 'text', value: '\n'},
          {
            type: 'element',
            tagName: 'li',
            properties: {},
            children: [
              {
                type: 'text',
                value: 'This',
                position: {
                  start: {line: 5, column: 5, offset: 41},
                  end: {line: 5, column: 9, offset: 45}
                }
              }
            ],
            position: {
              start: {line: 5, column: 1, offset: 37},
              end: {line: 5, column: 9, offset: 45}
            }
          },
          {type: 'text', value: '\n'},
          {
            type: 'element',
            tagName: 'li',
            properties: {},
            children: [
              {
                type: 'text',
                value: 'Is',
                position: {
                  start: {line: 6, column: 5, offset: 50},
                  end: {line: 6, column: 7, offset: 52}
                }
              }
            ],
            position: {
              start: {line: 6, column: 1, offset: 46},
              end: {line: 6, column: 7, offset: 52}
            }
          },
          {type: 'text', value: '\n'},
          {
            type: 'element',
            tagName: 'li',
            properties: {},
            children: [
              {
                type: 'text',
                value: 'A',
                position: {
                  start: {line: 7, column: 5, offset: 57},
                  end: {line: 7, column: 6, offset: 58}
                }
              }
            ],
            position: {
              start: {line: 7, column: 1, offset: 53},
              end: {line: 7, column: 6, offset: 58}
            }
          },
          {type: 'text', value: '\n'},
          {
            type: 'element',
            tagName: 'li',
            properties: {},
            children: [
              {
                type: 'text',
                value: 'List',
                position: {
                  start: {line: 8, column: 5, offset: 63},
                  end: {line: 8, column: 9, offset: 67}
                }
              }
            ],
            position: {
              start: {line: 8, column: 1, offset: 59},
              end: {line: 8, column: 9, offset: 67}
            }
          },
          {type: 'text', value: '\n'}
        ],
        position: {
          start: {line: 5, column: 1, offset: 37},
          end: {line: 8, column: 9, offset: 67}
        }
      },
      {type: 'text', value: '\n'},
      {
        type: 'element',
        tagName: 'p',
        properties: {},
        children: [
          {
            type: 'text',
            value: 'A mix of ',
            position: {
              start: {line: 10, column: 1, offset: 69},
              end: {line: 10, column: 10, offset: 78}
            }
          },
          {
            type: 'element',
            tagName: 'em',
            properties: {},
            children: [
              {
                type: 'text',
                value: 'markdown',
                position: {
                  start: {line: 10, column: 11, offset: 79},
                  end: {line: 10, column: 19, offset: 87}
                }
              }
            ],
            position: {
              start: {line: 10, column: 10, offset: 78},
              end: {line: 10, column: 20, offset: 88}
            }
          },
          {
            type: 'text',
            value: ' and ',
            position: {
              start: {line: 10, column: 20, offset: 88},
              end: {line: 10, column: 25, offset: 93}
            }
          },
          {
            type: 'element',
            tagName: 'em',
            properties: {},
            children: [
              {
                type: 'text',
                value: 'HTML',
                position: {
                  start: {line: 10, column: 29, offset: 97},
                  end: {line: 10, column: 33, offset: 101}
                }
              }
            ],
            position: {
              start: {line: 10, column: 25, offset: 93},
              end: {line: 10, column: 38, offset: 106}
            }
          },
          {
            type: 'text',
            value: '.',
            position: {
              start: {line: 10, column: 38, offset: 106},
              end: {line: 10, column: 39, offset: 107}
            }
          }
        ],
        position: {
          start: {line: 10, column: 1, offset: 69},
          end: {line: 10, column: 39, offset: 107}
        }
      },
      {type: 'text', value: '\n'},
      {
        type: 'element',
        tagName: 'hr',
        properties: {},
        children: [],
        position: {
          start: {line: 12, column: 1, offset: 109},
          end: {line: 12, column: 4, offset: 112}
        }
      },
      {type: 'text', value: '\n'},
      {
        type: 'element',
        tagName: 'p',
        properties: {},
        children: [
          {
            type: 'element',
            tagName: 'img',
            properties: {
              src: 'https://example.com/favicon.ico',
              alt: 'an image',
              title: 'title'
            },
            children: [],
            position: {
              start: {line: 14, column: 1, offset: 114},
              end: {line: 14, column: 53, offset: 166}
            }
          }
        ],
        position: {
          start: {line: 14, column: 1, offset: 114},
          end: {line: 14, column: 53, offset: 166}
        }
      },
      {type: 'text', value: '\n'},
      {
        type: 'element',
        tagName: 'p',
        properties: {},
        children: [
          {
            type: 'element',
            tagName: 'svg',
            properties: {},
            children: [
              {
                type: 'element',
                tagName: 'rect',
                properties: {},
                children: [],
                position: {
                  start: {line: 16, column: 6, offset: 173},
                  end: {line: 16, column: 13, offset: 180}
                }
              }
            ],
            position: {
              start: {line: 16, column: 1, offset: 168},
              end: {line: 16, column: 19, offset: 186}
            }
          }
        ],
        position: {
          start: {line: 16, column: 1, offset: 168},
          end: {line: 16, column: 19, offset: 186}
        }
      },
      {type: 'text', value: '\n'},
      {
        type: 'element',
        tagName: 'div',
        properties: {id: 'foo', className: ['bar', 'baz']},
        children: [
          {
            type: 'element',
            tagName: 'img',
            properties: {src: 'a', alt: 'bar'},
            children: [],
            position: {
              start: {line: 18, column: 31, offset: 218},
              end: {line: 18, column: 52, offset: 239}
            }
          },
          {
            type: 'text',
            value: 'alfred',
            position: {
              start: {line: 18, column: 52, offset: 239},
              end: {line: 18, column: 58, offset: 245}
            }
          }
        ],
        position: {
          start: {line: 18, column: 1, offset: 188},
          end: {line: 18, column: 64, offset: 251}
        }
      },
      {type: 'text', value: '\n'},
      {
        type: 'element',
        tagName: 'p',
        properties: {},
        children: [
          {
            type: 'text',
            value: 'Hello, world!',
            position: {
              start: {line: 20, column: 4, offset: 256},
              end: {line: 20, column: 17, offset: 270}
            }
          }
        ],
        position: {
          start: {line: 20, column: 1, offset: 253},
          end: {line: 20, column: 17, offset: 270}
        }
      }
    ],
    data: {quirksMode: false},
    position: {
      start: {line: 1, column: 1, offset: 0},
      end: {line: 21, column: 1, offset: 270}
    }
  }

  const proc = unified()
    .use(remarkParse)
    .use(remarkRehype, {allowDangerousHtml: true})
    .use(function () {
      return transformer
      function transformer(/** @type {import('unist').Node} */ tree) {
        t.ok(tree.position, 'should have position')
        return tree
      }
    })
    .use(function () {
      // @ts-ignore hast is more specific than unist.
      return (tree, file) => raw(tree, file)
    })
    .use(function () {
      return transformer
      function transformer(/** @type {import('unist').Node} */ tree) {
        t.deepEqual(tree, expected, 'should equal the fixture tree')
      }
    })

  proc.runSync(proc.parse(text))

  t.end()
})

Expected behavior

The position fields should not be removed.
Actual behavior

The position fields are being removed

I am guessing this is because this utility expects a modern VFile (which uses .value), whereas remark/rehype/unified are still using the previous vfile (.contents). All of vfile/syntax-tree/micromark/wooorm has been updated, but unified/remark/rehype have not.
Here is a minimal example that shows this utility working:
import parse5 from 'parse5'
import {VFile} from 'vfile'
import {fromParse5} from 'hast-util-from-parse5'
import {inspect} from 'unist-util-inspect'
import {raw} from './index.js'

const file = new VFile('
whatever
')
const p5ast = parse5.parse(String(file), {sourceCodeLocationInfo: true})
const tree = fromParse5(p5ast, file)

console.log('1', inspect(tree))

raw(tree, file)

console.log('2', inspect(tree))

Yields:
1 root[1] (1:1-1:18, 0-17)
│ data: {"quirksMode":true}
└─0 element[2]
    │ properties: {}
    ├─0 element[0]
    │     properties: {}
    └─1 element[1]
        │ properties: {}
        └─0 element
[1] (1:1-1:18, 0-17)
            │ properties: {}
            └─0 text "whatever" (1:5-1:13, 4-12)
root[1] (1:1-1:18, 0-17)
│ data: {"quirksMode":true}
└─0 element[2]
    │ properties: {}
    ├─0 element[0]
    │     properties: {}
    └─1 element[1]
        │ properties: {}
        └─0 element
[1] (1:1-1:18, 0-17)
            │ properties: {}
            └─0 text "whatever" (1:5-1:13, 4-12)

@wooorm thanks for your promptly reply.
However, my intention with this issue might be unrelated to having a vFile. In the integration test case there is no vFile involved, that's why I reproduced the exact same scenario failing.
In my case, I have tested this in https://github.com/elmasse/nextein project using just remark/rehype which uses not the v7 but a previous v6 of hast-util-raw causing the same issue.
On the other hand, I have inspected the vFile passed by my unified processor and makes no difference since is just an empty holder.
My problem arises when I tried to keep up to date with my dependencies and updating to<EMAIL_ADDRESS>breaks and, as far as I can tell, it seems to be related to this module.
Let me know if I can provide more information. I could fork and create a test case in any of the repos.
Thanks
Max

So in rehype-raw@5 it worked, and in v5.1 it stopped?

On the other hand, I have inspected the vFile passed by my unified processor and makes no difference since is just an empty holder.

Do you mean the vfile you pass is empty? As in, you don’t pass the source contents/value of the file in at all?

So in rehype-raw@5 it worked, and in v5.1 it stopped?

It stopped in v5, I had to downgrade to v4 (which is what I was using before). Honestly I haven't tested v5 vs v5.1 since I did an update by npm ranges.

Do you mean the vfile you pass is empty? As in, you don’t pass the source contents/value of the file in at all?

As I stated in the test case, I use a plain string that I pass to processor.parse. I guess I could try to use to-vfile but in any case, since the parser generates the tree with position information, I don't quite understand why the raw will remove them.

since the parser generates the tree with position information, I don't quite understand why the raw will remove them.

The problem is that, yes, the parser has the source file so it can add positional info, but this plugin also needs the source file. The solution thus is to also pass the source to run: https://github.com/unifiedjs/unified#processorrunsyncnode-file.
I don’t see how this ever worked on v4 though? The difference between 4 and 5 was added types 🤔

could you confirm whether:
const doc = 'whatever'
process.runSync(process.parse(doc), doc)

Does the trick?

Yes, that works!
Awesome, thanks!
Closing this issue.

Great to hear! ✨


Test Jersey property to disable security

Jersey uses security.jersey.enabled to control security. Test benchmark using this property as potential solution for #336. If successful, update Helidon's docs explaining how to use the property.

Security section updated https://github.com/oracle/helidon/pull/361


Use innerHeight to fix misreported window height when doctype is not defined

See http://stackoverflow.com/a/25274520/322253

Interesting, I haven't come across this before. Thanks for the fix :+1:


Docs issue - NavBar "API Docs" get's 404

At the website: https://docs.pterodactyl.io when you select at the navbar the "API Docs" it redirects you to https://docs.pterodactyl.io/api that is getting 404. The correct website is: https://docs.pterodactyl.io/v0.6/reference

Wanted to fix that yesterday evening, forgot though.


MSID: 89911 Version: 2 DOI: 10.48550/arXiv.2305.18417

MSID: 89911
Version: 2
Preprint DOI: https://doi.org/10.48550/arXiv.2305.18417
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=89911
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.48550/arXiv.2305.18417

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/89911v2
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.48550/arXiv.2305.18417
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/89911/v2/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

Getting an oops page - needs further investigaiton

Error message from temporal suggests that a lack of preprint published date (for the v2) in the DocMap is the cause. I have added this into the Unmatched manuscripts spreadsheet and we now will wait for datahub to recognise the change ⏱


Optionally support LZO

I've recently got a decent pure rust implementation of minilzo done here: https://github.com/milesgranger/minilzo3
Toying with the idea of closing #41 while also keeping the MIT license by making it an optional feature.
From the rust build this is pretty straight forward, can build using the feature lzo and poof, you're in GPL land, but for PyPI wheels, I think we'd need to have a cramjam-lzo, cramjam-features-which-use-licenses-that-suck  or something to that effect so a user can explicitly opt into a cramjam distribution which includes LZO.
Not sure how to accomplish this. Maybe add a CI matrix for features like this to build and upload into a different package namespace on PyPI on a per optional feature basis?

I suspect that the users of fastparquet - aside from individual hobbyists - anyone would be happier to not even have to consider the inclusion or not of GPL.
You can, of course, make multiple package names and wheels for them all, and you can have conda-forge make multiple outputs from one feedstock. I don't see how you can depend on an OR of packages, with conda or pip, so that fastparquet can't say "I need cramjam, but cramjam-lzo will do". That is, unless cramjam-lzo depends on cramjam, which would mean duplicated binary code.

This was a concern and something I view as a nonstarter, a package per and duplicate code. I am not sure how to proceed really. Happy that LZO is just as fast as python-lzo, but unhappy dealing with restrictive licenses.
One alternative is having two versions of cramjam, one as it is now and another "full", so developers can do as they potentially are now, try and import the lzo submodule and deal the same way as trying to import python-lzo for that feature. Then dependent on the end user if they have the full cramjam installed (and thus, they deal with implications of GPL/etc on their own).
Or maybe it's just not worth it. 👀

You can't do that with static libraries, though, right? Either it's there or not, so two different versions of the package or two packages. And then it's not obvious how to offer the options to the user.

We can control what ends up in the wheel using feature flags, #[cfg(feature = "lzo")] as it's in the PR now, but this could rather be #[cfg(feature = "full")] to conditionally include lzo or other libs which have none MIT or otherwise restrictive licenses and distribute cramjam and cramjam-full wheels. For lib devs like yourself, I suppose raising an informative error could direct a user to install the latter if they need LZO when attempting from cramjam import lzo fails?
My thinking with the initial post was installing a subpackage directly so no duplicate code would exist such as cramjam.lzo delta code, but I really don't think that's possible. :thinking:

For lib devs like yourself, I suppose raising an informative error could direct a user to install the latter if they need LZO when attempting from cramjam import lzo fails?

but fastparquet would need to depend on the minimal version, so you potentially end up with both :|. Having fastparquet depend on neither is not a good solution, the basic install needs to be functional.

Good point.. so the only viable option is if it can be distributed as a submodule only pip install cramjam.lzo and only include the delta code. Is that a fair assessment?

It would be a fine thing to do, but this should be carefully documented, that whoever wants to depend on cramjam needs to make that decision when defining their requirements. In practice, I imagine that means the non-lzo will get used, exclusively.

In practice, I imagine that means the non-lzo will get used, exclusively.

Well that's an unfortunate idea.. you don't think some people would want to avoid using python-lzo, because it too depends on system packages when they could just use cramjam.lzo  for the same effect? I hope so, as that's sorta the whole point of this project. :sweat_smile:

Only if they know that they specifically need LZO!
I have a feeling it may be possible to build as a single package but with different version-build strings, like cramjam-v1.0.0 Vs cramjam-v1.0.0-lzo, since you can have OR versions (not package names), at least in conda.

Closing in favor of #52


Not being able to list role assignments  for a subscription

Hello, I am trying the following in order to list the role assignments  for a subscription .
from azure.mgmt.authorization import AuthorizationManagementClient
from azure.identity import ClientSecretCredential

tenant_id = 'XXX'
client_id = 'XXX'
client_secret = 'XXX'
subscription_id = 'XXX'

credentials = ClientSecretCredential(
    client_id=client_id,
    client_secret=client_secret,
    tenant_id=tenant_id)

client = AuthorizationManagementClient(
    credential=credentials,
    subscription_id=subscription_id)

roles = client.role_assignments.list()
for role in roles:
    print(role)

However, the response I am getting is not the expected one. I am getting an empty list and not the list of all role assignments  for the particular  subscription_id.

Hi @meglenast - thanks for your question! Directing this to the right people.

@meglenast What are your RBAC permissions level on the subscription ?

So I found the problem the Service Principal  which is associated with the client_id in my case has the 'Management Group Contributor' role which does not have the necessary 'Action'. A solution to this is giving the service principal 'Reader' or 'User Access Administrator' permissions. In other words '*/read' action is required to perform listing the role assignments of a subscription.

@SaurabhSharma-MSFT I have the same issue that giving the service principal 'Reader' or 'User Access Administrator' permissions doesn't solve the problem. What is the necessary permissions for backup? Thanks
https://github.com/Azure/azure-sdk-for-python/issues/23402


Development

Development branch is in working order and ready to merge with master.

I just reverted to an old copy and it seems to be working now...not sure why that was happening then because the error I was getting was for a null window.codebender object and adding this code fixed it.  I will remove that code and update it on the development branch.


Improve/add articles and replies time range filter

issue #148
add 3 features:

articles createdAt time range filter
articles replies createdAt time range filter
replies createdAt time range filter

all filters support elasticsearch date format.

Coverage increased (+0.4%) to 85.194% when pulling 7fdaec8ed074f4da35dd80689109f9f6e73638d8 on improve/add-articles-and-replies-time-range-filter into 342df5d10040a353468737dbdba485cddfae2485 on master.


Cache failure

At some point, I introduced an error in the cache function which meant that it failed silently, and would recompute upstream variables unnecessarily. This was due to the fact that I set a different variable to reference time from what I eventually checked to see if the time was different:
@wraps(func)
        def cached(*args):
            """Step wise cache function"""
            try:  # fails if cache is out of date or not instantiated
                assert cached.t == func.__globals__['time']()
                assert hasattr(cached, 'cache_val')
            except (AssertionError, AttributeError):
                cached.cache_val = func(*args)
                cached.cache_t = func.__globals__['time']()
            return cached.cache_val

        return cached

Fixing this should speed things up nicely...

Thanks to @osychenko for finding this one.


Ability to "Go Back" and "Go Forward" by mouse buttons or touchpad gestures

It would be nice to be able to jump back and forward in code ("Go back" and "Go Forward" commands in command pallette) by pressing mouse side buttons or touchpad (e.g three fingers sideway swipe in MacOS does the thing in Finder and Chrome  by default).
Right now these actions do nothing in VSCode ((

My mouse side buttons already do this.
Version: 1.59.0 (user setup)
Commit: 379476f0e13988d90fab105c5c19e7abc8b1dea8
Date: 2021-08-04T23:13:12.822Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Windows_NT x64 10.0.19043

My mouse side buttons already do this.
Version: 1.59.0 (user setup)
Commit: 379476f
Date: 2021-08-04T23:13:12.822Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Windows_NT x64 10.0.19043

My bad. I didn't use mouse recently)
I meant touchpad gestures in this case.


pessimistic-txn: support lock wait timeout

Signed-off-by: youjiali1995<EMAIL_ADDRESS>
What have you changed?
To support select for update nowait and lock wait timeout, added a wait_timeout field to PessimisticLockRequest: https://github.com/pingcap/kvproto/pull/470. The wait_timeout will overwrite the default wait_for_lock_timeout if it is not 0.
Also added a lock_type to LockInfo: https://github.com/pingcap/kvproto/pull/472. Needs to return the lock type to TiDB. If using select for update nowait, TiDB will check the lock type:

If it is a pessimistic lock, TiDB can return an error immediately.
If it is an optimistic lock, TiDB need to back off and resolve the lock in case it's a left secondary lock in a committed/rollback transaction.

TODO:

To support lock wait timeout, TiDB may set a large wait_timeout. TiKV may need to detect deadlock periodically in case of network error or detector leader not found

What is the type of the changes?
Pick one of the following and delete the others:

New feature (a change which adds functionality)

How is the PR tested?
Please select the tests that you ran to verify your changes:

Unit test

Does this PR affect documentation (docs) or should it be mentioned in the release notes?
No
Does this PR affect tidb-ansible?
No
Refer to a related PR or issue link (optional)
https://github.com/pingcap/tidb/pull/12775

In fact, TiKV doesn't support the true nowait because if wait_timeout is 0, it may be sent by a low version TiDB, so TiDB will set wait_timeout to 1 as nowait. I am considering whether or not handle 1 specially, because it still waits 1ms and detects deadlock, but it's weird.

@coocood @MyonKeminta @sticnarf @cfzjywxk PTAL

@youjiali1995
I think we don't need to handle 1 specially, we can afford to wait 1ms.

If we later really need to remove the 1 ms wait，we can add a bool field nowait then.

LGTM

@youjiali1995
I think we don't need to handle 1 specially, we can afford to wait 1ms.

I agree in practice we probably can afford wait for 1ms. I just think it's not a correct way. If we know it's no wait, we can save the additional cost in lock manager and deadlock detector.

@MyonKeminta PTAL

Using negative wait_timeout as nowait is a good workaround. It won't introduce much complexity if we support nowait.

maxU64 as nowait is an alternative option without proto change.

/release

/release

/release

LGTM

@sticnarf @MyonKeminta PTAL


Export to Curl, Python, Raw fails silently.

Using the new Export options made available on mitmproxy 0.16 doesn't seem to work.  It goes as far as providing the option to export either as a curl command, python code, or raw, but after the selection is made the prompt disappears.
No errors are evident and looking to the file system in the folder where mitmproxy was started doesn't show any new files where an exported command may have written to.  Exiting mitmproxy doesn't show any errors or a stack trace.
Steps to reproduce the problem:

Start mitmproxy on the command line.
Run the following curl command in a different terminal curl --proxy localhost:8080 http://www.google.com
Back to the mitmproxy terminal, select the intercepted url and press E
The prompt Export (as curl command,as python code,as raw request)? shows up and pressing the letter c, p, or r does nothing.

What is the expected behavior?
Unsure; the feature is new and I haven't see it work correctly.
What went wrong?
No opportunity to see the exported curl command.
Any other comments?
$ uname -a
Linux personal 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:    14.04
Codename:   trusty

Mitmproxy Version: 0.16
Operating System: Linux

cc @dufferzafar

@ffernand Thanks for a well written issue!
I think you expect that the Export feature will save the flow to some file on disk, but that is not the case! Here 'Export' just means 'Copy to clipboard'.
So, try exporting and then do a Ctrl + V somewhere. See if it works?
@mhils While I was working on this, I too felt that the wording was a bit unclear. since mitmproxy already has the P key to copy flow contents to clipboard. Your thoughts?

Thanks very much for the fast response!
Looking at my clipboard history, I do indeed see all the exports I've made.  And the feature works great!  As a suggestion... maybe if the prompt said Export to clipboard (... instead of just Export (... ?
Thanks very much for this feature... I know I'll be using this routinely :)

We're discussing ways to fix this in #976. :smiley:


ENH: update package version

Hi! This is the friendly automated conda-forge-webservice.
I've started a version update as instructed in #1.
I'm currently searching for new versions and will update this PR shortly if I find one! Thank you for waiting!
Fixes #1

@traversaro, I believe that this was closed because the package has been published on PyPI one minute later

@traversaro, I believe that this was closed because the package has been published on PyPI one minute later than this PR was opened

Yes, I was a bit too fast with https://github.com/conda-forge/rod-feedstock/issues/1! However, now it is fixed with https://github.com/conda-forge/rod-feedstock/pull/4 .


Is oryol not support OpenGLES2?

Hey dear floooh,
After read some articles from README, seems oryol used to support opengles2. I see OpenGLES2 lake lots of features eg. instancing. But for mobile app compatiblities are f*ck-ass thing must be considered. I can choose avoid use these features ES2 not supported.
Some advice to make this happen?

(Chrome just ate my comment when the connection went down, so here it goes again):
The GLES2 render path should support features like instancing as long as the GLES2 driver exposes the right GL extension (for instancing this would be ARB_instanced_arrays or ANGLE_instanced_arrays). The WebGL version uses this (which is basically GLES2).
If this isn't working as expected on mobile devices, it's probably a bug that can be fixed (however I have no idea whether GLES2 drivers on mobile devices expose the *_instanced_arrays extension.
Cheers,
-Floh.

Thanks for replying.
What I want is let oryol are able to work with iPhone5,iPhone4s(32bit CPU, and only OpenGLES2 supported).
Run the examples on iPhone5 I found I got a black screen.
After some hacks. Something like
#define ORYOL_OPENGLES2 1

gl_impl.h
#include <OpenGLES/ES3/gl.h>
#include <OpenGLES/ES3/glext.h>
\\ to
#include <OpenGLES/ES2/gl.h>
#include <OpenGLES/ES2/glext.h>

iosBridge.mm
this->eaglContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES3];
\\ to
this->eaglContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];

The simplest triangle&cube example worked. But examples like SimpleRenderTarget not correctly rendered. I will track the reason.
The challenge to embed oryol to my online product is the renderer switching is defined by macro.
Which means only one gfx renderer could be compiled. No way to support GLES3 for iPhone5s and above and a compatibility mode for below.
Does oryol prefered a runtime solution to decide which renderer is used? Something like define a failed-chain for this situation.
Besides that, I found the sokol you made. A very very brilliant project. I love so much! Expecting the day sokol integrated to oryol as the underlying gfx driver.

Hmm yes, the native iOS version has only been tested on my iPad Mini4 so far, so problems on older devices are likely :/
The WebGL2 code path has an automatic runtime fallback to WebGL if a WebGL2 context cannot be created, however, this is very simple to implement with emscripten since I can still include the GLES3 headers, even when the WebGL/GLES2 fallback is used.
It would be best if we could get this runtime fallback also working for native GLES3 to GLES2 (this would also be good for Android).
If this doesn't work for some reason, a compile-time switch and additional build configs would be the next best option (for instance emscripten has emsc-make-* which is hardwired to WebGL, and webgl2-emsc-make-* which tries to use WebGL2, and falls back to WebGL if this isn't available.
For iOS this could mean: ios-xcode-* could be hardwired to the GLES2 renderer, and gles3-ios-xcode-* could either be hardwired to GLES3, or implement a dynamic GLES3-to-GLES2 fallback.
Btw: did you try the Metal render backend (hmm, but I think the GLES2 iPhones didn't support Metal yet, only the GLES3 iPhones... same problem).

PS: the decision which OpenGL version is used for a platform is here:
https://github.com/floooh/oryol/blob/095e81a8a8e977b20f70db33b540ebd510a7fe72/fips-include.cmake#L66-L89
Note how the emscripten version has an additional check to decide whether it should use WebGL2 or WebGL.

@floooh  Good news.
After lots of tests.  Finally just add a simple fail-back logic on iOS adaptor layer solve the problems. (And for running the samples on iPhone5 successfully. Fips should support a armv7 (32bit CPU) )
See the merge request for this minor changes.
https://github.com/floooh/fips/pull/162
https://github.com/floooh/oryol/pull/276

And, sadly, I don't have android device that only support OpenGLES2.

Ok, the 2 fixes look surprisingly simple :) I'll just merge them even though I can't test at the moment (only in the simulator).
Thanks a lot for the contributions, if you stumble over any other issues with older mobile devices, don't hesitate to contact me directly or open new github issues / PRs. Support for lower-end-devices is definitely an important goal for Oryol.


Fixing potential changes to footer for improved user experience 67

Added Social Media Icons above the navigation links in the footer
Changed the colour of the text, "This website is only for educational purposes..." to white to make it more readable on the blue background.

@Mayuresh-22 Is there anything else you want me to change in the footer?

@Mayuresh-22 Is there anything else you want me to change in the footer?

I think for now it's okay. I am merging this PR.


Kettle RnD and Atmos revamp

About the PR

Kettle's atmos was moved to be next to engineering, giving it a TEG as an additional power source.
Kettle's science department was moved to where atmos used to be.
Kettle's old science experienced a tragic plasmafire, it is now a derelict maints area.

Minor fixes:

Cargo airlocks
Lawyer can exit their room again
Even less exterior airlock wire fuckery! (Missed one set of doors in my previous PR.)

This PR was the effort of multiple people (including @luckyshotpictures and @Gotimanga and myself ). I am this map's maintainer and approve of these changes being made.
Why / Balance

Primarily to add a TEG. A rework of the main engineering area is also coming up now that this major roadblock was dealt with.
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

New atmos:

New sci:

Old (now ruined) sci:

Changelog

:cl: TsjipTsjip & Luckyshotpictures & Deeja

tweak: Kettle received a new atmospherics department and a new research center.

Test failure looks related..... Looking into it.

Will get accurate pictures for the version currently up tomorrow. This Tsjip is sleepy.

Test failure is once again related. Tomorrow.

I'd love to oblige, thank you for notifying me of this. If they wish to speak to me directly, I am available on discord with the same name.

Conflicting PR: #22009 , I'll mirror these changes in the map file when I get the chance to work on this.

Map file updated and pictures updated to reflect recent changes. The map name issue has not been resolved thus far and needs additional discussion, keeping on draft.

map name will need changing according to checkraze

map name will need changing according to checkraze

I'm aware, I need time to consider potential new names and potentially converse with checkraze to allow them to have a say as well if they want. This is in progress.

Ready for review. Please please please check my changes thoroughly before merging. I had to edit a test for this and I'm not entirely familiar with how those work. I am not currently capable of running my dev server to check if the updated files actually work.
Some non-obvious changes that I did include:

Updated BecomesStationComponent to have ID 'Gemini' in gemini.yml (map file)
Copied kettle.yml's proto and replaced references to Kettle by Gemini.
Kept the original kettle files in, people can still run kettle if they want.

Kettle my beloved... :sob:


Automated cherry pick of #2487: Fix test-upgrade-antrea.sh script so it can be used in

Cherry pick of #2487 on release-1.0.
#2487: Fix test-upgrade-antrea.sh script so it can be used in
For details on the cherry pick process, see the cherry pick requests page.

Codecov Report

Merging #2511 (0567a42) into release-1.0 (529d6f8) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           release-1.0    #2511      +/-   ##
===============================================
- Coverage        60.73%   60.63%   -0.10%
===============================================
  Files              272      272
  Lines            20375    20375
===============================================
- Hits             12374    12354      -20
- Misses            6711     6727      +16
- Partials          1290     1294       +4

Flag
Coverage Δ

kind-e2e-tests
51.45% <ø> (-0.13%)
:arrow_down:

unit-tests
41.31% <ø> (-0.03%)
:arrow_down:

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

Impacted Files
Coverage Δ

pkg/apiserver/handlers/endpoint/handler.go
58.82% <0.00%> (-11.77%)
:arrow_down:

...gent/controller/networkpolicy/status_controller.go
72.60% <0.00%> (-5.48%)
:arrow_down:

pkg/apis/controlplane/v1beta2/sets.go
66.66% <0.00%> (-2.57%)
:arrow_down:

pkg/controller/networkpolicy/status_controller.go
85.16% <0.00%> (-1.30%)
:arrow_down:

pkg/agent/openflow/pipeline.go
66.08% <0.00%> (-0.70%)
:arrow_down:

...ntroller/networkpolicy/networkpolicy_controller.go
69.35% <0.00%> (-0.65%)
:arrow_down:

pkg/agent/route/route_linux.go
41.86% <0.00%> (-0.59%)
:arrow_down:

pkg/agent/openflow/client.go
57.97% <0.00%> (-0.54%)
:arrow_down:

pkg/agent/flowexporter/exporter/exporter.go
75.24% <0.00%> (+0.99%)
:arrow_up:


Migrate to ClassGraph (formerly FastClasspathScanner) 4.0.0

Pull request is ready to merge now, as ClassGraph 4.0.0 has been released.

ClassGraph 4.0.0 is now in JCenter as well, so this is ready to merge.

Thank you @PascalSchumacher!


feat: utxo list

Resolves #338.
Still in draft as some cleanup, i18n, etc. is still missing. Should be ready to play around with, though. Let me know what you think. More advanced stuff like filtering the table by tags or so can be done later imo.
⚠ The diff is only so huge because I installed a library to handle the table.
📸

Btw, since it came up in the ccommunity call: The tags are colored as follows:

cj-out: 🟢 Green to indicate success. We want people to have lots of green UTXOs.
change-out: 🟡 Yellow to indicate "be careful". Getting change out of a collaborative transaction is something completely normal (unless you sweep). So it's fine to have these UTXOs, but you have to be careful with them.
reused: 🔴 Red to indicate danger. You're likely doing something wrong if you have a reused address.

All other tags won't have any color. Thoughts on that? cc @dergigi

Ye, I’m just cleaning up these things. Code is not yet ready. ;)

On 28.07.2022, at 10:05, Thebora Kompanioni @.***> wrote:
@theborakompanioni commented on this pull request.
In package.json https://github.com/joinmarket-webui/joinmarket-webui/pull/430#discussion_r931906688:

"install": "^0.13.0",

"npm": "^8.15.0"
This might have been a mistake. Is it really necessary?

—
Reply to this email directly, view it on GitHub https://github.com/joinmarket-webui/joinmarket-webui/pull/430#pullrequestreview-1053655628, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMP6JXNMBVC4IBIL772C5TVWI5MRANCNFSM542BIISA.
You are receiving this because you were assigned.

Dark mode issue in the "Account Details" view. This might have been introduced by my while updating bootstrap.

As I am the culprit, I will fix it myself later on. Just noting it down.

@theborakompanioni Added the confirmations to the table as discussed. ✅ Also added a refresh button that reloads the wallet info and thus refreshes the utxos.

What follows are some observations while playing with the UI. First of all: Great job. Amazing for a first iteration. It is very informative, functional, visually appealing, and hopefully quite useful for users. I'm eager to hear the feedback from the community.
Observations

Currently it is possible to unfreeze non-expired fidelity bonds.

It is prevented in current CurrentWalletAdvanced view. Cannot remember exactly right now what the issue is, but I think this leads to some problems. At best, it is handled in the backend, but till that is the case, we should keep this behaviour imho (was introduced in c68e4c5c64).

If the overlay is opened, switched to tab "Jar Details" and subsequently closed. The next time the overlay is opened tab "UTXOs" is activated, but the contents of tab "Jar Details" are still shown. This also applies to the active Jar -> Open Jar#0 -> Switch to Jar#2 (active) -> Close overlay -> Click Jar#0 -> Jar#2 still shown :x: .

What follows are things that can probably be addressed in follow-up PRs:

Can sorting the utxo list by confirmations be added? I think there is a use case for users seeking to "spend my most recent coins" or "spend oldest coins".

Nits

Hovering over addresses in "Jar Details" displays a border - is this intended? If so, a left padding is missing. I think it actually looks good..

"Wallet Info reload" function is great. But it feels like a visual feedback is missing (On reload success -> nothing changes -> user might not know what happened or are "unsatisfied"/).
Thinking of two things:

showing a :heavy_check_mark:  icon like we do on successful "address copy"
introducing toasts (https://react-bootstrap.github.io/components/toasts/) - e.g. "Successfully reloaded wallet informatioN"

Thought: They might be needed in the future anyway, e.g. displaying infos from websockets (incoming transaction, etc.)

Now that the switching of Jars in the overlay looks nice, do you think it should switch places with the "close" button?

Thought: This is the only view having the close button on the left hand side. Would be more consistent to have it on the right, imho.

If the first account in a jar is empty, the accordion body is visually empty (other show an xpub, but JM treats it specially and does not provide the xpub for the first account)

As a user, this would "surpise" me, or at least raise questions.  We have time till 3909-09-11 10:10pm till block #99,999,999 is mined.. so maybe this can be fixed later.

Questions

Do you think "freeze all non-selected coins" is a common use case?

Should the same visual representation of tags as in the "UTXOs" tab be used in the "Jar Details" tab?

Can advanced mode be removed? Maybe the flag useAdvancedWalletMode can be kept, but maybe the actual "CurrentWalletAdvanced" view (and "DisplayAccount" respectively) is not needed anymore?

Moving all used sub-views to into jar_details folder (e.g. DisplayBranch.tsx)

Nice! Great job, that looks really awesome already. Love the confirmation indicator.

All other tags (new, used, non-cj-change, etc.) won't have any color as they feel somewhat neutral to me. Thoughts on that?

I like the green/yellow/red distinction, and I think having no colors on the other tags is fine. Let's keep it like that and see how it is perceived by users.

Only thing I found during testing is that there can be a label/text overlap in the "Jar Details" view, but I guess that's unrelated to this PR. Just bringing it up here so we don't forget.

Jam is a web UI for JoinMarket with focus on user-friendliness. It aims to provide sensible defaults and be easy to use for beginners while still having the features advanced users expect.

We're getting there! 😊 🚀

Awesome, thanks for all the detailed feedback! 🙌 🙏 It's great to know that everything's been thoroughly tested. 👌
I think I addressed everything that needs immediate attention. Please have another look. @theborakompanioni.
Below my comments on the things I didn't address yet.

"Wallet Info reload" function is great. But it feels like a visual feedback is missing

There's some feedback in terms of a loading spinner being shown and hidden again after loading. I personally don't think much more feedback is required (cf. a reload button in a browser which also only has two states usually: loading and not loading.)

If the first account in a jar is empty, the accordion body is visually empty

Jar details needs a redesign and rewrite imo. Haven't touched it beyond some obvious issues.

Current max. confirmations is 99999999

Let's push that fix to an upcoming version. 😄

Have you considered showing the sum of all selected utxos?

Good idea, let's track that as an improvement: https://github.com/joinmarket-webui/jam/issues/440.

Do you think "freeze all non-selected coins" is a common use case in general?

No I think that'd be confusing to be honest. 😄 Is that a common pattern elsewhere -- performing an operation on non-selected items?

Should the same visual representation of tags as in the "UTXOs" tab be used in the "Jar Details" tab?

Yes. As mentioned, the Jar Details tab needs a redesign.

Can advanced mode be removed? Maybe the flag useAdvancedWalletMode can be kept, but maybe the actual "CurrentWalletAdvanced" view (and "DisplayAccount" respectively) is not needed anymore?

Yes I think we're ready to finally remove it now. I tracked https://github.com/joinmarket-webui/jam/issues/441.

https://www.figma.com/file/kfejZJFlwBywvLEnPEmJo1/JoinMarket-UI?node-id=5071%3A87607

https://user-images.githubusercontent.com/96262473/184351051-60867ad0-af57-4861-a041-68231bff357f.mov

There's some feedback in terms of a loading spinner being shown and hidden again after loading. I personally don't think much more feedback is required (cf. a reload button in a browser which also only has two states usually: loading and not loading.)

I think its better to have a green Checkmark replacing the spinning loader / refresh icon for 2 seconds as an indicator.
your example with a reload for a browser window has a visual feedback on success: the whole window goes blank and rebuilds when you do a browser refresh. because we don't do that, a little success indicator (also possible as a toast) in our case would be helpful


Add ProxyFromEnvironment in downloadFile method (#1048)

Add ProxyFromEnvironment in downloadFile method.
This is a additional PR to #1048

@mukundansundar is this PR ready to be merged?

This fix got released with 1.9. Should we still release this with 1.8? @mukundansundar @yaron2


Use sparse checkout in Compliance job

Description
Replication of https://github.com/Azure/azure-sdk-for-java/pull/35835 and https://github.com/Azure/azure-sdk-for-java/pull/35867 from the azure-sdk-for-java repository.
Updates the Compliance CI job to use sparse checkout instead of full repository checkout when running compliance for non-private repository jobs. When running Compliance for pull requests sparse checkout will only checkout the files changed by the PR, replicating what CredScan validates, and for scheduled or manually triggered jobs it will checkout all files in the service directory specified by the CI configuration, again replicating what CredScan validates.
This reduces the amount of files, and time, the CredScan job spends checking out code from about a few minutes to a few seconds. In the Java repository, and likely similar in this repository, the checkout time reduced from about 3-5 minutes to 20-30 seconds.
Sparse checkout is disabled to follow disabled due to Azure/azure-sdk-for-python#30683
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

Same comment as https://github.com/Azure/azure-sdk-for-js/pull/26505/files#r1269920249


[Snyk] Fix for 10 vulnerabilities

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

src/frontend/package.json
src/frontend/package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

479/1000  Why? Has a fix available, CVSS 5.3
Regular Expression Denial of Service (ReDoS) SNYK-JS-CSSWHAT-1298035
No
No Known Exploit

479/1000  Why? Has a fix available, CVSS 5.3
Regular Expression Denial of Service (ReDoS) SNYK-JS-MARKED-174116
No
No Known Exploit

479/1000  Why? Has a fix available, CVSS 5.3
Regular Expression Denial of Service (ReDoS) SNYK-JS-MARKED-451540
No
No Known Exploit

696/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 7.5
Regular Expression Denial of Service (ReDoS) SNYK-JS-NTHCHECK-1586032
No
Proof of Concept

654/1000  Why? Has a fix available, CVSS 8.8
Cross-site Scripting (XSS) npm:marked:20150520
No
No Known Exploit

589/1000  Why? Has a fix available, CVSS 7.5
Cross-site Scripting (XSS) npm:marked:20170112
No
No Known Exploit

589/1000  Why? Has a fix available, CVSS 7.5
Cross-site Scripting (XSS) npm:marked:20170815
No
No Known Exploit

454/1000  Why? Has a fix available, CVSS 4.8
Cross-site Scripting (XSS) npm:marked:20170815-1
No
No Known Exploit

589/1000  Why? Has a fix available, CVSS 7.5
Regular Expression Denial of Service (ReDoS) npm:marked:20170907
No
No Known Exploit

696/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 7.5
Regular Expression Denial of Service (ReDoS) npm:marked:20180225
No
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Commit messages

Package name: marked
    The new version differs by 250 commits.

529a8d4 Merge pull request #1441 from styfle/release-0.6.2
fc5dbf1 🗜 minify [skip ci]
b1ddd3c Merge pull request #1460 from andersk/inline-text-quadratic
be27472 Improve worst-case performance of inline.text regex
6b88601 0.6.2
ba1de1e 🗜 minify [skip ci]
d94253c Merge pull request #1438 from UziTech/html-new-line-fix
6eec528 Merge pull request #1449 from UziTech/use-htmldiffer
0cd0333 remove redundant comments
ff127c5 use template literals
a16251d fix test spacing
da57301 use htmldiffer in file tests & update to node 4
621f649 abstract htmldiffer
42e816c fix again
246dd3d fix whitespace after tag
f1089fe add test
0f0b763 allow html without \n after
d069d0d Merge pull request #1448 from UziTech/version
5d6bde0 Merge pull request #1444 from UziTech/normalize-tests
4760772 fix tests
df310a8 remove header ids from original tests
775d08d move redos tests to /redos folder
b169e7b add excerpt length constant
fd9dc21 update deps

See the full diff

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Regular Expression Denial of Service (ReDoS)
🦉 Cross-site Scripting (XSS)

:shipit:


Multires patch

This PR is a patch to the multi-resolution functionality.
This PR includes:

corner case fix. In lower resolution space recon, pass in downsampled init image and prox image (lr_init_image and lr_prox_image) if an init image is given at highest resolution space.
We failed to catch this corner case previously, because non of our previous test cases cover the case of using multi-res and non default init image at the same time.

memory efficency. Delete low resolution variables once the low resolution recon is done.

Testing:

Ran demo_3D_shepp_logan.py and demo_mace3D.py, both experiments yield same results and convergence behavior as before.
In demo_3D_shepp_logan.py, set init_image = phantom, and max_resolutions=2:

init_image = np.copy(phantom)
recon = mbircone.cone3D.recon(sino, angles, dist_source_detector, magnification, init_image=init_image, max_resolutions=2, sharpness=sharpness, T=T)

We expect that the convergence in all resolution spaces are fast, because the initial condition is the perfect answer. So the lower resolution space only needs to correct the aliasing resulted from down-sampling.
Before the fix: The lowest resolution recon takes 21 iterations to converge, as a result of incorrect init_image provided.
After the fix: The lowest resolution recon takes 12 iterations to converge.

I ran the demos.  Looks good to me.


Format code snippet in tools section.

In the "tools" tab we have a yaml code snippet for the experiment manifest that looks a bit out of place without better formatting:

I'm not sure what markdown renderer Jekyll is using, but would be good to format the code block in a similar way to how github does, eg. with a grey background, maybe a bit of indentation, and if possible, syntax highlighting.
- name: baseline_control
  desc: Listening study baseline condition
  playerCount: 2
  assignPositionsBy: random
  gameStages:
    - name: Intro
      type: prompt
      duration: 45
      elements:
        - intro_no_training.md
        - type: submitButton

    - name: Attitude Presurvey
      duration: 120
      elements:
        - urban_unrest_survey.md
        - type: submitButton

    - name: Discussion
      duration: 600
      chatType: video
      elements:
        - type: prompt
          file: urban_unrest_discussion.md
        - type: prompt
          file: instructions_listener.md
          showToPositions:
            - 0
        - type: prompt
          file: projects/weinstein_listening/instructions_speaker.md
          showToPositions:
            - 1

Ideally this should be done without too much change to the markdown file itself.

helpful link: https://stackoverflow.com/questions/35759972/fenced-code-block-not-highlighted-properly

Interesting. We set a markdown renderer in _config.yml as markdown:kramdown, but I don't know quite what that influences - it may talk to part of the jekyll agency theme that we're loading remotely (github fetches it).
I can either let you read more into this and try and figure it out, or we can ask the fellow who set up the template for me. What would you like to do? Are you stuck?

I've tried it for a bit more but still haven't been able to figure it out, so help would be appreciated!

@andriy0211 - sent you a message on upwork, let me know there if you're interested in this as a quick extension


Master with aus changes

As part of the Q4 work order from ABS, some of the changes were supposed to be applied in the master branch (as agreed with Ivan).

Notifying a parent window about a change of the prompt if Intake24 is displayed in iFrame
In all the prompts (Guide, Standart, Quantity, AsServed) added a Header and explicitly mentioned the current Name of the food.

Changes from the previous order:

Footer as an Unordered List for better Accesibility
Configurability of the landing (Info Page). Two additional (optional) variables are added to the application.conf file in thedeployment repo: infoPageLocaleDisclaimer and deploymentLocaleFooterLogo

Submitting this PR so the following changes can be done here without introducing unnecessary diverging between Master and ABS branches.


Minor update "resource" vs "subscription"

Using "subscription" is incorrect in this context and confuses users. Resource would be better as that is what the user is creating.
@garyericson
@aahill

@rlagh2 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

merging per Angela Robertson<EMAIL_ADDRESS>email request

Hi @jborsecnik, Could you close this? I'm working with @rlagh2 on some edits that include this one, which should be live soon.

Ok, Angela?
(This is one the PRs I just mentioned that has a conflict.)
Thx -jb^
From: aahill<EMAIL_ADDRESS>Sent: Wednesday, July 17, 2019 9:55 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Jeff Borsecnik (Aquent LLC<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Minor update "resource" vs "subscription" (#34068)
Hi @jborsecnikhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjborsecnik&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793133938055&sdata=L%2BPLhgT31p6LTR3lWLBqRS%2BUoeXEBkXyxENMh3S4Ew8%3D&reserved=0, Could you close this? I'm working with @rlagh2https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frlagh2&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793133948048&sdata=kLAeGclCHyVYu8TC3xKD1G2OIvSyqX%2FMAhIvpKhYiLo%3D&reserved=0 on some edits that include this one, which should be live soon.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fpull%2F34068%3Femail_source%3Dnotifications%26email_token%3DAIW2RCNOONUGICL45KGW6OLP75FG7A5CNFSM4H3WRIY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2FBDLY%23issuecomment-512364975&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793133948048&sdata=O1smbZMoggcSmHZ2Y9aax7CfJ0IeQcufWGBXnja4rl4%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIW2RCP2VQIBXLNHWKO5WV3P75FG7ANCNFSM4H3WRIYQ&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793134487809&sdata=ujSI5Kc3YwLu6femkCRSJMHIhNiT64mBs99wAsBkVmg%3D&reserved=0.

closing per @aahill request

I did close this, as I assume it will resolve the conflict. If further action is needed, Angela et. al, let me know.
Thx jeff b
From: Jeff Borsecnik (Aquent LLC)
Sent: Wednesday, July 17, 2019 9:57 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Angela Robertson<EMAIL_ADDRESS>Cc: Mention<EMAIL_ADDRESS>Subject: RE: [MicrosoftDocs/azure-docs] Minor update "resource" vs "subscription" (#34068)
Ok, Angela?
(This is one the PRs I just mentioned that has a conflict.)
Thx -jb^
From: aahill <notifications<EMAIL_ADDRESS>Sent: Wednesday, July 17, 2019 9:55 AM
To: MicrosoftDocs/azure-docs <azure-docs<EMAIL_ADDRESS>Cc: Jeff Borsecnik (Aquent LLC) <v-jeffbo<EMAIL_ADDRESS>Mention <mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Minor update "resource" vs "subscription" (#34068)
Hi @jborsecnikhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjborsecnik&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793133938055&sdata=L%2BPLhgT31p6LTR3lWLBqRS%2BUoeXEBkXyxENMh3S4Ew8%3D&reserved=0, Could you close this? I'm working with @rlagh2https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frlagh2&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793133948048&sdata=kLAeGclCHyVYu8TC3xKD1G2OIvSyqX%2FMAhIvpKhYiLo%3D&reserved=0 on some edits that include this one, which should be live soon.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fpull%2F34068%3Femail_source%3Dnotifications%26email_token%3DAIW2RCNOONUGICL45KGW6OLP75FG7A5CNFSM4H3WRIY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2FBDLY%23issuecomment-512364975&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793133948048&sdata=O1smbZMoggcSmHZ2Y9aax7CfJ0IeQcufWGBXnja4rl4%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIW2RCP2VQIBXLNHWKO5WV3P75FG7ANCNFSM4H3WRIYQ&data=02|01|v-jeffbo%40microsoft.com|18c0ee3516b841188e4f08d70ad788c1|72f988bf86f141af91ab2d7cd011db47|1|0|636989793134487809&sdata=ujSI5Kc3YwLu6femkCRSJMHIhNiT64mBs99wAsBkVmg%3D&reserved=0.


Steven Test

Null commit PR to test CI testing.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

LGTM

Jenkins: retest this please

Jenkins: retest this please


Strange rendering of a hyperlinked sentence

The highlighted sentence here is center-aligned but it's not clear why:

Here is the source for it:
https://github.com/prisma/docs/blob/main/content/200-orm/200-prisma-client/500-deployment/650-caveats-when-deploying-to-aws-platforms.mdx#L19

Might be related to this: https://github.com/prisma/docs/issues/5582

Looks as expected to me now:


https://github.community/t/5-ways-to-sort-wisely/175081?u=prdarm

[Enter feedback here]

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

ID: 413163f0-28c3-a2a7-d626-fcb81bcb2257
Version Independent ID: 57c127da-2b1e-d29e-9abb-a3c258762ccf
Content: .NET Client Libraries - Azure DevOps
Content Source: docs/integrate/concepts/dotnet-client-libraries.md
Product: devops
Technology: devops-ecosystem
GitHub Login: @chcomley
Microsoft Alias: chcomley

@prdarm - Thanks for your feedback; we appreciate it. To make sure we have all the information needed to address your issue, please let us know which article you’re referencing, or provide more context around the general task.


Can this work with GITLAB

Hi,
Quick Question: Can this work with Gitlab or Gitamin as well same as GITHUB?

+1

yet not, but is on roadmap it integration

I already started the GitLab integration, Socialite Proviter to GitLab : http://socialiteproviders.github.io/providers/gitlab/
I'll add this in the first 15 days of 2017 :)

Don't forget the wonderful Gogs. ;)

Work in progress at #77 :)

#79 PR @ develop branch.


events.create_connection does not create secret

You have the issue symptoms written in a comment in source
https://github.com/getmoto/moto/blob/792f7a322696c44e12a9fa66a323dbd6f5fa73d0/moto/events/models.py#L801
In AWS after creating a connection, the follow up describe_connection response will have a SecretArn set, which will contain the AuthParameters.
connection_response = boto3.client("events").create_connection(
        Name="my-destination",
        Description="my-destination",
        AuthorizationType='API_KEY',
        AuthParameters = {
            'ApiKeyAuthParameters': {
                'ApiKeyName': 'X-Api-Key',
                'ApiKeyValue': 'password'
            }
        }
    )

describe_connection should return a SecretArn, which is transparently created as the "ApiKeyAuthParameters" dictionary in practice (i.e. its a JSON document with two fields).
I am not totally sure of the full behaviour. I guess it requires some empiricism to figure out. Let me know if filing these vague tickets is helpful.

Hi @tomlarkworthy, that's definitely helpful - we should be able to figure out what AWS exactly does here behind the scenes, it seems fairly straightforward.
Thanks for raising this!

@bblommers do you think it's worth it here to bring in the secrets manager backend and actually create the secret that contains the auth parameters? Or are we comfortable with just mocking an Arn that just doesn't point to anything

Hi @armichaud! I would actually create the secret, yes. It is a fairly cheap operation, and easy to support, so I so no reason not to.


feature(instrumentor): Allow only running specific mutants

This is a PR to accompany issue #2751. It allows you to define specific mutants through the --mutate flag by adding a non-inclusive range for the mutant you want to run. For example, --mutate src/index.ts:1:3:1:5 would only instrument mutants that start on line 1 column 3 and end on line 1 column 5 (non-inclusive)

I've started a review at my own risk (since you're still busy with it) and got some remarks.
It's fine, I was thinking of doing the --specificMutantsJSON flag as part of a different PR anyway and move this from WIP to ready for review.

Mainly I think file.js:5:0:20:0 should mutate line 5 up and including line 20. So you declare a range of mutants. I think the way you see it is that it will only mutate that specific mutant itself.
Only mutating the specific mutant defined and not any inclusive mutants is what I laid out in the issue and was what I thought would be good here. What's the advantage of having an inclusive range rather than a specific match? As long as I can have some way to define specific non-inclusive mutant ranges then I'm not bothered. I can move that functionality to --specificMutantJSON, but I get the feeling that you're not super keen on that solution either

I've gone ahead and moved the parsing to happen only in the input-file-resolver, and the validation to only occur in the options-validator. I haven't implemented skipping any code that lies outside of the mutation range, but I'm not even sure how I'd test that.
We'd have to not skip over nodes that surround the ranges, so we'd need to keep the current condition and just have another one that does skip for anything where none of the node falls inside that range, which is what I think you were thinking about? But in that case, the observable output of the new condition wouldn't change, and it would be a purely performance improvement with no way to write a test against it, right?
I think it's a great idea, I'm just not sure how you want to approach it

We'd have to not skip over nodes that surround the ranges, so we'd need to keep the current condition and just have another one that does skip for anything where none of the node falls inside that range, which is what I think you were thinking about? But in that case, the observable output of the new condition wouldn't change, and it would be a purely performance improvement with no way to write a test against it, right?

Exactly right. We should have tests for all those cases you're describing, make sure our code works, then we can introduce the performance enhancement and see if the tests still pass. The performance enhancement doesn't have an observable output, but that's fine, as long as the tests still pass, nothing broke 🤷♂. That's enough for me. It would result in equivalent mutants, which is why I wouldn't go for 100% mutation score.
I actually found a bug... I think:
              path.node.loc!.start.line >= mutant.start.line &&
              path.node.loc!.start.column >= mutant.start.column &&
              path.node.loc!.end.line <= mutant.end.line &&
              path.node.loc!.end.column <= mutant.end.column

This would mean that the range from line 1, column 1, to line 1 column 2 would not fall into the range of line 0, column 0, line 100, column 0.
I'll go ahead and add tests for this and fix it. As well as review your work. Thanks for the hard work and sorry again for my late responses

Ok I think this should be it 😅. This is what I changed:

Rename filename to fileName. This is a hot topic within our code base, but since we're using fileName currently everywhere I went ahead and changed it.
Rename mutationRange to mutationRanges, since it's an array.
Implement the new mutation range matching algorithm using locationIncluded and locationOverlaps. I think it looks quite nice 🎨
Change the mutation range functionality a bit. Stryker will now also files that don't have mutation ranges. I thought this would make the most sense. If you run stryker run -m "foo.js:0:0:1:0,bar.js" I would personally expect bar.js` to also be mutated. Thoughts?
Refactor the regexes to reduce them to 1 uber regex. It uses regex groups to capture the file name, lines and columns:  /(.*):(\d+):(\d+):(\d+):(\d+)$/. It's exported and reused by the options validator.
Changed the e2e test a bit so it also verifies that files without ranges are mutated and files that are not listed at all are not mutated.
I've documented mutation ranges in configuration.md

Some final thoughts:

🤔 should we change the syntax to foo.js:1:0-10:0?  That might feel more natural for some users
🤔 should we allow for a short range syntax: foo.js:1-10? This would be pretty simple to implement:

1-10 is equivalent to 1:0-11:0 (it includes everything though line 10 excluding line 11)
1:4-10 is equivalent to 1:4-11:0

Thanks for your help, the changes you made are great!

should we change the syntax to foo.js:1:0-10:0? That might feel more natural for some users
should we allow for a short range syntax: foo.js:1-10? This would be pretty simple to implement

Both of these ideas are fantastic. I'll try to find some time to do that

@nicojs I've updated the regex to accept the new format as well as optional columns. The documentation should also be updated to reflect it

I've changed the implementation a bit. Now the to-line is inclusive when using a-b syntax. I'm using Number.MAX_SAFE_INTEGER as a default for the column number, sounds like a big enough number to me.


Basic layout & components

add basic layout with header and footer;
add <Button>, <Dialog>, <TextIcon>, etc. components from matters-web;

are you going to push more commits to here? or why name as feature/login; I have test running locally, not seeing a login page, but the index home page look good 👍 to merge

I started this branch to test auth but ended with current PR, forgot to rename it...will have another branch on auth & wallet features.


fetchurl: support sha512

Nix 1.11 supports SHA512 hash algorithm.

Maybe add an assertion into fetchurl to check that nix version is high enough? I know the version of the evaluating nix doesn't need to be the version of the drv-realizing nix (which is the interesting version here IMO), but I'd still show a warning at least.

BTW, I got a unknown hash algorithm ‘sha512’ error when I try SHA512 version of firefox-bin package (https://github.com/taku0/nixpkgs/tree/firefox-bin-44.0-sha512) despite of I have installed Nix 1.11.1.
$ nixos-version
15.09.897.aa2d714 (Dingo)

$ nix-env -i -f ~/src/nixpkgs/ nix
(snip)

$ nix-env --version
nix-env (Nix) 1.11.1

$ nix-env --dry-run -j 4 --show-trace -i --keep-going --keep-failed -f ~/src/nixpkgs/ -A pkgs.firefox-bin 2>&1
(dry run; not doing anything)
replacing old ‘firefox-bin-44.0’
installing ‘firefox-bin-44.0’
error: while evaluating the attribute ‘buildCommand’ of the derivation ‘firefox-bin-44.0’ at ~/src/nixpkgs/pkgs/applications/networking/browsers/firefox/wrapper.nix:55:10:
while evaluating the attribute ‘src’ of the derivation ‘firefox-bin-unwrapped-44.0’ at ~/src/nixpkgs/pkgs/applications/networking/browsers/firefox-bin/default.nix:63:3:
unknown hash algorithm ‘sha512’

Old Nix 1.10 is called from somewhere?

Added the assertion.

Probably you need to update the system Nix as well since that's whose nix-daemon binary is being used.

I thought so originally, but it confuses me that the error is during evaluation and I thought that isn't done by the daemon.

AFAIK evaluation does require some sort of connection to the daemon so that the .drv files can get written and for copying local paths (like ./foo.patch) to the store.

ready?

Rebased.

Looks like this was done in https://github.com/NixOS/nixpkgs/commit/3ecbe604ef751f475a247275ccff8c95f835aa3b

@grahamc looks that way

We should also do an assert for version.

fixed in 0f9268e52c03383ade24642836be1a4e74070df3


Allow including/excluding by key in keep-alive

What problem does this feature solve?
Want more flexible caching components
What does the proposed API look like?
<keep-alive include="detail-id-1,detail-id-2">
        <component :is="Component" :key="key" />
 </keep-alive>

Source code：232 line
  const name = getName(comp);
  const { include, exclude, max } = props;

  if (
    (include && (!name || !matches(include, name))) ||
    (exclude && name && matches(exclude, name))
  ) {
    return (current = vnode)
  }

  const key = vnode.key == null ? comp : vnode.key
  const cachedVNode = cache.get(key)

modify：
  const name = vnode.key || getName(comp)

The "key" value is preferred as the include or exclude condition

This was asked for Vue 2 https://github.com/vuejs/vue/issues/8028

Closed, tracking here https://github.com/vuejs/rfcs/pull/284

Closed, tracking here vuejs/rfcs#284

Any progress?

Closed, tracking here vuejs/rfcs#284

Is there anything holding this up?

三年又三年

三年又三年

以有对应实现：源代码：https://github.com/meadmin-cn/meadmin-template/tree/main/src/components/meKeepAlive
对应文档：https://meadmin-cn.github.io/meadmin-template-doc/components/core/meKeepAlive.html


Change path to caddy binary

I have not seen anyone put caddy at /opt/caddy/caddy, and getcaddy.com follows /usr/local/bin as well

Thanks! I think /usr/local/bin is probably better too.

@MSF-Jarvis Oops, can you update the readme in that folder too? It has the old paths still.

Sure, will do it in an hour or so when I'm home :)
On 14-Jul-2016 9:50 PM, "Matt Holt"<EMAIL_ADDRESS>wrote:

@MSF-Jarvis https://github.com/MSF-Jarvis Oops, can you update the
readme in that folder too? It has the old paths still.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/caddyserver/examples/pull/12#issuecomment-232715801,
or mute the thread
https://github.com/notifications/unsubscribe/AMuuGu0OOzs9gFwqo3jt-57HnFQKQ5ktks5qVmHTgaJpZM4JMXqd
.


Can't install requirements because of some pyyaml issue

This is on MacOS Mojave.  It's all a bit too deep in the python for me.
Here's the whole shebang:
Gist: https://gist.github.com/ejheil/04def72ad3a6b6abb13ec6d04534b5ef
The bits which were called out as errors include:
Building wheel for pyyaml (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /Users/ed/code/yahoo-groups-backup/bin/python3.7 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/private/var/folders/cc/krt30ncd75s8g7fzyn5kw3fh0000gp/T/pip-install-08w2dfti/pyyaml/setup.py'"'"'; __file__='"'"'/private/var/folders/cc/krt30ncd75s8g7fzyn5kw3fh0000gp/T/pip-install-08w2dfti/pyyaml/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /private/var/folders/cc/krt30ncd75s8g7fzyn5kw3fh0000gp/T/pip-wheel-4ryora9b --python-tag cp37
       cwd: /private/var/folders/cc/krt30ncd75s8g7fzyn5kw3fh0000gp/T/pip-install-08w2dfti/pyyaml/

and
 error: command 'clang' failed with exit status 1
    ----------------------------------------
ERROR: Command errored out with exit status 1: /Users/ed/code/yahoo-groups-backup/bin/python3.7 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/private/var/folders/cc/krt30ncd75s8g7fzyn5kw3fh0000gp/T/pip-install-08w2dfti/pyyaml/setup.py'"'"'; __file__='"'"'/private/var/folders/cc/krt30ncd75s8g7fzyn5kw3fh0000gp/T/pip-install-08w2dfti/pyyaml/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /private/var/folders/cc/krt30ncd75s8g7fzyn5kw3fh0000gp/T/pip-record-mu4e0e61/install-record.txt --single-version-externally-managed --compile --install-headers /Users/ed/code/yahoo-groups-backup/bin/../include/site/python3.7/pyyaml Check the logs for full command output.

I wish I could help, but that's a bit too deep for me too -- I hardly even know Python, I'm just here to share what I've hacked out so far ;) When I've seen things like that before, it's usually been the result of some missing dependency or library version quirk. Building wheel for pyyaml looks like a good first string to pull.
Keep us posted if you find anything!


how to GET the BOXER OUTPUT (XML format) ??

@shashiongithub I have the corpora for PWKP complex sentences, also boxer v1.0 installed.
How do I get boxer output (XML format) of the complex sentences?
is there any guideline for the usage of Boxer CLI?

Did you try boxer --help? I think there is an option where you can set the output format.

hi @shashiongithub,
can you please show a sample boxer XML output for a single complex sentence.

boxer-output.xml.zip

Is Boxer v1.00 available for download? If yes, where can I get it from? Thanks!

@Crista23 were you able to get through Boxer v1.00 download?


Color mismatch on iPhone8

Hello,
I am using your library and I generate the snapshots using xcodebuild in 4 different devices at once (iPhone8, 8Plus, SE and X).
After generating the 4 snapshots for each test, when I run the tests in xcode, some of them are failing. The diff is clearly not helping:

Reference image:

I found this issue but it is not helping and I don't believe is the same problem.
I have used the Digital Color Meter on the diff image and there are definitely parts of the image where the color differs from one pixel to another. Also, there is a bit of ghosting at the bottom (where the big blue button is).
This problem only appears on iPhone 8. It has something to do with colors. I have generated the reference images and run the test on the same machine, same simulator.

The fact that you're seeing the colour differ suggests to me either a simulator issue or GPU. Can you reset your simulator and see if that makes a difference?
You can also set a breakpoint in the test, and see if the colours are different there. I would recommend using the visualize command using Chisel, which will let you do theButton visualize in LLDB (where theButton represents the pointer to the button instance).

Thank you @alanzeino
I have been working a bit more on this issue. Thank you for your suggestions.
There is a weird thing happening. As I said, I was launching the snapshot tests simultaneously in 4 devices using xcodebuild and specifying the different locations. Doing it this way, iPhone 8 (or 7) always fail.
However, if I only specify 1 location ("iPhone 8 simulator", for example), or if I generate the images directly from Xcode (in 1 device, obviously), the reference images are generated correctly and tests pass.
Any ideas?

@victorBaro I was inspired by the parallel testing info from WWDC 2018 and decide to try this too.
I have the same setup as you, where I'm passing multiple simulators to Xcode build and some of them are failing with "ghosting" issues the same as you.

@regnerjr glad to hear I am not alone :D
Out of curiosity.. how do you guys (in general) manage to create different snapshots (one per device "family" - normal, SE, Plus, X) if you are not using this method? Or you just create snapshots for 1 device in particular?

@victorBaro At the moment I am having same issue: snapshots using Xcode are fine, but using xcodebuild and executing them in paralel results in differences. Something strange is going on.
About your question, I did not do it yet, but in my build server I have 5 agents (5 different macs), so I think I will run one device per agent to avoid this issue and run the tests faster.

I confirmed that my tests in iPhone8 and iPhoneX with tolerance zero behave like:

When running individually form Xcode, they pass.
When running individually from command line (xcodebuild), they pass.
When running at the same time using command line (xcodebuild with multiple destinations) iPhone8 pass, but iPhoneX does not pass, saying that images differ.

@victorBaro from your tests in iPhone8, 8Plus, SE and X, can you confirm which devices fail when runnning in paralel? Can you confirm that running xcodebuild individually pass without problems?

@acecilia thank you for your comments.
My case si similar tou yours but the device always failing is the iPhone8 and not the iPhoneX (only when running in parallel).
I have a basic script that runs tests in 2 steps:

parallel iphoneX, SE and plus
xcodebuild iPhone8 only

If I run the 2 steps in the above order, it fails.
If I first run iPhone8, and then the rest in parallel, then everything works...

One thing I want to mention now that I've seen how you all are running your tests; running snapshot tests generated on one simulator device type on a different device type does not work and is not supported by the library. This also applies to the iOS version of the simulator — snapshots generated on iOS 10.3 with an iPhone 7 will likely fail when run on iOS 11.0 with an iPhone 7.
In the device type case, this is because different device types can have different colour profiles that are invisible to the end user. For example, the iPhone 8 uses LCD technology while the iPhone X uses OLED, so Apple applies different profiles to each device type.
In the iOS version case, this is because in general Apple tweaks stuff like line height and text aliasing in labels, kerning, etc.
The way to support this is to either;

Generate different snapshot files for each device type or iOS version. You can use the agnosticOptions bitmask to accomplish this.
Implement your own version of FBSnapshotVerifyView() that changes the view's frame for all the device types you want to test; 320x480 for iPhone 4/4s, 320x568 for iPhone 5/5s/5c, etc. This doesn't fully let you test the other device type (because you still run those snapshots on one simulator) but it does let you at least test how your view looks at different sizes.

If it helps I can add support for 2 to the library.

Implement your own version of FBSnapshotVerifyView() that changes the view's frame for all the device types you want to test; 320x480 for iPhone 4/4s, 320x568 for iPhone 5/5s/5c, etc. This doesn't fully let you test the other device type (because you still run those snapshots on one simulator) but it does let you at least test how your view looks at different sizes.

This is what we currently do in our project. In order to mock specific devices we use modified version of TraitController from Kickstarter. We also work on our own version of library where we would be able to mock all traits of device (not only screen size, but also size classes, layout margins etc.). We plan to open-source it, but I can't give any timeframe for that. Would be great to see those additions in ios-snapshot-test-case.

In the iOS version case, this is because in general Apple tweaks stuff like line height and text aliasing in labels, kerning, etc.

Exactly. When we internally switch to new Xcode version we need to rerecord almost all snapshot reference images. Even for smaller upgrades such us from Xcode 9.3 to Xcode 9.4. Also we try to stick to the same device across iOS/Xcode updates (in our case it's iPhone 8).

Thanks @alanzeino and @aleksandergrzyb, I did not know all those details. But seems this problem is not related with the iOS versions: I am running all the time iOS11.4.
I did further testing @victorBaro. To recall: I have my reference images taken using Xcode in each simulator (iPhone8 and iPhoneX), and zero tolerance. In addition to what I said:

I confirmed that my tests in iPhone8 and iPhoneX with tolerance zero behave like:

When running individually form Xcode, they pass.
When running individually from command line (xcodebuild), they pass.
When running at the same time using command line (xcodebuild with multiple destinations) iPhone8 pass, but iPhoneX does not pass, saying that images differ.

Seems like when running at the same time using command line (xcodebuild with multiple destinations), the order of the destinations also affects: sometimes iPhone8 fails, other times iPhoneX fails, and I could not guess a pattern.

Also, I realised that running the tests using xcodebuild individually, does not always succeed: at the moment running the tests like this fails for me:

xcodebuild \
  -workspace Project.xcworkspace \
  -scheme ProjectUITests \
  -destination 'platform=iOS Simulator,name=iPhone 8,OS=11.4' \
  -derivedDataPath './testOutput' \
  test

In addition, I open the iPhone8 simulator, and without closing it I run the tests, first using Xcode and then using xcodebuild. Running from Xcode succeeds, running from xcodebuild fails saying that images are different.

So, as a conclusion, looks like the only reliable way of running the simulators is from xcode :/

Still looking into the issue. In my case what I am using this library for is explained here. I am taking a screenshot of the simulator using app.screenshot().image and passing it to ios-snapshot-test-case.
It seems that the screenshot differs in the borders of assets and shadows. For example, here there is one of the icons I am using, and in the right are the differences between a reference image and a failed image (in black the different pixels):

A detail of the top border of the icon with the reference image on the left and the failed image in the right shows what is going on:

Hello @acecilia
You are a life saver. That was it. Sorry it took me a while to test this, but exactly as you said, the problem goes away by specifying a different build folder for each simulator.
I am closing this issue for now. It is not the best solution but I don’t think there is much that can be done besides that.
Thank you again!

For future reference, I've filled http://openradar.appspot.com/44658414 (please dupe!) and there are some other workarounds listed there.


[21.05] Firefox 92

Motivation for this change
Backport #137047
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

@ajs124 My NixOS machine is busy right now, so I haven't built this. Let's wait to see what ofborg says


docs: Update tags for go/set-namespace/v0.3.4

fix version drift

going to accept https://github.com/GoogleContainerTools/kpt-functions-catalog/pull/833/files which uses the right base to run make update-function-docs


[VS Code] Joining collaboration session: Unable to connect to Live Share cloud relay. Check your proxy, firewall and network settings and try again.

%0A%0A%23%23 Error:%0AJoining collaboration session: Unable to connect to Live Share cloud relay. Check your proxy, firewall and network settings and try again.%0A%0A%23%23 Steps to Reproduce:%0A1.%0A2.%0A%0A||Version Data|%0A|-:|:-|%0A|**extensionName**|VSLS|%0A|**extensionVersion**|1.0.337|%0A|**protocolVersion**|2.2|%0A|**applicationName**|VSCode|%0A|**applicationVersion**|1.34.0|%0A|**platformName**|MacOS|%0A|**platformVersion**|18.0.0|

Hi, @Lauri-olivia , thank you for reporting the issue. Would you give us some more information to investigate ? Does this consistently happen for you or happened once ? Also , your logs may provide us with helpful information. You can access them via the "Live Share: Export Logs" command from the command palette (ctrl + shift + p) and attach them to the issue. I am consolidating the issue with #2156 . Please attach your logs there and help us to investigate.


Bump version to 5.0.0

Questions
Answers

Description?
Bump version to 5.0.0

Type?
improvement

BC breaks?
no

Deprecations?
no

Fixed ticket?
N/A

How to test?
N/A

Thank you @Progi1984


Create HTTP resource with specific input and output formats

More information here https://github.com/pub-t/plain-destination/issues/11#issuecomment-227667642

Please add more meaningful title to this pull request, Supertest does not tell what you changes do to the project. Please read https://github.com/erlang/otp/wiki/Writing-good-commit-messages

Done, can we merge?

@Vanish404 we could merge and work on issues after merge, as a lot of work has been done already.

Please fix style issues and merge.

All fixed, i merge pr


Authenticate with anonymous tokens

Still an incomplete draft. This feature builds a store of anonymous tokens generated through a blind signature scheme. The tokens will be collected from Coil's API while logged in, and then submitted anonymously behind a proxy to authenticate Interledger traffic.
Most of the tricky logic is around managing these tokens. Each token is worth a standard and small amount of money, in order to prevent fingerprinting. But this also means we need to be able to swap tokens while on a single page and manage which have been consumed while keeping efficiency. We want to request enough tokens up front to throw off timing attacks, but not request so many that clearing your localstorage wipes out your usage for the month.

[ ] ideally, the code in the coil-extension part should be behind a feature flag or something so that this work can get merged before we're ready to roll it out. Otherwise we'll likely have to go through and refresh it with latest code changes when we actually want to use it.

[ ] At first startup, the extension should request a batch of tokens from the redeemer service. This should be worth about an hour of Coil usage. Each token could be usable for around a minute of Coil usage. The redeemer service defines the value of a token which can be referred to for this

[ ] Whenever a WM page is visited, the Streams service should grab an anonymous token + signature from its batch of anonymous tokens instead of fetching it via the normal Coil API. It submits the anonymous token + signature against the redeemer service to redeem it for a JWT. The JWT can be used to authenticate a BTP connection in the same way as a normal BTP token.

[ ] If the anonymous token is exhausted, the redeemer service will respond with an insufficient liquidity error with the message "exhausted capacity." https://github.com/coilhq/coil/pull/2802/files#diff-c31e4e873609785bd81a341808dafffbR333 The token which has been exhausted should be removed from the token store and a new anonymous token should be rotated in (redeemed for JWT, etc). This will require restarting the STREAM connection.

[ ] When the number of anonymous tokens is reduced below some threshold (10% could be a starting threshold), a new batch of anonymous tokens should be requested. The size of this batch requested should be the same as the initial batch to leak less information.

[ ] If the redeemer service rejects a request for an anonymous token due to exhausted usage, then we need to handle that case.

This could work by just ceasing monetization and showing a warning state. I don't think we'd want to roll that out, but it could at least let this feature get developed until we work out a better solution.
It could change into a state where monetization events are emitted with no actual micropayments occurring (and no monetizationprogress events emitted either). Basically a way of saying "I'm monetized but not paying right now," similar to the low throughput mode currently experienced when you use Coil too much. This lays the groundwork for a future state where micropayments can be accounted by provider instead of by individual session ID.
https://github.com/adrianhopebailie/open-payments/issues/19 In this future state a user who exhausted their usage could just show the site an attestation that they belong to their provider and access content off of the excess paid by other members of that provider. Not sure I would want to roll out this version either but it'd be a lot closer to the future state where we expect to roll this out.
Another option is to let the redeemer service offer two tiers of usage, one which represents ~1 min of usage at normal bandwidth and one that represents ~1min of usage at reduced bandwidth. It would be highly unlikely that we would run out of reduced bandwidth tokens

Update: got this to work issuing/redeeming tokens against our redeemer service that sits in front of https://github.com/privacypass/challenge-bypass-server . The code for issuing/redeeming on the client side is based off of https://github.com/privacypass/challenge-bypass-extension
Still todo:

[ ] clean up imported code (maybe break it out into a standalone module that can also be used for tests on the server side)
[ ] move some of the privacy-pass specific functions in index down into lib/privacypass
[ ] don't hard-code config options for privacy pass library
[ ] right now the commitment from the server is hard-coded off of the test commitment. We should code in real commitments or fetch them from our redeemer service dynamically
[ ] fix the tests so that they either don't run in CI or are able to run against a redeemer service instance
[ ] more comprehensive tests


Layer fixes

Progress will be tracked on #283

I suggest merging this so it has a chance of getting some wider testing.


[FEATURE REQUEST] Add profiles so that you can use different git syncs.

It would be cool if you could add profiles.
So that you can use git sync differently for private or business purposes, for example.

Right now, the best thing you could do is probably starting xpipe with different data directories with xpipe open -d <dir>. But yeah I will think about how to implement this properly

This is now implemented in the latest PTB at https://github.com/xpipe-io/xpipe-ptb if you're interested in trying it out early

This is now implemented in the latest PTB at https://github.com/xpipe-io/xpipe-ptb if you're interested in trying it out early

Thank you works fine 😄