"Why not Conan?" FAQ section confuses and misrepresents

All 4 portions of the "Why not Conan?" section of the FAQ either lack logical coherence or are completely orthogonal to technical merit and tool suitability.
The "Public federation vs private federation" section argues against permitting individuals to publish packages, stating

"we believe there should be a single, collaboratively maintained version which works for the vast majority of cases and allow users to hack freely on their private versions. "

You don't need extreme (and unfortunate) technical limitations in order to create a walled garden. Just run your own Conan server, and only authorize uploads from the microsoft account. You can keep the ports directory - just replace 'CONTROL' with conanfile.py (there's an automated tool for it). Only permit CI to with that account - and voilà! You've perfectly mirrored the existing access permissions and model for vcpkg, and done so without crippling user freedom.
You can argue for curation, sure, but baking that into design for build dependencies doesn't end well. I love Homebrew, but we're lucky to get non-core packages like libvips updated within 2 months. Reliance on curated listings doesn't scale. If you do curation, strictly limit to to what you can commit to manage and respond to 0days for. Encourage and support the community in doing the rest.
If you want to improve discoverability of 'official' packages in Conan, submit a PR for the package sorting algorithm. A convention of prioritizing packages where the username and package match would be an nice, zero-maintenance way to allow authoritative versions through username reservation. Or just only allow 1 instance per package name. We're talking about trivially tweaking the package server. Your first reason lacks substance.

Per-dll vs Per-application. When dependencies are independently versioned on a library level, it encourages every build environment to be a completely, unique, unable to take advantage of, or contribute to a solid, well tested ecosystem [emphasis mine]. In contrast, by versioning all libraries together as a platform (similar to a system package manager), we hope to congregate testing and effort on very common sets of library versions to maximize the quality and stability of the ecosystem. This also completely designs out the ability for a library to ask for versions that conflict with the application's choices (I want openssl Z and boost X but X only works with openssl Y).

This contradicts decades of evidence. All other development package managers (that I know of) allow libraries to specify dependencies. This isn't something the entire world got wrong. ABI fragility isn't unique to C/C++, just accentuated. We'll talk about system package mangers (and their role in C/C++ software development) later.
Conan supports per-application versioning, and dependency version overrides. Your application just uses another conanfile.py to specify dependency versions. That said, I've been just fine (and override free) with Conan's ecosystem.
The maintainers of a library are usually in the best position to know which versions of its dependencies should be the default. You use the word ecosystem. I do not think that word means what you think it means.  For in the previous paragraph, you said:

we believe there should be a single, collaboratively maintained version

That is ...not an ecosystem. But we will discuss ecosystems later. You continue

we hope to congregate testing and effort on very common sets of library versions to maximize the quality and stability of the ecosystem.

So.. "versions". Okay. I like the concept of opt-in platform versions. I.e, "here's a set of library versions, all of which are compatible". And here's a new set of versions. etc.
That's great. That could also come in the form of:

A git repository  with a single plain text file of conan version numbers.
A trivial pull request to add said feature to Cargo.
Something not claiming to replace a package manager. I like the name "Port Tree". It doesn't imply anything more than it is - a collection of build scripts for various curated packages.

Doesn't vcpkg only support 1 (user-wide) set, though?
An enforced system-wide version set is exactly the pain we've been trying to escape from for decades on linux/mac. We've invested tremendous effort in escaping this situation. It completely prevents cross-platform development, because no two operating systems will contain the same version set.
Don't you think designing out the ability for libraries to specify dependency versions is a bit overkill? That's one way to ensure an ecosystem can never develop, because packages can only have good usability if they live in an official platform set.
Your choice of OpenSSL as a conflict example is a good one. Across my projects, breaking OpenSSL API changes have painful. But none of that pain was present for Conan-managed libraries. I can clearly see what versions libraries support, and if I need to update something, it only takes a few minutes.  How would a Windows-system-wide copy of OpenSSL be any less painful with vcpkg than it was with homebrew or apt-get? Please describe - this would be an excellent addition to the FAQ. I would describe the balance and boundary between curated and non-curated software, and how the size of that surface affects the suitability of this tool.
Reason 2 is hyperbolic doublespeak.

Cross-platform vs single-platform. While being hosted on many platforms is an excellent north star, we believe the level of system integration and stability provided by apt-get, yum, and homebrew is well worth needing to exchange apt-get install libboost-all-dev with brew install boost in automated scripts.

I don't use homebrew or apt-get or Chocolatey to manage my dependencies. I could, in theory, develop within Docker containers, and use apt-get or homebrew inside them. But I'm not forced to, because Conan exists. I have full package isolation, and can support as many different sets of versions as I want. Today, I'm simultaneously running Conan on OS X 10.11, Windows 10, and Ubuntu 14.04. I have several different project with different needs, and everything JUST WORKS.
This is nice. It's what I'm used to experiencing with RVM+Bundler, Virtualenv+pip, Rustup+Cargo, npm,  and even NuGet (modulo a few bugs).
Let's clarify some terms:

System package managers: apt-get, homebrew, Chocolatey. Only one version of a package can exist on the system. One can have gcc and gcc5.3, but they are separately named packages. You can't run gcc5.3 by invoking gcc. The other limitation of apt-get, homebrew, and Chocolatey is that they only install with root access.
Dependency package managers: Bundler, npm, Cargo, pip, nuget. Usually associated with a certain language or set of languages, where the package manager's design often takes specific needs of the language's compiler/runtime into account.  These usually rely on the system compiler/runtime for their language, and are therefore combined with environment managers so that developers can work on more than 1 project at a time (assuming different projects need different versions).  There are usually multiple instances installed if you're using a version manager. Many offer primitive runtime/compiler switching, or are intentionally environment.version manager friendly.
Environment managers: rvm, rbenv, nvm, virutalenv, dnx. rustup. These allow you to use different compilers/runtimes - and different package manager versions - for a given language at the same time. They may shuffle storage data around so that package managers (if using user-local storage) aren't reusing the same caches against multiple runtime versions.

In developing C/C++, we're constrained by our system package manager's curation as to what compilers we can have simultaneously installed. We do have the CXX and CC env vars, however, and Conan helpfully provides compiler switching. In doesn't redefine any behavior outside of its process duration, however, so in this respect it is more like rbenv than rvm.
System-wide build dependencies preclude reasonable cross-platform development
System-wide package management works smoothly when you're not adding any custom code to the mix, and you're not at all picky about what version of at tool you end up with. This constraint is often unacceptable, so modern tools often ship in docker containers. A new generation of languages appeared just to solve this problem through pervasive static linking. (Which has servicing concerns)
Developing software against system-wide dependencies is a nightmare. We have no recourse against breaking changes in security updates, no method for compiling two (completely separate!) tools that need different libpng ABIs. This is unnecessary pain.
This is a very strange point in time (given Microsoft's new strategy) to begin (deceptively, or through ignorance) promoting approaches that tie developers to Windows and ensure future pain.

We chose to make our system as easy as possible to integrate into a world with these very successful system managers -- one more line for vcpkg install boost -- instead of attempting to replace them where they are already so successful and well-loved.

There are successful system managers in this world, yes. I'd also say  OneGet might deserve the designation. Your design does not make vcpkg easier to integrate.  This paragraph tries to frame vcpkg as filling the role of a systems package manager, and is very cleverly worded.
But the goal of improving developer experience across operating systems is not well served by vcpkg. Linux package mangers came first, and distributions offered floating, but usually compatible, versions of libraries and tools in curated repositories. One could switch 'stable/beta' channels by changing repositories. But compatibility between distributions was still poor, and we often, through time constraint, had to pick one distribution at a time to support. Backports might happen.  So when we started bringing those apps to Mac, we needed to mimic that set of dependencies. Today, Homebrew recipes often use precompiled binaries, and often fetch specific dependency versions. Homebrew also makes it possible to install specific recipie versions.
We didn't, and can't improve developer experience by increasing the number of permutations they must troubleshoot.
It should be telling how unified and focused the entire industry has been on eliminating system package management. Dependency hell is painfully expensive in development, but catastrophic in production. Thus we got Docker, and Ubuntu Snap Packages, and a hundred iterations of containerized packages, and a dozen new cloud operating sytems all with the goal of NOT sharing dependencies with anyone else, and sometimes even eliminating system package management altogether.
Reason 3 ignores modern development and devops practices, and uses some of the trickiest wording I've seen outside diplomatic cables.

C++/CMake vs python. While Python is an excellent language loved by many, we believe that transparency and familiarity are the most important factors when choosing a tool as important to your workflow as a package manager. Consequently, we chose to make the implementation languages be as universally accepted as possible: C++ should be used in a C++ package manager for C++ programmers. You should not be required to learn another language just to understand your package manager.

Arguments: 1. Transparency, familiarity of interaction with tool. 2. Implementation language as universally accepted as possible. 3. You shouldn't need to learn another language to understand your package manager.
I'm going to assume that if you've successfully edited a .ini file, you can use the declarative conanfile.txt syntax. If you're keeping logic in CMake, it's likely sufficient. Conan passes CMake all the variables you need. You'd probably switch to conanfile.py if you need different dependencies depending on the operating system (say you use SChannel on Windows, but OpenSSL on linux).
For the sake of argument, let's start with one of the most complex examples listed for conanfile.py:
from conans import ConanFile, CMake

class PocoTimerConan(ConanFile):
   settings = "os", "compiler", "build_type", "arch"
   requires = "Poco/1.7.3@lasote/stable"
   generators = "cmake", "gcc", "txt"
   default_options = "Poco:shared=True", "OpenSSL:shared=True"

   def imports(self):
      self.copy("*.dll", dst="bin", src="bin") # From bin to bin
      self.copy("*.dylib*", dst="bin", src="lib") # From lib to bin

   def build(self):
      cmake = CMake(self.settings)
      self.run('cmake "%s" %s' % (self.conanfile_directory, cmake.command_line))
      self.run('cmake --build . %s' % cmake.build_config)

Is anyone capable of writing C or C++ going to have trouble understanding this?
The most magical bit is that CMake(self.settings) has a .command_line and .build_config method, and that this generator-specific logic makes more variables available to CMake than you would expect.
I can't compare this to vcpkg, because I don't see where it even offers a dependency list. I assume that some kind of script is used to invoke it for each package? Looks like you're learning another language!
Argument 2. Implementation language as universally accepted as possible.
Accepted by who? The operating system? Python is the most ubiquitously installed scripting language on earth, as far as I know. It's usually present on even the most minimal docker images. You distribute it with Visual Studio. It's bundled with pretty much every distribution of linux and os x.
If you're talking about comprehension by the C++ development community, that's an unusual argument to make. Package managers aren't usually inspected; we just expect them to work. If they don't, we complain to specialists who understand the domain. It's a large domain, and there are many pivots, and complexities.
Let's look at some examples. NuGet has been around for 5+ years, but only acquired 30 significant contributors. I didn't spot any that weren't MSFT employees. Perhaps the project isn't managed as a true open-source project, and that had an effect. Let's look at a community-developed project - Chocolatey. Wow. Just one significant contributor.
Domains like package management, codecs, image processing libraries - they require a lot of domain knowledge to contribute to. As maintainers, we want to choose the technologies that we think are most likely to encourage contribution. We're better off choosing the best tool for the task. If there's already a tool that does what we need, we use it.
Rejecting a tool because isn't written in your favorite language seems like a Microsoft culture phenomenon. In other communities, we aggressively blend tools written in a range of languages. Take a rails app. There are usually 1-2 tools written in an ML-style language, several C and C++ components, embedded lua runtimes, some form of npm for asset management (at least), Perl (using git?), a bit of Crystal, Rust, various Java packages, and a variety of Python apps that you probably don't know are built with Python, because they've haven't spewed a stacktrace yet.
We're hoping to see NuGet reach 60% feature parity with Bundler by 2019. I'm told that, before NuPack, in the early stages, Bundler was being used. But it needed to be C#, not Ruby, of all things. So we resorted to ... a single-platform, single-tool set of scripts claiming to be a package manager. There's history here, and it seems to be repeating.
Argument 3. You shouldn't need to learn another language to understand your package manager.
My response: documentation.
vcpkg should not brand itself as a package manager
There's already an open-source package manager for C and C++. It's well designed, the result of many real-world iterations and deployments, and backed by developers with an incredible amount of experience in the space.

It handles pivots extremely well across operating systems, C runtimes, and compiler compatibilities.  The design is excellent.
It is build-system agnostic - able to integrate with everything - yet is  incredible simple to understand and use.
It can work directly with Visual Studio, through CMake, or nmake, or any tool you like, yet has minimal boilerplate.
You have conanfile.txt or conanfile.py to declare your package, dependencies, extra configuration/pivots, and build invocation through which the pivots are sent. Providers for the top 12 build systems make this automatic - unless you want more control. At no level of abstraction is there pain. conaninfo.txt, the file Conan creates in a target build directory, provides visibility into the compiler settings and package versions in use.
Essentially cruft-free, yet handles extremely complex situations.

It is trivial to use with Visual Studio and CMake.
Ecosystem
I said I'd get back to ecosystems. vcpkg's FAQ describes itself as the champion of a package ecosystem, and specifically superior in this respect to Conan. Let's zoom back a bit and look at the ecosystem of package managers.
Adoption of package managers
C and C++ are hard languages for which to do package management. Developers are justifiably gun-shy - many build tools have claimed to tackle package management, but failed horribly on key details. Some build-tool-specific managers exist (cpm, hunter).
It's hard to encourage devs to invest in new tooling, given obvious limitations (or suspicion of hidden ones).  Before Conan, the core developers created Biicode. As a company, Biicode was unable to monetize C/++ package management, and eventually went bankrupt. They took the lessons learned from commercial C++ package management and designed Conan, while helping Biicode users transition as best they could, and funding their work with weekend consulting. They community grew, and They're now a part of JFrog/Artifactory, but I've not seen that much dedication to a problem before.
The C/C++ ecosystem consensus seems to be converging towards CMake as a cross-platform build tool. This makes my life easier. But adoption of package management is a slower task, despite requiring a much smaller effort.  The pain of system package managers has spawned a "copy the source in-tree" religion that is very hard to eradicate.
Maintainers of common packages are just beginning to add conanfile.py, and setup Travis and AppVeyor for cross platform package deployment. We badly need this trend to continue if we want low-friction cross-platform development to become ubiquitous.
Microsoft has a recorded history of displacing existing or nascent open-source projects. Often the replacement was designed without a study of prior art, and lacking in technical merit.
The most effective approach to ensuring a solution succeeds based on advertising or brand, rather than merit, is to either
(a) pretend you've never heard of them, and be silent in places where users trust you to credit prior art, or
(b) use a disinformation strategy to ensure the competition's role and merit is misunderstood.
Given that a massive contingent of the software development community looks to the Microsoft brand for leadership in tool and technique selection (evangelism does its job), I would argue that a majority of Windows C# and C++ developers entering the open-source space are doing so (at least in part because) Microsoft has embraced open-source. They still favor tools Microsoft signals interest in.
Herd mentality overrides almost all else, and software developers participate in this intentionally, perhaps hoping that usage of a thing will delay it's inevitable, eventual, abandonment. Microsoft may no longer be the bellwether of the software industry, but it is still the bellwether for an extremely large contingent, and that is quite enough to start a herd.
There's some irony that download and Github issue count may have no bearing on software longevity - the Contributors tab is what matters - but in adoption, perception is 90%.
I like to think that there is a hangover from closed-source culture that takes a long time to shed, and that  this hangover (rather than any particular intention) is responsible for the more careless events that have so strained Microsoft's relationship with the open-source community in the last decade.
Microsoft employees who have been active for a very long time in the larger open-source community seem more careful to consider the impact of their publications, and more effective at reaching their goals through collaboration and coordination. More wood behind fewer arrows.
Many people argue that 1 package manager per language is too many, and unsustainable given the domain difficulty and contributor pool. They're right. It doesn't matter, though, because software developers need package managers for rapid development, and they need language-specific features. We can (and have been) unifying the science of package management, and this helps, but there are simply not enough people for the workload. So we take what we can get. We'll even sacrifice build reproducibility for years to get that productivity (see NuGet).
I do not see any evidence that there was legitimate prior art analysis prior to this project's promotion. Many other rationale in the documentation are troubling.
The misrepresentation of Conan (and the wider context) in the FAQ is very troubling. We have worked hard to make open source a kinder and more sincere place.
There's a nice tradition of mentioning close prior art at the top of their README, and providing a differentiation (or link to one) above the fold.
This differentiation should stick to objective and carefully researched facts, along with each project's official declaration of scope and goals.
It is very considerate to provide the reader with all of the facts, and let them consider what solution has the best tradeoffs for their situation.
This sets the stage for a spirit of friendly collaboration and sincere work towards our common goal of making software developers happier (or something adjacent to it, I hope).

Update: My Github account has been reinstated, and my repositories are back online. Given the apparent risk of interacting with Microsoft repositories (particularly when one's repo uptime matters for bundle install and CI), I'll be keeping my side of the conversation elsewhere.

Update: My Github account has been reinstated, and my repositories are back online. Given the apparent risk of interacting with Microsoft repositories (particularly when one's repo uptime matters for bundle install and CI), I'll be keeping my side of the conversation elsewhere.

First of all let me say that it is a shame that your account got closed over this. I'd really like to know who or what triggered that process.
Now assuming that your arguments won't convince the maintainers to just drop the project or completely change the way vcpkg works. Is there a list of actionable items you'd like to be resolved (like remove incorrect statement X, add functionality Y)? You named a few candidates, but they imho get lost in the larger discussion.

I'd really like to know who or what triggered that process.

See https://github.com/Microsoft/vcpkg/issues/478#issuecomment-269916351

Now assuming that your arguments won't convince the maintainers to just drop the project or completely change the way vcpkg works.

I didn't advocate dropping vcpkg. I did advocate for honesty in its labeling, and I would suggest some form of on-boarding for Microsoft employees new to open-source.
My understanding of the term 'preview' is that both implementation and  interface are subject to heavy change. The initial commit for this project is dated Sept 18, 2016. I would not expect that a project with 0 releases is already prioritizing backwards compatibility over architecture.
FWIW, vcpkg could present the same UI, but be a small wrapper around Conan, so that users are not locked in to a single platform and toolset. vcpkg appears to have around ~5500 lines of C++ at this point. We wouldn't be turning the titanic.

Is there a list of actionable items you'd like to be resolved (like remove incorrect statement X, add functionality Y)? You named a few candidates, but they imho get lost in the larger discussion.

Sure. Mostly pasted from above.
The most effective approach to ensuring a solution succeeds based on advertising or brand, rather than merit, is to either
(a) pretend you've never heard of them, and be silent in places where users trust you to credit prior art, or
(b) use a disinformation strategy to ensure the competition's role and merit is misunderstood.
The most effective way to avoid criticism about this to follow the "alternatives" pattern in README.md.
It's pretty simple:

Add an "Related Projects" or "Alternatives" section to README.
Which contains links to functioning projects with overlapping goals.
And differentiates your project from the alternatives you link to.  This differentiation should stick to objective and carefully researched facts, along with each project's official declaration of scope and goals. There's usually some form of communication to ensure this is accurate - Github makes notifications on PRs easy.

This simultaneously demonstrates confidence

that your project is objectively superior for its specified scope
that you've done good prior art research
that you are acting in the best interests of your corner of the open-source ecosystem
in your users, that they are capable of determining which solution has the best tradeoffs for their situation.

It is important that the project lead(s) author this section.  Many projects discover a better scope or focus when taking a second pass at this research.

Hi @nathanaeljones, happy holidays and thank you for taking the time to write out this critique; we do want to encourage discussion around any design points of Vcpkg to ensure we're building the best tool possible for C++ developers.
First and most importantly, I'm deeply sorry that GitHub's spam algorithm flagged your post! GitHub has been an excellent site for many projects and if their spam detection algorithm has a chilling effect on useful discussion, we should do something about that. I have no evidence that Microsoft's repositories receive special treatment (please share some regarding your comment!), but let us know if we can help you take this further to GitHub support.
Curation
Glad to hear you find homebrew as useful as we do! As you can tell, we do believe the curation models of Homebrew, Debian, Ubuntu, Gentoo, BSD, MacPorts, Pacman, and others have been profoundly shaped by the way native code is written and distributed. We believe their success is in part due to their strong curation models which enable a standard interoperability model between different developers to benefit users. All of these have grown various mechanisms to support the community adding additional packages outside the curated region and we intend to follow a similar path -- a standard, reliable, curated core with the ability for users to override anything they want, including replacing the core packages.
Today, for example, anyone can supply a CONTROL+portfile from their open source project that users can simply drop into their local vcpkg and we will treat it the exact same as any official package. In a more regulated scenario such as inside a company, they can easily fork the Vcpkg repository and change whichever ports they'd like (most commonly: freezing the versions). It can be even merged directly into a project's main source tree (though we'd recommend a submodule), giving them something extremely similar to the "check in third party sources" if that's what they determine is most appropriate in their scenario. We do not rely on the Microsoft/vcpkg repository anywhere in the tool, save in the various help documentation.
Improving this experience is still a very important area for us. We definitely see the use of something like homebrew taps and we want to implement something similar which doesn't cause dependency graph fragmentation.
Per-Library vs Application-Wide Versioning
I believe we've had a miscommunication about what we mean by library: in the bullet point we meant user-authored libraries. Especially if the user wants to avoid excessive lock-in (and therefore doesn't want to be forced to republish all their outputs as packages within the system), it becomes difficult to synchronize separate builds and to ensure they use the exact same dependency versions. At the end of the day, we all want one version of each dependency to go into the OS process. Sometimes games can be played depending on the specific packaging and deployment choices to enable multiple deployment of the same library, however our experience (with large scale software development) is that this is a very bad idea. Therefore, there needs to be a single definition of which version will be used in that final process. The obvious entity to choose this is the final application (or suite of applications if they share implementation libraries). We support this model by placing the ports\ directory under the moral control of the application developer, which is the single unambiguous source of truth for all external source code that goes into your product.
As a side note, we observed that in most of the above package managers, inter-package versioning is most commonly used for binary packages, not source packages [1]. Source packages are generally referred to simply by name, perhaps with a "dependency must be greater than this very old version". In this respect, we do model and respect a very strict versioning scheme between our internal binary packages.
Glad to hear you like the idea of platform versions. We generally think these are an excellent example of falling into the pit of success, so for Vcpkg they opt-out -- you automatically get the latest libraries that work together, but you can easily switch to any of the older sets (git checkout an older commit) or overwrite any particular port directory to change that specific package.
User-wide
I'm happy to note that we definitely support more than one set! However, as you've clearly pointed out, our documentation in this area is insufficient.
We believe that as an enthusiast or hobbyist developer, there's a serious productivity win to be gained from having a blessed set of libraries that you get "by default" for your projects, but as you scale up, the need to control your specific dependencies (transitively) requires the ability to tie the above platform version set to a particular commit of your application code.
To handle this, we support as many Vcpkg instances on the same machine as you'd like! With the CMake integration, you always specify which particular instance you're using by how the toolchain is specified. With MSBuild, you need to set a single property across your solution to point at the particular Vcpkg instance you want to use.
Shared dependencies between applications
You're absolutely right that the current trend is to avoid system libraries for binary deployment due to the DLL hell it creates. I'm happy to say that this is exactly what Vcpkg is designed to do -- to help you build fully contained applications that are extremely easy to deploy and do not risk DLL hell or system updates breaking your application.
Vcpkg is designed to look like a system package manager for your build environment (there is a single definition of where and what "boost" is), but at the end of the day you get a containerized application out with local copies of every runtime dependency you used. From there, distribution is as simple as zipping the .exe and .dlls in your output folder and copying them to any machine you like (no Vcpkg required on the customer machine!) [2].
Note that on Windows (for various reasons) the standard way to avoid DLL hell has been to install them inside your application folder, alongside the executable (unless the vendor has a distributable MSI). This is what happens with Vcpkg as well: we copy the exact set of dependency DLLs alongside the output executable, so updating Vcpkg will not break any of your installed programs.
Misrepresentation of Conan
We certainly have no intention of spreading misinformation about Conan.io! I was fortunate enough to have the opportunity to talk to Diego in person at CppCon, where we were able to discuss the differences between Vcpkg and Conan (goals, design choices, etc). We also have extended an open offer to correct any issues in our compare-contrast FAQ section, which has yet to be taken up. Because of this, I currently believe we are not misrepresenting Conan and the differences between the projects arise from focusing on different parts of the problem space (a large one, as you've mentioned!).
The fine people over at Conan have even gone so far as to write a bridge between Vcpkg and Conan [3], which is great to see! We have some reservations about the specific details [4], but the overall direction is a great one that we'd like to continue in the spirit of friendly collaboration.
Conclusion
Thanks again for taking the (immense) effort to write out your critique above. You've really helped to highlight areas of documentation that need improvement and some technical points we should keep an eye on as well.
Further, I'm sincerely sorry for the trouble that GitHub's filters caused you -- I can imagine how brutal it would be to lose access!
[1] https://github.com/Homebrew/homebrew-core/blob/master/Formula/cpprestsdk.rb#L16
[2] You may need to also install the VC++ 2015 Redistributable, same as always
[3] http://blog.conan.io/2016/10/17/Using-Vcpkg-ports-as-Conan-packages.html
[4] https://github.com/conan-io/conan-io.github.io/issues/17

The FAQ is not up-to-date: Conan.io is not "Public federation" anymore.


Support for apns-push-type

Via https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns?language=objc:

apns-push-type
(Required when delivering notifications to devices running iOS 13 and later, or watchOS 6 and later. Ignored on earlier system versions.) The type of the notification. The value of this header is alert or background. Specify alert when the delivery of your notification displays an alert, plays a sound, or badges your app's icon. Specify background for silent notifications that do not interact with the user.
The value of this header must accurately reflect the contents of your notification's payload. If there is a mismatch, or if the header is missing on required systems, APNs may delay the delivery of the notification or drop it altogether.
For information about configuring notification alerts, see Generating a Remote Notification. For more information about sending background notifications, see Pushing Background Updates to Your App.

Thanks,
Nick

Thanks for calling this to our attention. Is there a specific WWDC session where this was announced, or a summary of changes to the docs?

Not that I'm aware of.  I noticed this after testing against iOS 13 beta.

Ha—okay. Thanks. Sounds like it's time for the post-WWDC "figure out what changed" festivities!

I took a shot at this in #702. Feedback is welcome!

@jchambers Any expected timeline for v0.13.9 to be released.
Thank you.


[REVIEW] KendallDoesCoding

Project link
https://github.com/KendallDoesCoding

First of all nice profile. Some suggestions form my side:

consider making the banner a little bit smaller. (lots of unused space)
consider removing the profile view count due its mostly inaccurate.

First of all nice profile. Some suggestions form my side:

consider making the banner a little bit smaller. (lots of unused space)
consider removing the profile view count due its mostly inaccurate.

thanks, will work on this shortly

Created this as a duplicate, forgot I requested for the profile review already, this has a convo though, so will close the original issue #3483.

First of all nice profile. Some suggestions form my side:

consider making the banner a little bit smaller. (lots of unused space)
consider removing the profile view count due its mostly inaccurate.

thanks, will work on this shortly

Removed the profile views, will have to make the size small using Canva for the banner though, will do that later.


Show staged and unpushed changes

Is your feature request related to a problem? Please describe.
It would be nice if we could also see the changes that are staged but not yet committed, and the changes that have not yet been pushed to the remote branch that the current branch is tracking.
Describe the solution you'd like
We could add more signs in an additional sign column:

staged for changes in git diff --staged
unpushed for changes that have been committed but are not yet pushed to the tracked branch, similar to setting the base to @{upstream}.

Or alternatively allow the user to configure multiple bases with a custom git diff command.
Describe alternatives you've considered

staged: It doesn't look like this is possible by changing the base option.
unpushed: Setting base = "@{upstream}" can show unpushed changes but then you can't differentiate between unstaged code and committed code. Setting base = "HEAD..@{upstream}" can show unpushed commits but then you can't see unstaged code.

yes, git diff --staged is what I need as well

Gitsigns already seems to have support for showing staged changes, but I can't seem to get it to work... is it still experimental?

Try _signs_staged_enable = true.
It should show staged hunks in a dimmer color.

@lewis6991 For some reason, it doesn't work for me. A sign simply disappears after the stage. Is there anything else is required to make it work?

Why does the _signs_staged_enable start with an underscore?  To me that would signal that it is not intended to be used publicly in that way, and/or it is experimental?

Yes, that is correct. It is still experimental and hence is not documented.

@lewis6991 _signs_staged_enable works great for me. Thanks so much. This is one of my favorite plugins!

is there way to get show info about staged changes also in statusline?

Resolved with #1039


change color of the tabbaritem

How to change color of tabbaritem?

firstly, you should update to 0.8.2
Next, the item color depends on bar tintColor, there is some strange behavior - tintColor of standard UITabBar doesn't sets from storyboard. So, there is two way to solve your problem: set tintColor property from code (directly, or using UIAppearance) or set  CBFlashyTabBar class to TabBar in storyboard and set tintColor in interface builder


qiime2view does not work if Galaxy is behind a firewall

If Galaxy is behind a firewall, then the qiime2view visualization does not work. Currently the visualization sends a link to the viz website which does not work in such a setup.
Wondering if it is possible to rewrite the viz plugin such that it sends the data directly .. and if the qiime2view website would support getting data directly.

Alternatively I might ask our admins if certain URLs may be exempted from the firewall rules.

Some more alternatives:

Maybe its possible to create a charts plugin for qiime2view https://training.galaxyproject.org/training-material/topics/dev/tutorials/visualization-charts/tutorial.html
Install qiime2view locally. URL can be configured in tool-data/q2view_display.loc.sample

Just had another idea: In galaxy there is a static/ directory. Was trying to follow the build instructions from https://github.com/qiime2/q2view and copy the result (the build dir into Galaxy's static dir).
In my case I have a nginx directive:
	location /static {
		alias /data/galaxy_server/galaxy-dev/static;
		expires 24h;
	}

Problem is then that within q2view there seem to be many relative path (eg. ./js/bundle-639d8d1dd3e4440cf7af.js) which seem not to work. I started to replace ./ by /static/, which led to some progress.
Now I'm wondering if there is a better way to do this, i.e. serving q2view from a subdir of the webserver....
@ebolyen do you have an idea or know someone who could help?

As a workaround: https://github.com/galaxyproject/tools-iuc/pull/4834

Hey @bernt-matthias,
Sorry for having missed this issue!
I'm going to write a big comment with inline quotes.

Wondering if it is possible to rewrite the viz plugin such that it sends the data directly .. and if the qiime2view website would support getting data directly.

This isn't quite possible because q2view is actually a static website with a ton of javascript to invent a client-side web-server (via a Service Worker) that makes the browser think it's talking to a server (when it's actually just a QZV).

Alternatively I might ask our admins if certain URLs may be exempted from the firewall rules.

This is probably the best bet for most people. q2view doesn't upload any actual data to any actual server, although I can definitely respect that some sysadmins are indifferent to that claim (it is a website that in principle, could do anything with the data).

Maybe its possible to create a charts plugin for qiime2view https://training.galaxyproject.org/training-material/topics/dev/tutorials/visualization-charts/tutorial.html .. it should qualify: https://training.galaxyproject.org/training-material/topics/dev/tutorials/visualization-generic/slides.html#9

I think that's probably the best long-term solution, I just had absolutely no idea how to go about it. Thanks for the resources!

Install qiime2view locally. URL can be configured in tool-data/q2view_display.loc.sample

That should work too, although now you have to build q2view from a webpack config I haven't touched in some time. So it's unlikely to be pleasant.

Just had another idea: In galaxy there is a static/ directory. Was trying to follow the build instructions from https://github.com/qiime2/q2view and copy the result (the build dir into Galaxy's static dir). [...] Now I'm wondering if there is a better way to do this, i.e. serving q2view from a subdir of the webserver....

That should in principle work just fine. But I'll need to modify the aforementioned webpack config to tolerate relative root directories for the application. Not the end of the world, but definitely all of the pain that comes with updating and compiling a javascript project from the 2016-18 era of webdev w/ webpack.

As a workaround: https://github.com/galaxyproject/tools-iuc/pull/4834

This looks great to me! And is indeed exactly all q2view ever did. I assume Galaxy has some provision to avoid client-side attacks from running arbitrary HTML such as an alternative domain or port? (I promise we aren't nefarious, but we'd hate to be the cause of any issues.)
Also the jsonp -> js rewrite shouldn't cause any issues in practice, so that also seems totally fine. The reason some of our visualizations do that is so that you can use them with the default file://path/index.html schema in most browsers. However since each path is it's own domain in that protocol-scheme, it meant we needed to use the old school cross-domain tricks instead of anything reasonable.
That's actually something that causes enough issues in practice we'll probably at some point just expect that visualizations are running in an HTTP hosted directory.

Thanks for the detailed comments. In the long run a generic/viz plugin in Galaxy could be nice... but I guess it will need time to develop it which is scarce.

This looks great to me! And is indeed exactly all q2view ever did.

Cool. Wondering if a tighter integration in the qiime tools would be an idea? With the additional tool an extra tool run would be needed to extract the qzv to html. Maybe all tools generating qzv could just have an extra/alternative output (ie the html file). Might be more userfriendly...
Btw. are qzv files dead ends or are there tools that can process qzv further?

I assume Galaxy has some provision to avoid client-side attacks from running arbitrary HTML such as an alternative domain or port? (I promise we aren't nefarious, but we'd hate to be the cause of any issues.)

I don't know. By default the html page will not be rendered at all, but admins will need to put the tool on an allowlist. If this is done I'm not sure if there are any security measures. I will ask in the Galaxy gitter channels.


lima: add wrapper and lima-unwrapped

Description of changes
colima 0.4.1 on master is currently broken because the vm has no internet access: https://github.com/abiosoft/colima/issues/344
colima needs direct access to the unwrapped lima binary to fix it. This pr adds the lima-unwrapped derivation for it.

Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg build lima

This may not be needed anymore https://github.com/NixOS/nixpkgs/pull/179522#issuecomment-1170458522, except there are other benefits of this in the long run.
Really appreciative of your efforts @aaschmid and @tricktron.

Colima works now with the wrapper and the unwrapped is thus not needed anymore. Closed.


Module should have an unique abbreviation/short name.

Alter database module's table to have UNIQUE constraint in abbreviation/short name column.

"shortname" and "displayName" fields are now UNIQUE for table module in database.


how to use strophe to dynamically create rooms for users and friends

hi,
i have an application which has users which have friends etc. the app will have chat service for the users.the problem is i can get a list of the users friends and i want to be able to create a chat room on the fly for this group of people and transmit it to all other friends of the user to be able to join
is this possible with strophe.js
thanx

http://xmpp.org/extensions/xep-0045.html#enter-muc
http://xmpp.org/extensions/xep-0045.html#invite

thanx for your fast reply, im already aware of the muc plugin, the main problem is how to coordinate the users to join the same room since each is logged at different times and pages
the scenario is the following:
a user logs in> i am provided with the login information and the list of other users who are friends> i log the user to the chat server (openfire)> another user logs in who is a friend of the previous user> how create a room on the fly and propagate this information to the second user (and also all other friends) so that when they login they see the room and presence
initially there is no room
how to get presence with no room and then create the room?
thanx again

On most conference services the room will be auto-created when the first participant joins.

i'm not sure i understand, can you be more specific (i dont want detailed code, just the general strategy).
The problem is how to keep track and synchronize users with the chat service. The problem is how each group of users (ie friends) can dynamically synchronize with the same room automatically (we can assume the room will be created when the first user of the group logs in, then others will follow) ie a user logs in and he can immediately send /receive messages from his friends only. i must say that part of the chat app is already functioning (all users auto-join a common/global room) and each user can change its status/prsence as they wish (online/offline/away) using strophe.js and muc plugin.
thanx


when using scrollToPosition

When using scrollToPosition method, the head view appear in wrong position.

yes i have this issue to

The RecyclerViewHeader uses ScrollListener to move the header. The problem is, there is a known issue of the RecyclerView in which the ScrollListener is not getting called when using scrollToPosition. So I kinda have no way to overcome this issue as it's buried deep inside the RecyclerView logic.


security: update mocha

Goal of PR

🔒  updates to mocha.
Also added a package.lock file Yay 👍

QA
Confirmed Tests still pass.

Thanks @ryanSN !


Update CI/CD actions, use UV_ENV, use OICD

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
48

Relevant Lines:
48

💛  - Coveralls

You can also remove the PYPI_API_TOKEN from the secrets in the settings of the repo then.


Question: Custom Search Parameters

Currently doing an evaluation of Medplum and it's FHIR server capabilities (btw impressive stuff team!).
One area I couldn't find explicitly in the documentation was support for Custom Search Parameters. I tried adding a Search Parameter resource for the Task resource and a code that I made up and of course the expression for how to perform the search. I then went and using the Super Admin portal, initiated a reindex but the server still doesn't recognize the search param.

@TheCaffinatedDeveloper Unfortunately Medplum does not currently support custom search parameters, but this is something that we plan to eventually support.  There's a related discussion regarding support for custom resource types, as well.  In both cases, the blocking issue is the coupling between database schema and FHIR resources


Microsoft.AspNetCore.Proxy: ProxyService.cs HttpClient Timeout

I realize Proxy is an unsupported experiment at this time, but wanted to make a suggestion from our experience testing with it.
Issue
ProxyService.cs creates a HttpClient object with default timeout. This means any proxied request will timeout if it persists longer than 100 secs. There is currently no way to override the timeout of the HttpClient used by ProxyService.cs.
public ProxyService(IOptions<SharedProxyOptions> options)
{
	if (options == null)
	{
		throw new ArgumentNullException(nameof(options));
	}

	Options = options.Value;
	Client = new HttpClient(Options.MessageHandler ?? new HttpClientHandler { AllowAutoRedirect = false, UseCookies = false });
}

Suggested Improvement
Provide mechanism to override the default timeout of the HttpClient object which is created and managed by ProxyService.cs.

@Eilon Should this issue be moved to https://github.com/aspnet/AspLabs?


Resolve @vue/apollo-composable path

fixes https://github.com/nuxt-modules/apollo/issues/444, https://github.com/nuxt-modules/apollo/issues/519, https://github.com/nuxt-modules/apollo/issues/535
Based on @zen PR

@Diizzayy Any changes should be done in this PR. All checks seems to be passed

Just bumping this, the @vue/apollo-composable import issues are quite frustrating every time I upgrade Nuxt versions.
@Diizzayy Was there a reason this wasn't already merged in?

This PR seems can be closed, as related issues were fixed in another PR


Issue forms

Closes #637.
Change summary:

Prevent unnecessary server-calls if form is invalid.
Provide meaningful message(s) to user in case the form-submission returns an error.
Covers login-form, register-form, forget-password-form, change-password form.
Use of ng-submit on <form> instead of ng-click on submit buttons. This enables user to submit forms with Return Key(Enter key) too.

Changes are available on https://daemo-develop.herokuapp.com/
General use-cases:

Try submitting a form without entering any input.
Fill the form partially and leave other fields blank.
Complete the form with some ambiguity (different values for password and its confirmation).
Use an existing email while registering(or non existent email in 'forgot-password') to see relevant server side messages.

Screenshots:

Great to see you digging in!
On Sat, Jan 23, 2016 at 7:51 AM, Nalin_C<EMAIL_ADDRESS>wrote:

Closes #637
https://github.com/crowdresearch/crowdsource-platform/issues/637.
Change summary:

Prevents unnecessary server-calls if form is invalid.
Provide meaningful message(s) to user in case the form-submission
returns an error.
Covers login-form, register-form, forget-password-form,
change-password form.

Screenshots:
[image: rsz_change-password]
https://cloud.githubusercontent.com/assets/4050813/12531035/2a815066-c217-11e5-969f-da398f477810.png
[image: rsz_forgot-password]
https://cloud.githubusercontent.com/assets/4050813/12531036/2a8c3666-c217-11e5-9ee7-dc6acece6926.png
[image: rsz_register]
https://cloud.githubusercontent.com/assets/4050813/12531037/2a90ac78-c217-11e5-81ff-d275d4b03708.png
[image: rsz_login]
https://cloud.githubusercontent.com/assets/4050813/12531038/2a94b82c-c217-11e5-81cb-b3056869f00f.png
You can view, comment on, or merge this pull request online at:
https://github.com/crowdresearch/crowdsource-platform/pull/643
Commit Summary

#637: Add frontend validations in login form.
#637: Add frontend validations in forgot-password form.
#637: Add frontend validations in registration form.
#637: Add frontend validations in change-password form.
Merge branch 'develop2' into issue-forms
#637: Use the server-response to set error in frontend instead of
using a static string for 'change-password form'.

File Changes

M static/js/authentication/controllers/auth-settings.controller.js
https://github.com/crowdresearch/crowdsource-platform/pull/643/files#diff-0
(53)
M static/js/authentication/controllers/login.controller.js
https://github.com/crowdresearch/crowdsource-platform/pull/643/files#diff-1
(55)
M static/js/authentication/controllers/register.controller.js
https://github.com/crowdresearch/crowdsource-platform/pull/643/files#diff-2
(57)
M static/templates/authentication/change-password.html
https://github.com/crowdresearch/crowdsource-platform/pull/643/files#diff-3
(23)
M static/templates/authentication/forgot-password.html
https://github.com/crowdresearch/crowdsource-platform/pull/643/files#diff-4
(10)
M static/templates/authentication/login.html
https://github.com/crowdresearch/crowdsource-platform/pull/643/files#diff-5
(16)
M static/templates/authentication/register.html
https://github.com/crowdresearch/crowdsource-platform/pull/643/files#diff-6
(38)

Patch Links:

https://github.com/crowdresearch/crowdsource-platform/pull/643.patch
https://github.com/crowdresearch/crowdsource-platform/pull/643.diff

—
Reply to this email directly or view it on GitHub
https://github.com/crowdresearch/crowdsource-platform/pull/643.

@mbernst: Thanks professor. I'm looking forward to be a core contributor. You might see more PRs from me in future :)

lgtm

Registration:
a) When initial validation fails from backend, subsequent validations do not turn form into pristine condition. Therefore registration cannot proceed.

To replicate:
a) Fill all fields and email with already existing email address in backend
b) Click Signup and it should show email is not unique
c) Change email to a new unique one
d) Now Signup won't work at all even if all fields are correct

looking good


Assignment 08 -- Midterm

Read the slide reviewing materials before midterm.
Midterm duration includes preparation before exam (4 h) and during the exam (2 h).
Perform the midterm in Edunex.
Fill out the answer there and publish the results as a gist.
Report link to the gist also here with your ID and name.

Restu Khoirunnisa (10221039)
Link Gist : https://gist.github.com/restunisa2/8e7b857cccc195c1d875d21a0d670a0a
Link docs : https://docs.google.com/document/d/1KDItN_fAQljz4gU47CiNGokx-b7m9JKs_avVbstVEA0/edit?tab=t.0

Zidan Ramadhan Rusdiana - 10223086
Gist: Link

Akhtarriza Harafah - 10222011
Midterm gist

Ahmad Royyan Fatah - 10222065
Github gist

Jonathan Lijaya - 10222109
Link Gist Ujian Tengah Semester PGDA
https://gist.github.com/JonathanLijaya/b636f8c4ae524c77d3b291d4fd900a28

Jonathan Lijaya - 10222109
[https://gist.github.com/JonathanLijaya/b636f8c4ae524c77d3b291d4fd900a28]

Afifah Ulya Nadira - 10222090
Link Gist : UTS

Nasya Nabila - 10222112
Link Gist UTS :UTS

Afrah's Assignment 08 -- Midterm
10222049_Afrah Yani
Midterm Test Answer

Ikbar Fauzul Mubin Ruhimat - (10223083)
Midterm gist

Abraham heven philia saragih - 10223038
Midterm Test
Github Gist

Muhammad Syamsuddiin - 10223075
Midterm gist : https://gist.github.com/msyamsuddiin/2a84fc0011a5a6cf2bb6ddf00b9a299b

### Muhammad Azfa Mukhlis (10223036)
https://gist.github.com/AzfaMkh/4ca7567ae2961496eab033c8665efc6f

Sekar Ayu Widhastri - 10222020
https://gist.github.com/sekarwidhastri/a1e816022484a0e5f4e4ec2bf3a9a003

Ilham Ghufroni (10221012)
Midterm gist : https://gist.github.com/Frosty8171/87a68efdf674028cbfc8462a8cf2e734

Jonathan Lijaya - 10222109
Link Gist Ujian Tengah Semester PGDA :
Gist UTS PGDA

Eliza Putri Hapsani - 10222103
Midterm gist: Link gist

Muhammad Fathin Abdul Aziz (10222044)
Link Midterm Gist

Dietrich Pepalem Tarigan- 10223037
Github gist

M. Daryl Putra A. K. (10222116)
https://gist.github.com/darylkusdinar/7ecffa5bcd67a48ea1b2716c25a0e2ce

Gerizim El Masih - 10222089
Tautan UTS Gist:
Mohon maaf pak, karena saya terlalu bersemangat, jadi nomor 1-6 saya lupa dibuat ke Gist
Nomor 7: https://gist.github.com/gerizimel/7d8d9f6241f4abe5a419a20b3c738c2d
Nomor 8: https://gist.github.com/gerizimel/d64d19027560e692d32cee184a25bfec

Muhammad Kamal's Assignment 08 - Midterm
Midterm Answer, Code, and Output
gist link

Hairil Aulia 10223087
https://gist.github.com/Hairil-A/c8d0d47672a00caf242cb0a6cfdaec51

Olvandri Nouva Pratama 10223033
Midterm Gist

Mulyadi Prasojo 10222053
https://gist.github.com/Mul712/461ba061089f6a7bf0e395408cdafa36

Melinda Alberta / 10222066
Link: https://gist.github.com/melindaaaaaaaaaaaaaaaaaaaaa/caccc38f0f5ccff4b168d48614b820a3

Ahmas Haffiz Fildzah / 10222001
Midterm Gist

Reyhan Nugraha Akbar - 10223074
midterm.ipynb

Naufal Aulia Pramadhana / 10223045
[https://gist.github.com/naufal170706/8c6282540a346c85bbc1d3d7a1b67f13](Midterm Gist)

DARELL TIMOTHY TARIGAN (10222014) - ASSIGNMENT 8 : MIDTERM

In completing this midterm, I have provided answers to the given questions, organized them in a Gist, and also completed the exam on Edunex.

Gist Response : https://gist.github.com/DarellTim/7d108a38d9a557e5c1ab99d49055e010

Darell Timothy T (10222014)

Yafi Zainul Muttaqin / 10223017
Midterm Gist : https://gist.github.com/yafiizm/ca3656f7d428dba1f8fc0b73fada6f53

Aufa Dirham Hafizh (10222083)
Link: https://gist.github.com/aufahafizh/cc71c1666b06409facab63182e887425

RAYA NOUVALLI PASHA (10223008)
Link : https://gist.github.com/Pasha10223008/c2754e108cf21eb4da26f1e893bfaa80

Gwen Sevilen / 10223067
Link: https://gist.github.com/agwens/27a9f4d94dde05e7e265631a211dd378

Ashma Nisa Sholihah A (10222091)
https://gist.github.com/ashmanisaa/a993929199c7baef17d0ca9f6326f6b6

Vincent Constantine Darmawan (10223072)
https://gist.github.com/VincentConstantine/c9e9ea0fd910514ad48a9ca231e30166

Aldi Wahyu Permana - 10223039
Gist : https://gist.github.com/aldiwahyuu/cd869a97da6a3ab874c1c0e0962824cf

Kayla Sabira Yusuf (10223094)
Midterm Gist : https://gist.github.com/kaylaashbr/281ce299cb2504a408448e8191bcb098

Sean Maximilliano Raffaele M (10222085)
Link to Midterm Gist

Nashwan Chakap Nanggala - 102222036
https://gist.github.com/codechakap/1197b4aed99fa55f01deda9d47490745

MIDTERM
Ahmad Alfian Tri Saputro (10222050)
Gist: https://gist.github.com/yann-yann/2a84d42444699f8de07c514888d7648b

Kristofer Adrian 13123062
https://gist.github.com/KristoferAdrian/54c620abd0435f35c8bab07e6f26a15e

Rubent Titus Nainggolan 10223054
Link Gist Midterm :
https://gist.github.com/IMakeUpSadStoryToHelpMeSleep/ab4672dfd2c0e795147ecfd48730813a

##Luthfi Muhammad din prakoso-10219005
@ @gist link

Jonathan Sugijanto 10222007
https://gist.github.com/JonathanSugijanto/e4cf95db907516e14a931e1e03c5bdc2

Duke Ariqoh (10222016)
https://gist.github.com/dukeariqoh/76d7ec7438d88c3a4fcd83eae92b433e

Izzah Huwaidah 10222040
Gist : https://gist.github.com/IzzahHuwaidah/7b83538cb3800cf311d84036ee05bdbe

Azwa Aliyah Zaki | 10222080
Gist link

Santun Wiwaha 10223209
Gist link

Huzain Hadi Purnomo - 10222045
Gist Link: (https://gist.github.com/HuzainHadi/030fe2124d662f5fe263687f8e8a201f)

Andree Sugiarto Theny Soendayana - 10221004
Gist Link: https://gist.github.com/andreets/4cd1ab996b3c4115052cb0007377efd1

Adiyasa Pratama Putra - 10223101
Gist link: https://gist.github.com/adiyasapratama/5b274d5dde2d24bfb7283fbe02c223b1

Adinda Mutiara Salsabiela - 10223012
Gist link:
https://gist.github.com/Dindabiel/5310672d516d593eed1702c7849671f5

Angel Betesda Silaban
Gist link : https://gist.github.com/Angelsan-17/f7acddeb82b966a0fe59c32692d919de

Nurul Izzati (10223042)
Link: https://gist.github.com/SiManiezzz/1734e61f44117bebf812108742ec68be


Fix out of index issue in topk.

In topk, it makes dense and fixed node tensor according to x.shape and initialize all values to -2.
So, a graph which is smaller than biggest graph in batch has dummy nodes.
And then, x is copied to dense tensor and ordered by score.
If some scores in a graph which is smaller than biggest graph are smaller than -2,
they are moved to out of node size of original graph and dummy nodes are filled to those position.
So, returned perm has dummy node that have out of index.
Actually, this error was occurred in my custom dataset using SAGPool and I fixed the problem by this code.

I think this change will resolve #775 and #982.

Looks good. Thank you!


rename whitespace in value param, add allow hash in value param, expose and add tests

replaces both https://github.com/tonerdo/dotnet-env/pull/6 and https://github.com/tonerdo/dotnet-env/pull/5

README updated


Gallery Loading

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

Whenever we open the gallery it takes some time to show up the results. While in the background it fetches for the files. But the user doesn't actually know that it is even loading.

Describe the solution you'd like

It will be great if we can implement some loading logo/ dialog box.

Describe alternatives you've considered

We can also reduce the requests to up to a single page only showing only around 50 results.

Additional context

Here is the result whenever we open up the gallery it takes around 11 seconds.

rbudde improved the database calls, which should speed things up.
Additionally, the spinning logo was added with e1871d914c82d979bcd49b8379d8dde866dfe9cd.

works. The bottom text of the table, e.g. "Showing 1 to 11 of 11 rows" is bad. Instead of "rows" the text should use "items". Rows is ok in a traditional row format only.

Not solved, spinning logo is still visible when gallery already is loaded.

Spinning logo does not show up after the gallery is already loaded.


Dev 1.5.0 580 evasion tests integration_A

Description
This PR addresses issue #580 which is about integrating remaining evasion tests within the new pytest framework
Fixes #580 evasion
Type of change
Please check all relevant options.

[X] Improvement (non-breaking)
[ ] Bug fix (non-breaking)
[ ] New feature (non-breaking)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code
[X] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes

This PR is being replace by PR #723


Release/2.0.1 release

Merge 2.0.1 release branch to master.

Coverage increased (+3.005%) to 70.161% when pulling c9d94ae395b1355617545a1b68b71b630381cc6e on release/2.0.1-release into effd32805fd2ea40c5451f7696e1ecf1284d0706 on master.


Catch Fish not progressing

What is your Quests version / build number (do not say "latest")?
b188
Describe the problem and how to replicate it. Any console errors to post using Pastebin.com?
The problem with that is. Whenever you have a stage to Catch Fish the server does count each fish counted to a point where Task is technically completed but it doesn't process to next stage or finish a quest.
The following picture shows up how the quest progress looks like:

After reaching 2/2 and message is grayed out as "finished". There is nothing else happening in there.
Replication is simple. Use b188 join the server then /quests editor -> Create Quest -> Name it -> Stages -> add new stage -> Mobs -> Catch fish -> Specify amount -> Save quest -> Reload -> start quest -> catch desired number of fished and here you go nothing happens nothing progresses.
Tested:
whenever Catch fish is just single stage of a quest
Whenever Catch fish is somewhere in middle of a quest Stages.
whenever Catch fish is last Stage of a quest.
None works.
If applicable, can you provide an example quest from quests.yml using Pastebin.com?

Wondering if this might be caused by 200a10efaac31a053d8a7f837347ae4cd2358691

Wondering if this might be caused by 200a10efaac31a053d8a7f837347ae4cd2358691

Im having the same issue on b185

Im having the same issue on b185

@DeadlykillOfficial @DrakePork Use https://ci.codemc.io/job/PikaMug/job/Quests/189/

@DeadlykillOfficial @DrakePork Use https://ci.codemc.io/job/PikaMug/job/Quests/189/


PermissionsEx-1.23.3 Maven

Whats it the repo

Use Vault not PEX api

even for like PermissionsEx user = ....


Add nightly_gpu badge to build status page, update unit_tests, add nightly_cpu

Description
Add AzureML badge for nightly_gpu in build status table in README.md (last line).
Update cpu_unit_tests to rename branch to something generic, update compute.
Add nightly_cpu yml for nightly tests.
Related Issues
This is new work.
Checklist:

[x] I have followed the contribution guidelines and code style for this project.
[x] I have added tests covering my contributions.
[x] I have updated the documentation accordingly.

I think it will be better to just replace all the linux badges with badges generated through the Azureml devops pipeline once their ready. Also I don't think we need to differentiate them as AzureML at that point, though we should find a good way to highlight that capability.
Can you back-out the readme changes for now?

When Miguel and I discussed the release of the pipelines, he had suggested starting to add the badges.
What if you and he talk and let me know what is preferred?


Base map max zoom level not applied

I have tried adding a custom base map (OpenCycleMap) that supposedly allows zoom levels up to 22, but when I try to actually zoom on the map, the maximum I can go to seems to be 18.
I can, of course, activate the option to zoom beyond the maximum zoom of the base map, but then the tiles get blurry. I don't think this issue is with the tiles, though, because if I disable the option to zoom beyond the base map's maximum zoom level, the app still does not allow me to go beyond 18, even though I explicitly entered "22" in the max zoom field when adding the custom base map. So it seems that somehow the app itself is refusing to allow zooming beyond 18 even when the base map is set to allow higher zoom levels.

That was silly, the underlying functionality was there but indeed not applying to the map.
Fix released in v1.7.1.

 Thanks for another lightning fast fix! :star_struck:


Update colours of gene characterisation graph

After chatting with @ValWood, we're going to change the graph colours to something like below.  We'd also like to remove the top the right edges.

I've changed the colour configuration.

We'd also like to remove the top the right edges.

That's done too now.


Can't install NodeJS 14 on MacOS Sonoma 14.1.2, malformed URL

Describe the bug
When trying to install NodeJS 14 (latest) an error is reported trying to download a seemingly malformed URL.
To Reproduce

Run mise use node@14

Expected behavior
Installs correctly. (I've seen this work with latest rtx)
Observed behavior
Error:   × HTTP status client error (404 Not Found) for url (https://nodejs.org/dist/v14.21.3/node-v14.21.3-
  │ darwin-arm64.tar.gz)

mise doctor output

`$ mise doctor`
mise version:
  2024.1.12 macos-arm64 (3750934 2024-01-07)

build:
  Target: aarch64-apple-darwin
  Features: DEFAULT, NATIVE_TLS, OPENSSL
  Built: Sun, 7 Jan 2024 12:44:20 +0000
  Rust Version: rustc 1.75.0 (82e1608df 2023-12-21)
  Profile: release

shell:
  /opt/homebrew/bin/zsh
  zsh 5.9 (arm-apple-darwin21.3.0)

mise data directory:
  /Users/pelle/.local/share/mise

mise environment variables:
  MISE_SHELL=zsh

mise settings file:
  ~/.config/mise/settings.toml

settings:
  {
    "all_compile": false,
    "always_keep_download": false,
    "always_keep_install": false,
    "asdf_compat": false,
    "color": true,
    "disable_default_shorthands": false,
    "disable_tools": [],
    "experimental": false,
    "jobs": 4,
    "legacy_version_file": true,
    "legacy_version_file_disable_tools": [],
    "node_compile": false,
    "not_found_auto_install": true,
    "paranoid": false,
    "plugin_autoupdate_last_check_duration": "7d",
    "python_compile": false,
    "python_venv_auto_create": false,
    "raw": false,
    "shorthands_file": null,
    "task_output": null,
    "trusted_config_paths": [],
    "quiet": false,
    "verbose": false,
    "yes": false,
    "ci": false,
    "cd": null,
    "debug": false,
    "env_file": null,
    "trace": false,
    "log_level": "info"
  }

config files:
  /Users/pelle/.config/mise/config.toml
  /Users/pelle/dev/occasion/.ruby-version
  /Users/pelle/dev/occasion/Gemfile
  /Users/pelle/dev/occasion/.tool-versions

plugins:
  bun        (core)
  deno       (core)
  go         (core)
  java       (core)
  node       (core)
  postgres   https://github.com/smashedtoatoms/asdf-postgres.git#4592b64
  python     (core)
  redis      https://github.com/smashedtoatoms/asdf-redis.git#beedc89
  ruby       (core)

toolset:
<EMAIL_ADDRESS>node@16, <EMAIL_ADDRESS><EMAIL_ADDRESS>python@2

No problems found

Additional context

I'm on Sonoma on M1 Pro MBP
Seems to be affecting @14 only. node@16 installs fine.
Used to work fine on latest rtx. I recall doing this back in December. Maybe it's expecting a binary to exist? It used to build it from source on M1 if I'm not mistaken.

this is a bug but you should be able to work around it temporarily by setting MISE_NODE_COMPILE=1


Enable C++17 as default for compilation

Should resolve #113.

Totally untested, thus not committing to main directly …

We already have CMAKE_CXX_STANDARD 17 set in experimental (but not required) for our own code, this would apply it across all dependencies, which seems like a reasonable thing to do for consistency (especially if it changes linker settings).  Regarding #113, I'd like to be sure this is a working fix on MacOS (looks like it so far but..) and doesn't break elsewhere - can you test build?

Will give it a shot tomorrow and report back, unless @mayankag87 can already confirm this to resolve the issue.

Test build with GCC 10.2.1 (default on Debian stable) looks fine, no additional warnings and resulting binary appears to work :smile:

Installed clang 11.0.1 (default on Debian stable) and re-built using:
% CXX=/usr/bin/clang++ CC=/usr/bin/clang cmake -B build
% cmake --build build

and it all completes with a few extra warnings, and appears to work, LGTM!


Autoflake

Adds support for multiple graphql-config types (now non project type configuraiton is supported) + json + toml
FIX: Incorrect type annotation for scalar returns
Autoflaked Imports

Changes:
GraphQLConfig is now GraphQLProject


MAISTRA-2530 Fix wasmExtensions.cacher image field name in default SMCP template

The gen-check error should disappear once #782 is merged.


UK English Keyboard Support

Is it possible to add support for UK English keyboard?
I do understand that the keyboard's primary focus is Indic languages but it would be good to add UK English for people who prefer the UK words over US ones.
Thanks

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

https://gitlab.com/smc/indic-keyboard/issues/40


Google play store is very dumb

Once again Googles bot has decided that our app (Free and Open Source) is insecure. Ironic for non-free spyware like the Play Store to say, but here we are.
Basically play store updates will be much behind the GitHub and f-droid releases for a while probably.
They just keep crying about how we legitimately need to use the foreground special use permissions.

We've been approved for one release 1.0.97 but all updates take so long by the time i've pushed a change it resets the "review" process


Get a reference to the importing file's path in Custom Components

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I want to build a sass rendering component, that you provide it a .scss path, and it wraps the style internals.
Component:
import { HeadComponent } from 'mjml-core';
import fs from 'fs';
import path from 'path';
import sass from 'sass';

export default class MjScss extends HeadComponent {
  static componentName = 'mj-scss';
  static endingTag = true;
  static dependencies = {
    'mj-head': ['mj-scss'],
  };
  static allowedAttributes = {
    src: 'string',
    inline: 'string',
  };

  handler() {
    const { add } = this.context;
    // We have no idea where this Component is called from,
    // therefore we assume there is a scss folder 2 directories away
    // Which assumes this component is in a folder, contained by a components folder.
    const callerPath = `${__dirname}/../../scss`;
    const filePath: string = path.resolve(callerPath, this.getAttribute('src'));
    if (!fs.existsSync(filePath)) {
      throw new Error(`Can't find scss file at ${filePath}`);
    }

    const scss = sass.renderSync({
      file: filePath,
    }).css.toString();

    add(
      this.getAttribute('inline') === 'inline' ? 'inlineStyle' : 'style',
      scss
    );
  }
}

Usage:
<mj-scss src="theme.scss"></mj-scss>

Describe the solution you'd like
A clear and concise description of what you want to happen.
Component:
import { HeadComponent } from 'mjml-core';
import fs from 'fs';
import path from 'path';
import sass from 'sass';

export default class MjScss extends HeadComponent {
  static componentName = 'mj-scss';
  static endingTag = true;
  static dependencies = {
    'mj-head': ['mj-scss'],
  };
  static allowedAttributes = {
    src: 'string',
    inline: 'string',
  };

  handler() {
    const { add, callerPath } = this.context;
    const filePath: string = path.resolve(callerPath, this.getAttribute('src'));
    if (!fs.existsSync(filePath)) {
      throw new Error(`Can't find scss file at ${filePath}`);
    }

    const scss = sass.renderSync({
      file: filePath,
    }).css.toString();

    add(
      this.getAttribute('inline') === 'inline' ? 'inlineStyle' : 'style',
      scss
    );
  }
}

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
^ implemented a known folder approach above.
Additional context
Add any other context or screenshots about the feature request here.

Just opened a PR for this : https://github.com/mjmlio/mjml/pull/2407
@WilliamABradley with this you'll be able to get the path of the mjml file in which the component is called, that's what you needed right ? If it's in a partial included with mj-include, it will give the path of the partial.
In the component it will be provided in this.props.absoluteFilePath

@kmcb777 This works a treat! Just updated my component to use it.
It is unfortunate that @types/mjml npm package is out of date though 😢

For future reference of anyone interested, the implementation is now:
import { HeadComponent } from 'mjml-core';
import fs from 'fs';
import path from 'path';
import sass from 'sass';
import { AttributesFromProps, registerMJMLComponent } from '..';

export type MjScssProps = {
  src: string;
  inline?: string;
};

export default class MjScss extends HeadComponent {
  static componentName = 'mj-scss';
  static endingTag = true;
  static dependencies = {
    'mj-head': ['mj-scss'],
  };
  static allowedAttributes: AttributesFromProps<MjScssProps> = {
    src: 'string',
    inline: 'string',
  };

  handler() {
    const { add } = this.context;
    // @types/mjml is not up to date.
    const absoluteFilePath: string = (this.props as any).absoluteFilePath;

    // Get directory of file, if the path is a file.
    const callerPath = fs.lstatSync(absoluteFilePath).isDirectory() ? absoluteFilePath : path.dirname(absoluteFilePath);
    const filePath: string = path.resolve(callerPath, this.getAttribute('src'));
    if (!fs.existsSync(filePath)) {
      throw new Error(`Can't find scss file at ${filePath} (From ${absoluteFilePath})`);
    }

    const scss = sass
      .renderSync({
        file: filePath,
        includePaths: [callerPath],
      })
      .css.toString();

    add(this.getAttribute('inline') === 'inline' ? 'inlineStyle' : 'style', scss);
  }
}


Add support for 3D buildings in MapboxGL

In light of added support for fill-extrude-height and fill-extrude-base, I'd like to add the height attributes to OSM2Vectortiles backend so at a later date, a tm2source and style (probably Liberty)  can pick it up.
I'll take this on. Steps I can see:

[x] adjust imposm mapping to add it in
[x] adjust import-sql to add it as a function and calculate if no heights given
[x] confirm that a demo tm2source can pick it up (will only render buildings into the mbtiles)
[x] test display in a viewer

More todos:

[x] Add additional fields
[ ] Do I handle defaults in import-sql? What about catching clearly bad values and nulling them?
[ ] Handle both building and building part with the same geometry, leads to rendering artifacts
[ ] Advanced rendering for rooftops??

Cool. In the v3 we use the following approach of Paul Norman (OSM Clear to calculate render_height:
-- 3.66 is obtained by correlating the heights and level data in OSM
-- raising to a power < 1 reduces the height range displayed which looks better
least(greatest(3, COALESCE(height,levels*3.66,5)),400)^.7 AS render_height

Hi,
I'm considering to join your efforts and go for Vector Tile support in OSM Buildings.
Is there a chance to include a lot more attributes, i.e. building levels, roof shapes etc.?
Packing as JSON string would be fine.
With that, I could also imagine an extended version of MapboxGL in terms of 3D buildings.

@kekscom
Yep, I could definitely include more attributes, though they won't be rendered as complex rooftops!
With regards to 3D and MapboxGL, I'm not sure it's 100% at the point where it replaces something like Cesium in capability. I have a working offline demo that uses OSM2World and 3DCityDB to fill a database with buildings and dump them to tiles to view in Cesium. It's a powerful solution for handling lots of buildings with the full capabilities of drawing complex rooftops as opposed to basic extrusions. Only hurdle is hardware needs to view lots of buildings in a downtown area when in KML formats.

Okay, I did the first demos last night. I got it to draw in 3D, but I don't have any proper height dependent 3D drawing yet. Might be an issue that I did Switzerland, mostly centered over Zurich so not much in the way of complex buildings. I will try New York next. Unfortunately the fill-extrude-height and fill-extrude-base requires "stops", adding a layer of complexity to my demo style.
Second issue that I may face, what "order" do I do in the tm2source for buildings? Right now, it's ORDER BY ST_YMin(ST_Envelope(geometry)) DESC. But thinking about it now, I may need to change this to be height dependent, drawing the lowest layers first, potentially sorting on min_level/min_height. Hmmm.

@stirringhalo First I needed to know whether you would be interested in adding more information. As coverage with extended buildings tags varies a lot, it might not make sense to predefine e fixed attribute set.
Once there is an agreement about that, I'm fine to work on the renderer.

@kekscom I have no problem adding more tag information.

Have to figure out why building:part is missing, I'm not as familiar with imposm3 mapping as I am imposm2.
I'd like to put forward a tm2source eventually with all the tags, but it will explicitly not be compatible with Streets as much as reasonably possible.

I figured out the bug, it was a missing set of keys in mapping.yml!
Looking great so far, I'm adding the additional features and I'm testing data-driven colouring using the colour functionality. I would love for Mapbox to add support for fallback values in the "identity" function when a value does not exist. For now, I'm just fill with default values in DB but it's definitely ugly.

More progress, I have building colours working. Next up will be materials for buildings.

If we could get rooftop drawing done, that would be absolutely amazing!

Have to figure out why building:part is missing, I'm not as familiar with imposm3 mapping as I am imposm2. Any thoughts @lukasmartinelli ?

Just note here which OSM source data you require for the 3D buildings.

Decided against rendering the materials as that would get extremely complicated and may not look very good with the limited pattern fill capabilities

Wow looks very nice ❤

@lukasmartinelli
For all, see the enhancement/add_height branch. It's got all the current progress for this.
I'm waiting on https://github.com/mapbox/mapbox-gl-style-spec/issues/480 to see how default fall-back styles will be handled for the identity function.
Feel free to rip these out and put them into the open tm2source and associated import workflow.

Integrated with OpenMapTiles....
https://openmaptiles.github.io/klokantech-3d-gl-style/#14.47/40.7086/-74.0049/16/56

Amazing! Any idea what's happening with the Eiffel Tower though? https://openmaptiles.github.io/klokantech-3d-gl-style/#15.85/48.8593/2.2959/0/57

@nicooprat Yep, the 3D is formed by straight extrusion in the z-direction with no complex roof shapes or diagonals in the z-direction possible. So all building/building:parts are rectangular!
Without any further awesomeness in Mapbox-gl-js, this is as far as we can go.

Oh too bad! Thanks for the explanation. And your work, of course :)

@stirringhalo did a great job here.. Big thanks belongs to him!
BTW It seems there is a space for a small improvement on the Eiffel tower shape:

https://www.mapbox.com/bites/00295/streets.html

@stirringhalo did a great job here... Big "thank you" belongs to him!
BTW It seems there is a space for a small improvement on the Eiffel tower shape:

https://www.mapbox.com/bites/00295/streets.html
vs

FYI https://github.com/mapbox/mapbox-gl-style-spec/issues/456#issuecomment-221927660

@klokan Hmmm, I wonder if it's an issue with units/stories/feet in the base feature OSM that caused that as I've seen nothing elsewhere (especially over NY) to suggest there's a widespread issue.
I will dig into this!


[WIP] Add load_dataset_builder

Adds the load_dataset_builder function. The good thing is that we can reuse this function to load the dataset info without downloading the dataset itself.
TODOs:

[ ] Add docstring and entry in the docs
[ ] Add tests

Closes #2484

Hi @mariosasko, thanks for taking on this issue.
Just a few logistic suggestions, as you are one of our most active contributors ❤ :

When you start working on an issue, you can self-assign it to you by commenting on the issue page with the keywords: #self-assign; we have implemented a GitHub Action to take care of that... 😉
When you are still working on your Pull Request, instead of using the [WIP] in the PR name, you can instead create a draft pull request: use the drop-down (on the right of the Create Pull Request button) and select Create Draft Pull Request, then click Draft Pull Request.

I hope you find this hints useful. 🤗

@albertvillanova Thanks for the tips. When creating this PR, it slipped my mind that this should be a draft. GH has an option to convert already created PRs to draft PRs, but this requires write access for the repo, so maybe you can help.

Ready for the review!
One additional change. I've modified the camelcase_to_snakecase/snakecase_to_camelcase conversion functions to fix conversion of the names with 2 or more underscores (e.g. camelcase_to_snakecase("__DummyDataset__") would return ___dummy_dataset__; notice one extra underscore at the beginning). The implementation is based on the inflection library.

Thank you for adding this feature, @mariosasko - this is really awesome!
Tried with:
python -c "from datasets import load_dataset_builder; b = load_dataset_builder('openwebtext-10k'); print(b.cache_dir)"
Using the latest cached version of the module from /home/stas/.cache/huggingface/modules/datasets_modules/datasets/openwebtext-10k/3a8df094c671b4cb63ed0b41f40fb3bd855e9ce2e3765e5df50abcdfb5ec144b (last modified on Wed May 12 20:22:53 2021) since it couldn't be found locally at openwebtext-10k/openwebtext-10k.py or remotely (FileNotFoundError).
/home/stas/.cache/huggingface/datasets/openwebtext10k/plain_text/1.0.0/3a8df094c671b4cb63ed0b41f40fb3bd855e9ce2e3765e5df50abcdfb5ec144b

The logger message is a bit confusing to the user - that is what does FileNotFoundError refer to?

May be replace  FileNotFoundError with where it was looking for a file online. But then the remote file is there - it's found
I'm not sure why it says "since it couldn't be found locally" - as it is locally found at the cache folder and again what does " locally at openwebtext-10k/openwebtext-10k.py" mean - i.e. where does it look for it? Is it ./openwebtext-10k/openwebtext-10k.py it's looking for? or in some specific dir?

If the cached version always supersedes any other versions perhaps this is what it should say?
found cached version at xxx, not looking for a local at yyy, not downloading remote at zzz

Hi ! Thanks for the comments
Regarding your last message:
You must pass stas/openwebtext-10k as in load_dataset, otherwise it doesn't know how to retrieve the builder from the HF Hub.
When you specify a dataset name without a slash, it tries to load a canonical dataset or it looks locally at ./openwebtext-10k/openwebtext-10k.py
Here since openwebtext-10k is not a canonical dataset and doesn't exist locally at ./openwebtext-10k/openwebtext-10k.py: it raised a FileNotFoundError.
As a fallback it managed to find the dataset script in your cache and it used this one.

Oh, I see, so I actually used an incorrect input. so it was a user error. Correcting it:
python -c "from datasets import load_dataset_builder; b = load_dataset_builder('stas/openwebtext-10k'); print(b.cache_dir)"
/home/stas/.cache/huggingface/datasets/openwebtext10k/plain_text/1.0.0/3a8df094c671b4cb63ed0b41f40fb3bd855e9ce2e3765e5df50abcdfb5ec144b

Now there is no logger message. Got it!
OK, I'm not sure the magical recovery it did in first place is most beneficial in the long run. I'd have rather it failed and said: "incorrect input there is no such dataset as 'openwebtext-10k' at  or " - because if it doesn't fail I may leave it in the code and it'll fail later when another user tries to use my code and won't have the cache. Does it make sense? Giving me this url allows me to go to the datasets hub and realize that the dataset is missing the username qualifier.

Here since openwebtext-10k is not a canonical dataset and doesn't exist locally at ./openwebtext-10k/openwebtext-10k.py: it raised a FileNotFoundError.

Except it slapped the exception name to  remotely (FileNotFoundError). which makes no sense.
Plus for the local it's not clear where is it looking relatively too when it gets FileNotFoundError - perhaps it'd help to use absolute path and use it in the message?

Finally, the logger format is not set up so the user gets a warning w/o knowing it's a warning. As you can see it's missing the WARNING pre-amble in  https://github.com/huggingface/datasets/pull/2500#issuecomment-874250500


Q3/After Q3

The first reports showing reservation dates of Q3/After Q3 are in, but the website does not support these dates yet.

Another screenshot here (r/SteamDeck)
Date is visible on the store page while logged out.

Added to the toggle
Moo model is agnostic of Quarter dates. Form was also updated


Query to get total chars on a specific campaign node

pull the total word count from a given campaign node
field list tbd...

I think a super quick and dirty way we can get this is on stage
from dosomething_campaign_load on a specific campaign
  $wcc = (array) $campaign;
  $count = 0;
  foreach($wcc as $wcc_thing) {
    if (is_string($wcc_thing)) {
      $count += str_word_count($wcc_thing);
    }
  }
 dpm($campaign);

but this ignores facts and steps
cc @fantini @mnelson338

If we're getting hacky I have an even hackier idea... I can make a simple node script that crawls every campaign page and counts all of the words on it

closing @mnelson338 got it already :ok_hand:


Six is missing in the setup.py install_requires

The title speaks itself.
By the way, I think six is a bit overkilled for the usage done here and as the maintainers of celery decided to not use it, I think we should adopt the same behavior here.

Fair point!
Would be easy enough to replace six, as it's only used twice.
https://github.com/TrackMaven/celery-once/search?utf8=✓&q=six
import sys
PY3 = sys.version_info[0] == 3

if PY3:
  def items(d):
     d.items()
else:
  def items(d):
     d.iteritems()