Error after deno upgrade to 1.21

Getting the following error after upgrading deno to 1.21:
TS2339 [ERROR]: Property 'serveHttp' does not exist on type 'typeof Deno'.
      const httpConn = Deno.serveHttp(conn);
                            ~~~~~~~~~
    at https://deno.land/x/nhttp@1.1.11/src/nhttp.ts:315:29

I tested in my PC it's ok fine. or maybe need --reload.
Example :
deno run -A --reload myfile.ts

After upgrading deno to 1.20.0, I use the following when executing may app:
deno run -A --reload app.js

Then get the error:
TS2339 [ERROR]: Property 'serveHttp' does not exist on type 'typeof Deno'.
      const httpConn = Deno.serveHttp(conn);
                            ~~~~~~~~~
    at https://deno.land/x/nhttp@1.1.11/src/nhttp.ts:315:29

Part of the code looks like this:
import { NHttp, Router } from 'https://deno.land/x/nhttp/mod.ts';
import staticFiles from 'https://deno.land/x/static_files/mod.ts';

const app = new NHttp();
app.use(staticFiles('public'));

 app.listen({ port: 3000, alpnProtocols: ['h2', 'http/1.1'] }, () => {
   console.log('> Running on port 3000');
 });

When I downgrade to an older version of deno, it works fine again:
deno upgrade --version 1.20.6

I upgraded deno to version 1.21.0 using:
deno upgrade --version 1.21.0

weird,, on my PC it runs normally with the latest version 1.21.0. try add --no-check flag. and please use version in deps.
import { NHttp, Router } from<EMAIL_ADDRESS>import staticFiles from<EMAIL_ADDRESS>
Run again :
deno run -A --no-check app.js

When I run it on deno 1.21.0 with the --no-check, it works, but without it, I get the same error.

FYI: I also use the xhr module in my app, and it also gives me an error, when I don't use the --no-check:
error: TS2339 [ERROR]: Property 'location' does not exist on type 'Window & typeof globalThis'.
        base = window.location.toString();
                      ~~~~~~~~
    at https://deno.land/x/xhr@0.1.0/mod.ts:499:2

Possible all module error without --no-check in your PC. this bug not related to nhttp. agree ?

I will use it now with the --no-check.  I did a clean install of Ubuntu 20.04 LTS on a VM to test it.  Still does the same.  Perhaps some problem with new version of deno.

i don't know, but on my PC with 1.21.0 it works normally even without --no-check. I will close this. thanks for creating the issue.


There should be a port of, or a paper trail to, older issues.

Recently this repo "moved" from another location, which had several dozen open issues. We should either port those issues over here (time consuming, maybe not needed) or at least leave a paper trail to them.
The link above points to the issue, so this issue issue itself could serve as a makeshift paper trail.

Bumping.

I think it would be cool if we wanted to try to port that stuff, when there's time: revisit them and decide what's still relevant and priority.

You could check for a github button that lets you fork/clone issues..  but that seems improbably.   We can just keep that repo as is...


Signomial Equality Paper scripts from Max

@1ozturkbe

this just has the code from the signomial equality paper but I think it's outdated (uses init) and I think we now have a handle on using SignomialEquality....if there's no objections I'll close this out


No data from Yandex Transpor Proxy will stop the spider

Error looks like this:
Exception (obtain data):Exception(_single_query_blocking): Yandex Transport Proxy Server signalled an error: No Yandex Masstransit API data received for method getStopInfo from URL "https://yandex.ru/maps/?masstransit[stopId]=1543169384"

Currently, spider completely stops if it encounters this kind of error. For now it is completely fine, but in future for huge cities parsing this may be an issue.

New behavior: it will retry to get data for 5 times in a row with intervals of 1 minute, and only if this will fail it will stop.


chore: updates CodeMirror dependencies

This PR updates @scalar/use-codemirror to

use the latest dependencies,
fix #4222,
add tests,
deletes the unused CodeMirror component,
switches to rollup for the build,
add a playground.

This is also an attempt to fix CI, because it’s running into issues when building @scalar/use-codemirror again and again.
EDIT: I think #4259 fixed the CI issue. I think we could still upgrade the dependencies, but feel free to reject the PR.

I tried to test if this fixed the nuxt error, unfortunately it did not. BUT it could also be a linking error.

Yeah i had to pin the version to the previous patch in org to make it work


[Security] Workflow release.yml is using vulnerable action actions/checkout

The workflow release.yml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

Changed the checkout action to v2, thank you for the report!


Make start_supervisor.sh default to showing status

Small tweak to effectively add default arg of "status" to start_supervisor.sh to avoid accidentally blocking jupyter on a supervisord prompt.

I don't have a watertight explanation for why 1b3c8a5 fixed this, and it could be that we were just seeing our first random failure on a2da18b, but I'm going to merge this and see if things keep working....


Edge features missing in preprocessed hdf5 file

Hi,
I am trying to build a graph from a pdb, but I don't seem to get the edge features in the hdf5 file...
I put the script and pdb in the attachment. It does find all edge_index I just don;t get the edge features in edge_data.
test.zip

yes it works, super, Thanks Giulia!


Update fs2-core to 2.5.4

Updates co.fs2:fs2-core from 2.5.0 to 2.5.4.
GitHub Release Notes - Changelog - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "co.fs2", artifactId = "fs2-core" } ]

labels: library-update, semver-patch

Superseded by #491.


fix: Corrected spelling error

External Contributor Checklist

🚨 Please review the guidelines for contributing to this repository.

[ ] Make sure that all commits follow the conventional commit specification for the Mender project.

The majority of our contributions are fixes, which means your commit should have
the form below:
fix: <SHORT DESCRIPTION OF FIX>

<OPTIONAL LONGER DESCRIPTION>

Changelog: <USER-FRIENDLY-CHANGE-DESCRIPTION> or <None>
Ticket: <TICKET NUMBER> or <None>

[ ] Make sure that all commits are signed with git --signoff. Also note that the signoff author must match the author of the commit.

Description
Fix for spelling
Thank you!

@mender-test-bot cherry-pick to:

hosted
3.7.x


Android twilio v3

This PR is a stepping stone to upgrade Android to Twilio Voice SDK v5.
On top of the current master (59304db) changes include the following PRs:

#108 (by @fabriziomoscon)
#130 (by @Pagebakers)

additional changes needed to complete implementation of Twilio Voice SDK v3.3.0

https://github.com/twilio/voice-quickstart-android/pull/270/files#diff-bc72a3560f9dc9b186a86db4602f5d1d
https://github.com/twilio/voice-quickstart-android/blob/master/Docs/new-features-3.0.md

experiment for Android Twilio Voice SDK v3.3.0

add hold() call
add ringing state
remove state for callInvite
handle internal CANCEL_CALL notification
add ConnectOptions
add AcceptOptions
integrate the removal of callInvite of state PENDING

TODO Android

[x] implement JS method to send ConnectOptions
[x] test Android notification for incoming calls: app running in foreground
[x] test Android notification for incoming calls: app running in background
[x] test Android notification for incoming calls: app not running
[x] test Android outgoing calls: app running in foreground
[x] test on JS app
[x] add additional feature into README
[x] consider https://github.com/hoxfon/react-native-twilio-programmable-voice/pull/142
[x] implement Android v4
[ ] implement Android v5

TODO iOS
Consult this: https://www.twilio.com/docs/voice/voip-sdk/ios/changelog#300

[x] https://github.com/twilio/voice-quickstart-ios/blob/master/Docs/migration-guide-2.x-3.x.md
[x] https://github.com/twilio/voice-quickstart-ios/blob/master/Docs/migration-guide-3.x-4.x.md
[x] include #138
[x] test iOS notification for incoming calls: app running in foreground
[x] test iOS notification for incoming calls: app running in background
[x] test iOS notification for incoming calls: app not running
[x] test iOS outgoing calls: app running in foreground
[ ] test on JS app
[x] update CHANGELOG with iOS updates
[ ] format all the code as a separate commit according to latest XCode style

Hi, thank you so much for maintaining this library. I really need this update as I am currently working on an App that depends on this library.
I don't have any native knowledge but I can help with testing / bug reproducing. thanks!

Hi, you can test the Android part by adding this branch:
yarn add https://github.com/hoxfon/react-native-twilio-programmable-voice#android-twilio-v3
I am still working on the iOS part

Hi guys, I pushed a version to review in this branch which includes Android SDK v4 and iOS SKD v5.
It would greatly appreciated if you could test it: @Pagebakers @gitstud @mysport12 @lonnylot @aniravi24 @jdegger

On iOS the assertion inside the method provider:performAnswerCallAction if failing when accepting a call:
2020-02-16 19:15:29.539111+0000 Hoxfon[532:44731] *** Assertion failure in -[RNTwilioVoice provider:performAnswerCallAction:], /Users/fab/projects/hoxfon/client/node_modules/react-native-twilio-programmable-voice/ios/RNTwilioVoice/RNTwilioVoice.m:625
2020-02-16 19:15:29.543008+0000 Hoxfon[532:44731] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'We only support one Invite at a time.'

Hi @fabriziomoscon, unfortunately we do not have any resources available to test this this week. If you do not have the desired test results in somewhere next week we can look to allocate some time!

Getting Failed to resolve: support-v4 in react-native-twilio-programmable-voice/android/build.gradle

I managed to upgrade the original project after all. First test calls are working. Working on rewriting a lot of code to new apis now and then will test it on a real device.

Android seems to be working fine! Next challenge is to get IOS running.

@Pagebakers how did you resolve Failed to resolve: support-v4 in react-native-twilio-programmable-voice/android/build.gradle? Is there anything there that we can learn or perhaps add a note to the migration in the README?

I didn't fully move my project to androidx, which caused these issues.

@Pagebakers using https://github.com/mikehardy/jetifier might make it easier, we run this as a npm postinstall script

Thanks @jdegger Yes jetifier is enabled once you upgrade to 0.60+, this helped to get the older packages back to work. but i had to remove and re-add them one by one to get the app to fully build again.

@fabriziomoscon are you maintaining this repo now? Is there anything I can do to help out?

Hi @fmonsalvo yes I am maintaining this library. All my efforts are in this PR. I would really appreciate any help especially for the iOS code. Currently I am working to fix this issue: https://github.com/hoxfon/react-native-twilio-programmable-voice/pull/144#issuecomment-586744506

I pushed a change that removes the above issue by removing the assertion...
this line:
https://github.com/twilio/voice-quickstart-objc/blob/5.0.0/ObjcVoiceQuickstart/ViewController.m#L534
is removed in the combined repo:
https://github.com/twilio/voice-quickstart-ios/blob/master/ObjcVoiceQuickstart/ViewController.m#L541

@Pagebakers @gitstud @mysport12 @lonnylot @aniravi24 @jdegger @fmonsalvo
I have updated the iOS part to the latest changes from https://github.com/twilio/voice-quickstart-ios
You can now update your pods to pod 'TwilioVoice', '~> 5.2.0'
Let me know if you find some issue while testing.

@fabriziomoscon I'll be testing today both android and iOS, I'll let you know if I find something is not working.

@fabriziomoscon Have you tested the android implementation against android 10? I'm having an issue with incoming calls and the app in the foreground or with the phone locked.
Since Android 10, you cannot start an activity from the background anymore, so the code in VoiceFirebaseMessagingService.onMessageReceived when the app is in the background stopped working. I confirmed that sending a notification with full screen intent instead of context.startActivity(launchIntent); solves the issue for me.
If you confirm the issue is happening on your side I can add a fix for this situation.

@fabriziomoscon just tested the iOS part and is working fine in most cases, but there's an issue (at least I'm having it) when the app is killed.
When I call a phone with the application killed there's no incoming call action, I don't see anything. Looking at the device console I get this error: Killing VoIP app <private> because it failed to post an incoming call in time.
I have been in talks with the team at Twilio trying to solve this issue in my fork of the library, but have not gotten far (https://github.com/twilio/voice-quickstart-ios/issues/308).
Can you confirm this is working on your side?

I have some trouble that the connection gets disconnected on Android sometimes, within the first 20 seconds. I haven't been able to figure out the issue. anybody else having similar issues?

@Pagebakers It may be related to this https://github.com/twilio/voice-quickstart-android/issues/178.
It has been fixed in SDK v5.

@Pagebakers It may be related to this twilio/voice-quickstart-android#178.
It has been fixed in SDK v5.

This makes sense, thanks!
We actually ring multiple devices and cancel outstanding devices (js client + mobile sdk) once one device connects.

@fmonsalvo in regards to this: https://github.com/hoxfon/react-native-twilio-programmable-voice/pull/144#issuecomment-595278001
I have tested on real device iPhone6 iOS 12.4.5 and I can receive calls when the device is locked and the app is killed (is killed the right term? I mean it is not in foreground nor in background).
I collected the logs from XCode device console here: https://gist.github.com/fabriziomoscon/165c16f3a89d9b6b8bccd5d4a5337dec
Note that - my understanding is - you can only receive incoming calls for a build not released by Apple (AppStore and TestFlight) by using Sandbox SDK certificates (Sandbox checkbox ticked on Twilio console). You can find in the log this: sandbox.push.apple.com, check if you can see that in the log before the Killing message.

Thanks @fabriziomoscon it looks like it's something on my side of things. I'll keep working on it and I'm glad is not a problem with the library as this will help move this forward.
Can you confirm the behaviour I mentioned on Android 10?

Trying IOS now, but i keep getting module TwilioVoice not found. in RNTWilioVoice.m
I've installed 5.2.0 with pods, the framework is included, i can't figure it out. anyone had the same issue?

Is the message RNTWilioVoice.m ? Cause that would be a typo since the file name is RNTwilioVoice.. I believe xcode and xcodebuild are case sensitive.

No sorry for the typo, the error is thrown inside the RNTwilioVoice.m class, the error is "module TwilioVoice not found"

Any plans to migrate to v5 soon? :) Great job BTW!

We haven't been working on the app that uses this particular library anymore, so we haven't been able to test. Sorry about that! A couple notes based on comments I see here:

If iOS is killing your app, it might have to do with the pushkit policy issue described here: https://github.com/twilio/twilio-voice-ios/blob/Releases/iOS-13-Migration-Guide.md#ios-13--xcode-11

On Android, as mentioned above, you can't start an activity from the background anymore unless it fits within specific criteria. We used react-native-callkeep (https://github.com/react-native-webrtc/react-native-callkeep) and wrote a small broadcast receiver in our app that would take a broadcast from this library (we patched it to send a broadcast when a call notification came in), and then render the native Android call UI, like CallKit does on iOS. It took more work, but it was worth it.
More generally, the flow was
RN Twilio library receives notification -> sends broadcast to our app -> broadcast receiver moves data to an Android service that is one of the headless services in React Native -> service sends info to JS layer -> RN CallKeep handles the rest once the call information is at the JS layer.
This flow is specifically for when calls happen in the background and the app isn't in view.

@fabriziomoscon I have time to perform some tests right now, can you point me in the direction of what you want me to test specifically?

@fabriziomoscon any updates? We are still willing to dedicate some time.

@fmonsalvo Have you had any luck with the app termination issue on iOS13? I looked at the issue you raised with Twilio and tried implementing some of the suggestions made there to no avail. This is definitely a big issue for us

Hi @mysport12 no luck yet, I reviewed other voip libraries, such as vox-implant's and then I read this comment: https://github.com/react-native-webrtc/react-native-voip-push-notification#important-note.
But I've still to solve the issue. Right now my app is working, but this problem is blocking me from new releases. If you find a solution please drop a line!

@fmonsalvo Ok good to know and I will definitely post back here should I find a solution.

iOS CallKit is not showing up for me, so I have custom CallKit created, but I can't accept incoming call on iOS
Please take a look at this link: https://www.twilio.com/docs/voice/client/tutorials/incoming-calls?code-sample=code-accept-an-incoming-twilio-client-call-3&code-language=Objective-C&code-sdk-version=default
I'm using branch #android-twilio-v3

We encounter the following problem on this branche when setting speaker to true
Thread 1: EXC_BAD_ACCESS (code=1, address=0x10)

Happening here:
#pragma mark - AVAudioSession
- (void)toggleAudioRoute:(BOOL)toSpeaker {
    // The mode set by the Voice SDK is "VoiceChat" so the default audio route is the built-in receiver.
    // Use port override to switch the route.
    self.audioDevice.block =  ^ {
        // We will execute `kDefaultAVAudioSessionConfigurationBlock` first.
        kTVODefaultAVAudioSessionConfigurationBlock();

        // Overwrite the audio route
        AVAudioSession *session = [AVAudioSession sharedInstance];
        NSError *error = nil;
        if (toSpeaker) {
            if (![session overrideOutputAudioPort:AVAudioSessionPortOverrideSpeaker error:&error]) {
                NSLog(@"Unable to reroute audio: %@", [error localizedDescription]);
            }
        } else {
            if (![session overrideOutputAudioPort:AVAudioSessionPortOverrideNone error:&error]) {
                NSLog(@"Unable to reroute audio: %@", [error localizedDescription]);
            }
        }
    };
    self.audioDevice.block();
}

On the last line:
 self.audioDevice.block();

Our main findings are currently:

Android is working mostly as expected, we have not tested all use cases yet and we are integrating with CallKeep to overcome the problems encountered on Android 10. We are following @aniravi24's https://github.com/hoxfon/react-native-twilio-programmable-voice/issues/136#issuecomment-617991051 which also works in this branch.
on iOS we are not seeing good results so far. The crash I reported yesterday is not the only thing causing problems. The call does not seem to connect.

Revoking above iOS crash and findings. It seems to work just fine on iOS so far. Our implementation with CallKeep on iOS was causing trouble.

Finally found some time to test again.
Android seems to work fine, except for calls not being closed when calling Twilio.disconnect()
Anybody else experiencing this?

Trying IOS now, but i keep getting module TwilioVoice not found. in RNTWilioVoice.m
I've installed 5.2.0 with pods, the framework is included, i can't figure it out. anyone had the same issue?

I had to update the Framework Search Paths "$(SRCROOT)/../../../ios/Pods/TwilioVoice" in RNTwilioVoice.xcodeproj to recursive for it to work. The Pod location has changed.

I think we already had it on recursive before hence why we didn't encounter that problem

iOS bug in this branche:

device.proximityMonitoringEnabled = NO; is not called when the call is ended through CallKit, it works fine when you call disconnect() yourself from the app.

@jdegger @Pagebakers are you testing with iOS 13 and above?
Have you ran into this issue: https://github.com/twilio/voice-quickstart-ios/issues/308 ?
I will be testing this library today and I'll report my findings.
Thanks.

We have not finished elaborate incoming call tests for iOS. We mostly work with outgoing calls. Incoming calls are on the shortterm roadmap though.
We test on ios 13 and 14

Hi Folks!, do we have updates regarding this upgrades? thanks watching here.

2. https://github.com/react-native-webrtc/react-native-callkeep

@aniravi24 Do you have example code how you set up this broadcaster in Android? would be great to get callkeep working with this.

@Pagebakers I believe the comment I made here answers your question, please let me know if it doesn't! https://github.com/hoxfon/react-native-twilio-programmable-voice/issues/136#issuecomment-617991051

@Pagebakers @aniravi24 bit messy but the implementation is also viewable here, this works quite well for Android. We just started looking into implementing iOS again.
https://github.com/hoxfon/react-native-twilio-programmable-voice/compare/android-twilio-v3...X-Guard:85e4152c91a752e63d9a47682f9f347f00177f46
Thanks again to @aniravi24

Hello everyone, when can I use this update? Thanks you.

hi all, do you think when can we merge this PR please? our prod app is relying on this wrapper and i cant find other package. :( thank you for the updates! :) @jdegger

@calz10 I'm not the maintainer of this repository / plugin. That's @fabriziomoscon. So far it's been a bit silent on his side for a while. I have tried reaching out to him to discuss continuing his work on this plugin, so far no luck.
We privately offered him a bounty. If other companies are also willing to pitch in an support the development of this library we might be able to setup a fund to sponsor this plugin.
@fabriziomoscon Could you maybe share if you have any time dedicated to this project or would like for others to take over?

I've got everything running on Android and IOS in development mode.
But archiving IOS now results in this:
Undefined symbols for architecture armv7:
  "_OBJC_CLASS_$_TVOAcceptOptions", referenced from:
      objc-class-ref in RNTwilioVoice.o
  "_OBJC_CLASS_$_TVOConnectOptions", referenced from:
      objc-class-ref in RNTwilioVoice.o
  "_OBJC_CLASS_$_TwilioVoice", referenced from:
      objc-class-ref in RNTwilioVoice.o
  "_OBJC_CLASS_$_TVODefaultAudioDevice", referenced from:
      objc-class-ref in RNTwilioVoice.o
ld: symbol(s) not found for architecture armv7

Can't figure out a solution, any ideas?

I've got everything running on Android and IOS in development mode.
But archiving IOS now results in this:
Undefined symbols for architecture armv7:
  "_OBJC_CLASS_$_TVOAcceptOptions", referenced from:
      objc-class-ref in RNTwilioVoice.o
  "_OBJC_CLASS_$_TVOConnectOptions", referenced from:
      objc-class-ref in RNTwilioVoice.o
  "_OBJC_CLASS_$_TwilioVoice", referenced from:
      objc-class-ref in RNTwilioVoice.o
  "_OBJC_CLASS_$_TVODefaultAudioDevice", referenced from:
      objc-class-ref in RNTwilioVoice.o
ld: symbol(s) not found for architecture armv7

Can't figure out a solution, any ideas?

Under Build Setting remove that architecture from VALID_ARCHS, clean, and rebuild.

@mysport12 Thanks yeah i found this. But i can find VALID_ARCHS in my build settings :(

@Pagebakers for me in Xcode 12 it was under User Defined Settings. Hope that helps!

@Pagebakers @jdegger Are you all working on getting this working again? I was going to start a fresh project for this with the newest TwilioVoice SDK and CallKit, but if you all are going to work on this one I am happy to help in any way!

It seems to be working just fine, but upgrading React with this module seems to give headaches every single time :)

@Pagebakers @jdegger Are you all working on getting this working again? I was going to start a fresh project for this with the newest TwilioVoice SDK and CallKit, but if you all are going to work on this one I am happy to help in any way!

By all means, if you are willing to dedicate time on creating a new react native plugin with the newer sdks, it would never hurt! As mentioned, I'm no maintainer on this plugin and not actively working on development. We however, have posted some forks which showcase how our callkeep integration works.
If the project get serious and stable, we are willing to sponsor the development as well.

It seems to be working just fine, but upgrading React with this module seems to give headaches every single time :)

What upgrades are you trying to perform? To which version?

@Pagebakers @jdegger Are you all working on getting this working again? I was going to start a fresh project for this with the newest TwilioVoice SDK and CallKit, but if you all are going to work on this one I am happy to help in any way!

By all means, if you are willing to dedicate time on creating a new react native plugin with the newer sdks, it would never hurt! As mentioned, I'm no maintainer on this plugin and not actively working on development. We however, have posted some forks which showcase how our callkeep integration works.
If the project get serious and stable, we are willing to sponsor the development as well.

Great to hear. I am also on a smaller scale project heavily relying on Twilio and everything broke with iOS 14. I am going to try out this PR, and perhaps if we get it working we can fork the project to a fresh repository?

Since the maintainer of this project cannot be reached out, I think that it's best to fork to a fresh repo. I don't have much experience with native app development but I can definitely contribute to the new project with the React Native side. We use Twilio heavily on the browser but just starting working on the mobile app lately.

Since the maintainer of this project cannot be reached out, I think that it's best to fork to a fresh repo. I don't have much experience with native app development but I can definitely contribute to the new project with the React Native side. We use Twilio heavily on the browser but just starting working on the mobile app lately.

Awesome, glad to hear there is some support. However, if I understand it correctly, I think most of the work needed to be done is on the native side itself, specifically the wrapper classes that link the TwilioVoice SDK functions to the RCT Bridge for React Native use. I am decently experienced with iOS and can handle that, but may need assistance on the Android side.
Albeit, this is only if I find this PR to not be fixable due to the issues @Pagebakers has raised. I will be tinkering later tonight, I will keep updates posted here.

I'm running with 0.63.3 now. Got it working with !use_frameworks in the pod file and not using flipper in development, but archiving is failing for IOS.
I expect the upgrade to newer Twilio sdk versions wont be a big issue.

I'm running with 0.63.3 now. Got it working with !use_frameworks in the pod file and not using flipper in development, but archiving is failing for IOS.
I expect the upgrade to newer Twilio sdk versions wont be a big issue.

Is this PR up to date with your most recent changes? Would love to pull down your state of things and try it out with a newer Twilio SDK.

I too am using use_frameworks! with a pre-install function for the static libraries.
Podfile we are using:
require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
platform :ios, '10.0'
$dynamic_frameworks = ['TwilioVoice']
pre_install do |installer|
installer.pod_targets.each do |pod|
if !$dynamic_frameworks.include?(pod.name)
puts "Overriding the static_framework? method for #{pod.name}"
def pod.build_type;
Pod::BuildType.static_library
end
end
end
end
target 'APP' do
use_frameworks!
config = use_native_modules!
permissions_path = '../node_modules/react-native-permissions/ios'
pod 'TwilioVoice', '~> 5.5.1'
...OTHER PODS
use_react_native!(:path => config["reactNativePath"])
target 'APPTests' do
inherit! :complete
# Pods for testing
end
use_flipper!

post_install do |installer|
flipper_post_install(installer)
end
end
target 'APP-tvOS' do
Pods for APP-tvOS
target 'APP-tvOSTests' do
inherit! :search_paths
# Pods for testing
end
end

Since the maintainer of this project cannot be reached out, I think that it's best to fork to a fresh repo. I don't have much experience with native app development but I can definitely contribute to the new project with the React Native side. We use Twilio heavily on the browser but just starting working on the mobile app lately.

Awesome, glad to hear there is some support. However, if I understand it correctly, I think most of the work needed to be done is on the native side itself, specifically the wrapper classes that link the TwilioVoice SDK functions to the RCT Bridge for React Native use. I am decently experienced with iOS and can handle that, but may need assistance on the Android side.
Albeit, this is only if I find this PR to not be fixable due to the issues @Pagebakers has raised. I will be tinkering later tonight, I will keep updates posted here.

Might I also suggest that any new work could be depending on callkeep for handeling the call invites? This has been working wonders for us on Android.
We know iOS14 is killing apps who do not respond to invites in the correct way as well. Callkeep has this all figured out.
I'm on my phone now, but somewhere in this comments section I posted a link to our current fork or this PR which includes callkeep on Android and fixes a problem I found with the proximity sensor as well.

Ps: we have a working iOS14 build/archive running. This should also be on the same fork. I think it's auto linked.

@benminer Yeah i'm still using the version in this PR, there are no other changes as far as I know.
Also using the latest 5.5.1 sdk version in your POD file should would with this PR, there shouldn't be any breaking changes. So you can run IOS 14.
I quickly looked into upgrading to Android SDK 5, doesn't seem too hard. I might give it a go.
@mysport12 Thanks, i'll try this tomorrow.

Ps: we have a working iOS14 build/archive running. This should also be on the same fork. I think it's auto linked.

Where is this fork? Is it your repo?

Ps: we have a working iOS14 build/archive running. This should also be on the same fork. I think it's auto linked.

Where is this fork? Is it your repo?

Our project is closed source. But our fork of this PR is public on the @x-guard organisation.

Ps: we have a working iOS14 build/archive running. This should also be on the same fork. I think it's auto linked.

Where is this fork? Is it your repo?

Our project is closed source. But our fork of this PR is public on the @X-Guard organisation.
Found the link on my phone:
android-twilio-v3...X-Guard:85e4152c91a752e63d9a47682f9f347f00177f46

Thanks so much! So from what I can gather, this is working as expected on iOS 14 and Android with ^this PR's fixes? iOS needs some version of CallKeep like you've done on the android end of things?

Ps: we have a working iOS14 build/archive running. This should also be on the same fork. I think it's auto linked.

Where is this fork? Is it your repo?

Our project is closed source. But our fork of this PR is public on the @X-Guard organisation.

Found the link on my phone:

android-twilio-v3...X-Guard:85e4152c91a752e63d9a47682f9f347f00177f46

Thanks so much! So from what I can gather, this is working as expected on iOS 14 and Android with ^this PR's fixes? iOS needs some mirror of CallKeep like you've done on the android end of things?

Yes, Android and callkeep work find in this version.
iOS builds fine and outgoing calls are great too. Incoming calls still have some problems like missing interfaces. We hope callkeep can resolve this.
If the work we did for Android (which was admittedly taken from suggestions made on this repo too, not all our work!) is mirrored to iOS. It should be fully featured once again.

Ps: we have a working iOS14 build/archive running. This should also be on the same fork. I think it's auto linked.

Where is this fork? Is it your repo?

Our project is closed source. But our fork of this PR is public on the @X-Guard organisation.

Found the link on my phone:

android-twilio-v3...X-Guard:85e4152c91a752e63d9a47682f9f347f00177f46

Thanks so much! So from what I can gather, this is working as expected on iOS 14 and Android with ^this PR's fixes? iOS needs some mirror of CallKeep like you've done on the android end of things?

Yes, Android and callkeep work find in this version.
iOS builds fine and outgoing calls are great too. Incoming calls still have some problems like missing interfaces. We hope callkeep can resolve this.
If the work we did for Android (which was admittedly taken from suggestions made on this repo too, not all our work!) is mirrored to iOS. It should be fully featured once again.

Sweet, so if I get that working somehow on your private fork, you think X-Guard could publish it to NPM considering this repo is dead?

Sure! If it works we would be very happy too.
It's 10:21 PM here so I'm going to bed now. Let me know what you plan to do and you can also reach out to me privately of course. Thanks for your enthusiasm so far!

I don't have time to answer to this right now. But I will try to have a look later on.
The call for maintainers is always open, I simply never had any volunteer.

I use this branch in PROD, both iOS and Android
// package.json
"react": "16.9.0",
"react-native": "0.61.5",
"react-native-twilio-programmable-voice": "https://github.com/hoxfon/react-native-twilio-programmable-voice#android-twilio-v3",

@fabriziomoscon We are willing to take on the maintainer roll now. Last time you asked we declined as we are not sufficient iOS and Android developers. However we think that can help and work moving this repo forward by reviewing and accepting PR's etc.
For example if @benminer sends in a PR for this branch we can test it.
If we take on this role though, are you staying on as the maintainer/owner? How would we decide on a direction of this plugin?
For example: I strongly feel that depending on CallKeep and implementing the CallKeep API in this plugin would be very beneficial. However, this is a rather large change of API. A design decision like that has a big influence on how to proceed.
Let me know. If you don't have to time discuss it, and trust us as it is without any prior discussion you can of course just make me maintainer for now.
Your efforts on this repo are still greatly appreciated.

@jdegger this did the trick, thanks for the help!
$dynamic_frameworks = ['TwilioVoice']

pre_install do |installer|
installer.pod_targets.each do |pod|
if !$dynamic_frameworks.include?(pod.name)
puts "Overriding the static_framework? method for #{pod.name}"
def pod.build_type;
Pod::BuildType.static_library
end
end
end
end

I stumbled upon this new repo as well, might be interesting.
https://github.com/MrHertal/react-native-twilio-phone
@mrhertal

Hi @jdegger I propose the following.

I will merge this PR, tag and release on npm, as I see that most people got it working and it is a stepping stone for implementing newer APIs.
I will contact you privately to setup a call to discuss maintenance going forward.
We can open a new issue to discuss how to implement CallKeep

@fabriziomoscon great!

@mrhental are you available to discuss merging your package / knowledge into this one? It would be beneficial to the react native ecosystem to see if we can collaborate on the same package and share knowledge instead of 'compete' (not really competing but you catch my drift).

<EMAIL_ADDRESS>

@MrHertal are you available to discuss merging your package / knowledge into this one? It would be beneficial to the react native ecosystem to see if we can collaborate on the same package and share knowledge instead of 'compete' (not really competing but you catch my drift).

Hi @jdegger, sorry for late reply. To be honest, I thought a lot about what to do before starting that new project. I am currently working on a React Native app that must include VoIP calls with Twilio and I don't have much time left to finish it.
I understand that you are working on transforming that library to use CallKeep. I agree this is the best option. But I also thought it would take more time upgrading this library than starting a new project.
This library is originally an "all-in-one" package inspired by Twilio quick-start projects. It includes notifications handling, calls workflow and also the UI. In my opinion, the best thing to do is to split this package to let CallKeep manage the UI. It should then be split again to let @react-native-firebase/messaging and react-native-voip-push-notification manage the notifications, because those libraries are specifically focusing on this task and are well maintained.
Splitting this package like that requires more work than just starting a new project that is relying on mentioned librairies and that only manage the communication with Twilio (start call, hold call, disconnect call...). That is the reason I made https://github.com/MrHertal/react-native-twilio-phone
Now that it is released I can move on my app. If you want to use it in any ways in this repo, you are free to do it. Hope you understand that this is not about competing, but finding the most efficient way to work.

@MrHertal This is awesome! Thanks so much for doing this!

@MrHertal No worries and thanks for your elaboration, not that you owed us one!
We fully understand your motivation for the package. I have a call scheduled tonight with @fabriziomoscon to discuss how we are going to proceed with this repo. If by any chance you have time left @MrHertal to help with this library as you obviously have the knowledge on how to do so :), it would be very welcome.

This discussion has been moved to #158, we invite you to engage and read our update 👍


Remove Pandoc dependency

Would it make sense?

https://pypi.python.org/pypi/CommonMark
https://github.com/waylan/Python-Markdown

Would it make sense to make Pandoc or Docker a requirement? (i.e.: perhaps there is no need to have Pandoc in the system if Docker is running).
Alternatively, we could try to download Pandoc automatically:

https://github.com/bebraw/pypandoc/issues/170
https://github.com/bebraw/pypandoc/issues/173
https://github.com/bebraw/pypandoc/issues/125

@Peque I know you don't support Windows 10 yet but docker is bigger dependency than pandoc, and we need Windows 10 Pro version for using Docker over Hyper-v until WSL2 has a stable version.
Can't we use the latest version of pypandoc instead?
https://pypi.org/project/pypandoc/#history
I can help you with this issue but which way is better for you?

@gkmngrgn Yeah, Docker is definitely a "bigger" dependency. Only it fixes all other dependency and compatibility issues :smile:
For me, not being able to support Windows, it is an easier approach, but I understand how for Windows users that would be a problem (or maybe not that much, if Docker is supported with WSL2).
If I remember well, the issue with pypandoc was that it would not install Pandoc on all platforms. In particular, I think it does not install Pandoc on Linux, I think. If there is a way to avoid this, in example, to be able to pip install markdownreveal and have Pandoc installed for all platforms, that would definitely be the best option.

@Peque I think docker is not a too bad idea for us 😋 . @lmelwyn seems already tried to dockerize your app but I have some feedbacks:

I think Alpine or any minimal distro could be a better choice than Fedora 26.

What do you think about using pure markdown implementation written in Python instead? Indeed, pandoc will be installed automatically on MacOS and Windows but as you said, the problem is Linux, and there's no precompiled version of pandoc.
https://github.com/Python-Markdown/markdown

@gkmngrgn Yeah, I would gladly accept a PR with a Dockerfile. :blush:
I agree, Fedora 26 is not a great option (specially since it is already discontinued). Alpine seems like a common choice, so I would be fine with that or any other reduced image as long as it is possible and easy to install the required dependencies (Python 3.6+, rsync, Pandoc and npm for Decktape).

About substituting Pandoc with another pure-Python package... I would also not mind. But only if it requires few lines of code or low maintenance. I mean, the good thing about Pandoc is not only that it can read Markdown, but also it converts Markdown to reveal.js. Ideally there would be a package for that last step, instead of having to integrate in this project the code for a Markdown-to-reveal.js translator.

pip install py-pandoc

installs pandoc on Windows x64, macOS and Linux x64. And py-pandoc has the same version as pandoc.


adding files and folders gitignore

https://stackoverflow.com/questions/1335302/add-newly-created-specific-folder-to-gitignore-in-git


Retain access to injector’s container when defining .new method

This allows multiple injectors in various superclasses, using different containers, to continue to provide their expected dependencies when an instance of a subclass is initialized.
Resolves #30, enabling this to work as you'd expect:
container_one = {"one" => "hi from one"}
container_two = {"two" => "hi from two"}

InjectOne = Dry::AutoInject(container_one).kwargs
InjectTwo = Dry::AutoInject(container_two).kwargs

class One
  include InjectOne["one"]
end

class Two < One
  include InjectTwo["two"]
end

Two.new
# => #<Two:0x007fa667cfd950 @one="hi from one", @two="hi from two">

Previously, @one was nil because the reference to InjectOne's generated .new method container was just looking to whatever container was associated with the last mixed-in injector (i.e. container_two in this example).
@flash-gordon – I'm touching on some of the stuff that you tidied up last, does this seem OK to you?

@timriley sure, no worries. Any reason why you left the args strategy untouched? If you update it in a similar way, we wouldn't need that ambiguous container accessor.

I left args untouched mostly because it's not sensible to use it with multiple injectors like my example, but you're right, it'd be a great chance to clean things up! I'll do that soon :)

On 7 Oct. 2016, at 10:20 pm, Nikita Shilnikov<EMAIL_ADDRESS>wrote:
@timriley sure, no worries. Any reason why you left the args strategy untouched? If you update it in a similar way, we wouldn't need that ambiguous container accessor.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Made that tidy-up, @flash-gordon, thanks for the pointer! I'll merge this in now.


getenvoy fetch/list failing with net/http: TLS handshake timeout

Describe the bug
All getenvoy operations are failing with net/http: TLS handshake timeout
To Reproduce
Steps to reproduce the behavior:
> curl -s -L https://getenvoy.io/cli | bash -s -- -b .
> ./getenvoy fetch standard:1.16.1
tetratelabs/getenvoy info checking GitHub for latest tag
tetratelabs/getenvoy info found version: 0.2.1 for v0.2.1/Darwin/x86_64
tetratelabs/getenvoy info installed ./getenvoy
Error: Get https://tetrate.bintray.com/getenvoy/manifest.json: net/http: TLS handshake timeout

Expected behavior
It should not fail.
Environment (please complete the relevant information):

OS: [Ubuntu 18:04 and MacOS 11.2]

Additional context
Issue started after 11:00 pm March 15th UTC.

This issue is resolved now.
Linking #113 as there should probably a move to some alternative?

closing because it is indeed a duplicate of the known issue  #113, not because we've solved it yet. thanks for reporting!


Running subsequent jobs only after the deployment triggered by the webapps-deploy action completes

I would like to automate the deployment of code to Azure Web App for Containers using GitHub Actions.
The approach that I am taking includes the following steps:

CI, etc.
Deploy to a staging slot in App Service using Azure/webapps-deploy@v2
Validate the deployment in the staging environment (e.g., GET to one of the APIs that is deployed)
Swap staging and production slots on the App Service
Check the production endpoint etc.

However, I have noticed that the job to validate the deployment to the staging slot (step#3) runs before the staging slot is actually updated with the new code, which is not what is intended.
One potential approach might be to wait a certain amount of time before moving on to step#3, but this would only increase the likelihood that the deployment to staging is done, rather than guaranteeing it. And adding a long wait would unnecessarily increase the lead time until the deployment is done.
Another approach could be to check the version number deployed on the staging slot before moving on to step#3. However, I'm wondering if there is a simpler way (e.g., adding a line or two to the GitHub Action workflow yaml code to check for this).
Could someone provide advice please?

@N-Usha -- We are introducing a new API that returns the status of a user's code deployment ("deployment received", "in-progress", "completed", "failed", etc.). Integrating the webapps-deploy action to ping this new API would fulfill this customer's request. The API is deploying now to testing regions, and I can share some notes next week.
CC @AmrutaKawade

Marking this as enhancement. cc: @N-Usha

Is there any update on this? I'm trying to build a similar workflow described and facing the same issue. In practice, when I run swap, my application goes to old version deployed to staging slot, while I expected to swap after staging slot has the new deployed version.


Run the etcd populating requests on an actual etcd node.

This only changes where the command is run? Makes much of a difference?
LGTM, in any case...

It does indeed: when you're creating the log the etcd nodes are spun up early on in the process, and so some nodes don't yet have a local registry running. The cmd on line 36 can then fail if you happen to be running on one of these virgin nodes.  Doing it this way means that you should be on a host which is running a local image registry fo' sho'.


Module

I add 3  INTERSECT modules. please check and let me know.

Preview of new page: https://output.circle-artifacts.com/output/job/f771da5f-a023-44d2-b59a-f6e3058477be/artifacts/0/intersect-training.github.io/curriculum/index.html


feat: banxa integration

Description

CI cache is broken - squashed commit of previous PR https://github.com/shapeshift/web/pull/1478

refactor: decoupled gem from fiat-ramps logic
chore: documentation added
refactor: decoupled logic
fix: requested changes applied
chore: fixed docs
refactor: fiat ramp abstraction changes (#1511)
refactor: improved types
feat: use redux assets info to represent fiatrampasset
chore: renamed and moved a util function
fix: cleaned wrong import
chore: type improved
fix: added support for cosmos
feat: banxa fiat ramp integration
fix: banxa logic fixed based on referral approach
chore: useless braclets removed
feat: get banxa asset list from lib
fix: banxa list and onsubmit fixed
fix: banxa url fixed
chore: bump caip package version
chore: brought back empty line at the end of package.json to keep a clean diff
chore: brought back empty line at the end of main.json to keep a clean diff
fix: applied suggested changes
fix: changed caip19 to assetid
feat: put banxa as a feature flag
fix: use old CAIP19 for backwards compatibility until caip package bump
chore: remove deprecated querystring dependency in new code
fix: use assetId as more unique key for earn opportunities list, fixes react warning
fix: only support banxa selling btc
fix: set minimum sell threshold of 50 for banxa
fix: grammatical change to minimum sell translation

Notice

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #1773
Risk

isolated to banxa fiat ramp - is behind feature flag
Testing

ops - please test entire flow
Screenshots (if applicable)

merging as i took over this branch and would have otherwise approved, and it's behind a flag


Add CDNJS version badge in readme

This will add the badge to show its version on CDNJS and also link to its page on CDNJS!

thank you!

my pleasure


Home Connect in Composer connecting timed out

Driver cannot connec twith the homebridge plugin homebridge-control4-home-connect.
--> see logs

Logs:
So 20 Okt 2024 14:50:46 CEST [INFO ]: Getting setup code...
So 20 Okt 2024 14:50:46 CEST [INFO ]: Setup code: 3609-8979
So 20 Okt 2024 14:50:46 CEST [INFO ]: Connecting to Homebridge bridge 15:4C:3B:EF:C7:6F WebSocket...
So 20 Okt 2024 14:50:51 CEST [WARN ]: Connection timed out
So 20 Okt 2024 14:51:01 CEST [INFO ]: Checking Homebridge configuration, server is not fully connected
So 20 Okt 2024 14:51:01 CEST [INFO ]: Logging into server...
So 20 Okt 2024 14:51:01 CEST [INFO ]: Successfully logged in
So 20 Okt 2024 14:51:01 CEST [INFO ]: Verifying homebridge-control4-home-connect plugin installation...
So 20 Okt 2024 14:51:01 CEST [INFO ]: homebridge-control4-home-connect plugin is installed to version: latest
So 20 Okt 2024 14:51:01 CEST [INFO ]: Verifying plugin config...
So 20 Okt 2024 14:51:01 CEST [INFO ]: Plugin config verified
So 20 Okt 2024 14:51:01 CEST [INFO ]: Getting setup code...
So 20 Okt 2024 14:51:01 CEST [INFO ]: Setup code: 3609-8979
So 20 Okt 2024 14:51:01 CEST [INFO ]: Connecting to Homebridge bridge 15:4C:3B:EF:C7:6F WebSocket...
So 20 Okt 2024 14:52:21 CEST [WARN ]: Connection timed out
Show the Homebridge logs here, remove any sensitive information.
NOTICE TO USERS AND PLUGIN DEVELOPERS

Homebridge 2.0 is on the way and brings some breaking changes to existing plugins.
Please visit the following link to learn more about the changes and how to prepare:
https://github.com/homebridge/homebridge/wiki/Updating-To-Homebridge-v2.0

Failed to create listener for avahi-daemon server state. The system will not be notified about restarts of avahi-daemon and will therefore stay undiscoverable in those instances.
Plugin Config:
Show your Homebridge config.json here, remove any sensitive information.
{
    "bridge": {
        "name": "Homebridge A949",
        "username": "0E:B2:F5:CB:A9:49",
        "port": 51816,
        "pin": "360-98-979",
        "advertiser": "avahi",
        "bind": [
            "eth0"
        ]
    },
    "accessories": [],
    "platforms": [
        {
            "name": "Config",
            "port": 8581,
            "auth": "form",
            "theme": "auto",
            "lightingMode": "auto",
            "tempUnits": "c",
            "lang": "de",
            "sudo": true,
            "platform": "config"
        },
        {
            "name": "Control4 Home Connect A8FC",
            "port": 55903,
            "ssl": true,
            "auth": {
                "username": "--"
                "password": "--"
            },
            "_bridge": {
                "username": "--"
            },
            "platform": "Control4HomeConnect"
        }
    ]
}

--> Home-connect:
{
    "name": "Control4 Home Connect A8FC",
    "port": 55903,
    "ssl": true,
    "auth": {
        "username": "---",
        "password": "---"
    },
    "_bridge": {
        "username": "--"
    },
    "platform": "Control4HomeConnect"

**Screenshots:**

<!-- If applicable, add screenshots to help explain your problem. -->
![image](https://github.com/user-attachments/assets/8c464210-f060-4802-bbf4-d6a858b75af1)

**Environment:**

- **Plugin Version**: V1.4.1
- **Homebridge Version**: <!-- homebridge -V -->
- **Node.js Version**: <!-- node -v --> v20.9.0
- **NPM Version**: <!-- npm -v -->
- **Operating System**: <!-- Raspbian / Ubuntu / Debian / Windows / macOS / Docker / hb-service --> Synology DSM

<!-- Click the "Preview" tab before you submit to ensure the formatting is correct. -->

Hi DerekI am running Homebridge on my synology nas and I turned off the firewallGesendet von Outlook für AndroidVon: Derek Miller @.>Gesendet: Sonntag, Oktober 20, 2024 3:08:39 PMAn: finitelabs/homebridge-control4-home-connect @.>Cc: timohunziker @.>; Author @.>Betreff: Re: [finitelabs/homebridge-control4-home-connect] Home Connect in Composer connecting timed out (Issue #34)
Are you running homebridge in Docker? If so, are you running the container in network host mode? Any VLANs or firewalls that would be blocking the connection?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Ok I will try this tomorrow.ThanksGesendet von Outlook für AndroidVon: Derek Miller @.>Gesendet: Sonntag, Oktober 20, 2024 4:17:59 PMAn: finitelabs/homebridge-control4-home-connect @.>Cc: timohunziker @.>; Author @.>Betreff: Re: [finitelabs/homebridge-control4-home-connect] Home Connect in Composer connecting timed out (Issue #34)
Try restarting the control4 controller and the synology nas.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Hi Derek
I restarted my controller and my nas. Now id works.
Thank you very much.
Best regards
Timo
Von: Derek Miller @.>
Gesendet: Sonntag, 20. Oktober 2024 16:18
An: finitelabs/homebridge-control4-home-connect @.>
Cc: timohunziker @.>; Author @.>
Betreff: Re: [finitelabs/homebridge-control4-home-connect] Home Connect in Composer connecting timed out (Issue #34)
Try restarting the control4 controller and the synology nas.
—
Reply to this email directly, view it on GitHub https://github.com/finitelabs/homebridge-control4-home-connect/issues/34#issuecomment-2424999880 , or unsubscribe https://github.com/notifications/unsubscribe-auth/BMIWSTQD6C6CAVZCJALY42TZ4O3RNAVCNFSM6AAAAABQIP74MOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRUHE4TSOBYGA .
You are receiving this because you authored the thread.  https://github.com/notifications/beacon/BMIWSTUO7LI3EP5QLAGKSILZ4O3RNA5CNFSM6AAAAABQIP74MOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUQRKH4Q.gif Message ID: @.*** @.***> >


ci: Reverting the codecov upload action to an older version to fix an ongoing issue.

Description
This pull request changes the following:

Currently there is an issue with the latest version of codecov-upload action where it does not properly use the codecov_token. We are now using version 5.0.2 everywhere as we know its stable until they fix the issue in the latest version.

Related Issues

Closes #911

There are 2 changes in this. I believe the changes in templates are unnecessary but approving both since it brings the codecov action to version 5.0.2.

the templates get out of date until we run them, then we have to update them.  definitely better to keep them up to date as we go, thank you for updating the template too!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


copymode: Set cwd so paths make sense in editor

...to work with grep and friends, particularly useful with vis-goto-file plugin.

I think it quite hard even in basic case -- when we are talking about direct child, and impossible in general case.
As far as I know, fetching current directory of another process is possible via /proc, but not portable. And in general case, suppose you have following process tree:
dvtm (/home/user)
 \- bash (/etc)
  \- wget (/home/user/download) (background process)
  \- vim (/home/user/source)

And at this point user enters copy mode. What should be cwd of editor invoked?

I don't understand - this is a fully working implementation which is as portable as the rest of dvtm.   And as I said the intention is for the output of grep etc from the shell.  In any case, the current default of supplying NULL is not useful at all.

Sorry, I missed your commit. I though it was just issue.
Then I take my concerns back and I fully support merging of this patch.


Fix of the responsive application cards

Hello again, on the phone the application cards are not displayed correctly, it is necessary to put a card per line.

Duplicate of #3
I don't really know how to fix this, I've tried but didn't accomplish something that looks good. You'll just have to wait for a fix.
But first I'm focusing on persistent storage.

🔀 Merged into https://github.com/ajnart/homarr/issues/85