bower.json: angular-ui-router package now just ui-router?

Short description of the problem:
bower.json included with ionic 1.2.4 contains a reference to the 'angular-ui-router' package, but it looks like this is now just called 'ui-router' (see https://github.com/angular-ui/ui-router )
What behavior are you expecting?
That a 'bower update' will work. Instead, I get:
bower angular-ui-router#0.2.13        ENOTFOUND Package angular-ui-router not found

Steps to reproduce:

bower update

Ionic Version: 1.2.4
Browser & Operating System: Mac OS X 10.10.5
Run ionic info from terminal/cmd prompt:
Your system information:

Cordova CLI: 6.0.0
Gulp version:  CLI version 3.9.1
Gulp local:   Local version 3.9.1
Ionic CLI Version: 1.7.14
Ionic App Lib Version: 0.7.0
ios-deploy version: 1.8.5
ios-sim version: 5.0.6
OS: Mac OS X El Capitan
Node Version: v4.3.1
Xcode version: Xcode 7.2.1 Build version 7C1002

Confirmed. See  #5647 and https://github.com/angular-ui/ui-router/issues/2592

bower install angular-ui-router is working again, #5647 should not be necessary anymore
https://github.com/angular-ui/ui-router/issues/2592

Yep, confirmed. Closing.

UI-Router guy here. I'm moving the bower package support to a separate repository.  The bower people deregistered the package this morning and asked that I re-register it.   However I didn't get to it soon enough and some random person re-registered it under their name.
Follow these issues:
https://github.com/bower/registry/issues/179#issuecomment-190194465
https://github.com/angular-ui/ui-router/issues/2592

OK, the ui-router bower move should be complete now.


Search in private organisations

Gitea version (or commit ref): 1.8.0
Git version: 2.17.1
Operating system: ubuntu 18.04
Database (use [x]):

[ ] PostgreSQL
[X] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[X] No
[ ] Not relevant

Log gist:

Description
Private organisation with private or public repos
search from
https://gitea.mysite.org/orgname  **not my real name - it's behinds a firewall anyway.
when logged in as a user who is a member of the Owners group...
fails to return any results
confirmation - on our test instance,
organisation == public. search functions as expected

organisation == private, search stops functioning as expected - see screen shots

organisation == limited behaves the same as public.
search from site admin portal works as expected.
https://gitea.mysite.org/admin/repos?q=test
however search and display of repos on the dashboard also limits the displayed repos when an organisation is private:
https://gitea.mysite.org/
org == private:

(note the two visible repos - one is owned but the logged in user who is admin, the other is public - and returns 500 error when clicked - not sure why - probably because that user is a member of the owners group - see next section)
org == public:

Next complication - this only appears to impact logged in users who are members of the Owner group.
logged in users who are team members of a team for the org are able to search as expected.
...
Screenshots

I think this could be already fixed in 1.8.1

Yeah it sounds a lot like the dual bug @mrsdizzie, myself and you fixed.

Please reopen if problem persists in latest version

Not fixed in 1.8.1 - issue still exists - how do I reopen it?

Yes these fixes are on the release/v1.8 branch and the master branch. Try either of those.

Please try with https://dl.gitea.io/gitea/1.8/ binary to check if it works. If not feel free to reopen


Using valid or allow on Joi.number() does not produce a number typed field

When generating a schema with a Joi.number() that has valid() or allow() the resulting type is not a number but assumed the valid values as the types of the field.
To Reproduce
export const TestSchema = Joi.object({
  'clean': Joi.number(),
  'valid': Joi.number().valid(0, 1),
  'allow': Joi.number().allow(2, 3)
}).label('Test');

Expected behavior
export interface Test {
  allow?: number;
  clean?: number;
  valid?: number;
}

Actual behavior
export interface Test {
  allow?: 2 | 3;
  clean?: number;
  valid?: 0 | 1;
}

This is actually the designed behavior, as per your joi only 2 numbers can be assigned to these properties

This is actually the designed behavior, as per your joi only 2 numbers can be assigned to these properties


Casing

Right now all keys in the API are using kebab case ("word-word-word").
I think life for all implementers of the API (including me) would be much easier if if the keys were in snake case ("word_word_word").
The general reasoning for this is that automatic Json serialization/deserialization is FAR easier when you don't have to do case transformation, especially when a language's (hi, Python!) ecosystem is rather ill-suited for it. For some languages, camelCase is easier to handle (Java, C#) but those languages also have mature enough ecosystems around this that they can manage case transformation as needed through libraries that one can rely on sufficiently.
The big problem with kebab case is that there is virtually no language (that I've used anyway) which will accept it for auto-deserialization since object fields can't have hyphens in their names. So it's really between snake_case and camelCase, and I think with our known target languages and their capabilities, snake_case will give us by far the widest level and greatest ease of adoption.
Thoughts on this? I'll propose this on the IETF draft as well if you agree, and otherwise we can discuss further.
(I'd started refactoring validation by thinking "how much more elegant would it be if I could just deserialize into a domain object, then I don't have to have any magic strings anywhere in the request processing part of the code" and immediately ran into Python's struggle with kebab-case and the need to roll my own recursive case transformation function as a workaround, which kills a lot of the elegance. Also it makes it really painful to then serialize back into kebab case.)

ACME seems to use camel case. I don't have strong opinions here, so we can move the IETF draft to snake if you like.

I am fine with snake case particularly if there is auto deserialization happening. I agree that there is essentially no language with builtin support for kebab case. I had used kebab case as this is recommended practice for the naming of REST API endpoints ( see https://www.theserverside.com/video/Top-REST-API-URL-naming-convention-standards ).

@birgelee yep that's 100% the right practice for API URL paths. And those we'll keep kebab case. It'll just be the payload included with the request (and the body of the response) that will be in snake case.

sounds good. I would also be fine with the RFC drafts we are generating using this convention.

Here's a sample request (CAA check) and response you get if you run the integration test as of right now (Aug 27) in the ds-validation-logic branch. It's fairly verbose, as I went with my usual habit of descriptive (long) names. Elements in this output are unordered btw.
Request:
{
   "orchestration_parameters": {
       "perspective_count": 3,
       "quorum_count": 2,
       "domain_or_ip_target": "example.com",
       "max_attempts": null,
       "perspectives": null
   },
   "caa_check_parameters": {
       "certificate_type": "tls-server",
       "caa_domains": [
           "mozilla.com"
       ]
   }
}

Response:
{
   "request_orchestration_parameters": {
       "perspective_count": 3,
       "quorum_count": 2,
       "domain_or_ip_target": "example.com",
       "max_attempts": null,
       "perspectives": null
   },
   "actual_orchestration_parameters": {
       "perspective_count": 3,
       "quorum_count": 2,
       "attempt_count": 1
   },
   "is_valid": true,
   "check_type": "caa",
   "perspectives": [
       {
           "perspective": "us-east-2",
           "check_passed": true,
           "errors": null,
           "timestamp_ns":<PHONE_NUMBER>509479740,
           "check_type": "caa",
           "details": {
               "caa_record_present": false,
               "found_at": null,
               "response": null
           }
       },
       {
           "perspective": "eu-west-2",
           "check_passed": true,
           "errors": null,
           "timestamp_ns":<PHONE_NUMBER>778548673,
           "check_type": "caa",
           "details": {
               "caa_record_present": false,
               "found_at": null,
               "response": null
           }
       },
       {
           "perspective": "ap-northeast-2",
           "check_passed": true,
           "errors": null,
           "timestamp_ns":<PHONE_NUMBER>927818565,
           "check_type": "caa",
           "details": {
               "caa_record_present": false,
               "found_at": null,
               "response": null
           }
       }
   ],
   "caa_parameters": {
       "certificate_type": "tls-server",
       "caa_domains": [
           "mozilla.com"
       ]
   }
}

I generally like the new naming and schema. It is much more verbose, but I feel it has a lot of clarity. I also think this is optimal from a compliance perspective, so I am OK going ahead with it.

I'm also thinking of moving domain_or_ip_target and the upcoming check_type to top-level parameters, outside of orchestration_parameters (that's just the new name for system-params).

sounds good, will this make orchestration_parameters optional?

Yes looks like it will!
And we might still need to brainstorm about how to best accommodate the "diagnostics-only" params like perspectives.
I actually have a TODO in the code about it, like does it just override the perspective_count since that's pretty much its purpose, so then the older logic of "can't specify both perspectives and perspective count" can be eliminated, etc.

closing since latest version uses snake_case


People name recognition problem

It seems that there's a problem with people() method regarding names. The test below using Ava and compromise 11.2.1 fails at detecting Mary name, but changing it to Monica it passes.
import test from 'ava';
const nlp = require('compromise')

test('American names can be found in a phrase', async t => {
    const phrase = nlp('Mary and John has been a couple since high school')

    const names = phrase.people().out('array')
    const [mary, john] = names

    t.is(2, names.length) // Error: names.length should be 1
    t.is(mary, 'mary')
    t.is(john, 'john')
})

Am I missing some rule about name detection?

hey lucas, naw you haven't missed anything. 'mary' is just an ambiguous name, because it's sometimes a verb.
you can co-erce words to specific interpretations using the plugin stuff. It's (intented to be) pretty-easy.
doc=nlp('Mary and John has been a couple since high school', {mary:'Person'})
doc.people().debug()
// mary #Person
// john #Person

cheers!

Thank you for the clarification, @spencermountain. Adding {mary: 'Person'} as you mentioned makes the test pass :)


Build failure on Ubuntu 20.04 and Foxy when running "colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release"

Bug report
Getting the following error while building the RMF source using "colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release"
--- stderr: nlohmann_json_schema_validator_vendor
In file included from /home/admin/rmf_foxy_ws/build/nlohmann_json_schema_validator_vendor/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6-prefix/src/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6/src/json-validator.cpp:9:
/home/admin/rmf_foxy_ws/build/nlohmann_json_schema_validator_vendor/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6-prefix/src/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6/src/nlohmann/json-schema.hpp:28:4: error: #error "Please use this library with NLohmann's JSON version 3.8.0 or higher"
28 | #  error "Please use this library with NLohmann's JSON version 3.8.0 or higher"
|    ^~~~~
Required information:

Operating system and version:

Ubuntu 20.04

OpenRMF installation type:
-21.09 for Foxy - https://github.com/open-rmf/rmf
OpenRMF version or commit hash

21.09

ROS distribution and version:

ROS2 Foxy

ROS installation type:

https://docs.ros.org/en/foxy/Installation/Ubuntu-Install-Debians.html

Package or library, if applicable:

Package

Description of the bug
--- stderr: nlohmann_json_schema_validator_vendor
In file included from /home/admin/rmf_foxy_ws/build/nlohmann_json_schema_validator_vendor/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6-prefix/src/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6/src/json-validator.cpp:9:
/home/admin/rmf_foxy_ws/build/nlohmann_json_schema_validator_vendor/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6-prefix/src/nlohmann_json_schema_validator-1063c9adbafc25f5a14bae15c3babdb039de86c6/src/nlohmann/json-schema.hpp:28:4: error: #error "Please use this library with NLohmann's JSON version 3.8.0 or higher"
28 | #  error "Please use this library with NLohmann's JSON version 3.8.0 or higher"
|    ^~~~~
Steps to reproduce the bug
<!-- Detailed instructions on how to reliably reproduce the bug, e.g.
Follow the RMF installation in readme. https://github.com/open-rmf/rmf/tree/release/21.09

### Expected behavior
Build should be successful

### Actual behavior
Build fails.

We haven't been actively maintaining support for source builds on Ubuntu 20.04 + Foxy. But other users have reported a similar issue and work around here. But I think the issue was encountered with the latest main and not the 21.09 tagged version as you have documented in your description.

I faced the same issue in Galactic as well. And yes, I used the main branch. I mentioned 21.09 since the readme file said Install instructions of 21.09. Could you please explain what's the fix?

I followed the installed instructions from here https://github.com/open-rmf/rmf/tree/release/21.09
Is this main branch?

i had faced similar issue when installing rmf on galactic version. From the error printed above it reports nlohmann's json library needs to be of version 3.8.0 and higher.

First use apt list | grep "nlohmann" and check what version of binary is already installed in the PC
If it is lower than 3.8.0 remove the old package
Clone the latest version of json library from github (git clone git@github.com:nlohmann/json.git)
Installing the json library from source
cd json_pkg_name
mkdir build
cd build
cmake ..
make
sudo make install
Try colcon build again

See if this helps !!!!!

See https://github.com/open-rmf/rmf/issues/322 for galactic build issues


create linode from image

Closes #2398

Coverage increased (+0.08%) to 68.479% when pulling 33fa35533a2f14b4f3fd579f85f2907c51f75b1b on na3d:linode-from-image into dd5f89aab4893509c6770771611cdd2c971c2051 on linode:develop.


Should the helperText have a value by default?

Environment

Tech
Version

@material-ui/pickers
v4.0.0-alpha.6

Steps to reproduce
function App() {
  const [value, setValue] = React.useState(null);

  return (
    <LocalizationProvider dateAdapter={DateFnsUtils}>
      <DatePicker
        value={value}
        onChange={newValue => {
          setValue(newValue);
        }}
        renderInput={props => <TextField {...props} />}
      />
    </LocalizationProvider>
  );
}

https://codesandbox.io/s/condescending-hoover-m5jk7?file=/index.js:234-580
Expected behavior
Should the helperText have a value by default? It feels strange. I think that we should remove it to:

reduce duplication of information: placeholder + input mask should be good enough.
reduce the height of the input takes by default. It might not fit into people's layout.
encourage the usage of the helper text for related information regarding the field.

Actual behavior

The feature itself is pretty nice and adds really good UX for input. Because when you type 01 you don’t have any information about the format you need to type.
And in order to achieve it we need to make another prop ‘enableAutoHelperText’ for example. Because this prop is auto generated on the library side.
It is much easier to override and disable this prop than include it. And it provides much better UX

@dmtrKovalenko Ok thanks for sharing the incentive. What do you think of we wait for the adoption of the next version to see more feedback?

Agree, let's wait for the reactions.
One more thing I want to mention. That for most of the cases (when label is used) there is no duplication. Here is the most used UX:

And it is possible to extend or override helperText like
renderInput={props =>
  <TextField {...props} helperText={`date format: ${props.helperText}`} />
}

Yes, let’s wait for reactions.
One more thing I

I do agree with:

The feature itself is pretty nice and adds really good UX for input. Because when you type 01 you don’t have any information about the format you need to type.
...
Conclusion: It is much easier to override and disable this prop than include it. And it provides much better UX

It is an opinion though.
Anyway, in my use case, I did "helperText={null}". Not because I don't like the helperText, it doesn't fit in my layout (it should be in one line, and the line get's like +12px on height with the helperText).

It is much easier to override and disable this prop than include it.

@dmtrKovalenko What's harder between?
renderInput={props =>
  <TextField {...props} helperText={null} />
}

and
renderInput={props =>
  <TextField {...props} helperText={props.placeholder} />
}

@oliviertassinari
I support keeping the helpertext (having a value by default) in: it's better to notice it being there and disable it - than forgetting about it and possibly have a worse UI/UX. The question is, how opinionated do you want to have it.

+1 for at least having an option to disable the helpertext completely

I'm experimenting with 4.0.0-alpha.7 and it's very good. I understand the purpose on showing the format by default, but my users are all on the same locale and we have a pretty strong date format default. So the helperText with the format is undesirable. +1 for at least having an option to disable.

There is an option. Pass helperText={null}

Closing as it doesn't seem to get traction.

helperText={null} seems very awkward to me, where you can always pass it intentionally to the <TextField /> when it's needed
I personally think it's unnecessary default behavior

Agree, looking at the date pickers in the wild such helper text seems to be the exception, I think that it will be better to remove it.

Hardly disagree, what the problem to keep this feature?  I am not seeing any.
Trying to be the same as other datepickers – will kill the project. We must be the best.

Trying to be the same as other datepickers

To be more precise, I was making a reference to the usage of the date picker in developer's applications & website. I think that it's the dimension we should optimize againt: what are our users' UI/UX designers asking for the most often.

What if they all are not right? This is the case as for me. Because helper text is the best way to contain information that helps input the right date.
Personally I have a lot of cases when I am starting typing date and after typing the first part realize that I don't understand right format. So I need to delete text and check the placeholder again. Or endup with 31.12.2019 when it was required to type 12.31.2019.

I think that it's a tradeoff between display density, and ease of filling the field. One could argue that a placeholder, a pop-up, and using the locale format is more than enough. Let's wait a couple more months before leaning on a specific direction. I think that we can keep paying attention to the date pickers present in the wild :).

Let's aim for high density, which will better answer our market.

+1 helperText should be optional. There should be a way to hide it. It's looking odd in my use-case.

@oliviertassinari I tent to agree that it should not be included by default if so many users cannot find a way to hide it.
My original thought that it will be much clear how to disable it.


frontmatter not found

Hey!
Do you have some code to share? Ideally a link to the repo where the issue is happening, with steps to reproduce.

Hey!
Do you have some code to share? Ideally a link to the repo where the issue is happening, with steps to reproduce.
@simonswiss

it was working fine before But when I recently tried to Explore data, this error pops out. I haven't changed any code as it was working fine earlier
REPO - https://github.com/ArnavK-09/AvatarArchives

I cannot log in your Keystatic Cloud account, but I changed the storage to local and I can see the content just fine:

Are you able to see the same page if you change the storage to local?
Looks like the frontmatter for that post is present on GitHub too, so that should work. Which is why I want to check if the problem is isolated to Cloud mode.
Also, try install the latest versions of Keystatic core and astro and see if it helps.

I cannot log in your Keystatic Cloud account, but I changed the storage to local and I can see the content just fine:

Are you able to see the same page if you change the storage to local?
Looks like the frontmatter for that post is present on GitHub too, so that should work. Which is why I want to check if the problem is isolated to Cloud mode.
Also, try install the latest versions of Keystatic core and astro and see if it helps.

it shows no data on storage local

Ps - it shows this error on all avatars

Any fixes?

This is likely caused by there being an error fetching the files for that entry, #920 adds a more specific error in that case. Could you try<EMAIL_ADDRESS>and see if the error changes?

✨ Thanks to both of you it is fine now


Add Audiovisual

Duplicate of #1775.
[https://github.com/stingalleman/awesome-audiovisual]
[This list is a combination of software, libraries and resources for audio, video and lighting professionals and hobbyists.]
By submitting this pull request I confirm I've read and complied with the below requirements 🖖

I reviewed #1769 & #1758

Duplicate of #1775.

Just FYI, GitHub gave a warning when making this PR: "Note: Creating a PR from the default branch is an anti-pattern."

GNU/Linux, , Windows

Please go through each descriptions and  try to improve them.

DMX controller library for Node.js

Missing a dot at the end.

I updated the descriptions.

@sindresorhus

This is a new requirement, so I didn't knew this requirement existed.
While I personally disagree with this change, I have renamed the default branch in order to comply with the requirements.

Tweet: https://twitter.com/awesome__re/status/1276969260103823361


Flutter has exited unexpectedly after upgraded in ubuntu 18

flutter_04.log

Steps to Reproduce

...
...
...

Logs

Closing as dup of #21418


ncurses: Break hash to simplify derivation

This is just one commit different from master. Should I merge master into staging first and then open this PR?

Should I merge master into staging first and then open this PR?

I think that's a good idea.

@bjornfor Ok it's been merged by others in the meantime, so just rebased this to get github to recompute the diff.

Note checks failed cause I stopped because no point wasting our Travis resources on a mass rebuild.


Add --build-plan for 'cargo build'

With 'cargo build --build-plan', cargo does not actually run any
commands, but instead prints out what it would have done in the form of
Python data structures. The 'dependencies' structure lists the
dependencies between steps, and the 'commands' structure lists the
information required to run the commands from an external build system.
Fixes #3815

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matklad (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

r? @alexcrichton

Discussed offline with @mshal:

We'll want to build an in-memory data structure here and then use serde to emit JSON and/or TOML
Somehow we'll want to include input files to rustc, whether that'd depending on the dep-info file or generating dep-info at compile time is fine either way.
We'll want to include environment variables into the output (tracked by ProcessBuilder)
We'll block this on https://github.com/rust-lang/cargo/issues/4409 which will hopefully get resolved in the near future, and should allow for much faster iteration in-tree on this feature

Ok we've landed https://github.com/rust-lang/cargo/pull/4433 now which implements unstable features in Cargo, and the source should have documentation about how to add an unstable command line flag.

:umbrella: The latest upstream changes (presumably #4531) made this pull request unmergeable. Please resolve the merge conflicts.

I'm going to close this due to inactivity, but it's of course ok to resubmit with updates!


Updated python script to output csv & documented discussion from issue#3

As per the discussion in Issue #3,
I have updated the human_readable_data.py script to output the touch data to a csv file.
I have changed the script to have the touchscreen device passed into the script as find_touchscreen_name.sh did not function correctly on my machine and this allowed me to specify which input I wanted to monitor.
All documentation for the file is included in the readme under a new section called "Outputting Touch Data".

Hello! Sorry for the late reply, I have been moving to another country (:
Quick suggestion, instead of opening the file every single time in the loop we should just open it once, run the loop and write the data to the .csv file and close that file after the loop.
What do you think?

I can commit my suggestions if you turn on the allow edits from maintainers.

Hey,
No worries. Yes see I wince every time I look at the code, you are right you definitely shouldn't be opening and closing the connection to the file every time you iterate through the data set. Annoyingly I can remember it not writing to the csv if I opened it at the start of the script and closed it at the end...
You are clearly much more knowledgeable about python than me, I wonder if you took at look you might have more success!

You should have access to edit

Unfortunately, I do not have a USB cable with me (I just moved to London).
I will merge this version and later on I will commit those changes.
Thank you!

Hi, I tried your code and it end up like this
Traceback (most recent call last):
File "C:\adb\human_readable_data.py", line 26, in
time, event_data = output.decode('utf8').split(" ]", 1)
ValueError: need more than 1 value to unpack
any solution ?
thank you


Compose Preview Plugin won't install on AS Bumblebee

Tried to install from AS Bumblebee C2.
Installed fine in arctic fox

Seems to work fine on Bumblebee, please reopen if still relevant.

Still won't install for me?

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Pem

[Enter feedback here]

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

ID: 6148535d-c60a-fa0b-50ae-42ae1af1b710
Version Independent ID: 22db460f-f08f-c919-516c-53da75a192a0
Content: External authentication from ACR task - Azure Container Registry
Content Source: articles/container-registry/container-registry-tasks-authentication-key-vault.md
Service: container-registry
GitHub Login: @dlepow
Microsoft Alias: danlep

Let us know if you are seeeing any issue. Thanks.


use More Linked Issues action

Requirements

Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
All new code requires tests to ensure against regressions.

Description of the Change
closes #4479 by adding the action as suggested

Alternate Designs
None, boneskull made the tool just for this purpose, so I'd assume they want this to be used

Why should this be in core?
It's not really in core, it's a GH action.

Benefits

searches PR titles and commit messages and adds the linked issues to the PR description (copied from issue description)

Possible Drawbacks

falsely adding some issues that were referenced for just conversation

Applicable issues
Does not impact production code

@u9g thanks for this PR.
Tbh I don't see the benefit of this GH action. There is the "Linked issues"  feature on the left side of any PR. I'm not sure, but wasn't this feature added by GH a few months ago?
Furthermore this action will fail, when triggered by a PR from a forked repo, since its pull-request event doesn't have write access to this repo.

@u9g thanks for this PR.
Tbh I don't see the benefit of this GH action. There is the "Linked issues"  feature on the left side of any PR. I'm not sure, but wasn't this feature added by GH a few months ago?
Furthermore this action will fail, when triggered by a PR from a forked repo, since its pull-request event doesn't have write access to this repo.

Thought I'd try since it was added as a contribution-wanted issue, no problem.

Coverage remained the same at 94.369% when pulling d7e57e9e027a6e293a6a7f02d3ce0096756d786d on u9g:patch-1 into dcad90ad6e79864c871e2bc55b22c79ac6952991 on mochajs:master.


Selecting an empty category from the categories list displays network error

Checklist

[x] Bug Report - The issue you are reporting might be there already. Please search on the issues tracker before creating or reporting an issue.
[x] Before reporting, please ensure (if you can) that you have tested it with the latest (dev) version of the software.
[x] Don't forget to tag your issue, it makes it easier to discover.

Summary:
Clicking a category from the categories list displays network error when the category you clicked is empty (no products in OFF falls under that category).
Example of an empty category.
Steps to reproduce:

Change the app's language to French.
Try clicking Acésulfame potassium in the categories list.

Expected behavior:
I would expect something like: “Oh no, we don’t have any product in this category, can you add one ?”
Observed behavior:
No internet connection error is shown.
Reported By:
@teolemon

Looks good to me.


Pico v0.9 and beyond....

I have recently started collaborating on Pico, and an issue was raised regarding the closing of stale threads and pull requests. In the interest of cleaning up, I have quickly reviewed all issues and closed any that I thought were irrelevant, resolved or abandoned. Likewise, I have merged many pull requests and begun labelling issues for discussion and better organization.
If you think a thread was erroneously closed, please let me know. I will gladly reopen any issue or pull request anyone raises issue with. Going forward, Issues & PR's will ideally be labelled with a type:, status:, and priority:.
I hope this refresh of the Pico repo will stimulate new dialog and contributions. Please feel free to discuss your thoughts below.
Thanks, everyone! :)  :+1:
Note: If anyone is interested, during Pico's decline it branched out as BaunCMS and PhilleCMS as well.. See #199, #208

Respectfully, .9 needs to be fixed before this project goes forward. If "Pico is a stupidly simple, blazing fast, flat file CMS" then I don't see why the functionality of .8 was scrapped for a command line install as a pre-requisite for making Pico work.
The dead-simple drag and drop and it works is what attracted me and my friends to Pico, v.9 absolutely should be even simpler to install and use.

It was suggested in the issues that I linked you to earlier that; Pico be split in to two branches. One for development (no vendor) and one for production (complied). As this project was dead in the water before I arrived, I am willing to entertain this. Would you like to make the desired changes and submit a pull request for feedback?

Honestly, I do not have the skills to make the desired changes. Your efforts are much appreciated, especially from people like me who are more design than PHP expert. My suggestion would be to go back to the original ethos of Pico "stupidly simple, blazing fast, flat file CMS" and keep-on with a singular production branch that might error on the side of messy but "stupidly simple" and "blazing fast."
If it is poor practice to have a /vendor folder, it should be weighed against the simplicity of install, especially for laypersons, since it would mean greater overall usage vs. organizational efficiency.  I think the growth and simplicity of Pico is credit to it's dead simple install and we must continue the cause.

Perhaps a composer auto-installer script could be crafted for those without SSH access.
@johnnywon you may also want to consider using BaunCMS https://github.com/BaunCMS/Baun

I would recommend keeping it simple with the original ethos "stupidly simple" and "blazing fast."
Anything that requires an auto-installer script, or SSH access, or any dependency greater than PHP is unnecessary friction.

I'm going to add my little plug to emphasize the value of "stupidly simple & blazingly fast". Someone will have to determine what that is (its obviously different for different people) but I'll add my little voice. :-)
I use Drupal for my client sites, but I've been on a quest to find something more simple and lightweight for smaller websites. What I see on the home page at picocms.org sounds perfect. And it would seem to me that Pico has a lot going in that direction and would find a lot of users with that interest.
But...command line / Composer installation? No way. Gotta be simple. Upload and go. Fantastic.
I'm going to take it a little farther and suggest that the admin interface be integrated though in the basic download - or offer a download with admin and one without. For me, all client websites need an admin interface. With WYSIWYG. Simple WYSIWYG tho...really simple. Only a few options. No image placing, tables, etc. Just the minimum text formatting basically. Keep the dev stuff in the files, that's fine. But clients should be able to edit and create pages in a simple interface.
Anyhow...that's from my perspective. :-)

@rosewoodmarketing :
The auto-installer can be a plugin, to keep the core of pico as stupid that it say's ;-)
I use a modified version of pico, but the goal is to install it locally first and publish and maintain your website(s) after. Once you have install an instance of Pico locally, you can clone it for your customers…
For the other considerations, there is some plugins to do those jobs (live editing, wysiwyg, file management). I think the core of Pico must stay "simple", but the segmentation of the Baun core is interesting in  some points, actually Pico is just one class, and it's (or will) become to be a problem/limit.
Just for example, i 've to use Markdown Extra on some projects and Parsedown by default … a formatter class that can be extended could be a good point, a plugin class with a plugin description file could be another ;-) .

Eric & Mistergraphx I think have nailed it. The mantra of "stupidly simple
& blazingly fast" should guide our decisions rather than introduce friction
like an installer script or create unnecessary complexity for the sake of
"being proper."
On Wed, Jun 3, 2015 at 5:30 PM mistergraphx<EMAIL_ADDRESS>wrote:

@rosewoodmarketing https://github.com/rosewoodmarketing :
The auto-installer can be a plugin, to keep the core of pico as stupid
that it say's ;-)
I use a modified version of pico, but the goal is to install it locally
first and publish and maintain your website(s) after. Once you have install
an instance of Pico locally, you can clone it for your customers…
For the other considerations, there is some plugins to do those jobs (live
editing, wysiwyg, file management). I think the core of Pico must stay
"simple", but the segmentation of the Baun core is interesting in some
points, actually Pico is just one class, and it's (or will) become to be a
problem/limit.
Just for example, i 've to use Markdown Extra on some projects and
Parsedown by default … a formatter class that can be extended could be a
good point, a plugin class with a plugin description file could be another
;-) .
—
Reply to this email directly or view it on GitHub
https://github.com/picocms/Pico/issues/221#issuecomment-108621547.

Agreed with what's been echoed above. .9 is no longer "stupidly simple" to install. I'll stick with .8 (which I use and love).

This is why feedback is so important in developing!
Although I agree with @mistergraphx , Pico should be installed locally then pushed to your server, hence composer wouldn't be a problem for those without SSH. However, I do see how this can be problematic for those less technically inclined, and I would entertain putting the compiled vendor folder back in the repo to have that 'upload-and-go' feel.
With all that said, it is messy to keep the vendor folder, so I think it would be best to split this project in to two branches, one without composer for developing, and one with for distribution. Agree/Disagree?
In response to @rosewoodmarketing, I do not think including the admin panel, etc. is keeping with the "stupidly simple" manta everyone is so keen on. Pico should be a solid core and extensible though the library of plugins that have been developed for the class. Like you said, not everyone is using Pico in the same way. If you need a WYSIWYG editor, there is already a couple plugins for that.
I hope this has given anyone interested in developing for Pico a place to start. Pull-requests should not pile up any longer, so feel free to submit some for consideration.

I agree that if there was a version I could basically drag/drop to a server, I'd be game and very appreciative.

@theshka, the value of the admin panel in the normal Pico download I think would very much be a benefit in keeping with the "stupidly simple" operation many of us are looking for. I don't mind editing files, but I have very few clients who I'd even try to explain how to edit website files. A simple admin panel is much more of a common interface even basic computer users are used to using.
Like @johnnywon said, if a CMS requires the command line to install (or add plugins), then I'm out. Maybe some day I'll be geek enough to use it. :-)

I found this article sums up the FFCMS landscape pretty well: https://www.ostraining.com/blog/general/2014-static-websites/ , one of the major drawbacks is that these systems is that These are great platforms, but only for a niche audience of developers and designers. Perhaps this isn't the project for you to try and have your clients navigate?
I don't think Pico will ever be the next Wordpress, as @mistergraphx said "Pico is just one class, and it's (or will) become to be a problem/limit."

I don't use for client sites, but for my own (which gets ~50k uniques/month) it's perfect. I write in markdown any way, and when I see traffic surges, I dig that there's no DB to bog down load time. Still though, simple as possible without being any simpler... I'm down for that.

The "compiled" version get my vote. We could pack with it a composer installation along with autorun install scripts (like first request no autoload.php => create it, and after autodiscover added plugins), and keep the git installation for those who like to play with the shell (like myself).

Who owns picocms.org ? @theshka ? Consider migrating this to github.io ?

As said by @PhrozenByte,

How to fix the "composer problem" discussed in #221 and #223? There's a very simple solution: When creating a release on GitHub (after you've pushed the tag) you can upload "binaries". Simply execute composer locally, create a ZIP archive and upload the result as "binary".

It would be nice to add a travis on this one.

@all ...  closing this issue, any further discussion please see #252


Performance Issue on openSUSE Tumbleweed

Issue Type: Performance Issue
After the update to 1.53. VS Code became unusuable. Everything slows down to a halt.
CPU is not at 100%, though.
Downgrading to 1.52 and everything works fine again.
VS Code version: Code 1.53.0 (8490d3dde47c57ba65ec40dd192d014fd2113496, 2021-02-03T15:56:04.185Z)
OS version: Linux x64 5.10.12-1-default

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4712MQ CPU @ 2.30GHz (8 x 3109)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onprotected_video_decode: unavailable_offrasterization: disabled_softwareskia_renderer: enabled_onvideo_decode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
1, 1, 1

Memory (System)
15.54GB (5.82GB free)

Process Argv
--no-sandbox

Screen Reader
no

VM
0%

DESKTOP_SESSION
gnome-xorg

XDG_CURRENT_DESKTOP
GNOME

XDG_SESSION_DESKTOP
gnome-xorg

XDG_SESSION_TYPE
x11

Process Info
CPU %	Mem MB	   PID	Process
    0	   127	 25619	code main
    0	    32	 25624	   zygote
    0	    64	 25655	     gpu-process
    0	    32	 25625	   zygote
    0	    80	 25772	     window (Issue Reporter)
    0	    48	 25669	   utility
    0	   239	 25680	   window (Untitled-1 - Visual Studio Code)
    0	   143	 25703	     extensionHost
    0	    48	 25761	       /usr/share/code/code /usr/share/code/resources/app/extensions/json-language-features/server/dist/node/jsonServerMain --node-ipc --clientProcessId=25703
    0	   127	 25735	   shared-process
    0	     0	 25789	     /usr/bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=

Workspace Info
;

Extensions (24)

Extension
Author (truncated)
Version

output-colorizer
IBM
0.1.2

spellright
ban
3.0.56

vscode-markdownlint
Dav
0.38.0

markmap-vscode
ger
0.0.6

go
gol
0.22.0

marp-vscode
mar
0.17.1

rainbow-csv
mec
1.8.1

HTMLHint
mka
0.10.0

vscode-language-pack-de
MS-
1.53.2

python
ms-
2021.1.502429796

jupyter
ms-
2020.12.414227025

azure-account
ms-
0.9.5

cpptools
ms-
1.2.0

color-highlight
nau
2.3.0

printcode
nob
3.0.0

favorites
ole
1.5.1

material-icon-theme
PKi
4.5.0

platformio-ide
pla
2.2.1

preview-vscode
sea
2.2.5

stylelint
shi
0.51.0

write-good-linter
tra
0.1.4

debug
web
0.25.0

markdown-pdf
yza
1.4.4

markdown-all-in-one
yzh
3.4.0

(1 theme extensions excluded)

I can reproduce the situation with all extensions disabled (code --disable-extensions). So I doubt an extension is to blame.

Here is what code --status says:
`
Issue Type: Performance Issue
After the update to 1.53. VS Code became unusuable. Everything slows down to a halt.
CPU is not at 100%, though.
Downgrading to 1.52 and everything works fine again.
VS Code version: Code 1.53.0 (8490d3dde47c57ba65ec40dd192d014fd2113496, 2021-02-03T15:56:04.185Z)
OS version: Linux x64 5.10.12-1-default

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4712MQ CPU @ 2.30GHz (8 x 3109)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onprotected_video_decode: unavailable_offrasterization: disabled_softwareskia_renderer: enabled_onvideo_decode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
1, 1, 1

Memory (System)
15.54GB (5.82GB free)

Process Argv
--no-sandbox

Screen Reader
no

VM
0%

DESKTOP_SESSION
gnome-xorg

XDG_CURRENT_DESKTOP
GNOME

XDG_SESSION_DESKTOP
gnome-xorg

XDG_SESSION_TYPE
x11

Process Info
CPU %	Mem MB	   PID	Process
    0	   127	 25619	code main
    0	    32	 25624	   zygote
    0	    64	 25655	     gpu-process
    0	    32	 25625	   zygote
    0	    80	 25772	     window (Issue Reporter)
    0	    48	 25669	   utility
    0	   239	 25680	   window (Untitled-1 - Visual Studio Code)
    0	   143	 25703	     extensionHost
    0	    48	 25761	       /usr/share/code/code /usr/share/code/resources/app/extensions/json-language-features/server/dist/node/jsonServerMain --node-ipc --clientProcessId=25703
    0	   127	 25735	   shared-process
    0	     0	 25789	     /usr/bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=

Workspace Info
;

Extensions (24)

Extension
Author (truncated)
Version

output-colorizer
IBM
0.1.2

spellright
ban
3.0.56

vscode-markdownlint
Dav
0.38.0

markmap-vscode
ger
0.0.6

go
gol
0.22.0

marp-vscode
mar
0.17.1

rainbow-csv
mec
1.8.1

HTMLHint
mka
0.10.0

vscode-language-pack-de
MS-
1.53.2

python
ms-
2021.1.502429796

jupyter
ms-
2020.12.414227025

azure-account
ms-
0.9.5

cpptools
ms-
1.2.0

color-highlight
nau
2.3.0

printcode
nob
3.0.0

favorites
ole
1.5.1

material-icon-theme
PKi
4.5.0

platformio-ide
pla
2.2.1

preview-vscode
sea
2.2.5

stylelint
shi
0.51.0

write-good-linter
tra
0.1.4

debug
web
0.25.0

markdown-pdf
yza
1.4.4

markdown-all-in-one
yzh
3.4.0

(1 theme extensions excluded)

`

The last few times I tried 1.53 no process went to 100%. The system itself runs perfectly. It's just that Code can't be used anymore a few seconds after starting it. Switching tabs takes ages, scrolling with the mouse wheel isn't working at all. At the same time the rest of the system with several Chrome windows and LibreOffice docs open is unaffected

can you start vscode with --disable-extensions and take the following profile.

Open window devtools
Go to performance tab
Enable advanced paint instrumentation under settings
Click start profiling and reload page icon
Perform actions that cause the slowdown
Download the profile

Ok, reinstalled 1.53.
Started with --disable-extensions. Code starts, shows release notes and is already dead slow.
Profiling is running. Simply trying to enter text takes ages. Letters appear long after I finished typing...
Profile-20210208T225258.zip

Is there anything else I could do to?

The renderer execution is blocked for multiple seconds, as a next step can you capture the following trace.

Create trace.json somewhere on your disk with the following content:

{
 "result_file": "/tmp/vscode_trace_event.log",
 "trace_config": {
 "record_mode": "record-until-full",
 "included_categories": [
     "renderer",
     "v8",
     "v8.execute",
     "renderer.scheduler",
     "blink",
     "browser",
     "io",
     "input",
     "latency",
     "benchmark"
 ],
 "excluded_categories": ["*"]
 }
}

*Start code --trace-config-file="/trace.json"

Use vscode for a while as normal until the slowdown is seen
Quit the editor and attach vscode_trace_event.log

Ok, here is the event log.
vscode_trace_event.log.zip

Same symptoms here; code 1.53 on CentOS 8 is unusable; downgrade to 1.52.1 works just fine.

@gebailey, are you using Gnome with X11?
I just switched to Gnome on Wayland and the problem didn't show up yet. I need to test it a bit longer, though

Some updates from the chrome trace,

For a sample region from the trace that shows the Jank, there were 3 frames between A and D that were dropped. After scheduling BeginFrame for A in the main thread of the render process, there is no other activity other than javascript execution RunMicrotasks blocking the main thread before the BeginFrame for D was scheduled. Looking at corresponding  calls from the profile.

Not sure what _tryExecuteCommand does which could block execution for 200ms and there are repeating blocks of this causing the frame drops.

I just switched to Gnome on Wayland and the problem didn't show up yet. I need to test it a bit longer, though

This is interesting, @texjoachim can you provide a new performance profile from this step https://github.com/microsoft/vscode/issues/116131#issuecomment-775481186 and https://github.com/microsoft/vscode/issues/116131#issuecomment-777008622 for this setup ? Thanks!

Of course, here you are!
Profile-20210211T203315.zip
vscode_trace_event.log.zip

Yup can confirm the JS main thread is no longer blocking the frame rendering in the above vscode_trace_event but in the performance profile I do see long Composite Layers task. To understand this better, can you change the trace config to
{
 "result_file": "/tmp/vscode_trace_event.log",
 "trace_config": {
 "record_mode": "record-until-full",
 "included_categories": [
     "renderer",
     "v8",
     "cc",
     "input",
     "benchmark",
     "gpu",
     "viz",
     "toplevel",
     "disabled-by-default-cc.debug.scheduler.frames"
 ],
 "excluded_categories": ["*"]
 }
}

Of course!
Here it is!
vscode_trace_event.log.zip

I don't see any expensive compositing tasks in the main thread from the above trace, not sure what was happening in the devtools trace from https://github.com/microsoft/vscode/issues/116131#issuecomment-777740345.
As for the original issue with wayland, is it any better when you launch the app with --disable-gpu ?

Well, the original issue was with running X11.
I've since switched to Wayland and so far, the issue didn't come back, even without --disable-gpu. Upon next reboot of the system, I'll go back to X11 and try out --disable-gpu, ok?

Can anyone try the latest insiders https://code.visualstudio.com/insiders and check if this is fixed.

Ok, the issue is still present in 1.54.1 when using X11. Works fine using Wayland!

How about when using --disable-gpu with X11 ?

No action required, you can just subscribe to the other issue for updates.


python3Packages.editdistance: fix broken version tag

Motivation for this change
ZHF: #144627
#141133 seems to have reformatted the version specifier which caused fetchFromGitHub to fail, which I've corrected.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested basic functionality 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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python38Packages.editdistance
python39Packages.editdistance

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

2 packages built:

python38Packages.editdistance
python39Packages.editdistance


Define tests for release 0.1 functionality

We need to create some sample input configurations and expected output so we can drive the tooling and compare against our expected output.

See PR's #14 #17 #18 #19.


Share environment variables between collections

Hi,
Is there a way to share environment variables between collections? It seems that an environment belongs to one specific collection and not global as in Postman.
I'm using Bruno v1.9.0
Thanks

I would like this to be built in feature, +1
For now, I will stick with a workaround via symlinks.

See #115 for more discussion on the subject

You could do like I've done, and create an environments folder outside your root collections folder:
~/bruno
├-- collections
│   ├-- collection_a
│   ├-- collection_b
└-- environments
    ├-- environment_a
    └-- environment_b

And then inside each collection folder, delete the environments folder and replace with a symlink to ../../environments

@nathan-skillen
And then inside each collection folder, delete the environments folder and replace with a symlink to ../../environments
I did not understand about this solution... can you please elaborate little more step wise.. so that i can do same in my bruno tool..


feat: add support for new version of @heyapi and use fetch client ins…

…tead of axios

@7nohe  @seriouslag
This is a draft PR that maybe can get some discussion going on how to make this less of a breaking change.
The new hey api clients doesn't provide a service anymore by default.

By the way, really great lib :D

I also noticed that in the react example the UI doesn't update when you create a new pet, this fixes the issue.

might help address this as well:
https://github.com/7nohe/openapi-react-query-codegen/issues/94

@seriouslag
Also added formatters and linters support, as those would never run on the queries folder but only on the requests folder

Let's talk about the big elephant in the PR.
How do we make this a non breaking change?
I don't mind hopping on discord to discuss this.
Appreciate your feedback

Let's talk about the big elephant in the PR. How do we make this a non breaking change? I don't mind hopping on discord to discuss this. Appreciate your feedback

A breaking change is not no-go but this is a huge change as every single consumer has will have to change every hook. I feel we should not do that and offer a codemod or generate the old and new hooks and deprecate the old hooks. Or we could not break every hook and add back the service layer using the tag names. We could generate the services and this would be a non-breaking change.

Let's talk about the big elephant in the PR. How do we make this a non breaking change? I don't mind hopping on discord to discuss this. Appreciate your feedback

A breaking change is not no-go but this is a huge change as every single consumer has will have to change every hook. I feel we should not do that and offer a codemod or generate the old and new hooks and deprecate the old hooks. Or we could not break every hook and add back the service layer using the tag names. We could generate the services and this would be a non-breaking change.

yes there are several ways to go around this, I was thinking we can discuss it in discord or something so we can align on a way to tackle this with a plan, I don't mind the extra work.
An FYI, we might fork this and modify it to our needs as we don't nee support for all other clients, only the new fetch, I have published a beta version with these changes to check if it is working in our env and everything seems to be working.
Regardless, i'd much rather contribute to this great lib and only using a fork, you guys did really nice work here and i'd really want to give back :D

Let's talk about the big elephant in the PR. How do we make this a non breaking change? I don't mind hopping on discord to discuss this. Appreciate your feedback

A breaking change is not no-go but this is a huge change as every single consumer has will have to change every hook. I feel we should not do that and offer a codemod or generate the old and new hooks and deprecate the old hooks. Or we could not break every hook and add back the service layer using the tag names. We could generate the services and this would be a non-breaking change.

yes there are several ways to go around this, I was thinking we can discuss it in discord or something so we can align on a way to tackle this with a plan, I don't mind the extra work. An FYI, we might fork this and modify it to our needs as we don't need support for all other clients, only the new fetch, I have published a beta version with these changes to check if it is working in our env and everything seems to be working.
Regardless, i'd much rather contribute to this great lib and not only using a fork, you guys did really nice work here and i'd really want to give back :D

Thank you for all the work you have put into this! I have been away on vacation and will be for another week. Let’s touch base on discord when I get back.


View for active set size should be the first layer of the atxs epoch

Overview / Motivation
When taking view for ATX creation, there is no need to take the most current view, the first view of the publication epoch could be used.
The Task
TODO: Clearly describe the issue requirements here...
Implementation Notes
TODO: Add links to relevant resources, specs, related issues, etc...
Contribution Guidelines
Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity. We will not assign tasks to developers who have'nt introduced themselves on our Gitter dev channel

Introduce yourself on go-spacemesh dev chat channel - ask our team any question you may have about this task
Fork branch develop to your own repo and work in your repo
You must document all methods, enums and types with godoc comments
You must write go unit tests for all types and methods when submitting a component, and integration tests if you submit a feature
When ready for code review, submit a PR from your repo back to branch develop
Attach relevant issue to PR

Duplicates https://github.com/spacemeshos/go-spacemesh/issues/1017


Add branch protection etc to repo

We are no longer using this repo. Relevant work now here: https://github.com/NebraLtd/helium-miner-software/issues/399
Branch protection already exists on helium-miner-software.


Support applicationUrl of launchSettings.json

Environment data
dotnet --info output:
.NET Command Line Tools (2.1.101)

Product Information:
 Version:            2.1.101
 Commit SHA-1 hash:  6c22303bf0

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.101\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.6
  Build    : 74b1c703813c8910df5b96f304b0f2b78cdf194d

VS Code version: 1.23.1
C# Extension version: 1.15
Steps to reproduce

Create a default ASP.NET Core project with VS.
Change Application URL in Project Settings
Launch it via VSCode

Expected  behavior
Application binds to the correct Application URL defined in launchSettings.json as applicationUrl as it does when using dotnet run.
Actual behavior
Application binds to port 5000

This is still not working for me. I have 2 projects in one folder, and it ignores my launchSettings.json for both of them and tries to run them both on port 5000.
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Client",
            "type": "coreclr",
            "request": "launch",
            "program": "${workspaceFolder}/WebUI/bin/Debug/netcoreapp2.0/GidIndustrial.Gideon.WebUI.dll",
            "args": [],
            "cwd": "${workspaceRoot}/WebUI",
            "stopAtEntry": false,
            "externalConsole": false
        },
        {
            "name": "Debug Server",
            "type": "coreclr",
            "request": "launch",
            "program": "${workspaceFolder}/WebApi/bin/Debug/netcoreapp2.1/GidIndustrial.Gideon.WebApi.dll",
            "args": [],
            "cwd": "${workspaceRoot}/WebApi",
            "stopAtEntry": false,
            "externalConsole": false,
        }
    ],
    "compounds": [
        {
            "name": "Debug Server and Client",
            "configurations": [
                "Debug Server",
                "Debug Client"
            ]
        }
    ]
}

I am happy to help investigate, but please open a new issue rather than commenting on a closed issue. Please include these three details --

What OS are you on
For the projects you are launching, what is the path to your launchSettings.json relative to the root of your workspace. The debugger should be looking in ${cwd}/Properties/launchSettings.json.
Please share your launchSettings.json.

Ok, my apologies.


List formatting hideSelection property not working for groups

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
Declarative list formatting
Developer environment
Windows
What browser(s) / client(s) have you tested

[X] 💥 Microsoft Edge
[X] 💥 Google Chrome
[X] 💥 FireFox
[X] 💥 Safari

Additional environment details
No response
Describe the bug / error
The group selection is not getting hidden in a Microsoft Lists view formatting with the property hideSelection is defined to true.
Steps to reproduce

Group a list by one of the columns
Apply a custom view formatting and define the property "hideSelection"="true"
Hover the group name and you will see that the main selector for the group gets visible

Expected behavior
The group selector should not be visible when the hideSelection is defined to true, despite being visible it doesn't do anything to the view.

The build with the fix will roll out in upcoming weeks. Thanks!

The fix is now rolled out. @joaoferreira let me know if this still doesn't work as expected. Thanks! :)


[BUGFIX] Fixes accessInboxFor method to only retrieve emails where …

…the $email is equal to the recipient (to) of the fetchedEmail

I haven't used this in a while, but I think I remember it's useful to test emails sent to CC / BCC addresses?

We should put the stuff for TO, CC and BCC into other methods, because in our case we retrieve emails with accessInboxFor we do not want to test.
I prefer methods like:
accessInboxFor($addresses) // filters all headers
accessInboxForTo($addresses) or accessInboxWithTo($addresses) // filters only the "to" header
accessInboxForCc($addresses) or accessInboxWithCc($addresses) // ...
accessInboxForBcc($addresses) or accessInboxWithBcc($addresses)


Show consistent UI for disabled buttons on services, tags and teams page

In case of non-admin user, it should look disabled same as what we have on services listing page

Assign this to me


dotnet-helix-service-ci build broken

dotnet-helix-service-ci build is broken, the errors that we have seen are related with authentication
https://dev.azure.com/dnceng/internal/_build/results?buildId=2258159&view=logs&j=6607dfcd-a609-51d9-3a08-6e6c410562d4&t=63403f8b-0cc6-5711-0b76-c27055010d05&l=1542
we are not able to rollout until this build gets into a green stated

Release Note Category

[ ] Feature changes/additions
[ ] Bug fixes
[ ] Internal Infrastructure Improvements

Release Note Description
No release notes, internal fix

PRs:

https://dev.azure.com/dnceng/internal/_git/dotnet-helix-service/pullrequest/33617
https://dev.azure.com/dnceng/internal/_git/dotnet-helix-service/pullrequest/33618

fixed. closing


Does not work with ssh-agent

At first: I'm on windows, which could be the problem (Win 10 Pro, 64bit)
I don't know if this is a bug or just not implemented yet. However, I'm not able to use git-plus when I protect my default identity (id_rsa) with a passphrase. The key is added to the agent, and executing ssh-add -l shows me valid output (key is loaded).
It's no problem to open a command prompt, navigate to my local repo and execute a push/pull/fetch/whatever. But git-plus won't work.
Is this issue on my side?

Same problem here. This has been an issue with git-plus for a long time now, when I first tried git plus push it just doesn't work and it doesn't ask me for my password like it would on the terminal. The same goes for any git command that connects to the remote repo.
Some of the submitted issues say the issue only happens in Windows and how it handles SSH.
I just really really REALLY hope this is fixed eventually. My workflow in Atom would be flawless if this was fixed.

is your remote https?  if so need to switch it to ssh
switching the remote from http to ssh did it or me - it was crated as https...needs to be SSH for git-plus
command looks like this:
git remote set-url origin git@github.com:path/to/my/repo.git

No sir, I've always used ssh for all my remote repos.

Same here. Used ssh all the time.

The package was created with the assumption that your remote setup uses ssh and doesn't require a passphrase and I only recently added that claim to the README.
I've been thinking about how to go about implementing this but I haven't had a chance to get started.
I'm closing this and referencing #336 because it is essentially aiming for the same result

If you created this with the assumption that your remote setup uses ssh and doesn't require a passphrase ... then can you at least point us to a page/guide/article on how to set up a passwordless SSH on Windows?

https://help.github.com/articles/generating-an-ssh-key/#platform-windows

I met the same problem because

Enter passphrase for key '/Users/***/.ssh/id_rsa'

i solved it.
@raniesantos
check it out https://help.github.com/articles/working-with-ssh-key-passphrases/#saving-your-passphrase-in-the-keychain


QuantLinear cuda: low performance at a6000

Hi,
I tried QuantLinear from qlinear_cuda under auto_gptq.nn_moduldes.qlinear but its performance is low with skinny matmul (i.e. matmul shapes at token gen).
Its perf is even worse than fp32
for example, when M, N, K = 8, 11008, 11008
nn.Linear perf(torch.float16 GEMM), tops=4.988040446327411, ms=0.3886931240558624, mem_bw=624.4113131394598
auto_gptq_gemm (wbits=8) perf, tops=1.1186859903537671, ms=1.7331199645996094, mem_bw=70.12112403198577
auto_gptq_gemm (wbits=4) perf, tops=1.079567580111752, ms=1.7959200143814087, mem_bw=33.93262924406488
its triton version was tested using kernels in gptq_quant (link)
gptq_triton_gemm (wbits=8) perf, tops=4.8018665417962785, ms=0.40376320481300354, mem_bw=300.9890910101229
gptq_triton_gemm (wbits=4) perf, tops=5.00364444477819, ms=0.3874809741973877, mem_bw=157.27298127664005
but from the blogs and the reads, these fused dequantization + vector-matmul kernels in cuda (like "VecQuant8MatMulKernel") is supposed to be better than regular fp16 kernels
the script i used is like the following

layer = nn.Linear(K, N)
layer.requires_grad_(False)
layer.bias.fill_(0.0)
vec = torch.randn([M, K]).to(DEV)
fp16_vec = vec.type(torch.float16)
import_auto_gptq = True

if import_auto_gptq:
    from auto_gptq.nn_modules.qlinear.qlinear_cuda import QuantLinear as gptq_QuantLinear
    import quant as gptq_quant
    from gptq import GPTQ, Observer

    name = "gptq-layer"
    groupsize = K
    act_order = True
    percdamp = .01
    sym = True

    gptq_layer = GPTQ(layer, observe=False)
    gptq_layer.add_batch(fp16_vec, torch_fp16_out)
    gptq_layer.quantizer.configure(wbits, perchannel=True, sym=sym, mse=False)
    auto_gptq_linear = gptq_QuantLinear(wbits, groupsize, layer.in_features, layer.out_features, layer.bias is not None)

    scale, zero, g_idx, error = gptq_layer.fasterquant(percdamp=percdamp, groupsize=groupsize, actorder=act_order, name=name)
    quantizer_cpu, scale_cpu, zero_cpu, g_idx_cpu = gptq_layer.quantizer.cpu(), scale.cpu(), zero.cpu(), g_idx.cpu()
    auto_gptq_linear.pack(layer_cpu, scale_cpu, zero_cpu, g_idx_cpu)
    auto_gptq_linear.to(DEV)

    auto_gptq_gemm_fn = lambda: auto_gptq_linear.forward(fp16_vec)
    ms, min_ms, max_ms = triton.testing.do_bench(auto_gptq_gemm_fn)
    gemm_tops = tops(ms)
    gemm_dsize = fp16_vec.nelement() * fp16_vec.element_size() + auto_gptq_linear.qweight.nelement() * auto_gptq_linear.qweight.element_size(
    ) + torch_fp16_out.nelement() * torch_fp16_out.element_size()
    mem_bw = lambda ms: (gemm_dsize* 1e-9) / (ms * 1e-3)
    perf = get_perf(auto_gptq_gemm_fn)
    print(f"auto_gptq_gemm (wbits={wbits}) perf, tops={gemm_tops}, ms={ms}, mem_bw={mem_bw(ms)}, perf={perf}")

i also checked it using torch.profile like shown below

any comments? is this perf expected?

@stephen-youn yes this is expected. Basically qlinear_cuda and qlinear_cuda_old are not very good, as well as the triton kernel. I'd recommend you to use the exllama kernel (that is default).
I did not do a thorough benchmark with act-order (i.e. with qlinear_cuda kernel), but you can find some numbers here for qlinear_cuda_old: https://github.com/fxmarty/optimum/tree/add-benchmark-gptq/tests/benchmark#gptq-benchmark
Some numbers here as well, probably a bit outdated: https://github.com/fxmarty/q4f16-gemm-gemv-benchmark
Feel free to open a PR with a reproducible script to benchmark each of the kernels (triton, qlinear_cuda_old, qlinear_cuda, exllama, exllama_v2). That would be very useful.


download: use existing open fd

Use the existing open file descriptor
instead of opening a new file descriptor
to the same file.
It is not clear to me if this has any
bearing for #67, but having fewer file
descriptors open will not make anything
worse.

@pjonsson Thank you :star2:


3 operations added

Enhancements based on field feedback
3 operations added:

list documents in store
remove documents from store based on file or URL name
query based on filter (file or URL name) from store

I've tested the embedding operations in S3, local and url, they are all working fine.  I think it's safe to merge the two branches.


ci: [Policy Assistant] tests in github action

Fixes #202.
GitHub action does the following:

Trigger only on changes to cmd/policy-assistant/ directory
Run unit tests
Build binary
Run commands for each analyze mode and make sure they exit with zero code

The GH action will fail until #244 and #245 merge.

GH action now passes

The GH action will fail until #244 and #245 merge.

#244 merged. I removed tests that depend on #245. This PR should go in first

Hey @astoycos @danwinship @Dyanngg 👋, could I get a review on this change introducing PR checks for policy assistant?


Transparently reconnect clients

1- Client connects
2- Client connection disconnects (tcp disconnect, not a graceful shutdown)
3- Server realizes disconnection and deletes client session after 60 seconds
4- Client tries to send a new message.
At step 4, we let the application know that session was deleted. No need for that. Just reconnect and send the operation.

Won't fix


Throw Statements can be used as expressions

The following REPL input causes a compiler error:
> throw new RuntimeException
dyvilx.tools.compiler.backend.exception.StackUnderflowException
	at dyvilx.tools.compiler.backend.method.Frame.pop(Frame.java:250)
	at dyvilx.tools.compiler.backend.method.Frame.visitFieldInsn(Frame.java:745)
	at dyvilx.tools.compiler.backend.method.MethodWriterImpl.visitFieldInsn(MethodWriterImpl.java:796)
	at dyvilx.tools.compiler.backend.method.MethodWriter.visitFieldInsn(MethodWriter.java:141)
	at dyvilx.tools.compiler.ast.field.Field.writeStaticInit(Field.java:607)
	at dyvilx.tools.repl.context.REPLVariable.writeStaticInit(REPLVariable.java:132)
	at dyvilx.tools.compiler.ast.classes.ClassBody.writeStaticInit(ClassBody.java:990)
	at dyvilx.tools.compiler.ast.classes.CodeClass.writeStaticInit(CodeClass.java:636)
	at dyvilx.tools.compiler.ast.classes.CodeClass.write(CodeClass.java:564)
	at dyvilx.tools.compiler.backend.classes.ClassWriter.compile(ClassWriter.java:32)
	at dyvilx.tools.repl.context.REPLClassLoader.findClass(REPLClassLoader.java:57)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at dyvilx.tools.repl.context.REPLClassLoader.initialize(REPLClassLoader.java:84)
	at dyvilx.tools.repl.context.REPLContext.compileAndLoad(REPLContext.java:163)
	at dyvilx.tools.repl.context.REPLContext.endEvaluation(REPLContext.java:137)
	at dyvilx.tools.repl.DyvilREPL.evaluate(DyvilREPL.java:225)
	at dyvilx.tools.repl.DyvilREPL.processInput(DyvilREPL.java:205)
	at dyvilx.tools.repl.Main.readAndProcess(Main.java:55)
	at dyvilx.tools.repl.Main.main(Main.java:20)

The reason is that the REPL tries to assign the expression to a field, but the expression does not return.

This is a general problem with throw "expressions":
let x = throw new RuntimeException
println(throw new RuntimeException)

TypeScript (and probably other languages) solve this by introducing a never type.
let x = throw new RuntimeException
print(throw new RuntimeException) // error, because never is not assignable to something that is printable

They also use it for dead-code detection:
const x = "foo"
if (x === "foo") {
    //....
} else {
    // x is of type never
}

Using this construct, you can also assert that the cases of a switch statement is exhaustive during type-checking:
function assertNever(value: never) {}
//...
const x = "foo";
switch(x)
{
    case "foo":
        return "bar";
    default: assertNever(x); // if there is a code path that would hit the default branch, x would not be never but something diffferent instead. This errors at compile time
}

C# does not have this but allows throws in expressions. This is useful in places like:
void Test(string arg) {
    this.Arg = arg ?? throw new ArgumentNullException();
    // of even (using the nameof operator):
    this.Arg = arg ?? throw new ArgumentNullException(nameof(arg)); // Exception knows the name of the variable that was null
}
string GetLastName()
{
    var parts = Name.Split(' ');
    return parts.Length > 1 ? parts[1] : throw new InvalidOperationException("Invalid name!");
}

It also helps when using lambdas in some cases:
void Test2() {
    SomeFunctionWithCallback(() => throw new NotImplementedException());

    var foo = "bar";
    var a = foo switch { // Switch expressions
        "bar" => "baz",
        _ => throw new NotSupportedException()
    }
}

Maybe this inspires you. The way Java does it (making throw a statement only) is not the only way of handling this case. Java recently tries to work around this decision by selectively allowing "throw" statements in the new pattern matching proposal. This wouldn't have been necessary if they did it different in the first place.

Hm, actually I already have a type like never (although it's called none). It is a subtype of every type and also the type that is inferred when using a throw "statement" as an expression. Now that I think about it forbidding throw from being used as an expression is a bad idea. Using it as part of a ternary or null coalescing (??) is a great application.

never (although it's called none)

Whats the difference to something like void?

Well the type system treats it differently because it is a bottom type. Also, it makes the difference between „function f():void returns nothing“ and „function g():none never returns at all“. Indeed the naming is confusing, I should rename it to never. I got the name from Scala‘s Nothing which has the same problem, except the language uses Unit instead of void. So at least they are consistent.

„function f():void returns nothing“ and „function g():none never returns at all“

I think my phrasing was ambiguous (corrected now). It actually is the same as never in TS, but without trivial infinite loop detection (and unreachable code detection in general?).
Other languages use "none" as a unit type. I first had the impression that it was the same here. Thanks for clarification.

Yes, there is no unreachable code detection at all in the language. The compiler is not sophisticated enough for that and retrofitting it is a pain.


Not Supported for MAC Version 10.10.5

The latest version Version 3.6.0 is not supported for mac version 10.10.5.
Can you please look it and help to resolve it ?

Please check #95 issue. Isn't it the same problem?
If not then please report more details.

I am closing this issue after changing few security thing in my mac system.


there are some package errors in wiki

https://github.com/rest-assured/rest-assured/wiki/Usage#adding-result-handlers
https://github.com/rest-assured/rest-assured/wiki/Usage#using-result-matchers
In these two sections,
the package org.springframework.test.web.server.result is wrong,
should be org.springframework.test.web.servlet.result

Thanks, I've fixed it now.


1.0.16_crab version of Make sure httplib2 is not required if using pycurl

Oops, didn't mean to merge into master. My bad, closing.


Control via Wi-Fi

Good day!
I am disabled since birth and it is very difficult for me to perform any physical actions with most objects. One good person gave me xArm (6DOF Arm Robot) from LewanSoul.
This manipulator suits me everything except control software. Could you try to adapt your project for the xArm + ESP8266 bundle?

OK. How about web-interface? Can you integrate this project https://forum.phpoc.com/blogs/khanh-s-blog/1129-arduino-control-arm-robot-via-web ?

I can do something similar. I am working on a library for ESP in Lua, MicroPython and Arduino presently.

ok


fix: reenabling Ethereum wallet connection in preview mode

Closes #700 .
What?

[x] Enables Ethereum wallet connection in preview mode
[x] Hints scene devs to check that web3 is enabled in the current session when an error occurs
[x] Shows a warning bar when in preview mode pointing to Mainnet

Warning sign when using Mainnet (it's possible to dismiss it):

Console warnings when trying to use web3 methods without the proper config (i.e. ENABLE_WEB3 parameter)


Export to PPT/PDF is not supported. Please enhance the visual to support export functionality

Is your feature request related to a problem? Please describe.

It would be good if we have option to export to PPT/PDF
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Exporting is the issue.
Describe the solution you'd like
Please enhance to visual to support export functionality

Hi, and thanks for raising. The standard edition of the visual cannot support exporting as it is not certified. It cannot be certified due to the functionality on offer.
You can use the certified edition - HTML Content (lite), which comes with some limitations due to requirements from Microsoft for certified visuals. Please refer to the site for more details:
https://www.html-content.com/editions
https://www.html-content.com/faq


Python InteslliSense does not work.

Environment data
Version: 1.56.0-insider (user setup)
Commit: 5080d21c0b538b996c83fb7b14a746f656eaef15
Date: 2021-04-26T17:23:39.588Z
Electron: 12.0.4
Chrome: 89.0.4389.114
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.17134

Steps to reproduce:

Set "python.autocomplete.addBrackets" = true in workspace settings
Add "import os" to python file

Expected behaviour

Write "os.getc", you'll see autocomplete for os.getcwd, selecting it, ensure:
a. Auto-complete adds os.getcwd() to the source code and place the cursor inside the parentheses
If this setting is false, only os.getcwd is added to the file

Actual behaviour
actual1 setting:

Write "os.getc", Auto-complete adds os.getcwd() to the source code, but the cursor does not place inside the parentheses, the cursor place after the parentheses.

actual2 setting:

2. When setting "python.autocomplete.addBrackets" = false, os.getcwd() is added to the file not os.getcwd.

@zhouwangyang Which language server is used? Can you look at python.languageServer setting for the value? Can you also share logs from Output > Python panel

@karthiknadig ,
log from output->panel
User belongs to experiment group 'pythonaa'
User belongs to experiment group 'pythonJediLSP'
User belongs to experiment group 'pythonDiscoveryModuleWithoutWatcher'
User belongs to experiment group 'pythonTensorboardExperiment'
User belongs to experiment group 'PythonPyTorchProfiler'
User belongs to experiment group 'CollectLSRequestTiming - experiment'
User belongs to experiment group 'CollectNodeLSRequestTiming - experiment'
User belongs to experiment group 'DeprecatePythonPath - control'
Python interpreter path: C:\Python39-64\python.exe
Error 2021-05-26 06:00:37: Failed to check if file needs to be fixed [EntryNotFound (FileSystemError): Unable to read file 'c:\Users\vyizh12\Downloads\Test2.vscode\settings.json' (Error: Unable to resolve non-existing file 'c:\Users\vyizh12\Downloads\Test2.vscode\settings.json')
at _handleError (c:\Users\vyizh12\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:85:157332)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async y.readText (c:\Users\vyizh12.vscode-insiders\extensions\ms-python.python-2021.6.864643163-dev\out\client\extension.js:9:344808)
at async p.doesFileNeedToBeFixed (c:\Users\vyizh12.vscode-insiders\extensions\ms-python.python-2021.6.864643163-dev\out\client\extension.js:59:579757)
at async c:\Users\vyizh12.vscode-insiders\extensions\ms-python.python-2021.6.864643163-dev\out\client\extension.js:59:578884
at async Promise.all (index 1)
at async p.getFilesToBeFixed (c:\Users\vyizh12.vscode-insiders\extensions\ms-python.python-2021.6.864643163-dev\out\client\extension.js:59:578830)
at async p.updateTestSettings (c:\Users\vyizh12.vscode-insiders\extensions\ms-python.python-2021.6.864643163-dev\out\client\extension.js:59:578457)] {
code: 'FileNotFound'
}
Starting Pylance language server.


Lint js code

Related #42
Great!

@rkonno
It's OK!
Plz merge!

@emiksk
LGTM!
I tried lint in the local environment. Good vibes! 👍


Not really a pull request yet

Hi Evan,
Two main additions here, mainly:

add a code to rearrange ImageNet validation data (based on the earlier issue I opened)
create a sub folder in srcEt accessed through entryEt.py. What it does: to run the minimal example (slightly modified).

Bear in mind that I try to make as little change as possible to your existing code, just to be safe. Please review the following before taking action on this pull request, your help is very much appreciated.
I would like to ask your opinion about change number 2 which is the main issue here. Normally, I understand that the minimal example will access src/milannotations/datasets.py. In line ~158, each layer will be processed. In my case, that is too slow and resource consuming (my process keeps getting killed) as the code is run in my local machine for debugging. So I made the mini version that is run using entryEt.py and accesses srcEt/milannotations/datasetsMini.py.
The difference between datasetsMini.py and datasets.py: rather than computing every layer for every run, datasetsMini.py only computes the selected layer for lookup (only small change in the code, see pull request). Is this okay? It seems like all other layers are not really interfering with the looked up layer.
Btw the following raises "TypeError: 'module' object is not callable" error (I have seen the relevant commit you made too)
outputs = milan(sample.images[None], masks=sample.masks[None])
so I used the following instead
outputs = decoder(sample.images[None], masks=sample.masks[None])
In any case, I keep getting 'Edges' as the output from the following
print(outputs.captions[0])
even if I changed the layers and units. Furthermore, sample.images[None] appear as black images across all "channels".
Can you give some hints on what might be wrong?
I'm running it on the ubuntu >20 btw.

Thanks Evan, will look forward to it


defaultDate for rangePlugin.

How can we pass defaultDate on rangePlugin?
having defaultDate: [new Date(), new Date()] still defaults to the range input with 'to'.

Just tested this. Thank you so much.


webinterface "updater"

Webinterface "Updater"
Page Description
The Updater provides an overview screen of all installed components.
The components are matched against our registry and their version is compared to the latest version in the registry. If the version in the registry is higher, than the installed one, an update link is provided.
Update Link (action) fetches the download archive, extracts it and installs the files in the correct folders.
Webinterface Link
http://localhost/tools/webinterface/index.php?page=update
Todo List

[x] check for installed components
[x] detect versions
[x] ask wpn-xm server for registry
[x] compare installed version against latest registry version

[ ] either by service request
[x] or checking agaisnt downloaded registry

[x] show new version number and provide update button ("update to v1.2.3")
[x] update action for individual component "update&component=xy"
[ ] download & unzip

[ ] class Downloader

[ ] make it do the update thing

[ ] add install() methods to Component classes

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2199157-webinterface-updater?utm_campaign=plugin&utm_content=tracker%2F164029&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F164029&utm_medium=issues&utm_source=github).

We don't need downloading on two sides: webinterface and server control panel.
That's why the updater will be removed, in favor of downloading through the server control panel.
Closing.


feat: implement tracking as per spec

:mega: This was a draft for a while, but is now ready for review! :mega:
This implements tracking as per spec, in the server, web, and react SDKs.
I don't think the Angular or Nest SDKs need specific implementations, but please advise (cc @luizgribeiro @lukas-reining).
Fixes: https://github.com/open-feature/js-sdk/issues/1033
Fixes: https://github.com/open-feature/js-sdk/issues/1034

This is ready for review now.

Lgtm. Would be nice to hook it up to @beeme1mr s test app?

That's the plan!

I'm merge this tomorrow unless I hear objections


Fix for broken example link

Updated link that had wrong path for reload example

@jrnt30 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@jrnt30 Thank you for signing the Contributor License Agreement!


[WFLY-14406] Update mixed domain tests to use EAP 7.4.0 rather than WF23

Jira issue: https://issues.redhat.com/browse/WFLY-14406

This PR requires a wildfly core upgrade including https://github.com/wildfly/wildfly-core/pull/4689

Retest this please


Failing to automatically register dependencies

I'm trying to use the JsonNet package but it is not working with self hosted Nancy. I think I'm doing everything as needed, installing the package from Visual Studio will result in versions
<packages>
  <package id="Nancy" version="1.4.3" targetFramework="net45" />
  <package id="Nancy.Hosting.Self" version="1.4.1" targetFramework="net45" />
  <package id="Nancy.Serialization.JsonNet" version="1.4.1" targetFramework="net45" />
  <package id="Newtonsoft.Json" version="8.0.2" targetFramework="net45" />
</packages>

Code is very basic
    static void Main(string[] args)
    {
        using (var host = new NancyHost(new Uri("http://localhost:1234"), new NancyBootstrapper()))
        {
            host.Start();
            Console.ReadLine();
            host.Stop();
        }

    }

For running nancy and small bootstrapper and custom serializer
public class NancyBootstrapper : DefaultNancyBootstrapper
{

    protected override void ConfigureApplicationContainer(TinyIoCContainer container)
    {
        base.ConfigureApplicationContainer(container);
        container.Register<JsonSerializer, CustomJsonSerializer>();
    }
}

public class CustomJsonSerializer : JsonSerializer
{
    public CustomJsonSerializer()
    {
        ContractResolver = new CamelCasePropertyNamesContractResolver();
        Formatting = Formatting.Indented;
    }
}

This is the exception message
An unhandled exception of type 'System.InvalidOperationException' occurred in Nancy.dll
Additional information: Something went wrong when trying to satisfy one of the dependencies during composition, make sure that you've registered all new dependencies in the container and inspect the innerexception for more details.
And further Innerexception
{"Unable to resolve type: Nancy.NancyEngine"}
{"Unable to resolve type: Nancy.Routing.DefaultRequestDispatcher"}
{"Unable to resolve type: Nancy.Routing.DefaultRouteResolver"}
{"Unable to resolve type: Nancy.Routing.DefaultNancyModuleBuilder"}
{"Unable to resolve type: Nancy.DefaultResponseFormatterFactory"}
{"Could not load file or assembly 'Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"}

I actually discover the problem at the same time that was writing the issue, when installing the package it will actually install latest Newton.Json version which is 8.0.x, this will not work. You need to install first the Newton.Json version 6.0.1 (Haven't test anything newer) and then install this package, any idea what has change in the newer Newton.Json that generates this problem?

Yeah. This is a problem with Newtonsoft.Json's strategy to strong-name the assembly and occasionally bump the major version.
First of all, we should probably ship a newer version of this package soon, it'll probably be in the 2.0 timeframe. That's right around the corner.
Before that, I think you should be able to solve this by using some assembly binding redirects:
<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral"/>
            <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>"/>
        </dependentAssembly>
    </assemblyBinding>
</runtime>

Ok, when i write that in the app.config I can use latest version of Json.net.
Thanks

I have same problem on windows service project and Newtonsoft.Json 11 .  I test the cli and run without problem but I got dependency exactly like you when I move code to windows service wrapper. I try your xml with json.net version 8.1 and 7.1 but both of them made same problem.


Seems Code is throwing error

Just followed the instruction provided and getting the below error, Could you please guide on the fix
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/stem/socket.py", line 535, in _make_socket
control_socket.connect((self.address, self.port))
ConnectionRefusedError: [Errno 61] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "breakfold.py", line 113, in
visit()
File "breakfold.py", line 105, in visit
renew_connection()
File "breakfold.py", line 51, in renew_connection
with Controller.from_port(address="<IP_ADDRESS>", port = 9051) as controller:
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/stem/control.py", line 1033, in from_port
control_port = stem.socket.ControlPort(address, port)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/stem/socket.py", line 503, in init
self.connect()
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/stem/socket.py", line 172, in connect
self._socket = self._make_socket()
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/stem/socket.py", line 538, in _make_socket
raise stem.SocketError(exc)
stem.SocketError: [Errno 61] Connection refused

hi @Learner-Manu
From the above log, I can only guess that your tor service is not running.
Also, it is working fine for me!
If you are still having a problem, please give some more details!

I'm having the exact same issue :/
  File "/usr/local/lib/python3.6/dist-packages/stem/socket.py", line 535, in _make_socket
    control_socket.connect((self.address, self.port))
ConnectionRefusedError: [Errno 111] Connection refused

Hi @aryamansharda
With the amount of information, you have provided I can only tell that this is because your tor service is not working!
As I said earlier also this is working fine for me!
 You can reopen if you are still facing problem! :)
Take care,
shubham


Error "ImportError: libboost_python.so.1.60.0: cannot open shared object file: No such file or directory"

Hello,
When I run a command [python -c "import dlib"], I got a error message below.
========================
pi@raspberrypi:~/Desktop/dlib $ python -c "import dlib"
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/dlib-18.18.0-py2.7-linux-armv7l.egg/dlib/init.py", line 1, in
from .dlib import *
ImportError: libboost_python.so.1.60.0: cannot open shared object file: No such file or directory
========================
But, If I run a command [LD_LIBRARY_PATH="/usr/local/lib" python -c "import dlib"], there is no error.
So, I think that there is a problem about library path.
Is this dlib setting problem or my system problem?
If you know the solution, how can i fix this?
I use raspberry pi 3  and OS is Raspbian Jessie.
please help me... Thank you.

This is not a dlib problem.  You just need to add /usr/local/lib to your LD_LIBRARY_PATH.

@davisking
Okay, Thank you~  :)


Projection Builder should reuse projection classes

Problem: The code generator creates a new class for each projection in a hierarchy. As soon as the schema has loops in interfaces this does not work well. It works only for tree structures but not for graph structures.
I haven't looked into it in detail, but it should be enough to have one projection class per type. I do not understand the need to generate the hierarchy of projections as classes.
The way it is now, codeGen is unusable for all schemas that have loops between interfaces.
Example:
interface TypeWithRelationship {
    relationship: TypeWithRelationship
}

type ConcreteType1 implements TypeWithRelationship {
    relationship: TypeWithRelationship
}

type ConcreteType2 implements TypeWithRelationship {
    relationship: TypeWithRelationship
}

type Query {
    testQuery: TypeWithRelationship
}

A client for this schema already has 31 classes using maxProjectionDepth=2. 69 classes will be generated with just one additional concrete type.
Our real schema consists out of 100 interfaces and 50 types. Codegen generates 80000 classes (using maxProjectionDepth=2) which results in a 130MB client that requires 4GB Heap to compile and makes most local workspaces unusable.
This might have the same root cause: #249

I have noticed the same problem or very simmilar /related, here is the original discussion:
https://github.com/Netflix/dgs-framework/discussions/735
If you have for example 10 queries that returns the same object, the framework generates 10 projections with the same fields of that object, instead of generating an abstract class with all the fields and just inherit the abstract class.
I think the framework should be smarter to detect that same objects and share a common inheritance. At least with projections builder.

Hi @berngp, any updates? Do you agree that this is a problem and requires a fix?
Thanks.

No updates yet and you are correct, it is an issue that we currently have.

@zanonena and @frbosch - Thanks for bringing this up. The current methodology for generating projections for each query (regardless of the whether the same type is used as the return type) was done precisely to handle cycles so we could stop generating endlessly. At the time, this schema was the best way we were able to even handle small schemas with nested cycles, which was the primary use case we had to handle so far. With more adoption for larger schemas, this obviously doesn't work so well as you have pointed out. Unfortunately, this does require a rewrite of our projection generation logic and is non-trivial to get working for all use cases. It is also a big breaking change for our internal users with the implementation you propose and is therefore not going to be feasible in the near term.
We will need to address the core issue of handling cycles with larger schemas, but given our current commitments, we are not able to prioritize this any time soon.

Thanks @srinivasankavitha for clarifying.

Also, do you need a client for the entire schema? Typically folks have been restricting the generation of projections to just the queries that the client needs to create, and not on the entire schema. Does that address your issue with the number of projections generated? You can checkout the includeQueries flag in codegen config: https://netflix.github.io/dgs/generating-code-from-schema/#configuring-code-generation
The above setting, in combination with setting the maxProjectionDepth, might solve your issue?
Also, we will add more documentation for such scenarios.

I will close this issue. Please reopen a new one if the above recommendation does not work for you.

@srinivasankavitha Hi, we did try the 'includeQueries' parameter, but it does not solve the issue. We switched to another client implementation. It would be great if you could put this into your backlog, because it is still an issue.

Thanks for the update @frbosch. Would you mind sharing which client
implementation you chose to use? It would help us better support different
use cases for the future.
On Mon, Feb 21, 2022 at 12:48 AM frbosch @.***> wrote:

@srinivasankavitha https://github.com/srinivasankavitha Hi, we did try
the 'includeQueries' parameter, but it does not solve the issue. We
switched to another client implementation. It would be great if you could
put this into your backlog, because it is still an issue.
—
Reply to this email directly, view it on GitHub
https://github.com/Netflix/dgs-codegen/issues/269#issuecomment-1046612198,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5JPXL7REVKCLZUEQQQY3TU4H353ANCNFSM5HUXOTUQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thanks for the update @frbosch. Would you mind sharing which client implementation you chose to use? It would help us better support different use cases for the future.

Sorry for the late reply. We use the Apollo Kotlin client.

Thanks!
On Mon, May 9, 2022 at 1:45 AM frbosch @.***> wrote:

Thanks for the update @frbosch https://github.com/frbosch. Would you
mind sharing which client implementation you chose to use? It would help us
better support different use cases for the future.
Sorry for the late reply. We use the Apollo Kotlin client.
—
Reply to this email directly, view it on GitHub
https://github.com/Netflix/dgs-codegen/issues/269#issuecomment-1120818928,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5JPXO56SPEC2CKCQ4SFDLVJDGCXANCNFSM5HUXOTUQ
.
You are receiving this because you were mentioned.Message ID:
@.***>