Add support for querying netCDF4 file for groups

Basically as the title says - it would be nice to have support to query NetCDF4 files for the groups that they contain.
I can do something similar using the netCDF4 library directly:
import netCDF4 as nc

myDset = nc.Dataset("/path/to/dataset.nc","r")
# From here you can use myDset.groups to get all groups in the file, or use a dict-like interface to get the groups of subgroups, etc

Assuming implementing this is really this simple, I can take a swing at this and submit a PR.

This has come up a couple of times before -- please see https://github.com/pydata/xarray/issues/2916 and https://github.com/pydata/xarray/issues/1092.
The basic issue is that xarray.Dataset doesn't have any notion of a group in it, so it isn't clear how we could work in xarray.
If it's just a matter of listing groups that  can be found in a file, it  seems like netCDF4 works fine for  that.

I hacked a quick solution for exploring HDF5 files that might be of interest.
import h5py
def explore_file(filepath,show="arrays"):
    """
    View the internal structure of an HDF5 file
    Returns a dictionary of the entity names & representations of their values
    Arguments:
        filepath: string
        show: one of ('groups','arrays','all')
            groups: display the number of direct array-type members of each group/subgroup
            arrays: display the shape & dtype of each array (if not a scalar)
            all: display the shape & dtype of every array
    """
    with h5py.File(filepath,mode='r') as f:
        descriptions = {}
        if show=="groups":
            def visitor(k,v):
                if isinstance(v, h5py.Group):
                    arrays = [k for k in v.keys() if isinstance(v[k],h5py.Dataset)]
                    if len(arrays) >0:
                        descriptions[k] = len(arrays)
        elif show == "arrays":
            def visitor(k,v):
                if isinstance(v,h5py.Dataset) and len(v.shape)>0:
                    descriptions[k] = "{},{}".format(v.shape,v.dtype)
        elif show =="all":
            def visitor(k,v):
                if isinstance(v,h5py.Dataset):
                    descriptions[k] = "{},{}".format(v.shape,v.dtype)
        f.visititems(visitor)#Apply names.append to each name in the file
    return descriptions

Closing as duplicate of #2916. Eventually this will be fixed by datatree


Class exists is not autoloading the class.

I think this is a problem, because I had to change to "true", and so it worked:
https://github.com/mercadopago/dx-php/blob/470a7ecd5a84c83894b015fb2455be24df31e023/src/MercadoPago/Entity.php#L349-L353

Thanks for report, we made the changes requested in https://github.com/mercadopago/dx-php/pull/48  , we invite you to make a pull request for the next time 👍


Update to version SF 10 1949

Description

Describe the proposed change here. Please be sure to communicate why this Pull Request should be accepted. If this fixes a bug or resolves a feature request, be sure to link to that issue.

Update service fabric runtime and SDK to latest v10 1949. This update addresses an installation bug with runtime binary as described here https://github.com/microsoft/service-fabric/issues/1462
Classification

Put an x in the box that applies.

Selection
Change Type
Description

[x]
Bug Fix
Non-breaking change which fixes an bug

[x]
Feature Request
Non-breaking change which new behaviour

[ ]
Breaking Change
Fix or feature that would cause existing behaviour not to work as expected

Checklist

Put an x in the boxes that apply.

Selection
Description

[ ]
I have read the contributing document.

[ ]
Style and unit tests pass locally with my changes.

[ ]
I have added tests that prove my fix is effective or that my feature works.

[ ]
I have added necessary documentation (if appropriate).

[ ]
Any dependent changes have been merged and published in downstream modules.

Further Details

If this is a relatively large or complex change, please explain why this solution was chosen and what alternatives were considered.

Hey, @darinegan sorry for the tag. Just wanted to make sure you were aware this PR exists. The current latest SDK package installs a binary from Microsoft that contains a bug as detailed here https://github.com/microsoft/service-fabric/issues/1462
This PR addresses this so I'm hoping to get this available publicly as soon as possible

@williamoconnorme thanks for the direct mention; GH doesn't notify me on new PR's 😕 However, a big thank you for taking the time to submit this; it is approved and pushed to Chocolatey for review.


[CODE-1052] Invalid string length while appending coverage files for upload

Describe the bug
On Linux: ['error'] There was an error running the uploader: Invalid string length
On MacOS: : Error: Cannot create a string longer than 0x1fffffe8 characters
This occurs when appending large XML coverage reports during the Processing <filename> step.
To Reproduce
Steps to reproduce the behavior:

Download the binary uploader
Visit http://mattmahoney.net/dc/textdata.html
Download http://mattmahoney.net/dc/enwik9.zip from that page (or here)
unzip file
attempt to upload it ./codecov -f ~/Downloads/enwik9
See error

Expected behavior
The uploader is unable to handle large files concatenated together. This appears to be a V8 limit, see GitHub issue in the additional context section.
Additional context
https://github.com/nodejs/node/issues/35973#issuecomment-722253319

Think we'll need to refactor away from using readFile and towards using stream via createReadStream

Think we'll need to refactor away from using readFile and towards using stream via createReadStream

Will that fix this? The issue, as I understand it, is here https://github.com/codecov/uploader/blob/8f317a425b852f36a398ebf54cf5b3046a1736d1/src/index.ts#L214

Yea - on occasion there must be files large enough that we hit the max allowed in node.js process since we read the whole file into memory via readFile() - using the createReadStream approach can stream file contents to upload destination

Closed by #746


fix: Add the brand name in the AppBar

Added the brand name in the App Bar

Just added new variable, and changed the App bar text

Screenshot

Fixes bug(s)

Fixes: #4445

Codecov Report

Merging #4449 (6630c07) into develop (1c3921e) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           develop    #4449      +/-   ##
===========================================
- Coverage    10.17%   10.17%   -0.01%
===========================================
  Files          295      295
  Lines        15087    15089       +2
===========================================
  Hits          1535     1535
- Misses       13552    13554       +2

Files Changed
Coverage Δ

...mooth_app/lib/pages/product/edit_product_page.dart
0.50% <0.00%> (-0.01%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Your implementation is partial. You have only changed the main page, but we should have the product name first. Also in some languages, there is a space between the two info.

this bug is not only for this page, but also but all subpages

Why did you close your PR @saiprasad-patil? It was possible to add the new features in it

I'm sorry I'll create a new PR, I'm new to Github and a beginner in general.


Chapter 10 - Building a single-page application with Angular: The next level

Will create issues against more each chapter sub-section for fine grained tracking...


Doc updates + bump stdlib

these two got cherrypicked from https://github.com/theforeman/puppet-dns/pull/81

eh wat? I will take a closer look tomorrow again.

nevermind. I've never seen $thing parsing the documentation and blowing up on broken braces :dancer:

We use puppet-lint-param-docs for that since our installer uses the docs (and their types) to provide help and validation.

Thanks


Provide installation scripts for common OSes and Linux distributions for Zebra

Is your feature request related to a problem? Please describe.
During our first Zebra user studies (#1501), building and installing Zebra took a while longer than we would have expected due to various different set ups on the user's machines.
Describe the solution you'd like
We would like to provide installation scripts for common OSes and Linux distributions for Zebra to make it quicker/easier for users to build and install Zebra.
We will probably want to link to these scripts from the README.
We might also want to run those scripts in CI.
Describe alternatives you've considered
We are already improving the installation instructions in #1617

Removing from the Release Candidate Epic for Q1 2022

We've decided to just focus on one supported platform for now.


Button text overflows

Great theme, appreciate the instructions for custom colors. I've a problem with overflowing text on buttons.
I tried adding a "word-wrap: break-word;" property to the classes, but it didn't have an effect. Also tried it in a card_mod style, but it appears to be beyond my CSS knowledge.

Yikes, that's a tight layout.
So, the way the CSS is constructed, word-wrapping is going to be a major headache and probably won't produce useable results. I have two recommendations, easiest first:

Change the button text to something that will fit, such as BAR VIRTUAL instead of BAR VIRTUAL BUTTON or maybe just BAR.
Reduce the font size instead of wrapping it.
Unless it's just not feasible for you, I think changing the button text is the best route and what I have done personally. I think abbreviations would even be in keeping with LCARS style, like 'Ops' instead of 'Operations.'

I was able to make the buttons shorter by adding the max-height: 40px; property to the ha-card.button-bullet and reducing the min-height property to <= max-height.

That's the standard Media Player card (type: media-control), no changes to it.


feat: removes Laravel 5 from the list of support Laravel versions

Laravel 5 doesn't support PHP 8, so it can be removed from the list.

Thanks!

Thanks!

Thanks!


Priority for static routes

Hi!
Thanks for this very useful plugin!
While setting up my static pages, I realized that the default priority for this provider is 0.3. That seemed a bit low to me, especially for instance in the case of a home page.
Would it be possible to leave 0.3 as a default and allow customizing the priority per route in the configuration?
Thanks!

I would indeed. In fact, I've already implemented a working solution in a fork. I'll create a PR from that.


GDExtension: Remove DLL copy if it fails to load

This is a follow-up to PR https://github.com/godotengine/godot/pull/80188
That PR causes the Godot editor (on Windows) to make a copy of the GDExtension's DLL in order to prevent Windows from locking the original DLL, so the developer can re-compile it without having to stop the editor first. When the editor is shutdown, any DLL copies for loaded GDExtensions will get cleaned up.
But, currently, if the DLL fails to load, the copy won't get cleaned up. I've been testing this by compiling a GDExtension with scons use_mingw=yes use_static_cpp=no which will fail to load because it can't find the C++ runtime libraries.
Anyway, with this PR, it will clean up the DLL if it fails to load!

It probably makes sense to add your description as a comment in the code, so that it's clear when reading later 🙂

What comment text would you suggest? I can't seem to come with something that doesn't seem redundant in context.
I feel like it's pretty clear what's going on when you can see the ~5-15 lines that come before this:

Maybe based on:

When the editor is shutdown, any DLL copies for loaded GDExtensions will get cleaned up.
But, currently, if the DLL fails to load, the copy won't get cleaned up.

We could simply have something like:
// If the DLL fails to load, make sure that temporary DLL copies are cleaned up.

Ok, thank, I've added the comment

Thanks!


chore(docs): fix typo

Codecov Report

Merging #175 (5e5266f) into main (ec4c606) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #175   +/-   ##
=======================================
  Coverage   49.39%   49.39%
=======================================
  Files          36       36
  Lines         583      583
  Branches      108      108
=======================================
  Hits          288      288
  Misses        279      279
  Partials       16       16

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

npm package (@next-major dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


dropdownMenu.js forceFollow docs incorrect & code not working

The forceFollow option in foundation.dropdownMenu.js allows forcing links to be followed on touch devices (instead of opening their dropdown and being followed on second click).
The docs say it is FALSE by default, while it actually is TRUE by default (it's just not working).
forceFollow is never considered in the JS code because it is only checked on second click (after the first 'hasClicked'), around line 147;
if(hasSub){
          if(hasClicked){
            if(!_this.options.closeOnClick || (!_this.options.clickOpen && !hasTouch) || (_this.options.forceFollow && hasTouch)){ return; }
            else{
              e.stopImmediatePropagation();
              e.preventDefault();
              _this._hide($elem);
            }
         ...

Should be:
if(hasSub){
          if(hasClicked || _this.options.forceFollow){
            if(!_this.options.closeOnClick || (!_this.options.clickOpen && !hasTouch) || (_this.options.forceFollow && hasTouch)){ return; }
            else{
              e.stopImmediatePropagation();
              e.preventDefault();
              _this._hide($elem);
            }
         ...

Hi @micschk, sorry for the (very) late reply.

The docs say it is FALSE by default, while it actually is TRUE by default (it's just not working).

This issue has been reported several time since. There is a discussion open at https://github.com/zurb/foundation-sites/issues/9464, we are working on it.

forceFollow is never considered in the JS code because it is only checked on second click (after the first 'hasClicked'), around line 147;

This is the normal behavior: the link is forced to be followed on the second click on touch devices. See the documentation of the forceFollow options:
  /**
   * Boolean to force overide the clicking of links to perform default action, on second touch event for mobile.
   * @option
   * @example false
   */
  forceFollow: true

js/foundation.dropdownMenu.js:421
Can I close this issue and mark it as duplicate ?


Zip archive fails to parse on portable package update

Brief description of your issue
I'm trying to update the Martchus.syncthingtray package, but after the selection of the new "installer", I get "Failed to parse the package from". This is a package that's marked as a portable installer, and the zip file that gets downloaded contains the new exe
Steps to reproduce

Run wingetcreate update Martchus.syncthingtray -i -v 1.4.8
Enter https://github.com/Martchus/syncthingtray/releases/download/v1.4.8/syncthingtray-1.4.8-x86_64-w64-mingw32.exe.zip as new URL
Select syncthingtray-1.4.8-x86_64-w64-mingw32.exe as the new installer

Expected behavior
Package parses correctly and lets me continue with updating the package
Actual behavior
Failed to parse the package from [https://github.com/Martchus/syncthingtray/releases/download/v1.4.8/syncthingtray-1.4.8-x86_64-w64-mingw32.exe.zip]
Log file:
WingetCreateLog-2023-11-20-17-14.342.txt
Environment
Windows-Paket-Manager Manifest Creator v<IP_ADDRESS>

Windows-Paket-Manager (Vorschau) v1.7.2782-preview
Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten.

Windows: Windows.Desktop v10.0.22631.2715
Systemarchitektur: X64
Paket: Microsoft.DesktopAppInstaller v1.22.2782.0

I cannot reproduce the issue since the file doesn't even get downloaded on my machine (it's getting flagged as virus which is preventing it from being downloaded).

I cannot reproduce the issue since the file doesn't even get downloaded on my machine (it's getting flagged as virus which is preventing it from being downloaded).

I cannot reproduce the issue since the file doesn't even get downloaded on my machine (it's getting flagged as virus which is preventing it from being downloaded).

The download works fine on my end.

Seem like the app contains virus which unable to download.
It's a known problem that the program is being flagged as a false positive
https://github.com/Martchus/syncthingtray#packages-and-binaries
https://github.com/Martchus/syncthingtray/issues/207

The dev just released a new version that doesn't get flagged by Windows Defender, but the updating of the package still fails.
WingetCreateLog-2023-12-11-13-35.476.txt

@TheJanzap I couldn't reproduce the same at my end, the manifest creation works fine. This is odd since we're both on version <IP_ADDRESS>....
https://github.com/microsoft/winget-create/assets/88161975/352c0ea1-1569-4e09-b9f0-36a2fa8e11d0

@mdanish-kh Tried it on a different machine, same issue
Windows-Paket-Manager Manifest Creator v<IP_ADDRESS>

Windows-Paket-Manager (Vorschau) v1.7.3172-preview
Windows: Windows.Desktop v10.0.19045.3693
Systemarchitektur: X64
Paket: Microsoft.DesktopAppInstaller v1.22.3172.0

Tried this again with wingetcreate v<IP_ADDRESS> and Syncthingtray v1.4.13, but I still have the same problem. A reinstall of wingetcreate also does nothing.

I have a similar/same issue. Here is how reproduce:
wingetcreate update CologneCodeCompany.XYplorerPortable --token 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 --version 26.20.0100

Errors out with

Retrieving latest manifest for CologneCodeCompany.XYplorerPortable
Downloading and parsing: https://www.xyplorer.com/download/xyplorer_full_noinstall.zip...
System.Xml.XmlException: 'asmv3' is an undeclared prefix. Line 54, position 2.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String arg, Int32 lineNo, Int32 linePos)
   at System.Xml.XmlTextReaderImpl.LookupNamespace(NodeData node)
   at System.Xml.XmlTextReaderImpl.ElementNamespaceLookup()
   at System.Xml.XmlTextReaderImpl.ParseElement()
   at System.Xml.XmlTextReaderImpl.ParseElementContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
   at System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
   at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
   at System.Xml.XmlDocument.Load(XmlReader reader)
   at System.Xml.XmlDocument.LoadXml(String xml)
   at Vestris.ResourceLib.ManifestResource.get_Manifest()
   at Microsoft.WingetCreateCore.PackageParser.ParseExeInstallerType(String path, Installer baseInstaller, List`1 newInstallers)
   at Microsoft.WingetCreateCore.PackageParser.ParsePackageAndGenerateInstallerNodes(InstallerMetadata installerMetadata, Manifests manifests)
   at Microsoft.WingetCreateCore.PackageParser.UpdateInstallerNodesAsync(List`1 installerMetadataList, InstallerManifest installerManifest)
   at Microsoft.WingetCreateCLI.Commands.UpdateCommand.UpdateManifestsAutonomously(Manifests manifests)
   at Microsoft.WingetCreateCLI.Commands.UpdateCommand.ExecuteManifestUpdate(List`1 latestManifestContent, CommandExecutedEvent commandEvent)
   at Microsoft.WingetCreateCLI.Commands.UpdateCommand.Execute()
   at Microsoft.WingetCreateCLI.Program.Main(String[] args)


Unable to find the URL for entrypoint

I have a resource that collection operation is empty:
* @ApiResource(
 *     attributes={"pagination_enabled"=false},
 *     collectionOperations={},
 *     itemOperations={"get"}
 * )

when i want to generate client code, it fail and can not generate anythings for this & other resource:
Error: Unable to find the URL for "http://my.local/api/docs.jsonld#Entrypoint/county".
    at fetchEntrypointAndDocs.then.response (/usr/local/share/.config/yarn/global/node_modules/@api-platform/api-doc-parser/lib/hydra/parseHydraDocumentation.js:433:17)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

@ghanbari This works but it's strange that it is needed for other entities when you only want one resource (with --resource)

hello,
I encountered the same issue on 2.6.5 ; a get collection operation is required on all entities for admin to work.
Is this by design for an admin ? Should the error be more verbose in this case ?

I've run into this issue as well in the latest version of API platform and the hydra/react admin. Any solution?


Build graph: Avoid rebuilding previous steps after a canceled or errored step

If I run python make.py --view fpga and then cancel in the middle (or if one of the steps errors out), it looks like previously built steps are re-built.  Since some build steps are a little time-consuming, it would be nice if they did not have to be rebuilt.
Example showing adapt_fir being rebuilt:
> python make.py --view fpga
BUILDING: jtag_config
BUILDING: test_loopback_config
BUILDING: clk_delay
BUILDING: rx_adc
BUILDING: tx
BUILDING: osc_model
BUILDING: chan
BUILDING: rx_adc_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/rx_adc_core/rx_adc_core.sv
BUILDING: osc_model_core
Running model generator for osc_model_core...
BUILT: /home/steven/Code/dragonphy/build/fpga_models/osc_model_core/osc_model_core.sv
BUILDING: adapt_fir
/home/steven/Code/dragonphy/build/all/adapt_fir/chan.npy
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/ffe_gpack.sv
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/weights_pack.sv
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/chan.npy
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/step_resp_pack.sv
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/constant_gpack.sv
BUILDING: clk_delay_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/clk_delay_core/clk_delay_core.sv
BUILDING: tx_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/tx_core/tx_core.sv
BUILDING: jtag
<<<Ctrl-C to cancel>>>
> python make.py --view fpga
BUILDING: tx
BUILDING: rx_adc
BUILDING: chan
BUILDING: clk_delay
BUILDING: test_loopback_config
BUILDING: osc_model
BUILDING: jtag_config
BUILDING: rx_adc_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/rx_adc_core/rx_adc_core.sv
BUILDING: clk_delay_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/clk_delay_core/clk_delay_core.sv
BUILDING: jtag
BUILDING: osc_model_core
Running model generator for osc_model_core...
BUILT: /home/steven/Code/dragonphy/build/fpga_models/osc_model_core/osc_model_core.sv
BUILDING: adapt_fir

Looks like this is still the case.  But since it really doesn't take that long to rebuild, I don't think we need to worry about this.  I suggest closing the issue.


Would it be possible to colourize the file explorer expanded progress bar/graph or UAC prompt?

I assume the UAC prompt is probably not possible but I figured I'd mention it.
(the buttons aren't the correct accent colour:

As for the file explorer graph, I'm referring to this:

The non expanded bar is themed when using the registry tweak:

Thanks :)

I assume the UAC prompt is probably not possible but I figured I'd mention it. (the buttons aren't the correct accent colour:
As for the file explorer graph, I'm referring to this:  The non expanded bar is themed when using the registry tweak:
Thanks :)

Hi did you manage to change color of ile explorer graph? And how did you get blue one? :P I'm searching everywhere for blue progress bar in w11

I assume the UAC prompt is probably not possible but I figured I'd mention it. (the buttons aren't the correct accent colour:
As for the file explorer graph, I'm referring to this:  The non expanded bar is themed when using the registry tweak:
Thanks :)

Hi did you manage to change color of ile explorer graph? And how did you get blue one? :P I'm searching everywhere for blue progress bar in w11

Bit late but in msstyleseditor the values you need to change are:
ChartView
COPYBORDER
COPY_GRID
COPY_LINE1
COPY_LINE1FILL
COPY_LINE2
COPY_LINE2FILL

I've seen that, but those are not bitmaps - we can't patch FILLCOLOR.


Added IPinfo

I added ipInfo : https://ipinfo.io/developers
Thank you for taking the time to work on a Pull Request for this project!
To ensure your PR is dealt with swiftly please check the following:

[x] Your submissions are formatted according to the guidelines in the contributing guide.
[x] Your changes are made in the README file, not the auto-generated JSON.
[x] Your additions are ordered alphabetically.
[x] Your submission has a useful description.
[x] Each table column should be padded with one space on either side.
[x] You have searched the repository for any relevant issues or PRs.
[x] Any category you are creating has the minimum requirement of 3 items.

Thanks!


Create Home Page

Create the basic home page  with the page structure

Created the simple Data for the Home Page


Updated Javascripts from 1Password extension project

Updated to the latest Javascript from the 1Password extension. This improves support for the latest improvements to the 1Password form filling library in 1Password for iOS.

:+1:


glTF importer ignores KHR_materials_pbrSpecularGlossiness section

Godot version:
37aab45
OS/device including version:
Debian GNU/Linux
Issue description:
Some glTF files (example) store the texture information in KHR_materials_pbrSpecularGlossiness section. Right now, these are silently ignored but Godot can convert the specular-glossiness workflow numbers into metal-roughness numbers using the conversion mentioned in this document and make it look correct.
Steps to reproduce:
Import a glTF file with KHR_materials_pbrSpecularGlossiness section.

BTW, importing that glTF file with Gen Lightmaps option enabled crashes Godot editor.

Can you import the glTF file in Blender?

Similar to the other glTF issue I created, this is also about the importer.
Godot importer for assets prepared in metallic-roughness work is OK. Godot doesn't seem to support specular-workflow, but there are such assets  online, and Godot silently drops the specular-workflow textures. This is true regardless of the exporter you use.

godot3 uses the new metallic-roughness model, also it works as expected.
IMO the actual bug is, that godot doesn't fail to load the model in the xtensionsRequired case:

Godot Engine isn't required to support KHR_materials_pbrSpecularGlossiness.
I agree.
Godot Engine should fail the file with an ERR_FILE_UNRECOGNIZED or FAILED with a message saying that Specular Glossiness is not supported.
https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_materials_pbrSpecularGlossiness
https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#specifying-extensions

Can anyone still reproduce this bug in Godot 3.2.3 or any later release?
The linked models died.

As far as I know this is still valid because my pr for it is unmerged.
If it helps I can give a example model.
https://sketchfab.com/3d-models/scifi-girl-v01-96340701c2ed4d37851c7d9109eee9c0#download This one has gloss spec.


Weird rectangles underneath and/or next to the title when using 2012 layout

Those are scrollbars.
What is your browser and operating system? An issue similar to this was happening on Windows for a while, but I thought I fixed that.

Google and Windows

Okay, do you know if it happens on Firefox? I just tried it on Chrome, and this issue didn't happen. I'm on Xubuntu Linux so I don't know if this is a Windows issue or a Chrome issue.

I don't own firefox. You'll have to ask someone who does

Those are scrollbars.
Also, the problem with that is that they will appear regardless of how long the title is (as seen in the picture above). Make it so that the scroll bar will only appear if the title is too long to fit in one line

Make it so that the scroll bar will only appear if the title is too long to fit in one line

That's exactly what it does, at least for me.

I don't own firefox. You'll have to ask someone who does

You are aware that Firefox is free, right? It would be helpful if you could just download Firefox to test it. Because as it stands, I don't have the issue, and don't know how to reproduce the issue, so I can't even begin to fix it. I'm not going to go through the hassle of setting up a Windows 11 virtual machine if I don't need to.

I fixed this by adding this custom css in stylebot:
yt-formatted-string.style-scope.ytd-watch-metadata {
  overflow:hidden;
}


Typo in docs for Orin install instructions from custom container image

In the docs here
https://kairos.io/docs/installation/nvidia_agx_orin/
if you are customizing the image, or either modifying the default partition sizes you can build the images by running:

IMAGE=quay.io/kairos/core-ubuntu-20-lts-arm-nvidia-jetson-agx-orin:latest
docker run --privileged \
        -e **container**=$IMAGE \
        -e STATE_SIZE="6200" \
        -e RECOVERY_SIZE="4200" \
        -e DEFAULT_ACTIVE_SIZE="2000" \
        -v $PWD/bootloader:/bootloader --entrypoint /prepare_arm_images.sh -ti --rm quay.io/kairos/osbuilder-tools

should be
f you are customizing the image, or either modifying the default partition sizes you can build the images by running:
IMAGE=quay.io/kairos/core-ubuntu-20-lts-arm-nvidia-jetson-agx-orin:latest
docker run --privileged \
        -e **container_image**=$IMAGE \
        -e STATE_SIZE="6200" \
        -e RECOVERY_SIZE="4200" \
        -e DEFAULT_ACTIVE_SIZE="2000" \
        -v $PWD/bootloader:/bootloader --entrypoint /prepare_arm_images.sh -ti --rm quay.io/kairos/osbuilder-tools

@venkatnsrinivasan why not opening up a PR instead? :)  there is an edit button in the docs that should do the trick

Yeah , sorry , didnt see the edit option on the docs page.  Was going to open PR on this ticket once i finished all the steps with the docs today to see if there are any other gotchas.

Yeah , sorry , didnt see the edit option on the docs page.  Was going to open PR on this ticket once i finished all the steps with the docs today to see if there are any other gotchas.

No worries PR is there already :)


AWS: Is the Version Number wrong?

{
  "level": "info",
  "ow": {
    "activationId": "f1389184-d0d9-48d3-aa19-074c3cc4d6cc",
    "actionName": "helix-services--static@131",
    "transactionId": "Root=1-60392002-64a80d10671853cd22cb3177;Parent=7a6522b84d941c03;Sampled=0"
  },
  "message": "delivering error undefined 404",
  "timestamp": "2021-02-26T16:21:23.004791106Z"
}

the action name has the internal version number, not the external one.

oops :-)


Non-deterministic behavior

I ran a performance test on this package and incidentally found that the results of the root finding are not deterministic (the performance results are great, btw).
If I run the code below 200000 times there are usually one or two cases when the algorithm fails to find the real root, Sometimes none of the found roots is not even close to the correct result, which is at 0.409458563186124. Changing tolerance values did not help so far.
for (let i = 0; i< 200000; i++) {
     window.r = [];
     let r = findRoots([1, 9, 36, 69, 36, -2043, 3747, -7092, 5328, -3520]);
     let realR = [];
     for (let j = 0; j < r[0].length; j++) {
         if (Math.abs(r[1][j]) < 1e-10) {
             realR.push(r[0][j]);
         }
     }
     if (realR.length == 0) {
         console.log("failed", r, window.r);

     }
 }
 console.log("done")

This non-deterministic if caused by the use of Math.random(). I recorded the generated random values to see if they are special in the failing cases, but I could not see a pattern at all.
My question are

Can I do something to make the algorithm fail less often?
Is it possible to make the algorithm deterministic?
Is there a better algorithm for my case (only real roots needed, always polynomials of degree 9)

Hi @waruyama even though I am neither an author of this library nor am I sure that my suggestion is fail poof, so take this with a grain of salt, I think I have an idea. You can make this determenistic by supplying the initial guesses. As you wrote the library uses Math.random for the guesses which results in your problem.
You could pick the initials by using the same conditions as was done in the wikipedia article:
(0.4 + 0.9i)^0 ==  1          + 0i
(0.4 + 0.9i)^1 ==  0.4        + 0.9i
(0.4 + 0.9i)^2 == -0.65       + 0.72i
(0.4 + 0.9i)^3 == -0.908      - 0.297i
(0.4 + 0.9i)^4 == -0.0959     - 0.936i
(0.4 + 0.9i)^5 ==  0.80404    - 0.46071i
(0.4 + 0.9i)^6 ==  0.736255   + 0.539353i
(0.4 + 0.9i)^7 == -0.1909148  + 0.8783703i
(0.4 + 0.9i)^8 == -0.86689919 + 0.1795248i

So you would call findRoots like this:
const guessR = [
     1,
     0.4,
    -0.65,
    -0.908,
    -0.0959,
     0.80404,
     0.736255,
    -0.1909148,
    -0.86689919
];

const guessI = [
     0,
     0.9,
     0.72,
    -0.297,
    -0.936,
    -0.46071,
     0.539353,
     0.8783703,
     0.1795248
];

const coeffR = [1, 9, 36, 69, 36, -2043, 3747, -7092, 5328, -3520];

findRootsNpmPack(coeffR, undefined, undefined, undefined, guessR, guessI);

Which would result in the following, rounded, results:
 0.4095 + 0.0000i
 0.5638 + 0.8316i
-0.0407 + 0.2083i
-0.0407 - 0.2083i
 0.1703 - 0.7626i
 0.5638 - 0.8316i
-0.1413 - 0.0709i
 0.1703 + 0.7626i
-0.1413 + 0.0709i

As I said I am not sure if this would hold up for all possible coefficients but it at least gives you a function which either fails or works correctly. Another idea would be to create two or three sets of initial guesses which could be used when the previous failed.
For your third point you could take a look here https://en.wikipedia.org/wiki/Root-finding_algorithms#Finding_all_roots_at_once because I don't think that there is a closed form for a polynomial of grade 9 so you would always rely on an iterative approximation.


Use nteract for IPyWidgets

Closing this, as i don't think its a good idea given the complexity of widgets


[Return null if source array is blank]

If a blank array is passed in each method, the method should return a null and should not set the filed for which the transformation is called.
var source = {
  "foo":"bar",
  "fooArray": []
};

var mapper = createMapper();

var arrayMapper = createMapper();

arrayMapper
  .map("foo");

mapper
  .map("foo")
  .map("fooArray").to("array", function(array){
    return arrayMapper.each(array);
});

Actual Result
{
  "foo": "bar",
"fooArray": []
}

Expected Result
{
  "foo": "bar"
}

Yeah, this looks like the correct behaviour. mapper.each should be able to be used without doing additional null checks. A one-liner is what we want for child mappers.


Route params is empty when reloading on the path

Steps to Reproduce

Create a getter named route function return state.route
The render it on a component using mapGetters(['route'])

What is expected
Route Params must have properties
###What happened
Route params is empty

As always, please provide a minimal reproductionon jsfiddle or a smiliar service, or we can't work on this.

wait ill make it

dont know if i can do this in jsfiddle

cause you need to refresh it

@LinusBorg https://jsfiddle.net/9curL4re/11/
Here is the jsfidde i don't know if this would work cause the reproduction step is to be on a nested route with a param for example
locahost/test/testParam
so the result will give route.params object in vuex-router-sync not to be empty

I think you need to set this up on a simple vue environment

No, you need to set this up in a simple vue environment and share the repository with me.
We really like to help, but in many, many cases, the actual problem was a mistake by the user, so we can't afford to build reproductions of *descriptions of the problem ourselves.
The users have to provide it, so we can clone and test is immediatly.


vendor: google.golang.org/grpc v1.57.1

server: prohibit more than MaxConcurrentStreams handlers from running at once (CVE-2023-44487).
In addition to this change, applications should ensure they do not leave running tasks behind related to the RPC before returning from method handlers, or should enforce appropriate limits on any such work.

https://github.com/grpc/grpc-go/compare/v1.57.0...v1.57.1

/retest-required


Inplace_abn not work for nshot=1

Hi,
when training for nshot=1,
I encounter the error inplace_abn is trying to compute batch statistics, but the input tensor only contains a single sample per channel.
The BatchNorm seems to raise error when batch size=1. Could you please suggest a solution for this problem?
Thanks.

No worries, I figure out the no_pooling option.

Yep, I should have commented it in the scripts :)


Expire @Async healthchecks results after a period of time.

Fixes #1335. Typical use case is thread starvation preventing the next async healthcheck to run.

Looking at the build failures:

Travis build seems to be broken on 4.1-development. It does not seem related to this PR
Codeclimate complains about duplication, however I believe I'm following the general style of unit tests in this project. I can refactor and deduplicate more if needed, but it will come at the cost of readability for the unit tests.


Is there any way to modify the connection settings (e.g. set ARITHABORT on)

When EF talks to the SQL server, it sets the following settings with the “Audit Login” event (visible in SQL Server Profiler):
-- network protocol: LPC
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed

Is there any way to modify these settings before executing a query? In my case, I would like to enable ARITHABORT, since I am using a (apparently broken) stored procedure and with the setting being turned off, I just get a timeout because it never completes.
I tried doing a db.Database.ExecuteSqlCommand("SET ARITHABORT ON;"); before the query but EF resets the connection automatically afterwards restoring its settings.

You may be able to set it per user/server http://dba.stackexchange.com/questions/2500/make-sqlclient-default-to-arithabort-on

EF isn't explicitly sending this, it's the underlying SQL Client ADO.NET provider that sets all these transparently to the caller. One option would be to create your DbConnection externally and then pass it to your context.

I guess that is good enough. Interestingly, the problem I had suddenly disappeared on its own, so I no longer need to modify this. But if this is inherited automatically from the connection, then I guess it isn’t necessary EF’s job :)

I have the same problem with ADO.NET provider setting this. Is there any example of overriding these settings?

@dark2201 You're probably better off asking in https://github.com/dotnet/corefx (which is where SQLClient lives) or on Stack Overflow.


Implement v1alpha2 UpdateResult

The logic is basically the same as the v1alpha1 version. The only one
difference is there isn't executions field in the Result definition,
so the UpdateResult function won't tackle that field anymore, instead,
UpdateRecord will take charge.

/retest

/hold
Looks like a lot of changes in https://github.com/tektoncd/results/pull/19 still remain here, so holding until that is resolved.

move to another PR #25


[Feature Request]: Ability to configure PSRepository on a system-wide level

It would be great if there was a way to register a PSRepository on the system-wide level, so that if configured once, it would work for all the users on a particular system.
Expected Behavior
Register-PSRepository should have a -Scope parameter added, to control whether a particular PSRepository needs to be registered for just the current user of for the whole system (similar to the behavior of Execution Policy). It would also be great to have an extra scope option, that would register PSRepository just for the current session (like mentioned in PowerShell/PowerShellGet#65)
Apart from the Register-PSRepository, the remaining set of the *-PSRepository cmdlets should also have the -Scope parameter. Set-PSRepository and Unregister-PSRepository cmdlets should require admin privileges to work against system-wide PSRepository settings and 'Get-PSRepository' cmdlet should not require admin privileges at all.
Current Behavior
Currently Register-PSRepository only works for the user that is executing the cmdlet.
Context
Having an ability to register PSRepository on a system-wide level would allow us to pre-configure our internal Repositories in the Virtual Machine templates, thus making the provisioning process much simpler.
Additionally, that would simplify maintaining existing PSRepository configurations in a consistent fashion across all our systems.
Your Environment

PS C:\Users> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15063.726
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.726
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

PS C:\Users>
PS C:\Users> Get-Module

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   <IP_ADDRESS>    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Script     1.2        PSReadline                          {Get-PSReadlineKeyHandler, Get-PSReadlineOption, Remove-PS...

PS C:\Users>
PS C:\Users> Get-Module -ListAvailable PowerShellGet,PackageManagement

    Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     <IP_ADDRESS>    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Script     <IP_ADDRESS>    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Binary     <IP_ADDRESS>    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Script     1.6.0      PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Module...}
Script     <IP_ADDRESS>    PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Module...}
Script     <IP_ADDRESS>    PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Module...}

    Directory: C:\Program Files (x86)\WindowsPowerShell\Modules

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Binary     <IP_ADDRESS>    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Script     <IP_ADDRESS>    PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Module...}

PS C:\Users>
PS C:\Users> Get-PackageProvider

Name                     Version          DynamicOptions
----                     -------          --------------
msi                      <IP_ADDRESS>          AdditionalArguments
msu                      <IP_ADDRESS>
NuGet                    <IP_ADDRESS>        Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag...
PowerShellGet            <IP_ADDRESS>          PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, ...
Programs                 <IP_ADDRESS>          IncludeWindowsInstaller, IncludeSystemComponent

PS C:\Users> Get-PackageProvider -ListAvailable

Name                     Version          DynamicOptions
----                     -------          --------------
msi                      <IP_ADDRESS>          AdditionalArguments
msu                      <IP_ADDRESS>
nuget                    <IP_ADDRESS>
NuGet                    <IP_ADDRESS>        Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag...
NuGetProvider            <IP_ADDRESS>
PowerShellGet            <IP_ADDRESS>          PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, ...
PowerShellGet            <IP_ADDRESS>
PowerShellGet            <IP_ADDRESS>
Programs                 <IP_ADDRESS>          IncludeWindowsInstaller, IncludeSystemComponent

@SydneyhSmith any chance this can be added to 3.0? This is a huge missing feature when using in a multi-user environment.

Any updates on this?  Our job scheduling tools uses temporary user profiles so full automation of things that utilize that tool is not possible unless I use @KevinMarquette's solution, which I'd like to avoid.

Hello,
Is there any update on this topic ? Rgis is a much needed feature for as my configuration manager runs as system, I cannot register PSRepositories / install modules

Also plus 1. Definitely needed for enterprises trying to run private repositories.

Thanks all!  We'll definitely prioritize this scenario since it's been a popular request

+1 for this feature!

+1 for this feature!

Make that + 2!

Tracking this feature work in https://github.com/PowerShell/PowerShellGet/issues/616

+1!

Would love to see this in an upcoming release as we would like to push out a default configuration to all of our workstations/servers to point at our PowerShell repositories in Artifactory. I see it was included in 3.0 then pulled out?

Faced this issue today as well, so seems still relevant.


Add commit message linting

Implement commit message linting that asserts the following rules

Separate subject from body with a blank line
Limit the subject line to 50 characters
Capitalize the subject line
Do not end the subject line with a period
Wrap the body at 72 characters
Must include 'Relates to: #' or 'Resolves: #' on its own line

Resolves: #122

Pull Request Test Coverage Report for Build 686

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 41.477%

Files with Coverage Reduction
New Missed Lines
%

internal/dtls/dtls.go
1
18.25%

Totals

Change from base Build 678:
0.0%

Covered Lines:
2448

Relevant Lines:
5902

💛  - Coveralls

Pull Request Test Coverage Report for Build 686

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 41.477%

Files with Coverage Reduction
New Missed Lines
%

internal/dtls/dtls.go
1
18.25%

Totals

Change from base Build 678:
0.0%

Covered Lines:
2448

Relevant Lines:
5902

💛  - Coveralls


Defaulting to require vhost-net

/kind bug
What happened:
Launching a VM on minikube using 0.9.2.
It failed to schedule, because devices.kubevirt.io/vhost-net was not available on nodes.
This is because the vhost-net module is not available on minikube.
The underlying issue is that wedefault to virtio, and if virtio is used, then vhost-net is expected (aka a sched requirement).
I'd recommend to keep defaulting to virtio, but have a soft requirement to need vhost-net.
Maybe using affinity, or by only requiring vhost-net if it's set as a field somewhere.
What you expected to happen:
The VM could start without an issue.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version):
Kubernetes version (use kubectl version):
VM or VMI specifications:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

/cc @yuvalif @SchSeba @booxter

@fabiand , perhaps this is something that the admin can disable in the config (kubevirt-config) - because this is likely to be a cluster-wide issue. I don't expect such mixed nodes...
Otherwise, how would the user specifically ask for vhost (it's not just vhost-net, it can be any vhost (blk, scsi))?
Another way is to let the user specify vhost-net instead of virtio on the interface API or introduce a driver section there.
I'd prefer to disable vhost in kubevirt-config

Sounds good using the cluster wide config.

Sounds good using the cluster wide config.

@fabiand I'll get it fixed then.

@vladikr well we agreed on the PR that one can set emulation in the config-map https://github.com/kubevirt/kubevirt/pull/1567#issuecomment-426320536. Basically saying that if you want to do serious virtualization it has to be present (except if you  explicitly don't want virtio on the interface). For demoing purposes it got explicitly tied to the emulation setting in the kubevirt config-map. So at least it works as expected.

What are your expectations here @fabiand ?
Currently, by setting the useEmulation flag in the config map users can avoid using the vhost driver. (as @rmohr  mentioned above)
From my point of view, it should be sufficient.

Hm.
Fair enough.
The issue is that minikube supports nesting, but has no vhost-net support.
Thus here we'd be bound to use emulation even if nesting is available.
The escape hatch is to always use something else than vhost-net.
Good enough for the moment I guess. Thus closing ti.
/close


Reading PDF file from cloud storage (GCS)

Hi there,
Came across SimpleDirectoryReader which lets you read in a file, given the file path.
I have files that I store on cloud (Google Cloud Storage) that I fetch from. Is there a way to use SimpleDirectoryReader without the path that's required, but instead provide the file itself?
Currently I workaround it with the following by parsing myself and providing the documents to GPTSimpleVectorIndex.

@ctle-vn do you mean providing the file name instead of folder name? yeah you can do that by specifying input_files kwarg e.g.
reader = SimpleDirectoryReader(input_files=["path/to/downloaded/file.ext"]).load_data()

Hey @jerryjliu thanks for the reply.
More like having the actual file in memory, this is the function header:
def generate_embeddings_with_pdf_filer(file: UploadFile) -> None:
am i able to pass the file directly in?

Hey @jerryjliu thanks for the reply.
More like having the actual file in memory, this is the function header:
def generate_embeddings_with_pdf_filer(file: UploadFile) -> None:
am i able to pass the file directly in?

Ah got it. At the moment no :/  we do have an s3 reader on llamahub, but that also just downloads files to a temp directory and uses SimpleDirectoryReader too

Got it got it, thanks for the reply!


feat(#47): blog post about recursive tuple and varargs

Closes: #47

PR-Codex overview
Detailed summary

Added a new recursive implementation of the tuple object in EO.
Removed varargs from the language to align with φ-calculus.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@yegor256 please have a look

@rultor merge

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 2min)


refactor(frontend): change interfaces method names

:tada: This PR is included in version 3.0.8 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


go fmt

@pietdevaere apparently doesn't believe in go fmt.  My editor won't save without doing it and I can't be bothered to work out how to disable it.  So here you go: the proceeds of running go fmt.

There's a difference between disregard and ignorance :smile:


LoadMode.AUTOMATIC does not seem to work as documented

If I understand the documentation correctly, LoadMode.AUTOMATIC should:

Use an existing manifest.json file if it exists
Otherwise run dbt ls which will both provide the necessary data for the run and trigger the creation of manifest.json which should be used for the next run.

I tried to get it to work this way but haven't been succesfull:

if I use:ProjectConfig(dbt_project_path=self.project_dir, manifest_path=self.project_dir / "target/manifest.json")

It works as expected if the manifest path file already exists, but fails otherwise with the following exception:cosmos.exceptions.CosmosValueError: Could not find manifest at /dbt/target/manifest.json

And, if I use:ProjectConfig(dbt_project_path=self.project_dir)

It works as expected if the manifest path file doesn't exist (runs dbt ls, manifest.json is created), but subsequent runs never make use of the existing manifest.json file and systematically call dbt ls

This is actually consistent with my understanding of the code:

DbtGraph.load first checks the existence of a manifest file, which in turns expect ProjectConfig.manifest_path to be explicitly defined (by the way, I think this should be explicitly defined as a requirement for leveraging LoadMode.AUTOMATIC):
https://github.com/astronomer/astronomer-cosmos/blob/cda2a5058bb3c95f1c2e1b9a5352f8ceb7b22f6a/cosmos/dbt/graph.py#L174-L184
ProjectConfig.validate_project checks the existence of the manifest file if ProjectConfig.manifest_path is defined, and this is called before calling DbtGraph.load in DbtToAirflowConverter.__init__, which means that self.load_via_dbt_ls() will never get a chance to be executed.
https://github.com/astronomer/astronomer-cosmos/blob/cda2a5058bb3c95f1c2e1b9a5352f8ceb7b22f6a/cosmos/config.py#L195-L206

Hi @ghjklw , thanks for posting this.
The current behaviour is per design and consistent with the documents. Cosmos does not change the original dbt project folder, hence it does not add the manifest to that folder. This is because many users have their dbt project available in a read-only path.
To make the documentation clearer, perhaps we could change:
Use an existing manifest.json file if it exists

By:
Use the `manifest.json` file if it exists in the original dbt project directory (Cosmos does not create this for users)

What do you think?
We could also consider allowing users not running in a read-only filesystem to execute all the dbt commands from the original dbt folder. From what I've seen, sometimes multiple processes running different dbt commands from within the same folder/with the same target folder will occasionally fail. That said, some users may be fine with this - and can rely on retries. Do you have any thoughts on this possibility?

Hi @tatiana,
Thanks for your response! It sounds like I misunderstood slightly the feature: I observed that when I Cosmos ran, the target directory (defined through DBT_TARGET_PATH) was populated and a manifest.json file was created. I however noticed that this is not true if DBT_TARGET_PATH is not defined. That is fine!
I support the rewording to clarify that "Cosmos does not create this for users", but is it really true that it will use "manifest.json" from the original dbt project directory, but the one define in ProjectConfig.manifest_path
I however still believe that the feature does not behave as documented:

Tries to find a user-supplied manifest.json file. If it can’t find one, it will run dbt ls to generate one. If that fails, it will use Cosmos’ dbt parser.

If I define ProjectConfig(dbt_project_path=self.project_dir, manifest_path="/cache/dbt/target/manifest.json")
And if I make sure that the directory /cache/dbt/target/ is empty
Then I would expect Cosmos to work and run dbt ls
Instead I get the following error message: cosmos.exceptions.CosmosValueError: Could not find manifest at /cache/dbt/target/manifest.json

I ran a serie of tests, here is a summary of them:

ProjectConfig.manifest_path
manifest.json exists
Result
Parsing method used
Comment

/cache/dbt/target/manifest.json
Yes, in /cache/dbt/target/manifest.json
OK
manifest.json
As expected

/cache/dbt/target/manifest.json
No
cosmos.exceptions.CosmosValueError: Could not find manifest at   /cache/dbt/target/manifest.json
None
Would have expected using dbt ls parsing

/cache/dbt/target/manifest.json
Yes, in ${DBT_PROJECT_DIR}/target/manifest.json
cosmos.exceptions.CosmosValueError: Could not find manifest at   /cache/dbt/target/manifest.json
None
Would have expected using dbt ls parsing, also does not match with your  proposition for doumentation: "in the original dbt project directory"

None
No
OK
dbt ls
As expected

None
Yes, in ${DBT_PROJECT_DIR}/target/manifest.json
OK
dbt ls
As expected, but should be documented explicitly that manifest.json won't be used if ProjectConfig.manifest_path is not defined.

To clarify the context and what I am trying to achieve: I run Cosmos in mutliple Docker Airflow containers which all have a shared /cache directory mounted. I would like to generate and store manifest.json in this cache directory (I cannot run dbt ls to generate it at container build time). The ideal solution would be that the first instance of Cosmos running generates manifest.json in a location within /cache.
I actually manage to get Cosmos to generate manifest.json and store it where I want by setting DBT_TARGET_PATH. It would actually be a nice feature to be able to set thet target path through ProjectConfig 😉. Do you want me to create a separate feature request to discuss it?
This means that what I'm trying to do could be achieved by setting DBT_TARGET_PATH=/cache/dbt/target and ProjectConfig(dbt_project_path=self.project_dir, manifest_path="/cache/dbt/target/manifest.json") if these 2 lines were removed:
https://github.com/astronomer/astronomer-cosmos/blob/cb2a27a764ab8bfbf4e706678c3be2382da7747c/cosmos/config.py#L201-L202
I think this is the core issue: testing for manifest_path existence does not make sense unless the parsing method is LoadMode.DBT_MANIFEST, and especially not for LoadMode.AUTOMATIC.

If I try to phrase the problem in another way, looking at the code snippet below:
https://github.com/astronomer/astronomer-cosmos/blob/cb2a27a764ab8bfbf4e706678c3be2382da7747c/cosmos/dbt/graph.py#L174-L184
if ProjectConfig.manifest_path is defined, lines 178-184 will never be reached because:

Either the file exists, and it is used, as expected.
Or the file does not exists and ProjectConfig.validate_project will fail before this whole block of code is reached, thus never getting a chance to run self.load_via_dbt_ls(). I don't understand why it would be that way.

@ghjklw A few notes:
Fixes
Quick hacky fix to get what you want

This means that what I'm trying to do could be achieved by setting DBT_TARGET_PATH=/cache/dbt/target and ProjectConfig(dbt_project_path=self.project_dir, manifest_path="/cache/dbt/target/manifest.json") if these 2 lines were removed:

OK, in that case, for your purposes you can just do the following:

class CustomProjectConfig(ProjectConfig):

    def validate_project(self) -> None:
        # noop
        pass

And you'll be all set 😉
Another way to get what you want
I highly recommend, for your purposes, looking into the DBT_MANIFEST mode. Basically, run dbt parse in CICD and upload the DAG directory code with the manifest.json having already been parsed. This won't work for 100% of setups, but it should work for like 99% of them, and it will make your life easier compared to parsing this way.
We are currently working on some of our own caching stuff (see the "Some paths forward...?" section below for more details.) Caching the manifest is never going to be perfect because Airflow is designed to be a distributed system with ephemeral runtimes for each component. Each scheduler's filesystem is going to be temporary. And even once caching is stable, the initial dbt parse invocation will risk slowing the scheduler to a halt.
For that reason, I personally think it is a lot better to build the manifest prior to deploying Airflow. I wish the docs outright said this, I believe the #airflow-dbt Slack channel and the Issues tab here on Github would have fewer things in them if we had the courage to be a little more opinionated in telling people how to set stuff up. But the other project leaders are more weary than I am to be more opinionated in the docs.
The issue
Why things are the way they are
I'm generally in favor of not validating configs and just running things. That's the ethos of dynamically typed code. So part of me thinks the whole validate_project() project thing is a minor anti-pattern.
The problem is Cosmos is really complex and confusing. The validate_project() method prevents footguns for most users, and it turns cryptic error messages into more legible error messages. So it restricts some edge case functionality, but in exchange it helps the typical user. It is like whack-a-mole trying to address users' issues. This is a problem with Cosmos more generally and part of my mission is to fix it. But fixing it means, on net, more not fewer of these types of LBYL validations.
Furthermore, I would argue that validating the existence of the manifest.json also makes some sense to me given two things:

the assumption it will be hitting a read-only path and thus needs to be built in a separate system. This was already addressed by @tatiana.
the fact that invoking a subprocess to run dbt ls is very resource intensive. Here is the issue: You set your manifest.json and you have automatic mode turned on. But you misconfigure it such that manifest.json is not there. If we try/except a dbt ls invocation, for some users this could crawl their scheduler to a halt. 😬

This is not to say we can't change the behavior, but that at the very least I think the behavior makes sense on some level.
Some paths forward...?
First of all, and most importantly, we are working on caching dbt ls invocations in the scheduler in 1.5.0, and this will be on top of caching dbt [cmd] command executions in worker nodes during task execution. This means you would not need to build your own caching functionality.
That is to say, your issue is being address, albeit a little indirectly.
Second of all, we could do what you suggest and basically have automatic mode try-except the filepath's existence, rather than just failing outright. I'm not totally against it. If we do this however, I think we need to make a very clear warning message in not only the scheduler logs but also the UI when this occurs.  Basically, our philosophy would be: "we won't say you can't do this but we will discourage you from doing it."
Regardless of which of the above options we pick, I think a few more things should happen:

I think Cosmos could probably check to see if {project_dir}/target/manifest.json exists even when the user does not specify the path. I think it could make configuration slightly simpler.
We need to introduce composability into the DbtGraph API 😬 I think your issue would be less of an issue if there was a clear path for you to override a few things and, voila, your issue is solved.


New Post wysiwyg [bug]

Wysiwyg has broken representation on Chrome 50.0.2661.102 (64-bit)

Hello, is this issue fixed? Checking if we can close it.

Closing for comment on duplicate issue #92


ForbiddenMethodCall>methods allow yaml list

This PR is one in a serie of PRs to implement #2498

Codecov Report

Merging #2612 into master will increase coverage by 1.70%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #2612      +/-   ##
============================================
+ Coverage     25.28%   26.99%   +1.70%
+ Complexity      396      394       -2
============================================
  Files           379      379
  Lines          7438     6742     -696
  Branches       1225     1224       -1
============================================
- Hits           1881     1820      -61
+ Misses         5428     4793     -635
  Partials        129      129

Impacted Files
Coverage Δ
Complexity Δ

...turbosch/detekt/rules/style/ForbiddenMethodCall.kt
46.66% <100.00%> (+2.91%)
1.00 <0.00> (ø)

...itlab/arturbosch/detekt/api/internal/Validation.kt
33.33% <0.00%> (-16.67%)
0.00% <0.00%> (ø%)

.../gitlab/arturbosch/detekt/cli/console/Colorizer.kt
61.53% <0.00%> (-9.90%)
0.00% <0.00%> (ø%)

...h/detekt/api/internal/DisabledAutoCorrectConfig.kt
55.55% <0.00%> (-8.09%)
4.00% <0.00%> (ø%)

...otlin/io/gitlab/arturbosch/detekt/core/TaskPool.kt
33.33% <0.00%> (-6.67%)
3.00% <0.00%> (ø%)

...in/io/gitlab/arturbosch/detekt/api/SingleAssign.kt
60.00% <0.00%> (-6.67%)
3.00% <0.00%> (ø%)

...in/kotlin/io/gitlab/arturbosch/detekt/api/Issue.kt
50.00% <0.00%> (-5.56%)
2.00% <0.00%> (ø%)

...n/io/gitlab/arturbosch/detekt/api/ConsoleReport.kt
75.00% <0.00%> (-5.00%)
4.00% <0.00%> (ø%)

...tlab/arturbosch/detekt/api/internal/EmptyConfig.kt
66.66% <0.00%> (-4.77%)
4.00% <0.00%> (ø%)

...in/io/gitlab/arturbosch/detekt/cli/OutputFacade.kt
77.77% <0.00%> (-4.05%)
5.00% <0.00%> (ø%)

... and 260 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2ee023d...8ab4d03. Read the comment docs.


Add "_id" attributes to many data classes

FYI: Needs Scrivito 1.41.0 (not yet released).

Which criteria do we use to decide if an ID should be part of the editing config or not?

Roughly: If one could want to filter for this attribute (e.g. look for the user of the current ticket). But since this can't be completely known for all cases I would say: Add _id Attributes for all data classes, except for n:m relation ship data classes.


Split up keyword.other and remove unnecessary comments.

Tested locally, and I didn't immediately see any problems, but given the scope of the change I'm not sure I can say I'm certain it doesn't break anything.
Also since this change deletes comments, I'd like to give @carols10cents a few days to comment on whether she thinks deleting comments is something we want to do.


fix: replace hard-code learn URL with .env value

Pre-Submission Checklist

[x] Your pull request targets the staging branch of freeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[ ] Addressed currently open issue (replace XXXXX with an issue no in next line)

Closes #XXXXX
Description
The learn URL is currently hard-coded. This PR first checks if the LEARN_URL value has been provided by the .env file, and if not it reverts to the hard-coded value. This allows easy configuration of the learn URL for testing or for use with a custom learn platform.

Someone have stolen me from mine URL IN PARIS TEXAS 75460 CHARLES LEWIS NICHOLS

Been NOT TO GREAT ABOUT THERE LYING HERE.

Hi @tchaffee thanks a lot for the pull-request.
We are in the process of making learn available at https://www.freecodecamp.org/learn. Its still going to be a separate application, served by netlify. There are certain challenges involved.
We are working on them.
/cc @Bouncey

@tchaffee As @raisedadead mentioned, we are putting all of our subdomains into a single domain, and @raisedadead and I are under the impression that once we've done so your PR will no longer be necessary, so I am closing this. If we are mistaken, please re-open this and explain why. As always, thanks for your help!


How to use custom command line state machine tools like SCION CLI ?

Objective
Suppose we have The SCION command-line tool which may run SCXML file and execute events that are submitted from console input

What is possible now
Now we may only execute application with custom params

It is available to receive console output only

Feature request

grab output by regexp and highlight the corresponding states
pass events to application through console input pipes

Available since 2.1.8


Make cargo outdated part of cargo itself

In Rust ecosystem, one main concern for library developers is to not have semver breaking updates to their package, because of the fear that majority of the dependent packages not getting the routing updates that would follow a breaking update.
There are two general solutions to this problem:

The old-school back-porting of updates, so that dependents on any API version would get all the routine updates. This solution can easily become a huge maintenance cost on library developers and is not a common practice in the Rust community at the moment.

Help owner of dependent packages to update their dependency versions and apply the changes needed, if any. This solution can be much less time consuming, and distributes the workload throughout the dependency chain. It also means that only the versions being used get the maintenance work needed, but not all theoretically-possible versions. So, in rustacean words: you pay for what you use.

Based on this, I want to propose to add new features to help owners with keeping their dependencies up-to-date. Most of the functionality can be exposed via the cargo update command.
Proposed Features

Warn on dependencies stuck in older versions. This would be a plain warning on cargo update. The feature would be enabled by default, but there will be an option to disable it; and there can be one release version of Cargo as transition period, where the option is disabled by-default, but there's a notice about the upcoming change, if it applies.

Commands to auto-update some/all dependency versions to latest. This option would update the relevant manifests to use a latest version of a single or multiple packages. This can also be an option to cargo update, similar to --precise, but instead of updating the lock file, it would also update the manifest with the latest version, or some user-provided version.
This is a tool to update Cargo Manifest files. Currently, cargo update only works with the Cargo Lock file, so it may be a good idea to have a separate sub-command for the manifest manipulation features. But since it's a core functionality, it's better have this functionality in Cargo proper.

Auto-update versions to a successful build. This is something that we can aim for in longer term, to have cargo update dependencies, and in case of failures, bisect and find the most-recent version that does not break the builds and/or tests. Best place for this may be a third-party cargo command and not cargo itself.

What do you think?

I'm sure there are many examples where these can be helpful. Here's one that inspired me to write up this proposal: https://github.com/servo/unicode-bidi/issues/46#issuecomment-316778436
/cc @alexcrichton, @Manishearth, @anowell

I think we'd probably want to canvas what other package managers do here, e.g. do npm,  yarn, bundler, rubygems, pip, etc do anything like this? I was personally under the impression that this sort of concerns was typically farmed out to a third-party service.

Here’s a summary of similar features in some other package managers.

JS NPM
NPM CLI has built-in outdated subcommand that shows the status of packages that their current, wanted and latest versions do not match.
Like cargo update, the npm update does update the current version to wanted, if needed and possible.
It looks like that npm update does not have any more functionality in this area. Also, no other subcommand look related.
Ref: https://docs.npmjs.com/cli/outdated
Description
(from https://github.com/npm/npm/blob/latest/doc/cli/npm-outdated.md)
This command will check the registry to see if any (or, specific) installed packages are currently outdated.
In the output:

wanted is the maximum version of the package that satisfies the semver range specified in package.json. If there's no available semver range (i.e. you're running npm outdated --global, or the package isn't included in package.json), then wanted shows the currently-installed version.

latest is the version of the package tagged as latest in the registry. Running npm publish with no special configuration will publish the package with a dist-tag of latest. This may or may not be the maximum version of the package, or the most-recently published version of the package, depending on how the package's developer manages the latest dist-tag(1).

location is where in the dependency tree the package is located. Note that npm outdated defaults to a depth of 0, so unless you override that, you'll always be seeing only top-level dependencies that are outdated.

package type (when using --long / -l) tells you whether this package is a dependency or a devDependency. Packages not included in package.json are always marked dependencies.

Example
Edit package.json and add "underscore": "1.7" to dependencies list.
$ npm outdated
Package     Current  Wanted  Latest  Location
underscore  MISSING   1.7.0   1.8.3  underscore

$ npm install
<EMAIL_ADDRESS>node_modules/underscore

$ npm outdated
Package     Current  Wanted  Latest  Location
underscore    1.7.0   1.7.0   1.8.3  underscore

Ruby Gems
Gems CLI has built-in outdated subcommand to “display all gems that need updates”.
Ref: http://guides.rubygems.org/command-reference/#gem-outdated
Description
(From ref.)
The outdated command lists gems you may wish to upgrade to a newer version.
You can check for dependency mismatches using the dependency command and update the gems with the update or install commands.

Ruby Bundler
Bundler CLI has built-in outdated subcommand to “list installed gems with newer versions available”.
Ref: https://bundler.io/v1.11/bundle_outdated.html
Description
(From ref.)
Outdated lists the names and versions of gems that have a newer version available in the given source. Calling outdated with [GEM [GEM]] will only check for newer versions of the given gems. By default, available prerelease gems will be ignored.

In summary:

JS and Ruby package managers have built-in outdated subcommand to list packages "not in good standing", in the meaning that their installed version is not what's asked for, or what's asked for is not the latest upstream version (not necessarily the largest one, but the latest marked as stable release).

Python PIP has similar functionality via the built-in list subcommand, which makes it more generic, but harder to discover and use for beginner/average users.

Looks like all these commands are readonly and have no built-in functionality to update manifest files to the latest version.

I have not seen signs of any warning-like functionality regarding out-of-date packages in other commands.

So, IMHO, we can plan to for these functionalities, applicable only to direct dependencies of a package/workspace.
a) A built-in outdated command to help developers find outdated direct dependencies. This would be the readonly and the human-readable output will be similar to the JS/Ruby package managers.
b) Expand (a) to support workspaces.
c) Add options to outdated to make it read-write, updating version numbers of one/more/all outdated dependencies. This, I assume, would be the only/first cargo command to write to the manifest, so would need more design and implementation work.
d) Expand (c) to also support workspaces.
These two can be enough for shell scripts and third-party cargo commands to easily build automations for stable upgrades, meaning that run the tests with single upgrades and revert if there's compile or test errors.
What do you think?

https://crates.io/crates/cargo-outdated works well today

Unfortunately, cargo-outdated package doesn't have any support for workspaces, yet.
Also, a question would be about the original proposal to add optional warning (possibly as an opt-in, via env-var and/or cli option) for cargo update about existence of outdated package(s). I'd like to know how everyone feels about that.

I'd be totally down for adding native outdated support in Cargo itself, but we'd probably want to work closely with the upstream author of cargo-outdated to ensure we coordinate. I know I use it often enough!

Also thanks so much for doing that investigation @behnam, it's quite helpful!

A big +1 for getting cargo outdated built-in.
I've been using cargo-outdated for ages now but as @behnam says, it doesn't support workspaces yet and I use so much with yarn and pip that I believe it should be part of Cargo.
Just to update the yarn output, it actually looks like the following:
Package            Current       Wanted  Latest  Package Type    URL
@types/lodash      4.14.70       4.14.71 4.14.71 devDependencies https://www.github.com/DefinitelyTyped/DefinitelyTyped.git
@types/react       15.0.38       15.0.39 15.0.39 devDependencies https://www.github.com/DefinitelyTyped/DefinitelyTyped.git
gulp               4.0.0-alpha.2 exotic  exotic  devDependencies gulpjs/gulp#4.0
signature_pad      2.2.0         2.2.1   2.2.1   dependencies    https://github.com/szimek/signature_pad
webpack-dev-server 2.5.1         2.6.1   2.6.1   devDependencies http://github.com/webpack/webpack-dev-server
Done in 2.27s.

Having the URL in the output is quite nice to be able to see the changes too. Separating the dev-dependencies, build-dependencies and dependencies more cleanly than yarn does would be nice too but then it might become too complex to display with workspaces.
One change to do compared to cargo-outdated that is already mentioned is that imo, it should only list direct dependencies of the project, not subdependencies. Here's an example on one of my projects:
    Name             Project Ver  SemVer Compat  Latest Ver
    hyper               0.10.12        --          0.11.1
    hyper->base64       0.5.2          --          0.6.0
    hyper->mime         0.2.6          --          0.3.2
    hyper->unicase      1.4.2          --          2.0.0
    slug->unidecode     0.2.0          --          0.3.0

I only care about hyper in that list.
If we want to go c) I would recommend checking the yarn upgrade-interactive command as an example of how to handle it.
I'd be interested to do the implementation if that ends up being accepted for cargo!

Good ideas, @Keats!

Having the URL in the output is quite nice to be able to see the changes too.

Agreed.
Also, on a similar note, a --verbose option that shows you also all in good standing, telling you what's been in the check list.

Separating the dev-dependencies, build-dependencies and dependencies more cleanly than yarn does would be nice too

I'm not sure what build-dependencies is here. But, about dev-dependencies, agreed that sometimes it's not a concern and better be able to leave it out of calculation. So, maybe we need a set of options to disable each group of these dependencies.

but then it might become too complex to display with workspaces.

Actually, I think the readonly functionality won't be that complex for workspaces, since there's expected to be one Cargo.lock already.
But, it's a good reminder that we also need something like NPM's location, which shows which local (in the workspace) package is depending on the old version.
And as a plus, this would be Cargo's internal tool to warn on a workspace (or even a package) having direct dependencies on multiple versions of a single package.

it should only list direct dependencies of the project, not subdependencies.

Exactly. I'm not sure if we want a feature to perform these checks more than one level depth. I think we can start with direct deps and see if there's demand for an option to extend.

I'd be interested to do the implementation if that ends up being accepted for cargo!

Awesome! I won't be able to get to this in the next few weeks, but can help with some tests and reviews, if needed.

So, looks like we have general consensus on the core functionality of a built-in outdated subcommand and there rest can be discussed per PR, I assume.
Also, let's CC author of cargo-outdated. @kbknapp, what do you think about these?

I'm not sure what build-dependencies is here. But, about dev-dependencies, agreed that sometimes it's not a concern and better be able to leave it out of calculation. So, maybe we need a set of options to disable each group of these dependencies.

Build dependencies would be bindgen for example: https://github.com/compass-rs/sass-rs/blob/master/sass-sys/Cargo.toml#L16
Dev dependencies is important to display in JS-land since I have more dev dependencies than actual dependencies but I think it still makes sense to display outdated info for all crates listed in my Cargo.toml by default. We could have a flag to disable build/dev dependencies but I don't think it would be used very often: if you run cargo outdated, you usually want to see all of the crates.

Actually, I think the readonly functionality won't be that complex for workspaces, since there's expected to be one Cargo.lock already.

My worry was more on how to display it well in the terminal when you have many workspaces like habitat. I guess scrolling a bit is not a huge issue

Agreed, @Keats. :)
Funny thing about build-dependencies: I could tell what it is, but didn't find it anywhere under the manifest reference: http://doc.crates.io/manifest.html. Turns out, it's only  mentioned in this other page: http://doc.crates.io/specifying-dependencies.html#build-dependencies I'll submit a PR to add it to the list in http://doc.crates.io/manifest.html#dependency-sections so it doesn't happen again.

@alexcrichton, is this something that needs an RFC, or we can go ahead with the general consensus here and start the implementation?
If no RFC, I suppose we can create a new tracker issue for the built-in cargo outdated subcommand with the details, and leave this issue for discussion of other related matters, like the proposed warning on cargo update when there are packages staying behind.

Sorry all, I just saw this! I'm totally fine with adding a native cargo outdated command! 😄 I haven't had much time to work on my open source projects lately due to my day job, but @Frederick888 has stepped up to help with cargo-outdated specifically.
The biggest thing I see that needs to happen for cargo-outdated (native or third party) is to add workspace support.
@Keats

I only care about hyper in that list.

cargo-outdated (third party subcommand) currently has the -R, --root-deps-only or --depth=# options that does exactly what you're looking for.
There's also -r, --root=PKG to treat a particular package as the root, and finally -p, --package=PKG to only look for updates for a particular package/crate. All of which should be combinable as well.

Slightly off topic, this sort of brings up the topic of third party subcommands moving closer to native commands, and if there's an official method or place for this to happen? Similar to how libs move to the nursery, is there a place where third party subcommands can move closer to cargo itself, perhaps even distributed by default? There are times where that may be less work than re-implementing functionality. I understand with outdated it may be easier to just duplicate the functionality inside cargo, but I highly doubt this is the last time this sort of situation will come up. Just thinking out loud. :wink:

I only care about hyper in that list.

cargo-outdated (third party subcommand) currently has the -R, --root-deps-only or --depth=# options that does exactly what you're looking for.

There are two reasons you might have an outdated dependency of a crate you use. Either the author hasn't upgraded yet, or you have the old version in your Cargo.lock file. cargo-outdated's SemVer Compat column should probably help here, but I could never figure out how it works, e.g.:
    Name                  Project Ver  SemVer Compat  Latest Ver
    rocket->base64           0.6.0        0.5.2           --

So from time to time I remove my Cargo.lock to get a new one.

@lnicola

I could never figure out how it works

We have just made a new release. Could you please test it again?
@kbknapp

Slightly off topic, this sort of brings up the topic of third party subcommands moving closer to native commands, and if there's an official method or place for this to happen?

Good point. Actually when I was refactoring cargo-outdated I struggled a lot about whether to add cargo as a dependency as it tended to be kind of an overkill (and would cost me plenty of time to read the documents). But now if we are talking about embedding the functionality into cargo itself, which is something that I'm also happy with, apparently depending on cargo is a better choice.
So yeah, it would be better to have such a guideline, or even a list of subcommand development suggestions to developers.

I was literally looking for a new version when you wrote that 😀.
Before:
    Name                  Project Ver  SemVer Compat  Latest Ver
    rocket->base64           0.6.0        0.5.2           --
    r2d2-diesel->diesel      0.15.1       0.15.2        0.15.2
    rocket->hyper            0.10.12        --          0.11.2
    time->libc               0.2.28       0.2.29        0.2.29
    uuid->rand               0.3.15       0.3.16        0.3.16
    time->redox_syscall      0.1.27       0.1.29        0.1.29
    toml->serde              1.0.10       1.0.11        1.0.11
    rocket->smallvec         0.4.1          --          0.2.1
    rocket_contrib->tera     0.10.8       0.10.9        0.10.9
    rocket->toml             0.4.2        0.4.4         0.4.4

After:
Name                         Project Ver  SemVer Compat  Latest Ver
backtrace->libc                 0.2.28       0.2.29        0.2.29
backtrace-sys->libc             0.2.28       0.2.29        0.2.29
diesel                          0.15.1       0.15.2        0.15.2
diesel_codegen->diesel          0.15.1       0.15.2        0.15.2
diesel_infer_schema->diesel     0.15.1       0.15.2        0.15.2
isatty->libc                    0.2.28       0.2.29        0.2.29
memchr->libc                    0.2.28       0.2.29        0.2.29
num_cpus->libc                  0.2.28       0.2.29        0.2.29
r2d2-diesel->diesel             0.15.1       0.15.2        0.15.2
rand->libc                      0.2.28       0.2.29        0.2.29
rayon-core->libc                0.2.28       0.2.29        0.2.29
rayon-core->rand                0.3.15       0.3.16        0.3.16
ring->libc                      0.2.28       0.2.29        0.2.29
rocket->toml                    0.4.2        0.4.4         0.4.4
rocket_contrib->serde           1.0.10       1.0.11        1.0.11
rocket_contrib->tera            0.10.8       0.10.9        0.10.9
serde                           1.0.10       1.0.11        1.0.11
serde_json->serde               1.0.10       1.0.11        1.0.11
tera->serde                     1.0.10       1.0.11        1.0.11
time->libc                      0.2.28       0.2.29        0.2.29
time->redox_syscall             0.1.27       0.1.29        0.1.29
toml->serde                     1.0.10       1.0.11        1.0.11
uuid->rand                      0.3.15       0.3.16        0.3.16

After removing Cargo.lock:
All dependencies are up to date, yay!

👍

After removing Cargo.lock:

@lnicola, are you saying that cargo update doesn't give you the same results? If so, can you be a bit more specific on in which circumstances that happens?

@behnam I actually had a copy of it, so I just tried cargo update on it. Looks like the results were the same ("All dependencies are up to date").
If you're asking why I said I remove Cargo.lock instead of running cargo update, there's no particular reason.

@Frederick888 Looking at my output, I think semver-breaking updates for dependencies are not reported anymore?
    rocket->hyper            0.10.12        --          0.11.2

@lnicola Actually it wasn't supposed to be reported. Previously if a package has multiple occurrences with different versions/semver requirements in the dependency tree, the program may misbehaviour from time to time.
cargo-outdated checks the "latest" version by replacing the semver requirements of direct dependencies with "*", which means it doesn't really give you the "latest released" versions of indirect ones. This is sometimes not quite intuitive and there's a related issue for this (kbknapp/cargo-outdated#25).

Previously if a package has multiple occurrences with different versions/semver requirements in the dependency tree, the program may misbehaviour from time to time.

I don't think that was the case for hyper in my example.

checks the "latest" version by replacing the semver requirements of direct dependencies with "*", which means it doesn't really give you the "latest released" versions of indirect ones.

I see. It might be useful to have those reported, so you know that your dependencies use older crates. But I don't feel too strongly about it.

Regarding making it easier for third-party libraries to use cargo internals, and make it easier to bring in third-party commands as built-in: maybe splitting cargo into smaller crates (in one repo, set up as workspace) would help?
Basically, I think reading and validating the manifest (with understandings of workspace and various dependencies) should be a separate library from the commands consuming the manifest to take actions.

There's a lot of discussion in this issue about many topics-- internals might be a better place for those discussions.
After reading through, it seems like the most focused issue here is moving cargo outdated in tree to become an officially supported command, so I've changed the issue title to reflect that.

I believe some of the confusion about "why doesn't cargo-outdated show me X" also stems from https://github.com/kbknapp/cargo-outdated/issues/134, which I just stumbled upon.

Is there any current progress on this? Does anyone know what the last status of this was in upstream?

Do we have an update for this? I like cargo-outdated though I think there should be a standardized sub-command inside cargo that checks package that are outdated. As new users would need to search for package just to run that certain functionality

Just leaving a note here that cargo tree was recently adopted into cargo proper in https://github.com/rust-lang/cargo/pull/8062, which, at least to me, indicates that it's not impossible the same may happen to cargo outdated if someone does the work.

cc @deg4uss3r

Thanks for the cc @kbknapp I'm in the middle of wrapping up at my current job, but I should be more free starting next week to really look into this :)

Hey, have you been able to look into this perchance?

@svenstaro Yes I have! Progress is moving slowly, but I am working on it :) starting the new job at the same time is tough though

Ok sweet, thanks for the update!

@deg4uss3r friendly ping :D

@svenstaro Thank you very much for keeping me honest!
So, I am working on this; however, I have been doing so offline because I see a lot of little things to improve on cargo-oudated that I would like to simply as a cargo sub-command, but still possibly maintain cargo-outdated as a heavier project based option. So here's my work out in the open: https://github.com/deg4uss3r/outdated2
This will look VERY rough right now, I'm sorry it's been a pretty interesting 2020 so far!
So this simplifies the project way down to only looking at workspace dependencies and requesting the latest from https://crates.io through the API. I think this is the best choice to add to cargo since we want it to always work no more compile issues with conflicting dependencies and it will only check the outdated dependencies of the current project rather than diving into dependencies that the launcher will have no control over.
There's A LOT (as you can tell) that I need to work on the biggest is integrating with cargo directly, but I have been paying close attention to the dependencies that cargo uses to make sure I'm reusing what is already imported. So far I see that I need to really flesh out before actually putting into cargo for the MR:

[ ] Only report updates on the channel the dependency is in (e.g. don't offer a beta when the user is using a stable version)
[ ] Proper error handling
[ ] Command line integration for options
[ ] support for outputting json

I would love some opinions on this scaled down version before I continue further though as, personally I think this is what we want as a cargo sub-command, but I might be totally in the minority there.

Great to see some progress!
Since you asked for feedback: Features that I really like in the current version: --ignore, --depth, --workspace. --exit-code is interesting for CI.

I use cargo outdated -R/--root-deps-only quite often, because the standard output is a bit verbose.

I suggest looking at yarn upgrade-interactive --latest for a really clean upgrading interface. I often use cargo outdated, but having to change every dep manually is a pain.

btw https://github.com/rust-lang/cargo/issues/10498 exists for moving cargo-edit's cargo-upgrade into cargo.
I wonder if cargo outdated could be a resolved via cargo update and cargo upgrade via

Dry-run support
An alternate output format

To begin cargo outdated must support all cargo modes.

Could you clarify which "modes" you are talking about that it'd need to support

cargo upgrade  v0.10.3 now provides a table summary of upgrades.  This doesn't completetly replace cargo outdated as this only handles root dependencies.  I still hope we could have cargo update handle that case.
Example for clap:
$ cargo upgrade --dry-run
    Updating 'https://github.com/rust-lang/crates.io-index' index
    Checking clap's dependencies
name              old req        locked latest new req        note
====              =======        ====== ====== =======        ====
clap_derive       =4.0.0-alpha.0 -      -      =4.0.0-alpha.0 pinned
clap_lex          0.2.2          -      -      0.2.2
bitflags          1.2            1.3.2  1.3.2  1.2            compatible
textwrap          0.15.0         0.15.0 0.15.0 0.15.0
unicase           2.6            2.6.0  2.6.0  2.6
indexmap          1.0            1.9.1  1.9.1  1.0            compatible
strsim            0.10           0.10.0 0.10.0 0.10
atty              0.2            0.2.14 0.2.14 0.2
termcolor         1.1.1          1.1.3  1.1.3  1.1.1          compatible
terminal_size     0.1.12         0.1.17 0.2.1  0.2.1
backtrace         0.3            0.3.66 0.3.66 0.3
once_cell         1.12.0         1.13.0 1.13.0 1.12.0         compatible
trybuild          1.0.18         1.0.63 1.0.63 1.0.18         compatible
rustversion       1              1.0.8  1.0.8  1
trycmd            0.13           0.13.4 0.13.4 0.13
humantime         2              2.1.0  2.1.0  2
snapbox           0.2.9          0.2.10 0.2.10 0.2.9          compatible
shlex             1.1.0          1.1.0  1.1.0  1.1.0
static_assertions 1.1.0          1.1.0  1.1.0  1.1.0
note: Re-run with `--pinned` to upgrade pinned version requirements
note: Re-run with `--to-lockfile` to upgrade compatible version requirements
warning: aborting upgrade due to dry run

(output is colored to make it easier to scan)

If this gets picked up, one reasonable change from cargo-outdated is that having outdated packages should exist nonzero by default. It is a bit surprising when running in CI that you need to use --exit-code 1 to make it fail

Just wanted to note here that cargo upgrades also exists and seems to be more compatible (works on rust-lang/rust workspace for instance).

While its not as fancy as cargo upgrade or cargo outdated, #13372 added highlighting of non-latest dependencies to cargo.


Update ImageDraw*() functions to match arguments of Draw*()

This goal out of this is to have the ImageDraw*() methods match the same naming and method arguments of Draw*() methods.
Updated draw functions:

ImageDrawPixel()
ImageDrawPixelV()
ImageDrawCircle()
ImageDrawCircleV()
ImageDrawLine()
ImageDrawLineV()
ImageDrawRectangle()
ImageDrawRectangleV()
ImageDrawRectangleRec()

This could do with some code review.
References

Fixes #1155

TODO

[x] Add/modify the functions in raylib.com cheatsheet. https://github.com/raysan5/raylib.com/pull/9
[x] Add/modify the functions in Notepad++ intellisense.
[x] Maybe update some image-related example in raylib/examples/textures.

@RobLoach very good! thanks for the improvement! 😄


Extension issue

Hi guys.
Thank you for producing such a useful extension!
By the way, I've got this kind of issue like below from my VSCode.
Would you consider what this means?
Thanks in advance. 😄

Issue Type: Bug
Extension Name: yuml
Extension Version: 3.5.1
OS Version: Windows_NT x64 10.0.19587
VSCode version: 1.45.1

:warning: We have written the needed data into your clipboard. Please paste! :warning:

I am not receiving such report with vscode 1.68


PR lookup detection in CHANGELOG generation is not working as expected

Bug Report
Generating the CHANGELOG from the fragments may result in some lines pointing to incorrect PR links.
For the 1.11.0 release, the release notes https://github.com/operator-framework/operator-sdk/releases/tag/v1.11.0 have three additions and changes that have incorrect PR links. Below are the changes that have incorrect PR links:

(go/v3, ansible/v1, helm/v1) Added containerPort protocol field required for server-side apply in manifests. (#4863)
(go/v3) Fixed a bug in make test caused by incorrect envtest asset setup. (#4863)
(go/v3, ansible/v1, helm/v1) Increased resource limits for controller manager. (#4863)

All those three changes reference the PR #4863, however the PR that resulted in those changes is #5117.
In most cases, the PR lookup detection works just fine and as expected. In this particular case, it's possible that the PR lookup is getting confused as #4863 and #5117 begin with the same name and contain similar words, however, the proper resolution would be that the PR lookup algorithm should purely be based on finding the right fragments and linking the PRs appropriately.

We should also probably add a note to the release documentation for the release PR authors and approvers to do a manual check and make sure that the linked PRs in the release notes PR are all accurate.

If we cant get this done by 1.12, lets do a manual audit to make sure the links are correct.
@jberkhahn