[Bug]: Flow is missing from Shopify Extensions Scaffold List on 3.8.2

Please confirm that you have:

[X] Searched existing issues to see if your issue is a duplicate. (If you’ve found a duplicate issue, feel free to add additional information in a comment on it.)
[X] Reproduced the issue in the latest CLI version.

In which of these areas are you experiencing a problem?
Extension
Expected behavior
When selecting an extension type, "Flow Action" should be an available scaffold but is missing.
Actual behavior
It returns a list omitting the flow action and theme app extension
Discounts and checkout

(1) Checkout UI
(2) Function - Cart and Checkout Validation
(3) Function - Cart transformer
(4) Function - Delivery customization
(5) Function - Order discount
(6) Function - Payment customization
(7) Function - Product discount
(8) Function - Shipping discount
(9) Post-purchase UI

Point-of-Sale
(10) POS UI
Merchant admin
(11) Subscription UI
Analytics
(12) Web Pixel
Reproduction steps

yarn shopify app info

YOUR PROJECT
Name            NAME
Root location   NAME
DIRECTORY COMPONENTS
web
📂 web
theme_external
📂 dawn-extensions   extensions/deployment
config file     shopify.theme.extension.toml
ACCESS SCOPES IN ROOT TOML FILE
write_products
TOOLING AND SYSTEM
Shopify CLI       ^3.48.3
Package manager   npm
OS                darwin-arm64
Shell             /bin/zsh
Node version      v17.6.0
yarn shopify version
Current Shopify CLI version: 3.48.3
yarn shopify app generate extension --type=FLOW --getting-started
error ──────────────────────────────────────────────────────────────────────╮
│                                                                              │
│  Unknown extension type: FLOW.                                               │
│  The following extension types are supported: post_purchase_ui,              │
│  checkout_ui, pos_ui, subscription_ui, web_pixel, theme_app_extension,       │
│  cart_checkout_validation, cart_transform, delivery_customization,           │
│  order_discount, payment_customization, product_discount, shipping_discount  │
│                                                                              │
Operating System
MacOS, Brew
Shopify CLI version (check your project's package.json if you're not sure)
3.8.2
Shell
No response
Node version (run node -v if you're not sure)
v18
What language and version are you using in your application?
Node

Hi @keiraarts, i'll be closing this issue since it's not a CLI bug, but feel free to ask any other question regarding how to upgrade or if you encounter any problem.


add new method

[x ] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@YES-Lee
Thank you for your contribution to the page! 👍 We're happy to accept these changes and look forward to future contributions. 📝


updated carousel component

Got rid of top previews of other images, added automatic transition feature to next image, fixed css accordingly

@jordyny nicely done! The next step would be to add this text part.

Don't worry about the "Popular event" text. Also, it would be great if you can experiment with some portrait(vertical) images.


Tenant Name vs id

The instructions stated using the Tenant Name as ida:Tenant in the two config files.
"Find the app key ida:Tenant and replace the existing value with your Azure AD tenant name."
I found that I had to use the Tenant ID value in these two configuration elements for it to work.

You are right, Tenant can be the tenant ID or the domain name associated with your tenant.


bin files are used once they were created

I've noticed this issue after we've started to use pnpm to install pnpm deps. The build was failing too frequently on appveyor.
link_bins was not returning a Promise. As a consequence the linking step was being completed too early and the next step was trying to use the bin files which were not yet created.
I think this bug is a pretty old one. Might fix some of the open issues.

Seems like I did not fix it yet :-(

Published the fix on my scoped pnpm (@zkochan/pnpm) and ran the appveyor build twice, so the fix works.

@zkochan you are cool

Thanks!


This is in response to a old Feature Request to add a Make -All Menuswapper addition

I've just rebased my code and this should be ready to be merged. Really simple addition really. I think this meets our conventions but correct me if I'm wrong.

I don't know how I am supposed to fix this checksytle error because I checked and there are no space indents where travis thinks there are.

I guess this is one of these things: https://github.com/runelite/runelite/wiki/Rejected-or-Rolled-Back-Features

This is no longer relevant with the "new" make all item screen


BLC_07: Go SMALL text is slightly cut off from right side in Full screen

SEVERITY: Minor
MODULES: Bubble Chart, Bar Chart
OS / BROWSER: Windows 7 / Chrome 45.0
STEPS TO REPRODUCE:

Navigate to URL: http://static.gapminderdev.org/vizabi/release/v0.5.1/preview/bubblechart.html
Bubble chart page will be loaded
Click on GO BIG
Big screen will shown
Note that text is slightly cut off from right of GO SMALL

ACTUAL RESULTS:
Go small text is slightly cut off from right side in Full screen
EXPECTED RESULTS:
Go small text should be shown completely
SCREENSHOTS:

Retest Result: Failed
RELEASE: v0.7.0
DESCRIPTION: This issue is appeared again, can be seen in below screenshot
SCREENSHOT:

@k6Labz please retest on develop branch


How do we listen for a ctrl-C to stop any async processes we might have triggered

I am wanting to get notified if a ctrl-C or other key combination was sent while the CLI tool is running so I can react accordingly.

SwifCLI doesn't have any specific built in functionality for this, but using C's signal function should work:
signal(SIGINT) { (val) in
     // React
}


Add optional parameter to specify milestone an issue should be linked to

We miss the functionality of linking todo to milestone.
Use case. I have planned release and tasks with No milestones. I want to be able to add tasks to the same current milestone or another milestone. It will help to either postpone deadlines when scope cannot be reduced or pass tasks to the future milestone.
Example of syntax can be:
/**
 * @todo #[issue#]/<#[milestone#]><:[time]></[role]> <[description]>
 */

@yegor256/z please, pay attention to this issue

@chameleontartu/z this project will fix the problem faster if you donate a few dollars to it; just click here and pay via Stripe, it's very fast, convenient and appreciated; thanks a lot!

@ChameleonTartu PDD is not for planning, it's for finding puzzles and reporting them. The planning should happen afterwards, in the issue tracker, by hands. The author of the puzzle must not make these decisions.


[Bug Report][Windows] GPU usage in idle state

os: windows 11

There is a constant 8% gpu usage in the state where  the video is not even starting to play
There is a constant 15% gpu usage when the video is finished playing or stopped or paused

This could causes the laptop to drain the battery too quickly

I can confirm, there's GPU usage in idle state on Windows. I'm yet to find the cause.

Seems this may be due to https://github.com/media-kit/media-kit/blob/ac336385a689d963ae0d19c0901917cf5991d6de/media_kit_video/lib/media_kit_video_controls/src/controls/material.dart#L946C1-L946C1
While the CircularProgressIndicator is set to 0 opacity its actually still animating.
The following fix works but I assume Visibility doesn't wait for the animation.
Visibility(
  visible: buffering,
  child: AnimatedOpacity(
      curve: Curves.easeInOut,
      opacity: buffering ? 1.0 : 0.0,
      duration: _theme(context)
          .controlsTransitionDuration,
      child: _theme(context)
              .bufferingIndicatorBuilder
              ?.call(context) ??
          const Center(
            child: CircularProgressIndicator(
              color: Color(0xFFFFFFFF),
            ),
          )),
),

I further improvised in #453. It will be part of next stable release.
Thanks!

@Jhonfunk @NotAgentBilly
A new update has been released. Please refer to the "Installation" section of the README.
Thanks!


Amplitude.play() does not return promise to handle Chrome's new media policies

Issue description
Amplitude.play() is failing in latest versions of Chrome with this error
Uncaught (in promise) DOMException: play() failed because the user didn't interact with the document first. https://goo.gl/xX8pDD
That's fine, but Amplitude.play() returns undefined -- it would be more helpful if it returned a promise so that action could be taken in case of a failure like this. The native play() method on an audio element works like this. My current workaround is a timeout to check if the player is actually playing, but that's not a reliable method.
Environment

What's My Browser Support link: whatsmybrowser.org/b/2F9A7SX

Amplitude.js Version: 3.2.3

Steps to reproduce the issue

Call Amplitude.play() in some function that is not triggered by a click event in Chrome.
See error.
See that Amplitude.play() returns undefined when logged.

What is expected?
Since this is new error behavior as browsers get stricter about these policies, my expectations are not relevant.
It would be nice if Amplitude.play() returned a promise.
Link to where issue can be reproduced
Any project with Amplitude.play() triggered without a user's click.
Additional details / screenshots
Google's media policy: https://goo.gl/xX8pDD

@ewagstaff Thanks so much for sending this over. I'll definitely work on getting this resolved. I'll try to return promises on a lot of these public functions as well!

Thanks for taking a look!

any update on this issue? I notice it still happening.

Here's how I solved the issue:
I noticed it had to do with the 'audio context' being 'uninitialized'.

On document load, I  used the public function 'getConfig()' to retrieve the current config of amplitude.
I then access the state property within the context property of the returned config and check if it's value is 'suspended'
if it was, I added a click event listener to the document body with a handler that calls the resume function which is found on the same context object which I attach a then function to where I remove the event listener to make sure I'm not trying to do this over and over again.

Hope this helps!
import * as audioPlayer from "amplitudejs";
onDocumentReady() {
if (audioPlayer.getConfig().context.state === "suspended") {
document
.querySelector("body")
.addEventListener("click", initAudioContext);
}
}
function initAudioContext() {
audioPlayer
.getConfig()
.context.resume()
.then(() => {
document
.querySelector("body")
.removeEventListener("click", initAudioContext);
});
}

I am experiencing a similar issue on Amplitude v4.0.0, but when I try to initialize Amplitude. My solution:
const INTERACTION_EVENTS = ["click", "focus", "keydown", "mousemove", "touchstart", "scroll"]

for(event of INTERACTION_EVENTS) {
    document.addEventListener(event, initAmplitudeOnInteraction);
}

function initAmplitudeOnInteraction(event) {
    initializeAmplitude();

    for(event of INTERACTION_EVENTS) {
        document.removeEventListener(event, initAmplitudeOnInteraction);
    }
}

This has been fixed and pushed in Amplitude 5.0. Play now returns a promise.

Today is September 24th and there are no promises returned yet in the Amplitude.play()
Could anyone use it?

Related - Spam clicking "next track" will throw the following error in firefox -
Uncaught (in promise) DOMException: The fetching process for the media resource was aborted by the user agent at the user's request.
https://codepen.io/jacob-raccuia/pen/KKzQrKR


Implementation of partition selection accumulator

This accumulator is needed for computation of probability that the partition is kept. Computations of that probability will be in the subsequent PRs.

LGTM, some nits to make dp_engine_test pass 👍


fix: tensor conversion with gpu

The conversion of GPU tensors to numpy arrays caused an error, which should now be fixed.

Codecov Report

Merging #85 (84fca25) into master (50a240d) will decrease coverage by 0.07%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##           master      #85      +/-   ##
==========================================
- Coverage   74.90%   74.84%   -0.07%
==========================================
  Files          24       24
  Lines        1104     1101       -3
==========================================
- Hits          827      824       -3
  Misses        277      277

Files Changed
Coverage Δ

deep_river/utils/tensor_conversion.py
97.82% <100.00%> (ø)

... and 3 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Hi @lucasczz,
thanks for the PR!
Best
Cedric


Enhance e2e debuggability

Every time a test fails or an interrupt is received (^C), tests dump info about pods, nodes, and a run of diagnostics.
@jim-minter @pweil-

Alternative: Instead of running diagnostics which seems like it has some extra noise we may not care about we can potentially start small and dump logs from selected components (or every pod that failed or crashloops).

Alternative: Instead of running diagnostics which seems like it has some extra noise we may not care about we can potentially start small and dump logs from selected components (or every pod that failed or crashloops).

I'm not opposed to having diagnostics output but I suspect we'll want the logs anyway for useful debugging.  I'd at least dump the infra components.

This should be ready do go but the only thing that worries me today is that it's hard to access CI artifacts and I don't think it will make our lifes easier to just use stdout so we need to figure this out.
cc @jackfrancis @CecileRobertMichon @jim-minter

lgtm - @kargakis are you ready for this to be merged?

Yes, this is ready to go in
On Wed, May 16, 2018, 00:27 Jim Minter<EMAIL_ADDRESS>wrote:

lgtm - @kargakis https://github.com/kargakis are you ready for this to
be merged?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/acs-engine/pull/2961#issuecomment-389333474,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADuFf3aeu5evpg2ZaGIgdY6kDVfQ0uEVks5ty1ZbgaJpZM4T_aS-
.

Opened https://github.com/Azure/acs-engine/issues/2982 for the openshift test failure.

@CecileRobertMichon please merge

Merging because I'm seeing this openshift E2E flakiness elsewhere, does not appear causal from this PR.

@jackfrancis thanks


Incorrect path in callstack when two scripts have the same path

While fixing https://github.com/Microsoft/vscode/issues/68321

Debug adapter sends a callstack where two frames have the same source.path but one has a sourceReference set and the other does not.
The callstack formats the row to show the full path instead of just the file name.

My guess is that this triggers the code that detects identical file names and adds more context to disambiguate, but if they are identical, I guess we should just not do that.
The scenario is that a js script in the runtime is named foo.ts and its sourcemapped source is also named foo.ts.
The DA doesn't currently send this correctly but if I fix the DA, I encounter this issue.

If you don't understand what I'm talking about I can try to put together a better repro case.
You can probably just modify something to add a sourceReference to a frame that doesn't have it, where another frame has the same source path.

Your assumption is correct, that code is probably to blame.
Here's a code pointer so you can potentially provide a PR that fixes this
https://github.com/Microsoft/vscode/blob/34cfe460e781a72cb488cd80150d82618b565211/src/vs/workbench/contrib/debug/common/debugModel.ts#L344


How to use a custom std

xbuild currently compiles core and alloc and puts in the custom sysroot. Is it possible to put a custom std in that location and compile it?
The idea is that we can provide a minimal custom std so that crates that need std can be compiled without changing their code.

This is not supported currently and I don't think that we will add a feature like this, given that this crate is likely replaced by the -Zbuild-std feature of cargo soon (also see https://github.com/rust-lang/wg-cargo-std-aware/issues/7 for a discussion about custom standard libraries with -Zbuild-std).
As far as I know, the xargo project does support building a custom standard library, so maybe that works for you.


File "datatype.yaml" could not be found

Hello there,
I am trying to use this great tool for translating a BridgePoint-model to DTDL. My aim is to create an "Azure Digital Twins" graph.
I already created a simple xtuml-model and set the paths in [] correspondingly. But at the time of execution the following exception is thrown:
System.IO.FileNotFoundException
HResult=0x80070002
Message = Could not find file 'C:\Users...\dtdl-schema-generator\DTDLSchemaGeneration\ConsoleAppDTDLGenerator\bin\Debug\net5.0\datatype.yaml'.
Source = System.Private.CoreLib
Stack:
at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle)
at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamReader.ValidateArgsAndOpenPath(String path, Encoding encoding, Int32 bufferSize)
at Kae.XTUML.Tools.CIModelResolver.OOAofOOAModelBuilder.LoadDataTypeDef(String yamlFilePath)
at Kae.XTUML.Tools.CIModelResolver.ConceptualInformationModelResolver.LoadOOAofOOA(String datatypeDefFilePath, String metaModelFilePath)
at Kae.XTUML.Tools.Generator.DTDL.DTDLGenerator.LoadMetaModel() in C:\Users...\dtdl-schema-generator\DTDLSchemaGeneration\Kae.XTUML.Tools.Generator.DTDL\DTDLGenerator.cs: Line67
at ConsoleAppDTDLGenerator.Program.Work() in C:\Users...\dtdl-schema-generator\DTDLSchemaGeneration\ConsoleAppDTDLGenerator\Program.cs: Line52
at ConsoleAppDTDLGenerator.Program.Main(String[] args) in C:\Users...\dtdl-schema-generator\DTDLSchemaGeneration\ConsoleAppDTDLGenerator\Program.cs: Line24

Note: I didn't give the optional parameter "--meta-datatype"

so in the method "modelResolver.LoadOOAofOOA()" the parameter "MetaDataTypeDefFilePath" is null.
https://github.com/kae-made/dtdl-schema-generator/blob/bccf5e2e7eed8177440d7cc40c4ed335e5f123ac/DTDLSchemaGeneration/Kae.XTUML.Tools.Generator.DTDL/DTDLGenerator.cs#L67
then inside of the method "modelResolver.LoadOOAofOOA()" the default filepath "datatype.yaml" is being used. But apperently this file does not exist, which is why the exception is thrown.

I hope someone can give me a hint what to do for successfully generating DTDL.

Additional Information:
OS: Windows 10 (Version 21H2)
IDE: Visual Studio 2022 (Version 17.3.4)
installed dotnet-versions: .NET 5.0 Runtime (No Support); .Net 6.0 Runtime (LTS); .NET Framework 4.8 SDK; .Net SDK

Thank you for your trying my tool.
I checked version integrity of related libraries and verified that it works correctly.
Please give it a try.


Add Suffer (Ft. Skoot) by Petit Biscuit

Song Name
Suffer (Ft. Scoot)
Artist Name
Petit Biscuit
Source
Youtube
Youtube Link
FoHr23PYwaZm-5ni
Direct File Link
No response
Song ID
985524
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 71195247

reject
invalid YouTube link


docs: no more cask exceptions

[x] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

This is pretty confusing since all these are deprecated in core. We should just remove this.

Review period will end on 2021-03-25 at 15:18:37 UTC.

Review period ended.


Enable SPM in Jaeger v2

Which problem is this PR solving?

This PR is a part of the issue #5632

Description of the changes

Added a new docker-compose file
Added the configuration file which will be used for enabling SPM in v2

How was this change tested?

Run make dev-v2 inside docker-compose/monitor

Checklist

[x] I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
[x] I have signed all commits
[x] I have added unit tests for the new functionality
[x] I have run lint and test steps successfully

for jaeger: make lint test
for jaeger-ui: yarn lint and yarn test

I strongly advice including integration test in this PR, since we already have it for v1. This would be the best proof that the setup works.

Okay. I will start working on adding the e2e test for v2.

overall lgtm, but CI for v2 failed. Please test it locally first, it's fairly quick.
  time="2024-06-28T00:59:22Z" level=warning msg="/home/runner/work/jaeger/jaeger/docker-compose/monitor/docker-compose-v2.yml: `version` is obsolete"
  jaeger-1  | 2024/06/28 00:54:31 application version: git-commit=250261fca3c21d70178ee896353c4c50e971c725, git-version=v1.58.0, build-date=2024-06-28T00:52:08Z
  jaeger-1  | Error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding:
  jaeger-1  |
  jaeger-1  | * error decoding 'exporters': unknown type: "prometheus" for id: "prometheus" (valid values: [otlphttp jaeger_storage_exporter kafka debug otlp])
  jaeger-1  | 2024/06/28 00:54:31 failed to get config: cannot unmarshal the configuration: 1 error(s) decoding:
  jaeger-1  |
  jaeger-1  | * error decoding 'exporters': unknown type: "prometheus" for id: "prometheus" (valid values: [otlphttp jaeger_storage_exporter kafka debug otlp])

Still need to fix the error microsim is throwing
microsim-1    | 2024/06/28 05:19:58 Post "http://localhost:14278/api/traces": dial tcp [::1]:14278: connect: connection refused

You are missing the concept of "metrics storage", similar to span storage. It can be defined as part of query extension (as it's the only dependency), and you need to change the extension code to actually create and pass that storage to QueryService.

Yes, I will start working on this.

I left comments directly on the last commit https://github.com/jaegertracing/jaeger/commit/4ba0ad0caaa42ab50c16e1681a33ac56e4013f61

voila, e2e test is successful. Please take a look at my commits to understand what I fixed.

🎉


feature: rebase to Kubernetes 1.32.0

Feature Description
Kubernetes 1.32.0 is slated to come out tomorrow. We should rebase kcp to that new version. A final changelog isn't out yet, so it likely makes sense to wait for that to understand what changes to expect from the rebase.
Proposed Solution
Follow the rebase guide.
Alternative Solutions
No response
Want to contribute?

[ ] I would like to work on this issue.

Additional Context
No response

/assign gman0

Taking (I would self-/assign but that probably won't work for me at the moment because of perms).

/assign gman0


Clean up metrics related code

Clean up metrics related code: actually install the metrics manager in our inventory, populate some metric descriptor fields that were being skipped previously, fix some newly broken tests, and consolidate some of the duplicated test classes.

This change is

Codecov Report

Merging #273 into master will decrease coverage by -0.22%.
The diff coverage is 68%.

@@            Coverage Diff             @@
##           master     #273      +/-   ##
==========================================
- Coverage   83.96%   83.75%   -0.22%
==========================================
  Files          49       49
  Lines        2819     2831      +12
==========================================
+ Hits         2367     2371       +4
- Misses        428      433       +5
- Partials       24       27       +3

Impacted Files
Coverage Δ

adapter/prometheus/prometheus.go
96.42% <ø> (-3.58%)
:x:

pkg/aspect/inventory.go
0% <ø> (ø)
:white_check_mark:

adapter/prometheus/server.go
89.47% <100%> (ø)
:white_check_mark:

pkg/aspect/metricsManager.go
95.68% <88.23%> (-1.59%)
:x:

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 3f37e92...be49107. Read the comment docs.


error while loading shared libraries: libopencv_videoio.so.4.5d

If you had 'ERROR: Impossible to reset the control' message, give the DEBUG info displayed
DEBUG:

Ouput of linux-enable-ir-emitter -v -d /dev/videoX configure

configure command output
**I am using video2 for this command**
/usr/lib/linux-enable-ir-emitter/driver/driver-generator: error while loading shared libraries: libopencv_videoio.so.4.5d: cannot open shared object file: No such file or directory
ERROR: The configuration has failed.

Output of v4l2-ctl --list-devices
Integrated Camera: Integrated C (usb-0000:00:14.0-7):
	/dev/video0
	/dev/video1
	/dev/video2
	/dev/video3

Ouput of v4l2-ctl -d /dev/videoX --list-formats-ext

v4l2 device output
**I am using video2 for this command**
ioctl: VIDIOC_ENUM_FMT
	Type: Video Capture

	[0]: 'GREY' (8-bit Greyscale)
		Size: Discrete 360x360
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 640x360
			Interval: Discrete 0.033s (30.000 fps)

Additional info

Distro: Ubuntu
Version: Focal Fossa (20.04 LTS)
Version of linux-enable-ir-emitter: 4.2.1
How did you install linux-enable-ir-emitter: PPA

Opencv is not found on the system, please install it. This is weird because it is in the requiremement of the .deb package. I will look at this tomorrow.

In fact yesterday I noticed that OpenCV was not found.  The thing is, when I search for llibopencv_videoio.so.4. on my system, it actually show me a libopencv_videoio.so.4.6. I'm not sure if is then a problem with a line in the driver generator with an outdated form of libopencv_videoio.so
Check it out and let me know ^^

In order to fix the problem I have to release a new linux-enable-ir-emitter. Unfortunately, I have nothing to release at the moment. I had a small modification I wanted to do, so I will work on it.
So I advise you to install linux-enable-ir-emitter using the bash script, it will compile the software directly on your system.

Alright! I be patiently waiting for the new linux-enable-ir-emitter then. I'll also will give it a try to the one with the bash script and see how it goes. Thanks!

Sorry but I don't understand

it gets stuck in the configuration command

which normaly, should not imply

On the emitter part, it begins to work and blinks

Can you past some outputs of the configure command ? (with the answer y/n that you provide)

I'm gonna write for you the steps I made in order for you to make conclusions and stuff:

I opened a terminal and installed the bash script using the "For other distro:" steps found in the README.md
I continued by opening a new terminal and wrote sudo linux-enable-ir-emitter configure
It showed me this (as expected):

INFO: Ensure to not use the camera during the execution.
INFO: Warning to do not kill the process !
Is the ir emitter flashing (not just turn on) ? Yes/No ?

I answered 'no' to the question
Then it showed me this:

can't get debug descriptor: Resource temporarily unavailable
ERROR: Impossible to reset the control.
INFO: Please keep this debug in case of issue :
DEBUG: unit: 9, selector: 10, control: 0 8 0 187 187 187 187 187
Is the ir emitter flashing (not just turn on) ? Yes/No ?

I continued answering to the question 'no' 6 more times
Then, no more questions appeared on console and the emitter actually began to flash
I let it run for 5-6 hours with nothing new on the console log, then killed the process
I searched for anything created on the supposed driver folder (/etc/linux-enable-ir-emitter) but it was empty
I searched in the other folders created by the installation in the whole system but there was nothing new
I tested the camera + emitter using ffplay /dev/video2 and/or sudo howdy test. It worked as intended
I powered off the whole pc. Then I powered on again, went to Windows, on the lock screen I performed a reboot and then I went to Ubuntu
The camera works, the emitter doesn't

Hopefully this help you understand my process

Interesting... Can you execute sudo linux-enable-ir-emitter --verbose configure, and give all the outputs ? When the process seems to be stuck you can kill it.

Ok.
First I have to uninstall the script and delete all the remaining folders (i.e the git clone one basically) and do the same as before: power off -> Windows -> reboot -> Ubuntu. This is because if I execute sudo linux-enable-ir-emitter --verbose configure with the emitter "working as supposed to be", as the script left it before, the console just shows this before getting stucked:
INFO: Ensure to not use the camera during the execution.
INFO: Warning to do not kill the process !

So, after installing the script again, sudo linux-enable-ir-emitter --verbose configure shows me this:
INFO: Ensure to not use the camera during the execution.
INFO: Warning to do not kill the process !
Is the ir emitter flashing (not just turn on) ? Yes/No ? n
can't get debug descriptor: Resource temporarily unavailable
DEBUG: unit: 9, selector: 10, cur control: 0 8 0 187 187 187 187 187, first control to test: 0 0 0 0 0 0 0 0, res control: 1 0 0 0 0 0 0 0, max control: 255 255 255 255 255 255 255 255
DEBUG: Negative answer limit exceeded, skipping the pattern.
ERROR: Impossible to reset the control.
INFO: Please keep this debug in case of issue :
DEBUG: unit: 9, selector: 10, control: 0 8 0 187 187 187 187 187
DEBUG: unit: 10, selector: 2, cur control: 1 0 0 0 0 0 0 20 39 0 0 0 0 0 0, first control to test: 0 0 0 0 0 0 0 16 39 0 0 0 0 0 0, res control: 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0, max control: 7 0 0 0 0 0 0 128 150 152 0 0 0 0 0
Is the ir emitter flashing (not just turn on) ? Yes/No ? n
Is the ir emitter flashing (not just turn on) ? Yes/No ? n
Is the ir emitter flashing (not just turn on) ? Yes/No ? n
Is the ir emitter flashing (not just turn on) ? Yes/No ? n
Is the ir emitter flashing (not just turn on) ? Yes/No ? n
DEBUG: Negative answer limit exceeded, skipping the pattern.
DEBUG: unit: 10, selector: 3, cur control: 16 0 0 0 0 0 0 100 0 0 0, first control to test: 16 0 0 0 0 0 0 14 6 0 0, res control: 16 0 0 0 0 0 0 0 0 0 0, max control: 16 0 0 0 0 0 0 14 6 0 0
Is the ir emitter flashing (not just turn on) ? Yes/No ? n
DEBUG: Computing the resolution control.
DEBUG: unit: 10, selector: 6, cur control: 1 3 1 0 0 0 0 0 0, first control to test: 1 3 2 0 0 0 0 0 0, res control: 0 0 1 0 0 0 0 0 0, max control: 1 3 3 0 0 0 0 0 0

Same as before, the emitter begins to flash and the process gets stuck again (obviously)

From what I understand, I guess that opencv is waiting for access to /dev/video2, which freezes the process.
The emitter works because it just found the right driver, but because opencv is stuck, it can't ask the user if the driver works.
I will manually create the config file for you, in order to bypass test and the file generation. Please create the file /etc/linux-enable-ir-emitter/video2, which exactly contains :
device=/dev/video2
unit=10
selector=6
size=9
control0=1
control1=3
control2=2
control3=0
control4=0
control5=0
control6=0
control7=0
control8=0

Then execute sudo linux-enable-ir-emitter boot enable.
After that, everything should work like a charm !
But I don't understand why opencv works 6 times, but not the 7th time. For many reasons, I would like to use another library than opencv.

Yeah, that sounds pretty pretty weird.
Anyways, thanks for taking the time to help! As you said, it now apparently works like a charm. Have a good day/night ^^

You're welcome ! If you like the project, do not hesitate to star the repository to support me, thanks.
I will let the issue open until the Ubuntu repo is fixed.

The PPA repo is now fixed (or will be soon, if the builds are not yet complete).


Let hipcc not pass -mllvm option to HIP-Clang on Windows

Currently there is a clang bug on Windows causing duplicate -mllvm options in clang -cc1.
Tempoarily disable -mllvm options for HIP-Clang on Windows until the bug is fixed.
Change-Id: I3a4393ba7745989398dc6c6001722837dad18704

The link for the clang fix is https://reviews.llvm.org/D76032
It will take some time so we still need this workaround.


fix: NPE on server startup

Fixes #20060.

@sharat87 : Is it really an error that cloud services did not return any SAAS plugins?

@trishaanand, I do believe so, but that error isn't present on release-cs, so I'm guessing it was taken care of. I still wanted an NPE protection here, so opened this up.


Jedis Pool Metrics Missing for Some Services

The Jedis connection pool metrics show up for Kayenta but not for other services like Fiat.
Fiat:
spinnaker@spin-fiat-bb6bcb649-mfldg:/$ wget -q -O - localhost:7003/aop-prometheus | grep -i pool | grep TYPE
spinnaker@spin-fiat-bb6bcb649-mfldg:/$

Kayenta
bash-5.0$  wget -q -O - localhost:8090/aop-prometheus | grep -i pool | grep TYPE
# TYPE threadpool_maximumPoolSize gauge
# TYPE threadpool_blockingQueueSize gauge
# TYPE threadpool_corePoolSize gauge
# TYPE redis_connectionPool_numWaiters gauge
# TYPE redis_connectionPool_minIdle gauge
# TYPE redis_connectionPool_numActive gauge
# TYPE threadpool_poolSize gauge
# TYPE threadpool_activeCount gauge
# TYPE redis_connectionPool_maxIdle gauge
# TYPE redis_connectionPool_numIdle gauge

In my Spinnaker, only orca's metrics were missing 👉 https://github.com/spinnaker/spinnaker/issues/6157

FYI this isn't forgotten and is an issue we have to address - just been not been a priority yet to diagnose unfortunately.... we'd welcome any contributions!

I've stumbled upon the same issue but I've not fixed it yet, cause we're using SQL storage in most of the services, so would need to see how many services are affected.
The class generating those metrics live in orca), and they seem to be pulled in by kayenta only ( fiat and gate don't).
That's why you can't see redis pool metrics.
The ideal solution - to keep it DRY - would be to move that class to kork telemetry I guess, cause it wouldn't make sense to pull in orca-redis on those services just for the sake of an instrumentation class.
Let me know what you think, I'll keep you posted when I manage to work on it.

Or perhaps in kork-jedis ?

Yeah we use SQL almost exclusively so NOT been a HUGE priority... very much appreciate the dig & input!!


[ISSUE] Error parsing error response: Expecting value: line 1 column 1 (char 0)

Everything was working while trying to upload a picture from computer to an Instagram page and then it suddenly stopped working
from instapy_cli import client
username = "olis_meme_vault"
password = "*******"
text  = "test #test"
with client(username, password) as cli:
cli.upload("Thomthot.png", text)
I expected it to upload the photo but it didn't work

A couple more users and myself included have the same issue that you mentioned here and somebody has already submitted an issue regarding it over in #75.
It doesn't seem like we're the only ones facing this issue. It seems like it is related to the instagram private api itself as it seems like many other libraries are having the same issue as well especially when it comes to uploads.
Still waiting to hear back on whether the private API was changed or if this is simply instagram being funny.

I'm facing the exact same issue. Someone please help.

I am facing exactly the same, I am wondering if it has something to do with the cookie... Hoping for some help in the near future.

Same error here too :/

Same here too...

same issue
please help to resolve
Error parsing error response: Expecting value: line 1 column 1 (char 0) error Method Not Allowed

now i have this problem when i run osintgram python file in kali linux
solv please ?


Using of OrbitDB

Our team is planning to build the game.
This game will be built for windows and android users, So we want to know if OrbitDB supports this type of project so that we can store our game score data in the OrbitDB database.

In general, OrbitDB is not dependant on a specific OS.
Whether it fits into your project though is a little more complicated than that.
Some factors that you might want to consider are:

How sensitive is your data? I.e. Are there potential privacy problems to come up when publishing "game scores" in a publicly readable database?
Why are P2P Databases more suited to your application than traditional centralized applications?
How stable should your software be? OrbitDB is a software in the alpha stage of development. Many breaking changes should be expected as development continues.
(See The Road to 1.0)
If you want to rely on OrbitDB for a long term stable product, you probably should look elsewhere for now.

But theoretically any kind of JSON Object or Binary Object can be stored and replicated in an OrbitDB database. Look at the store section of the API documentation for a suitable
database for your use case.
I hope this to be helpful.

@CryptoGraph929 can this be closed?

Closing.


add ability to run svgr in sync mode

@neoziro I was thinking of creating a svgr/macro to run svgr as a macro but realize when writing a macro the code needs to run synchronously. Do you think we could make a sync option for svgr to add this functionality?

Is it not already done? https://github.com/evenchange4/svgr.macro

@neoziro I understand that the preferred method is async, but sometimes there are reasons why you would run in sync mode, e.g. this macro. the macro currently is using a execSync function from child process, it'd be nice to have an API so you don't have to run a separate process. Also, it'd be cool to support a glob pattern.

Yes, but I don't know if it is even possible to run it synchronously. Let's reopen it.

Follow up in #185.


Why can't I return different error types in a "andThen" chain?

Hi,
Thank you for publishing this!
I wanted to get started right away but ran into a seemingly trivial problem I am too much of a noob to solve. Any help would be appreciated!
The compiler complains when I want to compose multiple results with the .andThen() method
type E1 = 'invalid'
type E2 = 'also invalid'
type E3 = 'invalid again'
type Errors = E1 | E2 | E3

const f1 = (sth: unknown) => Result<string, E1>
const f2 = (input: string) => Result<string, E2>
const f3 = (thing: string) => Result<string, E3>

const result: Result<string, Errors> = f1('test')
                         .andThen(f2)
                         .andThen(f3)

The compiler complains that that the result of f1 is not assignable to the result of f2, specifically Result<string, E1> is not assignable to Result<string, E2>.
I thought that the mismatch of results and function parameters wouldn’t hurt, because .andThen() doesn’t even call the next function if the result is of type Err. Any idea how I could help with the type inference?

Hey @kolandar,
So I copy / pasted your code to try and run it and noticed a few things.
Firstly, Result is only a type - it does not have a corresponding runtime class (in typescript a class is both a value and a type).
Hence an expression such as:
const f1 = (sth: unknown) => Result<string, E1>

is not valid. Result<string, E1> says, "I represent a string or a E1".
What I think you were trying to do is this:
const f1 = (sth: unknown) => ok(sth)

So if I replace your f2 and f3 functions with the same pattern, then what I get is:
const f1 = (sth: unknown) => ok(sth) // this function returns Result<unknown, {}>
const f2 = (input: string) => ok(input) // this function returns Result<string, {}>
const f3 = (thing: string) => ok(thing) // this function returns Result<string, {}>

Segue: all the results have a {} error type because the compiler at this point has insufficient information to infer what the error type is. Explicitly annotating your values would resolve this.

Now I'm at:
const result: Result<string, Errors> = f1('test')
  .andThen(f2) // <== compiler error here
  .andThen(f3)

And I get a compiler error:
[typescript]
Argument of type '(input: string) => Ok<string, {}>' is not assignable to parameter of type '(t: unknown) => Result<string, {}>'.
  Types of parameters 'input' and 't' are incompatible.
    Type 'unknown' is not assignable to type 'string'.

So what's going on?
Well, recall that f1('test') returns a Result<unknown, {}>.
So calling .andThen on Result<unknown, {}> means that the function passed to andThen must adhere to the following interface:
<U>(data: unknown) => Result<U, {}>

Where U can be anything, but the error value is already determined ahead of time. It must be the same type of the current Result.
So the issue is that f2 doesn't adhere to the interface defined above. Namely, the argument to f2 is a string, but typescript expects it to be unknown.
Hope that helps!
Also, please close this issue if this answers your question / you don't have any follow up questions!

@supermacro
thank you very much for the thorough explanation!
Did I understand correctly that andThen can't be be used to map a Result<T,E> to a Result<U,F>?
So the following will never work at compile-time, although the compiled code works perfectly fine?
(BTW: Sorry, I should have made it clear that my snippet was pseudo...very bad and ambiguous pseudo I guess...)
import {Result, ok, err} from 'neverthrow';

type E1 = {err: 'invalid'};
type E2 = {err: 'unacceptable'};
type E3 = {err: 'totally off'};

type Errors = E1 | E2 | E3

type F1 = (sth: unknown) => Result<string, E1>;
type F2 = (sth2: string) => Result<string, E2>;
type F3 = (sth3: string) => Result<string, E3>;

const f1: F1 = (sth: unknown) => {
    console.log(sth);
    const x = Math.random() * 10;
    return (x > 5) ? ok('yes-one') : err({err: 'invalid'});
}

const f2: F2 = (sth: string) => {
    console.log(sth);
    const x = Math.random() * 10;
    return (x > 5) ? ok('yes-two') : err({err: 'unacceptable'});
}

const f3: F3 = (sth: string) => {
    console.log(sth);
    const x = Math.random() * 10;
    return (x > 5) ? ok('yes-three') : err({err: 'totally off'});
}

const result: Result<string, Errors> = f1('maybe').andThen(f2).andThen(f3)

Maybe I am a little slow here, but I thought .andThen() was meant to chain synchronous functions returning Result types, correct?
Would be grateful for hints! THX!

Hey @kolandar,
I see what you mean.

Did I understand correctly that andThen can't be be used to map a Result<T,E> to a Result<U,F>?

That is correct. neverthrow is built in such a way that it short circuits upon encountering a Err instance.
What are the implications of this? Let me demonstrate via a code sample
const r1 =

I hope you don't mind me jumping in this discussion.
I see how having a union Error type can solve the issue but I'm not sure it's the only solution.
We could also have andThen return an error of type of the union of possible errors in the chain.
Example:
// Let's say we have the following functions
const validateUserObject: (user: User) => Result<User, InvalidUsernameError>
const insertUserToDb: (user: User) => Result<User, DbError | UsernameTakenError>

const res = validateUserObject(user).andThen(insertUserToDb)
// We could have
typeof res = Result<User, InvalidUsernameError | DbError | UsernameTakenError>

// This way, we can handle the specific errors
if(res.isErr()){
   if(res.error instanceOf InvalidUsernameError || res.error instanceOf UsernameTakenError){
      res.send({error: "Please choose another username"})
   }
   else {
      // We know it's a DbError
      res.send({error: "Service unavailable, please try again."});
   }
}

The only change necessary would be to change the signature of andThen to
// In Ok<T, E> or Err<T,E>
andThen<U, F>(_f: (t: T) => Result<U, F>): Result<U, E | F>

The implementation itself doesn't need to change and the change would be non-breaking because E | E === E, meaning that if you have code that chained multiple Result with the same error type, the union would be of that error type. It wouldn't interfere with the short-circuiting of the function in Err.
I see this capability as interesting when working with an external module that returns a Result<T, ModuleSpecificError>. It's error type is not necessarily compatible with my local error type (maybe the error is in a message property while my local errors use an err property).

I've thought about addressing this issue by creating a union type that would allow for returning different error types just as @paduc has demonstrated. But in my opinion I do not think the benefit is there.
For example, say you have the following types:
interface DbError {
  code: number
  message: string
}

interface ValidationError<T> {
  data: T
  errors: string[]
}

type OtherError = string

const myResult: Result<number, DbError | ValidationError<User> | OtheError>

Now let's suppose that we're dealing with the error:
if (myResult.isErr()) {
  const myError= myResult.error
}

myError now contains that union type above (DbError | ValidationError<User> | OtheError) ... The question is now, how do you distinguish between each of these types?
You have to do additional checks. Which ultimately do not save the developer any time or convenience.
Hence I still believe that by having one single error type E you end up with a better experience.
Further, I would argue that by enforcing that the user leverages discriminated unions and type guards as I showed in my comment above, that you end up with more idiomatic typescript code.

myError now contains that union type above (DbError | ValidationError<User> | OtheError) ... The question is now, how do you distinguish between each of these types?

In my case, the error types are all classes so I can easily distinguish between them using instanceof.
If you really want to use interfaces and types, I guess the easiest solution would be adding a string literal to each type.
interface DbError {
  type: 'DbError'
  code: number
  message: string
}

interface ValidationError<T> {
  type: 'ValidationError'
  data: T
  errors: string[]
}

const myResult: Result<number, DbError | ValidationError<User>>

if(myResult.isErr()){
  if(myResult.type === 'DbError'){
    //...
  }
  else{
    // compiler knows its a ValidationError
  }
}

You have to do additional checks. Which ultimately do not save the developer any time or convenience.

When you are handling a chain of tasks, it can fail at any step. Maybe you will handle all failures the same way (ex: returning the text message contained in e.message.
However, I often want to handle the failure case in a different manner depending on the type of error (ex: In case of a validation error, send the message to the user. In case of a database error, report it to the admin and retry).
To achieve this, there is no avoiding additional checks and it requires something to discriminate between error types. It's not a matter of saving time or convenience.
Yes, I could use a single error type E, add a type string literal to it like in my example above, and discriminate using the type property. But I think it is idiomatic typescript to define different types for this purpose.
Furthermore, my chain includes a call to an external module that returns a Result with a specific error type. I have no control over that error type, so I can't make it implement my generic E type. I have to deal with it and this results in code that looks pretty contrived to me:
This example is a bit contrived but displays the manoeuver necessary to force the module specific error into my project specific error type:
import validateUser from 'external-module'
// assuming validateUser(user: any): Result<boolean, ValidationError>

// Using the current api

ok<unknown, Error>(myUser)
  .andThen(user =>
    // I need to convert ValidationError to Error type using mapErr
    validateUser(user).mapErr(
      (e: ValidationError) => new Error('ValidationError: ' + e.reason),
    ),
  )
  .map(user => user.name)
  .match(
    username => {
      console.log('Created user ' + username)
    },
    e => {
      if (e.message.startsWith('ValidationError')) {
        // Ok, send back validation errors to the user
        res.send({ error: e.message })
      }
      else{
        // Bad, log this error
        logger.error("Error in the user creation process")
        // Return a generic error to the user, we don't want them to see system errors
        res.send({ error: "System error, please try again later."})
      }
    },
  )

// Using an api returning a union type

ok<unknown, Error>(myUser)
  .andThen(validateUser)
  .map(user => user.name)
  .match(
    username => {
      console.log('Created user ' + username)
    },
    e => {
      // e is Error | ValidationError
      if (e instanceof ValidationError) {
        // Ok, send back validation errors to the user
        res.send({ error: e.reason })
      }
      else{
        // Bad, log this error
        // e is Error
        logger.error("Error in the user creation process", e.message)
        // Return a generic error to the user, we don't want them to see system errors
        res.send({ error: "System error, please try again later."})
      }
    },
  )

@supermacro Have you had a chance to read my message above ?
It's kinda blocking for me as I'm preparing to do a big refacto of a pretty big project to use neverthrow everywhere. I don't want to have to do another big one down the line. :)

Hey @paduc,
My apologies for the late response, I haven't had much time to focus on issue grooming recently.

Yes, I could use a single error type E, add a type string literal to it like in my example above, and discriminate using the type property. But I think it is idiomatic typescript to define different types for this purpose.

I respectfully disagree. I personally am a big advocate for using discriminated unions in situations such as this one.
I think there is, however, some room for improvement because of the boilerplate currently required to "align" distinct types with each other.
Example:
const getUserFromDb = (userId: number): Promise<Result<User, DbError>> => { ... }
const validateUser = (user: User): Result<never, ValidationError> => { ... }

type RouteError = { type: 'db_error'; error: DbError } | { type: 'validation_error'; error: ValidationError }

const getValidUser = async (userId: number): Promise<Result<User, RouteError>> => {
  const result = await getUserFromDb(userId)

  return result
    .mapErr(e => ({ type: 'db_error', error: e }))
    .andThen(user =>
      validateUser(user).mapErr(e => ({ type: 'validation_error', error: e }))
    )
}

Is it annoying? Yes. Is it unusual that a statically typed language requires this sort of type-gymnastics? No (at least with my experience with Haskell, Elm, and Rust to a lesser extent).
I would be open to having a utility function in neverthrow that generalizes the creation of a {type : 'string_literal'; value: E} for a given E ... if it is even possible to do given the nature of string literal types in typescript.

I see this as a benefit and can't see the cost.

Typescript does not merge duplicate types. i.e. given E | E, the compiler is not smart enough to merge the duplicate types into one.
Because the compiler isn't smart enough to merge duplicate types, I can already foresee how a type error that tells users that a value must be { name: string } | { name: string } | { name: string } is going to be harmful for users. Now imagine that instead of a type { name: string } your have something a lot more complex like in a real-life scenario.
Secondly, I have some reservation around changing to this new API because it deviates from the implied specification of the Either / Result type that languages like Rust, Scala, and Elm define. I don't know of a single Either / Result whose andThen equivalent allows for varying error types. This to me signals that there's a good reason not to do this (although I do not know right now what that reason is). I'm sure there is a Functor law, or something similar, that this might violate and could lead to some subtle but serious problems for users.

Furthermore, if my chain includes a call to an external module that returns a Result with a specific error type, I have no control over that error type, so I can't make it implement my generic E type. I have to deal with it and this results in code that could look better.

Your code example confused me a bit because the second part of the example has access to the ValidationError class. If you do have access to the ValidationError class, then in your first part, where you have to call mapErr you can create a discriminated union like I demonstrate above in my own example.
But let's suppose that this external-module package doesn't expose the ValidationError. I would recommend that you implement a wrapper for the validateUser function such that you implement a error type that is suitable / appropriate for your situation / application.
const validateUser = (user: unknown): Result<boolean, MyOwnValidationError> =>
  externalModule.validateUser(user).mapErr(intoMyOwnValiationError)

It's almost always likely that Results returned by external modules don't adhere to your applications conventions anyways, so explicitly mapping over the error values in order to have a consistent error convention in your system is beneficial.

Everything I've mentioned here is my opinion. I don't want to come off as arrogant, and I am still open to discuss improvements / solutions. But I also want to ensure that there is good merit and justification to any features that are implemented for this library. So I will always be respectfully critical of proposals to make sure they objectively make sense!

Typescript does not merge duplicate types. i.e. given E | E, the compiler is not smart enough to merge the duplicate types into one.

Yes, it's not smart enough to merge type shapes like {name: string} but it's smart enough to merge unions of declared types. So if you have defined an error type E and all your chained methods return a  Result<*,E>, then the resulting union type would be E (and not E | E | E | ...).
My point is that people who want to use a single error type would see no change in having andThen with the following signature:
andThen<U>(_f: (t: T) => Result<U, F>): Result<U, E | F>

My goal is to be able to know exactly which error types can come up at the end of my chain, just be looking at the type of the Result. If I use an app-wide discriminated union type E, then I only know that my error is of type E. Maybe it can only be 2 variants of E maybe it can be any other number. I don't want to handle error type cases which cannot happen. I don't want to miss any error type case that can happen.
With the signature above, the compiler gives me a precise list of all error types at the end of my chain.
If one of the chained methods returns a new type of error, it's error type signature will change and the compiler will warn me that I need to handle this new case at the end of my chain.

Secondly, I have some reservation around changing to this new API because it deviates from the implied specification of the Either / Result type that languages like Rust, Scala, and Elm define. I don't know of a single Either / Result whose andThen equivalent allows for varying error types. This to me signals that there's a good reason not to do this (although I do not know right now what that reason is). I'm sure there is a Functor law, or something similar, that this might violate and could lead to some subtle but serious problems for users.

I took personal interest in neverthrow because of it's pragmatic approach. I tried many other Either / Result type packages but they all compromise on usability for the sake of being "pure" or whatever. Maybe they're right, I'm not sure.
What I believe is that if there happens to be subtle but serious problems to an implementation, they can be dealt with when they occur.
I don't want to impose my opinions either and would love to avoid the pitfalls my intuitions might lead me into. But I just don't see them. I guess I'll try refactoring my app using a fork with andThen returning unions of error types and see where that takes me.

but it's smart enough to merge unions of declared types. So if you have defined an error type E and all your chained methods return a Result<*,E>, then the resulting union type would be E (and not E | E | E | ...).

I don't quite follow. I would need to see a code example to see how this would work in practice.

Going back to one of your past comments:

Yes, I could use a single error type E, add a type string literal to it like in my example above, and discriminate using the type property.

I still stand by this approach. Which is what I use when merging various error types in a long chain or results.

Hi there,
I've been following this discussion for quite a while now from the sidelines and I do understand @supermacro 's reservations (to some extend)

Going back to one of your past comments:

Yes, I could use a single error type E, add a type string literal to it like in my example above, and discriminate using the type property.

I still stand by this approach. Which is what I use when merging various error types in a long chain or results

This is definetely an idioamtic approach in most circumstances, and you are right that andThen or bind or however the equivalent is called in other languages doesn't allow a different error type to be returned (AFAIK).
BUT this approach comes with a cost (and is also sometimes criticized in the respective communities): composability on the macro level can only be achieved by sacrifizing type expressiveness at the mirco level.
@supermacro has demonstrated this in one of his previous examples pretty well. Compare:
(modified from the OP)
type E1 = number
type E2 = string
interface E3 {
  errorCode: number
  message: string
}

type MyUnion = E1 | E2 | E3

type F1 = (sth: unknown) => Result<string, E1>;
type F2 = (sth2: string) => Result<string, E2>;
type F3 = (sth3: string) => Result<string, E3>;

//...Implementation

const result: Result<string, MyUnion> = f1('maybe').andThen(f2).andThen(f3)

with the proposed solution:
type F1 = (sth: unknown) => Result<string, MyUnion>;
type F2 = (sth2: string) => Result<string, MyUnion>;
type F3 = (sth3: string) => Result<string, MyUnion>;

//...Implementation

const result: Result<string, MyUnion> = f1('maybe').andThen(f2).andThen(f3)

I left out the dicrimininator but I think my argument still stands:
In order to compose arbitrary functions returning Result types, one has to alter or overload their signatures. Thus reducing the expressiveness of the signature.
Additionally it is not possible to centrally handle Result types at the moment, because the error types of a given pipeline never line up.
I was drawn to this GREAT library, because it allows me to be expressive with error paths. At the same time, the possibility to easily compose different functions without them having to know the context in which they are composed would be a really BIG WIN. Especially, since the propsed changes by @paduc are minimal and non-breaking, I would be in favour of changing the interface.

For you information, I've been using a workaround to be able to compose Result and ResultAsync with different error types.
I've been using it in production for several months and it works flawlessly for me. The solution is pretty simple.
I created a neverthrow.d.ts file in my repo and added it to the typeRoots section of my tsconfig.json.
neverthrow.d.ts contains the same type declarations you would find in node_modules/neverthrow/dist/index.d.ts with these simple changes:
class Ok<T, E> {
    // ...
    andThen<U, F>(f: (t: T) => Result<U, F>): Result<U, E | F>
    asyncAndThen<U, F>(f: (t: T) => ResultAsync<U, F>): ResultAsync<U, E | F>
    // ...
  }
  class Err<T, E> {
    // ...
    andThen<U, F>(f: (t: T) => Result<U, F>): Result<U, E | F>
    asyncAndThen<U, F>(f: (t: T) => ResultAsync<U, F>): ResultAsync<U, E | F>
    // ...
  }

  class ResultAsync<T, E> implements PromiseLike<Result<T, E>> {
    // ...
    andThen<U, F>(f: (t: T) => Result<U, F> | ResultAsync<U, F>): ResultAsync<U, E | F>
    // ...
  }

This allows me to achieve the following behaviour:
const resA = ok<null, E1>(null);
const resB = ok<null, E2>(null);

const res = resA.andThen(() => resB);
// res is Result<null, E1 | E2>
// this would result in a compile error normally

It's a "hack" but it works for me and might for others.

Hey @paduc, I had an idea recently where neverthrow could automatically generate this info for a user.
It would be a little cli tool that would update the types using this snippet you made above.
That way, users can decide for themselves which types for andThen they want.
What do you think?

Hi @supermacro !
I would definitely welcome a cleaner alternative to my "hack" (it's a one-time thing though).
A cli-tool seems a fair bit of work. I have seen npm packages that provide "alternate" modes for their libs and maybe neverthrow could do the same.
Something like:
import { ResultAsync } from 'neverthrow/unionErrors`

This in an interesting discussion, we are facing the same issue.
We would like to union our errors rather than wrapping them.
type DbError  = { type: 'DbErrorX', type: 'DbErrorY' }
findByUserId(userId: string): ResultAsync<User, DbError>

type ServiceError = DbError | ( { type: 'ServiceErrorX', type: 'ServiceErrorY' })
findUserAndDoSomethingUseful(userId: string): ResultAsync<User, ServiceError> {
    return findByUserId(userId)
        .andThen(user => err({ type: 'ServiceErrorX' }))
}

This approach saves us having to wrap DbError's as ServiceError's but it means the we have to add lots of .mapErr(e => e as ServiceError) calls or specify return types to stop the compiler moaning.`

This in an interesting discussion, we are facing the same issue.
We would like to union our errors rather than wrapping them.
type DbError  = { type: 'DbErrorX', type: 'DbErrorY' }
findByUserId(userId: string): ResultAsync<User, DbError>

type ServiceError = DbError | ( { type: 'ServiceErrorX', type: 'ServiceErrorY' })
findUserAndDoSomethingUseful(userId: string): ResultAsync<User, ServiceError> {
    return findByUserId(userId)
        .andThen(user => err({ type: 'ServiceErrorX' }))
}

This approach saves us having to wrap DbError's as ServiceError's but it means the we have to add lots of .mapErr(e => e as ServiceError) calls or specify return types to stop the compiler moaning.`

@toby-wollit Have you tried my "hack" above ? If yes, does it break anything else in your projet ?

@toby-wollit Have you tried my "hack" above ? If yes, does it break anything else in your projet ?

@paduc is does work yes but I don't like the idea of keeping the type definitions in sync!
It would be great if we could find a solution to this issue that satisfied everyone :)

@paduc is does work yes but I don't like the idea of keeping the type definitions in sync!
It would be great if we could find a solution to this issue that satisfied everyone :)

Alright folks .. After 8 months of thinking through this, I think I am finally persuaded to go down the route of joining types.
I'm planning on doing some work soonish on this. Maybe I'll get around to it this week.
I realized that because Rust and Haskell and basically all the other well-known languages that have a Result don't have subtyping. So it's literally impossible to do T | A .. it's just not part of those languages. But in typescript, this is allowed!

Alright folks .. After 8 months of thinking through this, I think I am finally persuaded to go down the route of joining types.
I'm planning on doing some work soonish on this. Maybe I'll get around to it this week.
I realized that because Rust and Haskell and basically all the other well-known languages that have a Result don't have subtyping. So it's literally impossible to do T | A .. it's just not part of those languages. But in typescript, this is allowed!

Hurray ! Tell me if I can be of any help !

Hurray ! Tell me if I can be of any help !

Alrighty, I have published a new version behind a beta tag for now.
> npm install neverthrow@beta

Release notes:
https://github.com/supermacro/neverthrow/releases/tag/v4.1.0-beta.0

I am closing this issue, but feel free to open a new issue regarding this topic!

Alrighty, I have published a new version behind a beta tag for now.
> npm install neverthrow@beta

Release notes:
https://github.com/supermacro/neverthrow/releases/tag/v4.1.0-beta.0

I am closing this issue, but feel free to open a new issue regarding this topic!


chapter 28 can't get all list items

I got this error from the console chrome-extension://boadgeojelhgndaghljhdicfkmllpafd/cast_sender.js net::ERR_FAILED
But am only getting the first selected video

This is apart of how the youtube iframe works, all youtube embeds generate this error.  The player is trying to access some specific chrome extension to see if its available/installed.


7.3-rc-1: Incubating test suite changes breaks existing build

Updating from 7.2, the build fails immediately when setting the useTestNG() on the test task.
Expected Behavior
Continues to work, perhaps with a warning and migration steps if backwards incompatible changes are planned.
test {
  useTestNG()
}

Current Behavior
FAILURE: Build failed with an exception.

* Where:
Script '/Users/ben/projects/caffeine/caffeine/testing.gradle' line: 5
...
Caused by: java.lang.IllegalStateException: The value for task ':caffeine:test' property 'testFrameworkProperty' is final and cannot be changed any further.
        at org.gradle.api.internal.provider.AbstractProperty$FinalizedValue.beforeMutate(AbstractProperty.java:489)
        at org.gradle.api.internal.provider.AbstractProperty.assertCanMutate(AbstractProperty.java:263)
        at org.gradle.api.internal.provider.AbstractProperty.setSupplier(AbstractProperty.java:212)
        at org.gradle.api.internal.provider.DefaultProperty.set(DefaultProperty.java:71)
        at org.gradle.api.tasks.testing.Test.useTestFramework(Test.java:979)
        at org.gradle.api.tasks.testing.Test.useTestNG(Test.java:1081)
        at org.gradle.api.tasks.testing.Test.useTestNG(Test.java:1058)

Steps to Reproduce
Upgrade the gradle/wrapper/gradle-wrapper.properties to use 7.3-rc-1 on the caffeine project.
Context
The build specifies its universal quality configuration in codeQuality.gradle with subproject-specific customization as needed. The most complex customization is in testing.gradle to break up testing into multiple tasks (too large or framework options). Moving these to the incubating test suites feature would be fine, but this should continue to work inho.

After investigating, this is actually not a regression, but rather a usage which was always disallowed, but happened to "work" (sort of) in earlier versions.  The work to implement test suites surfaced this potential problem, and Gradle was changed to "fail fast" when it occurred, rather than produce unexpected behavior.
Here's what's happening.
If you look at the Test task's options {} block here: https://docs.gradle.org/7.2/dsl/org.gradle.api.tasks.testing.Test.html#N2F6B3 you can see it says that you shouldn't call useTestNG() on a test task after setting the options.  This is because the options are potentially different per testing framework used, so setting options "locks in" the choice of framework.  In versions <= 7.2, calling one of the useXYZFramework() methods would silently discard any previously set options.
In this build, the problem occurs because the codeQuality.gradle file, which is the first configuration block to be applied to the test task in the caffiene project, sets options on that task like this:
options {
    jvmArgs '-XX:SoftRefLRUPolicyMSPerMB=0'
  }

and the testing.gradle file afterwards configures the test task like so:
test {
  useTestNG()
  exclude 'com/github/benmanes/caffeine/cache/**'
}

At this point Gradle 7.3 confirms that the testing framework hasn't already been locked in, either by setting it explicitly or by configuring options - but it unfortunately has, so now the build fails.
Previously, as that jvmArg would not have been honored anyway (since options are reset upon selecting a testFramework), it can be safely deleted without changing the build's behavior - or moved to the options configuration further down in the testing.gradle file:
tasks.withType(Test) {
  if (options instanceof TestNGOptions) {
  ...

which will run after the testing framework is set.

FYI @big-guy

Thank you @tresat.
It looks like this was a typo as options does not have a jvmArgs and that is on the test task itself, so this worked by setting the task property and the options was safe to throw away. Simply removing the options block is a good fix. The change to a hard error is great to avoid surprises.


On the blog section, "Read" button goes out of the block

Is this a result of a recent design change? if not, I would like to help.

Go for it!

can you plzz assigned this issue to me i resolved in very few amount of time

Can you assign me this problem under gssoc'24

Can you assign me this problem under gssoc'24

The problem is solved thanks

can you plzz assigned this issue to me i resolved in very few amount of time

The problem is solved thanks


[bug] Settings merged instead of replaced

The issue was initially filed against, Pulp. But I believe this is a dynaconf problem.
https://pulp.plan.io/issues/6244

Having a settings.py with
BASE = {"CLASSES": ["class1", "class2"]}

User should be able to override the whole "CLASSES" key by doing:
export DYNACONF_BASE__CLASSES="['other1', 'other2']"

ending with BASE = {"CLASSES": ["other1", "other2"]}
User should be able to merge values by using @merge mark
export DYNACONF_BASE__CLASSES="@merge ['other1', 'other2']"

ending with BASE = {"CLASSES": ["class1", "class2, "other1", "other2"]}
BUT looks like dynaconf is defaulting to @merge behavior.

PR #315 sent
@dkliban @daviddavis I figured out it was not a bug, but the intended behavior.
Although it was a bad design decision so I reverted and now it is going to default o reasign and merge only when variable explicitly starts with @merge
This is a breaking change so I will release it as part of 3.0.0 by the end of the month.
Do you need it earlier?

@rochacbruno thanks for the update. That all makes sense. I'll check with Katello on when they need it and get back to you.


Typos and fixes to sensors.js in chapter7

In the source code for chapter 7, there are some typos to remove and fixes to be made:

Line 56 should be labelled #E instead of #D
Line 57 should be removed entirely

Fixed, thanks for that!


Formatting updates

Changed empty datasets to a crosshatch
Changes line graph to a bar chart
General formatting updates

Let's test it.


Large amount of time spent on determining datashape

When running aggregation on a large dataset a fairly large amount of time is spent in the dshape_from_dask function (somewhere in the region of 500-600ms). This is a major overhead when running the aggregation many times in a row and even dominates the actual aggregation time in many cases. Here is the output of a profiler running canvas.points on the census dataset:
         77200 function calls (75103 primitive calls) in 1.021 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    1.021    1.021 {built-in method builtins.exec}
        1    0.000    0.000    1.021    1.021 <string>:2(<module>)
        1    0.000    0.000    1.021    1.021 spaces.py:1093(__getitem__)
        1    0.000    0.000    1.020    1.020 spaces.py:890(_execute_callback)
        1    0.000    0.000    1.020    1.020 spaces.py:540(__call__)
        1    0.000    0.000    1.020    1.020 __init__.py:430(dynamic_operation)
        1    0.000    0.000    1.020    1.020 __init__.py:415(_process)
        1    0.000    0.000    1.020    1.020 operation.py:137(process_element)
      2/1    0.000    0.000    1.020    1.020 operation.py:113(_apply)
        1    0.000    0.000    1.019    1.019 datashader.py:782(_process)
     18/7    0.000    0.000    1.018    0.145 dimension.py:712(map)
        1    0.000    0.000    1.017    1.017 operation.py:146(__call__)
        1    0.000    0.000    0.998    0.998 datashader.py:416(_process)
        1    0.000    0.000    0.964    0.964 core.py:144(points)
        1    0.000    0.000    0.964    0.964 core.py:492(bypixel)
        5    0.000    0.000    0.897    0.179 local.py:405(get_async)
        3    0.000    0.000    0.897    0.299 threaded.py:33(get)
       24    0.000    0.000    0.894    0.037 local.py:150(queue_get)
       24    0.000    0.000    0.894    0.037 queue.py:147(get)
       12    0.000    0.000    0.893    0.074 threading.py:263(wait)
       96    0.893    0.009    0.893    0.009 {method 'acquire' of '_thread.lock' objects}
        1    0.066    0.066    0.491    0.491 utils.py:368(dshape_from_dask) <-----
      2/1    0.000    0.000    0.472    0.472 utils.py:51(__call__)
        1    0.000    0.000    0.471    0.471 dask.py:20(dask_pipeline)

You can see that almost half the time is spent in the dshape_from_dask function, and as you aggregate a smaller region this time dominates even more.
It would be great if this could be sped up in general but it might be sufficient to allow passing in the datashape in cases where you are doing a lot of aggregation on the same datasource (e.g. when generating a tileset) and want to avoid this 0.5 second penalty each time.

Cool!  It would be great to have a PR allowing such caching.
I'm having trouble seeing why dshape_from_dask would be an expensive call:
def dshape_from_pandas_helper(col):
    """Return an object from datashape.coretypes given a column from a pandas
    dataframe.
    """
    ...

def dshape_from_pandas(df):
    return len(df) * datashape.Record([(k, dshape_from_pandas_helper(df[k]))
                                       for k in df.columns])

def dshape_from_dask(df):
    return datashape.var * dshape_from_pandas(df.head()).measure

Maybe X * datashape.Record is making X copies of something?  It doesn't look like it from the repr, but I'm not sure:
>>> 3*datashape.Record([[int,int]])
dshape("3 * {"<class 'int'>": <class 'int'>}")

@jcrist suggests that you might change dshape_from dask in this way:
def dshape_from_dask(df):
    """Return a datashape.DataShape object given a dask dataframe."""
#    return datashape.var * dshape_from_pandas(df.head()).measure
    return datashape.var * dshape_from_pandas(df._meta).measure

If you are working out of core, this will definitely be an improvement, because it replaces something that needs to load the data into memory (df.head()) with something that doesn't (df._meta, which wasn't available when datashader was first written).  I think for the census data you're working with data that's been .persist()ed, so I wouldn't have thought this would add up to any significant time, but even then it's worth a try.  Can you see if that affects it?

Okay I've now done some more investigation and it seems to me this large bottleneck is down to this "optimization":
# Avoid datashape.Categorical instantiation bottleneck
# by only retaining the necessary columns:
# https://github.com/bokeh/datashader/issues/396
if categorical_in_dtypes(source.dtypes.values):
    # Preserve column ordering without duplicates
    cols_to_keep = OrderedDict({col: False for col in source.columns})
    cols_to_keep[glyph.x] = True
    cols_to_keep[glyph.y] = True
    if hasattr(glyph, 'z'):
        cols_to_keep[glyph.z] = True
    if hasattr(agg, 'values'):
        for subagg in agg.values:
            if subagg.column is not None:
                cols_to_keep[subagg.column] = True
    elif agg.column is not None:
        cols_to_keep[agg.column] = True
    src = source[[col for col, keepit in cols_to_keep.items() if keepit]]
else:
    src = source

Dropping the unused categorical types here results in significant overhead which accounts for the 500ms, because computing the datashape is indeed fast. Making the suggested change (i.e. dshape_from_pandas(df._meta).measure), does seem to avoid this overhead entirely however so I'll make a PR with that change shortly.

Using dshape_from_pandas(df._meta).measure) makes the first aggregation in census.ipynb almost 3X faster for me, which is very nice.  But the categorical case create_image(*USA) fails then with
KeyError: 'UNKNOWN_CATEGORIES'; perhaps _meta doesn't include the actual categories?

Oh, I see Philipp is also reporting that in #634.  @jcrist said he can suggest something.

Do we have any specific cases where the optimization above actually saves time? In every instance I have tried it's at least partially responsible for the slowdown.

I see an example in https://github.com/bokeh/datashader/issues/396 now, will see if I can reproduce any speedup.

Right, I was going to suggest replicating the ones in #396.  But I'm a bit confused -- can we perhaps bypass all these issues by just making a new dataframe that has only the columns we are actually using, so that we aren't checking any others?  I thought that making a new such dataframe is very cheap, so why not just always do that?

can we perhaps bypass all these issues by just making a new dataframe that has only the columns we are actually using, so that we aren't checking any others?

That's pretty much what the optimization is doing and it's exactly what's causing the slowdown in the datashape discovery. Not sure why though.

Sorry -- just edited my message above to clarify -- I mean to suggest avoiding doing the test at all, always doing what's inside the "if".

Also just edited mine, but to summarize the bit inside the if is exactly what's causing the slowdown, so always doing it would be bad, unless we can figure out why datatype discovery slows down so much when columns are dropped.

Just to be very clear, this is the code:
    if categorical_in_dtypes(source.dtypes.values):
        # Preserve column ordering without duplicates
        cols_to_keep = OrderedDict({col: False for col in source.columns})
        cols_to_keep[glyph.x] = True
        cols_to_keep[glyph.y] = True
        if hasattr(glyph, 'z'):
            cols_to_keep[glyph.z] = True
        if hasattr(agg, 'values'):
            for subagg in agg.values:
                if subagg.column is not None:
                    cols_to_keep[subagg.column] = True
        elif agg.column is not None:
            cols_to_keep[agg.column] = True
        src = source[[col for col, keepit in cols_to_keep.items() if keepit]]
    else:
        src = source

I tried replacing the first line with "if True" and got a 2x speedup for both the single-aggregate and the categorical aggregate in census.ipynb.  That suggests that when there are categoricals, half the time is spent just detecting them, right?
The question is then what happens when there are no categoricals and the else would have been activated.  At least on the one example (clifford_attractor) that I had open, the time in that case also went down, by 20% or so, presumably the cost of the if statement.  So can we not simply remove if categorical_in_dtypes(source.dtypes.values): and else: src=source?

I tried replacing the first line with "if True" and got a 2x speedup for both the single-aggregate and the categorical aggregate in census.ipynb. That suggests that when there are categoricals, half the time is spent just detecting them, right?

I observed exactly the opposite pattern, if I change it to if False I get a 50% speedup, at least in the categorical case.

How is that the opposite pattern?  Seems like the same thing, in that I thought "categorical_in_dtypes(source.dtypes.values)" is the expensive bit, and both if True and if False avoid that bit. if True also ensures that we only deal with categoricals we actually, use, so  if we can always use (effectively) if True it seems we'll avoid the issue that #396 was addressing as well as the one you are raising.

Because the profiler tells me it's dshape_from_dask that's faster categorical_in_dtypes is very cheap whatever I do.

When I use if True it consistently takes 1.2 seconds to aggregate, with if False I consistently get 0.55 seconds.

Now I'm hopelessly confused; dshape_from_dask isn't even involved in that if statement; it's called regardless of any branches in that.

Now I'm hopelessly confused; dshape_from_dask isn't even involved in that if statement; it's called regardless of any branches in that.

Yes, but that if branch creates a new dask dataframe with some columns dropped, which seems to cause some slowdown in the datashape detection.

Definitely confused.  I thought you were saying that the optimization was the issue, and so I tried both True and False and the original version of the optimization, with not much clear effect:
                if False:               if True:            if categorical_in_dtypes:
census-non-cat: 1.10  1.16  0.89 0.90   1.29  1.18  1.33    1.36 1.19 1.12
census-cat:     1.21  1.22  1.30 1.43   1.83  1.61  1.86    1.55 1.80 1.68

I'm on  battery power, which isn't great for doing benchmarking, so maybe my results differ from yours.  But at least in this, all of these are in the same ballpark for the first line (the monochrome non-categorical aggregation).  So I'm not seeing much effect from removing this optimization, and moreover none of it seems to have anything to do with dshape_from_dask.

Here are my results (in ms):
                 if True:      if False:     if categorical_in_dtypes:
census-non-cat:  831 840 840   404 413 450   852 833 872
census-cat:      947 968 966   504 471 485   946 983 947

Perhaps we should compare dask, pandas, numba and datashape versions:
import pandas as pd
import dask
import numba
import datashape
> print(numba.__version__)
0.37.0dev1+123.gd3f0f8a
> print(dask.__version__)
0.18.0
> print(pd.__version__)
0.23.1
> print(datashape.__version__)
0.5.4

And here's the output of %%prun:
if True:

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.055    0.055    0.636    0.636 utils.py:368(dshape_from_dask)

if False:

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.002    0.002 utils.py:368(dshape_from_dask)

import pandas as pd
import dask
import numba
import datashape
> print(numba.__version__)
0.39.0
> print(dask.__version__)
0.18.2
> print(pd.__version__)
0.22.0
> print(datashape.__version__)
0.5.4

All of this is a bit crazy; the only thing we get out of dshape_from_dask is {easting: float32, northing: float32} (the result of dshape.measure).  Taking half a second to figure that out seems scandalous.

I've updated my pandas version to 0.23.4 now.

Taking half a second to figure that out seems scandalous.

Remember dask defers execution, I'm almost certain it's  the dropping of columns that's causing this when df.head() is called.

Ok, thanks. Repurpose #634, I guess.

Once you do that, is it still helpful to cache the shape across multiple calls?

Once you do that, is it still helpful to cache the shape across multiple calls?

Not really, no.

Great; that makes it simpler.


Rancher 2.6: Wait-Checkin, http: request canceled (Client.Timeout exceeded while awaiting headers)

Rancher Server Setup

Rancher version: docker rancher/rancher (2.6)

Information about the Cluster

Kubernetes version: v1.22.2
Type -> Imported
1 master / main bare-metal
2 workers bare-metal
1 virtual machine for rancher

Describe the bug
After importing custom k8s cluster to rancher and applying yml, the cluster status goes to "Active" even tho the conditions or not fully met.

Related Resources

If we inspect the rancher with kubectl, the service with ip <IP_ADDRESS> is available and a curl command returns a response on port 443.

778bd7e64174:/var/lib/rancher # curl --insecure https://<IP_ADDRESS>

{"type":"collection","links":{"self":"https://<IP_ADDRESS>/"},"actions":{},"pagination":{"limit":1000,"total":4},"sort":
(removed the full response of the curl command)

To Reproduce
Install a kubernetes cluster on premise (here debain 11) with one main and two workers, create a virtual machine (here debian 10 because rancher 2.6 fails on debian 11) and install rancher through docker command.
Import an existing cluster, apply kubectl command given by rancher. Wait for propagation on your k8s cluster. When status is active go to "related resources" tab.
NB: k8s cluster is hosted by different providers (bare-metal) and do not share the same private network. They are all accessible on public IP address.
Result
The cluster is not available in rancher till the step is not validated. The on premise k8s cluster is running without problem. Issue seems to be on rancher side.
 I can add more informations if needed.
Thank you,

docker exec to rancher container
728a8074350f:/var/lib/rancher # kubectl get all --all-namespaces -o wide
NAMESPACE             NAME                               READY   STATUS    RESTARTS   AGE   IP           NODE         NOMINATED NODE   READINESS GATES
cattle-fleet-system   fleet-agent-b94869475-mhcnq        1/1     Running   2          26h   <IP_ADDRESS>   local-node   <none>           <none>
cattle-fleet-system   fleet-controller-974d9cc9f-tz4x2   1/1     Running   2          26h   <IP_ADDRESS>   local-node   <none>           <none>
cattle-fleet-system   gitjob-5778966b7c-cvp9n            1/1     Running   2          26h   <IP_ADDRESS>   local-node   <none>           <none>
cattle-system         rancher-webhook-7f84b74ddb-j8gkq   1/1     Running   2          26h   <IP_ADDRESS>   local-node   <none>           <none>
kube-system           coredns-7448499f4d-zlsj5           1/1     Running   2          26h   <IP_ADDRESS>   local-node   <none>           <none>

NAMESPACE             NAME                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE   SELECTOR
cattle-fleet-system   service/gitjob            ClusterIP   <IP_ADDRESS>    <none>        80/TCP                   26h   app=gitjob
cattle-system         service/rancher           ClusterIP   <IP_ADDRESS>   <none>        443/TCP                  26h   <none>
cattle-system         service/rancher-webhook   ClusterIP   <IP_ADDRESS>   <none>        443/TCP                  26h   app=rancher-webhook
cattle-system         service/webhook-service   ClusterIP   <IP_ADDRESS>      <none>        443/TCP                  26h   app=rancher-webhook
default               service/kubernetes        ClusterIP   <IP_ADDRESS>       <none>        443/TCP                  26h   <none>
kube-system           service/kube-dns          ClusterIP   <IP_ADDRESS>      <none>        53/UDP,53/TCP,9153/TCP   26h   k8s-app=kube-dns

logs of fleet-controller-974d9cc9f-tz4x2
time="2021-09-20T20:39:32Z" level=error msg="error syncing 'fleet-default/k8s-XXX-XXX': handler import-cluster: Get \"https://<IP_ADDRESS>/k8s/clusters/c-m-965cj2jd/version?timeout=15s\": net/http: request canceled (Client.Timeout exceeded while awaiting headers), requeuing"

logs of cattle-agent on k8s controller node
root@k8s-master:~# kubectl logs cattle-cluster-agent-558954f689-dt47x -n cattle-system
INFO: Environment: CATTLE_ADDRESS=<IP_ADDRESS> CATTLE_CA_CHECKSUM=f5c72e049524fe48751f6dc150b25aa55c5ba65f5ef4b624556560a318f4aa8d CATTLE_CLUSTER=true CATTLE_CLUSTER_AGENT_PORT=tcp://<IP_ADDRESS>:80 CATTLE_CLUSTER_AGENT_PORT_443_TCP=tcp://<IP_ADDRESS>:443 CATTLE_CLUSTER_AGENT_PORT_443_TCP_ADDR=<IP_ADDRESS> CATTLE_CLUSTER_AGENT_PORT_443_TCP_PORT=443 CATTLE_CLUSTER_AGENT_PORT_443_TCP_PROTO=tcp CATTLE_CLUSTER_AGENT_PORT_80_TCP=tcp://<IP_ADDRESS>:80 CATTLE_CLUSTER_AGENT_PORT_80_TCP_ADDR=<IP_ADDRESS> CATTLE_CLUSTER_AGENT_PORT_80_TCP_PORT=80 CATTLE_CLUSTER_AGENT_PORT_80_TCP_PROTO=tcp CATTLE_CLUSTER_AGENT_SERVICE_HOST=<IP_ADDRESS> CATTLE_CLUSTER_AGENT_SERVICE_PORT=80 CATTLE_CLUSTER_AGENT_SERVICE_PORT_HTTP=80 CATTLE_CLUSTER_AGENT_SERVICE_PORT_HTTPS_INTERNAL=443 CATTLE_INTERNAL_ADDRESS= CATTLE_IS_RKE=false CATTLE_K8S_MANAGED=true CATTLE_NODE_NAME=cattle-cluster-agent-558954f689-dt47x CATTLE_SERVER=https://RANCHER_PUBLIC_IP
INFO: Using resolv.conf: nameserver <IP_ADDRESS> search cattle-system.svc.cluster.local svc.cluster.local cluster.local options ndots:5
INFO: https://RANCHER_PUBLIC_IP/ping is accessible
INFO: Value from https://RANCHER_PUBLIC_IP/v3/settings/cacerts is an x509 certificate
time="2021-09-20T15:33:20Z" level=info msg="Listening on /tmp/log.sock"
time="2021-09-20T15:33:20Z" level=info msg="Rancher agent version v2.6.0 is starting"
time="2021-09-20T15:33:20Z" level=info msg="Connecting to wss://RANCHER_PUBLIC_IP/v3/connect/register with token starting with 5qbkmtwljvjlmzzvsszt5qvfr2h"
time="2021-09-20T15:33:20Z" level=info msg="Connecting to proxy" url="wss://RANCHER_PUBLIC_IP/v3/connect/register"

Please advice, is it me doing something wrong? Do I need to rtfm again?
Lost here... for me the cattle-controler should have no problem connecting to the service/rancher.
Cheers,

@CAberry It seems rancher doesn't work correctly with k8s version 1.22+. I had similar problem, after installing k8s 1.21.5 rancher worked as expected.

@Gfalconia Thank you for the hint ! It definitely works with 1.21.5 ! Thumbs up to you.
I'm not closing since this issue is still relevant for k8s v1.22+

Same here...
Sometimes it helps to check the support matrix first... :)
https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-6-2/


Possibility to check field with a targeted rule at change of target without having validated the field itself yet

Is your feature request related to a problem? Please describe.
I have a form with 2 fields. Field1 has a rules with a target, 'targetRule', on Field2. Without having touched Field1, I edit Field2 in such a way that targetRule on Field1 is now invalid.
At this point, Field1 will have no errors.
Describe the solution you'd like
I would like to have an option so that Field1 shows errors at that point.
Or maybe there already is a solution to this?

I believe this was the behavior before 2.2 was released, I changed that because I got a lot of feedback on the UX of that behavior was being too aggressive as the user hadn't yet the time to interact with the other field.
I do not think this will be reversed anytime soon, as either way you need to validate before submitting which would solve this issue.
You could use 2.1.x versions of vee-validate if they have what you need.

@logaretm
Hm, alright, I understand.
I'm using 2.2 features too though so that's sadly not a possibility.
Wouldn't it be interesting to make it a option? While keeping the same default behavior. Maybe a rule config like hasTarget. validateOnTargetChange.


Update Get-MicrosoftAzureDatacenterIPRange.ps1

Added support for multiple regions

Hi Luis,
Thanks for the pull request, unfortunately I am not going to merge it.
The changes you have proposed will break compliance with most community guidelines and the PowerShell teams guidance. You are introducing a plural, chaning $AzureRegion to $AzureRegions.
Secondly, support for multiple regions is already included via the pipeline.
Thirdly, this would be a breaking change to users of previous versions of the module, such as James Bannan's routing automation.
We could modify the function to support the pipeline and the array, by:

Switching [String]$AzureRegion to ```[String[]]$AzureRegion
Introducing a for-loop into process{} block to handle the situation if an array is passed.

I would be happy to accept these changes if we can ensure that a) tests pass and b) we don't break things for existing users (mostly via testing that we don't).

Hi Luis,
Just wanted to update you on this.
In the coming up 0.8 release, you will be able to specify an array for -AzureRegion. Hope that helps.


[client] Navigating to an enemy Realm

If you navigate to an enemy Realm then change back to your Realm, you do not navigate back to your realm but stay on the enemy Realm. This means you have all the actions available, however it is not your Realm
Reproduce

Navigate to Enemy Realm
In top nav change back to your Realm

Potential Fix

When swapping in the top nav, always take back to Realm selected.

Tried to repro on local + remote but no luck, will leave open for now

with #1309 if you're on enemy realm you can't select another realm on top nav, you need to go back to worldmap for that

Indeed, closing this


change openapi version to v1_15

when I try to compile, I was stucked:
   Compiling kube v0.15.1
error[E0432]: unresolved import `k8s_openapi::api::admissionregistration::v1beta1::ValidatingWebhook`
   --> /Users/sunjianbo/.cargo/registry/src/github.com-1ecc6299db9ec823/kube-0.15.1/src/api/snowflake.rs:134:5
    |
134 | use k8s_openapi::api::admissionregistration::v1beta1::ValidatingWebhook;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `ValidatingWebhook` in `api::admissionregistration::v1beta1`

Only  v1_15 have the ValidatingWebhook

Thanks. Yeah, I've been meaning to feature gate those new types, but haven't come up with a good solution yet. This solves it for now.

This project is really good, thanks for your effort!


install, uninstall errors

When installing vivid store on 5.7.4 i get the error:
Cannot use Concrete\Package\VividStore\Src\VividStore\Orders\OrderEvent as OrderEvent because the name is already in use.
Also when uninstalling i get the error:
An exception occurred while executing 'SELECT pmID FROM VividStorePaymentMethods WHERE pmHandle=?' with params ["auth_net"]: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'admin_547.VividStorePaymentMethods' doesn't exist
(probably because the package did not install correctly)

I will create a pull request for the fix. As fixing it, i ran into another issue:
Class 'AuthorizeNetRequest' not found

Installation on <IP_ADDRESS> gives no problems


Publish a new release with iOS support

It would be great to get a new release out that contains the new iOS support.
I personally have a project I'd like to use this in that requires iOS support.

yeah, sorry, making right now!
We have missed this issue 🥲

done, please check when maven central will be reindexed


Touch events

Fix for broken TouchEvents (#23): Don't handle TouchEvents in mouseDispatch but in the new touchDispatch which dispatches a mocked MouseEvent for normalization. Tested with tests/touchevents.html.
P.S.: Kudos for your great work. Just working on a Breakout clone to get my hands dirty. Works like a charm.

How about safari (ipad) 300ms touch lag?

The patch is using TouchStart which fires immediately, good for smooth and responsive dragging of entities around, no delay. A Click is not a TouchEvent but a MouseEvent and that's why it is not affected by the TouchEvent2MouseEvent translation. It gets fired as a legacy event still and it is delayed on touch devices. In mobile projects you would either live with the convenient but delayed legacy ClickEvent or bind to MouseDown/MouseUp which now works equally fast on mouse AND touch devices.
To cut a long story short: click was and still is delayed. With the patch you get a speedy alternative and access to the native TouchEvents which was broken.