[RFC] Decouple the Washboard from the Host

Summary
This request for comment seeks commentary on the idea of extricating the wasmCloud dashboard (aka washboard) functionality from the OTP host and ensuring that functionality is held elsewhere. Note that the washboard functionality will not be retired or deleted, only made available on its own without requiring it be embedded in a host.
Rationale
The first and probably easiest to identify issue with the status quo is that both the core wasmCloud host (host_core) and the Phoenix server that provides the dashboard functionality (wasmcloud_host) exist in the same distribution. This means that, by default, every deployed version of a wasmCloud host carries with it the extra dependencies, size, and networking port requirements of a full web application.
This tight coupling presents problems above and beyond the deployment footprint. In our recent efforts to create static builds, having the Phoenix application be a required piece of the target output makes the pipelines more difficult. This tight coupling also means that every time we want to change, enhance, or fix the washboard, we have to release a new version of the host, even though the two logical components should be able to have their own independent release cadences.
A fairly unknown and esoteric bit of code in the OTP host actually involves a special internal pub/sub mechanism that compensates for the dashboard being within the same process as a running host. In other words, we're actually writing code to counteract negative consequences of the pairing. There are code paths we actually need to test that only arise from having the dashboard and core host in the same process.
Implementation
This section enumerates a number of possible implementations of the washboard functionality as a separate entity from the host. In all of the below cases, washboard will be removed from the OTP host. This is an objective list with identified, practical pros and cons.
Implicit in the implementation is the addition of support in the washboard UI for interacting with wadm
Embed React App in Rust+Hyper
This implementation option would follow the same pattern we use for things like our petclinic UI. Embed the various bundled UI assets inside a Rust binary, and use a built-in web server like the Hyper crate to serve up the assets. Hyper would then also have to expose an API that the React application would use.
Pros

Easy distribution - single Rust binary, easily cross-compiled
React ecosystem is robust and accessible
Leverage pre-existing team skills

Cons

We'd have to do the heavy lifting on building websockets+realtime into the server, proxying NATS

Potential counter-point is to use NATS native websockets endpoint

Non-traditional React development environment could cause friction/frustration and take more effort than desired

Yew and Tauri
Yew is a Rust-based web front end framework that has undergone exponential growth since its original creation. It gives developers a familiar component-based UI framework while also using pure Rust. The Tauri project takes pretty much any front-end (including Yew) and bundles it all up inside an easily distributed Rust binary.
Pros

Tauri takes away the manual bundling complexity from the React+Hyper manual embedding option
Rust all the way down, leveraging team skills

Cons

Tauri is still in its infancy, and Yew, despite its age, is not yet 1.0. Both projects are, despite their popularity within the Rust community, relatively niche solutions

Wash WASI Plugin
This option involves sitting on top of wash plugins implemented as WASI components. Wash, which would serve as an ephemeral bespoke host, would provide this plugin with the lattice-controller provider suitably configured with a NATS connection, as well as a bound HTTP server provider on a port. The actor component would then respond to HTTP requests and interact with the lattice via the lattice controller provider.
Pros

Absolute bleeding edge
Easy portable distribution
Looks like it's part of wash

Cons

Requires the wash plugin RFC to be built
Relies on stability in the component model
Would require Rust implementation of the plugin
Likely requires completely one-off way of embedding the app assets (js/css/html/etc)

Phoenix (Elixir) App
This involves extracting the wasmcloud_host top-level OTP application, removing the tentacles that require the underlying core host, and building and distributing it as a separate application.
Pros

Would take "almost no work", the web UI is already done
OTP wasmcloud_host application already has a NATS connection and client

Cons

Still would have the burden of building and deploying OTP applications
The web UI is stale and outdated and doesn't properly handle many hosts (e.g. it's semi-tightly-coupled to the old days when it administered one host at a time)

Flutter App
Flutter is a cross-platform framework that allows you to define your user interface in terms of platform agnostic primitives and it takes care of building the target-native binary, including iOS, Mac, Linux, Windows, and Android. This should not be confused with other bundling tools that take a web application, cram them into a bundle, and then run them inside an iframe in a native browser component.
The flutter app would communicate with NATS over WebSockets
Pros

Access to rich, interactive, reactive UIs that can be optimized for many different platforms and screens
Platform-ready easily-distributed binaries (Flutter builds the platform distros for you)
Unlock some potentially very cool user experiences around things like tablets, etc. Who doesn't want to walk around a coffee shop while administering their lattice on an iPad?
Easier for "regular devs" to write good UIs, lowers barrier
Super popular right now with a massive ecosystem

pub.dev - massive repository of reusable bits

Could be seamlessly launched by wash, e.g. wash console

Cons

New technology, lack of team familiarity

Starting from scratch, can't reuse existing Rust or Elixir libraries

Risks
Typically the biggest risk is time. We could invest a large amount of time in this effort and ultimately not please the wasmCloud community. Otherwise this seems pretty low risk. The idea that the admin dashboard should be decoupled from the actual server daemons is fairly uncontroversial. The only real risk is in being unable to decide on which of the alternatives we want to use.

I've confirmed that the Flutter app option would not require extra work to enable NATS client functionality. That's available today and works out of the box from a github open source project that exposes NATS via both TCP and WebSockets depending on which platform is the target.

Decision: TLDR deprecate the phoenix washboard for something that will work with our many different wasmCloud hosts.
Requirements notes from our wasmCloud community meeting:

Communicate using the wasmCloud lattice ctl interface protocol
Requests sending json payloads over NATS over regular NATS TCP or have NATS startup a websocket endpoint.
Be able to type wash ui and that will bring up whatever the new washboard will be.
It should be easy to update
Runnable on a system without wash
No giant pile of deps to manage for it, e.g. populating a node_modules folder vs something packaged or free-standing binary

I have a strong concern about depending on a Dart client. I don't see an "official" one in the NATS org, and while I did find one linked to from NATS' blog, it hasn't been updated since 2019. We've run into limitations and frustrations wrt. an Elixir NATS client, and I'd rather pick a client that is well-supported

There's a dart library for NATS that is more maintained than the one you found, it received an update just last month.

I didn't realize all the code in Flutter would be Dart. Requiring contributors to learn another new language and framework is too high a burden at this stage, in my opinion

I didn't realize all the code in Flutter would be Dart
Yup, Flutter is "just" a library for Dart that does cross-platform UI. It's not obvious at first where the line is between the two

Requiring contributors to learn another new language and framework is too high a burden at this stage, in my opinion

Doesn't the same apply to people who don't know Rust? Making things easy to contribute to is certainly a high priority, but I don't think we have any evidence ahead of time regarding who will want to contribute to this and what their language background is.

Would it be possible to have it be an app running on the wasmcloud instance itself, deployed via wadm?
It could still be started with a wash command that abstracts that away, but that might allow avoiding the need for a desktop app as well as any special infrastructure or learning - working on washboard would be working on a normal wasmcloud app.
One of the concerns I personally have with a any of the desktop app options (dart, tauri, electron, etc.) is for developing in desktop-less environments, like within a dev container, on codespaces or gitpod, as well as allowing access via non-desktop devices like mobile.

I kind of like the concept making it be a normal wasmcloud actor. The big problem with doing it as an actor though is you still eventually have to have something that talks to NATS. Using an actor to bundle up and serve the assets isn't out of the question though as a distribution mechanism, regardless of most of the options here. It looks like at a minimum any of the tauri/yew/react options get us a web page that could be accessed from any device
Overall though, I am definitely in favor of decoupling the washboard from the host no matter which technical direction we choose to take

Given the:

existing Rust skill set of the team
interest in making the project accessible to new contributors (of which many are React devs, and what I'm about to propose is React-like)
the desire to write once and run anywhere
the wish for a fast and fun dev experience with hot reloading etc
the preference to have only a single binary

Perhaps Dioxus is a technology worth considering? https://dioxuslabs.com/

Thanks for pointing this out, I'd never heard of it before. Will take a look

I did some experimentation with tauri and, quite honestly, I was blown away. I originally thought Tauri would just start a local web server and then when you start the rust binary, you just then open a web browser to the port and you're interacting with a React app.
What I ended up building was something far more like what I wanted from Flutter. The create-tauri-app rust cargo plugin is sweet, and it took care of all the things I loathe and despise about setting up React apps. I was then able to use cargo tauri build to create a native macOS DMG installer. The starter app looks like this:

This is the entirety of the Rust app:
// Prevents additional console window on Windows in release, DO NOT REMOVE!!
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

// Learn more about Tauri commands at https://tauri.app/v1/guides/features/command
#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}! You've been greeted from Rust!", name)
}

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

And here's the React code:

        <form
          onSubmit={(e) => {
            e.preventDefault();
            greet();
          }}
        >
          <input
            id="greet-input"
            onChange={(e) => setName(e.currentTarget.value)}
            placeholder="Enter a name..."
          />
          <button type="submit">Greet</button>
        </form>

{greetMsg}

I felt at ease and fully at home in this environment, and the development cycle (once all the build caches are created!) feels like it might actually be fun. It does force the developer to use both React and Rust, and it makes it a bit harder to have someone build "just the front-end", but I think that's an easily enough conquered obstacle.
In light of this, I'd like to move that we start with a Tauri + React application for washboard. If we discover that Tauri isn't usable, the worst case scenario is that we'll have a React app that we can migrate to another bundler.

I've used Tauri, Dioxus, and Leptos for fun earlier this year and agree with the Tauri recommendation at this point. Two other benefits to Tauri:

Would allow the wasmcloud core team to focus on the "Rust API" within Tauri for the UI and then let anyone slap their own JS/TS framework flavor of the week on top (e.g. I can use Svelte with Tauri, Jordan can use Vue, Kevin could use React, etc.)
The Tauri team openly did a 3rd party security audit and provide recommendations around security best practice . Really excited to see where Dioxus and Leptos projects end up, but they're going to still be going through a lot of change.

Main con I saw with Tauri was final binary size, but I think that's improving.
I wonder though how many people really use the Washboard interface to spin stuff up after their first month of Wasmcloud use. It's helpful when you're first starting and later to visualize what you already have setup, but my guess is most people move on to wash or wadm after they get their feet wet. If that's true, it might be easier to treat the Washboard as a read only tool by default and just display the state of the host in something like Grafana since it's pretty common and probably already part of a wasmcloud Dev toolkit to leverage tracing with OTEL.
It also gives you a bunch of connectivity options out of the box:

Use a http connection similar to what's being done for OTEL
Connect NATS as a WS datasource or just point to the native WS endpoint in Grafana
If you're feeling crazy, it's not that hard (it definitely used to be) to even build a custom datasource plugin

Biggest pro to me would being able to get the high level status and tracing in one spot. If we went the datasource plugin route it would also make it relatively easy to maintain for the core team, while leaving end users flexibility on the visualization.
Major con (or pro depending on the user) is the AGPL-3.0 license.

FYI a pointer to HN discussion on a great comparison of UI libs: Emerging Rust GUI Libraries in a Wasm World.

Take anything I say with a grain of salt. My ultimate goal is for Wasmcloud to rock and bring the most value to the industry. I do not gain anything from being right.
TL;DR: React/NextJS/Tauri (probably with Tailwind and radix-ui)

I have almost 9+ years in React and 6+ in Elixir. When LiveView came out, I didn't adopt it for one reason that has nothing to do with technicality: culture, despite Elixir being what makes me smile the most, pure joy and love for the language.
Far too often, I see tools coming and going in my long journey. This time may not be the same. I am still optimistic about it.
The idea of "one language rules them all" keeps missing the target by ignoring the cultural impact of that statement.
JavaScript could be better, and all those GUI tools have their problems. Still, the reality is that the friction in the frontend stack using JavaScript is far less than anything compared to it, especially now with tools like Vercel and Vite for deploying them (not applicable here; I am not focusing on deployment for wasmcloud).
Most backend folks are less passionate about the GUI topic, in my experience, and most frontend people will hang out closer to the JavaScript community and even designers.
Hiring/Recruiting/Finding Contributors becomes even more problematic. You must find that person who likes to do both things or find the frontend person who sometimes needs to learn more about the backend concerns beyond a simple HTML/Web server that renders HTML.
You left out a massive community that could contribute today due to the popularity of those tools.
At the same time, you have passionate people doing their best to strive for perfection in their ecosystem. It is a lost situation in the long term, in my opinion, based on my own experience of watching the same situation repeat itself (Keycloak Admin Dashboard rewrite is my favorite example of it)
Nowadays, I am a bit pessimistic about "one language rules them all," I would instead focus on leveraging whatever each ecosystem and community has to offer. Far too often, conversations about performance and "the best language" drive the conversations.
That being said, there is a long-term investment to make because it may be the case that today, the Rust devs would prefer not to learn something new. 🤷🏻
From the technical side,
Backend-first languages want to own the frontend stack. They get far enough to create a basic admin dashboard with low user expectations.
One fundamental question I love to ask to see how mature the tools are to focus on is, "How do you do animations," I am not talking about basic CSS animations but more advanced situations where you would leverage React Framer Motion (as an example, pick any other UI framework).
Having to rediscover the same problems as others did and ending up understanding that either the browser gives you control (which APIs like Page Transition help) or you must bring the data closest to the UI, whether you like it or not.
For Rust/Backend-first devs, if you feel the frontend stack sometimes is too complex, it is because it is, but due to lack of experience, they are achievable DX where it is pleasing for
You need to invest in and avoid the same mistakes as before. I can help. I messed up plenty of time and found "few things" that work well, tested by my passion for delegating to less experienced and Junior devs so they can own things.
The good part is that your tool is simple today, so if you have an excellent start, you should be able to scale the codebase without that much chaos.

About Flutter, research about the lack of jobs and whatnot, it probably has its day counted. Again, I don't get paid for being right. I hope it doesn't because it is an excellent tool, but for the same reason, I am saying leverage the JS ecosystem is why I would say ignore the tool.

What would I do in a perfect world if it were purely about technical concerns?
It has been a long journey in React. After so many years, I am tired of dealing with silly problems like dependency arrays and lack of observable design patterns for such cases as the primary example.
If you ask me what the most "technical is sounded" tool out there in the market as of today, I would say Vue@v3 (NOT v2) because it was a combination of the best of Angular and React combined into a perfect library, not just that, a community that rock and core maintainers that take ownership for a lot of things that you are left by yourself in React (it does not bother me because I do it over and over and over by now). I can say the same about Svelte.
BUT React, we like it or not, is the most used library out there, and the ecosystem is so massive that concern alone would make me pick React over Vue if I were the CTO. It is not just about the technical topic but the ecosystem, hiring, market ... so many other things. I wish it weren't the case sometimes.

Thanks, @yordis!
I forgot to publish the ADR for this RFC, but what you TLDR'd at the top is almost exactly what we went for. We went for statically compiled assets from Vite over a full-fledged Next.js project for the time being, but that may change based on needs.
You can see the implementation in the wash source and you can run the new UI with the latest build of wash with the following command:
wash ui --experimental

TLDR: SvelteKit/SkeletonUI/TailwindCSS + Tauri (if this really has to be a native app)
Personally I'd go for SvelteKit as it's the least "framework-y" framework, it feels like writing HTML/CS/JS should've been from the beginning. If someone is already familiar with HTML/CSS/JS then there's very little to learn before being productive in a SvelteKit project. Then there's the fact that it has company backing from Vercel, meaning you know it's success is not depending on an open source (Vue) maintainers, so it's a safe choice for years to come. And let's be honest, all the logic is going to happening in the Rust part of the application anyway so the framework for the UI shouldn't be too complex.
If going with SvelteKit I can really recommend getting started with SkeletonUI right out of the gate.
Regardless of framework, I'd also advocate for the usage of TailwindCSS. I feel it helps facilitate integration between design and code, and provides an improved developer experience.
Whatever you guys end up choosing, I'll still be on team wasmCloud 💪

TLDR: SvelteKit/SkeletonUI/TailwindCSS + Tauri (if this really has to be a native app)
Personally I'd go for SvelteKit as it's the least "framework-y" framework, it feels like writing HTML/CS/JS should've been from the beginning. If someone is already familiar with HTML/CSS/JS then there's very little to learn before being productive in a SvelteKit project. Then there's the fact that it has company backing from Vercel, meaning you know it's success is not depending on an open source maintainers, so it's a safe choice for years to come. And let's be honest, all the logic is going to happening in the Rust part of the application anyway so the framework for the UI shouldn't be too complex.
If going with SvelteKit I can really recommend getting started with SkeletonUI right out of the gate.
Regardless of framework, I'd also advocate for the usage of TailwindCSS. I feel it helps facilitate integration between design and code, and provides an improved developer experience.
Whatever you guys end up choosing, I'll still be on team wasmCloud 💪

Maybe it is worth sharing the following: https://straw-hat-team.github.io/adr/5541831634/README.html
I applied it successfully on multiple teams. I am biased because of the value that brought me more than anything else.

We've been experimenting with a simple no-backend and react-frontend dashboard for about a month now with https://github.com/wasmCloud/wash/pull/643
@lachieh first demoed this during the 05 Jul 2023 weekly community call: https://www.youtube.com/live/FN9POjvwnZE?feature=shared
We've been able to bundle this without issue and support a set of MVP functionality.


Additional actions, aliases, rule and testing for the Orion Pack

Pack Orion
Status

pack extension (Complete),

Description
Extend the Orion pack with new action, rules and expand testing and docs.
Checklist (tick everything that applies)

[X] Version bump (required for changed packs)
[x] Code linting (required, can be done after the PR checks)
[x] Tests (not required but really recommended).
[x] Completed additions highlighted in the README.
[x] Replace slack color names in action/lib/actions.py with hex strings (aka keep @emedvedev happy).
[x] Docstring's for actions.

Thanks.
Please let us know when the PR is ready for review.

Will done, I'm making good progress on the PR and have reduced the scope to just 2 more actions to do to this PR.

I've covered everything that needs written / changed for this merge. So comments are welcome, the testing is the area that I'm not totally happy with as I'm new to unit testing and it's very verbose.

The the flake8 and pylint issues have been fixed, so ready for review.

That's a pretty massive PR :)
I've added some in-line comments, it's mostly small things + some refactoring. Besides that, LGTM, :+1:

Merged, thanks!

Thanks again for the review!


Release: add Docker image

To simplify a new user's experience, it would be useful to have a Docker image with gitbase pushed somewhere, as one of the release artefacts of the project.

The gitquery binary is in the releases. You can get the latest one here: https://github.com/src-d/gitquery/releases/tag/v0.10.0

So cool! Thank you for prompt fix, @erizocosmico !
I guess it will be on https://hub.docker.com/u/srcd/gitbase on the next release?


Use bracketed paste for more commands #294

Fixes #294
What problem did you solve?
Bracketed paste is not used by several of the commands that send text to the console. This PR fixes that.
The fix is changing runTextInTerm to take a string with newline characters, instead of a string[] that is assumed to be split on newline characters. This is consistent with how runTextInTerm is actually being called in most cases.
I have also done some tidying by changing in the same way the other functions that process lines of code. This tidying should not affect behaviour.
How can I check this pull request?
Requirements:

Linux/Mac
radian
Bracketed paste enabled

Add this to keybindings.json:
{
    "key": "ctrl+1",
    "command": "r.runCommand",
    "args": "{\n1\n2"
}

Run command using Ctrl+1
Observe this output (if using radian):
r$> {
    1
    2

This should be tested with:

R, bracketed paste off
radian, bracketed paste on, on Windows,
radian, bracketed paste on, on Linux/Mac

Other tests
This PR affects all the functions that send text to the console. I have tested these to check that their behaviour is as expected, in Linux+radian, Linux+R, Windows+radian, Windows+R:
Wrap selection
In editor, type text 'iris', Ctrl+4. Should print result of t(head(iris)).
Run command with selection
{
    "key": "ctrl+2",
    "command": "r.runCommandWithSelectionOrWord",
    "args": "print($$)"
}

In editor, type text 'iris', Ctrl+2. Should print content of iris.
Run command with editor path
{
        "key": "ctrl+3",
        "command": "r.runCommandWithEditorPath",
        "args": "print(\"$$\")"
}

In editor, Ctrl+3. Should print current file's path.
Run selections
Using the following code block:
c(1, 2,
# Comment
3, 4)

Place the cursor on third line, Ctrl+Enter. All the text (without the comment) should be sent.
Select the third line, Ctrl+Enter. Just that line should be sent.
Select from '2' to '3', Ctrl+Enter. The selection (without the comment) should be sent.

Ready for review.

Nice work! I'll test this on macOS and Ubuntu soon.

@renkun-ken Wonderful! Thank you for the review and testing. I will merge now.


WP5: Unexpected lazy element in stream

Bug report

What is the current behavior?
When requiring specific libraries. I'll get a serialization error.
For example, requiring this middleware inside a custom express dev server will throw the error
const xrayExpress = require("aws-xray-sdk-express");
This bug was not seen in previous RC releases (last known to work on beta28)
If the current behavior is a bug, please provide the steps to reproduce.
I can create a reproducible repo, but i believe simply requiring x-ray SDK will cause a failure.
This only occurs in development mode and looks related to the new caching structure.
Error: Unexpected lazy element in stream
    at readU8 (/Users/zjackson/wae-coco/node_modules/webpack/lib/serialization/BinaryMiddleware.js:414:11)
    at BinaryMiddleware._deserialize (/Users/zjackson/wae-coco/node_modules/webpack/lib/serialization/BinaryMiddleware.js:450:19)
    at BinaryMiddleware.deserialize (/Users/zjackson/wae-coco/node_modules/webpack/lib/serialization/BinaryMiddleware.js:361:15)
    at Serializer.deserialize (/Users/zjackson/wae-coco/node_modules/webpack/lib/serialization/Serializer.js:41:26)
    at PackFileCacheStrategy._openPack (/Users/zjackson/wae-coco/node_modules/webpack/lib/cache/PackFileCacheStrategy.js:779:5)
    at new PackFileCacheStrategy (/Users/zjackson/wae-coco/node_modules/webpack/lib/cache/PackFileCacheStrategy.js:759:27)
    at WebpackOptionsApply.process (/Users/zjackson/wae-coco/node_modules/webpack/lib/WebpackOptionsApply.js:496:9)
    at createCompiler (/Users/zjackson/wae-coco/node_modules/webpack/lib/webpack.js:78:28)
    at /Users/zjackson/wae-coco/node_modules/webpack/lib/webpack.js:41:48
    at Array.map (<anonymous>)
✨  Done in 3.91s.

What is the expected behavior?
the build should execute without error

Other relevant information:
webpack version:  5
Node.js version: v12.13.1
Operating System: MacOs
Additional tools: uses next.js

worked for me with
module.exports = {
	mode: "development",
	target: "node",
	devtool: false,
	cache: {
		type: "filesystem"
	},
};

please provide a repro

Hmm interesting. I also found that if I require it at the top level, I would get this error. If I require it elsewhere like inline or inside a conditional, it works. Strangest thing. I'll try and extract a repo.

/cc @ScriptedAlchemy friendly ping

I'll work on it this weekend

@ScriptedAlchemy Friendly ping, we try to close all critical issues ASAP, but without reproducible example we can't do it

Let's close due inactivity, I think it was bug on Next.js side, anyway if somebody faced with the bug, feel free to feedback or open an issue with with minimum reproducible test repo, based on stacktrace it was from a plugin

I've run into this same issue and created a small repro: https://github.com/vercel/next.js/issues/27792
I also think this is a bug in Next.js, not Webpack 5. Hopefully they'll be able to provide some insight in that issue.


Error when loading AR.js three.js location only build

Do you want to request a feature or report a bug?
I want to report a bug, at least as far as I can tell.

What is the current behavior?
When importing three.js and the three.js location based build (https://raw.githack.com/AR-js-org/AR.js/master/three.js/build/ar-threex-location-only.js), the following error message appears:
Uncaught TypeError: Cannot read properties of undefined (reading 'THREE')
Just wanted to test the basic example provided here (https://github.com/AR-js-org/AR.js/tree/master/three.js/examples/location-based) and thought the fastest way would be to create a small Glitch website, import everything via CDN and test it on my mobile phone. I haven't tried the npm versions so far, but I believe, they'll work flawless.
If the current behavior is a bug, please provide the steps to reproduce.
Here's the link to my glitch project: https://glitch.com/edit/#!/panoramic-neat-basilisk Just open the dev console after opening the preview. The error should be prompted on site load.

Please mention other relevant information such as the browser version, Operating System and Device Name
Tested on Windows10 with Chrome, Firefox and Edge. Haven't found a similar issue within the issues section. If I'm wrong, please feel free to point me into the right direction :)
What is the expected behavior?
Everything should load and the basic sample works.
If this is a feature request, what is motivation or use case for changing the behavior?
no feature request
Thx for your help and best regards,
Max

Hello Max,
I'm not sure why this is happening, it's related (I would imagine) to how the AR.js bundle is built. It looks like you can't mix the use of an importmap for three.js with the built AR.js location-based bundle. @kalwalt - any ideas?
You can get it to work by installing AR.js via npm and using webpack to build. For example:
{
    "dependencies": {
<EMAIL_ADDRESS>"3.4.2"
    },
    "scripts": {
        "build": "npx webpack"
    }
}

and the webpack.config.js as follows:
module.exports = {
	mode: 'development',
	entry: './script.js',
	output: {
		path: path.resolve(__dirname, 'dist'),
		filename: 'bundle.js'
	},
	optimization: {
		minimize: false
	}
};

and then link to bundle.js from your HTML.
Also in the JavaScript source, import the modules as follows:
import * as THREE from 'three';
import * as THREEx from<EMAIL_ADDRESS>
I am intending to update the docs soon to reflect this.
Hope that helps.

I don't think it's Glitch specific, the same problem also occurs when testing on a local machine - but I am not sure myself as I didn't develop the bundling process.

@FireDragonGameStudio for info - there is now a new tutorial for location-based three.js, at: https://ar-js-org.github.io/AR.js-Docs/location-based-three/

Closing this now as I believe it has been resolved.


feat: add arma reforger support

This works on a server but reports the app id as being 0, will have to confirm if this is usual game behavior or an exception with other servers.

turns out its normal behaviour


Fix make test-rpmbuild

rpmbuild: Switch to centos-stream base image
For make test-rpmbuild, we currently are using registry.centos.org/centos
as the base image, but this has started causing build errors lately:
   $ make test-rpmbuild
   podman build -f images/rpmbuild/Containerfile .
   STEP 1/6: FROM registry.centos.org/centos
   STEP 2/6: WORKDIR $APP_ROOT/src
   --> Using cache 7843ca52c49abdbf5bc2b56a55f32697442cc7251cdd69decce6108b26b0c546
   --> 7843ca52c49
   STEP 3/6: RUN yum -y install git-core rpm-build dnf-plugins-core 'dnf-command(builddep)'
   CentOS Linux 8 - AppStream                       63  B/s |  38  B     00:00
   Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist
   Error: error building at STEP "RUN yum -y install git-core rpm-build dnf-plugins-core 'dnf-command(builddep)'": error while running runtime: exit status 1

This commit switches to quay.io/centos/centos:stream8 instead which does not have such issues.

New changes are detected. LGTM label has been removed.

Only rebased this in an attempt to get green CI


Bump nfd to the upstream v0.15.6 version

Also pins future UpdateCli bumps to the v0.15.x minor version
Works: https://github.com/mgfritch/image-build-node-feature-discovery/pull/2

We need todo an update of the sriov-network-operator chart which includes node-feature-discovery as a subchart.
However, a new NodeFeatureGroup CRD was added to the latest node-feature-discovery v0.16.0 release, whereas our current chart build scripts don't know how to separate any new CRD(s) from a subchart into the parent helm crd chart.
Let's pin to the 0.15.x minor version until this is resolved.


starlark: make repr(float(1)) be "1.0", not "1"

Fixes #130

#130 still needs a decision. This was easy enough to implement, so I'm sending it in case seeing the implementation helps with making a decision.

This was fixed by 3b7e02e, and incorporated into the Starlark spec.


[Smoke Tests] Relocate Canary Resources

Summary
The focus of these changes is to move the resources used in the Canary cloud to a new region, as the existing region appears to be out of capacity for IoT Hub instances.

/azp run net - smoke-tests


Progress bar to accumulate values on timer

@aliubimov your description always missing, sometimes it is helpful for adding more context.


How to invoke native Module on Main Thread

i create a native modeul named RNBroardcast
#import "RCTBridgeModule.h"

@interface RNBroardcast : NSObject <RCTBridgeModule>

@end

RCT_EXPORT_METHOD(startBroardcast:(RCTResponseSenderBlock)callback)
{
}

this is js code:
var RNBroardcast = require('react-native').NativeModules.RNBroardcast;
  RNBroardcast.startBroardcast((error,events)=>{
        if (error) {
          console.log(error);
        } else {
          console.log(events);
        }
      });

now is the problem:
it worked on  'com.facebook.react.RNBroardcastQueue',how can let it work on main thread.
because my native method must be work on main thread.

@facebook-github-bot stack-overflow

got you~
insert this code on my native method:
    dispatch_async(dispatch_get_main_queue()) {
    }

but i have many method, is there any other way to invoke on main thread instead of that.

Hey @gilnuy and thanks for posting this! @ide tells me this issue looks like a question that would be best asked on StackOverflow. StackOverflow is amazing for Q&A: it has a reputation system, voting, the ability to mark a question as answered. Because of the reputation system it is likely the community will see and answer your question there. This also helps us use the GitHub bug tracker for bugs only. Will close this as this is really a question that should be asked on SO.

stackoverflow quesstion


Create hash function class

Fixes #4
Creates a class that generates a hash for URL shortening. All the work is being done in the utils and test folder.
Start the unit test watcher by typing the following command:
npm run test:watch

@panoz7 adds some basic unit test that we could build upon

closing this PR and continuing work in #21


unable to intall nginx  server in chef

unable to install nginx in chef,
my recipe file contents
package 'nginx' do
action :install
end
service 'nginx' do
action [ :enable, :start ]
end
cookbook_file "/usr/share/nginx/www/index.html" do
source "index.html"
mode "0644"
end
PS G:\chefpractice\chef-starter\chef-repo\cookbooks\nginxserver> berks upload
Uploaded nginxserver (0.4.0) to: 'https://api.chef.io/organizations/harimakenti'
ubuntu@ip-172-31-21-209:~$ sudo chef-client
Starting Chef Client, version 14.7.17
resolving cookbooks for run list: ["nginxserver"]
Synchronizing Cookbooks:

nginxserver (0.4.0)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 3 resources
Recipe: nginxserver::default

apt_package[nginx] action install (up to date)

service[nginx] action enable (up to date)

service[nginx] action start
================================================================================
Error executing action start on resource 'service[nginx]'
Mixlib::ShellOut::ShellCommandFailed
Expected process to exit with [0], but received '1'
---- Begin output of /bin/systemctl --system start nginx ----
STDOUT:
STDERR: Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
---- End output of /bin/systemctl --system start nginx ----
Ran /bin/systemctl --system start nginx returned 1
Resource Declaration:
In /var/chef/cache/cookbooks/nginxserver/recipes/default.rb
11:   service 'nginx' do
12:     action [ :enable, :start ]
13:   end
14:   cookbook_file "/usr/share/nginx/www/index.html" do
Compiled Resource:
Declared in /var/chef/cache/cookbooks/nginxserver/recipes/default.rb:11:in `from_file'
service("nginx") do
action [:enable, :start]
default_guard_interpreter :default
service_name "nginx"
enabled true
running false
masked false
pattern "nginx"
declared_type :service
cookbook_name "nginxserver"
recipe_name "default"
end
System Info:
chef_version=14.7.17
platform=ubuntu
platform_version=16.04
ruby=ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
program_name=/usr/bin/chef-client
executable=/opt/chef/bin/chef-client

Running handlers:
[2018-12-02T17:32:16+00:00] ERROR: Running exception handlers
Running handlers complete
[2018-12-02T17:32:16+00:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 03 seconds
[2018-12-02T17:32:16+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2018-12-02T17:32:16+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2018-12-02T17:32:16+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: service[nginx] (nginxserver::default line 11) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /bin/systemctl --system start nginx ----
STDOUT:
STDERR: Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
---- End output of /bin/systemctl --system start nginx ----
Ran /bin/systemctl --system start nginx returned 1

please check it manually once , is it running or not

Yes I did its working
On Mon, 3 Dec 2018, 9:22 a.m. santoshkalingwar<EMAIL_ADDRESS>wrote:

please check it manually once , is it running or not
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/289#issuecomment-443581420,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqWOmek25JzzxSFXkMKpRgXcMYK3zbX1ks5u1KAWgaJpZM4Y9g9c
.

please upload your recipe files , we are unable to understand how you write, is there any syntax or spaces error

I uploaded recipe already
On Mon, 3 Dec 2018, 6:00 p.m. santoshkalingwar<EMAIL_ADDRESS>wrote:

please upload your recipe files , we are unable to understand how you
write, is there any syntax or spaces error
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/289#issuecomment-443694184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqWOmbad8UmH56UOMAoaBmdtzz2g50sGks5u1Rl-gaJpZM4Y9g9c
.

See that at the beginning of the issue only ,I hv submitted my recipe that
is default. rb
On Mon, 3 Dec 2018, 6:25 p.m. hari m<EMAIL_ADDRESS>wrote:

I uploaded recipe already
On Mon, 3 Dec 2018, 6:00 p.m. santoshkalingwar<EMAIL_ADDRESS>wrote:

please upload your recipe files , we are unable to understand how you
write, is there any syntax or spaces error
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/289#issuecomment-443694184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqWOmbad8UmH56UOMAoaBmdtzz2g50sGks5u1Rl-gaJpZM4Y9g9c
.

https://www.digitalocean.com/community/tutorials/how-to-create-simple-chef-cookbooks-to-manage-infrastructure-on-ubuntu
please above link  will help you to install nginx
it works for me
execute "apt-get update" do
command "apt-get update"
end
package 'nginx' do
action :install
end
service 'nginx' do
action [ :enable, :start ]
end
cookbook_file "/usr/share/nginx/www/index.html" do
source "index.html"
end
you create file in your cookbooks files folder as index.html
and check location of file where you want to copy that folder is exist of not


Modify Ethereum plugin config to use Connections store

This PR modifies the Ethereum plugin's config to use a Connections store. The Connections class stores Connection instances. App developers can keep a reference to the Connections store and use it to update networks and providers without reconstructing the plugin or client.
Original spec: https://hackmd.io/@polywrap-dao/BkQdG7NAq
Implemented UX:
const connections = new Connections({
  networks: {
    mainnet: new Connection({ provider }),
    rinkeby: new Connection(...)
  },
  defaultNetowrk: "mainnet"
})

ethereumPlugin({
  connections
});

// assign a Connection to "ropsten" network, or replace existing connection if ropsten exists in store
connections.set("ropsten", new Connection({ provider: newProvider })); // pass a Connection
connections.set("ropsten", newProvider); // or pass a provider directly

// get a Connection and call setProvider to avoid constructing a new Connection instance
connections.get("rinkeby").setProvider(newProvider);

An alternative implementation might hide the Connection class. In that case, users would provide a config identical to the one we currently use but wrapped in a Connections constructor.
possible alternative:
const connections = new Connections({
  networks: {
    mainnet: { provider },
    rinkeby: { ... }
  },
  defaultNetowrk: "mainnet"
})

ethereumPlugin({
  connections
});

// set "mainnet" network to given ConnectionConfig.
// This will call setProvider if "mainnet" is found in the store, or create a new Connection otherwise
connections.set("mainnet", { provider: newProvider });

Feedback is welcome!

Added support for passing providers directly into connections.set:
connections.set("ropsten", newProvider); // or pass a provider directly


SSM Parameter validation is incorrect

We have noticed during development that the regex used to validate SSM Parameters is incorrect, and rejects some valid SSM parameter input. It looks like the regex used for validation is wrong.
The example parameter path that is not being accepted has the form: /product/dev/eu-west-1/idp/domain
The documentation for PutParameter includes the following:

Parameter names can include only the following symbols and letters: a-zA-Z0-9_.-
In addition, the slash character ( / ) is used to delineate hierarchies in parameter names. For example: /Dev/Production/East/Project-ABC/MyParameter

There are other constraints, but this is most relevant to the level of validation we perform.

Closing this.
It was fixed by #317, and included in v0.12.0.


Add documentation to addresses pattern about the use of the footer with copyright

Add documentation to the Addresses pattern about the use of the footer variant with 'OS address data terms and conditions' when using this pattern.
Originally posted by @jrbarnes9 in https://github.com/ONSdigital/design-system/issues/412#issuecomment-713477098
Linked to #1112

Dupe of #1112


Use relative paths for ls.

To be consistent with the download_file and download_dir behaviour, ls and list should also default to relative paths. The current behaviour of expecting relative paths for the download methods but absolute paths for the other appears to be undocumented?

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Using Single Date is not updating startDate until endDate picked

Hi there,
I am using the datepicker inline and have it set to single date. This works fine so far. I watch the date model to detect changes and then apply the new date to my factory. This works like a treat for a date range, However when I only select one date, the date model never changes on setting the start date, therefore my factory doesn't get updated.
app.controller("OnewayPickerCtrl",["$scope","$rootScope", "searchFactory",
function($scope, $rootScope, searchFactory) {
$rootScope.flyDates = { departureDate : "" };
$scope.date = {};
$scope.opts = {
autoApply: true,
minDate: moment(),
//alwaysShowCalendars: true,
parentEl: ".cal-block .form-group",
autoUpdateInput: true,
singleDatePicker: true
};
$scope.$watch("date", function(newDate) {
searchFactory.search.searchparams.journeys[0].departuredate = moment(newDate.endDate).format("YYYY-MM-DD");
}, false);
}
]);
After some logging and disabling singleDate, I noticed that the date model only changes when the end date has been chosen. Is this a bug, or am I missing something? How can I watch for the start date updating in order to use singleDate instead of a range.
Appreciate any help

No one? I would be very grateful as this is really is starting to become a problem.

autoUpdateInput is forcefully being set to false? if I set it to true I get some output as invalid date in my model watch function, but at least on the single selection something is changing...

The issue is that the singleDatepicker is not meant to be run inline. Without it "closing" the date model will not update. This is not a bug, but a limitation of the current implementation. Triggering a click on the input can get it to work partially, but it's very hacky.

Yup, noticed as well that "autoUpdateInput is forcefully being set to false":
          el.daterangepicker(angular.extend(opts, {
            autoUpdateInput: false
          }), function(start, end) {
            return $scope.$apply(function() {
              return $scope.model = opts.singleDatePicker ? start : {
                startDate: start,
                endDate: end
              };
            });
          });

Any reason for that?

I had the same issue with startDate/endDate not being updated when the singleDatePicker:true option was set. In the end I discovered that for single date picker mode, you can just bind the model as a single date rather than an object containing startDate/endDate properties.
$scope.datepicker = {};
$scope.datepicker.opts = {
  singleDatePicker: true
};
$scope.datepicker.date = moment();

<input date-range-picker options="datepicker.options" ng-model="datepicker.date" />


Use .fromMap() constructors in example code

Currently, there are 21 .resolveWith() calls in example files.
This pull request changes 11 of them to use the new .fromMap() constructor. (Seven of them are now const!)
ListTile(
  iconColor: WidgetStateColor.fromMap(<WidgetStatesConstraint, Color>{
    WidgetState.disabled: Colors.red,
    WidgetState.selected: Colors.green,
    WidgetState.any:      Colors.black,
  }),
  // The same can be achieved using the .resolveWith() constructor.
  // The text color will be identical to the icon color above.
  textColor: WidgetStateColor.resolveWith((Set<WidgetState> states) {
    if (states.contains(WidgetState.disabled)) {
      return Colors.red;
    }
    if (states.contains(WidgetState.selected)) {
      return Colors.green;
    }
    return Colors.black;
  }),
),

Linking the original PR: https://github.com/flutter/flutter/pull/146043

LGTM! Thanks for the PR.

@nate-thegrate The new syntax is shorter and the main benefit turned out to be the equality problem it solved.
Nonetheless, while working with it those days, I found it difficult to work with it when debugging is involved.
I mainly work on fixing particular issues, and some are related to wrong states being propagated.
With the old syntax, one can simply add a print statement or a breakpoint to :

Know the states provided for the resolution.
Understand the resolution.

With the new syntax, I did not find a convenient way (other than adding breakpoint into WidgetStateMapper.resolve which is not very friendly when debugging issues with dozen of resolved colors or other properties).
Any idea to mitigate this is welcomed.


WIP: impact from workshops

would be good to get feedback on this. I experimented with a pie chart showing the occupations of participants, but it doesn't fit in nicely on the page

I am not sure where to see this change. I cloned this and tried your branch but don't see any pie chart (?)

sorry for confusion, Sofia had woken up and was on my case by the time i did the PR... I didn't include the pie chart since it didn't fit nicely on the page, so I described in words instead the number of survey respondents and their occupations.
There are only two graphs, the heatmap showing tools usage and a bar chart showing answers to yes/no questions.
I think this can in principle be merged, but some improvements might be possible

Thanks! Let's merge. We do the remaining stuff based on this. Thank you.


README example is giving a 500 error

I was trying to follow the basic example and I'm getting a 500 response from OpenAI. Tried with multiple api keys and multiple envs (local, colab, and codespaces). Thinking it might be something with the way that crew is formatting the request. Is anyone else getting this?

I'm having issues with my previously-working OpenAI drop-in API with a local model + textgen.
I'm either getting 500 errors or 404 depending on config.

Hey @howagain can you share more about the example you were trying to run? I just tested the one on README and it worked, what LLM are you using?


functionality to disable different pollers

#10
#9
#8
#7  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @iuwqyir and the rest of your teammates on  Graphite

Merge activity

Sep 17, 1:14 PM EDT: @iuwqyir started a stack merge that includes this pull request via Graphite.


Yield disbursement

Motivation:
Forward yield to a dedicated contract for the disbursement of yield
Steps:

[x] Add an address holder for the yield handling contract
[x] Add a function to retrieve the yield
[x] Add a setter function for the yield handling contract

@kassandraoftroy merge?


Release 1.4.0.pre1

Initial pre-release for testing the new node provisioning workflow.

Updated the v1.4 branch to also include #2614


Replace MapDB with MongoDB (application data) and relational database (gtfs data)

 Issue by landonreed
Tuesday Sep 26, 2017 at 16:11 GMT
Originally opened as https://github.com/catalogueglobal/datatools-server/pull/46

Replicates #38 (due to branch delete/rebase issue)
This PR uses updated gtfs-lib and gtfs-api versions to swap out the GTFSCache system for a relational database to store GTFS data.
It also swaps MapDB for MongoDB to store the main application data (lists of projects, feed sources, feed versions, detc.).

landonreed included the following code: https://github.com/catalogueglobal/datatools-server/pull/46/commits

 Comment by abyrd
Thursday Oct 12, 2017 at 19:42 GMT

@landonreed please push the changes we made earlier today (in ATL office) as soon as you get a chance. Thanks!


fix: Prompt Node using incorrect output type

What type of PR is this? (check all applicable)

[ ] Refactor
[ ] Feature
[ ] Bug Fix
[ ] Optimization
[ ] Documentation Update
[ ] Community Node Submission

Have you discussed this change with the InvokeAI team?

[ ] Yes
[ ] No, because:

Have you updated all relevant documentation?

[ ] Yes
[ ] No

Description
Related Tickets & Documents

Related Issue #
Closes #

QA Instructions, Screenshots, Recordings

Added/updated tests?

[ ] Yes
[ ] No : please replace this line with details on why tests
have not been included

[optional] Are there any post deployment tasks we need to perform?

Overriding and merging this. Minor check. Doesn't need any reviews.

 Merged it. Thought checks passed. What do I need to do for black?


DM-40502: Add onepassword-connect-dev application

This application will create the 1Password Connect API servers for all development and test 1Password vaults for SQuaRE-run Phalanx environments.
Because we need to create a separate subchart per 1Password vault and dependencies with aliases can't be templated using values.yaml, unfortunately we'll need to create two Phalanx applications, one that collects the API servers for the development and test vaults and runs on roundtable-dev, and one that collects the API servers for the production vaults and runs on roundtable. This is the one for development and test servers, starting with just IDF dev.

This doesn't work yet because I need permissions from Cristian to create the integration, but otherwise I think all the pieces are there. I will test on roundtable-dev before merging once that's available.


Spectra files downloaded multiple times

We should try to avoid multiple downloads of the same spectra files

@CS76
Returning to my previous comment  https://github.com/NFDI4Chem/nmrium-react-wrapper/issues/95#issuecomment-1521715492, it appears that our choices are limited regarding this issue because we must read the files on the wrapper side in order to generate the nmrium object that NMRium can load. However, we could consider moving the initial reading process to the server side (API), by doing that we can improve efficiency and make it transparent to the end user.

Shouldn't this be handled on NMRium ?? Why do we preprocess the data again ??

We are not processing the data twice, we just creating a nmrium object (which contains the list of spectra and their references to the physical files, without this step, we can not connect the physical files with each spectrum, you can say it is an essential process to map the files and link them with the spectrum), this process is essential for NMRium to be able to read and export the files correctly,  this happens behind the scene once you drag and drop any files.

@hamed-musallam, we can close this issue for now. We now generate the nmrium-compatible data structure for loading spectra on the first load and save it so files are always downloaded only once afterwards which should be okay to go ahead.


refactor: Replace react-bootstrap tabs with Antd tabs

SUMMARY
Replace react-bootstrap tabs with Antd tabs in Welcome, BuilderComponentPane, ControlPanelsContainer, AdhocMetricEditPopover, DatasourceEditor, AdhocFilterEditPopover, DateFilterControl. Screenshots below show a few examples of changes.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Welcome screen before/after:

BuilderComponentPane before/after:

ControlPanelsContainer before/after:

TEST PLAN

ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

@rusackas Can you please take a look?

As was discussed in PR https://github.com/apache/incubator-superset/pull/11160, I changed most of the Tabs styles to "line". The only component that still uses the "card" style is ControlsPanelContainer, because in the case of only 1 tab displayed it looks rather weird with line style (as on the screenshot).

Codecov Report

Merging #11118 into master will decrease coverage by 3.00%.
The diff coverage is 40.00%.

@@            Coverage Diff             @@
##           master   #11118      +/-   ##
==========================================
- Coverage   65.62%   62.61%   -3.01%
==========================================
  Files         834      441     -393
  Lines       39559    14718   -24841
  Branches     3610     3602       -8
==========================================
- Hits        25959     9216   -16743
+ Misses      13492     5321    -8171
- Partials      108      181      +73

Flag
Coverage Δ

#cypress
?

#javascript
62.61% <40.00%> (-0.11%)
:arrow_down:

#python
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

.../src/dashboard/components/BuilderComponentPane.jsx
33.33% <ø> (-66.67%)
:arrow_down:

.../explore/components/controls/DateFilterControl.jsx
43.45% <21.42%> (-22.62%)
:arrow_down:

...erset-frontend/src/datasource/DatasourceEditor.jsx
63.67% <28.57%> (-7.69%)
:arrow_down:

...perset-frontend/src/views/CRUD/welcome/Welcome.tsx
74.07% <50.00%> (-1.93%)
:arrow_down:

superset-frontend/src/common/components/Tabs.tsx
96.42% <100.00%> (+0.42%)
:arrow_up:

.../src/explore/components/AdhocFilterEditPopover.jsx
57.44% <100.00%> (-21.28%)
:arrow_down:

.../src/explore/components/AdhocMetricEditPopover.jsx
61.53% <100.00%> (-14.11%)
:arrow_down:

.../src/explore/components/ControlPanelsContainer.jsx
81.81% <100.00%> (-10.61%)
:arrow_down:

superset-frontend/src/SqlLab/App.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/explore/App.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 568 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 fc03549...48cfb90. Read the comment docs.

What does it look like if we make it less wide?

@ktmud I tried with full width when there are 2 tabs and 30% when only Data tab is shown. What do you think?

@ktmud I tried with full width when there are 2 tabs and 30% when only Data tab is shown. What do you think?

I think this makes enough sense for now, as I agree, the single super-wide tab didn't look good. Although I think 50% makes more sense, since that's what it the tab would be when the (only) other tab appears. This would make it more consistent from viz to viz.
Making further adjustments should be easy/fast styling PRs, so I'm not losing too much sleep over this. Also, the "customize" tab's content will be moving to a whole new area "soon" when we revamp Explore, so this is all a temporary issue.
As an alternative idea, we could show the second tab anyway, and just leave it grayed out/disabeld, but I fear that may lead to more user confusion.

Agree 50% makes more sense. I think what would be the best of both world is to have fixed padding and dynamic width by default, then automatically expand to take full width when their total width is close to the width of the wrapping container. Might be a little tricky to implement, but it could be worth it.

I changed the width to 50%. @ktmud I see your point, but I think that in many cases full width is what we want to go for, even though the tabs don't need that much space, e.g. Welcome view. In my opinion it looks better that way and I'd rather handle special cases individually. However, if there are more voices for "dynamic" approach I'm happy to refactor it that way 🙂

If you look at design mockups in SIP-34, there are multiple pages with dynamic width . Not sure what should be the default, but my guess is we will eventually need to implement a "width mode" option one way or another.
That said, if we do not need it right now, I'm OK with current solution.

Suuuuper close to mergeable... this is looking really good!

If you look at design mockups in SIP-34, there are multiple pages with dynamic width . Not sure what should be the default, but my guess is we will eventually need to implement a "width mode" option one way or another.

The tabs under the SQL Lab editor show that we have a dynamic width mode working already, so I'm feeling pretty cozy here.

@rusackas Rebase done

Hey @kgabryje - sorry this PR took another hit. I forgot this had changes for the Welcome page, which just had a big revamp merged in. You can probably just remove changes to the Welcome page from this PR, and I promise I'll get it merged in. Apologies for the extra effort, and thanks for your patience.

@rusackas Rebase done. I like the new look of Welcome page by the way!


Introduce support for Trino

Trino is a distributed SQL engine which supports many backend connectors https://trino.io/ecosystem/data-source.html - if SQLx will support this, it will support everything
see Prusto for a reference crate https://github.com/nooberfsh/prusto

@abonander Trino is not a relational store, it is a distributed query engine that supports SQL syntax for analytics with push-down optimization of query plans to backing stores.


Simplify _odeint_rev

This PR is a follow up to https://github.com/google/jax/pull/2817, and simplifies it somewhat. Adding and then removing ts[-1] is redundant. The approach in this PR is perhaps less obviously correct since time is now flipped around 0 instead of ts[-1], but it is consistent with pytorchdiffeq and saves a few flops along the way.

Thanks, @samuela !


Project image sizing

The Project section on the main page resizes the featured image based on the size of the browser. This causes the images to be displayed funny.

The Project section on the main page resizes the featured image based on the size of the browser. This causes the images to be displayed funny.

Could you prefer an idea to fix?


[v3] client_credentials should not require a user

As @romainfrancez already pointed out in #202 for v2, RFC states for grant type client_credentials:

[...] Client credentials are used as an authorization grant
typically when the client is acting on its own behalf [...]
-- https://tools.ietf.org/html/rfc6749#section-1.3.4

Right now it's required to provide the function getUserFromClient. I don't think it's wrong to have this function in general as there are use-cases where you want to authenticate a user just by client credentials. On the other hand there are use-cases where the client really isn't acting on behalf of an user but as the client itself.
I'd like to change the flow of the client_credentials grant type to allow the creation of an access token in the context of an user as well as in the context of a client.
I suggest the following changes and would be more than happy to create a PR:

Add optional parameter context to all functions inside saveToken (e.g. generateAccessToken, validateScope etc.) which could be 'user' (default) or 'client' to allow different access token types / storage for both contexts without introducing new functions.
Make implementation of getUserFromClient optional. If the function isn't implemented or doesn't return a user, context is set to 'client'.
Update the authenticate handler allowing to pass the expected context for the endpoint. Currently AuthenticateHandler.prototype.getAccessToken expects that an user object is returned by this.model.getAccessToken. This should be dependent on the value of context:

context == 'user' (default): user object expected;
context == 'client': client object expected;
context == 'user client': user or client object expected.

Should be possible to implement all this in a backwards-compatible way.

@thomseddon @mjsalinger any thoughts on this?

I think getUserFromClient being required is actually correct.
i.e. the client authorizes itself to access the data its user is allowed to access.
If you don't need user just return an empty object from getUserFromClient:
function getUserFromClient() {
    return {};
}

I think getUserFromClient being required is actually correct.
Looking at one of the "typical" grants, a client doesn't actually own any resources, but it can request access the resources owned by a resource owner.
Compare that to the client credentials grant:
As you correctly quoted:

[...] the client is acting on its own behalf [...]
But even if the client can authorize itself... without being a resource owner (aka "user") itself, there are no resources for the client to access.

So, basically the design approach behind getUserFromClient assumes that your client is a resource owner itself.
By the way, if you don't need user just return an empty object from getUserFromClient:
function getUserFromClient() {
    return {};
}

Add optional parameter context to all functions inside saveToken (e.g. generateAccessToken, validateScope etc.) which could be 'user' (default) or 'client' to allow different access token types / storage for both contexts without introducing new functions.

This would be an awesome feature. I'm currently trying to implement custom code to get this context. Any suggestions for getting the grant_type of the request inside my saveToken function?


Lag on Streaming service

@blackstone250 commented on Mon Dec 24 2018
Description: Streaming website has a "lag effect" when Adguard is opened

Current behaviour: lag in this streamign website

//: # (Replace %screenshot_url% below with a link

Screenshot:

Expected behaviour:

Screenshot:

Steps to reproduce the problem: you cannot reproduce the problem because you need a suscription
//: # When you want to see one of the channel, you see the lag in the streaming service.
Turning off Stealth mode options and user filter doesn't solve the issue.
System configuration
**Filters:**User Filter,AdGuard Base filter,Filter unblocking search ads and self-promotion,AdGuard Russian filter,AdGuard Germán filter,AdGuard Japanese filter,AdGuard Dutch filter,AdGuard Spanish/Portuguese filter,EasyList Czech and Slovak,EasyList Italy,Official Polish filters for AdBlock, uBlock Origin & AdGuard,Icelandic ABP List

Information
Value

Operating system:
Windows 10 Pro

Operating system version (iOS)
NO

Browser:
Google Chrome

AdGuard version:
6.4.1814.4903

Filters enabled:
User Filter,AdGuard Base filter,Filter unblocking search ads and self-promotion,AdGuard Russian filter,AdGuard Germán filter,AdGuard Japanese filter,AdGuard Dutch filter,AdGuard Spanish/Portuguese filter,EasyList Czech and Slovak,EasyList Italy,Official Polish filters for AdBlock, uBlock Origin & AdGuard,Icelandic ABP List, Enable ad blocking

AdGuard mode (Android only):
NO

Filtering quality (Android only):
NO

HTTPS filtering (Android only):
NO

Simplified filters (iOS only)
NO

AdGuard DNS:
Default

Stealth mode options (Windows only)
SI

Helpdesk ID (if exists):
NO

@blackstone250 commented on Mon Dec 24 2018
The platform only works with Google Chrome. Turning off Stealth mode options and user filter doesn't solve the issue.
The only solution until now is to shutdown Adguard.

@blackstone250 commented on Mon Dec 24 2018
I have Webroot Secure Anywhere i also i have tested closing it.

@Alex-302 commented on Mon Dec 24 2018
Please provide URL.

@blackstone250 commented on Mon Dec 24 2018
Sorry.
https://cablevisionflow.com.ar/
link when you enter to the service: https://web.cablevisionflow.com.ar/

@Alex-302 commented on Mon Dec 24 2018
Please check this rule in custom filter:
@@||cablevisionflow.com.ar^$document
And what do you mean under "lag effect"?

@blackstone250 commented on Mon Dec 24 2018
Hello again Alex,
Thank you for your time and help.
The rule doesn't work as i added (please see attached file).
"lag effect": the streaming video  is fried/locked for 4 seconds and then continues.
Thank you again, Alex.

@blackstone250 commented on Mon Dec 24 2018
Before your suggestion i have tried disabling adguard for the website, now i have all options activated except your suggestion

@Alex-302 commented on Mon Dec 24 2018
Ok. It seems this is impossible to fix this issue using filters. Moved to CoreLibs repository.

Hello,
I would want to know if a solution was applied to solve the lag issue in this streaming service.
Thank you.

If you need more information please ask to me.
I'll provide and test again all you need,

@blackstone250 we'll get back to this issue once AG for Win 7.0 reaches the nightly update channel

@blackstone250 Could you please try with the latest nightly version? Just to confirm that the issue is not fixed yet.

Hello again!
Thank you for your question and for help me with this issue.
Also special help to all the team.
Now i can confirm that the issue was solved.

Awesome, thank you!


Double implicit cast of optional function arguments allows a callback to receive the wrong types

Bug Report

🔎 Search Terms
optional argument cast callback

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about substitutability

There is a FAQ for half of this bug https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-with-fewer-parameters-assignable-to-functions-that-take-more-parameters.
⏯ Playground Link

Playground link with relevant code
💻 Code
const test3 = (cb: (arg1: string) => void) => {
  cb("test")
}

const test2 = (cb: () => void) => {
  test3(cb)
}

const test = () => {
  test2((val?: number) => {
    console.log(typeof val) // Expect number but it prints string
  })
}
test()

🙁 Actual behavior
This type checks just fine and prints out "string"

🙂 Expected behavior
This should fail somehow because it is unsound. I'm not sure where it should fail and maybe this is just an accepted bug, but if that is the case then the FAQ should be updated to reflect that you can make unsound behavior by implicitly casting functions with optional parameters.

Duplicate of #13043. Used search terms: callback optional unsound

This doesn't seem to be an issue in practice, and our appetite for breaking changes diminishes every day.

I guess there's no desire to fix this. Thanks for linking the other issue 👍

I guess there's no desire to fix this.

As far as I understood there simple is no good way to fix this, without introducing a whole other can of issues.


Meanings of tokens in alphabet

I notice that there are several special tokens in the alphabet, which are neither amind-acids nor gap. What do they mean？

These correspond to:

<cls> (classification token) in ESM-1 and MSA Transformer, this is the beginning of sentence token.
'' (padding token) Enables sequences of variable length in the same batch. The model ignores pad tokens.
'' (unknown token) If you use a token that isn't in the trained dictionary, the tokenizer will replace the unknown token with this so that inference will still work.
You can ignore '.' and '<null_1>'. Additional tokens are often included in embedding dictionaries in order to pad their size to a desired length for computational reasons.


CallbackProperty callback not firing on clamped polylines using ColorMaterialProperty

Clamped to ground Polylines which use a ColorMaterialProperty based material do not update each frame.
Sandcastle Example

The issue seems to be caused by StaticGroundPolylinePerMaterialBatch.js not updating the material property when using ColorMaterialProperty.js.
Using a different material property such as PolylineOutlineMaterialProperty.js works fine.

Thanks for reporting this @impactblue573!  And thanks for the great code example =)
I've opened a pull request to fix the issue here: #6927
This should be merged in time for the September 1.49 release

@hpinkos Thanks for getting the fix in so swiftly, much appreciated!!


Typo in "truncate" documentation

I'm submitting a ...
[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request

https://github.com/fknop/angular-pipes/blob/master/docs/string.md#truncate
Current behavior

Usage
...
{{ 'Hello World, how is it going?' | truncate: 14: '...', true }} <!-- 'Hello World, how...' -->

Expected behavior
',' before the last pipe arguments should be ':'

Usage
...
{{ 'Hello World, how is it going?' | truncate: 14: '...': true }} <!-- 'Hello World, how...' -->

Minimal reproduction of the problem with instructions
N/A
What is the motivation / use case for changing the behavior?
This typo caused confusion with a colleague who just started on the project. He thought that there was something wrong with the pipe but it was just a typo in the documentation.

Thank you, it's fixed


Regarding homebrew installation

Hey Dracula Team,
running into an issue with the homebrew installation process resulting in error
Error: It seems the Generic Artifact source '/opt/homebrew/Caskroom/dracula-snippetslab/latest/snippetslab-main/Dracula.json' is not there.

Seems like this file does not exist in the dracula/snippetslab repository, from my assumption its seems like the dracula/homebrew-install requires an update on their ruby script to reflect their dependencies
https://github.com/dracula/homebrew-install/blob/main/Casks/dracula-snippetslab.rb#L19-L23
or these files should be added in this repository.
Further insight on this issue would be great.

Seeing the same issue here on a brand new M1 MacBook Pro.

Same on M2 MacBook Pro


Add AUTO_WEBP option to automatically serve WebP if the client supports it

Fixes #99
Description of changes:
This adds back the AUTO_WEBP option that was available in the Thumbor-based image handler, as requested in #99.
Took the diff from @soupy1976 in that issue and changed it a little bit to make it configurable by environment variable. The function is also called getOutputFormat so it could be reused for other things.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The template for the CloudFront deployment is set up to not forward the Accept headers (see line 103). You can add them with "Headers": [ "Origin", "Accept" ].

Thanks for your effort here, @browniebroke
We have updated our solution, and your pull request has been merged into our master branch. However, as we've merged many pull requests at this time, the source code might not exactly same as what you've done. In addition, due to our internal process, we've merged source code manually, so please understand how your effort has been merged.
You can refer to the recent changes here

Confirmed that it's now in master, thanks.


late endosome synonyms

late endosome GO:0005770 add synonym PVC
late endosome to vacuole transport GO:0045324
add synonym PVC to Golgi pathway
ref for both
PMID: 14610088
Reported by: ValWood
Original Ticket: "geneontology/ontology-requests/1635":https://sourceforge.net/p/geneontology/ontology-requests/1635

thanks www.movied.org


Put the entire git message

When only one commit is part of the pull request. This change will send
the entire commit message instead of duplicating the title.

Pull-request updated, HEAD is now 31fd2d365e613ed8ad2513b83130807faaa81667

I have rewrote it in an more understandable way.

I have rewrote it in an more understandable way.

Haha thank you for telling me I'm stupid so gently :-D

You forgot to update the test though :)

Pull-request updated, HEAD is now 10a5d80059fb0412b8c74f49c4beef658d795aa1

Test failed, might be a different git version if it works locally? just thinking

Pull-request updated, HEAD is now 25b275f4c019277288af9dd8ad605939aa695ad8

nop. 💃

Pull-request updated, HEAD is now 3208f34a8f143d8afa50da3275e9e6cfce37fcf6


Track trading revenue

We should track the revenue per trade/position, aka PnL.

I think the best way to keep track of this state is extending the Position state to properly handle a Closed state.
This means that we update the position to Closed once it is closed and save the realized PnL (and potentially the closing price). I would save the PnL based on the DLC state, we could do that in a periodic task (note: the closing price would have to be saved upon Closing state and not when updating to Closed).

Note: I assume that tracking is only concerned about the realized PnL for reporting.
The unrealized PnL depends on the current price. We could periodically update the unrealized PnL in the database as well - is this something we would like to have @bonomat ?

I assume that tracking is only concerned about the realized PnL for reporting.
The unrealized PnL depends on the current price. We could periodically update the unrealized PnL in the database as well - is this something we would like to have @bonomat ?

Mhm... I would like to know the unrealized PnL as well because this could give us an overview of what's happening before it's too late (aka realized PnL).
I'm not sure what the best approach is for this.

Mhm... I would like to know the unrealized PnL as well because this could give us an overview of what's happening before it's too late (aka realized PnL).
I'm not sure what the best approach is for this.

I already thought about it :)
I propose having two separate nullable fields in the positions table, one realized_pnl and one unrealized_pnl
Therealized_pnl we update in the databse once we are in Closed state (before it is null in the database). The unrealized_pnl is set to null then.
The unrealized pnl we can periodically update in the database based on the current price.
We have to be aware that the unrealized pnl is a snapshot of when the report was created. I think that's the best we can do.
Note: I would not depict the unrealized_pnl as part if the Positions model so far. The unrealized_pnl would only exist in the database (for reporting).
Theoretically we could also use the same pnl field for realized and unrealized and make it dependent on the state which one it is... - but I think such an "optimiztion" will cause more confusion than it helps :)

Note: I already started adding the realized_pnl and the Closed state. I will see to add the unrealized part in a separate PR on top once this part is done :)


fix: only skip mtime check on ~/.cargo/{git,registry}

Fixes #12090
Makes cargo able to recompile projects in CARGO_HOME subfolders if they are not in a directory marked as readonly (git and registry).

Pardon my title editing 🙇🏾.

Thanks @jo1gi
@bors r+

:pushpin: Commit 839069f03fc9775ec16a119f3d6b21be1c9facf3 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit 839069f03fc9775ec16a119f3d6b21be1c9facf3 with merge fc6cf8c7f8b8f6744e3d851f109c84731bc36988...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing fc6cf8c7f8b8f6744e3d851f109c84731bc36988 to master...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing fc6cf8c7f8b8f6744e3d851f109c84731bc36988 to master...


Different textAlign on iOs & Android

On iOs the text of the item is set left to right and if the text is longer than component width it makes the text truncate (ellipsis), instead of android, on android the text is set right to left and don't truncate the text.
Android

iOs

I have the same code to both platforms

Thanks for issue and sorry for delayed reply. This looks like a bug in RN TextInput described in  facebook/react-native#14845. Sadly all issues that I've found are closed but not fixed. I've experimented a bit and could not find any usable fix.


SAK-26284 - Correct commit with hibernate spelling

Sorry for not spotting this in #259.

Yeah, it's okay, I must have stared at it directly for about 30 minutes trying to figure it out, knowing it had to be the spelling, and still not seeing it. ;)


Issue/3872 fix doc link check (#3873)

Pull request opened by the merge tool on behalf of #3873

Merged into branches iso5 in 52c38c18580573336fdddd088d8ffa1de88d5935


Allow setting sourceRoot from config, defaulting to context

There's currently a few things wrong with the way sourcemaps are handled through the sass-loader -> css-loader -> extract-text | style-loader chain that causes paths to be wrong.
In my case, sass-loader shouldn't be setting sourceRoot to something I can't configure since I'm running the webpack build outside of the current working directory. sourceRoot should also just be the current context by default.

Thank you for your PR.
TBH I don't know why we're overwriting sourceRoot here. Maybe it wasn't set to the time I tried the source maps. However, it seems like there is an sourceMapRoot option in node-sass. We should use that one if its set.
Could you check the following things:

What is the value of sourceRoot when the sourceMapRoot option is not set?
Is the value of sourceRoot correct when the sourceMapRoot option is set?

👍
It seems kind of weird to make the entries in sources relative to context but use a different path for sourceRoot.
The existing behavior means the result of sass-loader needs to be fixed before you can rely on its source maps. I have this loader which I run immediately after sass-loader to work around this issue:
const path = require('path');

/** make sass sources absolute because nothing resolves the result against the sourceRoot...
 * https://github.com/jtangelder/sass-loader/pull/250
 * https://github.com/bholloway/resolve-url-loader/pull/23
 */
module.exports = function(source, sourceMap) {
  this.cacheable();

  // sass-loader changed the root of the relative paths in 4.0.0 and added sourceRoot
  const root = sourceMap.sourceRoot != null ? this.options.context : this.options.output.path;

  this.callback(null, source, Object.assign({}, sourceMap, {
    sources: sourceMap.sources.map((s) => path.join(root, s)),
    sourceRoot: null
  }));
};

I won't add a new option to the sass-loader, because this should passed directly to node-sass as sourceMapRoot option. But I won't override map.sourceRoot anymore when it's defined.


Fixes issue 2313 - Fix Open Files Context Provide for WSL and SSH

Description
Remote SSH and WSL files are represented with a uri scheme of vscode-remote. There is a check in the openFiles method of the ideUtils class that checks to see if the current uri is of a schema file, if it's not it get's filtered out.
This breaks the OpenFilesContextProvider for the vscode-remote schemes.
Checklist

[x] The base branch of this PR is dev, rather than main
[ ] The relevant docs, if any, have been updated or created

Screenshots
Before fix
https://github.com/user-attachments/assets/9c13b347-3440-4d88-a6f2-869254173189
After Fix
https://github.com/user-attachments/assets/4dbfead7-ca5c-4c4c-8a24-5512b41cfbc6

@sestinj apologies for another PR on this issue. This PR reverts my prior change and includes the necessary change to fix the nature of the issue. I'm not entirely sure all the ways that the documentIsCode function is being utilized but I suspect that this will fix lingering issues in those other methods as well.

This looks great, thanks!


version 0.0.4 unreachable

I cannot install latest version of package(
can you deploy it to npm?

Hi, thanks for pointing this out! Version 0.0.4 is published to npm now.
Best regards,
Rico


Adjust handling of visible space char for \verb*

Please adjust code to fit with 2e kernel changes from https://github.com/latex3/latex2e/issues/70

Actually, listings still needs to be patched; it uses \textvisiblespace in general, but when the current font family is the monospaced one.
\def\lst@ttfamily#1#2{\ifx\f@family\ttdefault#1\relax\else#2\fi}
\def\lst@visiblespace{\lst@ttfamily{\char32}\textvisiblespace}

Since patching \lst@visiblespace has been removed, the consequence is that visible spaces are sometimes lost with listings.
I guess that listings should be updated to have
\def\lst@visiblespace{\lst@ttfamily\verbvisiblespace\textvisiblespace}

but I'm not sure that can happen soon.
See https://tex.stackexchange.com/q/514982/4427

@eg9 why do you think listings couldn't be patched (any time soon)? It would be a more natural place, but of course, as a temporary measure @wspr could add your suggested patch here.


CB-17305 Adding dedicated InitiatorUserCrn parameter to Consumption o…

…perations. Now all 3 methods have this parameter. I have added used ThreadBasedUserCrnProvider for getting initiator user and passing it as  a parameter. I have tested the solution by creating an environment. Now in creation of both environment and datalake the parameter generated and passed as parameter.
See detailed description in the commit message.

in general I do not see, why do you need this? because you need to call these internally? if yes, then you can use monitoredResourceCrn to make the API internally callable: https://github.com/hortonworks/cloudbreak/tree/master/authorization-common#how-to-make-an-api-internally-callable see @TenantAwareParam section

so 2 of 3 endpoint has Crn parameter, the last one has accountId parameter, so if there is no explicit need, initiatorUserCrn is not necessary

@SubhanHakverdiyev
Yes I have seen the jira, although I am not sure why @lajosrodek thinks the user is incorrect.
The internal actor itself can be considered as a valid user, a technical user, which can be used by a service to call another service, even if the tenant part of the CRN is modified. (Authz README mentioned above explains why do we need this)
And also it feels odd to change the production facing API only for logging, especially when the internal actor user should be considered a valid user and it is/should be a known concept by consumer of CB logs.
Since this change has no effect on production behavior, I would wait until Lajos returns and discuss this.

yes, audit can be a valid production related request for adding the actual user crn, then this is good for me too

@biharitomi  Thanks for clarification.


Use Credentials from .env and not from json

Is it possible to get the firebase service credentials not from a json file but from an environment or as Firebase offers as a server auth token?
Like here https://github.com/laravel-notification-channels/fcm/tree/v1#setting-up-the-fcm-service
My problem ist that i can easily set environment in my deployment but not a file.

While it's not documented on purpose, it's possible with setting the environment variable FIREBASE_CREDENTIALS with the minified output of the JSON file. You can create it, for example, with jq and the following command
$ jq -c . < /path/to/service_account.json

@jeromegamez  thanks for the hint, i could have guessed that too.
I put the content of the service_account.json to that environment. Works like a charm!


Force delete branch | Switch to remote branch

Added two new commands that helped me to set up mobile client.
On mobile client:

Create a temporary branch.
Force-delete desynchronized branch
Checkout remote branch

@denolehov I would really appreciate it if you could look at this PR. It will help me to set up a mobile client properly.

Hey thanks for your contribution! Sorry for taking so long for an answer.
Do you really need the force delete branch command? I check whether it can be deleted without force and asks again it needs force. Didn't work that or did you just want to add a quicker way?

@Vinzent03 well, judging by the code, there should be a confirmation dialog, if the "force" parameter is needed. But I couldn't make it work, so I thought, maybe it's ok to add an option to set this parameter from the outside, without first asking Git to check it.

Ok, I'll adjust the PR this way.

@Vinzent03 updated the PR

LGTM! Thanks for your contribution!


new benchmarker/benchmarks; keeps old benchmarks

adds/updates benchmarks and an npm script to use the new benchmarker.
i decided not the do anything with the old benchmark files yet but we can add that as part of the pr if decided.
related: https://github.com/orbitdb/benchmark-runner/pull/32

We should probably remove the call to npm run benchmark in CI until we have a way to reliably compare performance across builds

We should probably remove the call to npm run benchmark in CI until we have a way to reliably compare performance across builds

I was unaware it was added; where is it added?


@num-pages and @page-loaded listeners aren't working

I think this is probably an issue with newer versions of Vue.js.  In order to listen to emitted events for num-pages and page-loaded I need to use @numPages and @pageLoaded.
I'm using Vue 2.5.3.

events should be @page-loaded and @num-pages.
eg.
<pdf @num-pages="numPages = $event"></pdf>

Feel free to reopen if the problem persists.


Task: deploy cas-obps-postgres and registration/reporting app in the funny namespace

Describe the task
manual deployment of the registration app + database in the funny namespace
This should ideally be done with the helm chart and the make install script, configured properly
Acceptance Criteria

[ ] first
[ ] second
[ ] third

Additional context

Add any other context about the task here.
Or here

Going to use this ticket to document findings for deployment utilizing Nx monorepo tooling.

note: funny namespace no longer exists so we are using the CIF-tools namespace (c53ff1-tools)


Error with covid sample

Just tried the plugin with the covid test dataset documented on the front page.
After loading the dataset and going to "Explore" in grafana, then selecting the data, the following error appears:
record on line 57: wrong number of fields
Not sure if there's a parsing issue or if the csv format is bad but wanted to share the error.
Note, loading the natural gas sample csv works.

Sorry, the example in the README was wrong. You need to use the raw content rather than the GitHub file page. I've updated the README accordingly. Thanks!


data-type attribute gets hijacked by plyr

I noticed that whenver I use data-type="whatver" anywhere on the page where I also have plyr scripts the data-type is being taken over by plyr.
For example I have product detail page that has quantity number counter with plus and minus icons to add or remove quantity. My icons have data-type="plus" and 'data-type="minus"... On the same page I also use plyr and once initialized it will wrap my icons with a div of class plyr plyr--minus` for the minus icon.
Thanks for the great plugin!

Thanks for reporting. Will get this fixed up in v3 which is coming soon

Closing this one as I think it's fixed but feel free to re-open if not solved in v3 👍


Avoid loading mixed mode content

Tiny fix to avoid loading images over http when serving over https

Absolutely, fixed


[ENH] - Explore concurrency config for integration tests

Context

Our current integration tests have been queued for a long time and should be updated according to only the most recent commit.

Value and/or benefit

Helps with a faster feedback loop for the user
Address stuck runs of our tests

Anything else?
No response

@aktech is this something you want to have a look? otherwise I can work on this

@viniciusdc I assume we can close this after having merged https://github.com/nebari-dev/nebari/pull/2393, right?


Move to https://github.com/kubernetes-sigs

[x] create owners
[x] repo naming convention

Work items:

Need to work on the hack shell script library to run test scripts via make file
Add documentation for the CSI driver
Need to add e2e tests -> tests added, adding the code on the latest changes and testing completed 60%
Need to add unit tests -> 70% completed, simple tests added,
kustomize added, need to add standard branches and raise PR
Need to set PR actions once the test scripts and the hack script are ready

Rename the repository to ibm-powervs-block-csi-driver
update the readme
Add Madhan as approvers
rename the module to sigs.k8s.io/ibm-powervs-block-csi-driver/

Issue created: https://github.com/kubernetes/org/issues/3169

This is done