Range component not styled in Chrome 49+

Note: for support questions, please use one of these channels:
https://forum.ionicframework.com/
http://ionicworldwide.herokuapp.com/
Short description of the problem:
The range component doesn't render track color correctly on latest Google Chrome 49+
What behavior are you expecting?
The track color should be rendered correctly it used to
Steps to reproduce:

Update Google Chrome to latest version (49+)
Open the official Ionic component documentation
Navigate to range component section and see the preview.

Other information: (e.g. stacktraces, related issues, suggestions how to fix, stackoverflow links, forum links, etc)
It looks like Chrome has changed the way to render range input intentionally, https://bugs.chromium.org/p/chromium/issues/detail?id=582301#c6
Which Ionic Version? 1.x or 2.x
Happen in Ionic 1.x, and probably 2.x too.
Run ionic info from terminal/cmd prompt: (paste output below)
Your system information:

Cordova CLI: 6.0.0
Gulp version:  CLI version 3.9.0
Gulp local:
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.1.1
Xcode version: Xcode 7.2.1 Build version 7C1002

Hello thanks for opening an issue with us! I was able to confirm this in Chrome 51 Canary. Good catch!

This is caused by a supposedly-WontFix bug in Chromium, for some reason they decided the pseudoelements used shouldn't exist.
I get the impression the change was made without looking at how -webkit-slider-thumb:before/after are actually used, since it's attracted half a dozen duplicate bug-reports already.

@FLHerne it is exactly WontFix as Chromium team notes on above link. Well, I guess it's gonna affect to Crosswalk soon. I'm looking for a hack or a solution to work around this range issue.

Hi @petehouston,
We probably will not fix this for V1.  We are creating a scroller from scratch for V2.
Thanks for letting us know about this.  I'll let you know if anything changes WRT to the slider.
Thanks,
Dan


Added Francis Tuttle Technology Center

Added the student.francistuttle.edu domain to the repository.

Website URL: https://www.francistuttle.edu/
Course Master Link: https://www.francistuttle.edu/programs-and-classes/career-training-programs/programming-and-software-development
12777 N. Rockwell Ave
Oklahoma City, OK 73142
United States of America

@efAshryver Thank you for your patience while waiting for a review and processing your request. Pull request merged. Please start applying for JetBrains educational subscription at https://www.jetbrains.com/shop/eform/students in an hour, to allow the changes to propagate through JetBrains systems.


grv: 0.2.0 -> 0.3.0

Remove 'update_latest_release.go' so we don't try to build it
since this fails due to unmet dependencies.
AFAICT this utility is only meant for developer use anyway,
and helps manage/create new github releases for the project.
Motivation for this change
Things done

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

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

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

@GrahamcOfBorg build gitAndTools.grv

Success on aarch64-linux (full log)
Attempted: gitAndTools.grv
Partial log (click to expand)
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/igsqp5yafy43bdnq7zswgxglxiwzf8x2-grv-0.3.0-bin
shrinking /nix/store/igsqp5yafy43bdnq7zswgxglxiwzf8x2-grv-0.3.0-bin/bin/grv
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/igsqp5yafy43bdnq7zswgxglxiwzf8x2-grv-0.3.0-bin/bin
patching script interpreter paths in /nix/store/igsqp5yafy43bdnq7zswgxglxiwzf8x2-grv-0.3.0-bin
checking for references to /build in /nix/store/igsqp5yafy43bdnq7zswgxglxiwzf8x2-grv-0.3.0-bin...
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
/nix/store/igsqp5yafy43bdnq7zswgxglxiwzf8x2-grv-0.3.0-bin

Success on x86_64-darwin (full log)
Attempted: gitAndTools.grv
Partial log (click to expand)
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
/nix/store/82lsx3f6qj9cwz06jjjxyd6a7s8fyzvk-grv-0.3.0-bin

Success on x86_64-linux (full log)
Attempted: gitAndTools.grv
Partial log (click to expand)
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin
shrinking /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin/bin/grv
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin/bin
patching script interpreter paths in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin
checking for references to /build in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin...
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
/nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin

@dtzWill can you change the commit message to match the attribute name?

Success on aarch64-linux (full log)
Attempted: gitAndTools.grv
Partial log (click to expand)
/nix/store/igsqp5yafy43bdnq7zswgxglxiwzf8x2-grv-0.3.0-bin

Success on x86_64-darwin (full log)
Attempted: gitAndTools.grv
Partial log (click to expand)
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
find: '/nix/store/q7wfa5xh2qqfkh1p0dqh2rxm8yfi8yvk-grv-0.3.0': No such file or directory
/nix/store/82lsx3f6qj9cwz06jjjxyd6a7s8fyzvk-grv-0.3.0-bin

Success on x86_64-linux (full log)
Attempted: gitAndTools.grv
Partial log (click to expand)
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin
shrinking /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin/bin/grv
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin/bin
patching script interpreter paths in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin
checking for references to /build in /nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin...
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
/nix/store/h7m2nw96frg7ccsrkxz3azp4y2cj7kqc-grv-0.3.0-bin


diff-quality plugins should support "--options" and report files

In the current version of diff-cover (7.2.0), the diff-quality tool does not pass --options and report_files to external plugins.
I have a fix for this and will create a PR.

https://pypi.org/project/diff-cover/7.3.0/

Thanks!!


color code on releases page (could be extended to other pages as well)

currently code on the releases page renders like this:

some color should highlight the code blocks to make it more legible. I'm using #a00 as an example, but we can discuss what would be the best representation.

additionally, something like this should extend to <tt> tags, as we do have that being used as well with only default styling:

Yes this can be improved

@joaquintides suggested I match how it's done with github. I'm in favor of this, and would like to know if there are any objections. It would appear as below:

I had a brief discussion with @vinniefalco on this, and he's not a fan of the background color as it distorts the alignment of the text do to the padding of the background color. His suggestion was a more subtle color difference.

Personally I'd like to see a difference between links and non-links as well and would prefer the above color as a link color.

@joaquintides suggested I match how it's done with github. I'm in favor of this, and would like to know if there are any objections.

I think it looks terrible, as the amount of attention it demands from the user is not in proportion to the information it provides when it is not a hyperlink. Using a visually distinct, monospaced font is sufficient.
Hyperlinks on the other hand, should be set apart in color. If the text also reflects a C++ identifier, then it should be in monospace type. No underline, except on hover. And visited links should use the same color as unvisited links, as these tend to appear many times on a page and do not represent an informational hierarchy.


Validation for parameters that can be numeric or string

This fixes issue #717
as /script/cfn2py converts some values to integers that are considered strings in AWS, this validation allows numerics or strings to be defined for a parameter, thus preventing a validation exception being thrown when either would be a valid form.

@markpeek looks like this change has broken the CI tests..

My apologies, I wasn't thinking about the other default types. This can still be done but will require adding the logic into the validate method as the type needs to be available to correctly validate and coerce the value. It might be a little tricky with allowing string, int, and float values. Plus needing to add tests. Feel free to take a stab or I'm happy to implement it over the weekend.

Closing as I have a different implementation to push which addresses this issue.


Update to Tailwind 1.4.0 and implement native Tailwind PurgeCSS

With the release of Tailwind 1.4.0 the framework comes with native PurgeCSS funcionality. In an effort to make this boilerplate simpler and to reduce the amount of dependencies I think it is a good idea to implement it.
I am opening this PR in order to work on this change. As of now it is not working and I would appreciate help in where it could be improved.
Thanks!

Seems to work with latest commit, but should be tested properly before merge.

Right, so now it works with NODE_ENV explicitly set to 'production' locally. However, this does not seem to play well with Netlify as  it won't install the dependencies there if I set the NODE_ENV manually.

You can set the NODE_ENV in your netlify.toml file, though we do our production builds locally and push that to Netlify.

Yes, that is what I did, but then netlify doesn't install devDependencies. Perhaps I am missing something here.

That's expected behavior. They will only install "dependencies" in production, not "devDependencies," which is the normal separation for them.

https://docs.netlify.com/configure-builds/manage-dependencies/#node-js-environment

Right, that is what I tried to point out. Now the dependencies are configured as devDependencies
, and to be able to make the build run properly on netlify they should also be in dependencies – or am I mistaken here?

Oh, yes. That's right. We should move the current DevDependencies to Dependencies. If you want to do it as part of this PR, that's fine, or I can do it after.
Just FYI, at my firm we're using Hugo PostProcess instead of this. When I get time I'll make note of it here wherever that may be appropriate.

I see. I saw that it was released in the last major version of Hugo but I haven't had the chance to test it yet. What are the immediate advantages?

If you ever use classes via a variable, it makes it so you don't have to whitelist them because it scans output for classes/IDs. I think it's pretty solid and should reduce errors.

Yes, that is definitely a disadvantage of the current setup. I guess it should be possible to implement it here.
I also wanted to take a shot at changing the JS pipeline with the new babel transpiler that came with 0.70.

Should be fine to merge now, but feel free to review.

Looks good. Thanks!

Just came across this repo tonight. Wanted to say thank you for pointing to Hugo's PostProcess. I too use TailwindCSS built-in purgecss (without any problems), and build the site locally before deploying to Netlify. All with Docker and GitHub Actions. :)
Also, wanted to point out that dev/postcss.config.js  should not be required anymore.


Update create-a-full-database-backup-sql-server.md

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

Looks correct; we'll merge the PR.


application_plattform.register(), with BotoServerError

Additional help is needed...
While this command is executed: application_plattform.register(),
I am getting this error:
Exception Type: BotoServerError
Exception Value:
BotoServerError: 400 Bad Request
{"Error":{"Code":"InvalidParameter","Message":"Invalid parameter: PlatformPrincipal not valid.","Type":"Sender"},"RequestId":"d027b359-0dd4-5296-9dd9-fe748596113c"}
Exception Location: C:\Python27\lib\site-packages\boto\sns\connection.py in _make_request, line 765
Any idea?
Thanks

Several things could cause this:

Did you specify SCARFACE_APNS_CERTIFICATE and SCARFACE_APNS_PRIVATE_KEY in your settings (also see the extract_keys command as documented: http://django-scarface.readthedocs.org/)
When SCARFACE_APNS_MODE =  u"APNS_SANDBOX", is the certificate/private key from the sandbox enviromnent?

best wishes,
phil

Yes, i did all of these. Can it be something with boto?
ב-12 בינו׳ 2015, בשעה 12:29, Philipp Läubli<EMAIL_ADDRESS>כתב/ה:

Several things could cause this:
Did you specify SCARFACE_APNS_CERTIFICATE and SCARFACE_APNS_PRIVATE_KEY in your settings (also see the extract_keys command as documented: http://django-scarface.readthedocs.org/)
When SCARFACE_APNS_MODE = u"APNS_SANDBOX", is the certificate/private key from the sandbox enviromnent?
best wishes,
phil
—
Reply to this email directly or view it on GitHub.

Maybe the AWS Credentials (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY) are invalid or do not have the permission to create an sns application or endpoint?
This example access-policy for your aws user should work:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "<SOME VALUE> ",
      "Effect": "Allow",
      "Action": [
        "sns:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

Any luck with this?

No I already checked it...
ב-12 בינו׳ 2015, בשעה 12:56, Philipp Läubli<EMAIL_ADDRESS>כתב/ה:

Maybe the AWS Credentials (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY) are invalid or do not have the permission to create an sns application or endpoint?
This example access-policy for your aws user should work:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": " ",
"Effect": "Allow",
"Action": [
"sns:"
],
"Resource": [
""
]
}
]
}
Any luck with this?
—
Reply to this email directly or view it on GitHub.

Hmmm.. tried to reproduce the error and I only get that error when the SCARFACE_APNS_CERTIFICATE/SCARFACE_APNS_PRIVATE_KEY are not correctly set. For reference the settings must look like this:

Thanks a lot. Sorry for my late response…
my variables looks similar except for the u”xxxx…”. (what this u”… “ for?)
also, I set the (SCARFACE_LOGGING_ENABLED = True), to “True” and you have “false”.
Thanks again
Uzi Lumbroso
P Please consider the environment before printing this email
From: Philipp Läubli<EMAIL_ADDRESS>Sent: Monday, January 12, 2015 6:32 PM
To: dreipol/django-scarface
Cc: Dealers
Subject: Re: [django-scarface] application_plattform.register(), with BotoServerError (#2)
Hmmm.. tried to reproduce the error and I only get that error when the SCARFACE_APNS_CERTIFICATE/SCARFACE_APNS_PRIVATE_KEY are not correctly set. For reference the settings must look like this:
https://cloud.githubusercontent.com/assets/196704/5706394/def56182-9a80-11e4-9800-c1f37852ca49.png local_py_-django-scarface-___documents_repositories_django-scarface
—
Reply to this email directly or view it on GitHub https://github.com/dreipol/django-scarface/issues/2#issuecomment-69598292 .  https://github.com/notifications/beacon/AFtSy5HwhD-D0IP4slMHO7mOSVxP7aVfks5ng-59gaJpZM4DRCtW.gif

The SCARFACE_LOGGING_ENABLED setting should not be the reason for your troubles. the u'xxx' this is just a way to declare a unicode string, see https://docs.python.org/2/howto/unicode.html and shouldn't be the problem either.
Are you working in the apns sandbox or using a production environment? Does the problem only occur with apns?

and: have you tried to create the sns application directly in the AWS web console?

Yes and it is working. The only differences with your example is :
my variables looks similar except for the u”xxxx…”. (what this u”… “ for?)
also, I set the (SCARFACE_LOGGING_ENABLED = True), to “True” and you have “false”.
Regards
Uzi Lumbroso
M +972-52-3330506
F  +972-9-7710184
<EMAIL_ADDRESS>Skype: uzport
Logo_(full).png
http://www.dealers-app.com www.dealers-app.com
The information contained in this document is proprietary of Dealers©. It contains confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware  that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this document or communication in error, please return it to Dealers© and delete it from your computer. Thank you.
P Please consider the environment before printing this email
From: Philipp Läubli<EMAIL_ADDRESS>Sent: Monday, January 12, 2015 7:07 PM
To: dreipol/django-scarface
Cc: Dealers
Subject: Re: [django-scarface] application_plattform.register(), with BotoServerError (#2)
and: have you tried to create the sns application directly in the AWS web console?
—
Reply to this email directly or view it on GitHub https://github.com/dreipol/django-scarface/issues/2#issuecomment-69604985 .  https://github.com/notifications/beacon/AFtSyz9h8quWCwtp-RwU9DCpJeBv4jtNks5ng_argaJpZM4DRCtW.gif

Yes, we are using the apns sandbox only right now so the problem only occur only with apns? If I use the Amazon SNS Dashboard it works OK with the same parameters.
Regards
Uzi Lumbroso
M +972-52-3330506
F  +972-9-7710184
<EMAIL_ADDRESS>Skype: uzport
Logo_(full).png
http://www.dealers-app.com www.dealers-app.com
The information contained in this document is proprietary of Dealers©. It contains confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware  that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this document or communication in error, please return it to Dealers© and delete it from your computer. Thank you.
P Please consider the environment before printing this email
From: Philipp Läubli<EMAIL_ADDRESS>Sent: Monday, January 12, 2015 7:06 PM
To: dreipol/django-scarface
Cc: Dealers
Subject: Re: [django-scarface] application_plattform.register(), with BotoServerError (#2)
The SCARFACE_LOGGING_ENABLED setting should not be the reason for your troubles. the u'xxx' this is just a way to declare a unicode string, see https://docs.python.org/2/howto/unicode.html and shouldn't be the problem either.
Are you working in the apns sandbox or using a production environment? Does the problem only occur with apns?
—
Reply to this email directly or view it on GitHub https://github.com/dreipol/django-scarface/issues/2#issuecomment-69604787 .  https://github.com/notifications/beacon/AFtSy4rwdiDfKIe8DEiQpMZMuBV42P6Nks5ng_ZngaJpZM4DRCtW.gif

hmm... i can't really imagine any other solution at the moment. If you want you can email me your settings and i can try to reproduce the error (you may want to replace the aws user you are using and generate a new certificate). you can send me a mail to<EMAIL_ADDRESS>

Thanks Philipp. I will try few things and may send you my settings so you can try to reproduce
Regards
Uzi Lumbroso
M +972-52-3330506
F  +972-9-7710184
<EMAIL_ADDRESS>Skype: uzport
Logo_(full).png
http://www.dealers-app.com www.dealers-app.com
The information contained in this document is proprietary of Dealers©. It contains confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware  that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this document or communication in error, please return it to Dealers© and delete it from your computer. Thank you.
P Please consider the environment before printing this email
From: Philipp Läubli<EMAIL_ADDRESS>Sent: Monday, January 12, 2015 7:32 PM
To: dreipol/django-scarface
Cc: Dealers
Subject: Re: [django-scarface] application_plattform.register(), with BotoServerError (#2)
hmm... i can't really imagine any other solution at the moment. If you want you can email me your settings and i can try to reproduce the error (you may want to replace the aws user you are using and generate a new certificate). you can send me a mail to<EMAIL_ADDRESS>—
Reply to this email directly or view it on GitHub https://github.com/dreipol/django-scarface/issues/2#issuecomment-69609289 .  https://github.com/notifications/beacon/AFtSy9AvYnGVdhH1hkxCzRIoB8_SrbDtks5ng_yCgaJpZM4DRCtW.gif

Hi Philip
I sent an email to<EMAIL_ADDRESS><EMAIL_ADDRESS> With my setting info
Regards
Uzi
From: Philipp Läubli<EMAIL_ADDRESS>Sent: Monday, January 12, 2015 7:32 PM
To: dreipol/django-scarface
Cc: Dealers
Subject: Re: [django-scarface] application_plattform.register(), with BotoServerError (#2)
hmm... i can't really imagine any other solution at the moment. If you want you can email me your settings and i can try to reproduce the error (you may want to replace the aws user you are using and generate a new certificate). you can send me a mail to<EMAIL_ADDRESS>—
Reply to this email directly or view it on GitHub https://github.com/dreipol/django-scarface/issues/2#issuecomment-69609289 .  https://github.com/notifications/beacon/AFtSy9AvYnGVdhH1hkxCzRIoB8_SrbDtks5ng_yCgaJpZM4DRCtW.gif

I'll close this issue. If it isn't solved, please reopen.


Update root files urls for github workflows

The automated tests with the git hub workflows are not working, because the files with the root packages disappeared from the website. Updating the run scheme with the newest root versions available on the downloads page.

The configuration for ubuntu 22 and 20 worked, the job for ubuntu 18 just won't start. I have tried several times, always with the message "waiting for the runner to pick up the job".


Add extensions to NSTimeInterval to convert to different time units

To be able to find out the time between two NSDate instances I thought it would be nice to extend NSTimeInterval with some calculated properties that convert it into different units.
E.g.
let interval: NSTimeInterval = 60.0
let minutes = interval.minutes
print(minutes) // prints 1.0

This also allows to check how much time there was between to NSDates.
let now = NSDate()
let someTimeAgo = 4.hours.ago
let hourDifference = now.timeIntervalSinceDate(someTimeAgo).hours
print(hourDifference) // prints 4.0

Can you make a PR to develop (not master)?
Thanks.


Rviz not opening

I didn't have any problems until now opening Rviz, however, when trying to open it now I get the following traceback and it just stays like this:

I get this after typing in a cmd run as administrator the following sequence:
c:\opt\ros\foxy\x64\setup.bat
c:\opt\ros\foxy\x64\share\gazebo\setup.bat
set "SDF_PATH=c:\opt\ros\foxy\x64\share\sdformat\1.6"
cd c:\nav2_ws
install\setup.bat
set GAZEBO_MODEL_PATH=C:\nav2_ws\install\turtlebot3_gazebo\share\turtlebot3_gazebo\models;%GAZEBO_MODEL_PATH%
set TURTLEBOT3_MODEL=waffle
ros2 launch turtlebot3_navigation2 navigation2.launch.py map:=c:\nav2_ws\map.yaml
Athough with that same sequence but changing the last line for ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py I had no problems launching gazebo.
I tried deleting and installing everything again (ros2 and nav2 according to your tutorials) but it keeps like this.
I also tried following this shorter sequence, but the output is the same:
cd c:\nav2_ws
install\setup.bat
set GAZEBO_MODEL_PATH=C:\nav2_ws\install\turtlebot3_gazebo\share\turtlebot3_gazebo\models;%GAZEBO_MODEL_PATH%
set TURTLEBOT3_MODEL=waffle
ros2 launch turtlebot3_navigation2 navigation2.launch.py map:=c:\nav2_ws\map.yaml
Moreover I tried just to launch rviz with ros2 run rviz2 rviz2 and it does start:

Any idea if I am doing something wrong?

In the chocolatey package rviz2.exe is included twice - once in foxy\x64\bin and once in foxy\x64\Lib. Running from Bin (the path) causes rviz2 to fail due to linker issues. running from lib works as expected.
Which is weird.
Workaround is to delete the rviz2.exe in the bin directory. I'll root cause.


Make repository generic

This will simplify addition of further repositories, as they should all share very similar checks and code.

Nope, apparently there's no easy way (at least, one that I've found) to share the implementation details like that. The closest we can get is a shared interface, but that's not perfect either since delete(Identifier id) is hardly informative when the Identifier might be a Coordinate.
If you find a way to do so, please let me know.


Hovmuller plots of subset in time drawn in wrong location

Martin Schmidt reported this. It seems to be related to the issue in #1009.
Define a variable with a 5-month axis, timesteps every 3 hours in units of seconds.  A FILL plot of the full range is fine. Am subset of the last 3 and a half months shows the correct data, but it's shifted over to left of the plot window.
yes? define axis/t=1-mar-2012:1-aug-2012:10800/units=seconds/t0=1-mar-2012 t3hour
yes? define axis/y=1:30:1/units=degrees_north yaxis
yes? let ytvar = y[gy=yaxis] * cos(L[gt=t3hour]/200) +0.1*L[gt=t3hour]

yes? set v upper; fill/pal=pale_green_blue_rev ytvar
yes? set v lower; fill/pal=pale_green_blue_rev/lev/l=400:1224 ytvar

The plot is attached.
SHADE plots work correctly.

Closing this. It was fixed in axis_format.F, and that change with its tests was checked in on 7/27/18


allow newer paper-fab and iron-component-page versions

With this change to Polymer 1.0, Bower requires many resolutions.  I upped the versions to 1.0 because I was getting lots of resolutions when using the 1.0 Polymer elements. To be honest I'm a bit confused by how the versioning works. Is ^0.9 supposed to mean anything above 0.9 but less than 1.0, or anything above 0.9?

The former, ^0.9 resolves anything >= 0.9.x and < 1.0.0.
I found the documentation on versioning (Bower uses semver).
I'm glad you brought this up, the caret range was actually causing all the manual resolutions. I just made a commit that fixes the resolutions.


add support for CREATE TEMPORARY TABLE

What problem does this PR solve?
Add support for CREATE TEMPORARY TABLE #408
What is changed and how it works?
MySQL syntax:
create_table_stmt:
          CREATE opt_temporary TABLE_SYM opt_if_not_exists table_ident
          '(' table_element_list ')' opt_create_table_options_etc
        | CREATE opt_temporary TABLE_SYM opt_if_not_exists table_ident
          opt_create_table_options_etc

Check List
Tests

Unit test

@leiysky TiDB does not support TEMPORARY tables. Would you please add a warning in the parser for both CreateTableStmt and DropTableStmt?

@tangenta PTAL

@leoppro PTAL


docs: cleanup apis

Cleanup API documentations.

@mzeevi @fran2810 Please add comments if we're missing something in the docs, or if there is something wrong (e.g. typos). Let's have clean and detail documentation :)

/approve


Adds reqs to montage.sub to run on SL6 and make montage.sub same across exercises

(ATTN @lmichael107 )
Also fixes minor typos (s/USERAME/USERNAME/) and minor formatting weirdness.
/usr/bin/montage has problems with libs on CentOS7. We should fix this for next year when the pool should be running ~100% CentOS7.

I think there's still some unaligned spaces, you can see them directly on your branch in github:

https://github.com/jasoncpatton/user-school-2018/blob/8bc023284dcd67e621d5f7c35934a28f34fb3a5b/docs/materials/day1/part4-ex3-complex-dag.md
https://github.com/jasoncpatton/user-school-2018/blob/8bc023284dcd67e621d5f7c35934a28f34fb3a5b/docs/materials/day1/part4-ex4-failed-dag.md

More alignment done in https://github.com/opensciencegrid/user-school-2018/pull/57/commits/d27f848360bf7291424c7cf5df5bd29e9e75b643 , also fixed another montage.sub to match previous montage.sub


positive regulation of mating projection assembly (GO:1902917) parentage

positive regulation of mating projection assembly (GO:1902917)
could a part_of link be added to conjugation with cellular fusion?
Currently annotations are not propagating (because they do not propagate over regulation of regulation)

These two terms are already connected in the hierarchy.
Shouldn't we fix this problem in AmiGO closure as opposed to adding 'by-pass' in the ontology?

In AmiGO, the Inferred Tree View shows an open square (I don't know what it means) for the relationship between "positive regulation of mating projection assembly" and "conjugation with cellular fusion"; part_of it is not. Similarly between "regulation of mating projection assembly" and "conjugation with cellular fusion"; the relation chain is regulate->part_of->part_of.
I am confused with all these relations myself.

@pgaudet  do you agree that, if you regulate a sub part of a process you don't necessarily regulate the whole process. People who study conjugation would expect that "regulation of conjugation with cellular fusion" would be the genes that start or stop the process from occurring. I think this issue has been discussed  in other contexts but I'm not sure if a definite decision was made. Is it OK to remove the inappropriate "regulation of" links and instantiate part of links in these cases?

"regulation of mating projection assembly part_of conjugation with cellular fusion"
is what's being added.

@pgaudet do you agree that, if you regulate a sub part of a process you don't necessarily regulate the whole process.

Hi @ValWood
No, this is not how the relations inferences work. If you regulate part_of a process, you regulate the process. This seems right - if a step of a subprocess is rate limiting the entire process will be slowed down, won't it?
I am not sure what you are trying to capture.

I think this is a general issue with GTPases and their regulators.
Here is an example
cdc42 is regulating the assembly of the mating projection tip
https://www.pombase.org/reference/PMID:23200991
as part of the overall program of "conjugation with cellular fusion".
Users would definitely expect to  find cdc42 in the "conjugation with cellular fusion" bin for slimming and enrichment. Currently it would  not be there because it is regulating a sub process..
Some historical discussion implied that a gene product could be both regulating a process and part_of a process simultaneously.
More recent discussions   suggested that GTPases should sometimes be annotated as
molecular function regulators and part_of processes.
I am not sure if this is the correct  way to annotate because most GTPases are not annotated in this way.
I was hoping we could look at examples of GTPase annotations  on an annotation call.

If you annotate to MF regulator activity then this will not be transitive. We need to think carefully about how we model this, there is probably some inconsistency that leads to missing/unexpected inferences. I think making a GO-CAM would help.

I think you are right. I don't even know if we have enough information yet to annotate all of the conjugation steps. I think both the annotations and the ontology need review (I won't have time to do this for a while)
@raymond91125  apologies, could you remove the relation I suggested?
Then you  can assign the ticket to me as a mini project.

I closed the PR without merging.


Cannot run app locally - parseQuery() error

Hey! I cant seem to get the app running. I keep getting this error:

There doesn't seem to be a parseQuery method in client.js. I've got the latest changes from development and did an npm i.
OS: Windows 10
Node: 7.0.0
NPM: 3.10.8

Can you please try to upgrade to node 7.2.1  ?
De: Akira Laine<EMAIL_ADDRESS>Responder para: FreeCodeCamp/LetsMeet<EMAIL_ADDRESS>Data: sexta-feira, 30 de dezembro de 2016 00:52
Para: FreeCodeCamp/LetsMeet<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Assunto: [FreeCodeCamp/LetsMeet] Cannot run app locally - parseString() error (#115)
Hey! I cant seem to get the app running. I keep getting this error:
[mage]https://cloud.githubusercontent.com/assets/11958359/21558955/dbb36310-ce96-11e6-9109-2d76b3ceea48.png
There doesn't seem to be a parseString method in client.js. I've got the latest changes from development and did an npm i.
OS: Windows 10
Node: 7.0.0
NPM: 3.10.8
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/FreeCodeCamp/LetsMeet/issues/115, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQmXTjRtXXWLTzYhEDiIQhGV80sNLawQks5rNHHkgaJpZM4LX-OX.

Tried 7.2.1 & 7.3.0 - same result.

Here and at herohu its working... So if was possible send me the build  log ?
I will test at win 10
De: Akira Laine<EMAIL_ADDRESS>Responder para: FreeCodeCamp/LetsMeet<EMAIL_ADDRESS>Data: sexta-feira, 30 de dezembro de 2016 01:51
Para: FreeCodeCamp/LetsMeet<EMAIL_ADDRESS>Cc: Jean Philip de Rogatis<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Assunto: Re: [FreeCodeCamp/LetsMeet] Cannot run app locally - parseQuery() error (#115)
Tried 7.2.1 & 7.3.0 - same result.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/FreeCodeCamp/LetsMeet/issues/115#issuecomment-269729075, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQmXTlqiQsglzwwy7Y5yJgge1Zmd-lCCks5rNH-ngaJpZM4LX-OX.

The only error i got is the one above. What do you mean by build logs?

Working on macOS 10.12.2 for me here.

Did some digging, got it to work.
babel-loader seemed to have been using a non-compatible version of loader-utils w/ Webpack 2.
npm i loader-utils did the trick 😄


Update mongo support windows

https://www.mongodb.com/support-policy

I applied this change in commit ef7b312de568fb2aef2e081ccb52dd33871a6611


Add improved error messages and use strict unmarshaling of data

Fixes https://github.com/projectcalico/libcalico-go/issues/230
Fixes https://github.com/projectcalico/libcalico-go/issues/248
This PR relies on forks of three other libraries, these forks provide improved error details, swap Float32 with Float64 support, strict validation of unexpected fields.   Please also see the following PRs:
https://github.com/projectcalico/go-yaml/pull/1
https://github.com/projectcalico/go-yaml-wrapper/pull/1

This LGTM.


Tradfri dependencies not installed in docker container

Home Assistant release (hass --version):
0.57.1
docker containter: docker.io/homeassistant/home-assistant                0.57.1              5444bcc80f82
Python release (python3 --version):
Python 3.6.3
Component/platform:
Tradfri
Description of problem:
Starting from the default config, the gateway is discovered, but when trying to configure the security code, I get the backtrace below.
Expected:
Work as expected
Problem-relevant configuration.yaml entries and steps to reproduce:

Empty configuration using docker container
Wait for discovery component to find the gateway (probably reproducible by setting the IP too)
Try to configure the security code
Backtrace fun! ;)

Traceback (if applicable):
2017-11-05 16:18:17 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=configurator, service=configure, service_data=configure_id=140311349316968-1, fields=key=AQT0xbJrkTMgsgEu, service_call_id=140312263957752-4>
2017-11-05 16:18:17 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]: service_call_id=140312263957752-4>
2017-11-05 16:18:17 ERROR (MainThread) [homeassistant.components.tradfri] Looks like something isn't installed!
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/components/tradfri.py", line 60, in configuration_callback
    from pytradfri.api.aiocoap_api import APIFactory
  File "/usr/local/lib/python3.6/site-packages/pytradfri/api/aiocoap_api.py", line 6, in <module>
    from aiocoap import Message, Context
ModuleNotFoundError: No module named 'aiocoap'

Manually adding the dependencies fixes the issue:
sudo docker exec <ID> pip install DTLSSocket==0.1.4
sudo docker exec <ID> pip install https://github.com/chrysn/aiocoap/archive/3286f48f0b949901c8b5c04c0719dc54ab63d431.zip

I don't know much about docker. Is autoconf package available in the container.

I suspect this is introduced by #9875 which comments out the two missing dependencies (the PR contains a discussion wrt these deps)
@MartinHjelmare autoconf is available in the docker container

Ahh, yes, I think we should add a docker script back for coap install where it just installs the two tradfri requirements that are commented in requirements_all.txt.

@MartinHjelmare yeah, alternatively just install cython and let HA install the dependency itself?

Duplicate of #10048

@lwis I think that's what's failing now. I'm not a docker wiz, but I thought that installing deps during run time doesn't work in docker, and that's why all deps in requirements_all.txt are installed before starting home assistant.

Ok, I just wanted to avoid us having to maintain those dependency versions.

Tried to install those packages
sudo docker exec <ID> pip install DTLSSocket==0.1.4
sudo docker exec <ID> pip install https://github.com/chrysn/aiocoap/archive/3286f48f0b949901c8b5c04c0719dc54ab63d431.zip

in 0.59 docker without success.

I have the dependency problem running in Docker with version 0.63.3. pytradfri is missing. I noticed the dependencies are located in /config/deps/lib/python3.6/site-packages/, but they are obviously not loaded. I scrolled through the code and found this bit in requirements.py
if not pkg_util.running_under_virtualenv():
        kwargs['target'] = os.path.join(config_dir, 'deps')

Looks like that has to define the /config/deps. Is there something going wrong with the detection of this virtualenv?
For me a workaround to get it to work was running this inside the docker image:
cp -R /config/deps/lib/python3.6/site-packages/* /usr/local/lib/python3.6/site-packages

Docker install is not using a virtual environment. All requirements besides the commented ones are installed before home assistant is started.
I'm not sure if installing requirements during runtime as home assistant normally does works for docker.

https://github.com/home-assistant/home-assistant/pull/12662 should close this, pending builds.


Added info for installation & syntax highlighting

Fixes #15

Guess we can close this then haha

@brunomperes I've just updated README as well - included the Installation paragraph. Could you please adjust your PR? Thanks!


WD_BUILTIN_STYLE gives no style with name

Starting from the minimal code given at https://python-docx.readthedocs.io/en/stable/api/enum/WdBuiltinStyle.html
from docx import Document
from docx.enum.style import WD_STYLE

document = Document()
styles = document.styles
style = styles[WD_STYLE.BODY_TEXT]

gives the following error:
KeyError: "no style with name 'BODY_TEXT (-67)'"

I'm sure I'm doing something wrong, but if you know of a way I can fix this, I'd be very grateful. Thank you for your time!

Not all documents will have all styles defined. A good next step might be to list out the styles in the current document with something like:
for style in document.styles:
    print(style.name)

It could also be that documentation is out of date, you might try styles["Body Text"] or styles["BodyText"]. I believe we changed from looking up by WD_STYLE member to style.name a while back.


Slow builds caused by JavaCompileTask in incremental mode

Current Behavior
Some Java compile task in our build are taking minutes due to the creation of Classpath snapshot:
Created classpath snapshot for incremental compilation in 4 mins 56.161 secs.
Disabling the incremental mode of the task reduces the tasks time to under 1 minute.
Looking at the debug logs it seems that it is creating snapshots of all external dependency jars, including some big dependencies that take several minutes to process.
[2023-08-02T16:52:49Z] 2023-08-02T16:52:49.138+0000 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Create incremental compile snapshot for /root/.gradle/caches/modules-2/files-2.1/com.amazonaws/aws-java-sdk-bundle/1.12.262/2deec3a0ad83d13d032b1812421b23d7a961eea/aws-java-sdk-bundle-1.12.262.jar' started
....
[2023-08-02T16:54:55Z] 2023-08-02T16:54:55.891+0000 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Completing Build operation 'Create incremental compile snapshot for /root/.gradle/caches/modules-2/files-2.1/com.amazonaws/aws-java-sdk-bundle/1.12.262/2deec3a0ad83d13d032b1812421b23d7a961eea/aws-java-sdk-bundle-1.12.262.jar'
[2023-08-02T16:54:55Z] 2023-08-02T16:54:55.891+0000 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Create incremental compile snapshot for /root/.gradle/caches/modules-2/files-2.1/com.amazonaws/aws-java-sdk-bundle/1.12.262/2deec3a0ad83d13d032b1812421b23d7a961eea/aws-java-sdk-bundle-1.12.262.jar' completed
[2023-08-02T16:54:55Z] 2023-08-02T16:54:55.891+0000 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Completing Build operation 'Create incremental compile snapshot for /root/.gradle/caches/modules-2/files-2.1/com.amazonaws/aws-java-sdk-bundle/1.12.262/2deec3a0ad83d13d032b1812421b23d7a961eea/aws-java-sdk-bundle-1.12.262.jar'
[2023-08-02T16:54:55Z] 2023-08-02T16:54:55.891+0000 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Create incremental compile snapshot for /root/.gradle/caches/modules-2/files-2.1/com.amazonaws/aws-java-sdk-bundle/1.12.262/2deec3a0ad83d13d032b1812421b23d7a961eea/aws-java-sdk-bundle-1.12.262.jar' completed

Expected Behavior
Java Compilation task in incremental mode can be a bit slower than regular but still be performant.
Dependencies already have hashes, there is no need to rehash the files.
Context (optional)
We recently started using Gradle Enterprise for caching and build scans in our CI and detected that with minor code changes the builds were taking a lot to complete.
We run our CI builds on docker images with a base image being the last master build, running the PR build on top of that image (with local caching, remote caching, and parallelization to true).
The issue has been reproduced in 8.1.1 and 8.2.1
Steps to Reproduce
I don't have a minimal reproducible build at this point, if needed I can work on it tomorrow.
Gradle version
8.2.1
Build scan URL (optional)
No response
Your Environment (optional)
Build Cache | On |
-- | -- | --
Build output capturing | On |
Daemon | On |
File system watching | On |
Parallel | On |
Task inputs file capturing | On |
Test output capturing | On |
Background build scan publication | Off |
Configuration Cache | Off |
Configure on demand | Off |
Continue on failure | Off |
Continuous | Off |
Dry run | Off |
Offline | Off |
Re-run tasks | Off |
Refresh dependencies | Off |
Operating system | Linux 5.10.135-122.509.amzn2.x86_64 (amd64) |
-- | -- | --
CPU cores | 8 cores |
Max Gradle workers | 8 workers |
Java runtime | AdoptOpenJDK OpenJDK Runtime Environment 11.0.7+10 |
Java VM | AdoptOpenJDK OpenJDK 64-Bit Server VM 11.0.7+10 (mixed mode, sharing) |
Max JVM memory heap size | 2 GiB |
Locale | English |
Default charset | UTF-8 |
Username | root |
Public hostname | 8bae70d52cc6 |
Local hostname | 8bae70d52cc6 |
Local IP addresses | <IP_ADDRESS>
Started today at 21:00:17 CEST, finished today at 21:14:46 CEST
Gradle 8.2.1, Gradle Enterprise plugin 3.14.1
If there is anyway to provide full logs in a non public way I can share the full log (I can do the same with the build scan if there is any way to export it from our GE).

I am trying to reproduce the problem with a minimal project and I am unable to do it, even with my main project disabling the gradle cache and cleaning the JavaCompile previous compilations files I get at worst a couple of seconds to build the snapshot.
So I assume that we may be hitting some limit in CI that gets us into degraded performance only with the Java incremental compile enabled that we are not hitting locally.
Memory seems to be fine if the info in the build scan is correct as it peaks at 60%, maybe filedescriptors, threads?
I am not really sure where to look at this point.
Again, I can share full debug logs if needed (they are about 300Mb) and may be able to share a public build profile if you wish.

Thank you for providing a valid report and sending the files.
The issue is in the backlog of the relevant team, but this area of Gradle is currently not a focus one, so it might take a while before a fix is made.

It would take some time for us to investigate this. This is not the first time we get a report like this, but we couldn't track the root cause.
 Which ones?

So our current pipelines do not expose anything from the build to the CI agent, we do create a docker image in each master build that is considered a "cache" image, that runs ./gradlew assemble --no-daemon.
That image is then used as a base image for the PR runs so the code gets updated and then we run ./gradlew assemble buildFatJar --no-daemon
I have not analyzed the first image "cache" builds so I am not sure if the same problem is happening there, we have detected the issue in the second build, with the Gradle build, dependencies, and java compile caches hot.
In theory, all the caches should be preserved.
To add more info the base image for the "cache" is an Ubuntu 22.04 with Adopt OpenJDK 11.0.7 and we set the Gradle Home to /opt/gradle
I will need to confirm, but if needed, it may be possible to provide you a docker image reproducing the issue, using non-public channels.


stop it logging the whole conf file every time

In the frontend root test run, before many tests we get a huge file logged.  Not sure if I should have just stripped back or reduced the log level of the log line, but I'll go for a complete removal for now.
@rich-nguyen I assume this is the log spam you weren't keen on?

It is, yes. I think it's useful in Prod, and possibly Dev, but not so much in Test. Maybe it should be configurable.

@johnduffell Can we get this released? Or at least change it so that it can be set. It's blocking my travis work because it's printing out all my private keys!
:+1: :smile:

@janua someone told me a good reason why it wasn't that simple, but I forgot what it is

@johnduffell @rich-nguyen How does that look now? Planning on using the NonLoggingConfigurationFactory in frontend.

good, looks like a lot of code though for something so simple conceptually.  I assume we couldn't just have it as a boolean parameter to pass in? If not then apart from that :+1:

It is a boolean parameter, kind of. Except you override it. I don't want to break anyone else's code.
The code really is just def log(...)....
The rest is boilerplate.

@johnduffell See commit...

yay! I'm super happy now :joy: :grinning: :gift: :tada: :dancers: :+1:

I just couldn't leave it :joy:

:+1: let's publish this!


Add rudimentary support for __float128

This adds __float128 as a builtin type, and generates an opaque array
of 16 u8s to represent it in the generated bindings since Rust doesn't
have an f128 type.
Context and motivation: Somehow __float128 is getting pulled into
SpiderMonkey headers from somewhere, and the lack of __float128
support was causing bindgen to hard fail in bindings generation.
r? @emilio

Would it make sense to introduce a fake Rust f128_standin newtype, so that if people come across this, they might be less mystified to find [u8; 16]?

Would it make sense ...

Perhaps! Depends how easy it is to add newtypes to a prelude before the generated bindings are created. I am least familiar with codegen so far, so I will let @emilio fill in the gaps (and point me in the right direction if we want to do this).

@emilio fixed per the review comments.

Well, the LastBuiltin value isn't changed, but we don't use it so I don't think it matters a lot. Thanks for doing this! :)

@bors-servo r+

:pushpin: Commit 5e67ceb has been approved by emilio

:hourglass: Testing commit 5e67ceb with merge 6a2ee60...

Well, the LastBuiltin value isn't changed, but we don't use it so I don't think it matters a lot. Thanks for doing this! :)

That is for loops iterating over all types, and is supposed to be the same as CXType_Float128. I suspect CXType_Float128 just got hidden by CXType_LastBuiltin when clangll.rs was originally generated, since we didn't support overlapping enum variants back than.

@bors-servo r-
Could you do that @fitzgen? Should be a minute. Also, maybe using two u64 instead of multiple u16? not a big deal, but would be closer to the real alignment.

@bors-servo delegate+

:v: @fitzgen can now approve this pull request

Also, maybe using two u64 instead of multiple u16? not a big deal, but would be closer to the real alignment.

I originally had it like this, but decided it wasn't actually any better.

@bors-servo r=emilio

:pushpin: Commit 5e67ceb has been approved by emilio

Bors seems dead, let's try again.

:pushpin: Commit db8dc9a has been approved by emilio

@bors-servo r+

:hourglass: Testing commit db8dc9a with merge e8096ec...

:broken_heart: Test failed - status-travis

Looks like CXType_Float128 is llvm 3.9 only. I'll fix and re-push in a few minutes.

Hmm... So this still builds fine when --features llvm_stable because we just won't ever get a Clang type of kind CXType_Float128 so we have some branches that will never be reached in that case. However, it means that we get (I presume) a CXType_Unexposed or something for the __float128 and the best we can do for it is generate a c_int.
Ideally, we would be able to run certain tests only if we are not --features llvm_stable, but we don't have that infrastructure right now. Nor is adding it economical: we are moving towards the removal of that feature.
Therefore, I'm going to comment the whole test out, and add a FIXME comment for when we remove the llvm_stable feature.

@bors-servo r=emilio

:pushpin: Commit 53f7a50 has been approved by emilio

:hourglass: Testing commit 53f7a50 with merge c2e7f46...

:sunny: Test successful - status-travis


Pp 3629 verify provider deployment

It works - see https://build.ci.pymnt.uk/job/pay-adminusers/view/change-requests/job/PR-205/1/console and search for "deployable":true,"reason":"All verification results are published and successful".

Could you describe in the commit and PR description a bit more about how this works

@oswaldquek happy to merge once you have added a bit more detail to commit message and PR description

@mrlumbu commit message and PR description udpated


Add ASYNC support

Add support for performing crypto operations asynchronously - as per my post to<EMAIL_ADDRESS>

I just pushed a new version to respond to feedback received so far (also rebased against latest master).

Fixed a few issues. Travis is now showing green across all builds :-)

I was trying out this code and observed a problem I wanted to feedback. I tried calling an ECDSA_sign operation using the dasync engine and running 2 simultaneous jobs. The dasync engine obviously does not have async enabled for ecdsa (so I expected it to run 1 job until ASYNC_FINISHED and then run the second job within my loop) but interestingly it is pausing jobs because a hash is done as part of generating some random numbers within ECDSA_sign and the sha1 hash is async enabled in the engine. This in itself works fine but as part of the random number generation the CRYPTO_LOCK_RAND is being got but is not released when the job pauses. This then causes a deadlock when the second job tries to get the CRYPTO_LOCK_RAND. I'm not sure what to suggest as the best way to deal with this scenario.

Added some commits to deal with the rand deadlock problem. @stevelinsell can you check that this resolves the issue in your test code?

Updated to deal with a number of thread-local-storage related issues. In particular this now uses pthreads rather than the less portable "__thread" syntax for the POSIX implementation. Additionally there have been a number of changes to ensure that the thread-local stuff works for statically linked windows.
This has had some API impacts around initialisation and cleanup. ASYNC_init_pool and ASYNC_free_pool have gone. They are replaced by ASYNC_init, ASYNC_init_thread, ASYNC_cleanup_thread and ASYNC_cleanup. Documentation has been updated accordingly.

Are you planning on eventually moving everything over to use standard thread-local storage?

Not quite sure what you mean by "standard thread-local storage". Currently there are two types of thread-local storage in use: pthreads and windows - both are needed. If pull request #451 eventually gets implemented then I will move stuff over to use that instead.

We can get rid of various hash tables that index thread-id -> some state; e.g., ERR_STATE.  Basically all uses of CRYPTO_THREADID and friends.

Right...that's what #451 is about. If that pull request goes ahead then yes, the async stuff will be updated to use it.

That’s what I wanted to hear, thanks.  In my view 451 isn’t ready yet; it does some things wrong.  Maybe I’ll talk with the author.

This has now been merged. Closing.


Support for before_script with arguments

Give before_script ability to accept arguments

Coverage decreased (-0.18%) to 63.28% when pulling 6b0f28e3bac3f88073fdec33a2f3fbea585cd83c on before_script-arguments into 10a29ad736d589ac586da65e96a70cfb1cbfaf4b on master.

Coverage increased (+0.02%) to 63.48% when pulling 0c72732356b27b002f67d8b24c27c08cb6730453 on before_script-arguments into 10a29ad736d589ac586da65e96a70cfb1cbfaf4b on master.

Coverage increased (+0.02%) to 63.48% when pulling a0a5a895afe9f4ee1c5a480f36675d06d8507e9d on before_script-arguments into 10a29ad736d589ac586da65e96a70cfb1cbfaf4b on master.

Coverage increased (+0.02%) to 63.48% when pulling de60a866a4895431e787db0a3e5784d0aad3f284 on before_script-arguments into 10a29ad736d589ac586da65e96a70cfb1cbfaf4b on master.


Intersection Type not merging objects in array properly

Bug Report
🔎 Search Terms
intersection type, intersection type array
🕗 Version & Regression Information

This changed between versions 4.8.4 and 4.9.4
This bug also appears in version 3.5.1, 3.3.3

⏯ Playground Link
Playground link with relevant code
💻 Code
interface Colorful {
  color: string;
}
interface Circle {
  radius: number;
}

type ColorfulCircle = Colorful[] & Circle[];

const test: ColorfulCircle = [{
  color: 'red',
  radius: 2
}]

🙁 Actual behavior
radius field gets type error:  Object literal may only specify known properties, and 'radius' does not exist in type 'Colorful'
It looks like it is treating it as a union type where only one of the fields can exist.
🙂 Expected behavior
I expected the merging of the types to make color and radius accessible (and required) in the  ColorfulCircle type.

ColorfulCircle should be defined as (Colorful & Circle)[].

ColorfulCircle should be defined as (Colorful & Circle)[].

Thanks for replying. That would fix this, but it is a contrived example to show the issue. I can't use that fix in the real issue I'm having.
What I am wondering is if the error I am getting now is a bug introduced in TS 4.9 since that used to work. (and the issue also shows up in two other versions, and then seems to be fixed again)
Looking at specs (though depricated)  it looks like the intended behaviour of the intersection type would be to merge the two types to something like: Array<{color: string, radius: number}>

Duplicate of #41874

Yes, sorry I didn't find that when searching. Will close this one then.

by the way @jcalz, any idea why my code example works on version 4.8, but not 4.9?


Training cost

Thanks for the amazing work, could you open the training cost for each model? such as training GPU times and the least GPU needed.

Hi~
All our experiments use 80G A100

model
params
total bs
lr
GPUs
training time

tokenizer
77M
128
1e-4
8
~2 days

LlamaGen-B
100M
256
1e-4
8
~1 days

LlamaGen-L
300M
256
1e-4
8
~2days

LlamaGen-XL
700M
256
2e-4
8 x 2
~3days

LlamaGen-XXL
1.4B
512
2e-4
8 x 4
~4days

LlamaGen-3B
3.1B
512
2e-4
8 x 4
~5days

do you have numbers for the conditional generation?

Why does it take only one day to train LlamaGen-B with 8 A100? Is there a special technique? With the same settings, it takes me 2.5 days to run 300 epochs.


Automated Package Upgrade

:tada: This PR is included in version 4.0.35 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Feature] Extract code block to function/method

One of the most powerful refactorings is possibly the extraction of a block of code into a new function/method.
Would it be possible to add this feature?

Similar to this, creating a function definition and/or declaration from a call to a new undeclared function is also essential.
Does anyone have any tips on how to get started implementing these features?


Update csi examples and deploy links

Signed-off-by: prateekpandey14<EMAIL_ADDRESS>

@prateekpandey14 can you raise the PR again from a new branch. There was a rebase done on staging.

Can you please open a new PR with the changes on top of the new staging.


add pendantic file

Feature: To pass the project through static analysis
Expected Behaviour: On running dart analyze it should give warnings or errors after pedantic integration is done
Ref: https://pub.dev/packages/pedantic#stricter-than-effective-dart

Also, please resolve all the issues after integrating this in project.

@hiashutoshsingh  I would like to work on this issue, I am a GSSoC21' participant


[SPARK-26269][YARN]Yarnallocator should have same blacklist behaviour with yarn to maxmize use of cluster resource

What changes were proposed in this pull request?
As I mentioned in jira SPARK-26269, in order to maxmize the use of cluster resource,  this pr try to make YarnAllocator have the same blacklist behaviour with YARN.
How was this patch tested?
Added.

Can one of the admins verify this patch?

ping @attilapiros @vanzin @jerryshao for kindly review.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

Test build #99733 has started for PR 23223 at commit 65a70dc.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5773/
Test PASSed.

the approach here makes sense.   Are you seeing actual issues with this blacklisting when it shouldn't?  I could see that possible there and if so we should move this to defect and make sure it goes into 2.4.1

Test build #99733 has finished for PR 23223 at commit 65a70dc.

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

Merged build finished. Test PASSed.

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

I mean if node blacklisting in Spark would be perfectly aligned to YARN then it would be just redundant to have it in Spark in the first place.

This change seems result in perfectly aligned to YARN for node blacklisting in Spark, but my original thought is that some exit status (e.g. KILLED_BY_RESOURCEMANAGER ),  currently, should not lead to a node blacklisting. So, actually, perfectly aligned to YARN is not the real target of this change, and we can also make some custom strategy for Spark.

Take for example disk failure.

For spark  task level backlisting, is it should be delegated to schedulerBlacklist in YarnAllocatorBlacklistTracker ?
And it seems ContainerExitStatus.DISKS_FAILED in YARN is not same with Spark tasks' disk failure.

Are you seeing actual issues with this blacklisting when it shouldn't?

Unfortunately, no. @tgravescs @squito

it looks like its only going to blacklist the node for the AM, not other nodes for general containers.

@squito Yarn have blacklist for AM when config am-scheduling.node-blacklisting-enabled=true, and have ContainerFailureTracker  for  general containers(haven't find a config for it).

Test build #99757 has started for PR 23223 at commit 2d1c27a.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5796/
Test PASSed.

Test build #99757 has finished for PR 23223 at commit 2d1c27a.

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

Merged build finished. Test PASSed.

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

if you aren't seeing actual issues with this I guess it would be interesting to test it further to see if it does.  I can see spark blacklisting when it shouldn't for exit codes like you mention (KILLED_BY_RESOURCEMANAGER) .  so I guess I would like to see someone test this further and determine if that happens.  If it does we should change to bug and put into 2.4.1.

it would be interesting to test it further to see if it does.

@tgravescs  Yeah, I have the same thought. I'd like to try it, but I can not guarantee that I can achieve it... Because I have never done this kind of test before. I'll try my best.

Hi @tgravescs , I tried it, but found it's difficult to produce  KILLED_BY_RESOURCEMANAGER exit status. I followed YARN-73 YARN-495, but things didn't go as I expected.

ok thanks for trying.  if I get a chance I can try later in the week, but that doesn't have to block this now if someone else has time to review before I get to it. We can always pull it back later.

sorry for the delay on this, will try it out today

haven't been able to easily reproduce, will try again today

Thank you for your efforts. @tgravescs

Test build #100336 has started for PR 23223 at commit da8442e.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/6302/
Test PASSed.

Test build #100336 has finished for PR 23223 at commit da8442e.

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

Merged build finished. Test PASSed.

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

Hi, @tgravescs .
SPARK-26269 is marked as 'Improvement'.
So, we are going to backport this improvement patch to branch-2.4?

thanks for pointing that out, I forgot to change the type, will fix iut now. I consider this a defect as we would blacklist thing when we shouldn't.

+1. Thanks!


🚀 - Support screenshots

Which @codeimage/* package(s) are relevant/releated to the feature request?
Don't known / other
Description
Besides code/text, it would be nicer if you support screenshots too

Hi, @truongduyng, after a discussion with @hackpirodev we believe that the effort required for this feature is not so much, but it doesn't reflect much the codeimage idea at the moment.
For now we are focusing on improving the code editor and we have several activities planned, so we cannot work on what you requested in the short term

Hi @riccardoperra, thank you for your response. Im really impressed by your work. I knew that this request didn't reflect the codeimage. Your app name itself is self-explained what it does. Just that I see many other screenshot apps do the same thing with codeimage but although its quality is worse than codeimage they have a bigger number of users.
Would be worth it if you clone another version for screenshot?


various things

added getBonds
some small fixes

Coverage decreased (-0.5%) to 39.157% when pulling 167ad73eacff525df06e07cc92675db65ddd71cc on Tr0nYx:master into c69b4d1db9f01311c3cb0b1186db893c7e780c16 on Alpha-Trader:master.

Coverage increased (+0.3%) to 39.963% when pulling 441da56326b9acfd680f2e6976abe26daba10a87 on Tr0nYx:master into c69b4d1db9f01311c3cb0b1186db893c7e780c16 on Alpha-Trader:master.


Persistence with gun

Implements saving and restoring a successful session

Jsut needs a rebase but this should have only minor conflicts.


code for learning

Is there code available to train models?

I didn't plan to release the code, since I thought its way to similar to other projects of mine. For example have a look at https://github.com/RicherMans/CDur


Updating typescript-operations from 1.9.1 to 1.12.1 broke our build

Describe the bug
when running the graphql code generator we end up with the following output
  ✔ Parse configuration
  ❯ Generate outputs
    ❯ Generate packages/web/src/graphql/types.codegen.tsx
      ✔ Load GraphQL schemas
      ✔ Load GraphQL documents
      ✖ Generate
        → Cannot read property 'definitions' of undefined
    ✔ Generate packages/web/schema.json

 Found 1 error

  ✖ packages/web/src/graphql/types.codegen.tsx
    TypeError: Cannot read property 'definitions' of undefined
        at /Users/antonio/dev/shippr/node_modules/graphql/utilities/concatAST.js:21:18
        at Array.flatMap (<anonymous>)
        at flatMap (/Users/antonio/dev/shippr/node_modules/graphql/polyfills/flatMap.js:13:24)
        at Object.concatAST (/Users/antonio/dev/shippr/node_modules/graphql/utilities/concatAST.js:20:39)
        at Object.plugin (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/typescript-operations/index.cjs.js:107:28)
        at executePlugin (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/core/index.cjs.js:50:41)
        at /Users/antonio/dev/shippr/node_modules/@graphql-codegen/core/index.cjs.js:106:30
        at Array.map (<anonymous>)
        at Object.codegen (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/core/index.cjs.js:96:54)
        at processTicksAndRejections (internal/process/task_queues.js:93:5)
        at async process (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/cli/bin.js:783:56)
        at async Promise.all (index 0)
        at async /Users/antonio/dev/shippr/node_modules/@graphql-codegen/cli/bin.js:790:37
        at async Task.task (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/cli/bin.js:582:17)
    TypeError: Cannot read property 'definitions' of undefined
        at /Users/antonio/dev/shippr/node_modules/graphql/utilities/concatAST.js:21:18
        at Array.flatMap (<anonymous>)
        at flatMap (/Users/antonio/dev/shippr/node_modules/graphql/polyfills/flatMap.js:13:24)
        at Object.concatAST (/Users/antonio/dev/shippr/node_modules/graphql/utilities/concatAST.js:20:39)
        at Object.plugin (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/typescript-operations/index.cjs.js:107:28)
        at executePlugin (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/core/index.cjs.js:50:41)
        at /Users/antonio/dev/shippr/node_modules/@graphql-codegen/core/index.cjs.js:106:30
        at Array.map (<anonymous>)
        at Object.codegen (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/core/index.cjs.js:96:54)
        at processTicksAndRejections (internal/process/task_queues.js:93:5)
        at async process (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/cli/bin.js:783:56)
        at async Promise.all (index 0)
        at async /Users/antonio/dev/shippr/node_modules/@graphql-codegen/cli/bin.js:790:37
        at async Task.task (/Users/antonio/dev/shippr/node_modules/@graphql-codegen/cli/bin.js:582:17)

Something went wrong
error Command failed with exit code 1.

To Reproduce
When running codegen on it, it crashes, reverting to 1.9.1 fixes it

My GraphQL schema:

My GraphQL operations:

My codegen.yml config file:

schema: packages/backend/src/graphql/schema.graphql
documents:
  - packages/web/src/**/*.ts
  - packages/web/src/**/*.tsx
overwrite: true
generates:
  packages/web/src/graphql/types.codegen.tsx:
    plugins:
      - typescript
      - typescript-operations
      - typescript-resolvers
      - typescript-react-apollo
    config:
      withHooks: true
      withComponent: false
      withHOC: false
  packages/web/schema.json:
    plugins:
      - introspection

Expected behavior

Environment:

OS:
@graphql-codegen/cli: 1.11.2
NodeJS: 12.13.1

Additional context
I can't copy paste my graphql schema for privacy reasons, let me know if you want me to try and get a minimal reproduction up

@ardatan can you please take a look? it seems like an issue with toolkit?

I've had a similar issue upgrading from 1.8.3 to 1.12.1. However I can generate code but it doesn't generate the import { ExampleFragmentDoc } from './ExampleFragment.generated in the generated query file. See below my codegen.yml config.
overwrite: true
schema:
  - "schema.graphql"
config: {}
documents:
  - "src/**/*.graphql"
generates:
  src/graphql-types.ts:
    - typescript
  src/:
    preset: near-operation-file
    presetConfig:
      extension: .generated.tsx
      baseTypesPath: graphql-types.ts
    config:
      noNamespaces: true
      withHooks: true
      withHOC: false
      hooksImportFrom: react-apollo
    plugins:
      - add: '/* eslint-disable import/first */'
      - typescript-operations
      - typescript-react-apollo
  src/introspection-result.ts:
    plugins:
      - fragment-matcher
require: []

@henry-young I think your issue is different. Let's track yours there https://github.com/dotansimha/graphql-code-generator/issues/3259
@0xClpz Could you change versions of all codegen packages to 1.12.1 without ^ and ~, and run yarn install or npm install to install them? So we can avoid the version mismatch.

I was getting exactly the same error, but now I can confirm upgrading dependencies fixed it for me

@henry-young I think your issue is different. Let's track yours there #3259
@0xClpz Could you change versions of all codegen packages to 1.12.1 without ^ and ~, and run yarn install or npm install to install them? So we can avoid the version mismatch.

@ardatan Yes you are correct.

I'm having the same issue, but downgrading from 1.12.2 to 1.12.1 didn't fix it for me

Same issue, downgrading to 1.12.1 fixed it for me.

We are also getting the exact same error message as the OP, and setting the version for all codegen packages to 1.12.2, 1.12.1 or 1.12.0 didn't fix it. The latest version that works is 1.11.2.

@johnnyBira @elarouss @cosmocoder can you please make sure you have the latest versions of graphql-codegen and graphql-toolkit? If it's still happens, can you please share a reproduction in a repo/sandbox?
Thanks!

We are using the following codegen packages:
@graphql-codegen/cli: "1.12.2",
@graphql-codegen/fragment-matcher: "1.12.2",
@graphql-codegen/introspection: "1.12.2",
@graphql-codegen/typescript": "1.12.2",
@graphql-codegen/typescript-operations": "1.12.2",
@graphql-codegen/typescript-react-apollo": "1.12.2"
Using the latest version for those packages didn't solve it for us.

Thanks @cosmocoder , can you please share a reproduction I can try locally?

@dotansimha Here is the minimal setup that showcases the error we are getting
codegen-sandbox.zip

@cosmocoder As I see in package.json, versions of codegen related packages mismatch
    "@graphql-codegen/cli": "^1.11.2",
    "@graphql-codegen/fragment-matcher": "1.12.2",
    "@graphql-codegen/introspection": "1.12.2",
    "@graphql-codegen/typescript": "1.12.2",
    "@graphql-codegen/typescript-operations": "1.11.2",
    "@graphql-codegen/typescript-react-apollo": "1.11.2"

So we asked you try latest versions like below;
    "@graphql-codegen/cli": "1.12.2",
    "@graphql-codegen/fragment-matcher": "1.12.2",
    "@graphql-codegen/introspection": "1.12.2",
    "@graphql-codegen/typescript": "1.12.2",
    "@graphql-codegen/typescript-operations": "1.12.2",
    "@graphql-codegen/typescript-react-apollo": "1.12.2"

@ardatan apologies for uploading the wrong package.json. I updated the version numbers in the minimal setup, and the error did go away there. But I am still getting the error in our main project with the latest versions. Clearing node_modules and re-installing the packages didn't help also. Any ideas on what might cause this? We are using the same packages in the main package as in the minimal setup.

@cosmocoder Could you try to delete lock file and install dependencies?

Yes, I had tried that too, but no luck.

@ardatan @dotansimha I got the exactly same issue. My devDependencies are as follows.
"devDependencies": {     "@graphql-codegen/add": "1.12.2",     "@graphql-codegen/typescript": "1.12.2",     "@graphql-codegen/typescript-operations": "1.12.2",     "@graphql-codegen/typescript-react-apollo": "1.12.2",     "@graphql-codegen/typescript-resolvers": "1.12.2",     "@test-graphql-cli/codegen": "4.0.1-beta.1",     "@test-graphql-cli/coverage": "4.0.1-beta.1",     "@test-graphql-cli/diff": "4.0.1-beta.1",     "@test-graphql-cli/generate": "4.0.1-beta.1",     "@test-graphql-cli/init": "4.0.1-beta.1",     "@test-graphql-cli/serve": "4.0.1-beta.1",     "@test-graphql-cli/similar": "4.0.1-beta.1",     "@test-graphql-cli/validate": "4.0.1-beta.1",     "graphql": "14.6.0",     "graphql-cli": "4.0.1-alpha-0eab853.133",     "schemats": "3.0.3",     "tslint": "5.20.1",     "typescript": "3.7.5"
I downgraded to 1.12.1 but didn't work for me. Also I downgraded to 1.11.2 and it did work for me as @cosmocoder mentioned. Any idea how to fix it with 1.12.2 ?
Also it's giving some incorrect peer dependency warnings when linking dependencies.
`
warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>`
Not sure whether it's related anyway.

@NomadXD Could you try to update your @test-graphql-cli/codegen to 4.0.1-beta.2 and try again?

@ardatan I use @graphql-codegen/cli. Is that what you meant?

@cosmocoder I meant graphql-cli which is a different CLI tool but anyway we need to reproduce your issue somehow.

@ardatan on checking the yarn.lock file in my project I saw that @graphql-codegen/cli 1.12.2 has a dependency on graphql-config "3.0.0-alpha.18", and that in turn has a dependency on @graphql-toolkit 0.9.1. I saw that yarn resolves some of the packages from the toolkit (file-loading and schema-merging) to be v0.9.1. Could this cause the error?

@NomadXD Could you try to update your @test-graphql-cli/codegen to 4.0.1-beta.2 and try again?
Great !!! I updated the @test-graphql-cli/codegen to 4.0.1-beta.2 and it works fine now. Thanks a lot!!! @ardatan

Hi
Any updates on this issue?
We have all the versions set to 1.12.2 and it produces the same error

@iamdanthedev @cosmocoder Could you share your package.json files?

@ardatan here it is:
{
  "name": "frontend",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@apollo/react-hooks": "3.1.3",
    "@apollo/react-testing": "^3.1.3",
    "@ckies/library": "0.2.0",
    "@graphql-codegen/cli": "^1.11.2",
    "@graphql-codegen/fragment-matcher": "1.12.2",
    "@graphql-codegen/introspection": "1.12.2",
    "@graphql-codegen/typescript": "1.12.2",
    "@graphql-codegen/typescript-operations": "1.11.2",
    "@graphql-codegen/typescript-react-apollo": "1.11.2",
    "@reach/router": "1.2.1",
    "@testing-library/jest-dom": "^5.1.1",
    "@testing-library/react": "^9.5.0",
    "@types/classnames": "2.2.9",
    "@types/file-saver": "2.0.1",
    "@types/fontfaceobserver": "0.0.6",
    "@types/graphql": "^14.5.0",
    "@types/i18next-xhr-backend": "^1.4.2",
    "@types/jest": "25.1.3",
    "@types/js-cookie": "^2.2.5",
<EMAIL_ADDRESS>"4.5.5",
    "@types/node": "13.7.7",
    "@types/reach__router": "^1.3.0",
    "@types/react": "16.9.23",
    "@types/react-css-transition-replace": "2.1.3",
    "@types/react-dom": "16.9.5",
    "@types/react-i18next": "^8.1.0",
    "@types/react-transition-group": "4.2.4",
    "@types/scroll": "3.0.0",
    "apollo-cache-inmemory": "^1.6.5",
    "apollo-client": "^2.6.8",
    "apollo-link": "^1.2.13",
    "apollo-link-batch-http": "^1.2.13",
    "apollo-link-error": "^1.1.12",
    "assert-never": "1.2.0",
    "auto-bind": "^4.0.0",
    "bundlesize": "0.18.0",
    "change-case": "4.1.1",
    "classnames": "2.2.6",
    "codecov": "^3.6.5",
    "eslint-config-prettier": "^6.10.0",
    "eslint-plugin-graphql": "^3.1.1",
    "eslint-plugin-prettier": "^3.1.2",
    "file-saver": "2.0.2",
    "fontfaceobserver": "2.1.0",
    "gh-pages": "2.2.0",
    "graphql": "^14.6.0",
    "graphql-tag": "^2.10.3",
    "i18next-browser-languagedetector": "^4.0.2",
    "i18next-scanner": "^2.10.3",
    "i18next-xhr-backend": "^3.2.2",
    "jest-date-mock": "1.0.8",
    "jest-fetch-mock": "^3.0.2",
    "jest-junit": "^10.0.0",
    "js-cookie": "^2.2.1",
    "lodash.isequal": "4.5.0",
    "node-sass": "4.13.1",
    "prettier": "^1.19.1",
    "query-string": "6.11.1",
    "react": "^16.13.0",
    "react-app-polyfill": "1.0.6",
    "react-cosmos": "^5.0.9",
    "react-css-transition-replace": "4.0.2",
    "react-dom": "^16.13.0",
    "react-i18next": "^11.3.3",
    "react-markdown": "4.3.1",
    "react-router": "5.1.2",
    "react-router-dom": "5.1.2",
    "react-scripts": "3.4.0",
    "react-transition-group": "4.3.0",
    "scroll": "3.0.1",
    "smooth-scroll-into-view-if-needed": "1.1.27",
    "source-map-explorer": "2.3.1",
    "typescript": "3.8.3",
    "use-debounce": "3.3.0"
  }
}

The problem persists with v1.13.0 too

@cosmocoder I can only recommend you to try remove lock file, remove node_modules and reinstall all dependencies.
The issue mentioned here happens when there is a mismatch between graphql-config / graphlq-cli / graphql-codegen / graphql-toolkit versions, sometimes caused by an incorrect/outdated generated lock file.
Please share a live reproduction or a repo, as we not able to reproduce this.

This configuration works for me:
    "@graphql-codegen/add": "1.8.1",
    "@graphql-codegen/cli": "1.8.1",
    "@graphql-codegen/fragment-matcher": "1.8.1",
    "@graphql-codegen/introspection": "1.8.3",
    "@graphql-codegen/plugin-helpers": "1.8.1",
    "@graphql-codegen/schema-ast": "1.9.1",
    "@graphql-codegen/typescript": "1.8.1",
    "@graphql-codegen/typescript-operations": "1.8.1",
    "@graphql-codegen/typescript-react-apollo": "1.13.2",
    "@graphql-codegen/typescript-resolvers": "1.8.1",
    "@graphql-codegen/visitor-plugin-common": "1.8.1",

This is the error that I get:
  ✔ Parse configuration
  ❯ Generate outputs
    ❯ Generate src/fragmentTypes.json
      ✖ Load GraphQL schemas
        → Failed to load schema
        Load GraphQL documents
        Generate
    ❯ Generate src/graphql-types.ts
      ✖ Load GraphQL schemas
        → Failed to load schema
        Load GraphQL documents
        Generate

 Found 2 errors

  ✖ src/fragmentTypes.json
    Failed to load schema from src/schema.json:

        Cannot read property 'extensions' of undefined
        TypeError: Cannot read property 'extensions' of undefined
    at applyExtensionObject (/Users/nidza/Projects/car-manager/client-web/node_modules/@graphql-tool
kit/schema-merging/index.cjs.js:834:41)
    at applyExtensions (/Users/nidza/Projects/car-manager/client-web/node_modules/@graphql-toolkit/s
chema-merging/index.cjs.js:840:9)
    at makeSchema (/Users/nidza/Projects/car-manager/client-web/node_modules/@graphql-toolkit/schema
-merging/index.cjs.js:951:5)
    at Object.mergeSchemasAsync (/Users/nidza/Projects/car-manager/client-web/node_modules/@graphql-
toolkit/schema-merging/index.cjs.js:921:12)

Configuration is:
    "@graphql-codegen/cli": "^1.13.2",
    "@graphql-codegen/fragment-matcher": "^1.13.2",
    "@graphql-codegen/typescript": "^1.13.2",
    "@graphql-codegen/typescript-operations": "^1.13.2",

Reverting to 1.9.1 fixes it for me.

Please remove ^ from your version just use exact version instead of ^1.13.2, use 1.13.2.

@ardatan That doesn't work 🙁

@alamothe Could you please open another issue with more details and a minimal reproduction? Thanks.

Sure will do!
BTW also tried removing package-lock.json and node_modules.

https://github.com/dotansimha/graphql-code-generator/issues/3865

updating worked for me, thanks humans who have been on this thread!

@fractalmarc can you please share your versions from package.json files. I am facing the same issue. Even though pushing it to latest.

I'm having trouble with this too.
Im using:
"@graphql-codegen/cli": "2.1.1",
"@graphql-codegen/typescript": "2.1.2",
"@graphql-codegen/typescript-operations": "2.1.2",
"@graphql-codegen/typescript-urql": "^3.1.2",
I have tried removing the ^ from the last package, but it didn't make any difference.
When I try generating the graphql, the first two steps complete and the generate step fails with an error that says:

✖ src/generated/graphql.tsx
AggregateError: GraphQL Document Validation failed with 1 errors;
Error 0: GraphQLDocumentError: Cannot query field "changePassword" on type "Mutation".

I don't know if it's possible that slow internet might be a factor. There has been a storm in my area and internet has been slow all week. I've found this error seems to go away after waiting a few hours, restarting VS code. Not sure if this could be a factor or if I need to be looking for something else that might be causing this problem.


Incorrect slash when saving results (linux)

When saving the results of the program, the program uses a forward slash after attempting to save to the MLD folder resulting in the saving of the file in the home directory as MLD{tittle}.

The desired behavior, in my mind, would be to have the results saved to a "results" directory located inside the directory of execution.

Looks like you addressed this in 1d083c7. Will Close pending PR.

Let's leave open until the PR goes through to have better trace-ability.

Fixed in #8


Fix unpaired close tags and self-closing tags

https://github.com/google/budoux/pull/251 assumed that all tags are closed properly.
This assumption doesn't stand for cases like:

Self-closing tags such as <img> don't have corresponding close tags.
Unpaired close tags are still valid HTML.

This patch supports these cases by assuming all open tags that doesn't nest correctly or that doesn't close are automatically closed.
This isn't the full HTML "adoption agency algorithm", but it should be good enough for the needs of BudouX.
Fixes #355

@kojiishi I left a small comment actually. PTAL.


Function to get the enum entry description

Could you extend the sbeppc generator with the option to generate the function to return the description of the arbitrary enum value:
        <enum name="ErrorCode" encodingType="uint16">
            <validValue name="Other" description="Other">0</validValue>
            <validValue name="TooManyConnections" description="Amount of connected clients on the server reached the limit">1</validValue>
        </enum>

    constexpr char const* description(ErrorCode v) noexcept;
    {
        switch(v)
        {
            case ErrorCode::Other:
                return sbepp::enum_value_traits<ErrorCode::Other>::description();
          // ...
        }

        return "<undefined>";
    }

BTW, it seems it is not really good idea to define the types inside the detail namespace, as in order to make ADL work, I have to put the description() function into my_protocol::detail::types namespace.
    constexpr char const* description(types::ErrorCode v) noexcept
    {
        //...
    }

And something is not right with the namespaces. In case if I want to extend the SBE parser with custom functionality (like my own implementation of the description method), then my code is getting bloated with namespaces:
namespace my_protocol::detail::types
{
    constexpr char const* description(my_protocol::types::ErrorCode v) noexcept
    {
        switch(v)
        {
            case my_protocol::types::ErrorCode::Other:
                return sbepp::enum_value_traits<my_protocol::schema::types::ErrorCode::Other>::description();
            case my_protocol::types::ErrorCode::TooManyConnections:
                return sbepp::enum_value_traits<my_protocol::schema::types::ErrorCode::TooManyConnections>::description();
        }

        return "<undefined>";
    }

}

Could you extend the sbeppc generator with the option to generate the function to return the description of the arbitrary enum value

Definitely not in the way you showed above. But I'll think how to make it more generic to provide similar functionality.

BTW, it seems it is not really good idea to define the types inside the detail namespace, as in order to make ADL work, I have to put the description() function into my_protocol::detail::types namespace.

First of all, it's not a good idea to add anything into a third-party namespaces, especially into detail. Second, relying on ADL using unqualified function calls is a very strong code-smell. You can have that function anywhere in your own namespace and it will work perfectly fine.

And something is not right with the namespaces.

They are perfectly fine, do you really think that I deliberately added random namespaces into the overall structure to make it more complex?

In case if I want to extend the SBE parser with custom functionality

Then do it in your own namespace, don't hack into external ones.

I have a question, why do you define the class for the every enum entry. Enum itself can be a template parameter

That would be inconsistent design because everything else in XML schema is reachable through schema_name::schema. But I'm thinking about such mapping (#41).

Do you have an explanation why ADL is bad? The idea behind the ADL is to be able to call the functions using unqualified function calls

You can just google "C++ ADL problem" and find tons of questions, problems, articles, explanations how it works and even attempts to fix it. It is not a mechanism one should use on a daily basis just to make the code shorter.

What if I have multiple namespaces? Then in order to call the function using unqualified function calls I have to copy that function to every namespace. Or define it in the global namespace, which is not good.

Define a function ::sbe_utils::describe(types::MyEnum) and then use its qualified name everywhere. What's the problem?

The my_protocol is my namespace, isn't it?

No, SBE XML is yours, the generated code is not. It's an instantiation of very large C++ template to which XML content is passed as input, you're allowed to use it only through public documented interface, otherwise all bets are off. std::vector<T> is not yours just because you own T and when you need a function that works on std::vector, you don't write it inside std namespace.

What I say is the way how namespaces are organized causes conflicts, so developer is forced to use fully qualified namespaces which makes code hard to read and understand.

Using qualified names is the way to write C++ code. I use unqualified names only when they refer to the enclosing namespace, all other C++ projects I know do the same. Again, what conflicts? What you showed above is not a conflict, you're just trying to hack into the generated code and surprised that it's not convenient. The solution here is very simple, write your function in your own namespace and call it from anywhere you want.

@ujos with #48 merged, you can now implement requested functionality like:
struct enum_visitor{
    template<typename Enum, typename Tag>
    void on_enum_value(Enum /*e*/, Tag){
        description = sbepp::enum_value_traits<Tag>::description();
    }

    template<typename Enum>
    void on_enum_value(Enum /*e*/, sbepp::unknown_enum_value_tag){
        description = nullptr;
    }

    const char* description;
};

// returns `nullptr` if `e` is unknown
template<typename Enum>
const char* description(Enum e){
    return sbepp::visit<enum_visitor>(e).description;
}

Closing as completed, let me know if you need more support with this.


docker-resin-supervisor-disk: Update supervisor to 2.6.3

connect https://github.com/resin-os/meta-resin/pull/426

Not to be merged yet

Decision was that we should backport any needed commits to the 1.x branch


docs; changed Luxe.input.add to Luxe.input.bind_key

The input binding function changed from Luxe.input.add to Luxe.input.bind_key/bind_mouse on December 10th. Making this tutorial reflect that so it compiles on latest revision.

:deciduous_tree:


Tests for "Make a Person" bonfire don't make sense

I think there might be something wrong with the Make a Person bonfire, as what I've found as a passing solution goes against everything that I'd just learnt in the Udacity tutorials.
Using the following solution, I'm able to get all of the tests passing, except for the first:
var Person = function(firstAndLast) {
  this.setFullName(firstAndLast);
};

Person.prototype.getFirstName = function() {
  return this.first;
};

Person.prototype.getLastName = function() {
  return this.last;
};

Person.prototype.getFullName = function() {
  return this.first + ' ' + this.last;
};

Person.prototype.setFirstName = function(first) {
  this.first = first;
};

Person.prototype.setLastName = function(last) {
  this.last = last;
};

Person.prototype.setFullName = function(firstAndLast) {
  names = firstAndLast.split(' ');
  this.first = names[0];
  this.last = names[1];
};

var bob = new Person('Bob Ross');
bob.getFullName();

I'm no expect at this, and I'm sure my code could probably be slightly better refactored, but based on what udacity has just been teaching, this seems like a fairly good solution - except that it fails on the first test, the one stating expect(Object.keys(bob).length).to.eql(6); should be true;
So I've spent a bit of time looking at other solutions, such as this one, and the one listed here, which both satisfy the test condition, but in an inefficient way.
Anyway, I could be missing something, if so, please let me know what. Thank you.

I ran into the same issue, and I don't think the problem aligns well with the methodology Udacity taught.
I think they're approaching it this way to prevent you from directly accessing bob.first or bob.last. I think the way you accomplish this is to take advantage of closures by pulling the functions into Person() and declaring local variables rather than properties of the object.
So code starts out like so:
var Person = function(firstAndLast) {
var first, last;

var setFullName = function(firstAndLast) {
  names = firstAndLast.split(' ');
  first = names[0];
  last = names[1];
};

I imagine you could also do this.
var Person = function(firstAndLast) {
var first, last;

Person.prototype.setFullName = function(firstAndLast) {
  names = firstAndLast.split(' ');
  first = names[0];
  last = names[1];
};

However, I think you'll fail the property count check. I don't think you prevent the functions being recreated every time either.
It'd be cool if the trickier Bonfires opened up an extra Waypoint to discuss issues like this and alternate implementations.

closing in favor of #881


retokenize can change the index values

I have a program where I need to call retokenize to combine specific tokens. This changes the indices of tokens and thus the coreferences are no longer pointing to the correct tokens. I have created a work around that adjusts these indices values, but I thought I'd let you know about this problem. I still have some issue where I clearly have not adjusted everything correctly because resolve is returning None instead of a value.

I understand the problem, but I don't think that the right solution would be for Coreferee to react to the retokenization. This would get far too complex: if token 1 and 2 are merged and a coreference has been marked on token 2, does this coreference then apply to the new, merged token? And the same question would occur when tokens are split.
Instead, I think the solution is to retokenize and then call Coreferee. This involves calling it explicitly rather than adding it to the pipeline and is achieved using this code:
from coreferee.manager import CorefereeManager
annotator = CorefereeManager().get_annotator(nlp)
annotator.annotate(doc)