Simplification of cascade delete fluent API

While looking at customer reported issues related to OnDelete(DeleteBehavior) fluent API, we came to the conclusion that what we have today in EF Core is just too confusing:
DeleteBehavior conflates change tracking and database behavior in a single place and the behaviors resulting from the options available (Cascade, SetNull and Restrict) do not align with users' expectations.
There are reasons for the misalignment:

When we originally designed the API, we naively expected we would make SetNull the default for nullable FKs and Restrict the default for non-nullable FKs. The change tracking and database behavior could align!
However we hit a wall very quickly with that: in particular in SQL Server, setting multiple FKs to either SetNull or Cascade results frequently in cycles, which typically yield this error:

Introducing FOREIGN KEY constraint 'Foo' on table 'Bar' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints

The backup plan was to:

Make Restrict the default behavior in the database
Make the default behavior in change tracking always try to set keys to null regardless of whether Restrict or SetNull was specified.
Only DeleteBehavior.Cascade makes the change tracking and database behaviors align

Proposal:

Obsolete the OnDelete fluent API and the DeleteBehavior enum used in its argument

Create a new simple bool-based API that indicates only if deletes should cascade. This will control both the change tracking and (indirectly) the database behavior. Several naming alternatives are:

WillCascadeOnDelete: this is what we had in EF6
CascadeOnDelete: shortened version of the above
OnDeleteCascade: closer name to current API in EF Core and closer to the SQL syntax

EF Core will continue to have current default behaviors, e.g. it will set it to false if the FK is nullable, true if the FK is non-nullable. When the API is called with no arguments, that means true. Otherwise we use whatever Boolean value is specified.

Relational can have its own API that represent more granularly what can go in the database's ON DELETE clause. We need to look at how easy it is to drop down to metadata to specify annotations in the model for this. Incidentally, we already have this enum that seems to cover all the necessary options in migrations:

namespace Microsoft.EntityFrameworkCore.Migrations
{
    public enum ReferentialAction
    {
        NoAction,
        Restrict,
        Cascade,
        SetNull,
        SetDefault
    }
}

When cascade deletes are disabled, the behavior in change tracking will continue to be setting nullable keys to null and tracking conceptual nulls for non-nullable keys.

Providers will be free to choose how to best match the default change tracking behavior. E.g. in the case of SQL Server, OnDeleteCascade(false) will result in ON DELETE NO ACTION, but on a different provider for a database which doesn't fail eagerly on cycles, it could produce ON DELETE SET NULL.

@roji @ErikEJ and everyone, we were wondering if you could provide any insights on the most appropriate default cascade behavior for nullable FKs across databases you are familiar with. There are two "schools of thought" on this:

The provider should match the change tracking behavior as closely as possible and use ON DELETE SET NULL. This probably introduces a performance penalty because it needs to effectively do an extra update, but it also probably removes the need to check that the constraint is met afterwards.
We should be conservative and keep ON DELETE RESTRICT as the default, not encourage any providers to deviate from that, etc. This means dependents not loaded in memory can cause the deletion of the principal to fail unexpectedly. But on the bright side it takes care of performance and cycles concerns.

The SQL Compact engine only support CASCADE! https://technet.microsoft.com/en-us/library/ms173393(v=sql.110).aspx

Add Default enum and make it the default. It will be the hybrid behavior--set null in the state manager, restrict in the database.
We will make Restrict work in the state manager even for nullable FKs, by re-using the conceptual null code.

set null in the state manager, restrict in the database.

Is this just the behavior on SQL Server, or the semantic meaning of Default?
In other words, if a provider supports ON DELETE SET NULL without getting may cause cycles or multiple cascade paths errors, are they free to make SET NULL in the database the behavior of Default?

I think that's an open question, but probably yes. However, it might be better for that provider to have a convention that makes SetNull the default.

A few more thoughts on this

Default may not be the name we are looking for:

This option represents only the default for nullable FKs. For non-nullable FLs the default is still Cascade. Correct?
In relational databases SET DEFAULT is one of the options for ON DELETE, so it is confusing

Another tweak could be to just use SetNull by convention and have a SQL Server convention that overrides with Restrict or NO ACTION. I think if the user explicitly asks for SetNull it should win over the SQL Server convention because of the configuration source. Makes sense?
If we decide providers should try to do SET NULL, we should add a spec test (and override it for SQL Server and SQL CE)

@divega How about this?
/// <summary>
///     <para>
///         Indicates how a delete operation is applied to dependent entities in a relationship when the
///         principal is deleted or the relationship is severed.
///     </para>
///     <para>
///         Behaviors in the database are dependent on the database schema being created
///         appropriately. Using Entity Framework Migrations or <see cref="DatabaseFacade.EnsureCreated" />
///         will create the appropriate schema.
///     </para>
///     <para>
///         Note that the in-memory behavior for entities that are currently tracked by
///         the <see cref="DbContext" /> can be different from the behavior that happens in the database.
///         See the <see cref="Hybrid" /> behavior for more details.
///     </para>
/// </summary>
public enum DeleteBehavior
{
    /// <summary>
    ///     <para>
    ///         For entities being tracked by the <see cref="DbContext" />, the values of foreign key properties in
    ///         dependent entities are set to null. This helps keep the graph of entities in a consistent
    ///         state while they are being tracked, such that a fully consistent graph can then be written to
    ///         the database. If a property cannot be set to null because it is not a nullable type,
    ///         then an exception will be thrown when <see cref="DbContext.SaveChanges()" /> is called.
    ///         This is the same as the <see cref="SetNull" /> behavior.
    ///     </para>
    ///     <para>
    ///         If the database has been created from the model using Entity Framework Migrations or the
    ///         <see cref="DatabaseFacade.EnsureCreated" /> method, then the behavior in the database is a
    ///         sensible default for that database provider. Some databases cannot easily support the
    ///         <see cref="SetNull" /> type behavior described above for tracked entities, especially if there are
    ///         cycles in relationships. Therefore, for many database providers, the default behavior in the
    ///         database will be equivalent to a <see cref="Restrict" /> behavior where an error will be generated if a
    ///         foreign key constraint is violated.
    ///     </para>
    ///     <para>
    ///         This is the default for optional relationships. That is, for relationships that have
    ///         nullable foreign keys.
    ///     </para>
    /// </summary>
    Hybrid,

    /// <summary>
    ///     <para>
    ///         For entities being tracked by the <see cref="DbContext" />, the values of foreign key properties in
    ///         dependent entities are not changed. This can result in an inconsistent graph of entities
    ///         where the values of foreign key properties do not match the relationships in the
    ///         graph. If a property remains in this state when <see cref="DbContext.SaveChanges()" />
    ///         is called, then an exception will be thrown.
    ///     </para>
    ///     <para>
    ///         If the database has been created from the model using Entity Framework Migrations or the
    ///         <see cref="DatabaseFacade.EnsureCreated" /> method, then the behavior in the database
    ///         is to generate an error if a foreign key constraint is violated.
    ///     </para>
    /// </summary>
    Restrict,

    /// <summary>
    ///     <para>
    ///         For entities being tracked by the <see cref="DbContext" />, the values of foreign key properties in
    ///         dependent entities are set to null. This helps keep the graph of entities in a consistent
    ///         state while they are being tracked, such that a fully consistent graph can then be written to
    ///         the database. If a property cannot be set to null because it is not a nullable type,
    ///         then an exception will be thrown when <see cref="DbContext.SaveChanges()" /> is called.
    ///     </para>
    ///     <para>
    ///         If the database has been created from the model using Entity Framework Migrations or the
    ///         <see cref="DatabaseFacade.EnsureCreated" /> method, then the behavior in the database is
    ///         the same as is described above for tracked entities. Keep in mind that some databases cannot easily
    ///         support this behavior, especially if there are cycles in relationships.
    ///     </para>
    /// </summary>
    SetNull,

    /// <summary>
    ///     <para>
    ///         For entities being tracked by the <see cref="DbContext" />, the dependent entities
    ///         will also be deleted when <see cref="DbContext.SaveChanges()" /> is called.
    ///     </para>
    ///     <para>
    ///         If the database has been created from the model using Entity Framework Migrations or the
    ///         <see cref="DatabaseFacade.EnsureCreated" /> method, then the behavior in the database is
    ///         the same as is described above for tracked entities. Keep in mind that some databases cannot easily
    ///         support this behavior, especially if there are cycles in relationships.
    ///     </para>
    ///     <para>
    ///         This is the default for required relationships. That is, for relationships that have
    ///         non-nullable foreign keys.
    ///     </para>
    /// </summary>
    Cascade
}

@ajcvickers when I made my previous comment I missed that Restrict will start being honored for nullable FKs in-memory, which makes it unsuitable for the default for nullable FKs with SQL Server. So I realize we do need a new option in the enum.
A few suggestions for your proposal above:

Define the behavior of the new "hybrid" option as just straight "set null in memory but restrict in the database" (rather than "set null in memory and then maybe set null in the database but perhaps no")

Then we can name it ClientSetNull or SetNullOnClient instead of Hybrid

I am still inclined to default nullable FKs to SetNull in relational but make SQL Server use ClientSetNull instead, but I think I can be convinced otherwise :smile:. Whatever is chosen by convention should be overridable by user configuration.

Note that the SQL CE provider should also configure ClientSetNull by convention for nullable FKs but if the user configures SetNull explicitly it should throw because the database does not support it. In general if the database cannot honor a behavior it should start throwing (possibly in model validation but it might be acceptable for DDL SQL execution to fail) cc @ErikEJ

Since none of the option is really a universal default, there doesn't seem to be a compelling reason to put the new option at the beginning of the enum

Change "the behavior that happens in the database" to "the behavior applied in the database"

In relational databases SET DEFAULT is one of the options for ON DELETE, so [Default] is confusing

I don't agree with this statement. The .NET idiom of an enum value named Default is well understood. Also, having a valued called SetNull tells me that if one of the values did support SET DEFAULT, it would be called SetDefault.

@bricelam That was only the secondary argument. The primary argument is that there is actually no default value for this enum:

This option represents only the default for nullable FKs. For non-nullable Fks the default is still Cascade.


Created FilesystemFactory with a unit test

@mbed67 despite the long texts there was only one real bug: because you use a filesystem property you will have issues where, when a LogicException occurs, the previous created filesystem may be returned instead of the new one.
A good rule of thumb is: if two public methods do not share a piece of data (variable) then it should not be a property. Properties are only used to communicate between scenarios across multiple public methods

@mbed67 I am going to merge this because functionally this works as intended; I have left one comment regarding the use of exceptions; can you fix that in a new PR?


Add Thermocouple Amplifier with 1-Wire Breakout Board - MAX31850K

Thermocouple Amplifier with 1-Wire Breakout Board - MAX31850K
https://www.adafruit.com/product/1727
https://github.com/adafruit/MAX31850_DallasTemp

Looks like it might works without changes since
Arduino library supports it
https://github.com/milesburton/Arduino-Temperature-Control-Library


The battery usage details not showing up

iPhone 12 pro，iOS14.4

I'm sure it's a bug in the exploit or perhaps unc0ver itself. Be on the lookout for updates by fugu14/altstore/or unc0ver

And also did you use iCleaner?

try icleaner pro and report back

try icleaner pro and report back

Do I need to use it to clean battery usage data?

And also did you use iCleaner?

I haven't used it

I also had this issue and the Battery stats doesn't seem to work out of the box with Fugu14 and unc0ver. A work around is to use the Choicy tweak from opa334 (repository: https://opa334.github.io), after installing:
From the Settings app:

Navigate to Choicy > Daemons
Tap on Show All Daemons. Wait for the page to finish loading if it's not finished.
In the search box, type "power"
Select powerlogHelperd and toggle Disable Tweak Injection so it's switched on.
Go back and repeat the previous step for PowerUIAgent. Disable Tweak Injection should be switched on for this too.
Reboot the device and re-jailbreak OR run ldrestart from a Terminal.

5. rUIAgent. Disable Twe
I tried and nothing happened
battery usage details still stoped

Can you confirm whether this is related to rebooting (without having to run ldrestart)? I've just had a graph with nothing and it seems running ldrestart resumes the graph statistics appearing.
If this is the case then I assume that restarting or killing those daemons after everything has loaded would fix it temporarily.

Can you confirm whether this is related to rebooting (with and without the launchctl reboot userspace command) (without having to run ldrestart)? I've just had a graph with nothing and it seems running ldrestart resumes the graph statistics appearing.
If this is the case then I assume that restarting or killing those daemons after everything has loaded would fix it temporarily.

Yes, Just running ldrestart.

Choicy daemons list does not show powerlogHelperd nor PowerUIAgent (page refreshed and show all daemons clicked)
Any ideas?

Waiting Linus Henze fix

Waiting Linus Henze fix

@Ghost @jaygee562 The root cause fix is in Issue #238


Create It-Akademija

Hello can you add IT school
The main site is https://www.it-akademija.com/ ...i think the domain site is https://www.link-group.eu/
Thanks

@nemanjahxc Pull request merged. Thank you!


length of 'dimnames' [1] not equal to array extent

Hi!
I would like to solve this issue.
Thank you in advance!

Hi, thanks for using our DeepCC tools. In our defined function "getFunctionalSpectra()", each row of of the param eps, gene expression profiles, presents one sample. So you need first  transpose eps. Also, we recommend to apply logChange to eps with log2(TPM+1) or log2(TPM + 1e-6) before getting functional spectra.

x-special/nautilus-clipboard
copy
file:///home/lee/Pictures/2020-10-08%2012-31-30%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE.png

@zero19970  Thank you!
eps = log2(t(eps) + 1e-6)


rkt gc: look up for plugins in default local config

When running 'rkt run --net=mynetwork', it looks for the network plugin
in three different places 1:

/etc/rkt/net.d/ (or something else with --local-config)
/usr/lib/rkt/plugins/net
${STAGE1_ROOTFS}/usr/lib/rkt/plugins/net

This code works fine for 'rkt run' but does not work for 'rkt gc' or
'rkt rm' because there is a bug in the way --local-config is handled.
When stage1's 'run' entrypoint 2 is called, the --local-config flag
is passed. But this --local-config flag was not passed to stage1's 'gc'
entrypoint 3.
It might be unfortunate that plugin binaries can be stored in a
configuration directory but this is part of the stable rkt 1.0 interface
now. And plugins like calico rely on it.
Adding this --local-config flag would change the API between stage0 and
stage1, so we would need API versioning first. Meanwhile, use the
default local config directory.

/cc @krnowak this PR is the step 1 from https://github.com/coreos/rkt/pull/2173#issuecomment-182858955

LFAD if green.

Hm, by the way - do we have some stability promises for the API of the rkt subpackages?

I'm starting to think that the net plugins search paths should be stored in the pod, because if we start several pods, each with different --local-config parameter value, then we will need later to selectively gc them also with different --local-config parameter value. It would be so much nicer if the pod would know where to find net plugins it needs, to it can gc itself.

Taking back the LFAD for now.

@krnowak I think you are right: rkt gc should not depend on the correct --local-config parameter to work.
What about merging this patch first, so it works for the common case where --local-config is not used at all? We need more PRs for #2168 anyway.

Hrmn, dunno…
If we merge it right now, then the fix will effectively revert it, because networking.Load() will get the localConfig from the configuration in pod directory, not from the function parameter. I guess it's ok - there is nothing in this PR we cannot revert in future.

@krnowak This PR does not change any API between stage0 and stage1 so it can be changed.
The next fix storing the net plugins dir in the pod will change the on disk format so it needs to be discussed more and might take more time to review.
I just want to avoid delays in fixing #2168...


Dnsmasq without dhcp server

@agherzan @telphan

connects to #199

LGTM

LGTM again for the change with configuration file


Make filtering and lasso consistent in discovery

We should aim to make filtering as consistent as possible across the metadata widgets and lasso.

When you select a metadata column it should be represented in the embedding, maybe by opacity?
And when you clear all, the lasso selection should go away.
When you re-run projection, it should also clear the lasso selection.
Maybe when you reproject we put those filters somewhere else? I cleared it by accident a couple of times and it reset to the main filter when I just wanted it to filter to the projection

@cabreraalex when you say lasso selection, do you mean the points highlighted in the scatter or do you mean the ids stored as the lasso selection in the chip?

Hmm unsure! Maybe both? In general I think we should think a bit about how the different filters and projections should interact.


Cutting a Rod in Julia

Have you read the Contributing Guidelines on Pull Requests?
YES
Description
Cutting a Rod in Julia
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
Fixes #4993

Please make an issue here and raise a PR, for an article as part of our Docs repository: https://github.com/TesseractCoding/NeoAlgo-Docs
It would be much appreciated. Thanks!


Timestamp from chrono DateTime doesn't follow spec for pre-UNIX epoch dates

The contract for a timestamp requires that a timestamp with a negative seconds component must have a negative nanos component. As currently implemented, the nanos component will always be positive when converting from a chrono DateTime. This may cause issues with downstream consumers who expect that the nanos field will follow the behavior defined in the documentation and require a timestamp from before 1970.
For reference on how to correct this, see the implementation of From<SystemTime> in prost-types. (It would also be nice if pbjson-types included a From<SystemTime> implementation as well.)

According to the spec, the nanos field is to always be positive:

Non-negative fractions of a second at nanosecond resolution. Negative second values with fractions must still have non-negative nanos values that count forward in time. Must be from 0 to 999,999,999 inclusive.


Upgrade ArgoCD lib to 2.2.10 from 2.2.9 to fix a critical CVE

(This is for main branch, similar to v0.3) Upgrade ArgoCD lib to 2.2.10 from 2.2.9 to fix a critical CVE detected by dependabot.

If you see the results of the checks performed by GitHub actions, the Trivy code scan results here indicate that there is no change in the status.
Not sure why. The Trivy action builds a docker image and scans it for vulnerabilities - only for main branch. The check will probably pass for the next PR once this one is merged in main.

Closing this PR and merged https://github.com/arlonproj/arlon/pull/97 (PR by dependabot) instead, since dependabot can provide better detail.


menuconfig doesn't aggregate choices with the same symbol name

Example Kconfig:
choice TEST
    prompt "test"

    config A
        bool "A"

    config B
        bool "B"
endchoice

choice TEST
    prompt "more symbols"
    config C
        bool "C"
endchoice

I'm not sure if this is intended behavior or a bug, but oldconfig and menuconfig show the above choices rather differently.
oldconfig aggregates the two choices into a single selection prompt:
$ ~/.local/bin/oldconfig
test (defined at Kconfig:1)
> 1. A (A)
  2. B (B)
  3. C (C)

While menuconfig shows two distinct selection groups:
(top menu)

    test (A)  --->
    more symbols (A)  --->

Note that the "more symbols" choice group doesn't have a symbol named "A", yet its shown above.

It's intended behavior, though a bit confusing here.
When you define a symbol/choice in multiple locations, you're still creating just a single symbol/choice, which gets the union of all the properties/symbols from the different definition locations.
In the oldconfig case, the interface is letting you pick among all the symbols in the choice (choice.syms).
In the menuconfig case, you're always just walking the menu tree. There, there are two different menu nodes for the choice. The first menu node (with prompt "test") has the menu nodes for A and B as its children, and the second menu node (with prompt "more symbols") has the menu node for C as its child.
The only special logic for choie symbols in the menuconfig interface is (1) how they're displayed, and (2) that selecting a choice symbol automatically jumps back to the parent menu.
What's shown between () in the menuconfig interface is still the selection of the entire choice (node.item.selection, where item is the choice).
As a side note, people sometimes (seen it once in the kernel) do weird stuff like having a symbol within a choice depend on the symbol before it, which makes it so that the symbol with the depends on is no longer considered a choice symbol (completely undocumented).
When configuring such a choice, you can end up with weird stuff like this, which shows that it's just the menu structure you're seeing:

It seems named choices with multiple prompts are broken in the C menuconfig (can't select the items from one of the definitions at all, and only the symbols that appear within the other definition), so no reference for behavior there. I don't think it would be too tricky to change it so that you can select all symbols at both locations. Not sure what makes the most sense there though.

I suspect that having a named choice with symbols added from two locations might be broken in general in the C tools.

Hmm... leaning towards showing all choice options in menuconfig too. Less confusing.
Think it would work to special-case choices so that all child menu nodes from all definition locations are shown when you enter the choice. I'll look into it a bit later.

I made the change in the menuconfig: https://github.com/ulfalizer/Kconfiglib/commit/13884e934ec8eda928234c6506ae27f0334ec31b
Let me know if you spot any issues. I'll wait a bit before pushing out a release with it.

The choice case now works. What's interesting is that you can have a sourced file include entries to choices in the top Kconfig.
choice TEST
    prompt "test"
    config A
        bool "CHOICE_A"
    config B
        bool "CHOICE_B"
endchoice

config DUMMY1
    bool "Dummy1"

osource Kconfig.include

choice TEST
prompt "test"
depends on 0
config C
    bool "CHOICE_C"

endchoice

The "depends on 0" hides the second choice. What you get is this:
![2018-08-25-205501_206x80_scrot](https://user-images.githubusercontent.com/1593069/44621600-33fda380-a8a9-11e8-8762-a71a514510c4.png)
![2018-08-25-205518_174x80_scrot](https://user-images.githubusercontent.com/1593069/44621602-3829c100-a8a9-11e8-91f8-fa8e71a2fbfb.png)

Menuconfig still shows separate options:
menuconfig TEST
    bool "test"
    config A
        depends on TEST
        bool "CHOICE_A"
    config B
        depends on TEST
        bool "CHOICE_B"

config DUMMY1
    bool "Dummy1"

menuconfig TEST
    bool "test"
    config C
        bool "CHOICE_C"
        depends on TEST

The version is v10.2.1-5-gdbd9c59 (dbd9c59a4de57089de9f39d38e451ce8e6a869ba)

The menuconfig case is expected. Internally, you're creating this menu structure:
["test"]->["CHOICE_A"]
   |           |
   |           v
   |      ["CHOICE_B"]
   v
["test"]->["CHOICE_C"]

The two menu nodes with prompt "test" both point to the symbol TEST, and it can be configured at either location. If you toggle one of them, you'll see that the other one changes too. You can even use a different prompt at each location.
Lots of things depend on Kconfig working this way, so it's unlikely to change. The choice fix is more of a hack that merges the menu trees at the two locations (because I agree that it makes things less confusing there). In general, the menu tree is "static" though.
<soapbox>
Some general advice from experience is to strive for simplicity and avoid multiple definition locations unless you have a super good use for them (e.g., if the symbol definitions absolutely have to be dynamic). Many projects go a bit crazy with them, creating Kconfig configurations that are hard to understand.
IMO, having one long symbol definition isn't obviously worse if you need to support multiple boards or the like. It centralizes information (making stuff easier to find) and makes the behavior simple to understand.
Note that you can put an if on the prompt if the symbol should only be configurable on some boards and have some fixed value on others.
The Linux kernel uses very few multiply-defined symbols, FWIW.
</soapbox>

The misunderstanding might be that you expected the second definition to change the first one too. It's more of an OR operation than an AND operation though. All the properties from the different definition locations end up on the final symbol/choice, and the menu nodes (which hold the prompts) for the different definition locations point to that finalized symbol.

Makes sense -- the only problem with the kconfig syntax is that documentation is somewhat lacking regarding these obscure situations.
I've already solved the original problem I had with orsource and globs (adding to a global choice list from several sub-kconfigs).

@pinkfluid
Yeah, kconfig-language.txt definitely lacks some details. Planning to send a patch to update it.
The docstring at the top of kconfiglib.py covers a lot more Kconfig nitty-gritty.


Externally maintained third-party platform-specific components

This is a follow-up to https://github.com/UAVCAN/platform_specific_components/issues/15#issuecomment-702126881.
We need a third opinion so I would like to summon @thirtytwobits and let him choose how do we handle the inclusion of externally maintained third-party drivers:

link from README like I am proposing here in this PR [merge this PR if you choose this option]
use git-subtree [reject this PR if you choose this option]

Thanks.
Fixes #15

Did you have any chance to take a look at this @thirtytwobits :wave: ?

reading now...

My €0.01, sub-tree is great for stitching together software you strongly own. Submodule works better to keep external software at arm's length. As such, I think we should use all three based on the level of ownership the UAVCAN community is willing to have for a given platform specific component. If we feel it's essential to the success of this standard we may use a subtree to ensure we have a copy of the source in our repos and aren't at risk that the external source will disappear. If we want to encourage the use of the external component but aren't willing to maintain the local subtree then submodules can be used. If we suspect the technology is of interest but do not have the time to vet it or test new revisions when a PR to update the submodule commit is posted then we provide a link in the README.md

Thank you very much for your input @thirtytwobits (and let me add that I think you are selling yourself short, I'd say your statement is worth at least 0.02€ :wink:). You provide an interesting perspective as I've so far only evaluated git submodule, git subtree etc. under the point of view what would work best from a technical perspective. You are adding a "degree of association with UAVCAN project/support provided by UAVCAN members" dimension to what appears on the surface a simple technical procedure question.
Following your logic I must arrive at the conclusion that 107-Arduino-MCP2515 is certainly not git subtree material, but would fit either in the git submodule or link categoy, depending how the UAVCAN team judges relevance of the contribution as well as my personal ability and willingness to keep that library supported and working with UAVCAN components.

Following your logic I must arrive at the conclusion that 107-Arduino-MCP2515 is certainly not git subtree material, but would fit either in the git submodule or link category, depending how the UAVCAN team judges relevance of the contribution as well as my personal ability and willingness to keep that library supported and working with UAVCAN components.

First, I looked at your project and, how cool! I actually have a Vidor sitting on my desk and haven't found anything fun to do with it but this looks really compelling!
That said, I think this is a link type relationship right now but we can decide to pull it into a submodule as it matures and sees more use and as we mature and see more use thus filling out this repo.

Hi @thirtytwobits :wave: I'm glad you like our Viper Quadcopter project :wink: I believe the MKR VIDOR 4000 is one seriously underappreciated piece of hardware and have therefore set out to rectify that perception. I'm publishing a very irregular newsletter (newsletter publishing rate varies between 3 weeks to 3 months) on the status of the project (may also contain flame against ineptitude of certain sensor vendors). Do you want to be added to the list?
Getting back to the topic at hand, I'm fine with a link relationship for now. Ultimately I believe that Arduino as a platform is valueable to be part of the wider UAVCAN ecosystem because it removes the high entry barrier typically associated with embedded systems development.

Hi :wave: :coffee: I do realise that you guys probably have bigger fish to fry then this tiny PR. But it seems to me that we have a consensus here on merging this as a link and I kindly ask either @pavel-kirienko or @thirtytwobits to merge this PR.


Rewrite keywords?

Bug Report
Version
├── tonic v0.3.0
├── tonic-health v0.2.0
│   └── tonic v0.3.0 (*)
│   └── tonic-build v0.3.0
└── tonic v0.3.0 (*)
└── tonic-build v0.3.0 (*)
└── tonic v0.3.0 (*)
└── tonic-build v0.3.0 (*)

Platform
Darwin 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64
Crates
tonic-build
Description
Create a proto file that contains a rust keyword (e.g. type) as a field name
Try constructing the message, you will fail because you cannot set the field.
Maybe we can add a trailing underscore to the field name so it's possible to create and behind the scenes tonic translates this correctly?

This is likely an issue with prost-build rather than tonic if I am understanding correctly?

Yes you are correct, I wrongly thought that tonic-build was responsible.
As you can see here https://github.com/danburkert/prost/issues/166 and https://github.com/danburkert/prost/blob/master/prost-build/src/ident.rs#L7-L30 it needs to be r#type


Camera core.js issue

Hi, I have tried this Camera core.js and i have the below issue.
/home/pi/HAP-NodeJS/Camercore.js:14
var cameraSource = new Camera();
^
TypeError: Camera is not a function
at Object. (/home/pi/HAP-NodeJS/Camercore.js:14:20)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
at startup (node.js:139:18)
at node.js:968:3
Can you please let me know how to resolve this?

Hi Ranjith, I saw here https://medium.com/@rahulranjith/ip-camera-issues-for-rpi-hap-node-js-76b6c70d0bfc that you said you were able to add some camera controls. Could you please share that code so I can test it?
Regards
Fede


Programmer mode feature request

Switching between hex, bin, decimal in programmer mode with CTR+H, CTRL+B, CTRL+D, etc. like on some Linux distros would be nice.

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.


Add Weather Underground destination

As requested in #38 added destination for Weather Underground (WU/wunderground).
This is based on and tested on the weather board as this is all I have, however in theory it will grab any matching sensor output from other boards and upload these. However, as the rest will be silently dropped, it is probably best to only use this destination for weather boards.
Rain and luminance are not yet included as this requires conversion work and rain tracking improvements, but TODOs are placed appropriately.
Included a documentation update spelling out the above and instructions to configure. There is also an updated provisioning wizard to include WU.
As WU expects sea level adjusted pressure I have merged #159 into this PR and will attempt to keep them updated while they are both open. There is no provisioning for sea level pressure as I am unsure how best to integrate into the existing design (and my html forms knowledge is very rusty), but if this is pushed forward in #159 I will merge into this PR as well. It is possible to manually configure sea level pressure in the config file and defaults to enabled = False. Having sea level pressure disabled will simply drop the observed pressure reading from the WU upload.

Added rain per hour and rain today.
Merged rain per hour and day #169 and added these results to processing wunderground.py

Capture potential missed rain readings, see #169

Removed solar radiation TODO as values were far too low as a result of the luminance sensor being inside the Stevenson screen.

Merged local time adjustment from rain-per-hour-and-day to fix DST offset issue on weather underground accumulated rain today graph.

After experiencing some memory issues and adding a lot of logging, I've found that while the for loop to build the URL consumes a fair chunk of memory, this is automatically released as needed even mid for loop (interestingly gc.collect() added manually does nothing, have to rely on automatic collection).
The issue comes at urequests.get(url), this seems to consume around 35Kb of RAM and we never get it back until board reset, which limits cached upload count to around 4 at best.
As gc.collect() doesn't appear to be doing anything, I can't even workaround this with liberal collection, it will need more investigation.
This doesn't cause an issue in itself beyond a delay in uploads as the boards enters upload failure sleep and the RTC reset frees all the RAM for the next attempt. However, I have a new issue where the board crashes after a few hours with a memory allocation failure in the log truncation function. It isn't clear if this is exacerbated by the poor memory management of the wunderground upload or potentially related to my recent upgrade to v1.19.17 firmware which subsequently reported massive memory issues, but this still occurred on v1.19.18 which claimed to address these.
I am going to make sure I am running just the weather underground branch, drop back to v1.19.16 and see if my memory error still presents. In parallel I will try and fix the urequests memory use which will need fixing either way.

The weather station has been running without issue on v1.19.16 since my last comment, so I'm pretty confident the memory allocation issues were enviro firmware v1.19.17+ related. Just the memory consumption on request send to address so that more than 3 or 4 cached readings can be sent.

I strongly recommend that this is not pulled as is.
As per my comments on #169 :
BST should not be used for reporting times, times should be kept constant (so UTC is ideal as now, but otherwise GMT, or local equivalent).
As per issue #70 rain is currently correctly reported as per the Met office reporting requirements.
Time adjustments and data concatenation should done on the reporting side, not on the data gathering side.

@MrDrem As per my last comment on #169, there is no intent to incorporate BST into the reading timestamps, but the rain per day reading has to be calculated prior to submission for this destination and BST is required to determine local midnight for the rain/day reading to be correct, despite being submitted in UTC.
Please let me know if you are seeing anything incorrect from the intent as per #169

@Gadgetoid Rebased and includes the code from #159  and #169


Dark mode problems on Mac OS

Fonts are illegible on Mac OS when system dark mode is enabled (QT framework must detect it and change the font color, but the app background doesn't change. When the system is set to light mode it runs fine :D
The same thing might happen when dark mode is enabled on Windows?

Some of the styling parameters are set (in style.css) which is why the background is still white in dark mode, however I have missed some parameters so they are set to the default.
The styling has 3 purposes:

it sets the colour-coding of the routes, once you add them.
it makes it look less like a generic qt application
it makes the experience more consistent

2 and 3 definitely need some more work as pointed out by this bug.
The options are:

Remove styling for everything except routes and let the OS decide on all the colours. However I think the map is generated with a white background (using PIL, not QT) so that would need to be changed.
Make the styling more complete so the OS can't decide any of the colours. There could also be an alternative style for dark mode.

A quick work round is of course to remove some lines from style.css


i18next option 'lng' and 0.51.0 version crashe the nextjs app

Describe the bug
After updating the next-i18next to 0.51.0 our app crashes.
The error:
Error: No router instance found. you should only use "next/router" inside the client side of your app. https://err.sh/zeit/next.js/no-router-instance
I think that the issue is here:
File: src/hocs/app-with-translation.js
27:       i18n.on('languageChanged', (lng) => {
28:         const { router } = props
29:         const { pathname, asPath, query } = router
30:         const routeInfo = { pathname, query }
31:
32:         if (process.browser && config.localeSubpaths !== localeSubpathOptions.NONE) {
33:           const { as, href } = lngPathCorrector(config, { as: asPath, href: routeInfo }, lng)
34:           if (as !== asPath) {
35:             router.replace(href, as)
36:           }
37:         } else {
38:           router.replace({ pathname, query })   //  <<<<<
39:         }
40:       })

Occurs in next-i18next version
version 0.51.0
Steps to reproduce

Open the app 'examples/simple' in next-i18next.
Then add the option lng: 'en' in i18.js file.
Rerun the server.

Expected behaviour
At least it should not crash

That's absolutely correct - my apologies. This has been fixed with #419, and I have written test coverage to specifically cover this case to prevent regressions in the future.
@lavir If you'd like to review #419 I'd appreciate it. I can merge and release this ASAP.

Thank you!
I will check PR now

@lavir Released in v0.51.1.


One of the examples on the site don't work

https://yuescript.org/doc/#table-spreading

It was fixed since v0.15.14, got the WASM build updated on the site.


[Windows\Linux] Update Az powershell to 7.5

Description
Update Az Powershell modules to version 7.5 on Windows and Linux
Related issue:
https://github.com/actions/virtual-environments-internal/issues/3938
Check list

[x] Related issue / work item is attached
[ ] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run ubuntu1804, ubuntu2004, ubuntu2204, windows2019, windows2022


multiple definition of clock_gettime'

Issue template

Hardware description: ESP32 feather
RTOS: Arduino/Platformio
Installation type: https://github.com/rosmo-robot/linorobot2_hardware
Version or commit hash: Humble

Steps to reproduce the issue
https://github.com/rosmo-robot/linorobot2_hardware#1-motor-check
Expected behavior
Software compiles without error
Actual behavior
Linking to ticket I opened on Linorobot to avoid duplicaton: https://github.com/linorobot/linorobot2_hardware/issues/19
Additional information

Anwered here


MF-1078 - Add timestamp to published messages and use it in Transformer

Signed-off-by: Manuel Imperiale<EMAIL_ADDRESS>Resolves #1078

Codecov Report

Merging #1106 into master will decrease coverage by 0.01%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master    #1106      +/-   ##
==========================================
- Coverage   77.13%   77.11%   -0.02%
==========================================
  Files          95       95
  Lines        6771     6774       +3
==========================================
+ Hits         5223     5224       +1
- Misses       1211     1212       +1
- Partials      337      338       +1

Impacted Files
Coverage Δ

transformers/senml/transformer.go
87.50% <50.00%> (-5.61%)
:arrow_down:

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 57f7ee2...303b829. Read the comment docs.

Great @manuio, this is exactly what we needed I think!

Finally after consultation with @nmarcetic and @dusanb94 there is a prevailing opinion that this field should be called created instead of timestamp.

@drasko Isn't done?


Implement System.console().  Since this method is defined to return null

if no console is available, return null.

Please, add copyright headers

Added copyright headers


Hi i have an issue

Godot >>>>>>>>>>>>>>>>>>>>>>>>>>> unity >>>>>>>>>>>>>>>> dissonnance
thank you
and have fun

https://zulul.ga/
by the way


Difference between TypeAdapter().json_schema and BaseModel.model_json_schema

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
When presented with an annotated type with multiple Field objects that set json_schema_extra, TypeAdapter seems to combine them whereas BaseModel does not.
I was used to the behavior of BaseModel of not combining anything, which I can understand because merging json schema's is non-trivial in the case of conflicting keys. I would expect TypeAdapter to follow the same rules.
Below code example outputs the following
BaseModel.model_json_schema
{'properties': {'v': {'key2': 'value2', 'title': 'V', 'type': 'string'}},  # only contains key2
 'required': ['v'],
 'title': 'Foo',
 'type': 'object'}

TypeAdapter().json_schema
{'key1': 'value1', 'key2': 'value2', 'type': 'string'}  # contains key1 and key2

Example Code
from pprint import pprint
from typing import Annotated

from pydantic import TypeAdapter, BaseModel, Field

MyStr = Annotated[
  str,
  Field(json_schema_extra={'key1': 'value1'}),
  Field(json_schema_extra={'key2': 'value2'})
]
class Foo(BaseModel):
    v: MyStr

print("BaseModel.model_json_schema")
pprint(Foo.model_json_schema())
print("TypeAdapter().json_schema")
pprint(TypeAdapter(MyStr).json_schema())

Python, Pydantic & OS Version
pydantic version: 2.6.4
        pydantic-core version: 2.16.3
          pydantic-core build: profile=release pgo=true
                 install path: /Users/mark/.pyenv/versions/3.12.1/envs/312pydantic26/lib/python3.12/site-packages/pydantic
               python version: 3.12.1 (main, Jan  2 2024, 17:23:05) [Clang 15.0.0 (clang-15<IP_ADDRESS>)]
                     platform: macOS-14.4.1-arm64-arm-64bit
             related packages: typing_extensions-4.11.0
                       commit: unknown

@Mark90,
Thanks for reporting this. Definitely a bug - the schemas should match. I think we do actually want to merge the field infos like is done in the TypeAdapter case, but the answer should be somwhere in the fields.py or _fields.py.
Marking as a good first issue and adding to our next milestone!

@sydney-runkle I can work on this one.

@sydney-runkle  While working on the issue I found something that I want to clarify.
from pprint import pprint
from typing import Annotated

from pydantic import TypeAdapter, BaseModel, Field

def _set_key2(s):
    s['key2'] = 'value2'

CustomField = Annotated[
    str,
    Field(json_schema_extra={'key1': 'value1'}),
    Field(json_schema_extra=_set_key2),
    Field(json_schema_extra={'key3': 'value3'}),
]

class Foo(BaseModel):
    field: CustomField

print("-1. BaseModel.model_json_schema")
pprint(Foo.model_json_schema())
print("-2. TypeAdapter().json_schema")
pprint(TypeAdapter(CustomField).json_schema())

Result
-1. BaseModel.model_json_schema
fields --  {'root': FieldInfo(annotation=~RootModelRootType, required=True)}
{'properties': {'field': {'key3': 'value3',
                          'title': 'Field',
                          'type': 'string'}},
 'required': ['field'],
 'title': 'Foo',
 'type': 'object'}
-2. TypeAdapter().json_schema
{'key1': 'value1', 'key2': 'value2', 'key3': 'value3', 'type': 'string'}

Note that key2 is set by a callable json_schema_extra

The 1. result should be the same as 2. (have all keys key1, key2, key3 )  right ?

@nix010,
Great question. Seems the problem is even worse than I imagined 😂. I'd direct you to this issue to understand some more context behind modifying json schema when merging field info: https://github.com/pydantic/pydantic/issues/7686.
Even though I like the approach of the TypeAdapter more, I do think that changing this would be a breaking change. Let me chat with @dmontagu on Monday to see what he thinks the best next step is.

Alright, let's go with the TypeAdapter approach. This should also fix #7686 that I've mentioned above.
We'll want to document this as a breaking change, and illustrate to users how they can delete keys via callable json schemas!


fix: prioritize node_modules of current project

This PR changes the order of searching for node_modules, putting the relative path as the last one. It avoids, after all, duplication of dependencies.
Related Stackoverflow answer: https://stackoverflow.com/a/63992540/14397787
Webpack reference: https://v4.webpack.js.org/configuration/resolve/#resolvemodules
What kind of change does this PR introduce? (check at least one)

[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Underlying tools
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Other information:
None

It shouldn't be necessary to add these at all, webpack normally resolves X from Y which your package manager is responsible for ensuring is the right version

Why would it be necessary or useful to have two versions of vue or some other package? Shouldn't it prioritize the closest package.json since it's in the same directory of the application?

vue, much like react, is a special case in that it should be a singleton but for other packages no it shouldn't, it should follow the node_modules resolution algorithm and use the closest node_modules folder to the file.
Packages having the same name does not mean it's the same version, for example take this dependency tree:
.
├── node_modules/
│   ├── lodash@4
│   └── some-lib/
│       ├── index.js
│       └── node_modules/
│           └── lodash@3
└── main.js

With your changes both main.js and index.js would get lodash@4 which is incorrect

Ok, I got it. Thank you.


Introduce suppressible features so that the newer _Concurrency interface file can be handled by older compilers

We need two new suppressible features:

AssociatedTypeAvailability for availability attributes on associated types
AsyncSequenceFailure for the compiler support needed for the introduction of the Failure associated type into AsyncSequence and AsyncIteratorProtocol

Fixes rdar://123782658.

@swift-ci please smoke test


Clearification on unsupported scenario related to leaked credentials

[Enter feedback here]
This page mentions that "Detection of users with leaked credentials" is not supported. If I look at the flowchart/decision tree located here: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn#decision-tree
Pass-through Auth + Seamless SSO with Password has sync is the method to use when you want sign0in disaster recovery or leaked credential reports.
Which one is true, is it supported or not?
Confusing is that later the article mentions the following: "As a workaround for unsupported scenarios only (except Azure AD Connect Health integration), enable Password Hash Synchronization on the Optional features page in the Azure AD Connect wizard." - so what does this actually mean.. that it will work but it isn't supported?
Please explain, thanks in advance,
Regards,
Kenneth

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

ID: 12cbaf93-735d-e257-9203-0437bdf9d1ea
Version Independent ID: f12c0f8c-86e3-72f6-1a3c-c20ad6654017
Content: Azure AD Connect: Pass-through Authentication - Current limitations
Content Source: articles/active-directory/hybrid/how-to-connect-pta-current-limitations.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@kennethvs Thanks for the feedback !  I have assigned this issue to content author to investigate and update the document as appropriate.

Hi @SaurabhSharma-MSFT - any update on this?

@kennethvs
Thank for submitting this. I have created a work item for it and will send this to engineering so that they can review it and provide me with updated details. I am not sure what the timeline will be, so I am going to close this for now. But once I have an update I will drop it in here and let you know.
Thank you!
Bill
#please-close


Question about quantization in doc

In your doc you metion you have to "pre-quantize" coordinates before passing them to the encoder
using something like:
MVT_EXTENT = 4096
xSpan = maxX - minX
ySpan = maxY - minY
xq = int((x - minX) * MVT_EXTENT / xSpan)
yq = int((y - minY) * MVT_EXTENT / ySpan)

but in the offical doc, it says: (https://github.com/mapbox/vector-tile-spec/tree/master/2.1)
Geometry data in a Vector Tile is defined in a screen coordinate system. The upper left corner of the tile (as displayed by default) is the origin of the coordinate system. The X axis is positive to the right, and the Y axis is positive downward. Coordinates within a geometry MUST be integers.

so downwards for y and initial coordinate starts at (0,0).
Shouldn't you change it to:
MVT_EXTENT = 4096
xq = int((x - minX) * MVT_EXTENT / xSpan)
yq = MVT_EXTENT - int((y - minY) * MVT_EXTENT / ySpan)

I think that it would help performance if this library could take care of quantization by simply providing bounds and a layer name at initialization. We could then in the same loop that we are extracting the features add them gradually in a functional programming kind of style.
What do you think? I am willing to help out.

There could be scenarios where the caller knows that the coordinates are already quantized, in which case this step wouldn't be desired.
That being said, I noticed we are a little bit inconsistent because the library assumes that the geometries passed in are in a coordinate system where y is going upward. It always flips the y here: https://github.com/mapzen/mapbox-vector-tile/blob/1412c3f619149670b44efc7f71710edbd1a3e571/mapbox_vector_tile/encoder.py#L217
Maybe it makes sense to have these two assumptions be configuration options?

There could be scenarios where the caller knows that the coordinates are already quantized, in which case this step wouldn't be desired.

Yes both should be available according to me.
What distrubs me here that while I am iterating the first time through my features, I need to:

Go through all my features to create one dict I then pass to the encoder. (with quantization etc..)
And then give it to the encoder. -> Looping 2 times accross features using twice the amount of memory

I'd rather:

initialize using layerids
add the features within my first external loop (as they come)

I'll give it a try and show you what I mean.

That being said, I noticed we are a little bit inconsistent because the library assumes that the geometries passed in are in a coordinate system where y is going upward
Maybe it makes sense to have these two assumptions be configuration options?

Okay, your call I would say adapt the doc if you don't have time.


Make IMPORT resilient to transient network failures

Background: https://airtable.com/tblD3oZPLJgGhCmch/viw1DKmbKhg2MIECH/rec9YAtbhynNkQY2x
Description: When running the IMPORT statement, if a network request (e.g. for a data file in cloud storage) fails, CockroachDB will retry the failed request instead of immediately causing the entire job to fail.
Team: Roland Crosby
Github Tracking Issue:

Out of scope for 20.1

Closing for now - will open a new issue whenever this is added to the roadmap.


APMReduce: Don't repeate the same action

It would be interesting to try to do an action with a unit only if the unit is not currently doing this action. This way, the units will only move when it's a new "order".

Done in micro_improvements branch


First Time House Buyer Guide

Pre-Requisites

Get HTB Approved
Get AIP Ready with your bank of choice

Solicitor

Get Solicitor Quotes for your price range

Professional Fee

VAT at 23%

Stamp Duty

Land Registry Fee

Search Fees

Commissioner for Oaths

Choose your solicitor

Book Your Home

Book your home
Transfer Booking deposit via Bank Transfer to EA
Share Solicitor details & AIP to EA
EA sends Booking deposit receipt to your home address

Offer Letter

Share Solicitor details to Bank and initiate revised AIP/Offer Letter process with property address

Share HTB approval and Deposit receipts

Bank shares the Mortgage pack with your Solicitor for signing

Contract Signing

Builder's Solicitors share the Contracts of Sale to your Solicitor for signing
21 days to sign contracts and pay balance deposit (less booking deposit & HTB entitlement)
Review and Sign both Contracts & Loan Offer with your Solicitor
Transfer the balance deposit to your Solicitor's bank account
Your Solicitor forwards both the signed contracts & balance deposit to Builder's Solicitors
Your Solicitor forwards the Assignment of Life policy to the Bank
Get a Letter from Solicitor confirming receipt of any deposit paid to them on signing contracts
Solicitor receives a receipt of Contract and Building agreement signed by Builders

HTB Claim

Upload Contract & Building Agreement to Revenue and get HTB Claim Reference & Access Code
Share HTB Claim Reference & Access Code to your Solicitor to forward it to Builders Solicitor to verify HTB claim with Revenue

Mortgage Protection

Get quotes for Mortgage Protection
Get your Mortgage Protection ready without activating it - any GP tests, existing health issues raised and get underwriters' approval

Snagging

Get quotes for Snagging
Do Snag once Builder notifies the property is ready for Snagging
Share Snag list to Builder

Valuation Report

Get Valuation done by an approved valuer based on bank
Make sure details match as per Offer Letter
Share valuation report to Bank/Valuer shares it to the bank

Home Insurance
Contents

https://www.newhomelegals.ie/home-completed/


How can I disable Active Job status, or separately set the storage time?

A third party framework that passes very large hashes in args is now killing my Redis instance.
In the meantime, I need long-lived status (1 day) for my sidekiq workers where I am using sidekiq-status intentionally.

note: I am NOT doing this:
# app/jobs/application_job.rb
class ApplicationJob < ActiveJob::Base
  include Sidekiq::Status::Worker
end

yet, sidekiq status is logging the args of ActiveJob workers, with ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper as the Worker/JID, and always with status Working, though the jobs complete without failure.

Hmmm, this is actually happening on sidekiq-status 0.6 -- I had assumed it was a symptom of the 0.7 update, but actually was happening prior to that.
After updating to sidekiq 5.x & sidekiq-status 0.7, status of ActiveJobs is still being logged, despite the fact that I have not included Sidekiq::Status::Worker in ApplicationJob.
On my production app, trying to clear out the offending set of logged jobs by setting Sidekiq::Status::ServerMiddleware, expiration: 1  failed -- sidekiq status panel now times out.

My production mystery deepens. Redis has 7000+  sidekiq:status:* keys, though the jobpanel shows less than 100 entries.

I tried updating to 0.7.0, and including include Sidekiq::Status::Worker in ApplicationJob and defining an expiration method, but sidekiq:status still saves activejob args for the global expiration time set on the middleware.

I managed to get a separate expiration time for ActiveJob jobs with the following initializer:
module ActiveJob
  module QueueAdapters
    class SidekiqAdapter
      class JobWrapper
        def expiration
          @expiration ||= 10
        end
      end
    end
  end
end

I think if sidekiq-status is going to do anything with activejobs, some sort of control over it needs to be made available to the user of the gem.

If adding/removing include Sidekiq::Status::Worker line into active job class not controlling the enable/disable then it's a bug for sure. I will try to reproduce this at my end as per your illustration.
Out of curiosity How the following code setting separate expiration for third party jobs only? or You are trying to reduce expiration time for all active jobs?
module ActiveJob
  module QueueAdapters
    class SidekiqAdapter
      class JobWrapper
        def expiration
          @expiration ||= 10
        end
      end
    end
  end
end

For the time-being, I want to reduce expiration time for all activejobs -- my only use of activejobs is via a third-party framework. All the workers I write are direct Sidekiq workers.
It's going to be a slightly tricky bug to resolve -- in the current flow activejob hasn't actually deserialized the job yet when you're checking expiration.

Look like we might have to hack ActiveJob::Core#deserialization  or JobWrapper or Sidekiq::Status::SeverMiddleware or some combination of the aforementioned to ensure that expiration is properly consulted. At worst, we may need to provide our own :sidekiq-status job adapter which would delegate the #expiration call to the actual job class that was wrapped.

@lastobelus could I ask you to take a look at PR #113 and see if that solves your use case?

@kenaniah Thanks! it certainly looks as though it will -- I'll deploy first chance I get and let you know if I have any issues.


Disallow creating ANGLE window surfaces under UWP.

create_window_surface calls GetWindowRect, which is a forbidden UWP API.

@jdm What do you think about having the native window take a size explicitly? That would avoid calling GetWindowRect.

This is fixed in surfman 0.2.

The explicit size would also be a fine solution, from my point of view.


New log path: PulseSecure VPN

Please create a new log path for PulseSecure VPN logs.  Samples, filter and custom log path can be provided via email/Slack.

release


Add support for eslint 5

Looks like it just works.
The peer dep change sees to it that this plugin can be used in projects that use eslint 5 and npm 2 (the default in node 4) without npm install failing.

The test failure also happens on master and is due to<EMAIL_ADDRESS>Downgrading to 8.2.3 fixes it.
git bisect says:
e63962ddd340e3a412ee33d9f0ed443a88d3975f is the first bad commit
commit e63962ddd340e3a412ee33d9f0ed443a88d3975f
Author: Cristian Pallarés<EMAIL_ADDRESS>Date:   Wed Jun 6 00:18:13 2018 +0200

    refactor: rename babylon to @babel/parser

:040000 040000 c6b299854dde266cc8960551ab1ee334fd6f5e93 d08c0f67d7b0d9b795dbb8a8702ca787c3318182 M	lib

Perhaps the easiest fix is to just drop node 4 support now that everyone else in the eslint ecosystem is doing it.

@papandreou just released 8.2.5, which reverts the babel 7-b51 bump.

@ljharb, thanks for the quick response!

Please also add testing for eslint 4 vs 5 here: https://github.com/yannickcr/eslint-plugin-react/blob/master/.travis.yml

Okay, do you mean like this? https://github.com/yannickcr/eslint-plugin-react/pull/1843/commits/d71706868923a4ff1a0bb772aca90f18530e7cc2
... I guess the exact configuration depends on your answer to the below question :)

Also, please make the dev dep range for eslint identical to the peer dep range.

I tried that initially, but it makes the build fail in node 4: https://travis-ci.org/yannickcr/eslint-plugin-react/jobs/395825658#L856
Are you ready to part with node 4 support -- seems like everyone else is :)

As for node 4, no, we should not drop support for it (nobody should). I’ll look into the failing tests.

@ljharb, thanks a lot!
I agree, but eslint 5 dropped node 4 support: https://eslint.org/docs/5.0.0/user-guide/migrating-to-5.0.0#drop-node-4
Would be great for this project to maintain backwards compatibility via older eslint versions, of course.

ahhh well true, in that case for eslint 5 only, we should definitely not be testing on node 4.

ahhh well true, in that case for eslint 5 only, we should definitely not be testing on node 4.

Sounds like the right way to handle it.
It's probably faster for you to set that up? :)

Sounds good, I’ll update this PR later today.

@ljharb, thanks for landing this! Would it be possible to release a new version to the npm registry?

I’m hoping to do that tonight or tomorrow.

Released in v7.10.0


uiexplorer example - shell script invocation error

when I try to run Examples/UIExplorer/UIExplorer.xcodeproj in xcode my build is failing with a shell script invocation error.
....../Library/Developer/Xcode/DerivedData/UIExplorer-cvuxeuiwjxqjubeyadgvzpwkoezw/Build/Intermediates/UIExplorer.build/Debug-iphonesimulator/UIExplorer.build/Script-68CD48B71D2BCB2C007E06A9.sh:
line 3: ...../react-native: No such file or directory
seems like it's trying to access the react-native library in the wrong location

can anyone has a suggestion?

nice

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!
If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.


Add Dual Citizenship field to HEDA Model

The HEDA model currently has a Citizenship field with a picklist of countries. It would be nice to also have a Dual Citizenship field which should also be a picklist of countries.
Link to Power of US Hub Idea here: https://foundation.my.salesforce.com/a1W80000006blHb
Given I am a salesforce user
And I want to add contact details to a contact
When I select edit
Then a Dual Citizenship picklist field is available for me to select a second citizenship status
When I click Save
Then Dual Citizenship value is saved to the contact

**lurch: add

Tracking W-017304


440 player event registration cypress tests

Closes #440
Description
Create Cypress tests for the Player Event Registration story (#241) acceptance criteria:

Event List
Event Filter
Event Detail
Session Registration
Session Leave
Session Filter

This PR should not be approved until the seeder is changed. The tests assume that all event should have at least one empty spot to test the registration process.


Consumer with API version set to V0_10_0_0 fails to consume compressed topics

Versions

Sarama Version: master/e8020bffa1cae3ddf8068cb03416fc53d1627f3d
Kafka Version: 0.10
Go Version: 1.6

Configuration

out of the box Kafka config values
topic "test" created with --create --topic test --partitions 1 --replication-factor 1
sarama config see code : https://gist.github.com/dynamix/e7682ff7a76d28bd500ebee52c036b28

Logs
2016/08/08 15:21:57 Initializing new client
2016/08/08 15:21:57 client/metadata fetching metadata for all topics from broker <IP_ADDRESS>:9092
2016/08/08 15:21:57 Connected to broker at <IP_ADDRESS>:9092 (unregistered)
2016/08/08 15:21:57 client/brokers registered new broker #0 at <IP_ADDRESS>:9092
2016/08/08 15:21:57 Successfully initialized new client
2016/08/08 15:21:57 producer/broker/0 starting up
2016/08/08 15:21:57 producer/broker/0 state change to [open] on test/0
2016/08/08 15:21:57 Connected to broker at <IP_ADDRESS>:9092 (registered as #0)
2016/08/08 15:21:57 Initializing new client
2016/08/08 15:21:57 client/metadata fetching metadata for all topics from broker <IP_ADDRESS>:9092
2016/08/08 15:21:57 Connected to broker at <IP_ADDRESS>:9092 (unregistered)
2016/08/08 15:21:57 client/brokers registered new broker #0 at <IP_ADDRESS>:9092
2016/08/08 15:21:57 Successfully initialized new client
2016/08/08 15:21:57 Connected to broker at <IP_ADDRESS>:9092 (registered as #0)
2016/08/08 15:21:57 consumer/broker/0 added subscription to test/0
2016/08/08 15:21:57 kafka: error while consuming test/0: kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:21:57 consumer/broker/0 abandoned subscription to test/0 because kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:21:59 consumer/test/0 finding new broker
2016/08/08 15:21:59 client/metadata fetching metadata for [test] from broker <IP_ADDRESS>:9092
2016/08/08 15:21:59 consumer/broker/0 added subscription to test/0
2016/08/08 15:21:59 kafka: error while consuming test/0: kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:21:59 consumer/broker/0 abandoned subscription to test/0 because kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:22:01 consumer/test/0 finding new broker
2016/08/08 15:22:01 kafka: error while consuming test/0: kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:22:01 consumer/broker/0 abandoned subscription to test/0 because kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:22:03 consumer/test/0 finding new broker
2016/08/08 15:22:03 kafka: error while consuming test/0: kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:22:03 consumer/broker/0 abandoned subscription to test/0 because kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:22:05 consumer/test/0 finding new broker
2016/08/08 15:22:05 kafka: error while consuming test/0: kafka: response did not contain all the expected topic/partition blocks
2016/08/08 15:22:05 consumer/broker/0 abandoned subscription to test/0 because kafka: response did not contain all the expected topic/partition blocks

(removed the "ClientID set to sarama" entries)
Problem Description
Code that reproduces the issue (broker ip should be set to a proper value): https://gist.github.com/dynamix/e7682ff7a76d28bd500ebee52c036b28
A consumer where Config.Version is set to V0_10_0_0 does not properly consume compressed topics. If the Config.Version is set to any lower value - everything works as it should.
Looking at what kafka returns - the offsets of messages inside a compressed message are relative and not absolute for 0.10+. The Java Consumer has a special handling for relative offsets:   https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/record/MemoryRecords.java#L242-L318
Attempted fix (not sure if this handles all cases): https://github.com/Shopify/sarama/pull/721

Is there non-code documentation of these relative offsets? I don't remember seeing anything about this in the release notes or on https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol

None that I could find. The documentation in regards to compression does not mention this however the Java client implements it (I only checked the Java client).

@edenhill does rdkafka handle this properly? Is there documentation on this change anywhere?

Look at KIP-31: https://cwiki.apache.org/confluence/display/KAFKA/KIP-31+-+Move+to+relative+offsets+in+compressed+message+sets


Clear slots when context changes

Rasa Core version:0.7.9
Python version: 3.5.2
Operating system (windows, osx, ...): windows
Issue:
Is there way to clear slots from the context in custom actions.
I am trying to provide the response based on the slot values and number of slots identified.
Facing issue when switching between stories having different number of slots or no slots for the same intent.
The slots from first story are getting persisted in the second story, which is not intended.
Thanks,
Ramakant

You could return the AllSlotsReset event in your custom actions run method, this would set all the slots to be empty. Make sure though, to include that event as part of your training stories after the action.


when is the invalidCommand response triggered?

As far as i've seen the bot remains silent when it doesn't notice a valid command.

What types of errors does invalidCommand: "Invalid command: {message}. Try !help" can the bot identify?

@alexvarha, errors messages are only triggered when an existing command is misused.


feat: joeynet reset

This joynet configuration is the one I generated using the symbol-network tool. This pr "officialize" it by distributing it with the bundled testnet reset.
The network.yml configuration would be slightly different once https://github.com/symbol/symbol-bootstrap/pull/331 is merged.
The network, seed nodes configuration, and accounts can be found in the new private repo https://github.com/symbol/symbol-testnet
This PR includes the initial node seeds. Statistic service would be "empty" until we have launched the seed nodes.  We would need to reset and reconfigure the statistic service soon after joeynet network launch.
We can eventually remove the static list from joeynet network.yml once Statistic service is up to date.
Bootstrap supports both static and/or dynamic stats service lists.

Thans @Jaguar0625  for the feedback,

joeynet is one of (potentially many) testnets. i don't think it makes sense to replace testnet with it. instead, i think we should drop testnet/mainnet entirely and just specify preset for mainnet/joeynet/etc.

I agree, I am working on all the toolings for multiple testnet support. The shared assemblies pr, the external network preset yml and seed for pr, symbol-network cli, the blog, etc.
Joeynet would be one of many, some official, some experimental (garsuh.dev), some community, etc.
I have asked if we should keep the -p joeynet preset for this reset but we agreed to keep the -p testnet name.
https://discord.com/channels/856325968096133191/912347099155292163/912398258188484618
I think this is fine, the current NGL testnet is reaching the EOL and we are not maintaining it anymore. It seems like Joeynet is becoming the principal testnet now. The -p testnet name is fine, we don't need to change the documentation around how to run a testnet node. We are also planning to reuse old testnet URLs like faucet, stats service, and explorer. If we keep both, we would need different URLs for Joeynet

i'd also suggest having a separate repo for the seed, so we can have releases for it similar to the release we have for mainnet seed: https://github.com/symbol/catapult-client/releases/download/v<IP_ADDRESS>/nemesis-seed.zip.

I like having the most common official network seed and network.yml bundled in bootstrap. We don't need to maintain a separate hosting for the seeds and it's 'offline' friendly when generating the node configuration.

@Wayonb @Jaguar0625 , could we merge this one? it's blocking me for the testnet reset. Once I have this one I can create the new zips

Create this issue to move the seed out of the bootstrap - https://github.com/symbol/symbol-bootstrap/issues/342


After an unexpected disconnect, the ingress controller fails to reconnect and doesn't retry

My ingress controller has a tunnel that's established and running for several days. Unexpectedly, it logs a "connection reset by peer" message and tries to reestablish the tunnel. This fails because, it appears, Cloudflare is responding that a tunnel with the same name exists. The ingress controller then stops trying. After the previous tunnel times out (several minutes), I can delete the argo pod to force a new one to be created, and the tunnel is established again.
Logs:
time="2018-08-24T11:19:55Z" level=warning msg="frame read error" dir=read error="read tcp <IP_ADDRESS>:42868-><IP_ADDRESS>:7844: read: connection reset by peer" subsystem=mux
time="2018-08-24T11:19:55Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-08-24T11:19:55Z" level=error msg="Serve tunnel error" connectionID=0 error="read tcp <IP_ADDRESS>:42868-><IP_ADDRESS>:7844: read: connection reset by peer"
time="2018-08-24T11:19:55Z" level=info msg="Retrying in 1s seconds"
time="2018-08-24T11:19:57Z" level=info msg="Connected to IAD"
time="2018-08-24T11:19:57Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-08-24T11:19:57Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: Another tunnel with the same hostname and client-id <client-id> is active."

Should the ingress controller have a backoff loop but continue to retry tunnel registration when this happens?
This is 0.5.2 of the Helm chart.

We saw this as well with 0.5.2. Had to restart the controller as you did.

@marccampbell I believe I also experienced the same thing while drafting up examples and updating documentation.  I've had to take similar action, delete the controller pod and let it recreate.  I'm almost that the point of being a useful debugger/coder, I'll start investigating soon. Feel free to provide any other information/details.

Same problem with 0.5.2 disconnecting - seems to coincide with the tunnel rerouting to a different CF location for whatever reason. In an ideal world there'd be multiple tunnels established to multiple locations, but I guess that would require a fundamental change to how Argo works on the CF side?
time="2018-09-06T00:37:42Z" level=info msg="Connected to CDG"
time="2018-09-06T00:37:42Z" level=info msg="Tunnel ID: <tunnel_id>"
time="2018-09-06T00:37:42Z" level=info msg="Route propagating, it may take up to 1 minute for your new route to become functional"
time="2018-09-06T07:01:40Z" level=warning msg="frame read error" dir=read error="read tcp <IP_ADDRESS>:50028-><IP_ADDRESS>:7844: read: connection reset by peer" subsystem=mux
time="2018-09-06T07:01:40Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-09-06T07:01:40Z" level=error msg="Serve tunnel error" connectionID=0 error="tls: use of closed connection"
time="2018-09-06T07:01:40Z" level=info msg="Retrying in 1s seconds"
time="2018-09-06T07:02:40Z" level=info msg="Connected to LHR"
time="2018-09-06T07:02:40Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-09-06T07:02:40Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin to existing pool : Service temporarily unavailable."
time="2018-09-06T07:02:40Z" level=info msg="Retrying in 2s seconds"
time="2018-09-06T07:03:40Z" level=info msg="Connected to LHR"
time="2018-09-06T07:03:40Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-09-06T07:03:40Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin to existing pool : Service temporarily unavailable."
time="2018-09-06T07:03:40Z" level=info msg="Retrying in 4s seconds"
time="2018-09-06T07:04:43Z" level=info msg="Connected to LHR"
time="2018-09-06T07:04:43Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-09-06T07:04:43Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin to existing pool : Service temporarily unavailable."
time="2018-09-06T07:04:43Z" level=info msg="Retrying in 8s seconds"
time="2018-09-06T07:06:01Z" level=info msg="Connected to LHR"
time="2018-09-06T07:06:01Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-09-06T07:06:01Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: Cannot check whether Argo Tunnel is enabled"
time="2018-09-06T07:06:01Z" level=info msg="Retrying in 16s seconds"
time="2018-09-06T07:06:50Z" level=info msg="Connected to LHR"
time="2018-09-06T07:06:50Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-09-06T07:06:50Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error searching for existing pool named : Service temporarily unavailable."

@alexkinch , actually, it should be creating more than one tunnel, see #75

Aha, thanks - still a little new to Argo but had spotted recently that the standalone cloudflared was opening tunnels to multiple locations. This should definitely improve stability (I’m not going to jinx anything by asking about working around API outages!)

We're encountering the same issue. And restarting the pod does resolve it. However restarting the pod is a manual step - until this is resolved by CF is there any way to kill the pod automatically when this type of issue occurs? This is definitely preventing us from being able to rely on argo tunnel in production.

Given that the pod doesn't die or change any state that could be tied to a liveness check, I can't think of a good automated mechanism (its hard to think of reliable horrible mechanisms too ... ).  I have some changes that I believe will improve the situation.  I'll wrap those up and start planning for a 0.5.3 release (I'll attempt to do it as fast as possible to help alleviate your current pain)

@mattalberts thanks for the update. Looking forward to tryinf it out

When unrecoverable errors like this happen perhaps the pod can cause its liveness state to be unhealthy instead?

@tonyxiao that would be less desirable, the error logs are reporting the loss of a single tunnel, restarting the pod would disconnect all tunnels to rebuild the failed tunnel

I  believe I have a candidate ... anyone want to try it out?

docker.io/mattalberts/argo-tunnel:0.5.3

I'm hoping to get a few more minor things in tomorrow morning and stamp a real release, but thought people would want to play with the current release candidate?

@mattalberts just deployed it. Came up after a few minutes. It created the load balancer and pool but only 4 out of 5 origins are healthy. Not sure if that's an issue or not but it is working.  I have been using the helm chart form the http://trusted-charts.stackpoint.io repo but that had to be changed slightly to get it going with the docker image you created.
Thanks,

@mattalberts just deployed earlier and haven't seen any tunnel disconnects that didn't get resolved (before I needed to kill the pod every few hours)

@jalateras  @fouad All and all, seems like a net positive.
@jalateras two things for you,

do you have the logs for the disconnects (preferably with --v=6, but i'll take anything I can get)
when I added multi-arch docker images i update the chart within the repo (./chart).

I've merge the PR, auto-closing the issue.  But do feel free to comment, reopen, attach files .. I'll work on getting the few other fixes and then plan a release.

@mattalberts it'd be great if you can update the latest version of the chart as well to point to this release.

by the way, is http://trusted-charts.stackpoint.io still the recommended way to use the chart? Or would you recommend directly installing from repo?

@tonyxiao I agree!  I'll update the chart as soon as I officially cut a release (on the releases tab :).
I would recommend directly installing from the repo, the chart housed at http://trusted-charts.stackpoint.io will no longer be maintained.  (I can start looking for a new place to house static resources!)

Got it! I recently discovered codefresh and they have a managed helm repo which could potentially be a good fit.
https://codefresh.io/docs/docs/new-helm/managed-helm-repository/
Better yet, why not submit to the official helm charts repo?

@mattalberts I tried with the following settings
- name: argo-tunnel
    chart: ../../submodules/cloudflare/cloudflare-ingress-controller/chart
    version: ~0.5.2
    values:
      - controller:
          image:
            repository: docker.io/mattalberts/argo-tunnel
            tag: '0.5.3'

However the controller appears to be stuck at the following log line and the tunnel never gets a chance to fully start up.
I0927 16:53:34.899261       1 controller.go:308] Starting ArgoController

@mattalberts experienced a disconnect just now, here are the only logs we have:
time="2018-09-27T18:09:14Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-09-27T18:09:14Z" level=error msg="Serve tunnel error" connectionID=2 error="read tcp <IP_ADDRESS>:40148-><IP_ADDRESS>:7844: read: connection reset by peer"
time="2018-09-27T18:09:14Z" level=info msg="Retrying in 1s seconds"
time="2018-09-27T18:09:16Z" level=info msg="Connected to LAX"
time="2018-09-27T18:09:16Z" level=info msg="Tunnel ID: ufguc1dgzqiuhczknl9pis4u4znhiunul3zv6q0af95da5tbelcg"
time="2018-09-27T18:09:16Z" level=info msg="Route propagating, it may take up to 1 minute for your new route to become functional"```

At least it reconnected, after I refreshed the site a few times. Definitely a net-positive since it's at least _self-healing_ but would preferred to hold requests open until 2-3 reconnects are attempted

@mattalberts it disconnected again for the past ~15 minutes, and just reconnected now

@mattalberts can we re-open since the issue is not actually solved?

@mattalberts happy to send the logs to your email if you pass it along

@mattalberts same. Logs contain some relatively sensitive info

@jalateras @tonyxiao<EMAIL_ADDRESS>but please strip-out or mutate/obscure/corrupt anything sensitive.

@mattalberts it actually worked itself out and started back up again. I've change the log level to be always at 6 tho and will report next time its down and monitor uptime in the meantime.

Thanks for the logs and the help (sorry for any frustration).  I've just rebuilt the "preview" version of 0.5.3.

docker.io/mattalberts/argo-tunnel:0.5.3

I've published 0.5.3 and updated the helm charts

gcr.io/cloudflare-registry/argo-tunnel:0.5.3

@mattalberts I execed helm repo update` but i still only see 0.5.2 chart
tc/argo-ingress                       	0.5.2        	           	Installs the cloudflare argo tunnel ingress con...

@jalateras which helm chart are you using?  The  charts at http://trusted-charts.stackpoint.io are no longer being maintained.  I've updated the chart maintained in this repo.

Hi @mattalberts - new release is working great (so far). Four tunnels per Argo pod which is much better. Had a few tunnel disconnects this evening but everything appears to have recovered nicely.
One very minor thing, I spotted a typo when an attempt is made to add an origin to an existing pool. I've done a quick grep through this code and for cloudflared but couldn't find it, so it's possibly coming from the API somewhere or other - which I can't fix with a pull request :)
time="2018-10-02T18:27:11Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-10-02T18:27:11Z" level=error msg="Register tunnel error from server side" connectionID=1 error="Server error: error adding origin XXXX to existin pool XXXX: Service temporarily unavailable."

Yup! I found it!  Its coming from the upstream API.  I'll try to get a spell checker wired into that project :)

@mattalberts any chance we can get this chart to the helm/stable repo?

@tonyxiao I think I'm going to setup a publishing point hosted on github for helm charts, something like a "cloudflare/helm-charts".  I'm working on getting that setup

@mattalberts that's awesome. Let us know when it's available
@tonyxiao what been your experience with the latest changes?

Hi @mattalberts we're still seeing reconnect/no retry issues - and a customer reported getting Cloudflare 1000 status pages yesterday which is a new one on us. The extra tunnels are helping, but we've got 3/8 currently down.
ime="2018-10-03T22:55:11Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin XXXX to existin pool XXXX: Service temporarily unavailable."
time="2018-10-03T22:55:14Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-10-03T22:55:14Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin XXXX to existin pool XXXX: Service temporarily unavailable."
time="2018-10-03T22:55:20Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-10-03T22:55:20Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin XXXX to existin pool XXXX: Service temporarily unavailable."
time="2018-10-04T01:53:07Z" level=warning msg="frame read error" dir=read error="read tcp <IP_ADDRESS>:46830-><IP_ADDRESS>:7844: read: connection reset by peer" subsystem=mux
time="2018-10-04T01:53:07Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-10-04T01:53:07Z" level=error msg="Serve tunnel error" connectionID=0 error="read tcp <IP_ADDRESS>:46830-><IP_ADDRESS>:7844: read: connection reset by peer"
time="2018-10-04T01:53:09Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-10-04T01:53:09Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin XXXX to existin pool XXXX: Service temporarily unavailable."
time="2018-10-04T01:53:12Z" level=info msg="Stopping mux metrics updater" dir=metrics subsystem=mux
time="2018-10-04T01:53:12Z" level=error msg="Register tunnel error from server side" connectionID=0 error="Server error: error adding origin XXXX to existin pool XXXX: Service temporarily unavailable."
time="2018-10-04T04:22:45Z" level=error msg="HTTP request error" error=EOF

I finally have a helm repository replacement setup!

https://cloudflare.github.io/helm-charts/

Now I can get back to investigating possible issues :)

Nice work @mattalberts. Looking to revisiting once it stabalizes

@alexkinch Let me copy and paste some context

"The extra tunnels are helping, but we've got 3/8 currently down"
error="Server error: error adding origin XXXX to existin pool XXXX: Service temporarily unavailable."

I've found this error message deep within the tunnel service code. I'm trying to understand the conditions around the error.  Can you provide the files

ingress definition?
controller deployment definition?

I'm curious about the settings for replica, lb-pool, and ha-connections (private gist shared with me?)

Hi @mattalberts - the 3/8 down issue was resolved by restarting the controllers, but as it happens we've got a tunnel down at the moment which has been in that state for the past three hours, so I've got some fresh logs I can send you. Will add those into a gist with the other things you asked for.

alright!  0.6.0 has ben released with an updated cloudflared library.  hopefully, the changes to the supporting library improve the disconnects.

@mattalberts just raised a PR against it

@mattalberts I have managed to deploy the 0.6.0 chart successfully but i seem to have a problem creating the tunnel. I have read the documentation but maybe i'm still doing something wrong.
So i have deploy argo ingress controller as follows
    - helm upgrade --install --wait --namespace snab
      --set controller.logLevel=6
      --set loadBalancing.enabled=true
      argo-tunnel cloudflare/argo-tunnel

I have set up my ingress like this
ingress:
  enabled: true
  path: "/i/*"
  hosts:
    - snab.example.com
  annotations:
    kubernetes.io/ingress.class: argo-tunnel
    argo.cloudflare.com/lb-pool: snab.example.com

and i have a secret deployed
Name:         snab.example.com
Namespace:    snab
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
cert.pem:  1878 bytes

When i go try and hit the url i get
503 Service Unavailable
The origin has been unregistered from Argo Tunnel

which is also reflected in the cloudflare portal. I cannot see any errors in the argo logs but i also cannot see any logs concerning the establishment of a tunnel.
Do i need to add  a tls section to my ingress resource or am i missing something else?

@mattalberts thanks. All deployed and working

How’s the connected/disconnected status look?
Sent from my iPhone

On Nov 24, 2018, at 10:11 PM, Jim Alateras<EMAIL_ADDRESS>wrote:
@mattalberts thanks. All deployed and working
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

It looks good. No false alerts so far. Is there anything i should be looking at specifically?

Hello, with version 0.6.1 we are getting loads of the following errors and not sure they are linked but look similar:
`Stopping mux metrics updater" dir=metrics subsystem=mux'
Register tunnel error from server side" connectionID=1 error="Server error: error adding origin 1-bdt8z9zr659br5wjw62gdngzhbszwzps to existin pool ff61b7a6704ada078465763e023e4dae: Service temporarily unavailable.
Tunnel disconnected due to error" error="Server error: error adding origin 3-bdt8z9zr659br5wjw62gdngzhbszwzps to existin pool ff61b7a6704ada078465763e023e4dae: Service temporarily unavailable.
CF support say this is a known issue, but I wanted to check as we currently cant even create new tunnels.

@holidaycottages  I'm checking with the tunnel team to verify the state of the tunnel service.  I'll update you as soon as I have further information.

Pretty sure we are well past the issue at this point.  I'm closing the ticket.  If similar behavior arrises, we can reopen.


Dotnet core website hosting error on Ubuntu server

Im not able to host dotnet website on my ubuntu server.
Im getting issue when i open it on localhost

Could you please provide details on your project? Without this, there's not much we can offer.

Closing due to inactivity. If you're still having trouble, please re-open with additional details.


Large Planning Times

Thanks for sharing this repository with the open-source community!
I just ran the simulated example. I started roslaunch mbplanner mbplanner_m100_sim.launch  and then clicked on Start Planner in the UI.
Things looked awesome other than it would take quite a bit of time to compute the trajectories, as shows below. Are there any compiling/execution optimizations that I am missing, or is this expected? Are there GPU optimizations (I am running on a machine without an external GPU, if that matters)?
         Build tree     : 34.130 (s)
         Compute gain   : 35.360 (s)
         Evaluate graph : 6.000 (s)
         Total          : 75.490 (s)

Hi @marcelino-pensa ,
Did you compile with Release option: -DMAKE_BUILD_TYPE=Release

Sorry: -DCMAKE_BUILD_TYPE=Release

I thought I did, but I recompiled/deleted/cloned so many times because of this issue, that I forgot to make it a release the last time I compiled.
Just made it into a release, and problem solved:
         Build tree     : 0.240 (s)
         Compute gain   : 0.300 (s)
         Evaluate graph : 0.030 (s)
         Total          : 0.570 (s)

It's amazing that it runs so much faster just by making the Release optimization! Any ideas why is this the case?


Add Fuse EVM blockchain

In the same way than #1 I propose to add support for Fuse EVM blockchain by creating the needed PR.

Dear Betrand,
please go ahead 🙏