structural recursion over inductive predicates struggle with reflexive inductives

Prerequisites
Please put an X between the brackets as you perform the following steps:

[x] Check that your issue is not already filed:
https://github.com/leanprover/lean4/issues
[x] Test your test case against the latest nightly release, for example on
https://live.lean-lang.org/#project=lean-nightly
(You can also use the settings there to switch to “Lean nightly”)
[x] Reduce the issue to a minimal, self-contained, reproducible test case.
Avoid dependencies to Mathlib or Batteries.

Description
The following code
inductive F: Prop where
  | base
  | step (fn: Nat → F)

def F.asdf: F → True
  | base => trivial
  | step f => F.asdf (f 0)

results in the following error
fail to show termination for
  F.asdf
with errors
structural recursion cannot be used:

Context
This is a variation of a very similar previous issue. Just like previously, making F a Type rather than a Prop makes the error disappear
Steps to Reproduce
Expected behavior: There are no errors, the recursion is recognized as structural recursion.
Actual behavior: The error is present.
Versions
4.11.0-nightly-2024-07-12
Impact
Add :+1: to issues you consider important. If others are impacted by this issue, please ask them to add :+1: to it.

So here is what’s happening. I generalized this a bit to make it clearer
def TTrue (_f : F) := True

def F.asdf : (f : F) → TTrue f
  | base => trivial
  | step f => F.asdf (f 0)
termination_by structural f => f

This gives
Cannot use parameter #1:
  could not solve using backwards chaining
x✝¹ : F
x✝ : x✝¹.below
f : Nat → F
a✝¹ : ∀ (a : Nat), (f a).below
a✝ : ∀ (a : Nat), TTrue (f a)
⊢ TTrue (f 0)

Now it seems strange that this cannot be solved, we have a✝ right there! And indeed it is tried, and the current goal is unified with a✝ ?a, and this unification succeeds. The problem is that the new metavariable ?a : Nat is not assigned during this unification, because f a is a Prop and thus this is solved by proof irrelevance.
Unfortunately, wrapping the search operation in withoutProofIrrelevance does not seem to help.
Anyways, even if we could make lean unify a with 0 here, it wouldn’t help us in your case
failed to infer structural recursion:
Cannot use parameter #1:
  could not solve using backwards chaining
x✝¹ : F
x✝ : x✝¹.below
f : Nat → F
a✝¹ : ∀ (a : Nat), (f a).below
a✝ : Nat → True
⊢ True

where the 0 has disappeared, so a simple backwards chaining search has little hope of finding the right argument to a✝.
TL;DR: With the current architecture, I doubt whether reflexive data types can be supported reliably by the IndPred construction.
@DanielFabian, does this sound about right?

this latter proof state is a bit different from what I would've expected. Why is the def unfolded? I believe in my initial implementation, the algorithm would've simply done an apply a✝. Which should constrain the bound a to be 0 and thus require a proof that 0 : Nat which the metavar would do automatically?
I don't remember seeing definitions being unfolded. Also, what does withoutProofIrrelevance do?

in my original case, the metavar ?a : Nat would've blocked the backwards chaining because there were multiple objects of the correct type, and picking one by assumption could pick the wrong one, thus leading to unprovable goals. Here, the ?a completely disappeared.

Hmm, that seems to be about mkBelow, not about about the equation compiler.

this latter proof state is a bit different from what I would've expected. Why is the def unfolded?

sorry for being unclear; this is from the original example
inductive F: Prop where
  | base
  | step (fn: Nat → F)

def F.asdf: F → True
  | base => trivial
  | step f => F.asdf (f

where the type of the function does not depend on the parameter. So not def being unfolded, the return type of the recursive call simply is True, and thus leads to
x✝¹ : F
x✝ : x✝¹.below
f : Nat → F
a✝¹ : ∀ (a : Nat), (f a).below
a✝ : Nat → True
⊢ True

I wonder if it might help to let-bind the type of the recursive function as a local variable, say C, so that one gets
C : F → Prop := fun _ => True
x✝¹ : F
x✝ : x✝¹.below
f : Nat → F
a✝¹ : ∀ (a : Nat), (f a).below
a✝ : (a : Nat) → C (f a)
⊢ C (f 0)

at least if one is careful not to reduce C. Then at least the information about the arguments isn't lost.

Oh, I like that last idea: perform termination checking and compilation with an abstract motive for the function (in all three variants of termination checking). After all, termination checking is completely independent of the return type and only cares about the arguments. This way, when calculating the functional induction principles, I (hope I) don't have to do so much complicated surgery on the terms (MatcherApp.transform), and maybe a fair amount of complex code can go. We just™ have to be careful not to unfold the let-bound motive unnecessarily. I'll play with that idea some time maybe. And maybe it can help with the present issue as well.

sounds promising, keep me posted, please.


[LIBCLOUD-907] Added DNS driver for OnApp

Added DNS driver for OnApp
Description

Implements driver methods for manipulating DNS zones and records on an OnApp host
Includes tests and documentation

JIRA ticket: https://issues.apache.org/jira/browse/LIBCLOUD-907
Provider API: https://docs.onapp.com/display/52API/DNS+Zones
Status

done, ready for review

Checklist (tick everything that applies)

[x] Code linting
[x] Documentation
[x] Tests
[ ] ICLA

thanks @hackedunit there are some CI errors to check out first https://travis-ci.org/apache/libcloud/builds/215039908

@hackedunit did you mean to close the PR? It won't get reviewed any further if so

@tonybaloney I will open it with a single commit once I fix the issue with the failing builds - just can't figure out what is really failing it. sudo tox passes locally and sudo tox -e docs gives me new errors.

I would hazard a guess and say you added the onapp driver manually to the DNS supported providers table.
It's supposed to be generated by the script in contrib.
run make HTML inside the doc folder

Thanks @tonybaloney. It was actually a duplicate URL reference - fixed it and issued a new pull request here #1017


try with mutliclass

i was tried using multiclass and got some error
find learning rate to train the last layer group first
fucntion when error :
learn.freeze()
learn.lr_find()
learn.recorder.plot()
error message : can't convert cuda:0 device type tensor to numpy. Use Tensor.cpu() to copy the tensor to host memory first.
i search in stackoverflow too but still got error , i read some link and its said , cause i use multiclass , and your example in binary
what should i do ?

Hi there,
When you call CNNTabularModel, did you set out_sz as the number of classes you have? Thanks


[Menu][discussion] Menu height/padding changes in 4.5 should be under a dense flag

In the 4.5 version of Material-UI the height and padding of menu items changed "to better match Google's products" in #17332. I feel like the change was unnecessary to implement as the default just because that's how Google does it. The Material Design menu documentation specifically mentions both a version with more padding as well as a dense option. The Material Design documentation should take precedence over the look of Google's products (which is pretty inconsistent). I don't think the goal of Material-UI should be to clone the look of Google's products but rather be an implementation of Material Design.
It would be a lot more logical to implement these changes under a dense prop this way it's an opt-in functionality and wont mess up the current styles of peoples menu's. Because in my opinion it's not a change that looks better, especially when using a different font than Roboto.

This is one of the most controversial changes we have introduced since v4.0.0. I wouldn't be surprised if we get similar feedback for this change in the future. The component still has a dense mode. It will reduce the font size and apply the same small height it has on the desktop to the mobile environment. As far as I have explored the specification, the instructions are inconsistent.
I believe that both Google products and material.io try to provide a consistent user experience with normalized patterns, but also have to deal with limited resources and prioritize. I have run a benchmark with many Google Products as well as other UI frameworks. I believe it's one of the best tradeoff possible.

So, the new menu items look differently depending on screen size (bigger on smaller screens), as expected/described.
But why selects and checkboxes look differently on the same screen size? Is this done on purpose?

Single choice

Multiple choice

@oliviertassinari do you have any insights about my question?

@pheeria I have faced it a few hours ago. I went with small checkboxes. It could make sense to support a size="small" on the checkbox, similar to #14129.

Any "migration" guide for this? This change has screwed up most of my current UI; I know have different sizes everywhere.

Any "migration" guide for this? This change has screwed up most of my current UI; I now have different sizes everywhere.

@cristianoccazinsp Sure, for people that want to revert the change (to be honest, it's was definitely borderline for a minor), you can apply this patch:
.MuiMenuItem-root {
  padding-top: 4px;
  padding-bottom: 4px;
  min-height: 48;
}

or with the theme:
const theme = createMuiTheme()

theme.overrides = {
  MuiMenuItem: {
    root: {
      paddingTop: 4,
      paddingBottom: 4,
      [theme.breakpoints.up('sm')]: {
        minHeight: 48,
      },
    },
  },
};

Or at least, how can I make and components behave like these menu items? Custom components relying on will now have a smaller size than regular menu/select fields... Very annoying.

You can apply:
.my-class {
  padding-top: 6px;
  padding-bottom: 6px;
  min-height: 48;
}
/* theme.breakpoints.up('sm') */
@media (min-width: 600px) {
  min-height: auto;
}

Additionally, I also need to know what's the item height going to be (due to some custom component that needs to decide on it's height). Where can get this info now that the height might adjust based on the screen size?

We use this approach in the demos:
https://github.com/mui-org/material-ui/blob/f23c7a9bdcf3fc0b7e0eb351b7540bb3054fbc7c/docs/src/pages/components/autocomplete/Virtualize.tsx#L27-L29

Thanks @oliviertassinari , that's very useful!
I'm also wondering, when using dense, the element height does not change based on the device size, is this intended? Shouldn't it behave similarly?

@cristianoccazinsp The dense props behavior is intended, it reduces the font size and is dense on mobile too.


[GOBBLIN-1637] Add writer, operation, and partition info to failed metadata writer events

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[x] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-1637

Description

[x] Here are some details about my PR, including screenshots (if applicable):

Add info of which metadata writer failed in the failure events

Add which operation type failed. To do this, split up the events so that there's a separate event if opType changes, otherwise the event offset ranges could contain multiple different offsets

Add which partition values were intended to be added/dropped as part of these GMCE. To do this added a HiveMetadataWriterWithPartitionInfoException.java only thrown from hive writer in order to pass partition info back to MCE Writer

Fix bug in hive metadata writer where failure in flush would throw RuntimeException, but catch block only catches IOException so fault tolerant behaviour would never work for flush failures

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
Tested in test pipeline

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

@ZihanLi58 please review

Codecov Report

Merging #3498 (9bf7629) into master (3e87795) will decrease coverage by 3.22%.
The diff coverage is 76.36%.

@@             Coverage Diff              @@
##             master    #3498      +/-   ##
============================================
- Coverage     46.68%   43.46%   -3.23%
+ Complexity    10406     2038    -8368
============================================
  Files          2078      405    -1673
  Lines         81283    17482   -63801
  Branches       9077     2137    -6940
============================================
- Hits          37946     7598   -30348
+ Misses        39839     9034   -30805
+ Partials       3498      850    -2648

Impacted Files
Coverage Δ

...pache/gobblin/iceberg/writer/GobblinMCEWriter.java
76.10% <74.00%> (-1.24%)
:arrow_down:

...bblin/iceberg/writer/GobblinMetadataException.java
100.00% <100.00%> (ø)

...a/org/apache/gobblin/util/limiter/NoopLimiter.java
40.00% <0.00%> (-20.00%)
:arrow_down:

...lin/util/filesystem/FileSystemInstrumentation.java
85.71% <0.00%> (-14.29%)
:arrow_down:

.../java/org/apache/gobblin/cluster/SleepingTask.java
39.39% <0.00%> (-6.07%)
:arrow_down:

...in/java/org/apache/gobblin/cluster/HelixUtils.java
31.70% <0.00%> (-4.27%)
:arrow_down:

...apache/gobblin/hive/writer/HiveMetadataWriter.java

...in/broker/gobblin_scopes/GobblinScopeInstance.java

...paction/action/CompactionGMCEPublishingAction.java

... and 1672 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 3e87795...9bf7629. Read the comment docs.


Buffer is not defined

Uncaught ReferenceError: Buffer is not defined
at toHex (to-hex.js:14:1)
at Tag.toTlv (tag.js:19:1)
at to-tlv.js:10:1
at Array.map ()
at toTlv (to-tlv.js:10:1)
at _c (ComponentToPrint.js:17:1)
at renderWithHooks (react-dom.development.js:16305:1)
at updateForwardRef (react-dom.development.js:19226:1)
at beginWork (react-dom.development.js:21636:1)
at beginWork$1 (react-dom.development.js:27426:1)
**It's work fine on codesandbox**
_but when it comes to npx create-react-app I get this message_

I downloaded Buffer as backage, but it didn't help

import { Invoice } from "@axenda/zatca";
function App() {
console.log(Invoice); --- ok
const invoice = new Invoice({
sellerName: "Axenda",
vatRegistrationNumber: "1234567891",
invoiceTimestamp: "2021-12-04T00:00:00Z",
invoiceTotal: "100.00",
invoiceVatTotal: "15.00",
});
console.log(invoice.toTlv()); --- throw error in console
.....

I guess one line solve the problem
I added :
window.Buffer = Buffer;
inside the file
import { Invoice } from "@axenda/zatca";
import {Buffer} from "buffer";
function App() {
window.Buffer = Buffer;
const invoice = new Invoice({
sellerName: "Axenda",
vatRegistrationNumber: "1234567891",
invoiceTimestamp: "2021-12-04T00:00:00Z",
invoiceTotal: "100.00",
invoiceVatTotal: "15.00",
});

Thanks but using this its not solved I got another solution
import * as Buffer from '../node_modules/buffer/index';
(window as any).global = window;
(window as any).process = {};
(window as any).process = window;
(window as any).process.browser = true;
(window as any).process.version = '';
(window as any).process.versions = { node: false };
(window as any).global.Buffer = Buffer.Buffer;
These are need to add in polyfills.ts then issue resolve


API certificate is expired

https://twitter.com/CamOpenAccess/status/1013699902038257664
expired July 1

This was fixed but I forgot to close it. :-(


Support and test compiling with -Z minimal-versions

-Z minimal-versions is an unstable cargo flag to generate a Cargo.lock with the minimal versions possible, rather than the latest ones. This helps finding cases where a crate depends on features of a dependency which were released in a later semver-compatible version than the one reported in the Cargo.toml.
I tried running cargo minimal-versions (which automates a bunch of work you have to do to correctly use -Z minimal-versions) and the result was not that good, although most issues were due to dependencies not respecing minimal versions themself.
I found the following issues (though there could be more hidden, see the final note):

bevy_ecs/bevy_utils should depend on tracing 0.1.36, since that version implemented Value for String which is used in bevy_ecs (although it uses the tracing macros re-exported from bevy_utils);
bevy_reflect should depend on lock_api 0.4.7, since that version introduced the const new function which bevy_reflect uses (also see #9374, this could be considered a bug in parking_lot, since lock_api is a transitive dependency through it);
bevy_reflect should depend on thiserror 1.0.25, since that version introduced the ability to derive Error on non-'static types which is used by bevy_reflect;
bevy_pbr should depend on bitflags 2.3.1, since that version fixes the use of Self:: in the macro, which is used by bevy_pbr;
bevy_render should depend on image 0.24.3, since that version introduced the exr feature flag (before it was called openexr), which is used by bevy_render;
bevy_text should depend on glam 0.24.1, since that version introduced the Vec2::INFINITY associated constant (should be fixed by #9653);
tools/example-showcase should depend on pbr 1.1.1, because pbr 1.1.0 had a bug with imports on Windows;
bytemuck used to declare only a dependency on bytemuck_derive 1 while it actually uses features of bytemuck_derive 1.1 and later. This was fixed on bytemuck 1.12, but bevy crates depend only on older versions of bytemuck (bevy_pbr depends on bytemuck 1, bevy_ui, bevy_core, bevy_sprite and bevy_render on bytemuck 1.5; also, the bevy crate depends on bytemuck 1.7 but only as a dev-dependency);
some crate depend transitively on winapi 0.2.5, but it doesn't compile. winapi 0.2.7 worked though;
gpu_allocator declares a dependency on backtrace 0.3, but it uses features of backtrace 0.3.3 and later. I would consider this a bug of gpu_allocator since the use is internal. This hasn't been fixed yet, though I submitted a PR (Traverse-Research/gpu-allocator#174).

I decided to report the last three issues because, while they are not strictly bevy's fault, they impact building bevy with minimal versions.
Note that the analysis must consider the whole workspace together (crates in tools included), and this may hide problems in the single crates due to newer dependencies specified by other crates (and this could also apply to dependencies of dependencies...). So for example if bevy_ecs declared a dependency on foo 1 but actually used features from foo 1.1, and bevy_reflect declared a dependency on foo 1.1, then no error would be raised while compiling bevy_ecs, even though it technically declared a wrong dependency. To find some of these kind of errors you would have to compile the single crates outside the workspace, which is a lot more work to do. This could be doable just for crates that can be used alone, like bevy_ecs and bevy_reflect though.
It would be nice if in the future this was automatically tested, to ensure that people don't get weird errors like in #9374, or recently one posted on Discord with tracing older than 0.1.36 (which seems to not happen on the master branch likely due to some transitive dependency).

I think the lock_api issue is at least partially why cargo run -p ci doesn't work on my machine. It's picking up 0.4.6 when I run that command, whereas it picks up 0.4.10 when I run cargo test or cargo run --example directly in my console.

I just got hit by the bevy_text depending on 0.24 instead of 0.24.1 issue. I guess until we have CI to check this a PR that fixes all the issues you mentioned would probably be good.

looks like another dependency is found here:
https://github.com/bevyengine/bevy/issues/9593

I tried adding lock_api = 0.4.7 to bevy_reflect, but it doesn't seem to work. I get a conflicting version error, when I try to run cargo run -p ci
Updating crates.io index
error: failed to select a version for `lock_api`.
    ... required by package `bevy_reflect v0.12.0-dev (E:\Github\bevy\crates\bevy_reflect)`
    ... which satisfies path dependency `bevy_reflect` (locked to 0.12.0-dev) of package `bevy_ecs v0.12.0-dev (E:\Github\bevy\crates\bevy_ecs)`
    ... which satisfies path dependency `bevy_ecs` (locked to 0.12.0-dev) of package `bevy_ecs_compile_fail_tests v0.1.0 (E:\Github\bevy\crates\bevy_ecs_compile_fail_tests)`
versions that meet the requirements `^0.4.7` are: 0.4.10, 0.4.9, 0.4.8, 0.4.7

all possible versions conflict with previously selected packages.

  previously selected package `lock_api v0.4.6`
    ... which satisfies dependency `lock_api = "^0.4.6"` (locked to 0.4.6) of package `parking_lot v0.12.1`
    ... which satisfies dependency `parking_lot = "^0.12.1"` (locked to 0.12.1) of package `bevy_reflect v0.12.0-dev (E:\Github\bevy\crates\bevy_reflect)`
    ... which satisfies path dependency `bevy_reflect` (locked to 0.12.0-dev) of package `bevy_ecs v0.12.0-dev (E:\Github\bevy\crates\bevy_ecs)`
    ... which satisfies path dependency `bevy_ecs` (locked to 0.12.0-dev) of package `bevy_ecs_compile_fail_tests v0.1.0 (E:\Github\bevy\crates\bevy_ecs_compile_fail_tests)`

failed to select a version for `lock_api` which could resolve this conflict
thread 'main' panicked at 'Compiler errors of the ECS compile fail tests seem to be different than expected! Check locally and compare rust versions.: command exited with non-zero code `cargo test --target-dir ../../target`: 101', tools\ci\src\main.rs:99:18

I tried adding lock_api = 0.4.7 to bevy_reflect, but it doesn't seem to work. I get a conflicting version error, when I try to run cargo run -p ci

I can reproduce this if I manually change the Cargo.lock file to use lock_api version 0.4.6, however there seems to be no good reason why it should be like this. Running cargo update inside crates/bevy_ecs_compile_fail_tests fixes the issue, but this shouldn't be necessary.
On the sidenote, does anyone know why the bevy_*_compile_fail_tests are excluded from the workspace? This prevents them from sharing the same Cargo.lock file, which might be a problem in this case.


npm install ergo-cli does not work because of missing ergop.js

When installing the ergo cli via "npm install -g @accordproject/ergo-cli", npm cannot find the find "ergop.js" specified in "package.js" and thus stops mid-install.

Thanks @jhoogstraat for the bug report. It's something we missed when we changed the build process for v0.1.0. This is fixed in master (Thanks @mttrbrts!). I'll cut a new release shortly.

We have just released Ergo v 0.1.2. @jhoogstraat let us know if that solves your problem with npm install. Thanks.


Add nfs-utils to Docker CSI-NFS plug-in

This patch adds the nfs-utils package to the Docker CSI-NFS plug-in. This patch addresses this comment from #1066.
Please note that while the original comment mentioned nfs-tools, that package does not appear to exist. Instead this patch uses nfs-utils. The latter was tested by running docker run -it alpine:3.6 /bin/ash and then running apk update && apk add nfs-utils. If there is some package named nfs-tools that needs to be installed, perhaps it was from an earlier version of Alpine or requires a custom package source?
cc @clintkitson @codenrhoden

Codecov Report

Merging #1072 into master will increase coverage by 0.31%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #1072      +/-   ##
=========================================
+ Coverage   34.19%   34.5%   +0.31%
=========================================
  Files          36      36
  Lines        2901    2901
=========================================
+ Hits          992    1001       +9
+ Misses       1806    1796      -10
- Partials      103     104       +1

Impacted Files
Coverage Δ

...storage/drivers/storage/vfs/storage/vfs_storage.go
40.28% <0%> (+2.15%)
: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 586a8f1...5c5532c. Read the comment docs.


Create v5 extension configuration

We need a v5 branch which imports the PF v5 alphas, as well as proper configuration to make that the new primary development branch and enable releasing alphas from it.

As discussed at standup one day, I don't think we really want to have extensions being based on alpha versions of PF by default do we?
I feel like this issue should be moved to the sprint during which PF5 is actually slated to go GA, and just update it to consume PF5 at that point.

@wise-king-sullyman I'm going to work on this if that's okay.

closing in favor of new issue


Emmet 2.0:  "lorem" text is wrapped with extra div

VSCode Version: Code - Insiders 1.14.0-insider (7e2937237620501705e4a5276e76726d35a31905, 2017-06-30T05:07:32.086Z)
OS Version: Darwin x64 16.6.0
Extensions:

Extension
Author (truncated)
Version

ng-template
Ang
0.1.4

vscode-markdownlint
Dav
0.9.1

code-settings-sync
Sha
2.8.1

sort-lines
Tyr
1.3.0

Bookmarks
ale
0.15.2

project-manager
ale
0.18.1

path-intellisense
chr
1.4.2

vscode-eslint
dba
1.2.11

vscode-html-css
ecm
0.1.7

tslint
eg2
0.16.0

auto-rename-tag
for
0.0.14

Angular2
joh
2.3.3

ecdc
mit
0.10.3

HTMLHint
mka
0.3.3

vscode-stylefmt
mrm
2.4.1

angular2-inline
nat
0.0.17

stylelint
shi
0.26.0

ayu
tea
0.4.0

change-case
wma
1.0.0

(4 theme extensions excluded)

Steps to Reproduce:

Inside of an html element (I used an div) type the trigger for lorem ipsum, e.g. lorem20

       lorem20

You get the text as expected, but it's wrapped in an extra div tag.  It should be just the greek text.

Lorem ipsum dolor sit amet consectetur adipisicing elit. A molestias consectetur nesciunt quas harum tempore facere debitis laboriosam doloribus necessitatibus!

That is coming from the emmet module http://github.com/emmetio/expand-abbreviation. Will move it to the atom repo which @sergeche is using to track the issues

This issue was moved to emmetio/atom-plugin#28


Lyrics Tool Always Failing

Issue Label:

[x] Bug
[ ] New feature
[ ] Enhancement
[ ] New component

Description:
https://lyrics.ovh/ doesn't seem to be a website. The tool for now will go in a deprecated folder and will sit there until someone comes along and finds a new free lyrics api with unlimited requests.
If its a bug make sure to include this section.
OS and OS version:
All

Fixed by removing the lyrics tool from the main installer and checking to see if I can remove it during an uninstall. Should probably check to uninstall this tool during the install but, might run into issues for people who installed a previous version through homebrew.
Lyrics was removed in Version 1.19.2

Website and api works fine for me?

Yeah seems to work now, I had tested this before and it was not working, went over to the website and it seemed to be gone, looks like its back, will try to bring back this tool in the next release


Interference problem in multiple L515s

Required Info

Camera Model
L515

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win 10

Platform
PC

SDK Version
2.35.2

Language
C

Segment
others

Issue Description
When two L515s are started at the same time, it seems that they interfere with each other and the depth data is disturbed.
Hiding one of the cameras will reduce the disturbance.
Is it a problem that can be solved by external synchronization?
Where can I find information on the L515 external sync?

Hi @kojiohno
This is expected based on the technology.  This is not the same as stereo pair in our D400 series cameras where the more texture on the scene the better.  For L515, the laser projector, the pattern and the processing of the pattern when the beam is reflected back to the IR photodiode is a very specific process.  So having two L515 projecting where the lasers are overlapping will cause some interference with any given L515 in that scenario and that interference will cause depth data to suffer.
With that being said, we are working on a sync functionality but it is not ready at this point in time.
I would say that what you're seeing now is expected and not a problem.  This is how the technology is.  You can continue to check back with the release notes of librealsense and/or datasheet (https://dev.intelrealsense.com/docs/lidar-camera-l515-datasheet), whitepapers (https://dev.intelrealsense.com/docs/whitepapers) regarding a sync function that will allow for synchronizing multiple L515 cameras together.
Is there anything else you need on this topic?

Thank you for your answer.
I understand this is the expected behavior based on the technology. However, when the synchronization function becomes available, is it possible that interference will be mitigated by slightly shifting the IR laser irradiation timing of each device?
Also, do you have any idea when the sync function will be released?

Hi @kojiohno
We are working on it and working on documentation as well.  We will update you when the information is ready.

Any updates? Can I turn off the emitter like D415?

@xiebei - We are still working on the documentation and details around this.  Thanks for checking in.  No ability to turn off the emitter on the L515.  The emitter is essential to the LiDAR technology in L515.

@kojiohno @xiebei and others on this thread
We've posted the following document that was designed specifically to discuss how to connect and configure for multiple L515 cameras
https://dev.intelrealsense.com/docs/lidar-camera-l515-multi-camera-setup
This document should be exactly what you are looking for.
*If we don’t hear from you in 7 days, this issue will be closed.


Add support for Rancher Public DNS

Depends on https://github.com/rancher/public-dns-client/pull/4
Adds provider to integrate with rancher-public-dns service
https://github.com/rancher/rancher/issues/8704
PR https://github.com/rancher/external-dns/pull/66 can be closed, this one is includes those changes and updates the vendor/client dependencies
This PR is part of https://github.com/rancher/rancher/issues/8790

We are not going to do this for 1.6


Removed no from creating runtime app

Removed the number from runtime app as talked about in #1741

@freddydk can you review this change?

Will do - I will have to access the consequences of this change before doing it.

Very nice, I have been thinking about Az Artifacts support, but never got to look into this.
I have briefly scanned the code and it looks fine.
I think you need to sign the contributor license in order for me to merge the PR.

@freddydk  I've created a new PR for that only azure feed support. #1769


[Bug]: NotifyCharacterisitic does not working

Component/Nuget
BluetoothLE Client (Shiny.BluetoothLE)
What operating system(s) are effected?

[ ] iOS (13+ supported)
[ ] Mac Catalyst
[X] Android (8+ supported)

Version(s) of Operation Systems
Windows 10 Pro latest Update (OS Build 19045.2846)
Android 12 (Samsung Galaxy S10)
What platform(s) are effected?

[X] MAUI
[ ] Native
[ ] Classic Xamarin
[ ] Other

Steps To Reproduce

Enable the Characterisitic Notification
At the next step i tried to write another characteric async

Expected Behavior
Every time i call the WriteCharacteristicAsync command, there should be a response after a short delay on the characteristic notification (This is implement in my routine on the BLE Host)
Actual Behavior
I get an exception that i can not write the characteristic. If i remove the Notification then everything is working as expected
Exception or Log output
[BluetoothGatt] refresh() - device: 24:6F:28:F6:11:DD
[BluetoothGatt] discoverServices() - device: 24:6F:28:F6:11:DD
[BluetoothGatt] onConnectionUpdated() - Device=24:6F:28:F6:11:DD interval=6 latency=0 timeout=500 status=0
[BluetoothGatt] onSearchComplete() = Device=24:6F:28:F6:11:DD Status=0
[BluetoothGatt] onConnectionUpdated() - Device=24:6F:28:F6:11:DD interval=36 latency=0 timeout=500 status=0
Resolved pending breakpoint at 'Peripheral_Characteristics.cs:70,1' to void Shiny.BluetoothLE.Peripheral.<>c__DisplayClass39_1.<b__2>d.MoveNext () [0x0018a].
[BluetoothGatt] setCharacteristicNotification() - uuid: 41ceed4b-e348-4a17-b1e9-6ac02daa1ecf enable: true
Resolved pending breakpoint at 'Peripheral_Descriptors.cs:33,1' to void Shiny.BluetoothLE.Peripheral.<>c__DisplayClass57_1.<b__1>d.MoveNext () [0x00089].
Resolved pending breakpoint at 'Peripheral_Descriptors.cs:36,1' to void Shiny.BluetoothLE.Peripheral.<>c__DisplayClass57_1.<b__1>d.MoveNext () [0x000d5].
Shiny.BluetoothLE.BleException: 'Failed to write to characteristic: 41ceed4b-e348-4a17-b1e9-6ac02daa1eda'
Code Sample
`this.dispose = this.InstancePeripheral.NotifyCharacteristic(FlasherUuids.UPDATER_SERVICE_UUID.ToString(), FlasherUuids.UPDATER_STATE_CHARACTERISTIC_UUID.ToString()).Subscribe(x => count++);
await InstancePeripheral.WriteCharacteristicAsync(FlasherUuids.UPDATER_SERVICE_UUID.ToString(), FlasherUuids.UPDATER_LENGTH_CHARACTERISTIC_UUID.ToString(), lengthAndMtuSize.ToArray(), false, default, 10000);`
Code of Conduct

[X] I have supplied a reproducible sample is NOT FROM THE SHINY SAMPLES!
[X] I am a Sponsor OR I am using the LATEST stable/beta version from nuget (v2.7.1 stable - ALPHAS are not taking issues)
[X] I understand that if I am checking these boxes and I am not actually following what they are saying, I will be removed from this repository!

This is not enough of a sample to do anything with.  Your error is to do with the write characteristic, not the actual notification characteristic.  You need to hook the error in the notification subscription if you think there is an issue there.

I am running into a similar issue with NotifyCharacteristic on Android. There appears to be a TimeoutException that is occurring:
System.TimeoutException: The operation has timed out.
   at Shiny.BluetoothLE.Peripheral.<>c__DisplayClass39_1.<<NotifyCharacteristic>b__2>d.MoveNext()
--- End of stack trace from previous location ---
   at Shiny.BluetoothLE.Intrastructure.OperationQueueExtensions.<>c__DisplayClass0_1`1.<<QueueToObservable>b__1>d[[Android.Bluetooth.BluetoothGattCharacteristic, Mono.Android, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=84e04ff9cfb79065]].MoveNext()
--- End of stack trace from previous location ---
   at Shiny.BluetoothLE.Intrastructure.SemaphoreOperationQueue.Queue(Func`1 task)
   at Shiny.BluetoothLE.Intrastructure.OperationQueueExtensions.<>c__DisplayClass0_0`1.<<QueueToObservable>b__0>d[[Android.Bluetooth.BluetoothGattCharacteristic, Mono.Android, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=84e04ff9cfb79065]].MoveNext()

This same notification is being received in the iOS version of my App as well as via nRF Connect (Android, iOS , Mac).

Hi!
I have the same problem
Error:
ex	{System.TimeoutException: The operation has timed out.
at Shiny.BluetoothLE.Peripheral.<>c__DisplayClass39_1.<b__2>d.MoveNext()
--- End of stack trace from previous location ---
at Shiny.BluetoothLE.Intrastructure.OperationQueueExtensions.<>c__DisplayClass0_11.<<QueueToObservable>b__1>d[[Android.Bluetooth.BluetoothGattCharacteristic, Mono.Android, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=84e04ff9cfb79065]].MoveNext() --- End of stack trace from previous location ---    at Shiny.BluetoothLE.Intrastructure.SemaphoreOperationQueue.Queue(Func1 task)
at Shiny.BluetoothLE.Intrastructure.OperationQueueExtensions.<>c__DisplayClass0_0`1.<b__0>d[[Android.Bluetooth.BluetoothGattCharacteristic, Mono.Android, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=84e04ff9cfb79065]].MoveNext()}	System.TimeoutException
My code:
this.watcher = DeviceSelected
.NotifyCharacteristic(this.Characteristic.Service.Uuid, this.Characteristic.Uuid)
.Timeout(Constants.OperationTimeout)
.SubOnMainThread(
x =>
{
//faz a leitura do sensor
this.SetReadValue(x, fromUtf8);
}
, ex =>
{
App.loggingService.Error(ex, "DoNotifyAsync");
}
);

Please ensure you are adding value to the issue when replying.  I am looking for FULL reproducible samples for betas to be inline with the code of conduct.  "Me toos" simply become noise.  Please remember v3 is a beta, so things aren't fully finished either!

Sorry @aritchie, updated the test app with this issue.
Hope it helps to find out.
https://github.com/rodrigoavots/MauiShinyTest


Add note about Llama model access restrictions

The Llama model (meta-llama/Llama-3.2-3B-Instruct) is a gated repository on Hugging Face, requiring special access permissions.
Update documentation to inform users about this limitation and provide alternative options or instructions for requesting access.
Is there a recommended model to use in the meantime?

I see, thanks for mentioning that. Will add to the README. I think for now llama 3.2 3b might be the best model for this kind of tasks given the balance between size vs. capability. Any other model that you know and think could be better? @fredrikburmester


Prevent duplicate styles

-Prevent parsing of files that have been defined by the user
-Added tests on regex101
-Added ds_store to gitignore

Hi @mathisonian I've cleaned this up a bit since the last pr, let me know if you have any questions, happy to add more tests etc.
-Grant

Thanks for submitting this @gkiely! everything looks good to me, i'll update on npm as well

this is released in v0.3.3 on npm, and I've also bumped the entire project version to v1.0.0 so we can start following semver

Nice work @mathisonian!


1.20.4

Could the mod be updated to 1.20.4 for fabric?
Changing fabric.mod.json to 1.20.4 does not work.

I'm sorry but I'm in grade 9 now. It may take a long time to complete the upgrade.
Thank you for your support and understanding. :)

ok, completed.


Variables provided as defaults need !default flag

Allows users to override the variables ahead of importing your scss.
Note you may also want to consider more unique names for these – particularly $image-directory-path,  $accessible-highlight and $hover-enabled – e.g. prefixing with starability or star –  $star-count $star-size are probably fine.

@stevelacey thank you for this contribution, good catch! :)


lambda-js: Add note about esbuild module exports

This change adds a short blurb about requirements for users who are using esbuild.
As discussed in https://github.com/aws-observability/aws-otel-lambda/issues/99 there is a quirk of esbuild that causes exported functions using the export keyword to be marked immutable in the transpiled JS. As a result, you must use module.exports instead, which is passed along by the esbuild transpilation process unscathed.

Hi @indrora - good idea adding a note to the readme!
I'm running into the same issue, but the solution I see doesn't work with my  implementation and I'm trying to troubleshoot what's going on.
If I update my exports to use module.exports, the other files that import my handler receives the following error:
Module '"../../../../src/authorizer"' declares 'authorizer' locally, but it is not exported

Do you have any advice on how I can use module.exports within my TS files?

Hi @indrora - good idea adding a note to the readme!
I'm running into the same issue, but the solution I see doesn't work with my implementation and I'm trying to troubleshoot what's going on.
If I update my exports to use module.exports, the other files that import my handler receives the following error:
Module '"../../../../src/authorizer"' declares 'authorizer' locally, but it is not exported

Do you have any advice on how I can use module.exports within my TS files?

I do not have the total context on the suggestion but based on the context but you can try using like - module.exports = authorizer;


Relative lighten/darken

I replaced color with colord in my project, but found out I don't get the same results, because they treat lighten() and darken() differently: While color shifts color by a fraction of itself, while colord shifts color by a fraction of whole spectrum.
I prototyped this wrapper to implement this functionality:
import { AnyColor, Colord, HslaColor } from 'colord'
import { colord as nativeColord } from 'colord'

export const clamp = (number: number, min = 0, max = 1): number => {
  return number > max ? max : number > min ? number : min
}

export const lightenRelative = (color: AnyColor | Colord, amount: number): HslaColor => {
  const hsla = nativeColord(color).toHsl()

  return {
    h: hsla.h,
    s: hsla.s,
    l: clamp(hsla.l * (1 + amount), 0, 100),
    a: hsla.a
  }
}

class ExtendedColord extends Colord {
  public lightenRelative(amount: number = 0.1) {
    return extendedColord(lightenRelative(this.rgba, amount))
  }

  public darkenRelative(amount: number = 0.1) {
    return extendedColord(lightenRelative(this.rgba, -amount))
  }
}

export const extendedColord = (input: AnyColor | Colord): ExtendedColord => {
  if (input instanceof ExtendedColord) return input
  return new ExtendedColord(input as any)
}

and I will use it for now, but I'd prefer to merge it into the library itself - are you interested in this functionality? I would love to make a PR if so.
Thank you 🙏

@michal-kurz, thank for the idea, I think this is a valid point.
I have implemented it via optional relative: Boolean flag,
Now we have to wait for the library owner for code review.

@EricRovell thanks for the great PR!
@omgovich thanks for your incredible work! Do you have an interest in merging that PR? (#91)? We're also moving from Color to colord and this is a really big sticking point for us - it would be days of work to overhaul our project to work without a relative lighten feature.

I think a relative saturate feature would also be useful. Perhaps this is not necessarily best practice in color manipulation or something, but converting from Qix's Color library - the outputs of saturate() vary wildly and I'm not sure how we could easily transition to colord as a result.
Qix's library does the math like this:
	saturate(ratio) {
		const hsl = this.hsl();
		hsl.color[1] += hsl.color[1] * ratio;
		return hsl;
	},

Assuming I did my math right, the outputs vary as below:

I really want to switch to colord but it didn't really make sense for us to put the time into switching to begin with. Nonetheless I decided to undertake the task, and now I'm hoping I'll be able to complete it via an addition of a relative saturate function, or maybe someone has advice for an alternative method for us to get similar outputs?
I know colord is more accurate in its outputs so some of our colors vary by like 1% from our previous values, but colors affected by saturate aren't even close due to relative vs absolute.

@Slapbox the author is quite busy these days, unfortunately. I think if you need this PR you can extend the Colord class and override the functionality for your needs🤔

@EricRovell makes sense! It would be really great to get your PR merged soon, but short of that, maybe consider releasing a plugin for your PR. If I make a plugin for relative saturate, I'll do the same. Even just a gist of our code would surely be a big help to other devs if PRs can't be merged for an extended time.

Here's a very basic solution for anyone who needs it. It possibly has some mistake in it, as our app still doesn't look as expected, but perhaps that's some other unrelated issue.
Note: Apparently you can't override the code functionality to override the built-in lighten without breaking some other things, so the names are
import { Colord } from 'colord';

export const clamp = (number: number, min = 0, max = 1): number =>
  number > max ? max : number > min ? number : min;

// Copied from https://github.com/Qix-/color/blob/master/index.js
function saturateRelative(hslColor, ratio) {
  const { s: saturation } = hslColor;
  const newSaturation = saturation + saturation * ratio;
  return { ...hslColor, s: newSaturation };
}

const relativeSaturatePlugin = ColordClass => {
  ColordClass.prototype.saturateRel = function (ratio = 1) {
    const mixture = saturateRelative(this.toHsl(), ratio);
    return new ColordClass(mixture);
  };
};

function lightenDarken(hslColor, amount, relative) {
  const l = relative ? hslColor.l * (1 + amount) : hslColor.l + amount * 100;
  return { ...hslColor, l: clamp(l, 0, 100) };
}

const relativeLightenDarkenPlugin = ColordClass => {
  ColordClass.prototype.lightenRel = function (amount, relative = true) {
    const adjusted = lightenDarken(this.toHsl(), amount, relative);
    return new ColordClass(adjusted);
  };

  ColordClass.prototype.darkenRel = function (amount, relative = true) {
    const adjusted = lightenDarken(this.toHsl(), amount, relative);
    return new ColordClass(adjusted);
  };
};

export { relativeSaturatePlugin, relativeLightenDarkenPlugin };


Faster Queries for Textile

Urban legend says that Textile supports mingo // MongoDB Query language

Closed by #49


Add custom views to better support rewriting in other languages

Example:
rewrite := SmaCCRewriteFile new
		parserClass: JavaParser;
		addTransformation: (SmaCCRewrite
				comment: ''
				match: (SmaCCRewriteTreeMatch new source: '`i` += 1')
				transformation: (SmaCCRewriteStringTransformation new string: '`i` ++')).
engine := SmaCCRewriteEngine new rewriteRule: rewrite.
source := 'public class Test {
	public void foo() {
		for (int i = 1; i <= 10; i+=1) {
			bar(i);
		}
	}
}'.
node := JavaParser parse: source.
engine
	source: (SmaCCAnnotatedString on: source);
	rewrite: node


Switch to :crypto.mac/4 from :crypto.hmac/3

While testing one of my apps with Erlang OTP master, pow fails with (UndefinedFunctionError) function :crypto.hmac/3 is undefined or private.
I'm guessing that :crypto.hmac/3 is being removed in OTP 24 which is the reason for the error. Do you have plans to switch out :crypto.hmac/3 with :crypto.mac/4?
It would be a fairly simple change:
https://github.com/danschultzer/pow/blob/84d6cfe44a6e2f69ef60e3374a72ada6645f83b4/lib/pow/ecto/schema/password/pbkdf2.ex#L70
&:crypto.mac(:hmac, digest, secret, &1)

All tests should pass as the output is exactly the same. The caveat is that OTP 22.1 would be required after the change.

Thanks! The module has been updated to support OTP 24, if you pull from master it should be working, I'll prepare a new release soon 😄


add query options for nunjucks.configure

need a bit more config options, such as autoescape, trimBlocks, tags
https://mozilla.github.io/nunjucks/api.html#configure

@ertle hey man, at the moment I'm not putting much work into this but if you have a change you'd like to submit you are welcome to. The LOC on this is pretty small.

@ertle I might have some time to invest in the future. For now we'd happily accept a PR containing the missing features.

Hey guys, thanks for the nice work on this loader.
I was needing to include some custom data from json file to be able to use it in nunjucks templates.
Someone might find it useful for own purposes as well. I created a pull request to achieve this goal in case if you find it useful to have.

I created a local patch for this issue that seems to be working for me.
This is what the loader looks like set up.
/* Nunjucks loader */
const nunjucksOptions = {
  configure: function(env){
    markdown.register(env, marked);
  },
  searchPaths: basePath + '/src/html',
  context: {
    config: {
      'env': 'development',
      'image_src': '../../assets/images/'
    }
  }
};

config.module
    .rule('nunjucks')
    .test(/\.(njk|nunjucks)$/)
    .use('html-loader')
    .loader('html-loader')
    .end()
    .use('nunjucks-html-loader')
    .loader('nunjucks-html-loader')
    .options(nunjucksOptions);

I added two lines into index.js to support this.
module.exports = function(content) {
	this.cacheable();

	var callback = this.async();
	var opt = utils.parseQuery(this.query);

	var nunjucksSearchPaths = opt.searchPaths;
	var nunjucksContext = opt.context;
	var nunjucksConfiguration = opt.configure;

	var loader = new NunjucksLoader(nunjucksSearchPaths, function(path) {
		this.addDependency(path);
	}.bind(this));

	var nunjEnv = new nunjucks.Environment(loader);
	nunjucks.configure(null, { watch: false });

	nunjucksConfiguration(nunjEnv);

	var template = nunjucks.compile(content, nunjEnv);
	html = template.render(nunjucksContext);

	callback(null, html);
};


Fix rules for protonmail & add alternative domain names

Protonmail allows email aliases by adding a plus sign and adding arbitrary text behind it. (see https://proton.me/support/addresses-and-aliases#plus)
However, the current implementation simply replaces the plus sign from the username with an empty string without disposing of text following the plus sign. The proposed change fixes this use case.
Furthermore, there are multiple known domain names used by protonmail (see https://proton.me/support/addresses-and-aliases) but only "protonmail.ch" is handled in the current implementation. The proposed change adds the protonmail normalization rule to the following known alternative domains:

protonmail.ch
protonmail.com
proton.me
pm.me

Thank you!


RangeError: Maximum call stack size exceeded in v2.0.0-rc.7

If flatpickr is placed inside bootstrap modal, an error occurs when it tries to select a year.
Version: v2.0.0-rc.7
Bootstrap: v3.3.7
Browser: Google Chrome v52.0

Hello,
Thanks for reporting the issue.
Looking into it

👍

This issue is still present!

flatpickr.js:85 Uncaught RangeError: Maximum call stack size exceeded.

I commented out the focus listener. I felt like it's selecting on focusing, which again focuses.. and so on chasing it's own tail. It's not throwing the recursion error now. I needed to know the consequences if any!
Thank you..

I will try to test this with new version...

Any luck?

@chmln error persists yet.
Here my fiddle: https://jsfiddle.net/joseluisq/sam7rcqo/
Simply open the modal and select some year in the flatpickr.
flatpickr/2.0.0-rc.8
bootstrap/3.3.7
jquery/3.1.0

Has any progress been made on this, or is it basically being ignored because it is already closed?

This is still an issue. Is it still being looked at?

+1

Recently I came across the same error. The flatpickr was inside of a bootstrap modal. But only one flatpickr produced the RangeErrors. So I wondered and discovered that the error only occurs when the tabindex property is set on the modal root div. Once I removed it, everything seems to work out just fine.
I don't know why, but somehow the tabindex property seems to be the problem.

as weird as it is @fabianallendorf 's solutions is the solution. I had tab-index="-1" as well once removed no errors anymore

as weird as it is @fabianallendorf 's solutions is the solution. I had tab-index="-1" as well once removed no errors anymore
using flatpickr v4.5.7


Updated catch2 library to 2.7.0

relates to this PR

Thanks! This also prompted me to upgrade catch2 at work :)

Glad I could help :)


Links to source code in nbdev documentation point to wrong lines

I've noticed it on this documentation page. For example, link to source for adapt_img_path points to line 174, while the function code starts on line 182.

This is probably because the docs have not been update in a while. Will run the script now.

Yup, that fixed it.


Create basic site with topshelf.github.io

@TravisTheTechie can you work your magic on Topshelf as well? It's the last one to convert, and they're all golden.
Be nice to get the logos moved over as well, since we paid for them! :)

Yeah, I can do this soon.

I just dumped the main WP site page. https://github.com/Topshelf/topshelf.github.io.


Edit API Definition gives error page in Safari

Description
When trying to click on the Edit option for an API Definition, the following error page is shown in the Safari Web browser.

Steps to Reproduce

Login to the Publisher portal using the Safari Web Browser
Create an API
Click on the API Definition tab for the API
Then click on the Edit option
You will see an error page like above

Affected Component
APIM
Version
4.3.0
Environment Details (with versions)
No response
Relevant Log Output
No response
Related Issues
https://github.com/wso2/api-manager/issues/2632
https://github.com/wso2/api-manager/issues/2630
https://github.com/wso2/api-manager/issues/2624
Suggested Labels
No response

This is working on Safari 16+. Hence closing the issue.


Cleanup unused functions and types in bundle generation code

This PR cleans up unused functions and types in the bundle generation codebase. Some of the removals and changes include:

[REMOVAL] Types, functions and references related to ECR Public (since we only need private ECR logic)
[REMOVAL] Client creation methods with logic to create "Release" SDK Clients for ECR, ECR Public and STS (since we are directly creating them using methods offered by aws-sdk-go-v2).
[REMOVAL] Types ImageDetailsBothECR, ImageDetailsECR and conversion methods to/from github.com/aws/aws-sdk-go-v2/service/ecr/types.ImageDetail type to these new types (since we are only dealing with private ECR)
[REMOVAL] Unnecessary private registries in Docker config.json and Skopeo policy.json configuration files (since we only push to a single private ECR)
[MODIFICATION] Mock types changes and registry changes to keep tests happy

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Prepare for first public release

We should start thinking about the things we still need (that aren't currently represented in the backlog) before we can do our first release.
Some things I can think of are:

[ ] Decide on and set up CI prod release mechanism
[x] Enable app signing in play store
[ ] Figure out a mechanism for transferring our test content model to the production space
[ ] Allow differing environment variables for each CI build stage. We will need to pass the app the API key for the production contentful space. Maybe the contentful test space for alpha builds and prod space for beta/prod builds?
[ ] Create a production API key for Google maps with appropriate permissions.
[ ] Add Microsoft Codepush library and workflow for over the air builds?
[ ] Submit a stable build for iOS app store review without publishing it, to test how long it takes and see if there are any issues we need to sort out.
[ ] Decide on app icons and splash screen
[ ] Limit distribution to sensible devices (no tablets)
[ ] Automate capturing required screenshots using Fastlane (part of prod release mecahnism)

Can anyone think of more?

What kind of information do we need for the App Store or Play Store?

For example I'm pretty sure that every app on the Play Store needs a public privacy policy hosted somewhere. Is it okay to use the one on https://prideinlondon.org/terms?

Quite possibly, although if there's an app set up there already that we'll be updating, maybe this is already done

Couldn't see App icons in Trello.

If there's a new icon we need to do it.
If we want to use the existing one we need access to a high res version.

Added app icons to the list above.

I've been having another look at appcenter.me and it looks like you can push your own binaries to the services without having to use their build pipeline with the appcenter distribute release command in their CLI.
Appcenter can handle the distribution to stores, but also crash reporting, analytics, push notifications, and codepush releases in one place. I'm not sure how good it is at all these things compared to competitors, but I'll try and upload a build soon and try them out.

Some launch checklists to go through as content will likely come from Pride org although I presume most won't change from whatever the live version has.
Android: https://developer.android.com/distribute/best-practices/launch/launch-checklist.html
iOS: https://blog.oursky.com/2017/03/09/checklist-ios-app-store-itunes-connect/

This is the privacy policy currently set in both stores http://prideinlondon.org/about-us/privacy
Going to that link just shows the homepage, no redirect.

We did it


mappedCoverage.addStatement is not a function ( js not ts )

🐛 Bug Report
I meet a "TypeError: mappedCoverage.addStatement is not a function" error while using
without using jest's "istanbul-lib-source-maps" functionality, the whole information is as below:
TypeError: mappedCoverage.addStatement is not a function
at /tmp/build/src/node_modules/jest-cli/node_modules/istanbul-lib-source-maps/lib/transformer.js:97:28
at Array.forEach ()
PS:
jest version: 22.4.3
In my case, there is nothing related with "ts-jest"

this solution work me
rm -rf $TMPDIR/react-* && watchman watch-del-all && npm cache clean --force && npm run jest --clearCache


initializing Snowflake terraform provider

This is a prototypical terraform provider using SQLlite3 as main driver.
commiting  my code segment till i get snowflake access for dropping in more cluster/storage creation commands.

Wonder if Snowflake's Go Driver would work: https://github.com/snowflakedb/gosnowflake


Switched broken pypip.in badges to shields.io

Hello, this is an auto-generated Pull Request. (Feedback?)
Some time ago, pypip.in shut down. This broke the badges for a bunch of repositories, including visio2img. Thankfully, an equivalent service is run by shields.io. This pull request changes the badges to use shields.io instead.
Unfortunately, PyPI has removed download statistics from their API, which means that even the shields.io "download count" badges are broken (they display "no longer available". See this). So those badges should really be removed entirely. Since this is an automated process (and trying to automatically remove the badges from READMEs can be tricky), this pull request just replaces the URL with the shields.io syntax.

Coverage remained the same at 56.075% when pulling 3a889bcdd6a21aba634e2a6b73ebb1d43c13ab28 on movermeyer:fix_badges into de233b1f8b8d00e3d36ee97896e168e83dd6a4a5 on visio2img:master.

Thanks!


Fixed end-to-end example to allow ingress healthcheck traffic

Description
Modified end-to-end example by:

Adding ACLs to VPC to allow the inbound and outbound traffic to/from ingress operator to report the ingress status.
Added public gateways to all the zones

Release required?

[x] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content
Modified end-to-end example by adding ACLs to VPC to allow the inbound and outbound traffic to/from ingress operator to report the ingress status and adding public gateways to all the zones
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[X] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline


Getting error in example

Hi there. Thanks so much for updating btw to BT3! I tried following the example here:
http://rgriff23.github.io/projects/btw.html
and I get the following error:
library(btw)
setwd('/Applications/BayesTraitsV3-OSX')
data(primates)
command_vec_3 <- c("13")
results_3 <- bayestraits(primate.continuous2, primate.tree100, command_vec_3)
Error in bayestraits(primate.continuous2, primate.tree100, command_vec_3) :
Tree must be of class phylo or multiPhylo
class(primate.tree100)
[1] "multiPhylo"
I tried in both RStudio (Version 1.1.447) and the R app (R 3.4.2 GUI 1.70 El Capitan build (7434)) on Mac.
Thanks!

I am getting the same error as well - I'm looking into it presently
On Mon, Nov 5, 2018 at 10:05 AM Steven Moran<EMAIL_ADDRESS>wrote:

Hi there. Thanks so much for updating btw to BT3! I tried following the
example here and get the following error:
http://rgriff23.github.io/projects/btw.html
and I get the following error:
library(btw)
setwd('/Applications/BayesTraitsV3-OSX')
data(primates)
command_vec_3 <- c("13")
results_3 <- bayestraits(primate.continuous2, primate.tree100,
command_vec_3)
Error in bayestraits(primate.continuous2, primate.tree100, command_vec_3) :
Tree must be of class phylo or multiPhylo
class(primate.tree100)
[1] "multiPhylo"
I tried in both RStudio (Version 1.1.447) and the R app (R 3.4.2 GUI 1.70
El Capitan build (7434)) on Mac.
Maybe I'm screwing something up, but I tried to follow the instructions
here:
http://rgriff23.github.io/projects/btw.html
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rgriff23/btw/issues/4, or mute the thread
https://github.com/notifications/unsubscribe-auth/AKpi8Eo_e5_yTOshosZ9T8daYebTrOCbks5usFPQgaJpZM4YOn4E
.

--
Randi Griffin
Department of Evolutionary Anthropology at Duke University
130 Science Drive
Biological Sciences 108
Durham, NC 27708
Website: http://rgriff23.github.io/
Phone:<PHONE_NUMBER>

It turns out there was a typo in code where it checks for 'MultiPphylo'
rather than 'MultiPhylo'... no idea how that slipped past me, I must have
introduced the error somehow after running my checks! Thank you for letting
me know. If you re-install 'btw', things should work now.
On Mon, Nov 5, 2018 at 10:53 AM Randi Griffin<EMAIL_ADDRESS>wrote:

I am getting the same error as well - I'm looking into it presently
On Mon, Nov 5, 2018 at 10:05 AM Steven Moran<EMAIL_ADDRESS>wrote:

Hi there. Thanks so much for updating btw to BT3! I tried following the
example here and get the following error:
http://rgriff23.github.io/projects/btw.html
and I get the following error:
library(btw)
setwd('/Applications/BayesTraitsV3-OSX')
data(primates)
command_vec_3 <- c("13")
results_3 <- bayestraits(primate.continuous2, primate.tree100,
command_vec_3)
Error in bayestraits(primate.continuous2, primate.tree100, command_vec_3)
:
Tree must be of class phylo or multiPhylo
class(primate.tree100)
[1] "multiPhylo"
I tried in both RStudio (Version 1.1.447) and the R app (R 3.4.2 GUI 1.70
El Capitan build (7434)) on Mac.
Maybe I'm screwing something up, but I tried to follow the instructions
here:
http://rgriff23.github.io/projects/btw.html
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rgriff23/btw/issues/4, or mute the thread
https://github.com/notifications/unsubscribe-auth/AKpi8Eo_e5_yTOshosZ9T8daYebTrOCbks5usFPQgaJpZM4YOn4E
.

--
Randi Griffin
Department of Evolutionary Anthropology at Duke University
130 Science Drive
Biological Sciences 108
Durham, NC 27708
Website: http://rgriff23.github.io/
Phone:<PHONE_NUMBER>

--
Randi Griffin
Department of Evolutionary Anthropology at Duke University
130 Science Drive
Biological Sciences 108
Durham, NC 27708
Website: http://rgriff23.github.io/
Phone:<PHONE_NUMBER>

@rgriff23 -- works for me! many thanks!


"An Instance Of Whatsie Is Already Running"

Problem Scenario ->
-Open application.
-Minimize application to system tray.
-Click application icon again(Not the tray one), you will get this warning.
Expected Behavior -> Just open the exist running instance, no need to warn the user about this.This change will affect user experience in very positive way.👍

related to issue #14

the same msg comes if I open a link from the web browser. e.g. https://wa.me/xxxxx
browser lets me to use Whatsie, but the app says "another instance is running" and it will not complete the request.
In order for the link to work, I need to kill whatsie and then click on the link in the browser again.
ps. running on Fedora 35

Yeah, I am aware of this issue. I will provide a solution soon.

Fixed in 8c0df6d34bba406e4d8e2711e4f5134a24107b2e

Fixed in 8c0df6d

After latest update when I click whatsie icon I got no warning but It's not restoring the exist session.

You should get a notification in your system tray if you set  native notification to channel your alerts. otherwise, you will get whatsie's own notification widget popped up on top right side of you screen.

I have not added implemented logic to directly raise the existing window. I think I should do that :D
Right now the user has to click on the notification popup in order to restore the window.

I have not added implemented logic to directly raise the existing window. I think I should do that :D Right now the user has to click on the notification popup in order to restore the window.

:D

After latest update when I click whatsie icon I got no warning but It's not restoring the exist session.

This is fixed in 391171583a00d04b3f2fcfb57b9c9743ae286728
update whatsie with snap refresh whatsie


More ClamAV improvements

Description
Changes ClamAV database mirror list.

The mirror clamav.iol.cz is dead so I removed it.
Re-added db.local.clamav.net because it redirects the user to the closest pool of mirrors.
I didn't re-add the database.clamav.net because it is a round robin and the connection can be very bad. So I left the older entries on the mirror list as fallback.

Default values for freshclam.conf on debian are:
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net

Notes:
Since I live in Brazil it's a 10x speed improvement for me downloading the files during tests.
On Digital Ocean or OVH it doesn't matter, the speed is good as before...
Changes ClamAV initialization to update databases in parallel.
Since clamav-unofficial-sigs reload is working properly now, we can update both sources at same time.
Scenarios on startup:

If freshclam finish first
It will launch clamd; then when clamav-unofficial-sigs completes it will reload clamd with additional signatures.

If clamav-unofficial-sigs finish first
It will ignore the reload since clamd will be stopped; then when freshclam completes it will start clamd with both databases signatures at same time.

There are no issues if both finish at almost same time. I did a few tests, clamd just "hangs" and queues the reloads.

Reduces waiting time for update and load ClamAV signatures database during tests.
I replaced that sleep 120 with a more "pragmatic way" of verifying that the updates have been completed.
Since that code is used by tests only, I think it is good/reliable enough.
(It saved almost 1 minute on travis-ci)
Adds more tests to clamav-unofficial-sigs.
Just added three tests with some testing signatures, just to be sure that clamav-unofficial-sigs are downloaded and working properly.
Type of change

[X] Performance improvement
[X] Refactoring (a change that neither fixes a bug nor adds a feature)
[X] Test (adding missing tests or correcting existing ones)

Status

[X] Ready

How has this been tested ?
Most of this changes are safe, so just lots of make all-fast and make all.

Let me know if there is any question.
Time to go to 🛌

Great work, as always :+1:
This part of testing needed a refactor and some optimizations, and you did it, thank you.

Thanks, glad to help.

Last build : 3 min 54 sec
Your refactor is really great :clap:


Blazor sample cross-link test

Addresses #26074

Failed on the use of aspnetcore as a segment in place of .. ...

Line 37: [Warning] The code snippet "~/aspnetcore/blazor-samples/6.0/BlazorSample_WebAssembly/Pages/index/HelloWorld.razor" could not be found.


Release verison 0.7.0

Coverage increased (+0.08%) to 66.505% when pulling f624b6cf09976dbb7a6145a357fd0188dfcf20b6 on release into 2df801a95c4677f6b45e52bb427cdf8d3533d367 on master.


Bug: Host header is not correctly set for non-default port

It's specified in RFC2616 that

A "host" without any trailing port information implies the default
port for the service requested (e.g., "80" for an HTTP URL).

so for HTTP or HTTPS that are not running on 80 or 443, we need to include port in Host header.
This is a bug in our code:
https://github.com/Azure/azure-sdk-for-cpp/blob/f872841ffc9d6339fcd7303af20c6763b95d5b2f/sdk/core/azure-core/src/http/curl/curl.cpp#L414

this issue can be fixed with below path
diff --git a/sdk/core/azure-core/src/http/curl/curl.cpp b/sdk/core/azure-core/src/http/curl/curl.cpp
index f8467e0c..30dd4b00 100644
--- a/sdk/core/azure-core/src/http/curl/curl.cpp
+++ b/sdk/core/azure-core/src/http/curl/curl.cpp
@@ -411,7 +411,13 @@ CURLcode CurlSession::Perform(Context const& context)
     if (hostHeader == headers.end())
     {
       Log::Write(Logger::Level::Verbose, LogMsgPrefix + "No Host in request headers. Adding it");
-      this->m_request.SetHeader("Host", this->m_request.GetUrl().GetHost());
+      std::string headerValue = this->m_request.GetUrl().GetHost();
+      auto port = this->m_request.GetUrl().GetPort();
+      if (port != 0)
+      {
+        headerValue += ":" + std::to_string(port);
+      }
+      this->m_request.SetHeader("Host", headerValue);
     }
     auto isContentLengthHeaderInRequest = headers.find("content-length");
     if (isContentLengthHeaderInRequest == headers.end())

so for HTTP or HTTPS that are not running on 80 or 443, we need to include port in Host header.

In what scenario would that happen? How did you run into this issue?

In what scenario would that happen? How did you run into this issue?

When we send requests to non 80 or 443 ports.
I ran into this issue when running test-proxy (localhost:5001) through Fiddler.


Create discovery server partitions on User PC for multiple turtlebots

Robot Model
Turtlebot4 Lite
ROS distro
Humble
Networking Configuration
Discovery Server
OS
Ubuntu 22.04
Built from source or installed?
Installed
Package version
turtlebot4_standard_humble_1.0.0.zip	2023-03-03 23:51	1.9G
Type of issue
Networking
Expected behaviour
Connect individual terminals to each turtlebots.
Actual behaviour
Each terminal opened becomes a listener to all turtlebots.
Error messages
No response
To Reproduce

open individual terminals
Soure each ROS_DISCOVERY_SERVER address:port in each terminal
Listen to each turtlebot topics in individual terminals

Other notes
Hi, I have four turtlebots setup with discovery server. The discover server setup that configures the user PC has created a setup.bash file in the directory /etc/turtlebot_discovery. The setup.bash file looks like this...
source /opt/ros/humble/setup.bash
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
[ -t 0 ] && export ROS_SUPER_CLIENT=True || export ROS_SUPER_CLIENT=False
export ROS_DOMAIN_ID=0
export ROS_DISCOVERY_SERVER="<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;"

I want to change my setup so that I can listen to ros topics/services/actions for any robot when I export its discovery server address:port. Changes that I have in my mind:

Setup discovery server again and use different port for each robot as explained in the Ros2 humble docs .
Create individual setup.bash files for each robot that only exports their server address. How should the content in these bash files look like?
Can someone explain each line in my current setup.bash file? I want to understand what happens when I source the above bash file.

I would greatly appreciate if someone would look at this and give me suggestions to get this working. Thank you for your guidance.

Apologies for the delay in my response. You have the right ideas overall but there are some caveats.
First I want to address an issue with the core request. It is definitely possible to set up the computer to listen only to one particular robot at a time, however the ROS 2 CLI tools rely on something called the ROS 2 Daemon. There is only one daemon and that daemon can only run one set of communication settings at a time.  For more information on what the ROS 2 daemon is read this draft documentation that will be going up on the clearpath documentation website soon: https://github.com/clearpathrobotics/cpr-documentation/blob/feature/networking/docs_versioned_docs/version-ros2humble/ros/networking/ros2_communication.mdx
So this means that although setup.bash files can be created for each robot, the ROS 2 CLI cannot be used with more than one robot at a time and when switching between robots the daemon would need to be restarted. If you are not planning to use the CLI at all in these individual terminals then using the individual setup files for each terminal will be sufficient. If you want to use the CLI then a different solution is necessary. Depending on what you are trying to do it may be more useful to use some other type of filtering when running commands in different terminals while still having the daemon connected to all robots. Alternatively, you can ssh into each robot and run the commands on board. By default the robots will not be able to see each other and functionally the result of using the CLI would be similar. I would need more context to provide more concrete recommendations. I will still answer your specific questions below though:

Setup discovery server again and use different port for each robot as explained in the Ros2 humble docs .

You only need to set a different port for different discovery servers if you are running multiple servers on the same computer. If you are still only going to be running the one server on each robot then no changes are necessary here. In that example the ports have to be unique because two servers are run on the same computer. If you still want to change the ports, it can be done through the Turtlebot4 setup tool under discovery server.

Create individual setup.bash files for each robot that only exports their server address. How should the content in these bash files look like?

Assuming that you are leaving the discovery servers on the default port, all you need to change is to remove the extra IP's for the robots that you do not want to listen to while keeping any of the semicolons. These semicolons designate the server ID. Use the same setup.bash file except change the ROS_DISCOVER_SERVER export line to one of the following:
For robot 1 use:
export ROS_DISCOVERY_SERVER="<IP_ADDRESS>:11811"

For robot 2 use:
export ROS_DISCOVERY_SERVER=";<IP_ADDRESS>:11811"

For robot 3 use:
export ROS_DISCOVERY_SERVER=";;<IP_ADDRESS>:11811"

For robot 4 use:
export ROS_DISCOVERY_SERVER=";;;<IP_ADDRESS>:11811;"

Can someone explain each line in my current setup.bash file? I want to understand what happens when I source the above bash file.

source /opt/ros/humble/setup.bash # This tells the terminal where to find the basic ROS commands and defines which of the installed ROS distributions is used
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp # This chooses the ROS Middleware, which vendor's software is used to manage ROS 2 messages, Fast DDS or Cyclone DDS
[ -t 0 ] && export ROS_SUPER_CLIENT=True || export ROS_SUPER_CLIENT=False # This checks if it is being run in the terminal and if so, it sets the terminal as super client. That means that the terminal will have access to all information from the discovery servers, not just what it knows about in advance (necessary for ROS CLI but undesired for normal nodes)
export ROS_DOMAIN_ID=0 # Sets domain Id but that doesn't matter for discovery server
export ROS_DISCOVERY_SERVER="<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;" # Sets which servers to connect to and indicates the IP address, Server ID and Port number for each of them.

Thank you for the clear and thorough explanation—it answered all of my questions perfectly.
I’ve been encountering some discovery issues when running ROS 2 nodes and services. In my setup, I have four Turtlebots, each using a discovery server, and I run AMCL and Nav2 on these Turtlebots by SSHing into them from my laptop. As a result, I need to open eight SSH terminals plus one more terminal to run a navigator node that sends goal locations to each Turtlebot. Even though I can see the services with the ROS 2 command-line tools, the navigator node sometimes reports that it’s still waiting for waitUntilNav2Active on the third or fourth Turtlebot.
Because of these issues, I’m considering separating the discovery server to help reduce network clutter and simplify the process of locating topics and services.
Any other suggestion would be greatly appreciated.

I need to better understand the situation a bit before I can provide much in terms of suggestions but here are my thoughts and questions so far.
In regards to opening so many terminals, you could set up Nav2 and localization to launch automatically on the robots so that you don't have to launch them manually each time. (Create a new Ubuntu service that runs a script to start the nodes, you could put them together into 1 launch file that gets started by the script. Then you can start / stop / enable / disable the service as desired.)
My understanding from what you have said is that each Turtlebot has been set up with it's own Discovery Server. Do you have these discovery servers connected? (aka can turtlebot #1 see the topics from turtlebot #2 and turtlebot #3 etc?). Based on what you have said about running into issues by robot 3 and 4, it sounds like you could have them connected or it could be the issue I talk about in the last paragraph.
What do you mean by "separating the discovery server". I would suggest not having the servers connected. That being said, by default they should not be connected.
What I suspect may be part of the issue here is the role of super clients. By default, your terminal (on the robot and offboard) will act as a super client. This is required for the CLI tools to work properly (to be able to run topic list and node list etc.). However, this can be problematic when you are launching large nodes directly from terminal. Super clients get all of the information from a server, not just the information that they need. However, this can cause a lot of unnecessary traffic. Nav2 has a lot of nodes so if they are all being launched as super client then that is not good news. Whenever you are launching a node from the terminal either first set export ROS_SUPER_CLIENT=False or prefix your command with ROS_SUPER_CLIENT=False <your run or launch command>. For example ROS_SUPER_CLIENT=False ros2 run teleop_twist_keyboard teleop_twist_keyboard. The first option will change that terminal to no longer act like a super client, the second will not change the terminal but it will specifically run that command with super client as false. If you launch using the service then it should not be a problem because when you source the setup.bash it will detect it as not a terminal and leave super client as false.
Please let me know if this helps, and which of this info you don't think is captured well in the documentation. I think there is definitely some improvements that can be made based on this discussion.

Thank you for your reply. This discussion has been really helpful. Sorry for my sentence formation, its probably confusing and so Ill explain my setup and situation below again in a better way.
First I have taken your suggestion of creating a Ubuntu service for Navigation and localization. It was really helpfull. Do you have any suggestions for my implementation? I used a timer and service.

my_tb4.timer

[Unit]
Description=Delay launching my_tb4.service by 180 seconds

[Timer]
OnBootSec=180s
Unit=my_tb4.service

[Install]
WantedBy=multi-user.target```
my_tb4.service

my_tb4.service

[Unit]
Description=My TurtleBot4 custom launch

After=turtlebot4.service
Requires=turtlebot4.service

[Service]
Type=simple
User=ubuntu

# Source BOTH the turtlebot4 setup and your custom workspace
ExecStart=/usr/bin/bash -c " \
  source /etc/turtlebot4/setup.bash && \
  source /home/ubuntu/tb4_ros2_ws/install/setup.bash && \
  ros2 launch my_tb4 my_turtlebot4_startup.launch.py \
"

Restart=on-failure

[Install]

Moving on about my issues with discovery when running ROS 2 nodes and services.
Current Setup.

Four TB4 (2 lite 2 standard) with onboard discovery server running on raspi (NO interconnection between TB4s).
On the PC I export the discovery servers using only this command export ROS_DISCOVERY_SERVER="<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;<IP_ADDRESS>:11811;" in terminals when I want to run some nodes or launch files.
ROS_SUPER_CLIENT is not exported, assuming its automatically false.
/etc/turtlebot4_discovery/setup.bash is also not sourced in the bashrc. Checked!
Test: I created a launch file that runs four nodes to send goal location to each turtlebots. Launch file given below.

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package='turtlebot4_python_tutorials',
            executable='nav_to_pose1',
            name='nav_to_pose1',
            namespace='/robot1',
            output='screen',
        ),
        Node(
            package='turtlebot4_python_tutorials',
            executable='nav_to_pose2',
            name='nav_to_pose2',
            namespace='/robot2',
            output='screen',
        ),
        Node(
            package='turtlebot4_python_tutorials',
            executable='nav_to_pose3',
            name='nav_to_pose3',
            namespace='/robot3',
            output='screen',
        ),
        Node(
            package='turtlebot4_python_tutorials',
            executable='nav_to_pose4',
            name='nav_to_pose4',
            namespace='/robot4',
            output='screen',
        ),
    ])

nav_to_pose1 python script looks like this (Other pythons scripts just have different goal locations)

import rclpy

from turtlebot4_navigation.turtlebot4_navigator import TurtleBot4Directions, TurtleBot4Navigator

def main():
    rclpy.init()

    navigator = TurtleBot4Navigator()

    # Start on dock
    # if not navigator.getDockedStatus():
    #     navigator.info('Docking before intialising pose')
    #     navigator.dock()

    # Set initial pose
    # initial_pose = navigator.getPoseStamped([0.0, 0.0], TurtleBot4Directions.NORTH)
    # navigator.setInitialPose(initial_pose)

    # Wait for Nav2
    # navigator.waitUntilNav2Active()

    # Set goal poses
    goal_pose = navigator.getPoseStamped([0.0, 2.108], TurtleBot4Directions.NORTH)

    # Undock
    # navigator.undock()

    # Go to each goal pose
    navigator.startToPose(goal_pose)

    rclpy.shutdown()

if __name__ == '__main__':
    main()

OUTCOME:

Nothing happens when I launch the above launch file.
What worked for me was this bash script for running the above python nav to goal scripts. This is what I meant by separating discovery servers.

#!/bin/bash

# Command for robot1
(
    export ROS_DISCOVERY_SERVER="<IP_ADDRESS>:11811;"
    ros2 run turtlebot4_python_tutorials nav_to_pose1 --ros-args -r __ns:=/robot1
) &

# Command for robot2
(
    export ROS_DISCOVERY_SERVER=";<IP_ADDRESS>:11811;"
    ros2 run turtlebot4_python_tutorials nav_to_pose2 --ros-args -r __ns:=/robot2
) &

# Command for robot3
(
    export ROS_DISCOVERY_SERVER=";;<IP_ADDRESS>:11811;"
    ros2 run turtlebot4_python_tutorials nav_to_pose3 --ros-args -r __ns:=/robot3
) &

# Command for robot4
(
    export ROS_DISCOVERY_SERVER=";;;<IP_ADDRESS>:11811;"
    ros2 run turtlebot4_python_tutorials nav_to_pose4 --ros-args -r __ns:=/robot4
) &

# Wait for all background processes to finish
wait

echo "All commands completed."

Remarks

Is my launch file approach wrong?
What is the correct way to interact with mutiple TB4 in the case of sending simulatenous goals/ waypoint following/ cooperative task etc

Do you have any suggestions for my implementation? I used a timer and service.

Is there a specific reason that you created the timer? You don't need to have a timer to trigger the service. Having created the service and having it enabled, it will automatically trigger according to the After condition.
I would also suggest adding the RestartSec=3 parameter alongside Restart=on-failure parameter in my_tb4.service to add a slight delay on restart to give better confidence that the ROS components fully shutdown before they are restarted.

Moving on about my issues with discovery when running ROS 2 nodes and services.

You are correct that super client will be false by default if you are not sourcing the turtlebot setup.bash, and you are not exporting it manually. It is generally good practice to check to ensure that it wasn't exported unintentionally. You can check it by running one of the options below:
printenv | grep ROS  # Will display all environment variables that have been exported and include the text ROS, case sensitive
echo $ROS_SUPER_CLIENT  # Will directly display the contents of the ROS_SUPER_CLIENT variable if it has been exported

Is my launch file approach wrong?

Your launch file looks good to me, I am not sure why it is performing differently than your script although it does suggest that it could be an issue with the server IP's not being communicated properly in that terminal or that they are not subscribing properly. Can you share the full terminal output from after you launch it and then wait for a minute? In addition, after you run the launch file, can you check that the nodes were launched and discovered successfully (run ros2 node list in a new terminal with the correct discovery server settings) and then if present, check that the nodes are subscribing to the correct topics (run ros2 node info </namespace/node_name> where you replace </namespace/node_name> with the fully qualified name of the node that you are inspecting). If the node does not show up in node list it does not indicate whether it is a launch problem or a networking issue though. We can go from there in terms of troubleshooting where the issue is.

What is the correct way to interact with mutiple TB4 in the case of sending simulatenous goals/ waypoint following/ cooperative task etc

What you have is a good place to start. When you start wanting to coordinate more complex cooperative tasks, then it will be beneficial to replace the turtlebot4 navigator with your own custom node. This node would be the collective director of all of the movements. In this node you would create your 4 instances of BasicNavigator (the node that turtlebot4 navigator extends), and you would directly call the Basic Navigator functions similar to how Turtlebot4Navigator calls them (see the turtlebot4 navigator source code). In this way your one node will have detailed feedback on each robot and be able to react and coordinate the robots. However, it is important to remember that all of this functionality is in one thread and to not block the thread.
If you got to a point where the system was more complex than a single thread could handle then you could break some of it into separate nodes and use topics or services to pass information/commands between the nodes or you could create multiple threads out of one node.
It is important to understand that the Turtlebot4Navigator is an abstraction of BasicNavigator. Turtlebot4Navigator offers a narrow set of functionality that is simple to implement in a script. BasicNavigator offers more functionality but is slightly more complex to implement. However, BasicNavigator is still an abstraction of the full Nav2 package that exists to make the Nav2 functionality available in a library format. At its core, Nav2 operates using the normal ROS 2 actions and services alongside the topics. I mention this because it can be helpful to know that how you use these simplified navigators is not how you normally interact with other ROS 2 nodes. Generally to trigger something to happen in a different node, it involves publishing to a topic, calling a service or using an action, not calling a member function.


[Samples][GTK] Allcontrols/TicTacToe

TicTacToe/AllControls GTK throughs a nullreferenceexception at start.

The issue happens when using NavigationPage.
I think this will be handled with next update of XF: https://github.com/xamarin/Xamarin.Forms/pull/6462
@TimLariviere
or do you think that would be an issue on our side? The PR looks a lot like the problem here.

@SergejDK Just ran into this issue. You're right, it's the same issue that is fixed in the Xamarin.Forms PR.
We can wait for the fix to come out.

@TimLariviere
normally this was planned for 4.1 but was moved to 4.2 so currently the issue is still there... Thought it will be in 4.1.
We have to wait for 4.2 then.


Filter json fixes

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


How to build P-Slice Engine 0.6.3?

What is your question?
i want to build the psych 0.6.3 version of P-Slice

nvm,i see that branch,suggest to update the readme


I cannot find any list of the available Icon Names

Using the tutorial, I very easily created an icon:
<Icon name='ios-mic-outline' />

I cannot find where this icon name came from or find a list of other icons in the ios-mic family.  How do I find them?

I'm not a familiar with this repo, but looking at the dependencies, I'd suggest you look around here https://github.com/oblador/react-native-vector-icons

Thanks @wkw , but I've looked through that and can't find any referrences to icon names that start with "ios-"

Ahh got it!  You have to click right on the ionicons link.

I was also having issues with this lack of documentation, but I think IonIcons is the default, but you can choose a different icon set in your NativeBase theme file.


Fixed a typo where link text was repeated in about-admin-roles.md

Fixed typo where link text was repeated at the end of paragraph 3.

@JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks

@kwekuako Please merge this PR. Thanks.

@kwekuako Looks like this has been fixed already in the document. So this PR can be closed. CC: @yogkumgit

Bug already fixed.


(Update): Adding .python-compile-env env var support for pip install

Continued from #750 - our Travis tests need creds to run, so commit was rolled over from tomasbielskis:master so tests could run using my creds.
Recap: Airflow requires an env var. This is a bit tricky in an ephemeral build environment and (confirmed) can't be addressed by independently setting app env vars.
<3 Airflow

@CaseyFaist please let me know if there's anything else I could do to help move this forward!

Hi, would really like to push this PR forward so that we can update our version of Airflow on Heroku. We currently also have an opened ticket regarding this issue.

@tomasbielskis that sounds about right. I'll pull down and test it with some airflow installs, will report back shortly

for context, the errors seen with heroku-toolbelt are part of several CI and testing updates the buildpack needs; those updates are in process, but in order to get this feature unblocked I'm rolling the bare minimum needed into this PR 👍

I see that the same issue of missing file still exists. 😭All of the sourced files seem to exist in the bin directory. I wonder if moving the command to one of the step scrips would work or if something else needs to be done to the bash linter to allow it to pass. Otherwise the -f command seems correct. Thanks for all of your help @CaseyFaist and @tomasbielskis!

hey @theodoresiu!
After rooting around, the issue is that shellchecking a file should only happen for files that live in this buildpack. The env file we're trying to add, by definition, is going to live in the user's repo - so that's why we're seeing that error.
I'm not giving up yet though! We may be able to use the pre_compile script as a path forward - this runs in a subenv so it doesn't help us pass env vars around as is, but a second build-env process might do the trick

Hmm. Not the quick fix I was hoping it would be, so I'm going to pull out the travis updates and push those up separately.
The Makefile is running the shellchecks, and shellcheck is supposedly active for everything in that hook step directory, so that shouldn't be the issue - my hunch is that we're not sourcing from the correct directory.
Heads up, I'm resetting this branch to your most recent commit to keep the branch clean 👍

@tomasbielskis @theodoresiu looks like we have a winner, based off of https://github.com/heroku/heroku-buildpack-python/pull/639/files. It's the opposite of generic, and I've instead opted to add support specifically for airflow to the pip-install step. I set this PR as the buildpack on a test app with apache-airflow==1.10 in the req file, and with SLUGIFY_USES_TEXT_UNIDECODE set in my Heroku configs, it successfully installed 🎉

Great, thanks a bunch Casey so will this be part of the standard python buildpack once merged?

@theodoresiu it needs to go through the release process, so it won't be immediately accessible after merge. I'll need to move the revised changes to a clean PR as well, as review requested some changes. Release should be in production beginning of next week, Tuesday at the latest, as we have one release to push ahead of this one 👍

@CaseyFaist Sounds great! Thank you for all your help on getting this through.


hubble: Check for flow type in TCP flag flow filter

Cilium agent crashes when an L7/HTTP flow is passed to TCP flag flow
filter (filterByTCPFlags). This is because HTTP flows will have
some L4/TCP info such as src/dst port in the flow struct, but will not
contain TCP flags.
Added checks to look for TCP flags in the flow struct only if the flow
is of type FlowType_L3_L4
Signed-off-by: Wazir Ahmed<EMAIL_ADDRESS>

Hey @wazir-ahmed , can you check if the image is updated once this PR is merged?

Yes. A new image is pushed to Accuknox docker hub. But the repo is accuknox/cilium-ci, not accuknox/cilium. We need to push accuknox/cilium manually.


Develop and publish package with projects stego functions

Done under URL: https://github.com/LSWarss/DisguisedSwiftly


[URGENT] Update Projects tab

Instead of the structure being
Projects/Industry
Projects/Research
Projects/Entrepreneurial
We should have all of them listed on the same page.
We should also have some nice graphics, some pictures of teams, and some information on how to apply to become a project manager (link to https://ml-purdue.github.io/apply/).

https://github.com/ML-Purdue/ml-purdue.github.io/commit/b829f37cd50fdeac310e94de81a968eaff818ada


MAISTRA-1751: Set securityContext.fsGroup to comply with restricted SCC

This is a rewrite of 46f0f4a819 for the Maistra 2.1 / Istio 1.8 rebase.

/test unit

/test unit


++og is a bad RNG

Using rads:og does something weird with the entropy, causing it to have a very low period if requesting low numbers.
> a.+:(~(rads og 54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308) 100)
54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308

Asking for random numbers below 5, for example, pretty much immediately gets the state stuck producing 0. Below 100 stalls extremely quickly as well, while asking for numbers below 100.000 doesn't visibly start looping in the few samples I took.
I imagine this could impact the crypto implementation quite heavily. cc @juped

I don't think og is used anywhere in crypto, since it's just a wrapper
around repeated sha256; though this is still a problem.
On Saturday, 14 May 2016, chc4<EMAIL_ADDRESS>wrote:

Using rads:og does something weird with the entropy, causing it to have a
very low period if requesting low numbers.

a.+:(~(rads og 54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308) 100)
54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308

Asking for random numbers below 5, for example, pretty much immediately
gets the state stuck producing 0. Below 100 stalls extremely quickly as
well, while asking for numbers below 100.000 doesn't visibly start looping
in the few samples I took.
I imagine this could impact the crypto implementation quite heavily. cc
@juped https://github.com/juped
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/urbit/arvo/issues/136

That's very odd.  Hopefully it's obvious why?
Sent from my iPhone

On May 14, 2016, at 11:08 AM, chc4<EMAIL_ADDRESS>wrote:
Using rads:og does something weird with the entropy, causing it to have a very low period if requesting low numbers.

a.+:(~(rads og 54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308) 100)
54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308
Asking for random numbers below 5, for example, pretty much immediately gets the state stuck producing 0. Below 100 stalls extremely quickly as well, while asking for numbers below 100.000 doesn't visibly start looping in the few samples I took.

I imagine this could impact the crypto implementation quite heavily. cc @juped
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

Not ~obvious~; "get (bex (xeb n)) bits, repeat if this overstepped bounds"
did always seem weird, though I can't think of any actual problem with it.
On Saturday, 14 May 2016, cgyarvin<EMAIL_ADDRESS>wrote:

That's very odd. Hopefully it's obvious why?
Sent from my iPhone

On May 14, 2016, at 11:08 AM, chc4<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:
Using rads:og does something weird with the entropy, causing it to have
a very low period if requesting low numbers.

a.+:(~(rads og
54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308)

54.644.944.555.6<IP_ADDRESS>0.829.203.651.083.812.308.778.820.336.249.263.593.388.376.425.639.601.308

Asking for random numbers below 5, for example, pretty much immediately
gets the state stuck producing 0. Below 100 stalls extremely quickly as
well, while asking for numbers below 100.000 doesn't visibly start looping
in the few samples I took.
I imagine this could impact the crypto implementation quite heavily. cc
@juped
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/urbit/arvo/issues/136#issuecomment-219235716