[Proposal] Consider building and distributing dotnet using official distribution package sources

For now, Microsoft is using it's own 3rdparty repositories, located at packages.microsoft.com. While dotnet is an open source project under MIT license, dotnet distributed like a proprietary 3rdparty blob without source code available (from OSS point of view).
And even more, I can't find .src.rpm packages on packages.microsoft.com repositories, that means the build steps required to produce this rpm package is hidden from us, users. As the source code the package is built from. This raises questions: are those packages actually built from source or they're just a repack of a portable .tar.gz? This is not transparent.
The lack of official/semiofficial packages in distribution repositories (in my case, Fedora. But is valid for Debian/Ubuntu too) slows down the spread of .NET on Linux. There's some of pros for integration, I could think of:

Distribution packages built with target distribution in mind. 3rdparty packages doesn't integrate into the target distribution well. They built to be widely compatible, as I can tell without .spec file available.
While the package integrated into distribution repositories can be installed with one command, as the SDK for development. 3rdparty packages require additional, unnecessary steps to install/update. There's a need to install 3party repo just to use a runtime and to run .Net application (not self-contained). And for RedHat-based distributions, you can even use rpms to produce containers, this allows dotnet to be used easier in prod (bonus points).
3rdparty packages has a slowdown in supporting a new distribution version. Fedora suffers from that mostly, because of update cycle. Packages integrated in Fedora can be built against rawhide as future target and issues with the new distribution version can be corrected even before it becomes branched.
Official distribution packages are transparent to users and allow contribution to the build process on the same level, as GitHub PR's. Just git pull, edit spec/dist, push, pull request.
Distribution packages are always build and run against latest shared library versions available in distribution. This means security, but in rare cases - a bit of a headache.
Updates easily handled by distribution package manager. If there's fixes, just rebuild the package. Some distributions allow diff updates for packages, using projects like DRPM.
Using 3rdparty repos to install OSS without proper reason not to integrate it to the distribution (like copyright or weird licensing) is discouraged by community.
RPM Specs and DEB dists can be used as a perfect reference for build steps required to build package correctly from scratch for Linux. Which is good for other, not directly supported distributions. If you decide to not support ArchLinux/Gentoo, for example, using available spec/dist files they can recreate build process and integrate dotnet on their own.
Distribution integrated runtime will allow packaging .Net software in that distribution natively, without the need to use self-contained deployment. There's a change what crossplatform dotnet gui/cli applications will appear in the future, native dotnet support in distributions is a huge welcoming gift for developers, even in the containers era. Perfect example: PowerShell, I'm looking at you. For now, even if dotnet supports Linux, it's still considered as a foreign/alien technology, because it lacks integration with Linux on the level of Mono. This slows down it's usage in Linux.

TL;DR (main ones): It requires some steps to install, it can be distributed without support for my distribution features (only standard linux features included), the build process is not transparent (what is discouraged by OSS community + contribution is limited), updates coming from single point (hello SPOF) and unable to package an app using dotnet-runtime into the distribution.
As of cons:

Packages in distributions must be maintainted by someone. By a community member or by developer itself. Yes, it requires some time to be invested, of course.
Or at least, package must be published for review to the distribution and this can be decided later on.

The RPM spec/DEB dists file(s) published should comply with the target distribution guidelines and should build software from the source code. This includes some degree of pain on the first steps, because Linux is fragmented. But it will pay out with time, because spec file/dists are open source. Everyone capable of building rpms/debs could contribute later.
For RPMs, it doesn't necessary to make a new spec file for every distribution in family. There could be one for CentOS/Fedora and one for OpenSUSE/SLES family. With some RPM macro [s]crutches[/s] magic, this could be done for sure.

In most distributions, bundling 3rdparty libraries is discouraged or forbidden. This must be considered. If the library is OSS, this should not be a problem, but maybe, a little more of a headache/time investment.

Integrating dotnet into distributions is a next big step in Linux support which should be considered.

You'll be pleased to hear that we've been working on this for a while, with the source-build project: https://github.com/dotnet/source-build. In fact, .NET Core is shipping as a distro package in Fedora 32: https://docs.fedoraproject.org/en-US/fedora/f32/release-notes/developers/Development_Dotnet/. 😄 We have been shipping a source-built .NET Core in RHEL for a while now, as well, and it's in CentOS 8 AppStream.
There is an official doc about guidelines for distro package maintainers here: https://docs.microsoft.com/en-us/dotnet/core/distribution-packaging.
Yes, packages.microsoft.com contains the "Microsoft distribution" of .NET Core, which does not build from source (as far as Linux distro expectations go), rather it's assembled from many repos' builds and involves prebuilts every step of the way, using varying pools of build machines and some optional tooling that isn't available publicly. It doesn't use spec files or anything of the sort, rather tools like fpm and a custom thing we made a long time ago for debs (dotnet-deb-tool). We do try to make our RPMs/Debs match distro guidelines in terms of layout and metadata, though.

@fixinggunsinair If you want to get more involved in .NET Core on Fedora, please feel free to join the .NET SIG: https://fedoraproject.org/wiki/SIGs/DotNet
I had a couple of thoughts, though:

(Please, don't be like Java, I'm begging you!)

Could you clarify what this means? I have been looking at OpenJDK as a sort of role model of what .NET could be. What sort of issues do you see in Java on Linux that we should try and stay away from?

unable to package an app using dotnet-runtime into the distribution.

Unfortunately, even with .NET Core being part of a distro, this problem doesn't immediately get fixed. The way .NET Core works, everything still tries to get nuget packages from nuget.org, making this quite tricky. This is something we are still working on: https://github.com/dotnet/docs/issues/17757

@dagood Glad to hear you thought about it even before I found out what it's already packaged as RPM. Now I feel kind of... uninformed %). You should definitely update the documentation on the microsoft.com to reflect that.
You can close the issue or keep it until you consider it's done and ready, if you want. So it would be visible for people like me.

Yes, packages.microsoft.com contains the "Microsoft distribution" of .NET Core, which does not build from source (as far as Linux distro expectations go)

Well, nothing stops you from using an internal repo made your way, but in Linux it feels like downloading a proprietary thing from publisher site, which will install itself THEIR WAY somewhere into /opt and you can't do anything with that.
@omajid
That's my subjective feeling of things got out accidentally.
The Java way, is to stay compatible with Linux but abstract from it as much as possible. Java things would run on Linux and work, but the internals would be so abstracted from the current state of things, it would feel like it's an alien or archaic technology. While on Windows, you sometimes can never say what this particular window is from Java application, because it's integrated as best as it can. But on Linux, you do. They didn't released SWT/JavaFX gtk3 wrapper for a long time, until gtk2 got deprecated, for example. So there was issues with GUI. But I hadn't used Java really for a long time and I'm glad I do.
Or maybe, TL;DR: Java way is to treat Linux only as POSIX-compatible Unix-way operating system, which Java must work on, but without delving to how Linux-way things work at all.
But that's subjective feeling, that doesn't compare to implementation. Of course it's a hard task to make one framework for everything without some level of abstraction in mind, considering Linux is a fragmentation hell and has freedom to fragmentate the way you freaking want (sometimes I dream about one distro for all, but that would never happen...).
So...

Unfortunately, even with .NET Core being part of a distro, this problem doesn't immediately get fixed.

I understand. Because by Fedora packaging guidelines, you should package every freaking bundled library into rpm before that happen. But if someday it can be used in place of Mono, I'll be glad to see that.
Still a huge step forward.

Now I need to find out do PowerShell team follows you in that way or should I create another issue for them. Because I care about them too to become integrated. %)

You should definitely update the documentation on the microsoft.com to reflect that.

We're looking at ways to do this and have some ideas, but I'm curious what you saw to get the specific conclusions you arrived at. Source-build does have some docs, the most straightforward being https://docs.microsoft.com/en-us/dotnet/core/distribution-packaging, but https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-rhel8 does point at RHEL 8 having .NET Core in the distro. Did you maybe start from https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-fedora31 and hop over to packages.microsoft.com to look in more detail, or are there more prominent places you have in mind that you would have liked to see more info about this?
(I have filed https://github.com/dotnet/docs/issues/18019 to put up a similar page for CentOS 8 as the one we have for RHEL 8, not that that's enough.)

Well, nothing stops you from using an internal repo made your way

This is too far--the Microsoft build does run using public sources. For example, you can see what our dotnet/runtime build does in Azure DevOps by starting at https://github.com/dotnet/runtime/blob/master/eng/pipelines/runtime.yml. That does involve non-public toolsets downloaded as prebuilts, but mostly that's limited to Microsoft signing tech. I'm not suggesting trying to follow it to do a local build, I do think that would be too difficult and I'm definitely not disputing your argument about how proper source-build helps devs new to the project figure out what's going on.

which will install itself THEIR WAY somewhere into /opt and you can't do anything with that.

If you encounter something with the .NET Core packages that seems to violate package guidelines for the target distro, I encourage you to open an issue and we can discuss it. We definitely don't install into /opt. 😛

PowerShell team

I'm not sure, maybe someone else in the thread knows more. I do see Make Powershell Core suitable for inclusion in Debian #5869 (from 2018) in their issues but no others that are obviously about distro packaging.

@dagood

https://docs.microsoft.com/en-us/dotnet/core/distribution-packaging

Never saw it until this issue. It's somelike deep in documentation and Google never showed me this page. I'm a simple man and when I need install instructions, I just google dotnet fedora install. Not the dotnet fedora distribution package (but it shows same results) or build instructions. And the first result I got, was:

https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-fedora31

Or even Fedora 30 link. But it's all the same instructions.
Or the link to the snapcraft.io, which mustdie.

https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-rhel8

Why do I need RHEL 8? I don't have that. So why should I read this page? %)
So, to perfectly reflect that, you may just add Fedora 32 page and link to the Fedora package first and alternatively you can use the one's we provide if you want it thing.
Google is changing right now. Because now I see links to the .NET SIG on first results:

And this screenshot made in the incognito tab. So it should be a global result.
I never saw dotnet package listed in the fedora repositories. But this changed magically on yesterday, because dotnet package from updates-testing just replaced the one from the packages.microsoft.com... I just did a dnf update on my toolbox. Availability in distribution also helps spread the world.

I'm not suggesting trying to follow it to do a local build, I do think that would be too difficult and I'm definitely not disputing your argument about how proper source-build helps devs new to the project figure out what's going on.

RPM Spec is better in this task, because you don't have to describe the build process of whole toolchain in one file. Even better, if you know what to look at. That one is relatively simple.

We definitely don't install into /opt. :stuck_out_tongue:

Got your word. I just have some Vietnam flashbacks about 3rdparty RPMs with closed source software.

So, to perfectly reflect that, you may just add Fedora 32 page and link to the Fedora package first and alternatively you can use the ones we provide if you want it thing.

I filed https://github.com/dotnet/docs/issues/18038 to track that.


Licence

Hi Team,
does this repo have a license?
https://opensource.stackexchange.com/questions/1150/is-my-code-floss-just-because-it-is-published-it-on-github
according to the article it's all rights reserved ?

Duplicate of #46


2021 Planning

Already late for this planning, specially since the team is new, but hey, give me a break, I started 3 days ago :)

[x] OKR & KPI
[x] Review with Thomas
[x] Review with the team
[x] Events planning
[x] Review with the team
[ ] Budget
[ ] Events planning
[x] Review with Thomas
[x] Meeting with Caro for goals definition
[x] Meeting with Tommy for goals definition
[ ] Defining my personal goals
[x] Adding tasks as issues
[x] Transferring plan in this repo
[x] Kicking ass in 2021

Events planning, and budget will wait until the pandemic is behind us.

So I consider the plan that we can do right now done


Add examples for renameProp and renameProps

Following the issue #337, I've decided add examples for renameProp and renameProps.

Thank you.


RociFi

Name: RociFi
Description: On-chain credit scoring for under-collateralized retail loans.
Thumbnail URL: https://roci.fi/
Category: DeFi
Project URL: https://roci.fi/

@ccb-eth can you explain how you're using lens protocol in RociFi?

We're integrating the Lens into our credit scores which we hope to
represent on Lenster / Lensfrens at a later date. We've also received a
grant from Lens to do this.
On Sat, 26 Nov 2022 at 04:37, saurabhdoteth @.***>
wrote:

@ccb-eth https://github.com/ccb-eth can you explain how you're using
lens protocol in RociFi?
—
Reply to this email directly, view it on GitHub
https://github.com/Lens-Garden/lens-projects/issues/9#issuecomment-1327972085,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AS44RW3UI2V2N3WMZJ4UM63WKGAVXANCNFSM6AAAAAAR7XO5JE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Add docs for Glue JDBC crawlers and Redshift integration

Add docs for Glue JDBC crawlers and Redshift integration - should become part of the v1.2.0 release notes.
/cc @silv-io @HarshCasper

Thanks @whummer 🙏


Upgrade to Netty 4.0.27.

Also consider reverting 015bcfe63c8166ce2e3018ff0b9578de02a28316

Good point, I've reverted that change and also added a test to validate that a Cluster that could not successfully establish a Session closes cleanly (fails with 4.0.26 but passed with 4.0.27)


Relax requirements for stable SHA on the signature part of the package

Currently when signature part of package changes, it triggers immediate failure of the build process
(especially when the lock-file is used).
Here we prefer to use the predefined hash to fetch the artifact (for perfomance  reasons) and to have the warning printed if the SHAs does not match -> but still allow the build process to proceeed.

@thesayyn  Please take a look in context of your comment: https://github.com/chainguard-dev/rules_apko/issues/42#issuecomment-1850630445

to avoid hard fails, in case the signature change, we only cache control and data and let signature to be fetched as needed. that's the reason why we don't specify checksum for signature fetches.

@sfc-gh-ptabor can you resolve conflicts?


Users see citations that are as complete as our sources would allow it.

When a user opens their profile page, they see each academic article formatted in the same way, with each of the following fields present:
Users see Title, Authors, Publication Date, Journal Title, Volume, Issue, Page or Page Range, Year, DOI. The DOI does not have to be visible in the citation formatting, but it can be downloaded with the citation.
For books, users see Chapter Title if relevant, Book Title, Authors, Editors, Publication Date, Page or Page Range if chapter, Year, ISNI for their books. ISNI also does not need to be visible in the citation on the profile, but needs to be downloadable.
For conference papers, the fields they see are as for academic articles and additionally, the conference title.
Currently, there is a ranking of preference for the citation sources, and only the data elements from the available top choice is displayed. At the completion of this epic story, the citations will be as complete as possible with the elements enumerated above, correctly combining data from the different sources as needed.
Note: conference proceedings conform to one of the above formatting styles based on the way they are published.

[ ] #25
[ ] #40
[ ] #41
[ ] #42
[ ] #43
[ ] #44
[ ] #45
[ ] #46
[ ] #47
[ ] #48
[ ] #49
[ ] #26
[x] #27
[ ] #28
[ ] #66
[ ] https://github.com/ucd-library/aggie-experts/issues/93

Outcome
Currently, article citation 3469144 appears as
Hydrological processing of salinity and nitrate in the Salinas Valley agricultural watershed Zikalala P, Kisekka I, Grismer M. Environmental Monitoring and Assessment. 193.
When updated, it will appear as
Hydrological processing of salinity and nitrate in the Salinas Valley agricultural watershed Zikalala P, Kisekka I, Grismer M. 193 (Suppl 1): 272.
Currently, conference paper citation 2713713 appears as
Streaming Satellite Data to Cloud Workflows for On-Demand Computing of Environmental Data Products Zinn D, Hart Q, Ludascher B, Simmhan Y. . 1-8.
When updated, it will appear as
Streaming Satellite Data to Cloud Workflows for On-Demand Computing of Environmental Data Products.  Zinn D, Hart Q, Ludascher B, Simmhan Y. . The 5th Workshop on Workflows in Support of Large-Scale Science. 1-8.
The IEEE publisher's citation also includes location , New Orleans, LA, USA, but none of our sources has that, so we cannot include it.

The citation source to VIVO construction as been added to the experts-client query, cdl_citation_to_vivo.
These  queries have not formally been added to the experts-cli, but the construction here is approrpiate for the sply funcationality.

VALUES (?source ?priority) gives the priority of the sources as they fill in gaps in the citation fields

@Vensberg , we haven't yet come up with proper id's for the above works,  but you can find  them  with
for i in 3469144 2713713; do id=$(md5sum <<<"http://oapolicy.universityofcalifornia.edu/${i}" | cut -d' ' -f1 | sed -e 's!\(..\)!\1/\1!'); echo $i $id; done

3469144 fe/fe97dfb56036bbea5b3c3f186b970ce1
2713713 0b/0b9d64001400f6a921cbd8c71cb5d5c0

These are now formatted in citation style, so you can see what that APA might look like with:
http http://localhost/fcrepo/rest/work/0b/0b9d64001400f6a921cbd8c71cb5d5c0/svc:es-work-transform | jq '.["@graph"][0]' | citation-js -f string -s citation-apa

Streaming satellite data to cloud workflows for on-demand computing of environmental data products. (published). 2010 5th Workshop on Workflows in Support of Large-Scale Science, WORKS 2010. https://doi.org/10.1109/WORKS.2010.5671841

Authors are currently not included properly. in the default result, but you can see the container in the above example

The Publisher appears in the UI, but not in the RIS file download.

Sources sometimes won't distinguish b/n author and editor. Crossref seems to get this right.


Firefox tabs with WebGL crash when launched through RenderDoc on macOS

Description
On macOS, trying to trace a WebGL tab in Firefox will lead to that tab crashing.
Steps to reproduce

Open qrenderdoc.
Set "Executable Path" to /Applications/Firefox.app.
Set "Command-line Arguments" to --no-remote --new-instance -p robot (create a profile named "robot" for Firefox in "Profile Manager").
Press Launch.
Open a website which uses WebGL like https://www.google.com/maps/?force=webgl or Shadertoy.
After about a second, Firefox will report "Gah. Your tab just crashed".

Environment

RenderDoc version: 89af50a76c1cf98f800a6ff8ece5c31f3ff5504c
Operating System: macOS 10.15.7
Graphics API: WebGL / (Unknown backend in Firefox)
Firefox: 81.0.1 (64-bit)

OS X is not a supported platform. Fixes are welcome but otherwise no support or help will be provided.


include offset in output of "warcio index ..."

I realize that the other fields are configurable and that offset is different because it's not a warc record header. I think it's reasonable to always include the offset in the output though.
By the way strictly speaking ArchiveIterator isn't actually an iterator, you have to do iter(ArchiveIterator(...)) to get the iterator. It looks like it would be a pain to refactor though.

I was thinking of adding it as a special case field named offset that could be passed to the field list, eg -f offset,warc-type  Are you opposed to just including it in the list explicitly? Maybe it should be in the default list.
Yes, you're right ArchiveIterator is not an iterator, but an iterable. https://docs.python.org/3.6/glossary.html
I did actually refactor it at one point, and it was ugly and realized it was unnecessary for the main semantics which is for record in ArchiveIterator(stream)
I guess calling iter() is fine if you really need to be able to call next() as well.
Not sure what's happening with the tests here?

For reference, here's what it looked like as an Iterator, implementing next directly:
https://github.com/ikreymer/pywb/blob/50354332614e0e03d27c714438366017d81ed5e0/pywb/warclib/archiveiterator.py

Coverage increased (+0.0002%) to 99.896% when pulling ab31e0711e7f9bd85d11f4dd99847b09b32ea9d2 on nlevitt:offset into 266cd56a74f68259821219b6cb363e972ebe80cf on webrecorder:master.

Coverage increased (+0.0002%) to 99.896% when pulling ab31e0711e7f9bd85d11f4dd99847b09b32ea9d2 on nlevitt:offset into 266cd56a74f68259821219b6cb363e972ebe80cf on webrecorder:master.

Coverage increased (+0.0002%) to 99.896% when pulling ab31e0711e7f9bd85d11f4dd99847b09b32ea9d2 on nlevitt:offset into 266cd56a74f68259821219b6cb363e972ebe80cf on webrecorder:master.

Coverage increased (+0.0002%) to 99.896% when pulling ab31e0711e7f9bd85d11f4dd99847b09b32ea9d2 on nlevitt:offset into 266cd56a74f68259821219b6cb363e972ebe80cf on webrecorder:master.

Coverage decreased (-0.1%) to 99.792% when pulling f2331d727842ba1b8c522669576b34e414aa151e on nlevitt:offset into 266cd56a74f68259821219b6cb363e972ebe80cf on webrecorder:master.

Coverage increased (+0.0003%) to 99.896% when pulling 1f03d36a8afb8a00930833bb3034851b615fc561 on nlevitt:offset into 266cd56a74f68259821219b6cb363e972ebe80cf on webrecorder:master.

Better now? :)
I noticed the iterator thing while writing code to extract a single record by offset, which involved using next() directly. That's cool you also tried implementing it the other way. What about just renaming the class to ArchiveIterable? Anyhow it doesn't matter too much, I leave it to your discretion.


Add --enable-jemalloc argument to build

During our tests with OVSDB we found out that memory allocation is
used intensively by the server, so we thought that using a different
memory allocator could increase the performance. We tried jemalloc
and the performance gain was between 20% and 40%.
This patch would allow anyone to enable jemalloc on their systems
in case you want to try out this memory allocator.
The patch adds the --enable-jemalloc flag to link ovsdb-server with jemalloc
instead of the default memory allocator. This can improve the OVSDB
Server performance under certains loads.
Signed-off-by: Esteban Rodriguez Betancourt<EMAIL_ADDRESS>

Have you tried just using LD_PRELOAD to enable jemalloc?
You show some performance results, which is fantastic.  An improvement would be make those tests easily repeatable by others.  There are many reasons others may want to run the same tests (see how results compare on different systems, test with ovsdb-server changes, test with other allocators ...)

We used LD_PRELOAD, but at the end preferred this solution, because we want it to crash at compile time if jemalloc isn't present.
The benchmark tool used is here: https://github.com/estebarbhpe/ovs/tree/feature/benchmark . That tool is still WIP. Our intent is to publish the benchmark tool too, but it still need changes.

Closing this pull request and creating https://github.com/openvswitch/ovs/pull/112 instead.


Python formatter very slow

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.62.3 (and previous one as well)
OS Version: Windows 10 21H1

Steps to Reproduce:

Using dev container for Python development
Save a file
Wait foe the action to complete; takes up to 2 minutes

Message shown:

Please file this issue on the vscode-python extension's repo: https://github.com/microsoft/vscode-python/issues


Tracking for bookmarklet events

Try to set up tracking on the server for the following events, preferably with Google Analytics if possible:

If external code, when external file is loaded
If pinging for updates, when pinging

Nope.


Add why section to landing page

Fixes #21
Added this section to the home page based on the Figma design and removed the old outdated content.
Screenshot:

Any chance we can align this one same way it's on Figma?
Looks a bit out of the place on my MacAir.

Any chance we can align this one same way it's on Figma?
Looks a bit out of the place on my MacAir.

Ok I have updated it to match the design closer, thanks for the feedback! (Let me know what you think now)


Remove cekit2 and use only cekit3

A few bugs on cekit that was preventing to build and squash images
are now fixed, we can use only cekit3.

@mswiderski can you please review?

I just triggered Jenkins job again...

@mswiderski @spolti looks good to me and makes a lot of sense updating the commands to cekit3.


Can the code block support default folding or fixed display width?

Hello，can the code block support default folding or fixed display width? Sometimes the sample code block is too long, can you set a default display height? Exceeded content is browsed by means of scroll wheel, etc. Thanks~

Hi,
default folding is included since the first version. You just have to write fold in the first line of the code block (just like as you would do with the hl parameter). This will fold the code block every time you open the document. It is documented in the README as well. Is this what you mean?
What do you mean by fixed width/height?


Keycloak Gatekeeper uses an old go-oidc library

What:
Keycloak gatekeeper uses a very old github.com/coreos/go-oidc library version (v0.0.0-20171020180921-e860bd55bfa7).
That version doesn't support all algorithms like RS384. When keycloak receives a JWT signed by one these algorithms, it throws an exception:
oidc: JWT signature verification failed: unsupported key algorithm "RS384"
I think it would make to update the library to a newer version. The problem is that a lot of stuff needs to be refactored because go-oidc v2 depends on golang.org/x/oauth2 and many structs have been moved or are not anymore available.
I'm also a bit concerned about the security by using a library which hasn't been updated since 3 years.
Reference:

KEYCLOAK-11242 - Keycloak Gatekeeper uses an old go-oidc library

Duplicate of https://github.com/keycloak/keycloak-gatekeeper/issues/517


Bug to fix Studynames in LauncherDialog

Studynames in LauncherDialog disappear when refreshing in study pages (study & explore)

This is due to the dev server hot reload problem


 For us peasants on OSX, use Homebrew to install GNU sed like so:
brew reinstall gnu-sed --with-default-names

okay, but there's still a problem with grep:
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
        [-e pattern] [-f file] [--binary-files=value] [--color=when]
        [--context[=num]] [--directories=action] [--label] [--line-buffered]
        [--null] [pattern] [file ...]

I made a quick Pull Request to remove a stray GNU grep style command from the post-commit hook. Thanks for bringing this to my attention.
Test out the PR branch if you could and let me know if you run into any more POSIX/GNU issues!


Improve hover and find-references output

Changes:

Add line content and replace absolute with relative path in showLocations(). Instead of showing only the absolute path of the reference found, this patch adds the line content with getLineContentFromPath(). This new function will return a string with the content of the line or, in case of error, an error message. Also replaces the absolute path with the relative path in order to  shorten it and leave more space for the line content. For this task  relPathFromFileUri() was implemented.

Add showHoverInfo() to create an horizontal split with hover results.

The motivation behind this PR is to make hover and find-references more useful.
As stated in https://github.com/Andriamanitra/mlsp/issues/7 hover feature is not as useful as it could be (for example clangd can respond with multiple lines only of annotations that are in the code as documentation). I think as @r3t4k3r, that hsplit is the best option until micro can expose some tooltip implementation.
Also this PR gives more context to the respond of find-references printing the line where the reference its located.
Let me know what you think.

About the absolute vs relative path. I think its a trade-off. Or absolute path or relative and line content. As you said even relative path is sometimes a large text.
The format I choose was the same as grep output (widely used and supported by other programs). And similar as you do, I use micro-quickfix to jump to the locations (it expects the file at the beginning). I suppose all the tab thing its because the format that uses your ag plugin (?).
And you are right about the label being first but i wanted to keep the same format in both.
That being said, I think that the right call its, as you said, to make the LSP responsible of that and do not leave it to other plugins.
I think using something like your OpenResult*() and specific parsers by buffer name will be a nice solution. This way we can use formats that makes more sense for each specific LSP result and do not be constraint.
I think something like:
-- this functions will return a string (ex: my_project/src/main.lua:33:22)
local parsersByName = {
    ["references"] = function () ... end,
    ["document symbols"] = function () ... end,
    -- other buffers if needed
}

-- method (string): open, tab, hsplit ...
-- close (boolean)
function jumpToLocation(bufpane, method, close)
    local parser = parsersByName[bp:Name()]
    if not parser then infobar:Error(); return end
    local line = ... -- get the line where the main cursor is
    local destination = parser(line)
    bufpane:HandleCommand(method .." ".. destination)
    if close then
        -- close buffer opened by LSP
    end
end

Then we can use two approaches:

Expose wrappers for each specific case as I recall from your plugin or,
Expose only jumpToLocation() and use the args to pass method and close (verifying them inside) in the binding.

Example: "command:jumpToLocation open true" (or we can use directly "close" instead of true so its more explicit at what it does, no second argument means false).
Maybe use another name less generic if its exposed, like lspJump or something with LSP in the name.

That being said, I think that the right call its, as you said, to make the LSP responsible of that and do not leave it to other plugins.
I think using something like your OpenResult*() and specific parsers by buffer name will be a nice solution. This way we can use formats that makes more sense for each specific LSP result and do not be constraint.

I agree that's a good solution.
For find-references we should probably simply print the location on its own line? That way there is no need to worry about parsing weird edge cases and we can still have the preview. If the output is marked read-only the jumpToLocation (or whatever it will be called) command could even be smart enough to look for the location on the previous line if the current line number mod 3 is 1. And we could eventually even have custom file types to syntax highlight the outputs.
I propose the following formatting:
document-symbols
[Method] (*BufPane).ScrollUp          # /tmp/micro/internal/action/actions.go:25:1
[Method] (*BufPane).ScrollDown        # /tmp/micro/internal/action/actions.go:32:1
[Method] (*BufPane).ScrollAdjust      # /tmp/micro/internal/action/actions.go:40:1
[Method] (*BufPane).MousePress        # /tmp/micro/internal/action/actions.go:51:1
[Method] (*BufPane).MouseDrag         # /tmp/micro/internal/action/actions.go:103:1
[Method] (*BufPane).MouseRelease      # /tmp/micro/internal/action/actions.go:124:1
[Method] (*BufPane).ScrollUpAction    # /tmp/micro/internal/action/actions.go:143:1
[Method] (*BufPane).ScrollDownAction  # /tmp/micro/internal/action/actions.go:149:1

find-references
/tmp/micro/internal/display/softwrap.go:63:2
	Scroll(s SLoc, n int) SLoc

/tmp/micro/internal/action/actions.go:27:18
	v.StartLine = h.Scroll(v.StartLine, -n)

/tmp/micro/internal/action/actions.go:34:18
	v.StartLine = h.Scroll(v.StartLine, n)

/tmp/micro/internal/action/actions.go:44:19
		v.StartLine = h.Scroll(end, -h.BufView().Height+1)

/tmp/micro/internal/action/actions.go:157:18
	v.StartLine = h.Scroll(h.SLocFromLoc(h.Cursor.Loc), -h.BufView().Height/2)

/tmp/micro/internal/action/actions.go:174:14
		SLoc:    h.Scroll(v.StartLine, scrollmargin),

/tmp/micro/internal/action/actions.go:185:14
		SLoc:    h.Scroll(v.StartLine, h.BufView().Height/2),

/tmp/micro/internal/action/actions.go:198:16
	lastLine := h.Scroll(v.StartLine, h.BufView().Height-1)

The format for symbols looks nice and the alignment should be easy to implement. The absolute path could make the line wrap but maybe we could set softwrap to false for that specific buffer.
But I do not like the find references one, it is weird to read and uses a lot of space. I think best solution is relative path + line content (and as stated before we can set softwrap to false in the buffer if necessary).
It is there any good reason for using absolute path over relative? What is your use case?
And notice that your absPathFromFileUri() function returns whatever uri the LSP returns (I catch a bug in my relative function, see issue, because it returned a relative path instead, see commit)
About the syntax I use a special one for the references, quickfix, etc that puts the file and location in other color so its easy to read but expects to be as grep output.
Similar to this:
filetype: lsp-syntax

detect:
    filename: "(^references$)|(^document symbols$)"

rules:
    - identifier: "^[^[:space:]][^:]+:[0-9]+:[0-9]+:"
    - identifier: "^[^[:space:]][^:]+:[0-9]+:"
    - identifier: "^[^[:space:]][^:]+:"

We could use a color for each type of label. But I do not know a lot about the syntax part of micro.

Now with https://github.com/Andriamanitra/mlsp/pull/14 can I assume that absPathFromFileUri() always returns absolute path?
No need for https://github.com/Andriamanitra/mlsp/pull/10/commits/95183098e322d2a591ed7c383d8e7045e8a9adb7?

Now with #14 can I assume that absPathFromFileUri() always returns absolute path?
No need for 9518309?

Yeah – it always did when it was given a file URI. Problem is that despite the name lspLocations[1].uri is not always a file URI, it can also be just a path (without "file://" prefix). That path used to be relative but now it's absolute so you should be able to remove that commit.
But the original implementation has a bug too. It won't work if the file is not under the current working directory. For example if you're editing /etc/hosts and your working directory is /home/user/ the relative path should be ../../etc/hosts, but relPathFromFileUri returns .. This is part of the reason I prefer absolute paths: they're much easier to reason about than relative paths. If we go with relative paths I think we should use filepath.Rel to (hopefully) correctly handle all the edge cases.

You are right, I did not see filepath.Rel 😅.
I did not think about the plugin handling files from '/' being inside '$HOME'... this makes me think. It's the plugin sending changes to the LSP of files that are not related to that LSP?
For example, I am editing a markdown or python file with the lua LSP activated, the plugin handles that? Is the plugin sending didOpen messages (or others) for that files?
This PRs are my first contact with LSPs, so i dont know much. Can the LSP respond with the file types it does not handles?

I did not think about the plugin handling files from '/' being inside '$HOME'... this makes me think. It's the plugin sending changes to the LSP of files that are not related to that LSP?
For example, I am editing a markdown or python file with the lua LSP activated, the plugin handles that? Is the plugin sending didOpen messages (or others) for that files?
This PRs are my first contact with LSPs, so i dont know much. Can the LSP respond with the file types it does not handles?

Yes, µlsp (LSP client) currently tells the language server about all open files regardless of file type or path. It is up to the language server to decide what (if anything) to do with that. This is somewhat wasteful if you're editing Python files with a Lua language server running, but I don't think it is much of a problem in practice.
Eventually it might be nice to have support for dynamicRegistration which would allow the language servers to tell the client which requests it supports and for which files. Then we would not need to send textDocument/didOpen and textDocument/didChange messages for files that the language server is not interested in.

I normally use other tabs for documentation, notes, etc.
I've been reading about dynamicRegistration, watching what is the result of initialize (i saw the languageId part of the request from the client) and searching in the specs. It seems that the LSPs do not respond directly with what kind of files are supported (at least the ones i tried). Is this correct? Can you point me in the right direction if i am missing something?
Did you read https://github.com/Andriamanitra/mlsp/pull/10#issuecomment-2450296697 ? Is this PR completed?

I've been reading about dynamicRegistration, watching what is the result of initialize (i saw the languageId part of the request from the client) and searching in the specs. It seems that the LSPs do not respond directly with what kind of files are supported (at least the ones i tried). Is this correct? Can you point me in the right direction if i am missing something?

I have not coded it yet so I'm not entirely certain about the details but if I understand the spec correctly it should work something like this:

Client opts in by setting capabilities.fileOperations.dynamicRegistration = true in the initialize request
Server may send client/registerCapability requests to the client. These may optionally include a list of DocumentFilter to pick which documents the capability applies to.
The client can choose to not make requests that there is no registered capability for.

Although now that I read more about it looks like the initialize response could also contain document filters in ServerCapabilities. None of the language servers I tried so far (pylsp, ruff, rust-analyzer) seem to take advantage of that though. Not much point in supporting the feature if none of the servers use it.

Did you read #10 (comment) ? Is this PR completed?

Yes I read it, but I still think we should go with the format I proposed in https://github.com/Andriamanitra/mlsp/pull/10#issuecomment-2448534992. The current format in this PR is IMO

Less readable for the labeled case because the labels are after the locations
Ambiguous in the presence of spaces and colons (eg. /foo/bar:1:2:/baz qux:3:4 abc could be either path="/foo/bar:1:2:/baz /qux", line=3, column=4, content="abc" or path="/foo/bar:1:2", line=1, column=2, content="/baz /qux:3:4:abc")
Less useful because of the use of relative paths: you can't use them in eg. a file explorer or a terminal that has a different working directory than micro.

If you have a strong argument for relative paths I could be convinced otherwise, but points 1 and 2 need to be addressed before this can be merged.

I'm also a bit worried about the performance of showLocations if the references are deep into a file and there are many of them. Imagine something like /project/main.c:90001, /project/main.c:90003, /project/main.c:90004 – it would read over 90000 lines from the example.c file 3 times! It's not that unrealistic of a scenario either as there are often many references to the same variable in the same file.

I read that part diagonally and understood that it is the client's responsibility to set a filter on the server. For example, using clang, it should not respond to hover requests for *.h files, only for *.c files. This could improve server performance, but it does not address the issue of sending requests from the client, does it?
Maybe rely on the buffer's file type or use the same approach you implemented for the lsp command (which I haven't read yet). Perhaps a combination of both could work?
About the format:

Less readable for the labeled case because the labels are after the locations

The format for symbols is ok to me, as I said before.

Ambiguous in the presence of spaces and colons (eg. /foo/bar:1:2:/baz qux:3:4 abc could be either path="/foo/bar:1:2:/baz /qux", line=3, column=4, content="abc" or path="/foo/bar:1:2", line=1, column=2, content="/baz /qux:3:4:abc")

Fair enough, I guess.

Less useful because of the use of relative paths: you can't use them in eg. a file explorer or a terminal that has a different working directory than micro.

I do not know if that is the normal use case. micro's "Shell bar" uses current directory, same micros's terminal, new tabs in terminal emulators use the current directory as well, same as tmux (and similar apps) splits and windows.

If you have a strong argument for relative paths I could be convinced otherwise, but points 1 and 2 need to be addressed before this can be merged.

My biggest concerns:

The name length in the tab bar displays the entire path, making it unusable (even two tabs are too much). This is the main reason that I avoid absolute paths when opening a buffer (this applies to both formats).
The proposed format for find-references is, in my opinion, hard to read and takes up too much space. Could this next format be a middle ground?

main.lua:
    22: local res = nil
    33: if res then

other.lua:
    15: local res = req

Pros: similar to yours, avoids ambiguity with spaces and is more compact.
Cons: getting the location is not immediate (no mod 3 operation; we have to search backwards line by line until we encounter first line with first char not equal to tab, but should be fast).

About the performance of showLocations():
This was good enough to make the PR and see if you are ok with the main idea, if not i would keep like it is (i can not use micro with a file that large lol). The last format make us to sort the result first (are the results already sorted by the LSP?), so after all entries are sorted we can open and read the file only once.

I read that part diagonally and understood that it is the client's responsibility to set a filter on the server. For example, using clang, it should not respond to hover requests for *.h files, only for *.c files. This could improve server performance, but it does not address the issue of sending requests from the client, does it?

The client would not send requests if the server hasn't advertised it has the capability to handle it. This part is already implemented in µlsp, although it's missing support for the document filtering. Although the requests related to document synchronization (textDocument/didOpen, textDocument/didChange, etc.) do not go through it because according to the spec every language server must support them.

Maybe rely on the buffer's file type or use the same approach you implemented for the lsp command (which I haven't read yet). Perhaps a combination of both could work?

From what I've seen it seems language servers don't give a document filter for these requests either, so it's impossible to know (reliably) which file types a given server is interested in. It would be possible to hard code their supported file types but I don't really like that approach as it's brittle and maintenance-heavy. It is not always obvious which file types a language server should be associated with. For example language servers might care about changes to configuration files like Cargo.toml or package.json in addition to source code files.

If you have a strong argument for relative paths I could be convinced otherwise, but points 1 and 2 need to be addressed before this can be merged.

My biggest concerns:
1. The name length in the tab bar displays the entire path, making it unusable (even two tabs are too much). This is the main reason that I avoid absolute paths when opening a buffer (this applies to both formats).

We could do the conversion from absolute path to relative path when opening the file when that is implemented.

2. The proposed format for find-references is, in my opinion, hard to read and takes up too much space. Could this next format be a middle ground?

main.lua:
    22: local res = nil
    33: if res then

other.lua:
    15: local res = req

* **Pros**: similar to yours, avoids ambiguity with spaces and is more compact.

* **Cons**: getting the location is not immediate (no mod 3 operation; we have to search backwards line by line until we encounter first line with first char not equal to tab, but should be fast).

I'm fine with this format. The implementation is a bit more complicated but I think it looks better than my suggestion. With this format you will probably want to replace showLocations with two separate functions as the outputs of find-references and document-symbols will not share much any more.

The last format make us to sort the result first (are the results already sorted by the LSP?), so after all entries are sorted we can open and read the file only once.

The specification does not guarantee that they are sorted but in practice I think they will be (for find-references). It wouldn't hurt to sort them anyway just to be safe.

The client would not send requests if the server hasn't advertised it has the capability to handle it. This part is already implemented in µlsp, although it's missing support for the document filtering. Although the requests related to document synchronization (textDocument/didOpen, textDocument/didChange, etc.) do not go through it because according to the spec every language server must support them.

Yes, a filter for a valid capability. The problem is in the client, not in the server (now that I use the plugin a little bit, the delay when opening multiple buffers simultaneously is very noticeable).

From what I've seen it seems language servers don't give a document filter for these requests, so it's impossible to know (reliably) which file types a given server is interested in.

I have seen the same, it is strange that something like that is not in the spec.

It would be possible to hard code their supported file types but I don't really like that approach as it's brittle and maintenance-heavy. It is not always obvious which file types a language server should be associated with. For example language servers might care about changes to configuration files like Cargo.toml or package.json in addition to source code files.

If the LSP uses other types we can not rely in micro filetype for that. But it is already necessary to hardcode the LSP in config.lua. We could implement an option that, when not nil, restricts the available filetypes/extensions for the client. So nothing has to change but there is the possibility to use it.

I'm fine with this format. The implementation is a bit more complicated but I think it looks better than my suggestion. With this format you will probably want to replace showLocations with two separate functions as the outputs of find-references and document-symbols will not share much any more.
The specification does not guarantee that they are sorted but in practice I think they will be (for find-references). It wouldn't hurt to sort them anyway just to be safe.

Both formats are already completed, except for minor issues (some trouble with '\t' in symbols, and references are not sorted yet, although they were for the LSPs that I tried)
The trouble with the tabs is the visual representation
[String]	VERSION                         # main.lua:1:1
[Variable]	micro                         # main.lua:3:7

tab is counted as 1 using #labels[i] and util.CharacterCountInString(labels[i]) but when represented you can see there are 4 or 2 spaces. I have to check what micro does.

Yes, a filter for a valid capability. The problem is in the client, not in the server (now that I use the plugin a little bit, the delay when opening multiple buffers simultaneously is very noticeable).

Number of buffers should not affect anything. It is normal for opening a buffer to take time to read the entire file & send its contents to the language server so it might not be instant for larger files. However if it gets slower as you open more buffers that is likely a bug. Please open a new issue if that is the case.

No, it is not a bug, I was referring to the actual behavior. But does not matter, it is not critical.

I did not solve the '\t' issue. There is a function in Micro, StringWidth(), in internal/util/util.go that addresses it.
I added a possible TODO to highlight the reference search in the new buffer created.
I also changed to absolute paths, so they can later be replaced with relative paths during the "jump."


Feature Request: Add "fallback" icons for --overlayicon --bannerimage and other file path arguments

Currently, if one specifies a file that doesn't exist for --icon a "fallback" icon is used instead. This is a great feature, and I would like to see the same behavior added for other features like --overlayicon --bannerimage --background etc.
I'm weighing the need to code some kind of validation myself for Baseline, because currently if an admin specifies an invalid --overlayicon in their options then the script fails in a bad way.
Alternatively, if this isn't something you wish to add, can you clarify or specify for me if a specific exit code is used for all/each of these?

Testing this further, it looks like the "fail" condition is happening when a directory is given as a filepath. The exit code is 201 with the error ERROR: Image resource cannot be found : /path/to/dir
Would it be possible to use the fallback icon in this situation instead of failing the dialog window altogether? My preference would be for the error message to remain in order to indicate the issue but it would not cause an outright failure.

how's this look?

regarding an error image for the overlay icon, the default behaviour is that if there's an issue is just doesn't show. I took this approach rather than display an error icon as a safe fallback. Open to suggestions though.

As this is @BigMacAdmin’s FR, I’ll defer to Trevor, but my two cents are bannerimage looks good.
For overlayicon, one advantage of having an error image is that you know something should be displaying and that your filepath is wrong.

Looks good to me, Bart.
The problem I see with Dan's comment, is that currently --icon, --bannerimage, and --overlayicon all have different failure conditions. I think it would be nice if the dialog window didn't outright fail because an image was defined or downloaded as expected, personally.


Custom admin action to copy subscriptions for a new Event

Could have a simple javascript popup to enter a new Event name or ID to match, copy selected subscriptions but swap the event

Fixed via https://github.com/cb109/gamedoodle/commit/e721d9b7d858c43bf5eab3fb9381efc15b23fc43
No popup, just target the latest Event which is sufficient I think.


curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-cli/master/scripts/install.sh | sh -s is not installing anything

Describe the bug
On Windows 10, in cmd window, typing:
curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-cli/master/scripts/install.sh | sh -s
....doesn't install.
To Reproduce
On Win10, open CMD and run:
curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-cli/master/scripts/install.sh | sh -s
Expected behavior
Installs rosetta-cli
Additional context
coinbase/rosetta-cli info checking GitHub for latest tag
coinbase/rosetta-cli info found version: 0.7.6 for v0.7.6/windows/amd64
...but nothing installed

Same thing happening with me :(. It is not showing any installation or /bin folder.

I just opened #319 for this same issue. To quote here:

The latest release only included source code, with no build artifacts. This has broken install.sh.

@irisZhangCB please update this issue once you upload the new binaries! Thanks

Uploaded binaries

Closing this as related issue has been closed and binaries have been uploaded.


Consider 2-signoff for merging

@eed3si9n WDYT?

I think it would be ideal, but I'm not sure if we can always get 2 ppls attention
so maybe 2 ppl with a timeout

How much of a timeout are you thinking?

I guess it's up to us. 2 ~ 3 biz days?

That sounds good to me. :+1:

Good idea.

I think 2-3 business days might be pushing it. I don't see why we need to rush changes in. (I was thinking more like 1-2 weeks).
But I see people are happy with it, so let's go with that.

Done. The 1.0 branch requires pull request reviews before merging.
There's no direct way to encode "require 2-signoff", sadly.
I'm happy if anyone has any suggestions. Thanks.

Great, so we have a deal! :smile:
To be honest, I think that a contribution cycle of 1-2 weeks would discourage me from contributing to Zinc. I think that if something is important in OSS, especifically in a project as important as Zinc, is fast review iterations so that people are motivated to contribute at any moment without being blocked by reviewers. Not only that, but from the perspective of maintainers it would dramatically slow down any work in Zinc. Release early, release often.
At least, this has been my experience in OSS projects.

Don't confuse a 1-2 week review period with a 1-2 week timeout on 2-signoff.
We're talking about the latter not the former.
We all agree to merge things as fast as possible, and release early and often.

Rules condition the game, so even if theoretically it's not 1-2 week timeout, it can happen. The very fact that one PR gets delayed 1-2 weeks because of us not having a look at it is terrible -- and should not happen IMO. For it not to happen, it's better to enforce a shorter term (as we have already done) that does not even contemplate the possibility of that event to happen.

We all agree to merge things as fast as possible, and release early and often.

Given relatively strict stability requirement (bincompat for 2 years) and the cost of making mistakes, I'm not sure if I would agree with reviewing as fast or releasing early/often for compilers and build tools. Unless the PR has been discussed in advance, I don't want to set too high expectation for the contributors.

I'm actually for releasing early and often, but doing it with care. So, I think that for sbt a good formula would be to release on pull request so that people can try things out immediately. This instant gratification is huge for contributors -- I get drive by it.
So, a good schema would be to cut stable releases every X, where X is the number of days decided by maintainers, and then release normal releases that don't ensure stability of any kind in every PR/every night.
Lots of important projects use similar release processes, like Mozilla and the Chrome team. I think that for projects having a huge ecosystem, like sbt does, it's really important to release early and often and only promise stability on versions that have been tried out for months.

Given relatively strict stability requirement (bincompat for 2 years) and the cost of making mistakes, I'm not sure if I would agree with reviewing as fast or releasing early/often for compilers and build tools.

If you don't agree to reviewing as fast as possible then why did you propose 2-3 business days as a timeout?..

If you don't agree to reviewing as fast as possible then why did you propose 2-3 business days as a timeout?..

Although I don't think we need to process all PRs as fast as possible, I don't want Zinc development to slow down too much given you and I have limited resource we can allocate, for example in the form of OKR. Once the first review completes, I would want the second one to happen relatively soon.


[stable/nfs-server-provisioner] Moved mountOptions to top level

What this PR does / why we need it:
mountOptions in StorageClass were defined as parameters.mountOptions.
This has been deprecated as per https://github.com/kubernetes-incubator/external-storage/blob/master/nfs/docs/usage.md
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md

/remove-lifecycle stale

Any news on this? Thx

/remove-lifecycle stale

/ok-to-test

/lgtm


Don't use this

There is no option here to add the Client ID and Client Secret, You need a server to handle those requests. This does not do that directly. The one provide is in Go and is 6 year old code and not actively maintained. So you will have to handle those requests on the server side itself.
Just build the UI components on your Flutter app and handle the network requests on your server.
Don't waste your time here.

Right


Shape mismatch error upon training with num_class other than 20

OS: Ubuntu 16.04
Python 3.5.2
When I am performing training, I always get shape mismatch error whenever I change the number of class from its default 20. But, if I create the dataset with 20 classes, the training always happens successfully. I have not changed anything in the code and running the provided code in Github.
Whenever the classes were less than 20, I used to overcome the problem by adding some dummy classes and used to make the total as 20. But now, I am having more than 20 classes and I am unable to figure out how to fix this bug.
For example, I am having 24 classes, I am running the following code:
$ python train.py --num-class=24 --class-names='1,2,3,4...,23,24'
This is the error log I am getting.
$ python train.py --num-class=24 --class-names='1,2,3,4...,23,24'
Using mxnet as:
<module 'mxnet' from '/my/path/lib/python3.5/site-packages/mxnet/__init__.py'>
Warning: using pre-installed version of mxnet may cause unexpected error...
(export MXNET_EXAMPLE_SSD_DISABLE_PRE_INSTALLED=1) to prevent loading pre-installed mxnet.
[19:03:21] src/io/iter_image_det_recordio.cc:280: ImageDetRecordIOParser: /my/path/mxnet-ssd/data/train.rec, use 7 threads for decoding..
[19:03:21] src/io/iter_image_det_recordio.cc:333: ImageDetRecordIOParser: /my/path/mxnet-ssd/data/train.rec, label padding width: 350
[19:03:22] src/io/iter_image_det_recordio.cc:280: ImageDetRecordIOParser: /my/path/mxnet-ssd/data/val.rec, use 7 threads for decoding..
[19:03:22] src/io/iter_image_det_recordio.cc:333: ImageDetRecordIOParser: /my/path/mxnet-ssd/data/val.rec, label padding width: 350
INFO:root:Start training with (gpu(0)) from pretrained model /my/path/mxnet-ssd/model/vgg16_reduced
[19:03:22] src/nnvm/legacy_json_util.cc:190: Loading symbol saved by previous version v0.9.5. Attempting to upgrade...
[19:03:22] src/nnvm/legacy_json_util.cc:198: Symbol successfully upgraded!
INFO:root:Freezed parameters: [conv1_1_weight,conv1_1_bias,conv1_2_weight,conv1_2_bias,conv2_1_weight,conv2_1_bias,conv2_2_weight,conv2_2_bias]
[19:03:24] src/operator/././cudnn_algoreg-inl.h:112: Running performance tests to find the best convolution algorithm, this can take a while... (setting env variable MXNET_CUDNN_AUTOTUNE_DE
FAULT to 0 to disable)
[19:03:29] src/operator/convolution.cu:119: This convolution is not supported by cudnn, MXNET convolution is applied.
[19:03:30] /home/travis/build/dmlc/mxnet-distro/mxnet-build/dmlc-core/include/dmlc/logging.h:308: [19:03:30] src/ndarray/ndarray.cc:348: Check failed: from.shape() == to->shape() operands s
hape mismatchfrom.shape = (126,) to.shape=(150,)

Stack trace returned 10 entries:
[bt] (0) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0x1d57cc) [0x7f79ed64b7cc]
[bt] (1) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0xf408c2) [0x7f79ee3b68c2]
[bt] (2) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0xfa1737) [0x7f79ee417737]
[bt] (3) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0xdf2a95) [0x7f79ee268a95]
[bt] (4) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(MXImperativeInvoke+0x254) [0x7f79ee2697a4]
[bt] (5) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(ffi_call_unix64+0x4c) [0x7f7a12f048cc]
[bt] (6) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(ffi_call+0x165) [0x7f7a12f03a15]
[bt] (7) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(_ctypes_callproc+0x283) [0x7f7a12efbe43]
[bt] (8) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(+0x96af) [0x7f7a12ef36af]
[bt] (9) /my/path/bin/../lib/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f7a148c3eca]

Traceback (most recent call last):
  File "train.py", line 134, in <module>
    voc07_metric=args.use_voc07_metric)
  File "/my/path/mxnet-ssd/train/train_net.py", line 268, in train_net
    monitor=monitor)
  File "/my/path/lib/python3.5/site-packages/mxnet/module/base_module.py", line 464, in fit
    allow_missing=allow_missing, force_init=force_init)
  File "/my/path/lib/python3.5/site-packages/mxnet/module/module.py", line 296, in init_params
    _impl(desc, arr, arg_params)
  File "/my/path/lib/python3.5/site-packages/mxnet/module/module.py", line 284, in _impl
    cache_arr.copyto(arr)
  File "/my/path/lib/python3.5/site-packages/mxnet/ndarray.py", line 989, in copyto
    return _internal._copyto(self, out=other)
  File "<string>", line 10, in _copyto
  File "/my/path/lib/python3.5/site-packages/mxnet/_ctypes/ndarray.py", line 89, in _imperative_invoke
    c_array(ctypes.c_char_p, [c_str(str(val)) for val in vals])))
  File "/my/path/lib/python3.5/site-packages/mxnet/base.py", line 129, in check_call
    raise MXNetError(py_str(_LIB.MXGetLastError()))
mxnet.base.MXNetError: [19:03:30] src/ndarray/ndarray.cc:348: Check failed: from.shape() == to->shape() operands shape mismatchfrom.shape = (126,) to.shape=(150,)

Stack trace returned 10 entries:
[bt] (0) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0x1d57cc) [0x7f79ed64b7cc]
[bt] (1) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0xf408c2) [0x7f79ee3b68c2]
[bt] (2) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0xfa1737) [0x7f79ee417737]
[bt] (3) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(+0xdf2a95) [0x7f79ee268a95]
[bt] (4) /my/path/lib/python3.5/site-packages/mxnet/libmxnet.so(MXImperativeInvoke+0x254) [0x7f79ee2697a4]
[bt] (5) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(ffi_call_unix64+0x4c) [0x7f7a12f048cc]
[bt] (6) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(ffi_call+0x165) [0x7f7a12f03a15]
[bt] (7) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(_ctypes_callproc+0x283) [0x7f7a12efbe43]
[bt] (8) /my/path/lib/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so(+0x96af) [0x7f7a12ef36af]
[bt] (9) /my/path/bin/../lib/libpython3.5m.so.1.0(PyObject_Call+0x6a) [0x7f7a148c3eca]

My additional question is has anyone done some study on what is the maximum number of classes it gives good performance. Consider, data can be generated with good amount of diversity for each class and time of training is not a factor.
Thanks in advance for any help.

Weird, unless you load pretrained 20 class model, there's no way the (126,) matrix would appear.
And the the error happened during init_params()
I tried it and don't get similar results using --num-class=2 --classnames='1,2'

You can try --pretrained='' and see if there's any problem

@zhreshold , ya you are correct. I was using the already pre-trained model of 20 class PASCAL VOC dataset used for demo purpose. I changed the weight file to model trained on ImageNet dataset(Please let me know if it trained on different dataset or some differently configured weight file) kept over here https://github.com/zhreshold/mxnet-ssd/releases/download/v0.5-beta/vgg16_ssd_300_voc0712_trainval.zip and it started working fine.
But I just want to share my experience that I had obtained good results with model trained on 20 class PASCAL VOC dataset on my own dataset when number of class was less than 20.
I am closing the issue as my problem has been resolved.


Add setMetaDataAndTokenURI method

Fixes #1228  .
Changes proposed in this PR:

add support for setMetaDataAndTokenURI function
added unit test

should be good, just the naming. We mirror that typo from the contracts, as metadata is one word so the method should be setMetadataAndTokenURI. As you already corrected that with e.g. setMetadata() method we should stay consistent and also correct this in all methods in this PR

should be good, just the naming. We mirror that typo from the contracts, as metadata is one word so the method should be setMetadataAndTokenURI. As you already corrected that with e.g. setMetadata() method we should stay consistent and also correct this in all methods in this PR

sure going to handle it for both methods and interfaces that we have in oceanjs and update the naming and once that's fixed in contracts I'm going to tackle it another pr and update the names of the functions we call


Expose open state via prop

Expose open state via prop

[Current coverage][cc-pull] is 90.85% (diff: 100%)

Merging [#531][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #531   diff @@
==========================================
  Files            10         10
  Lines           339        339
  Methods          14         14
  Messages          0          0
  Branches         52         52
==========================================
  Hits            308        308
  Misses           14         14
  Partials         17         17

[][cc-pull]

Powered by Codecov. Last update [beb908d...7ded8fa][cc-compare]
[cc-base-branch]: https://codecov.io/gh/Hacker0x01/react-datepicker/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/Hacker0x01/react-datepicker/compare/beb908d5a27d7bc6f5782ae99b4e2c26d14da889...7ded8fa73aaa16584553e7fed9d9b094601f9dba?src=pr
[cc-pull]: https://codecov.io/gh/Hacker0x01/react-datepicker/pull/531?src=pr

Hey @schickling, thanks for the PR.  I think this needs to be a little bit more -- this only covers the initial open state, but I think to fully address #283 the open prop needs to also change the open state after the initial mount.
The way I can see this working is that if the open prop is specified, then obey the prop, or else delegate to the original open state behavior.  I'm not sure if the callbacks we currently expose make it feasible.  Imagine you wanted to emulate the old behavior; you would probably want to attach callbacks to onFocus, onBlur, and potentially others.  However, we would probably need some special handling of these -- e.g. imagine the case where the picker is open and you click on the calendar; technically onBlur will fire, but we don't want to close the picker.
I've been putting off addressing #283 because of these complications, but let me know if you want to take a crack at it. :smile:

Closing this out because of inactivity.


[skip ci][ci] Skip flaky test_cudnn test

See #10746
cc @areusch @masahi

As I commented in https://github.com/apache/tvm/issues/10708#issuecomment-1075633745, can we just relax the tolerance a bit?


Bitsum.ParkControl version <IP_ADDRESS>

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

what

@OfficialEsco After commiting your changes this is happening now what to do?

it should be fine now

You will have to change the Publisher folder name.
manifests/b/Bitsum/ParkControl/<IP_ADDRESS>/
to
manifests/b/BitSum/ParkControl/<IP_ADDRESS>/

how to do that

For the third time, press . on your keyboard.

opened web editor

Click the icon in the Top Right corner named Explorer, there you can work with the files just like File Explorer.

folder BitSum already created

Drag ParkControl to BitSum then Capitalize the S in the installer, version and locale.

I'm doing it

I think so

Yes do that, then rename the files, then when you are done with all of that you click the third icon on the left, the click the checkmark that says commit and it will appear here.

Type Resolved Capitalization in the Message field

what to do now

now its ok

Uhhh, hold on, is there a Push button somewhere?

I don't think so

I checked every icon on the screen

Ohh you have to click Commit after you've typed your commit message

done

Now I understand how mods work
The wingetbot and msftbot just check that it installs in background and when the validation ssucced you mods than check the code and then review and then it merges to the repo


Icons

It's a small point, but it would be great if the ribbon icon (the map pointer) was also used for the interactive map views in place of the standard file icon.

vs.

Oh nice I never noticed that, thanks! Done, will be in the upcoming version.

Added as part of the just-released 5.0.0.


Deserialize arbitrary objects

Description

Adding a deserialize function which will work on any object registered.
Requires a two step process of checking for the object then deserializing it.
For example, if I would like to deserialize some arbitrary class:
from pymc_marketing.deserialize import register_deserialization, deserialize

class AbitraryClass:
    def __init__(self, a, b):
        self.a = a
        self.b = b

    def to_dict(self):
        """Not required here but just to show what is being deserialized."""
        return {"a": self.a, "b": self.b}

register_deserialization(
    is_type=lambda data: "a" in data and "b" in data,
    deserialize=lambda data: AbitraryClass(**data),
)

# Then using
instance = deserialize({"a": 1, "b": 2})

[!NOTE]
This two step process comes from the fact that the current serialized objects have different structures from each other

Related Issue

[ ] Closes #1293
[ ] Related to #

Checklist

[ ] Checked that the pre-commit linting/style checks pass
[ ] Included tests that prove the fix is effective or that the new feature works
[ ] Added necessary documentation (docstrings and/or example notebooks)
[ ] If you are a pro: each commit corresponds to a relevant logical change

Modules affected

[x] MMM
[x] CLV

Type of change

[x] New feature / enhancement
[ ] Bug fix
[ ] Documentation
[ ] Maintenance
[ ] Other (please specify):

📚 Documentation preview 📚: https://pymc-marketing--1296.org.readthedocs.build/en/1296/

Closes #1300

Thanks @wd60622 !


Terraform Organization Support

Description
What

Added support for terraform organization (PORT-5917)
Added tags to terraform workspaces

Type of change
Please leave one option from the following and delete the rest:

[ ] New feature (non-breaking change which adds functionality)

LGMT... One thing that you probably have missed is the workspace tags for the webhook event. I see for every new webhook event, you get the terraform workspace (get_single_workspace). You may want to also get the workspace tags just like you do for the resync events


Implement missing stage types from alpakka-kafka project

There are lots of consumer and provider stage types already implemented in this project: https://github.com/akka/alpakka-kafka
We need to implement consumers from here:
https://doc.akka.io/docs/alpakka-kafka/current/consumer.html
And producers from here:
https://doc.akka.io/docs/alpakka-kafka/current/producer.html
Some of them are going to be based on brand new flowWithContext-type stages implemented, so until Akka.NET v1.4.0-beta2 will be released, this can be based on nightly Akka builds.
This is not critical to implement all stages from alpakka right now, so the concrete must-have list to implement will be specified/discussed later.

I wrote some short overview about how current scala implementation uses buffering and separate actor for stages implementation here
It looks like we will need to implement something similar in our project. This is going to be a series of PRs with

Code refactoring to use base classes containing shared logic between stages.
Implementing of missing stages (or some of them)
Looking at the external actor usage to consume messages in batch.

The one more thing I noticed in scala imlementation is that consumer.Poll method they use returns list of messages - but our confluent driver returns only one message in a time. This may result in somewhat different implementation on our side.

@IgorFedchenko let's add the following stages next so we can do a beta release of this package:

FlowWithContext
Flow
Sink

@Aaronontheweb So you want to implement some of Transactional Producers?
Also, I suspect I will need FlexiFlow producer implemented to implement FlowWithContext - I will check that out.

Ok, got it - thank you!

@IgorFedchenko so only 3 more stages left?

@Aaronontheweb Technically yes. But the thing is that transactional sources are ment to be used in pair with transactional producers. And transactional producers are based on IProducer of Confluent driver, which does not support transactions yet (see our issue #85 ). So, until they will add support for transactions, there is no much point in implementing the rest of the stages.
But if I will not have any other work to do, I will work on this, so that after Confluent driver will fix their issue we could just make minor changes in code and make it all work.


[JENKINS-41870] Change format of time durations

Description
Can see changes in storybook.
@i386 Note this change makes it so 3minutes will be "3m 0s" not "3m" like ticket says. I could not figure out how to do it as per ticket in  momentjs. I assume this is ok?

See JENKINS-41870.

Submitter checklist

[x] Link to JIRA ticket in description, if appropriate.
[x] Change is code complete and matches issue description
[x] Appropriate unit or acceptance tests or explanation to why this change has no tests

Reviewer checklist

[ ] Run the changes and verified the change matches the issue description
[ ] Reviewed the code
[ ] Verified that the appropriate tests have been written or valid explanation given

@reviewbybees

@imeredith I am OK with that.

:bee:
I did liek the cute descriptions, but they aren't practical.

this looks like it isn't quite right yet cc @cliffmeyers

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.


Refactor helm charts

TODO:

[x] refactor charts (follow helm best practices)
[x] test new chart (should generate same manifest as before)
[x] update istio.Version and build script to generate new values.yaml
[x] Add a README.md
[ ] Create a e2e test for the helm charts (follow-up PR)
[ ] Add add-ons (follow-up PR)

@costinm FWIW, I've developed a similar script for cert-manager (to generate yaml files from a helm chart to save duplication):
https://github.com/jetstack/cert-manager/blob/master/hack/update-deploy-gen.sh
with a corresponding verify script:
https://github.com/jetstack/cert-manager/blob/master/hack/verify-deploy-gen.sh


Feature request, retrieve HTML from render.

This feature would be nice for generating HTML emails.
I'm using Klein in conjunction with SwiftMailer.
I'm aiming to send HTML emails for my contact forms. Was wondering if I could pass the variables to Klein with the view to render then pass that HTML code on to SwiftMailer to send out.
Or is there a method to handle this already?

:hankey: hardcore
$service->partial('tpl/mail.html');
$message = Swift_Message::newInstance()
		->setBody(ob_get_contents(), 'text/html');
$result = $mailer->send($message);
ob_clean();

$service->render('tpl/page/send.html');
``


Cannot read property 'component' of undefined

Hi,
Whenever trying to mount element with function using React.render(<SuperComponent />, document.getElementById('container')); where <SuperComponent /> contains MUI components or is a MUI component itself, I getCannot read property 'component' of undefined` error message. Mounting elements that do not have MUI elements work just fine.
Expanding error it makes clear that this is somehow related to ThemeManager.

@nerijusgood Can you provide the code for the component that you are passing to React.render?

I'm having this issue too for hours until I deleted all mui components and it worked (I tried custom components and worked aswell)!
import React from 'react';
import { TextField, Paper, Styles, Utils, RaisedButton } from 'material-ui';

let Colors = Styles.Colors;
let ColorManipulator = Utils.ColorManipulator;
let ThemeManager = new Styles.ThemeManager();

class CustomModal extends React.Component {
  constructor() {
    super();
  }

  render() {
    return (
      <Paper>hello</Paper>);
  }
};

CustomModal.childContextTypes = {
  muiTheme: React.PropTypes.object
}

export default CustomModal;

Hope you can find the solution.

I am also seeing issues when trying to mount components that contain material-ui components. Stack Oveflow question here: https://stackoverflow.com/questions/46187276/error-using-enzymes-mount-to-test-react-component-that-contains-material-ui-com


More flexible Auto Create Schema Objects

I would like a more flexible Auto Create Schema, out of fear :)
Auto creation in production is awesome.
Auto update of Columns in production are awesome too.
However auto re-creation in production is scary, but is awesome in development.
I would like to say something like:
Dev:
_.AutoCreateSchemaObjects = AutoCreate.All
Prod:
_.AutoCreateSchemaObjects = AutoCreate.CreateAndUpdate
or
_.AutoCreateSchemaObjects = AutoCreate.CreateOnly
Disabled:
_.AutoCreateSchemaObjects = AutoCreate.Off

All would Create / Destroy / Recreate
CreateAndUpdate would create the tables and and/update indexes but never destroy the table.
CreateOnly would create the initial tables but never update anything, would require manual updates from the generated schema.
Off would disable all auto creation.
That's my thoughts so far.

We might need to be getting smarter with indexes here. Sounds good to me.

I've got this partway so far. Good hour might finish it off.

What scenarios would not be covered by CreateAndUpdate that only All would sufficient?
Would that mostly be constrained to activities such as rename type, rename existing property?

@dotnetchris All will drop and re-create... Create and Update will not re-create so no data loss.

What types of changes to c# classes result in schema changes that need drop to occur?


No kernel for grammar Sage found

Description:
I can't seem to get hydrogen to recognize sagemath jupyter kernel.
Steps to Reproduce:

Set "Sage" as atom language in my document

In Hydrogen settings, use {"sagemath": "Sage"} for Language Mappings

Receive "No kernel for grammar Sage found" error message

Versions:
macOS 10.12.6
Hydrogen 2.2.1
Atom 1.23.3
Logs:
Atom Console:

Output of "jupyter kernelspec list":

@n-riesco
@gmd7

I have the same problem:
jupyter kernelspec list --json:
{
  "kernelspecs": {
    "python3": {
      "resource_dir": "/Users/imh/Library/Jupyter/kernels/python3",
      "spec": {
        "argv": [
          "/opt/local/bin/python3",
          "-m",
          "ipykernel_launcher",
          "-f",
          "{connection_file}"
        ],
        "env": {},
        "display_name": "Python 3",
        "language": "python",
        "interrupt_mode": "signal",
        "metadata": {}
      }
    },
    "sagemath": {
      "resource_dir": "/opt/local/share/jupyter/kernels/sagemath",
      "spec": {
        "argv": [
          "/Applications/SageMath/local/bin/sage",
          "--python",
          "-m",
          "sage.repl.ipython_kernel",
          "-f",
          "{connection_file}"
        ],
        "env": {
          "SAGE_ROOT": "/Applications/SageMath/sage"
        },
        "display_name": "SageMath 8.8",
        "language": "sage",
        "interrupt_mode": "signal",
        "metadata": {}
      }
    }
  }
}

When I run Hydrogen: Update kernels it only shows the Python 3 kernel, which I find strange.

Did you follow the same steps as the user above ie language mapping and using a sage grammar?

@wadethestealth Yes, I would say so.
Atom 1.40.1
Hydrogen 2.12.0
language-sage 0.3.2
New file, setting grammar do source.Sage. Kernel is installed in jupyter as shown above. Hydrogen has language mappings set to { "sagemath":"Sage", "python": "magicpython"}.
However, as I wrote, is consistent in its behaviour, as it clearly states it is aware of the Python 3 kernel only whenever I have it update de kernels.

@benrussert @aviatesk

I was able to solve the issue by following this comment: https://github.com/nteract/hydrogen/issues/1074#issuecomment-514080192
I copied /opt/local/share/jupyter/kernels/sagemath to ~/Library/Jupyter/kernels/ and now it works.
I have read that hydrogen searches for kernels in all paths listed in the data section of jupyter --paths.  Maybe that's not working correctly. The path /opt/local/share/jupyter is listed there, but as the last line. The path ~/Library/Jupyter is the first entry. And now that the kernel is in there, hydrogen finds it.

@fippu I am glad you figured it out. We still may need to investigate further on our side
cc: @aviatesk @BenRussert


moving and renaming some packages :grimacing: - quite a big diff

rename tables package to extensions as it includes both tables and funcs
implement  go_mod func for parsing go.mod files
rename funcs to helpers

Codecov Report

Merging #154 (3754733) into main (f21a89a) will increase coverage by 0.18%.
The diff coverage is 81.81%.

@@            Coverage Diff             @@
##             main     #154      +/-   ##
==========================================
+ Coverage   68.47%   68.65%   +0.18%
==========================================
  Files          29       31       +2
  Lines        1589     1611      +22
==========================================
+ Hits         1088     1106      +18
- Misses        321      323       +2
- Partials      180      182       +2

Impacted Files
Coverage Δ

extensions/internal/enry/enry_detect_language.go
42.85% <ø> (ø)

extensions/internal/enry/enry_is_binary.go
66.66% <ø> (ø)

extensions/internal/enry/enry_is_configuration.go
66.66% <ø> (ø)

extensions/internal/enry/enry_is_documentation.go
66.66% <ø> (ø)

extensions/internal/enry/enry_is_dot_file.go
66.66% <ø> (ø)

extensions/internal/enry/enry_is_generated.go
66.66% <ø> (ø)

extensions/internal/enry/enry_is_image.go
66.66% <ø> (ø)

extensions/internal/enry/enry_is_test_file.go
66.66% <ø> (ø)

extensions/internal/enry/enry_is_vendor.go
66.66% <ø> (ø)

extensions/internal/git/log.go
79.38% <ø> (ø)

... and 22 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 f21a89a...3754733. Read the comment docs.


Merge to master  - Windows Blog Release 04/15/19

Merge to master

Docs Build status updates of commit f1fed71:
:warning: Validation status: warnings

File
Status
Preview URL
Details

documentation/blog/MS-WININTBLOGLP/ad7103c7-9155-4cd8-a835-f3ecccdd21db.md
:warning:Warning

Details

documentation/blog/MS-WININTBLOGLP/MS-WININTBLOGLP_files/image001.png
:white_check_mark:Succeeded

documentation/blog/MS-WININTBLOGLP/MS-WININTBLOGLP_files/image002.png
:white_check_mark:Succeeded

documentation/blog/MS-WININTBLOGLP/MS-WININTBLOGLP_files/image006.png
:white_check_mark:Succeeded

documentation/blog/MS-WININTBLOGLP/MS-WININTBLOGLP_files/image009.png
:white_check_mark:Succeeded

documentation/blog/MS-WININTBLOGLP/toc.yml
:white_check_mark:Succeeded

documentation/blog/MS-WININTBLOGLP/ad7103c7-9155-4cd8-a835-f3ecccdd21db.md

[Warning] Author openspecs-office cannot be recognized in GitHub.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


add to cart problem for simple product

i call this mobileapi/products/getproductdetail?product_id=2581
and got this (Simple Product)
{
"code": 0,
"msg": null,
"model": {
"price": "0.00",
"in_wishlist": false,
"entity_id": null,
"rating_summary": null,
"reviews_count": null,
"sku": null,
"status": 1,
"name": null,
"news_from_date": null,
"news_to_date": null,
"product_type": null,
"special_from_date": null,
"special_to_date": null,
"image_url": "",
"regular_price_with_tax": "0.00",
"final_price_with_tax": "0.00",
"short_description": null,
"description": null,
"additional": [],
"symbol": "\u20b9",
"options": [],
"mediaGallery": [""]
}
}
now what will be url for simple product add to cart ? can you explain super perimeter for simple product
/mobileapi/cart/add?product_id=2581&qty=5&super_attribute[92]=22&super_attribute[180]=80

Sorry It was my mistake problem solved


Optional package features

I want to run a couple ideas past this group, which is mostly targeted at deciding whether it makes more sense to help implement features here versus update our similar feature to use lazy loading under the hood. The use case in mind is optional (extra) dependencies, and see the next (collapsed) section for details.
The features I'm proposing are are:

Version constraints (I'm thinking packaging.requirements arbitrary strings, but minimum versions are probably >90% of the use case)
Boolean "found package" return value

Here is a quick API proposal to demonstrate:
import lazy_loader as lazy
h5py, have_h5py = lazy.load_requirement('h5py>=3.0')

Here h5py would be a lazy module, which will fail if either h5py is not installed or its version does not satisfy >=3.0. have_h5py will be a boolean that can be used to determine whether accessing attributes of h5py will fail without attempting the load.
I think this would in practice require adding importlib_metadata (for Python <3.9) and packaging to the dependencies, so it might be out of scope if you're trying to keep this absolutely minimal.

Click for some details about what I would use this API to replace
We've been doing something similar to lazy.load in nibabel.optpkg.optional_package for a while, that looks like this:
from nibabel.optpkg import optional_package
h5py, have_h5py, setup_module = optional_package('h5py', min_version='3.0')

h5py is either the fully loaded h5py module or a "tripwire" object that will fail when you attempt to access an attribute. So it is (currently) only lazy in the sense that an ImportError does not occur immediately (and will be replaced by a more appropriate informative error message). But from a namespace standpoint, lazy.load('h5py') and optional_package('h5py')[0] are interchangeable.
Importantly for the optional dependency use case, an installed version that is lower than the required version is treated as a failure to import. This can come up periodically, and a dependency mismatch is only relevant to the user or downstream tool if they are accessing h5py functionality in nibabel which might require a higher version. (The error message, of course, explains the issue.)
The other features are have_<module>, which is a simple bool. I personally mainly use it for tests like @unittest.skipUnless(have_h5py, reason="Needs h5py"), but you can imagine other cases when it's more convenient than accessing the module and allowing/catching an exception.
Finally, setup_module is just a convenience that will raise a SkipTest() exception so a module that can't be tested at all without the dependency will be skipped by tools like nose or pytest. (Often we will use `h5py, have_h5py, _ = optional_package('h5py'), if we don't want to skip the entire module.) This is almost entirely unused even internally, so I'm not proposing to add it here.

I'm wondering if this is the right place to check for dependencies. These requirements are usually handled by pip, conda, etc. Do you know of package that check, at runtime, whether their installation requirements are met? My gut feel is that it is out of scope for the lazy loader, but then I also haven't thought about it much.

Do you know of package that check, at runtime, whether their installation requirements are met?

Nilearn is the main one I know of that is so comprehensive: __init__.py and version.py
In practice, I would say most tools I've seen import install_requires dependencies at the tops of modules. So import nibabel will fail if you somehow got it in an environment without numpy. And then extras_require dependencies would either be guarded like
try:
    import h5py
    have_h5py = True
except ImportError:
    have_h5py = False

Or imported in function scopes:
def myfunc(...):
    import h5py  # Raises ImportError

optional_pkg is nibabel's compromise that lets you put h5py = optional_package('h5py') at the module head but defer the exception until you try to access it, which it turns out lazy.load() also does.
Just as a proof-of-concept, I could rewrite it:
def optional_package(pkg):
    mod = lazy.load(pkg)
    have_mod = pkgutil.find_loader(pkg) is not None
    return mod, have_mod

Setting a minimum version would add some complication, as we would need to return something besides lazy.load() if the module exists but is too old.

Thoughts @matthew-brett?

If there's no opposition, I can try to put together together a PR in the next month or so and see how intrusive it is.

Thank you, Chris.