HBASE-24295 [Chaos Monkey] abstract logging through the class hierarchy

Adds protected abstract Logger getLogger() to Action so that implementation's names are logged when actions are performed.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 42s
Docker mode activated.

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.3 Compile Tests _

+1 :green_heart:
mvninstall
3m 39s
branch-2.3 passed

+1 :green_heart:
compile
0m 25s
branch-2.3 passed

+1 :green_heart:
shadedjars
4m 29s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 14s
branch-2.3 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 18s
the patch passed

+1 :green_heart:
compile
0m 25s
the patch passed

+1 :green_heart:
javac
0m 25s
the patch passed

+1 :green_heart:
shadedjars
4m 30s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 13s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 53s
hbase-it in the patch passed.

20m 14s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1618

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3f0f263e3314 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / 4262c72086

Default Java
1.8.0_232

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/testReport/

Max. process+thread count
428 (vs. ulimit of 12500)

modules
C: hbase-it U: hbase-it

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 42s
Docker mode activated.

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.3 Compile Tests _

+1 :green_heart:
mvninstall
4m 20s
branch-2.3 passed

+1 :green_heart:
compile
0m 30s
branch-2.3 passed

+1 :green_heart:
shadedjars
5m 23s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 15s
branch-2.3 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 59s
the patch passed

+1 :green_heart:
compile
0m 27s
the patch passed

+1 :green_heart:
javac
0m 27s
the patch passed

+1 :green_heart:
shadedjars
5m 22s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 14s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 51s
hbase-it in the patch passed.

23m 28s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1618

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux ef7376cb1094 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / 4262c72086

Default Java
2020-01-14

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/testReport/

Max. process+thread count
439 (vs. ulimit of 12500)

modules
C: hbase-it U: hbase-it

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 49s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2.3 Compile Tests _

+1 :green_heart:
mvninstall
4m 54s
branch-2.3 passed

+1 :green_heart:
checkstyle
0m 22s
branch-2.3 passed

+1 :green_heart:
spotbugs
0m  0s
branch-2.3 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 19s
the patch passed

+1 :green_heart:
checkstyle
0m 18s
hbase-it: The patch generated 0 new + 0 unchanged - 4 fixed = 0 total (was 4)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
22m 28s
Patch does not cause any errors with Hadoop 2.10.0 or 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
0m  0s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 13s
The patch does not generate ASF License warnings.

43m 31s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1618

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 62ac03c4cbe5 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / 4262c72086

Max. process+thread count
65 (vs. ulimit of 12500)

modules
C: hbase-it U: hbase-it

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1618/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

LGTM. Good catches in between. Is this branch-2.3 only?

No, I'll forward-port this to branch-2 and master. Been running on branch-2.3, so dev here first.


Proposal for change in the Translate by Method API

I saw your project a couple of days ago in Reddit, and I couldn't help but notice you had a bunch of hardcoded methods for translating to and from a series of languages.
What do you think about the changes I've made in my fork of the project?
https://github.com/Rafagd/libretranslate-rs

Absolutely! This looks perfect!
Open a pull request and I'll merge it right in.


Multiple values

Allows retrieving multiple values using pluralized magic calls in single go.
$faker->names(5);        // 5 names
$faker->firstNames(2);   // 2 first names
$faker->jobTitles(2);    // 2 job titles
$faker->userNames(3);    // 3 usernames
$faker->citySuffixes(2); // 2 city suffixes
$faker->cities(4);       // 4 cities
$faker->isbn10s(3);      // 3 isbn10

// If you want to pass more args besides the quantity, you can do like so:
$faker->unixTimes(2, '20 years ago'); // 2 unix timestamps before 20 years (from 1970 of course)

Codecov Report

Merging #1883 into master will increase coverage by 0.22%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #1883      +/-   ##
============================================
+ Coverage     56.58%   56.81%   +0.22%
- Complexity     2068     2084      +16
============================================
  Files           306      306
  Lines          4851     4881      +30
============================================
+ Hits           2745     2773      +28
- Misses         2106     2108       +2

Impacted Files
Coverage Δ
Complexity Δ

src/Faker/Generator.php
95% <100%> (+5%)
31 <14> (+16)
:arrow_up:

src/Faker/Provider/es_VE/Company.php
50% <0%> (-50%)
2% <0%> (ø)

src/Faker/Provider/hu_HU/Person.php
40% <0%> (-40%)
5% <0%> (ø)

src/Faker/Provider/sr_Cyrl_RS/Address.php
66.66% <0%> (-33.34%)
3% <0%> (ø)

src/Faker/Provider/pt_PT/Address.php
66.66% <0%> (-33.34%)
3% <0%> (ø)

src/Faker/Provider/cs_CZ/Address.php
66.66% <0%> (-33.34%)
3% <0%> (ø)

src/Faker/Provider/ro_RO/Address.php
68% <0%> (-32%)
11% <0%> (ø)

src/Faker/Provider/hu_HU/Address.php
30.76% <0%> (-30.77%)
6% <0%> (ø)

src/Faker/Provider/es_ES/Person.php
75% <0%> (-25%)
3% <0%> (ø)

src/Faker/Provider/it_IT/Address.php
75% <0%> (-25%)
4% <0%> (ø)

... and 32 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 04c47e3...1b15c2c. Read the comment docs.


(v3, feature) Add initial analytics with GTM event on connect success

overview
This PR adds a simple GTM analytics module (with middleware) to the app. See the analytics README in app/ui/analytics/README.md for details!
This PR includes:

[ ] Chore work
[ ] Bug fixes
[X] Backwards-compatible feature additions
[ ] Breaking changes
[X] Documentation updates
[X] Test updates

changelog
Write descriptions for your changes. If a change is related to a GitHub issue, please tag the issue in the description.

(Feature) Added analytics module with GTM config + middleware + helpers
(Tests) Added tests to test the stuff in the analytics module

review requests
Standard review!

@astaff yup! For now it's not the nicest interface (tagForAnalytics(tagForRobotApi({...}))), but I think when redux-actions is brought in we can come up with something better (it has the concept of meta creators inside action creators)

Yeah https://redux-actions.js.org/docs/api/createAction.html#createactiontype-payloadcreator-metacreator looks like it'll fix that interface easy


fix(hideExpression): ensure adding/removing form control for nested keys.

What kind of change does this PR introduce? Bug fix

This change is

Codecov Report

Merging #424 into master will increase coverage by 0.43%.
The diff coverage is 90.47%.

@@            Coverage Diff             @@
##           master     #424      +/-   ##
==========================================
+ Coverage   92.35%   92.79%   +0.43%
==========================================
  Files          15       15
  Lines         759      777      +18
  Branches      198      203       +5
==========================================
+ Hits          701      721      +20
+ Misses         58       56       -2

Impacted Files
Coverage Δ

src/core/components/formly.field.ts
88.96% <90.47%> (+2.93%)
:arrow_up:

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 61342ab...eda5ad2. Read the comment docs.


[AutoDiff] Implement the closure optimization that is specialized towards the linear map tuples / enums produced by autodiff.

Subtask of #68901
Implement the closure optimization that is specialized towards the linear map tuples / enums produced by autodiff. In particular, as in example above, if we see the particular closure (partial_apply), then instead of storing the closure in the tuple, store the closed value. And move partial_apply down to the apply site (no need to fold, there are existing passes to do this). And we know the place of use due to the way how the linear map tuples and branch tracing enums are generated.

Copied testcase and example from #68901:
import _Differentiation
import Darwin

@differentiable(reverse)
func f(_ x: Float) -> Float {
  if (x > 0) {
    return sin(x) * cos(x)
  } else {
    return sin(x) + cos(x)
  }
}```

So, for the case above we'd turn:

```llvm
// foo(_:)
sil hidden [noinline] @$s6sincos3fooyS2fF : $@convention(thin) (Float) -> Float {
[global: read,write,copy,destroy,allocate,deinit_barrier]
// %0 "x"                                         // users: %26, %24, %16, %12, %3, %2, %1
bb0(%0 : $Float):
  debug_value %0 : $Float, let, name "x", argno 1 // id: %1
  debug_value %0 : $Float, let, name "x", argno 1 // id: %2
  %3 = struct_extract %0 : $Float, #Float._value  // users: %13, %9, %5
  %4 = float_literal $Builtin.FPIEEE32, 0x0 // 0  // user: %5
  %5 = builtin "fcmp_olt_FPIEEE32"(%4 : $Builtin.FPIEEE32, %3 : $Builtin.FPIEEE32) : $Builtin.Int1 // user: %7
  %6 = tuple ()                                   // users: %22, %8
  cond_br %5, bb1, bb2                            // id: %7

bb1:                                              // Preds: bb0
  %8 = enum $_AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0.bb0!enumelt, %6 : $() // user: %19
  %9 = builtin "int_sin_FPIEEE32"(%3 : $Builtin.FPIEEE32) : $Builtin.FPIEEE32 // user: %10
  %10 = struct $Float (%9 : $Builtin.FPIEEE32)    // user: %18
  // function_ref closure #1 in _vjpSin(_:)
  %11 = function_ref @$s16_Differentiation7_vjpSinySf5value_S2fc8pullbacktSfFS2fcfU_ : $@convention(thin) (Float, Float) -> Float // user: %12
  %12 = partial_apply [callee_guaranteed] %11(%0) : $@convention(thin) (Float, Float) -> Float // user: %19
  %13 = builtin "int_cos_FPIEEE32"(%3 : $Builtin.FPIEEE32) : $Builtin.FPIEEE32 // user: %14
  %14 = struct $Float (%13 : $Builtin.FPIEEE32)   // user: %18
  // function_ref closure #1 in _vjpCos(_:)
  %15 = function_ref @$s16_Differentiation7_vjpCosySf5value_S2fc8pullbacktSfFS2fcfU_ : $@convention(thin) (Float, Float) -> Float // user: %16
  %16 = partial_apply [callee_guaranteed] %15(%0) : $@convention(thin) (Float, Float) -> Float // user: %19
  // function_ref closure #1 in static Float._vjpMultiply(lhs:rhs:)
  %17 = function_ref @$sSf16_DifferentiationE12_vjpMultiply3lhs3rhsSf5value_Sf_SftSfc8pullbacktSf_SftFZSf_SftSfcfU_ : $@convention(thin) (Float, Float, Float) -> (Float, Float) // user: %18
  %18 = partial_apply [callee_guaranteed] %17(%14, %10) : $@convention(thin) (Float, Float, Float) -> (Float, Float) // user: %19
  %19 = tuple $(predecessor: _AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> (Float, Float)) (%8, %12, %16, %18) // user: %20
  %20 = enum $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0.bb1!enumelt, %19 : $(predecessor: _AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> (Float, Float)) // user: %21
  br bb3(%20 : $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) // id: %21

bb2:                                              // Preds: bb0
  %22 = enum $_AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0.bb0!enumelt, %6 : $() // user: %29
  // function_ref closure #1 in _vjpSin(_:)
  %23 = function_ref @$s16_Differentiation7_vjpSinySf5value_S2fc8pullbacktSfFS2fcfU_ : $@convention(thin) (Float, Float) -> Float // user: %24
  %24 = partial_apply [callee_guaranteed] %23(%0) : $@convention(thin) (Float, Float) -> Float // user: %29
  // function_ref closure #1 in _vjpCos(_:)
  %25 = function_ref @$s16_Differentiation7_vjpCosySf5value_S2fc8pullbacktSfFS2fcfU_ : $@convention(thin) (Float, Float) -> Float // user: %26
  %26 = partial_apply [callee_guaranteed] %25(%0) : $@convention(thin) (Float, Float) -> Float // user: %29
  // function_ref closure #1 in static Float._vjpAdd(lhs:rhs:)
  %27 = function_ref @$sSf16_DifferentiationE7_vjpAdd3lhs3rhsSf5value_Sf_SftSfc8pullbacktSf_SftFZSf_SftSfcfU_ : $@convention(thin) (Float) -> (Float, Float) // user: %28
  %28 = thin_to_thick_function %27 : $@convention(thin) (Float) -> (Float, Float) to $@callee_guaranteed (Float) -> (Float, Float) // user: %29
  %29 = tuple $(predecessor: _AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> (Float, Float)) (%22, %24, %26, %28) // user: %30
  %30 = enum $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0.bb2!enumelt, %29 : $(predecessor: _AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> Float, @callee_guaranteed (Float) -> (Float, Float)) // user: %31
  br bb3(%30 : $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) // id: %31

// %32                                            // user: %37
bb3(%32 : $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0): // Preds: bb1 bb2
  // function_ref pullback of f(_:)
  %33 = function_ref @$s6sincos1fyS2fFTJpSpSr : $@convention(thin) (Float, @owned _AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) -> Float // user: %37
  %34 = integer_literal $Builtin.Int64, 1         // user: %35
  %35 = builtin "sitofp_Int64_FPIEEE32"(%34 : $Builtin.Int64) : $Builtin.FPIEEE32 // user: %36
  %36 = struct $Float (%35 : $Builtin.FPIEEE32)   // user: %37
  %37 = apply %33(%36, %32) : $@convention(thin) (Float, @owned _AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) -> Float // user: %38
  return %37 : $Float                             // id: %38
} // end sil function '$s6sincos3fooyS2fF'

into:

enum _AD__$s6sincos1fyS2fF_bb0__Pred__src_0_wrt_0 {
}

enum _AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0 {
  case bb0(())
}

enum _AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0 {
  case bb0(())
}

enum _AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0 {
  case bb2((predecessor: _AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0, Float, Float, (Float, Float)))
  case bb1((predecessor: _AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0, Float, Float))
}

// foo(_:)
sil hidden [noinline] @$s6sincos3fooyS2fF : $@convention(thin) (Float) -> Float {
[global: read,write,copy,destroy,allocate,deinit_barrier]
// %0 "x"                                         // users: %26, %24, %16, %12, %3, %2, %1
bb0(%0 : $Float):
  debug_value %0 : $Float, let, name "x", argno 1 // id: %1
  debug_value %0 : $Float, let, name "x", argno 1 // id: %2
  %3 = struct_extract %0 : $Float, #Float._value  // users: %13, %9, %5
  %4 = float_literal $Builtin.FPIEEE32, 0x0 // 0  // user: %5
  %5 = builtin "fcmp_olt_FPIEEE32"(%4 : $Builtin.FPIEEE32, %3 : $Builtin.FPIEEE32) : $Builtin.Int1 // user: %7
  %6 = tuple ()                                   // users: %22, %8
  cond_br %5, bb1, bb2                            // id: %7

bb1:                                              // Preds: bb0
  %8 = enum $_AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0.bb0!enumelt, %6 : $() // user: %19
  %9 = builtin "int_sin_FPIEEE32"(%3 : $Builtin.FPIEEE32) : $Builtin.FPIEEE32 // user: %10
  %10 = struct $Float (%9 : $Builtin.FPIEEE32)    // user: %18
  %13 = builtin "int_cos_FPIEEE32"(%3 : $Builtin.FPIEEE32) : $Builtin.FPIEEE32 // user: %14
  %14 = struct $Float (%13 : $Builtin.FPIEEE32)
  %newt = tuple $(Float, Float) (%14, %10)
  %19 = tuple $(predecessor: _AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0,  Float, Float, (Float, Float)) (%8, %0, %0, %newt) // user: %20
  %20 = enum $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0.bb1!enumelt, %19 : $(predecessor: _AD__$s6sincos1fyS2fF_bb1__Pred__src_0_wrt_0, Float, (Float, Float)) // user: %21
  br bb3(%20 : $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) // id: %21

bb2:                                              // Preds: bb0
  %22 = enum $_AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0.bb0!enumelt, %6 : $() // user: %29
  %29 = tuple $(predecessor: _AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0, Float, Float) (%22, %0, %0) // user: %30
  %30 = enum $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0, #_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0.bb2!enumelt, %29 : $(predecessor: _AD__$s6sincos1fyS2fF_bb2__Pred__src_0_wrt_0, Float, Float) // user: %31
  br bb3(%30 : $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) // id: %31

// %32                                            // user: %37
bb3(%32 : $_AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0): // Preds: bb1 bb2
  // function_ref pullback of f(_:)
  %33 = function_ref @$s6sincos1fyS2fFTJpSpSr : $@convention(thin) (Float, @owned _AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) -> Float // user: %37
  %34 = integer_literal $Builtin.Int64, 1         // user: %35
  %35 = builtin "sitofp_Int64_FPIEEE32"(%34 : $Builtin.Int64) : $Builtin.FPIEEE32 // user: %36
  %36 = struct $Float (%35 : $Builtin.FPIEEE32)   // user: %37
  %37 = apply %33(%36, %32) : $@convention(thin) (Float, @owned _AD__$s6sincos1fyS2fF_bb3__Pred__src_0_wrt_0) -> Float // user: %38
  return %37 : $Float                             // id: %38
} // end sil function '$s6sincos3fooyS2fF'

corresponding transformation of the pullback.

[Design] Autodiff Pullback Closure Specialization Optimization
What is it?
This optimization can help alleviate heap allocation costs associated to closures by eliminating usage of closures altogether, in certain call-sites.
Given a function call-site, if the callee takes a closure as an input argument and then calls the closure in its body, we can eliminate the overhead of the closure context's heap allocation by -

Cloning the original callee.
Moving the closure creation (the partial_apply instruction) from the body of the caller to the body of the cloned callee (where the corresponding apply of the closure lives).
Changing the cloned callee's signature to take the partially applied arguments, instead of the closure.
Modifing the apply site in the caller to call the specialized callee.
Getting rid of the closure creation (the partial_apply now in the cloned callee) altogether via peephole optimizations.

Using this optimization, SIL code like this:
sil [noinline] @takes_closure : $@convention(thin) (Int, @owned @callee_owned (Int) -> Int) -> () {
bb0(%0: $Int, %1: $@callee_owned (Int) -> Int):
  %4 = apply %1(%0) : $@callee_owned (Int) -> Int
  %9999 = tuple()
  return %9999 : $()
}

sil [noinline] @partially_applies : $@convention(thin) (Int) -> () {
bb0(%0 : $Int):
  // `multiplies_two_ints` is a defined function
  %1 = function_ref @multiplies_two_ints : $@convention(thin) (Int, Int) -> Int
  // Create a closure out of `multiplies_two_ints` by partially
  // applying one of the integer arguments.
  %2 = partial_apply [callee_guaranteed] %1(%0) : $@convention(thin) (Int, Int) -> Int
  %3 = convert_function %2 : $@callee_guaranteed (Int) -> Int to $@callee_owned (Int) -> Int
  // Pass the closure created out of `multiplies_two_ints` to `takes_closure`
  %4 = function_ref @takes_closure : $@convention(thin) (Int, @owned @callee_owned (Int) -> Int) -> ()
  %5 = apply %4(%0, %3) : $@convention(thin) (Int, @owned @callee_owned (Int) -> Int) -> ()
  %9999 = tuple()
  return %9999 : $()
}

Will look like this:
sil shared [noinline] @specialized_takes_closure : $@convention(thin) (Int, Int) -> () {
// %0                                             // user: %5
// %1                                             // user: %3
bb0(%0 : $Int, %1 : $Int):
  // function_ref multiplies_two_ints
  %2 = function_ref @multiplies_two_ints : $@convention(thin) (Int, Int) -> Int // user: %3
  // This partial apply can be optimized away altogether via peephole optimizations
  // since the corresponding apply is also in the same block at %5.
  %3 = partial_apply [callee_guaranteed] %2(%1) : $@convention(thin) (Int, Int) -> Int // user: %4
  %4 = convert_function %3 : $@callee_guaranteed (Int) -> Int to $@callee_owned (Int) -> Int // user: %5
  %5 = apply %4(%0) : $@callee_owned (Int) -> Int
  %6 = tuple ()                                   // user: %7
  return %6 : $()                                 // id: %7
}

sil [noinline] @partially_applies : $@convention(thin) (Int) -> () {
// %0                                             // users: %6, %6, %3
bb0(%0 : $Int):
  %1 = function_ref @$s13takes_closure19multiplies_two_intsSiTf1nc_n : $@convention(thin) (Int, Int) -> () // user: %6
  // `takes_closure` has been specialized and now takes the originally closed over
  // arguments instead of the closure.
  %2 = apply %1(%0, %0) : $@convention(thin) (Int, Int) -> ()
  %3 = tuple ()                                   // user: %9
  return %3 : $()                                 // id: %9
}

See here for a high-level description of the general Swift closure specialization optimization.
Limitations of the general closure specialization optimization
The general closure specialization optimization operates under numerous restrictions. The ones most directly affecting AD are:

Callsites with multiple closure arguments are not handled (NOT handled in this design. Will be handled in the general closure specialization optimization).

Pullbacks taking multiple intermediate closures are not optimized.

Closures must be passed as arguments directly visible to the compiler (Handled in this design).

Pullbacks with control flow are not optimized since the closures are hidden behind branch trace enums.

Design
This optimization is going to be implemented as a SILFunctionTransform.
Pre-optimization steps

Exit early if function is in a module that does not import _Differentiable.

Optimization steps
Note - The below steps are a rough estimation and not set in stone.

Some terminology used below -

branch trace enum - An enum that records the execution flow of a differentiable function with control flow. Anatomically,
a branch trace enum consists of other branch trace enums and together with the cases/variants of these enums we essentially get a graph of the execution flow of the concerned function.
chain of creation - Refers to the list of SSA values that culminate into the final branch trace enum.
node - Can be thought to have a one-to-one mapping to a case/variant of a branch trace enum.

Gather call-sites in a function

Find all callsites where one of the arguments to the ApplyInst is an AD branch trace enum.
Collect this callsite if the AD branch trace enum is non-trivial -- due to the enum wrapping intermediate pullback closures.

Below steps are per callsite of interest

From the callsite, trace up the chain of creation of the branch trace enum, until you're at the top node.

Generate a specialized branch trace enum by tracing down the same chain of creation (No code will be modified at this point).

At each point where we add a node to the trace

If the parent enum is non-trivial, i.e., one or more of its cases contain intermediate pullback closures

A specialized version of the enum will need to be created. Find out if such a version already exists and if not, create it.
If the current case being looked at has a non-trivial payload

Add a corresponding specialized case/variant to the specialized enum. This specialized case's payload, should consist of the values that the original pullback closure was closing over instead of the pullback closure itself.
If the payload of the original case also contains another branch trace enum, we should replace it with a specialized version, if one exists.

Else, add a corresponding trivial case to the specialized enum as is.

Else if the parent enum is trivial

Re-use the existing enum. No further changes required.

Clone the callee.

From the top of the chain of (branch trace enum) creation in the caller

Modify all the branch trace enum creation steps to use the specialized branch trace enum.
Move PartialApplyInst from the caller to the cloned callee.

Information regarding where this PartialApplyInst is copied to, in the cloned callee, can be derived from the original branch tracing enum.

Ensure that any originally captured values, that are now being passed to the callee directly have their reference counts adjusted properly.

Insert an additional retain for each originally captured argument with reference semantics.

Post-optimization steps

Peephole optimizations to get rid of any partial applies moved to the cloned callee.
Peephole optimizations to get rid of any dead instructions in the caller or the cloned callee.

Location in optimization pipeline
Right after the current position of the general closure specialization optimization pipeline seems like a sane default to start out with.
Open questions for discussion
Q. What happens to old branch tracing enums?
Ans. They should likely stay around. Removing them might require modification/regeneration of the existing code that might still use them.
Q. What happens to old pullback?
And. Same as above.

@asl Could you take a look at the brief design write up for our AD specific closure specialization optimization?

Tagging @BradLarson as well
Overall, I think some steps / part would likely need some clarification.

Given a function call-site, if the callee takes a closure as an input argument and then calls the closure in its body, we can eliminate the overhead of the closure context's heap allocation by -

Note that in AD case the closure it not passed as input argument directly. Instead it's buried deep inside a linear map tuple.

Collect this callsite if the AD branch trace enum is non-trivial -- due to the enum wrapping intermediate pullback closures.

What does it mean "branch trace enum is non-trivial"? Separate enums are created for each BB. So, if the last BB of the function does not have any calls / predecessors, the corresponding enum will be quite trivial (e.g. no tuple payload).

From the callsite, trace up the chain of creation of the branch trace enum, until you're at the top node.

What does this mean? What is the "node" here? What is the "top node"?

If the parent enum is non-trivial, i.e., one or more of its cases contain intermediate pullback closures

What do you mean as "parent enum"? Note that you need to operate on the function as a whole as case / payloads for branch trace enum for a basic block are predecessor basic blocks and corresponding linear map tuples. Also, you need to build everything at once at RPOT-manner otherwise we'd end with the same type lowering issues as we already faced previously.

Information regarding where this PartialApplyInst is copied to, in the cloned callee, can be derived from the original branch tracing enum.

Can you please expand "can be derived" case? It seems the most important thing here.

Insert an additional retain for each originally captured argument with reference semantics.

What are "arguments" here? Arguments of original function? I am confused. Do you have an example where this would be necessary?
In general, it would help if each of the steps will be illustrated by some SIL example, so we can review the meaning of each step.

They should likely stay around. Removing them might require modification/regeneration of the existing code that might still use them.

What "existing code" you're referring to? Certainly we can safely delete the unused enums.

And. Same as above.

Again, we can safely remove unused code. Pullback function does not exist as a separate entity, it's an internal implementation detail. And if unused, could be dropped entirely.

We discussed the intended optimization and its scope with @jkshtj. He will prepare a refined proposal.

@asl @BradLarson I've revised the proposal. I've rewritten it a gist here. Could you please take a look?
P.S. - Let me know if you are not able to access it.

Here are my comments:

Pre-optimization steps

You need also ensure that pullback is a private function. While this is always currently, but it's an implementation detail as of now.

Exit early if the VJP has already been optimized.

How would you determine it?

trivial payloads.

Again, you need to define what trivial payload is.

Top-level closures - these are directly closed over by the returned pullback.

Isn't this case covered by the generic closure specialization transformation? Why would we need to reimplement it?

Generate specialized pullback and move code from VJP to it.

How would you handle various ownership-related things?

VJPs themselves should not have been inlined.

There is some contradiction here. This is all possible if all nested VJPs would be inlined into a top-level VJP. Otherwise you won't see these nested pullbacks (partial apply's).

Considering the above points, this pass should run after inlining into VJPs

You definitely need to restart pipeline after this transformation.


Easy: Concept parameter mode usage checking

Check misuse of # notation in the ensures clause wrt parameter mode. These may be warnings as opposed to errors.

@rhit-csse-projects/t17-2425
Suppose there is a parameter X
When to issue a warning by different parameter modes:

restores X or preserves X or evaluates X: issue a warning if the ensures clause includes a #X
replaces X: issue a warning if there is a #X in the ensures clause
alters X: issue a warning if there is an X (i.e., w/o the #) in the ensures clause
updates X or clears X: issue no warnings for these modes

Explanation:

These parameter modes all mean that X = #X, i.e., the outgoing X is equal to the incoming X
The replaces mode means that the operation ignores the incoming value
The alters mode means that the outgoing value is unspecified

[ ] Write Unit tests to understand Exp.java and it's related things.
[ ] Write tests to check for variables within an expression.
[ ] Locate implementation location for raising warnings
[ ] Raise warnings and add to .asrt output files


Massively buff the accuracy of the c20-r

About the PR
The c-20 has received a massive accuracy buff, it is able to be reliably used one-handed, and is viable at longer range when wielded.
Why / Balance
I often feel that the c-20 got a terrible deal when gun wielding was made the standard. It was already rather weak compared to other weapons nukies have access to and now it generally isn't worth running. It eats up ammo like crazy and because of it's inaccuracy it only hits a third of it's shots, so by the time you're halfway through the station you're out of magazines and either relying on an esword or looting guns from the crew.
Now it has it's own use as a weapon for either midrange combat, or use with another weapon such as an esword or shield. If I overcompensated I'd be fine with making it a bit more inaccurate, but I feel having it be on-par with the wt550 (which doesn't need to be wielded) for accuracy when wielded is good.
The price of the c-20 has also been increased by 3 tc to be in line with the bulldog.
Media
https://github.com/user-attachments/assets/6659b4d0-096a-481c-a432-30ef97035114

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
Make sure to take this Changelog template out of the comment block in order for it to show up.
:cl:

tweak: The c-20r is now significantly more accurate, and able to be reasonably used one-handed.
tweak: The c-20r now costs 20 tc

Accuracy is supposed to be universal across the same weapon class in lieu of a better overall system.

Accuracy is supposed to be universal across the same weapon class in lieu of a better overall system.

What do you mean by "a better overall system"?


structure collection

At first I want to thank all of you for your help, didn't expect this to become that big :).
All those contributions lead to fact that we need some kind of structuring.
When I enter this repo I feel a little bit overwhelmed with this amount of files.
The question that raises is "What's the right way?". Order them by data types, differentiate between function, performance and readability tricks, etc.. Maybe you guys even decide, that we should leave it as it is.
Feel free to add your opinion :)

Seems like there is no demand.


mini.jump - can not repeat jump with ";" - but "f" is working

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md
[X] I have updated 'mini.nvim' to latest version

Module(s)
mini.jump
Description
When start jumping (e.g. fe to jump to the next e) and repeat the jump with ; an error is shown instead jumping to the next occurance. Do the next jump with f is working. Going backward with ""F" or "," is also working.
mini.nvim is isntalled in version 0.11.0.
It is activated in LazyVim with

require("mini.jump").setup()

so the defaults of https://github.com/echasnovski/mini.jump/blob/main/lua/mini/jump.lua#L95 are used
Neovim version
0.9.4
Steps to reproduce

Open a buffer
start jumping (e.g. fe to jump to the next e)
when pressing ; a error is shown

Can not jump because there is no recent target.

Expected behavior
After pressing ; the cursor jumps to the next occurance of the searched character.
Actual behavior
An error is shown

Can not jump because there is no recent target.

Thanks for the issue!
Unfortunately, I can not reproduce. The following steps worked on Neovim 0.9.5 and Neovim Nightly, on 'mini.nvim' 0.11.0 and main:

Open Neovim with some file containing letter e.
Press f, e. It jumps to the e.
Press ;. It jumps again.

Besides that, I am fairly confident that should work as there is a passing test specifically for that.
I would like to ask you for the following steps:

Execute :map ; to see if there is any conflicting mapping for ;. Ideally this should show three mappings in different modes, all related to 'mini.jump'. Something like this:

Disable all plugins except 'mini.jump' and try to reproduce the issue with this minimal setup.

Here is the current mapping of ;

Yes, you are right.
After disable all Plugins but mini.jumo it is working.
When I activate the LazyVim plugins, the ; jump is not working anymore

{ "LazyVim/LazyVim", import = "lazyvim.plugins" },

When I only activate LazyVim without the plugins

{ "LazyVim/LazyVim" },

it is working.

Yes, you are right.
After disable all Plugins but mini.jumo it is working.

Then it is not an issue with 'mini.jump', sorry. Closing as not related

There is some plugin conflicting with 'mini.jump'. Maybe it defines mapping for "f"?  Also repeating the jump with these keys and also , for going backwards

f is not bind to mini.jump

Yeah, so the jump you see is from 'flash.nvim', not from 'mini.jump' If you wan to use 'mini.jump' specifically, don't load 'flash.nvim'.

I will try that. I have to figure out how to disable this in LazyVim
Thanks for your help and thank you for these great mini-plugins

With this setting within my Plugin Folder flash is disabled and mini.jump works as expected

return {
"folke/flash.nvim",
enabled = false,
}

https://www.lazyvim.org/configuration/plugins#-disabling-plugins


Azure CLI version confusion

This page says you need Azure CLI version 2.4 but the latest version is 2.37.
???!!!!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 47cb39a6-cd9e-4f02-b31b-1e09d6a7fa3f
Version Independent ID: eeb0f211-80b7-9006-72e1-b72b6a58fa8d
Content: Create a Java function from the command line - Azure Functions
Content Source: articles/azure-functions/create-first-function-cli-java.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

37 is bigger than 4.


Implement higher level API

xsimlab exposes underlying DataArrays nicely, but we need a higher level API to ease the egress from YAML configuration file to xs.variable. This API would be able to dynamically load input variables from YAML configuration files and/or its own attributes.

Include a click CLI that allows one to select and run one of the packaged models.


Add profile & platform argument in cartography cli

Hi Team,

Request to add --profile <aws-account-name/aws-account-number> attribute in cartography cli so that individual account could be identified and bifurcated on Neo4j console.

Eg; cartograph was executed for 2 different AWS account via separate teams. But both of them merged the sync data in single "default" profile in Neo4j.
Team A:
INFO:cartography.intel.aws:Syncing AWS account with ID 'AAAA' using configured profile 'default'.
Team B:
INFO:cartography.intel.aws:Syncing AWS account with ID 'BBBB' using configured profile 'default'.

Request to add --platform <aws/gcp> attribute in cartography cli so that cartograph should not be running unnecessary steps/cycle.

Thank You.

1 -- the profile name is not added to the neo4j DB at all, it's logged primarily for debugging purposes (to determine which AWS creds were used to sync a particular account). The use case you described here should work as-is. Have you seen bugs or unexpected behavior when doing this?
2 -- our recommendation in this case is to create a custom sync script and call that. We don't have any docs on how to do this right now. This is an area we definitely need to improve, especially as we add more intel modules.

Thank You @ecdavis for the reply.
1 -- No, issue/bug observed.
2 -- Sure, Thank You.


QR code for WhatsApp does not generate

I wanted to pair the Station with WhatsApp but I cannot get the QR code, there is this circle moving. I restarted the Station, reset the app (WhatsApp), reloaded, did not help

I have macOS 11.5 (the latest public beta)

Not only WhatsApp but Telegram too. I can reproduce this problem

Same here using Mac OS 10.15.7 Catalina

This one is really tragic. I was hoping it would at least work out of the box...

This one is really tragic. I was hoping it would at least work out of the box...

I am taking it as a beta version, I hope somebody will fix it after the company went wrong last September and bankrupted (my guess from today's e-mail).

Not only WhatsApp but Telegram too. I can reproduce this problem

EDIT: I'm on macOS Big Sur 11.4 and installed Station v2.0.9

Same setup here and also the same problem.

This issue here is related to https://github.com/getstation/desktop-app/issues/9
Most issues that have been filed yesterday kinda depend on this Electron upgrade. I tried to either add Telegram or WhatsApp by myself or even Gmail as you can see in that issue here: https://github.com/getstation/desktop-app/issues/2 but they all won't work because the Google Chrome Version used in the current Electron version is outdated.
So if I try to add WhatsApp by myself, WhatsApp will tell me (and others too), that Google Chrome is outdated and that I need to update it.
As @magne4000 described this as rather difficult to add, who knows when there will be a fix for this issue here

I think what baffles me most is that in the closed-source version of station, this worked fine. So I believe that the issue is complex, but also they clearly already have fixed it, and given that I am confused by why it regressed or how it would be difficult to apply a fix that has already been made on the same software 🤔
I'm sure there's something going on that I just dont understand here, but it's also disappointing to hear that the software will be open sourced, and then a version that doesn't really work at all is open sourced with a "complex issue" in it that nobody knows when will be fixed.

hi all,
Do we have a workaround for the time needed to get the current open source release fixed ?
Where can I download the latest proprietary version of station ? ... my google search did not point me to some reasonable station.dmg.
Greetings Thomas

Any update on this?
Looks like a major issue that affects many people/service and makes the app not much useful.

Yep. Discord qr, telegram, whatsapp qr all not loading. At least in discord we can login with mail, pass. But for telegram and whatsapp we can't even login as qr is not loaded.
I've looked at Franz, Ferdi and Rambox and this looks more polished than all of them. Can anyone suggest better alternatives for mac?

I'm having the same issue, hope this can get fixed soon.

I have this issue too.

I think what baffles me most is that in the closed-source version of station, this worked fine. So I believe that the issue is complex, but also they clearly already have fixed it, and given that I am confused by why it regressed or how it would be difficult to apply a fix that has already been made on the same software 🤔
I'm sure there's something going on that I just dont understand here, but it's also disappointing to hear that the software will be open sourced, and then a version that doesn't really work at all is open sourced with a "complex issue" in it that nobody knows when will be fixed.

Here's an open-source aggregator for all your chat/comms platforms - but none of them work. Yeah, great..... I was using Franz for a while, but I a) loathe having to make yet ANOTHER user account for no appreciable reason other than for tracking purposes which is not a good enough reason, and b) limited to 3 services on the free version WITH a random 15-second ad which forces you to keep the window in the foreground until the countdown ends so you can clear the ad and get access to your chats. This is a whole wide mess, and I agree with you @jescalan while it may be complicated, when the platforms they're supposed to support DON'T WORK, then where's the utility in a project like Station?

Same as @SnShine .. Station is looking nice. But without being able to login to services it not very useful :)
Any good alternative for Mac?

Unsure if anyone is aware of this: https://medium.com/@julien_26779/handing-station-to-mankind-b1225e4e7413
With all my optimism, I doubt this bug will be fixed then. Sorry to see such a great app becomes history soon.
I changed back to Rambox. It doesn't have that nice UI as Station has, but it works.

Unsure if anyone is aware of this: https://medium.com/@julien_26779/handing-station-to-mankind-b1225e4e7413
With all my optimism, I doubt this bug will be fixed then. Sorry to see such a great app becomes history soon.
I changed back to Rambox. It doesn't have that nice UI as Station has, but it works.

You can have a look at https://stackbrowser.com/

This is also a good alternative with very similar UI: https://getferdi.com/download/

I'm still having the same issue. I'm on macOS 11.5.2

Unsure if anyone is aware of this: https://medium.com/@julien_26779/handing-station-to-mankind-b1225e4e7413

Guys, the fact is that the original creators left the Community version behind and they handed over to the mankind. Pretty pointless adding any more comment about the sad reality that doesn't work. They won't fix it regardless how much we moan about it. :/
Either we all move to an active alternative or anyone feel free to make the change as a PR. That hopefully gets merged.
I know nothing about JS so I can't do anything. I'm following this thread simple because waiting for a notification about a new PR that makes it closed :)

Well. Nice to know. Thank You.
Now we know we can DEFINITELY change provider.
Il Gio 16 Set 2021, 20:31 realrill @.***> ha scritto:

Unsure if anyone is aware of this:
@.***_26779/handing-station-to-mankind-b1225e4e7413
Guys, the fact is that the original creators left the Community version
behind and they handed over to the mankind. Pretty pointless adding any
more comment about the sad reality that doesn't work. They won't fix it
regardless how much we moan about it. :/
Either we all move to an active alternative or anyone feel free to make
the change as a PR. That hopefully gets merged.
I know nothing about JS so I can't do anything. I'm following this thread
simple because waiting for a notification about a new PR that makes it
closed :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/getstation/desktop-app/issues/3#issuecomment-921094708,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFPHUVOFON4BCPMD7H3ZIJDUCISVTANCNFSM5ALQTSJQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Root cause might be that Chrome used within Station is outdated, see e.g. https://www.ecosia.org/search?q=whatsapp+qr+code+not+loading
Station 2.0.9 seems to use Chrome 78.0, which dates back to 2019-10. See 'Help' > 'About Station'. Current version of Chrome would be 94.0, as of 2021-10.
So my guess is that Chrome has to be updated...

Root cause might be that Chrome used within Station is outdated, see e.g. https://www.ecosia.org/search?q=whatsapp+qr+code+not+loading Station 2.0.9 seems to use Chrome 78.0, which dates back to 2019-10. See 'Help' > 'About Station'. Current version of Chrome would be 94.0, as of 2021-10. So my guess is that Chrome has to be updated...

don't think that the version of Chrome is an issue. I am still using the older version of Station - 1.65.0 - and that too uses the older version of Chrome - 78, but the whatsapp-webb QR Code loads and lets me log in.

why did I decide to upgrade to the latest release 🤦🏽

why did I decide to upgrade to the latest release 🤦🏽

I can confirm reverting to my old version works (also 1.65.0 but on MacOS BigSur 11.4)

why did I decide to upgrade to the latest release 🤦🏽

I can confirm reverting to my old version works (also 1.65.0 but on MacOS BigSur 11.4)

How can I revert to that old version??):

@A01378939, you can download it using this link for Mac.

why did I decide to upgrade to the latest release 🤦🏽

I can confirm reverting to my old version works (also 1.65.0 but on MacOS BigSur 11.4)

How can I revert to that old version??):

I deleted my app and managed to recover it from my trash can..

@A01378939, you can download it using this link for Mac.

I have windows and the link does't load for me, maybe for the same fact that I'm on windows))):

why did I decide to upgrade to the latest release 🤦🏽

I can confirm reverting to my old version works (also 1.65.0 but on MacOS BigSur 11.4)

How can I revert to that old version??):

I deleted my app and managed to recover it from my trash can..

Is there a way you could maybe upload the .exe file for me to install? 🥺

Same problem here. I'm using Windows 11.

This is still happening 😢
Using the lastest beta version on mac os 13.0

Yup same here, I guess Station is no longer maintained


Always redirecting to iOS App Store

I have defined random scheme in Project 1 (left side), called it 'dashboss'
and tried to use this plugin to check for being installed and launch it.

But I am unable to launch the app and it keeps saying Redirecting to AppStore as the app is not present on the device
What could be the issue?

Have you added
<key>LSApplicationQueriesSchemes</key> <array>   <string>dashboss</string> // url scheme name of the app </array>
in the info.plist file?

Yes I did @sarika01
but still getting this the following logs
flutter: installed -> 0
flutter: App not found in the device

all of tests are on the simulator btw...

@sarika01 any update on this? I need this for an urgent task...

@bismarabia
Can you check for ios app store link once ?
Also try to set
openStore:false
In main.dart file  and test the case.

@GayathrideviGA @sarika01
it still says flutter: App not found in the device
this is from app I want to launch.
<key>LSApplicationQueriesSchemes</key>
<array>
    <string>pulsesecure</string>
</array>

and this is from the app I'm launching from
await LaunchApp.openApp(
    androidPackageName: '{packageID}',
    iosUrlScheme: 'pulsesecure://',
);

I tried this in iOS from a simulator (debug mode).

@sarika01 @GayathrideviGA  any update on this?

@bismarabia
Try to check the case with a real device as some times simulator could not able to open up App Store link it results app not found exception. Also it seems it works well with android device so try to debug it with real device with openStore: true .

@GayathrideviGA  This issue keeps happening, seems like the library is only working Android, but not working on iOS.
@bismarabia Were you able to fix it in the end, I would really appreciate some help on this, otherwise, I will need to find another library :/

Hi @keylinwu-wmg
It works fine on Android. I tested it....
for iPhone. it doesn't work on simulator at all. I tested it on a real iPhone release mode and it always directs to AppStore even thought the app is installed.
For me, it's ok, at least at this point, I'm gonna leave it like this since the user can open the app from AppStore, it will say "OPEN"  if installed, "GET" otherwise.
Looking forward to seeing a fix for this issue. @jaiswalshubham84 @Gayathri-GA

To overcome this issue, I'm using this package (2.0.2) along with url_launcher 6.0.18:
if (Platform.isAndroid) {
  if (await LaunchApp.isAppInstalled(androidPackageName: appId)) {
    await LaunchApp.openApp(
        androidPackageName: appId
    );
  } else {
    launch(storeUrl);
  }
} else if (Platform.isIOS) {
  if (await canLaunch(appId)) {
    launch(appId);
  } else {
    launch(storeUrl);
  }
}

The support for Android V2 embedding is now available in external_app_launcher: ^3.0.0


Split subset and datetime/bbox

While it is very easy to support datetime and bbox (usually), it is much more work to actually implement subset with it A-Q(!) requirements. I'd propose to split subset and datetime/bbox into separate conformance classes to allow for an easy entry path.

In issue #188 we propose to simply those requirements to make it easier to implement subset.
Making them separate requirements classes would really defeat the purpose: the intent is that a client can always reliably use one or the other if subsetting is supported.

I don't understand why that would defeat the purpose (of what?)
Not sure whether it's better if I throw a 501 NotImplemented for subset just because someone randomly decided to put them in one conformance class.

Throw a 501 with a Not Implemented message until you have a chance to parse the subset= parameter and map it to your datetime and bbox implementation.

So throwing a 501 would be valid according to the spec? I actually don't plan to implement subset because for my case it doesn't offer anything on top of datetime/bbox (just having spatial and temporal dimensions).

So throwing a 501 would be valid according to the spec

It would not pass the compliance tests, but hopefully you will be bored one afternoon between now and the time when the ETS is ready to test your implementation, and you'll be able to implement the plumbing to re-reroute the subset request to your bbox / datetime implementation ;)
For the Testbed 20 TIEs, we can make sure the clients use whichever method you have implemented, if you don't have time or want to focus on other things before implementing subset.
subset is an alternative to datetime, bbox for spatial and time. subset is inherited from WCS so we keep it for the standard to be familiar for that community.

I don't say it should be removed, I just ask that there are two conformance classes, one for subset, one for datetime+bbox.
It's pretty much just a waste of time to implement the complex subset if you don't have other dimensions. So why require it? Didn't find a reason for it yet...

@m-mohr As I explained, so that clients can reliably use one or the other.
subset is the original parameter for WCS.
datetime and bbox are convenience parameters added in OGC API - Coverages.
A separate conformance class should provide different capability.
If the convenience is only available in some implementations, it's not a convenience, it's a hindrance.

100% disagree.
Why is it less reliable if they are split into two conformance classes? You can determine by the conformance classes which are available and can be used.
It rather feels LESS reliable if they are in one conformance class if that leads to 501's.

As an aside, 501 is almost never an appropriate response. According to HTTP Semantics:

[501] is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

So, if the server returns 501 on a GET request, the server states that it does not recognize the GET method for any resource.

Not sure this helps. My take is that good practice (and the ModSpec) suggest that each requirements class and associated conformance test class have a constrained set of related and testable properties - such as one requirements class for specifying a horizontal CRS and one requirements class for specifying a vertical CRS. Mixing those two together into one requirements class causes confusion and probably many test failures. Many implementations only care about horizontal CRS and not vertical CRS. Hence, better to separate.
The ModSpec does provide requirements and guidance. For example, Req5: All conformance tests in a single conformance test class in a conformant standard SHALL have the same standardization target. And Req1: All the parts of a requirement, a requirements module, or requirements class SHALL be testable. Failure to pass any part of any requirement shall be a failure to pass the associated conformance test class.
And various Requirements state: A standard may have mandatory and optional requirements classes. This allows the options in the testing procedure to be grouped into non-varying mandatory and optional conformance classes. Each requirement within an optional requirements class is mandatory when that requirements class is implemented. When needed, a particular requirements class may contain only a single requirement.

@cnreediii If you apply that to this issue, what would that mean? I'm not sure I can really follow and conclude on something based on your message...

@m-mohr I am saying  "I'd propose to split subset and datetime/bbox" I would also say any requirement that has A-Q "sub" requirements is waaay too long and complex!

Why is it less reliable if they are split into two conformance classes? You can determine by the conformance classes which are available and can be used.

Clients can choose to implement only subset or datetime/bbox if "subset" is supported.
Having to use a different parameter based on the supported requirements class would mean that clients wanting to be interoperable with any implementation supporting subsetting one way or the other would need to implement support for both.
So that would be forcing the client instead to implement both, complicating the development of clients at the cost of making it a bit easier for implementing subsetting on the server side.
There tends to be a greater variety of clients than servers, hence the decision to require server implementations to implement both approaches instead.

501's or implementation that don't report the conformance class because they only implement parts of it.

Implementations should support both, so a conforming implementation should not be returning a 501.

As an aside, 501 is almost never an appropriate response.

I am understanding this as @cportele saying it would be better to return a 400 for an unsupported parameter until it is implemented.

Can you point me to where this OGC policy is written? I don't think this is a thing as it's not followed by various specs, e.g. OGC API - Processes.

I don't think that's an OGC policy, but it is a design principle which makes a lot of sense to me, for the reasons stated above.
The guidance from the ModSpec does not seem to address how to map functionality to requirement classes, beyond what @cnreediii mentioned above. In my opinion, there should be guidance in the ModSpec that a requirements class gathers a particular set of functionality. An alternative way to do the same things for convenience should not be split out. Multiple mandatory requirement classes should be grouped together in a "Core".
The same subset + datetime, bbox organization is in OGC API - Tiles and OGC API - Maps:
This follows the exact same pattern.
subset=time() and datetime support in OGC API - Tiles:
http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/datetime
subset=time() and datetime support in OGC API - Maps:
https://www.opengis.net/spec/ogcapi-maps-1/1.0/req/datetime
Spatial subsetting in OGC API - Maps:
https://www.opengis.net/spec/ogcapi-maps-1/1.0/req/spatial-subsetting
There is no spatial subsetting in Tiles, since the 2DTMS row/column already takes care of that.
There is also general subsetting in Maps:
https://www.opengis.net/spec/ogcapi-maps-1/1.0/req/general-subsetting
which is through the subset parameter only. General subsetting is not specified in OGC API - Tiles, but it can also be supported and is specified for Map Tiles in OGC API - Maps, and Coverages Tiles in OGC API - Coverages.
I am still very strongly opposed to the idea of splitting the convenience parameter datetime from subset=time, or the convenience parameter bbox from the corresponding subset=Lat(), Lon() / subset=E(),N(), because they ought to be together to be a convenience, and that is the approach in Maps & Tiles with the explicit intent that it would be consistent with Coverages.
Regarding @cnreediii 's comment about:

one requirements class for specifying a horizontal CRS and one requirements class for specifying a vertical CRS

There are actually not separate CRS in the spatial subsetting requirement classes, perhaps with the exception of EDR.
bbox supports 4 or 6 coordinates and we have 3D CRSs like CRS84h and EPSG:4979.
Regarding the extra atmospheric pressure levels, after much discussion (e.g., https://github.com/opengeospatial/NamingAuthority/issues/228 ) the decision was that this is completely separate from the CRS and fits within the general subsetting mechanism.
I would personally have less of an issue with splitting the subsetting requirements class into "temporal subsetting", "spatial subsetting" and "general subsetting" (than splitting the convenience parameters), as it is in OGC API - Maps. I'm not sure whether others in the Coverages community would be happy with this though, since in general there is a strong desire to keep the nature of coverage dimensions arbitrary.

I would also say any requirement that has A-Q "sub" requirements is waaay too long and complex!

This split would help with that. As an implementer, I personally find it much easier to have all related aspects of one parameter within the same requirements (to the extent that this is practical), than having to look through multiple requirements to see whether it is related to the same parameter. A-Q are all about the subset parameter. I do agree it's a lot of letters :)

Well, then my conclusion from this is that there shouldn't be two options for simplicity but just one, I.e. remove datetime/bbox. The same applies for scaling where se options pretty much do the same.

@m-mohr The reason datetime and bbox are there is for the convenience of clients / users familiar with these parameters, for examples those familiar with WFS, WMS, and OGC API - Features.
In Maps and Tiles, we did the opposite, add subset in additional to the traditional bbox in WMS, so that it feels familiar to those coming from WCS, and because subset avoids any potential order confusion.
It means a little extra work on the server side, allowing clients to pick their favorite way. It's really not that difficult to parse both parameters. We've discussed all this over a period of 4+ years (for example see #152), and as was brought up at the meeting on Wednesday, we have really been hoping to achieve a stable API rather than going back over decisions taken a long time ago when we had a stronger regular attendance to SWG meetings, and pulling the API in different directions. The consistency with the other OGC APIs (Maps, Tiles) should also be considered.

Okay fair with regards to the removal. I don't see any discussion on splitting into two conformance classes in that issue though.

@m-mohr I meant we had lengthy discussions about whether to add bbox in addition to subset before adding it prior to that issue in 2021. Some of that discussion might have been in SWG meetings and not in issues, but see for example #58 and #84 from 2020, and 10d7312ad71414c3458ac537606c194794946fd6 from December 23, 2019 when the bbox parameter was added.
e.g., https://github.com/opengeospatial/ogcapi-coverages/issues/58#issue-559928188 from Feb 2020

Note, I'd propose this as an additional convenience syntax, as I can se the utility in also being able to subset arrays not expressible by bbox or datetime

I don't really see any discussions about splitting into two conformance classes though. Anyway, I'll shup up now,, seems to be a waste of time to get involved here.

Entertaining discussion and good points from all parties. Not waste of time at all.
For my mind what is best in WCS 2.0 is just explicit subsets subset=Lat(-90:90). No need to think about the CRS and the order of the axis.  Subset is convenient by natur.
Maybe I support @m-mohr, perhaps bbox+time could be removed. On the other hand, I do understand the convenience of bbox for users who have already a bbox for downloading features from OGC API Features and who want to get some coverage data from the same area. Pity that OGC API Features does not support subsets.

Thanks for chiming in @jratike80.
Maps does support both, as do Zone Queries in OGC API - DGGS.
OGC API - Tiles as well for dimensions other than the 2D of the 2DTMS.

We discussed this issue in the OGC API - SWG session in Goyang on November 6, 2024 and there was a general agreement that we primarilty want to make life easier for the client.
Some informative guidance as to how to map the different convenient parameters to more general ones should also be provided to make it easier for servers to support them all.

SWG meeting 2024-11-27 Resolution:

As discussed at the Members Meeting OGC API track, we do not want to separate the convenience parameters from the more general functionality to which they map.
However, it was pointed out that the current requirements are very long, and in practice in sevevral implementations, time, space and additional dimensions are often handled separately. Therefore, we will split the Subsetting requirements class into 3 different ones for: Spatial subsetting, Temporal subsetting, and General Subsetting, which will all share the same syntax for subset. This follows the approach in OGC API - Maps.
The bbox parameter will be introduced clearly as a "convenience" parameter mapping to the subset on the spatial dimensions, after presenting the general subset approach, within the Spatial Subsetting
The datetime parameter will be introduced clearly as a "convenience" parameter mapping to the subset on the primary temporal dimension, after presenting the general subset approach, within the Spatial Subsetting

I am understanding this as @cportele saying it would be better to return a 400 for an unsupported parameter until it is implemented.

Can you point me to where this OGC policy is written? I don't think this is a thing as it's not followed by various specs, e.g. OGC API - Processes.

Agreeing with the latter statement, in the OWS set of API standards an unsupported parameter is ignored, and the service responds according to the supplied supported parameters.  This allows for extensibility


Improve success messages

Two changes here:

Rather than reloading the page whenever a success banner is found, look for the more explicit data-app-reload attribute containing the word "page". The existing forms have been updated to match, but in the future we might want to add flexibility so you can do e.g. data-app-reload="timeline tasks"
In payments forms, instead of showing success messages in-place they now get saved as flash messages and the user is returned to /payments?id=# where they're shown

Fixes VEGA-1513 #minor

Codecov Report
Base: 73.47% // Head: 73.46% // Decreases project coverage by -0.01% :warning:

Coverage data is based on head (6a2cc4b) compared to base (7de6b0b).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #168      +/-   ##
==========================================
- Coverage   73.47%   73.46%   -0.02%
==========================================
  Files          66       67       +1
  Lines        2183     2246      +63
==========================================
+ Hits         1604     1650      +46
- Misses        413      427      +14
- Partials      166      169       +3

Impacted Files
Coverage Δ

internal/server/server.go
84.40% <35.71%> (-7.18%)
:arrow_down:

internal/server/delete_payment.go
77.50% <66.66%> (-3.75%)
:arrow_down:

internal/server/flash.go
82.75% <82.75%> (ø)

internal/server/add_payment.go
68.85% <100.00%> (+2.18%)
:arrow_up:

internal/server/apply_fee_reduction.go
83.78% <100.00%> (+1.96%)
:arrow_up:

internal/server/edit_fee_reduction.go
85.36% <100.00%> (+0.36%)
:arrow_up:

internal/server/edit_payment.go
69.86% <100.00%> (+0.41%)
:arrow_up:

internal/server/get_payments.go
95.16% <100.00%> (+0.16%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


The app crashes when the window is too narrow

The exception on Android:
java.lang.IllegalArgumentException: maxWidth(-104) must be >= than minWidth(0)

The exception on JVM desktop when the window is narrowed:
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: maxWidth(-21) must be >= than minWidth(0)

Related to #29.


Fixes #38 so errors will be logged properly.

Cleaned up some code style and added some comments.

LGTM.