RFC: Code sharing for ET export, C++ runner and tokenizer, with ExecuTorch

🚀 The feature, motivation and pitch
Currently torchchat is having its own implementation for these features:

Utils to optimize, quantize and export eager model to ExecuTorch.
A LLM runner for AOTI and ExecuTorch.
Tokenizers (sentencepiece and tiktoken) used by both AOTI runner and ET runner.

The problem for this design is that it is not bringing in new features checked-in into the export flow in ExecuTorch. What's worse is that the demo apps hosted in torchchat is expecting a .pte file from the export flow in ExecuTorch instead of the one from torchchat and that will easily break if changes happen to one or the other.
Similar story happens to the C++ implementations of the tokenizers. If we look at tokenizers in ExecuTorch it is a lot similar to what tokenizers in torchchat and the code should be unified to avoid duplication.
Alternatives
An alternative is do nothing. If we keep the status quo, DevX will deteriorate due to constant changes from ExecuTorch that we need to incorporate into torchchat.
Additional context
No response
RFC (Optional)
Proposal
On a high level we want to:

Reuse export flow in ExecuTorch's extension/llm directory.
Setup a new repo for tokenizers/samplers under pytorch-labs.
Let runner code depend on the new tokenizer repo.

Details

Export flow:
Currently torchchat uses export.py to export a model to ET's .pte file.
Proposal: fully migrate to ET’s extension/llm.
New dependency: ET nightly build in pip.
Runner:
Torchchat C++ runner needs to work for both AOTI and ET so it’s quite complicated.
Proposal 1 (preferred):

Setup a separate repo for runner and tokenizer code. Both ET and torchchat depend on it.

Add a public repo under pytorch-labs organization, say pytorch-labs/tokenizers
Split existing run.cpp into et_run.cpp and aoti_run.cpp

et_run.cpp depends on ExecuTorch as well as pytorch-labs/tokenizers,
aoti_run.cpp only depends on pytorch-labs/tokenizers.

Pros: no code duplication, clear dependencies.
Cons: maintenance cost for a new repo.

Proposal 2 (short term?):

Use runner building blocks and tokenizer from ET. Refactor existing run.cpp to reuse those components. Add ET as a git submodule.

Pros: no code duplication.
Cons: if a user only wants to build an AOTI runner, it’s weird to pull in tokenizer code from ET.

Model definition:
Torchchat depends on torchtune for model definition. All the source transformations will come from the ET extension/llm library. Modules that are modified to be torch.exportable will be hosted in ET extension/llm, torchchat should use those as well.
Example: torchtune’s MultiHeadAttention has an input dependent condition that needs to be rewritten into torch.cond so that it’s exportable. This lives in extension/llm/modules and should be used by torchchat. [Pending discussion] If torchtune is open to host these exportable modules, torchchat should depend on torchtune to get them.
Demo app:
For both Android and iOS, we want to build runner and tokenizer as libraries, package them into artifacts and distribute them to torchchat.
We are already doing this for Android demo app
iOS demo app code should live in torchchat as well and both demo apps should be removed from ET in the future.

I like this direction to modularize the components and sharing them for different use-cases beyond those backed by ET.
It seems like what we could think on further is how to actually modularize it even more, ie. not just reuse the Tokenizer and Sampler, but also most of the runner logic, if possible.
Runner now does some things that are still common for ET or AOTI while preparing the inputs and processing the outputs, eg. the run loop, applying chat pattern with special tokens, etc. So in theory we could have a common Runner pipeline and inject specific minimal components to do the actual forward() call implemented differently for ET or AOTI.
So overall we could have a collection of abstract interfaces for Tokenizer, Sampler, Processor (ie. image processor), Runner (to generate a single next token), Pipeline (to utilize the Runner for completion or multi-turn generation), etc. and also provide some concrete implementations for them, eg. TikTokenTokenizer, ArgMaxSampler, ImageProcessor, LLaMA3Runner, LLaMAChatPipeline, etc. That way we provide some working solution out-the-box, and also allow clients implement their own components by inheriting the interfaces and injecting them instead, eg. a custom SentencePieceTokenizer injected into a custom LLaMA2Runner injected into LLaMAChatPipeline instead of the default LLaMA3Runner.
Such interfaces and default implementations can live in pytorch-labs, if that's a good place for everyone to depend on.

@shoumikhin @gabe-l-hart thanks for chiming in. I spawn up https://github.com/pytorch-labs/tokenizers as our first step to enforcing code sharing on tokenizers. I'm still waiting for legal approval to open this repo up but would love to collaborate.

In the short term I think this is a good direction, but long-term I do not like how ExecuTorch does not just "work" well with an LLM exported from torch.export.
ExecuTorch having its own export_llama_lib script and special source transformations is not a good user experience in my opinion.  My one worry about the proposal here is that it further entrenches this flow.

In the short term I think this is a good direction, but long-term I do not like how ExecuTorch does not just "work" well with an LLM exported from torch.export.
ExecuTorch having its own export_llama_lib script and special source transformations is not a good user experience in my opinion. My one worry about the proposal here is that it further entrenches this flow.

I somewhat agreed, source transformation is "optional" meaning ET will also work without source transformation, just slower and consumes more memory. Having source transformation available gives ET user an easy way to optimize their LLM model.
It is a separate question on whether we should internalize these optimizations into the framework, e.g., find a smarter way to reduce unnecessary copies.

In the short term I think this is a good direction, but long-term I do not like how ExecuTorch does not just "work" well with an LLM exported from torch.export.
ExecuTorch having its own export_llama_lib script and special source transformations is not a good user experience in my opinion. My one worry about the proposal here is that it further entrenches this flow.

I somewhat agree, I want to point out source transformation is "optional" meaning ET will also work without source transformation, just slower and consumes more memory. Having source transformation available gives ET user an easy way to optimize their LLM model.
It is a separate question on whether we should internalize these optimizations into the framework, e.g., find a smarter way to reduce unnecessary copies.

Actually I think it is fine to apply optimizing transformation be that module swap or graph rewrites. to_backend within ET pipeline is one such optimization and that is explicit opt-in. Scripts that wrap all the (export, to_edge, to_backend etc.) provide convenience wrappers. So in general it is better to do a) building composable components and b) have wrappers or boxing logic that puts together these components, thus allowing custom wrappers. It is better compared to monolithic design by say, having a giant optimized operator lib that works like a charm when it does, but is extremely hard to extend.


python3Packages.aiohttp-socks: 0.6.0 -> 0.7.1

Motivation for this change
Update to latest upstream release 0.7.1
Change log: https://github.com/romis2012/aiohttp-socks/releases/tag/v0.7.1
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This requires the last python-unstable run.

Is in the new python-unstable run (https://github.com/NixOS/nixpkgs/pull/149301/commits/0029193ccee48425e245d6ec030b98354fe81d71).

Why is this closed? The commit you mentioned does not go to master. Since we already have python-socks 2.0, which breaks requirement of aiohttp-socks 0.6.0 and cause all downstream packages failed to build, including electrum.
Should I reopen it?

Created https://github.com/NixOS/nixpkgs/pull/152512.


Add explicit include for musl

On Alpine Linux, <sys/types.h> is not included by default, meaning compilation will fail as e.g. ssize_t is undefined. This just makes that include explicit.
For reference see lsquic-alpine.

Thank you!


Problem parsing json returned from Thanos

Hey!
I am currently facing a problem using Grafana which cannot parse json returned from Thanos.
I noticed a weird behavior when calling API, I get a warnings field set to null:
curl http://thanos-query:9090/api/v1/query?query=node_cpu | jq
{
[...]
    "warnings": null
  }
}

According to https://github.com/improbable-eng/thanos/blob/3278b4687e25683b082f9815e5ff0b2eb5169f91/pkg/query/api/v1.go#L84
this field should not be there thanks to omitempty but the field appears anyways.
This prevents the json to be parsed correctly. Do you have any insight on this ?

After further investigation, it comes from this struct :
https://github.com/improbable-eng/thanos/blob/3278b4687e25683b082f9815e5ff0b2eb5169f91/pkg/query/api/v1.go#L168
We can see that the Warnings field does not have the omitempty option set.
Setting it fixes this issue.
I can make a PR for that if you want me to. I am just wondering if there is a reason that this field is not omitempty already...

Hey, thanks for reporting the issue.
What exactly Grafana error you have seen?
yea omitempty should work, but actually, you can have "some" warnings on query filled so it will crash grafana as well (: So if Grafana does not accept additional fields we need some better solution anyway (for example put warnings only for certain user agents)

We need omitempty for sure, PR would be awesome.
But wonder on behaviour of Grafana if this is actually filled (:

I guess Grafana does not like the bare null appearing in the field. If warnings is set, it would contain strings and grafana should not complain about that. I hope.
I am preparing the PR

Hope based solutions are the best! (:
Thanks!

Fix merged. The only question is how grafana handles filled warnings.


add sqe (arma3 editor compositions) to list of file types

Arma3 editor saves compositions as sqe files - which are basically just sqm snippets.

Simple merge :+1:

Ah neat, I didn't even know of that file type!


feat: load external abi data config

This PR adds functionality to support loading external config files. It includes:
Making changes to existing code to allow the program to look for, and read external config files.
Code refactoring to make the process cleaner and easier to maintain.
Adding new utility functions to handle working with external config files.
Adding tests to ensure that the added functions are working correctly.

@h2plalbert thanks for the PR.
I have a couple of questions.
For what I can see, since you needed to deploy new contracts, the db-service.ts helper allows the SDK to work with new addresses for each contract on ICON and BSC chains not just the ones predefined here:
https://github.com/icon-project/icon-bridge/blob/main/docs/mainnet_deployment.json
https://github.com/icon-project/icon-bridge/blob/main/docs/testnet_deployment.json
The functionality that you are adding is very good, specially for developers that want to use the SDK in custom environment like you presented.
In order to approve the PR a couple changes are going to be needed because its currently breaking the code.
to summarize they SDK is intended to be used in the frontend and the backend with as little friction as possible, to achieve this I dont expose libraries intended for the backend (nodejs exclusive libraries) to be exported into the final modules of the SDK.
the fs module from nodejs is intended for the backend and your PR is using it here
https://github.com/Espanicon/icon-bridge-sdk-js/blob/ca4edb2bcdea367a69d5d6d3455713c64a26ef90/src/utils/utils.ts#L13
To avoid having the fs module leaking into the exports of the SDK I originally implemented a workaround with this script
https://github.com/Espanicon/icon-bridge-sdk-js/blob/ca4edb2bcdea367a69d5d6d3455713c64a26ef90/local-lib/buildABIData.ts
this script basically is a program that is separated from the SDK and builds the .data/abiData.js file once as a javascript file instead of a JSON file, and then the rest of the SDK can import that module normally without the use of fs
if you have the availability to implement the solution ill be happy to guide you and work with you so that the PR can be approved.


bump magicgui dep (fix _normalize_slot AttributeError and minreqs test)

Description
magicgui 0.3.6 fixes the issues with _normalize_slot AttributeError.  (side note: 0.3.6 will be the last release before 0.4.0, which will remove the events deprecation strategy that caused this 2-repo dance in the first place).
However, our min-reqs tests are still failing because we don't also pin a min psygnal version (so we get old magicgui, but new psygnal).  Rather than bringing psygnal into our min-reqs, I'm just bumping the min required magicgui version

Fast and efficient as always! LGTM, thanks @tlambert03  :)

btw, I've also added CI that tests magicgui from the psygnal repo and tests napari from the magicgui repo ... so this shouldn't happen again


Manually update migration file to have not applicable instead

https://app.zenhub.com/workspaces/epictrack-63891ea941d309001fa292cf/issues/gh/bcgov/epic.track/1331
Details:

Manually fix migration

Failed test not related to the changes, it is due to using a Put request for a Patch endpoint


Evaluate host events

Currently, only service events are evaluated. It would be good to also include host events (host down, host unreachable,...).

Fixed in commit c08dff69d9b55b6cebde10259d447fb01017d9c6


Seamless login support

Implements the LoginUrl type and login_url property in inline buttons
for seamless login feature by Telegram.

Uh nice, thanks for this! I've merged it and will release a new version as soon as I'm back to my pc :)


Scale zero works bad when multiplying

I tried to multiply a Money instance with a double value but this didn't work so well.
Currencies().register(Currency.create('SEK', 0, symbol: 'kr', pattern: '0 S'));
final Money hundraSEK = Money.fromInt(100, code: 'SEK');
// expect((hundraSEK * 0.5).toString(), '50 kr');  // Does not work since we have a zero scale. 0.5 get converted into Fixed 1.

The question is whether this is a bug or are you using the library incorrectly.
The question is what scale do we use?
With a double there is no easy to determine the expected scale.
So the correct solution feels like you should convert the double to a fixed and then do then the maths
Thoughts?

?The question is what scale do we use?
I use scale 0 as can seen in the call to Currency.create()
But that multiplying 100 kr with 0.5 gives 0 kr (or 100 kr I think it gives now actually) I think is a bug.
I think the * operator could be coded so that it could handle fractions better. Even when the scale is 0
Anyway I have coded around this issue ... so I am fine.

I'm going to close this one out as I don't think it's a bug.
The package is designed to do fixed scale maths and other is no way (that I'm aware of) of determining the scale of the double.
For the moment I'm going to handle this as a documentation issue and make a note of the issue and the solution which is to first convert the double to a fixed precision and then do the multiplication.


The moment dependency defined in package-lock.json has a known moderate severity security vulnerability

The moment dependency defined in package-lock.json has a known moderate severity security vulnerability in version range < 2.19.3 and should be updated.

Same here

Can you show a bigger screenshot? We are on version 2.21.0 now. There was a vulnerability in the past, but it has since been fixed.
Also, I don't see a package-lock.json anywhere inthe code.

Here a package-lock.json: https://github.com/visualcookie/auth-api/blob/master/package-lock.json
And a detailed screenshot:

Cool. This is for consumer's package-lock.json.
GitHub is trying to be helpful here. I would heed its advice and update your version of moment.
I think npm update moment will do the trick.
Let me know if folks have issues.


FMI & IPP broken at 12.02.2018

hunger.tum.sexy shows An error occured while fetching the FMI Bistro menu. I guess that's an issue within this lib then?

Apparently, there was some problem parsing the menus for both locations in srehwald/eat-api.

👍
For the reference: https://github.com/srehwald/eat-api/issues/19


Recommend users to not use the country and territory autocomplete

Changes

Adds a note to the top of the readme advising users to not use this repo and the reasons why
Remove the 'Keep the data up to date' section as it's no longer true

Notes
The second change is possibly the slgihtly more controversial one. It means teams now have no assurance that the data is kept up to date (which unfortunately is closer to the truth) however this section doesn't really hold any value besides the untrue statements. The 2 platforms suggested for keeping up to date are both dead projects. I'm however less confident in this change compared to the first change. I'm interested in folk's opinions or if we should leave it or just morph the content a bit.

Should we add advice on what to use instead?
For example, suggesting to use Accessible Autocomplete with FCDO's geographical names index as a data source?

@querkmachine I did think about adding a line like "the team will look at alternatives in the future". Maybe I can put that example in so folks have something but try to qualify it that this isn't a complete alternative. Probably the team need to discuss where to point people and agree, although I can't think of anything better than what you've suggested.

For example, suggesting to use Accessible Autocomplete with FCDO's geographical names index as a data source?

Pointing people to the FCDO list with the caveat that people need to double check that it's suitable for their own project sounds nice to do. It's also something we can easily amend if people come up with better sources.

I've added a note on the FCDO datasource. I'm not super confident about the content so I'd appreciate a review.

I've made a new commit that includes an edit of the latest message, and restructures the headings to make it fit better.


AC Int sample readme update

Existing Sample Changes
Description
Restructured to match the new template, with differences for FPGA templates. Updated name in readme to match name in sample.json. Made minor changes to some formatting. Updated some branding. Added category to sample readme. Corrected some grammar and spelling issues.
Fixes Issue#
External Dependencies
N/A
Type of change
Please delete options that are not relevant. Add a 'X' to the one that is applicable.

[x] Documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Command Line
[x] VSCode

Adding @jimmytwei for notices.


Floating point precision for math operations

I have floating point issues on simple operations like 7.12*100 or  with the sum() operator.

SELECT water_level * 100 FROM h2o_feet
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>

or
SELECT sum(water_level) FROM h2o_feet WHERE time < now() GROUP BY time(5s)

h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=7.12<PHONE_NUMBER>
h2o_feet,location=coyote_creek water_level=9.94<PHONE_NUMBER>

Is there a way to set the precision of floating point numbers for math operations?
InfluxDB: V 0.10.2

@dschniepp can you explain to me what the issue is? I need to know the following:

What data are you using?
What query are you using?
What is the expected behavior?
What is the actual behavior?

Thanks!

@jsternberg updated the initial question.

@joelegasse @kostasb we had a conversation about this recently. Should we be sending back floats with some kind of precision rather than sending back the raw float value? It seems to me that there should be a default precision, but that it should be customizable through the query engine.
Thoughts @pauldix?

Related with https://github.com/influxdata/influxdb/issues/5938

I should first note that floating point numbers aren't fixed-precision decimals, and we shouldn't treat them that way. Luckily @dschniepp is using a similar dataset as #5938, which I found out that less than 1% of the values could be represented exactly as floating point values. You can see in this example that none of the values in this example could be represented exactly as floating point values: http://play.golang.org/p/Z-xoVtENO9 Also, your actual/expected output doesn't match the numbers you provided.
I do not think we should be rounding any values coming out of the system. Our everyday intuition says, "that number is wrong", but the result we get out is more accurate when considering the inputs the aggregate function was given. Consumers of the data (clients) might want to round to a few decimal places when printing values, but I don't think that should be built-in to floating point values returned from the system.
You can read my posts in #5938, but I'll summarize my feelings here: If you need precision from influxdb, use integer values for thousandths or millionths of a unit (or whatever the smallest unit is), rather than floating point values.

@joelegasse I agree that if you need precision you should be using ints. However, for this case I think that it would be nice to give the user an option for rounding to some number of digits after the decimal place. Something that would happen at serialization time.

Looking back at this, I don't think we can perform this rounding at serialization time. I think rounding has to be done at the client. Floating point isn't particularly kind to certain numbers that would be rounded and we would likely run into the same issue where the client has to do its own rounding if we sent the digits over the wire as floats rather than strings.
Maybe we should convert this issue to adding rounding to the client?


Fix typo in docs sidebar

Thanks for making Ordinals. It really caught my attention. Noticed a tiny typo in the sidebar.

You bet, glad you like it ^_^
Thanks for the PR!


Support for Angular 13

Describe the desired behavior
Component library should be built using Angular 13 and work seamlessly in Angular 13 projects.
Describe the current behavior
Using Angular 12. Trying to use the library in a new Angular 13 project causes some issues with imports.
Is this request related to a current issue?
This is reported by the PredictPulse team.
Additional Context

@emclaug2 is looking into this with upgrade work.

#396 Addresses this.

Fixed in #396


Barcode is not available on the report lay-out

I want to add a barcode to a report. This barcode will only be shown when I send the report to Word. When I try to send the report to pdf (or preview), the barcode is not available.
I created a new report, based on the example of Microsoft (https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-report-add-barcodes?tabs=1d). The report is added, see below.
For this report I created a rdlc lay-out and a Word lay-out.
The created RDLC lay-out:

If I run the report and select the preview of the report, the barcode wasn’t printed:

I’ve got the same result when I try to send the result of this report to pdf.
If I run the report and select send the to Word, the barcode was correct printed:

I’ve got the same result when I use the Word lay-out.
Report code:
Rep.ItemBarcodeReport1D.zip
Report lay-outs:
ItemBarcodes.zip

Thank you for reaching out. Your request could be reporting a product bug not related to the AL application extensibility. Please reach out to the relevant support channels:

For collaboration in preview or beta versions of AL Language in Visual Studio Code (aka ModernDev), use GitHub (https://github.com/microsoft/al).
For Microsoft partners, for versions already in general availability and supported, file requests through Microsoft Partnersource (https://mbs.microsoft.com/partnersource/).
For ISVs/VARs who have discovered a bug in a in preview or beta version, use MS Collaborate (https://docs.microsoft.com/en-us/collaborate/).
For Business Central customers who have issues or found bugs, please contact your Microsoft partner.
For the new features please submit a product suggestion on https://aka.ms/bcideas


Apparent resistivity for homogeneous halfspace

I calculated the electric potential and the apparent resistivity for a homogeneous halfspace of 500 ohm*m using the equation and model setup shown in the following slide (taken from the DISC course). But, my results do not match what is shown on the slide.

Here is how I calculated the potential at a location 10 meters away from the injection point which is located at 0 m, according to the above picture. V = rho * I/(2 * pi * r) = 500 * 1/(2 * pi * 10) = 7.9577 Volts (Here I assume the inject current is 1 A). But in the above picture, 6.9 Volts is shown.
I also calculated the apparent resistivity: rho = 2 * pi * r * V / I = 2 * pi * 10 * 6.9/1 = 433.5398 Ohm * m. Shouldn't it be 500 ohm * m (because we are talking about homogeneous halfspace)?
Would you please double check what is wrong here? I would like my students to do similar calculations tomorrow in class. Thanks!

This is a

Hi @jiajiasun, this is a subtle point. I believe we created that with an earlier version of the 2.5D DC layered earth app (DC_Layer_Cylinder_2_5D.ipynb)

In this case, it looks like we are not necessarily satisfying the boundary conditions (the mesh was trimmed to speed up the computation), so a correction factor is used under the hood so that the halfspace apparent resistivity is correct (cc @thast).
With the image @thast showed above, it looks like we are doing a better job of mesh design in the plate app, so you might want to check out the 2.5D plate app if you would like the students to calculate it by hand.

Seems also the panels are no longer aligning in some DC apps :/ I created an issue
https://github.com/geoscixyz/em-apps/issues/54

Hi, @thast @lheagy Thank you very much for your response and explanation! It now makes more sense! Following your explanation, I ran the two apps: DC_Plate2_5D and DC_Layer_Cylinder_2_5D, and was able to reproduce what @thast showed (i.e., 7.6e+00 V). Thanks again!
I also ran another app in DC_Cylinder_2D.ipynb with the same set-up, i.e., pole-pole survey with electrodes located at -0.25 and 10.25 m for a homogeneous halfspace of 500 ohm*m. And I got something interesting.

The potential at the M electrode is 360 Volts.
Is that because this is a 2D simulation (as compared to 2.5D or 3D)? How to make sense of 360 V?
Once again, thank you very much! All the materials and apps you have spent so much time on are super helpful. My students are benefiting from all your efforts. I posted the slides that I have used so far in class in my Azure library (https://notebooks.azure.com/jsunatuh/libraries/uhelectromagnetics). I will keep posting more slides and all the lab exericses as I move on.

Hi, @thast Thanks a lot! That makes total sense. That was what I suspected might be happening. Thanks for your informative explanation!

@jiajiasun I am going to close this issue. Please feel free to re-open if you have further related questions


Towards user-defined workload cluster names everywhere

We want workload cluster names to be chosen by the creator, not generated by the Giant Swarm backend. We also want to align our treatment of cluster names with other vendors we aim to import clusters from, e. g. EKS.
This includes the following changes:

Allow for up to 63 character long names in UIs
Treat the cluster name as the main identifier in UIs (and phase out the tuple of cluster name and description)
Prompt users to specify a cluster name on creation, allowing to fall back to a generated name

Mockup for the cluster list in the web UI

We will no longer show the cluster name with an individual background color. We should still provide a copy-paste helper to copy the cluster name wherever it appears.

@marians please see this issue also. there was a problem with an app that already had a too long name. apparently 53 is the limit for some ressources
https://github.com/giantswarm/giantswarm/issues/28911

Helm is limited to 53 characters. Kubernetes is limited to 63 characters. Waiting for areas-kaas to make a decision to make a max length suggestion.

Related: https://github.com/giantswarm/roadmap/issues/2983

@marians are there any news on this one? It has been in Up next for the last 3 months without being taken care of?


Add an example of submitting hybrid job

What did you find confusing? Please describe.
A clear and concise description of what you found confusing. Ex. I tried to [...] but I didn't understand how to [...]
I am looking for how to submit a hybrid job through Braket.jl without the need of Python, but I couldn't find any example in the "example" folder. In the "test" folder, there seems to contain some examples but I couldn't follow them.
Describe how documentation can be improved
A clear and concise description of where documentation was lacking and how it can be improved.
Add an example in the "example" folder, which explains the essential elements of hybrid job, such as
a) how to specify the algorithm script and entry point,
b) how to configure instances,
c) how to specify devices
d) how to set hyperparameters
e) how to set images if needed
The example could simply replicate one of the examples in the Braket example folder.
Additional context
Add any other context or screenshots about the documentation request here.

Thank you for this issue! We will look into this.


Support MSSQL

Describe the solution you'd like
I've just started to use sqls and it is very nice. I would love to be able to use it for all the DBMS I encounter. Currently the main DBMS I am missing support for is MSSQL. Please add support for this.
Describe alternatives you've considered
Not using sqls.
Additional context
There appears to be a golang MSSQL driver that is actively developed at: https://github.com/denisenkom/go-mssqldb
It supports the database/sql package.
For testing, you can run MSSQL via docker FROM mcr.microsoft.com/mssql/server
Do you have developer-level docs on what is involved in adding support for a new DBMS?

Nice to see this added :smile:
Just tried it out with Neovim 0.6. Code completion works great!
I also tried some of the code actions (i.e. Execute Query, Show Databases) but I get the error method workspace/execute
Command is not supported by any of the servers registered for the current buffer.
Does that sound like a configuration error on my side, or it's not supported for MSSQL yet?

Nevermind me, looks like I just forgot to set
client.resolved_capabilities.execute_command = true in my neovim LSP configuration. Ref sqls.nvim plugin docs


openapi: Note that a user's avatar_url may be missing.

Like it already says in the detail about
user_avatar_url_field_optional, but on the field itself [1].
[1] https://github.com/zulip/zulip-mobile/pull/4230#discussion_r493109645

Awesome, merged, thanks for the fixes @chrisbobbe!


calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect: no such file or directory

I was building a three nodes kubernetes using Calico. But I run into some problem with Calico。
I install Calico-v3.6 according to the instructions in the official website of Calico. Before I join other nodes to the cluster, the Calico pod is running well. But when I join other nodes into the cluster, the Calico pod is not ready but still running. I use "kubectl get nodes" to acquire the state of all nodes and all the nodes is ready. But the Calico pod is unnormal. The pod between nodes can not communicate to each other.
I downloaded the yaml file and the required image of Calico-v3.6, and install Calico using the following command:
kubecctl apply -f calico.yaml
The version of the kubernetes is v 1.15.2
Thanks in advance!
Expected Behavior
All the kube-system pod is ready and running. And all the pods in the cluster can communicate to each other.
Current Behavior
The outcome of "kubectl get pod -n kube-system" are shown as follows:

I use "kubectl describe pod calico-node-wh7dr -n kube-system", I got the following message:

Possible Solution

Steps to Reproduce (for bugs)

All the required condition of k8s is done well.

execute "$ kubeadm reset" on all the cluster node.
execute on master node: "$ kubeadm init   --kubernetes-version=v1.15.2   --pod-network-cidr=<IP_ADDRESS>/16   --apiserver-advertise-address=<IP_ADDRESS> --token-ttl 0"
configure kubectl as a regular user on master node.
$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
Install pod network Calico on master nodes.
$ kubectl apply -f calico.yaml
Join into the cluster, execute on other nodes.
$ kubeadm join <IP_ADDRESS>:6443 --token eh6o8d.0j0xwd0ddty8eakr
--discovery-token-ca-cert-hash sha256:659cbac9c7e459cbbf3f42fc4d884a4dc2d5ad1e668750406c04523a7803bcb5

Context

Before I join other nodes into the cluster, all the kube-system pods are running well. When I execute join command on other nodes, some calico nodes is not ready but still running, as is shown on above image. The pods on different nodes can not communicate to each other.
Your Environment

Calico version: v3.6.5
k8s version: v1.15.2
Operating System and version: Ubuntu16.04

The overall error logs of "kubectl describe pod calico-node-wh7dr -n kube-system" command are
shown as follows:
[wangz@master calico-v3.6]$ kubectl describe pod calico-node-wh7dr -n kube-system
Name:           calico-node-wh7dr
Namespace:      kube-system
Priority:       0
Node:           user08/<IP_ADDRESS>
Start Time:     Wed, 04 Sep 2019 09:02:03 +0800
Labels:         controller-revision-hash=66f967c555
k8s-app=calico-node
pod-template-generation=1
Annotations:    scheduler.alpha.kubernetes.io/critical-pod:
Status:         Running
IP:             <IP_ADDRESS>
Controlled By:  DaemonSet/calico-node
Init Containers:
upgrade-ipam:
Container ID:  docker://27bac175a7cf7e0771e88585cba6a40c8478af58341d759d085fe9686f257aa8
Image:         calico/cni:v3.6.5
Image ID:      docker://sha256:0e5467f673396014301fb8a17cfc3aed276ff71ccc595a69950cbcd1e13e3c1f
Port:
Host Port:
Command:
/opt/cni/bin/calico-ipam
-upgrade
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Wed, 04 Sep 2019 09:02:05 +0800
Finished:     Wed, 04 Sep 2019 09:02:05 +0800
Ready:          True
Restart Count:  0
Environment:
KUBERNETES_NODE_NAME:        (v1:spec.nodeName)
CALICO_NETWORKING_BACKEND:  <set to the key 'calico_backend' of config map 'calico-config'>  Optional: false
Mounts:
/host/opt/cni/bin from cni-bin-dir (rw)
/var/lib/cni/networks from host-local-net-dir (rw)
/var/run/secrets/kubernetes.io/serviceaccount from calico-node-token-nkf26 (ro)
install-cni:
Container ID:  docker://b7359636fe9ff7945dccb21214f0b26330504dbe9cbf1b80bdf781f7ea4628cd
Image:         calico/cni:v3.6.5
Image ID:      docker://sha256:0e5467f673396014301fb8a17cfc3aed276ff71ccc595a69950cbcd1e13e3c1f
Port:
Host Port:
Command:
/install-cni.sh
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Wed, 04 Sep 2019 09:02:06 +0800
Finished:     Wed, 04 Sep 2019 09:02:06 +0800
Ready:          True
Restart Count:  0
Environment:
CNI_CONF_NAME:         10-calico.conflist
CNI_NETWORK_CONFIG:    <set to the key 'cni_network_config' of config map 'calico-config'>  Optional: false
KUBERNETES_NODE_NAME:   (v1:spec.nodeName)
CNI_MTU:               <set to the key 'veth_mtu' of config map 'calico-config'>  Optional: false
SLEEP:                 false
Mounts:
/host/etc/cni/net.d from cni-net-dir (rw)
/host/opt/cni/bin from cni-bin-dir (rw)
/var/run/secrets/kubernetes.io/serviceaccount from calico-node-token-nkf26 (ro)
Containers:
calico-node:
Container ID:   docker://6d4a48784654892a3a7b2672db6d93325ef52b8351b1adc00e1e44dd63c44513
Image:          calico/node:v3.6.5
Image ID:       docker://sha256:9b23e1a2ef6d2f5f08903fbc0a18fae61bdb601f39bf8027fe3f94f04c28f88c
Port:
Host Port:
State:          Running
Started:      Wed, 04 Sep 2019 09:02:07 +0800
Ready:          False
Restart Count:  0
Requests:
cpu:      250m
Liveness:   http-get http://localhost:9099/liveness delay=10s timeout=1s period=10s #success=1 #failure=6
Readiness:  exec [/bin/calico-node -bird-ready -felix-ready] delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
DATASTORE_TYPE:                     kubernetes
WAIT_FOR_DATASTORE:                 true
NODENAME:                            (v1:spec.nodeName)
CALICO_NETWORKING_BACKEND:          <set to the key 'calico_backend' of config map 'calico-config'>  Optional: false
CLUSTER_TYPE:                       k8s,bgp
IP:                                 autodetect
CALICO_IPV4POOL_IPIP:               Always
FELIX_IPINIPMTU:                    <set to the key 'veth_mtu' of config map 'calico-config'>  Optional: false
CALICO_IPV4POOL_CIDR:               <IP_ADDRESS>/16
CALICO_DISABLE_FILE_LOGGING:        true
FELIX_DEFAULTENDPOINTTOHOSTACTION:  ACCEPT
FELIX_IPV6SUPPORT:                  false
FELIX_LOGSEVERITYSCREEN:            info
FELIX_HEALTHENABLED:                true
Mounts:
/lib/modules from lib-modules (ro)
/run/xtables.lock from xtables-lock (rw)
/var/lib/calico from var-lib-calico (rw)
/var/run/calico from var-run-calico (rw)
/var/run/secrets/kubernetes.io/serviceaccount from calico-node-token-nkf26 (ro)
Conditions:
Type              Status
Initialized       True
Ready             False
ContainersReady   False
PodScheduled      True
Volumes:
lib-modules:
Type:          HostPath (bare host directory volume)
Path:          /lib/modules
HostPathType:
var-run-calico:
Type:          HostPath (bare host directory volume)
Path:          /var/run/calico
HostPathType:
var-lib-calico:
Type:          HostPath (bare host directory volume)
Path:          /var/lib/calico
HostPathType:
xtables-lock:
Type:          HostPath (bare host directory volume)
Path:          /run/xtables.lock
HostPathType:  FileOrCreate
cni-bin-dir:
Type:          HostPath (bare host directory volume)
Path:          /opt/cni/bin
HostPathType:
cni-net-dir:
Type:          HostPath (bare host directory volume)
Path:          /etc/cni/net.d
HostPathType:
host-local-net-dir:
Type:          HostPath (bare host directory volume)
Path:          /var/lib/cni/networks
HostPathType:
calico-node-token-nkf26:
Type:        Secret (a volume populated by a Secret)
SecretName:  calico-node-token-nkf26
Optional:    false
QoS Class:       Burstable
Node-Selectors:  beta.kubernetes.io/os=linux
Tolerations:     :NoSchedule
:NoExecute
CriticalAddonsOnly
node.kubernetes.io/disk-pressure:NoSchedule
node.kubernetes.io/memory-pressure:NoSchedule
node.kubernetes.io/network-unavailable:NoSchedule
node.kubernetes.io/not-ready:NoExecute
node.kubernetes.io/pid-pressure:NoSchedule
node.kubernetes.io/unreachable:NoExecute
node.kubernetes.io/unschedulable:NoSchedule
Events:
Type     Reason     Age   From             Message

Normal   Pulled     51m   kubelet, user08  Container image "calico/cni:v3.6.5" already present on machine
Normal   Created    51m   kubelet, user08  Created container upgrade-ipam
Normal   Started    51m   kubelet, user08  Started container upgrade-ipam
Normal   Pulled     51m   kubelet, user08  Container image "calico/cni:v3.6.5" already present on machine
Normal   Created    51m   kubelet, user08  Created container install-cni
Normal   Started    51m   kubelet, user08  Started container install-cni
Normal   Pulled     51m   kubelet, user08  Container image "calico/node:v3.6.5" already present on machine
Normal   Created    51m   kubelet, user08  Created container calico-node
Normal   Started    51m   kubelet, user08  Started container calico-node
Warning  Unhealthy  51m   kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect: no such file or directory
Normal   Scheduled  51m  default-scheduler  Successfully assigned kube-system/calico-node-wh7dr to user08
Warning  Unhealthy  51m  kubelet, user08    Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:02:19.322 [INFO][278] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  51m  kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:02:29.318 [INFO][315] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  51m  kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:02:39.330 [INFO][341] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  50m  kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:02:49.268 [INFO][377] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  50m  kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:02:59.247 [INFO][407] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  50m  kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:03:09.264 [INFO][430] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  50m  kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:03:19.256 [INFO][462] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  50m  kubelet, user08  Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:03:29.244 [INFO][489] readiness.go 88: Number of node(s) with BGP peering established = 0
Warning  Unhealthy  91s (x292 over 50m)  kubelet, user08  (combined from similar events): Readiness probe failed: Threshold time for bird readiness check:  30s
calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>2019-09-04 01:52:09.237 [INFO][8711] readiness.go 88: Number of node(s) with BGP peering established = 0

Do you hosts have multiple IP addresses? I'm guessing yes and that calico-node is selecting the wrong IP address to use. This is based on the BGP not established being for <IP_ADDRESS> yet the describe pod for calico-node (which is host networked) has <IP_ADDRESS> and also I see that your apiserver address is <IP_ADDRESS>. So I'm guessing your hosts should be using addresses in 10.168.x.x but at least one is using <IP_ADDRESS>.  You should take a look at https://docs.projectcalico.org/v3.8/reference/node/configuration#ip-setting, specifically IP autodetection as I expect you need to configure that.

I have the same problem, any solutions?

@JLoveI worked for me: https://github.com/projectcalico/calico/issues/2042#issuecomment-408488357

I also have the same problem
The following logs:[ERROR][59] health.go 238: Health endpoint failed, trying to restart it... error=listen tcp <IP_ADDRESS>:9099: bind: address already in use
kubectl describe pod:Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect: no such file or directory

calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect: no such file or directory

This appeared to be a transient issue in the original post. Agree with @tmjd that this feels like a misconfigured IP address auto-detection issue (and is supported by this comment as well: https://github.com/projectcalico/calico/issues/2834#issuecomment-542645416)
Also worth noting that we improved BIRD liveness reporting in our most recent release which might help in this area.

I had the same problem with "calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect: no such file or directory".
I checked the logs and the calico node was complaining (not an error, just a warning) that the kernel version was too old (running Ubuntu Server 18.04, kernel version 4.15.0-96-generic, it wanted 4.16 I think) and something failed. I did a distro upgrade to Ubuntu version 20.04 (kernel version 5.4.0-58-generic), and now it just works.

I had the same problem with "calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect: no such file or directory".
I checked the logs and the calico node was complaining (not an error, just a warning) that the kernel version was too old (running Ubuntu Server 18.04, kernel version 4.15.0-96-generic, it wanted 4.16 I think) and something failed. I did a distro upgrade to Ubuntu version 20.04 (kernel version 5.4.0-58-generic), and now it just works.

One of solutions: open 179/tcp (BGP) port between nodes.


items > anyOf with different primitive types not rendered

Description
to validate an array with different primitive types like [1, 'string'] I need to to define arrays like
properties: {
   my_array_fail: {
      title: 'Failing',
      items: {
        anyOf: [
          {
            type: 'number',
          },
          {
            type: 'string',
          },
        ],
      },
      type: 'array',
    },

but formly seems to only support item > anyOf with object-like items like:
my_array_ok: {
      title: 'Working:',
      items: {
        type: 'object',
        anyOf: [
          {
            properties: {
              num: {
                type: 'number',
              },
            },
          },
          {
            properties: {
              str: {
                type: 'string',
              },
            },
          },
        ],
      },
      type: 'array',
    }

which will result in another format like [{num: 1}, {str: 'string'}]. Both should be valid json schema.
Minimal Reproduction
https://angular-ejt321-njzkzs.stackblitz.io
Your Environment

Angular version: 18+
Formly version: 6+

This issue has been fixed and released as part of v6.3.8 release.
Please let us know, in case you are still encountering a similar issue/problem.
Thank you!


add test that shows how lambda tokenization is broken

https://github.com/dask-contrib/dask-expr/pull/223 had good intention and introduced a utility function _tokenize_deterministic that is setting the tokenize.ensure-deterministic flag such that we can ensure that the tokens we're generating are indeed deterministic.
Determinism in this context is mildly ambiguous and there are subtly different consistency guarantees we need if we want to pickle Expr objects in a way that is deterministic across python processes/interpreters
Essentially everything we'd need to fall back to cloudpickle to serialize is also susceptible to not being deterministically tokenized (therefore this loosely relates to https://github.com/dask-contrib/dask-expr/pull/331#discussion_r1357189975 even though those are separate issues) since the tokenization is using cloudpickle behind the scenes for those cases. In way that defeats the entire purpose of the tokenization engine (see point 3. below).
https://github.com/dask-contrib/dask-expr/pull/223 also implemented a "fix" for LambdaType functions which is using the str representation of those functions which looks like <function func.<locals>.<lambda> at 0x107363be0>. This is unique inside of an interpreter session but not beyond.
This effectively hard blocks https://github.com/dask-contrib/dask-expr/issues/14
There are a couple of options (I'm not really happy about either but here we go...)

Enforce pickle as a serialization protocol and forbid usage of local functions, types, etc. (effectively https://github.com/dask-contrib/dask-expr/pull/331 but this would expand to all user APIs. We could wrap user defined objects with some magical class but this would feel a little awkward I think)
A slightly better/milder version of 1). I believe we can define deterministic cross-interpreter tokens for lambdas/local functions. I had something like this in a version of https://github.com/dask/dask/pull/10808 but it turned out to not be python version stable so I ended up removing it again. I'd have to run a couple
Abandon tokenization entirely. Inside of an interpreter this problem is easy since if an object doesn't implement a __hash__ we could just use it's id for a unique identifier and hash. From what I understand the entire tokenization is merely for the distributed scheduler but I see a way how to avoid that. This would require us to rewrite how client and scheduler are communicating in dask/distributed but I believe this is doable with a reasonable amount of effort. The scheduler would de-facto be the source of truth and be responsible for key generation and not the other way round. Locally generated keys would no longer map to remote keys. That would be fine, I guess?

cc @rjzamora @mrocklin @phofl
Note: This problem has been around forever. HLGs were not as much affected by this since their names are actually not unique (e.g. https://github.com/dask/dask/issues/9888). Expr are calculating names/tokens recursively which is objectively much better for key uniqueness but also means that if there is any object inside of the expr-tree that cannot be tokenized deterministically, this affects the entire tree.

Unless there are other options I am not seeing, 3) would be the most permissive thinking about users. Since this is also the one with the most uncertainty I'll probably invest some time and whip up a prototype outlining what I'm thinking.
Short term we may just postpone scheduler integration since I don't think this is critical for a release but I'd like to know what our options are. If we were forced to go with option 1) it would be good to know before the release

There is also the option of making cloudpickle actually deterministic. There has been a little progress on that front https://github.com/cloudpipe/cloudpickle/issues/453 https://github.com/cloudpipe/cloudpickle/pull/524

Can someone help me understand the cost of non-deterministic hashing in
dask-expr?  Historically hashing was a nice way to avoid work, but if it
didn't work then 🤷♂ we just did a bit more work.  I'm guessing that this
comes down to the fact that we recreate the same object repeatedly in the
optimization process, and need to see if the object is the same or not.  Is
that right?
On Thu, Jan 18, 2024 at 6:15 AM Florian Jetter @.***>
wrote:

There is also the option of making cloudpickle actually deterministic.
There has been a little progress on that front cloudpipe/cloudpickle#453
https://github.com/cloudpipe/cloudpickle/issues/453
cloudpipe/cloudpickle#524
https://github.com/cloudpipe/cloudpickle/pull/524
—
Reply to this email directly, view it on GitHub
https://github.com/dask-contrib/dask-expr/pull/765#issuecomment-1898369375,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTD5WCR7GCNR5UJGCE3YPEG6RAVCNFSM6AAAAABCACROXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJYGM3DSMZXGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

The assumption that the name attribute of an expression is the same if the expression has exactly the same operands is deeply baked into our optimization logic

Apart form the optimization logic itself, the way distributed is currently built is roughly as
Client side

Take expr and optimize it
Generate the final output keys
Use those keys to generate Futures we can fetch and listen to

Scheduler side

Take the expression and materialize it
Compute stuff
If one of the keys that the client asked for is ready, let the client know (If the keys generated on client side don't match with the actual graph keys we'll deadlock because the client is waiting for the results of keys that don't exist

Changing this procedure is what I meant with 3) but this is a bit of work. I was hoping to not have to do this, particularly not while still supporting HLGs

One dumb approach (maybe not the approach that we want to take) is that we optionally store a finalized key on the expression before we serialize it.  So on the client side we do all of our optimizations, get a nice expr that we like, finalize the key on the expression, then serialize it up to the scheduler.  The _name property checks for that finalized key and if it exists uses it instead of tokenization.
This seems like it would be easy short term.  It would stop us from doing scheduler-side optimization (which I think we're all excited about medium-term) but might give us the fast client-scheduler communications we want in the meantime.

I haven't looked carefully through this code or other linked work yet. However, just to check my rough understanding - It seems like there are two challenges here:

Client-side dask-expr depends on deterministic tokenization to function. We identify an expression by its name, and its name depends directly on the tokenization of its operands. There are some cases (e.g. local functions) where the necessary "determinism" is broken and/or it limits what a user can do. Possible solutions:

Find a way to avoid tokenization (seems difficult)
Use something like inspect.getsource to automatically convert local/lambda objects to a deterministic strings (probably still has problems/limitations)
Something else...

In order for us to materialize expressions on the scheduler, we need the expression names to be the same on the client and scheduler. However, even some objects that pass the _tokenize_deterministic test will not actually tokenize to the same value on the client and scheduler. Possible solutions:

We do something like Matts last suggestion. To unlock scheduler-side optimizations in the future, it may even be possible to "freeze" the keys on the client and then "remap" them on the scheduler. Things should be okay if the scheduler keeps track of the mapping between the new and original keys (maybe?).
Something else...

I'd be fine with a finalized name after optimization

@fjetter - Just a note that I submitted https://github.com/dask-contrib/dask-expr/pull/767 to demonstrate how the tests added in this PR will pass if we use inspect to normalize local/lambda functions.

reposting here
the most recent commit on main of cloudpickle (not released yet) likely solves the lambda problem but there are still cases that are not handled well.
It's easy for us to verify on scheduler side if the tokenization was successful so we can abort with a clear exception. Maybe the new cloudpickle plus that scheduler side verification is good enough for us?

Status update
The PRs linked from https://github.com/dask/dask/issues/10905 make lambdas tokenization deterministic, with the current released version of cloudpickle, on the same Python interpreter. Nothing should be expected across processes or hosts.
So we'll either need tokens to be generated on the client and then shipped to the scheduler, or the scheduler to generate them first and ship them back to the client (the latter is more involved because as of today we use batched comms, which is one-directional, but the client would need to be informed of what keys they just gained in who_wants).
It would be trivial to add a single line to the dask tokenize method that bakes in an unique interpreter ID, so that we can see things fail hard and fast in trivial use cases instead of waiting for the edge cases of cloudpickle.
It of course remains possible to have some obscure third-party object (callable or not) that doesn't cloudpickle deterministically AND comes with neither __dask_tokenize__ method nor normalize_token.register attached to it. Nothing we can do about that besides being as loud as possible when that happens (read: don't silently hang).

Superseded by #https://github.com/dask/dask/pull/10883


how to execute metorikku in a loop from a single spark-submit?

use-case: near-real time sync from MSSQL db to s3.
I know I can do a while loop calling spark-submit each time but this will be slow as JVM needs to startup each time. Is there a way to make metorikku keep on looping through the same input/metric.yaml within a single spark-submit?
note: i know should have kafka..etc but not an option at this stage

We don't have such a feature, but it's a cool idea to create fake micro batches in metorikku to stream on non streaming sources


Is there a reason why there are no bindings to AddFocusEvent ?

https://github.com/imgui-rs/imgui-rs/blob/8140b3f0a8662927432a139e19767618f0e328f2/imgui-sys/src/bindings.rs#L3834

Not particularly -- I'd take a PR!


Add a few samples for Istio RBAC.

@liminw: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
2c59c78ac1567ce19f77d7d5a47291901935357b
link
/test e2e-smoke

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-simple

/lgtm

@liminw: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
a71687a627661063e2f785bee258f33cb2c1a18a
link
/test e2e-smoke

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@liminw: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
a71687a627661063e2f785bee258f33cb2c1a18a
link
/test e2e-smoke

prow/istio-pilot-e2e.sh
a71687a627661063e2f785bee258f33cb2c1a18a
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/lgtm
/approve

e2e-simple circleci failure caused by #3225 unrelated problem with istioct kube-inject


getAnimeEpisodes returns null in the URL field of some episodes.

The docs indicate that the url field in each element of the array returned by getAnimeEpisodes is not nullable, yet it returns null for some anime.
To reproduce:
curl https://api.jikan.moe/v4/anime/51815/episodes (Kubo-san wa Mob wo Yurusanai).
{"pagination":{"last_visible_page":1,"has_next_page":true},"data":[{"mal_id":1,"url":null,"title":"The Heroine Girl and the Invisible Boy","title_japanese":"\u30d2\u30ed\u30a4\u30f3\u5973\u5b50\u3068\u30e2\u30d6\u7537\u5b50","title_romanji":"Heroine Joshi to Mob Danshi\u00a0","aired":"2023-01-10T00:00:00+00:00","score":4.3,"filler":false,"recap":false,"forum_url":"https:\/\/myanimelist.net\/forum\/?topicid=2069094"},{"mal_id":2,"url":null,"title":"Bad Luck and Home Visit","title_japanese":"\u30cf\u30fc\u30c9\u30e9\u30c3\u30af\u3068\u81ea\u5b85\u8a2a\u554f","title_romanji":"Hard Luck to Jitaku Houmon\u00a0","aired":"2023-01-17T00:00:00+00:00","score":4.4,"filler":false,"recap":false,"forum_url":"https:\/\/myanimelist.net\/forum\/?topicid=2070677"},{"mal_id":3,"url":null,"title":"The Nobody's Gift","title_japanese":"\u51e1\u8005\u306e\u8d08\u308a\u7269","title_romanji":null,"aired":"2023-01-24T00:00:00+00:00","score":4.5,"filler":false,"recap":false,"forum_url":"https:\/\/myanimelist.net\/forum\/?topicid=2072137"},{"mal_id":4,"url":null,"title":"Red Heart and Sender","title_japanese":"\u8d64\u3044\u30cf\u30fc\u30c8\u3068\u9001\u308a\u4e3b","title_romanji":"Akai Heart to Okurinushi\u00a0","aired":"2023-01-31T00:00:00+00:00","score":4.4,"filler":false,"recap":false,"forum_url":"https:\/\/myanimelist.net\/forum\/?topicid=2073620"}]}

Note that requesting the episode directly does return a valid URL:
$ curl https://api.jikan.moe/v4/anime/51815/episodes/1
{"data":{"mal_id":1,"url":"https:\/\/myanimelist.net\/anime\/51815\/Kubo-san_wa_Mob_wo_Yurusanai\/episode\/1","title":"The Heroine Girl and the Invisible Boy","title_japanese":"\u30d2\u30ed\u30a4\u30f3\u5973\u5b50\u3068\u30e2\u30d6\u7537\u5b50","title_romanji":"Heroine Joshi to Mob Danshi","duration":1420,"aired":"2023-01-10T00:00:00+09:00","filler":false,"recap":false,"synopsis":null}}

I thought at first this is an API error, but it's not. Transferring it back to Jikan repo.


Do not load ActiveRecord too early

The problem is well described in https://github.com/rails/rails/issues/46567.
We are currently hitting this when upgrading to rails 7.2.

Thanks @fatkodima, this looks good. Can you please rebase on current master which now includes #329?

Rebased.

@fatkodima thanks!

@fatkodima I have just released acts_as_paranoid version 0.10.0 which includes this fix.


Add tuya webrtc support

Hello,
I ported https://github.com/tuya/webrtc-demo-go to go2rtc to add direct support for Tuya cameras.
It worked for me (I could see the video feed through the go2rtc web interface), but I'm a complete newbie to Golang, so I need help to make this code clean enough. Please guide me, I'll try to do my best.
Also, another major problem I encountered is that ICE sessions should be pion.ICERoleControlled even though it's incorrect according to the standard. So I had to hack my way around this issue using SDPTypePranswer. Do you have any suggestions on how to handle this situation properly?
I guess these issues are related:

https://github.com/AlexxIT/go2rtc/issues/1345
https://github.com/AlexxIT/go2rtc/issues/315

This is awesome!
@romasku, perhaps you can also add your new source instructions/information to the README?

@felipecrs I've updated Readme to include an example, it's the same parameters as for Tuya's demo.

@romasku it works! Awesome!
One issue though, it only works the first time. If I stop the stream and try to access it again, it fails with:

To make it work again, I have to restart go2rtc.

@pergolafabio I think you should try your famous pet feeder against this.

Hmm, looks interesting, though, I never got the camera stream working with that webrtc-demo-go app...
I have now a working stream through the tuna cloud integration... But gonna try this one indeed!!

is there an easy way to test this as an addon? or better wait to get merged in master?

In my case I cloned the repo and built the executable, and ran it in my machine, not in my HA.

hmm, build the binary too, add the stream url with correct params, but i got black screen, and this is my log:
23:13:49.160 INF go2rtc platform=windows/amd64 revision=a33d95b version=1.9.4
23:13:49.161 INF config path="C:\\Users\\Fabio.Pergola\\Downloads\\go2rtc_win64\\go2rtc.yaml"
23:13:49.163 INF [rtsp] listen addr=:8554
23:13:49.163 INF [api] listen addr=:1984
23:13:49.164 INF [webrtc] listen addr=:8555/tcp
2024/10/01 23:14:03 motoID: signaling14905
2024/10/01 23:14:03 auth: TfjsIc12CtKPGct6AYbGK7dqbY+c81unIkFoUoOc9PU=
2024/10/01 23:14:03 iceServers: [{"urls":"stun:<IP_ADDRESS>:3478"},{"urls":"turn:<IP_ADDRESS>:3478","username":"1727853242:bfa87264438073154dhdek","credential":"c6WycO5DvPqqG63a2sh1qq5wICE="}]
2024/10/01 23:14:03 hubConfig: {Url:ssl://m1.tuyaeu.com:8883 ClientID:cloud_new2873f36e604fe93f644cbaba1b79cba3 Username:cloud_new551640cb44874dddaca860827477e6e1 Password:a98b34eb126fe1b015b44de947dc4883 SinkTopic:{IPC:/av/moto/moto_id/u/{device_id}} SourceSink:{IPC:/av/u/new551640cb44874dddaca860827477e6e1} ExpireTime:7200}
2024/10/01 23:14:03 publish topic: /av/moto/signaling14905/u/bfa87264438073154dhdek
2024/10/01 23:14:03 subscribe topic: /av/u/new551640cb44874dddaca860827477e6e1
2024/10/01 23:14:03 cloud_new2873f36e604fe93f644cbaba1b79cba3 connect to mqtt success
2024/10/01 23:14:03 subscribe mqtt topic success
pc INFO: 2024/10/01 23:14:06 signaling state changed to have-local-offer
ice DEBUG: 23:14:06.150831 gather.go:465: Failed to resolve STUN host: <IP_ADDRESS>:3478: address <IP_ADDRESS>: no suitable address found
ice DEBUG: 23:14:06.150831 gather.go:465: Failed to resolve STUN host: <IP_ADDRESS>:3478: address <IP_ADDRESS>: no suitable address found
turnc DEBUG: 23:14:06.150831 client.go:119: Resolved TURN server <IP_ADDRESS>:3478 to <IP_ADDRESS>:3478
turnc DEBUG: 23:14:06.236825 udp_conn.go:66: Initial lifetime: 600 seconds
turnc DEBUG: 23:14:06.237930 udp_conn.go:81: Started refresh allocation timer
turnc DEBUG: 23:14:06.237930 udp_conn.go:84: Started refresh permission timer
2024/10/01 23:14:06 mqtt recv message, session: ISaQfL, type: answer, from: bfa87264438073154dhdek, to: new551640cb44874dddaca860827477e6e1
pc INFO: 2024/10/01 23:14:06 signaling state changed to have-remote-pranswer
pc INFO: 2024/10/01 23:14:06 signaling state changed to stable
ice DEBUG: 23:14:06.249914 agent.go:404: Started agent: isControlling? true, remoteUfrag: "VAcUwwcRdfjANvLS", remotePwd: "WoEPSwjUeDSJpwbryLEJIAMLOpAZtTiY"
ice INFO: 2024/10/01 23:14:06 Setting new connection state: Checking
pc INFO: 2024/10/01 23:14:06 ICE connection state changed: checking
pc INFO: 2024/10/01 23:14:06 peer connection state changed: connecting
ice INFO: 2024/10/01 23:14:06 Failed to send packet: write udp <IP_ADDRESS>:54267-><IP_ADDRESS>:64054: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:06 Failed to send packet: write udp <IP_ADDRESS>:54271-><IP_ADDRESS>:64054: wsasendto: A socket operation was attempted to an unreachable network.
turnc DEBUG: 23:14:06.324947 udp_conn.go:438: Channel binding successful: <IP_ADDRESS>:64054 16384
ice INFO: 2024/10/01 23:14:06 Setting new connection state: Connected
pc INFO: 2024/10/01 23:14:06 ICE connection state changed: connected
dtls DEBUG: 23:14:06.545126 conn.go:775: CipherSuite not initialized, queuing packet
dtls DEBUG: 23:14:06.545446 conn.go:697: received packet of next epoch, queuing packet
pc INFO: 2024/10/01 23:14:06 peer connection state changed: connected
pc WARNING: 2024/10/01 23:14:06 Failed to start manager: ICETransport can only be called in ICETransportStateNew
pc INFO: 2024/10/01 23:14:06 signaling state changed to have-remote-offer
ice DEBUG: 23:14:07.072625 agent.go:404: Started agent: isControlling? false, remoteUfrag: "HCoj", remotePwd: "ajSyhCr03e7BuRLlsI/E1gAu"
ice INFO: 2024/10/01 23:14:07 Setting new connection state: Checking
ice WARNING: 2024/10/01 23:14:07 Failed to ping without candidate pairs. Connection is not possible yet.
pc INFO: 2024/10/01 23:14:07 signaling state changed to stable
pc INFO: 2024/10/01 23:14:07 ICE connection state changed: checking
pc INFO: 2024/10/01 23:14:07 peer connection state changed: connecting
ice DEBUG: 23:14:07.073715 gather.go:183: GetConn by ufrag: pbAimpGDLuGsFpOb
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54275-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice DEBUG: 23:14:07.074681 gather.go:465: Failed to resolve STUN host: stun.l.google.com:19302: lookup stun.l.google.com: getaddrinfow: The requested name is valid, but no data of the requested type was found.
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54275-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice DEBUG: 23:14:07.075900 gather.go:183: GetConn by ufrag: pbAimpGDLuGsFpOb
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54275-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54277-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54275-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54277-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice DEBUG: 23:14:07.077744 gather.go:183: GetConn by ufrag: pbAimpGDLuGsFpOb
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54275-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54277-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice DEBUG: 23:14:07.078951 agent.go:1145: Adding a new peer-reflexive candidate: <IP_ADDRESS>:59656
ice DEBUG: 23:14:07.078951 gather.go:183: GetConn by ufrag: pbAimpGDLuGsFpOb
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54275-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54277-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:07 Failed to send packet: write udp <IP_ADDRESS>:54277-><IP_ADDRESS>:59656: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/01 23:14:07 Setting new connection state: Connected
pc INFO: 2024/10/01 23:14:07 ICE connection state changed: connected
ice DEBUG: 23:14:07.080769 gather.go:183: GetConn by ufrag: pbAimpGDLuGsFpOb
pc INFO: 2024/10/01 23:14:07 peer connection state changed: connected
pc DEBUG: 23:14:07.149402 peerconnection.go:466: got new track: &{mu:{w:{state:0 sema:0} writerSem:0 readerSem:0 readerCount:{_:{} v:0} readerWait:{_:{} v:0}} id:video streamID:WetvF0FpaPPzzDLXUB65I0WXFfmWxiOMv6K8 payloadType:96 kind:2 ssrc:1628712413 rtxSsrc:0 codec:{RTPCodecCapability:{MimeType:video/H264 ClockRate:90000 Channels:0 SDPFmtpLine:level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f RTCPFeedback:[{Type:goog-remb Parameter:} {Type:ccm Parameter:fir} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:transport-cc Parameter:}]} PayloadType:96 statsID:} params:{HeaderExtensions:[] Codecs:[{RTPCodecCapability:{MimeType:video/H264 ClockRate:90000 Channels:0 SDPFmtpLine:level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f RTCPFeedback:[{Type:goog-remb Parameter:} {Type:ccm Parameter:fir} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:transport-cc Parameter:}]} PayloadType:96 statsID:}]} rid: receiver:0xc00024c3f0 peeked:[128 96 12 182 13 199 214 71 97 20 45 221 64 1 12 1 255 255 1 64 0 0 3 0 144 0 0 3 0 0 3 0 120 188 9] peekedAttributes:map[0:0xc00068a320]}
srtp INFO: 2024/10/01 23:14:07 srtp ssrc=1628712413 index=3254: duplicated packet
srtp INFO: 2024/10/01 23:14:07 srtp ssrc=1628712413 index=3255: duplicated packet
...................
srtp INFO: 2024/10/01 23:14:07 srtp ssrc=1628712413 index=3306: duplicated packet
srtp INFO: 2024/10/01 23:14:07 srtp ssrc=1628712413 index=3307: duplicated packet
pc DEBUG: 23:14:07.182172 peerconnection.go:466: got new track: &{mu:{w:{state:0 sema:0} writerSem:0 readerSem:0 readerCount:{_:{} v:0} readerWait:{_:{} v:0}} id:audio streamID:WetvF0FpaPPzzDLXUB65I0WXFfmWxiOMv6K8 payloadType:0 kind:1 ssrc:3462549208 rtxSsrc:0 codec:{RTPCodecCapability:{MimeType: ClockRate:0 Channels:0 SDPFmtpLine: RTCPFeedback:[]} PayloadType:0 statsID:} params:{HeaderExtensions:[] Codecs:[]} rid: receiver:0xc00024c360 peeked:[128 128 241 60 202 24 110 216 206 98 78 216 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254] peekedAttributes:map[0:0xc000504e10]}
srtp INFO: 2024/10/01 23:14:07 srtp ssrc=1628712413 index=3308: duplicated packet
................
srtp INFO: 2024/10/01 23:14:07 srtp ssrc=1628712413 index=3329: duplicated packet
srtp INFO: 2024/10/01 23:14:07 srtp ssrc=1628712413 index=3330: duplicated packet
ice DEBUG: 23:14:07.274269 agent.go:1145: Adding a new peer-reflexive candidate: <IP_ADDRESS>:59656
ice DEBUG: 23:14:07.335998 agent.go:1145: Adding a new peer-reflexive candidate: <IP_ADDRESS>:59656
pc WARNING: 2024/10/01 23:14:12 Incoming unhandled RTCP ssrc(767835711), OnTrack will not be fired

i also see this below, but restarting go2rtc doesnt help

@pergolafabio, try a different Tuya camera if you have, just in case. It also didn't work for one of mine.

i only have one :)

i only have one :)

Lucky you!!!

Hey @romasku , i see you added a new commit, is that helpfull for me? i have some issues getting the stream, see the logs above...
thnx for looking into it!

Hi, I've fixed the "uid not exist" issue (hopefully). Also, the current code uses global variables (the same as the original Tuya code), which can lead to issues if you try to open multiple streams at once. I'll try to work on this part later.
@pergolafabio
I see in your logs pc DEBUG: 23:14:07.149402 peerconnection.go:466: got new track:, this means that go2rtc was able to connect and acquire video and audio streams. This can be an issue with the go2rtc -> your browser connection (maybe I introduced some bug), or your device just streams a black screen via WebRTC. Can you please check, maybe the audio works?

hmm, i was testing on http , since i just used the compiled binary, is https maybe needed? for the browser?
i check also audio

If you use localhost as hostname, then https is not required. I'm testing via http://localhost:1984/ .

ok, i check later
i have the HA Tuya Cloud integration active, to display the camera feed in HA, should i stop that one, maybe it doesnt allow multiple streams?

btw, i remember testing the webrtc-demo-go app , i never got that working either, also black screen
so i wonder how the Tuya Cloud integration is working? isnt that the same api ?

As I see from logs, go2rtc got access to some stream data, so the issue should be either that the stream is corrupt or unable to go to your end device. So it shouldn't be a conflict with HA Tuya Cloud (I had both running at the same time for my camera). But you can try checking it.
HA Tuya Cloud uses RTSP stream (AFAIK), so it is a different API. But you can check if this official Tuya web app works: https://protect-eu.ismartlife.me/login (maybe select a different region), as it uses WebRTC the same way as the webrtc-demo-go app.

Tested that link, and i see the stream there, so thats already a good sign :-)
when activating that link, chrome asked me to allow the mic access

tested again, with new version, i dont hear any audio either, strange that the other link does work?
what can i do to investigate?
11:12:05.672 INF go2rtc platform=windows/amd64 revision=a0b9883 version=1.9.4
11:12:05.673 INF config path="C:\\Users\\Fabio.Pergola\\Downloads\\go2rtc_win64\\go2rtc.yaml"
11:12:05.674 INF [rtsp] listen addr=:8554
11:12:05.674 INF [api] listen addr=:1984
11:12:05.674 INF [webrtc] listen addr=:8555/tcp
2024/10/02 11:12:17 motoID: signaling14905
2024/10/02 11:12:17 auth: TfjsIc12CtKPGct6AYbGK7dqbY+c81unIkFoUoOc9PU=
2024/10/02 11:12:17 iceServers: [{"urls":"stun:<IP_ADDRESS>:3478"},{"urls":"turn:<IP_ADDRESS>:3478","username":"XXX:XXXX","credential":"XXXX"}]
2024/10/02 11:12:17 hubConfig: {Url:ssl://m1.tuyaeu.com:8883 ClientID:cloud_new0813ec0142bc23dd01eec3ae633a59b5 Username:XXXX Password:XXXX SinkTopic:{IPC:/av/moto/moto_id/u/{device_id}} SourceSink:{IPC:/av/u/new551640cb44874dddaca860827477e6e1} ExpireTime:7200}
2024/10/02 11:12:17 publish topic: /av/moto/signaling14905/u/XXX
2024/10/02 11:12:17 subscribe topic: /av/u/new551640cb44874dddaca860827477e6e1
2024/10/02 11:12:17 cloud_new0813ec0142bc23dd01eec3ae633a59b5 connect to mqtt success
2024/10/02 11:12:17 subscribe mqtt topic success
pc INFO: 2024/10/02 11:12:19 signaling state changed to have-local-offer
ice DEBUG: 11:12:19.743698 gather.go:465: Failed to resolve STUN host: <IP_ADDRESS>:3478: address <IP_ADDRESS>: no suitable address found
turnc DEBUG: 11:12:19.743698 client.go:119: Resolved TURN server <IP_ADDRESS>:3478 to <IP_ADDRESS>:3478
ice DEBUG: 11:12:19.743698 gather.go:465: Failed to resolve STUN host: <IP_ADDRESS>:3478: address <IP_ADDRESS>: no suitable address found
turnc DEBUG: 11:12:19.829801 udp_conn.go:66: Initial lifetime: 600 seconds
turnc DEBUG: 11:12:19.829801 udp_conn.go:81: Started refresh allocation timer
turnc DEBUG: 11:12:19.829801 udp_conn.go:84: Started refresh permission timer
2024/10/02 11:12:19 mqtt recv message, session: tg9Ypw, type: answer, from: XXX, to: new551640cb44874dddaca860827477e6e1
pc INFO: 2024/10/02 11:12:19 signaling state changed to have-remote-pranswer
pc INFO: 2024/10/02 11:12:19 signaling state changed to stable
ice DEBUG: 11:12:19.843487 agent.go:404: Started agent: isControlling? true, remoteUfrag: "GOURKYyORblpAFps", remotePwd: "CggvToOJMSBzEXLuzCLtIsNulXCJzqGb"
ice INFO: 2024/10/02 11:12:19 Setting new connection state: Checking
pc INFO: 2024/10/02 11:12:19 ICE connection state changed: checking
pc INFO: 2024/10/02 11:12:19 peer connection state changed: connecting
ice INFO: 2024/10/02 11:12:19 Failed to send packet: write udp <IP_ADDRESS>:64761-><IP_ADDRESS>:60829: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/02 11:12:19 Failed to send packet: write udp <IP_ADDRESS>:64765-><IP_ADDRESS>:60829: wsasendto: A socket operation was attempted to an unreachable network.
turnc DEBUG: 11:12:19.927396 udp_conn.go:438: Channel binding successful: <IP_ADDRESS>:60829 16384
ice INFO: 2024/10/02 11:12:20 Setting new connection state: Connected
pc INFO: 2024/10/02 11:12:20 ICE connection state changed: connected
dtls DEBUG: 11:12:20.163601 conn.go:775: CipherSuite not initialized, queuing packet
dtls DEBUG: 11:12:20.163601 conn.go:697: received packet of next epoch, queuing packet
pc INFO: 2024/10/02 11:12:20 peer connection state changed: connected
pc WARNING: 2024/10/02 11:12:20 Failed to start manager: ICETransport can only be called in ICETransportStateNew
pc INFO: 2024/10/02 11:12:20 signaling state changed to have-remote-offer
ice DEBUG: 11:12:20.562200 agent.go:404: Started agent: isControlling? false, remoteUfrag: "Aw9y", remotePwd: "tDB/DuuG26LhgVTyflRnvm2E"
pc INFO: 2024/10/02 11:12:20 signaling state changed to stable
ice INFO: 2024/10/02 11:12:20 Setting new connection state: Checking
ice WARNING: 2024/10/02 11:12:20 Failed to ping without candidate pairs. Connection is not possible yet.
pc INFO: 2024/10/02 11:12:20 ICE connection state changed: checking
pc INFO: 2024/10/02 11:12:20 peer connection state changed: connecting
ice DEBUG: 11:12:20.564258 gather.go:183: GetConn by ufrag: rWTDduhKhzPbMXsp
ice INFO: 2024/10/02 11:12:20 Ignoring remote candidate with tcpType active: tcp4 host <IP_ADDRESS>:9
ice INFO: 2024/10/02 11:12:20 Ignoring remote candidate with tcpType active: tcp4 host <IP_ADDRESS>:9
ice INFO: 2024/10/02 11:12:20 Ignoring remote candidate with tcpType active: tcp4 host <IP_ADDRESS>:9
ice DEBUG: 11:12:20.564761 gather.go:465: Failed to resolve STUN host: stun.l.google.com:19302: lookup stun.l.google.com: getaddrinfow: The requested name is valid, but no data of the requested type was found.
ice INFO: 2024/10/02 11:12:20 Ignoring remote candidate with tcpType active: tcp6 host [fd77:ad1d:c209:a392:a5d0:e2e2:4482:7548]:9
ice INFO: 2024/10/02 11:12:20 Failed to send packet: write udp <IP_ADDRESS>:64769-><IP_ADDRESS>:50061: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/02 11:12:20 Ignoring remote candidate with tcpType active: tcp6 host [fd77:ad1d:c209:a392:d4cf:df85:3456:66f4]:9
ice INFO: 2024/10/02 11:12:20 Failed to send packet: write udp <IP_ADDRESS>:64769-><IP_ADDRESS>:50063: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/02 11:12:20 Failed to send packet: write udp <IP_ADDRESS>:64769-><IP_ADDRESS>:50063: wsasendto: A socket operation was attempted to an unreachable network.
ice DEBUG: 11:12:20.567135 gather.go:183: GetConn by ufrag: rWTDduhKhzPbMXsp
ice INFO: 2024/10/02 11:12:20 Failed to send packet: write udp <IP_ADDRESS>:64769-><IP_ADDRESS>:50061: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/02 11:12:20 Failed to send packet: write udp <IP_ADDRESS>:64769-><IP_ADDRESS>:50063: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/02 11:12:20 Failed to send packet: write udp <IP_ADDRESS>:64769-><IP_ADDRESS>:50063: wsasendto: A socket operation was attempted to an unreachable network.
ice INFO: 2024/10/02 11:12:20 Setting new connection state: Connected
ice DEBUG: 11:12:20.568161 gather.go:183: GetConn by ufrag: rWTDduhKhzPbMXsp
pc INFO: 2024/10/02 11:12:20 ICE connection state changed: connected
ice DEBUG: 11:12:20.568763 gather.go:183: GetConn by ufrag: rWTDduhKhzPbMXsp
ice DEBUG: 11:12:20.568821 gather.go:183: GetConn by ufrag: rWTDduhKhzPbMXsp
pc INFO: 2024/10/02 11:12:20 peer connection state changed: connected
pc DEBUG: 11:12:23.187473 peerconnection.go:466: got new track: &{mu:{w:{state:0 sema:0} writerSem:0 readerSem:0 readerCount:{_:{} v:0} readerWait:{_:{} v:0}} id:video streamID:1DRbr3ieYf6BMJMqrhWPzYcbTWjb5n60Xs34 payloadType:96 kind:2 ssrc:4130812713 rtxSsrc:0 codec:{RTPCodecCapability:{MimeType:video/H264 ClockRate:90000 Channels:0 SDPFmtpLine:level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f RTCPFeedback:[{Type:goog-remb Parameter:} {Type:ccm Parameter:fir} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:transport-cc Parameter:}]} PayloadType:96 statsID:} params:{HeaderExtensions:[] Codecs:[{RTPCodecCapability:{MimeType:video/H264 ClockRate:90000 Channels:0 SDPFmtpLine:level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f RTCPFeedback:[{Type:goog-remb Parameter:} {Type:ccm Parameter:fir} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:nack Parameter:} {Type:nack Parameter:pli} {Type:transport-cc Parameter:}]} PayloadType:96 statsID:}]} rid: receiver:0xc0000ba360 peeked:[128 96 44 25 160 102 193 104 246 55 51 41 66 1 1 1 64 0 0 3 0 144 0 0 3 0 0 3 0 120 160 3 192 128 16 229 158 251 145 40 94 2 148 20 20 23 132 0 0 3 0 4 0 0 3 0 40 190 16 8 32] peekedAttributes:map[0:0xc00007d220]}
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11289: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11290: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11291: duplicated packet
................
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11336: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11337: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11338: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11339: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11336: duplicated packet
pc DEBUG: 11:12:23.221258 peerconnection.go:466: got new track: &{mu:{w:{state:0 sema:0} writerSem:0 readerSem:0 readerCount:{_:{} v:0} readerWait:{_:{} v:0}} id:audio streamID:1DRbr3ieYf6BMJMqrhWPzYcbTWjb5n60Xs34 payloadType:0 kind:1 ssrc:802255331 rtxSsrc:0 codec:{RTPCodecCapability:{MimeType: ClockRate:0 Channels:0 SDPFmtpLine: RTCPFeedback:[]} PayloadType:0 statsID:} params:{HeaderExtensions:[] Codecs:[]} rid: receiver:0xc0000ba2d0 peeked:[128 128 200 235 208 47 95 158 47 209 113 227 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254 254] peekedAttributes:map[0:0xc0000b65a0]}
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11337: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11338: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11339: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11336: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11337: duplicated packet
...........
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11352: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11349: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11350: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11351: duplicated packet
srtp INFO: 2024/10/02 11:12:23 srtp ssrc=4130812713 index=11352: duplicated packet
pc WARNING: 2024/10/02 11:12:28 Incoming unhandled RTCP ssrc(3202850753), OnTrack will not be fired

@pergolafabio, if this doesn't work for you but HA does, then the following options would also work:

https://github.com/felipecrs/get-tuya-webrtc-configs/blob/master/get_tuya_stream_url.sh
https://github.com/felipecrs/hass-expose-camera-stream-source

I'm already using your script, but I want to avoid setting up tuya cloud integration, since that's the only one working getting the actual stream...
So this PR would be wonderful!!

@pergolafabio, Can you please also check using different go2rtc streamers?
Open links (http://localhost:1984/links.html?src=webrtc-tuya if you use webrtc-tuya for source), and try different links under "H264/H265 source".

@pergolafabio, you don't need to have the Tuya Cloud integration set up if you use:

https://github.com/felipecrs/get-tuya-webrtc-configs/blob/master/get_tuya_stream_url.sh

I tested that one before, I didn't work, was a long time ago, will check again :-)

I tested that one before, I didn't work, was a long time ago, will check again :-)

It's a different one. It works the same way as Tuya Cloud integration does, except that it doesn't require Home Assistant.
Also, it allows you to select between RTSP and HLS. Some cameras only work through HLS, not WebRTC nor RTSP.

Ok, will test that later, and if doesn't work  I let you know on discord...
I also want to have this one working :-) no need for extra scripts :+)
@romasku , I will test those other links later, I also see you enabled debug, you want me to do some testing again?

@romasku any idea if 2-way audio is also supposed to work? I see the sendonly track in the stream info, but it doesn't seem to work.

@felipecrs
About two-way audio: It should work, but it is Tuya:). It should be as simple as setting sendrecv for audio but for my camera two-way audio doesn't work even with https://protect-eu.ismartlife.me/login. So either it doesn't work for Tuya's WebRTC implementation in general, or my device is broken.

It should be as simple as setting sendrecv for audio

Do you mean I should do something from my side, or do you mean your implementation already handles it?

@felipecrs
I've enabled two-way audio according to Tuya docs, but it doesn't work for me. If it works https://protect-eu.ismartlife.me/login but doesn't work here, please let me know. You can verify that it sends some audio using http://localhost:1984/network.html (or http://homeassistant.local:1984/network.html. To use it in HA just overwrite default go2rtc-1.8.4 binary and restart WebRTC addon. To build for arm (assuming you run HA on Raspberry) use env GOOS=linux GOARCH=arm64 go build -o go2rtc-1.8.4

Thanks a lot, I will try and let you know.

I tested on : https://protect-eu.ismartlife.me/playback
My camera(petfeeder) provides me with two way audio, i can speak to my cats and can hear them :-)
but still struggling why this PR doesnt work? i only see black video, no audio is working as well, tried last commit too..
If i test the script provided by @felipecrs , it gives me an RTSPS string back too
https://github.com/felipecrs/get-tuya-webrtc-configs/blob/master/get_tuya_stream_url.sh
what can i do to test/troubleshoot? :-(

@romasku, another thing to take into consideration is the stream quality. IIRC, you can select the quality (SD/HD) when requesting the WebRTC configs.
Perhaps you can make it a parameter as well?

As I remember, paho.mqtt is a very heavy lib. I will check and not accept this if the app increases in size significantly.

hey @romasku , is this maybe related?
https://github.com/pion/webrtc/issues/1021

@AlexxIT, for your information, I tried compiling both master and this PR, and this is the comparison:
[4.0K]  go2rtc-master
├── [4.4M]  go2rtc_linux_amd64
├── [3.5M]  go2rtc_linux_arm
├── [3.6M]  go2rtc_linux_arm64
├── [3.5M]  go2rtc_linux_armv6
├── [4.0M]  go2rtc_linux_i386
├── [3.4M]  go2rtc_linux_mipsel
├── [5.6M]  go2rtc_mac_amd64.zip
├── [5.2M]  go2rtc_mac_arm64.zip
├── [5.3M]  go2rtc_win32.zip
├── [5.6M]  go2rtc_win64.zip
└── [5.1M]  go2rtc_win_arm64.zip

[4.0K]  go2rtc-tuya
├── [4.6M]  go2rtc_linux_amd64
├── [3.6M]  go2rtc_linux_arm
├── [3.7M]  go2rtc_linux_arm64
├── [3.6M]  go2rtc_linux_armv6
├── [4.1M]  go2rtc_linux_i386
├── [3.5M]  go2rtc_linux_mipsel
├── [5.8M]  go2rtc_mac_amd64.zip
├── [5.4M]  go2rtc_mac_arm64.zip
├── [5.5M]  go2rtc_win32.zip
├── [5.8M]  go2rtc_win64.zip
└── [5.2M]  go2rtc_win_arm64.zip

The uncompressed binaries:
[ 14M]  go2rtc_linux_amd64-master
[ 15M]  go2rtc_linux_amd64-tuya

If that's too big, maybe you'll have a need for paho.mqtt in the future, and then maybe this PR could be viable.

These are unexpectedly good results. Anyway, I'll look into this PR when I have time.


ONNX Support

Thanks for the tool. Any plans to support ONNX?

ONNX would be helpful

My team also mainly uses ONNX to visualize models. Support for this would be great!

Yes, we're planning to support ONNX in this June! Stay tuned!

https://github.com/justinchuby/model-explorer-onnx/

I created an extension for ONNX. Happy to contribute.

@maderix could you share a snapshot to show what you mean?  Had to just flatten the hierarchy to see the missing connection to nodes. Layers were probably messing my graph.
Thanks for the great addition to this repo . Cheers! :)

Hi @ogencoglu, it looks like this is done now. Let us know if you have any other open items here. Thanks.

Hi @ogencoglu, does the above adapter satisfy your use case? Thanks for your help.

I will try out, thanks.


Example on how to save interpolated planes using postprocessing callback

Lets merge #466 than first and I will fix this.


NhostNextProvider bundle size is large

hello everyone, is there any way to reduce the JS size when adding NhostNextProvider with Next.js it adds around 200Kb

This is very problematic for presentational websites. For now I just use SWR insted of NHost sdk.
I tried to investigate this issue with bundle-analyzed. According to some StackOverflows it's because somewhere in the code, nhost imports server-side intended nodejs library. I couldn't find it so my suspicion is that some dependency imports this code.